STLC - Hướng dẫn nhanh

STLC là viết tắt của Vòng đời kiểm thử phần mềm. STLC là một chuỗi các hoạt động khác nhau được thực hiện bởi nhóm kiểm thử để đảm bảo chất lượng của phần mềm hoặc sản phẩm.

STLC là một phần không thể thiếu của Vòng đời phát triển phần mềm (SDLC). Tuy nhiên, STLC chỉ giải quyết các giai đoạn thử nghiệm.
STLC bắt đầu ngay sau khi các yêu cầu được xác định hoặc SRD (Tài liệu Yêu cầu Phần mềm) được chia sẻ bởi các bên liên quan.
STLC cung cấp quy trình từng bước để đảm bảo chất lượng phần mềm.
Trong giai đoạn đầu của STLC, trong khi phần mềm hoặc sản phẩm đang phát triển, người kiểm thử có thể phân tích và xác định phạm vi kiểm thử, tiêu chí đầu vào và lối ra và cả các Trường hợp kiểm thử. Nó giúp giảm thời gian chu kỳ kiểm tra cùng với chất lượng tốt hơn.
Ngay sau khi giai đoạn phát triển kết thúc, người kiểm thử đã sẵn sàng với các trường hợp kiểm thử và bắt đầu với việc thực thi. Điều này giúp tìm ra lỗi trong giai đoạn đầu.

Giai đoạn STLC

STLC có các giai đoạn khác nhau sau đây nhưng không bắt buộc phải tuân theo tất cả các giai đoạn. Các giai đoạn phụ thuộc vào bản chất của phần mềm hoặc sản phẩm, thời gian và nguồn lực được phân bổ cho thử nghiệm và mô hình SDLC sẽ được tuân theo.

Có 6 giai đoạn chính của STLC -

Requirement Analysis - Khi SRD đã sẵn sàng và được chia sẻ với các bên liên quan, nhóm thử nghiệm bắt đầu phân tích mức cao liên quan đến AUT (Ứng dụng đang thử nghiệm).
Test Planning - Nhóm Kiểm tra hoạch định chiến lược và cách tiếp cận.
Test Case Designing - Phát triển các trường hợp kiểm thử dựa trên phạm vi và tiêu chí của.
Test Environment Setup - Khi môi trường tích hợp đã sẵn sàng để xác nhận sản phẩm.
Test Execution - Thời gian thực xác nhận sản phẩm và tìm lỗi.
Test Closure - Sau khi kiểm tra xong, ma trận, báo cáo, kết quả được lập thành tài liệu.

Trong chương này, chúng ta sẽ hiểu các yếu tố so sánh giữa STLC và SDLC. Chúng ta hãy xem xét các điểm sau và qua đó, so sánh STLC và SDLC.

STLC là một phần của SDLC. Có thể nói STLC là một tập con của tập SDLC.
STLC được giới hạn trong giai đoạn thử nghiệm đảm bảo chất lượng của phần mềm hoặc sản phẩm. SDLC có vai trò to lớn và quan trọng trong việc phát triển hoàn chỉnh một phần mềm hoặc sản phẩm.
Tuy nhiên, STLC là một giai đoạn rất quan trọng của SDLC và sản phẩm cuối cùng hoặc phần mềm không thể được phát hành nếu không thông qua quy trình STLC.
STLC cũng là một phần của chu kỳ sau phát hành / cập nhật, giai đoạn bảo trì của SDLC nơi các lỗi đã biết được sửa hoặc một chức năng mới được thêm vào phần mềm.

Bảng sau liệt kê các yếu tố so sánh giữa SDLC và STLC dựa trên các giai đoạn của chúng:

Giai đoạn	SDLC	STLC
Thu thập các yêu cầu	Business Analyst tập hợp các yêu cầu. Nhóm phát triển phân tích các yêu cầu. Sau khi cấp cao, nhóm phát triển bắt đầu phân tích từ kiến trúc và quan điểm thiết kế.	Nhóm kiểm tra xem xét và phân tích tài liệu SRD. Xác định các yêu cầu thử nghiệm - Các điểm chính về Phạm vi, Xác minh và Xác thực. Xem xét các yêu cầu về mối quan hệ logic và chức năng giữa các mô-đun khác nhau. Điều này giúp xác định các lỗ hổng ở giai đoạn đầu.
Thiết kế	Kiến trúc của SDLC giúp bạn phát triển thiết kế cấp cao và cấp thấp của phần mềm dựa trên các yêu cầu. Business Analyst làm việc trên nền tảng của thiết kế giao diện người dùng. Sau khi thiết kế hoàn thành, các bên liên quan sẽ ký hợp đồng.	Trong STLC, Kiến trúc sư kiểm thử hoặc Trưởng nhóm kiểm tra thường lập kế hoạch chiến lược kiểm tra. Xác định các điểm kiểm tra. Phân bổ nguồn lực và tiến trình thời gian được hoàn thành ở đây.
Phát triển	Nhóm phát triển bắt đầu phát triển phần mềm. Tích hợp với các hệ thống khác nhau. Sau khi tất cả tích hợp được thực hiện, một phần mềm hoặc sản phẩm sẵn sàng để kiểm tra sẽ được cung cấp.	Nhóm kiểm thử viết các kịch bản kiểm tra để xác nhận chất lượng của sản phẩm. Các trường hợp kiểm thử chi tiết được viết cho tất cả các mô-đun cùng với hành vi mong đợi. Các điều kiện tiên quyết và tiêu chí vào và ra của một mô-đun thử nghiệm được xác định ở đây.
Môi trường thiết lập	Nhóm phát triển thiết lập một môi trường thử nghiệm với sản phẩm đã phát triển để xác nhận.	Nhóm Kiểm tra xác nhận môi trường được thiết lập dựa trên các điều kiện tiên quyết. Thực hiện kiểm tra khói để đảm bảo môi trường ổn định cho sản phẩm được kiểm tra.
Thử nghiệm	Thử nghiệm thực tế được thực hiện trong giai đoạn này. Nó bao gồm kiểm thử đơn vị, kiểm tra tích hợp, kiểm tra hệ thống, kiểm tra lại lỗi, kiểm tra hồi quy, v.v. Nhóm Phát triển sẽ sửa lỗi được báo cáo, nếu có và gửi lại cho người thử nghiệm để kiểm tra lại. Kiểm tra UAT thực hiện ở đây sau khi đăng xuất khỏi kiểm tra SIT.	Kiểm thử tích hợp hệ thống bắt đầu dựa trên các trường hợp thử nghiệm. Các lỗi được báo cáo, nếu có, sẽ được kiểm tra lại và sửa. Kiểm tra hồi quy được thực hiện ở đây và sản phẩm được đăng xuất sau khi đáp ứng tiêu chí thoát.
Triển khai / Phát hành sản phẩm	Sau khi nhận được đăng xuất từ các nhóm thử nghiệm khác nhau, ứng dụng sẽ được triển khai trong môi trường sản phẩm dành cho người dùng cuối thực sự.	Thử nghiệm khói và độ tỉnh táo trong môi trường sản xuất được hoàn thành tại đây ngay khi sản phẩm được triển khai. Báo cáo thử nghiệm và chuẩn bị ma trận được thực hiện bởi nhóm thử nghiệm để phân tích sản phẩm.
Bảo trì	Nó bao gồm hỗ trợ triển khai bài đăng, nâng cao và cập nhật, nếu có.	Trong giai đoạn này, việc duy trì các trường hợp thử nghiệm, bộ đồ hồi quy và các tập lệnh tự động hóa diễn ra dựa trên việc nâng cao và cập nhật.

