Tôi sẽ bỏ qua phần thảo luận ở đây về các kỹ thuật thiết kế thử nghiệm nổi tiếng và được sử dụng rộng rãi như Lớp tương đương, Thử nghiệm giá trị biên và Thử nghiệm theo cặp, tôi sẽ thảo luận về các kỹ thuật khác ít phổ biến hơn. Bạn cũng có thể đọc bài viết của tôi về các vấn đề với kỹ thuật thiết kế tổ hợp thử nghiệm .
Bảng quyết định là một công cụ tuyệt vời để ghi lại các yêu cầu và mô tả chức năng của ứng dụng. Các bảng này rất thuận tiện cho việc mô tả logic nghiệp vụ của ứng dụng và ngoài ra, chúng có thể đóng vai trò là nền tảng vững chắc để tạo các trường hợp thử nghiệm. Nếu ứng dụng được thử nghiệm thiếu tài liệu phù hợp thì đó là lý do chính đáng để sử dụng Bảng quyết định. Việc trình bày các yêu cầu ở dạng nhỏ gọn và đơn giản giúp việc tạo các trường hợp thử nghiệm khá dễ dàng.
Tiếp cận:
Bảng quyết định mô tả logic của ứng dụng dựa trên các thực thể (thuộc tính/điều kiện) của trạng thái hệ thống. Mỗi bảng quyết định chỉ mô tả một trạng thái của hệ thống.
| quy tắc 1 | quy tắc 2 | … | quy tắc N |
---|---|---|---|---|
Thực thể | | | | |
Bất động sản 1 | | | | |
… | | | | |
Thuộc tính M | | | | |
hành động | | | | |
Hành động 1 | | | | |
… | | | | |
Hành động P | | | | |
Thực thể (Thuộc tính) từ 1 đến M thể hiện các thuộc tính khác nhau của hệ thống; chúng được trình bày trong bảng dưới dạng dữ liệu đầu vào có thể được nhập vào hệ thống. Các hành động từ 1 đến P là các hành động có thể xảy ra với sự kết hợp các thực thể được chỉ định. Tùy thuộc vào sự kết hợp của tất cả dữ liệu đầu vào của các thực thể, các hành động sẽ nhận các giá trị cần thiết. Mỗi quy tắc xác định một tập hợp dữ liệu đầu vào duy nhất cho tất cả các thuộc tính dẫn đến việc thực thi các hành động cụ thể.
Sau khi soạn bảng quyết định, thường có thể đơn giản hóa bảng, chẳng hạn bằng cách loại bỏ một số hoặc tất cả các tình huống không thể xảy ra. Sau đó, bảng có thể được chuyển đổi thành các trường hợp thử nghiệm.
Kiểm thử chuyển trạng thái, giống như kiểm thử bảng quyết định, là một công cụ có giá trị để ghi lại các yêu cầu và mô tả cấu trúc cũng như thiết kế của một hệ thống. Không giống như thử nghiệm bảng Quyết định mô tả một trạng thái hệ thống cụ thể, thử nghiệm Chuyển trạng thái mô tả cách các trạng thái này của hệ thống có thể thay đổi. Sơ đồ xác định tất cả các sự kiện xảy ra trong quá trình hoạt động của ứng dụng và cách ứng dụng phản ứng với những sự kiện này.
Tiếp cận:
Có hai loại biểu diễn trực quan của kỹ thuật này:
Ví dụ: hãy xem xét việc đặt vé máy bay. Nó hoạt động đại khái như sau: Ban đầu, khách hàng cung cấp cho hãng hàng không thông tin để đặt chỗ - địa điểm khởi hành, điểm đến, ngày và giờ khởi hành. Nhân viên hãng hàng không đóng vai trò là cầu nối giữa khách hàng và hệ thống đặt vé, sử dụng thông tin do khách hàng cung cấp để tạo đặt chỗ. Sau đó, đặt chỗ của khách hàng ở trạng thái "Đã thực hiện". Ngoài ra, sau khi tạo đặt chỗ, hệ thống sẽ khởi động bộ hẹn giờ. Khi hết thời gian mà vé đã đặt chưa được thanh toán, hệ thống sẽ hủy việc đặt chỗ cho vé đó.
Vòng tròn thể hiện trạng thái của hệ thống đặt vé máy bay, trạng thái “Made”. Mũi tên biểu thị sự chuyển đổi sang trạng thái "Made". Mô tả bên dưới mũi tên ("get_info") là sự kiện bắt nguồn từ bên ngoài hệ thống. Lệnh trong phần mô tả bên dưới mũi tên (sau "/") biểu thị rằng hệ thống đã thực hiện một số hành động để phản hồi sự kiện - trong trường hợp này là bắt đầu tính giờ. Vòng tròn màu đen biểu thị điểm bắt đầu/vào của sơ đồ.
Nếu bộ đếm thời gian không hết hạn và chúng tôi đã thanh toán cho vé đã đặt trước thì hệ thống sẽ chuyển sang trạng thái "Đã thanh toán". Điều này được mô tả bằng mũi tên có nhãn "payMoney" và sự chuyển đổi từ trạng thái "Đã thực hiện" sang trạng thái "Đã thanh toán".
Các bảng chuyển trạng thái là các bảng bao gồm bốn cột: Trạng thái hiện tại, Sự kiện, Hành động và Trạng thái tiếp theo.
Ưu điểm của Bảng chuyển trạng thái là chúng xác định tất cả các kịch bản Chuyển trạng thái có thể xảy ra, chứ không chỉ các kịch bản đúng. Do đó, Bảng chuyển trạng thái thường dẫn đến việc phát hiện các kết hợp Chuyển trạng thái không xác định, không có giấy tờ, tốt hơn nên xác định các kết hợp này trước khi viết mã.
Có bao nhiêu kết hợp tồn tại cho cặp giá trị "1" và "2"? {1,1}, {1,2}, {2,1} và {2,2}. Mảng trực giao là mảng hai chiều có thuộc tính đặc biệt - trong bất kỳ hai cột nào của mảng, tất cả các kết hợp giá trị trong các cột đó đều có mặt. Nghĩa là, nếu bạn lấy bất kỳ hai cột nào từ mảng trực giao, trong đó các giá trị chỉ có thể là "1" hoặc "2", bạn sẽ tìm thấy các hàng sau cho các cột đó - {1,1}, {1,2}, { 2,1} và {2,2}.
Ví dụ, hãy xem xét một hệ thống có ba tham số đầu vào, mỗi tham số là nhị phân (nghĩa là lấy giá trị "1" hoặc "2").
hàng | biến 1 | biến 2 | biến 3 |
---|---|---|---|
1 | 1 | 1 | 1 |
2 | 2 | 1 | 1 |
3 | 1 | 2 | 1 |
4 | 1 | 1 | 2 |
5 | 2 | 2 | 1 |
6 | 1 | 2 | 2 |
7 | 2 | 1 | 2 |
số 8 | 2 | 2 | 2 |
Mảng trực giao được biểu diễn dưới dạng - L_4(2^3), trong đó L_4 chỉ ra rằng mảng trực giao có bốn hàng và (2^3) chỉ ra rằng mảng có ba cột, với các giá trị có thể là "1" hoặc "2 ".
hàng | biến 1 | biến 2 | biến 3 |
---|---|---|---|
1 | 1 | 1 | 1 |
2 | 1 | 2 | 2 |
3 | 2 | 1 | 2 |
4 | 2 | 2 | 1 |
L_4, trong đó 4 là số hàng
2^3, trong đó 2 là giá trị lớn nhất (== 2, 3, …, N) và 3 là số cột
Mảng trực giao - là mảng hai chiều có thuộc tính sau: chọn hai cột bất kỳ của mảng và bạn sẽ tìm thấy tất cả các kết hợp giá trị trong các cột đó.
Sử dụng mảng trực giao:
Bản chất của thuật toán AllPairs là không cần phải kiểm tra tất cả các kết hợp giá trị cho tất cả các biến. Thay vào đó, nó tập trung vào việc kiểm tra tất cả các kết hợp giá trị cho từng cặp biến.
Là một chuyên gia QA, hiểu được những sắc thái này là điều quan trọng. Mặc dù về mặt lý thuyết trong một số trường hợp, việc hiểu được sự phức tạp của các kỹ thuật thiết kế thử nghiệm tổ hợp cho phép các chuyên gia QA kiểm tra hiệu quả logic kinh doanh phức tạp của ứng dụng và cung cấp phần mềm chất lượng cao cho người dùng của họ.