BÀI 3 - QUY TRÌNH KIỂM THỬ PHẦN MỀM

BÀI 3. QUY TRÌNH KIỂM THỬ PHẦN MỀM

1. Quy trình kiểm thử phần mềm tổng quát
2. Lâp kế hoac̣ h kiêm̉ tra ( Test Plan)
3. Chuẩn bi ̣môi trƣờng kiểm tra
4. Thiết kế kiểm tra ( Test Design)
5. Thƣc hiện kiểm tra ( Test Execute)
6. Thẩm tra và đánh giá kết quả kiểm tra
7. Ghi nhân và xƣ̉ lý lỗi
8. Lâp kế hoac̣h và triển khai kiểm thử hồi quy
9. Thông báo phát hành sản phẩm
10. Xây dựng kế hoạch kiểm thử
11. Các thành phần chính trong kế hoạch kiểm thử

3.1. Quy trình kiểm thử phần mềm tổng quát

Quy trình kiểm thử phần mềm là gì?

• Chế độ kiểm thử đƣợc định nghĩa bởi tổchức phát triển phần mềm là gì.
• Cần có chiến lƣợc kiểm thửvà nó sẽlý giải tại sao tổ chức phần mềm kiểm thử các thành phần mà mình tạo ra.
• Cần nhận dạng cái gì là quan trọng đối với tổchức (chi phí, chất lƣợng, thời gian, phạm vi,..) và cách nào, bởi ai và khi nào việc kiểm thửsẽ đƣợc thực hiện.

Tất cảcác thông tin trên sẽ đƣợc lập thành tài liệu cho hoạt động kiểm thử và ta có thể gọi qui trình tạo lập tài liệu này là qui trình kiểm thử phần mềm (Test Process).

Tạo sao cần phải thực hiện qui trình kiểm thửphần mềm ?

• Cần làm rõ vai trò và trách nhiệm của việc kiểm thử phần mềm.
• Cần làm rõ các công đoạn, các bƣớc kiểm thử.
• Cần phải hiểu và phân biệt các tính chất kiểm thử(tạo sao phải kiểm thử), các bƣớc kiểm thử (khi nào kiểm thử), và các kỹ thuật kiểm thử(kiểm thử bằng cách nào).

Các tính chất của qui trình kiểm thử tốt :

• Cần có 1 mức độ kiểm thử cho mỗi công đoạn phát triển phần mềm.
• Các mục tiêu kiểm thử sẽ bị thay đổi, mỗi mức kiểm thử nên có các mục tiêu đặc thù của mình.
• Việc phân tích và thiết kế testcase cho 1 mức độ kiểm thử nên bắt đầu sớm nhất nhƣ có thể có.
• Các tester nên xem xét các tài liệu sớm nhƣ có thể có, ngay sau khi các tài liệu này đƣợc tạo ra trong chu kỳ phát triển phần mềm.
• Sốlƣợng và cƣờng độ của các mức kiểm thử đƣợc điều khiển theo các yêu cầu đặc thù của project phần mềm đó

Hình dƣới đây là quy trình kiểm thử phần mềm tổng quát.

Hình 3.1. Quy trình kiểm thử phần mềm

3.2. Lâp kế hoac̣h kiêm̉ tra ( Test Plan)

a) Đầu vào

• Kế hoạch dự án
• Tài liệu SRS, SRD, HLD
• Các tài liệu mô tả nghiệp vụ

b) Mô tả

Tìm hiểu các yêu cầu là bƣớc đầu tiên của quy trình kiểm thƣ̉ phần mềm.Trong giai đoạn này, kiểm thƣ̉ viên phải có trách nhiệm tìm hiểu thông tin về sản phẩm, về các tính năng của sản phẩm sẽ kiểm tra, các yêu cầu và tiêu chí chấp nhận sản phẩm của khách hàng. Tƣ̀  đó sẽ xác điṇ h kiểm tra nhƣ̃ng cái gì và pham vi kiểm tra, cũng nhƣ tiến đô,̣ thời gian và nguồn nhân lƣc tham gia vaò quy trình kiêm̉ thƣ̉ . Trong quá trình tìm hiểu, ngoài việc tiếp nhận và khảo sát yêu cầu của khách hàng còn có thêm công việc tƣ vấn cho khách hàng về hệ thống đang cần xây dựng.

Sau khi tiếp nhận yêu cầu kiểm tra của dự án phần mềm, nhóm đảm bảo chất lƣơng phần mềm PQA (Product Quality Asurrance)) tiến hành lập kế hoạch kiểm tra. Việc lập kế hoạch kiểm tra hệ thống phần mềm nhằm mục đích xác định các yêu cầu, mục đích, phƣơng thức kiểm tra cũng nhƣ xác định nguồn lực và thời gian, công cụ kiểm tra cần thiết cho toàn bộ quá trình kiểm tra, trƣớc khi tiến hành kiểm tra hệ thống phần mềm. Giai đoạn này tiến hành song song với thời gian phát triển dự án phần mềm. Khi đã có kế hoạch dự án, tài liệu SRS và HLD thì có thể tiến hành xây dựng kế hoạch kiểm tra. Đồng thời, nhóm PQA thống nhất phƣơng thức giao tiếp với nhóm phát triển.

• Nhóm dự án cung cấp các tài liệu liên quan của phần mềm cho nhóm PQA.
• Nhóm PQA nghiên cứu các yêu cầu, thời gian và nội dung các yêu cầu nhận đƣợc để quyết định các bƣớc tiếp theo.
• Nhóm PQA chuẩn bị nhân lực và đào tạo nghiệp vụ cần thiết phục vụ cho nhu cầu dự án.
• Cán bộ PQA lập kế hoạch kiểm tra và trình Giám đốc dự án phê duyệt. Bản kế hoạch kiểm tra đã phê duyệt sẽ đƣợc phổ biến đến từng thành viên tham gia quá trình kiểm tra và là cơ sở cho việc đánh giá mức độ hoàn thành công việc và quản lý nhóm làm việc, tiến độ công việc.

Kết quả của bƣớc lập kế hoạch là bản tài liệu kế hoạch KTPM, bao gồm nhiều chi tiết từ các loại kiểm tra, chiến lƣợc kiểm tra, cho đến thời gian và phân định lực lƣợng kiểm tra viên. Giai đoạn này đƣợc tiến hành song song với thời gian phát triển dự án phần mềm. Khi đã có kế hoạch dự án, tài liệu SRS thì có thể tiến hành xây dựng kế hoạch kiểm tra.

Bản kế hoạch kiểm tra đầu tiên đƣợc phát triển rất sớm trong chu trình phát triển phần mềm (PTPM), ngay từ khi các yêu cầu đã tƣơng đối đầy đủ, các chức năng và luồng dữ liệu chính đã đƣợc mô tả. Bản kế hoạch này có thể đƣợc coi là bản kế hoạch chính (master test plan), trong đó tất cả các kế hoạch chi tiết cho các mức kiểm tra và loại kiểm tra khác nhau đều đƣợc đề cập.

Lƣu ý, tùy theo đặc trƣng và độ phức tạp của mỗi dự án, các kế hoạch kiểm tra chi tiết có thể đƣợc gom chung vào bản kế hoạch chính hoặc đƣợc phát triển riêng.

 

Hình 2.2: Kế hoạch kiểm thử phần mềm

Sau khi bản kế hoạch chính đƣợc phát triển, các bản kế hoạch chi tiết lần lƣợt đƣợc thiết kế theo trình tự thời gian phát triển của dự án. (Hình 3.1 minh hoạ thời điểm phù hợp để thiết lập các kế hoạch kiểm tra, gắn liền với quá trình phát triển của dự án). Quá trình phát triển các kế hoạch kiểm tra không dừng lại tại một thời điểm, mà liên tục đƣợc cập nhật chỉnh sửa cho phù hợp đến tận cuối dự án.

c) Các bƣớc lập kế hoạch

• Xác định yêu cầu kiểm tra: chỉ định bộ phận, thành phần của phần mềm s ẽ đƣợc kiểm tra, phạm vi hoặc giới hạn của việc kiểm tra. Yêu cầu kiểm tra cũng đƣợc dùng để xác định nhu cầu nhân lực.
• Khảo sát rủi r o: Các rủi ro có khả năng xảy ra làm chậm hoặc cản trở quá trình cũng nhƣ chất lƣợng kiểm thử . Ví dụ : Kỹ năng và kinh nghiệm của kiểm thƣ̉ viên quá yếu, không hiểu rõ yêu cầu.
• Xác định chiến lược kiểm thử : Chỉ định phƣ ơng pháp tiếp cân để thƣc hiên viêc kiểm thƣ̉ trên phần mềm . Chỉ định các kỹ thuật và công cụ hỗ trợ kiểm thƣ̉ , xác định các phƣơng pháp dùng để đánh giá chất lƣợng kiêm tra cũng nhƣ điều kiên để xác điṇ h thời gian kiểm tra.

• Xác định nhân lực,vật lực: Kỹ năng, kinh nghiệm của kiểm tra viên; phần cứng, phần mềm, công cụ, thiết bị giả lập... cần thiết cho việc kiểm tra.
• Lập kế hoạch chi tiết: Ƣớc lƣợng thời gian, khối lƣợng công việc, xác định chi tiết cácphần công việc, ngƣời thực hiện, thời gian tất cả các điểm mốc của quá trình kiểm tra.
• Tổng hợp và tạo các bản kế hoạch kiểm tra: Kế hoạch chung và kế hoạch chi tiết.
• Xem xét các kế hoạch kiểm tra: Phải có sự tham gia của tất cả những ngƣời có liên quan, kể cả trƣởng dự án và có thể cả khách hàng. Việc xem xét nhằm bảo đảm các kế hoạch là khả thi, cũng nhƣ để phát hiện (và sữa chữa sau đó) các sai sót trong các bản kế hoạch.

d) Kết quả

- Kế hoạch kiểm tra đƣợc phê duyệt.

e) Ngƣời thực hiện

- Cán bộ PQA

- Trƣởng nhóm PQA

- Giám đốc dự án

3.3. Chuẩn bi môi trường kiểm tra

a) Đầu vào môi trƣờng kiểm tra

- Kế hoac̣ h kiểm tra

- Tài liệu SRS, SRD, HLD

- Tài liệu nghiệp vụ.

b) Mô tả

Chuẩn bị dữ liệu và môi trƣờng kiểm tra là tiền đề để đảm bảo cho việc kiểm tra có chất lƣợng và năng suất cao. Tiến hành xây dựng dữ liệu,thiết lập môi trƣờng, kiểm tra thiết bị cần thiết, công cụ kiểm tra đã đáp ứng kế hoạch kiểm tra đề ra. Mục đích của giai đoạn này là chuẩn bị môi trƣờng kiểm tra cho hệ thống phần mềm.

Cán bộ kiểm tra có trách nhiệm phối hợp cùng với bên hỗ trợ kỹ thuật để chuẩn bị đầy đủ môi trƣờng thực tế hay giả lập cho chƣơng trình, dự án phần mềm trƣớc khi tiến hành kiểm tra.

c) Các công việc cần thực hiện

- Xây dựng các công cụ tạo dữ liệu, kiểm tra cơ sở dữ liệu.

- Tạo dữ liệu kiểm tra hệ thống cho chƣơng trình/công cụ kiểm tra.

- Xây dựng môi trƣờng phần cứng

- Xây dựng môi trƣờng phần mềm

d) Kết quả

- Môi trƣờng kiểm tra sẵn sàng

e) Ngƣời thực hiện

- Cán bộ PQA.

- Trƣởng nhóm PQA

3.4.  Thiết kế  kiểm tra ( Test Design)

a) Đầu vào

- Tài liệu SRS, SRD, HLD.

- Prototype (nếu có)

b) Mô tả

Giai đoạn thiết kế kiểm tra nhằm đƣa ra các tình huống kiểm tra. Đây là tài liệu cụ thể hoá các bƣớc kiểm tra sẽ phải tiến hành trong quá trình thực hiện tình huống kiểm tra. Các tình huống kiểm tra cần chỉ rõ phần mềm có thể đáp ứng đƣợc các yêu cầu nào, có những khía cạnh nào. Các khía cạnh cần tập trung là:

Các yêu cầu chức năng bắt buộc, các yêu cầu chức năng tuỳ chọn hay phi chức năng

- Các tính năng bảo mật mà hệ thống cần đáp ứng

- Tính ổn định của chƣơng trình

- Khả năng phục hồi của hệ thống

- Các giai đoạn tiến hành kiểm tra

Việc lập các tình huống kiểm tra sẽ do cán bộ kiểm tra đảm nhiệm, quá trình lập tình huống sẽ đƣợc Trƣởng nhóm kiểm tra thƣờng xuyên xem xét và sửa đổi, cập nhật nếu cần.

Hình dƣới đây cho thấy việc thiết kế test không chỉ làm môt lần, nó sẽ đƣợc sửa chƣ̃a, câp nhâṭ, thêm hoăc bớt tron suốt chu trình phát triển phần mềm, vào bất cứ lúc nào có sự thay đổi yêu cầu hoặc sau khi phân tích thấy cần sửa chữa , bổ sung.

Hình 2.3: Thiết kế kiểm tra

c) Các bƣớc thiết kế kiểm tra

• Xác định và mô tả Test Case: xác định các điều kiện cần thiết lập trƣớc và trong lúc kiểm tra. Mô tả đối tƣợng hoặc dữ liệu đầu vào, mô tả các kết quả mong chờ sau khi kiểm tra.
• Mô tả các bước chi tiết để kiểm tra: các bƣớc này mô tả chi tiết để hoàn thành một Test Case khi thực hiện kiểm tra. Các Test Case nhƣ đã nói ở trên thƣờng chỉ mô tả đầu vào, đầu ra, còn cách thức tiến hành nhƣ thế nào thì không đƣợc định nghĩa. Thao tác này nhằm chi tiết hóa các bƣớc của một Test Case, cũng nhƣ chỉ định các loại dữ liệu nào cần có để thực thi các Test Case, chúng bao gồm các loại dữ liệu trực tiếp, gián tiếp, trung gian, hệ thống...
• Xem xét và khảo sát độ bao phủ của việc kiểm tra: mô tả các chỉ số và cách thức xác định việc kiểm tra đã hoàn thành hay chƣa. Bao nhiêu phần trăm phần mềm đã đƣợc kiểm tra. Để xác định điều này có hai phƣơng pháp: căn cứ trên yêu cầu của phần mềm hoặc căn cứ trên số lƣợng code đã viết
• Xem xét Test Case và các bước kiểm tra: Việc xem xét cần có sự tham gia của tất cả những ngƣời có liên quan, kể cả trƣởng dự án nhằm bảo đảm các Test Case và dữ liệu yêu cầu là đủ và phản ánh đúng các yêu cầu cần kiểm tra, độ bao phủ đạt yêu cầu, cũng nhƣ để phát hiện (và sữa chữa) các sai sót.

1. Test Case

• Mục đích
• Một tình huống kiểm tra (test case - TC) đƣợc thiết kế để kiểm tra một đối tƣợng có thỏa mãn yêu cầu đặt ra hay không.
• Một Test case thường có 4 phần cơ bản:

- Điều kiện (Codition): Đặc tả các điều kiện cần có để tiến hành kiểm tra.

- Dữ liệu đầu vào (Input Data): Đặc tả đối tƣợng hay dữ liệu cần thiết, đƣợc sử dụng làm đầu vào để thực hiện việc kiểm tra.

- Kết quả mong chờ (Expected Result): Kết quả mong đợi trả về từ đối tƣợng kiểm tra.

- Kết quả thực tế (Actual Result): kết quả thực tế trả về từ đối tƣợng kiểm tra

• Kỹ thuật thiết kế Test Case:

- Kỹ thuật dựa trên đặc tả - hộp đen (Black box testing): Tìm kiếm lỗi theo cách hệ thống thực hiện.

- Kỹ thuật dựa trên cấu trúc – hộp trắng (Black box testing): Tìm kiếm lỗi theo cách hệ thống đƣợc xây dựng

- Kỹ thuật dựa trên kinh nghiệm: Tạo dữ liệu kiểm thử dựa vào sự hiểu biết về hệ thống, kinh nghiệm trong quá khứ, phƣơng pháp phỏng đoán về lỗi.

2. Test Script

 Định nghĩa

Một kịch bản (Test Script) là một nhóm mã lệnh dạng đặc tả kịch bản dùng để tự động hóa một trình tự kiểm tra, giúp cho việc kiểm tra nhanh hơn, hoặc cho những trƣờng hợp mà kiểm tra bằng tay sẽ rất khó khăn hoặc không khả thi.

Các Test Script có thể tạo thủ công hoặc tạo tự động dùng công cụ kiểm tra tự động.

• Mục đích:  Bƣớc này thƣờng không bắt buộc trong các loại và mức kiểm tra, chỉ yêu cầu trong những trƣờng hợp đặc thù cần thiết kế, tạo ra các Test Script có khả năng chạy trên máy tính giúp tự động hóa việc thực thi các bƣớc kiểm tra đã định nghĩa ở bƣớc thiết kế test
• Các bước phát triển Test Script
• Test Script: Thủ công hoặc dùng công cụ hỗ trợ để phát sinh script một cách tự động (tuy nhiên trong hầu hết mọi trƣờng hợp, ta vẫn phải chỉnh sửa ít hoặc nhiều trên các script đƣợc sinh tự động). Thông thƣờng, mỗi bƣớc kiểm Kiểm tra đƣợc thiết kế trong phần thiết kế test, đòi hỏi ít nhất một Test Script. Các Test Script có khả năng tái sử dụng càng nhiều càng tốt để tối ƣu hóa công việc.
• Kiểm tra Test script: Xem có “chạy” tốt không nhằm bảo đảm các Test Script hoạt động đúng yêu cầu, thể hiện đúng ý đồ của các bƣớc kiểm tra
• Thành lập các bộ dữ liệu ngoài dành cho các Test Script: Bộ dữ liệu này sẽ đƣợc các Test Script sử dụng khi thực hiện kiểm tra tự động. Gọi là “ngoài” vì chúng đƣợc lƣu độc lập với các Test Script, tránh trƣờng hợp vì dễ dãi, một số kiểm tra viên “tích hợp” luôn phần dữ liệu vào bên trong code của các script (thuật ngữ chuyên môn gọi là “hard-code”). Việc tách riêng dữ liệu cho phép dễ dàng thay đổi dữ liệu khi kiểm tra, cũng nhƣ giúp việc chỉnh sửa hoặc tái sử dụng các script sau này.
• Xem xét và khảo sát độ bao phủ của việc kiểm tra: Bảo đảm các Test Script đƣợc tạo ra bao phủ toàn bộ các bƣớc kiểm tra theo yêu cầu.

3. Test Data

• Định nghĩa

Test Data là bộ dữ liệu đƣợc xây dựng để chạy thử các test case. Dữ liệu trong Test Data gồm có hai loại là dữ liệu thƣờng (normal data) và dữ liệu bắt buộc (Initial Data). Xây dựng Test Data là một khâu rất quan trọng trong tiến trình test, vì kết quả test phụ thuộc rất lớn vào dữ liệu trong Test Data.

Initial Data là các trƣờng dữ liệu dùng để khởi tạo chƣơng trình, bắt buộc cần phải có để hệ thống có thể làm việc đƣợc. Initial Data là một bộ phận của Test Data.

• Các bước phát triển Test Data
• Kiểm thử với tất cả các dữ liệu vào là cần thiết, nhƣng chúng ta không thể thực hiện kiểm thử “vét cạn” đƣợc.
• Chọn tập các dữ liệu thử đại diện từ miền dữ liệu vào dựa trên các tiêu chuẩn chọn dữ liệu thử. Yêu cầu đối với bộ dữ liệu kiểm thử là phải phủ kín đƣợc mọi trƣờng hợp cần đánh giá
• Người thực hiện
• Test Leader và Developer xây dựng, sau khi có tài liệu phân tích thiết kế mức chi tiết.
• Dữ liệu khởi tạo (Initial Data) là phần bắt buộc cần phải có để hệ thống có thể hoạt động đƣợc, thƣờng do lập trình viên tạo lập sau khi hoàn chỉnh từng bộ phận của hệ thống.
• Test Leader chịu trách nhiệm xây dựng bộ dữ liệu Test Data thông thƣờng.
• Tester sẽ dùng các dữ liệu này để thực hiện Test Case
• Đầu vào

Để xây dựng Test Data cần sử dụng các tài liệu mô tả dữ liệu trong phần Data_Model (Analysis_Design). Trong đó, quan trọng nhất là 2 tài liệu:

- Physical_ER_Diagram: Lƣợc đồ quan hệ thực thể; lƣợc đồ này mô tả quan hệ giữa các bảng trong dự án.

- Physical_Table_Definition: Mô tả định nghĩa các bảng, bao gồm Danh sách toàn bộ tên bảng sử dụng trong dự án; Mô tả chi tiết của từng bảng (tên cột, kiểu giá trị của từng cột, kích thƣớc dữ liệu, …).

d) Kết quả

- Tình huống kiểm tra đƣợc phê duyệt.

e) Ngƣời thực hiện

- Cán bộ kiểm tra

- Trƣởng nhóm PQA

- Quản trị dự án

3.5. Thƣc hiên kiểm tra ( Test Execute)

a) Đầu vào

- Kế hoac̣ h kiểm tra

- Tình huống kiểm tra

- Môi trƣờng kiểm tra đã sẵn sàng

b) Mô tả

Giai đoạn thực hiện tình huống kiểm tra là giai đoạn quan trọng nhất trong toàn bộ quy trình kiểm tra hệ thống phần mềm, vì nó là quá trình thực hiện toàn bộ kế hoạch, tình huống kiểm tra và các hoạt động khác; nhằm bảo đảm phần mềm đƣợc phát hành và chuyển giao đáp ứng các yêu cầu hoặc các tiêu chuẩn đƣợc xác lập. Các công việc kiểm tra cần chỉ rõ phần mềm đã đáp ứng hoặc chƣa đáp ứng các yêu cầu nào, có những lỗi nào. Các khía cạnh cần tập trung là:

- Khẳng định các module riêng biệt và các giao dịch không có lỗi.

- Hệ thống đáp ứng các yêu cầu về giao diện.

- Hệ thống thực hiện đúng quy trình, thao tác nghiệp vụ.

- Sự ổn định, tốc độ yêu cầu với khối lƣợng giao dịch/dữ liệu trong phạm vi cho phép.

- Sự ổn định, tốc độ yêu cầu với môi trƣờng tối thiểu.

- Hệ thống đáp ứng các yêu cầu về tính thống nhất (ngôn ngữ, phím nóng, thuật ngữ,...)

Các lỗi đƣợc tìm thấy trong quá trình kiểm tra đƣợc ghi nhận và theo dõi trạng thái lỗi, tình trạng lỗi …đảm bảo rằng lỗi không đƣợc ở trạng thái Open quá lâu, các lỗi nghiêm trọng phải đƣợc ƣu tiên sửa trƣớc…Kiểm tra lại những lỗi đã đƣợc sửa và các chức năng liên quan đảm bảo lỗi đƣợc Đóng triệt để và không ảnh hƣởng đến các lỗi khác, các chức năng khác... Việc thực hiện tình huống kiểm tra sẽ do cán bộ kiểm tra đảm nhiệm.Trong quá trình thực hiện tình huống kiểm tra, Trƣởng nhóm kiểm tra thƣờng xuyên xem xét (nếu cần).

c) Các bƣớc thƣc hiện kiểm tra

Quá trình thực hiện kiểm tra thƣờng thông qua các bƣớc sau:

- Thực hiện các bước kiểm tra: thủ công hoặc thi hành các Test Script nếu là quy trình kiểm thử tự động. Để thực hiện kiểm tra, tao tác đầu tiên cần làm là xác lập, khởi động môi trƣờng và điều kiện kiểm tra. Việc kiểm tra nhằm bảo đảm tất cả các bộ phận liên quan (nhƣ phần cứng, phần mềm, máy chủ, mạng, dữ liệu…) đã đƣợc cài đặt sẵn sàng trƣớc khi chính thức bắt đầu kiểm tra