Mục tiêu chung của thử nghiệm là tìm ra lỗi càng sớm càng tốt. Và, khi các lỗi đã được sửa, hãy đảm bảo rằng nó đang hoạt động như mong đợi và không phá vỡ bất kỳ chức năng nào khác.

Để đạt được những mục tiêu này, bảy nguyên tắc cơ bản được đưa ra để kiểm thử phần mềm -

Thử nghiệm cho thấy gì?

Thử nghiệm có thể cho thấy có khuyết tật nhưng không có cách nào để chứng minh rằng sản phẩm không có khuyết tật. Các giai đoạn kiểm tra đảm bảo rằng ứng dụng được kiểm tra đang hoạt động dựa trên yêu cầu đã cho và nó giúp giảm xác suất các lỗi chưa được phát hiện trong ứng dụng. Nhưng, ngay cả khi không tìm thấy khuyết tật, điều đó không có nghĩa là nó hoàn toàn chính xác. Chúng tôi có thể cho rằng AUT phù hợp với tiêu chí thoát của chúng tôi và duy trì các yêu cầu theo SRD.

Thử nghiệm hoàn chỉnh có khả thi không?

Không thể bao phủ 100% hoặc kiểm tra tất cả các kết hợp đầu vào và các kết hợp có thể có ngoại trừ các trường hợp nhỏ. Thay vì kiểm tra toàn diện, phân tích rủi ro và ưu tiên được sử dụng để xác định phạm vi kiểm tra. Ở đây, hầu hết các kịch bản thời gian thực cũng có thể xem xét bao gồm cả kịch bản tiêu cực có thể xảy ra nhất. Điều này sẽ giúp chúng tôi theo dõi lỗi.

Thử nghiệm sớm

Các hoạt động kiểm tra nên bắt đầu càng sớm càng tốt và tập trung vào các mục tiêu đã xác định trong Chiến lược kiểm tra và kết quả mong đợi. Giai đoạn đầu của thử nghiệm giúp xác định Khuyết điểm Yêu cầu hoặc sai lệch mức thiết kế. Nếu những loại lỗi này được bắt trong giai đoạn đầu, nó sẽ giúp chúng tôi tiết kiệm thời gian và hiệu quả về chi phí. Câu trả lời cho lý do tại sao thử nghiệm nên bắt đầu ở giai đoạn đầu rất đơn giản - ngay sau khi nhận được SRD, người thử nghiệm có thể phân tích yêu cầu từ góc độ thử nghiệm và có thể nhận thấy sự khác biệt về yêu cầu.

Phân cụm khiếm khuyết

Dựa trên phân tích lỗi của sản phẩm trước đây, có thể nói rằng hầu hết các lỗi được xác định từ một nhóm nhỏ các mô-đun rất quan trọng đối với ứng dụng. Các mô-đun này có thể được xác định dựa trên độ phức tạp, sự tương tác hệ thống khác nhau hoặc sự phụ thuộc vào các mô-đun khác khác nhau. Nếu người kiểm tra có thể xác định các mô-đun quan trọng này, họ có thể tập trung nhiều hơn vào các mô-đun này để xác định tất cả các lỗi có thể xảy ra. Trong một nghiên cứu, người ta thấy rằng 8 trong số 10 lỗi được xác định từ 20% chức năng của AUT.

Nghịch lý thuốc trừ sâu

Nghịch lý thuốc trừ sâu là gì - nếu thuốc trừ sâu thường xuyên được sử dụng trên cây trồng, sẽ đến khi côn trùng phát triển một loại kháng thuốc nhất định và dần dần thuốc trừ sâu được phun ra dường như không có tác dụng đối với côn trùng.

Khái niệm tương tự cũng được áp dụng cho thử nghiệm. Ở đây, côn trùng là lỗi trong khi thuốc trừ sâu là trường hợp thử nghiệm được sử dụng để chạy đi chạy lại. Nếu các tập hợp các trường hợp thử nghiệm giống nhau được thực thi lặp đi lặp lại, các trường hợp thử nghiệm này sẽ trở nên vô hiệu sau khung thời gian nhất định và người thử nghiệm sẽ không thể xác định bất kỳ lỗi mới nào.

Để khắc phục những điều kiện này, các trường hợp kiểm thử cần được sửa đổi và xem xét theo thời gian và có thể thêm các trường hợp kiểm thử mới và khác nhau. Điều này sẽ giúp xác định các khiếm khuyết mới.

Thử nghiệm phụ thuộc vào ngữ cảnh

Nguyên tắc này nói rằng không thể kiểm tra hai loại ứng dụng khác nhau bằng cách sử dụng cùng một phương pháp cho đến khi cả hai ứng dụng có cùng bản chất. Ví dụ: nếu người thử nghiệm sử dụng cùng một cách tiếp cận cho Ứng dụng dựa trên web và Ứng dụng dành cho thiết bị di động, điều đó hoàn toàn sai và có nhiều rủi ro về chất lượng sản phẩm kém. Người kiểm tra nên sử dụng các cách tiếp cận, phương pháp luận, kỹ thuật và phạm vi bảo hiểm khác nhau cho các loại và bản chất ứng dụng khác nhau.

Không có lỗi - Sai lầm

Nguyên tắc này nêu rõ việc tìm ra các khiếm khuyết và sửa chữa chúng cho đến khi ứng dụng hoặc hệ thống ổn định, tốn thời gian và cũng tiêu tốn tài nguyên. Ngay cả sau khi sửa chữa 99% các khiếm khuyết, vẫn có nguy cơ ứng dụng không ổn định cao. Điều cần thiết đầu tiên là xác minh tính ổn định của ứng dụng và các điều kiện tiên quyết của môi trường. Nếu hai điều kiện này đáp ứng, chỉ sau đó chúng ta có thể bắt đầu với thử nghiệm chi tiết.

Phân tích Yêu cầu là giai đoạn đầu tiên của STLC và nó bắt đầu ngay sau khi SRD / SRS được chia sẻ với nhóm thử nghiệm. Chúng ta hãy xem xét các điểm sau để hiểu Phân tích Yêu cầu trong STLC.

Tiêu chí đầu vào của giai đoạn này là cung cấp SRS (Đặc tả yêu cầu phần mềm); nó cũng được khuyến nghị rằng kiến trúc ứng dụng phải tiện dụng.
Trong giai đoạn này, nhóm QA phân tích ở cấp cao hơn những gì cần kiểm tra và cách kiểm tra.
Nhóm QA liên hệ với các bên liên quan khác nhau như Nhà phân tích kinh doanh, Kiến trúc hệ thống, Khách hàng, Người quản lý kiểm tra / Trưởng nhóm trong trường hợp cần có bất kỳ câu hỏi hoặc giải thích nào để hiểu yêu cầu.
Các yêu cầu có thể là chức năng hoặc phi chức năng như hiệu suất, bảo mật, khả năng sử dụng, v.v. hoặc cả chức năng và phi chức năng.
Tiêu chí thoát ra của giai đoạn này là hoàn thành tài liệu RTM, báo cáo khả thi về tự động hóa và danh sách các câu hỏi nếu có để cụ thể hơn về các yêu cầu.

Các hoạt động được thực hiện để phân tích yêu cầu

Có ba hoạt động chính được nhóm QA thực hiện trong giai đoạn này. Các hoạt động đã được mô tả dưới đây.

Xác định phạm vi

Nhóm QA xác định phạm vi kiểm thử ở các cấp độ cao và chia thành các mô-đun chức năng khác nhau. Nhóm cũng xác định các loại kiểm tra bắt buộc phải thực hiện - kiểm tra khói, kiểm tra độ tỉnh táo, kiểm tra chức năng, kiểm tra hồi quy, v.v. Nhóm QA phân tích các điều kiện tiên quyết và chi tiết về môi trường nơi thử nghiệm được cho là phải thực hiện. Nhóm thu thập thông tin chi tiết về các ưu tiên thử nghiệm và tập trung vào chuỗi các mô-đun cần được xác thực. Nó cũng xác định các lỗi yêu cầu nếu các mô-đun bị mâu thuẫn và chức năng không được thực hiện cùng với các mô-đun khác.

Chuẩn bị RTM

Theo dõi yêu cầu là một quá trình ghi lại các mối liên hệ giữa các yêu cầu và sản phẩm công việc được phát triển để thực hiện và xác minh các yêu cầu đó. RTM nắm bắt tất cả các yêu cầu tại Phân tích Yêu cầu cùng với khả năng xác định nguồn gốc của chúng trong một tài liệu duy nhất. Tất cả những điều này được chuyển giao khi kết thúc vòng đời.

Ma trận được tạo khi bắt đầu một dự án vì nó tạo cơ sở cho phạm vi dự án và các sản phẩm sẽ được sản xuất.

Ma trận là hai chiều, vì nó theo dõi yêu cầu về phía trước bằng cách kiểm tra đầu ra của các sản phẩm phân phối và lùi lại bằng cách xem xét yêu cầu kinh doanh đã được chỉ định cho một tính năng cụ thể của sản phẩm.

Phân tích tự động hóa

Trong giai đoạn yêu cầu, nhóm QA phân tích phạm vi tự động hóa để kiểm tra hồi quy. Nếu tự động hóa được thêm vào phạm vi, nhóm sẽ quyết định công cụ nào có thể được sử dụng, những chức năng nào sẽ được đề cập như tự động hóa, khung thời gian và phân bổ nguồn lực liên quan đến phát triển tự động hóa. Sau khi hoàn thành phân tích này, nhóm QA sẽ cung cấp Báo cáo khả thi tự động hóa cho các bên liên quan khác nhau để cung cấp cho người ký.

Trong chương này, chúng ta sẽ thấy các Tiêu chí Vào và Thoát ở các cấp độ khác nhau trong STLC. Những điểm sau đây cần được xem xét để hiểu các tiêu chí.

Tốt nhất, nhóm QA không tiến hành giai đoạn tiếp theo cho đến khi đáp ứng các tiêu chí thoát ra của giai đoạn hiện tại. Các tiêu chí đầu vào nên bao gồm việc hoàn thành các tiêu chí thoát của giai đoạn trước.

Trong thời gian thực, không thể đợi giai đoạn tiếp theo cho đến khi các tiêu chí thoát ra được đáp ứng. Bây giờ, giai đoạn tiếp theo có thể được bắt đầu nếu các sản phẩm quan trọng của giai đoạn trước đã được hoàn thành.

Trong mỗi giai đoạn của STLC, các tiêu chí vào và ra cần được xác định.

Tiêu chuẩn nhập cảnh

Tiêu chí đầu vào cho các giai đoạn STLC có thể được xác định là các điều kiện cụ thể; hoặc, tất cả các tài liệu cần thiết để bắt đầu một giai đoạn cụ thể của STLC phải có sẵn trước khi bước vào bất kỳ giai đoạn STLC nào.

Tiêu chí đầu vào là một tập hợp các điều kiện cho phép một nhiệm vụ thực hiện, hoặc nếu thiếu bất kỳ điều kiện nào trong số này, nhiệm vụ không thể được thực hiện.

Trong khi thiết lập tiêu chí đầu vào, điều quan trọng là phải xác định khung thời gian khi mục tiêu chí nhập có sẵn để bắt đầu quá trình.

Đối với Phiên bản, để bắt đầu giai đoạn phát triển Trường hợp kiểm thử, các điều kiện sau cần được đáp ứng:

Tài liệu yêu cầu phải có sẵn.
Cần có hiểu biết đầy đủ về quy trình ứng dụng.
Tài liệu Kế hoạch Kiểm tra đã sẵn sàng.

Tiêu chí thoát

Tiêu chí Thoát cho các giai đoạn STLC có thể được định nghĩa là các mục / tài liệu / hành động / nhiệm vụ phải được hoàn thành trước khi kết thúc giai đoạn hiện tại và chuyển sang giai đoạn tiếp theo.

Tiêu chí thoát là một tập hợp các kỳ vọng; điều này cần được đáp ứng trước khi kết thúc giai đoạn STLC.

Đối với Phiên bản, để kết thúc giai đoạn phát triển Trường hợp thử nghiệm, cần đáp ứng các kỳ vọng sau:

Các trường hợp kiểm thử phải được viết và xem xét.
Dữ liệu thử nghiệm phải được xác định và sẵn sàng.
Kịch bản tự động hóa kiểm tra phải sẵn sàng nếu có.

Tiêu chí chấp nhận có nghĩa là hành vi mong đợi của một chức năng, mô-đun và ứng dụng như được liệt kê trong các tài liệu yêu cầu. Đó là các giai đoạn / điểm kiểm tra xác minh để xác định xem hệ thống phần mềm có đáp ứng các yêu cầu kỹ thuật hay không. Mục đích chính của thử nghiệm này là để đánh giá sự tuân thủ của hệ thống với các yêu cầu nghiệp vụ và xác minh xem hệ thống đã đáp ứng các tiêu chí yêu cầu hay chưa.

Tiêu chí chấp nhận là một tập hợp các tuyên bố, đề cập rõ ràng về kết quả đạt / không đạt mong đợi. Tiêu chí chấp nhận quy định cả yêu cầu chức năng và phi chức năng. Những yêu cầu này đại diện cho "điều kiện thỏa mãn hoặc hành vi mong đợi." Không có sự chấp nhận từng phần; hoặc một tiêu chí được đáp ứng hoặc nó không được đáp ứng.

Các tiêu chí này xác định ranh giới và thông số của một chức năng / mô-đun và xác định xem chức năng / mô-đun đã hoàn thành và đang hoạt động như mong đợi hay chưa.

Tiêu chí Chấp nhận Cấp cao được đề cập ở Cấp Kế hoạch Kiểm tra. Tiêu chí chấp nhận được chuyển đổi thành danh sách các điểm cần xác minh hoặc kết quả mong đợi ở cấp trường hợp thử nghiệm.

Tiêu chí chấp nhận được xác định dựa trên các thuộc tính sau:

Tính đúng đắn và đầy đủ của chức năng
Toàn vẹn dữ liệu
Chuyển đổi dữ liệu
Usability
Performance
Timeliness
Tính bảo mật và tính khả dụng
Khả năng cài đặt và nâng cấp
Scalability
Documentation

Kế hoạch kiểm thử phác thảo chiến lược sẽ được sử dụng để kiểm tra một ứng dụng, các tài nguyên sẽ được sử dụng, môi trường kiểm thử mà việc kiểm thử sẽ được thực hiện, các hạn chế của kiểm thử và lịch trình của các hoạt động kiểm thử. Thông thường, Trưởng nhóm Đảm bảo Chất lượng sẽ chịu trách nhiệm viết Kế hoạch Kiểm tra.

Kế hoạch Kiểm tra Bao gồm những gì?

Kế hoạch kiểm tra bao gồm những điều sau đây.

Giới thiệu về tài liệu Kế hoạch kiểm tra.
Các giả định trong khi thử nghiệm ứng dụng.
Danh sách các trường hợp thử nghiệm được bao gồm trong việc thử nghiệm ứng dụng.
Danh sách các tính năng sẽ được kiểm tra.
Loại phương pháp được sử dụng trong khi kiểm tra phần mềm.
Danh sách các sản phẩm cần được kiểm tra.
Các tài nguyên được phân bổ để kiểm tra ứng dụng.
Bất kỳ rủi ro nào liên quan trong quá trình thử nghiệm.
Lịch trình các nhiệm vụ và các mốc quan trọng cần đạt được.

Các điểm quan trọng để lập kế hoạch kiểm tra

Các điểm sau đây cần được xem xét để Lập kế hoạch kiểm tra trong STLC.

Tốt nhất, Nhà phân tích thử nghiệm (Trưởng nhóm) / Người quản lý chuẩn bị Tài liệu Chiến lược Thử nghiệm / Kế hoạch Kiểm tra.
Phân tích tập trung hơn vào dữ liệu / thông tin liên quan đến ứng dụng.
Đây là giai đoạn đầu tiên của các nhiệm vụ thử nghiệm thực tế.
Giai đoạn này trả lời "CÁI GÌ cần được kiểm tra" và "NHỮNG NGUỒN LỰC NÀO được yêu cầu để kiểm tra".
Tiêu chí đầu vào cơ bản của giai đoạn này là cung cấp Tài liệu Yêu cầu (phiên bản cập nhật của các yêu cầu không rõ ràng / thiếu / được làm rõ) cùng với Ma trận xác định nguồn gốc yêu cầu.
Nếu tự động hóa nằm trong phạm vi, cần chuẩn bị Báo cáo khả thi tự động hóa trước khi bước vào giai đoạn này.
Tiêu chí thoát ra của giai đoạn này là hoàn thành Tài liệu Chiến lược Kiểm tra / Kế hoạch Kiểm tra và Tài liệu Ước tính nỗ lực Kiểm tra.

Các khía cạnh của giai đoạn lập kế hoạch thử nghiệm

Mục tiêu chính của giai đoạn này là chuẩn bị tài liệu Kế hoạch Kiểm tra / Chiến lược Kiểm tra. Nó bao gồm ba khía cạnh chính - Phạm vi phân phối, ước tính nỗ lực và kế hoạch nguồn lực.

Phạm vi phân phối

Các hoạt động sau cần được thực hiện để kết thúc phạm vi phân phối -

Xác định mô hình tương tác và phân phối phù hợp.
Xác định mục tiêu thử nghiệm, phạm vi thử nghiệm, các giai đoạn và hoạt động thử nghiệm.
Xem xét yêu cầu nghiệp vụ và yêu cầu hệ thống để xác định tính khả thi của thử nghiệm.
Xác định quy trình thử nghiệm, loại thử nghiệm và các thủ tục.
Xác định các thủ tục quản lý lỗi và quản lý thay đổi.
Xác định các công cụ kiểm tra, kỹ thuật và thực hành tốt nhất.
Xác định Phân tích Rủi ro.
Xác định giải pháp tự động hóa và xác định các ứng viên phù hợp cho tự động hóa nếu có.

Ước tính nỗ lực

Ước lượng là quá trình tìm kiếm một ước tính, hay gần đúng, là một giá trị có thể được sử dụng cho một số mục đích ngay cả khi dữ liệu đầu vào có thể không đầy đủ, không chắc chắn hoặc không ổn định.

Ước tính xác định cần bao nhiêu tiền, công sức, nguồn lực và thời gian để xây dựng một hệ thống hoặc sản phẩm cụ thể. Ước tính dựa trên -

Dữ liệu quá khứ / Kinh nghiệm trong quá khứ
Tài liệu / Kiến thức sẵn có
Assumptions
Rủi ro đã xác định

Bốn bước cơ bản trong Ước tính Thử nghiệm là:

Ước tính kích thước của AUT (Ứng dụng Đang Thử nghiệm).
Ước tính nỗ lực tính bằng người-tháng hoặc người-giờ.
Ước tính lịch trình trong các tháng dương lịch.
Ước tính chi phí dự án bằng đơn vị tiền tệ đã thỏa thuận.

Kế hoạch tài nguyên

