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.
Bạn đang xem: Chất lượng phần mềm là gì
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 Script
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 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 tra
Mụ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 tra
Mụ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.
 |
Đá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.
Sau đây, chúng tôi sẽ giới thiệu một mô hình giúp các tổ chức đánh giá và nâng cao năng lực KTPM của mình, đó là mô hình TMM (Testing Maturity Model).
Có rất nhiều định nghĩa về chất lượng phần mềm được đưa ra bởi các tổ chức, cá nhân khác nhau. Trong phạm vi của bài viết này trình bày một số định nghĩa tiêu biểu.
*Định nghĩa theo IEEE(1991):
Định nghĩa 1: Chất lượng phần mềm là một mức độ mà một hệ thống, thành phần hệ thống hay tiến trình đáp ứng được yêu cầu đã được đặc tả.
Định nghĩa 2: Chất lượng phần mềm là mức độ mà một hệ thống, thành phần hệ thống hay tiến trình đáp ứng được yêu cầu và sự mong đợi của khách hàng hay người sử dụng.
*Phân tích hai quan điểm của IEEE:
Theo quan điểm thứ nhất của IEEE: chúng ta sẽ bị phụ thuộc quá nhiều vào tài liệu đặc tả của yêu cầu, dẫn đến nếu việc xấc định yêu cầu bị sai, thiếu thì một phần mềm được làm đúng với đặc tả chưa chắc đã là một phần mềm có chất lượng.
Theo quan điểm thứ hai của IEEE: khách hàng đôi khi không có kiến thức về công nghệ, họ có thể đưa ra những mong muốn hết sức vô lý và có thể thay đổi yêu cầu với phần mềm nhiều lần, thậm chí thay đổi ngay trong giai đoạn cuối. Điều này gây nhiều khó khăn cho việc phát triển phần mềm.
*Định nghĩa theo Pressman: Chất lượng phần mềm là sự phù hợp của các yêu cầu cụ thể về hiệu năng và chức năng, các tiêu chuẩn phát triển phần mềm được ghi lại rõ ràng bằng tài liệu với các đặc tính ngầm định của tất cả các phần mềm được phát triển chuyên nghiệp.
Định nghĩa của Pressman đề xuất ba yêu cầu với chất lượng phần mềm phải được đáp ứng khi phát triển phần mềm:
Các yêu cầu chức năng rõ ràng là nhân tố chính quyết định chất lượng đầu ra của phần mềm.
Các tiêu chuẩn chất lượng phần mềm sẽ được nói đến trong hợp đồng.
Các đặc tính ngầm định cần được đáp ứng trong quá trình phát triển cho dù không được nói đến rõ ràng trong hợp đồng.
1.2. Định nghĩa đảm bảo chất lượng phần mềm
Định nghĩa theo Daniel Galin: Đảm bảo chất lượng phần mềm (Software Quality Assure) là một tập hợp các hành động cần thiết được lên kế hoạch một cách hệ thống để cung cấp đầy đủ niềm tin rằng quá trình phát triển phần mềm phù hợp để thành lập các yêu cầu chức năng kỹ thuật cũng như các yêu cầu quản lý theo lịch trình và hoạt động trong giới hạn ngân sách.
Lỗi phần mềm
2.1. Định nghĩa lỗi phần mềm và phân loại lỗi phần mềm
Định nghĩa lỗi phần mềm: Có rất nhiều định nghĩa về lỗi phần mềm nhưng có thể hiểu và phát biểu một cách đơn giản thì "Lỗi phần mềm là sự không khớp giữa chương trình và đặc tả của nó".Dựa vào định nghĩa, ta có thể phân loại lỗi phần mềm thành 3 dạng:Lỗi sai: Sản phẩm phần mềm được xây dựng khác với đặc tả.Lỗi thiếu: Các yêu cầu của sản phẩm phần mềm đã có trong đặc tả nhưng lại không có trong sản phẩm thực tế.Lỗi thừa: Sản phẩm thực tế có những tính năng không có trong tài liệu đặc tả.2.2. Các nguyên nhân gây lỗi phần mềm
Lỗi phần mềm có thể đến từ nhiều nguyên nhân khác nhau, trong đó có cả các nguyên nhân chủ quan và các nguyên nhân khách quan. Dưới đây là chín nguyên nhân chủ yếu gây ra lỗi phần mềm:
*Định nghĩa các yêu cầu bị lỗi: Những lỗi trong việc xác định yêu cầu thường nằm ở phía khách hàng. Một số lỗi thường gặp là: định nghĩa sai yêu cầu, lỗi không hoàn chỉnh, thiếu các yêu cầu quan trọng hoặc là quá chú trọng các yêu cầu không thật sự cần thiết.
*Các lỗi trong giao tiếp giữa khách hàng và nhà phát triển: Hiểu lầm trong giao tiếp giữa khách hàng và nhà phát triển cũng là nguyên nhân gây lỗi. Những lỗi này thường xuất hiện trong giai đoạn đầu của dự án. Một số lỗi hay gặp phải: hiểu sai chỉ dẫn trong tài liệu yêu cầu, hiểu sai thay đổi khi khách hàng trình bày bằng lời nói và tài liệu, hiểu sai về phản hồi và thiếu quan tâm đến những đề cập của khách hàng.
Giải pháp khắc phục: Cần có ủy ban liên kết giữa khách hàng và nhà cung cấp để tránh lỗi trong giao tiếp. Ủy ban do quản trị dự án đứng đầu và khách hàng phải giới thiệu những người hiểu về mặt nghiệp vụ vào ủy ban đó.*Sai lệch có chủ ý với các yêu cầu phần mềm: Trong một số trường hợp các nhà phát triển cố tình làm sai lệnh các yêu cầu trong tài liệu đặc tả. Nguyên nhân của việc này đến từ các áp lực thời gian, ngân sách, hay cố tình sử dụng lại các mô-đun từ các dự án trước mà chưa phân tích đầy đủ những thay đổi để thích nghi với các yêu cầu mới.
Giải pháp khắc phục: Dựa trên những thống kê để quyết định xem giải pháp như thế nào, sắp xếp ưu tiên xem bỏ được yêu cầu nào hay sử dụng lại được mô-đun nào.*Các lỗi thiết kế logic: Lỗi phần mềm xảy ra trong quá trình các chuyên gia thiết kế hệ thống, các kiến trúc sư hệ thống, kỹ sư phần mềm, các nhà phân tích xây dựng phần mềm theo yêu cầu. Các lỗi điển hình bao gồm:
Định nghĩa các yêu cầu phần mềm bằng các thuật toán sai.
Quy trình định nghĩa có chứa trình tự lỗi.
Sai sót trong các định nghĩa biên như > 3 hay ≥ 3.
Thiếu sót các trạng thái hệ thống phần mềm được yêu cầu.
*Các lỗi lập trình: Có rất nhiều lý do dẫn đến việc các lập trình viên gây ra các lỗi lập trình. Những lý do này bao gồm: sự hiểu sai các tài liệu thiết kế, ngôn ngữ; sai sót trong ngôn ngữ lập trình; sai sót trong việc áp dụng các công cụ phát triển; sai sót trong lựa chọn dữ liệu...
*Không tuân thủ theo các tài liệu hướng dẫn và tiêu chuẩn lập trình: Các lỗi phần mềm có thể đến từ việc không tuân thủ các tài liệu và tiêu chuẩn lập trình của các tổ chức phát triển phần mềm.
*Thiếu sót trong quá trình kiểm thử: Lỗi phần mềm có thể đến từ chính quá trình kiểm thử khi mà người kiểm thử để lọt lỗi.
Những lỗi này đến từ các nguyên nhân sau đây:
Kế hoạch kiểm thử chưa hoàn chỉnh, để sót yêu cầu cần kiểm thử.Lỗi trong tài liệu và báo cáo kiểm thử.Việc sửa chữa các lỗi được phát hiện không hoàn chỉnh do áp lực thời gian hay do thiếu cẩn thận.Giải pháp: Lên kế hoạch kiểm thử cụ thể tại giai đoạn đầu của dự án.
*Các lỗi thủ tục: Các thủ tục hướng dẫn cho người sử dụng tại từng bước của tiến trình. Chúng có tầm quan trọng đặc biệt trong các hệ thống phần mềm phức tạp mà các tiến trình được thực bằng nhiều bước, mỗi bước có thể có nhiều kiểu dữ liệu và cho phép kiểm tra các kết quả trung gian. Các lỗi có thể đến từ việc viết các thủ tục.
*Các lỗi về tài liệu: Các lỗi về tài liệu là vấn đề của các đội phát triển và bảo trì khi có những sai sót trong các tài liệu liên quan. Những lỗi này có thể là nguyên nhân gây ra lỗi trong giai đoạn phát triển kế tiếp và giai đoạn bảo trì.
2.3. Chi phí cho việc sửa lỗi phần mềm
Việc kiểm thử và sửa lỗi phần mềm có thể thực hiện trong bất cứ giai đoạn nào của vòng đời phần mềm. Tuy nhiên công việc này nên được thực hiện càng sớm càng tốt vì càng về giai đoạn sau của vòng đời phần mềm, chi phí cho việc tìm và sửa lỗi càng tăng, đặc biệt là đến giai đoạn đã triển khai phần mềm thì chi phí cho sửa lỗi sẽ trở nên rất lớn và ảnh hưởng trực tiếp đến uy tín của tổ chức phát triển phần mềm.
Theo tài liệu của Boehm, chi phí cho việc tìm và sửa lỗi phần mềm sẽ tăng theo hàm mũ trong biểu đồ sau:
_Sơ đồ 1: Chi phí cho việc sửa lỗi phần mềm _
Quy trình xử lý lỗi phần mềm
Trước khi giới thiệu về qui trình xử lý lỗi phần mềm, sau đây sẽ trình bày về các trạng thái có thể có của lỗi.
Sơ đồ 2: Các trạng thái của lỗi
Trong đó:* New: Lỗi mới* Assigned: Lỗi đã được gán cho nhân viên phát triển* Resolved: Lỗi đã được xử lý* Confirmed: Lỗi cần được chứng thực, thảo luận lại* Canceled: Lỗi được xác định là không phải lỗi, lỗi được bỏ qua* Next: Lỗi không thuộc phạm vi của dự án, hoặc sẽ được xử lý trong một giai đoạn khác của dự án* Accept: Các lỗi có thể chấp nhận được. Ví dụ: Các lỗi do Framework* Closed: Trạng thái đóng. Lỗi đã được sửa thành công.
Mỗi tổ chức phát triển phần mềm sẽ sử dụng một công cụ quản lý lỗi riêng, trong đó có thể kể đến Mantis là một công cụ được sử dụng khá phổ biến hiện nay. Phần tiếp theo sẽ trình bày một qui trình xử lý lỗi phần mềm hiện đang được sử dụng trong thực tế ở một số tổ chức phát triển và gia công phần mềm:
Sơ đồ 3: Qui trình xử lý lỗi
Theo đó, qui trình xử lý lỗi có thể bao gồm 6 bước chính:
Bước 0_Bắt đầu: Phát hiện phần mềm có lỗiBước 1_Đưa lỗi lên hệ thống quản lý lỗi
Bước 2_Gán lỗi cho nhân viên phát triển
Bước 3_Xử lý lỗi
Bước 4_Kiểm thử lại
Bước 5_Đóng lỗi
3.1. Bước 1: Đưa lỗi lên phần mềm quản lý lỗi
Người thực hiện: tất cả các thành viên trong đội dự án như quản trị dự án, nhóm kiểm thử, nhóm giải pháp, nhóm lập trình.Trạng thái của lỗi là NEW.*** Một số thông tin cần có về lỗi: **
Category: Thư mục lỗi dùng để phân loại lỗi, lỗi thuộc phần chức năng nào phải chọn đúng phần thư mục lỗi tương ứng để thuận tiện cho việc tra cứu, thống kê lỗi của chức năng.Severity (trọng số của lỗi): Thông số này biểu hiện độ nghiêm trọng của lỗi, thông thường lỗi sẽ thuộc một trong ba trọng số dưới đây:Minor: Các lỗi định dạng (font chữ, cỡ chữ, màu sắc của các đối tượng, chiều dài của các đối tượng), lỗi chính tả, lỗi validate dữ liệu.Major: Các lỗi ràng buộc dữ liệu, lỗi chức năng nghiệp vụ của hệ thống (nhưng chưa gây ra treo hệ thống hay không làm cho hệ thống không xử lý được tiếp).Crash: Các lỗi chức năng nghiệp vụ của hệ thống gây treo hệ thống, không xử lý được tiếp.Reproducibility: Khả năng tái tạo lỗi. Khi phát hiện ra lỗi, nhân viên kiểm thử cần thực hiện lại phần chức năng phát hiện ra lỗi để xét khả năng tái tạo lỗi và lựa chọn đúng khả năng tái tạo lỗi.Priority: Mức độ ưu tiên trong việc sửa lỗi.Summary: Tóm tắt nội dung lỗi, có thể coi là tiêu đề của lỗi.Description: Đây là phần mô tả lỗi, phải mô tả rõ 3 phần nội dung:Các bước thực hiện.Kết quả trả về từ hệ thống o Kết quả mong muốnNotes: Dùng để đưa các lưu ý, trao đổi về lỗi của các thành viên trong dự án.
3.2. Bước 2: Gán lỗi cho nhân viên phát triển
Nhân viên kiểm thử thực hiện gán lỗi cho nhân viên phát triển, người sẽ chịu trách nhiệm về phần chức năng bị lỗi.
Trạng thái của lỗi là ASSIGNED.
Lưu ý:Trưởng nhóm kiểm thử, quản trị dự án có thể xem xét lại các lỗi có trạng thái NEW và ASSIGNED trên hệ thống phần mềm quản lý lỗi: o Nếu thấy không phải là lỗi thì đưa lỗi về trạng thái CANCELLED và nêu rõ nguyên nhân đưa lỗi về CANCELLED.
Nếu thấy nhân viên kiểm thử mô tả không rõ ràng, thiếu thông tin thì chuyển lỗi sang trạng thái CONFIRMED và yêu cầu nhân viên kiểm thử bổ sung thêm thông tin.
Nếu thấy lỗi không thuộc phạm vi phát triển của dự án trong giai đoạn hiện tại thì chuyển lỗi về trạng thái NEXT.
Quản trị dự án xem xét lại các lỗi có trạng thái NEW hoặc ASSIGNED, nếu thấy là lỗi nhưng có thể chấp nhận được thì chuyển lỗi sang trạng thái ACCEPTED và nêu rõ nguyên nhân đưa lỗi về trạng thái ACCEPTED.
3.3. Bước 3: Xử lý lỗi
Nhân viên phát triển xem xét các lỗi được gán cho mình:
Nếu thấy đúng là lỗi và đã mô tả lỗi rõ ràng, đầy đủ thông tin, nhân viên phát triển thực hiện sửa lỗi và chuyển lỗi về trạng thái RESOLVED, đồng thời bắt buộc nêu rõ hướng giải quyết và các chức năng bị ảnh hưởng trong phần NOTES.Các trường hợp khác: Nếu thấy không phải là lỗi của hệ thống, nhân viên phát triển sẽ yêu cầu nhân viên kiểm thử bổ sung thêm thông tin, hoặc thấy là lỗi nhưng có thể chấp nhận được lỗi thì nhân viên phát triển chuyển lỗi sang trạng thái CONFIRMED và nêu rõ lý do chuyển lỗi sang trạng thái CONFIRMED trong phần NOTES.3.4. Bước 4: Kiểm thử lại
Theo phân công của trưởng nhóm kiểm thử, nhân viên kiểm thử thực hiện kiểm thử lại các chức năng có lỗi đang ở trạng thái RESOLVED:
Nếu lỗi đã được sửa thì chuyển lỗi về trạng thái CLOSED.Nếu lỗi chưa được sửa hoặc mới chỉ sửa một phần thì chuyển lỗi về trạng thái ASSIGNED và nêu rõ những phần chức năng nào chưa chỉnh sửa để nhân viên phát triển tiến hành sửa tiếp.Nếu thấy có thể chấp nhận lỗi thì chuyển lỗi về trạng thái ACCEPTED. Đồng thời khi cập nhật kịch bản kiểm thử thì sẽ để kết quả của case đó là fail (vì vẫn là lỗi).Lưu ý: Nếu phần chức năng bị ảnh hưởng gây ra lỗi mới thì đưa một lỗi mới lên phần mềm quản lý lỗi.*Tổng kết
Bài viết đã trình bày được những định nghĩa và những vấn đề cơ bản xung quanh phần mềm, công nghệ phần mềm, lỗi phần mềm và xử lý lỗi phần mềm.
Xem thêm: Liên minh anh hùng zing me, tải miễn phí apk liên minh anh hùng android
Các vấn đề cụ thể bao gồm:
Các định nghĩa về phần mềm, công nghệ phần mềm, chất lượng phần mềm, bảo đảm chất lượng phần mềm, lỗi phần mềm.Các vấn đề liên quan đến lỗi phần mềm và qui trình xử lý lỗi phần mềm.