Viết trường hợp kiểm tra chấp nhận

Chúng tôi đang tích hợp một quy trình thử nghiệm trong quy trình SCRUM của chúng tôi. Vai trò mới của tôi là viết các bài kiểm tra chấp nhận các ứng dụng web của chúng tôi để tự động hóa chúng sau này. Tôi đã đọc rất nhiều về cách viết các trường hợp kiểm thử, nhưng không có lời khuyên nào cho tôi để viết các trường hợp kiểm thử cho các ứng dụng web phức tạp, và thay vào đó chúng đã đưa ra các nguyên tắc mâu thuẫn mà tôi thấy khó áp dụng:

• Các trường hợp kiểm tra nên ngắn gọn: Lấy ví dụ về một CMS. Các trường hợp thử nghiệm ngắn dễ bảo trì và để xác định đầu vào và đầu ra. Nhưng điều gì sẽ xảy ra nếu tôi muốn kiểm tra một loạt các hoạt động dài (ví dụ: thêm tài liệu, gửi thông báo cho người dùng khác, người dùng khác trả lời, tài liệu thay đổi trạng thái, người dùng nhận được thông báo). Dường như với tôi rằng các trường hợp thử nghiệm nên thể hiện các kịch bản hoàn chỉnh. Nhưng tôi có thể thấy làm thế nào điều này sẽ tạo ra các tài liệu kiểm tra quá phức tạp.

• Các thử nghiệm nên xác định đầu vào và đầu ra :: Điều gì xảy ra nếu tôi có một hình thức dài với nhiều trường tương tác, với các hành vi khác nhau. Tôi có viết một bài kiểm tra cho tất cả mọi thứ, hoặc một bài kiểm tra cho mỗi bài không?

• Các trường hợp kiểm thử phải độc lập: Nhưng làm thế nào tôi có thể áp dụng rằng nếu kiểm tra hoạt động tải lên yêu cầu thao tác kết nối thành công? Và làm thế nào để áp dụng để viết trường hợp thử nghiệm? Tôi nên viết một bài kiểm tra cho từng thao tác, nhưng mỗi bài kiểm tra khai báo các phụ thuộc của nó, hay tôi nên viết lại toàn bộ kịch bản cho mỗi bài kiểm tra?

• Các trường hợp thử nghiệm nên được ghi chép lại một cách nhẹ nhàng: Nguyên tắc này dành riêng cho các dự án Agile. Vậy bạn có lời khuyên nào về cách thực hiện nguyên tắc này không?

Mặc dù tôi nghĩ rằng việc viết các trường hợp thử nghiệm chấp nhận sẽ trở nên đơn giản, tôi thấy mình bị choáng ngợp bởi mọi quyết định tôi phải đưa ra (FYI: Tôi là một nhà phát triển chứ không phải một người thử nghiệm chuyên nghiệp). Vì vậy, câu hỏi chính của tôi là: Bạn có những bước hoặc lời khuyên nào để viết các trường hợp kiểm tra chấp nhận có thể duy trì cho các ứng dụng phức tạp. Cảm ơn bạn.

Chỉnh sửa : Để làm rõ câu hỏi của tôi: Tôi biết rằng thử nghiệm Chấp nhận nên bắt đầu từ yêu cầu và coi toàn bộ ứng dụng là một hộp đen. Câu hỏi của tôi liên quan đến các bước thực tế để viết tài liệu thử nghiệm, xác định các trường hợp thử nghiệm, xử lý các phụ thuộc giữa các thử nghiệm ... cho các ứng dụng web phức tạp

Trong các bộ chấp nhận của tôi, tôi đã tránh sử dụng các điều khiển cụ thể về công nghệ, tức là đối với các ứng dụng web không sử dụng css, đừng sử dụng các phần tử html nếu bạn cần điền vào một biểu mẫu để thực hiện các chi tiết cụ thể trong các bước để thiết lập SUT chứ không phải các bài kiểm tra chấp nhận thực tế

Tôi sử dụng dưa chuột để chấp nhận và có những điều sau đây

Given A xxx 
And I am on the xxx page
And a clear email queue
And I should see "Total Payable xxxx"
And I supply my credit card details
When I the payment has been processed
Then my purchase should be complete
And I should receive an email
When I open the email with subject "xxx"
Then I should see the email delivered from "xx"
And there should be an attachment of type "application/pdf"
And attachment 1 should be named "xxxx"
And I should be on the xxx page
And I should see my receipt

ví dụ này được quay lại bởi một ứng dụng web nhưng tôi vẫn có thể sử dụng thử nghiệm để kiểm tra ứng dụng trên máy tính để bàn vì các bước được sử dụng để thiết lập SUT chứ không phải các thử nghiệm chấp nhận

bài kiểm tra này nằm ở phần cuối của giao dịch mua

Tạo -> Xác nhận -> Thanh toán -> In hóa đơn