Kế hoạch nguồn lực là yếu tố quan trọng trong các giai đoạn thử nghiệm. Các kế hoạch này tỷ lệ nghịch với thời gian mà nhóm thử nghiệm thực hiện để hoàn thành một nhiệm vụ cụ thể. Việc tăng số lượng tài nguyên sẽ làm giảm số ngày hoàn thành trong một giới hạn nhất định sau đó nó sẽ bão hòa và tăng tài nguyên sẽ không có nhiều tác động và có thể không dẫn đến giảm số ngày hoàn thành.

Người yêu cầu tài nguyên, thường là người quản lý dự án, tạo kế hoạch tài nguyên để yêu cầu tài nguyên, theo dõi nỗ lực và chi phí. Người quản lý tài nguyên có thể sửa đổi và phê duyệt kế hoạch tài nguyên trước khi kế hoạch được sử dụng.

Quy trình công việc bình thường cho một kế hoạch tài nguyên là -

Lập kế hoạch bởi Quản lý dự án
Yêu cầu do Quản lý dự án nêu ra
Phê duyệt / Sửa đổi / Từ chối bởi Người quản lý Tài nguyên
Hoàn thành - Đóng yêu cầu sau khi đăng xuất bởi Trình quản lý tài nguyên

Khi Kế hoạch thử nghiệm đã sẵn sàng, Nhóm QA bắt đầu phát triển các trường hợp thử nghiệm. Mục tiêu chính của giai đoạn này là chuẩn bị các trường hợp thử nghiệm cho một đơn vị riêng lẻ. Các trường hợp kiểm thử chức năng và cấu trúc này bao gồm chức năng, các điểm xác minh và xác nhận được đề cập trong Kế hoạch kiểm tra.

Các điểm sau đây cần được xem xét để phát triển trường hợp thử nghiệm trong STLC.

Trong giai đoạn này, nhóm QA viết trường hợp thử nghiệm với cách tiếp cận từng bước. Sau đó, Trường hợp kiểm thử được ký bởi Nhà phân tích kinh doanh sau khi xem xét hoặc làm lại các trường hợp kiểm thử trong trường hợp cần sửa đổi.
Khi các trường hợp thử nghiệm đã sẵn sàng, nhóm QA chuẩn bị Dữ liệu thử nghiệm dựa trên các điều kiện tiên quyết.
Tiêu chí đầu vào của giai đoạn này là các hoạt động trong kế hoạch kiểm tra phải được hoàn thành và kế hoạch kiểm tra phải sẵn sàng.
Tiêu chí thoát của giai đoạn này là các trường hợp thử nghiệm phải được ký kết, dữ liệu thử nghiệm phải sẵn sàng và các tập lệnh thử nghiệm được chuẩn bị nếu phạm vi tự động hóa.
Các trường hợp thử nghiệm nên được ánh xạ với Ma trận xác định nguồn gốc yêu cầu để theo dõi các yêu cầu nếu có bất kỳ điều gì bị bỏ sót.

Các hoạt động trong giai đoạn phát triển trường hợp thử nghiệm

Sau đây là ba hoạt động được thực hiện trong giai đoạn Phát triển trường hợp thử nghiệm:

Nhận dạng các tình huống thử nghiệm

Các kịch bản giúp dễ dàng kiểm tra và đánh giá một hệ thống phức tạp. Các chiến lược sau đây giúp tạo ra các tình huống tốt -

Liệt kê những người dùng có thể có, hành động và mục tiêu của họ.
Đánh giá người dùng với tư duy của hacker và liệt kê các trường hợp lạm dụng hệ thống có thể xảy ra.
Liệt kê các sự kiện hệ thống và cách hệ thống xử lý các yêu cầu đó.
Liệt kê các lợi ích và tạo các nhiệm vụ đầu cuối để kiểm tra chúng.
Đọc về các hệ thống tương tự và hành vi của chúng.
Nghiên cứu khiếu nại về sản phẩm của đối thủ cạnh tranh và sản phẩm tiền nhiệm của họ

Viết các trường hợp kiểm tra

Trường hợp thử nghiệm là một tài liệu, bao gồm dữ liệu thử nghiệm, điều kiện tiên quyết, kết quả mong đợi và điều kiện đăng bài, được phát triển cho một kịch bản thử nghiệm cụ thể nhằm xác minh sự tuân thủ theo một yêu cầu cụ thể.

Test Case đóng vai trò là điểm khởi đầu để thực thi test. Sau khi tập hợp các giá trị đầu vào được áp dụng; ứng dụng có kết quả cuối cùng và rời khỏi hệ thống tại một số điểm cuối còn được gọi là điều kiện đăng thực thi.

Chuẩn bị dữ liệu thử nghiệm

Dữ liệu thử nghiệm được sử dụng để thực hiện các thử nghiệm trên thiết bị thử nghiệm. Dữ liệu kiểm tra cần phải chính xác và đầy đủ để phát hiện ra các khiếm khuyết. Để đạt được ba mục tiêu này, cần tuân theo cách tiếp cận từng bước như được đưa ra dưới đây:

Xác định các tài nguyên hoặc yêu cầu kiểm tra
Xác định các điều kiện / chức năng cần kiểm tra
Đặt điều kiện kiểm tra ưu tiên
Chọn các điều kiện để kiểm tra
Xác định kết quả mong đợi của việc xử lý các ca kiểm thử
Tạo các trường hợp thử nghiệm
Điều kiện kiểm tra tài liệu
Tiến hành kiểm tra
Xác minh và sửa các trường hợp thử nghiệm dựa trên các sửa đổi

Sơ đồ khối hoạt động

Sơ đồ sau đây cho thấy các hoạt động khác nhau tạo thành một phần của Phát triển trường hợp thử nghiệm.

Môi trường Kiểm tra bao gồm các phần tử hỗ trợ thực thi kiểm tra với phần mềm, phần cứng và mạng được cấu hình. Cấu hình môi trường thử nghiệm phải bắt chước môi trường sản xuất để phát hiện ra bất kỳ vấn đề nào liên quan đến môi trường / cấu hình.

Các điểm sau đây cần được xem xét trong Thiết lập Môi trường Thử nghiệm.

