Tiêu chuẩn quốc gia TCVN 12849-1:2020 (ISO/IEC/IEEE 29119-1:2013) về Kỹ thuật hệ thống và phần mềm - Kiểm thử phần mềm - Phần 1: Khái niệm và định nghĩa
ISO/IEC/IEEE 29119-1:2013
KỸ THUẬT HỆ THỐNG VÀ PHẦN MỀM - KIỂM THỬ PHẦN MỀM - PHẦN 1: KHÁI NIỆM VÀ ĐỊNH NGHĨA
Software and systems engineering - Software testing Part 1: Concepts and definitions
Lời nói đầu
TCVN 12849-1:2020 hoàn toàn tương đương ISO/IEC 29119-1:2013 Software and systems engineering - Software testing - Part 1: Concepts and definitions.
TCVN 12849-1:2020 do Viện Khoa học Kỹ thuật Bưu điện - Học viện Công nghệ Bưu chính viễn thông biên soạn, Bộ Thông tin và Truyền thông đề nghị, Tổng cục Tiêu chuẩn Đo lường chất lượng thẩm định, Bộ Khoa học và Công nghệ công bố.
Lời giới thiệu
Mục đích của bộ tiêu chuẩn kiểm thử phần mềm TCVN 12849 nhằm xác định một tập hợp các tiêu chuẩn quốc tế thống nhất về thử nghiệm phần mềm có thể được sử dụng bởi các tổ chức khi thực hiện bất kỳ hình thức kiểm thử phần mềm nào.
Phải thừa nhận rằng có rất nhiều loại phần mềm, tổ chức phần mềm và phương pháp luận khác nhau. Các loại phần mềm gồm phần mềm công nghệ thông tin (IT), phần mềm máy tính cá nhân (PC), phần mềm nhúng, phần mềm cho thiết bị di động, phần mềm khoa học và nhiều loại phần mềm khác. Các tổ chức phần mềm có phạm vi từ nhỏ đến lớn, từ địa phương đến đa quốc gia và từ thương mại đến hướng dịch vụ công. Phương pháp luận phần mềm bao gồm hướng đối tượng, truyền thống, điều khiển và xử lý linh hoạt dữ liệu. Những điều này và các yếu tố khác sẽ ảnh hưởng tới việc kiểm thử phần mềm. Bộ tiêu chuẩn quốc gia TCVN 12849 có thể hỗ trợ việc kiểm thử trong nhiều bối cảnh khác nhau.
Tiêu chuẩn này là nền tảng cho việc sử dụng các tiêu chuẩn kiểm thử phần mềm TCVN 12849 (ISO/IEC/IEEE 29119) khác bằng cách định nghĩa từ vựng và cung cấp các ví dụ về ứng dụng của chúng trong thực tế. Phần này cung cấp thông tin về định nghĩa, mô tả các khái niệm về kiểm thử phần mềm, cách thức áp dụng quy trình kiểm thử phần mềm và hướng dẫn cho các phần khác.
Ban đầu trình bày các khái niệm chung về kiểm thử phần mềm, vai trò của kiểm thử phần mềm trong bối cảnh tổ chức và dự án. Giải thích việc kiểm thử phần mềm trong một vòng đời phần mềm chung, giới thiệu các quy trình kiểm thử phần mềm và quy trình con có thể được thiết lập cho các hạng mục kiểm thử cụ thể hoặc các mục tiêu kiểm thử cụ thể, mô tả cách kiểm thử phần mềm phù hợp với các mô hình vòng đời khác nhau. Chứng minh việc sử dụng các thực tiễn khác nhau trong việc lập kế hoạch kiểm thử cũng như cách thức tự động hóa có thể được sử dụng để hỗ trợ kiểm thử và đề cập tới việc tham gia của kiểm thử trong quản lý khiếm khuyết.
Phụ lục A mô tả vai trò của kiểm thử trong phạm vi của việc xác minh và xác nhận. Phụ lục B cung cấp giới thiệu xúc tích về các thước đo được sử dụng để giám sát và kiểm soát kiểm thử. Phụ lục C bao gồm một tập hợp các ví dụ mô tả cách thức áp dụng tiêu chuẩn trong các mô hình vòng đời khác nhau. Phụ lục D cung cấp các ví dụ về quy trình kiểm thử con chi tiết. Phụ lục E cung cấp thông tin bổ sung về các vai trò và trách nhiệm thường gặp trong các nhóm kiểm thử và người kiểm thử độc lập và cuối cùng là tài liệu tham khảo.
Lưu ý rằng trường hợp chữ in hoa được sử dụng thông suốt trong tiêu chuẩn này để biểu thị các quy trình và tài liệu được quy định trong tiêu chuẩn TCVN 12849-2:2020 (ISO/IEC/IEEE 29119-2:2013) và TCVN 12849-3:2020 (ISO/lEC/IEEE 29119-3:2013) (ví dụ: Quy trình lập kế hoạch kiểm thử, Kế hoạch kiểm thử ), trong khi các chữ in thường được sử dụng cho các tài liệu hình thành các phần của các tài liệu khác (ví dụ: chiến lược kiểm thử dự án là một phần tử của kế hoạch kiểm thử dự án).
Mô hình quy trình kiểm thử được xác định chi tiết trong tiêu chuẩn TCVN 12849-2:2020 (ISO/IEC/IEEE 29119-2:2013) “Kỹ thuật hệ thống và Phần mềm - Kiểm thử phần mềm - Phần 2: Quy trình kiểm thử”. Tiêu chuẩn TCVN 12849-2:2020 (ISO/IEC/IEEE 29119-2:2013) bao gồm các quy trình kiểm thử phần mềm tại các cấp độ tổ chức, cấp độ quản lý kiểm thử và cấp độ kiểm thử động. Kiểm thử là phương pháp chính để xử lý rủi ro trong phát triển phần mềm. Tiêu chuẩn này định nghĩa một phương pháp tiếp cận dựa trên rủi ro để kiểm thử. Kiểm thử dựa trên rủi ro là một phương pháp được khuyến khích để vạch ra chiến lược và quản lý kiểm thử, cho phép kiểm thử phải được ưu tiên và tập trung.
Các mẫu và ví dụ về tài liệu kiểm thử được xây dựng trong quá trình kiểm thử được định nghĩa trong tiêu chuẩn TCVN 12849-3:2020 (ISO/IEC/IEEE 29119-3:2013) “Kỹ thuật hệ thống và Phần mềm - Kiểm thử phần mềm - Phần 3: Tài liệu kiểm thử”. Các kỹ thuật kiểm thử phần mềm có thể được sử dụng trong quá trình kiểm thử được định nghĩa trong tiêu chuẩn TCVN 12849-4:2020 (ISO/IEC/IEEE 29119- 4:2015) “Kỹ thuật hệ thống và Phần mềm - Kiểm thử phần mềm - Phần 4: Kỹ thuật kiểm thử”.
Bộ tiêu chuẩn này cung cấp cho các bên liên quan khả năng để quản lý và thực hiện kiểm thử phần mềm trong bất kỳ tổ chức nào.
KỸ THUẬT HỆ THỐNG VÀ PHẦN MỀM - KIỂM THỬ PHẦN MỀM - PHẦN 1: KHÁI NIỆM VÀ ĐỊNH NGHĨA
Software and systems engineering - Software testing Part 1: Concepts and definitions
Tiêu chuẩn này quy định các định nghĩa và khái niệm về kiểm thử phần mềm và đưa ra các khái niệm quan trọng để hiểu bộ tiêu chuẩn về kiểm thử phần mềm TCVN 12849 (ISO/IEC/IEEE 29119).
Tiêu chuẩn TCVN 12849-1:2020 (ISO/IEC/IEEE 29119-1:2013) là tham khảo và không yêu cầu tuân thủ.
Bộ tiêu chuẩn kiểm thử phần mềm TCVN 12849 (ISO/IEC/IEEE 29119) gồm ba tiêu chuẩn yêu cầu tuân thủ, bao gồm:
- TCVN 12849-2:2020 (ISO/IEC/IEEE 29119-2:2013) “Kỹ thuật hệ thống và Phần mềm - Kiểm thử phần mềm - Phần 2: Quy trình kiểm thử”;
- TCVN 12849-3:2020 (ISO/IEC/IEEE 29119-3:2013) “Kỹ thuật hệ thống và Phần mềm - Kiểm thử phần mềm - Phần 3: Tài liệu kiểm thử”;
- TCVN 12849-4:2020 (ISO/IEC/IEEE 29119-4:2015) “Kỹ thuật hệ thống và Phần mềm - Kiểm thử phần mềm - Phần 4: Kỹ thuật kiểm thử”;
Sự tuân thủ khi áp dụng tiêu chuẩn được đề cập chi tiết trong TCVN 12849-2:2020 (ISO/IEC/IEEE 29.119-2:2013), TCVN 12849-3:2020 (ISO/IEC/IEEE 29119-3:2013) và TCVN 12849-4:2020 (ISO/IEC/IEEE 29119-4:2015).
Các tài liệu viện dẫn dưới đây là cần thiết để áp dụng tiêu chuẩn này. Đối với các tài liệu viện dẫn ghi năm công bố thì áp dụng bản được nêu. Đối với các tài liệu viện dẫn không ghi năm công bố thì áp dụng phiên bản mới nhất, bao gồm cả các sửa đổi, bổ sung (nếu có).
ISO/IEC/IEEE 24765:2017 Systems and software engineering - Vocabulary (Kỹ thuật phần mềm và hệ thống -Từ vựng)
Các thuật ngữ và định nghĩa được đưa ra trong tiêu chuẩn ISO/IEC/IEEE 24765 và các thuật ngữ sau được áp dụng cho mục đích của tiêu chuẩn này.
CHÚ THÍCH: Các thuật ngữ và định nghĩa sau đây được cung cấp để hỗ trợ nền tảng kiến thức và khả năng đọc hiểu các phần 1, 2, 3, 4 và 5 của bộ tiêu chuẩn kiểm thử phần mềm (TCVN 12849 (ISO/IEC/IEEE 29119)) vì vậy một số thuật ngữ quy định trong tiêu chuẩn này sẽ không được sử dụng trong tiêu chuẩn này mà sẽ chỉ được sử dụng trong các phần khác của bộ tiêu chuẩn TCVN 12849 (ISO/1EC/IEEE 29119). Mục này không dự định cung cấp một danh sách đầy đủ các thuật ngữ kiểm thử mà chỉ là các thuật ngữ quan trọng cho sự thông hiểu về bộ tiêu chuẩn TCVN 12849 (ISO/IEC/IEEE 29119). Các thuật ngữ không có trong mục này cần được tham chiếu với tiêu chuẩn ISO/IEC/IEEE 24765 “Từ vựng hệ thống và kỹ thuật phần mềm”. Nguồn này có tại trang web sau đây: http://www.computer.org/sevocab.
4.1
Kiểm thử khả năng truy nhập (accessibility testing)
Loại kiểm thử khả năng được sử dụng để đánh giá mức độ mà một hạng mục kiểm thử có thể được vận hành bởi người dùng với phạm vi rộng nhất có thể của đặc điểm và khả năng.
4.2
Kết quả thực tế (actual results)
Tập các thuộc tính hoặc điều kiện của một hạng mục kiểm thử hoặc tập các điều kiện dữ liệu liên quan hoặc môi trường kiểm thử được coi là kết quả của việc thực hiện kiểm thử.
Ví dụ: Đầu ra màn hình, đầu ra phần cứng, các thay đổi dữ liệu, báo cáo và các bản tin thông báo đã được gửi đi.
4.3
Kiểm thử sao lưu và phục hồi (backup and recovery testing)
Loại kiểm thử độ tin cậy để đánh giá mức độ mà trạng thái hệ thống có thể được khôi phục lại từ bản sao lưu với các thông số được quy định về thời gian, chi phí, tính đầy đủ và chính xác trong trường hợp thất bại.
4.4
Kiểm thử kiểu hộp đen (black-box testing)
Xem kiểm thử dựa trên đặc tả (4.39)
4.5
Kiểm thử khả năng (capacity testing)
Loại kiểm thử hiệu quả hiệu năng được tiến hành để đánh giá mức độ mà tại đó gia tăng tải (của người dùng, tương tác, lưu trữ dữ liệu, vv) lên khả năng của một hạng mục kiểm thử nhằm duy trì hoạt động theo yêu cầu
4.6
Kiểm thử khả năng tương thích (compatibility testing)
Loại kiểm thử để đánh giá mức độ mà một hạng mục kiểm thử có thể hoạt động một cách thỏa đáng cùng với các sản phẩm độc lập khác trong một môi trường chia sẻ (cùng tồn tại) và nếu cần thiết, trao đổi thông tin với các hệ thống hoặc thành phần khác (khả năng tương tác)
4.7
Hạng mục độ bao phủ (coverage item)
Xem mục Hạng mục độ bao phủ kiểm thử (4.54)
4.8
Quyết định (decision)
Các loại tuyên bố, trong đó việc sự lựa chọn giữa hai hoặc nhiều hơn các kết quả kiểm soát có thể có sẽ dẫn đến việc thiết lập các hành động.
CHÚ THÍCH: Quyết định điển hình là lựa chọn đơn giản (ví dụ như nếu-thì-khác), để quyết định khi nào để thoát khỏi vòng lặp (ví dụ như trong khi lặp), và trong trường hợp (thay đổi) tuyên bố (ví dụ như trường hợp-1-2-3-. ,-N).
4.9
Kiểm thử động (dynamic testing)
Kiểm thử yêu cầu việc thực hiện các hạng mục kiểm thử.
4.10
Kiểm thử độ bền lâu (endurance testing)
Loại kiểm thử hiệu quả hiệu năng được tiến hành để đánh giá xem một hạng mục kiểm thử có thể duy trì tải theo yêu cầu liên tục trong một thời gian cụ thể.
4.11
Phân vùng tương đương (equivalence partition)
Tập con các giá trị của một biến hoặc tập các biến trong một hạng mục kiểm thử hoặc tại giao diện của nó, vì vậy tất cả các giá trị trong phân vùng hợp lý sẽ được xử lý tương tự bởi hạng mục kiểm thử (tức là chúng có thể được coi là "tương đương ").
4.12
Độ bao phủ phân vùng tương đương (equivalence partition coverage)
Tỷ lệ phân vùng tương đương xác định của một hạng mục kiểm thử được bao phủ bởi một bộ kiểm thử.
CHÚ THÍCH: Trong nhiều trường hợp, việc xác định các phân vùng tương đương là chủ quan (đặc biệt là trong các phân vùng con của phân vùng "không hợp lệ"), do đó, việc xác định số lượng các phân vùng tương đương trong một hạng mục kiểm thử không thể thực hiện được.
4.13
Kỹ thuật phân vùng tương đương (equivalence partitioning)
Kỹ thuật thiết kế kiểm thử, trong đó ca kiểm thử được thiết kế để thực hiện các phân vùng tương đương bằng cách sử dụng một hoặc nhiều thành viên đại diện của từng phân vùng.
4.14
Phỏng đoán lỗi (error guessing)
Kỹ thuật thiết kế kiểm thử, trong đó ca kiểm thử được hình thành trên cơ sở kiến thức của người kiểm thử về những thất bại trong quá khứ hoặc kiến thức chung về cách thức thất bại.
CHÚ THÍCH: Các kiến thức có liên quan có thể thu được từ kinh nghiệm cá nhân, hoặc có thể được gói gọn trong, ví dụ, một cơ sở dữ liệu các khiếm khuyết hoặc "Phân loại lỗi".
4.15
Kết quả mong đợi (expected results)
Hành vi dự đoán quan sát được của hạng mục kiểm thử theo các điều kiện cụ thể dựa trên đặc tả của nó hoặc các nguồn khác.
4.16
Kiểm thử thăm dò (exploratory testing)
Loại kiểm thử dựa trên kinh nghiệm phi kịch bản, trong đó người kiểm thứ tự thiết kế và thực hiện các kiểm thử dựa trên các kiến thức hiểu biết của mình, thăm dò trước hạng mục kiểm thử (bao gồm các kết quả kiểm thử trước đây) và phỏng đoán theo "quy tắc ngón tay cái" về các cơ chế phần mềm phổ biến và các loại thất bại.
CHÚ THÍCH: Kiểm thử thăm dò tìm kiếm cho các thuộc tính ẩn (bao gồm cả các cơ chế ẩn), mà có thể tác động tới các thuộc tính khác của phần mềm đang được kiểm thử, và do đó tạo ra rủi ro rằng phần mềm sẽ thất bại.
4.17
Tập tính năng (feature set)
Thu thập các hạng mục chứa các điều kiện kiểm thử của hạng mục kiểm thử được kiểm thử có thể được thu thập từ các rủi ro, các yêu cầu, chức năng, mô hình, vv
CHÚ THÍCH: Điều này có thể là một tập tất cả các tính năng cho hạng mục (tập tính năng đầy đủ của nó), hoặc một tập con xác định cho một mục đích cụ thể (tập tính năng chức năng vv).
4.18
Báo cáo sự cố (Incident Report)
Tài liệu hướng dẫn về việc xảy ra, bản chất và các trạng thái của một sự cố.
4.19
Kiểm thử khả năng cài đặt (installability testing)
Loại kiểm thử tính linh hoạt được thực hiện để đánh giá xem một hạng mục kiểm thử hoặc tập các hạng mục kiểm thử có thể được cài đặt theo yêu cầu trong tất cả các môi trường quy định.
4.20
Kiểm thử tải (load testing)
Loại kiểm thử hiệu quả hiệu năng được thực hiện để đánh giá cơ chế của một hạng mục kiểm thử theo các điều kiện dự kiến tải khác nhau, thường là giữa các điều kiện được dự kiến của việc sử dụng thấp, trung bình và đỉnh.
4.21
Kiểm thử khả năng bảo trì (maintainability testing)
Loại kiểm thử được thực hiện để đánh giá mức độ khả năng và hiệu quả mà một hạng mục kiểm thử có thể được sửa đổi.
4.22
Chính sách kiểm thử của tổ chức (Organizational Test Policy)
Tài liệu phân cấp thực hiện mô tả mục đích, mục tiêu và phạm vi tổng thể của các kiểm thử trong một tổ chức và diễn giải tại sao kiểm thử được thực hiện và những gì dự kiến sẽ đạt được.
CHÚ THÍCH: Để thích hợp hơn, thường duy trì chính sách kiểm thử có tổ chức càng ngắn càng tốt trong một bối cảnh cụ thể.
4.23
Quy trình kiểm thử của tổ chức (Organizational Test Process)
Quy trình kiểm thử để phát triển và quản lý đặc tả kiểm thử của tổ chức.
4.24
Đặc tả kiểm thử của tổ chức (organizational test specification)
Tài liệu cung cấp thông tin về kiểm thử cho một tổ chức, tức là thông tin đó không phải là dự án cụ thể.
VÍ DỤ: Các ví dụ phổ biến nhất của các đặc tả kiểm thử có tổ chức là chính sách kiểm thử có tổ chức và chiến lược kiểm thử có tổ chức.
4.25
Chiến lược kiểm thử của tổ chức (Organizational Test strategy)
Tài liệu thể hiện các yêu cầu chung cho các kiểm thử được thực hiện trên tất cả các dự án thực hiện trong tổ chức, cung cấp chi tiết về cách thức kiểm thử sẽ được thực hiện.
CHÚ THÍCH 1: Chiến lược kiểm thử có tổ chức phù hợp với chính sách kiểm thử có tổ chức.
CHÚ THÍCH 2: Một tổ chức có thể có nhiều hơn một chiến lược kiểm thử có tổ chức để bao phủ các bối cảnh dự án khác nhau một cách rõ ràng.
4.26
Tiêu chí đạt/không đạt (pass/fall criteria)
Nguyên tắc quyết định được sử dụng để xác định xem một hạng mục kiểm thử hoặc tính năng của một hạng mục kiểm thử đã đạt hay không đạt sau khi kiểm thử.
4.27
Kiểm thử hiệu năng (performance testing)
Loại kiểm thử được thực hiện để đánh giá mức độ mà một hạng mục kiểm thử hoàn thành các chức năng được chỉ định trong các ràng buộc cho trước về thời gian và các nguồn lực khác.
4.28
Kiểm thử tính khả chuyển (portability testing)
Loại kiểm thử được thực hiện để đánh giá một hạng mục kiểm thử có thể được chuyển từ một môi trường phần mềm hoặc phần cứng sang môi trường khác một cách dễ dàng, bao gồm cả mức độ sửa đổi cần thiết để thực hiện trong nhiều loại môi trường khác nhau.
4.29
Kiểm thử thủ tục (procedure testing)
Loại kiểm thử sự phù hợp chức năng được tiến hành để đánh giá liệu hướng dẫn thủ tục để tương tác với một hạng mục kiểm thử hoặc sử dụng kết quả đầu ra của nó đáp ứng các yêu cầu người sử dụng và hỗ trợ các mục đích sử dụng của họ.
4.30
Rủi ro sản phẩm (product risk)
Rủi ro mà một sản phẩm có thể bị lỗi trong một số khía cạnh cụ thể về chức năng, chất lượng hoặc cấu trúc của nó.
4.31
Rủi ro dự án (project risk)
Rủi ro liên quan đến việc quản lý một dự án.
VÍ DỤ: Thiếu nhân lực, thời hạn nghiêm ngặt, thay đổi các yêu cầu.
4.32
Kiểm thử hồi quy (regression testing)
Kiểm thử sau khi có sửa đổi về hạng mục kiểm thử hoặc môi trường vận hành để xác định xem liệu có xảy ra các thất bại hồi quy không.
CHÚ THÍCH: Tính đầy đủ của một tập các ca kiểm thử hồi quy phụ thuộc vào các hạng mục cần kiểm thử và các sửa đổi đối với hạng mục đó hoặc môi trường vận hành của nó.
4.33
Kiểm thử độ tin cậy (reliability testing)
Loại kiểm thử được tiến hành để đánh giá khả năng của một hạng mục kiểm thử để thực hiện các chức năng cần thiết của nó, bao gồm cả việc đánh giá tần suất mà thất bại xảy ra, khi được sử dụng trong các điều kiện quy định với một chu kỳ thời gian cụ thể.
4.34
Kiểm thử lại (retesting)
Thực hiện lại các ca kiểm thử mà trước đó có kết quả là "không đạt", để đánh giá hiệu quả của các hành động khắc phục.
CHÚ THÍCH: Còn được gọi là kiểm thử xác thực.
4.35
Kiểm thử dựa trên rủi ro (risk-based testing)
Kiểm thử trong đó việc quản lý, lựa chọn, ưu tiên và sử dụng các nguồn lực và hoạt động kiểm thử dựa trên cơ sở các loại và mức của rủi ro được phân tích tương ứng.
4.36
Kiểm thử kịch bản (scenario testing)
Lớp kỹ thuật thiết kế kiểm thử, trong đó kiểm thử được thiết kế để thực hiện kịch bản riêng.
CHÚ THÍCH: Một kịch bản có thể là một câu chuyện người sử dụng, trường hợp sử dụng, khái niệm vận hành hoặc một chuỗi các sự kiện của phần mềm có thể gặp phải, vv.
4.37
Kiểm thử bản thảo (scripted testing)
Kiểm thử động, trong đó các hành động của người kiểm thử được quy định theo hướng dẫn bằng văn bản trong một ca kiểm thử.
CHÚ THÍCH: Thuật ngữ này thường được áp dụng để tự thực hiện kiểm thử, chứ không phải là việc thực hiện một kịch bản tự động.
4.38
Kiểm thử an toàn (security testing)
Loại kiểm thử được tiến hành để đánh giá mức độ mà một hạng mục kiểm thử, thông tin và dữ liệu có liên quan được bảo vệ để các hệ thống hoặc những người không có ủy quyền không thể sử dụng, đọc hoặc sửa đổi và chỉ các hệ thống hoặc những người có ủy quyền được phép truy cập chúng.
4.39
Kiểm thử dựa trên đặc tả (specification-based testing)
Kiểm thử, trong đó cơ sở kiểm thử chính là các yếu tố đầu vào và đầu ra bên ngoài của hạng mục kiểm thử, thường dựa trên đặc tả chứ không phải là thực hiện nó trong mã nguồn hoặc phần mềm thực thi.
CHÚ THÍCH: Từ đồng nghĩa với kiểm thử dựa trên đặc tả bao gồm kiểm thử hộp đen và kiểm thử hộp kín.
4.40
Độ bao phủ câu lệnh (statement coverage)
Tỷ lệ phần trăm của tập tất cả các tuyên bố thực thi của một hạng mục kiểm thử được bao phủ bởi bộ kiểm thử.
4.41
Kiểm thử câu lệnh (statement testing)
Kỹ thuật thiết kế kiểm thử, trong đó các ca kiểm thử được xây dựng để thực thi các câu lệnh riêng trong một hạng mục kiểm thử.
4.42
Kiểm thử tĩnh (static testing)
Kiểm thử trong đó hạng mục kiểm thử được kiểm tra dựa trên một bộ chất lượng hoặc các tiêu chí khác mà không cần thực thi mã.
VÍ DỤ: Soát xét, phân tích tĩnh.
4.43
Kiểm thử tới hạn (stress testing)
Loại kiểm thử hiệu quả hiệu năng được tiến hành để đánh giá cơ chế của một hạng mục kiểm thử theo các điều kiện tải vượt quá yêu cầu về năng lực quy định hoặc dự kiến, hoặc các nguồn lực sẵn có dưới mức yêu cầu quy định tối thiểu.
4.44
Kiểm thử có cấu trúc (structural testing)
Xem kiểm thử dựa trên cấu trúc (4.45)
4.45
Kiểm thử dựa trên cấu trúc (structure-based testing)
Kiểm thử động, trong đó các kiểm thử được hình thành từ việc xem xét cấu trúc của hạng mục kiểm thử.
CHÚ THÍCH 1: Kiểm thử dựa trên cấu trúc không bị hạn chế sử dụng ở cáp độ thành phần và có thể được sử dụng ở tất cả các cấp độ, ví dụ như danh sách phạm vi bao phủ hạng mục như là một phần của một hệ thống kiểm thử.
CHÚ THÍCH 2: Các kỹ thuật bao gồm kiểm thử chi nhánh, kiểm thử quyết định, kiểm thử câu lệnh.
CHÚ THÍCH 3: Tử đồng nghĩa với kiểm thử dựa trên cấu trúc là kiểm thử cấu trúc, kiểm thử hộp kính và kiểm thử hộp trắng.
4.46
Tiêu chí tạm dừng (suspension criteria)
Tiêu chí sử dụng (tạm thời) để ngăn chặn tất cả hoặc một phần của các hoạt động kiểm thử.
4.47
Cơ sở kiểm thử (test basis)
Nền tảng kiến thức được sử dụng làm cơ sở cho việc thiết kế kiểm thử và các ca kiểm thử.
CHÚ THÍCH: Các cơ sở kiểm thử có thể ở hình thức tài liệu, chẳng hạn như là một đặc tả yêu cầu, đặc đặc tả thiết kế, hoặc đặc tả mô đun, nhưng cũng có thể là sự hiểu biết phi tài liệu của hành vi bắt buộc.
4.48
Ca kiểm thử (test case)
Tập hợp các điều kiện tiên quyết, các đầu vào (bao gồm các hành động nếu có) và kết quả mong đợi, được phát triển để thực hiện một mục kiểm thử nhằm đáp ứng các mục tiêu kiểm thử, bao gồm việc thực hiện đúng, xác nhận lỗi, kiểm tra chất lượng và các thông tin có giá trị khác.
CHÚ THÍCH 1: Một ca kiểm thử là mức thấp nhất của đầu vào kiểm thử (tức là ca kiểm thử không được tạo thành từ các ca kiểm thử) cho các quy trình kiểm thử con mà nó được dự định.
CHÚ THÍCH 2: Các điều kiện tiên quyết ca kiểm thử bao gồm môi trường kiểm thử, dữ liệu hiện có (ví dụ như cơ sở dữ liệu), phần mềm để kiểm thử, phần cứng, vv
CHÚ THÍCH 3: Đầu vào là các thông tin dữ liệu được sử dụng để điều khiển thực hiện kiểm thử.
CHÚ THÍCH 4: Kết quả dự kiến bao gồm các tiêu chí thành công, thất bại để kiểm tra, vv
4.49
Đặc tả ca kiểm thử (Test Case Specification)
Tài liệu chứa một tập hoặc nhiều ca kiểm thử.
4.50
Quy trình kết thúc kiểm thử (Test Completion Process)
Quy trình quản lý kiểm thử để đảm bảo rằng các tài nguyên kiểm thử hữu ích phải có sẵn để sử dụng sau này, các môi trường kiểm thử được duy trì trong điều kiện thích hợp, các kết quả kiểm thử phải được ghi lại và được chuyển đến các bên liên quan.
4.51
Báo cáo kết thúc kiểm thử (Test Completion Report)
Cung cấp báo cáo tóm tắt việc kiểm thử đã được thực hiện.
CHÚ THÍCH: Còn được gọi là Báo cáo tóm tắt kiểm thử.
4.52
Điều kiện kiểm thử (test condition)
Khía cạnh có thể kiểm thử của một thành phần hoặc một hệ thống, chẳng hạn như là một chức năng, tiến trình, tính năng, thuộc tính chất lượng hoặc phần tử có cấu trúc được xác định là một cơ sở để kiểm thử.
CHÚ THÍCH: Điều kiện kiểm thử có thể được sử dụng để điều khiển các mục phạm vi, hoặc cố thể tự tạo thành các mục phạm vi.
4.53
Độ bao phủ kiểm thử (test coverage)
Tỷ lệ tính theo phần trăm, mà hạng mục độ bao phủ kiểm thử cụ thể đã được thực hiện bởi một ca kiểm thử hoặc các ca kiểm thử.
4.54
Hạng mục độ bao phủ kiểm thử (test coverage item)
Thuộc tính hay sự kết hợp của các thuộc tính được hình thành từ một hoặc nhiều điều kiện kiểm thử bằng cách sử dụng một kỹ thuật thiết kế kiểm thử cho phép đánh giá mức độ hoàn thành của việc thực hiện kiểm thử.
4.55
Dữ liệu kiểm thử (test data)
Dữ liệu được tạo ra hoặc được lựa chọn đáp ứng các yêu cầu đầu vào để thực hiện một hoặc nhiều ca kiểm thử, có thể được xác định trong kế hoạch kiểm thử, ca kiểm thử hoặc thủ tục kiểm thử.
CHÚ THÍCH: Dữ liệu kiểm thử có thể được lưu trữ trong các sản phẩm được kiểm thử (ví dụ như trong các mảng, các tập tin, hoặc một cơ sở dữ liệu), hoặc có thể là có sẵn từ hoặc được cung cấp bởi các nguồn bên ngoài, chẳng hạn như các hệ thống khác, các thành phần hệ thống khác, các thiết bị phần cứng, hoặc khai thác của con người.
4.56
Báo cáo tính sẵn sàng dữ liệu kiểm thử (Test Data Readiness Report)
Tài liệu mô tả tình trạng của yêu cầu yêu cầu dữ liệu kiểm thử.
4.57
Quy trình thiết kế và chuẩn bị kiểm thử (Test Design and Implementation Process)
Quy trình kiểm thử để tạo ra và xác định các ca kiểm thử và thủ tục kiểm thử.
4.58
Đặc tả thiết kế kiểm thử (Test Design Specification)
Tài liệu quy định các tính năng cần phải được kiểm thử và các điều kiện kiểm thử tương ứng của chúng.
4.59
Kỹ thuật thiết kế kiểm thử (test design technique)
Các hoạt động, khái niệm, quy trình và các mẫu được sử dụng để xây dựng một mô hình kiểm thử được sử dụng để xác định các điều kiện kiểm thử cho một hạng mục kiểm thử, lựa chọn các hạng mục độ bao phủ kiểm thử tương ứng và sau đó tạo ra hoặc lựa chọn các ca kiểm thử.
4.60
Môi trường kiểm thử (test environment)
Các phương tiện, phần cứng, phần mềm, phần sụn, thủ tục và tài liệu hướng dẫn dành cho hoặc được sử dụng để thực hiện kiểm thử phần mềm.
CHÚ THÍCH: Một môi trường kiểm thử có thể chứa nhiều môi trường để thích ứng với các quy trình kiểm thử con cụ thể (ví dụ như môi trường kiểm thử thành phần, môi trường thử nghiệm hiệu suất, vv).
4.61
Báo cáo tính sẵn sàng của môi trường kiểm thử (test environment readiness report)
Tài liệu mô tả việc đáp ứng từng yêu cầu về môi trường kiểm thử.
4.62
Yêu cầu môi trường kiểm thử (Test Environment Requirements)
Mô tả các thuộc tính cần thiết của môi trường kiểm thử.
CHÚ THÍCH: Tất cả hoặc một phần các yêu cầu môi trường kiểm thử có thể tham khảo ở nơi thông tin có thể được tìm thấy, ví dụ như trong Chiến lược kiểm thử có tổ chức, Kế hoạch kiểm thử và/hoặc Đặc tả kiểm thử thích hợp.
4.63
Quy trình thiết lập môi trường kiểm thử (Test Environment Set-up Process)
Quy trình kiểm thử động để thiết lập và duy trì một môi trường kiểm thử cần thiết.
4.64
Thực hiện kiểm thử (test execution)
Quy trình thực hiện kiểm thử trên một hạng mục kiểm thử, tạo ra các kết quả thực tế.
4.65
Nhật ký thực hiện kiểm thử (Test Execution Log)
Tài liệu ghi lại chi tiết việc thực hiện một hoặc nhiều thủ tục kiểm thử.
4.66
Quy trình thực hiện kiểm thử (Test Execution Process)
Quy trình kiểm thử động để thực hiện các thủ tục kiểm thử được tạo ra trong quy trình thiết kế và chuẩn bị kiểm thử trong môi trường kiểm thử chuẩn bị trước và ghi lại các kết quả.
4.67
Quy trình báo cáo sự cố kiểm thử (Test Incident Reporting Process)
Quy trình kiểm thử động để báo cáo cho các bên liên quan các vấn đề đã được xác định trong quá trình thực hiện kiểm thử mà cần tiếp tục đưa ra hành động để khắc phục.
4.68
Hạng mục kiểm thử (test item)
Sản phẩm dự án là đối tượng của kiểm thử.
VÍ DỤ: Một hệ thống, một hạng mục phần mềm, tài liệu yêu cầu, một đặc tả thiết kế, hướng dẫn người dùng.
4.69
Mức kiểm thử (test level)
Trường hợp cụ thể của một quy trình kiểm thử con.
VÍ DỤ: Dưới đây là mức kiểm thử phổ biến có thể được khởi tạo như Quy trình kiểm thử con: mức kiểm thử thành phần/Quy trình con, tích hợp mức kiểm thử/Quy trình con, mức kiểm thư hệ thống/Quy trình con, mức kiểm thử chấp nhận/Quy trình con.
CHÚ THÍCH: Các mức kiểm thử đồng nghĩa với các giai đoạn kiểm thử.
4.70
Quản lý kiểm thử (test management)
Lập kế hoạch, lịch trình, ước lượng, giám sát, báo cáo, kiểm soát và kết thúc các hoạt động kiểm thử.
4.71
Quy trình quản lý kiểm thử (Test Management Process)
Quy trình kiểm thử bao gồm các quy trình con cần thiết để quản lý một dự án kiểm thử.
CHÚ THÍCH: Xem Quy trình lập kế hoạch kiểm thử, Quy trình giám sát và kiểm soát kiểm thử, Quy trình hoàn thành kiểm thử.
4.72
Quy trình giám sát và kiểm soát kiểm thử (Test Monitoring and Control Process)
Quy trình quản lý kiểm thử để đảm bảo rằng kiểm thử được thực hiện đúng theo kế hoạch kiểm thử và với đặc tả kiểm thử của tổ chức.
4.73
Đối tượng kiểm thử (test object)
Xem mục 4.68: Hạng mục kiểm thử.
4.74
Giai đoạn kiểm thử (test phase)
Trường hợp cụ thể của quy trình kiểm thử con.
CHÚ THÍCH: Các giai đoạn kiểm thử là đồng nghĩa với các mức kiểm thử, do đó ví dụ về các giai đoạn kiểm thử là giống như đối với các mức kiếm thử (ví dụ như giai đoạn kiểm thử hệ thống/Quy trình con).
4.75
Kế hoạch kiểm thử (Test Plan)
Mô tả chi tiết các mục tiêu kiểm thử cần phải đạt được và các phương tiện và lịch trình để đạt được chúng, được tổ chức để phối hợp các hoạt động kiểm thử cho một số hạng mục kiểm thử hoặc tập hợp các hạng mục kiểm thử.
CHÚ THÍCH 1: Một dự án có thể có nhiều hơn một kế hoạch kiểm thử, ví dụ có thể là một Kế hoạch kiểm thử dự án (cũng được biết đến như lá một kế hoạch kiểm thử tổng thể) mà bao gồm tất cả các hoạt động kiểm thử về dự án; chi tiết thêm về các hoạt động kiểm thử đặc biệt có thể được định nghĩa trong một hoặc nhiều Kế hoạch quy trình kiểm thử con (tức là một kế hoạch kiểm thử hệ thống hoặc một kế hoạch kiểm tra hiệu năng).
CHÚ THÍCH 2: Thông thường một Kế hoạch kiểm thử là một tài liệu bằng văn bản, mặc dù các định dạng kế hoạch khác có thể có là định nghĩa nội bộ trong một tổ chức hoặc dự án.
CHÚ THÍCH 3: Kế hoạch kiểm thử cũng có thể được viết cho các hoạt động phi dự án, ví dụ như Kế hoạch kiểm thử bảo trì.
4.76
Quy trình lập kế hoạch kiểm thử (Test Planning Process)
Quy trình quản lý kiểm thử được sử dụng để hoàn thành kế hoạch kiểm thử và phát triển các kế hoạch kiểm thử.
4.77
Thực hành kiểm thử (test practice)
Khung khái niệm có thể được áp dụng cho các quy trình kiểm thử của tổ chức, quy trình quản lý kiểm thử và/hoặc quy trình kiểm thử động để tạo điều kiện kiểm thử.
CHÚ THÍCH: Thực hành kiểm thử đôi khi được gọi là phương pháp kiểm thử.
4.78
Thủ tục kiểm thử (test procedure)
Chuỗi các ca kiểm thử thực hiện tuần tự và mọi hành động có liên quan cần thiết để thiết lập các điều kiện tiên quyết ban đầu và mọi hành động ràng buộc cần phải thực hiện.
CHÚ THÍCH: Thủ tục kiểm thử bao gồm các hướng dẫn chi tiết làm thế nào để chạy một tập hợp của một hoặc nhiều ca kiểm thử được lựa chọn một cách liên tục, bao gồm thiết lập các điều kiện tiên quyết chung, và cung cấp đầu vào và đánh giá kết quả thực tế cho từng ca kiểm thử.
4.79
Đặc tả thủ tục kiểm thử (Test Procedure Specification)
Tài liệu quy định một hoặc nhiều thủ tục kiểm thử, nó là những tập hợp của các ca kiểm thử được thực hiện cho một mục tiêu cụ thể.
CHÚ THÍCH 1: Các ca kiểm thử trong một tập kiểm thử được liệt kê theo thứ tự yêu cầu của chúng trong thủ tục kiểm thử.
CHÚ THÍCH 2: Cũng được biết đến như một kịch bản kiểm thử nghiệm nhân công. Một đặc tả thủ tục kiểm thử cho việc chạy một kiểm thứ tự động thường được gọi là một kịch bản kiểm thử.
4.80
Quy trình kiểm thử (test process)
Cung cấp thông tin về chất lượng của một sản phẩm phần mềm, thường bao gồm một số hoạt động được nhóm lại thành một hoặc nhiều quy trình kiểm thử con.
VÍ DỤ: Quy trình kiểm thử cho một dự án cụ thể cũng có thể gồm nhiều quy trình con, ví dụ: một quy trình kiểm thử con hệ thống, một quy trình con lập kế hoạch kiểm thử (một phần của quy trình quản lý kiểm thử lớn hơn) hoặc một quy trình kiểm thử con tĩnh.
4.81
Yêu cầu kiểm thử (test requirement)
Xem mục 4.52: Điều kiện kiểm thử.
4.82
Kết quả kiểm thử (test result)
Chỉ số cho biết một ca kiểm thử cụ thể hoặc là đạt hay không đạt, tức là nếu kết quả thực tế thu được tại đầu ra hạng mục kiểm thử tương ứng với kết quả mong đợi hoặc sai lệch.
4.83
Kịch bản kiểm thử (test script)
Đặc tả thủ tục kiểm thử dùng cho kiểm thử thủ công hoặc tự động.
4.84
Bộ kiểm thử (test set)
Tập hợp một hoặc nhiều ca kiểm thử có các ràng buộc chung về thực hiện chúng, VÍ DỤ: Môi trường kiểm thử cụ thể, kiến thức chuyên ngành cụ thể hoặc mục đích cụ thể.
4.85
Đặc tả kiểm thử (test specification)
Tài liệu hoàn chỉnh về thiết kế kiểm thử, các ca kiểm thử và các thủ tục kiểm thử cho một hạng mục kiểm thử cụ thể.
CHÚ THÍCH: Một đặc tả kiểm thử có thể được trình bày chi tiết trong một tài liệu, trong một tập hợp các tài liệu, hoặc bằng cách khác, ví dụ như trong một hỗn hợp của các tài liệu và các thực thể cơ sở dữ liệu.
4.86
Báo cáo tình trạng kiểm thử (test status report)
Báo cáo cung cấp thông tin về tình trạng của kiểm thử đang được thực hiện trong một chu kỳ báo cáo quy định.
4.87
Chiến lược kiểm thử (test strategy)
Một phần của kế hoạch kiểm thử mô tả phương pháp để kiểm thử cho một dự án kiểm thử cụ thể hoặc các quy trình kiểm thử con hoặc các quy trình con.
CHÚ THÍCH 1: Chiến lược kiểm thử là một thực thể riêng biệt từ Chiến lược kiểm thử có tổ chức.
CHÚ THÍCH 2: Chiến lược kiểm thử thường mô tả một số hoặc tất cả những điều sau đây: các thực hành kiểm thử sử dụng; các quy trình kiểm thử con sẽ được thực hiện; kiểm thử lại và kiểm thử hồi quy được sử dụng; kỹ thuật thiết kế kiểm thử và tiêu chí hoàn thành kiểm thử nghiệm tương ứng sẽ được sử dụng; dữ liệu kiểm thử; môi trường kiểm thử và công cụ kiểm thử yêu cầu; và kỳ vọng khả năng chuyển giao kiểm thử.
4.88
Quy trình kiểm thử con (test sub-process)
Quy trình quản lý kiểm thử và quy trình kiểm thử động (và tĩnh) được sử dụng để thực hiện một mức kiểm thử cụ thể (ví dụ như kiểm thử hệ thống, kiểm thư chấp nhận) hoặc loại kiểm thử thông thường (như kiểm thử khả năng sử dụng, kiểm thử hiệu năng) trong bối cảnh của một quy trình kiểm thử tổng thể cho một dự án kiểm thử.
CHÚ THÍCH: Một quy trình kiểm thử con có thể bao gồm một hoặc nhiều loại kiểm thử. Tùy thuộc vào mô hình vòng đời sử dụng, quy trình kiểm thử con cũng thường được gọi là giai đoạn kiểm thử, mức kiểm thử, tầng kiểm thử hoặc các nhiệm vụ kiểm thử.
4.89
Kỹ thuật kiểm thử (test technique)
Xem mục 4.59: Kỹ thuật thiết kế kiểm thử.
4.90
Ma trận truy xuất nguồn gốc kiểm thử (test traceability matrix)
Tài liệu, bảng tính, hay các công cụ tự động khác được sử dụng để xác định các hạng mục có liên quan trong tài liệu và phần mềm, chẳng hạn như các yêu cầu với các kiểm thử kết hợp.
CHÚ THÍCH 1: Cũng được gọi là ma trận xác minh tham chiếu chéo, ma trận kiểm thử yêu cầu, bảng xác minh yêu cầu, vv.
CHÚ THÍCH 2: Ma trận truy xuất nguồn gốc kiểm thử khác nhau có thể có những thông tin, định dạng và mức chi tiết khác nhau.
4.91
Kiểu kiểm thử (test type)
Nhóm các hoạt động kiểm thử tập trung vào đặc tính chất lượng cụ thể.
CHÚ THÍCH: Một loại kiểm thử có thể được thực hiện trong một quy trình kiểm thử con duy nhất hoặc có thể được thực hiện qua một số quy trình kiểm thử con (ví dụ như kiểm thử hiệu năng hoàn thành tại một quy trình kiểm thử con thành phần và cũng hoàn thành tại một quy trình kiểm thử con hệ thống).
VÍ DỤ: Kiểm thử an toàn, kiểm thử chức năng, kiểm thử khả năng sử dụng, và kiểm thử hiệu năng.
4.92
Kiểm thử (testing)
Tập hợp các hoạt động được thực hiện để phát hiện và/hoặc đánh giá các đặc tính của một hoặc nhiều hạng mục kiểm thử.
CHÚ THÍCH 1: Hoạt động kiểm thử có thể bao gồm việc lập kế hoạch, chuẩn bị, thực hiện, báo cáo, và các hoạt động quản lý kiểm thử.
4.93
Tài liệu và công cụ kiểm thử (testware)
Tài liệu và công cụ được tạo ra trong quá trình kiểm thử cần thiết để lập kế hoạch, thiết kế và thực hiện các kiểm thử.
CHÚ THÍCH 1: Tài liệu và công cụ kiểm thử có thể bao gồm những thứ như tài liệu, kịch bản, đầu vào, kết quả dự kiến, các tập tin, cơ sở dữ liệu, môi trường, và bất kỳ phần mềm bổ sung hoặc các tiện ích được sử dụng trong quá trình kiểm thử.
4.94
Kiểm thử phi kịch bản (unscripted testing)
Kiểm thử động, trong đó các hành động của người kiểm thử không được quy định theo hướng dẫn bằng văn bản trong một ca kiểm thử.
4.95
Kiểm thử kích cỡ dữ liệu (volume testing)
Loại kiểm thử hiệu quả hiệu năng được tiến hành để đánh giá khả năng của một hạng mục kiểm thử để xử lý khối lượng dữ liệu cụ thể (thường là tại hoặc gần năng lực tối đa quy định) về khả năng thông qua, khả năng lưu trữ, hoặc cả hai.
4.96
Kiểm thử hộp trắng (white box testing)
Xem mục 4.45: Kiểm thử dựa trên cấu trúc.
5 Các khái niệm về kiểm thử phần mềm
5.1 Giới thiệu kiểm thử phần mềm
Kiểm thử phần mềm là cần thiết vì:
- Thông tin về các đặc tính chất lượng của các hạng mục kiểm thử được yêu cầu bởi người ra quyết định;
- Các hạng mục kiểm thử đang được kiểm thử không phải luôn thực hiện đúng theo dự kiến;
- Các hạng mục kiểm thử đang được kiểm thử cần phải được xác minh;
- Các hạng mục kiểm thử đang được kiểm thử cần được xác nhận và/hoặc;
- Việc đánh giá các hạng mục kiểm thử cần phải được tiến hành trong suốt vòng đời phát triển hệ thống và phần mềm.
Phần mềm thường được chấp nhận rằng không thể tạo ra một phần mềm hoàn hảo. Vì vậy, cần phải kiểm thử phần mềm trước khi phát hành tới người sử dụng nhằm giảm rủi ro phát sinh lỗi và các ảnh hưởng tiêu cực khi sử dụng trong việc sản xuất phần mềm. Đồng thời cũng cần thiết để đảm bảo rằng việc kiểm thử được thực hiện tốt.
Phát sinh lỗi hoặc các khiếm khuyết phát sinh là không thể tránh khỏi. Một sai lầm hoặc lỗi được tạo ra bởi con người gây nên một lỗi xuất hiện trong sản phẩm mà người đó đang thực hiện; (ví dụ như một đặc tả yêu cầu hoặc một thành phần phần mềm). Khiếm khuyết không ảnh hưởng đến hoạt động của phần mềm nếu không gặp phải khi sử dụng. Nhưng nếu một khiếm khuyết gặp phải trong các điều kiện thích hợp khi sử dụng sản phẩm có thể dẫn đến một sản phẩm không đáp ứng được nhu cầu chính đáng của người sử dụng. Hậu quả nghiêm trọng có thể dẫn đến người sử dụng phải nếm trải một thất bại phần mềm; Ví dụ, một khiếm khuyết có thể làm tổn hại uy tín kinh doanh, an toàn công cộng, khả năng sinh lợi, kinh doanh hoặc an toàn người dùng và/hoặc môi trường.
Kiểm thử động là cần thiết, nhưng không đủ để cung cấp sự đảm bảo hợp lý rằng phần mềm sẽ thực hiện đúng dự định, cần bổ sung các hoạt động kiểm thử tĩnh, chẳng hạn như đánh giá kỹ lưỡng và phân tích tĩnh phải được kết hợp thực hiện có hiệu quả với các hoạt động kiểm thử động.
Các mục tiêu chính của kiểm thử là: Cung cấp thông tin về chất lượng của các hạng mục kiểm thử và bất kỳ rủi ro còn tồn tại trong mối quan hệ với nhiều hạng mục kiểm thử đã được kiểm thử; phải tìm các khiếm khuyết trong các hạng mục kiểm thử trước khi phát hành để sử dụng; và giảm thiểu rủi ro cho các bên liên quan về chất lượng không tốt của sản phẩm.
Thông tin này có thể được sử dụng cho nhiều mục đích; bao gồm:
- Để cải thiện các hạng mục kiểm thử bằng cách loại bỏ các khiếm khuyết;
- Để cải thiện các quyết định quản lý bằng cách cung cấp thông tin về chất lượng và rủi ro làm cơ sở cho các quyết định; và
- Để cải thiện các quy trình trong tổ chức bằng cách đánh dấu quy trình cho phép các khiếm khuyết xuất hiện và/hoặc vẫn chưa được khám phá ở nơi mà chúng có thể đã được phát hiện.
Chất lượng sản phẩm có nhiều khía cạnh, trong đó có sự phù hợp với đặc tả, sự vắng mặt của các khiếm khuyết và sự phù hợp trong việc đáp ứng các yêu cầu của người sử dụng sản phẩm. Tiêu chuẩn ISO/IEC 25.010: “Mô hình chất lượng hệ thống và phần mềm” xác định tám đặc điểm chất lượng có thể đo kiểm hoặc được đánh giá bằng cách kiểm thử (xem mục 5.5.3).
Kiểm thử phần mềm nên tập trung vào việc cung cấp thông tin về một sản phẩm phần mềm và tìm ra nhiều khiếm khuyết có thể có càng sớm càng tốt trong quy trình phát triển theo các ràng buộc nhất định về chi phí và lịch trình.
Các lưu ý kiểm thử bao gồm:
- Kiểm thử là một quy trình, quy trình là một tập hợp các hoạt động liên quan đến nhau hoặc tương tác mà biến đổi đầu vào thành đầu ra. Mục đích của tiêu chuẩn này là trình bày và mô tả quy trình thử nghiệm chung (xem TCVN 12849-2:2020 (ISO/IEC/IEEE 29119-2:2013) “Kỹ thuật hệ thống và phần mềm - Kiểm thử phần mềm - Phần 2: Quy trình kiểm thử” để biết thêm chi tiết).
- Quy trình kiểm thử của tổ chức thiết lập, duy trì các chính sách kiểm thử và chiến lược kiểm thử áp dụng qua các dự án và các chức năng của tổ chức.
- Kiểm thử phải được lập kế hoạch, được giám sát và kiểm soát. TCVN 12849-2:2020 (ISO/IEC/IEEE 29119-2:2013) “Kỹ thuật hệ thống và phần mềm - Kiểm thử phần mềm - Phần 2: Quy trình kiểm thử” bao gồm một quy trình quản lý kiểm thử và có thể được áp dụng để kiểm thử trong tất cả các vòng đời phát triển và quản lý của các kiểm thử thăm dò.
- Quy trình kiểm thử và quy trình con có thể được áp dụng cho bất kỳ giai đoạn hoặc mức kiểm thử (ví dụ như kiểm thử hệ thống) hoặc loại kiểm thử (ví dụ như kiểm thử hiệu năng).
- Kiểm thử đòi hỏi phải kiểm tra một hạng mục kiểm thử.
- Kiểm thử có thể được thực hiện trên một sản phẩm mà không thực hiện sản phẩm trên máy tính. Điều này được gọi là kiểm thử tĩnh trong tiêu chuẩn này và trong nhiều lĩnh vực của ngành công nghiệp, mặc dù các tiêu chuẩn khác (ví dụ như IEEE 1028) cụ thể hơn có thể gọi là các soát xét, trao đổi chuyên môn hoặc thẩm tra. Để kiểm thử tĩnh tiêu chuẩn này thừa nhận và xác định vai trò của người kiểm thử trong các hoạt động này mặc dù họ có thể được thực hiện bởi các nhóm khác trong một dự án hoặc được xác định bởi các tiêu chuẩn phi kiểm thử khác. Điều này là do các hoạt động kiểm thử tĩnh được coi là rất quan trọng để kết thúc vòng đời kiểm thử và hoạt động kiểm thử đã được chứng minh là rất quan trọng cho việc phát hiện khiếm khuyết sớm, giảm chi phí dự án tổng thể và cải thiện khả năng đáp ứng nhu cầu tiến độ.
- Kiểm thử tĩnh cũng có thể bao gồm việc sử dụng các công cụ phân tích tĩnh để tìm ra các khiếm khuyết trong mã lệnh hoặc tài liệu mà không cần có mã thực thi (ví dụ: một trình biên dịch, một bộ phân tích phức tạp, hoặc một bộ phân tích an toàn mã lệnh).
- Kiểm thử động không "chỉ" bao gồm thực hiện các hạng mục kiểm thử thực thi mà cũng bao gồm cả các hoạt động chuẩn bị và hoạt động theo dõi. Quy trình kiểm thử động được mô tả trong tiêu chuẩn TCVN 12849-2:2020 (ISO/IEC/IEEE 29119-2:2013) bao hàm cả từng hoạt động được thực hiện trong kiểm thử động.
- Xác minh là xác nhận, thông qua việc cung cấp các bằng chứng khách quan rằng các yêu cầu cụ thể đã được thực hiện đầy đủ trong một hạng mục công việc cụ thể.
- Xác nhận chứng minh rằng các hạng mục công việc có thể được sử dụng bởi những người sử dụng cho các nhiệm vụ cụ thể của họ.
- Kiểm thử cho dù tĩnh hay động, nên nhằm mục đích để cung cấp cả hai loại xác nhận, mặc dù có những kỳ vọng mà việc xác nhận sẽ không được thực hiện ngay lập tức do việc phát hiện của các khuyết khuyết.
5.1.1 Vai trò của kiểm thử trong việc xác minh và xác nhận
- Tiêu chuẩn này chỉ đưa ra một số hoạt động xác minh và xác nhận cụ thể để kiểm thử phần mềm, đó là một hoạt động quan trọng của việc xác minh và xác nhận. Các tiêu chuẩn khác, ví dụ ISO/IEC 12.207 và IEEE 1012, đưa ra các hoạt động xác minh hoặc xác nhận khác. Kiểm thử đưa ra trong tiêu chuẩn này không chỉ các hoạt động của việc xác minh và xác nhận (ví dụ như: các phân tích V & V, các phương pháp bắt buộc). Để cung cấp một xác minh và xác nhận đầy đủ của một sản phẩm, một tổ chức cần phải sử dụng tiêu chuẩn này kết hợp với các tiêu chuẩn khác như là một phần của một chương trình kỹ thuật toàn diện. Xem Phụ lục A về hệ thống phân cấp các hoạt động xác minh và xác nhận.
Do tính phức tạp của hệ thống và phần mềm là không thể kiểm thử triệt để mọi khía cạnh của bất kỳ hạng mục kiểm thử cho trước. Người kiểm thử cần biết rằng kiểm thử thấu đáo là không thể và các hoạt động kiểm thử cần nhắm vào mục tiêu kiểm thử để hoàn thành tốt nhất cho một hạng mục kiểm thử. Kiểm thử dựa trên rủi ro là một phương pháp sử dụng rủi ro để nỗ lực kiểm thử trực tiếp. Xem mục 5.4: Kiểm thử dựa trên rủi ro.
Trong kỹ thuật (và kỹ thuật phần mềm) phỏng đoán là một phương pháp dựa trên cơ sở kinh nghiệm (thử và lỗi) có thể được sử dụng như là một trợ giúp để giải quyết vấn đề và thiết kế. Tuy nhiên, trong khi phỏng đoán có thể được sử dụng để giải quyết các vấn đề, chúng có thể mắc sai lầm ở chỗ đôi khi chúng không thể giải quyết, hoặc chỉ giai quyết một phần của một vấn đề. Phần lớn kiểm thử phần mềm và hệ thống là dựa trên phương pháp phỏng đoán. Ví dụ, phỏng đoán là hữu ích khi tạo mô hình của hệ thống để kiểm thử; Tuy nhiên, phỏng đoán có thể không mô hình đầy đủ của hệ thống và do khiếm khuyết trong hệ thống có thể không được tìm thấy mặc dù các kiểm thử thực hiện là hoàn tất. Công nhận rằng cách thức mà kiểm thử được thực hiện có thể không cho phép để giảm thiểu các rủi ro của một chiến lược kiểm thử không hiệu quả bằng cách sử dụng các chiến lược kiểm thử đa nhiệm.
5.2 Kiểm thử phần mềm trong bối cảnh dự án và tổ chức
Các doanh nghiệp tham gia vào việc phát triển hoặc mua lại các sản phẩm phần mềm có lợi ích trong việc phát triển và sử dụng các quy trình hiệu quả và có khả năng tái tạo. Để thực hiện điều này họ thường phát triển một bộ các quy trình vòng đời phần mềm mạnh được áp dụng cho các dự án phát triển mà họ thực hiện. Tiêu chuẩn này hướng tới hữu ích cho cả việc áp dụng trong toàn bộ tổ chức và sử dụng vào các dự án cụ thể. Một tổ chức sẽ áp dụng các tiêu chuẩn và bổ sung các thủ tục, thực hành, công cụ và các chính sách khi cần thiết. Một dự án phần mềm hoặc hệ thống phát triển cụ thể thực hiện trong một tổ chức thường sẽ phù hợp với các quy trình của tổ chức chứ không phải trực tiếp phù hợp với tiêu chuẩn này. Trong một số trường hợp, một dự án có thể được thực hiện bởi một tổ chức mà không có một bộ các quy trình trong toàn bộ tổ chức. Một dự án như vậy có thể áp dụng các quy định của tiêu chuẩn này trực tiếp cho dự án đó.
Trong mỗi loại hình tổ chức sản xuất phần mềm, có thể là một tổ chức đa quốc gia với hàng ngàn kiểm thử viên hoặc công ty một người, kiểm thử phần mềm nên có sự cam kết ở cấp độ cao nhất của tổ chức quản lý, có thể là giám đốc điều hành, Ban chỉ đạo mã nguồn mở hoặc quản lý bộ phận. Cam kết này được thể hiện phù hợp trong chính sách kiểm thử của tổ chức và một hoặc nhiều chiến lược kiểm thử của tổ chức, phục vụ như là cơ sở cho tất cả các kiểm thử phần mềm được thực hiện trong tổ chức. Chính sách kiểm thử và các chiến lược kiểm thử của tổ chức thường chỉ được thấy trong các tổ chức qui mô lớn. Kiểm thử có thể và được thực hiện mà không cần các chính sách kiểm thử chính thức và chiến lược kiểm thử của tổ chức trong các tổ chức qui mô nhỏ hơn, nhưng thực tế điều này mang lại ít gắn kết với kiểm thử trong tổ chức và thường làm cho việc kiểm thử được thực hiện trong các dự án kém hiệu quả và hiệu lực.
Kiểm thử phần mềm được thực hiện như là một quy trình bối cảnh được quản lý. Điều này có nghĩa là phải được lập kế hoạch, được giám sát và được kiểm soát. Bối cảnh có thể là một dự án phát triển (từ người đa nhiệm, dự án phát triển chính thức trong nhiều năm tới một số người phát triển chính thức theo giờ) hoặc hoạt động bảo trì đang diễn ra của một hệ thống vận hành. Một số cân nhắc trong việc tìm hiểu bối cảnh kiểm thử là; ngân sách tổng thể; nhu cầu tiến độ; rủi ro; văn hóa tổ chức; kỳ vọng của khách hàng/người dùng; khả năng sẵn sàng của môi trường hạ tầng để kiểm thử; phạm vi của dự án; tính chất quan trọng của dự án; vv. Kinh nghiệm của ngành công nghiệp là không có chiến lược kiểm thử, kế hoạch, phương pháp hoặc quy trình duy nhất sẽ thực hiện tất cả các tình huống. Do đó các tổ chức và các dự án cần điều chỉnh và tinh chỉnh các chi tiết của kiểm thử có sự tham khảo các tiêu chuẩn này.
Một kế hoạch dự án tổng thể cần bao gồm việc xem xét các hoạt động kiểm thử sẽ được thực hiện như một phần của dự án. Một kế hoạch kiểm thử dự án cần phản ánh cả về chính sách kiểm thử của tổ chức và chiến lược kiểm thử của tổ chức và độ lệch từ các nguyên tắc của tổ chức. Nó cũng cần tính tới các ràng buộc nhất định trong kế hoạch dự án tổng thể. Kế hoạch kiểm thử dự án bao gồm một chiến lược kiểm thử dự án và các quyết định cụ thể của dự án (bao gồm cả các giả thiết) được sử dụng để xây dựng chiến lược này. Một yếu tố quan trọng của kế hoạch kiểm thử là khối lượng của các nhu cầu kiểm thử khác nhau và cân đối các nguồn lực theo các kiểm thử khác nhau. Kế hoạch kiểm thử ghi lại các kết quả của phân tích này. Rủi ro trong tiêu chuẩn này là phương pháp chính của việc xác định các nhu cầu kiểm thử (xem mục 5.4), mặc dù các thực hành kiểm thử được trình bày trong mục 5.6 có thể được kết hợp trong một chiến lược.
Kiểm thử cho một dự án thường sẽ được thực hiện qua một số quy trình kiểm thử con; mỗi một quy trình kiểm thử con có thể có một kế hoạch kiểm thử tương ứng (Kế hoạch quy trình kiểm thử con, ví dụ như một kế hoạch kiểm thử hệ thống hoặc một Kế hoạch kiểm thử hiệu năng) bao gồm một chiến lược quy trình kiểm thử con phù hợp với chiến lược kiểm thử dự án và quy trình kiểm thử con chi tiết cụ thể.
Hình 1 mô tả cách kiểm thử phù hợp với một bối cảnh nhiều lớp. Kiểm thử được thành lập dựa trên tình hình chỉ đạo của một tổ chức nếu có. Bối cảnh này tạo thành từ các luật, quy định và tiêu chuẩn công nghiệp. Theo chỉ đạo này, tổ chức phát triển các chính sách và thủ tục yêu cầu cần thiết để thực hiện thành công, chính sách kiểm thử của tổ chức hoạt động ở cấp độ này. Trong tổ chức mỗi dự án được khởi tạo để đáp ứng một số nhu cầu hay cơ hội tổ chức đã xác định. Bối cảnh dự án giúp xác định vòng đời mô hình được chọn, ở cấp độ này, dựa trên bối cảnh của mô hình vòng đời và dự án, một chiến lược để kiểm thử được xác định. Kế hoạch dự án và chiến lược để kiểm thử hình thành cơ sở cho kế hoạch kiểm thử dự án.
Kế hoạch kiểm thử dự án mô chiến lược tổng thể để kiểm thử và các quy trình kiểm thử sẽ được sử dụng. Nó thiết lập bối cảnh kiểm thử cho dự án bằng cách xác định mục tiêu, thực hành, nguồn lực và tiến độ; nó cũng xác định khả năng áp dụng các quy trình kiểm thử con (ví dụ: như kiểm thử hệ thống, kiểm thử hiệu năng). Việc xác định các quy trình con sau đó được mô tả trong kế hoạch kiểm thử quy trình con (ví dụ như: kế hoạch kiểm thử hệ thống, kế hoạch kiểm thử hiệu năng). Kế hoạch kiểm thử cũng mô tả các kỹ thuật thiết kế kiểm thử thích hợp (tĩnh hoặc động) sử dụng để hoàn thành việc kiểm thử theo yêu cầu của kế hoạch quy trình con cụ thể. Để biết thêm về kỹ thuật thiết kế kiểm thử xem mục 5.5.6 của tiêu chuẩn này và TCVN 12849-4:2020 (ISO/IEC/IEEE 29119-4:2015).
Mỗi kế hoạch kiểm thử quy trình con có thể giải quyết nhiều hơn một mức độ kiểm thử (ví dụ như kế hoạch kiểm thử khả năng bảo mật có thể giải quyết một số mức độ kiểm thử) và có thể giải quyết nhiều hơn một kiểu kiểm thử (ví dụ như: một kế hoạch kiểm thử hệ thống giải quyết việc kiểm thử hiệu năng và chức năng tại mức độ kiểm thử hệ thống). Kế hoạch kiểm thử quy trình con cũng mô tả chiến lược để thực hiện kiểm thử (ví dụ như: theo kịch bản, phi kịch bản, hoặc kết hợp cả hai).
Kế hoạch kiểm thử bao gồm một chiến lược kiểm thử (xem mục 6). Chiến lược kiểm thử được điều chỉnh theo bối cảnh dự án kiểm thử cụ thể. Chiến lược kiểm thử cần giải quyết các hạng mục cụ thể được liệt kê trong hình 1, được định nghĩa trong các phần khác của tiêu chuẩn này. Mỗi kế hoạch kiểm thử (và chiến lược) sẽ là duy nhất, lựa chọn khác nhau: Quy trình kiểm thử con; các mức độ tự động hóa; kết hợp của các kỹ thuật thiết kế kiểm thử; tiêu chí hoàn thành và lập tiến độ và nguồn lực của chúng. Việc lập kế hoạch và lựa chọn thời điểm khởi đầu trong một dự án và sẽ tiếp tục thông qua chu kỳ vòng đời kiểm thử là các yếu tố như sự thay đổi rủi ro. Nhiều phần của kế hoạch và chiến lược kiểm thử nên được dự kiến sẽ thay đổi, mặc dù các thay đổi này sẽ có khả năng bị hạn chế bởi dự án, tổ chức, và/hoặc các ràng buộc pháp lý.
Hình 1: Sơ đồ bối cảnh kiểm thử nhiều lớp
Mối quan hệ giữa quy trình kiểm thử tổng quát, quy trình kiểm thử con tổng quát, các mức/giai đoạn kiểm thử và các kiểu kiểm thử được mô tả chi tiết hơn trong hình 2. Hình này cho thấy việc thực hiện các quy trình kiểm thử con tổng quát như là các mức kiểm thử và kiểu kiểm thử cụ thể. Quy trình kiểm thử con tổng quát có thể được áp dụng trong các cách sau:
- Là một mức hoặc giai đoạn kiểm thử: nghĩa là mỗi một mức kiểm thử là một ứng dụng cụ thể của quy trình kiểm thử con tổng quát (ví dụ như: giai đoạn kiểm thử thành phần, mức kiểm thử nghiệm thu);
- Là một kiểu kiểm thử: nghĩa là mỗi một kiểu kiểm thử là một ứng dụng cụ thể của quy trình kiểm thử con tổng quát (ví dụ như: kiểm thử hiệu năng, kiểm thử khả năng sử dụng);
- Một quy trình kiểm thử con kết hợp với một mức kiểm thử có thể bao gồm nhiều hơn một quy trình con kiểu kiểm thử (ví dụ như: kiểm thử hiệu năng và chức năng là một phần của kiểm thử hệ thống); và
- Quy trình kiểm thử dự án có thể được bao gồm một chuỗi các quy trình kiểm thử con (ví dụ như: kiểm thử thành phần, kiểm thử tích hợp, kiểm thử hệ thống và quy trình kiểm thử con kiểm thử chấp nhận).
Sơ đồ cũng làm rõ mối quan hệ giữa các kiểu kiểm thử và đặc tính chất lượng (như được định nghĩa trong tiêu chuẩn ISO/IEC 25010: Các mô hình chất lượng hệ thống và phần mềm). Mỗi kiểu kiểm thử nhắm mục tiêu tới một đặc tính chất lượng cụ thể. Để biết thêm về mối quan hệ giữa các kiểu kiểm thử và đặc tính chất lượng xem mục 5.5.3 của tiêu chuẩn này.
Hình 2: Mối quan hệ giữa quy trình kiểm thử con tổng quát, các mức kiểm thử và các kiểu kiểm thử
Tiêu chuẩn này sử dụng một mô hình quy trình ba lớp, được mô tả chi tiết trong TCVN 12849-2:2020 (ISO/IEC/IEEE 29119-2:2013) và minh họa ở mức cao tại Hình 3. Mô hình quy trình bắt đầu với một lớp tổ chức quản lý các đặc tả kiểm thử (tổ chức) mức cao, chẳng hạn như chính sách kiểm thử của tổ chức và chiến lược kiểm thử của tổ chức. Lớp giữa là quản lý kiểm thử (quản lý kiểm thử dự án, quản lý giai đoạn kiểm thử, quản lý kiểu kiểm thử), trong khi lớp cuối xác định một số quy trình kiểm thử được sử dụng cho kiểm thử động.
Mô hình quy trình ba lớp được mô tả trong hình 3.
Hình 3: Mối quan hệ nhiều lớp giữa các quy trình kiểm thử
Chính sách kiểm thử thể hiện kỳ vọng quản lý của tổ chức và phương pháp tiếp cận để kiểm thử phần mềm trong kinh doanh. Mặc dù cũng sẽ có ích cho bất cứ ai tham gia vào kiểm thử, nhằm mục đích điều hành và quản lý cấp cao. Chính sách kiểm thử cũng hướng dẫn các hướng ưu tiên và cơ chế liên quan đến việc xây dựng và thực hiện chiến lược kiểm thử của tổ chức và các quy trình kiểm thử của tổ chức. Việc tạo ra, thực hiện và duy trì các chính sách kiểm thử của tổ chức được mô tả bằng các quy trình kiểm thử của tổ chức.
Chiến lược kiểm thử của tổ chức thể hiện các yêu cầu và các ràng buộc về quá trình quản lý kiểm thử và các quy trình kiểm thử động được thực hiện trên tất cả các dự án của tổ chức, trừ khi chúng cùng một đặc tính, trong đó có trường hợp nhiều chiến lược kiểm thử của tổ chức có thể được đưa ra. Nó được gắn kết với chính sách kiểm thử của tổ chức và mô tả cách thức kiểm thử sẽ được thực hiện. Việc tạo ra, thực hiện và duy trì các chiến lược kiểm thử của tổ chức cũng được xác định bởi quy trình kiểm thử của tổ chức.
Việc quản lý kiểm thử được thực hiện bằng cách mô tả bởi các quy trình quản lý kiểm thử dựa trên việc phân tích các rủi ro được xác định và các ràng buộc của dự án và có tính tới chiến lược kiểm thử của tổ chức, chiến lược kiểm thử liên quan đến dự án được phát triển. Chiến lược này được xây dựng trong điều kiện xác định các kiểm thử tĩnh và kiểm thử động sẽ được thực hiện, nhân sự tổng thể, cân đối các ràng buộc nhất định (các nguồn lực và thời gian) với phạm vi quy định và chất lượng công tác kiểm thử phải được thực hiện. Đây là tài liệu hướng dẫn trong một kế hoạch kiểm thử dự án. Trong thời gian kiểm thử, hoạt động giám sát được thực hiện để đảm bảo kiểm thử được tiến triển theo kế hoạch và để đảm bảo rằng những rủi ro đang được xử lý thích hợp và nếu có bất kỳ thay đổi nào đối với các hoạt động kiểm thử được yêu cầu sau đó kiểm soát trực tiếp sẽ được phát hành cho các quy trình kiểm thử hoặc quy trình kiểm thử con có liên quan. Trong chu kỳ thời gian của giám sát và kiểm soát, các báo cáo trạng thái kiểm thử có thể được lập nên để thường xuyên thông báo cho các bên liên quan đến tiến độ kiểm thử. Kết quả tổng thể của việc kiểm thử cho dự án là tài liệu trong báo cáo kết thúc kiểm thử dự án.
Các quy trình quản lý kiểm thử được mô tả trong hình 4.
Hình 4: Các quy trình quản lý kiểm thử
Kiểm thử tổng thể cho một dự án thường được chia nhỏ thành các quy trình kiểm thử con (ví dụ như kiểm thử thành phần, kiểm thử hệ thống, kiểm thử khả năng sử dụng, kiểm thử hiệu năng) và cũng cần được quản lý, thực thi và báo cáo một cách tương tự như dự án kiểm thử tổng thể. Các quy trình quản lý kiểm thử cũng có thể được áp dụng cho quy trình kiểm thử con. Ví dụ về kế hoạch quy trình kiểm thử con là một kế hoạch kiểm thư hệ thống, kế hoạch kiểm thử chấp nhận hoặc một kế hoạch kiểm thử hiệu năng.
Quy trình kiểm thử con có thể bao gồm cả kiểm thử tĩnh và kiểm thử động. Quy trình kiểm thử động được đưa ra trong Hình 5 và mô tả đầy đủ trong TCVN 12849-2:2020 (ISO/IEC/IEEE 29119-2:2013). Quy trình để kiểm thử tĩnh được mô tả trong các tiêu chuẩn đã được công bố khác (ví dụ như IEEE 1028).
Hình 5: Quy trình kiểm thử động
5.3 Quy trình kiểm thử tổng quát trong vòng đời phần mềm
Phần mềm có một vòng đời dự kiến từ sự hình thành ban đầu đến lúc ngừng hoạt động. Kiểm thử phần mềm diễn ra trong bối cảnh rộng lớn hơn của việc phát triển và bảo trì phần mềm. Chính điều này đưa ra một vòng đời phát triển phần mềm và một số mối quan hệ giữa quy trình con và quy trình kiểm thử.
TCVN 10539:2014 đưa ra một chu kỳ vòng đời phần mềm chi tiết. ISO/IEC 15288 đưa ra quy trình chu kỳ vòng đời của hệ thống một cách chi tiết. Một ví dụ về chu kỳ vòng đời của hệ thống được minh họa trong hình 6.
Hình 6: Ví dụ về chu kỳ vòng đời phần mềm
Một chu kỳ vòng đời phần mềm thường bao gồm nhiều chu kỳ vòng đời con. Hình 6 cho thấy một chu kỳ vòng đời phần mềm thường được tạo thành từ một hoặc nhiều chu kỳ vòng đời phát triển và một hoặc nhiều chu kỳ cuộc đời vận hành.
Chu kỳ thời gian từ lúc khởi tạo đến lúc phát hành bản đầu tiên được gọi là vòng đời phát triển và là một tập con của chu kỳ vòng đời phần mềm. Một chu kỳ vòng đời phát triển được quản lý và kiểm soát trong một dự án phát triển
Từ thời điểm hệ thống được phát hành bản đầu tiên đi vào hoạt động, hệ thống vẫn duy trì hoạt động cho đến khi dừng hẳn; điều này có thể là một vài giờ tới vài thập kỷ. Chu kỳ hoạt động thường bao gồm khoảng thời gian mà một phiên bản cụ thể của hệ thống được sử dụng, trong khi một phiên bản mới đang được phát triển để phát hành. Bất kỳ phiên bản mới nào được phát triển phải được coi là một dự án phát triển của chính nó với các kiểm thử tương ứng đòi hỏi. Thông thường hoạt động bảo trì cũng được thiết lập để khả năng sẵn có của hệ thống và hoạt động đúng dự kiến.
Nó cũng có thể có ca kiểm thử xảy ra trên một hệ thống hoạt động mà không có một dự án phát triển tương ứng - ví dụ "chạy thử" kiểm thử phát hiện thảm họa. Các quy trình từ tiêu chuẩn này cũng có thể được áp dụng trong những tình huống như vậy.
Kiểm thử cũng được thực hiện để đánh giá phần mềm đã được mua để đáp ứng yêu cầu kinh doanh. Khung công việc cho việc đánh giá và kiểm thử mua phần mềm thương mại sẵn sàng (COTS) có thể được tìm thấy trong TCVN 10540:2014.
5.3.1 Các quy trình con dự án phát triển và kết quả
Phát triển hệ thống và phần mềm thường bao gồm một vài khối xây dựng chung. Trong ngành công nghiệp phần mềm các khối xây dựng thường được gọi là các 'giai đoạn', tầng, 'bước', 'mức', hoặc nhiều khi khái quát là "Quy trình phát triển con”.
Có thể bao gồm:
- Yêu cầu kỹ thuật;
- Thiết kế kiến trúc;
- Thiết kế chi tiết; và
- Viết mã.
Các biện pháp đặc biệt để phát triển hệ thống thông qua một tổ chức hoặc dự án sẽ xác định làm thế nào những quy trình phát triển con được bố trí. Trong một dự án phát triển tuần tự, phân tích yêu cầu có thể là một quá trình ban đầu của chính nó. Trong một dự án phát triển linh hoạt, yêu cầu này sẽ được xác định cho mỗi lần giao hàng, mỗi vài tuần.
Trong từng quy trình con phát triển một cái gì đó được sản sinh; có thể là một tài liệu chi tiết cấu trúc bậc cao hoặc có thể được chính thức ghi nhận quyết định bằng tài liệu hoặc phi tài liệu..
Trong bất kỳ dự án phát triển cho trước, các quy trình con phát triển riêng có thể được thực hiện một lần hoặc lặp đi lặp lại khi có yêu cầu. Quy trình con phát triển tổng quát và các sản phẩm công việc liên quan, các hệ thống con và hệ thống phần mềm hoàn thành được mô tả trong hình 7.
Hình 7: Ví dụ về quy trình con phát triển
Mỗi một sản phẩm công việc, thành phần hệ thống phần mềm và hệ thống phần mềm hoàn chỉnh là một hạng mục kiểm thử tiềm năng.
Lưu ý rằng nó nằm ngoài phạm vi của tiêu chuẩn này để xác định một mỏ hình phát triển. Các giai đoạn được mô tả trong hình 7 chỉ là ví dụ cần thiết để minh họa cách kiểm thử áp dụng để phát triển.
5.3.2 Hoạt động bảo trì và kết quả
Họa động bảo trì diễn ra trong một phần của vòng đời phần mềm hoạt động, tức là sau khi phát triển ban đầu và sẽ được quản lý trong bối cảnh của quản lý ứng dụng hoặc khung quy trình quản lý dịch vụ CNTT. Một dự án có thể được thiết lập để bảo trì liên tục và điều này thường là khá khác nhau so với một dự án phát triển, ví dụ như các mô hình tài chính có thể khác nhau. Một mô hình tài chính phổ biến là một số tiền được duyệt để bảo trì trong một khoảng thời gian cụ thể; điều này có thể được ghi trong một thỏa thuận mức dịch vụ (SLA) giữa khách hàng và các tổ chức bảo trì.
Quy trình hoạt động bảo trì đang diễn ra thường liên quan với việc duy trì một mức độ chấp nhận hoặc đồng ý về độ tin cậy và tính sẵn sàng của hệ thống. Điều này liên quan đến việc phát hành của các phiên bản mới của hệ thống với các chỉnh sửa các khiếm khuyết ưu tiên cao nhất được tìm thấy trong vận hành và có thể tạo ra các thay đổi ưu tiên cao cho các chức năng. Các phiên bản này có thể được phát hành như là các hệ thống 'đang hoạt động' trên cơ sở đặc biệt, khi được chọn chỉnh sửa và các thay đổi hoàn tất hoặc trên cơ sở tần suất cố định, ví dụ 3 tháng. Nếu chu kỳ thời gian phát hành bảo trì là đặc biệt, các chỉnh sửa và/hoặc thay đổi bao gồm được lựa chọn, thực hiện và phát hành chúng thường được thực hiện càng sớm càng tốt. Nếu chu kỳ thời gian phát hành bảo trì cố định được sử dụng thì các chỉnh sửa và/hoặc thay đổi có thể được thực hiện trong khoảng thời gian đó với trình tự thực hiện dựa trên một ưu tiên thống nhất. Các kết quả chính của một giai đoạn phát hành như vậy được mô tả trong hình 8.
Hình 8: Ví dụ chu kỳ phát hành bảo trì
Tùy thuộc vào mục đích của việc phát hành, từng kết quả mô tả trong hình 8 có thể được tạo ra trong một chu kỳ phát hành duy nhất hoặc có thể chỉ là một tập con cần thiết. Ví dụ nó có thể là một sự điều chỉnh đặc biệt không ảnh hưởng đến các yêu cầu và thiết kế mà chỉ ảnh hưởng tới mã và hệ thống hoàn chỉnh; hoặc có thể là tất cả các sản phẩm công việc bị ảnh hưởng nhiều hơn một lần trước khi hệ thống đã sẵn sàng cho việc phát hành.
Chu kỳ phát hành bảo trì được lặp đi lặp lại khi cần thiết trong suốt vòng đời hoạt động của hệ thống.
5.3.3 Quy trình hỗ trợ cho vòng đời phát triển phần mềm
Trong một tổ chức, quy trình hỗ trợ được yêu cầu để hỗ trợ vòng đời phát triển phần mềm. Một trong số nay là:
- Đảm bảo chất lượng;
- Quản lý dự án;
- Quản lý cấu hình; và
- Cải tiến quy trình.
5.3.3.1 Đảm bảo chất lượng và kiểm thử
Đảm bảo chất lượng là một tập các quy trình hỗ trợ lập kế hoạch và có hệ thống và các hoạt động cần thiết để cung cấp niềm tin rằng một quy trình hoặc một sản phẩm công việc sẽ thiết lập đầy đủ các yêu cầu về kỹ thuật hoặc chất lượng.
Điều này đạt được bằng việc áp dụng các phương pháp, tiêu chuẩn, công cụ và kỹ năng được công nhận là phù hợp với bối cảnh. Quá trình đảm bảo chất lượng sử dụng các kết quả kiểm thử và các thông tin khác để điều tra, xếp hạng và báo cáo bất kỳ vấn đề nào (bao gồm cả rủi ro bất kỳ) trong việc thiết kế, lập kế hoạch hoặc thực hiện các quy trình công nghệ phần mềm.
Các biện pháp cần được thu thập trong quá trình kiểm thử khi chúng có thể cung cấp thông tin về chất lượng của quy trình kiểm thử và/hoặc các hạng mục kiểm thử và tính hiệu quả của ứng dụng của chúng trên từng dự án.
5.3.3.2 Quản lý dự án và kiểm thử
Quản lý dự án đề cập đến các quy trình hỗ trợ được sử dụng để lập kế hoạch và kiểm soát quá trình của một dự án bao gồm việc quản lý các dự án kiểm thử trong dự án tổng thể. Bất kể ai có trách nhiệm với từng quy trình, quản lý dự án và quy trình quản lý kiểm thử có liên quan chặt chẽ được mỏ tả trong hình 9.
Hình 9: Mối quan hệ giữa dự án tổng thể và dự án kiểm thử
Việc lập dự toán, phân tích rủi ro và lịch trình của các hoạt động kiểm thử nên được hợp nhất với kế hoạch dự án tổng thể. Kế hoạch dự án là một hạng mục thông tin từ quy trình quản lý dự án vì vậy là đầu vào cho quy trình quản lý kiểm thử khi nó được sử dụng để quản lý các dự án thử thử.
Trong suốt quá trình của dự án kiểm thử, biện pháp thu thập từ hoạt động kiểm thử chi tiết được phân tích bởi người quản lý kiểm thử và thông báo cho người quản lý dự án để phân tích trong bối cảnh dự án. Điều này có thể dẫn đến những thay đổi trong kế hoạch dự án ảnh hưởng đến dự án kiểm thử, kế hoạch được cập nhật và các chỉ thị thích hợp mà cần phải được cấp cho dự án kiểm thử để giúp đảm bảo rằng các dự án kiểm thử được giữ dưới sự kiểm soát.
Khi một quy trình kiểm thử con hoặc dự án kiểm thử đã hoàn thành, một báo cáo kết thúc tóm tắt và các kết quả của các quy trình kiểm thử con hoặc dự án kiểm thử được cung cấp cho nhà quản lý dự án.
5.3.3.3 Quản lý cấu hình và kiểm thử
Quản lý cấu hình là một tập các quy trình hỗ trợ mà kiểm thử tương tác. Mục đích của quản lý cấu hình là thiết lập và duy trì tính toàn vẹn của sản phẩm công việc. Đó là thực hành tốt để kiểm thử một hệ hống quản lý cấu hình của dự án của tổ chức trước khi sử dụng vận hành, để tìm hiểu xem có đáp ứng các yêu cầu tổ chức hoặc dự án.
Quy trình quản lý cấu hình bao gồm việc nhận dạng duy nhất, lưu trữ kiểm soát, kiểm tra phát hành, kiểm soát thay đổi và báo cáo trạng thái cho các sản phẩm công việc được lựa chọn, các thành phần hệ thống và các hệ thống trong suốt vòng đời của sản phẩm. Một đối tượng chịu sự quản lý của quản lý cấu hình được gọi là một hạng mục cấu hình. Các quy trình quản lý cấu hình là hướng sự kiện, nghĩa là chúng đều khởi đầu độc lập với nhau tùy thuộc vào yêu cầu của các quá trình khác.
Sản phẩm công việc từ quá trình kiểm thử, có thể được đặt dưới sự quản lý của quản lý cấu hình, bao gồm:
- Đặc tả kiểm thử của tổ chức (ví dụ: Chính sách kiểm thử, Chiến lược kiểm thử của tổ chức);
- Kế hoạch kiểm thử;
- Đặc tả kiểm thử; và/hoặc
- Hạng mục cấu hình môi trường kiểm thử như: công cụ kiểm thử, dữ liệu kiểm thử (cơ sở), trình điều khiển.
Tất cả ba lớp trong mô hình quy trình kiểm thử được xác định trong tiêu chuẩn này có thể tương tác với quản lý cấu hình. Các hạng mục cấu hình được cung cấp cho một quy trình kiểm thử là các sản phẩm công việc cần đưa vào và thuộc quản lý của quản lý cấu hình. Các hạng mục cấu hình phân phối từ một quy trình kiểm thử là các sản phẩm được tạo ra bởi quy trình kiểm thử mà cần phải được đặt dưới sự quản lý của quản lý cấu hình.
Quy trình kiểm thử của tổ chức có thể ví dụ, tạo ra một chính sách kiểm thử và một chiến lược kiểm thử của tổ chức, được đặt dưới sự quản lý của quản lý cấu hình. Người quản lý kiểm thử dự án có thể trích xuất một bản sao của kế hoạch dự án đó là thuộc quyền quản lý của quản lý cấu hình và sử dụng như là cơ sở cho việc kế hoạch kiểm thử dự án, sau đó được đặt dưới sự quản lý của quản lý cấu hình. Thực hiện quy trình kiểm thử con động có thể trích xuất một bản sao các đặc tả yêu cầu là thuộc quyền quản lý của quản lý cấu hình và sử dụng như là cơ sở cho đặc tả kiểm thử, sau đó được đặt dưới sự quản lý của quản lý cấu hình.
Đối với mục đích của việc có thể tái tạo lại một vấn đề vì vậy nó có thể được phân tích thêm, đó là thực hành tốt (nếu có thể) để làm cho hệ thống quản lý cấu hình toàn diện và đủ mạnh tại bất kỳ điểm nào trong tương lai một kiểm thử có thể được lặp đi lặp lại dưới các điều kiện chính xác tương tự như trước. Có thể chấp nhận thực tế để loại trừ một số kiểu kiểm thử - ví dụ, kiểm thử hạng mục - từ yêu cầu có tính lặp lại miễn là các ngoại lệ được công bố trong chiến lược kiểm thử của tổ chức hoặc kế hoạch dự án.
Các báo cáo quản lý cấu hình cho một quy trình kiểm thử cần cung cấp các biện pháp chi tiết mà có thể cần thiết để phân tích tiến độ và trạng thái của sự cố.
5.3.3.4 Cải tiến quy trình và kiểm thử
Cải tiến quy trình sẽ hành động để thay đổi quy trình của một tổ chức để chúng đáp ứng các mục tiêu kinh doanh của tổ chức có hiệu lực và hiệu quả hơn.
Các quy trình kiểm thử và quá trình cải tiến quy trình tương tác theo hai cách:
1. Các quy trình kiểm tra cung cấp thông tin cơ sở về những hành động cải tiến quy trình có thể được (cùng với thông tin thu được từ các nguồn khác); và
2. Các quy trình kiểm thử có thể chính là đối tượng để cải tiến quy trình.
Khi kiểm thử cung cấp thông tin tương tác để cải thiện quá trình thường là giữa các quy trình quản lý kiểm thử được áp dụng ở mức độ dự án và quá trình cải tiến quy trình. Biện pháp kiếm thử có thể được truyền trực tiếp từ các quá trình quản lý kiểm thử. Quá trình cải tiến quy trình cũng có thể có được một số số liệu kiểm thử liên quan đến từ quản lý cấu hình, nếu điều này được đặt ra và bao gồm kiểm soát thay đổi.
Trong trường hợp của các quy trình kiểm thử là đối tượng cải tiến, điều này có thể nằm trong phạm vi của một việc cải tiến tổ chức rộng hoặc nó có thể nằm trong phạm vi của quá trình cải tiến quy trình kiểm thử một cách độc lập của tổ chức tổng thể. Trong cả hai trường hợp, quá trình cải tiến quy trình cần được thông tin từ nhiều nguồn khác nhau để chẩn đoán mà các quy trình kiểm thử để cải tiến và cách thức để xác định các quy trình kiểm thử được cải tiến. Điều này sẽ dẫn đến một phiên bản mới của từng quy trình kiểm thử được lựa chọn, sau đó phải được triển khai cho người sử dụng thích hợp. Cải tiến được xác định chỉ có thể áp dụng cho một dự án cho trước hoặc có thể được triển khai trên tất cả các dự án trong tổ chức. Các quy trình kiểm thử mới phải được giám để đánh giá xem chúng tạo ra giá trị hoàn vốn đầu tư.
Không thể kiểm thử một hệ thống phần mềm thấu đáo, do đó kiểm thử là một hoạt động lấy mẫu. Một loạt các khái niệm kiểm thử (ví dụ: thực tiễn, kỹ thuật và các kiểu) tồn tại để hỗ trợ trong việc lựa chọn một màu thích hợp để kiểm thử và chúng được thảo luận và trình bày trong tiêu chuẩn này. Một tiền đề quan trọng của tiêu chuẩn này là ý tưởng thực hiện các kiểm thử tối ưu trong các bối cảnh và ràng buộc nhất định sử dụng phương pháp tiếp cận dựa trên rủi ro.
Điều này đạt được bằng cách xác định các giá trị có liên quan của các chiến lược khác nhau để kiểm thử, về các rủi ro giảm nhẹ cho các bên liên quan của hệ thống hoàn chỉnh và cho các bên liên quan đến phát triển hệ thống. Thực hiện kiểm thử dựa trên rủi ro, đảm bảo rằng các rủi ro có mức ưu tiên cao nhất nhận được sự chú ý cao nhất trong quá trình kiểm thử. Các tiêu chuẩn khác có thể giúp xác định rủi ro của hệ thống trong vận hành, ví dụ như tiêu chuẩn ISO/IEC 16085: “Quản lý rủi ro”.
Rủi ro có thể được phân loại theo một số cách. Ví dụ, rủi ro có thể được xác định trong các điều khoản của việc không thỏa mãn và/hoặc yêu cầu pháp lý, không đáp ứng được các nghĩa vụ theo hợp đồng, liên quan đến chậm tiến độ và hoàn thành dự án (rủi ro dự án) và một sản phẩm công việc không đạt được các cơ chế dự kiến của nó (rủi ro sản phẩm).
Khi thực hiện kiểm thử dựa trên rủi ro, phân tích rủi ro được sử dụng để xác định và ghi rủi ro, do đó những rủi ro nắm bắt được trong hệ thống cung cấp (và cho sự phát triển của hệ thống này) có thể ghi được, ưu tiên, phân loại và sau đó giảm nhẹ.
5.4.1 Sử dụng kiểm thử dựa trên rủi ro trong quy trình kiểm thử của tổ chức
Chính sách kiểm thử của tổ chức thiết lập bối cảnh cho việc kiểm thử trong tổ chức. Khi làm như vậy nó phải xác định các rủi ro của tổ chức có ảnh hưởng đến quy trình kiểm thử. Ví dụ, một tổ chức sản xuất phần mềm y tế có thể phải tuân thủ các tiêu chuẩn chất lượng nghiêm ngặt; Chính sách kiểm thử của tổ chức cho các tổ chức này có thể bao gồm các yêu cầu để giải quyết các tiêu chuẩn an toàn liên quan và do đó cố gắng để giảm thiểu ảnh hưởng này đến việc kinh doanh.
Chiến lược kiểm thử của tổ chức cần đưa ra các phương pháp quản lý rủi ro trong quy trình kiểm thử. Trong ví dụ trên của một tổ chức sản xuất phần mềm y tế, chiến lược kiểm thử của tổ chức có thể cung cấp các hướng dẫn về cách kiểm thử cần được thực hiện trong tổ chức để góp phần vào việc quản lý rủi ro của việc không tuân thủ các tiêu chuẩn quy định. Thêm vào đó chiến lược kiểm thử của tổ chức có thể uỷ quyền cho một phương pháp cụ thể để áp dụng quản lý rủi ro sẽ được sử dụng trong các quy trình quản lý kiểm thử.
5.4.2 Sử dụng kiểm thử dựa trên rủi ro trong quy trình quản lý kiểm thử
Hồ sơ rủi ro được phân loại (tập xác định các rủi ro và lưu chúng) được sử dụng để xác định các kiểm thử cần được thực hiện trên các dự án này được mô tả trong các chiến lược kiểm thử, đó là một phần trong kế hoạch kiểm thử. Ví dụ, lưu rủi ro có thể được sử dụng để xác định tính chặt chẽ của kiểm thử (ví dụ như quy trình kiểm thử con, kỹ thuật thiết kế kiểm thử, tiêu chí hoàn thành kiểm thử). Các ưu tiên của rủi ro có thể được sử dụng để xác định lịch trình kiểm thử (kiểm thử liên quan đến các rủi ro ưu tiên cao hơn thường được giải quyết trước). Các loại rủi ro có thể được sử dụng để quyết định hình thức thích hợp nhất để thực hiện kiểm thử. Ví dụ, nếu có một rủi ro biết được trong các giao diện giữa các thành phần khi đó việc kiểm thử tích hợp là cần thiết và nếu có một rủi ro biết được rằng người dùng có thể tìm kiếm các ứng dụng rất khó khăn để sử dụng khi đó việc kiểm thử khả năng sử dụng là cần thiết.
Đó là thực tiễn tốt liên quan đến phạm vi của các bên liên quan có thể trong các hoạt động này để đảm bảo rằng càng nhiều rủi ro có thể được xác định và các hành động giảm nhẹ rủi ro tương ứng (hoặc không - chúng ta có thể quyết định không giải quyết một số rủi ro) được thống nhất.
Một lợi ích của việc sử dụng phương pháp này là vào thời điểm bất kỳ rủi ro phát sinh có thể chỉ cần thông báo cho các bên liên quan như các rủi ro còn tồn tại.
Các kết quả thực hiện kiểm thử chống lại các rủi ro biết được và cũng là tình trạng phát triển kinh doanh một cách tự nhiên sẽ gây ra hồ sơ rủi ro thay đổi theo thời gian do đó yêu cầu kiểm thử dựa trên rủi ro được coi là một hoạt động đang diễn ra.
5.4.3 Sử dụng kiểm thử dựa trên rủi ro trong các quy trình kiểm thử động
Hồ sơ rủi ro được sử dụng để cung cấp hướng dẫn cho tất cả các quy trình kiểm thử động. Trong quá trình thiết kế kiểm thử các rủi ro sản phẩm được sử dụng để thông báo cho người kiểm thử để các kỹ thuật thiết kế kiểm thử thích hợp nhất được áp dụng. Nó cũng có thể được sử dụng để hướng dẫn việc phân tích kiểm thử xảy ra trong quy trình thiết kế kiểm thử, với các khu vực có rủi ro cao hơn cần nỗ lực nhiều hơn so với các vùng có rủi ro thấp. Rủi ro cũng có thể được sử dụng đề ưu tiên các tập tính năng và một khi chúng có nguồn gốc, điều kiện kiểm thử và các ca kiểm thử.
Thực hiện kiểm thử động là một hoạt động giảm thiểu rủi ro. Chạy các ca kiểm thử giảm thiểu rủi ro vì nếu kiểm thử thành công thì sau đó khả năng của các rủi ro xảy ra thường là thấp và do đó tổng số rủi ro được giảm. Tương tự như vậy, nếu kiểm thử nghiệm thất bại, rủi ro có thể tăng. Quá trình báo sự cố kiểm thử sau đó sẽ được sử dụng để xác định xem ca kiểm thử thất bại có dẫn đến một vấn đề hoặc yêu cầu nghiên cứu thêm.
Một dự án kiểm thử thường được cấu trúc thành một số quy trình kiểm thử con dựa trên chiến lược kiểm thử dự án. Một quy trình kiểm thử con có thể được kết hợp với một đoạn chu kỳ vòng đời phần mềm và/hoặc tập trung vào thuộc tính chất lượng cụ thể. Một quy trình kiểm thử con có thể bao gồm cả kiểm thử tĩnh và kiểm thử động.
Mỗi một quy trình kiểm thử con được quản lý bằng cách áp dụng các quy trình quản lý kiểm thử cho nó. Một quy trình kiểm thử con bắt đầu với kế hoạch kiểm thử, việc giám sát và kiểm soát hoạt động kiểm thử thực hiện liên tục trong quá trình kiểm thử cho một quy trình kiểm thử con và các thông tin từ các hoạt động giám sát có thể đem đến các kế hoạch để được xem xét lại cho phù hợp.
Lập kế hoạch kiểm thử liên quan đến việc xác định mục tiêu kiểm thử, phạm vi kiểm thử và các rủi ro liên quan đến quy trình kiểm thử con. Kết quả của hướng dẫn này là chiến lược cho quy trình kiểm thử con, bao gồm cả việc lập kế hoạch kiểm thử tĩnh và kiểm thử động cho quy trình kiểm thử con. Trong một số trường hợp những gì được nêu trong chiến lược kiểm thử dự án có thể được sử dụng trực tiếp trong chiến lược đối với quy trình kiểm thử con, trong các trường hợp khác các quyết định cụ thể cho quy trình kiểm thử con sẽ phải được thực hiện dựa trên các rủi ro cụ thể để xử lý.
Khi mô tả một quy trình kiểm thử con điều quan trọng là phải xác định các tính năng của hạng mục kiểm thử cần và không được kiểm thử. Điều này là để đảm bảo rằng những mong muốn liên quan đến phạm vi của kiểm thử được hiểu rõ và đúng cách.
Sẽ là điều bất thường khi một quy trình kiểm thử con chỉ bao gồm một vòng lặp kiểm thử động hoặc kiểm thử tĩnh. Nếu chỉ có một vòng lặp kiểu kiểm thử được xác định có thể là cần thiết để lặp lại nó, ví dụ như để đáp ứng tiêu chí hoàn thành kiểm thử, quy trình kiểm thử động lặp đi lặp lại thường được gọi tắt là kiểm thử lại và kiểm thử hồi quy. Kiểm thử lại và kiểm thử hồi quy có thể được thực hiện để xác định rằng các thay đổi được thực hiện cho một sản phẩm công việc để chỉnh sửa các khiếm khuyết và các khiếm khuyết được chỉnh sửa không xảy ra sau này (để biết thêm thông tin xem mục 5.5.5).
Ví dụ về quy trình kiểm thử con được minh họa trong hình 10.
Hình 10: Quy trình kiểm thử con tổng quát
Số lượng các quy trình kiểm thử con trong một dự án kiểm thử phụ thuộc vào chiến lược kiểm thử và các giai đoạn vòng đời xác định cho toàn bộ dự án. Tuy nhiên, không phụ thuộc vào vòng đời phát triển (tức là một chu kỳ phát triển tuần tự hoặc linh hoạt không xác định số lượng quy trình kiểm thử con cần thiết của chính nó).
Các ví dụ về các quy trình kiểm thử con được trình bày chi tiết trong Phụ lục D.
Mục tiêu kiểm thử, hạng mục kiểm thử, cơ sở kiểm thử và rủi ro là cụ thể đối với một quy trình kiểm thử con và các hướng dẫn lựa chọn các hoạt động kiểm thử để thực hiện trong một quy trình kiểm thử con cũng như các kỹ thuật thiết kế kiểm thử để sử dụng. Ví dụ về các mục tiêu kiểm thử, hạng mục kiểm thử, cơ sở kiểm thử và kỹ thuật thiết kế kiểm thử được cung cấp dưới đây.
Một kiểm thử được thực hiện để đạt được một hoặc nhiều mục tiêu. Các mục tiêu kiểm thử bao phủ bởi tiêu chuẩn này bao gồm:
- Cung cấp thông tin cho các hoạt động quản lý rủi ro;
- Cung cấp thông tin về chất lượng của sản phẩm;
- Đánh giá liệu sản phẩm đã đáp ứng được mong đợi của các bên liên quan hay không;
- Đánh giá liệu các khiếm khuyết đã được loại bỏ hoàn toàn và không có tác động phụ bất lợi;
- Đánh giá liệu việc thực hiện thay đổi đúng không gây tác dụng phụ bất lợi; và
- Đánh giá thực hiện các yêu cầu (tức là quy định, thiết kế, hợp đồng, vv).
Kiểm thử được hoàn thành để thực hiện các mục tiêu kiểm thử cho một tính năng hay tập tính năng, các loại tính năng được kiểm thử sẽ xác định các kiểu kiểm thử sẽ được yêu cầu, các tính năng có đặc tính chất lượng mà họ đang dự định để thực hiện. Thành phần của các đặc tính chất lượng cho một tính năng hoặc một tập tính năng cho phép người kiểm thử xác định các kiều kiểm thử có thể được sử dụng để thực hiện các mục tiêu kiểm thử.
Có thể là chỉ một số các mục tiêu kiểm thử có liên quan với một quy trình kiểm thử con hoặc kiểu hạng mục kiểm thử cụ thể. Quyết định mục tiêu kiểm thử có liên quan cho một hạng mục kiểm thử có thể hỗ trợ trong việc xác định các quy trình kiểm thử con chính xác để áp dụng. Ví dụ, trong kiểm thử một sản phẩm thương mại sẵn sàng, mục tiêu kiểm thử là đánh giá rằng các khiếm khuyết đã được cố định có thể không có liên quan theo dự kiến mà nhà cung cấp đã hoàn thành kiểm thử đầy đủ để tìm và hiệu sửa các khiếm khuyết. Do đó việc chấp nhận quy trình kiểm thử con được áp dụng trong bối cảnh này để đáp ứng các mục tiêu kiểm thử rằng sự thay đổi đã được thực hiện mà không có tác dụng phụ bất lợi.
Kiểm thử được thực hiện trên một hạng mục kiểm thử về những gì được kỳ vọng của các hạng mục kiểm thử; kỳ vọng này được mô tả bởi các cơ sở kiểm thử (xem mục 5.5.4). Một hạng mục kiểm thử là kết quả của một hoạt động, chẳng hạn như quản lý, phát triển, bảo trì, kiểm thử chính nó hoặc các quá trình hỗ trợ khác.
Ví dụ về các hạng mục kiểm thử bao gồm:
- Hạng mục kiểm thử mã liên quan:
o Thành phần phần mềm thực thi;
o Phân hệ;
o Hệ thống hoàn chỉnh.
- Hạng mục kiểm thử tài liệu liên quan:
o Một kế hoạch, ví dụ kế hoạch dự án, kế hoạch kiểm thử hoặc kế hoạch quản lý cấu hình;
o Đặc tả yêu cầu;
o Thiết kế kiến trúc;
o Thiết kế chi tiết;
o Mã nguồn;
o Kiểu cài đặt, ví dụ thủ công hoặc tiến trình cài đặt;
o Đặc tả kiểm thử và thủ tục kiểm thử.
Hạng mục cuối cùng trong danh sách trên chỉ ra rằng mặc dù đặc tả kiểm thử và thủ tục kiểm thử được phát triển bởi những người kiểm thử nhưng họ cũng phải chịu sự kiểm thử (kiểm thử tĩnh) khi họ có thể không có khiếm khuyết.
5.5.3 Kiểm thử đặc tính chất lượng
Tiêu chuẩn ISO/IEC 25010: “Mô hình chất lượng hệ thống và phần mềm” chỉ ra một mô hình về chất lượng phần mềm. Mô hình này mô tả tám đặc tính chất lượng, trong đó xác định các thuộc tính chất lượng của một hạng mục kiểm thử. Kiểm thử là một hoạt động mà các đánh giá đặc tính chất lượng quan trọng cho một hạng mục kiểm thử cho trước. Tám đặc tính chất lượng là:
- Sự phù hợp chức năng: mức độ mà các sản phẩm cung cấp các chức năng đáp ứng các nhu cầu đã nêu và ngụ ý khi sản phẩm được sử dụng dưới điều kiện quy định;
- Hiệu quả thực thi: thực hiện tương đối so với lượng tài nguyên được sử dụng trong các điều kiện đã nêu;
- Khả năng tương thích: mức độ mà hai hay nhiều hệ thống hoặc các thành phần có thể trao đổi thông tin và/hoặc thực hiện các chức năng cần thiết của chúng trong khi chia sẻ cùng một môi trường phần cứng hoặc phần mềm;
- Tính khả dụng: mức độ mà một sản phẩm có thể được sử dụng bởi người dùng quy định để đạt được mục tiêu cụ thể có hiệu quả, hiệu lực và sự hài lòng trong một bối cảnh cụ thể của việc sử dụng;
- Độ tin cậy: mức độ mà một hệ thống hay thành phần thực hiện các chức năng cụ thể theo các điều kiện quy định trong một chu kỳ thời gian nhất định;
- An toàn: mức độ mà thông tin và dữ liệu được bảo vệ vì vậy những người hoặc các hệ thống không được phép không thể đọc hoặc chỉnh sửa chúng và những người hoặc các hệ thống được ủy quyền không bị từ chối truy cập vào chúng;
- Khả năng bảo trì: mức độ hiệu quả và hiệu lực để các sản phẩm có thể được sửa đổi; và
- Khả năng di chuyển: mức độ mà một hệ thống hay thành phần có thể vận chuyển một cách hiệu quả từ phần cứng, phần mềm hoặc môi trường hoạt động tới môi trường khác.
Để kiểm thử một đặc tính chất lượng, một quy trình kiểm thử con có thể cần phải được khởi tạo. Ví dụ lập kế hoạch và thực hiện các kiểm thử để đánh giá các đặc tính chất lượng an toàn có thể yêu cầu một quy trình kiểm thử con an toàn (kiểm thử an toàn) sẽ được thực hiện.
Mỗi một đặc tính chất lượng có một số đặc tính con có thể kiểm thử để cung cấp một cái nhìn tổng thể về chất lượng của đặc tính. Cũng nên nhớ rằng không phải tất cả các đặc tính chất lượng được áp dụng cho tất cả các hệ thống, ví dụ như khả năng di chuyển có thể không quan trọng đối với một hệ thống nhúng một lần. Lưu ý các đặc tính chất lượng trên không nhất thiết phải đầy đủ và nó có thể thích hợp để xác định đặc tính chất lượng hơn nữa cho một hạng mục kiểm thử cụ thể.
Nó được phổ biến giữa các học viên kiểm thử để tham khảo các kiểm thử về đặc tính chất lượng chức năng như "kiểm thử chức năng" và để tham khảo các kiểm thử về các đặc tính chất lượng khác như kiểm thử "phi chức năng". Các kiểu thử được sử dụng để đánh giá các đặc tính chất lượng là khác hơn Iso với kiểm thử sự phù hợp chức năng thường là các kiểu kiểm thử như kiểu kiểm thử phi chức năng và có thể bao gồm các kiểu kiểm thử như kiểm thử tải, kiểm thử khả năng chịu tải, thử nghiệm thâm nhập, kiểm thử tính khả dụng, vv
Khi phát triển một kế hoạch kiểm thử, người quản lý kiểm thử cần xem xét tất cả các đặc tính chất lượng. Sự nhấn mạnh được đặt lên các kiểm thử của từng đặc tính chất lượng khác nhau và các đặc tính con của nó là có thể thay đổi tùy thuộc vào các biến số như:
- Hồ sơ rủi ro của hệ thống được phát triển; Ví dụ, một ứng dụng an toán quan trọng có thể nhấn mạnh độ tin cậy;
- Ngành công nghiệp mà hệ thống đang được phát triển; Ví dụ, một ứng dụng ngân hàng có thể đề cao về an toàn.
Trong tiêu chuẩn này, thuật ngữ "cơ sở kiểm thử" được sử dụng cho nền tảng của kiến thức (dưới mọi hình thức) mà từ đó các kiểm thử của một hạng mục có thể được lập kế hoạch, thiết kế, suy luận, triển khai và quản lý. Điều này có thể bao gồm việc lựa chọn cơ chế kiểm thử, tiêu chí đạt - không đạt, đầu vào, môi trường, thực tiễn và kỹ thuật. Bản chất của cơ sở kiểm thử cũng thay đổi qua các giai đoạn của chu kỳ vòng đời phát triển.
Ví dụ về các cơ sở kiểm thử có thể bao gồm:
- Kỳ vọng về định dạng và nội dung của các tài liệu, thông thường trong các hình thức tiêu chuẩn và/hoặc danh sách kiểm tra;
- Kỳ vọng của khách hàng/người dùng của một hệ thống phần mềm mới hoặc hiện tại thường ở dạng văn bản đặc tả yêu cầu. Đây có thể được xem như là mô tả chức năng/phi chức năng có "trách nhiệm" thông báo, trường hợp sử dụng, những câu chuyện của người dùng hoặc các hình thức khác của yêu cầu không chính thức hay chính thức bằng văn bản. Điều này cũng có thể bao gồm các tiêu chuẩn quy định cần tuân thủ với nhiều loại sản phẩm nhất định, ví dụ như phần mềm an toàn quan trọng cho ngành công nghiệp dược phẩm hoặc cho các hệ thống vận tải như tàu hỏa hoặc máy bay;
- Kinh nghiệm của người kiểm thử hoặc các chuyên gia với các chức năng cần thiết của người dùng hoặc với lịch sử của sản phẩm;
- Những kỳ vọng của các giao diện trực tiếp và/hoặc gián tiếp giữa các thành phần hệ thống phần mềm và/hoặc cùng tồn tại của các thành phần hệ thống phần mềm, thông thường trong các hình thức của một thiết kế kiến trúc như sơ đồ và/hoặc chính thức bằng văn bản mô tả giao thức; và/hoặc
- Kỳ vọng của việc thực hiện của các thành phần hệ thống phần mềm trong mã, thông thường là dưới hình thức thiết kế chi tiết.
Lưu ý rằng các hạng mục tương tự có thể xuất hiện như là một hạng mục kiểm thử trong một quy trình kiểm thử con và như là một cơ sở kiểm thử trong một quy trình kiểm thử con khác, ví dụ: một đặc tả yêu cầu có thể là hạng mục kiểm thử của một quy trình kiểm thử con tĩnh và là cơ sở kiểm thử của một quy trình kiểm thử con hệ thống sau này.
Các yêu cầu có thể được phân thành hai loại chính, cụ thể là:
- Yêu cầu chức năng - xác định những gì các hạng mục nên làm, việc sắp xếp để các đặc tính chất lượng phù hợp chức năng đưa ra trong tiêu chuẩn ISO/IEC 25010: “Mô hình chất lượng hệ thống và phần mềm”; và
- Yêu cầu phi chức năng - xác định cách thức các chức năng cần trình bày và cơ chế, việc sắp xếp các đặc tính chất lượng khác được đưa ra trong tiêu chuẩn ISO/IEC 25010: “Mô hình chất lượng hệ thống và phần mềm”. Các yêu cầu phi chức năng có liên quan đến một số hoặc tất cả các tính năng và yêu cầu chức năng thông thường có liên quan đến yêu cầu phi chức năng thích hợp hoặc là cá nhân hoặc theo nhóm.
5.5.5 Kiểm thử lại và kiểm thử hồi quy
Kiểm thử lại được kiểm thử để đánh giá liệu một giải pháp cho một sự cố đã khắc phục vấn đề ban đầu. Kiểm thử lại thường được thực hiện bằng cách chạy lại các ca kiểm thử tạo ra các kết quả không theo dự kiến đã dẫn đến việc xác định các vấn đề ban đầu. Tuy nhiên để kiểm thử lại một cách hiệu quả, các điều kiện kiểm thử mới có thể được xác định, phân tích và các ca kiểm thử mới được xây dựng.
Kiểm thử hồi quy là kiểm thử có chọn lọc của một hệ thống hoặc thành phần mà trước đó đã được kiểm thử để xác minh rằng những sửa đổi đã không gây ra các tác dụng phụ không lường trước và rằng hệ thống hoặc thành phần vẫn phù hợp với yêu cầu ban đầu của nó. Mục đích của kiểm thử hồi quy là để xác định rằng những sửa đổi đã không gây ra các khiếm khuyết trong các phần không thay đổi của hệ thống.
Điều quan trọng là khi lập kế hoạch kiểm thử xem xét cả kiểm thử hồi quy và kiểm thử lại khi cả hai thường được yêu cầu đề hoàn thành kiểm thử cho một quy trình con. Thời gian cần phải được tính vào tiến độ thực hiện kiểm thử cho cả hai hoạt động.
5.5.6 Kỹ thuật thiết kế kiểm thử
Kỹ thuật thiết kế kiểm thử tồn tại cho kiểm thử tĩnh và kiểm thử động. Mục đích của một kỹ thuật thiết kế kiểm thử là để hỗ trợ những người kiểm thử về các ca kiểm thử trong việc tìm kiếm các khiếm khuyết một cách hiệu quả nhất có thể. Kiểm thử tĩnh thường đạt được điều này bằng cách xác định các khiếm khuyết rõ ràng ("vấn đề") trong tài liệu các hạng mục kiểm thử hoặc bất thường trong mã nguồn. Kiểm thử động đạt được điều này bằng cách tạo ra những thất bại của các hạng mục kiểm thử thực thi.
5.5.6.1 Kỹ thuật thiết kế kiểm thử tĩnh
Kiểm thử tĩnh có thể bao gồm một loạt các hoạt động, ví dụ phân tích mã tĩnh, phân tích khả năng truy xuất nguồn gốc tài liệu chéo và soát xét để tìm các vấn đề và cung cấp các thông tin khác về các sản phẩm phần mềm.
Kiểm thử tĩnh là một hình thức kiểm thử thường bao gồm như là một phần của một chiến lược kiểm thử và trong phạm vi tiêu chuẩn này. Các tiêu chuẩn quốc tế khác hiện tại mô tả các kỹ thuật có thể được sử dụng để thực hiện việc kiểm thử tĩnh. Mục này giới thiệu các khái niệm của kiểm thử tĩnh và cho mô tả mối quan hệ với các tiêu chuẩn khác.
Kỹ thuật soát xét và quy trình hữu ích trong việc phát triển phần mềm được định nghĩa trong tiêu chuẩn IEEE 1028: 2008. Hoạt động xác minh và xác nhận được định nghĩa trong tiêu chuẩn IEEE 1012 (xem Phụ lục A). Mục đích chính của bất kỳ các kỹ thuật thiết kế kiểm thử tĩnh là để tìm các khiếm khuyết, nhưng chúng cũng có mục đích thứ hai, ví dụ trao đổi có thể được sử dụng để trao đổi kiến thức, và đánh giá kỹ thuật để đạt được sự đồng thuận. Việc soát xét kỹ cũng có thể phục vụ mục đích ngăn ngừa các khiếm khuyết trong tương lai. Các kiểu kỹ thuật thiết kế kiểm thử tĩnh được lựa chọn trong bất kỳ tình huống cụ thể nào không phụ thuộc nhiều vào kiểu hạng mục kiểm thử, cũng như các rủi ro có liên quan (các rủi ro mức cao hơn thì các kỹ thuật thiết kế kiểm thử tĩnh cao hơn được đề nghị) và mục tiêu thứ hai của kỹ thuật thiết kế kiểm thử tĩnh.
Trong khi kiểm thử tĩnh thường xuyên nằm trong phạm vi của hoạt động kiểm thử phần mềm của một tổ chức hoặc dự án, chỉ được xử lý trong trong bộ tiêu chuẩn kiểm thử phần mềm TCVN 12849 (ISO/IEC/IEEE 29119), chi tiết trong tiêu chuẩn TCVN 12849-1:2020 (ISO/IEC/IEEE 29119-1:2013) và bởi các tài liệu tham khảo trên. Kỹ thuật và quy trình cho kiểm thử tĩnh không được đề cập trong tiêu chuẩn TCVN 12849 (ISO/IEC/IEEE 29119).
5.5.6.2 Kỹ thuật thiết kế kiểm thử động
Kỹ thuật thiết kế kiểm thử cho kiểm thử động là kỹ thuật xác định các điều kiện kiểm thử, hạng mục mức bao phủ kiểm thử và sau đó ca kiểm thử được thực hiện trên một hạng mục kiểm thử. Các kỹ thuật thiết kế kiểm thử động được phân thành ba loại chính dựa trên các yếu tố đầu vào kiểm thử thu được. Các phân loại này là các kỹ thuật dựa trên đặc tả, dựa trên cấu trúc và dựa trên kinh nghiệm. TCVN 12849-4:2020 (ISO/IEC/IEEE 29119-4:2015) mô tả chi tiết từng kỹ thuật thiết kế kiểm thử động.
Kỹ thuật thiết kế kiểm thử dựa trên đặc tả được sử dụng để lấy các ca kiểm thử từ cơ sở kiểm thử mô tả các hành vi dự kiến của các hạng mục kiểm thử. Với kỹ thuật kiểm thử này cả phần đầu vào của các ca kiểm thử và kết quả dự kiến sẽ được bắt nguồn từ cơ sở kiểm thử. Sự lựa chọn trong đó kỹ thuật thiết kế kiểm thử dựa trên đặc tả để sử dụng trong bất kỳ tình huống cụ thể phụ thuộc vào bản chất của các cơ sở kiểm thử và/hoặc các hạng mục kiểm thử và về những rủi ro có liên quan. Ví dụ về kỹ thuật thiết kế kiểm thử dựa trên đặc tả bảo phủ trong tiêu chuẩn TCVN 12849-4:2020 (ISO/IEC/IEEE 29119- 4:2015) là ranh giới phân tích giá trị, kiểm thử chuyển đổi trạng thái và kiểm thử bảng quyết định..
Kỹ thuật thiết kế kiểm thử dựa trên cấu trúc được sử dụng để thu được các ca kiểm thử từ đặc tính cấu trúc, ví dụ như cấu trúc của mã nguồn hoặc cấu trúc danh mục. Nếu các kỹ thuật được áp dụng cho mã nguồn ứng dụng, sau đó kết quả dự kiến đối với ca kiểm thử được bắt nguồn từ cơ sở kiểm thử. Việc lựa chọn kỹ thuật thiết kế kiểm thử dựa trên cấu trúc để sử dụng trong bất kỳ trường hợp cụ thể nào phụ thuộc vào bản chất của cơ sở kiểm thử và về các rủi ro có liên quan, các kỹ thuật nay được định nghĩa và mô tả chi tiết trong tiêu chuẩn TCVN 12849-4:2020 (ISO/IEC/IEEE 29119-4:2015) “Kỹ thuật hệ thống và Phần mềm - Kiểm thử phần mềm - Phần 4: Kỹ thuật kiểm thử”. Ví dụ về kỹ thuật thiết kế kiểm thử dựa trên cấu trúc bao phủ trong trong tiêu chuẩn TCVN 12849-4:2020 (ISO/IEC/IEEE 29119-4:2015) là kiểm thử nhánh, kiểm thử điều kiện và kiểm thử luồng dữ liệu.
Phương pháp tiếp cận dựa trên rủi ro để kiểm thử như trình bày trong mục 5.4, đã được áp dụng rộng rãi và là phương pháp tiếp cận cơ bản của bộ các tiêu chuẩn TCVN 12849 (ISO/IEC/IEEE 29119). Có một số cách thực hành khác nhau để lập kế hoạch và thực hiện kiểm thử cho một dự án. Cách thực hành truyền thống đã được kiểm thử trên cơ sở các yêu cầu, bắt nguồn từ các ca kiểm thử nhân công trước khi thực hiện kiểm thử và sử dụng kết hợp cả thực thực kiểm thử nhân công kiểm thử tự động. Việc sử dụng kiểm thử dựa trên rủi ro không có nghĩa là các thực hành này không thể được sử dụng như một phần của một kế hoạch kiểm thử bởi muốn khẳng định sự phù hợp với tiêu chuẩn TCVN 12849-2:2020 (ISO/IEC/IEEE 29119-2:2013). Sự lựa chọn của chiến lược kiểm thử được xác định bởi một loạt các rủi ro, chẳng hạn như các tổ chức, dự án và các hạng mục kiểm thử. Ví dụ, một tổ chức có thể phải đối mặt với rủi ro vi phạm hợp đồng nếu không đảm bảo rằng mọi yêu cầu được kiểm thử. Do đó sử dụng một thực hành dựa trên yêu cầu sẽ là một cách để quản lý rủi ro của tổ chức này. Mục này giới thiệu một số thực hành kiểm thử có thể được sử dụng như là một phần của một chiến lược kiểm thử tạo ra phù hợp với tiêu chuẩn TCVN 12849-2:2020 (ISO/IEC/IEEE 29119-2:2013). Nói chung nó không chắc rằng bất kỳ của các thực hành kiểm thử sẽ được sử dụng riêng biệt mà thay vào đó sẽ được sử dụng như là một phần của chiến lược kiểm thử lớn hơn.
Mục này đưa ra một số thực hành kiểm thử khác nhau được sử dụng hiện nay để chứng minh một số các tùy chọn có sẵn trong quá trình lập kế hoạch kiểm thử.
5.6.2 Kiểm thử dựa trên yêu cầu
Mục đích chính của kiểm thử dựa trên yêu cầu là để đảm bảo rằng các yêu cầu của hạng mục kiểm thử đã được giải quyết (tức là "bao phủ") trong khi kiểm thử, để xác định xem các hạng mục kiểm thử có đáp ứng các yêu cầu của người dùng cuối không. Ngoài ra, nó được sử dụng để thu thập và cung các cấp thông tin có giá trị khác cho các bên liên quan trong chu kỳ vòng đời, chẳng hạn như các khiếm khuyết được xác định trong các hạng mục kiểm thử. Bằng cách sử dụng thực hành này, các yêu cầu được sử dụng để thông báo cho việc ra quyết định xung quanh quá trình lập kế hoạch kiểm thử, thiết kế kiểm thử và thực thi. Lưu ý rằng kiểm thử dựa trên yêu cầu có thể được sử dụng một phần để hoàn thành các kết quả xác minh yêu cầu nêu trong tiêu chuẩn ISO/IEC 12207.
Kiểm thử dựa trên yêu cầu sử dụng chủ yếu trong kiểm kiểm theo kịch bản. Các ca kiểm thử được xây dựng trước khi thực hiện kiểm thử trong quá trình thiết kế kiểm thử và thực hiện. Các ca kiểm thử sau đó được thực hiện trong quá trình thực hiện kiểm thử tương ứng theo tiến độ được quy định trong thủ tục kiểm thử. Phân tích các kết quả thực hiện kiểm thử sau đó được sử dụng để tinh chỉnh kiểm thử, có thể đem lại thiết kế kiểm thử và kịch bản ca kiểm thử tiếp theo. Các ca kiểm thử tạo ra trong quá trình thiết kế kiểm thử thêm này được tài liệu hóa và thực hiện sau này trong chu kỳ vòng đời thực hiện kiểm thử.
Kiểm thử dựa trên yêu cầu có thể được hỗ trợ bởi các thực hành kiểm thử với ý định rằng chúng sẽ giúp đỡ để chứng minh rằng các yêu cầu đã được kiểm thử đầy đủ. Ngoài ra việc sử dụng kiểm thử dựa trên yêu cầu để đảm bảo tất cả các yêu cầu đã được đáp ứng, các thực hành khác (tức là kiểm thử dựa trên kinh nghiệm) có thể được sử dụng để giải quyết các rủi ro khác. Ví dụ, yêu cầu là bất thường khi không có các khiếm khuyết hồi quy còn lại trong một sản phẩm chuyển giao. Tuy nhiên kiểm thử thăm dò có thể được sử dụng như là một cách để giải quyết rủi ro hồi quy này.
Tính thực tế của việc sử dụng kiểm thử dựa trên yêu cầu phụ thuộc rất nhiều vào bối cảnh. Nếu các yêu cầu này là không đầy đủ hoặc không nhất quán thì kết quả kiểm thử có thể chịu tổn thất theo cách tương tự. Thậm chí ngay cả khi yêu cầu là đầy đủ nhưng vì nguy cơ hạn chế về ngân sách và thời gian nên không thể kiểm thử tất cả các yêu cầu. Khi yêu cầu được bổ sung thông tin vào các ưu tiên có liên quan của chúng thì điều này có thể được sử dụng như một phương tiện ưu tiên kiểm thử (trong trường hợp này phương pháp dựa trên rủi ro có thể được sử dụng để ưu tiên các yêu cầu có ưu tiên cao hơn). Trong thực tế, người kiểm thử sử dụng kiểm thử dựa trên yêu cầu thường xuyên sẽ bổ sung các yêu cầu cơ bản theo cách này để các (rủi ro cao nhất) yêu cầu quan trọng nhất được kiểm thử kỹ hơn và sớm hơn.
5.6.3 Kiểm thử dựa trên mô hình
Tất cả các kiểm thử sử dụng khái niệm về một mô hình đại diện cho cơ chế dự kiến của các hạng mục kiểm thử là có sẵn như là cơ sở kiểm thử. Mô hình này có thể được đại diện trong các hình thức yêu cầu ngôn ngữ tự nhiên, hình ảnh trí tuệ, phương trình toán học, ký hiệu đồ họa (ví dụ như sơ đồ chuyển trạng thái, sơ đồ UML) hoặc ma trận (ví dụ bảng quyết định) hoặc thông thường hơn là một kết hợp của chúng. Theo truyền thống, người kiểm thử sử dụng mô hình để tự thu được đầu vào kiểm thử và các kết quả dự kiến khi thực hiện kiểm thử dựa trên đặc tả và các kết quả dự kiến khi thực hiện kiểm thử dựa trên cấu trúc (ở đây đầu vào kiểm thử được rút ra bằng cách xem xét cấu trúc của hạng mục kiểm thử). Sau đó các kiểm thử được thực hiện hoặc bằng nhân công hoặc sử dụng công cụ kiểm thử.
Kiểm thử dựa trên mô hình sử dụng một thực hành cơ bản khác nhau, nhưng vẫn dựa trên một mô hình của cơ chế dự kiến. Sự khác biệt là với kiểm thử dựa trên mô hình là mô hình có thể hoàn toàn chính thức và/hoặc đủ chi tiết để thông tin kiểm thử hữu ích có thể được rút ra từ mô hình. Thông tin mô hình này có thể bao gồm các kế hoạch kiểm thử, thiết kế, thủ tục, đầu vào, rủi ro và/hoặc phỏng đoán. Các lợi thế của việc sử dụng kiểm thử dựa trên mô hình bao gồm việc tạo ra các thông tin kiểm thử, cải tiến mức độ tự động hóa trong chu kỳ vòng đời kiểm thử (lập kế hoạch tài liệu hướng dẫn) và xác định sớm của một số loại lỗi. Kết quả của mức độ tự động hóa này là có khả năng hàng triệu ca kiểm thử có thể được tạo ra, thực hiện và kiểm tra một cách tự động trong một khoảng thời gian ngắn.
Bối cảnh điển hình cho việc sử dụng kiểm thử dựa trên mô hình sẽ là một ứng dụng tới hạn, nơi một thất bại có thể dẫn đến mất mát lớn và nơi cơ chế yêu cầu của ứng dụng tuân theo mô hình trong một hình thức có thể được sử dụng bởi một công cụ kiếm thử dựa trên mô hình (và nhân viên có tay nghề cao có sẵn để tạo ra và cập nhật các mô hình). Các ký hiệu đồ họa UML thường được sử dụng làm cơ sở cho các mô hình này, mặc dù ký hiệu khác cũng được sử dụng. Xem xét hỗ trợ việc sử dụng nó sẽ được bảo trì ứng dụng trong tương lai được dự kiến một cách thường xuyên và sửa đổi các mô hình sẽ được dễ dàng hơn so với việc cập nhật các kịch bản kiểm thử tự động (mỗi khi mô hình được cập nhật, các công cụ kiểm thử dựa trên mô hình có thể tạo ra sau đó và chạy nhiều kiểm thử với chi phí tương đối thấp).
Sử dụng một mô hình có thể cung cấp các lợi ích tại các khu vực khác. Ví dụ tự động tạo mã nguồn dựa trên các mô hình có thể làm giảm sự hiện diện của một số loại khiếm khuyết (tức là viết sai mã và các khiếm khuyết có thể được phát hiện bởi mô hình kiểm tra) được tạo ra trong quá trình phát triển. Điều này giúp quá trình kiểm thử bằng cách giảm số lượng các khiếm khuyết trong các hạng mục kiểm thử được đưa vào kiểm thử từ quá trình phát triển.
5.6.4 Kiểm thử dựa trên toán học
Thực hành kiểm thử dựa trên toán học có thể được sử dụng để lập kế hoạch, thiết kế, chọn dữ liệu và thiết lập các điều kiện đầu vào khi đầu vào hạng mục kiểm thử hoặc không gian đầu ra có thể được mô tả đầy đủ chi tiết. Thực hành toán học sử dụng các chi nhánh của toán học để đưa ra cách tiếp cận. Những thực hành này có thể giúp giảm các vấn đề ảnh hưởng của con người về lựa chọn ca kiểm thử và ưu tiên.
Thực hành dựa trên toán học sử dụng một số kỹ thuật, nhưng đặc biệt là nó sử dụng các kỹ thuật thiết kế kiểm thử sau đây (được trình bày trong tiêu chuẩn TCVN 12849-4:2020 (ISO/IEC/IEEE 29119- 4:2015):
- Kiểm thử tổ hợp;
- Lựa chọn ca kiểm thử ngẫu nhiên;
Ngoài ra, mô hình thống kê có thể được sử dụng để xác định mức bao phủ kiểm thử (không đề cập trong tiêu chuẩn TCVN 12849-4:2020 (ISO/IEC/IEEE 29119-4:2015), ví dụ:
- Lấy mẫu phân tầng;
- Thử nghiệm Fuzz;
- Lấy mẫu cụm;
- Lấy mẫu xét đoán chuyên gia.
Thực hành kiểm thử dựa trên toán học cũng có thể được sử dụng để lẩy mẫu ca kiểm thử một cách khách quan bằng cách sử dụng các công cụ dựa trên toán học và các kỹ thuật.
Do số lượng lớn của đầu vào thường có thể được tạo ra bằng cách sử dụng thực hành toán học, các công cụ tự động thường được yêu cầu để sử dụng thực hành này.
5.6.5 Kiểm thử dựa trên kinh nghiệm
Kiểm thử dựa trên kinh nghiệm dựa trên:
- Kinh nghiệm kiểm thử trước đây;
- Kiến thức về hệ thống và phần mềm cụ thể;
- Kiến thức chuyên ngành; và
- Số liệu từ các dự án trước đây (trong tổ chức và từ ngành công nghiệp)
Tiêu chuẩn TCVN 12849-4:2020 (ISO/IEC/IEEE 29119-4:2015) mô tả kỹ thuật thiết kế kiểm thử dựa trên kinh nghiệm về phỏng đoán lỗi. Thực hành kiểm thử dựa trên kinh nghiệm khác bao gồm (nhưng không giới hạn) kiểm thử thăm dò, tấn công phần mềm và kiểm thử đặc biệt. Kiểm thử thăm dò và tấn công phần mềm không trình bày trong tiêu chuẩn TCVN 12849-4:2020 (ISO/IEC/IEEE 29119-4:2015) như các kỹ thuật thiết kế kiểm thử khi chúng thực hành ở đó một số kỹ thuật thiết kế kiểm thử có thể được áp dụng.
Kiểm thử thăm dò nén các hoạt động được mô tả trong tiêu chuẩn TCVN 12849-2:2020 (ISO/IEC/IEEE 29119-2:2013) ‘Thiết kế kiểm thử và thực hiện’ và các quá trình ‘Thực hiện kiểm thử’ để chúng được thực hiện một cách tự động để hoàn thành các mục tiêu kiểm thử. Khi sử dụng kiểm thử thăm dò, các ca kiểm thử thường không được thiết kế và tài liệu hóa trước, nhưng người kiểm thử sử dụng trực giác, sự ham học hỏi và các kết quả kiểm thử trước đây để quyết định những gì và làm thế nào để kiểm thử tiếp.
Kiểm thử thăm dò, phỏng đoán lỗi và kiểm thử đặc biệt là thực hành kiểm thử không dựa trên số lượng lớn tài liệu (ví dụ như thủ tục kiểm thử) để thực hiện kiểm thử. Việc liên tục từ kiểm thử theo kịch bản đến kiểm thử phi kịch bản, những thực hành kiểm thử dựa trên kinh nghiệm như vậy chủ yếu là phi kịch bản. Sử dụng thực hành này có nghĩa là chỉ có thể đạt được sự phù hợp với tiêu chuẩn TCVN 12849-2:2020 (ISO/IEC/IEEE 29119-2:2013).
5.6.6 Kiểm thử có kịch bản và phi kịch bản
Bảng dưới đây mô tả những ưu điểm và nhược điểm của kiểm thử theo kịch bản và phi kịch bản. cần lưu ý rằng hai thực hành này là không loại trừ lẫn nhau trong một dự án; đa số chúng thường được kết hợp để tạo ra một thực hành lai ghép dựa trên mức độ rủi ro của các hạng mục kiểm thử.
Khi quyết định sử dụng kiểm thử theo kịch bản, kiểm thử phi kịch bản hoặc lai ghép của cả hai, cần xem xét kỹ hồ sơ rủi ro của các hạng mục kiểm thử. Ví dụ, một thực hành lai ghép có thể sử dụng kiểm thử theo kịch bản để kiểm thử các hạng mục kiểm thử rủi ro cao và kiểm thử phi kịch bản để kiểm thử các hạng mục kiểm thử rủi ro thấp trên cùng một dự án.
Bảng 1: Sự tương phản của thực hành theo kịch bản và phi kịch bản trong thực hiện kiểm thử.
|
|
Ưu điểm |
Nhược điểm |
|
Kiểm thử theo kịch bản |
Kiểm thử có khả năng lặp lại; các ca kiểm thử đơn giản có thể được chạy lại, do đó cung cấp khả năng kiểm soát tốt cho các hoạt động xác minh và xác nhận. Ca kiểm thử theo kịch bản có thể được truy vết lại một cách rõ ràng cho các yêu cầu cho phép mức bao phủ kiểm thử phải được tài liệu hóa trong ma trận truy xuất nguồn gốc. Ca kiểm thử có thể được giữ lại như là công cụ tái sử dụng cho các dự án hiện tại và tương lai, có thể làm giảm thời gian cần thiết cho việc thiết kế kiểm thử và thực hiện trong tương lai. |
Thường tốn nhiều thời gian và chi phí hơn so với thực hiện kiểm thử phi kịch bản; Tuy nhiên nếu các ca kiểm thử theo kịch bản có khả năng tái sử dụng có thể giúp tiết kiệm thời gian. Ca kiểm thử xác định trước khi thực hiện kiểm thử ít có khả năng thích ứng với hệ thống khi nó xuất hiện. Có thể không khuyến khích cho người thực hiện như hầu hết các công việc phân tích đã được hoàn thành. Điều này có thể đem đến cho người kiểm thư sự mất tập trung và thiếu chi tiết trong quá trình thực thi. |
|
Kiểm thử phi kịch bản |
Người kiểm thử không bị ràng buộc bởi một kịch bản và có thể làm theo ý tưởng tạo ra bằng cách thực hiện kiểm thử theo thời gian thực. Người kiểm thử có thể điều chỉnh thiết kế kiểm thử và thực hiện' và Thực hiện kiểm thử cơ chế của hệ thống theo thời gian thực. Hạng mục kiểm thử có thể được khám phá một cách nhanh chóng. |
Các kiểm thử thường không có khả năng lặp lại. Người kiểm thử phải có khả năng áp dụng một loạt các kỹ thuật thiết kế kiểm thử theo yêu cầu, vì vậy những người kiểm thử có nhiều kinh nghiệm hơn thường là có nhiều khả năng tìm kiếm các khiếm khuyết hơn so với những người kiểm thử ít kinh nghiệm. Các kiểm thử phi kịch bản cung cấp ít hoặc không có hồ sơ của những thực hiện kiểm thử đã được hoàn thành. Do đó nó có thể gặp khó khăn trong việc đánh giá các quá trình thực hiện kiểm thử động, trừ khi các công cụ được sử dụng để nắm bắt thực hiện kiểm thử. |
5.7 Tự động hóa trong kiểm thử
Có thể tự động hóa nhiều trong các nhiệm vụ và hoạt động được mô tả trong quản lý kiểm thử và quy trình kiểm thử động được nêu trong tiêu chuẩn TCVN 12849-2:2020 (ISO/IEC/IEEE 29119-2:2013), cũng như các khía cạnh kỹ thuật kiểm thử trong tiêu chuẩn TCVN 12849-4:2020 (ISO/IEC/IEEE 29119- 4:2015). Tự động hóa kiểm thử có thể được sử dụng để hỗ trợ thực hành kiểm thử trình bày tại mục 5.6 (ví dụ như kiểm thử trên cơ sở mô hình gần như luôn dựa trên việc sử dụng các công cụ thực hiện kiểm thử tự động). Việc tự động hóa kiểm thử đòi hỏi việc sử dụng các phần mềm thường được gọi là các công cụ kiểm thử. Kiểm thử tự động thường xem xét quan tâm chủ yếu đến việc thực hiện kiểm thử của các kiểm thử theo kịch bản chứ không phải người kiểm thử thực hiện nhân công các ca kiểm thử, tuy nhiên nhiều nhiệm vụ kiểm thử bổ sung và các hoạt động có thể được hỗ trợ bởi các công cụ dựa trên phần mềm. Danh sách sau đây cung cấp các ví dụ về một số lĩnh vực bao phủ bởi các công cụ kiểm thử:
- Quản lý ca kiểm thử;
- Giám sát và kiểm soát kiểm thử;
- Tạo dữ liệu kiểm thử;
- Phân tích tĩnh;
- Tạo ca kiểm thử;
- Thực hiện ca kiểm thử;
- Thực thi môi trường kiểm thử và bảo trì; và
- Kiểm thử dựa trên phiên.
Có một loạt các công cụ tự động kiểm thử có sẵn. Chúng có thể được phát triển trong nhà, đạt được từ thương mại hoặc từ các cộng đồng mã nguồn mở.
Người quản lý kiểm thử dự án thường chịu trách nhiệm quản lý khiếm khuyết (còn được gọi là Quản lý sự cố) trên một dự án. Quản lý khiếm khuyết được đề cập trong tiêu chuẩn TCVN 12849-2:2020 (ISO/IEC/IEEE 29119-2:2013), để hỗ trợ người kiểm thử trong việc điều tra và tài liệu hóa về các báo cáo sự cố kiểm thử và kiểm thử lại các khiếm khuyết khi có yêu cầu. Tất cả các yếu tố khác của quản lý khiếm khuyết không được đề cập trực tiếp bởi bộ tiêu chuẩn TCVN 12849 (ISO/IEC/IEEE 29119). Các khái niệm quản lý khiếm khuyết và các quy trình có thể được tìm thấy trong các tiêu chuẩn sau đây: tiêu chuẩn ISO/IEC 12207; ISO/IEC 20000; IEEE 1044.
Vai trò của kiểm thử trong việc xác minh và xác nhận
Hình A.1 định nghĩa một hoạt động phân loại xác minh và xác nhận (V & V). V & V có thể được thực hiện trên hệ thống, phần cứng và các sản phẩm phần mềm. Những hoạt động này được định nghĩa và tinh chế tronq tiêu chuẩn IEEE 1012 và tiêu chuẩn ISO/IEC 12207, phần lớn V & V được thực hiện bằng cách kiểm thử. Bộ các tiêu chuẩn ISO/IEC/IEEE 29.119 giải quyết các kiểm thử phần mềm động và tĩnh (một cách trực tiếp hoặc thông qua tài liệu tham khảo), do đó bao phủ các phần của mô hình xác minh và xác nhận này. Bộ các tiêu chuẩn TCVN 12849 (ISO/IEC/IEEE 29119) này không nhằm giải quyết tất cà các yếu tổ của mô hình V & V, nhưng là điều quan trọng để người kiểm thử nắm được nơi kiểm thử phù hợp trong mô hình này.
Hình A.1: Hệ thống phân cấp hoạt động xác minh và xác nhận
B.1 Các thước đo và đánh giá
Mục đích chính của kiểm thử là cung cấp thông tin để giúp quản lý các rủi ro. Để giám sát, kiểm soát kiểm thử và cung cấp thông tin kịp thời cho các bên liên quan khi cần thiết để có đánh giá hiệu quả quá trình kiểm thử. Đánh giá các quá trình kiểm thử là cần thiết để xác định những thông tin cung cấp, cách thức có được và trình bày nó. Vì vậy tất cả những nỗ lực kiểm thử cần phải xác định, sử dụng các đơn vị đo và cung cấp các đánh giá với cả hai sản phẩm và quy trình.
Một số ví dụ về các thước đo có thể được sử dụng trong kiểm thử là:
- Rủi ro còn tồn tại: số rủi ro giảm thiểu/số rủi ro được xác định;
- Khiếm khuyết tích lũy phát sinh và cố định: số khiếm khuyết phát sinh mỗi ngày so với số khiếm khuyết cố định mỗi ngày;
- Tiến hành ca kiểm thử: số ca kiểm thử thực thi/số ca kiểm thử theo kế hoạch để thực hiện; và
- Tỷ lệ phần trăm khiếm khuyết phát hiện: số khiếm khuyết tìm thấy trong kiểm thử/tổng số khiếm khuyết được tìm thấy (tổng thể).
Kiểm thử trong các mô hình vòng đời khác nhau
C.1 Tổng quan
Phụ lục này đưa ra các ví dụ về cách kiểm thử có thể phù hợp với các mô hình vòng đời phát triển phần mềm khác nhau. Đối với một dự án, các giai đoạn phát triển và/hoặc các hoạt động cần thiết được xác định và như vậy sẽ được thực hiện trong mối quan hệ với nhau trong cả quá trình vòng đời phát triển. Tập các giai đoạn phát triển và mối quan hệ của chúng được gọi là "mô hình vòng đời phát triển" hay đơn giản hơn là "mô hình vòng đời".
Một số mô hình vòng đời đã được sử dụng bởi ngành công nghiệp phần mềm trong những năm qua. Một ví dụ về mô hình vòng đời điển hình được phân loại ở đây, theo thứ tự ABC (và theo thứ tự ngược lại từ khi chúng có tồn tại), mặc dù đây không phải là một danh sách toàn diện.
- Linh hoạt
- Tiến hóa
- Tuần tự (nghĩa là mô hình thác nước)
Các hoạt động phát triển được thực hiện nhiều hơn hoặc ít hơn như nhau trong tất cả các mô hình vòng đời; những khác biệt chính nằm trong định nghĩa về phạm vi của chúng, số lượng và tính chất của tài liệu hướng dẫn sản xuất và các tần suất mà chúng được lặp đi lặp lại trong suốt quá trình vòng đời phát triển.
CHÚ THÍCH Tiêu chuẩn này không có ý định đề chuẩn hóa các mô hình vòng đời khác nhau; mà có ý định thiết lập bối cảnh cho kiểm thử để hỗ trợ cho việc thực hiện các chu kỳ vòng đời đó.
C.2 Phát triển và kiểm thử linh hoạt
C.2.1 Các nguyên tắc phát triển linh hoạt
Phát triển linh hoạt thường tuân theo nguyên tắc cơ bản sau:
- Phát triển tăng dần - mỗi chu kỳ chuyển giao các sản phẩm hữu ích và có thể sử dụng;
- Phát triển lặp - cho phép các yêu cầu phát triển (tức là thay đổi và được bổ sung) như dự án phát triển;
- phát triển hướng người dùng - dựa vào chất lượng của các nhóm dự án (ví dụ như các nhà phát triển và thử nghiệm) chứ không phải là quy trình được xác định rõ; cho phép các đội linh hoạt để tự quản lý; kỳ vọng tương tác hàng ngày giữa các nhóm phát triển và các bên kinh doanh liên quan; và
- Kỹ thuật và công nghệ xuất sắc - đạt được thông qua các phương pháp đào tạo phát triển, tích hợp và kiểm thử các sản phẩm.
Có một số phương pháp phát triển linh hoạt và khung công việc bao gồm: lập trình đặc biệt (XP), Scrum, Crystal, Kanban và phát triển Feature-Driven. Trong khi họ có cách tiếp cận khác nhau nhưng họ chia sẻ tất cả các nguyên tắc linh hoạt cơ bản như thể hiện trong tuyên ngôn linh hoạt (xem http //: agilemanifesto.org/). Vì không có đủ thời gian và không gian để cung cấp các ví dụ về tiêu chuẩn này được thực hiện với từng phương pháp linh hoạt khác nhau và do đó khung công việc tiêu chuẩn này sẽ sử dụng khuôn công việc Scrum là một ví dụ. Scrum không phải là một phương pháp phát triển (tức là nó không cho bạn biết những phương pháp tốt nhất để mô tả các yêu cầu hoặc làm thế nào để viết mã lệnh) và được mô tả tốt hơn là một khung công việc quản lý dự án trong đó phương pháp linh hoạt được áp dụng bởi các nhà phát triển (XP thường được sử dụng).
Một dự án Scrum bao gồm một số lần lặp được gọi là chạy nước rút (sprints), với mỗi sprints thường dẫn đến chức năng mới có thể được giao cho người sử dụng (xem hình C.1). Chức năng mới này có thể cải tiến chức năng hiện có hoặc giới thiệu những chức năng mới. Mỗi sprints thường kéo dài từ một đến bốn tuần. Thường thì số sprints là không biết được tại lúc bắt đầu bởi vì trong các dự án linh hoạt điển hình các yêu cầu không được hiểu đầy đủ khi bắt đầu của dự án. Yêu cầu mở ra khi thực hiện dự án, yêu cầu của khách hàng được thu thập trong một đơn hàng sản phẩm; thường được thể hiện như câu chuyện của người dùng.
Các mô hình quy trình kiểm thử xác định trong tiêu chuẩn này có thể được áp dụng cho việc kiểm thử được thực hiện trong các dự án theo mô hình phát triển linh hoạt.
C.2.2 Quản lý kiểm thử trong phát triển linh hoạt
Chiến lược kiểm thử của tổ chức cần phản ánh một thực tế là sự phát triển theo một mô hình phát triển linh hoạt. Trong một tổ chức mà phát triển được thực hiện bằng cách sử dụng một hỗn hợp của các mô hình phát triển trên các dự án khác nhau bao gồm cả linh hoạt, thưởng sẽ có một chiến lược kiểm thử của tổ chức cụ thể bao phủ cả phát triển linh hoạt. Chiến lược kiểm thử của tổ chức cho các dự án sử dụng phát triển linh hoạt nên sử dụng các từ vựng linh hoạt cụ thể, bao gồm các khái niệm về đơn hàng, chạy nước rút (sprints) và scrums mỗi ngày, nhưng ngoài ra các nội dung bất kỳ của chiến lược kiểm thử của tổ chức phụ thuộc chủ yếu vào hồ sơ rủi ro đối với các dự án và sản phẩm nó bao phủ (mặc dù các loại mô hình phát triển sử dụng có thể tạo ra các loại rủi ro bổ sung mà chiến lược kiểm thử cần phải giải quyết).
Một dự án linh hoạt thường được quản lý bởi một người quản lý dự án và các nước rút (sprints) được tạo điều kiện bởi một chuyên gia scrum (những vai trò này có thể được thực hiện bởi cùng một người). Việc quản lý kiểm thử trong một dự án linh hoạt được thực hiện như một phần tích hợp của việc quản lý đơn hàng sản phẩm, chạy nước rút riêng và các scrums mỗi ngày.
Khi bắt đầu chạy nước rút, nhóm Scrum và khách hàng (chủ sản phẩm) đồng ý với các câu chuyện của người dùng từ đơn hàng sản phẩm phải được thực hiện trong bước nước rút này, những câu chuyện được lựa chọn bao gồm cả đơn hàng Sprint. Nhóm nghiên cứu sau đó lên kế hoạch chạy nước rút bằng cách lên lịch các hoạt động phát triển, kiểm thử và phân công vai trò, trách nhiệm của các thành viên trong nhóm. Linh hoạt theo cùng quy trình chung trên tất cả các sản phẩm phát triển và kiểm thử có thể được tìm thấy trong ví dụ chạy nước rút Scrum trong hình C.2 dưới đây:
Khả năng phân bổ từ chạy nước rút được chứng minh cho khách hàng tại các cuộc họp giới thiệu chạy nước rút (sprint) nơi mà các đội có cơ hội để trình bày cho các bên liên quan những gì họ đã tạo ra. Các hoạt động cuối cùng trong nước rút là nghiệm lại nước rút, trong đó xem xét lại nhóm thực hiện ra làm sao và xác định nơi mà những cải tiến có thể được thực hiện cho chạy nước rút tương lai - như vậy, cải tiến quy trình được xây dựng trong khung công việc Scrum.
Trong suốt những ngày chạy nước rút các buổi họp scrum được tổ chức vào đầu mỗi ngày để đảm bảo rằng cả nhóm nhận thức được: những gì đã được thực hiện; những gì đang được thực hiện trong ngày hôm đó; và các vấn đề mà nhóm phải đối mặt. Họ cũng Báo cho chuyên gia scrum để xác định những trở ngại cần phải được loại bỏ để cho phép nhóm thực hiện có hiệu quả nhất.
Các vấn đề chính trong một dự án linh hoạt đang quản lý rủi ro các khiếm khuyết hồi quy (như mỗi nước rút xây dựng dựa bởi những người trước đó) và quản lý các thay đổi bản chất của yêu cầu và tác động của các công cụ kiểm thử. Thông thường kiểm thử tự động được sử dụng để quản lý các rủi ro hồi quy và kiểm thử thăm dò có thể được sử dụng để quản lý các tác động của việc thiếu các yêu cầu chi tiết.
C.2.3 Quy trình kiểm thử con trong phát triển linh hoạt
Các hoạt động kiểm thử là một phần tích hợp của một dự án phát triển linh hoạt như mô tả trong hình C.2, với các kiểm thử được thực hiện trên một cơ sở liên tục trong suốt chạy nước rút (sprint). Quy trình kiểm thử con có thể được xác định và thực hiện sử dụng các quá trình trong tiêu chuẩn này để kiểm thử những câu chuyện của người dùng và phát triển hệ thống được chuyển giao.
Thực hành kiểm thử điển hình được sử dụng bởi các nhóm chạy nước rút (Sprint) là:
Phát triển trình điều khiển kiểm thử (TDD), đó là nơi mà các kiểm thử cho mã lệnh được cải tiến bởi các mã có trước. Các kiểm thử này dựa trên câu chuyện người sử dụng và được phát triển bởi cả người kiểm thử và người phát triển. Những kiểm thử này thường được thực hiện bằng cách sử dụng các công cụ kiểm thử thành phần tự động và điều này có thể dẫn đến TDD được xem như là một hình thức của lập trình.
Kiểm thử tự động xây dựng và tích hợp liên tục; đây là nơi mà hệ thống được cập nhật liên tục và kiểm thử hồi quy mã lệnh được kiểm tra lại. Nó được sử dụng để đảm bảo việc xác định kịp thời và hiệu chỉnh các vấn đề về tích hợp và hồi quy.
Kiểm thử hệ thống của tất cả các đặc tính chất lượng (tức là cả chức năng và phi chức năng) được thực hiện đối với cả những câu chuyện của người dùng và các yêu cầu mức cao bất kỳ nào tồn tại. Kiểm thử hệ thống thường được theo sau kiểm thử chấp nhận có liên quan đến người sử dụng đầu cuối đảm bảo các chức năng được chuyển giao đáp ứng nhu cầu của họ.
Kiểm thử hồi quy thường là cần thiết để xác định rằng bất kỳ thay đổi trong bước nước rút hiện tại không có tác dụng phụ bất lợi trên các chức năng và tính năng hiện có của sản phẩm.
Tại thời điểm cuối của "lý tưởng" chạy nước rút các tính năng đã sẵn sàng để sử dụng bởi những người sử dụng, có nghĩa là tất cả các kiểm thử nói trên được thực hiện trong vòng chạy nước rút (như mô tả trong hình C.2). Trong thực tế nhiều dự án gặp phải khó khăn này, dẫn đến việc lựa chọn các giải pháp thay thế thỏa hiệp, chẳng hạn như kiểm thử được thực hiện song song hoặc kiểm thử được xử lý trong bước chạy nước rút tập trung kiểm thử thường xuyên.
C.3 Phát triển tuần tự và kiểm thử
C.3.1 Nguyên tắc phát triển tuần từ
Mô hình vòng đời tuần tự đã tồn tại rất lâu và vẫn được sử dụng rộng rãi. Mô hình tuần tự cơ bản (và khởi đầu) được biết là mô hình thác nước và được mô tả theo từng giai đoạn phát triển sắp xếp theo trình tự trước một giai đoạn kiểm thử với một hoạt động giai đoạn cuối ở cuối.
Một mô hình vòng đời tuần tự được đặc trưng bởi kể cả không có sự lặp lại rõ ràng trong những giai đoạn khác hơn là thực thi rất cần thiết bởi sự phản hồi từ các giai đoạn tiếp theo.
Mô hình quy trình kiểm thử nêu trong tiêu chuẩn này có thể được áp dụng cho các kiểm thử để phát triển theo mô hình vòng đời tuần tự.
C.3.2 Quản lý kiểm thử trong phát triển tuần tự
Chiến lược kiểm thử của tổ chức cần phản ánh một thực tế là việc phát triển tuân theo một mô hình phát triển tuần tự. Trong một tổ chức mà phát triển được thực hiện bằng cách sử dụng một hỗn hợp của các mô hình phát triển cho các dự án khác nhau bao gồm tuần tự, thường sẽ có một hay nhiều chiến lược kiểm thử của tổ chức bao phủ các mô hình phát triển được sử dụng. Chiến lược kiểm thử của tổ chức nên sử dụng những từ vựng được sử dụng bởi các loại dự án nó bao phủ; nếu không các nội dung của một chiến lược kiểm thử của tổ chức phụ thuộc vào hồ sơ rủi ro đối với các dự án và các sản phẩm nó bao phủ và không phải trên các mô hình phát triển sử dụng.
Một dự án tuần tự được quản lý bởi một người quản lý dự án. Trên hầu hết các dự án vai trò của người quản lý phát triển và người quản lý kiểm thử cũng được xác định. Tùy thuộc vào quy mô của các dự án những vai trò này có thể được thực hiện bởi những người khác nhau, hoặc hai hay tất cả các vai trò có thể được thực hiện bởi cùng một người.
Kế hoạch trong phát triển tuần tự được xây dựng cho toàn bộ dự án, mặc dù chủng nên phát triển trong suốt quá trình dự án. Dự án phát triển tuần tự có thể tương đối lớn và nó không có thể lập kế hoạch cùng mức đô chi tiết cho toàn bộ dự án lúc bắt đầu. Một kế hoạch kiểm thử dự án cũng phải được xây dựng. Điều này thường là dưới hình thức của một tài liệu cá nhân, nhưng có thể là một phần của kế hoạch tổng thể dự án. Kế hoạch quy trình kiểm thử con riêng có thể được xây dựng nếu bảo hành trong quy trình kiểm thử con được chỉ định để được thực hiện trong kế hoạch kiểm thử dự án. Kế hoạch này thường tài liệu chính thức trong phát triển tuần tự.
C.3.3 Quy trình kiểm thử con trong phát triển tuần tự
Quy trình kiểm thử con mô tả cho sự phát triển tiến hóa tại Phụ lục C.3 cũng có liên quan với kiểm thử trong một dự án tuần tự, mặc dù chúng chỉ diễn ra một lần (chỉ có một lần thông qua mô hình phát triển tuần tự).
Hình C.3: Ví dụ quy trình con kiểm thử trong vòng đời phát triển tuần tự
Lưu ý rằng hình C.3 không theo quy mô; kích cỡ tương đối củạ các quy trình kiểm thử con được hiển thị là không liên quan đến kích cỡ thực tế của các quy trình kiểm thử con trong điều khoản của ví dụ, thời gian thiết lập, nỗ lực hoặc chi phí.
Kiểm thử thiết kế kiến trúc, kiểm thử thiết kế chi tiết và kiểm thử mã nguồn được xác định. Đối với mỗi giai đoạn phát triển tương ứng có thể được xác nhận trên cơ sở các kết quả của kiểm thử hoàn thành, tức là khi tất cả các hạng mục phát triển chi tiết đã được kiểm thử riêng.
Đối với giai đoạn mã hóa có hai quy trình kiểm thử con khác nhau. Đầu tiên là một quy trình kiểm thử con mã nguồn, cấu thành từ kiểm thử tĩnh của mã nguồn, thứ hai là kiểm thử thành phan, cấu thành từ các kiểm thử động của khả năng thực thi hoặc mã có khả năng biên dịch. Các quy trình kiểm thử con có thể được kết hợp và kiểm thử động của một thành phần được thực hiện phụ thuộc vào các kiểm thử tĩnh thành công của mã nguồn.
Kết quả cuối cùng của giai đoạn tích hợp là một hệ thống hoàn chỉnh. Tại thời điểm này các hoạt động thực hiện là kiểm thử hệ thống, giả sử chúng đã được lên kế hoạch và chuẩn bị trên cơ sở các yêu cầu có thể bắt đầu.
Ví dụ quy trình kiểm thử con trình bày ở đây được mô tả thêm trong Phụ lục E.
C.4 Phát triển tiến hóa và kiểm thử
C.4.1 Nguyên tắc phát triển tiến hóa
Phát triển tiến hóa dựa trên hai nguyên tắc cơ bản của sự lặp lại và chuyển giao tăng dần. Lặp đi lặp lại cho phép các nhà phát triển để phát triển các hệ thống như là một loạt các phần nhỏ và sau đó họ có thể sử dụng thông tin phản hồi trên cả sản phẩm được phát triển và thực tiễn phát triển của họ để cải tiến các lần lặp kế tiếp. Lặp đi lặp lại cho phép các rủi ro cao hơn được giải quyết sớm hơn so với các chu kỳ tuần tự truyền thống, do đó gia tăng thời gian để giải quyết chúng. Với sự phát triển tăng dần kết quả của mỗi lần lặp được phát hành cho khách hàng, có nghĩa là người dùng nhận được hệ thống trong một loạt các chuyển giao với tăng chức năng lên.
Một lần lặp bao gồm tất cả hoặc một số các hoạt động phát triển tiêu chuẩn. Một lần lặp sẽ bao gồm một giai đoạn chấp nhận khi kết quả của việc lặp lại đang được chuyển giao cho người sử dụng; nếu không một giai đoạn chấp nhận sẽ thường chỉ được thực hiện trong lần lặp cuối cùng.
Hình C.3 trong mục C.3.3 cho thấy một vòng đời tuần tự. Một vòng đời phát triển tiến hóa có thể được mô tả như một số vòng đời tuần tự rời rạc mà mỗi lần bổ sung thêm khả năng cho hệ thống đang được phát triển.
Các mô hình quy trình kiểm thử nêu trong tiêu chuẩn này có thể được áp dụng đối với các kiểm thử cho sự phát triển tuân theo một mô hình phát triển tiến hóa.
C.4.2 Quản lý kiểm thử trong phát triển tiến hóa
Chiến lược kiểm thử của tổ chức cần phản ánh một thực tế là việc phát triển tuân theo mô hình phát triển tiến hóa. Trong một tổ chức mà phát triển được thực hiện bằng cách sử dụng một hỗn hợp của các mô hình phát triển cho các dự án khác nhau bao gồm cả tiến hóa, thường sẽ có một hay nhiều chiến lược kiểm thử của tổ chức bao phủ các mô hình phát triển được sử dụng. Chiến lược kiểm thử của tổ chức nên sử dụng các từ vương được sử dụng bởi loại dự án gõ nó bao phủ, ngoài ra các nội dung bất kỳ của chiến lược kiểm thử của tổ chức phụ thuộc chủ yếu vào hồ sơ rủi ro đối với các dự án và sản phẩm đó bao phủ (mặc dù các loại mô hình phát triển sử dụng có thể tạo ra các loại rủi ro bổ sung mà các chiến lược kiểm thử cũng cần phải giải quyết).
Một dự án tiến hóa được quản lý bởi một người quản lý dự án. Trên hầu hết các dự án vai trò của người quản lý phát triển và người quản lý kiểm thử cũng được xác định. Tùy thuộc vào qui mô của các dự án những vai trò này có thể được thực hiện bởi những người khác nhau, hoặc hai hoặc tất cả các vai trò có thể được thực hiện bởi cùng một người.
Kế hoạch phát triển tiến hóa được xây dựng cho toàn bộ dự án và cho mỗi lần lặp. Một kế hoạch kiểm thử dự án phải được xây dựng và một trong hai có thể ở dạng một tài liệu riêng hoặc là một phần của kế hoạch tổng thể dự án. Một kế hoạch kiểm thử lặp lại nhò hơn cũng có thể được xây dựng cụ thể để kiểm thử được thực hiện trong một lần lặp lại. Kế hoạch có thể có nhiều hoặc ít tài liệu chính thức hơn trong phát triển tiến hóa, nhưng chúng thường sẽ được duy trì trong một tài liệu và/hoặc trong một công cụ lập kế hoạch. Kế hoạch kiểm thử lặp và các quy trình con có liên quan thường sẽ được tái sử dụng với các chỉnh sửa cần thiết từ lần lặp này đển lần lặp khác.
Tiến độ kiểm thử được theo dõi trong suốt một lần lặp và các hành động khắc phục cần thiết được thực hiện trên một cơ sở liên tục và được truyền đạt đến các bên liên quan trong các kế hoạch kiểm thử cập nhật.
C.4.3 Quy trình kiểm thử con trong phát triển tiến hóa
Trong mỗi lần lặp các sản phẩm công việc và hệ thống hoàn chỉnh có thể được kiểm thử. Quy trình kiểm thử con có thể được xác định và thực hiện bằng cách sử dụng các quá trình trong tiêu chuẩn này để kiểm thử khả năng các sản phẩm công việc thực thi và hệ thống đang được sản xuất.
Giai đoạn phát triển đầu tiên trong ví dụ này là các yêu cầu kỹ thuật, nơi mà các nghiệp vụ, các yêu cầu chức năng/phi chức năng và hệ thống đang được xác định. Hình C.3 chỉ cho thấy các các quy trình kiểm thử con có liên quan đến giai đoạn đầu tiên (các yêu cầu giai đoạn kiểm thử) để tránh làm xáo trộn các hình ảnh. Việc kiểm thử các yêu cầu như chúng đang được chì định có thể được coi là một quá trình con của kiểm thử tĩnh. Hình thức của quy trình kiểm thử con này phụ thuộc vào hồ sơ rủi ro của sản phẩm, nhưng vì các yêu cầu là nền tảng cho công việc trong quá trình lặp nên các kỹ thuật thiết kế kiểm thử tĩnh được lựa chọn để kết thúc chính thức hơn về quy mô.
Tương tự quy trình kiểm thử con có thể được định nghĩa cho hai giai đoạn thiết kế, cũng như đối với các giai đoạn mã hóa. Với ví dụ mô hình phát triển thể hiện trong Hình C.3 này có thể bao gồm:
- Kiểm thử thiết kế kiến trúc;
- Kiểm thử thiết kế chi tiết;
- Kiểm thử mã nguồn.
Các quy trình kiểm thử con thường dàn tải trên hầu hết các giai đoạn phát triển tương ứng và chúng tập trung vào một loại hạng mục kiểm thử, ví dụ các yêu cầu và bao gồm các cách khác nhau để kiểm thử các hạng mục kiểm thử, ví dụ “walkthroughs” và đánh giá kỹ thuật. Quy trình kiểm thử con các yêu cầu sẽ không được hoàn thành cho đến khi tất cả các yêu cầu phát triển đã được kiểm thử theo kế hoạch quy trình kiểm thử con. Thường có một mốc quán trọng nhiều hay ít chính thức hơn để đánh dấu sự kết thúc của giai đoạn yêu cầu kỹ thuật và điều này thường sẽ phụ thuộc vào kết quả của quy trình kiểm thử con yêu cầu.
Tương tự các quy trình kiểm thử con thiết kế và mã nguồn sẽ không được hoàn thành cho đến khi tất cả các hạng mục kiểm thử phát triển đã được kiểm thử theo kế hoạch quy trình kiểm thử con và các mốc phát triển tương ứng sẽ phụ thuộc vào các kết quả từ các quy trình kiểm thử con.
Việc chấp nhận các quy trình kiểm thử con được mô tả trong Hình C.3. Các hoạt động lập kế hoạch và chuẩn bị trong việc chấp nhận quy trình kiểm thử con có thể bắt đầu ngay sau khi rủi ro thay đổi đáng kể trong các yêu cầu cho sự lặp lại này là thấp hơn so với lợi ích của các quy trình kiểm thử con bắt đầu. Kiểm thử thiết kế sẽ công bố các khiếm khuyết trong các yêu cầu và theo cách này, góp phần cung cấp thông tin về các yêu cầu. Tương tự quy trình kiểm thử con có thể được xác định cho các mốc phát triển khác, nơi kiểm thử động được tham gia. Đối với ví dụ mô hình phát triển thể hiện trong Hình C.3 này có thể bao gồm các quy trình con sau đây và là tương tự đối với việc chấp nhận quy trình con:
- Kiểm thử thành phần;
- Kiểm thử tích hợp;
- Kiểm thử hệ thống.
Ví dụ trong hình C.3, kiểm thử năng lực thực thi cũng đã được xác định. Các quy trình kiểm thử con cụ thể có thể được định nghĩa để bao phủ các hạng yêu cầu mục cụ thể hoặc khu vực cụ thể của hệ thông được mô tả bởi các yêu cầu, thường phụ thuộc vào hồ sơ rủi ro đối với hệ thống. Quy trình kiểm thử con cụ thể như vậy có thể trải dài qua một số giai đoạn phát triển và do đó có thể có một loạt các hạng mục kiểm thử và các cơ sở kiểm thử có liên quan, trách nhiệm kiểm thử, kỹ thuật, môi trường và mục tiêu kiểm thử, tiêu chí hoàn thành và các kế hoạch, mặc dù có chỉ có một trọng tâm về quy trình kiêm thử con, trong trường hợp này các yêu cầu thực thi và làm thế nào để chúng đang được mô tả, thiết kế và được thực hiện trong hệ thống.
Tất cả các kiểm thử mô tả ở trên có thể được thực hiện cho từng lần lặp tiếp theo.
Kể từ khi sản phẩm không ngừng mở rộng, kiểm thử hồi quy sâu rộng về những gì trước đây đã được chấp nhận là bắt buộc trong môi lần lặp. Một quy trình kiểm thử con hồi cần được xác định cho mỗi lần lặp. Quy trình kiểm thử con có thể bao gồm kiểm thử hồi quy của tất cả các hạng mục được mở rộng trong một lần lặp lại, bao gồm cả các yêu cầu, thiết kế, mã nguồn và hệ thống hoặc nó có thể chỉ bao phủ một lựa chọn của những phụ thuộc vào hồ sơ rủi ro. Quy trình kiểm thử con hồi quy riêng biệt cũng có thể được xác định cho từng loại hạng mục được mở rộng để tạo điều kiện linh hoạt hơn trong việc kiểm thử hồi quy từ lần lặp này đến lần lặp khác.
Các ví dụ về quy trình kiểm thử con chi tiết
D.1 Tổng quan
Phụ lục này đưa ra ví dụ về quy trình kiểm thử con. Các ví dụ được cung cấp theo thứ tự abc. Danh sách này chỉ cho thấy một vài ví dụ; nhiều quy trình con cụ thể khác có thể cần thiết trong một dự án thử kiểm cụ thể.
Các ví dụ là:
- Kiểm thử chấp nhận;
- Kiểm thử thiết kế chi tiết;
- Kiểm thử tích hợp;
- Kiểm thử năng lực thực thi;
- Kiểm thử hồi quy;
- Kiểm thử lại;
- Kiểm thử câu chuyện;
- Kiểm thử hệ thống;
- Kiểm thử thành phần.
Lưu ý rằng kiểm thử hồi quy và kiểm thử lại đã được đưa vào quy trình kiểm thử con cụ thể. Đây có thể được bao gồm trong bất kỳ quy trình kiểm thử con khác cho phù hợp.
Đối với mỗi ví dụ quy trình kiểm thử con mô tả bao gồm:
- Mục tiêu quy trình kiểm thử con;
- Nội dung quy trình kiểm thử con được lập kế hoạch - các quy trình kiểm thử tĩnh và/hoặc quy trình kiểm thử động được thực hiện.
Đối với mỗi quy trình kiểm thử tĩnh hoặc động lên kế hoạch cho quy trình kiểm thử con, mô tả bao gồm:
- Mục tiêu kiểm thử;
- Các hạng mục kiểm thử;
- Cơ sở kiểm thử;
- Quy trình kiểm thử khả năng áp dụng;
- Các kỹ thuật thiết kế kiểm thử được đề nghị, nếu áp dụng.
Lưu ý rằng các ví dụ được cung cấp chỉ là các ví dụ. Trong từng tình huống thực tế các sự lựa chọn nên được thực hiện phù hợp với hồ sơ rủi ro cho sản phẩm.
D.2 Quy trình kiểm thử con chấp nhận
Ví dụ này trình bày các quy trình kiểm thử con gắn liền với các giai đoạn chấp nhận của vòng đời phát triển.
Mục tiêu quy trình kiểm thử con: Để chứng minh cho khách hàng khả năng chấp nhận của hệ thống hoàn thiện theo các yêu cầu cụ thể của họ.
Nội dung quy trình kiểm thử con theo hoạch: Kiểm thử động 1: ‘diễn tập’,
Kiểm thử động 2: Trình bày
Kiểm thử động 1: ‘Diễn tập’
Mục tiêu kiểm thử: Để đảm bảo rằng việc thực hiện cuối cùng trong sự hiện diện của các khách hàng sẽ được thành công.
Đối tượng kiểm thử: Hệ thống hoàn chỉnh.
Cơ sở kiểm thử: Các yêu cầu người sử dụng, hướng dẫn sử dụng, tài liệu quy trình nghiệp vụ.
Quy trình kiểm thử động: Thiết kế và thực hiện; thiết lập môi trường kiểm thử và bảo trì; thực hiện kiểm thử; và báo cáo sự cố kiểm thử.
Các kỹ thuật thiết kế kiểm thử: Sử dụng ca kiểm thử, các kỹ thuật khác tùy theo tính chất của các yêu cầu.
Việc thiết kế và thực hiện các ca kiểm thử có thể bắt đầu ngay sau khi các yêu cầu sử dụng ổn định. Mặc dù các giả định cho việc kiểm thử chấp nhận là hệ thống hoạt động, hầu hết các tổ chức chuẩn bị và thực hiện các kiểm thử trước khi khách hàng có mặt để chứng kiến sự trình bày chính thức của hệ thống; điều này được gọi là ‘diễn tập’. Quy trình kiểm thử lại và hồi quy có thể được lập kế hoạch để phục vụ cho việc loại bỏ khiếm khuyết bất kỳ ở 'phút cuối cùng' như là kết quả của kiểm thử này.
Kiểm thử động 2: Trình bày
Mục tiêu kiểm thử: Để trình bày hệ thống hoàn chỉnh cho khách hàng.
Hạng mục kiểm thử: Hệ thống hoàn chỉnh.
Cơ sở kiểm thử: N/A
Quy trình kiểm thử động: thiết lập môi trường kiểm thử và bảo trì; thực hiện kiểm thử; và báo cáo sự cố kiểm thử.
Các kỹ thuật thiết kế kiểm thử: N/A
Các môi trường sẽ cần phải được thiết lập lại sau khi kết thúc 'diễn tập', nhưng nếu không thực hiện thử nghiệm được thực hiện theo các thủ tục và môi trường được chuẩn bị trong 'diễn tập'.
D.3 Quy trình kiểm thử con thiết kế chi tiết
Ví dụ này trình bày quy trình kiểm thử con gắn liền với các giai đoạn thiết kế chi tiết của vòng đời phát triển.
Mục tiêu quy trình kiểm thử con: Cung cấp thông tin về chất lượng của thiết kế chi tiết
Nội dung quy trình kiểm thử con theo kế hoạch: Kiểm thử tĩnh 1: tài liệu hướng dẫn hạng mục thiết kế chi tiết.
Kiểm thử tĩnh 2: Chi tiết khả năng sử dụng mục thiết kế, (không phải khả năng sử dụng của hệ thống)
Kiểm thử tĩnh 3: Thiết kế chi tiết hạng mục hoàn chỉnh.
Trong giai đoạn thiết kế chi tiết các hạng mục một số hạng mục thiết kể được phát triển, tùy thuộc vào thiết kế kiến trúc. Mỗi một hạng mục lệ thuộc vào các kiểm thử tĩnh được xác định cho quy trình kiểm thử con này, vì vậy trường hợp của các kiểm thử tĩnh có thể được lên kế hoạch với các hạng mục kiểm thử được xác định như là một hạng mục thiết kế chi tiết cụ thể. Quy trình kiểm thử con thiết kế chi tiết chỉ được hoàn thành khi tất cả các kiểm thử theo kế hoạch được hoàn thành (hoặc bị bỏ qua trường hợp có thể được).
Kiểm thử tĩnh 1: Tài liệu hướng dẫn hạng mục thiết kế chi tiết
Mục tiêu kiểm thử: Để cung cấp thông tin về cách thức một hạng mục thiết kế chi tiết được tài liệu hỏa. Hạng mục kiểm thử: Hạng mục thiết kế chi tiết.
Cơ sở kiểm thử: Danh sách kiểm tra nội bộ và/hoặc bên ngoài xác định các vai trò tài liệu hướng dẫn thiết kế chi tiết.
Các kỹ thuật thiết kế kiểm thử: Đánh giá kỹ thuật, thẩm tra.
Kiểm thử tĩnh 2: Khả năng sử dụng hạng mục thiết kế chi tiết
Mục tiêu kiểm thử: Để cung cấp thông tin về tính hữu ích của một hạng mục thiết kế chi tiết về ví dụ mã hóa hoặc kiểm thử.
Hạng mục kiểm thử: Hạng mục thiết kế chi tiết.
Cơ sở kiểm thử: N/A
Các kỹ thuật thiết kế kiểm thử: Trao đổi chuyên môn giữa lập trình viên hoặc người kiểm thử
Kiểm thử tĩnh 3: Thiết kế chi tiết hạng mục hoàn chỉnh
Mục tiêu kiểm thử: Để cung cấp thông tin về tính hoàn chỉnh của hạng mục thiết kế chi tiết.
Hạng mục kiểm thử: Hạng mục thiết kế chi tiết.
Cơ sở kiểm thử: Thông tin truy xuất nguồn gốc cho thiết kế cấp cao hơn và/hoặc yêu cầu.
Các kỹ thuật thiết kế kiểm thử: Đánh giá kỹ thuật
D.4 Quy trình kiểm thử con tích hợp
Ví dụ này trình bày quy trình kiểm thử con gắn liền với giai đoạn tích hợp trong vòng đời phát triển, nơi mà (kiểm thử) các thành phần đang dần được tích hợp.
Trong giai đoạn tích hợp một số hạng mục kiểm thử tương tự được xây dựng, đó là hai thành phần được tích hợp. Các kiểm thử động trong ví dụ này là tổng quát và có thể được thực hiện cho hai thành phần bất kỳ được tích hợp, từ hai thành phần đầu tiên được tích hợp vào một thành phần và cho đến khi hai thành phần cuối cùng được tích hợp vào các hệ thống hoàn chỉnh. Quy trình kiểm thử con tích hợp chỉ được hoàn thành khi tất cả các kiểm thử theo kế hoạch được hoàn thành (hoặc bị bỏ qua trường hợp có thể được).
Tích hợp có thể diễn ra ở các mức độ khác nhau, nó có thể được tích hợp một thành phần mã nguồn vào một thành phần (lớn hơn) và kết thúc với một hệ thống hoàn chỉnh, các loại phân hệ khác nhau (phần cứng, phần mềm, dữ liệu, tài liệu đào tạo, vv) được tích hợp vào một hệ thống hoàn chỉnh hoặc hệ thống hoàn chỉnh được tích hợp vào một thành phần (lớn hơn) và kết thúc với một hệ thống của các hệ thống. Các nguyên tắc là như nhau, mặc dù các hình thức phụ thuộc vào hồ sơ rủi ro.
Mục tiêu quy trình kiểm thử con: Cung cấp thông tin về sự tương tác của các thành phần tích hợp.
Nội dung quy trình kiểm thử con theo kế hoạch: Kiểm thử tĩnh: giao diện trực tiếp,
Kiểm thử động 1: giao diện trực tiếp,
Kiểm thử động 2: giao diện gián tiếp,
Kiểm thử động 3: Sự cùng tồn tại
Kiểm thử tĩnh: Giao diện trực tiếp
Mục tiêu kiểm thử: Để cung cấp thông tin về giao diện trực tiếp giữa hai thành phần tích hợp, ví dụ như trong các hình thức của một danh sách tham số.
Hạng mục kiểm thử: Mã nguồn cho giao diện giữa các thành phần được tích hợp.
Cơ sở kiểm thử: Thiết kế kiến trúc.
Quy trình kiểm thử chi tiết: Thiết kế kiểm thử và thực hiện, thiết lập môi trường kiểm thử và bảo trì, thực hiện kiểm thử và báo cáo sự cố kiểm thử.
Các kỹ thuật thiết kể kiểm thử: Đánh giá kỹ thuật hoặc thẩm tra tùy thuộc vào hồ sơ rủi ro.
Kiểm thử động 1: Giao điện gián tiếp
Mục tiêu kiểm thử: Để cung cấp thông tin về giao diện trực tiếp giữa hai thành phần tích hợp, ví dụ như trong các hình thức của một danh sách tham số.
Hạng mục kiểm thử: Giao diện giữa các thành phần được tích hợp.
Cơ sở kiểm thử: Thiết kế kiến trúc.
Quy trình kiểm thử chi tiết: Thiết kế kiểm thử và thực hiện, thiết lập môi trường kiểm thử và bảo trì, thực hiện kiểm thử và báo cáo sự cố kiểm thử.
Các kỹ thuật thiết kế kiểm thử: Kỹ thuật khi phù hợp.
Kiểm thử động 2: Indirect interface
Mục tiêu kiểm thử: Để cung cấp thông tin về giao diện gián tiếp giữa hai thành phần tích hợp, ví dụ thông qua một cơ sở dữ liệu.
Hạng mục kiểm thử: Thành phần được tích hợp.
Cơ sở kiểm thử: Thiết kế kiến trúc.
Quy trình kiểm thử chi tiết: Thiết kế và thực hiện kiểm thử; thiết lập môi trường kiểm thử và bảo trì; thực hiện kiểm thử; và báo cáo sự cố kiểm thử. Có thể sử dụng lại các thủ tục kiểm thử từ các quy trình con trước đó (tức là thành phần), nếu điều này là thiết kế ca kiểm thử và triển khai thực hiện có thể được giảm thiểu hoặc loại bỏ.
Các kỹ thuật thiết kế kiểm thử: Khi thích hợp.
Kiểm thử động 3: Cùng tồn tại
Mục tiêu kiểm thử: Để cung cấp thông tin về sự đồng tồn tại của một thành phần tích hợp (hoặc hệ thống hoàn chỉnh) với các hệ thống hiện có trong các môi trường.
Hạng mục kiểm thử: Các thành phần tích hợp (hoặc hệ thống hoàn chỉnh) và hệ thống hiện có trong môi trường.
Cơ sở kiểm thử: Thiết kế kiến trúc.
Quy trình kiểm thử chi tiết: Thiết kế và thực hiện kiểm thử; thiết lập môi trường kiểm thử và bảo trì; thực hiện kiểm thử; và báo cáo sự cố kiểm thử, có thể sử dụng lại các thủ tục kiểm thử từ các kiểm thử khác nhằm giảm thiểu nhu cầu về thiết kế và thực hiện kiểm thử.
Các kỹ thuật thiết kế kiểm thử: Khi thích hợp và có thể được bổ sung kinh nghiệm dựa và/hoặc kiểm thử tham dò.
D.5 Quy trình kiểm thử con hiệu năng
Ví dụ này trình bày một quy trình kiểm thử con tập trung vào hiệu năng của hệ thống.
Mục tiêu quy trình kiểm thử con: Cung cấp thông tin liên quan đến việc thực hiện các yêu cầu hiệu năng của hệ thống.
Nội dung quy trình kiểm thử con theo kế hoạch:
Kiểm thử tĩnh 1: Tài liệu yêu cầu hiệu năng,
Kiểm thử tĩnh 2: Tính hoàn chỉnh yêu cầu hiệu năng,
Kiểm thử tĩnh 3: Thiết kế kiến trúc liên quan tới hiệu năng,
Kiểm thử tĩnh 4: Thiết kế chi tiết liên quan tới hiệu năng,
Kiểm thử động 1: Khả năng áp dụng phân hệ liên quan tới hiệu năng,
Kiểm thử động 2: Hệ thống hoàn chỉnh liên quan tới hiệu năng.
Quy trình kiểm thử con này không được kết nối đến một giai đoạn cụ thể trong vòng đời phát triển. Các kiểm thử có thể được lên kế hoạch sẽ được thực hiện như các hạng mục kiểm thử có khả năng áp dụng đang được phát triển. Trong các kiểm thử tĩnh việc chuẩn bị có thể bắt đầu ngay sau khi sự phát triển của hạng mục kiểm thử được lập kế hoạch, thực hiện và theo dõi có thể diễn ra ngay sau khi các hạng mục kiểm thử được thông báo sẵn sàng để kiểm thử tĩnh. Đối với kiểm thử động, thiết kế và thực hiện có thể bắt đầu ngay sau khi cơ sở kiểm thử ổn định và thực thi có thể được thực hiện ngay sau khi các hạng mục kiểm thử thông báo đã sẵn sàng sẵn.
Mục này là một ví dụ về quy trình kiểm thử con có thể có liên quan đến các thuộc tính chất lượng. Các quy trình kiểm thử con tương tự có thể được định nghĩa về ví dụ cho các chức năng, khả năng hoạt động và tính khả chuyển.
Kiểm thử tĩnh 1: Tài liệu các yêu cầu hiệu năng
Mục tiêu kiểm thử: Để cung cấp thông tin về chất lượng của các yêu cầu hiệu năng.
Hạng mục kiểm thử: Bộ các yêu cầu hiệu năng.
Cơ sở kiểm thử: Danh sách kiểm tra nội bộ và/hoặc bên ngoài cho các tài liệu về các yêu cầu hiệu năng, ví dụ liên quan đến khả năng kiểm thử.
Các kỹ thuật thiết kế kiểm thử: Đánh giá kỹ thuật hoặc thẩm tra (nên nhớ rằng việc thẩm tra phải được chuẩn bị trước bởi đánh giá không chính thức hoặc kỹ thuật để đảm bảo một kỳ hạn nhất định các yêu cầu để được kiểm tra).
Kiểm thử tĩnh 2: Tính hoàn chỉnh các yêu cầu hiệu năng
Mục tiêu kiểm thử: Để cung cấp thông tin về tính hoàn chỉnh của các yêu cầu hiệu năng (tất cả các yêu cầu chức năng có liên quan đến các yêu cầu hiệu năng ).
Hạng mục kiểm thử: Tất cả các yêu cầu.
Cơ sở kiểm thử: Thông tin truy xuất nguồn gốc theo chiều dọc giữa các yêu cầu chức năng và yêu cầu hiệu năng.
Các kỹ thuật thiết kế kiểm thử: Đánh giá kỹ thuật.
Kiểm thử tĩnh 3: Thiết kế kiến trúc liên quan tới năng lực thực thi
Mục tiêu kiểm thử: Để cung cấp thông tin về làm thế nào các yêu cầu năng lực thực thi đã được đưa vào thiết kế kiến trúc.
Hạng mục kiểm thử: Thiết kế kiến trúc.
Cơ sở kiểm thử: Các yêu cầu năng lực thực thi và danh sách kiểm tra..
Các kỹ thuật thiết kế kiểm thử: Trao đổi chuyên môn, đánh giá kỹ thuật hoặc thẩm tra (nên nhớ rằng việc thẩm tra phải được chuẩn bị trước bởi đánh giá không chính thức hoặc kỹ thuật để đảm bảo một kỳ hạn nhất định các yêu cầu để được kiểm tra).
Kiểm thử tĩnh 4: Thiết kế chi tiết liên quan tới năng lực thực thi
Mục tiêu kiểm thử: Để cung cấp thông tin về làm thế nào các yêu cầu năng lực thực thi đã được đưa vào thiết kế chi tiết.
Hạng mục kiểm thử: Một hoặc nhiều hạng mục thiết kế chi tiết khi phù hợp.
Cơ sở kiểm thử: Các yêu cầu năng lực thực thi và danh sách kiểm tra.
Các kỹ thuật thiết kế kiểm thử: Trao đổi chuyên môn, đánh giá kỹ thuật hoặc thẩm tra (nên nhớ rằng việc thẩm tra phải được chuẩn bị trước bởi đánh giá không chính thức hoặc kỹ thuật để đảm bảo một kỳ hạn nhất định các yêu cầu để được kiểm tra).
Kiểm thử động 1: Khả năng áp dụng phân hệ liên quan tới năng lực thực thi
Mục tiêu kiểm thử: Để cung cấp thông tin về năng lực thực thi của một phân hệ cụ thể.
Hạng mục kiểm thử: Một hoặc nhiều phân hệ có liên quan.
Cơ sở kiểm thử: Các yêu cầu năng lực thực thi và các rủi ro năng lực thực thi xác định có thể có.
Quy trình kiểm thử chi tiết: Thiết kế và thực hiện kiểm thử, thiết lập môi trường kiểm thử, bảo trì, thực hiện kiểm thử và báo cáo sự cố kiểm thử. Một số thủ tục kiểm thử để kiểm thử tích hợp có thể được sử dụng lại.
Các kỹ thuật thiết kế kiểm thử: Các kỹ thuật có khả năng áp dụng.
Điều này hoặc các kiểm thủ này thường được thực hiện trong thời gian quy trình kiểm thử con tích hợp.
Kiểm thử động 2: Hệ thống hoàn chỉnh liên quan tới hiệu năng
Mục tiêu kiểm thử: Để cung cấp thông tin về hiệu năng của một hệ thống tích hợp hoàn chỉnh.
Hạng mục kiểm thử: Hệ thống hoàn chỉnh.
Cơ sở kiểm thử: Các yêu cầu hiệu năng và các rủi ro hiệu năng xác định có thể có.
Quy trình kiểm thử chi tiết: Thiết kế và thực hiện kiểm thử, thiết lập môi trường kiểm thử, bảo trì, thực hiện kiểm thử và báo cáo sự cố kiểm thử. Một số thủ tục kiểm thử để kiểm thử tích hợp có thể được sử dụng lại.
Các kỹ thuật thiết kế kiểm thử: Các kỹ thuật có khả năng áp dụng.
Kiểm thử này thường được thực hiện trong thời gian quy trình kiểm thử con hệ thống.
D.6 Quy trình kiểm thử con hồi quy
Ví dụ này trình bày một quy trình kiểm thử con tổng quát sẽ được thực hiện theo một sự thay đổi thực hiện trong một hạng có mục liên quan đến các hạng mục kiểm thử và/hoặc sự thay đổi môi trường trong đó hạng mục kiểm thử đang chạy. Quy trình kiểm thử con được sử dụng cho một hạng mục kiểm thử trước đó có thông qua một hoặc nhiều kiểm thử và được đánh giá là không bị ảnh hưởng bởi các thay đổi thực hiện.
Quy trình kiểm thử con có thể được thực hiện như là một phần của quy trình kiểm thử con bất kỳ khác và vào bất kỳ hạng mục kiểm thử. Việc lựa chọn các hạng mục kiểm thử phụ thuộc vào bản chất của các thay đổi và hồ sơ rủi ro. Số lượng các kiểm thử hồi quy cần thiết cho một quy trình kiểm thử con thuộc vào chất lượng ban đầu của các hạng mục kiểm thử và các tiêu chí hoàn thành kiểm thử.
Mục tiêu quy trình kiểm thử con: Để cung cấp thông tin về tình trạng của các hạng mục kiểm thử khi thay đổi (có liên quan đến các hạng mục kiểm thử hay không) đã được triển khai.
Nội dung quy trình kiểm thử con theo kế hoạch: Thực hiện lại các kiểm tra tĩnh trước đây hoặc các kiểm thử động thực thi là phù hợp.
Kiểm thử hồi quy:
Mục tiêu kiểm thử: Để cung cấp thông tin về chất lượng của các hạng mục kiểm thử thay đổi trên các hạng mục kiểm thử không thay đổi.
Hạng mục kiểm thử: Hạng mục kiểm thử theo đề nghị.
Cơ sở kiểm thử: Khi phù hợp.
Quy trình kiểm thử chi tiết: Thiết lập môi trường kiểm thử và bảo trì, thực hiện kiểm thử và báo cáo sự cố kiểm thử. Thiết kế và thực hiện kiểm thử là không cần thiết, vì kiểm thử này được thực hiện bằng cách sử dụng thủ tục kiểm thử được lựa chọn đã được thông qua.
Các kỹ thuật thiết kế kiểm thử: Khi phù hợp.
Kiểm thử tĩnh 1: Tài liệu hướng dẫn yêu cầu
Mục tiêu kiểm thử: Để cung cấp thông tin về cách thức các yêu cầu được ghi nhận.
Hạng mục kiểm thử: Các yêu cầu được chọn (tất cả hoặc một nhóm).
Cơ sở kiểm thử: Danh sách kiểm tra nội bộ và/hoặc bên ngoài, ví dụ liên quan đến một kiểu tài liệu hướng dẫn yêu cầu cụ thể và/hoặc liên quan đến thông tin có liên quan như nhận dạng duy nhất, ưu tiên và khởi tạo.
Các kỹ thuật thiết kế kiểm thử: Đánh giá kỹ thuật hoặc thẩm tra (nên nhớ rằng việc thẩm tra phải được chuẩn bị trước bởi đánh giá không chính thức hoặc kỹ thuật để đảm bảo một kỳ hạn nhất định các yêu cầu để được kiểm tra).
Kiểm thử tĩnh 2: Khả năng sử dụng các yêu cầu
Mục tiêu kiểm thử: Để cung cấp thông tin về tính hữu ích của các yêu cầu về thiết kế hoặc kiểm thử.
Hạng mục kiểm thử: Các yêu cầu được chọn (tất cả hoặc một nhóm).
Cơ sở kiểm thử: N/A.
Các kỹ thuật thiết kế kiểm thử: Trao đổi chuyên môn giữa những người thiết kế và người kiểm thử.
Kiểm thử tĩnh 3: Tính hoàn chỉnh các yêu cầu
Mục tiêu kiểm thử: Để cung cấp thông tin về tính hoàn chỉnh về tập các yêu cầu.
Hạng mục kiểm thử: Các yêu cầu được chọn (tất cả hoặc một nhóm).
Cơ sở kiểm thử: Danh sách kiểm tra và/hoặc thông tin truy xuất nguồn gốc cho các yêu cầu mức cao hơn.
Các kỹ thuật thiết kế kiểm thử: Đánh giá kỹ thuật.
D.7 Quy trình kiểm thử con kiểm thử lại
Ví dụ này trình bày một quy trình kiểm thử con tổng quát sẽ được thực hiện theo sự thay đổi thực hiện trong một hạng mục do một khiếm khuyết tìm thấy trong một thực hiện kiểm thử trước đó, tức là cho một hạng mục kiểm thử trước đó có thất bại.
Quy trình kiểm thử con có thể được thực hiện như là một phần của quy trình kiểm thử con khác bất kỳ và vào hạng mục kiểm thử bất kỳ.
Kiểm tra tiểu trình Mục tiêu: Cung cấp thông tin về một khiếm khuyết được báo cáo là loại bỏ.
Kế hoạch kiểm tra nội dung tiểu trình: Thực hiện lại kiểm tra tĩnh không thành công trước đó hoặc kiểm thử nghiệm động được thực hiện khi phù hợp.
Kiểm thử lại:
Mục tiêu kiểm thử: Để cung cấp thông tin về chất lượng của các hạng mục kiểm thử đã thay.
Hạng mục kiểm thử: Hạng mục kiểm thử theo đề nghị.
Cơ sở kiểm thử: Khi phù hợp.
Quy trình kiểm thử chi tiết: Thiết kế và thực hiện kiểm thử, thiết lập môi trường kiểm thử và bảo trì, thực hiện kiểm thử và báo cáo sự cố kiểm thử. Thiết kế và thực hiện kiểm tra không bắt buộc kể từ kiểm thử này được thực hiện bằng cách sử dụng thủ tục kiểm thử đã thất bại trước đó.
Các kỹ thuật thiết kế kiểm thử: Khi phù hợp.
D.8 quy trình kiểm thử con tập câu chuyện
Ví dụ này trình bày một quy trình kiểm thử con gắn liền với việc lựa chọn các đơn hàng để xử lý trong một bước nước rút cụ thể dựa trên đơn hàng dự án hiện tại.
Mục tiêu quy trình kiểm thử con: Để cung cấp thông tin về chất lượng về tập các câu chuyện để thực hiện trên bước một nước rút cụ thể..
Nội dung quy trình kiểm thử con theo kế hoạch: Kiểm thử tĩnh: tính khả thi của câu chuyện.
Kiểm thử tĩnh: Tính khả thi của câu chuyện
Mục tiêu kiểm thử: Để cung cấp thông tin về tập các câu chuyện được lựa chọn.
Hạng mục kiểm thử: Các cầu chuyện được chọn.
Cơ sở kiểm thử: Danh sách kiểm tra, ví dụ liên quan đến sự hiểu biết về những câu chuyện và ước tính thời gian phát triển, cũng như sự phụ thuộc và tính nhất quán giữa các câu chuyện..
Quy trình kiểm thử chi tiết: Thiết kế và thực hiện kiểm thử, thiết lập môi trường kiểm thử và bào trì, thực hiện kiểm thử và báo cáo sự cố kiểm thử. Thiết kế và thực hiện kiểm tra không bắt buộc kể từ kiểm thử này được thực hiện bằng cách sử dụng thủ tục kiểm thử đã thất bại trước đó.
Các kỹ thuật thiết kế kiểm thử: Đánh giá không chính thức hoặc đánh giá kỹ thuật.
D.9 Quy trình kiểm thử con câu chuyện
Ví dụ này trình bày một quy trình kiểm thử con gắn liền với hoàn thành việc thực hiện câu chuyện trước khi kể câu chuyện trong xây dựng hàng ngày (hoặc tỷ lệ quyết định cho việc xây dựng mới).
Quá trình phát triển câu chuyện trong đơn hàng chạy nước rút một sổ hạng mục kiểm thử tương tự được xây dựng, đó là việc thực hiện một câu chuyện. Do đó, quy trình kiểm thử con toàn bộ câu chuyện có thể bao phủ việc kiểm thử một hoặc nhiều câu chuyện, tùy thuộc vào bao nhiêu câu chuyện được thực hiện trước khi xây dựng. Những câu chuyện thực hiện được kiểm thử riêng theo các cách tương tự. Các kiểm thử động trong ví dụ này là tổng quát và có thể được thực hiện cho bất kỳ câu chuyện nào. Quy trình kiểm thử con câu chuyện chỉ hoàn thành khi tất cả các kiểm thử theo kế hoạch được hoàn thành (hoặc bị bỏ qua trường hợp có thể được).
Mục tiêu quy trình kiểm thử con: Cung cấp thông tin về những câu chuyện thực hiện trước khi đưa nó vào xây dựng.
Nội dung quy trình kiểm thử con theo kế hoạch: Kiểm thử tĩnh: Các thuộc tính chất lượng mã nguồn.
Kiểm thử động: Kiểm thử cầu chuyện, kiểm thử thăm dò.
Kiểm thử tĩnh: Các thuộc tính chất lượng mã nguồn
Mục tiêu kiểm thử: Để cung cấp thông tin về chất lượng lượng mã nguồn.
Hạng mục kiểm thử: Mã nguồn được tạo hoặc bị ảnh hưởng bởi việc thực hiện câu chuyện.
Cơ sở kiểm thử: Danh sách kiểm tra nội bộ và/hoặc bên ngoài, ví dụ liên quan đến một kiểu viết mã cụ thể, và/hoặc mã hóa bất thường như sử dụng một biến trước khi nó được khai báo.
Quy trình kiểm thử chi tiết: Thiết kế và thực hiện kiểm thử, thiết lập môi trường kiểm thử và bảo trì, thực hiện kiểm thử và báo cáọ sự cố kiểm thử. Thiết kế và thực hiện kiểm tra không bắt buộc kể từ kiểm thử này được thực hiện bằng cách sử dụng thủ tục kiểm thử đã thất bại trước đó.
Các kỹ thuật thiết kế kiểm thử: Đánh giá kỹ thuật hoặc phân tích tĩnh.
Kiểm thử động: Kiểm thử câu chuyện
Mục tiêu kiểm thử: Để cung cấp thông tin về chất lượng lượng thực hiện cầu chuyện.
Hạng mục kiểm thử: Câu chuyện được thực hiện trong một môi trường cô lập từ xây dựng.
Cơ sở kiểm thử: Câu chuyện.
Quy trình kiểm thử chi tiết: Thiết kế và thực hiện kiểm thử, thiết lập môi trường kiểm thử và bảo trì, thực hiện kiểm thử và báo cáo sự cố kiểm thử.
Các kỹ thuật thiết kế kiểm thử: Kỹ thuật phù hợp, bổ sung cho phù hợp với các kỹ thuật để đạt được mức bao phủ cần thiết.
D.10 Quy trình kiểm thử con hệ thống
Ví dụ này trình bày một quy trình kiểm thử con gắn liền với việc giai đoạn hoàn thành hệ thống, có thể được kết hợp với một giai đoạn định nghĩa là giai đoạn trưởng thành sẽ được hoàn thành trước khi hệ thống có thể được thông báo sẵn sàng cho thử nghiệm chấp nhận.
Mục tiêu quy trình kiểm thử con: Cung cấp thông tin về chất lượng của hệ thống đầy đủ.
Nội dung quy trình kiểm thử con theo kế hoạch: Kiểm thử động: Kiểm thử hệ thống.
Kiểm thử động: Kiểm thử hệ thống
Mục tiêu kiểm thử: Để đánh giá chất lượng của hệ thống hoàn chỉnh sau khi tích hợp.
Hạng mục kiểm thử: Hệ thống hoàn chỉnh.
Cơ sở kiểm thử: Các yêu cầu hệ thống.
Quy trình kiểm thử chi tiết: Thiết kế và thực hiện kiểm thử, thiết lập môi trường kiểm thử và bảo trì, thực hiện kiểm thử và báo cáo sự cố kiểm thử.
Các kỹ thuật thiết kế kiểm thử: Kỹ thuật phân vùng tương đương, phân tích giá trị biên, kiểm thử chuyển đổi trạng thái và phương pháp cây phân loại cho phù hợp.
Mục tiêu của kiểm thử hệ thống là để tìm các khiếm khuyết trong các tính năng của hệ thống so với cách nó đã được xác định trong các yêu cầu hệ thống phần mềm.
Nên được dự kiến rằng một số quy trình kiểm thử con lại và quy trình kiểm thử con hồi quy sẽ là cần thiết để đạt được các tiêu chí hoàn thiện cho kiểm thử hệ thống.
D.11 Quy trình kiểm thử con thành phần
Ví dụ này trình bày quy trình kiểm thử con gắn liền với các giai đoạn mã hóa của vòng đời phát triển.
Trong giai đoạn mã hóa một số hạng hạng mục kiểm thử tương tự được xây dựng, đó là các thành phần mã nguồn có thể là các thành phần có khả năng biên dịch hoặc được biên dịch và liên kết thành các thành phần có khả năng thực thi. Do đó, quy trình kiểm thử con toàn bộ thành phần có thể bao phủ các kiểm thử của tất cả hoặc một số các thành phần riêng theo cách tương tự. Các kiểm thử động trong ví dụ này là tổng quát và có thể được thực hiện đối với thành phần bất kỳ nào. Quy trình kiểm thử con thành phần chỉ hoàn thành khi tất cả các kiểm thử theo kế hoạch được hoàn thành (hoặc bỏ qua trường hợp có thể được).
Mục tiêu quy trình kiểm thử con: Cung cấp thông tin về chất lượng của thành phần.
Nội dung quy trình kiểm thử con theo kế hoạch: Kiểm thử động: Kiểm thử thành phần.
Kiểm thử động: Kiểm thử thành phần
Mục tiêu kiểm thử: Cung cấp thông tin về chất lượng của thành phần
Hạng mục kiểm thử: Một thành phần trong sự cô lập từ các thành phần khác trong hệ thống (có thể cần điều khiển và khai).
Cơ sở kiểm thử: Thiết kế chi tiết cho các thành phần, bao gồm truy xuất nguồn gốc theo yêu cầu.
Quy trình kiểm thử chi tiết: Thiết kế và thực hiện kiểm thử, thiết lập môi trường kiểm thử và bảo trì, thực hiện kiểm thử và báo cáo sự cố kiểm thử.
Các kỹ thuật thiết kế kiểm thử: Kỹ thuật phù hợp, bổ sung cho phù hợp với các kỹ thuật để đạt được độ bao phủ cần thiết..
Vai trò và trách nhiệm trong kiểm thử
E.1 Vai trò kiểm thử
Có một loạt các tên cho các vai trò khác nhau trong nghề kiểm thử do đó tiêu chuẩn này không cung cấp một danh sách toàn diện về vai trò và trách nhiệm dự định là đại diện của nghề kiểm thử toàn cầu. Thay vào đó, các vai trò sau đây được nêu ở xa như vậy người có thể điền vào vai trò đó sẽ chịu trách nhiệm hoàn tất một số khía cạnh của quá trình trình thử được nêu trong tiêu chuẩn này. Nhiều hơn một người có thể có trách nhiệm đối với môi vai trò dưới đây.
Người lập chiến lược kiểm thử
Thiết lập, và đảm bảo sự phù hợp với quy trình kiểm tra của tổ chức.
Người quản lý kiểm thử
Phát triển, quản lý và đảm bảo sự phù hợp với các quy trình quản lý kiểm thử. Người quản lý kiểm thử cũng có kế hoạch và kiểm soát các quy trình kiểm thử động.
Người kiểm thử
Phát triển các sản phẩm kiểm thử có khả năng chuyển giao và hoàn thiện các quy trình liên quan đến quy trình kiểm thử động.
Trong thực tế, các quy trình đã nêu trong tiêu chuẩn này có thể sẽ được hoàn thành bởi một loạt các người với một loạt các chức danh công việc.
E.2 Truyền thông trong kiểm thử
Người kiểm thử cần phải giao tiếp với những người ở mức độ phù hợp của tổ chức cũng như các bên liên quan trong các tổ chức bên ngoài (ví dụ như các nhà phát triển của các hạng mục kiểm thử, các nhà tài trợ sản phẩm, các đội hỗ trợ và bán hàng và nhân viên kinh doanh). Trạng thái kiểm thử cần phải được truyền đạt một cách kịp thời, phù hợp với tiến độ dự án. Thông tin có thể được dựa trên các tài liệu bằng văn bản như chiến lược kiểm thử của tổ chực, kế hoạch kiểm thử, báo cáo trạng thái kiểm thử và báo cáo kết thúc kiểm thử. Tài liệu hướng dẫn bằng văn bản có thể được đi kèm với bài thuyết trình, thường là trường hợp chính thức hơn trong phát triển tuần tự hoặc tiến hóa. Trong hình thức phát triển không chính thức, chẳng hạn như linh hoạt trong giao tiếp chủ yếu có thể bằng miệng, được hỗ trợ bởi các tài liệu bằng văn bản theo yêu cầu.
E.3 Tính độc lập trong kiểm thử
Kiểm thử nên càng khách quan càng tốt. Các địa điểm gần nhà phân tích kiểm thử là tác giả của các hạng mục kiểm thử, các khó khăn hơn là phải khách quan. Nó thường được chấp nhận la khó khăn hơn cho một tác giả để tìm khiếm khuyết trong công việc của mình hơn là cho một kiểm thử độc lập để tìm các khiếm khuyết tương tự. Độc lập trong việc đánh giá sản phẩm rất phổ biến trong nhiều ngành công nghiệp, ví dụ như xuất bản, nơi mà các biên tập viên thực hiện việc giám định; sản xuất, nơi có kiểm soát chất lượng; và xây dựng nhà, nơi có thanh tra viên xây dựng.
Các mức độ độc lập gia tăng giữa tác giả và người kiểm thử:
a) Tác giả kiểm thử hoặc sản phẩm là của riêng mình;
b) Các kiểm thử được thiết kế và thực hiện bởi một người khác với tác giả, nhưng có các trách nhiệm giống nhau, điển hình là một tác giả là một thành viên của cùng một đơn vị tổ chức khi tác giả báo cáo cho cùng một người quản lý;
c) Các kiểm thử được thiết kế và thực hiện bởi một người kiểm thử là một thành viên của cùng một đơn vị tổ chức khi tác giả, báo cáo cho cùng một người quản lý;
d) Các kiểm thử được thiết kế và thực hiện bởi người kiểm thử độc lập của các đơn vị tổ chức sản xuất, mặc dù vẫn trong trong nhà;
e) Các kiểm thử được thiết kế và thực hiện bởi các người kiểm thử làm việc cho một tổ chức bên ngoài (tư vấn), nhưng làm việc trong các tổ chức tương tự như tác giả;
f) Các kiểm thử được thiết kế và thực hiện bởi các người kiểm thử trong một tổ chức bên ngoài (kiểm thử bởi bên thứ ba).
Ý định là để đạt được càng nhiều sự độc lập giữa những người thiết kế các ca kiểm thử và những người xât dựng các hạng mục kiểm thử càng tốt trong các ràng buộc của dự án về thời gian, ngân sách, chất lượng và rủi ro. Chiến lược kiểm thư của tổ chức nên xác định mức độ cần thiết của sự độc lập trong tổ chức và điều này cần được thửa kế trong kế hoạch kiểm thử dự án và kế hoạch cho các quy trình kiểm thử con ở bàn tay. Các tình huống rủi ro cao hơn thường dẫn đến một mức độ cao hơn của sự độc lập. IEEE 1012-2004, Tiêu chuẩn IEEE để xác minh và xác nhận phần mềm đưa ra các khái niệm về độc lập trong hoạt động xác minh và xác nhận, bao gồm kiểm thử.
Các mức độ độc lập thường thay đổi đối với các quy trình kiểm thử con khác nhau. Trong kiểm thử thành phần động mức độ thấp nhất của độc lập (tức là không có độc lập) thường được nhìn thấy, mặc dù cùng một mức độ độc lập áp dụng trong đánh giá ngang hàng (kiểm thử tĩnh thực hiện bởi các nhà phát triển) thường không được coi là chấp nhận được.
Nếu kiểm thử trong một dự án linh hoạt, khái niệm về một đội ngũ các nhà phát triển tích hợp và kiểm thử thông thường có nghĩa là các mức độ cao hơn của sự độc lập có thể khó khăn để đạt được. Trong các tình huống như vậy cần phải thận trọng để đàm bảo rằng càng nhiều tính độc lập càng tốt là đạt được.
Thư mục tài liệu tham khảo
[1] BS 7925-1:1998, Software testing - Vocabulary (Kiểm thử phần mềm - Từ vựng)
[2] BS 7925-2:1998, Software testing - Software component testing (Kiểm thử phần mềm - Kiểm thử thành phần phần mềm)
[3] CRISPIN, L. and GREGORY, J. 2009. Agile Testing: A Practical Guide for Testers and Agile Teams. Pearson Education (Hướng dẫn thực hành cho kiểm thử viên và nhóm linh hoạt)
[4] IEC 60300-3-9:1995, Risk analysis of technological systems (Phân tích rủi ro cho các hệ thống kỹ thuật)
[5] IEEE Std 610.12-1995, IEEE Standard Glossary of Software Engineering Terminology (Thuật ngữ theo tiêu chuẩn IEEE của Thuật ngữ kỹ thuật phần mềm)
[6] IEEE Std 829-2008, IEEE Standard for Software and System Test Documentation (Tiêu chuẩn IEEE cho Tài liệu kiểm thử hệ thống và phần mềm)
[7] IEEE Std 1008-1987, IEEE Standard for Software Unit Testing (Tiêu chuẩn IEEE cho Kiểm thử đơn vị phần mềm)
[8] IEEE Std 1012-2012, IEEE Standard for Software Verification and Validation (Tiêu chuẩn IEEE cho xác minh và xác nhận phần mềm)
[9] IEEE Std 1028-2008, IEEE Standard for Software Reviews and Audits (Tiêu chuẩn IEEE cho kiểm tra và đánh giá phần mềm)
[10] ISO/IEC 12207:2008, Systems and software engineering - Software life cycle processes (Kỹ thuật hệ thống và phần mềm- Quy trình vòng đời phần mềm)
[11] ISO/IEC 15026-3:2011, Information technology - System and software integrity levels (Công nghệ thông tin - Mức độ toàn vẹn của hệ thống và phần mềm)
[12] ISO/IEC 16085:2006, Systems and software engineering - Life cycle processes - Risk management (Kỹ thuật hệ thống và phần mềm - Quy trình vòng đời - Quản lý rủi ro)
[13] ISO/IEC/IEEE 24765:2010, Systems and software engineering - Vocabulary (Kỹ thuật hệ thống và phần mềm - Từ vựng)
[14] ISO/IEC 25000:2005, Software Engineering - Software product Quality Requirements and Evaluation (SQuaRE) - Guide to SquaRE (Kỹ thuật phần mềm - Đánh giá và yêu cầu về chất lượng sản phẩm phần mềm (SQuaRE) - Hướng dẫn về đánh giá và yêu cầu về chất lượng sản phẩm phần mềm)
[15] ISO/IEC 25010:2011, Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - System and software quality models (Kỹ thuật phần mềm - Đánh giá và yêu cầu về chất lượng sản phẩm phần mềm (SQuaRE) - Các mô hình chất lượng hệ thống và phần mềm)
[16] ISO/IEC 25051:2006, Software engineering - Software product Quality Requirements and Evaluation (SQuaRE) - Requirements for quality of Commercial Off-The-Shelf (COTS) software product and instructions for testing (Kỹ thuật phần mềm - Đánh giá và yêu cầu về chất lượng sản phẩm phần mềm (SQuaRE) - Yêu cầu về chất lượng của sản phẩm phần mềm thương mại không trên kệ (Off-The-Shelf) và hướng dẫn kiểm tra)
[17] International Software Testing Qualifications Board (ISTQB), standard glossary of terms used in Software Testing [online]. 2010. Updated 1 April 2010 [viewed 11 April 2011]. Available from: http://www.istgb.org (Thuật ngữ tiêu chuẩn được sử dụng trong kiểm thử phần mềm của Hội đồng kiểm tra phần mềm kiểm tra phần mềm quốc tế (ISTQB))
[18] KOEN, B. V., 1985. Definition of the Engineering Method. American Society for Engineering Education (Định nghĩa về phương pháp kỹ thuật của Hiệp hội giáo dục kỹ thuật Hoa Kỳ).
Mục lục
Lời nói đầu
Lời giới thiệu
1. Phạm vi áp dụng
2. Sự tuân thủ
3. Tài liệu viện dẫn
4. Thuật ngữ và Định nghĩa
5 Các khái niệm về kiểm thử phần mềm
5.1 Giới thiệu kiểm thử phần mềm
5.1.1 Vai trò của kiểm thử trong việc xác minh và xác nhận
5.1.2 Kiểm thử thấu đáo
5.1.3 Kiểm thử phòng đoán
5.2 Kiểm thử phần mềm trong bối cảnh dự án và tổ chức
5.2.1 Quy trình kiểm thử
5.3 Quy trình kiểm thử tổng quát trong vòng đời phần mềm
5.3.1 Các quy trình con dự án phát triển và kết quả
5.3.2 Hoạt động bảo trì và kết quả
5.3.3 Quy trình hỗ trợ cho vòng đời phát triển phần mềm
5.4 Kiểm thử dựa trên rủi ro
5.4.1 Sử dụng kiểm thử dựa trên rủi ro trong quy trình kiểm thử của tổ chức
5.4.2 Sử dụng kiểm thử dựa trên rủi ro trong quy trình quản lý kiểm thử
5.4.3 Sử dụng kiểm thử dựa trên rủi ro trong các quy trình kiểm thử động
5.5 Quy trình kiểm thử con
5.5.1 Mục tiêu kiểm thử
5.5.2 Hạng mục kiểm thử
5.5.3 Kiểm thử đặc tính chất lượng
5.5.4 Cơ sở kiểm thử
5.5.5 Kiểm thử lại và kiểm thử hồi quy
5.5.6 Kỹ thuật thiết kế kiểm thử
5.6 Thực hành kiểm thử
5.6.1 Giới thiệu
5.6.2 Kiểm thử dựa trên yêu cầu
5.6.3 Kiểm thử dựa trên mô hình
5.6.4 Kiểm thử dựa trên toán học
5.6.5 Kiểm thử dựa trên kinh nghiệm
5.6.6 Kiểm thử có kịch bản và phi kịch bản
5.7 Tự động hóa trong kiểm thử
5.8 Quản lý khiếm khuyết
Phụ lục A (Tham khảo ) Vai trò của kiểm thử trong việc xác minh và xác nhận
Phụ lục B (Tham khảo) Các thước đo và đánh giá
B. 1 Các thước đo và đánh giá
Phụ lục C (Tham khảo) Kiểm thử trong các mô hình vòng đời khác nhau
C. 1 Tổng quan
C.2 Phát triển và kiểm thử linh hoạt
C.2.1 Các nguyên tắc phát triển linh hoạt
C.2.2 Quản lý kiểm thử trong phát triển linh hoạt
C.2.3 Quy trình kiểm thử con trong phát triển linh hoạt
C.3 Phát triển tuần tự và kiểm thử
C.3.1 Nguyên tắc phát triển tuần tự
C.3.2 Quản lý kiểm thử trong phát triển tuần tự
C.3.3 Quy trình kiểm thử con trong phát triển tuần tự
C.4 Phát triển tiến hóa và kiểm thử
C.4.1 Nguyên tắc phát triển tiến hỏa
C.4.2 Quản lý kiểm thử trong phát triển tiến hóa
C.4.3 Quy trình kiểm thử con trong phát triển tiến hóa
Phụ lục D (Tham khảo) Các vụ dụ về quy trình kiểm thử con chi tiết
D. 1 Tổng quan
D.2 Quy trình kiểm thử con chấp nhận
D.3 Quy trình kiểm thử con thiết kế chi tiết
D.4 Quy trình kiểm thử con tích hợp
D.5 Quy trình kiểm thử con hiệu năng
D.6 Quy trình kiểm thử con hồi quy
D.7 Quy trình kiểm thử con kiểm thử lại
D.8 quy trình kiểm thử con tập câu chuyện
D.9 Quy trình kiểm thử con câu chuyện
D.10 Quy trình kiểm thử con hệ thống
D.11 Quy trình kiểm thử con thành phần
Phụ lục E (Tham khảo) Vai trò và trách nhiệm trong kiểm thử
E. 1 Vai trò kiểm thử
E.2 Truyền thông trong kiểm thử
E.3 Tính độc lập trong kiểm thử
Thư mục tài liệu tham khảo
Ý kiến bạn đọc