- Đánh giá quá trình kiểm tra: giám sát quá trình kiểm tra suôn sẻ đến khi hoàn thành hay bị treo và dừng giữa chừng, cần bổ sung hay sửa chữa gì không để quá trình kiểm tra đƣợc tốt hơn. Nếu quá trình kiểm tra diễn ra trơn tru, kiểm tra viên hoàn thành chu kỳ kiểm tra và chuyên qua bƣớc “thẩm định kết quả kiểm tra”. Nếu quá trình bị treo hoặc dừng giữa chừng, kiểm tra viên cần phân tích để xác định nguyên nhân lỗi khắc phục và lập lại quá trình kiểm tra.

- Thẩm định kết quả kiểm tra: sau khi kết thúc, kết quả kiểm tra cần đƣợc xem xét để đảm bảo kết quả nhận đƣợc là đáng tin cậy, cũng nhƣ biết đƣợc những lỗi xảy ra không phải do phần mềm mà do dữ liệu dùng để kiểm tra, môi trƣờng kiểm tra hoặc các bƣớc kiểm tra (hoặc Test Script) gây ra. Nếu thực sự lỗi xảy ra do quá trình kiểm tra cần sửa chữa và kiểm tra lại từ đầu.

Quá trình thực thi test thông thƣờng bao gồm 4 giai đoạn: Unit test, Integration test, System test, Acceptance test ,

Unit testing – Kiểm thƣ̉  mƣ́ c đơn vi ̣

- Tập trung vào việc xác mình trên đơn vị nhỏ nhất của thiết kế phần mềm, thành phần phần mềm, module (hàm, thủ tục, đoạn code, component…)

- Dựa vào tài liệu thiết kế chi tiết

- Unit testing đƣợc thực hiện bởi lập trình viên

- Sử dụng phƣơng pháp test hộp trắng(White box testing).

Integration test – Kiểm thƣ̉ mƣ́ c tích hơp̣

- Dựa và tài liệu thiết kế tổng thể của dự án

- Kiểm tra sự tƣơng tác giữa các module

- Kiểm tra tính đúng đắn so với bản đặc tả

- Kiểm tra tính hiệu quả

- Đƣợc thực hiện bởi kiểm thử viên

- Sử dụng các kỹ thuật kiểm tra nhƣ: Tích hợp từ trên xuống (Top-Down), Tích hợp từ dƣới lên (Bottom -Up), Tích hợp kẹp (Sandwich)

System test – Kiểm thƣ̉ mƣ́ c hê ̣thống

- Dựa vào tài liệu đặc tả yêu cầu phần mềm

- Kiểm tra tất cả các thành phần của hệ thống đã đƣợc tích hợp có thực hiện đúng các chức năng đã xác định hay chƣa.

- Sử dụng phƣơng pháp test hộp đen(Black box testing).

- Ngƣời thực hiện: Kiểm thƣ̉ viên , Lâp phần mềm trình viên , Nhóm dƣ̣ án phát triển

Acceptance test – Kiểm thƣ̉  chấp nhân san̉ phâm̉

- Dựa vào yêu cầu nghiệp vụ của khách hàng và tài liệu hƣớng dẫn sử dụng phần mềm

- Kiểm tra xem phẩn mềm đac thỏa mãn tất cả các yêu cầu của khách hàng hay chƣa

- Ngƣời thực hiện là khách hang

- Ngƣời hỗ trợ: Kiểm thử viên và nhóm phát triển phần mềm

Regression Test - Kiểm tra hồi quy

- Thực hiện kiểm tra khi thay đổi bất kỳ chức năng nào của phần mềm

- Có thể thực hiện tại mọi mức kiểm tra và thƣờng sử dụng lại Test Case và bộ dữ liệu thử đã sử dụng trong các giai đoạn trƣớc đó.

- Ngƣời thực hiện là kiểm thử viên và nhóm phát triển dự án phần mềm

d) Kết quả

- Báo cáo kết quả kiểm tra

- Tình huống kiểm tra đƣợc cập nhật (nếu có)

e) Ngƣời thƣc hiên

- Cán bộ kiểm tra

- Trƣởng nhóm PQA

- Nhóm phát triển

- Quản trị dự án

3.6. Thẩm tra và đá nh giá kết quả kiểm tra

a) Đầu vào

- Kế hoạch kiểm tra

- Tình huống kiểm tra

- Báo cáo ghi nhận lỗi và xử lý lỗi.

b) Mô tả

Sau khi kết thúc, kết quả kiểm tra cần đƣợc xem xét để bảo đảm kết quả nhận đƣợc là đáng tin cậy, cũng nhƣ nhận biết đƣợc những lỗi xảy ra không phải do PM mà do dữ liệu dùng để kiểm tra, môi trƣờng kiểm tra hoặc các bƣớc kiểm tra (hoặc Test Script) gây ra. Nếu thực sự lỗi xảy ra do quá trình kiểm tra, cần phải sửa chữa và kiểm tra lại từ đầu.

Đánh giá toàn bộ quá trình kiểm tra, bao gồm xem xét và đánh giá kết quả kiểm tra, liệt kê lỗi, chỉ định các yêu cầu thay đổi, và tính toán các số liệu liên quan đến quá trình kiểm tra (chẳng hạn số giờ, thời gian kiểm tra, số lƣợng lỗi, phân loại lỗi...).

Lƣu ý, mục đích của việc đánh giá kết quả kiểm tra ở bƣớc này hoàn toàn khác với bƣớc thẩm định kết quả kiểm tra sau khi hoàn tất một vòng kiểm tra. Đánh giá kết quả kiểm tra ở giai đoạn này mang tính toàn cục và nhằm vào bản thân giá trị của các kết quả kiểm tra. Việc đánh giá quá trình và kết quả kiểm tra đƣợc thực hiện song song với bất kỳ lần kiểm tra nào và chỉ chấm dứt khi quá trình kiểm tra đã hoàn tất.