Nó là sự kết hợp giữa môi trường phần cứng và phần mềm mà các bài kiểm tra sẽ được thực hiện.
Nó bao gồm cấu hình phần cứng, cài đặt hệ điều hành, cấu hình phần mềm, thiết bị đầu cuối kiểm tra và các hỗ trợ khác để thực hiện kiểm tra.
Đây là khía cạnh quan trọng nhất của quá trình thử nghiệm. Không có sẵn hoặc thiết lập môi trường bị lỗi có thể làm hỏng tất cả các nỗ lực thử nghiệm.
Trên thực tế, nhóm QA không thể bắt đầu công việc thực tế nếu không có môi trường thích hợp để kiểm tra.
Nó là và hoạt động độc lập và có thể được bắt đầu cùng với việc phát triển trường hợp thử nghiệm.
Nói chung, hoạt động này được thực hiện bởi các nhà phát triển trong các khía cạnh kỹ thuật trong khi các điều kiện yêu cầu có thể được thực hiện bởi Khách hàng / Nhà phân tích kinh doanh.
Tính sẵn sàng của môi trường thử nghiệm có thể được xác nhận bằng thử nghiệm khói và được thực hiện bởi nhóm QA.
Lý tưởng nhất, chúng ta có thể nói rằng Tiêu chí đầu vào của giai đoạn này là việc cung cấp Kế hoạch kiểm tra, sự sẵn sàng của các trường hợp Kiểm thử Smoke và chuẩn bị dữ liệu kiểm tra.
Tiêu chí thoát ra của giai đoạn này là môi trường thử nghiệm phải sẵn sàng và thử nghiệm khói phải được thực hiện thành công với kết quả mong đợi.

Các hoạt động được thực hiện để thiết lập môi trường thử nghiệm

Các hoạt động sau được thực hiện trong giai đoạn này.

Môi trường kiểm tra thiết kế

Các yếu tố sau đây đóng một vai trò quan trọng đối với việc thiết kế một môi trường thử nghiệm.

Xác định xem môi trường thử nghiệm có cần lưu trữ để sao lưu hay không.
Xác minh cấu hình mạng.
Xác định hệ điều hành máy chủ cần thiết, cơ sở dữ liệu và các thành phần khác.
Xác định số lượng giấy phép mà nhóm thử nghiệm yêu cầu.

Thiết lập Môi trường

Phân tích các yêu cầu thiết lập môi trường và chuẩn bị danh sách các yêu cầu phần mềm và phần cứng để thiết lập. Nhận xác nhận chính thức để thiết lập môi trường thử nghiệm và định cấu hình để truy cập môi trường thử nghiệm.

Kiểm tra khói

Sau khi môi trường được thiết lập và nhóm QA có quyền truy cập vào nó, một vòng kiểm tra khói nhanh chóng sẽ được thực hiện để xác nhận tính ổn định của môi trường thử nghiệm. Nếu kết quả đúng như mong đợi, nhóm QA có thể chuyển sang giai đoạn tiếp theo để chỉ ra sự khác biệt và chờ triển khai sau khi sửa chữa.

Thực thi kiểm tra là quá trình thực thi mã và so sánh kết quả mong đợi và thực tế. Các yếu tố sau cần được xem xét đối với quá trình thực thi kiểm tra:

Dựa trên rủi ro, hãy chọn một tập hợp con của bộ thử nghiệm sẽ được thực thi cho chu kỳ này.
Chỉ định các trường hợp thử nghiệm trong mỗi bộ thử nghiệm cho người thử nghiệm để thực thi.
Thực hiện kiểm tra, báo cáo lỗi và nắm bắt trạng thái kiểm tra liên tục.
Giải quyết các vấn đề chặn khi chúng phát sinh.
Báo cáo tình trạng, điều chỉnh các nhiệm vụ và xem xét lại các kế hoạch và ưu tiên hàng ngày.
Báo cáo các phát hiện và trạng thái chu kỳ thử nghiệm.

Các điểm sau đây cần được xem xét để Thực hiện Kiểm tra.

Trong giai đoạn này, nhóm QA thực hiện xác nhận thực tế của AUT dựa trên các trường hợp thử nghiệm đã chuẩn bị và so sánh kết quả từng bước với kết quả mong đợi.
Tiêu chí đầu vào của giai đoạn này là hoàn thành Kế hoạch thử nghiệm và giai đoạn Phát triển các trường hợp thử nghiệm, dữ liệu thử nghiệm cũng phải sẵn sàng.
Việc xác nhận thiết lập Môi trường thử nghiệm luôn được khuyến nghị thông qua thử nghiệm khói trước khi chính thức bắt đầu thực hiện thử nghiệm.
Các tiêu chí thoát yêu cầu xác nhận thành công tất cả các Trường hợp Kiểm thử; Các khiếm khuyết nên được đóng lại hoặc hoãn lại; việc thực hiện test case và báo cáo tóm tắt lỗi phải sẵn sàng.

Các hoạt động để thực thi kiểm tra

Mục tiêu của giai đoạn này là xác thực thời gian thực của AUT trước khi chuyển sang sản xuất / phát hành. Để bắt đầu từ giai đoạn này, nhóm QA thực hiện các loại thử nghiệm khác nhau để đảm bảo chất lượng của sản phẩm. Cùng với việc báo cáo khiếm khuyết này và kiểm tra lại cũng là hoạt động quan trọng trong giai đoạn này. Sau đây là các hoạt động quan trọng của giai đoạn này:

Kiểm tra tích hợp hệ thống

Việc xác nhận thực sự của sản phẩm / AUT bắt đầu ở đây. Kiểm thử tích hợp hệ thống (SIT) là một kỹ thuật kiểm tra hộp đen đánh giá sự tuân thủ của hệ thống đối với các yêu cầu cụ thể / trường hợp kiểm thử được chuẩn bị.

Kiểm thử tích hợp hệ thống thường được thực hiện trên tập hợp con của hệ thống. SIT có thể được thực hiện với việc sử dụng tối thiểu các công cụ kiểm tra, được xác minh cho các tương tác được trao đổi và hành vi của từng trường dữ liệu trong từng lớp riêng lẻ cũng được điều tra. Sau khi tích hợp, có ba trạng thái chính của luồng dữ liệu:

Trạng thái dữ liệu trong lớp tích hợp
Trạng thái dữ liệu trong lớp cơ sở dữ liệu
Trạng thái dữ liệu trong lớp Ứng dụng

Note- Trong thử nghiệm SIT, nhóm QA cố gắng tìm ra càng nhiều khuyết tật càng tốt để đảm bảo chất lượng. Mục tiêu chính ở đây là tìm ra lỗi càng nhiều càng tốt.

Báo cáo sai sót

Lỗi phần mềm phát sinh khi kết quả mong đợi không khớp với kết quả thực tế. Nó có thể là một lỗi, lỗ hổng, lỗi hoặc lỗi trong một chương trình máy tính. Hầu hết các lỗi phát sinh từ những sai lầm và lỗi do nhà phát triển hoặc kiến trúc sư thực hiện.

Trong khi thực hiện kiểm tra SIT, nhóm QA tìm thấy các loại lỗi này và chúng cần được báo cáo cho các thành viên nhóm liên quan. Các thành viên tiếp tục hành động và sửa chữa các khiếm khuyết. Một ưu điểm khác của báo cáo là nó giúp giảm bớt việc theo dõi tình trạng của các khuyết tật. Có nhiều công cụ phổ biến như ALM, QC, JIRA, Version One, Bugzilla hỗ trợ báo cáo và theo dõi lỗi.

Báo cáo Lỗi là một quá trình tìm kiếm các khiếm khuyết trong ứng dụng đang được thử nghiệm hoặc sản phẩm bằng cách thử nghiệm hoặc ghi lại phản hồi từ khách hàng và tạo ra các phiên bản mới của sản phẩm để sửa chữa các khiếm khuyết dựa trên phản hồi của khách hàng.

Theo dõi lỗi cũng là một quá trình quan trọng trong kỹ thuật phần mềm vì các hệ thống quan trọng và phức tạp trong kinh doanh có hàng trăm lỗi. Một trong những yếu tố thách thức nhất là quản lý, đánh giá và ưu tiên những khiếm khuyết này. Số lượng lỗi được nhân lên trong một khoảng thời gian và để quản lý chúng một cách hiệu quả, hệ thống theo dõi lỗi được sử dụng để giúp công việc dễ dàng hơn.

Bản đồ khiếm khuyết

Sau khi lỗi được báo cáo và ghi lại, nó phải được ánh xạ với các trường hợp thử nghiệm bị lỗi / bị chặn có liên quan và các yêu cầu tương ứng trong Ma trận xác định nguồn gốc yêu cầu. Việc lập bản đồ này được thực hiện bởi Defect Reporter. Nó giúp đưa ra một báo cáo khuyết tật thích hợp và phân tích độ bẩn trong sản phẩm. Khi các trường hợp thử nghiệm và các yêu cầu được lập bản đồ với khiếm khuyết, các bên liên quan có thể phân tích và đưa ra quyết định về việc có sửa chữa / trì hoãn lỗi dựa trên mức độ ưu tiên và mức độ nghiêm trọng hay không.

Kiểm tra lại

Kiểm tra lại đang thực hiện kiểm tra không thành công trước đó đối với AUT để kiểm tra xem sự cố đã được giải quyết chưa. Sau khi một lỗi đã được khắc phục, việc kiểm tra lại được thực hiện để kiểm tra kịch bản trong cùng điều kiện môi trường.

Trong quá trình kiểm tra lại, người kiểm tra tìm kiếm các chi tiết cụ thể tại khu vực chức năng đã thay đổi, trong khi kiểm tra hồi quy bao gồm tất cả các chức năng chính để đảm bảo rằng không có chức năng nào bị hỏng do thay đổi này.

Kiểm tra hồi quy

Một khi tất cả các lỗi đều ở trạng thái đóng, hoãn hoặc bị từ chối và không có trường hợp kiểm thử nào đang ở trạng thái tiến hành / không thành công / không chạy, có thể nói rằng kiểm thử tích hợp hệ thống hoàn toàn dựa trên các trường hợp kiểm thử và yêu cầu. Tuy nhiên, cần một vòng kiểm tra nhanh để đảm bảo rằng không có chức năng nào bị hỏng do thay đổi mã / sửa lỗi.

Kiểm thử hồi quy là một kỹ thuật kiểm thử hộp đen bao gồm việc thực hiện lại những kiểm thử đã có tác động do thay đổi mã. Các thử nghiệm này nên được thực hiện thường xuyên nhất có thể trong suốt vòng đời phát triển phần mềm.

Các loại kiểm tra hồi quy

Final Regression Tests- Một "kiểm tra hồi quy cuối cùng" được thực hiện để xác nhận bản dựng không trải qua thay đổi trong một khoảng thời gian. Bản dựng này được triển khai hoặc vận chuyển cho khách hàng.
Regression Tests - Kiểm tra hồi quy thông thường được thực hiện để xác minh xem bản dựng KHÔNG phá vỡ bất kỳ phần nào khác của ứng dụng bằng các thay đổi mã gần đây để sửa lỗi hoặc để nâng cao.

Sơ đồ khối hoạt động

Sơ đồ khối sau đây cho thấy các hoạt động quan trọng được thực hiện trong giai đoạn này; nó cũng cho thấy sự phụ thuộc từ các giai đoạn trước -

Vòng đời khiếm khuyết, còn được gọi là Vòng đời lỗi, là hành trình của một khiếm khuyết, chu kỳ mà một khiếm khuyết trải qua trong suốt thời gian tồn tại của nó. Nó khác nhau giữa các tổ chức và cũng từ dự án này sang dự án khác, vì nó được điều chỉnh bởi quy trình kiểm thử phần mềm và cũng phụ thuộc vào các công cụ được sử dụng.

Vòng đời khiếm khuyết - Quy trình làm việc

Sơ đồ sau đây cho thấy quy trình làm việc của Vòng đời khiếm khuyết.

Các trạng thái của một vòng đời khiếm khuyết

Sau đây là các trạng thái khác nhau của Vòng đời khiếm khuyết.

New - Khuyết tật tiềm ẩn được nêu ra và chưa được xác nhận.
Assigned - Được chỉ định chống lại một nhóm phát triển cần giải quyết.
Active- Lỗi đang được nhà phát triển giải quyết và đang tiến hành điều tra. Ở giai đoạn này, có hai kết quả có thể xảy ra - Bị hoãn hoặc Bị từ chối.
Test / Fixed / Ready for Retest - Lỗi đã được sửa và sẵn sàng để kiểm tra.
Verified - Các khiếm khuyết được kiểm tra lại và kiểm tra đã được xác nhận bởi QA.
Closed - Trạng thái cuối cùng của khiếm khuyết có thể được đóng lại sau khi QA kiểm tra lại hoặc có thể được đóng lại nếu khiếm khuyết trùng lặp hoặc được coi là KHÔNG phải khiếm khuyết.
Reopened - Khi lỗi KHÔNG được sửa, QA mở lại / kích hoạt lại lỗi.
Deferred - Khi một khiếm khuyết không thể được khắc phục trong chu kỳ cụ thể đó, nó được hoãn lại để phát hành trong tương lai.
Rejected - Một khiếm khuyết có thể bị từ chối vì bất kỳ lý do nào trong ba lý do - khiếm khuyết trùng lặp, KHÔNG PHẢI là khiếm khuyết, Không thể tái tạo.

Các khiếm khuyết được phân loại từ góc độ nhóm QA như Priority và từ quan điểm phát triển như Severity(độ phức tạp của mã để sửa chữa nó). Đây là hai cách phân loại chính đóng vai trò quan trọng trong khung thời gian và khối lượng công việc cần thực hiện để sửa chữa các khiếm khuyết.

Ưu tiên là gì?

Mức độ ưu tiên được định nghĩa là thứ tự các khiếm khuyết cần được giải quyết. Trạng thái ưu tiên thường được đặt bởi nhóm QA trong khi nâng cao lỗi với nhóm phát triển đề cập đến khung thời gian để sửa lỗi. Trạng thái Ưu tiên được đặt dựa trên yêu cầu của người dùng cuối.

Ví dụ: nếu logo của công ty được đặt không chính xác trong trang web của công ty thì mức độ ưu tiên cao nhưng nó có mức độ nghiêm trọng thấp.

Danh sách ưu tiên

Mức độ ưu tiên có thể được phân loại theo những cách sau:

Low - Những khiếm khuyết này có thể được sửa chữa sau khi những khuyết tật quan trọng được khắc phục.
Medium - Các khiếm khuyết cần được khắc phục trong các lần xây dựng tiếp theo.
High - Lỗi phải được khắc phục ngay lập tức vì lỗi ảnh hưởng đến ứng dụng ở một mức độ đáng kể và các mô-đun liên quan không thể được sử dụng cho đến khi nó được sửa.
Urgent - Lỗi phải được khắc phục ngay lập tức vì lỗi ảnh hưởng nghiêm trọng đến ứng dụng hoặc sản phẩm và không thể sử dụng sản phẩm cho đến khi nó đã được khắc phục.

Mức độ nghiêm trọng là gì?

Mức độ nghiêm trọng được định nghĩa là mức độ thiếu sót của lỗi trong ứng dụng và độ phức tạp của mã để sửa chữa nó từ quan điểm phát triển. Itcó liên quan đến khía cạnh phát triển của sản phẩm. Mức độ nghiêm trọng có thể được quyết định dựa trên mức độ xấu / nghiêm trọng của lỗi đối với hệ thống. Tình trạng mức độ nghiêm trọng có thể đưa ra ý tưởng về sự sai lệch trong chức năng do lỗi.

Example - Đối với trang web điều hành chuyến bay, lỗi trong việc tạo số vé so với đặt chỗ là mức độ nghiêm trọng và mức độ ưu tiên cao.

Danh sách mức độ nghiêm trọng

Mức độ nghiêm trọng có thể được phân loại theo những cách sau:

Critical /Severity 1- Lỗi ảnh hưởng đến hầu hết các chức năng quan trọng của Ứng dụng và nhóm QA không thể tiếp tục xác nhận ứng dụng đang được kiểm tra mà không sửa chữa nó. Ví dụ: Ứng dụng / Sản phẩm thường xuyên bị lỗi.
Major / Severity 2- Khiếm khuyết ảnh hưởng đến một mô-đun chức năng; nhóm QA không thể kiểm tra mô-đun cụ thể đó nhưng tiếp tục xác nhận các mô-đun khác. Ví dụ: đặt chỗ chuyến bay không hoạt động.
Medium / Severity 3- Lỗi có vấn đề với một màn hình hoặc liên quan đến một chức năng duy nhất, nhưng hệ thống vẫn hoạt động. Các khiếm khuyết ở đây không chặn bất kỳ chức năng nào. Ví dụ: Vé # là một đại diện không tuân theo các ký tự số chữ cái thích hợp như năm ký tự đầu tiên và năm ký tự cuối cùng là số.
Low / Severity 4- Nó không ảnh hưởng đến chức năng. Nó có thể là một khiếm khuyết thẩm mỹ, sự không nhất quán của giao diện người dùng cho một trường hoặc một đề xuất để cải thiện trải nghiệm người dùng cuối từ phía giao diện người dùng. Ví dụ: màu nền của nút Gửi không khớp với màu nền của nút Lưu.

Việc kiểm tra các tiêu chí thoát thử nghiệm là rất cần thiết để xác nhận rằng thử nghiệm đã hoàn tất. Trước khi kết thúc quá trình thử nghiệm, chất lượng sản phẩm được đo lường dựa trên các tiêu chí hoàn thành thử nghiệm.

Tiêu chí đầu vào của giai đoạn này là việc thực hiện test case đã hoàn tất, có kết quả kiểm tra và báo cáo lỗi đã sẵn sàng.

Tiêu chí để hoàn thành bài kiểm tra bao gồm:

Đã đạt được phạm vi bảo hiểm cụ thể.
Không showstoppers hoặc khuyết tật nghiêm trọng
Có rất ít khuyết tật được biết đến ở mức độ ưu tiên trung bình hoặc thấp. Những điều này không ảnh hưởng đến việc sử dụng sản phẩm.

Tiêu chí thoát của giai đoạn này là việc cung cấp các báo cáo kết thúc thử nghiệm và chuẩn bị các ma trận mà sau đó khách hàng sẽ ký.

Bây giờ chúng ta hãy thảo luận về activities involved in the closure of Test Cycle.

Báo cáo hoàn thành kiểm tra

Báo cáo hoàn thành thử nghiệm là một quá trình, theo đó các chỉ số thử nghiệm được báo cáo ở định dạng tóm tắt để cập nhật cho các bên liên quan. Điều này cho phép họ đưa ra quyết định sáng suốt.

Báo cáo Hoàn thành Kiểm tra chứa các thông tin sau.

Mã định danh báo cáo tóm tắt kiểm tra
Summary
Variances
Kết quả tóm tắt
Evaluation
Có kế hoạch so với Nỗ lực thực tế
Đăng xuất

Một Báo cáo Hoàn thành Thử nghiệm tốt chỉ ra chất lượng, đo lường các rủi ro tồn tại và xác định mức độ của một phần mềm được thử nghiệm.

Ma trận hoàn thành kiểm tra

Sau khi hoàn thành thử nghiệm, các ma trận khác nhau được thu thập để chuẩn bị báo cáo thử nghiệm. Các tiêu chí để chuẩn bị các báo cáo bao gồm:

Số lượng thử nghiệm đã thực hiện
Số bài kiểm tra đã vượt qua
Số lần kiểm tra không thành công
Số lần kiểm tra không thành công dựa trên mỗi mô-đun
Số lỗi kiểm tra tăng lên trong chu kỳ thực hiện
Số lỗi kiểm tra được chấp nhận
Số lỗi kiểm tra bị từ chối
Số lỗi kiểm tra bị hoãn lại
Tình trạng khuyết tật hoạt động
Tính chỉ số chất lượng của công trình

Kết quả kiểm tra

Trong khi thực hiện một trường hợp kiểm thử, kiểm tra lại các lỗi và thực hiện trường hợp kiểm thử hồi quy, Test results articulate nên được lưu và có thể được tạo ra cùng với các tài liệu kết thúc chu trình thử nghiệm để hỗ trợ việc hoàn thành việc thực thi thử nghiệm.

Các khớp nối có thể là ảnh chụp màn hình, kết quả truy vấn cơ sở dữ liệu, bản ghi, tệp nhật ký, v.v.