thử nghiệm ở trên dành cho bước thanh toán, các bước khác được thiết lập trong các thử nghiệm khác do ứng dụng có thể thiết lập vào các trạng thái này bằng dữ liệu hoặc hành động http trong trường hợp này thanh toán có các bước xác nhận và xác nhận thực hiện tạo các bước để chúng có thể giòn một chút

Đầu tiên bạn cần xác định Kiểm tra chấp nhận .

Những gì bạn dường như mô tả là tích hợp hoặc thử nghiệm hệ thống .

Vì vậy, mặc dù tôi không đồng ý 100% với các định nghĩa trên wikipedia, nhưng chúng vẫn có giá trị phần lớn.

Về cơ bản, mục đích của kiểm tra chấp nhận là để xác minh rằng các quy trình 'doanh nghiệp' sử dụng phần mềm bạn xây dựng thực sự hoạt động như dự định và phù hợp với mục đích - với dữ liệu thực tế. Vì vậy, như vậy bạn không xây dựng các trường hợp thử nghiệm như bạn làm các bài kiểm tra đơn vị hoặc phần còn lại. Nó không phải là được thiết kế theo cùng một kiểu.

Câu hỏi cần đặt ra là "hệ thống được sử dụng như thế nào?". Vì vậy, hãy kiểm tra nó theo cách nó được sử dụng. Tất nhiên bây giờ bạn đặt chiếc mũ kỹ thuật của bạn trở lại và thực hiện các yêu cầu kinh doanh một cách tôn giáo để rút ra các trường hợp thử nghiệm của bạn. Điều đó giả định rằng bạn có yêu cầu kinh doanh bằng văn bản.

Nếu bạn không, không quá muộn, bạn phải ngồi lại với (các) người dùng hoặc đại diện của họ (và nhà phân tích kinh doanh và người thiết kế kỹ thuật) và viết ra những gì họ mong đợi phần mềm sẽ cung cấp trong điều khoản kinh doanh ( với lời cảnh báo rõ ràng rằng điều này là quá ít quá muộn, nhưng tốt hơn là bắt đầu muộn hơn là không bao giờ - và tất nhiên không giới thiệu các tính năng mới). Đây là những gì trường hợp thử nghiệm của bạn sẽ được.

Một cách khác để làm điều đó (một lần nữa nếu bạn có một tài liệu như vậy) là xem qua hướng dẫn sử dụng. Mặc dù đây là một bước được loại bỏ khỏi các yêu cầu kinh doanh thực tế vì vậy chỉ được sử dụng nếu tất cả các cách khác đều thất bại.

Khi bạn đi mua một chiếc ô tô, bạn thường không đi sâu dưới mui xe (trừ khi bạn là thợ sửa xe). Bạn chỉ cần ngồi vào tay lái và kiểm tra sự thoải mái, tiện dụng, ngoại hình, âm thanh ... tức là những thứ chung chung. Bạn thường tin tưởng rằng nếu chiếc xe đã ở trong tay bạn ngay từ đầu (ít nhất là cho một chiếc xe mới), nó thường an toàn và được chế tạo tốt (có bảo hành, bạn đã hoàn thành công việc tại nhà và xem xét thông số kỹ thuật ...). Vì vậy, bây giờ bạn kiểm tra xem đây có phải là chiếc xe mà bạn sẽ muốn lái trong vài năm tới.

Tương tự với phần mềm.

Các thông tin mâu thuẫn có thể gây khó chịu và khó khái quát hóa và áp dụng vào tình huống cụ thể của bạn. Ergo, bạn có thể phải làm những gì tốt nhất trong bối cảnh của bạn.

Tôi không phải là một fan hâm mộ lớn của các tài liệu thử nghiệm dài và đã sử dụng hình ảnh khá hiệu quả cho một vài dự án nhỏ hơn. Hãy thử điều đó? Giống như biểu đồ luồng (hoặc bất kỳ sơ đồ UML nào khác như sơ đồ trạng thái, v.v.) thay vì chỉ sử dụng văn bản? Chỉ ra đầu vào, đầu ra, điều kiện, vòng lặp, làn đường, trạng thái, tương tác với các thành phần khác, v.v.

Có thể là một chút công việc lúc đầu, nhưng có thể giúp bạn tỉnh táo trong thời gian dài. Dù bạn chọn phương pháp nào, bạn càng làm việc với nó, bạn sẽ càng nhận được nó tốt hơn.

HTH, và chúc may mắn!

Quốc gia

Tôi nghĩ rằng bạn đã đóng đinh một số tiêu chí tốt. Điểm thứ hai của bạn là một cách tốt để xác định phạm vi cho các thử nghiệm của bạn và tôi cũng đề nghị kiểm tra các điều kiện lỗi và các lỗi (tôi ủng hộ rằng mọi sửa lỗi đều có ít nhất một thử nghiệm đơn vị mới). Bây giờ nó có vẻ áp đảo, nhưng chỉ cần lao vào, và sau khi có được một chút kinh nghiệm, nhận ra những gì làm cho các bài kiểm tra tốt sẽ trở nên dễ dàng hơn.