Khái niệ m l ỗ i
Trước khi đề cập đến kiếm thử phần mềm, trước hết chúng ta sẽ tìm hiếu một số khái niệm liên quan đến lỗi
Trong các ví dụ đã nêu, chúng ta nhận thấy phần mềm hoạt động không đạt yêu cầu, dẫn đến việc xác định phần mềm có lỗi Ngoài ra, có thể sử dụng nhiều thuật ngữ khác để mô tả tình trạng này như thất bại, sai sót, vấn đề, bất thường, không hợp lý và không tương thích.
Để hiểu rõ hơn về lỗi phần mềm, cần có một định nghĩa cụ thể Lỗi phần mềm được xác định dựa trên khái niệm đặc tả, mà trong đó đặc tả là sự thống nhất giữa các nhà phát triển phần mềm và người sử dụng.
Lỗi phần mềm xuất hiện khi một hay nhiều điều kiện sau là đúng [2] (,) :
1 Phần mềm không thực hiện đúng những gì mà đặc tả định nghĩa
2 Phần mềm thực hiện những gì mà đặc tả khuyến cáo không nên thực hiện
3 Phần mềm thực hiện những gì mà đặc tảkhông đề cập đến
4 Phần mềm không thực hiện những gì mà đặc tảkhông đề cập đến nhưng lẽ ra nên thực hiện
5 Phần mềm là khó hiểu hay khó sử dụng
Chương trình tính toán trên phân số cho phép thực hiện các phép toán như rút gọn, cộng, trừ, nhân và chia Để đảm bảo tính chính xác, chương trình phải thực hiện đúng các phép toán này; nếu khi cộng hai phân số mà không hiển thị kết quả hoặc hiển thị sai, đó là lỗi theo điều kiện 1 Ngoài ra, chương trình không nên chạy ở chế độ thường trú, vì nếu luôn ở chế độ này sẽ tốn kém bộ nhớ, đây là lỗi theo điều kiện 2.
Khi kiểm tra, chúng ta nhận thấy rằng bên cạnh các phép toán rút gọn phân số, còn có các phép toán cộng, trừ, nhân và chia cho hai phân số, cũng như các phép toán tương tự với n (n > 0).
Trong bài viết này, chúng ta sẽ thảo luận về phân số và vấn đề không được đề cập trong đặc tả, liên quan đến lỗi ứng với điều kiện 3 Khi thực hiện phép nhân hai phân số 3/10 và 100/9, kết quả thu được là một giá trị cụ thể.
Kết quả mong đợi của bài toán 300/90 là 10/3, mặc dù vấn đề này không được định nghĩa rõ ràng trong đặc tả, nhưng chương trình cần phải xử lý tình huống này một cách chính xác.
Lỗi này tương ứng với điều kiện 4
Lỗi ứng với điều kiện 5 xuất hiện khi người dùng thử nghiệm chương trình và cảm thấy không hài lòng, bất kể lý do là gì Ví dụ, một số người có thể cho rằng màu sắc hiển thị phân số khó nhìn hoặc các nút bấm quá nhỏ và khó sử dụng Mỗi người dùng có cách nhìn nhận khác nhau về chương trình, do đó việc đáp ứng tất cả các yêu cầu là rất khó khăn Tuy nhiên, khi tiến hành thử nghiệm, cần luôn lưu ý đến các lỗi liên quan đến điều kiện 5 để đưa ra những lựa chọn hợp lý nhất.
Trong nghiên cứu về tính khả tin cậy của hệ thống, ba khái niệm quan trọng là sai sót, lỗi và thất bại được sử dụng để thể hiện mức độ ảnh hưởng của lỗi đối với phần mềm.
Sai sót trong phát triển phần mềm là những nhầm lẫn hoặc hiểu sai của các thành viên tham gia, bao gồm nhà phân tích, nhà thiết kế, lập trình viên và kiểm thử viên Những sai sót này có thể xảy ra trong bất kỳ giai đoạn nào của quá trình phát triển, ví dụ như khi người thiết kế hiểu nhầm một khái niệm hoặc khi lập trình viên gõ nhầm câu lệnh hay toán tử.
Lỗi phần mềm thường xuất hiện do sai sót trong quá trình phân tích, thiết kế hoặc lập trình, dẫn đến những hoạt động không đúng yêu cầu Khi sai sót được kích hoạt, nó sẽ tạo ra lỗi trong quá trình thực thi chương trình, ví dụ như khi người dùng gặp thông báo lỗi trong quá trình sử dụng.
Thất bại trong một chương trình xảy ra khi có lỗi xuất hiện, dẫn đến việc chương trình không hoạt động hoặc cho kết quả không như mong đợi Lỗi chính là nguyên nhân gây ra sự thất bại, và khi điều này xảy ra, chương trình sẽ không thể tiếp tục hoạt động.
Quan hệ giữa các khái niệm trên được minh hoạ trong Hình 1.1
Sai sót Lỗi Thất bại Hình 1.1 Quan hệ giữa sai sót, lỗi và thất bại
Trong nghiên cứu độ tin cậy của phần mềm, các khái niệm được phân biệt rõ ràng, đặc biệt là đối với phần mềm quan trọng (critical software) Những phần mềm này, như phần mềm điều khiển tàu điện ngầm hay tên lửa, có thể gây ra hậu quả nghiêm trọng và nguy hiểm nếu xảy ra lỗi.
Chúng ta chú trọng vào việc nhận diện các lỗi để giảm thiểu các thất bại có thể xảy ra Để không làm giảm tính sư phạm của tài liệu, chúng tôi sẽ sử dụng linh hoạt các khái niệm lỗi và sai sót trong nội dung này.
Trong quá trình lập trình, có nhiều loại lỗi có thể ảnh hưởng đến phần mềm, và việc phân loại chúng một cách chính xác là điều khó khăn Tuy nhiên, tài liệu này sẽ phân loại sáu lớp lỗi cơ bản mà các nhà phát triển thường gặp phải.
-Lỗi tính toán : lỗi ở các biểu thức tính toán Ví dụ, tồn tại câu lệnh X - X + 10 thay vì X = X + 100
-Lỗi lô-gic : biểu diễn sai một điều kiện Ví dụ, biểu thức điều kiện a > b được sử dụng thay vì viết a < b
-Lỗi vào/ra : gồm tất cả các lỗi liên quan xử lí dữ liệu vào/ra, như định dạng sai, chuyển đổi sai kiểu các dữ liệu vào/ra
-Lỗi xứ lí dữ liệu : truy cập hay thao tác sai trên dữ liệu, như sử dụng sai một con trỏ, sử dụng vượt quá chì số mảng
-Lồi giao tiếp : lỗi về giao tiếp giữa các thành phần bên trong của phần mềm, chẳng hạn như truyền tham số không đúng, gọi hàm không đúng
Lỗi định nghĩa dữ liệu xảy ra khi dữ liệu được định nghĩa không chính xác Chẳng hạn, một dữ liệu có thể được định nghĩa là kiểu số thực, trong khi thực tế nó nên được định nghĩa là kiểu số nguyên.
Khái niệ m ki ể m th ử
Khái niệm kiểm thử lại thường bị hiểu sai, với những phát biểu như "kiểm thử là quy trình nhằm chỉ ra rằng không tồn tại lỗi trong phần mềm" hoặc "kiểm thử nhằm mục đích chỉ ra rằng phần mềm thực hiện đúng các chức năng mong đợi một cách đúng đắn" Điều này dẫn đến sự nhầm lẫn về mục tiêu thực sự của kiểm thử phần mềm.
Kiểm thử phần mềm là quy trình nhằm xác định rằng không có lỗi tồn tại trong sản phẩm Tuy nhiên, mục tiêu này không thể đạt được với tất cả phần mềm, vì thực tế không thể khẳng định một phần mềm, ngay cả khi đơn giản, hoàn toàn không chứa lỗi.
Kiểm thử phần mềm không chỉ nhằm xác nhận rằng các chức năng hoạt động đúng như mong đợi, mà còn phải nhận thức rằng vẫn có thể tồn tại lỗi Điều này đặc biệt đúng khi phần mềm thực hiện các chức năng không được chỉ định trong yêu cầu.
Kiểm thửđược định nghĩa bởi nhiều cách khác nhau, như :
Kiểm thử là quy trình đánh giá hệ thống hoặc thành phần bằng cách vận hành chúng dưới các điều kiện xác định, sau đó quan sát, ghi nhận kết quả và đưa ra nhận định về hiệu suất của hệ thống hoặc thành phần đó.
-Kiểm thử dược mô tả là các thủ tục được thực hiện nhằm đánh giá một vài mặt của phần mềm [4]
-Kiểm thửđược mô tảnhư là quy trình được sử dụng để phát hiện lỗi phần mềm, để xác định rằng phần mềm đạt được chất lượng đặt ra [4],
-Kiểm thử là quy trình thực thi chương trình với mục đích tìm thấy lỗi [2]
Kiểm thử phần mềm có nhiều định nghĩa khác nhau, nhưng nhìn chung đều xoay quanh hai nội dung chính: phát hiện lỗi và đánh giá chất lượng Định nghĩa của Myers cho rằng “kiểm thử là quy trình thực thi chương trình với mục đích tìm thấy lỗi” là một trong những định nghĩa đơn giản và thực tế nhất Tuy nhiên, định nghĩa này không hoàn toàn phù hợp trong mọi trường hợp, vì các kỹ thuật kiểm thử tĩnh như thẩm định, thanh tra và phân tích tĩnh có khả năng phát hiện lỗi cao mà không cần thực thi chương trình.
Quan niệm thông thường của lập trình viên cho rằng việc kiểm thử phát hiện lỗi là thành công, trong khi không phát hiện lỗi thì được coi là thất bại Tuy nhiên, theo định nghĩa của Myers, kiểm thử không phát hiện lỗi là không thành công, và ngược lại, phát hiện lỗi trong kiểm thử được xem là thành công Mục đích chính của kiểm thử là phát hiện lỗi, vì phần mềm hầu như luôn chứa lỗi Do đó, quan niệm về việc phát hiện lỗi có phải là thành công hay không phụ thuộc vào góc nhìn của lập trình viên hoặc kiểm thử viên.
Khi một người đến bệnh viện với cảm giác bệnh tật nhưng không được chẩn đoán đúng, việc khám và xét nghiệm được coi là thất bại, khiến người bệnh nghi ngờ khả năng của bác sĩ Ngược lại, nếu bệnh được phát hiện, quá trình khám và xét nghiệm được xem là thành công và bác sĩ sẽ tiến hành điều trị Tương tự, trong kiểm thử phần mềm, phần mềm cần kiểm thử có thể được ví như một người bệnh, với mục tiêu phát hiện lỗi và đảm bảo chất lượng.
Cần phân biệt rõ giữa hai hoạt động kiểm thử và gỡ rối (debugging) Kiểm thử nhằm phát hiện lỗi trong phần mềm, trong khi gỡ rối được tiến hành sau khi kiểm thử đã chỉ ra sự tồn tại của lỗi Quá trình gỡ rối bao gồm hai bước cơ bản.
-Xác định bàn chất lỗi và định vị lỗi trong chương trình ;
Kiểm thử phần mềm có vai trò quan trọng trong việc phát hiện lỗi, với giả định rằng lỗi luôn tồn tại trong phần mềm Việc phát hiện và sửa lỗi không chỉ giúp cải thiện chất lượng sản phẩm mà còn nâng cao độ tin cậy của phần mềm.
Các khái niệm cơ bản:
Trong mục này, chúng tôi sẽ trình bày một số các khái niệm cơ bản liên quan đến kiểm thử
Hoạt động kiểm thử nhằm phát hiện lỗi trong phần mềm thông qua hai phương pháp chính: phân tích tĩnh (không thực thi phần mềm) và xác định dữ liệu vào cần thiết cho việc thực thi Dữ liệu vào này được gọi là dữ liệu thử (DT - test data) và thường được ký hiệu bằng tập hợp Ví dụ, khi kiểm thử một chương trình tính tổng với các biến a, b và c kiểu số nguyên, chúng ta sẽ ký hiệu dữ liệu thử tương ứng.
DT1 - {a = 3, h = 10, c - 1} có nghĩa là chúng ta khởi gán các giá trị 3, 10 và 1 cho các biến tương ứng a,b và c để tạo ra dữ liệu thửđầu tiên
Tập dữ liệu thử (set of test data) là tập hợp các dữ liệu được tạo ra nhằm mục đích kiểm thử Để đưa tập dữ liệu vào chương trình, cần thực hiện một số thao tác như khởi động phần mềm, khởi gán tệp tin và lựa chọn các mục cần thiết để kích hoạt chức năng cần kiểm thử Dãy các thao tác này được gọi là kịch bản kiểm thử (test scenario).
Khi thực hiện kịch bản kiểm thử, phần mềm sẽ tạo ra một kết quả xác định, và sự thiếu vắng kết quả do các yếu tố không xác định như dừng bất thường hay vòng lặp vĩnh cửu cũng được coi là một kết quả Kết quả này cần được so sánh với kết quả mong đợi để đưa ra kết luận về quá trình kiểm thử Việc đánh giá kết quả kiểm thử rất quan trọng và đôi khi còn khó khăn hơn việc tạo ra dữ liệu thử Đánh giá có thể được thực hiện tự động qua công cụ hoặc thủ công bởi con người, được gọi là phán xét kiểm thử Ví dụ, để kiểm tra tính đúng đắn của nghiệm trong một phương trình bậc nhất, chúng ta sẽ thay thế nghiệm vào chương trình để xác minh.
Phán xét kiểm thử là tài liệu hoặc chương trình giúp kiểm thử viên đánh giá xem một phép kiểm thử có thành công hay thất bại.
Nếu phán xét kiểm thử được coi là một tài liệu như đặc tả hoặc thiết kế, thì việc xác định kết quả kiểm thử cần phải được thực hiện thủ công thông qua quan sát của con người Trên thực tế, phán xét kiểm thử thường chỉ tồn tại dưới dạng tài liệu.
Trong trường hợp phán xét kiểm thử là một chương trình, kết quả kiểm thử có thể hoàn toàn tự động mà không cần can thiệp của con người Tuy nhiên, việc xây dựng một chương trình phán xét kiểm thử tin cậy lại rất phức tạp, thậm chí khó hơn cả việc phát triển chương trình cần kiểm thử Phán xét kiểm thử là một trong những yếu tố khó khăn trong quy trình kiểm thử Mặc dù tài liệu phán xét kiểm thử có thể dễ dàng được xây dựng dựa trên đặc tả và thiết kế, nhưng hiệu quả của nó lại thấp và cản trở tự động hóa quy trình kiểm thử do yêu cầu can thiệp thủ công Ngược lại, chương trình phán xét kiểm thử có độ chính xác cao hơn và cho phép tự động hóa quy trình, nhưng việc xây dựng nó lại tốn kém và khó khăn Tài liệu này sẽ không đi sâu vào việc xây dựng và sử dụng phán xét kiểm thử.
Các bướ c ki ể m th ử
Để kiểm thử một chương trình, kiểm thử viên phải thực hiện các bước cơ bản khác nhau Các bước này được giải thích chi tiết ở dưới đây
Lập kế hoạch kiểm thử là bước quan trọng giúp xác định mục tiêu, đối tượng và kỹ thuật kiểm thử, cũng như phân bổ nguồn tài nguyên và lịch trình kiểm thử Một kế hoạch kiểm thử hiệu quả không chỉ giảm chi phí mà còn cải thiện mối quan hệ với lập trình viên, đồng thời nâng cao chất lượng kiểm thử.
-Thi ế t k ế ca ki ể m th ử: Như đã trình bày ở trên, một ca kiểm thử bao gồm dữ liêu thử, điều kiện thực thi và kết quả mong đợi
Thiết kế dữ liệu thử là một hoạt động quan trọng trong quá trình kiểm thử phần mềm, được thực hiện dựa trên mục tiêu kiểm thử, kỹ thuật kiểm thử và đối tượng kiểm thử Các dữ liệu thử cần được xây dựng dựa trên đặc tả yêu cầu, thiết kế chương trình hoặc mã nguồn để đảm bảo khả năng phát hiện lỗi cao.
Xác định điều kiện thực thi là bước quan trọng trong quá trình kiểm thử, có thể đơn giản hoặc phức tạp tùy thuộc vào đối tượng cần kiểm thử Việc này giúp đảm bảo rằng các bước kiểm thử được thực hiện một cách chính xác và hiệu quả.
+ Xác định kết quảmong đợi : Cần xác định kết quả chúng ta mong đợi khi thực thi phần mềm với dữ liệu thử được thiết kế
Kiểm thử viên cần chuẩn bị môi trường để thực thi chương trình cần kiểm thử, sau đó thực hiện chương trình với các dữ liệu đã được thiết kế và ghi nhận kết quả thu được.
Phân tích kết quả kiểm thử và lập báo cáo là bước cuối cùng trong quy trình kiểm thử phần mềm Công việc này bao gồm việc so sánh kết quả thực thi chương trình với kết quả mong đợi, với độ phức tạp của so sánh phụ thuộc vào dữ liệu được quan sát và phân tích Sau khi hoàn thành bước này, phán xét kiểm thử sẽ được gán cho chương trình, với ba kết quả chính là: thành công, thất bại và chưa kết luận.
+ Nếu chương trình tạo ra kết quả khác với kết quả mong đợi thì phán xét thất bại được gán
Trong một số trường hợp, việc xác định thành công hay thất bại của chương trình trong quá trình kiểm thử có thể gặp khó khăn, đòi hỏi thực hiện thêm các kiểm thử khác để làm rõ kết quả Tại giai đoạn này, phán xét về kết quả chưa thể đưa ra conclusively Do đó, kiểm thử viên cần lập báo cáo lỗi và báo cáo kiểm thử để ghi nhận tình hình.
Báo cáo lỗi (bug report) cần được lập ngay sau khi phân tích lỗi, bao gồm thông tin về người xác định, thời gian, sản phẩm và phiên bản bị lỗi, mô tả lỗi, cách tái tạo, độ nghiêm trọng, trạng thái lỗi cùng các thông tin hỗ trợ sửa lỗi Trong khi đó, báo cáo kiểm thử (test report) tổng hợp kết quả kiểm thử, chỉ rõ những phần đã và chưa được kiểm thử, danh sách các lỗi phát hiện, cũng như lịch và thời gian kiểm thử thực tế.
Ki ể m ch ứng và hợ p th ức hóa
Để đảm bảo phần mềm được phát triển đúng cách và các thành phần của nó cũng được xây dựng một cách chính xác, chúng ta cần thực hiện kiểm chứng (verification) Tuy nhiên, phần mềm không chỉ cần đáp ứng yêu cầu của nhà sản xuất mà còn phải thỏa mãn nhu cầu của người sử dụng cuối cùng Quá trình đảm bảo phần mềm đáp ứng nhu cầu của người dùng được gọi là hợp thức hoá (validation).
Hợp thức hóa phần mềm phản ánh quan điểm của người sử dụng, trong khi kiểm chứng xác nhận quan điểm của nhà sản xuất Một phần mềm có thể đáp ứng nhu cầu người dùng nhưng không nhất thiết được sản xuất đúng cách Ngược lại, việc phát triển phần mềm tuân thủ quy trình sản xuất không đảm bảo rằng sản phẩm sẽ thỏa mãn nhu cầu người dùng Do đó, kiểm chứng và hợp thức hóa (v&v - Verification & Validation) hỗ trợ lẫn nhau để tạo ra sản phẩm phần mềm chất lượng cao.
Chúng ta có thể phân biệt hai khái niệm kiểm chứng và hợp thức hoá: Kiểm chứng tập trung vào việc xác định xem phần mềm đã được xây dựng đúng cách hay chưa, trong khi hợp thức hoá nhằm đánh giá chất lượng tổng thể của phần mềm đã được phát triển.
Mỗi chiến lược kiểm thử đều có thể áp dụng các kỹ thuật kiểm thử khác nhau, trong đó kỹ thuật kiểm thử chức năng thường được ưu tiên vì đây là yếu tố quan trọng đối với người sử dụng Để đảm bảo tính chính xác, cả kỹ thuật kiểm thử chức năng và kiểm thử cấu trúc đều có thể được sử dụng.
Khái niệ m ho ạt độ ng ki ể m th ử
Hoạt động kiểm thử hay mức kiểm thử là kế hoạch xác định mục tiêu và kỹ thuật cho các giai đoạn kiểm thử Quyết định về hoạt động kiểm thử thường dựa vào các yếu tố cụ thể.
-Tiêu chuẩn vầđộ tin cậy của phần mềm;
-Chi phí cho việc phát triển phần mềm
Trong quy trình phát triển phần mềm, các lập trình viên tạo ra những đơn vị độc lập nhỏ, sau đó phát triển và tích hợp chúng để đạt được sản phẩm cuối cùng theo yêu cầu khách hàng Chiến lược kiểm thử sẽ phụ thuộc vào kích thước của đối tượng kiểm thử và quan điểm của chúng ta về đối tượng đó.
Kiểm thử đơn vị (unit testing) là quá trình kiểm tra độc lập các thành phần phần mềm, như hàm, thủ tục hay lớp Hoạt động này chủ yếu do các lập trình viên thực hiện và tập trung vào từng đơn vị phần mềm Để thực hiện kiểm thử đơn vị, có thể áp dụng các kỹ thuật kiểm thử chức năng và kiểm thử cấu trúc.
Kiểm thử tích hợp (integration testing) là quá trình kiểm tra sự kết hợp của các thành phần phần mềm nhằm phát hiện lỗi giao tiếp giữa chúng Thường do lập trình viên hoặc kiểm thử viên thực hiện, kiểm thử tích hợp chủ yếu sử dụng các kỹ thuật kiểm thử chức năng Trong những trường hợp cần thiết, kỹ thuật kiểm thử cấu trúc cũng có thể được áp dụng, tuy nhiên sẽ làm tăng chi phí kiểm thử.
Sau khi hoàn tất kiểm thử tích hợp, giai đoạn tiếp theo là kiểm thử hệ thống, một quy trình quan trọng nhằm đảm bảo phần mềm hoạt động đúng yêu cầu và hầu hết các lỗi đã được phát hiện và sửa chữa Kiểm thử hệ thống thường diễn ra ở giai đoạn cuối của quy trình phát triển phần mềm và có thể bao gồm nhiều loại kiểm thử như kiểm thử chức năng, bảo mật, cấu hình, khả năng chịu tải, hiệu năng, độ tin cậy và tài liệu Giai đoạn này được thực hiện bởi các kiểm thử viên chuyên nghiệp để đảm bảo chất lượng sản phẩm trước khi chuyển giao cho người dùng.
Sau khi hoàn tất kiểm thử hệ thống, phần mềm sẽ được chuyển giao cho người sử dụng để thực hiện kiểm thử chấp nhận, nhằm đánh giá chất lượng thay vì tìm lỗi Kiểm thử chấp nhận cho phép người sử dụng định nghĩa các tiêu chí dựa trên mong đợi của họ Phần mềm thường trải qua bốn giai đoạn kiểm thử: kiểm thử đơn vị, kiểm thử tích hợp, kiểm thử hệ thống (do nhà phát triển thực hiện) và kiểm thử chấp nhận (do khách hàng thực hiện) Khi kiểm thử phát hiện lỗi, việc sửa lỗi có thể dẫn đến sự xuất hiện của các lỗi mới, do đó cần thực hiện kiểm thử hồi quy để đảm bảo không có lỗi mới xuất hiện Kiểm thử hồi quy được thực hiện khi có thay đổi trong hệ thống, nhằm đảm bảo rằng các thay đổi không tạo ra lỗi mới trong các thành phần không bị chỉnh sửa Kiểm thử hồi quy được coi là một giai đoạn con trong các loại kiểm thử khác.
Hình 1.3 Kiểm thử hồi quy ở các hoạt động kiểm thử khác nhau
Các nguyên tắ c ki ể m th ử
Nguyên tắc trong công nghệ phần mềm đóng vai trò quan trọng, hướng dẫn quy trình thiết kế, phát triển, kiểm thử và bảo trì phần mềm Kiểm thử, một lĩnh vực thiết yếu của công nghệ phần mềm, có các nguyên tắc riêng giúp kiểm thử viên xác định phương pháp kiểm tra và thực hiện công việc một cách chuyên nghiệp Bài viết này sẽ xem xét một số nguyên tắc cơ bản liên quan đến kiểm thử động, tức là kiểm thử yêu cầu thực thi phần mềm.
Nguyên t ắ c 1 : Kiểm thử là quy trình thực thi phần mềm và sử dụng các ca kiểm thửđể phát hiện lỗi
Mặc dù công nghệ phần mềm đã có nhiều cải tiến trong các phương pháp phát triển nhằm hạn chế và loại bỏ lỗi, nhưng lỗi vẫn xuất hiện và ảnh hưởng tiêu cực đến chất lượng phần mềm Kiểm thử viên cần xác định các lỗi này trước khi phần mềm được đưa vào sử dụng Định nghĩa về kiểm thử phần mềm là nguyên tắc mà kiểm thử viên phải tuân thủ, và không nên lập kế hoạch kiểm thử chỉ để chứng minh rằng lỗi không tồn tại.
Nguyên tắc 2 trong kiểm thử phần mềm nhấn mạnh rằng mục đích chính là phát hiện lỗi Một ca kiểm thử hiệu quả là ca kiểm thử có khả năng cao trong việc phát hiện những lỗi chưa được phát hiện trước đó.
Nguyên tắc này hướng dẫn cách đánh giá hiệu quả của một ca kiểm thử Trong quá trình thiết kế, kiểm thử viên cần xác định mục tiêu rõ ràng cho từng ca kiểm thử.
Kiểm thử phần mềm bao gồm các loại kiểm thử như kiểm thử đơn vị, kiểm thử tích hợp, kiểm thử hệ thống và kiểm thử chấp nhận để phát hiện các loại lỗi khác nhau Kiểm thử viên cần lựa chọn bộ dữ liệu thử nghiệm, kịch bản kiểm thử và thực hiện kiểm thử phần mềm Kết quả kiểm thử sẽ giúp kiểm thử viên xác định rõ ràng mục tiêu của ca kiểm thử.
Nguyên tắc 3 trong kiểm thử phần mềm nhấn mạnh rằng mỗi ca kiểm thử cần phải định nghĩa rõ ràng kết quả mong đợi Mặc dù dữ liệu thử là yếu tố quan trọng, nhưng nếu không xác định được kết quả mong đợi, ca kiểm thử sẽ trở nên vô nghĩa Điều này có thể dẫn đến tình trạng kết quả sai được coi là đúng, do tâm lý của nhà phát triển mong muốn có kết quả tích cực Việc định nghĩa kết quả mong đợi giúp kiểm thử viên phát hiện lỗi và đánh giá thành công hay thất bại của quá trình kiểm thử Do đó, việc xác định dữ liệu thử và kết quả tương ứng cần được thực hiện trong giai đoạn thiết kế ca kiểm thử.
Nguyên t ắ c 4 : Kiểm thử nên được thực hiện bởi một nhóm độc lập với nhóm phát triển
Việc các lập trình viên chấp nhận lỗi trong phần mềm do chính mình phát triển là một thách thức tâm lý lớn Họ thường khó khăn trong việc chuyển từ góc nhìn xây dựng sang góc nhìn kiểm tra, khiến cho việc tự kiểm thử trở nên kém hiệu quả Điều này xuất phát từ nỗi lo ngại về việc bị đánh giá thấp bởi đồng nghiệp hoặc cấp trên Ngoài khía cạnh tâm lý, sự hiểu lầm về đặc tả hay mô tả bài toán cũng có thể dẫn đến lỗi trong chương trình, và lập trình viên có thể mang theo sự hiểu không chính xác này vào quá trình kiểm thử Do đó, mặc dù lập trình viên có thể kiểm thử sản phẩm của mình, nhưng kiểm thử sẽ đạt hiệu quả cao hơn khi được thực hiện bởi những người khác.
Nguyên tắc 5: Kết quả kiểm thử cần được phân tích cẩn thận để đảm bảo phát hiện lỗi hiệu quả và tránh phát sinh lỗi mới Việc đánh giá không đúng có thể dẫn đến việc bỏ sót lỗi quan trọng.
Một lỗi bị bỏ qua hoặc coi nhẹ có thể dẫn đến việc kiểm thử không phát hiện ra lỗi, mặc dù thực tế lỗi vẫn tồn tại Kiểm thử sẽ tiếp tục dựa trên kết quả không chính xác đó, và lỗi có thể được phát hiện trong các bước kiểm thử sau Tuy nhiên, trong trường hợp này, việc định vị và sửa lỗi sẽ trở nên khó khăn hơn.
Một lỗi có thể bị nghi ngờ là tồn tại, nhưng thực tế lại không có Trong tình huống này, chúng ta có thể tiêu tốn nhiều thời gian và công sức để tìm kiếm và xác định lỗi Tuy nhiên, một phân tích tỉ mỉ kết quả kiểm thử sẽ chỉ ra rằng lỗi thực sự không tồn tại.
Nguyên tắc 6 : Các ca kiểm thử nên được thiết kế cho cả những dữ liệu vào hợp lệ và không hợp lệ
Kiểm thử phần mềm thường chỉ tập trung vào các tập dữ liệu đầu vào hợp lệ theo đúng đặc tả, nhưng thực tế cho thấy dữ liệu đầu vào có thể không hợp lệ vì nhiều lý do khác nhau Người dùng có thể hiểu sai hoặc thiếu thông tin về dữ liệu, và ngay cả khi có đầy đủ thông tin, họ vẫn có thể nhập sai dữ liệu Ngoài ra, các thiết bị cung cấp dữ liệu đầu vào cũng có thể gặp sự cố do các tác động hoặc điều kiện bất thường.
Sử dụng các ca kiểm thử với dữ liệu không hợp lệ có thể kích hoạt phần mềm theo cách không mong đợi, từ đó giúp phát hiện các hành vi bất thường Ngoài ra, việc thử nghiệm với dữ liệu không hợp lệ cũng cho phép đánh giá khả năng bền vững của phần mềm, tức là khả năng hoạt động của nó khi gặp sự kiện không lường trước.
Các ca kiểm thử sử dụng dữ liệu vào không hợp lệ thường hiệu quả hơn trong việc phát hiện lỗi so với các ca kiểm thử với dữ liệu vào hợp lệ.
Nguyên tắc 7: Các ca kiểm thử phải được tái sử dụng
Các ca kiểm thử cần được lưu giữ sau mỗi lần kiểm thử để phục vụ cho việc sửa lỗi phần mềm Sau khi sửa lỗi, phần mềm sẽ được kiểm thử lại hoặc thực hiện kiểm thử hồi quy Nếu không lưu giữ các ca kiểm thử, việc xây dựng lại sẽ rất tốn thời gian và có thể dẫn đến việc kiểm thử lại bị bỏ qua Do đó, kiểm thử lại thường không được thực hiện nghiêm túc như lần kiểm thử đầu tiên.
Nguyên tắc 8 cho rằng xác suất xuất hiện của các lỗi khác trong một đơn vị phần mềm tỉ lệ thuận với số lượng lỗi đã được phát hiện trong cùng đơn vị phần mềm đó Điều này nhấn mạnh tầm quan trọng của việc phát hiện và sửa chữa lỗi, vì mỗi lỗi được tìm thấy có thể chỉ ra sự tồn tại của nhiều lỗi tiềm ẩn khác.
Các khó khăn củ a ki ể m th ử
Khó khăn liên quan đến quy trình phát triể n ph ầ n m ề m
Quy trình phát triển phần mềm bao gồm các giai đoạn từ khảo sát, phân tích, thiết kế đến cài đặt và bảo trì Mỗi giai đoạn chuyển đổi thông tin từ mô hình thế giới thực thành phần mềm thực thi, nhưng quá trình này thường dẫn đến mất mát thông tin và xuất hiện lỗi Kiểm thử phần mềm gặp khó khăn do tính trừu tượng của đối tượng trong các giai đoạn chuyển đổi, và việc phát hiện lỗi ở giai đoạn cuối có thể khiến lập trình viên khó xác định nguyên nhân từ các giai đoạn trước.
Khó khăn về m ặ t con ng ườ i
Kiểm thử là một hoạt động quan trọng trong công nghệ phần mềm, nhưng mục đích của nó thường chưa được hiểu rõ bởi các chuyên gia Một phần nguyên nhân là do sự thiếu hụt trong đào tạo và sự quan tâm đến kiểm thử Các chuyên gia thường tập trung vào thiết kế và lập trình mà ít chú ý đến quy trình kiểm thử, dẫn đến việc kiểm thử chỉ được xem như giai đoạn cuối cùng để hợp thức hóa sản phẩm.
Kiểm thử phần mềm thường không được các nhà nghiên cứu chú trọng, dẫn đến nhiều lỗi nghiêm trọng xuất hiện từ giai đoạn đầu của quy trình phát triển, như đặc tả và thiết kế Các thống kê cho thấy rằng lỗi càng được phát hiện muộn trong quy trình phát triển thì càng khó khắc phục Do đó, nghiên cứu các phương pháp và công cụ phát triển thích ứng là rất cần thiết để giảm thiểu lỗi ngay từ những giai đoạn đầu.
Khó khăn về m ặt kĩ thuậ t
Khó khăn về mặt kỹ thuật là đặc trưng của hoạt động kiểm thử Từ năm 1931, nhà toán học Kurt Gôdel đã chứng minh sự tồn tại của các phát biểu không thể chứng minh là đúng hay sai, được gọi là vấn đề không giải quyết được (non-decidability) Một ví dụ điển hình là phát biểu "Câu này là sai"; nếu câu này đúng, thì nội dung của nó lại khẳng định rằng nó sai.
Liên quan đến hoạt động kiểm thử phần mềm, cần lưu ý rằng không có thuật toán tổng quát nào có khả năng chứng minh hoàn toàn tính đúng đắn của bất kỳ chương trình nào Điều này nhấn mạnh sự phức tạp và thách thức trong việc đảm bảo chất lượng phần mềm.
Kiểm thử phần mềm không chỉ bị giới hạn bởi các yếu tố định lượng như khả năng kiểm thử toàn bộ dữ liệu, độ phức tạp của mã nguồn và khó khăn trong việc xây dựng phán xét tự động, mà còn bị ảnh hưởng bởi các yếu tố định tính liên quan đến tính chất giải quyết của hệ thống.
K ế t lu ậ n
Chương này tổng quan về kiểm thử phần mềm, nhấn mạnh tầm quan trọng của nó trong phát triển phần mềm thông qua các ví dụ về thiệt hại do kiểm thử kém Khái niệm lỗi được giới thiệu, cùng với nhiều định nghĩa khác nhau về kiểm thử, tất cả đều tập trung vào việc phát hiện lỗi và nâng cao chất lượng phần mềm.
Trong lĩnh vực kiểm thử, nhiều khái niệm quan trọng như dữ liệu vào, dữ liệu thử, kịch bản kiểm thử, ca kiểm thử và phán xét kiểm thử đã được trình bày Các kĩ thuật kiểm thử được phân loại dựa trên cách thiết kế dữ liệu thử, và các hoạt động kiểm thử được phân biệt theo đối tượng kiểm thử và giai đoạn phát triển phần mềm Định hướng của kiểm thử viên được nhấn mạnh qua các nguyên tắc kiểm thử, cho thấy rằng kiểm thử là một hoạt động phức tạp, đòi hỏi sự chú trọng cao từ các chuyên gia công nghệ thông tin.
Trong các chương tiếp theo, chúng ta sẽ tiếp tục đề cập một cách chi tiết các vấn đềđã được giới thiệu trong chương này.
Câu hỏi và bài tập
1.Hãy phân biệt các khái niệm sai sót, lỗi và thất bại Cho ví dụ minh hoạ
2.Kiểm thử nhằm mục đích gì ?
3.Tại sao không thể kiểm thử vét cạn ?
4.Ca kiểm thử là gì ?
5.Phán xét kiểm thử là gì?
6 Tại sao phát hiện lỗi càng sớm trong quy trình phát triện phần mềm càng tốt ? 7.Phân biệt kiểm thử động và kiểm thử tỉnh?
8 Phân biệt kiểm thử chức năng và kiểm thử cấu trúc?
9 Trong quy trình kiểm thử, bước nào thưòng quan trọng nhất ? Tại sao ?
10 Phân biệt thuật ngữ kiểm chứng và hợp thức hoá?
11 Tại sao kiểm thử nên được thực hiện bởi nhóm độc lập với nhóm phát triển ?
12 Tại sao các ca kiểm thử nên được thiết kế cho cả những dữ liệu hợp lệ và dữ liệu không hợp lệ ?
KIẾM THỬ TRONG QUY TRÌNH PHÁT TRIỂN PHẦN MỀM
Chương này sẽ đi sâu vào vai trò của kiểm thử phần mềm trong quy trình phát triển, bắt đầu bằng việc giới thiệu các kỹ thuật kiểm thử Tiếp theo, những quy trình phát triển phần mềm phổ biến trong công nghệ phần mềm sẽ được nhắc đến Cuối cùng, chúng ta sẽ thảo luận về các hoạt động kiểm thử trong các quy trình phần mềm và các kỹ thuật kiểm thử liên quan.
Các kĩ thuậ t ki ể m th ử
S ự hi ệ u qu ả c ủa các kĩ thuậ t ki ể m th ử
Sự hiệu quả của các kỹ thuật kiểm thử cần được xem xét kỹ lưỡng do ảnh hưởng của nhiều yếu tố khác nhau Những yếu tố này có thể bao gồm môi trường kiểm thử, độ phức tạp của ứng dụng, và khả năng của đội ngũ kiểm thử.
- Kinh nghiệm của kiểm thử viên; Độ khó áp dụng của kĩ thuật và hiệu suất của nó (thời gian học/đào tạo, giá công cụ…);
- Loại lỗi được phát hiện, tần suất và độ nghiêm trọng của lỗi;
- Phương pháp phát triển đang sử dụng và giai đoạn áp dụng;
- Độ chính xác khi định vị lỗi;
Yếu tố độ chính xác trong việc định vị lỗi là rất quan trọng, không chỉ vì việc phát hiện lỗi mà còn vì khả năng xác định vị trí lỗi trong mã nguồn Các kỹ thuật kiểm thử cấu trúc có khả năng xác định chính xác vị trí gần lỗi, giúp giảm thời gian gỡ rối đáng kể Ngược lại, các kỹ thuật kiểm thử chức năng thường phát hiện lỗi nhưng mất nhiều thời gian để xác định vị trí, làm giảm hiệu quả của chúng Để đánh giá hiệu quả thực tế của một kỹ thuật kiểm thử, cần xem xét tất cả các yếu tố và thành phần liên quan Hơn nữa, cần lưu ý rằng lỗi do lập trình viên gây ra có thể thay đổi theo thời gian, với bản chất và tần suất lỗi thay đổi theo sự phát triển của công nghệ phần mềm.
Tỉ lệ phát hiện lỗi trong phát triển phần mềm đã được cải thiện đáng kể nhờ vào các công nghệ mới như đặc tả hình thức, hỗ trợ thiết kế, sinh mã nguồn tự động và kiểm tra kiểu Những công nghệ này giúp lập trình viên nhận diện và sửa chữa lỗi một cách hiệu quả hơn, chẳng hạn như việc biên dịch cảnh báo khi một biến chưa được khởi gán Nhờ đó, lập trình viên có xu hướng chú ý và khắc phục những lỗi này thường xuyên hơn.
Nếu một biến không được khởi gán, chỉ cần khởi gán bằng 0 Việc sửa lỗi này có thể dẫn đến các lỗi khác Do đó, việc tích hợp các kỹ thuật mới có thể thay đổi loại lỗi gặp phải Những lỗi này trở nên khó phát hiện hơn và yêu cầu các kỹ thuật kiểm thử phức tạp hơn Nghịch lý này không có nghĩa là việc tích hợp công cụ hay kỹ thuật mới là không tốt, nhưng chúng tôi muốn nhấn mạnh rằng chính sách công cụ hóa hoàn toàn không phải lúc nào cũng đảm bảo thành công trong kiểm thử.
Một sự đánh giá hiệu quả phát hiện lỗi của các kĩ thuật kiểm thử đề xuất trong [7] dựa trên sự phân loại các loại lỗi (Bẩng 2.2)
Bảng 2.2 chỉ ra khả năng phát hiện lỗi của các kỹ thuật kiểm thử, với các kỹ thuật kiểm thử cấu trúc có khả năng phát hiện cao các lỗi tính toán và logic, như biểu thức số học và điều kiện Tuy nhiên, bảng này không hoàn toàn thể hiện lợi ích của từng kỹ thuật, ví dụ như thẩm định mã nguồn rất hiệu quả trong việc phát hiện lỗi nhưng lại có chi phí cao.
Chúng ta có thể đánh giá hiệu quả của các kỹ thuật bằng cách so sánh số lượng lỗi đã được phát hiện với những lỗi chưa được phát hiện, giả sử chúng ta có khả năng ước lượng số lượng lỗi còn lại.
Số lỗi được phát hiện Tổng số lỗi
Tổng số lỗi được phát hiện sau giai đoạn kiểm thử không phản ánh số lỗi thực tế mà chỉ là kết quả từ việc áp dụng các kỹ thuật kiểm thử khác nhau Các thống kê từ các phương pháp kiểm thử cho phép chúng ta đánh giá tương đối tỷ lệ phát hiện lỗi, như thể hiện trong Bảng 2.3.
Kết quả này chỉ ra hiệu quả của các kỹ thuật kiểm thử và có thể được sử dụng làm tài liệu tham khảo Một kỹ thuật kiểm thử hiệu quả không chỉ đơn thuần là phát hiện lỗi mà còn cần nhận diện các lỗi thường xuyên xuất hiện và các lỗi nghiêm trọng.
M ục tiêu cùa các nhóm kĩ thuậ t ki ể m th ử
Các kĩ thuật kiêm thử tĩnh không thực thi mã chương trinh có thể được chia làm bốn nhóm khác nhau
Nhóm kỹ thuật kiểm thử tĩnh bao gồm các kỹ thuật thẩm định mã nguồn và thẩm định đặc tả, nhằm kiểm tra sự tuân thủ các nguyên tắc lập trình hoặc nguyên tắc đặc tả đã được thiết lập Ngoài ra, thẩm định mã nguồn còn giúp phát hiện những điểm khó hiểu và dấu hiệu lỗi trong phần mềm Chất lượng của các kỹ thuật này phụ thuộc nhiều vào năng lực của người thẩm định.
B ả ng 2.2 Hi ệ u qua phát hi ệ n l ỗi cùa các kĩ thuậ t ki ể m th ử
Phân tích tĩnh Chứng minh sự đúng đắn
Tính toán trung bình trung bình lớn lớn trung bình
Lô-gic trung bình trung bình lớn lớn trung bình
Xử lí dữ liệu lớn lớn trung bình hạn chế lớn
Giao tiếp lớn lớn hạn chế lớn trung bình Định nghĩa dữ liệu trung bình trung bình trung bình hạn chế trung bình
Bảng 2.3 Tỉ lệ phát hiện các loại lỗi
Kĩ thuật Tỉ lệ phát hiện
Chứng minh sự đúng đắn 0,50- 1,00
Nhóm kĩ thuật kiểm thử tĩnh thứ hai tập trung vào việc đánh giá độ lớn của một số chỉ số trong mã nguồn, bao gồm số dòng lệnh, số dữ liệu vào/ra và độ phức tạp Mục tiêu chính của các kĩ thuật này là so sánh các chỉ số của mã nguồn với các ngưỡng đã được thiết lập trước Các phương pháp phổ biến được sử dụng trong nhóm này bao gồm đánh giá độ phức tạp theo McCabe và Halstead.
Nhóm kỹ thuật kiểm thử tĩnh thứ ba bao gồm các phương pháp chứng minh tính đúng đắn của chương trình Mục tiêu chính của các kỹ thuật này không phải là xác minh, mà là chứng tỏ rằng chương trình hoặc thuật toán hoạt động đúng theo yêu cầu Khái niệm về tính đúng đắn phụ thuộc vào đặc tả của chương trình Việc chứng minh tính đúng đắn thường là những kỹ thuật phức tạp và thường chỉ được áp dụng cho các phần mềm yêu cầu độ tin cậy cao.
Nhóm kỹ thuật kiểm thử tĩnh thứ tư tập trung vào việc phân tích luồng dữ liệu và luồng điều khiển của chương trình để kiểm tra tính tuân thủ các đặc tính Các đặc tính này bao gồm việc xác định các biến được khai báo nhưng không được sử dụng và các biến bị gán giá trị liên tục hai lần mà không có sự sử dụng giữa hai lần gán.
Nhóm các kỹ thuật kiểm thử chức năng là những phương pháp phổ biến nhất trong kiểm thử phần mềm, nhằm trả lời câu hỏi quan trọng của kiểm thử viên: “Phần mềm có thực hiện đúng chức năng của nó hay không?” Mục tiêu chính của các kỹ thuật này là kiểm tra toàn bộ các điều kiện hoạt động của phần mềm hoặc đơn vị phần mềm theo những yêu cầu đã được xác định.
Mục tiêu chính của các kỹ thuật kiểm thử cấu trúc là đảm bảo bao phủ toàn bộ cấu trúc mã nguồn Sự bao phủ này có thể được đánh giá dựa trên nhiều tiêu chí khác nhau, bao gồm bao phủ các lệnh, các rẽ nhánh, các điều kiện và các lộ trình.
Mục tiêu của các nhóm kỹ thuật kiểm thử phần mềm thường khác nhau, và việc lựa chọn kỹ thuật kiểm thử phụ thuộc vào yêu cầu cụ thể và độ tin cậy cần thiết của phần mềm Các kỹ thuật này bổ sung cho nhau, giúp phát hiện nhiều loại lỗi khác nhau, từ đó nâng cao chất lượng phần mềm.
