5 Biểu đồ quan Trọng mà những kiểm thử viên cần tìm hiểu để sử dụng

Nếu không có những hình ảnh thì đã không có những ghi chép về thời tiền sử, sự hiểu biết tương đối và sự tiến hóa của ngôn ngữ.

Không quá phô trương, nhưng những biểu đồ luôn có một vị trí đặc biệt của riêng mình ngay cả trong một thế giới với những biểu mẫu phát triển mạnh và tinh tế về cách viết và cách hiển thị.

Trong ngành công nghiệp công nghệ, các biểu đồ là những người bạn rất gần gũi với chúng ta.

Dưới đây là một trong những biểu đồ nổi bật mà những người kiểm thử chúng ta thường xuyên tiếp xúc và cách sử dụng chúng.

Flow Charts:

Flow chart là tốt nhất để minh họa process. Chúng sử dụng những symbol cụ thể cho từng task/type của hành động được thực hiện trong quá trình. Nó cho phép các quyết định, các nhánh và các vòng lặp ...vv làm cho nó trở thành một công cụ đặc lực cho các tài liệu và việc tìm hiểu.

Các kiểm thử viên sẽ thường xuyên tìm kiếm các flow chart trong test plan, test strategy, các yêu cầu artifacts (BRD, FRD, ...vv) hoặc những tài liệu quy trình khác.

Các symbol thường được sử dụng nhất và ý nghĩa của chúng trong một flow chart là:

• Ovals- Sử dụng Ovals cho Start/Stop
• Rectangles- Sử dụng cho đang xử lý/hoặc 1 task
• Diamond- Sử dụng cho các quyết định

Để hiểu được một process hoăc một flow thông qua một flow chart là cực kì đơn giản. Nó sẽ giúp ghi nhớ, hiểu và dùng như là một tham khảo nhanh.

Dưới đây là 2 cách để kiểm thử viên sử dụng các flow chart:

a) Flow chart cho flow điều khiển và những phần tích thống kế:

Cyclomatic Complexity là một thước đo giúp chúng ta đo lường được đồ phức tạp của một chương trình phần mềm cụ thể. Một trong những cách sử dụng được biết của Cyclomatic Complexity là nó giúp chúng ta hiểu được mức độ kiểm thử đơn vị được thực hiện để đạt được mức độ bao phủ đầy đủ.

Flow chart là một phương pháp để tiến đến cách đo lường này.

Hãy tìm hiểu làm thế nào để tính toán Cyclomatic Complexity cho chương trình sau đây thông qua một control flow chart.

Đơn giản chỉ cần tạo ra một control flow chart như dưới đây và sử dụng cách thức này:

Cyclomatic Complexity = Số lượng các kết nối hoặc line - số nút + 2

Từ sơ đồ trên ta thấy, số nút là 7 và số kết nối là 7. Do đó, Cyclomatic Complexity của đoạn code là: 7-7+2=2

b) Hình ảnh mình họa của Flow chart cho process:

Dưới đây là một quá trình theo dõi lỗi thể hiện trong một định dạng flow chart. Như bạn có thể thấy, nó rất dễ dàng để tiếp thu và thực hiện:

Biểu đồ chuyển trạng thái:

Bảng chuyển trạng thái hoặc biểu đồ là những công vụ phân tích tuyệt vời khi bạn cần tìm kiếm tại các hệ thống phức tạp mà trải qua rất nhiều những thay đổi từ một trạng thái khác.

Đối với những người mới bắt đầu có những người đang suy nghĩ "chuyển trạng thái là gì"- Hãy suy đến một cái bóng đèn được điều khiển mởi một switch. Một switch có thể được đảo ON/OFF. Vì vậy, các trạng thái của bóng đèn có thể ở một thời điểm nhất định là ON hoặc OFF và các sự kiện/hoạt động gây ra nó được chuyển từ một trạng thái khác là đảo switch.

Điều này có thể được thể hiện dưới dạng một biểu đồ hoặc một bảng như dưới đây:

Đơn giản phải không nào? Chúng ta hãy đi vào một cái gì đó phức tạp hơn một chút. Nhìn vào một biểu đồ chuyển trạng thái cho một hệ thống bán vé. Nó khá là đơn giản và dễ hiểu.

Hãy lưu ý rằng, các biểu đồ chuyển trạng thái thường là các thực thể nghiệp vụ trung tâm và không được thể hiện một cách trực quan từng page một.

Ví dụ: Các thực thể nghiệp vụ cốt lõi trong trường hợp của chúng ta là bản thân tấm vé đã được tạo thông qua các ứng dụng. Phần đầu tiên là tạo vé, có thể liên quan đến việc điều hướng hệ thống thông qua một vài page nào đó:

• Page 1 -> Chọn số khách lữ hành: người lớn, trẻ em và người già.
• Page 2 -> Chọn loại vé: vé ngày, vé tuần, vé tháng ... vv
• Page 3 -> Xem lại chi tiết và hoàn thiện.
• Page 4 -> Thực hiện thanh toán...vv

Vì vậy, có thể có nhiều người khác nhau thay đổi từng page một nhưng bản thân cái vé đó thì ở trạng thái đang được thực hiện. Vì vậy chúng tôi thường không tạo ra một biểu đồ ST cho những quá trình chuyển đổi nhìn thấy được (Bạn có thể nếu bạn muốn, nhưng nó không thường xuyên được sử dụng), chúng tôi thực hiện chuyển trạng thái cho những thực thể nghiệp vụ cốt lõi. Dựa vào các biểu đồ ST đã được tạo ra, bạn có thể sử dụng nó để dễ dàng xác định được các kịch bản kiểm thử từ đầu đến cuối và các giao dịch của người dùng cuối như sau:

Ba dòng màu vàng là 3 trường hợp end-to-end khi thực hiện kiểm thử, nó sẽ bao gồm các vùng quan trọng nhất và được sử dụng với hầu hết các ứng dụng. Đây là một công cụ hữu ích để tạo ra các trường hợp kiểm thử có ý nghĩa từ đầu đến khi nghiệm thu.

Context diagrams:

Hệ thống phần mềm hiếm khi các chức năng hoạt động như những đơn vị độc lập. Một ứng dụng đơn giản như calculator, notepad,...vv có thể làm công việc riêng của chúng, nhưng những ứng dụng doanh nghiệp thường giao tiếp với nhiều ứng dụng khác.

Ví dụ: Một hệ thống bản lương có thể tương tác với ứng dụng kế toán, thệ thống time-sheet cho thời gian làm việc và cổng thông tin HR cho các thông tin chi tiết của nhân viên. Context diagram là biểu đồ xuất sắc cho thấy tất cả các mối quan hệ một cách dễ hiểu. Dưới đây là một Context diagram mô tả cho một hệ thống bảng lương:

Đây là một Context diagram rất rõ ràng cho thấy bối cảnh của một hệ thống với các đơn vị khác có liên quan đến nó.

Context Diagram giúp các kiểm thử viên hiểu được hệ thống một cách rộng hơn và hỗ trợ người kiểm thử trong việc tạo ra các chiến lược kiểm thử bao gồm các mối quan hệ trong và ngoài hệ thống với những thực thể khác. Chúng ta không thể tạo ra một context diagram như một phần của quá trình kiểm thử, nhưng nếu có, chúng sẽ hỗ trợ chúng ta một cách tuyệt vời.

Mindmaps:

Một biểu đồ tư duy men theo những suy nghĩ của bạn từ chủ đề này đến chủ đề khác, mỗi suy nghĩ sẽ trở nên sâu và rộng hơn cho mỗi ý tưởng của bạn.Nó là một dạng biểu đồ chỉ bắt đầu với ý tưởng chính của bạn và ghi lại tất cả các suy nghĩ xung quanh mà bắt nguồn từ ý tưởng chính đó.

Biểu đồ tư duy có thể sử dụng bất kỳ điều gì và tất cả mọi thứ. Mặc dù chúng vẫn chưa được xuất hiện trong IEEE, CMMI hoặc các template chuẩn khác hoặc các văn bản quy trình nhưng chúng vẫn là một phần rất phổ biến trong nền công nghệ phần mềm.

Một sử dụng khá phổ biến của biểu đồ tư duy đó là để theo dõi hoạt động kiểm thử tham dò (Tôi biết bạn đang suy nghĩ, tại sao kiểm thử thăm dò cần được theo dõi tất cả? Đó là bởi vì với chu kỳ phát triển nhanh chóng, linh hoạt và các phương thức phát triển phần mềm nhanh chóng khác, dần dần các kiểm thử viên ngày càng khó có khả năng tìm ra thời gian và phạm vi để hoàn thiện tài liệu. Điều này có nghĩa là mức độ thăm dò đang lan rộng và nó vần phải được tăng cường. Biểu đồ tư duy có thể làm điều đó cho bạn.)

Ví dụ: Dưới đây là một biểu đồ cho một ứng dụng thương mại điện tử, ở đây bạn chỉ việc theo dõi các thử nghiệm của mình một cách đơn giản với một biểu đồ tư duy như sau:

Kiểm thử viên có thể không nhận được từ các biểu đồ tư duy như những dữ liệu đầu vào. Nhưng chúng ta có thể thấy các tình huống khi chúng ta tạo ra chúng. Để làm như vậy rất dễ dàng. Bắt đầu với ý tưởng trọng tâm của bạn hoặc bắt đầu với những point và đi theo những suy nghĩ bạn đưa ra. Có nhiều công cụ trực tuyến miễn phí mà bạn có thể sử dụng để lập biểu đồ tư duy một cách đơn giản và dễ dàng.

ER diagrams:

Những biểu đồ quan hệ thực thể (ER) được sử dụng cho các mô hình cơ sở dữ liệu. Chúng giúp chúng ta hiểu được các bảng, các trường và làm thế nào các trường trong một bảng liên kết với các trường trong các bảng khác trong hệ thống DB. Nó cho thấy các thành phần của hệ thống DB của bạn và các mối quan hệ giữa chúng một cách trực quan.

Biểu đồ ER cũng hoạt động như một hoạt động chạy thử đầu tiên của mô hình DB và hình dung ra được trước hệ thống DB sau khi được thiết kế và xây dựng

Biểu đồ ER có các thực thể (Các instance của các bản DB) và những mối quan hệ giữa chúng (quan hệ 1-1, quan hệ 1-n, ...) được thể hiện sử dụng các box và các đường lối chân chim.)

Có rất nhiều biến thể của biểu đồ ER, nhưng phiên bản đơn giản nhất có thể thấy dưới đây:

Kết luận

Trên đây là 5 biểu đồ quan trọng mà các kiểm thử viên nên tìm hiểu để phục vụ cho công việc kiểm thử của mình. Kiến thức là mênh mông vô tận, hy vọng giúp đỡ được cho các bạn phần nào.

Tham khảo: http://www.softwaretestinghelp.com/5-important-diagrams-that-testers-need-to-learn-how-to-use/