Những lời khuyên cho việc viết Testcases

Một trong những hoạt động thường xuyên và quan trọng nhất của một người kiểm thử phần mềm là viết Test Cases. A. Các TestCases dễ bị sửa đổi và cập nhật thường xuyên:

Chúng ta sống trong một thế giới liên tục thay đổi, phần mềm cũng không miễn nhiễm với những thay đổi. Tương tự cũng phù hợp với yêu cầu và điều này ảnh hưởng trực tiếp đến các trường hợp thử nghiệm. Bất cứ khi nào, yêu cầu làThay đổi, TC cần phải được cập nhật. Tuy nhiên, nó không chỉ là thay đổi trong yêu cầu có thể gây ra việc sửa đổi và cập nhật cho TC.

Trong quá trình thực hiện TC, nhiều ý tưởng nảy sinh trong tâm trí, nhiều điều kiện phụ của một TC đơn lẻ đã gây ra việc cập nhật và thậm chí cả việc bổ sung các TC. Hơn nữa, trong quá trình hồi quy thử nghiệm một số sửa chữa hoặc gợn sóng cần sửa đổi hoặc TC mới.

B. Các trường hợp thử nghiệm có xu hướng phân bố trong số những người kiểm tra sẽ thực hiện những điều sau:

Tất nhiên hầu như không có trường hợp một người kiểm tra thực hiện tất cả các TC. Thông thường có một số người kiểm tra đã kiểm tra các mô đun khác nhau của một ứng dụng duy nhất. Vì vậy, các TC được phân chia trong số chúng theo các khu vực sở hữu của họ đang áp dụng thử nghiệm. Một số TC liên quan đến tích hợp ứng dụng có thể được thực hiện bởi nhiều người kiểm tra trong khi một số chỉ có thể được thực hiện bởi một người kiểm tra duy nhất.

C. Các trường hợp thử nghiệm có xu hướng tập hợp và trộn:

Bình thường và phổ biến là các TC thuộc một kịch bản thử nghiệm đơn lẻ thường yêu cầu thực hiện của họ trong một số trình tự cụ thể hoặc dưới hình thức nhóm. Có thể có một số TCs điều kiện tiên quyết của TC khác. Tương tự, theo logic kinh doanh của AUT, một TC đơn lẻ có thể đóng góp vào một số điều kiện kiểm tra và một điều kiện kiểm tra đơn lẻ có thể bao gồm nhiều TC.

D. Các trường hợp kiểm tra có khuynh hướng phụ thuộc lẫn nhau:

Đây cũng là một hành vi thú vị và quan trọng của các TC mà những người đó có thể phụ thuộc lẫn nhau. Trong các ứng dụng vừa và lớn với logic kinh doanh phức tạp, xu hướng này rõ ràng hơn.

Các khu vực rõ ràng nhất của bất kỳ ứng dụng mà hành vi này có thể được quan sát là sự tương tác giữa các mô-đun khác nhau của cùng một ứng dụng hoặc thậm chí khác nhau. Đơn giản chỉ cần nói, bất cứ nơi nào các mô-đun khác nhau hoặc các ứng dụng phụ thuộc lẫn nhau, hành vi tương tự được phản ánh trong TC.

E. Các trường hợp thử nghiệm có xu hướng phân bố giữa các nhà phát triển (đặc biệt là trong môi trường phát triển theo TC):

Một thực tế quan trọng về TC là những điều này không chỉ được sử dụng bởi các xét nghiệm. Trong trường hợp bình thường, khi một lỗi được sửa bởi các nhà phát triển, chúng gián tiếp sử dụng TC để khắc phục sự cố. Tương tự như vậy, khi phát triển TCD, các TC được sử dụng trực tiếp bởi các nhà phát triển để xây dựng logic của chúng và bao gồm tất cả các kịch bản, được giải quyết bởi TC, trong mã của chúng. Các bài kiểm tra viết lời khuyên

Vì vậy, hãy nhớ 5 yếu tố trên, đây là một số mẹo để viết các trường hợp thử nghiệm:

1. Giữ nó đơn giản nhưng không quá đơn giản; Làm cho nó phức tạp nhưng không quá phức tạp:

Lời tuyên bố này dường như là một nghịch lí, nhưng tôi hứa nó không phải là như vậy. Giữ tất cả các bước của TCs nguyên tử, chính xác với trình tự đúng và với bản đồ chính xác đến kết quả mong đợi, đây là những gì tôi có nghĩa là để làm cho nó đơn giản.

Bây giờ, làm cho nó phức tạp trên thực tế có nghĩa là để làm cho nó tích hợp với Kế hoạch kiểm tra và các TC khác. Tham khảo các TC khác, các hiện vật có liên quan, các GUI, vv ở đâu và khi nào được yêu cầu. Nhưng làm điều này cân bằng, không làm cho người kiểm tra để di chuyển đến và đi qua trong các đống tài liệu để hoàn thành kịch bản thử nghiệm duy nhất. Mặt khác thậm chí không để cho người thử muốn bạn có tài liệu các TCs một cách nhỏ gọn. Trong khi viết TC, luôn nhớ rằng bạn hoặc người khác sẽ phải sửa đổi và cập nhật chúng.

2. Sau khi tài liệu các trường hợp kiểm tra, xem lại một lần là Tester:

Không bao giờ nghĩ rằng công việc được thực hiện một khi bạn đã viết TC cuối cùng của kịch bản thử nghiệm. Hãy bắt đầu và xem xét tất cả các TC một lần, nhưng không phải với tâm trí của nhà văn TC hoặc Kế hoạch kiểm tra. Xem xét tất cả các TC với tâm trí của người kiểm tra. Hãy suy nghĩ một cách hợp lý và cố gắng để khô chạy TC của bạn. Đánh giá rằng tất cả các bước bạn đã đề cập đều có thể hiểu được rõ ràng và kết quả mong đợi sẽ hài hòa với các bước đó.

Các dữ liệu thử nghiệm được chỉ định trong TCs là khả thi không chỉ cho người kiểm tra thực tế mà còn theo môi trường thời gian thực. Đảm bảo rằng không có xung đột về sự phụ thuộc giữa các TC và cũng xác minh rằng tất cả các tham chiếu đến TC khác / các hiện vật / GUI đều chính xác bởi vì, người kiểm tra có thể gặp rắc rối lớn nếu không.

3. Bound cũng như dễ dàng các xét nghiệm:

Không để dữ liệu thử nghiệm trên người kiểm tra, cung cấp cho họ nhiều đầu vào đặc biệt là nơi tính toán được thực hiện hoặc ứng dụng của hành vi là phụ thuộc vào đầu vào. Bạn có thể chia các giá trị của các mục kiểm tra trong số chúng, nhưng không bao giờ cho phép họ tự chọn các dữ liệu thử nghiệm. Bởi vì, cố ý hoặc không chủ ý, họ có thể sử dụng cùng một dữ liệu thử nghiệm và một số dữ liệu thử nghiệm quan trọng có thể bị bỏ qua trong quá trình thực hiện TC.

Giữ cho người kiểm tra giảm bớt bằng cách tổ chức các TC theo các hạng mục thử nghiệm và các lĩnh vực áp dụng liên quan. Hướng dẫn rõ ràng và đề cập đến TC nào phụ thuộc lẫn nhau và / hoặc được thực hiện theo lô. Tương tự, nêu rõ các TC nào độc lập và bị cô lập để người kiểm tra có thể quản lý hoạt động tổng thể theo ý của mình.

4. Hãy là Cộng tác viên:

Không bao giờ chấp nhận FS hoặc Tài liệu Thiết kế như nó được. Công việc của bạn không chỉ để đi qua FS và xác định các Kịch bản thử nghiệm. Là nguồn lực có liên quan đến chất lượng, đừng ngần ngại đóng góp. Đề xuất cho các nhà phát triển, đặc biệt là trong môi trường phát triển hướng TC. Đề xuất danh sách thả xuống, điều khiển lịch, danh sách lựa chọn, các nút radio nhóm, các thông điệp có ý nghĩa, cảnh báo, nhắc nhở, cải tiến liên quan đến khả năng sử dụng vv

5. Không bao giờ quên người dùng cuối

Bên liên quan quan trọng nhất là 'Người dùng Cuối', người sẽ thực sự sử dụng AUT. Vì vậy, đừng bao giờ quên anh ta ở bất kỳ giai đoạn nào của văn bản TC. Trên thực tế, người dùng cuối không nên bỏ qua ở bất kỳ giai đoạn nào trong SDLC, nhưng sự nhấn mạnh của tôi cho đến nay chỉ liên quan đến chủ đề của tôi. Vì vậy, trong quá trình xác định các kịch bản thử nghiệm, bạn không bao giờ bỏ qua những trường hợp mà người sử dụng sẽ sử dụng chủ yếu hoặc thậm chí là sử dụng ít thường xuyên hơn. Hãy tưởng tượng mình là Người dùng cuối, một lần đi qua tất cả các TC và đánh giá giá trị thực tế của việc thực hiện tất cả các TC của bạn.

Phần kết luận:

Viết luận án thử nghiệm là một hoạt động có ảnh hưởng đáng kể đến toàn bộ giai đoạn thử nghiệm. Thực tế này làm cho nhiệm vụ lập hồ sơ cho TC, rất quan trọng và tinh tế. Vì vậy, nó phải được lên kế hoạch đúng đắn trước tiên và phải được thực hiện theo cách có tổ chức tốt. Người lập hồ sơ cho TC phải ghi nhớ rằng, hoạt động này không dành cho anh ta hoặc cô ta, nhưng cả một nhóm gồm các nhà kiểm tra và phát triển khác, cũng như khách hàng sẽ bị ảnh hưởng trực tiếp và gián tiếp bởi công việc này.

Vì vậy, sự chú ý phải được thanh toán trong suốt hoạt động này. "Tài liệu Hồ sơ Thử nghiệm" phải dễ hiểu đối với tất cả người dùng, một cách rõ ràng và dễ dàng duy trì. Hơn nữa, tài liệu TC phải đề cập đến tất cả các tính năng quan trọng và phải bao gồm tất cả các dòng chảy hợp lý quan trọng của AUT, với thời gian thực và các đầu vào thực tế chấp nhận được.

Các trường hợp thử nghiệm của bạn viết chiến lược là gì? Chia sẻ mẹo của bạn với độc giả của chúng tôi và cũng đặt các truy vấn của bạn trong nhận xét dưới đây.

http://www.softwaretestinghelp.com/tips-for-writing-test-cases/