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 Kiểm tra bảng quyết định 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 tra chuyển trạng thái 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: Sơ đồ chuyển trạng thái Bảng chuyển trạng thái Sơ đồ chuyển trạng thái 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 biểu thị bằng hình tròn trên sơ đồ) Đây là trạng thái của hệ thống khi nó chờ một hoặc nhiều sự kiện. Trạng thái ghi nhớ dữ liệu đầu vào đã nhận được cho đến nay và cho biết hệ thống sẽ phản ứng như thế nào với các sự kiện đã nhận. Các sự kiện có thể kích hoạt các hành động và/hoặc dẫn đến thay đổi trạng thái. Trạng thái : (được biểu thị trên sơ đồ dưới dạng mũi tên) Điều này thể hiện sự chuyển đổi từ trạng thái này sang trạng thái khác, xảy ra do một sự kiện. Chuyển đổi : (được biểu thị dưới dạng hình chữ nhật phía trên mũi tên) Sự kiện là thứ khiến ứng dụng thay đổi trạng thái. Các sự kiện có thể đến từ bên ngoài ứng dụng, chẳng hạn như thông qua giao diện người dùng của ứng dụng. Đồng thời, bản thân ứng dụng có thể tạo ra các sự kiện, chẳng hạn như sự kiện như "hết giờ". Khi một sự kiện xảy ra, ứng dụng có thể giữ nguyên trạng thái, thay đổi trạng thái hoặc thực hiện một hành động. Sự kiện có thể có tham số; ví dụ: sự kiện "pay_money" có thể có các thông số như "Tiền mặt", "Séc", "Thẻ ghi nợ" hoặc "Thẻ tín dụng". Sự kiện : (được biểu thị sau "/" trong nhãn phía trên quá trình chuyển đổi) Đây là hành động được bắt đầu bởi sự thay đổi về trạng thái. Đó có thể là các hành động như "in vé", "hiển thị trên màn hình", v.v. Thông thường, các hành động tạo ra kết quả đầu ra đóng vai trò là dữ liệu đầu ra của hệ thống. Hành động xảy ra trong quá trình chuyển đổi; bản thân các quốc gia là thụ động. Hành động : được hiển thị trên sơ đồ dưới dạng một chấm đen. Điểm vào được hiển thị trên sơ đồ dưới dạng biểu tượng "mắt bò". Điểm thoát Bảng chuyển trạng thái 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ã. Sơ đồ chuyển trạng thái có thể dễ dàng được sử dụng để tạo các trường hợp thử nghiệm. Cần phải tạo một tập hợp các trường hợp thử nghiệm bao gồm tất cả các chuyển đổi ít nhất một lần. Từ Bảng chuyển trạng thái, việc tạo các ca kiểm thử cũng tương đối đơn giản. Người ta cần phải xem xét tất cả các kết hợp hợp lệ (nếu thời gian cho phép hoặc rủi ro không ngăn cản, thì cũng có thể xem xét tất cả các kết hợp không hợp lệ). Mảng trực giao 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: Xác định các biến (số lượng dữ liệu đầu vào). Cần phải chọn dữ liệu đầu vào, bất kỳ sự kết hợp nào của các giá trị có thể tồn tại một cách hợp lý. Xác định số giá trị mà mỗi biến có thể nhận. Vào thời điểm số lượng giá trị được xác định, các kỹ thuật thiết kế thử nghiệm khác đã được áp dụng để giảm số lượng giá trị (ví dụ: giá trị biên, lớp tương đương và bất kỳ loại nào khác). Xác định một mảng trực giao trong đó sẽ có một cột cho mỗi biến (cột của mảng trực giao có nhiều tùy chọn giá trị như biến). Chiếu nhiệm vụ thử nghiệm lên mảng trực giao. Viết các trường hợp thử nghiệm. Thuật toán tất cả các cặp 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ọ.

This story contains new, firsthand information uncovered by the writer.

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

dài quá đọc không nổi

Making security fun one episode at a time

Phân tích các kỹ thuật thiết kế thử nghiệm tổ hợp

dài quá đọc không nổi

Constantine

STORY’S CREDIBILITY

Original Reporting

About Author

chuyên mục

Languages

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

Phân tích các kỹ thuật thiết kế thử nghiệm tổ hợp

dài quá đọc không nổi

Constantine

STORY’S CREDIBILITY

Original Reporting

About Author

chuyên mục

Languages

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

NHỮNG BÀI VIẾT LIÊN QUAN