Please enable JavaScript.
Coggle requires JavaScript to display documents.
TestCase Development - Coggle Diagram
TestCase Development
Write Test Cases
Viết test case
Test case là gì?
Là một tình huống kiểm tra, được thiết kế để kiểm tra
một đối tượng có thỏa mãn yêu cầu đặt ra hay không
Test scenario :arrow_right: test case :arrow_right: Test Step
Test Case:
danh sách các test step
Test Scenario:
danh sách các test case và phối hợp của
chúng
Test Step:
một hành động để thực hiện và đáp ứng mong
đợi
Cấu trúc test case
Precondition
Tập các bước phải thực hiện trước khi chạy
test case
Cũng có thể là 1 hoặc chuỗi các test case khác
Test step
Tập các bước/hành động được thực hiện để
hoàn thành mục đích của test case
Nên
Mô tả chi tiết, dùng giá trị cụ thể
Ngắn gọn, từng bước cụ thể
Các bước nên được đánh thứ tự
Test name/Test description
Mô tả mục đích của test case
Nên
Ngắn gọn, rõ ràng
Mô tả một cách tổng quan mục đích của test
case
Expected result
Tập kết quả trả về được mong đợi sau khi chạy
test case
Test case ID
Mã định danh duy nhất để phân biệt các test
case
Nên đặt tên
Dễ biết được test case thuộc chức năng nào
Dễ thêm 1 test case mới cho cùng 1 chức năng
Không dùng lại ID của test case đã bị xóa
Good Test Case
Traceable
: Có thể theo dõi - theo yêu cầu
Appropriate
: Thích hợp - cho môi trường thử nghiệm
Repeatable, reusable:
Lặp lại, tái sử dụng
Self standing:
Tự lập - không phụ thuộc vào người viết
Economical
: Tiết kiệm - không có bước không cần thiết
Self cleaning:
Tự dọn dẹp
Accurate
: Chính xác - kiểm tra những gì
được thiết kế để kiểm tra
Bad Test Case
Mô tả các bước không rõ ràng
Không mô tả kết quả mong đợi
Không có Test Data cụ thể
Quá phức tạp
Mục tiêu Test không rõ ràng
Test Scenario
Kịch bản kiểm thử
What
Được định nghĩa là bất kỳ chức năng nào cũng có thể được kiểm tra
Còn được gọi là Test Condition hay Test Possibility
Why
Chúng đóng vai trò như một công cụ để xác định effort kiểm thử nhanh chóng và theo đó tạo đề xuất cho khách hàng hoặc tổ chức lực lượng lao động
Chúng giúp xác định các giao dịch đầu cuối quan trọng nhất hoặc việc sử dụng thực sự của các ứng dụng phần mềm.
Các kịch bản thử nghiệm có thể được phê duyệt bởi các skateholder khác nhau như Business Analyst, Developers, Khách hàng để đảm bảo AUT được kiểm tra kỹ lưỡng. Nó đảm bảo rằng phần mềm đang hoạt động với các use case phổ biến nhất.
Để nghiên cứu hoạt động từ đầu đến cuối của chương trình, Test Scenerio là rất quan trọng
Đảm bảo phạm vi kiểm tra hoàn chỉnh
When not
Các dự án tuân theo Phương pháp Agile như Scrum, Kanban có thể không tạo Test Scenario
Test Scenariocó thể không được tạo cho lỗi mới sửa hay Regression Testing. Trong các trường hợp như vậy, Test Scenarios phải được ghi lại nhiều trong các chu kỳ thử nghiệm trước đó. Điều này đặc biệt đúng với các dự án bảo trì
Ứng dụng đang kiểm thử rất phức tạp, không ổn định và có một thời gian khủng hoảng trong dự án
How
Bước 3: Sau khi đọc Tài liệu yêu cầu và thực hiện Phân tích, hãy liệt kê các kịch bản kiểm tra khác nhau để xác minh từng tính năng của phần mềm
Bước 4: Khi bạn đã liệt kê tất cả các Test Scenarios có thể, Traceability Matrix được tạo để xác minh rằng mỗi & mọi yêu cầu đều có Test Scenario tương ứng
Bước 5: Các Test Scenarios được tạo ra được xem xét bởi người giám sát của bạn. Sau đó, họ cũng được xem xét bởi các Stakeholders trong dự án
Bước 2: Đối với mỗi yêu cầu, hãy tìm ra các hành động và mục tiêu của người dùng có thể thực hiện. Xác định các khía cạnh kỹ thuật của yêu cầu. Xác định các tình huống có thể xảy ra về lạm dụng hệ thống và đánh giá người dùng với suy nghĩ của hacker.
Bước 1: Đọc các Tài liệu yêu cầu như BRS, SRS, FRS, của Hệ thống đang thử nghiệm (SUT)
Test Documentation
Tài liệu kiểm thử
Ưu điểm
Cung cấp một sản phẩm chất lượng cho khách hàng trong thời gian giới hạn cụ thể
Giúp cấu hình hoặc thiết lập chương trình thông qua tài liệu cấu hình và hướng dẫn vận hành
Là một chiến lược tiếp thị và bán hàng tốt để giới thiệu Tài liệu kiểm thử nghiệm để thể hiện một quy trình thử nghiệm trưởng thành
Cải thiện tính minh bạch với khách hàng
Không chỉ cung cấp một cách tiếp cận có hệ thống để kiểm thử phần mềm, mà nó còn đóng vai trò là tài liệu đào tạo cho những người mới vào quy trình kiểm thử phần mềm
Giảm hoặc loại bỏ bất kỳ sự không chắc chắn nào về các hoạt động kiểm thử. Giúp bạn loại bỏ sự mơ hồ thường phát sinh khi phân bổ nhiệm vụ
Nhược điểm
Nhiều khi nó được viết bởi những người không thể viết tốt hoặc những người không biết tài liệu
Theo dõi các thay đổi theo yêu cầu của khách hàng và cập nhật các tài liệu tương ứng khá mệt mỏi
Chi phí của tài liệu có thể vượt quá giá trị của nó vì nó rất tốn thời gian
Tài liệu kém phản ánh trực tiếp chất lượng sản phẩm là sự hiểu lầm giữa khách hàng và tổ chức có thể xảy ra
Một số tài liệu quan trọng
Test Scenario
Một sản phẩm hoặc sự kiện của một hệ thống phần mềm có thể được xác minh bằng một hoặc nhiều test cases
Test case
Một nhóm các giá trị đầu vào, điều kiện tiên quyết thực hiện, kết quả thực tế và kết quả mong đợi
Requirements Traceability Matrix
Một tài liệu kết nối các yêu cầu với các test cases
Test Data
Dữ liệu tồn tại trước khi kiểm thử được thực thi, được sử dụng để thực hiện các test cases
Test plan
Một kế hoạch kiểm thử là một tài hoàn chỉnh bao gồm phạm vi, cách tiếp cận, tài nguyên, lịch trình, vv của các hoạt động kiểm thử
Defect Report
Một tài liệu báo cáo về bất kỳ lỗ hổng nào trong Hệ thống phần mềm hoặc khi không thực hiện được chức năng mong đợi
Test summary report
Một tài liệu cấp cao trong đó tóm tắt các hoạt động kiểm thử được thực hiện cũng như kết quả kiểm thử
Test strategy
Một tài liệu cấp cao xác định các Mức kiểm thử sẽ được thực thi cho dự án
Test policy
Một tài liệu cấp cao mô tả các nguyên tắc, phương pháp và tất cả các mục tiêu kiểm thử quan trọng của tổ chức
Định nghĩa
Là tài liệu về các tạo phẩm được tạo ra trước hoặc trong quá trình kiểm thử phần mềm
Test Analysis
Phân tích kiểm thử
Test Analysis là gì?
Là quá trình xem xét các artifact (các sản phẩm được tạo ra trong quá trình phát triển phần mềm như SRS, BRS,...) kiểm thử để làm cơ sở cho các test conditions/test cases
Dựa trên
BRS (Business Requirement Specification)
Functional Design Documents
SRS (Software Requirement Specification)
Phân tích kiểm thử trong mô hình V
Test Data Generation
Tạo dữ liệu kiểm thử
Test data là gì?
Là dữ liệu đầu vào được cung cấp cho một chương trình phần mềm trong quá trình thực hiện kiểm thử
Các cách tạo dữ liệu kiểm thử
Một lượng lớn dữ liệu copy từ dữ liệu production tới môi trường test
Một lượng lớn dữ liệu copy từ các hệ thống client
Tạo thủ công
Từ các tools tự động
tạo dữ liệu test
Test Data Generator của DTM
Datatect của Banner Software
Requirements Traceability Matrix (RTM)
RTM là gì?
Là một tài liệu cập nhật các yêu cầu và được đối chiếu với các test case
Các loại RTM
Backward/reverse traceability
Bi-directional traceability ( Forward+Backward)
Forward traceability
Lợi ích của RTM
Làm nổi bật bất kỳ yêu cầu nào bị thiếu hoặc không nhất quán về tài liệu
Cho thấy các khiếm khuyết tổng thể hoặc trạng thái thực thi với trọng tâm là các yêu cầu kinh doanh.
Đảm bảo kiểm tra 100% phạm vị
Giúp phân tích hoặc ước tính tác động đến công việc của nhóm QA liên quan đến việc xem xét lại hoặc thực thi lại các test case