c) Các bƣớc thẩm tra và đánh giá kết quả kiểm tra Đánh giá quá trình kiểm tra thƣờng thông qua các bƣớc sau:

• Phân tích kết quả kiểm tra và đề xuất yêu cầu sửa chữa: Chỉ định và đánh giá sự khác biệt giữa kết quả mong chờ và kết quả kiểm tra thực tế, tổng hợp và gửi thông tin yêu cầu sửa chữa đến những ngƣời có trách nhiệm trong dự án, lƣu trữ để kiểm tra sau đó.
• Đánh giá độ bao phủ: Xác định quá trình kiểm tra có đạt đƣợc độ bao phủ yêu cầu hay không, tỷ lệ yêu cầu đã đƣợc kiểm tra (tính trên các yêu cầu của phần mềm và số lƣợng code đã viết).
• Phân tích lỗi: Đƣa ra số liệu phục vụ cho việc cải tiến các qui trình phát triển, giảm sai sót cho các chu kỳ phát triển và kiểm tra sau đó. Ví dụ, tính toán tỷ lệ phát sinh lỗi, xu hƣớng gây ra lỗi, những lỗi “ngoan cố” hoặc thƣờng xuyên tái xuất hiện.
• Xác định quá trình kiểm tra có đạt yêu cầu hay không: Phân tích đánh giá  để xem các Test Case và chiến lƣợc kiểm tra đã thiết kế có bao phủ hết những điểm cần kiểm tra hay không? Kiểm tra có đạt yêu cầu dự án không? Từ những kết quả này, kiểm tra viên có thể sẽ phải thay đổi chiến lƣợc hoặc cách thức kiểm tra.
• Báo cáo tổng hợp: Tổng hợp kết quả các bƣớc ở trên và phải đƣợc gửi cho tất cả những ngƣời có liên quan.

d) Đầu ra

- Thống kê lỗi, lỗi phát sinh

- Báo cáo kết quả kiểm tra hệ thống phần mềm

e) Ngƣời thƣc hiên

- Tester: Thu thập kết quả Test.

- Test Manager:Tổng hợp và phân tích kết quả test.

- Test Manager : Thông báo với Project Manager vể Test Result.

3.7. Ghi nhân và xƣ̉ lý lỗi

a) Đầu vào

- Báo cáo kết quả kiểm tra

- Tình huống kiểm tra

b) Mô tả

Theo dõi xử lý lỗi nhằm phân tích, tổng hợp các lỗi mới nhất để gửi tới nhóm phát triển tiến hành sửa đổi cũng nhƣ cập nhật các tình huống kiểm tra mới vào tài liệu tình huống kiểm tra khi có các lỗi phát sinh mới, nhằm đảm bảo:

- Lỗi đƣợc sửa đúng tiến độ.

- Thực hiện kiểm tra lại các lỗi đã đƣợc sửa

Việc xử lý lỗi cũng phải đƣợc tập hợp vào công cụ kiểm tra, dữ liệu kiểm tra. Các công việc theo dõi và xử lý sẽ do Trƣởng nhóm kiểm tra đảm nhiệm phối hợp cùng với bên phát triển

c) Các bƣớc ghi nhận và xử lý lỗi

Ghi nhận lỗi

- Trong quá trình t riển khai phần mềm , khi nhà phát triển nh ận phản hồi về lỗi phần mềm t ừ phía khách hàng , tester sẽ có nhiệm vụ ghi nhận lỗi trên với các thông tin rõ ràng: dự án, module, giai đoạn, mức độ nghiêm trọng

của lỗi, kiểu lỗi, ngày kiểm tra, ngày tạo…

- Trạng thái lỗi lúc này là ERROR

Phân tích lỗi

Lúc này, trƣởng nhóm test (Test Leader) phải tiến hành phân tích lỗi nhằm mục đích cải thiện tình trạng lỗi của phần mềm đang xây dựng.

- Xác định lỗi do yếu tố nào mang lại (do hiểu sai requirement của khách hàng, hiểu sai thiết kế, do yếu tố khách quan, do yếu tố chủ quan..).

- Xác định trọng số cho lỗi, lỗi mang trọng số cao sẽ đƣợc ƣu tiên fix trƣớc

- Xác định lỗi xảy ra thuộc giai đoạn test nào

- Theo dõi, xác định tình trạng lỗi đó (đã fix, đang fail, đang pending hay đang skip)

- Ai sẽ là ngƣời chịu trách nhiệm sửa lỗi này

- Trạng thái lỗi lúc này là ASSIGNED

Sửa lỗi

- Tùy vào các thuộc tính của lỗi (lỗi rất nghiêm troṇ g , lối nghiêm troṇ g , lỗi nhẹ) mà nhóm phát triển đƣa ra bản kế hoạch và xƣ̉ lý lỗi phù hơp không ảnh hƣởng đến uy tín và chất lƣợng của Nhà phát triển . Ví dụ với lỗi là lỗi nghiêm troṇ g buôc phải sƣ̉ a chƣ̃a để có thể sƣ̉ duṇ g đƣơc các yêu cầu đăt ra. Lập trình viên có trách nhiệm giải quyết lại xem các lỗi đó xẩy ra từ đâu và chỉnh sửa lại code sao cho lỗi đó không xẩy ra nữa và đảm bảo chƣơng trình vẫn chạy đúng.

- Trạng thái lỗi lúc này là PENDING

Kiểm tra lai lôi

- Viêc thƣc hiên  xƣ̉ lý lỗi phải tiến hành song song với viêc lâp kế hoạch và triển khai test laị . Nhằm mục đích kiểm tra lại các chức năng có chứa lỗi và đảm bảo rằng lỗi đã đƣợc sửa chữa hoàn toàn. Công việc này sẽ do tester thực nhiện.

- Trạng thái lỗi lúc này là TESTED

- Sau khi các lỗi đã đƣợc kiểm tra lại, nhóm phá t triển phải câp phẩm sau khi xƣ̉ lý lỗi, Update các traṇ g thái lỗi.

d) Đầu ra

- Có đƣợc phiên bản mới nhất sau khi đƣợc sửa lỗi

