Thiết kế trường hợp thử là một phần của kiểm thử hệ thống và kiểm thử thành phần, bạn sẽ thiết kế các trường hợp thử nghiệm (đầu vào và đầu ra dự đoán) để kiểm thử hệ thống.
Mục tiêu của quá trình thiết kế trường hợp kiểm thử là tạo ra một tập các trường hợp thử nghiệm có hiệu quả để phát hiện khiếm khuyết của chương trình và chỉ ra các yêu cầu của hệ thống.
Để thiết kế một trường hợp thử nghiệm, chúng ta chọn một chức năng của hệ thống hoặc của thành phần mà bạn sẽ kiểm thử. Sau đó bạn chọn một tập các đầu vào thực hiện các chức năng đó và cung cấp tài liệu về đầu ra mong muốn và giới hạn của đầu ra, cũng như điểm mà có thể thiết kế tự động để kiểm tra thử nghiệm với đầu ra thực tế và đầu ra mong đợi vẫn như thế.
Có nhiều phương pháp khác nhau giúp bạn có thể thiết kế các trường hợp thử nghiệm:
– Kiểm thử dựa trên các yêu cầu: Các trường hợp thử nghiệm được thiết kế để kiểm thử các yêu cầu hệ thống. Nó được sử dụng trong hầu hết các bước kiểm thử hệ thống, bởi vì các yêu cầu hệ thống thường được thực hiện bởi một vài thành phần. Với nỗi yêu cầu, bạn xác định các trường hợp thử nghiệm để có thể chứng tỏ được hệ thống có yêu cầu đó.
– Kiểm thử phân hoạch: xác định các phân hoạch đầu vào phân hoạch đầu ra và thiết kế thử nghiệm, vì vậy hệ thống thực hiện với đầu vào từ tất cả các phản hoạch và sinh ra đầu ra trong tất cả các phân hoạch. Các phân hoạch là các nhóm dữ liệu có chung đặc tính như tất cả các số đều âm, tất cả tên đều có đều có độ dài nhỏ hơn 30 ký tự, tất cả các sự kiện phát sinh từ việc chọn các mục trên thực đơn…
– Kiểm thử cấu trúc: Bạn sử dụng những hiểu biết về cấu trúc chương trình để thiết kế các thử nghiệm thực hiện tất cả các phần của chương trình. Về cơ bản, khi kiểm thử một chương trình, bạn nên kiểm tra thực thi mỗi câu lệnh ít nhất một lần. Kiểm thử cấu trúc giúp cho việc xác định các trường hợp thử nghiệm.
Thông thường, khi thiết kế các trường hợp thử nghiệm, bạn nên bắt đầu với các thử nghiệm mức cao nhất của các yêu cầu, sau đó thêm dán các thử nghiệm chi tiết bằng cách sử dụng kiểm thử phân hoạch và kiểm thử cấu trúc.
1. Kiểm thử dựa trên các yêu cầu.
Một nguyên lý chung của các yêu cầu kỹ nghệ là các yêu cầu phải có khả năng kiểm thử được. Các yêu cầu nên được viết theo cách mà một thử nghiệm có thể được thiết kế, do đó quan sát viên có thể kiểm tra xem yêu cầu đó đã thỏa mãn chưa.
Vì vậy, kiểm thử dựa trên các yêu cầu là một tiếp cận có hệ thống để thiết kế trường hợp thử nghiệm giúp cho bạn xem xét mỗi yêu cầu và tìm ra các thử nghiệm. Kiểm thử dựa trên các yêu cầu có hiệu quả hơn kiểm thử khiếm khuyết – bạn đang chứng tỏ hệ thống thực hiện được đầy đủ các yêu cầu.
Ví dụ, hãy xem xét các yêu cầu cho hệ thống LIBSYS (hệ thống quản lý thư viện). Người dùng có thể tìm kiếm hoặc tất cả các tập ban đầu của cơ sở dữ liệu hoặc lựa chọn một tập con từ đó; Hệ thống sẽ cung cấp các khung nhìn hợp lý cho người dùng để đọc tài liệu trong kho tài liệu; Mọi yêu cầu sẽ được cấp phát một định danh duy nhất (ORDER_ID) để người dùng có thể được phép sao chép qua tài khoản của vùng lưu trữ thường trực.
Giả sử chức năng tìm kiếm đã được kiểm thử, thì các thử nghiệm có thể chấp nhận được cho yêu cầu thứ nhất là: Ban đầu, người dùng tìm kiếm các mục đã biết sự có mặt và không có trong tập cơ sở dữ liệu chỉ gồm một cơ sở dữ liệu; Ban đầu, người dùng tìm kiếm các mục đã biết sự có mặt và không có trong tập cơ sở dữ liệu gồm có hai cơ sở dữ liệu; Ban đầu, người dùng tìm kiếm các mục đã biết sự có mặt và không có trong tập cơ sở dữ liệu gồm có nhiều hơn hai cơ sở dữ liệu; Lựa chọn một cơ sở dữ liệu từ tập cơ sở dữ liệu, người dùng tìm kiếm các mục đã biết sự có mặt và không có trong cơ sở dữ liệu đó; Lựa chọn nhiều hơn một cơ sở dữ liệu từ tập cơ sở dữ liệu, người dùng tìm kiếm các mục đã biết sự có mặt và không có trong cơ sở dữ liệu đó.
Từ đó, bạn có thể thấy kiểm thử một yêu cầu không có nghĩa là chỉ thực hiện kiểm thử trên một thử nghiệm. Thông thường, bạn phải thực kiểm thử nghiệm trên một vài thử nghiệm để đảm bảo bạn đã kiểm soát được yêu cầu đó.
Kiểm thử các yêu cầu khác trong hệ thống LIBSYS có thể được thực hiện theo giống như trên. Với yêu cầu thứ hai, bạn sẽ soạn ra các thử nghiệm để phân phối tất cả các kiểu tài liệu có thể được xử lý bởi hệ thống và kiểm tra sự hiển thị các tài liệu đó. Với yêu cầu thứ ba, bạn giả vờ đưa vào một vài yêu cầu, sau đó kiểm tra định danh yêu cầu được hiển thị trong giấy chứng nhận của người dùng, và kiểm tra định danh yêu cầu đó có là duy nhất hay không.
2. Kiểm thử phân hoạch.
Dữ liệu đầu vào và kết quả đầu ra của chương trình thường được phân thành một số loại khác nhau, mỗi loại có những đặc trưng chung, như các số đều dương, các số đều âm và các thực đơn lựa chọn. Thông thường, các chương trình thực hiện theo cách có thể so sánh được với tất cả thành viên của một lớp. Do đó, nếu chương trình được kiểm thử thực hiện những tính toán và yêu cầu hai số dương, thì bạn sẽ mong muốn chương trình thực hiện theo cách như nhau với tất cả các số dương.
Bởi vì cách thực hiện là tương đương, các loại này còn được gọi là phân hoạch tương đương hay miền tương đương (Bezier, 1990). Một cách tiếp cận có hệ thống để thiết kế các trường hợp kiểm thử là dựa trên sự định danh của tất cả các phân hoạch trong một hệ thống hoặc một thành phần. Các trường hợp thử nghiệm được thiết kế sao cho đầu vào và đầu ra nằm trong phân hoạch đó. Kiểm thử phân hoạch có thể được sử dụng để thiết kế các trường hợp thử nghiệm cho các hệ thống và các thành phần.
Đầu vào các phân hoạch tương đương là những tập dữ liệu, tất cả các tập thành viên nên được xử lý một cách tương đương. Đầu ra phân hoạch tương đương là đầu ra của chương trình và chúng có các đặc trưng chung. Vì vậy, chúng có thể được kiểm tra như một lớp riêng biệt. Bạn cũng cần xác định các phân hoạch có đầu vào ở bên ngoài các phân hoạch khác. Kiểm tra các thử nghiệm mà chương trình sử dụng đầu vào không hợp lệ có thực hiện đúng cách thức không. Các đầu vào hợp lệ và đầu vào không hợp lệ cũng được tổ chức thành các phân hoạch tương đương.
Khi đã xác định được tập các phân hoạch, có thể lựa chọn các trường hợp thử nghiệm cho mỗi phân hoạch đó. Một quy tắc tốt để lựa chọn trường hợp thử nghiệm là lựa chọn các trường hợp thử nghiệm trên các giới hạn của phân hoạch, cùng với các thử nghiệm gần với điểm giữa của phân hoạch.
Lý do căn bản là người thiết kế và lập trình viên thường xem xét các giá trị đầu vào điển hình khi phát triển một hệ thống. Bạn kiểm thử điều đó bằng cách lựa chọn điểm giữa của hệ thống. Các giá trị giới hạn thường không điển hình (ví dụ, số 0 có thể được sử dụng khác nhau trong các tập các số không âm), vì vậy nó không được người phát triển chú ý tới. Các lỗi của chương trình thường xuất hiện khi nó xử lý các giá trị không điển hình.
Bạn xác định các phân hoạch bằng cách sử dụng đặc tả chương trình hoặc tài liệu hướng dẫn sử dụng và từ kinh nghiệm của mình, bạn dự đoán các loại giá trị đầu vào thích hợp để phát hiện lỗi. Ví dụ, từ đặc trưng của chương trình: chương trình chấp nhận từ 4 đến 8 đầu vào là các số nguyên có 5 chữ số lớn hơn 10000.
Để minh họa cho nguồn gốc của những trường hợp thử nghiệm này, sử dụng các đặc tả của thành phần tìm kiếm. Thành phần này tìm kiếm trên một dây các phần tử để đưa ra phần tử mong muốn (phần tử khóa). Nó trả lại vị trí của phần tử đó trong dây. Tôi đã chỉ rõ đây là một cách trừu tượng để xác định các điều kiện tiên quyết, phải đứng trước khi thành phần đó được gọi và các hậu điều kiện phải đứng sau khi thực hiện.
Khi chúng ta thử nghiệm chương trình với các dãy, màng hoặc danh sách, một số nguyên tắc thường được sử dụng để thiết kế các trường hợp kiểm thử:
– Kiểm thử phần mềm với dãy chỉ có một giá trị. Lập trình viên thường nghĩ các dãy gồm vài giá trị, và thỉnh thoảng họ cho rằng điều này luôn xảy ra trong các chương trình của họ. Vì vậy, chương trình có thể không làm việc chính xác khi dãy được đưa vào chỉ có một giá trị.
– Sử dụng các dãy với các kích thước khác nhau trong các thử nghiệm khác nhau. Điều này làm giảm cơ hội một chương trình khiếm khuyết, sẽ ngẫu nhiên đưa ra đầu ra chính xác bởi vì các đầu vào có các đặc tính ngẫu nhiên.
– Xuất phát từ các thử nghiệm có phần tử đầu tiên, phần tử ở giữa và phần từ cuối cùng được truy cập. Cách tiếp cận này bộc lộ các vấn đề tại các giới hạn phân hoạch.
Từ các nguyên tắc trên, hai phân hoạch tương đương có thể được xác định: Dãy đầu vào có một giá trị; Số phần tử trong dãy đầu vào lớn hơn 1.
Sau đó bạn xác định thêm các phân hoạch bằng cách kết hợp các phân hoạch đã có, ví dụ, kết hợp phân hoạch có số phần tử trong dãy lớn hơn 1 và phần tử khóa không thuộc dây. Một tập các trường hợp thử nghiệm có thể dựa trên các phân hoạch đó cũng được đưa ra. Nếu phần từ khóa không thuộc dây, giá trị của L là không xác định (??’). Nguyên tắc “các dãy với số kích thước khác nhau nên được sử dụng” đã được áp dụng trong các trường hợp thử nghiệm này.
Tập các giá trị đầu vào sử dụng để kiểm thử thủ tục tìm kiếm không bao giờ hết. Thủ tục này có thể gặp lỗi nếu dãy đầu vào tình cờ gồm các phần tử 1, 2, 3 và 4. Tuy nhiên, điều đó là hợp lý để giả sử: nếu thử nghiệm không phát hiện khiếm khuyết khi một thành viên của một loại được xử lý, không có thành viên khác của lớp sẽ xác định các khiếm khuyết. Tất nhiên, các khiếm khuyết sẽ vẫn tồn tại. Một vài phân hoạch tương đương có thể không được xác định, các lỗi có thể đã được tạo ra trong phân hoạch tương đương hoặc dữ liệu thử nghiệm có thể đã được chuẩn bị không đúng.
3. Kiểm thử cấu trúc.
Kiểm thử cấu trúc là một cách tiếp cận để thiết kế các trường hợp kiểm thử, các thử nghiệm được xác định từ sự hiểu biết về cấu trúc và sự thực hiện của phần mềm. Cách tiếp cận này thỉnh thoảng còn được gọi là kiểm thử hộp trắng, kiểm thử hộp kính, hoặc kiểm thử hộp trong để phân biệt với các kiểm thử hộp đen.
Hiểu được cách sử dụng thuật toán trong một thành phần, có thể giúp bạn xác định thêm các phân hoạch và các trường hợp thử nghiệm. Để minh họa điều này, tôi đã thực hiện cách đặc tả thủ tục tìm kiếm, như một thủ tục tìm kiếm nhị phân. Tất nhiên, điều kiện tiên quyết đã được đảm bảo nghiêm ngặt và dãy được thực thi.
Như một màng và màng này phải được sắp xếp và giá trị giới hạn dưới phải nhỏ hơn giá trị giới hạn trên. Để kiểm tra mã của thủ tục tìm kiếm, bạn có thể xem việc tìm kiếm nhị phân chia không gian tìm kiếm thành ba phần. Mỗi phần được tạo bởi một phân hoạch tương đương.
Sau đó, bạn thiết kế các trường hợp thử nghiệm có phần từ khóa nằm tại các giới hạn của mỗi phân hoạch. Điều này đưa đến một tập sửa lại của các trường hợp thử nghiệm cho thủ tục tìm kiếm. Chú ý, đã sửa đổi mảng đầu vào, vì vậy nó đã được sắp xếp theo thứ tự tăng dần, và đã thêm các thử nghiệm có phần tử khóa kế với phần từ giữa của mảng.
4. Kiểm thử đường dẫn.
Kiểm thử đường dẫn là một chiến lược kiểm thử cấu trúc. Mục tiêu của kiểm thử đường dẫn là thực hiện mọi đường dẫn thực hiện độc lập thông qua một thành phần hoặc chương trình. Nếu mọi đường dẫn thực hiện độc lập được thực hiện, thì tất cả các câu lệnh trong thành phần đó phải được thực hiện ít nhất một lần.
Hơn nữa, tất cả câu lệnh điều kiện phải được kiểm thử với cả trường hợp đúng và sai. Trong quá trình phát triển hướng đối tượng, kiểm thử đường dẫn có thể được sử dụng khi kiểm thử các phương thức liên kết với các đối tượng.
Số lượng đường dẫn qua một chương trình thường tỷ lệ với kích thước của nó. Khi tất cả các module được tích hợp trong hệ thống, nó trở nên không khả thi để sử dụng kỹ thuật kiểm thử cấu trúc. Vì thế, kỹ thuật kiểm thử đường dẫn hầu như được sử dụng trong lúc kiểm thử thành phần.
Kiểm thử đường dẫn không kiểm tra tất cả các kết hợp có thể của các đường dẫn qua chương trình. Với bất kỳ thành phần nào ngoài các thành phần rất tầm thường không có vòng lặp, đây là mục tiêu không khả thi. Trong chương trình có các vòng lặp sẽ có một số vô hạn khả năng kết hợp đường dẫn. Thậm chí, khi tất cả các lệnh của chương trình đã được thực hiện ít nhất một lần, các khiếm khuyết của chương trình vẫn có thể được đưa ra khi các đường dẫn đặc biệt được kết hợp.
Điểm xuất phát để kiểm thử đường dẫn là đồ thị luồng chương trình. Đây là mô hình khung của tất cả đường dẫn qua chương trình. Một đồ thị luồng chứa các nút miêu tả các quyết định và các cạnh trình bày luồng điều khiển. Đồ thị luồng được xây dựng bằng cách thay đổi các câu lệnh điều khiển chương trình sử dụng biếu đó tương đương.
Nếu không có các câu lệnh goto trong chương trình, đó là một quá trình đơn giản xuất phát từ đồ thị luồng. Mỗi nhánh trong câu lệnh điều kiện (if-then-else hoặc case) được miêu tả như một đường dẫn riêng biệt. Mỗi mũi tên trở lại nút điều kiện miêu tả một vòng lặp.
Tôi đã vẽ đồ thị luồng cho phương thức tìm kiếm nhị phân. Để tạo nên sự tương ứng giữa đồ thị này và chương trình được rõ ràng, tôi đã miêu tả mỗi câu lệnh như một nút riêng biệt, các số trong mỗi nút tương ứng với số dòng trong chương trình.
Mục đích của kiểm thử đường dẫn là đảm bảo mỗi đường dẫn độc lập qua chương trình được thực hiện ít nhất một lần. Một đường dẫn chương trình độc lập là một đường đi ngang qua ít nhất một cạnh mới trong đồ thị luồng. Cả nhánh đúng và nhánh sai của các điều kiện phải được thực hiện.
Đồ thị luồng cho thủ tục tìm kiếm nhị phân được miêu tả, mỗi nút biểu diễn một dòng trong chương trình với một câu lệnh có thể thực hiện được. Do đó, bằng cách lần vết trên đồ thị luồng, bạn có thể nhận ra các đường dẫn qua đồ thị luồng tìm kiếm nhị phân. Nếu tất cả các đường dẫn được thực hiện, chúng ta có thể đảm bảo mọi câu lệnh trong phương thức đã được thực hiện ít nhất một lần và mỗi nhánh đã được thực hiện với các điều kiện đúng và sai.
Bạn có thể tìm được số lượng các đường dẫn độc lập trong một chương trình bằng tính toán vòng liên hợp (McCabe, 1976) trong đồ thị luồng chương trình. Với chương trình không có câu lệnh goto, giá trị vòng liên hợp nhiều hơn số câu lệnh điều kiện trong chương trình. Một điều kiện đơn là một biểu thức logic không có các liên kết “and” hoặc “or”. Nếu chương trình bao gồm các điều kiện phức hợp, là các biểu thức logic bao gồm các liên kết “and” và “or”, thì bạn phải đếm số điều kiện đơn trong các điều kiện phức hợp khi tính số vòng liên hợp.
Vì vậy, nếu có 6 câu lệnh “if” 1 vòng lặp “while” và các biểu thức điều kiện là đơn, thì số vòng liên hợp là 8. Nếu một biểu thức điều kiện là biểu thức phức hợp như “if A and B or C”, thì bạn tính nó như ba điều kiện đơn. Do đó, số vòng liên hợp là 10. Số vòng liên hợp của thuật toán tìm kiếm nhị phân (hình 3.13) là 4 bởi vì nó có ba điều kiện đơn tại các dòng 5, 7, 11.
Sau khi tính được số đường dẫn độc lập qua mã chương trình bằng tính toán số vòng liên hợp, bạn thiết kế các trường hợp thử nghiệm để thực hiện mỗi đường dẫn đó. Số lượng trường hợp thử nghiệm nhỏ nhất bạn cần để kiểm tra tất cả các đường dẫn trong chương trình bằng số vòng liên hợp.
Thiết kế trường hợp thử nghiệm không khó khăn trong trường hợp chương trình là thủ tục tìm kiếm nhị phân. Tuy nhiên, khi chương trình có cấu trúc nhánh phức tạp, có thể rất khó khăn để dự đoán có bao nhiêu thử nghiệm đã được thực hiện. Trong trường hợp đó, một người phân tích chương trình năng động có thể được sử dụng để phát hiện sơ thảo sự thực thi của chương trình.
Những người phân tích chương trình năng động là các công cụ kiểm thử, cùng làm việc với trình biên dịch. Trong lúc biên dịch, những người phân tích này thêm các chỉ thị phụ để sinh ra mã. Chúng đếm số lần mỗi câu lệnh đã được thực hiện.
Sau khi chương trình đã thực hiện, một bản sơ thảo thực thi có thể được in ra. Nó chỉ ra những phần chương trình đã thực thi và không thực thi bằng cách sử dụng các trường hợp thử nghiệm đặc biệt. Vì vậy, bản sơ thảo thực thi cho phép phát hiện các phần chương trình không được kiểm thử.
Tác giả: Thạc Bình Cường
Bạn đang xem bài viết:
Thiết kế trường hợp thử (Test case design) là gì?
Link https://vnlibs.com/cong-nghe/thiet-ke-truong-hop-thu-test-case-design-la-gi.html
