Trong thời đại công nghệ phát triển không ngừng, việc đảm bảo chất lượng phần mềm trở thành một yếu tố then chốt quyết định sự thành công của sản phẩm.
Với sự phức tạp ngày càng tăng của các chương trình, việc kiểm thử phần mềm không chỉ là một bước cần thiết mà còn là một nghệ thuật đòi hỏi sự tỉ mỉ và chính xác. Bài viết này tại VNLibs.com sẽ giúp bạn hiểu rõ hơn về các khái niệm cơ bản và kỹ thuật kiểm thử phần mềm hiện đại, từ đó nâng cao chất lượng sản phẩm và đáp ứng tốt hơn nhu cầu của người dùng.
Có một nhận định về công việc kiểm thử (testing) chương trình. Càng ngày các chương trình (phần mềm) càng trở nên phức tạp và đồ sộ. Việc tạo ra một sản phẩm có thể bán được trên thị trường, đòi hỏi sự nỗ lực của hàng chục, hàng trăm, thậm chí hàng ngàn nhân viên. Số lượng dòng mã lên đến hàng triệu.
Để tạo ra một sản phẩm thì không phải chỉ do một tổ chức đứng ra làm từ đất đến cuối, mà đòi hỏi sự liên kết, tích hợp của rất nhiều sản phẩm, thư viện lập trình,… của nhiều tổ chức khác nhau. Từ đó, đòi hỏi việc kiểm nghiệm phần mềm càng ngày càng trở nên rất quan trọng và cực kỳ phức tạp.
Song song với sự phát triển các công nghệ lập trình và các ngôn ngữ lập trình, dẫn đến các công nghệ và kỹ thuật kiểm thử phần mềm ngày càng phát triển và mang tính khoa học. Bài viết này tại VNLibs.com giúp bạn đưa ra được mục đích tập hợp, nghiên cứu, phân tích các kỹ thuật, các công nghệ kiểm thử phần mềm đang được sử dụng và phát triển hiện nay.
“Lỗi phần mềm là chuyện hiển nhiên của cuộc sống. Chúng ta dù cố gắng đến mức nào, thì thực tế là ngay cả những lập trình viên xuất sắc nhất cũng không thể lúc nào, cũng viết được những đoạn mã không có lỗi. Tính trung bình, ngay cả một lập trình viên loại tốt, thì cũng có từ 1 đến 3 lỗi trên 100 dòng lệnh. Người ta ước lượng rằng việc kiểm tra để tìm ra các lỗi này, chiếm phân nửa khối lượng công việc phải làm, để có được một phần mềm hoạt động được“. (Software Testing Techniques, Second Edition, by Boris Beizer, Van Nostrand Reinhold, 1990, ISBN 1850328803).
1. Định nghĩa về kiểm thử phần mềm.
“Việc kiểm thử là quá trình thực thi một chương trình với mục đích là tìm ra lỗi” – Glen Myers.
Kiểm thử phần mềm là một quá trình điều tra được thực hiện để cung cấp cho các bên liên quan thông tin về chất lượng của sản phẩm hoặc dịch vụ đang được kiểm thử. Kiểm thử phần mềm cũng có thể cung cấp một cái nhìn khách quan, độc lập về phần mềm để cho phép doanh nghiệp đánh giá và hiểu rõ những rủi ro khi triển khai phần mềm. Định nghĩa này đã được cập nhật dựa trên định nghĩa của ISTQB (International Software Testing Qualifications Board).
Nói cách khác: Kiểm thử phần mềm không chỉ đơn thuần là việc chạy chương trình với mục đích tìm ra lỗi (như định nghĩa của Glen Myers), mà còn là một quá trình mang tính hệ thống và toàn diện, bao gồm nhiều hoạt động khác nhau nhằm:
– Phát hiện lỗi: Tìm kiếm và xác định các lỗi (bug/defect/fault) tồn tại trong phần mềm.
– Phòng ngừa lỗi: Áp dụng các kỹ thuật và phương pháp để ngăn chặn lỗi xuất hiện ngay từ giai đoạn đầu của quá trình phát triển.
– Đánh giá chất lượng: Đánh giá các thuộc tính chất lượng của phần mềm, bao gồm không chỉ chức năng (phần mềm có hoạt động đúng như mong đợi hay không) mà còn cả hiệu năng, bảo mật, khả năng sử dụng, độ tin cậy, khả năng bảo trì,…
– Cung cấp thông tin: Cung cấp thông tin khách quan và đáng tin cậy về chất lượng phần mềm cho các bên liên quan (khách hàng, quản lý dự án, nhóm phát triển,…) để họ có thể đưa ra quyết định phù hợp.
– Nâng cao sự tự tin: Xây dựng niềm tin vào chất lượng phần mềm và giảm thiểu rủi ro khi triển khai.
Các đặc điểm của kiểm thử phần mềm: Là một quá trình liên tục được thực hiện trong suốt vòng đời phát triển phần mềm, từ giai đoạn phân tích yêu cầu đến giai đoạn bảo trì; Bao gồm cả hoạt động tĩnh (ví dụ: review code) và hoạt động động (ví dụ: chạy test case); Có thể được thực hiện thủ công hoặc tự động, hoặc kết hợp cả hai.
Mục tiêu của kiểm thử phần mềm: Mục tiêu cuối cùng của kiểm thử phần mềm là đảm bảo chất lượng phần mềm và mang lại sự hài lòng cho người dùng.
Tóm lại: Kiểm thử phần mềm là một phần không thể thiếu trong quy trình phát triển phần mềm, đóng vai trò quan trọng trong việc đảm bảo chất lượng phần mềm, giảm thiểu rủi ro và nâng cao sự hài lòng của người dùng.
2. Các thuật ngữ trong kiểm thử phần mềm.
– Lỗi (Error): Là các lỗi lầm do con người gây ra.
– Sai sót (Fault): Sai sót gây ra lỗi. Có thể phân loại như sau: Sai sót do đưa ra dư thừa là chúng ta đưa một vài thứ không chính xác so với mô tả yêu cầu phần mềm; Sai sót do bỏ sót là người thiết kế có thể gây ra sai sót do bỏ sót, kết quả là thiếu một số phần đáng ra phải có trong mô tả yêu cầu phần mềm.
– Hỏng hóc (Failure): Xảy ra khi sai sót được thực thi. (Khi thực thi chương trình tại các nơi bị sai thì sẽ xảy ra trạng thái hỏng hóc).
– Kết quả không mong đợi, hậu quả (Incident): Là những kết quả do sai sót gây ra. Hậu quả là các triệu chứng liên kết với một hỏng hóc và báo hiệu cho người dùng biết sự xuất hiện của hỏng hóc.
– Trường hợp thử (Test case): Trường hợp thử được liên kết tương ứng với hoạt động của chương trình. Một trường hợp thử bao gồm một tập các giá trị đầu vào và một danh sách các kết quả đầu ra mong muốn.
– Thẩm tra (Verification): Thẩm tra là tiến trình nhằm xác định đầu ra của một công đoạn trong việc phát triển phần mềm phù hợp với công đoạn trước đó. Thẩm tra là quá trình xem xét chứng ta đang xây dựng đúng sản phẩm phần mềm mà được đặc tả hay không?
– Xác nhận (Validation): Xác nhận là tiến trình nhằm chỉ ra toàn bộ hệ thống đã phát triển xong, phù hợp với tài liệu mô tả yêu cầu. Xác nhận là quá trình kiểm chứng, chúng ta xây dựng sản phẩm đúng đắn mà phù hợp với yêu cầu của người dùng.
So sánh giữa Thẩm tra và Xác nhận: Thẩm tra là quan tâm đến việc ngăn chặn lỗi giữa các công đoạn; Xác nhận là quan tâm đến sản phẩm cuối cùng không còn lỗi.
– Bug: Thuật ngữ thông dụng chỉ lỗi phần mềm, thường được sử dụng thay thế cho “Fault” hoặc “Error”.
– Defect: Cũng là một thuật ngữ chỉ lỗi phần mềm, tương đương với “Fault” hoặc “Bug”.
– Debug: Quá trình tìm kiếm và sửa lỗi phần mềm (Bug/Defect/Fault).
– Test Suite: Tập hợp các Test Case được thiết kế để kiểm tra một chức năng hoặc module cụ thể của phần mềm.
– Test Plan: Tài liệu mô tả chi tiết về phạm vi, mục tiêu, phương pháp, nguồn lực và lịch trình của quá trình kiểm thử.
– Test Report: Tài liệu tổng hợp kết quả của quá trình kiểm thử, bao gồm thông tin về các lỗi đã phát hiện, mức độ nghiêm trọng của lỗi và các khuyến nghị.
Ví dụ: Error (Lỗi của con người) –> Fault (Sai sót trong code) –> Failure (Hỏng hóc khi thực thi) –> Incident (Hậu quả người dùng gặp phải).
Giải thích ví dụ: Error: Lập trình viên quên kiểm tra điều kiện đầu vào; Fault: Đoạn code không xử lý trường hợp đầu vào không hợp lệ; Failure: Chương trình bị crash khi người dùng nhập dữ liệu không hợp lệ; Incident: Người dùng không thể sử dụng chức năng của chương trình.
3. Tại sao lại xuất hiện lỗi?
Nhiều trường hợp kiểm thử được thực thi trong các dự án từ rất nhỏ đến cực lớn, và cho các kết quả giống nhau. Một trong số các nguyên nhân gây ra lỗi là ở khâu đặc tả. Lỗi được gây ra bởi nhiều nguyên nhân, nhưng phân tích trong một vài dự án, thì nguyên nhân chính gây ra lỗi tập trung ở khâu đặc tả.
Có một vài nguyên nhân từ khâu đặc tả là lỗi lớn trong quá trình sản xuất phần mềm. Trong một số trường hợp đơn giản không có tài liệu về đặc tả. Những nguyên nhân khác có thể là đặc tả chưa hoàn toàn đầy đủ, liên tục thay đổi hoặc liên lạc nối kết trong toàn đội phát triển không tốt. Việc lập kế hoạch cho việc phát triển phần mềm là cực kỳ quan trọng, nếu khâu này không được làm tốt thì chắc chắn có nhiều lỗi xảy ra.
Một nguyên nhân lớn thứ hai có thể gây ra lỗi là khâu thiết kế. Đó là khâu mà các lập trình viên bố trí kế hoạch phấn mềm của họ. Có thể so sánh khâu này giống như trong thiết kế một tòa nhà vậy! Lỗi xảy ra trong giai đoạn này giống như trong khâu đặc tả. Nó được thiết kế vội vàng, thay đổi công nghệ hay do tương tác bởi nhiều hệ thống.
Lỗi viết mã thì đã quen thuộc với những người lập trình. Nguyên nhân của những lỗi này, thường cũng xuất phát từ độ phức tạp của chương trình, hay những tài liệu nghèo nàn (đặc biệt trong những đoạn mã lệnh được nâng cấp hoặc sửa chữa lại), và do áp lực về thời gian. Điều quan trọng là cần chú ý rằng, những lỗi trong lập trình có thể do lỗi đặc tả và thiết kế gây nên.
Các ví dụ bên dưới đây cho thấy việc kiểm tra và đảm bảo chất lượng phần mềm là vô cùng quan trọng. Phát hiện và sửa lỗi càng sớm, chi phí càng thấp và giảm thiểu rủi ro cho dự án. Ngược lại, nếu lỗi được phát hiện muộn, chi phí sửa chữa sẽ tăng lên đáng kể, thậm chí gây ra hậu quả nghiêm trọng về kinh tế và uy tín. Dưới đây là một số ví dụ thực tế:
3.1. Lỗi do đặc tả:
– Dự án hệ thống quản lý hành lý sân bay Denver (1994): Hệ thống tự động phân loại và vận chuyển hành lý trị giá 193 triệu USD đã thất bại thảm hại do đặc tả yêu cầu không rõ ràng và thiếu kiểm tra kỹ lưỡng. Hệ thống quá phức tạp, không đáp ứng được lưu lượng hành lý thực tế, dẫn đến chậm trễ chuyến bay, hư hỏng hành lý và thiệt hại hàng triệu USD. (Nguồn: https://www.wired.com).
– Ứng dụng Therac-25 (1985-1987): Máy xạ trị Therac-25 đã gây ra nhiều ca tử vong và thương tích do lỗi phần mềm. Nguyên nhân chính là đặc tả yêu cầu không đầy đủ và thiếu cơ chế xử lý lỗi, dẫn đến việc máy xạ trị quá liều cho bệnh nhân. (Nguồn: https://en.wikipedia.org/wiki/Therac-25).
3.2. Lỗi do thiết kế:
– Tàu con thoi Ariane 5 (1996): Tên lửa Ariane 5 đã nổ tung chỉ sau 40 giây phóng do lỗi chuyển đổi dữ liệu từ hệ thống định vị quán tính 64 bit sang hệ thống điều khiển 16 bit. Lỗi này xuất phát từ việc tái sử dụng mã nguồn từ tên lửa Ariane 4 mà không xem xét kỹ sự khác biệt về thiết kế. (Nguồn: https://www.esa.int/Enabling_Support/Space_Transportation/Launch_vehicles/Ariane_5).
– Hệ thống điều khiển máy bay Boeing 737 MAX (2018-2019). Hệ thống MCAS (Maneuvering Characteristics Augmentation System). Hệ thống MCAS được Boeing phát triển để tự động điều chỉnh góc tấn của máy bay 737 MAX, nhằm ngăn chặn tình trạng máy bay bị chết máy (stall) khi cất cánh với góc dốc lớn. Tuy nhiên, thiết kế của MCAS có một số điểm yếu nghiêm trọng. Hậu quả, hai vụ tai nạn thảm khốc của máy bay Boeing 737 MAX (Lion Air Flight 610 và Ethiopian Airlines Flight 302) đã khiến 346 người thiệt mạng. Nguyên nhân chính của cả hai vụ tai nạn đều liên quan đến lỗi thiết kế của hệ thống MCAS. Sau các vụ tai nạn, Boeing đã phải ngừng sản xuất và cấm bay 737 MAX trên toàn cầu để điều tra và sửa chữa lỗi. (Nguồn: https://en.wikipedia.org/wiki/Boeing_737_MAX_groundings).
3.3. Lỗi viết mã:
– Lỗ hổng Heartbleed (2014): Lỗ hổng bảo mật nghiêm trọng trong thư viện OpenSSL cho phép tin tặc đánh cắp dữ liệu nhạy cảm từ máy chủ web. Lỗi này xuất phát từ việc viết mã không kiểm tra kỹ lưỡng giới hạn bộ nhớ, dẫn đến việc tin tặc có thể truy cập vào vùng nhớ không được phép. (Nguồn: https://heartbleed.com).
– Sự cố Y2K (2000): Nhiều hệ thống máy tính cũ đã gặp sự cố khi chuyển sang năm 2000 do sử dụng định dạng ngày tháng chỉ có 2 chữ số cuối. Lỗi này xuất phát từ việc viết mã không lường trước được sự thay đổi thế kỷ, dẫn đến việc máy tính hiểu năm 2000 là năm 1900. (Nguồn: https://en.wikipedia.org/wiki/Year_2000_problem).
Lưu ý: Các ví dụ trên chỉ là một phần nhỏ trong số rất nhiều sự cố phần mềm đã xảy ra trong lịch sử. Việc nghiên cứu và học hỏi từ những sai lầm này sẽ giúp chúng ta nâng cao chất lượng phần mềm và giảm thiểu rủi ro trong tương lai.
4. Chi phí cho việc sửa lỗi.
Phần mềm được thiết lập theo quy trình phát triển phần mềm. Từ lúc bắt đầu dự án, qua các khâu lập kế hoạch, lập trình, kiểm thử và sử dụng trong cộng đồng, thì sẽ phát hiện được một vài lỗi tiềm năng. Thông thường, chi phí để sửa các lỗi sẽ tăng theo thời gian.
Chi phí sửa lỗi tăng lên gấp 10 lần theo thời gian. Một lỗi nào đó được tìm thấy và sửa trong giai đoạn đầu, khi mà tài liệu đặc tả đang được viết, thì chi phí không là bao nhiêu, chỉ có thể là tương đương giá trị 1 USD cho lỗi này.
Tuy nhiên, cũng lỗi thế này, nếu không được phát hiện cho đến giai đoạn viết mã và kiểm thử, thì chi phí để sửa lỗi có thể đã tăng lên từ 10 USD đến 100 USD. Và nếu lỗi này không được phát hiện sớm, đến khách hàng hoặc người sử dụng phát hiện ra lỗi tìm ẩn, thì chi phí có thể lên đến hàng ngàn USD, hoặc hàng tỷ USD.
Bạn có muốn biết thêm chi tiết về các ví dụ chi phí sửa lỗi tăng theo thời gian sẽ trông như thế nào không?
4.1. Lỗi trong hệ thống ngân hàng:
– Gọi đoạn mã sai: Trong giai đoạn phát triển, một lập trình viên vô tình gọi một đoạn mã xử lý sai trong module tính lãi suất. Nếu lỗi này được phát hiện trong quá trình review code (giai đoạn đầu), chi phí sửa chữa chỉ khoảng 100 USD (thời gian sửa lỗi và kiểm tra lại).
– Phát hiện trong kiểm thử nội bộ: Nếu lỗi không được phát hiện trong review code mà đến giai đoạn kiểm thử nội bộ mới phát hiện, chi phí sẽ tăng lên khoảng 1.000 USD (thời gian sửa lỗi, kiểm tra lại toàn bộ module liên quan và cập nhật tài liệu).
– Phát hiện sau khi triển khai: Nếu lỗi không được phát hiện trong kiểm thử và hệ thống đã được triển khai cho khách hàng, chi phí sửa chữa có thể lên đến 10.000 USD hoặc hơn (thời gian sửa lỗi, kiểm tra lại toàn bộ hệ thống, cập nhật phiên bản mới, thông báo cho khách hàng và xử lý các phát sinh liên quan). Thậm chí, nếu lỗi gây ra thiệt hại tài chính cho khách hàng, ngân hàng có thể phải bồi thường hàng triệu USD.
4.2. Lỗi trong ứng dụng di động:
– Lỗi hiển thị giao diện: Trong giai đoạn thiết kế, một designer mắc lỗi trong việc thiết kế giao diện, khiến một số nút bấm bị che khuất trên một số thiết bị. Nếu lỗi này được phát hiện trong quá trình review thiết kế (giai đoạn đầu), chi phí sửa chữa chỉ khoảng 50 USD (thời gian chỉnh sửa thiết kế).
– Phát hiện trong kiểm thử beta: Nếu lỗi không được phát hiện trong giai đoạn thiết kế mà đến giai đoạn kiểm thử beta mới phát hiện, chi phí sẽ tăng lên khoảng 500 USD (thời gian chỉnh sửa thiết kế, cập nhật code, kiểm tra lại ứng dụng trên nhiều thiết bị).
– Phát hiện sau khi phát hành: Nếu lỗi không được phát hiện trong kiểm thử và ứng dụng đã được phát hành trên kho ứng dụng, chi phí sửa chữa có thể lên đến 5.000 USD hoặc hơn (thời gian chỉnh sửa thiết kế, cập nhật code, kiểm tra lại ứng dụng, phát hành phiên bản mới, thông báo cho người dùng và xử lý các đánh giá tiêu cực).
4.3. Lỗi trong website thương mại điện tử:
– Lỗi liên kết đến trang sản phẩm: Trong giai đoạn phát triển, một lập trình viên đặt sai đường dẫn liên kết đến trang chi tiết sản phẩm. Nếu lỗi này được phát hiện trong quá trình kiểm thử chức năng (giai đoạn đầu), chi phí sửa chữa chỉ khoảng 20 USD (thời gian sửa code và kiểm tra lại liên kết).
– Phát hiện trong kiểm thử người dùng: Nếu lỗi không được phát hiện trong kiểm thử chức năng mà đến giai đoạn kiểm thử người dùng mới phát hiện, chi phí sẽ tăng lên khoảng 200 USD (thời gian sửa code, kiểm tra lại toàn bộ website, cập nhật tài liệu hướng dẫn).
– Phát hiện sau khi website hoạt động: Nếu lỗi không được phát hiện trong kiểm thử và website đã hoạt động, chi phí sửa chữa có thể lên đến 2.000 USD hoặc hơn (thời gian sửa code, kiểm tra lại toàn bộ website, cập nhật phiên bản mới, thông báo cho khách hàng và xử lý các đơn hàng bị ảnh hưởng). Lỗi này còn có thể làm giảm doanh thu do khách hàng không thể truy cập vào trang sản phẩm để mua hàng.
4.4. Lỗi trong trò chơi điện tử:
– Lỗi mất cân bằng trong game: Trong giai đoạn thiết kế game, một nhà phát triển thiết lập chỉ số sức mạnh của một nhân vật quá cao, khiến nhân vật này trở nên “bất khả chiến bại”. Nếu lỗi này được phát hiện trong quá trình thử nghiệm nội bộ (giai đoạn đầu), chi phí sửa chữa chỉ khoảng 100 USD (thời gian điều chỉnh chỉ số và kiểm tra lại).
– Phát hiện trong giai đoạn thử nghiệm beta: Nếu lỗi không được phát hiện trong thử nghiệm nội bộ mà đến giai đoạn thử nghiệm beta mới phát hiện, chi phí sẽ tăng lên khoảng 1.000 USD (thời gian điều chỉnh chỉ số, kiểm tra lại cân bằng game, cập nhật phiên bản beta và thu thập phản hồi từ người chơi).
– Phát hiện sau khi game phát hành: Nếu lỗi không được phát hiện trong thử nghiệm và game đã phát hành, chi phí sửa chữa có thể lên đến 10.000 USD hoặc hơn (thời gian điều chỉnh chỉ số, kiểm tra lại cân bằng game, phát hành bản cập nhật, thông báo cho người chơi và xử lý các phàn nàn từ cộng đồng). Lỗi này còn có thể ảnh hưởng đến trải nghiệm người chơi và uy tín của nhà phát hành.
Kết luận: Các ví dụ trên cho thấy rõ ràng rằng việc phát hiện và sửa lỗi càng sớm trong quá trình phát triển phần mềm, chi phí càng thấp. Ngược lại, nếu lỗi được phát hiện muộn, chi phí sửa chữa sẽ tăng lên đáng kể và có thể gây ra những hậu quả nghiêm trọng về tài chính, uy tín và trải nghiệm người dùng.
Tác giả: Thạc Bình Cường
Bạn đang xem bài viết:
Các định nghĩa về kiểm thử và đảm bảo chất lượng phần mềm
Link https://vnlibs.com/cong-nghe/cac-dinh-nghia-ve-kiem-thu-va-dam-bao-chat-luong-phan-mem.html