- Cập nhật tình huống kiểm tra nếu có lỗi mới phát sinh

- Câp nhật dữ liệu mới vào công cụ kiểm tra

- Kết quả xử lý lỗi phát hiện nhâṭ sản

e) Ngƣời thƣc hiên

- Cán bộ kiểm tra

- Trƣởng nhóm PQA

- Nhóm phát triển

- Quản trị dự án

3.8. Lâp kế hoac̣h và triển khai kiểm thử hồi quy

a) Đầu vào

- Kế hoac̣ h dự án

- Báo cáo kết quả kiểm tra

- Tình huống kiểm tra

- Phiên bản phần mềm mới nhất trƣớc khi dƣợc sửa lỗi

- Công cu ̣ hỗ trơ ̣

b) Mô tả

Trong thực tế, lỗi là phần “luôn hiện diện” trong mọi PM từ giai đoạn phát triển sơ khởi đến khi nó không còn đƣợc sử dụng. Lâp kế hoac̣ h và triển khai test laị đƣơc tiến hành sau khi nhà phát triển nhân tiếp nhân lỗi tƣ̀ phía khách hàng và đƣơc nhóm phát triển thực hiện xử lý lỗi. Viêc lâp kế hoac̣ h và triển khai test laị nhằm mục đích là để chắc chắn rằng chúng ta đang phát triển một thứ có khả năng đúng và hữu ích đối với khách hàng. Chuẩn bị và triển khai test lại: Môi trƣờng kiểm thƣ̉ ,test case, test script...Thực hiện test dựa trên kế hoạch test lại.

c) Các bƣớc lập kế hoạch và triển khai test lại

- Lập kế hoạch thực hiện test lại: đƣợc thực hiện bởi Test Manager nhằm đƣa ra kế hoạch thực hiện test lại các lỗi sau khi đã đƣợc sửa. Lập kế hoạch cho test lại tƣơng tự nhƣ lập kế hoạch kiểm tra cho một dự án. Căn cứ vào số lƣợng lỗi và thời gian bàn giao sản phẩm cho khách hàng mà Test Manager cần phải đƣa ra kế hoạch test lại cho hợp lý.

- Chuẩn bị và triển khai test lại: bao gồm các tình huống kiểm tra, thủ tục kiểm tra, tài nguyên hệ thống cần thiết

- Thực hiện test dựa trên kế hoạch test lại: Cần ƣu tiên kiểm tra những lỗi nghiêm trọng trƣớc tiên sau đó đến các lỗi khác… Đánh giá, tổng hợp lại kết quả kiểm tra sau khi đã test lại

d) Kết quả

- Báo cáo kết quả kiểm tra lỗi đƣợc test lại

- Báo cáo kết toàn bộ hệ thống sau khi test lại

- Có đƣợc phiên bản mới nhất sau khi đƣợc test lại

e) Ngƣời thƣc hiên

- Cán bộ kiểm tra

- Trƣởng nhóm PQA

- Nhóm phát triển

- Quản trị dự án

3.9. Thông báo phát hành sản phẩm

a) Đầu vào

- Tài liệu SRS, SRD

- Kế hoạc kiểm tra

- Báo cáo kết quả kiểm tra hệ thống phần mềm

- Tình huống kiểm tra đã cập nhập

b) Mô tả

Đây là bƣớc cuối cùng của quá trình kiểm tra nhắm mục đích thông báo sản phẩm phần mềm mới đã đạt yêu cầu và sẵn sang chuyển giao cho khách hàng.

c) Quá trình thực hiện

- Làm thủ tục thông báo phát hành

d) Kết quả

- Biên bản thông báo phát hành sản phẩm

- Tài liệu hƣớng dẫn sử dụng

e) Ngƣời thực hiện

- Trƣởng nhóm PQA

3.10. Xây dựng kế hoạch kiểm thử

1- Định nghĩa: Kế hoạch kiểm thử thƣờng đƣợc để trong 1 file và chứa các kết quả của các hoạt động sau :

- Nhận dạng các chiến lƣợc đƣợc dùng để kiểm tra và đảm bảo rằng sản phẩm thỏa mãn đặc tả thiết kế phần mềm và các yêu cầu khác vềphần mềm.

- Định nghĩa các mục tiêu và phạm vi của nỗ lực kiểm thử.

- Nhận dạng phƣơng pháp luận mà đội kiểm thử sẽ dùng để thực hiện công việc kiểm thử.

- Nhận dạng phần cứng, phần mềm và các tiện ích cần cho kiểm thử.

- Nhận dạng các tính chất và chức năng sẽ đƣợc kiểm thử.

- Xác định các hệ số rủi ro gây nguy hại cho việc kiểm thử.

- Lập lịch kiểm thử và phân phối công việc cho mỗi thành viên tham gia. Test Manager hoặc Test Leader sẽ xây dựng kế hoạch kiểm thử.

2- Nhu cầu cần phải có kếhoạch kiểm thử:

Kế hoạch kiểm thử cần phải đƣợc xây dựng sớm nhƣcó thểcó trong mỗi chu kỳ phát triển phần mềm để:

- Tập hợp và tổ chức các thông tin kiểm thử cần thiết.

- Cung cấp thông tin về qui trình kiểm thử sẽ xảy ra trong tổ chức kiểm thử.

- Cho mỗi thành viên trong đội kiểm thử có hƣớng đi đúng.

- Gán các trách nhiệm rõ ràng cụ thểcho mỗi thành viên đội kiểm thử.

- Có lịch biểu làm việc rõ ràng và các thành viên có thể làm việc với nhau tốt.

3- Kế hoạch kiểm thử cần chứa các thông tin sau đây :

- Phạm vi/mục tiêu kiểm thử

- Các chiến lƣợc đƣợc dùng

- Các tài nguyên phần cứng và phần mềm phục vụ kiểm thử.

- Các nhu cầu vềnhân viên và huấn luyện nhân viên.

- Các tính chất cần đƣợc kiểm thử.

- Các tính chất không cần kiểm thử.

- Các rủi ro & sự cố bất ngờ.

- Lịch kiểm thử cụ thể.

- Các kênh thông tin liên lạc.

