Trong   , 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. kiểm thử phần mềm  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.    không xác định chính xác các giá trị đầu vào Tôi  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.  Loại lỗi  SYS1  SYS2  2 cách  30  29  3 chiều  4  12  4 chiều  7  1  > 4 chiều  7  3  Không tìm thấy  34  43  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à   và   . Lỗi do tương tác của ba biến là   và   . Đối với các tương tác liên quan đến bốn biến, lỗi là   và   . Lỗi do tương tác với nhiều hơn bốn biến là   và   . Đáng chú ý, SYS1 không tìm thấy   lỗi và SYS2 không tìm thấy   lỗi. 29 in SYS1 30 in SYS2 4*(30+4) in SYS2 12*(29+12) in SYS1 7*(30+4+7) in SYS2 1*(29+12+1) in SYS1 3*(29+12+1+3) in SYS1 7*(30+4+7+7) in SYS2 43 34  Trong ví dụ này, lỗi nghiêm trọng nhất thuộc về danh mục   . 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   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. Không tìm thấy Không tìm thấy    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. Bản chất của vấn đề   Đ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ó   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. 2^12 * 3  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   (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   . 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   . 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. 2^12 * 3 mặc định gần như/gần như mặc định  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.  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ù chỉ mang tính lý thuyết trong một số trường hợp, nhưng những hiểu biết sâu sắc này nhấn mạnh sự cần thiết của một phương pháp thử nghiệm toàn diện vượt xa bề ngoài, đảm bảo độ tin cậy và tính mạnh mẽ cho ứng dụng của bạn. Hiểu được sự phức tạp của 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ọ.

About Me

Read My Articles

Hire Me

Nghe bài viết này bằng Tiếng Anh, đọc bởi robot thông minh của HackerNoon

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

About Author

BÌNH LUẬN

chuyên mục

BÀI VIẾT NÀY CŨNG CÓ MẶT TẠI

Related Stories

184 Stories To Learn About Psychology

223 Stories To Learn About Science

179 Stories To Learn About Reading

147 Stories To Learn About Reading Books Online

184 Stories To Learn About Psychology

223 Stories To Learn About Science

179 Stories To Learn About Reading

147 Stories To Learn About Reading Books Online

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps