Bài giảng được thiết kế dành cho sinh viên đại học ngành Công nghệ thông tin. Nội dung gồm có 5 chương, cung cấp cho người học những kiến thức như: Giới thiệu về kiểm thử; Kiểm thử trong quy trình phát triển phần mềm; Kiểm thử chức năng-Kiểm thử cấu trúc; Thiết kế các trường hợp kiểm thử;...Mời các bạn cùng tham khảo!
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 rằng phần mềm không hoạt động như mong đợi, dẫn đến việc thường xuyên xác định rằng phần mềm có lỗi Tuy nhiên, có nhiều thuật ngữ khác có thể được sử dụng để mô tả tình trạng này, chẳng hạn như thất bại, sai sót, có 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 định nghĩa một cách cụ thể hơn Lỗi phần mềm được xác định dựa trên khái niệm đặc tả, trong đó đặc tả là sự thống nhất giữa các nhà phát triển phần mềm hoặc giữa nhà phát triển và người sử dụng phần mềm.
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 cần thực hiện đúng các phép toán này; nếu không hiển thị kết quả hoặc hiển thị sai khi cộng hai phân số, đó 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ú như một tiến trình, vì điều này sẽ tốn bộ nhớ; nếu chương trình luôn ở chế độ thường trú khi kích hoạt, đó là lỗi theo điều kiện 2.
Khi kiểm tra, chúng ta nhận thấy ngoài 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 hai phân số, cũng như các phép toán cộng, trừ, nhân và chia với n (n > 0).
Vấn đề về phân số không được đề cập trong đặc tả, dẫn đến lỗi theo đ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à.
Kết quả mong đợi cho phép tính 300/90 là 10/3, mặc dù vấn đề này không được định nghĩa rõ ràng trong đặc tả Đây là một vấn đề mà chương trình cần thực hiện, và lỗi này tương ứng với điều kiện 4.
Lỗi ứng với điều kiện 5 thường xảy ra khi người dùng trải nghiệm chương trình và cảm thấy không hài lòng, dù lý do cụ thể 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 kích thướ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 của họ là điều không dễ dàng Tuy nhiên, khi tiến hành kiểm thử, cần chú ý đế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 trong nhóm, bao gồm người phân tích, 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 lập trình viên gõ nhầm câu lệnh hoặc toán tử.
Lỗi trong phần mềm thường phát sinh từ những sai sót trong quá trình phân tích, thiết kế hoặc lập trình Khi những sai sót này được kích hoạt, chúng dẫn đến việc phần mềm hoạt động không đúng yêu cầu Cụ thể, lỗi có thể xuất hiện khi chương trình được thực thi, ví dụ như khi người dùng nhận được thông báo lỗi trong quá trình sử dụng.
Thất bại là kết quả của một lỗi xảy ra, khiến cho chương trình không hoạt động đúng hoặc cho kết quả không như mong đợi Lỗi chính là nguyên nhân dẫn đến thất bại, và khi thất bại 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 lĩnh vực 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à liên quan đến phần mềm quan trọng (critical software) Những phần mềm này nếu xảy ra lỗi sẽ dẫn đến hậu quả nghiêm trọng, thậm chí nguy hiểm, như trong trường hợp các hệ thống điều khiển tàu điện ngầm hay tên lửa.
Chúng tôi tập trung vào việc nhận diện và hạn chế các lỗi để giảm thiểu thất bại có thể xảy ra Để không làm ảnh hưởng đến tính sư phạm của tài liệu, chúng tôi 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 lỗi ả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à một thách thức 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 có thể 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, ví dụ như việc định nghĩa một dữ liệu kiểu số thực trong khi nó thực sự 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 chính xác".
Kiểm thử phần mềm là quá trình xác định rằng không có lỗi trong phần mềm, nhưng mục tiêu này không thể đạt được cho tất cả các phần mềm Thực tế cho thấy, không thể khẳng định một phần mềm hoàn toàn không có lỗi, ngay cả với những chương trình đơn giản nhất.
Kiểm thử phần mềm không chỉ nhằm xác định xem phần mềm có thực hiện đúng các chức năng mong đợi hay không, mà còn có thể phát hiện ra các lỗi tồn tại ngay cả khi phần mềm thực hiện các chức năng không được đặc tả Do đó, kiểm thử có thể được định nghĩa theo nhiều cách khác nhau.
Kiểm thử là quy trình vận hành hệ thống hoặc thành phần trong các điều kiện xác định, nhằm quan sát, ghi nhận kết quả và đưa ra đánh giá 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ử phần mềm là quy trình nhằm phát hiện lỗi và đảm bảo rằng sản phẩm phần mềm đạt được tiêu chuẩn chất lượng đã đề ra.
-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, mặc dù có nhiều định nghĩa khác nhau, nhưng chủ yếu tập trung vào 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 cách tiếp cận đơn giản và thực tế Tuy nhiên, định nghĩa này có thể không phù hợp trong một số 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 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 kiểm thử phát hiện lỗi là thành công, trong khi không phát hiện lỗi 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 được coi là không thành công, và ngược lại, phát hiện lỗi trong quá trình kiểm thử là thành công Mục đích chính của kiểm thử là phát hiện lỗi, vì thực tế 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 là thành công hay thất bại 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ì cảm giác bị bệnh nhưng không được chẩn đoán đúng, việc khám và xét nghiệm được xem 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 sẽ được coi 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 bệnh nhân, và việc kiểm thử sẽ xác định tính hiệu quả của phần mềm đó.
Cần phân biệt 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 khi gỡ rối được thực hiện sau khi lỗi đã được phát hiện Quá trình gỡ rối bao gồm hai bước.
-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ó mục đích chính là phát hiện lỗi, với giả định rằng lỗi có thể tồn tại trong sản phẩm Việc phát hiện và sửa chữa các lỗi này sẽ góp phần nâng cao chất lượng tổng thể 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 và thực thi phần mềm với dữ liệu vào Dữ liệu vào được sử dụng trong quá trình kiểm thử đượ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 phục vụ cho việc 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, gán tệp tin và thực hiện các lựa chọn cần thiết để kích hoạt chức năng kiểm thử Tập hợp 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ẽ cho ra một kết quả xác định, bao gồm cả những trường hợp không có kết quả do các yếu tố không xác định như dừng bất thường hoặc vòng lặp vĩnh cửu Kết quả này được so sánh với kết quả mong đợi để rút ra kết luận về việc kiểm thử Việc đánh giá kết quả kiểm thử là rất quan trọng và đôi khi còn khó khăn hơn việc tạo dữ liệu thử Đánh giá có thể được thực hiện tự động bằng công cụ hoặc thủ công bởi con người, được gọi là phán xét kiểm thử (test oracle) Ví dụ, để kiểm tra tính đúng đắn của nghiệm phương trình bậc nhất, chúng ta thay thế nghiệm vào phương trình để xác nhận Phán xét kiểm thử giúp kiểm thử viên xác định xem một phép kiểm thử thành công hay thất bại.
Nếu phán xét kiểm thử được coi là tài liệu như đặc tả hoặc thiết kế, việc xác định kết quả kiểm thử sẽ 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.
Khi phán xét kiểm thử được xem như 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 không hề đơn giản và thường phức tạp hơn so với việc phát triển chính chương trình cần kiểm thử Việc xây dựng và sử dụng phán xét kiểm thử là một trong những thách thức lớn trong quy trình kiểm thử Dù tài liệu phán xét kiểm thử có thể dễ dàng được tạo ra từ đặc tả và thiết kế, nhưng hiệu quả của nó thường 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, nhưng việc xây dựng chúng lại rất khó khăn và tốn kém 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
Kế hoạch kiểm thử đóng vai trò quan trọng trong việc xác định mục tiêu, đối tượng, kỹ thuật và nguồn tài nguyên cho quá trình kiểm thử Một kế hoạch kiểm thử hiệu quả không chỉ giúp giảm chi phí mà còn cải thiện mối quan hệ với lập trình viên và 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 bước quan trọng trong quá trình kiểm thử phần mềm, tùy thuộc vào mục tiêu, kỹ thuật và đối tượng kiểm thử Các dữ liệu thử được xây dựng dựa trên yêu cầu, thiết kế chương trình hoặc mã nguồn, nhằm đảm bảo khả năng phát hiện lỗi cao nhất.
Việc xác định điều kiện thực thi là một 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 được kiểm tra.
+ 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 kiểm thử Sau đó, họ sẽ 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 chủ yếu là 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 việc so sánh phụ thuộc vào dữ liệu cần 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 phán xét 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 chương trình thành công hay thất bại trong quá trình kiểm thử có thể gặp khó khăn, yêu cầu thực hiện thêm các kiểm thử khác để làm rõ kết quả Khi chưa có phán xét cuối cùng, 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 lỗi, 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 lỗi, độ nghiêm trọng, trạng thái lỗi và 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ử, nêu rõ những gì đã 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, chúng ta cần thực hiện kiểm chứng (verification) các thành phần của nó Tuy nhiên, phần mềm không chỉ đơn thuần đáp ứng yêu cầu của nhà sản xuất; nó chỉ thực sự hữu ích khi đáp ứng nhu cầu của người sử dụng cuối cùng Quá trình đảm bảo phần mềm thỏa mãn 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 lại thể hiện quan điểm của nhà sản xuất Một phần mềm đáp ứng nhu cầu người dùng chưa chắc đã được sản xuất đúng cách, và việc phát triển phần mềm theo quy trình sản xuất không đảm bảo rằng nó sẽ thỏa mãn nhu cầu người sử dụng Do đó, việc 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 hóa như sau: Kiểm chứng nhằm trả lời câu hỏi "Chúng ta đã xây dựng tốt một phần mềm chưa?", trong khi hợp thức hóa nhằm trả lời câu hỏi "Chúng ta đã xây dựng một phần mềm tốt chưa?".
Mỗi chiến lược kiểm thử 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 do sự quan tâm chính của người dùng là các chức nă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 kiểm thử cho các giai đoạn khác nhau Quyết định về hoạt động kiểm thử thường dựa vào nhiều yếu tố khác nhau.
-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 các đơ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ử phụ thuộc vào kích thước và quan điểm về đối tượng được kiểm thử.
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 hoặc lớp Hoạt động này chủ yếu do các lập trình viên thực hiện và sử dụng cả kỹ thuật kiểm thử chức năng lẫn kiểm thử cấu trúc để đảm bảo chất lượng từng đơn vị phần mềm.
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 Hoạt động này thường được thực hiện bởi lập trình viên và kiểm thử viên, chủ yếu sử dụng các kỹ thuật kiểm thử chức năng Trong một số trường hợp cần thiết, có thể áp dụng các kỹ thuật kiểm thử cấu trúc, nhưng chi phí sẽ cao hơn.
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, nhằm đảm bảo phần mềm hoạt động đúng theo yêu cầu Đây là bước cuối trong quy trình phát triển, giúp phát hiện và sửa chữa lỗi trước khi bàn giao sản phẩm Kiểm thử hệ thống bao gồm nhiều loại 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 Quá trình này được thực hiện bởi đội ngũ kiểm thử viên chuyên nghiệp.
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 phần mềm dựa trên tiêu chí mà họ định nghĩa 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 phát hiện lỗi trong quá trình kiểm thử, việc sửa lỗi có thể dẫn đến sự xuất hiện của lỗi mới, do đó cần thực hiện kiểm thử hồi quy để đả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 là một giai đoạn quan trọng trong quy trình phát triển phần mềm, được thực hiện khi có sự thay đổi trong hệ thống.
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 cách xây dựng, phát triển, kiểm thử và bảo trì phần mềm Kiểm thử, một lĩnh vực chính trong công nghệ phần mềm, có các nguyên tắc riêng giúp kiểm thử viên 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 các 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 tiến bộ trong phát triển để giảm thiểu lỗi, nhưng lỗi vẫn thường 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 Kiểm thử phần mềm được định nghĩa 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 không có lỗi tồn tại.
Nguyên tắc 2: Mục đích của kiểm thử là phát hiện lỗi, vì vậy một ca kiểm thử hiệu quả là ca 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ử chấp nhận nhằm phát hiện các lỗi trong phần mềm Kiểm thử viên sẽ lựa chọn bộ dữ liệu, 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ử giúp kiểm thử viên xác định liệu mục tiêu của ca kiểm thử đã đạt được hay chưa.
Nguyên tắc 3: Một ca kiểm thử phải định nghĩa kết quả mong đợi Đối với kiểm thử viên, việc chứa dữ liệu thử là điều hiển nhiên, nhưng nếu bỏ qua kết quả mong đợi, ca kiểm thử sẽ không có giá trị Điều này có thể dẫn đến việc một kết quả sai được xem là đúng do tâm lý của người phát triển mong muốn có kết quả tốt Định nghĩa kết quả mong đợi giúp kiểm thử viên xác định lỗi và đánh giá sự thành công hay thất bại của kiểm thử Do đó, việc đặc tả dữ liệu thử và kết quả tương ứng cần được thực hiện trong quá trình 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 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 thử, dẫn đến việc kiểm thử không hiệu quả khi do chính họ thực hiện Nỗi lo ngại về sự đánh giá từ đồng nghiệp và cấp trên khiến họ có thể tránh tìm ra lỗi Bên cạnh đó, lỗi trong chương trình cũng có thể phát sinh từ sự hiểu không chính xác về đặc tả bài toán, điều này càng làm cho việc phát hiện lỗi trở nên khó khăn hơn Tuy nhiên, nguyên tắc này không có nghĩa là lập trình viên không thể kiểm thử phần mềm của mình, mà thực tế là 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: Phân tích kết quả kiểm thử một cách cẩn thận là rất quan trọng, vì việc này giúp phát hiện lỗi hiệu quả và ngăn chặn sự xuất hiện của các lỗi mới.
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 được lỗi, dù thực tế lỗi vẫn tồn tại Việc kiểm thử tiếp tục dựa trên kết quả không chính xác trước đó, và có thể trong các bước kiểm thử sau, lỗi sẽ được phát hiện Khi đó, 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ế thì nó 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, trong khi một phân tích tỉ mỉ kết quả kiểm thử sẽ cho thấy 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 vào hợp lệ theo đặc tả, nhưng thực tế cho thấy dữ liệ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ó thông tin đầy đủ, 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 cũng có thể gặp lỗi do các tác động hoặc điều kiện bất thường.
Sử dụng dữ liệu không hợp lệ trong các ca kiểm thử có thể kích hoạt phần mềm một cách không mong đợi, giúp phát hiện các hành vi bất thường Ngoài ra, việc này còn 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 phải các sự kiện không mong đợi.
Các ca kiểm thử sử dụng dữ liệu vào không hợp lệ thường có hiệu quả phát hiện lỗi cao hơn 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 lại các ca kiểm thử, việc xây dựng lại sẽ mất nhiều thời gian và có thể dẫn đến việc kiểm thử lại bị bỏ quên 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 nêu rõ 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 sẽ 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 có nghĩa là, khi số lượng lỗi đã được phát hiện tăng lên, khả năng tồn tại của các lỗi khác cũng sẽ gia tăng.
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 có thể dẫn đến mất mát thông tin và xuất hiện lỗi Khó khăn trong kiểm thử phần mềm xuất phát từ tính trừu tượng của đối tượng trong quá trình chuyển đổi, và các lỗi có thể xuất hiện từ những giai đoạn trước đó, khiến cho việc xác định nguyên nhân trở nên khó khăn.
Khó khăn v ề m ặ t con ng ườ i
Kiểm thử phần mềm là một hoạt động quan trọng nhưng thường bị xem nhẹ bởi các chuyên gia công nghệ thông tin Nguyên nhân một phần là do đào tạo chưa đầy đủ và phần khác là do thiếu sự quan tâm đến kiểm thử trong ngành công nghệ phần mềm Nhiều chuyên gia chỉ tập trung vào thiết kế và lập trình, trong khi kiểm thử thường bị coi là giai đoạn cuối cùng đơn giản nhằm hợp thức hóa sản phẩm.
Kiểm thử thường bị xem nhẹ trong nghiên cứu, 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ế Thống kê cho thấy rằng, lỗi xảy ra càng sớm thì càng khó phát hiện và 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ừ đầu quy trình phát triển.
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 đúng hay sai, được gọi là vấn đề không giải quyết được (non-decidability) Một ví dụ cổ điển là câ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 nó sai.
Trong lĩnh vực kiểm thử phần mềm, có một nguyên tắc quan trọng cần lưu ý: không có thuật toán tổng quát nào có khả năng chứng minh sự đúng đắn hoàn toàn của mọi chương trình.
Kiểm thử không chỉ bị giới hạn bởi các yếu tố định lượng như khả năng kiểm tra 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 cung cấp cái nhìn 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 lớn do thiếu kiểm thử hiệu quả 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 mục tiêu 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ử phần mềm, 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ử, trong khi 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 và đòi hỏi sự chú trọng 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ệ ?
CHƯƠNG 2 KIẾM THỬ TRONG QUY TRÌNH PHÁT TRIỂN PHẦN MỀM
Chương này sẽ trình bày vai trò quan trọng của kiểm thử trong quy trình phát triển phần mềm, bắt đầu bằng việc giới thiệu các kỹ thuật kiểm thử Tiếp theo, sẽ nhắc lại một số quy trình phát triển phần mềm phổ biến trong công nghệ phần mềm Cuối cùng, chúng tôi 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 cẩn thận do nhiều yếu tố có thể ảnh hưởng đến kết quả Những yếu tố này bao gồm: độ phức tạp của phần mềm, môi trường kiểm thử, 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;
Độ chính xác trong việc định vị lỗi là yếu tố quan trọng trong kiểm thử phần mềm, vì không chỉ phát hiện mà còn xác định vị trí lỗi là cần thiết Các kỹ thuật kiểm thử cấu trúc thường xác định chính xác vị trí lỗi trong mã nguồn, giúp giảm thời gian gỡ rối Ngược lại, kỹ thuật kiểm thử chức năng phát hiện lỗi nhưng thường tốn nhiều thời gian để định vị, làm giảm hiệu quả Để đánh giá hiệu quả của một kỹ thuật kiểm thử, cần xem xét tất cả các yếu tố liên quan, đồng thời nhận thức rằng bản chất và tần suất lỗi của lập trình viên có thể 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 cụ này giúp lập trình viên nhận diện và sửa lỗi hiệu quả hơn, chẳng hạn như việc biên dịch cảnh báo về biến chưa được khởi gán, từ đó nâng cao chất lượng mã nguồn và giảm thiểu sai sót trong quá trình phát triển.
Nếu một biến không được khởi gán, chỉ cần khởi gán bằng 0 Cách sửa lỗi này có thể dẫn đến các lỗi khác Việc tích hợp các kỹ thuật mới có thể thay đổi loại lỗi xảy ra, khiến chúng 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 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ử, trong đó 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 phản ánh 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 chi phí thực hiện lại 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 số lỗi còn 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 chưa được phát hiện.
Số lỗi được phát hiện Tổng số lỗi
Tổng số lỗi được xác định sau giai đoạn kiểm thử thông qua các kỹ thuật khác nhau, không phản ánh chính xác số lỗi thực tế Các thống kê từ các kỹ thuật kiểm thử cho phép chúng ta đánh giá 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 hiệu quả không chỉ đơn thuần phát hiện lỗi mà còn cần phát hiện những 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 đặt ra Ngoài ra, thẩm định mã nguồn và đặc tả 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 thẩm định viên.
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ố liên quan đến 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 của các kỹ thuật này là so sánh độ lớn của các đặc tính 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 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 tập trung vào việc chứng minh sự đúng đắn của chương trình, với mục tiêu không phải chỉ xác minh mà còn chứng tỏ rằng chương trình hoặc thuật toán hoạt động đúng theo đặc tả đã định Khái niệm đúng đắn phụ thuộc vào yêu cầu cụ thể của từng chương trình Các kỹ thuật chứng minh sự đúng đắn thường phức tạp và thường được áp dụng cho những 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 trong chương trình để xác định tính tuân thủ của các thuộc tính Các kỹ thuật này có thể kiểm tra các vấn đề như biến được khai báo nhưng không được sử dụng, hoặ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 của các kỹ thuật này là kiểm thử tất cả các điều kiện hoạt động của phần mềm hoặc đơn vị phần mềm theo đú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ể dựa trên nhiều tiêu chí khác nhau, bao gồm bao phủ các lệnh, bao phủ các nhánh, bao phủ các điều kiện và bao phủ 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 là khác nhau, tùy thuộc vào yêu cầu kiểm thử và độ tin cậy của phần mềm Việc lựa chọn kỹ thuật kiểm thử phù hợp giúp phát hiện các loại lỗi khác nhau, từ đó nâng cao chất lượng phần mềm Các kỹ thuật này bổ sung cho nhau, góp phần tạo ra sản phẩm phần mềm tốt nhất có thể.