Thuộc tính
Nội dung
Tiếng Anh (English)
Văn bản gốc/PDF
Lược đồ
Liên quan hiệu lực
Liên quan nội dung
Thuộc tính
Tải về
Các bản dự thảo

Đang tải văn bản...

Tiêu chuẩn quốc gia TCVN 12849-1:2020 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

Số hiệu:	TCVN12849-1:2020	Loại văn bản:	Tiêu chuẩn Việt Nam
Nơi ban hành:	***	Người ký:	***
Ngày ban hành:	Năm 2020	Ngày hiệu lực:
ICS:	35.080	Tình trạng:	Đã biết

Ư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à

...

Bạn phải đăng nhập hoặc đăng ký Thành Viên TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.

Mọi chi tiết xin liên hệ: ĐT: (028) 3930 3279 DĐ: 0906 22 99 66

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ở.

5.8 Quản lý khiếm khuyết

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.

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

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.

...

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á

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;

...

- 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ể).

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

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

...

- 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à

...

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:

...

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.

...

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ự.

...

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ử

...

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.

...

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ử 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.

Phụ lục D

(Tham khảo)

Các ví dụ về quy trình kiểm thử con chi tiết

...

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ử 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ử;

...

- 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.

...

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 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

...

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.

...

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 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ố.

...

Cơ sở kiểm thử: Thiết kế kiến trúc.

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.

...

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 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.

...

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.

...

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.

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ể.

...

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ó.

...

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ị.

...

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.

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ử.

...

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.

...

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

...

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

...

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 đó.

...

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 đủ.

...

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.

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

...

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.

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..

...

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ử

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.

...

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ý;

...

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)

...

[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)

...

[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

...

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.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.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.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.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.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.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

...