QA phần mềm: Giải quyết vấn đề với thiết kế thử nghiệm tổ hợp

Trong kiểm thử phần mềm , việc thiết kế các trường hợp kiểm thử là điều cơ bản để đảm bảo độ tin cậy và độ bền của ứng dụng. Các kỹ thuật thiết kế thử nghiệm tổ hợp, chẳng hạn như thử nghiệm k-way và thử nghiệm theo cặp, nhằm mục đích kiểm tra sự tương tác giữa các biến đầu vào khác nhau. Tuy nhiên, rõ ràng là những thách thức và cạm bẫy có thể cản trở hiệu quả của họ trong việc phát hiện ra những lỗi nghiêm trọng.

Bài viết ngắn này tập trung vào các vấn đề cụ thể có thể gặp phải trong quá trình thiết kế thử nghiệm tổ hợp, khám phá các sắc thái cần xem xét cẩn thận. Chúng ta hãy đi sâu vào các trường hợp giá trị đầu vào không chính xác, tầm quan trọng của các oracle mạnh mẽ, tầm quan trọng của các kết hợp biến thường bị bỏ qua và hiểu biết quan trọng về cách các biến tương tác.

Tôi không xác định chính xác các giá trị đầu vào

Bộ kiểm tra k-way bao gồm tất cả các kết hợp giá trị có thể có của k biến. Ví dụ: việc áp dụng Thuật toán Allpairs sẽ tạo ra bộ kiểm tra 2 chiều, bao gồm tất cả các kết hợp có thể có của các cặp giá trị biến. Do đó, lỗi k-way đề cập đến lỗi do sự tương tác giữa các giá trị của k biến. Việc kiểm tra hai hệ thống SYS1 và SYS2 đã phát hiện ra các lỗi sau khi chúng được đưa vào sản xuất. Cả hai hệ thống đều trải qua thử nghiệm k-way với k giá trị là 2, 3, 4 và 5+.

Bảng hiển thị kết quả kiểm tra k-way cho hai hệ thống.

Kiểm tra tuần tự được tiến hành cho từng bộ k-way. Hình 2.1 chỉ ra rằng các lỗi phát sinh từ sự tương tác của hai hoặc ít biến đầu vào là 29 in SYS1 và 30 in SYS2 . Lỗi do tương tác của ba biến là 4*(30+4) in SYS2 và 12*(29+12) in SYS1 . Đối với các tương tác liên quan đến bốn biến, lỗi là 7*(30+4+7) in SYS2 và 1*(29+12+1) in SYS1 . Lỗi do tương tác với nhiều hơn bốn biến là 3*(29+12+1+3) in SYS1 và 7*(30+4+7+7) in SYS2 . Đáng chú ý, SYS1 không tìm thấy 43 lỗi và SYS2 không tìm thấy 34 lỗi.

Trong ví dụ này, lỗi nghiêm trọng nhất thuộc về danh mục Không tìm thấy . Các cuộc điều tra sâu hơn cho thấy hầu hết các lỗi không được phát hiện đều là lỗi 1 chiều, nghĩa là một giá trị cụ thể của một biến sẽ dẫn đến lỗi một cách độc lập với các giá trị biến khác. Kiểm tra từng cặp lẽ ra đã phát hiện ra những lỗi này, nhưng vì lý do nào đó, chúng vẫn chưa được phát hiện. Các lỗi Không tìm thấy này chủ yếu là lỗi 1 chiều không được chú ý do một số giá trị đầu vào nhất định không được chọn hoặc được chọn không chính xác.

Bản chất của vấn đề nằm ở chỗ mọi lỗi xảy ra trước khi áp dụng Thuật toán Allpairs sẽ vẫn tồn tại. Điều này ngụ ý rằng nếu các kỹ thuật thiết kế thử nghiệm trước đó được áp dụng không chính xác hoặc giá trị đầu vào không chính xác thì lỗi trong ứng dụng sẽ vẫn tồn tại bất kể sử dụng Thuật toán Allpairs hay Thử nghiệm mảng trực giao.

Điểm yếu trong việc xác định kết quả mong đợi: Sự không chắc chắn về kết quả đầu tiên

Ví dụ: hãy xem xét một mô-đun ứng dụng có nhiều tùy chọn (giống như dạng này) và do đó có một số lượng lớn các kết hợp dữ liệu đầu vào.

Trong mô-đun, giả sử có 2^12 * 3 kết hợp có thể xảy ra. Ở đây, thách thức không nằm ở việc chọn giá trị đầu vào không chính xác, vì tất cả các giá trị biến có thể có đều có thể được kiểm tra toàn diện bằng thuật toán Allpairs. Tuy nhiên, liệu điều này có phát hiện ra tất cả các lỗi nghiêm trọng? Có thể là không, do có vấn đề với kết quả mong đợi. Sau khi thao tác từng tổ hợp tùy chọn trong loại mô-đun phần mềm như vậy, người ta sẽ cần sử dụng hệ thống một thời gian để xác minh rằng các tùy chọn hoạt động chính xác và không có gì khác bị hỏng sau khi áp dụng các tùy chọn đã chọn. Trong trường hợp này, không có gì đảm bảo rằng không có vấn đề tế nhị, không rõ ràng nào dễ bị bỏ qua.

Sau mỗi lần kiểm tra, người ta có thể cần đánh giá kỹ lưỡng các chức năng cốt lõi của hệ thống. Vấn đề ở đây là những khiếm khuyết nghiêm trọng thường không rõ ràng như người ta mong muốn và việc tính toán mọi thứ theo kết quả mong đợi trên thực tế trở nên không thể thực hiện được.

Không chú ý đến những sự kết hợp có thể xảy ra nhất

Trong số các kết hợp 2^12 * 3 (như chúng tôi đã đề xuất trong ví dụ trên), có thể có một kết hợp các tùy chọn mô-đun sẽ xảy ra thường xuyên hơn tất cả các kết hợp khác - cài đặt mặc định . Nếu 95% mọi người sẽ không bao giờ thay đổi các tùy chọn từ cài đặt mặc định cho mô-đun này, thì sẽ có phạm vi bao quát tốt về các tùy chọn gần như/gần như mặc định . Việc kiểm tra tất cả các biến thể có độ lệch so với cấu hình mặc định trong một tùy chọn sẽ dẫn đến số lần kiểm tra có 2 chữ số. Nếu thử nghiệm tất cả các kết hợp tùy chọn có thể có sai lệch trong hai cài đặt so với mặc định, thì sẽ có khoảng một trăm trường hợp thử nghiệm. Việc thử nghiệm với các trường hợp thử nghiệm này và các trường hợp thử nghiệm tất cả các cặp có thể mang lại kết quả tốt hơn việc bỏ qua sự tồn tại của tùy chọn mặc định. Tuy nhiên, thuật toán Allpairs buộc người thử nghiệm phải bỏ qua các kết hợp biến có thể xảy ra và được sử dụng phổ biến nhất.

Tương tác biến không xác định

Yếu tố then chốt dẫn đến sự thành công hay thất bại của thử nghiệm theo cặp nằm ở việc hiểu được sự kết hợp của các biến đầu vào ảnh hưởng như thế nào đến dữ liệu đầu ra. Áp dụng thử nghiệm theo cặp cho hai ứng dụng được thử nghiệm khác nhau có thể mang lại kết quả khác nhau đáng kể. Một số ứng dụng sử dụng ít dữ liệu đầu vào hơn để tạo ra dữ liệu đầu ra, trong khi những ứng dụng khác sử dụng nhiều dữ liệu hơn.

Ví dụ, hãy xem xét chương trình có ba biến đầu vào (X, Y, Z) và ba dữ liệu đầu ra có thể có (1, 2, 3). Các mũi tên chỉ ra những biến nào sẽ tương tác để tạo ra một kết quả cụ thể. Để có kết quả là 1, biến Y và X phải tương tác; để có được kết quả là 2, các biến Z và X phải tương tác. Đối với ứng dụng này, việc áp dụng thử nghiệm theo cặp sẽ là một lựa chọn phù hợp và có thể mang lại kết quả tích cực. Tuy nhiên, trong trường hợp có những tình huống trong đó dữ liệu đầu ra là kết quả của sự tương tác của nhiều hơn hai biến đầu vào, khả năng cao là việc kiểm tra theo cặp sẽ không xác định được lỗi. Việc chỉ áp dụng thử nghiệm theo cặp sẽ làm tăng nguy cơ bỏ qua các lỗi nghiêm trọng trong ứng dụng được thử nghiệm.