Quy trình test phần mềm trong quá trình sản xuất phần mềm.
Sau khi nhận được tài liệu yêu cầu (spec) từ khách hàng hoặc bộ phận thiết kế chi tiết.
QC sẽ tìm hiểu spec và viết test plan, sau đó gửi test plan cho khách hàng và project manager xem lại, sau khi duyệt test plan này.
QC sẽ tiến hành viết test case dựa vào spec đó. (song song đó DEV sẽ dựa vào spec để code)
Nếu công ty có bộ phận test whitebox thì dựa vào spec viết test case test whitebox và viết test script để test whitebox. (thường gọi là unit test - ở đây, "unit" là 1 hàm, 1 class hoặc 1 component,... tùy cách nhìn nhận và quản lý của mỗi công ty)
Sau khi test whitebox thành công (test pass các test case whitebox) thì QC sẽ tiến hành test blackbox (test chức năng của từng màn hình - cái này cũng được xem là unit test, "unit" ở đây là 1 màn hình hoặc một chức năng tùy qui định và cách quản lý của mỗi công ty).
Sau khi test từng màn hình thành công (pass hết các test case hoặc đạt được số % test case pass nào đó - ví dụ 97% test case pass) thì chuyển sang giai đoạn test tích hợp (integration testing) là kết hợp một số màn hình/chức năng có liên quan lại với nhau rồi test theo luồng xử lý (user story)
Sau khi pass vòng này thì sẽ tiến hành tổng hợp toàn bộ hệ thống (sản phẩm phần mềm) và tiến hành test ở mức hệ thống.
Có một số công ty hoặc khách hàng yêu cầu test UAT (User Acceptance Testing) thì sẽ thực hiện test lại hệ thống theo các chức năng đã được mô tả trong spec.
Có một số loại phần mềm hoặc khách hàng yêu cầu hoặc qui trình sản xuất phần mềm của công ty, phần mềm sẽ được test alpha và beta.
Trên đây là một qui trình test 1 phần mềm. Tùy vào tính chất của sản phẩm và qui trình sản xuất của mỗi công ty, qui trình trên có thể có nhiều hoặc ít loại test khác hơn.
Trong quá trình test ở bất kỳ mức nào, nếu phát hiện bug thì tester sẽ post bug lên hệ thống quản lý bug (bằng excel hoặc chương trình riêng) và DEV sẽ dựa vào đó fix bug và tester sẽ test lại. (đây là qui trình quản lý và xử lý bug - sẽ nói riêng ở một bài khác)
Ví dụ một qui trình test dựa theo mô hình xây dựng phần mềm V model
Mời các bạn bổ sung thêm cho phần test process này. thanks
Mời bạn tham khảo thêm Qui Trình Kiểm Thử
Mời các bạn tải về một test process mẫu (file đính kèm)
Testing process - quy trình kiểm thử phần mềm
Forum rules
Thảo luận các vấn đề liên quan đến Kiểm thử phần mềm.
Thảo luận các vấn đề liên quan đến Kiểm thử phần mềm.
-
tvn
- Admin
- Posts: 4900
- Joined: Tue 10 Aug, 2010 10:11 am
- Location: HCM
- Contact:
Testing process - quy trình kiểm thử phần mềm
You do not have the required permissions to view the files attached to this post.
-
tvn
- Admin
- Posts: 4900
- Joined: Tue 10 Aug, 2010 10:11 am
- Location: HCM
- Contact:
Testing process - Test Cycle
Gửi các bạn một số thông tin về test cycle, vui lòng tải file đính kèm
You do not have the required permissions to view the files attached to this post.
-
tvn
- Admin
- Posts: 4900
- Joined: Tue 10 Aug, 2010 10:11 am
- Location: HCM
- Contact:
Re: Testing process - qui trình kiểm thử phần mềm
Quy trình kiểm tra phần mềm
Trước khi tìm hiểu một quy trình kiểm tra phần mềm cơ bản, ta cần hiểu hai khái niệm sau: Test Case và Test Script.
Test Case
Một Test Case có thể coi nôm na là một tình huống kiểm tra, được thiết kế để kiểm tra một đối tượng có thỏa mãn yêu cầu đặt ra hay không. Một Test Case thường bao gồm 3 phần cơ bản:
• Mô tả: đặc tả các điều kiện cần có để tiến hành kiểm tra.
• Nhập: đặ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ờ: kết quả trả về từ đối tượng kiểm tra, chứng tỏ đối tượng đạt yêu cầu.
Test Script
Một 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. (Hình 04)
Phần sau sẽ giải thích rõ hơn các bước cơ bản của một quy trình kiểm tra.
Một quy trình kiểm tra cơ bản có thể áp dụng rộng rãi cho nhiều hệ thống PM với những đặc trưng khác nhau.
Lập kế hoạch kiểm tra
Mục đích: Nhằm chỉ định và mô tả các loại kiểm tra sẽ được triển khai và thực hiện. 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.
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 (hình 05).
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.
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 06 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.).
Bản kế hoạch chính và các bản kế hoạch chi tiết
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 PM 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 ro: 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 tra. Ví dụ: kỹ năng và kinh nghiệm của kiểm tra viên quá yếu, không hiểu rõ yêu cầu.
Xác định chiến lược kiểm tra: chỉ định phương pháp tiếp cận để thực hiện việc kiểm tra trên PM, chỉ định các kỹ thuật và công cụ hỗ trợ kiểm tra, chỉ đị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 định 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ác phầ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.
Thiết kế Test
Mục đích: Nhằm chỉ định các Test Case và các bước kiểm tra chi tiết cho mỗi phiên bản PM. Giai đoạn thiết kế test là hết sức quan trọng, nó bảo đảm tất cả các tình huống kiểm tra “quét” hết tất cả yêu cầu cần kiểm tra.
Hình dưới cho thấy việc thiết kế test không phải chỉ làm một lần, nó sẽ được sửa chữa, cập nhật, thêm hoặc bớt xuyên suốt chu kỳ PTPM, 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 được sửa chữa hoặc bổ sung.
Thời điểm phù hợp để thiết lập các kế hoạch kiểm tra
Các bước thiết kế test bao gồm:
• 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 PM đã đượ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.
Phát triển Test ScriptMụ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 bao gồm:• Tạo 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 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.
Thực hiện kiểm traMục đích: Thực hiện các bước kiểm tra đã thiết kế (hoặc thi hành các Test Script nếu tiến hành kiểm tra tự động) và ghi nhận kết quả.
Hình 06 cho ta thấy, việc thực hiện kiểm tra cũng được làm rất nhiều lần trong suốt chu trình kiểm tra, cho đến khi kết quả kiểm tra cho thấy đủ điều kiện để dừng hoặc tạm dừng việc thực hiện.
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 tra tự động. Để thực hiện kiểm tra, thao tác đầu tiên cần làm là xác lập và khởi động môi trường và điều kiện kiểm tra. Việc này 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 và sẵn sàng, trước khi chính thức bắt đầu thực hiện 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ó 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 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 lỗi 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 để 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á quá trình kiểm traMục đích: Đá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.
Hình 06 cho thấy, 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ấu trúc của một mức trưởng thành trong mô hình TMM
Đá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 PM 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.
Tóm lược: Trên đây là tóm tắt các bước cơ bản của một quy trình KTPM. Tùy theo đặc thù của dự án, loại kiểm tra và mức độ kiểm tra, quy trình kiểm tra trong thực tế có thể chi tiết hơn nhiều, tuy nhiên các bước trên là xương sống của bất kỳ quy trình kiểm tra nào.
Tham khảo mô hình TMM (Testing Maturity Model).
Nguồn: http://www.bluesoft.com.vn
Trước khi tìm hiểu một quy trình kiểm tra phần mềm cơ bản, ta cần hiểu hai khái niệm sau: Test Case và Test Script.
Test Case
Một Test Case có thể coi nôm na là một tình huống kiểm tra, được thiết kế để kiểm tra một đối tượng có thỏa mãn yêu cầu đặt ra hay không. Một Test Case thường bao gồm 3 phần cơ bản:
• Mô tả: đặc tả các điều kiện cần có để tiến hành kiểm tra.
• Nhập: đặ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ờ: kết quả trả về từ đối tượng kiểm tra, chứng tỏ đối tượng đạt yêu cầu.
Test Script
Một 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. (Hình 04)
Phần sau sẽ giải thích rõ hơn các bước cơ bản của một quy trình kiểm tra.
Một quy trình kiểm tra cơ bản có thể áp dụng rộng rãi cho nhiều hệ thống PM với những đặc trưng khác nhau.
Lập kế hoạch kiểm tra
Mục đích: Nhằm chỉ định và mô tả các loại kiểm tra sẽ được triển khai và thực hiện. 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.
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 (hình 05).
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.
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 06 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.).
Bản kế hoạch chính và các bản kế hoạch chi tiết
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 PM 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 ro: 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 tra. Ví dụ: kỹ năng và kinh nghiệm của kiểm tra viên quá yếu, không hiểu rõ yêu cầu.
Xác định chiến lược kiểm tra: chỉ định phương pháp tiếp cận để thực hiện việc kiểm tra trên PM, chỉ định các kỹ thuật và công cụ hỗ trợ kiểm tra, chỉ đị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 định 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ác phầ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.
Thiết kế Test
Mục đích: Nhằm chỉ định các Test Case và các bước kiểm tra chi tiết cho mỗi phiên bản PM. Giai đoạn thiết kế test là hết sức quan trọng, nó bảo đảm tất cả các tình huống kiểm tra “quét” hết tất cả yêu cầu cần kiểm tra.
Hình dưới cho thấy việc thiết kế test không phải chỉ làm một lần, nó sẽ được sửa chữa, cập nhật, thêm hoặc bớt xuyên suốt chu kỳ PTPM, 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 được sửa chữa hoặc bổ sung.
Thời điểm phù hợp để thiết lập các kế hoạch kiểm tra
Các bước thiết kế test bao gồm:
• 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 PM đã đượ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.
Phát triển Test ScriptMụ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 bao gồm:• Tạo 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 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.
Thực hiện kiểm traMục đích: Thực hiện các bước kiểm tra đã thiết kế (hoặc thi hành các Test Script nếu tiến hành kiểm tra tự động) và ghi nhận kết quả.
Hình 06 cho ta thấy, việc thực hiện kiểm tra cũng được làm rất nhiều lần trong suốt chu trình kiểm tra, cho đến khi kết quả kiểm tra cho thấy đủ điều kiện để dừng hoặc tạm dừng việc thực hiện.
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 tra tự động. Để thực hiện kiểm tra, thao tác đầu tiên cần làm là xác lập và khởi động môi trường và điều kiện kiểm tra. Việc này 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 và sẵn sàng, trước khi chính thức bắt đầu thực hiện 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ó 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 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 lỗi 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 để 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á quá trình kiểm traMục đích: Đá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.
Hình 06 cho thấy, 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ấu trúc của một mức trưởng thành trong mô hình TMM
Đá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 PM 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.
Tóm lược: Trên đây là tóm tắt các bước cơ bản của một quy trình KTPM. Tùy theo đặc thù của dự án, loại kiểm tra và mức độ kiểm tra, quy trình kiểm tra trong thực tế có thể chi tiết hơn nhiều, tuy nhiên các bước trên là xương sống của bất kỳ quy trình kiểm tra nào.
Tham khảo mô hình TMM (Testing Maturity Model).
Nguồn: http://www.bluesoft.com.vn
-
thuandm
- Fresher Tester
- Posts: 17
- Joined: Sun 14 Apr, 2013 10:37 am
- Contact:
Re: Testing process - quy trình kiểm thử phần mềm
Cảm ơn bạn đã chia sẻ. 
Không có mục tiêu nào là quá lớn. Không có ước mơ nào là quá xa vời.
-
KhaiHoan
- Hoc Tester
- Posts: 1
- Joined: Tue 07 May, 2013 9:49 pm
- Contact:
Re: Testing process - quy trình kiểm thử phần mềm
Mình nghĩ Test Plan do QC lead hay PM lập ra chứ nhỉ.
-
tvn
- Admin
- Posts: 4900
- Joined: Tue 10 Aug, 2010 10:11 am
- Location: HCM
- Contact:
Re: Testing process - quy trình kiểm thử phần mềm
Test plan do thường là do QC Leader lập ra chứ PM thì không, PM sẽ lập Project Plan (nó bao gồm một số nội dung của test plan nhưng không chứa cả test plan.
-
VoTaKa
- Hoc Tester
- Posts: 4
- Joined: Mon 05 Aug, 2013 1:53 pm
- Contact:
Re: Testing process - qui trình kiểm thử phần mềm
Anh tvn có thể giải thích rõ cái sơ đồ này được không ạ?tvn wrote:
Hình dưới cho thấy việc thiết kế test không phải chỉ làm một lần, nó sẽ được sửa chữa, cập nhật, thêm hoặc bớt xuyên suốt chu kỳ PTPM, 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 được sửa chữa hoặc bổ sung.
Thời điểm phù hợp để thiết lập các kế hoạch kiểm tra
Lập kế hoạch suốt cả quá trình. Trong khi kiểm tra chỉ có 1 tí xíu.
-
tvn
- Admin
- Posts: 4900
- Joined: Tue 10 Aug, 2010 10:11 am
- Location: HCM
- Contact:
Re: Testing process - quy trình kiểm thử phần mềm
Nhìn vào hình này thì hơi khó hình dung, nhưng bạn nghĩ đến hình V trong V model thì sẽ hiểu hơn.
Ứng với từng giai đoạn bên phát triển phần mềm thì bên phía kiểm thử sẽ có các hoạt động tương ứng để thực hiện test.
Giai đoạn Yêu cầu là lấy yêu cầu người dùng. Thì mình sẽ dựa vào thông tin User requirements để viết kế hoạch kiểm thử ở mức User Acceptance Testing (Kiểm thử chấp nhận người dùng)
Giai đoạn Thiết kế, thì sẽ dựa vào các thông tin này để thực hiện kế hoạch kiểm thử hệ thống - System testing và kiểm thử tích hợp - Integration testing
Giai đoạn viết code (còn gọi triển khai hoặc phát triển) thì mình sẽ tiến hành kế hoạch kiểm thử mức thành phần/ đơn vị - unit test
Bạn nói "kiểm tra chỉ có 1 tí xíu" đó là do bạn chỉ được tham gia vào 1 phần hoặc 1 giai đoạn nào đó của quá trình phát triển phần mềm. Vì vậy bạn chỉ biết phần việc của mình, nên thấy ít. Nếu bạn tham gia cả 1 dự án từ đầu đến cuối và phải test ở nhiều mức, bạn sẽ thấy đuối ngay thôi.
-
VoTaKa
- Hoc Tester
- Posts: 4
- Joined: Mon 05 Aug, 2013 1:53 pm
- Contact:
Re: Testing process - quy trình kiểm thử phần mềm
Cảm ơn anh tvn rất nhiều về câu trả lời này.tvn wrote:
Nhìn vào hình này thì hơi khó hình dung, nhưng bạn nghĩ đến hình V trong V model thì sẽ hiểu hơn.
Ứng với từng giai đoạn bên phát triển phần mềm thì bên phía kiểm thử sẽ có các hoạt động tương ứng để thực hiện test.
Giai đoạn Yêu cầu là lấy yêu cầu người dùng. Thì mình sẽ dựa vào thông tin User requirements để viết kế hoạch kiểm thử ở mức User Acceptance Testing (Kiểm thử chấp nhận người dùng)
Giai đoạn Thiết kế, thì sẽ dựa vào các thông tin này để thực hiện kế hoạch kiểm thử hệ thống - System testing và kiểm thử tích hợp - Integration testing
Giai đoạn viết code (còn gọi triển khai hoặc phát triển) thì mình sẽ tiến hành kế hoạch kiểm thử mức thành phần/ đơn vị - unit test
Bạn nói "kiểm tra chỉ có 1 tí xíu" đó là do bạn chỉ được tham gia vào 1 phần hoặc 1 giai đoạn nào đó của quá trình phát triển phần mềm. Vì vậy bạn chỉ biết phần việc của mình, nên thấy ít. Nếu bạn tham gia cả 1 dự án từ đầu đến cuối và phải test ở nhiều mức, bạn sẽ thấy đuối ngay thôi.
----------
Anh cho em hỏi thêm 1 câu nữa là: Bất kì dự án nào mà làm theo quy trình phát triển phần mềm, thì thời gian/thời điểm của việc lên kế hoạch kiểm thử đều tương tự nhau đúng không ạ?
-
tvn
- Admin
- Posts: 4900
- Joined: Tue 10 Aug, 2010 10:11 am
- Location: HCM
- Contact:
Re: Testing process - quy trình kiểm thử phần mềm
Không phải bất kỳ dự án nào các hoạt động kiểm thử cũng được bắt đầu vào thời điểm giống nhau. Thời điểm này sẽ khác nhau tùy thuộc và tính chất của từng dự án, NHƯNG có 1 điểm chung là, các hoạt động kiểm thử nên được bắt đầu càng sớm càng tốt ngay khi có tài liệu (kể cả bản nháp - chưa chính thức). Mình tham gia vào review (rà soát) xem có lỗi gì ở tài liệu đó hay không, giúp giảm thiểu phát sinh lỗi ở các giai đoạn sau (thiết kế, lập trình,...)VoTaKa wrote:
----------
Anh cho em hỏi thêm 1 câu nữa là: Bất kì dự án nào mà làm theo quy trình phát triển phần mềm, thì thời gian/thời điểm của việc lên kế hoạch kiểm thử đều tương tự nhau đúng không ạ?