- Cấu hình cho từng phần tử nhƣ kế hoạch kiểm thử, testcase, thủ tục kiểm thử,...

- Môi trƣờng kiểm thử(Test bed)

- Tiêu chí đầu vào và tiêu chí dừng kiểm thử.

- Các kết quả phân phối

4- Quy trình xây dựng kế hoạch kiểm thử

 Sau khi xây dựng kế hoạch kiểm thử xong ta có thể thay đổi nó, nhƣng cần tuân thủ quy trình yêu cầu thay đổi

5- Các hoạt động chính trong việc xây dựng kế hoạch kiểm thử

- Định nghĩa mục đích, phạm vi, chiến lƣợc, cách tiếp cận, các điều kiện chuyển, các rủi ro, kếhoạch giảm nhẹ và tiêu chí chấp thuận.

- Định nghĩa cách thức thiết lập môi trƣờng và các tài nguyên đƣợc dùng cho việc kiểm thử.

- Thiết lập cơ chế theo dõi lỗi phát hiện.

- Chuẩn bị ma trận theo dõi bao phủ mọi yêu cầu phần mềm.

- Báo cáo trạng thái kiểm thử.

- Phát hành leo thang (Escalating Issues)

- Raising Testing related PIR (Process Improvement Request) / PCR (Process Change Request

3.11. Các thành phần chính trong kế hoạch kiểm thử 1- Mục đích và phạm vi kiểm thử:

- Đặc tả mục đích của tài liệu về kế hoạch kiểm thử.

- Cung cấp vắn tắt về phạm vi mà project đƣợc hỗ trợ nhƣ platform, loại database, hay danh sách vắn tắt về các loại project con in project kiểm thử.

Ví dụ:

 

2- Cách tiếp cận & các chiến lƣợc đƣợc dùng :

- Đặc tả về phƣơng pháp luận kiểm thử sẽ đƣợc dùng để thực hiện kiểm thử.

- Thí dụ: General Testing Process Approach for Project ABC Đề cập các cấp độ kiểm thử cần thực hiện

Các kỹ thuật đƣợc dùng cho mỗi kiểu kiểm thử trong project :

- ƒ Kiểm thử tích hợp (Integration Testing)

- ƒ Kiểm thử hệ thống (System Testing)

- ƒ Kiểm thử độ chấp thuận (Acceptance Testing)

- ƒ Kiểm thửchức năng của ngƣời dùng (Functionality Testing)

- ƒ Kiểm thử hồi qui (Regression Testing)

- ƒ Kiểm thử việc phục hồi sau lỗi (Failover and Recovery Testing)

- ƒ Kiểm thửviệc kiểm soát an minh và truy xuất (Security and Access Control Testing)

- ƒ Kiểm thử việc cấu hình và cài đặt (Configuration and Installation Testing)

- ƒ Kiểm thử đặc biệt (Ad-hoc Testing)

- ƒ Kiểm thử hiệu suất (Performance Testing)

3- Các tính chất cần đƣợc kiểm thử

Danh sách các tính chất của phần mềm cần đƣợc kiểm thử, đây là 1 catalog chứa tất cảác testcase (bao gồm chỉ số testcase, tiêu đề testcase) cũng nhƣ tất cả trạng thái cơ bản

Ví dụ:

4- Các tính chất không cần kiểm thử

- Danh sách các vùng phần mềm đƣợc loại trừ khỏi kiểm thử, cũng nhƣ các testcase đã đƣợc định nghĩa nhƣng không cần kiểm thử.

5- Rủi ro và sự cố bất ng

- Danh sách tất cả rủi ro có thểxảy ra trong chu kỳ kiểm thử.

- Phƣơng pháp mà ta cần thực hiện để tối thiểu hóa hay sống chung với rủi ro

- Ví dụ

6- Tiêu chí đình chỉ & phục hồi kiểm thử:

- Tiêu chí đình chỉ kiểm thử là các điều kiện mà nếu thoả mãn thì kiểm thử sẽ dừng lại.

- Tiêu chí phục hồi là những điều kiện đƣợc đòi hỏi để tiếp tục việc kiểm thử đã bị ngừng trƣớc đó.

7- Môi trƣờng kiểm thử

- Đặc tả đầy đủ về các môi trƣờng kiểm thử, bao gồm đăc tảphần cứng, mạng, database, phần mềm, hệ điều hành và các thuộc tính môi trƣờng khác ảnh hƣởng đến kiểm thử.

- Ví dụ:

8- Lịch kiểm thử

- Lịch kiểm thử ởdạng ƣớc lƣợng, nên chứa các thông tin : các cột mốc với ngày xác định + Kết quả phân phối của từng cột mốc.

- Ví dụ:

9- Tiêu chí dừng kiểm thử và chấp thuận

Bất kỳ chuẩn chất lƣợng mong muốn nào mà phần mềm phải thỏa mãn yêu cầu sẵn sàng cho việc phân phối đến khách hàng. Có thể bao gồm các thứ sau :

- Các yêu cầu mà phần mềm phải đƣợc kiểm thử dƣới các môi trƣờng xác định.

- Số lỗi tối thiểu ở cấp an ninh và ƣu tiên khác nhau, số phủ kiểm thử tối thiểu,..

- Stakeholder sign-off and consensus

- Ví dụ:

10- Nhân sự:

Vai trò và trách nhiệm từng ngƣời :

- Danh sách các vai trò xác định của các thành viên đội kiểm thử trong hoạt động kiểm thử.

- Các trách nhiệm của từng vai trò.

- Công tác huấn luyện.

- Danh sách các huấn luyện cần thiết cho các QC

- Ví dụ:

 

11- Các tool phục vụ kiểm thử

- Danh sách tất cả các tiện ích cần dùng trong suốt chu kỳ kiểm thử.

- Với project kiểm thử tự động, các tiện ích cần đƣợc liệt kê với chỉ số version cùng thông tin license.

- Ví dụ:

12- Các kết quả phân phối

- Danh sách tất cả tài liệu hay artifacts dự định phân phối nội bộ sau khi mỗi cột mốc kết thúc hay sau khi project kết thúc.

- Ví dụ: