TỔNG QUAN VỀ KIỂM THỬ
Các thuật ngữ và định nghĩa cơ bản về kiểm thử
Mục tiêu: Trình bày được tổng quan về kiểm thử phần mềm
Kỹ nghệ kiểm thử đã trải qua nhiều thập kỷ phát triển, dẫn đến sự không thống nhất và thiếu tương thích trong các thuật ngữ của tài liệu Cuốn sách này trình bày các thuật ngữ dựa trên tiêu chuẩn của IEEE (Viện Kỹ nghệ điện và điện tử), đồng thời lựa chọn cẩn thận các thuật ngữ tiếng Việt tương ứng.
Lỗi trong phát triển phần mềm là những vấn đề mà con người thường gặp phải, do khả năng mắc sai lầm của con người Khi lập trình viên mắc lỗi, những lỗi này được gọi là bug Lỗi có thể lan truyền, ví dụ như một lỗi trong xác định yêu cầu có thể dẫn đến sai sót trong thiết kế và tiếp tục gây ra lỗi khi lập trình theo thiết kế đó Như vậy, lỗi là nguyên nhân chính dẫn đến các sai sót trong quá trình phát triển phần mềm.
Sai (Fault) là kết quả của lỗi, thể hiện qua các biểu thức như chương trình, văn bản, sơ đồ dòng dữ liệu hay biểu đồ lớp Sai lầm thường khó phát hiện, đặc biệt khi nhà thiết kế bỏ sót thông tin trong quá trình thiết kế, dẫn đến thiếu sót cần thiết Sai về nhiệm vụ xảy ra khi thông tin nhập vào không chính xác, trong khi sai do bỏ quên xảy ra khi không nhập đủ thông tin, loại sai này thường khó phát hiện và sửa chữa hơn.
Thất bại xuất hiện khi có lỗi được thực thi, thường liên quan đến mã nguồn Cần phân biệt giữa các thất bại do lỗi nhiệm vụ và các lỗi bỏ quên, như trường hợp của virus Michaelangelo, chỉ hoạt động vào ngày 6/3 Việc khảo sát và phát hiện các lỗi thuộc cả hai loại này có thể giúp ngăn chặn nhiều thất bại.
Sự cố (Incident) xảy ra khi có một thất bại, có thể hiển thị rõ ràng hoặc không rõ ràng với người dùng hoặc người kiểm thử Sự cố là dấu hiệu liên kết với thất bại và giúp người dùng hoặc người kiểm thử nhận biết sự xuất hiện của vấn đề này.
Yêu cầu của khách hàng và đặc tả phần mềm là yếu tố then chốt trong quá trình phát triển sản phẩm Phần mềm được thiết kế dựa trên việc thu thập và phân tích nhu cầu của khách hàng, từ đó xác định các đặc trưng cần thiết Đặc tả phần mềm cung cấp mô tả chi tiết về yêu cầu và giao diện mà sản phẩm cần đáp ứng Tài liệu này là nền tảng cho đội ngũ phát triển, giúp đảm bảo sản phẩm hoạt động đúng như mong đợi Nếu sản phẩm không phù hợp với đặc tả, có thể dẫn đến thất bại, và những lỗi trong quá trình xây dựng đặc tả cần được chú ý để tránh bỏ sót yêu cầu quan trọng.
Kiểm chứng và thẩm định là hai khái niệm thường bị nhầm lẫn nhưng thực chất có ý nghĩa khác nhau Kiểm chứng (verification) đảm bảo sản phẩm phần mềm đáp ứng đúng các đặc tả, trong khi thẩm định (validation) xác định sản phẩm có đáp ứng yêu cầu của người dùng hay không Quy trình thực hiện kiểm chứng cần được thực hiện trước thẩm định để đảm bảo tính chính xác của đặc tả Việc này giúp tránh tình trạng không xác định được nguồn gốc lỗi khi phát hiện ra vấn đề sau khi thẩm định Do đó, thuật ngữ V&V (Verification & Validation) được sử dụng để nhấn mạnh tầm quan trọng của kiểm chứng trước thẩm định.
Chất lượng và độ tin cậy của phần mềm là hai yếu tố quan trọng trong việc đánh giá sản phẩm Chất lượng phần mềm được định nghĩa là sự đáp ứng các yêu cầu về chức năng, sự hoàn thiện, và các tiêu chuẩn đã được thiết lập, bao gồm tính đúng đắn, tính hiệu quả, độ tin cậy, và khả năng kiểm thử Độ tin cậy, cụ thể là xác suất phần mềm hoạt động mà không gặp sự cố trong một khoảng thời gian nhất định, là một yếu tố then chốt trong chất lượng phần mềm Thời gian trung bình để khắc phục sự cố cũng là một chỉ số quan trọng trong việc đánh giá độ tin cậy của sản phẩm Do đó, cần phân biệt rõ giữa độ tin cậy và chất lượng tổng thể, vì nhiều người kiểm thử thường nhầm lẫn hai khái niệm này.
Kiểm thử phần mềm liên quan chặt chẽ đến các khái niệm như lỗi, sai sót, thất bại và sự cố Mục đích chính của kiểm thử là phát hiện thất bại hoặc xác nhận rằng phần mềm hoạt động đúng đắn.
Kiểm thử phần mềm là yếu tố then chốt trong việc đảm bảo chất lượng cao cho sản phẩm phần mềm trong quá trình phát triển Qua chu trình “kiểm thử - tìm lỗi - sửa lỗi”, chất lượng sản phẩm sẽ được cải thiện đáng kể Bên cạnh đó, việc thực hiện kiểm thử hệ thống trước khi phát hành giúp đánh giá mức độ tốt của sản phẩm.
Kiểm thử phần mềm được coi là một quy trình kiểm chứng nhằm đánh giá và nâng cao chất lượng sản phẩm Quy trình này bao gồm hai công việc chính: phân tích tĩnh và phân tích động.
Phân tích tĩnh là quá trình khảo sát các tài liệu phát triển sản phẩm như đặc tả nhu cầu người dùng, mô hình phần mềm, hồ sơ thiết kế và mã nguồn Các phương pháp truyền thống bao gồm khảo sát đặc tả và mã nguồn cùng với tài liệu thiết kế Bài 4 sẽ giới thiệu các kỹ thuật khảo sát này Ngoài ra, có thể sử dụng các kỹ thuật phân tích hình thức như kiểm chứng mô hình và chứng minh định lý để đảm bảo tính đúng đắn của thiết kế và mã nguồn, tuy nhiên các kỹ thuật này khá phức tạp và không nằm trong phạm vi cuốn giáo trình Phân tích tĩnh không liên quan đến việc thực thi chương trình mà chỉ xem xét và lý giải các hành vi có thể xảy ra khi chương trình được thực thi, trong đó tối ưu hóa các chương trình dịch là một ví dụ điển hình.
Phân tích động là quá trình thực thi chương trình nhằm phát hiện những thất bại tiềm ẩn và quan sát hiệu suất hành vi Do không thể kiểm tra tất cả các dữ liệu đầu vào, việc chọn một tập con dữ liệu, gọi là “ca kiểm thử”, là rất quan trọng để tối ưu hóa khả năng phát hiện lỗi Việc lựa chọn này cần được thực hiện cẩn thận để đảm bảo xác suất phát hiện thất bại cao nhất Cùng với phân tích tĩnh, hai kỹ thuật này bổ sung cho nhau và cần được lặp lại thường xuyên trong quá trình kiểm thử, nhằm phát hiện và sửa lỗi sớm nhất có thể trong phát triển phần mềm.
Ca kiểm thử là một đơn vị kiểm tra phần mềm, được đặt tên và liên kết với một hành vi cụ thể của chương trình Mỗi ca kiểm thử bao gồm một tập hợp dữ liệu đầu vào và một chuỗi các giá trị đầu ra mong đợi, giúp đánh giá tính chính xác và hiệu quả của phần mềm.
Hình 1.1: Một vòng đời của việc kiểm thử.
Vòng đời kiểm thử theo mô hình thác nước cho thấy rằng lỗi có thể xuất hiện trong các giai đoạn như đặc tả yêu cầu, thiết kế và lập trình, dẫn đến sai sót lan truyền trong quá trình phát triển Nhà kiểm thử lỗi lạc đã chỉ ra rằng ba giai đoạn đầu là "đưa lỗi vào", giai đoạn kiểm thử nhằm tìm lỗi, và ba giai đoạn cuối là "khử lỗi" Quá trình sửa sai không chỉ là cơ hội để khắc phục mà còn có thể tạo ra lỗi mới, làm cho phần mềm từ đúng trở thành sai, cho thấy việc sửa sai có thể không hoàn chỉnh.
Ca kiểm thử
Kiểm thử phần mềm dựa trên phân tích động tập trung vào việc xác định các ca kiểm thử nhằm phát hiện lỗi tiềm ẩn trong hệ thống Để xây dựng ca kiểm thử, cần xác định đầu vào, bao gồm tiền điều kiện và dữ liệu đầu vào, cũng như đầu ra mong đợi, gồm hậu điều kiện và dữ liệu đầu ra thực tế Đầu ra thường bị bỏ qua do khó xác định Ví dụ, khi kiểm thử phần mềm tìm đường bay tối ưu, câu hỏi về đường đi tối ưu có nhiều câu trả lời khác nhau Câu trả lời lý thuyết phụ thuộc vào một "cây đũa thần" (oracle), trong khi câu trả lời thực tế, gọi là kiểm thử tham chiếu, dựa vào sự giám sát của các chuyên gia trong lĩnh vực ứng dụng phần mềm để đánh giá tính chấp nhận của dữ liệu đầu ra.
Hoạt động kiểm thử phần mềm bao gồm việc thiết lập các tiền điều kiện cần thiết, cung cấp các ca kiểm thử, quan sát dữ liệu đầu ra và so sánh chúng với các đầu ra mong đợi Quá trình này giúp phát hiện các lỗi và khiếm khuyết có thể xảy ra trong sản phẩm phần mềm.
Hình 1.2: Thông tin về một ca kiểm thử tiêu biểu
Hình 1.2 trình bày thông tin cơ bản về ca kiểm thử, nhằm hỗ trợ quản lý hiệu quả Mỗi ca kiểm thử cần có tên/chỉ số và lý do tồn tại, chẳng hạn như đặc tả nhu cầu Cần ghi lại lịch sử thực hiện, bao gồm ai thực hiện, thời gian, kết quả (thành công hoặc thất bại) và phiên bản phần mềm liên quan Đối với kiểm thử giao diện người dùng, cần bổ sung thông tin về trình tự nhập đầu vào Tóm lại, ca kiểm thử quan trọng không kém gì mã nguồn và cần được phát triển, kiểm tra, sử dụng, quản lý và lưu trữ một cách khoa học.
Mô tả bài toán kiểm thử qua biểu đồ venn
Kiểm thử chủ yếu tập trung vào hành vi của chương trình, phản ánh quan điểm về cấu trúc phổ biến mà các nhà phát triển hệ thống hoặc phần mềm thường áp dụng.
Sự khác biệt giữa quan điểm cấu trúc và hành vi trong kiểm thử phần mềm nằm ở chỗ cấu trúc tập trung vào "là cái gì", trong khi hành vi chú trọng vào "làm gì" Một trong những thách thức lớn đối với người kiểm thử là tài liệu cơ sở thường được soạn thảo cho các nhà phát triển, dẫn đến việc thông tin cấu trúc được ưu tiên hơn, trong khi thông tin hành vi lại bị xem nhẹ Để làm rõ hơn về kiểm thử, chúng ta sẽ phát triển một biểu đồ Venn đơn giản, với chi tiết sẽ được trình bày trong bài 3.
Hình 1.3: Các hành vi được cài đặt và được đặc tả
Trong vũ trụ hành vi của chương trình cần kiểm thử, việc xác định tập các ca kiểm thử hữu ích là rất quan trọng Cho một chương trình và đặc tả của nó, tập hợp S đại diện cho các hành vi được đặc tả, trong khi P là tập hợp các hành vi của chương trình Biểu đồ mô tả mối quan hệ giữa các hành vi lập trình và hành vi được đặc tả cho thấy các thách thức mà người kiểm thử phải đối mặt Nếu có hành vi được đặc tả nhưng không được lập trình, đó là sai sót bỏ quên Ngược lại, hành vi được lập trình nhưng không được đặc tả tương ứng với sai sót nhiệm vụ Tương giao giữa S và P thể hiện phần đúng đắn, bao gồm các hành vi đã được cài đặt và đặc tả, với tính đúng đắn chỉ có ý nghĩa trong bối cảnh tương đối giữa đặc tả và cài đặt.
Hình 1.4: Các hành vi được cài đặt, được đặc tả và được kiểm thử.
Vòng tròn T trong hình 1.4 đại diện cho các ca kiểm thử, trong khi tập hợp các hành vi của chương trình nằm trong vũ trụ chuyên đề đang được xem xét Mỗi ca kiểm thử xác định một hành vi, mặc dù thuật ngữ này có thể gây nhầm lẫn Mối quan hệ giữa S, P và T cho thấy có thể tồn tại các hành vi được mô tả nhưng không được kiểm thử (các miền 2 và 5), các hành vi được mô tả và kiểm thử (các miền 1 và 4), cùng với các ca kiểm thử tương ứng với các hành vi không được mô tả (các miền 3 và 7).
Trong quá trình kiểm thử, có thể phân loại hành vi thành các nhóm: hành vi không được kiểm thử (các miền 2 và 6), hành vi được lập trình và kiểm thử (các miền 1 và 3), và các ca kiểm thử cho hành vi không được lập trình (các miền 4 và 7) Việc xem xét tất cả các miền này là rất quan trọng để đảm bảo tính đầy đủ của quá trình kiểm thử Nếu có hành vi được đặc tả mà không có ca kiểm thử tương ứng, quá trình kiểm thử sẽ không đầy đủ Ngược lại, nếu có ca kiểm thử cho hành vi không được đặc tả, điều này có thể chỉ ra rằng đặc tả còn thiếu hoặc ca kiểm thử không đảm bảo Kinh nghiệm cho thấy, một người kiểm thử giỏi thường phát hiện ra các ca kiểm thử thuộc loại đầu, vì vậy sự tham gia của người kiểm thử trong giai đoạn khảo sát đặc tả và thiết kế là cần thiết.
Việc xác định các ca kiểm thử
Có hai phương pháp chính để xác định các ca kiểm thử: kiểm thử hàm (hay còn gọi là kiểm thử chức năng hoặc kiểm thử hộp đen) và kiểm thử cấu trúc (hay kiểm thử hộp trắng).
- white-box testing) Mỗi cách tiếp cận có phương pháp xác định ca kiểm thử khác nhau và được gọi chung là phương pháp kiểm thử.
Kiểm thử hàm dựa trên quan niệm rằng mọi chương trình là một hàm ánh xạ giá trị từ miền dữ liệu đầu vào sang miền dữ liệu đầu ra Khái niệm này được áp dụng trong kỹ thuật, coi các hệ thống như những hộp đen, dẫn đến thuật ngữ kiểm thử hộp đen, trong đó nội dung và cài đặt của hộp đen không cần được biết đến Chức năng của hộp đen được hiểu qua dữ liệu đầu vào và đầu ra Trong thực tế, chúng ta thường làm việc hiệu quả với kiến thức về hộp đen, điều này cũng là trung tâm của khái niệm định hướng đối tượng, nơi các đối tượng tương tác với nhau thông qua các phương thức có thể quan sát từ bên ngoài.
Hình 1.5: Một hộp đen kỹ thuật.
Kiểm thử hàm sử dụng đặc tả phần mềm để xác định các ca kiểm thử, mang lại hai lợi ích chính: các ca kiểm thử này độc lập với cách cài đặt phần mềm, cho phép chúng vẫn có hiệu lực khi cài đặt thay đổi, và chúng được phát triển song song, không phụ thuộc vào quá trình cài đặt hệ thống.
Cách tiếp cận này giúp rút ngắn thời gian phát triển dự án, tuy nhiên, nhược điểm là các ca kiểm thử hàm thường có thể chứa nhiều tính dư thừa.
Hình 1.6 trình bày kết quả từ các ca kiểm thử được xác định bởi các phương pháp kiểm thử hàm, trong đó phương pháp A cho thấy khả năng xác định một tập hợp ca kiểm thử lớn hơn so với các phương pháp khác.
B Lưu ý rằng đối với cả hai phương pháp, tập các ca kiểm thử đều chứa trọn trong tập các hành vi được đặc tả Do các phương pháp kiểm thử hàm đều dựa trên các hành vi đặc tả, các phương pháp này khó có thể xác định được các hành vi không được đặc tả Trong bài 5 ta sẽ so sánh các ca kiểm thử sinh bởi các phương pháp hàm khác nhau cho các ví dụ nêu trong bài 2
Hình 1.6: So sánh các phương pháp xác định các ca kiểm thử hàm
Trong bài viết này, chúng ta sẽ khám phá các phương pháp kiểm thử hàm chủ yếu, bao gồm phân tích giá trị biên, kiểm thử tính bền vững, phân tích trường hợp xấu nhất, kiểm thử giá trị đặc biệt, kiểm thử phân lớp tương đương của miền dữ liệu đầu vào và lớp tương đương của miền dữ liệu đầu ra, cùng với kiểm thử dựa trên bảng quyết định Tất cả các kỹ thuật này đều dựa trên thông tin xác định về các thành phần cần kiểm thử.
4.2 Kiểm thử cấu trúc có thể mô tả chính xác các yêu cầu kiểm thử và hệ thống cần kiểm thử Do có cơ sở lý thuyết mạnh, kiểm thử cấu trúc cho phép định nghĩa chính xác và sử dụng các độ đo về độ bao phủ Các độ đo về độ phủ cho phép khẳng định tường minh phần mềm đã được kiểm thử tới mức nào và do đó giúp cho việc quản lý quá trình kiểm thử tốt hơn
Hình 1.7: xác định ca kiểm thử đối với kiểm thử cấu trúc.
Phương pháp kiểm thử cấu trúc A cho thấy số lượng ca kiểm thử lớn hơn so với phương pháp B, nhưng không chắc rằng số lượng ca kiểm thử nhiều hơn thì tốt hơn Cả hai phương pháp đều tạo ra các ca kiểm thử nằm trong tập các hành vi đã được lập trình, nhưng việc xác định lỗi liên quan đến các hành vi được mô tả nhưng chưa được lập trình là khá khó khăn Tập ca kiểm thử cấu trúc vẫn còn nhỏ so với tổng số hành vi lập trình So sánh giữa các phương pháp sẽ được thực hiện ở mục 1.4.3, trong khi các phương pháp kiểm thử cấu trúc như kiểm thử dòng điều khiển và kiểm thử dòng dữ liệu sẽ được trình bày chi tiết trong các chương tiếp theo.
4.3 Tranh luận về kiểm thử hàm so với kiểm thử cấu trúc
Khi so sánh hai phương pháp xác định ca kiểm thử, câu hỏi về phương pháp nào hiệu quả hơn vẫn chưa có lời giải thỏa đáng Robert Poston chỉ trích kiểm thử cấu trúc, cho rằng nó lãng phí thời gian của người kiểm thử và không hỗ trợ hiệu quả cho kiểm thử phần mềm từ những năm 1970 Ngược lại, Edward Miller bảo vệ kiểm thử cấu trúc, nhấn mạnh rằng độ bao phủ nhánh đạt 85% hoặc cao hơn có thể phát hiện gấp đôi số lỗi so với kiểm thử trực quan.
Hình 1.8: Nguồn các ca kiểm thử.
Biểu đồ Venn trong hình 1.8 giúp làm rõ cuộc tranh luận về hai cách tiếp cận kiểm thử Mục tiêu của cả hai phương pháp này là xác định các ca kiểm thử, với kiểm thử hàm dựa vào đặc tả và kiểm thử cấu trúc dựa vào mã nguồn Không có phương pháp nào hoàn hảo; kiểm thử cấu trúc không thể phát hiện các hành vi chưa được cài đặt, trong khi kiểm thử hàm không thể phát hiện các hành vi đã được cài đặt nhưng chưa được đặc tả, như trường hợp của virus Do đó, cả hai phương pháp đều cần thiết, và sự kết hợp hợp lý giữa chúng sẽ nâng cao độ tin cậy cho kiểm thử hàm và độ đo cho kiểm thử cấu trúc.
Kiểm thử hàm có thể gặp phải vấn đề về tính dư thừa và hố phân cách Tuy nhiên, nếu kiểm thử hàm được thực hiện cùng với các số đo độ phủ của kiểm thử cấu trúc, những khiếm khuyết này có thể được phát hiện và khắc phục hiệu quả.
Quan điểm biểu đồ Venn trong kiểm thử giúp làm rõ mối quan hệ giữa tập T các ca kiểm thử và các tập S, P đại diện cho hành vi cài đặt và đặc tả Điều này cho thấy sự tương tác và tương đồng giữa các yếu tố này, từ đó nâng cao hiệu quả của quá trình kiểm thử.
Các ca kiểm thử trong T được xác định bởi phương pháp xác định ca kiểm thử được sử dụng, và câu hỏi quan trọng là phương pháp này có phù hợp và hiệu quả hay không Để giải quyết vấn đề này, ta cần xem xét quá trình từ lỗi đến sai sót, thất bại và sự cố Việc nhận biết loại lỗi thường gặp và sai sót phổ biến trong phần mềm kiểm thử sẽ giúp lựa chọn phương pháp xác định ca kiểm thử phù hợp hơn Điều này chứng tỏ rằng kiểm thử không chỉ là một quy trình mà còn là một nghệ thuật.
Phân loại các lỗi và sai
Lỗi và sai được định nghĩa qua sự phân biệt giữa quy trình và sản phẩm; quy trình đề cập đến cách thức thực hiện, trong khi sản phẩm là kết quả cuối cùng Kiểm thử phần mềm và đảm bảo chất lượng phần mềm (SQA) đều nhằm cải thiện chất lượng sản phẩm thông qua việc cải tiến quy trình Kiểm thử tập trung vào việc phát hiện sai sót trong sản phẩm, trong khi SQA chú trọng đến việc giảm thiểu lỗi trong quá trình phát triển Cả hai đều dựa trên các định nghĩa về loại sai, được phân loại theo giai đoạn phát triển, hậu quả, độ khó giải quyết và mức độ rủi ro Một phương pháp phân loại phổ biến là dựa trên tần suất xuất hiện của lỗi: hiếm khi, thỉnh thoảng, hoặc lặp lại nhiều lần Hình 1.9 minh họa phân loại sai dựa trên mức độ nghiêm trọng của hậu quả.
2 Vừa Hiểu lầm hoặc thừa thông tin
3 Khó chịu Tên bị thiếu, cụt chữ hoặc hóa đơn có giá trị 0.0 đồng
4 Bực mình Vài giao dịch không được xử lý
5 Nghiêm trọng Mất giao dịch
6 Rất nghiêm trọng Xử lý giao dịch sai
7 Cực kỳ nghiêm trọng Lỗi rất nghiêm trọng xảy ra thường xuyên
8 Quá quắt Hủy hoại cơ sở dữ liệu
9 Thảm họa Hệ thống bị tắt
10 Dịch họa Thảm họa lây lan
Để xử lý các loại sai, tham khảo tiêu chuẩn IEE93 về phân loại bất thường phần mềm Chuẩn IEEE định nghĩa quy trình giải quyết bất thường qua bốn giai đoạn: nhận biết, khảo sát, hành động và bố trí lại Các bất thường phổ biến được mô tả trong các bảng từ Bảng 1.1 đến Bảng 1.5, hầu hết đều đã được đề cập trong chuẩn IEEE, cùng với một số bất thường bổ sung.
Các mức kiểm thử
Một trong những khái niệm quan trọng trong kiểm thử phần mềm là các mức độ kiểm thử Các mức này thể hiện mức độ trừu tượng trong mô hình thác nước của vòng đời phát triển phần mềm.
Bảng 1.1: Các sai lầm về đầu vào/đầu ra
Trong quá trình xử lý dữ liệu, có nhiều loại trường hợp có thể xảy ra, bao gồm dữ liệu đầu vào đúng nhưng không được chấp nhận, dữ liệu đầu vào sai nhưng lại được chấp nhận, mô tả sai hoặc thiếu tham số, cũng như dữ liệu đầu ra không chính xác Các lỗi có thể bao gồm khuôn dạng sai, kết quả sai, kết quả đúng nhưng tại thời gian không hợp lệ (quá sớm hoặc quá muộn), kết quả không đầy đủ hoặc thiếu, và kết quả giả tạo Ngoài ra, các lỗi về văn phạm và chính tả cũng có thể xuất hiện, dẫn đến những sai lầm về logic trong quá trình xử lý dữ liệu.
Mô hình thác nước, mặc dù có một số nhược điểm, vẫn rất hữu ích cho việc kiểm thử, giúp xác định các mức kiểm thử khác nhau và làm rõ mục đích của từng mức Hình 1.10 minh họa một dạng của mô hình này, nhấn mạnh sự tương ứng giữa kiểm thử và các mức thiết kế Theo thuật ngữ kiểm thử hàm, ba mức định nghĩa (đặc tả, thiết kế sơ bộ và thiết kế chi tiết) tương ứng trực tiếp với ba mức kiểm thử: kiểm thử đơn vị, kiểm thử tích hợp và kiểm thử hệ thống.
Bảng 1.3 liệt kê các sai lầm thường gặp trong tính toán thuật toán, bao gồm sai sót về toán hạng, sai dấu ngoặc, và thiếu độ chính xác do làm tròn hoặc cắt đuôi Ngoài ra, việc sử dụng hàm đi kèm không chính xác cũng là một nguyên nhân dẫn đến lỗi trong quá trình tính toán.
Bảng 1.4 liệt kê các sai lầm thường gặp trong giao diện xử lý gián đoạn của hệ thống nhúng, bao gồm thời gian vào ra không chính xác, gọi sai thủ tục hoặc gọi đến thủ tục không tồn tại, và các vấn đề liên quan đến tham số không tương thích như kiểu và số lượng Ngoài ra, kiểu không tương thích và bao hàm thừa cũng là những vấn đề cần lưu ý Các mức kiểm thử cũng đặt ra thách thức về thứ tự kiểm thử, có thể thực hiện theo phương pháp từ dưới lên, từ trên xuống hoặc các khả năng khác.
Các mức kiểm thử có thể được mô tả sơ bộ như sau:
Kiểm thử đơn vị là quá trình kiểm tra các đơn vị chương trình một cách độc lập, với đơn vị chương trình thường là một hàm hoặc phương thức có thể gọi từ bên ngoài và tương tác với các đơn vị khác Việc kiểm thử này giúp phát hiện lỗi nội tại và khắc phục trước khi tích hợp với các đơn vị khác Thông thường, kiểm thử đơn vị được thực hiện bởi chính tác giả chương trình và có thể chia thành hai giai đoạn: kiểm thử đơn vị tĩnh và kiểm thử đơn vị động Các lỗi phổ biến trong kiểm thử đơn vị bao gồm sai dữ liệu khởi tạo, truy cập sai giá trị chỉ số, sử dụng biến không đúng cách, và các vấn đề liên quan đến kiểu và phạm vi dữ liệu.
Hình 1.10: mức kiểm thử trong mô hình thác nước.
Kiểm thử tích hợp là bước tiếp theo sau kiểm thử đơn vị, nơi các đơn vị chương trình đã được kiểm thử sẽ được kết nối để tạo thành hệ thống hoàn chỉnh Quá trình này không đơn giản và có thể phát sinh lỗi giao diện giữa các đơn vị, do đó cần thực hiện kiểm thử để phát hiện những lỗi này Công đoạn này bao gồm hai giai đoạn: kiểm thử tích hợp và kiểm thử hệ thống Mục tiêu của kiểm thử tích hợp là đảm bảo hệ thống hoạt động ổn định trong môi trường thử nghiệm, chuẩn bị cho việc triển khai vào môi trường thực tế bằng cách kết nối các đơn vị theo phương pháp tăng dần.
Kiểm thử hệ thống là giai đoạn được thực hiện khi hệ thống đã hoàn chỉnh và tất cả các thành phần đã được tích hợp Mục tiêu chính của kiểm thử này là đảm bảo rằng cài đặt đáp ứng đầy đủ các yêu cầu của người dùng Quá trình kiểm thử này đòi hỏi nhiều công sức do có nhiều khía cạnh của yêu cầu người dùng cần được kiểm tra Kỹ thuật kiểm thử hàm trong bài 5 là phương pháp phù hợp nhất cho loại kiểm thử này.
Kiểm thử chấp nhận là giai đoạn quan trọng khi sản phẩm phần mềm đã được nhóm kiểm thử hệ thống xác nhận đạt yêu cầu Giai đoạn này được thực hiện bởi khách hàng để đảm bảo sản phẩm hoạt động đúng như mong đợi Có hai loại kiểm thử chấp nhận: kiểm thử chấp nhận người dùng do người dùng thực hiện và kiểm thử chấp nhận doanh nghiệp do nhà sản xuất thực hiện.
Bài tập của học viên
1: Trình bày mô tả bài toán kiểm thử qua biểu đồ venn
2: Nêu các mức kiểm thử
3: Hãy so sánh hai cách tiếp cận kiểm thử hàm và kiểm thử cấu trúc?
4: Phân loại các lỗi và sai
5 Hãy vẽ biểu đồ Venn phản ánh khẳng định: ta đã không làm cái mà lẽra ta cần phải làm, và làm cái mà lẽra ta không được làm
1: Trình bày mô tả bài toán kiểm thử qua biểu đồ venn, tham khảo mục 3 trong bài học trên
2: Nêu các mức kiểm thử, tham khảo mục 6 trong bài học trên
3: Hãy so sánh hai cách tiếp cận kiểm thử hàm và kiểm thử cấu trúc, tham khảo mục
4: Phân loại các lỗi và sai, tham khảo mục 5 trong bài học trên
5 Hãy vẽ biểu đồ Venn phản ánh khẳng định: ta đã không làm cái mà lẽra ta cần phải làm, và làm cái mà lẽ ra ta không được làm, tham khảo mục 3 trong bài học trên
Những trọng tâm cần chú ý
Trình bày đầy đủ nội dung của ca kiểm thử
Cần phải mô tả bài toán kiểm thử qua biểu đồ venn
Trình bày việc xác định các ca kiểm thử
Phân loại được đâu là lỗi và sai của chương trình
Bài mở rộng và nâng cao
Trong lĩnh vực phần mềm, có một câu chuyện về một nhân viên cáu kỉnh đã phát triển một chương trình quản lý lương, trong đó có chức năng kiểm tra số chứng minh thư của cán bộ và nhân viên Tuy nhiên, nếu nhân viên này bị sa thải, chương trình sẽ tự động tạo ra mã độc gây hại cho cơ quan Tình trạng này phản ánh những lỗi và sai sót trong quy trình phát triển phần mềm, đồng thời cho thấy sự cần thiết phải áp dụng các phương pháp kiểm thử phù hợp để ngăn chặn những thất bại tiềm ẩn và bảo vệ an toàn thông tin của tổ chức.
Yêu cầu đánh giá kết quả học tập
+ Trình bày đầy đủ nội dung của ca kiểm thử
+ Cần phải mô tả bài toán kiểm thử qua biểu đồ venn
+ Trình bày việc xác định các ca kiểm thử
+ Phân loại được đâu là lỗi và sai của chương trình
Năng lực tự chủ và trách nhiệm: Tỉ mỉ, cẩn thận, chính xác, linh hoạt và ngăn nắp trong công việc.
Về kiến thức: Đánh giá bằng hình thức kiểm tra viết, trắc nghiệm, vấn đáp
Về kỹ năng: Đánh giá kỹ năng xác định được ca kiểm thử thử hàm, kiểm thử cấu trúc
Năng lực tự chủ và trách nhiệm: Tỉ mỉ, cẩn thận, chính xác, linh hoạt và ngăn nắp trong công việc.
MỘT SỐ VÍ DỤ
Bài toán tam giác
Bài toán tam giác nhận ba số nguyên làm dữ liệu đầu vào, tương ứng với các cạnh của một tam giác Chương trình sẽ xác định loại tam giác dựa trên các số đo này, bao gồm: tam giác đều (Equilateral), tam giác cân (Isosceles), tam giác thường (Scalene), hoặc không phải là tam giác (NotATriangle) Ngoài ra, bài toán cũng có thể mở rộng để xác định thêm loại tam giác vuông (Right Triangle) Trong các bài tập, chúng ta sẽ sử dụng phiên bản mở rộng này.
Bài toán này phổ biến do nó thể hiện sự định nghĩa không đầy đủ, ảnh hưởng đến việc trao đổi thông tin giữa khách hàng, nhà phát triển và người kiểm thử Đặc tả giả định rằng nhà phát triển hiểu rõ về tam giác, đặc biệt là tính chất rằng tổng của hai cạnh bất kỳ phải lớn hơn cạnh còn lại Nếu a, b và c là ba cạnh của tam giác, thì điều này được diễn đạt qua ba bất đẳng thức a < b + c, b < a + c và c < a + b Nếu một trong ba bất đẳng thức không được thỏa mãn, a, b và c không tạo thành tam giác Tam giác đều xảy ra khi ba cạnh bằng nhau, tam giác cân khi có một cặp cạnh bằng nhau, và tam giác thường khi không có cặp nào bằng nhau Một người kiểm thử giỏi có thể làm rõ bài toán bằng cách đặt giới hạn cho độ dài các cạnh, ví dụ như yêu cầu các cạnh phải lớn hơn hoặc bằng 1 và giới hạn trên có thể là 20000.
Cài đặt truyền thống của ví dụ cổ điển này sử dụng kiểu tựa FORTRAN Tuy nhiên, chúng tôi đã chuyển đổi cài đặt sang ngôn ngữ C để đồng nhất với các ví dụ khác trong giáo trình Sơ đồ khối của ví dụ được thể hiện trong hình 2.1, với các số trong sơ đồ tương ứng với các chú giải trong chương trình Một cài đặt có cấu trúc hơn sẽ được trình bày trong mục 1.4.
Hình 2.1: Sơ đồ khối cho cài đặt chương trình tam giác truyền thống.
Biến match được sử dụng để ghi nhận sự bằng nhau giữa các cặp cạnh, giúp giảm số lượng so sánh cần thực hiện Nếu hai cạnh bằng nhau, ví dụ a = c, chỉ cần so sánh a + c với b, vì b > 0 và a + b > c sẽ luôn thỏa mãn Tuy nhiên, việc tối ưu hóa này có thể làm giảm tính rõ ràng và dễ kiểm thử của quá trình.
In the following chapters, we will explore the advantages of this version of the program by discussing its possible pathways The program begins by prompting the user to input three integers representing the sides of a triangle It then checks for equality among the sides to determine the type of triangle: scalene, isosceles, or equilateral If the sum of any two sides is less than or equal to the third side, it concludes that the input does not form a triangle The program effectively categorizes triangles based on user input, ensuring clarity and correctness in its output.
Lưu ý là có sáu cách để đi đến nút “Not A Triangle” (12.1 – 12.6) và có ba cách để đi đến nút “Isosceles” (15.1 – 15.3)
1.4 Cài đặt có cấu trúc
Hình 2.2: Sơ đồ dòng dữ liệu cho cài đặt có cấu trúc của chương trình tam giác.
Hình 2.2 mô tả sơ đồ dòng dữ liệu của chương trình tam giác, được cài đặt thông qua một chương trình chính và bốn thủ tục Để phục vụ cho việc kiểm thử đơn vị sau này, bốn thủ tục đã được tích hợp thành một chương trình C Các dòng chú giải liên kết mã nguồn với phần phân rã trong hình 2.2.
//Function 1: Get Input printf("Enter 3 integers being sides of a triangle\n"); printf("a = ");scanf("%d",&a); printf("b = "); scanf("%d",&b); printf("c = "); scanf("%d",&c); printf ("Side A is ", a, "\n"); printf ("Side B is ", b, "\n"); printf ("Side C is ", c, "\n");
//Function 3: Determine Triangle Type if(IsATriangle) if((a == b) && (b == c)) printf("Triangle is Equilateral"); else if((a != b) && (a != c) && (b != c)) printf("Triangle is Scalene"); else printf("Triangle is Isosceles"); else printf("Not a Triangle"); return 0;
Lưu ý: Function 4 và Output Controller đã được kết hợp thành các lệnh trong Function 3
Hàm NextDate (ngày kế tiếp)
Độ phức tạp của chương trình tam giác chủ yếu nằm ở các mối quan hệ giữa dữ liệu đầu vào và đầu ra Hàm NextDate minh họa một loại độ phức tạp khác, đó là mối quan hệ giữa các biến đầu vào.
Hàm NextDate nhận ba biến day, month và year, tương ứng với ngày, tháng và năm, và trả về ngày kế tiếp của ngày đầu vào Các giá trị của day, month và year phải thỏa mãn các điều kiện: 1 ≤ day ≤ 31, 1 ≤ month ≤ 12, và 1812 ≤ year ≤ 2021.
Độ phức tạp của hàm NextDate đến từ hai nguồn: các ràng buộc của dữ liệu đầu vào và quy tắc phân biệt giữa năm nhuận và năm không nhuận Trung bình, một năm có 365,2422 ngày, vì vậy năm nhuận được sử dụng để điều chỉnh ngày "vượt trội" Theo lịch Gregorian, một năm là nhuận nếu chia hết cho 4 nhưng không phải là năm thế kỷ, trong khi các năm thế kỷ chỉ là nhuận nếu chia hết cho 400 Ví dụ, các năm 1992, 1996 và 2000 là năm nhuận, nhưng năm 1900 không phải Hàm NextDate cũng phản ánh khía cạnh của kiểm thử phần mềm, khi mà 80% mã nguồn được dành cho các năm nhuận, tương ứng với quy luật Zipf về việc 80% hoạt động xảy ra trong 20% không gian.
2.3 Cài đặt int mai(){ typedef struct{ int day; int month; int year;
To calculate tomorrow's date based on today's input, prompt the user to enter the date in the format DD MM YYYY Store the current date in a variable and set tomorrow's date to be the same as today If today's month is January, March, May, July, August, or October, check if the day is less than 31; if so, increment tomorrow's day by one.
1; else{tomorrow.day = 1; tomorrow.month today.month + 1;
} if(today.month == 4 || today.month == 6 || today.month == 9 || today.month == 11) if(today.day < 30) tomorrow.day = today.day + 1; else{ tomorrow.day = 1; tomorrow.month today.month + 1;
} if(today.month == 12) if(today.day < 31) tomorrow.day = today.day + 1; else{ tomorrow.day = 1; tomorrow.month = 1; if(today.year == 2012) printf("2012 is over"); else tomorrow.year = today.year + 1;
} if(today.month == 2) if(today.day < 28) tomorrow.day = today.day + 1; else{ if(today.day == 28) if((today.year%4 == 0)&&(today.year%400 !0)) tomorrow.day = 29;//leap year else{ tomorrow.day := 1; tomorrow.month := 3;
} else if(today.day == 29){ tomorrow.day := 1; tomorrow.month := 3;
} else printf("Cannot have Feb.", today.day); printf("Tomorrow’s date is %3d %3d %5d", } tomorrow.day, tomorrow.month, tomorrow.year); return 0;
Hệ thống rút tiền tự động đơn giản
Để dễ dàng thảo luận về kiểm thử tích hợp và kiểm thử hệ thống, chúng ta cần một ví dụ có phạm vi lớn hơn, như hệ thống rút tiền tự động (ATM) Hệ thống này được mô tả trong [ADP93] và bao gồm nhiều chức năng và giao diện đa dạng Mặc dù nó đặc trưng cho các hệ thống thời gian thực, nhưng vẫn phù hợp với mục đích của chúng ta, vì các chuyên gia trong lĩnh vực thương mại điện tử cho rằng ngay cả các hệ thống COBOL truyền thống cũng gặp phải nhiều vấn đề tương tự liên quan đến hệ thống thời gian thực.
Hình 2.3: Trạm rút tiền ATM.
Hệ thống rút tiền tự động giao tiếp với các khách hàng của ngân hàng thông qua
Khách hàng có thể thực hiện ba loại giao dịch chính: gửi tiền, rút tiền và kiểm tra số dư tài khoản Các giao dịch này áp dụng cho hai loại tài khoản là tài khoản tiết kiệm và tài khoản vãng lai.
Hình 2.4: Các màn hình của máy ATM đơn giản
Khi khách hàng đến trạm rút tiền, màn hình đầu tiên sẽ xuất hiện Khách hàng sử dụng thẻ nhựa chứa mã số tài khoản cá nhân (PAN) để truy cập vào tệp tài khoản nội bộ Nếu PAN khớp với thông tin trong hệ thống, màn hình thứ hai sẽ được hiển thị Ngược lại, nếu PAN không tồn tại, màn hình thứ tư sẽ xuất hiện và thẻ sẽ bị giữ lại.
Trên màn hình 5, hệ thống cập nhật thông tin tài khoản khách hàng bằng cách thêm ngày hiện tại và tăng số lượng giao dịch ATM Khách hàng có thể chọn giao dịch mong muốn từ các tùy chọn trên màn hình 3 Ngay sau đó, hệ thống sẽ chuyển sang màn hình 6, nơi khách hàng có thể lựa chọn tài khoản để thực hiện giao dịch đã chọn.
Khi yêu cầu kiểm tra số dư, hệ thống sẽ kiểm tra tệp ATM địa phương để xác định các giao dịch chưa được gửi đi và kết hợp chúng với số dư ban đầu trong tệp tài khoản khách hàng của ngày hôm đó Kết quả sẽ được hiển thị trên màn hình 14.
Khi gửi tiền vào tài khoản, trạng thái của khe phong bì được xác định từ tệp điều khiển của trạm Nếu không có vấn đề, hệ thống hiển thị màn hình 7 để nhận tiền giao dịch Ngược lại, nếu có sự cố, màn hình 12 sẽ xuất hiện Sau khi tiền gửi được nạp, hệ thống chuyển sang màn hình 13 để chấp nhận và xử lý phong bì tiền gửi Số tiền gửi được ghi nhận từ tệp ATM địa phương, và số lần gửi trong tháng sẽ được tăng lên Cả hai thông tin này được xử lý bởi hệ ATM chủ một lần mỗi ngày, sau đó hệ thống sẽ hiển thị màn hình 14.
Khi khách hàng yêu cầu rút tiền từ tài khoản, hệ thống sẽ kiểm tra trạng thái của khe nhả tiền Nếu khe bị kẹt, màn hình 9 sẽ xuất hiện; nếu không, màn hình 7 cho phép khách hàng nhập số tiền muốn rút Sau khi nhập xong, hệ thống xác minh xem máy có đủ tiền để trả hay không Nếu không đủ, màn hình 9 sẽ hiển thị lại; nếu đủ, quá trình rút tiền sẽ được tiếp tục Hệ thống cũng kiểm tra số dư tài khoản của khách hàng, và nếu số dư không đủ, màn hình 8 sẽ được hiển thị Ngược lại, nếu số dư đủ, màn hình 11 sẽ xuất hiện và tiền sẽ được nhả ra Số tiền rút sẽ được ghi vào tệp ATM địa phương và số lần rút trong tháng sẽ được tăng lên Cuối cùng, số dư tài khoản sẽ được in ra trong sao kê, và sau khi khách hàng nhận tiền, màn hình 14 sẽ được hiển thị.
Khi khách hàng chọn nút No trên các màn hình 10, 12 hoặc 14, hệ thống sẽ chuyển sang màn hình 15 và trả lại thẻ ATM Sau khi khách hàng nhận thẻ, hệ thống sẽ quay lại màn hình 1 Ngược lại, nếu khách hàng chọn nút Yes trên các màn hình này, hệ thống sẽ hiển thị màn hình 5 để khách hàng có thể chọn các giao dịch khác.
Trong hệ thống vừa mô tả, một lượng thông tin quan trọng đã bị bỏ quên Chẳng hạn, ta có thể suy luận rằng trạm chỉ sử dụng tờ 10 ngàn đồng (xem màn hình 7) Định nghĩa bằng văn bản có thể chính xác hơn so với thực tế mà chúng ta gặp phải Ví dụ này thể hiện sự đơn giản nhưng có tính toán.
Có nhiều câu hỏi cần giải quyết liên quan đến các giả thiết về giới hạn cho vay và cách ngăn chặn khách hàng rút tiền vượt quá số dư thực tế của tài khoản tại các máy ATM khác nhau trong cùng một ngày Ngoài ra, cần xem xét các yếu tố khởi tạo như số tiền có trong máy và số lượng khách hàng mới gia nhập hệ thống Những vấn đề này cùng với nhiều chi tiết thực tế khác thường bị bỏ qua để đảm bảo tính đơn giản.
4 Bộ điều khiển gạt nước ô tô
Cần gạt nước ô tô trên xe Saturn năm 1992 được điều khiển thông qua một chốt và một núm vặn Chốt có bốn vị trí: OFF, INT (thỉnh thoảng), LOW và HIGH, trong khi núm vặn có ba vị trí được đánh số 1, 2 và 3, tương ứng với ba tốc độ chậm khác nhau Núm vặn chỉ hoạt động khi chốt ở vị trí INT Bảng 2.1 trình bày tốc độ của cần gạt tương ứng với các vị trí của chốt và núm vặn, trong đó giá trị n/a chỉ ra rằng trường hợp này không áp dụng.
Bảng 2.1: Tốc độ của cần gạt ứng với từng vị trí của chốt và núm vặn
Chốt OFF INT INT INT LOW HIGH
Bài tập của học viên
1 Xem lại sơ đồ khối của bài toán tam giác trong hình 2.1 Liệu biếnchương trình match có thể có: giá trị 4?, giá trị 5? Liệu có thể tiến hành dãy các khối 1, 2, 5, 6?
2 Nhắc lại lời bàn trong bài 1 về mối quan hệ giữa đặc tả và càiđặt của chương trình Nếu xem xét cẩn thận việc cài đặt của hàm NextDate, bạn sẽ thấy một vấn đề như sau Hãy nhìn vào lệnh CASE đối với các tháng có 30 ngày (4, 6,
Không có hành động đặc biệt nào cho trường hợp day = 31 Cần thảo luận về tính chính xác của cài đặt này Hãy xem xét lại cách xử lý cho trường hợp day ≥ 29 trong lệnh CASE liên quan đến tháng Hai.
3 Trong chương 1, ta đã nói rằng một bộ phận của ca kiểm thử là dữ liệuđầu ra mong đợi Đối với hàm NextDate bạn dùng cái gì làm dữ liệu đầu ra mong đợi cho các ca kiểm thử của ngày 31 tháng 6 năm 1812 (June 31, 1812)? Tại sao?
KIỂM THỬ HÀM
Tổng quan
Kiểm thử hàm (functional testing) là quá trình kiểm tra phần mềm dựa trên tài liệu mô tả chức năng, hay còn gọi là đặc tả chức năng Đặc tả chức năng định nghĩa yêu cầu và hành vi mong muốn của chương trình, từ đó là cơ sở để xây dựng các ca kiểm thử, một hoạt động quan trọng trong thiết kế kiểm thử Cần lưu ý rằng kiểm thử hàm chỉ dựa vào đặc tả mà không phân tích mã nguồn, do đó còn được gọi là kiểm thử dựa trên đặc tả, kiểm thử hộp đen hay kiểm thử chức năng Ngược lại, thiết kế kiểm thử dựa vào mã nguồn được gọi là kiểm thử cấu trúc hay kiểm thử hộp trắng.
Kiểm thử hàm là kỹ thuật quan trọng trong phát hiện lỗi mà kiểm thử hộp trắng có thể bỏ qua, đặc biệt là các lỗi cài đặt không đầy đủ so với đặc tả Trong trường hợp phần mềm thiếu hoàn toàn một chức năng, lỗi này dễ dàng nhận thấy Tuy nhiên, nếu phần mềm chỉ thiếu một trường hợp cụ thể của chức năng, việc phát hiện ra lỗi này sẽ khó khăn hơn nếu không kiểm tra kỹ lưỡng chương trình so với đặc tả.
Tài liệu đặc tả là cơ sở để thiết kế các ca kiểm thử, bao gồm mô tả chức năng của chương trình bằng ngôn ngữ dễ hiểu cho người sử dụng Thông thường, tài liệu này còn bao gồm các phân tích, thiết kế chi tiết hơn với hình vẽ, bảng biểu và sơ đồ, giúp làm rõ hành vi của chương trình Những tài liệu này phản ánh chính xác các tính chất hàm của chương trình, từ đó làm nền tảng cho việc thiết kế kiểm thử Tất cả các tài liệu này được gọi chung là đặc tả chức năng.
Kiểm thử hàm có ưu điểm nổi bật là có thể thực hiện sớm, ngay cả trước khi cài đặt chương trình, nhờ vào việc dựa trên đặc tả chức năng Thời điểm lý tưởng để bắt đầu thiết kế kiểm thử là khi tài liệu đặc tả đã ổn định Tuy nhiên, nhiều quy trình phần mềm hiện đại đang khuyến khích việc này diễn ra sớm hơn, ngay trong giai đoạn xác định yêu cầu, khi đã lồng ghép việc xác định các ca kiểm thử Các ca kiểm thử thường được mô tả dưới dạng ví dụ, không chỉ giúp làm rõ tài liệu đặc tả mà còn có thể được sử dụng làm kịch bản kiểm thử.
Kết quả của việc thiết kế kiểm thử hàm thường dẫn đến việc tạo ra đặc tả ca kiểm thử, tương tự như đặc tả chương trình mô tả chương trình mong muốn Đặc tả kiểm thử xác định các ca kiểm thử cần thiết để kiểm tra chương trình Từ một đặc tả ca kiểm thử, chúng ta có thể phát triển nhiều ca kiểm thử cụ thể Chẳng hạn, đối với hàm giải phương trình bậc hai với ba hệ số a, b, c, đặc tả ca kiểm thử cho nghiệm kép là khi b² = 4ac Từ đặc tả này, các ca kiểm thử cụ thể như a = 1, b = 2, c = 1 sẽ cho kết quả mong đợi là nghiệm kép -1.
Các đặc tả ca kiểm thử xác định các lớp hành vi của chương trình, do đó việc thiết kế kiểm thử hàm là phân tách các hành vi có thể của chương trình thành những lớp nhất quán hoặc tương tự Ví dụ, với hàm giải phương trình bậc hai, chúng ta có thể chia đặc tả thành các hành vi như nghiệm kép, kết quả vô nghiệm, và các trường hợp khác.
Việc phân tích đặc tả giúp xác định và phân tách các lớp thông tin, đồng thời phát hiện những điểm không rõ ràng và thiếu sót trong đặc tả Quá trình này tổng hợp thông tin từ nhiều nguồn, bao gồm đặc tả và kinh nghiệm của người thiết kế kiểm thử, nhưng cũng dễ mắc lỗi do tính thủ công Nhiều chuyên gia thiết kế kiểm thử có thể bỏ sót các ca kiểm thử quan trọng, vì vậy cần có phương pháp hệ thống để chia nhỏ quá trình thiết kế thành các bước cơ bản Một số bước có thể được tự động hóa để giảm thiểu sai sót và nâng cao chất lượng công việc, mặc dù hoàn toàn tự động hóa vẫn chưa khả thi và một số bước vẫn cần thực hiện thủ công Kỹ năng và kinh nghiệm của người thiết kế kiểm thử là yếu tố quyết định chất lượng bộ kiểm thử Để minh họa, giả sử chúng ta đang thiết kế kiểm thử cho chương trình P với đầu vào X và đầu ra Y, từ đó tính toán kết quả mong đợi Y dựa trên các giá trị cụ thể của vec-tơ đầu vào.
Để xác minh tính chính xác của chương trình, chúng ta cần so sánh kết quả mong đợi P(X) với kết quả thực tế Y Nếu P(X) và Y khớp nhau, điều đó có nghĩa là chương trình đã hoạt động chính xác với giá trị X Nếu chương trình hoạt động đúng với tất cả các giá trị X theo như đặc tả, chúng ta có thể kết luận rằng chương trình P đã được triển khai đúng theo yêu cầu.
1.1 Sự phức tạp của kiểm thử hàm Để hiểu sự phức tạp của kiểm thử hàm chúng ta xem một chương trình đơn giản Y
Hàm roots(X) được sử dụng để tính nghiệm của phương trình bậc hai với đầu vào là ba tham số a, b, c, và kết quả được gán cho hai biến root_one và root_two, tức là Y là cặp giá trị này Hàm này không trả về giá trị như một hàm toán học thông thường mà trả về void, nghĩa là kết quả được lấy từ hai biến toàn cục Do đó, khi xác định X và Y, chúng ta cần cẩn thận vì đầu vào a, b, c cũng có thể được truyền qua các biến toàn cục.
Để thiết kế kiểm thử cho hàm giải phương trình bậc hai, chúng ta cần xác định các bộ giá trị cho a, b, c, và tính toán kết quả mong đợi cho hai nghiệm bằng tay Sau đó, chương trình sẽ được chạy với các giá trị này và so sánh kết quả thu được với kết quả mong đợi Trong đoạn mã, chúng ta giả định rằng các biến a, b, c có kiểu double, nhưng nếu sử dụng kiểu số nguyên 32-bit, số lượng kết hợp có thể lên đến 2^23.
10 28 giá trị hợp lệ cho a, b, c Nếu giả sử chương trình chạy với tốc độ 1.000.000.000.000
(1 tỷ) ca kiểm thử mỗi giây thì chúng ta vẫn cần đến hơn 2.5 tỷ năm mới chạy xong (chính xác là 2,510,588,971 năm, 32 ngày, và 20 giờ)
Kiểm thử theo kiểu vét cạn giúp xác định chính xác tính đúng đắn của hàm, nhưng việc tính toán thủ công cho số lượng lớn kết quả mong đợi là không khả thi Ngay cả việc sử dụng máy tính cũng gặp khó khăn trong việc xử lý khối lượng tính toán lớn như vậy.
Một cách kiểm thử hàm roots hiệu quả là sử dụng các bộ giá trị ngẫu nhiên cho X Tuy nhiên, phương pháp này gặp khó khăn trong việc tạo ra các ca kiểm thử thỏa mãn điều kiện 2 − 4ac = 0 Bởi vì phân phối của các nghiệm, nghiệm kép và trường hợp không có nghiệm không đồng nhất, việc kiểm thử ngẫu nhiên có thể bỏ sót lỗi ở những tình huống đặc biệt Do đó, cần thiết phải áp dụng phương pháp kiểm thử tốt hơn để xử lý các trường hợp tổng quát.
Trước hết chúng ta hãy xem các công việc chính của thiết kế kiểm thử cho chương trình Y = P(X):
Để xây dựng mô hình, trước tiên cần xác định các biến đầu vào và đầu ra, cũng như miền giá trị của từng biến Cụ thể, chúng ta cần xác định các biến X và Y, trong đó X bao gồm các biến x₁, , xₙ và Y bao gồm các biến y₁, , yₘ Tiếp theo, chúng ta cần xác định miền giá trị của từng biến, tức là Dom(xᵢ) cho i = 1 n và Dom(yⱼ) cho j = 1 m, trong đó Dom(x) là tập hợp các giá trị mà biến x có thể nhận.
Chọn một số bộ giá trị của X làm ca kiểm thử và tính toán kết quả mong đợi tương ứng cho từng bộ giá trị đầu vào Với mỗi bộ giá trị đầu vào cụ thể, việc này giúp đảm bảo tính chính xác và độ tin cậy của hệ thống.
Để so sánh kết quả của chương trình P(a1,…,an) với Y = (b1,…,bm), chúng ta cần tính toán Y dựa trên đầu vào X = (a1,…,an) Việc tính toán này có thể trở nên phức tạp đối với những chương trình lớn Quy trình chọn bộ giá trị đầu vào thường dựa trên hiểu biết về miền dữ liệu, trong đó chúng ta thường sử dụng các giá trị đặc biệt và bình thường cho mỗi miền, sau đó kết hợp chúng lại với nhau.
Kiểm thử bằng bảng quyết định
Kỹ thuật kiểm thử lớp tương đương và kiểm thử giá trị biên là phương pháp hiệu quả cho các hàm với các biến đầu vào không có quan hệ ràng buộc Trong chương này, chúng ta sẽ tìm hiểu về kỹ thuật kiểm thử dựa trên bảng quyết định, phù hợp cho các hàm có hành vi khác nhau dựa trên tính chất của bộ giá trị đầu vào.
Kiểm thử dựa trên bảng quyết định là một trong những phương pháp chính xác nhất trong kỹ thuật kiểm thử chức năng Bảng quyết định giúp mô tả rõ ràng các điều kiện và hành vi xảy ra khi các điều kiện nhất định được thỏa mãn.
Cấu trúc bảng quyết định chia thành bốn phần chính như trong Hình 3.9:
• Các biểu thức điều kiện C1, C2, C3.
• Giá trị hành động, có (xảy ra) hay không, X là có
Khi xây dựng bảng quyết định, chúng ta cần xác định các điều kiện có thể xảy ra để phân tích các tổ hợp của chúng Từ đó, chúng ta sẽ xác định các ca kiểm thử tương ứng cho các điều kiện được thỏa mãn Hành động xảy ra sẽ là kết quả mong đợi của từng ca kiểm thử.
Bảng quyết định lôgic sử dụng các giá trị điều kiện T, F và – để biểu thị các quyết định Chúng ta có thể mở rộng các giá trị này bằng cách sử dụng các tập giá trị khác như 1, 2.
3, 4, khi đó chúng ta có bảng quyết định tổng quát
Bảng 3.10 minh họa một bảng quyết định đơn giản để xử lý sự cố máy in Khi gặp sự cố, chúng ta sẽ đánh giá tình trạng máy in dựa trên các điều kiện có trong bảng, xác định cột duy nhất thỏa mãn các điều kiện đó và thực hiện các biện pháp khắc phục tương ứng.
Bảng 3.9: Ví dụ bảng quyết định
Bảng 3.10 cung cấp hướng dẫn khắc phục sự cố máy in, với các điều kiện như máy in không in và đèn đỏ nhấp nháy Nếu máy in không in, cần kiểm tra dây nguồn Trong trường hợp máy không nhận ra, người dùng nên xác minh các kết nối và trạng thái của máy in để tìm ra nguyên nhân.
Kiểm tra cáp máy in X X Kiểm tra phần mềm in X X X X
Trong việc xây dựng bảng quyết định, thứ tự các điều kiện và hành động không quan trọng, cho phép chúng ta linh hoạt trong việc sắp xếp các hàng Tuy nhiên, để làm rõ hơn, có thể đánh số thứ tự cho các hành động thay vì sử dụng dấu X, nhằm chỉ ra hành động nào cần thực hiện trước Đối với bảng quyết định tổng quát, các giá trị của điều kiện không chỉ giới hạn ở đúng (T) hoặc sai (F), do đó cần tăng số cột để bao quát tất cả các tổ hợp có thể của các điều kiện.
Để xác định các ca kiểm thử từ bảng quyết định, cần chuyển đổi các điều kiện thành đầu vào và các hành động thành đầu ra Các điều kiện có thể xác định các lớp tương đương của đầu vào, trong khi các hành động tương ứng với các mô-đun xử lý chức năng đang được kiểm thử.
Bảng 3.11: Bảng quyết định cho Triangle Điều kiện 1 2 3 4 5 6 7 8 9 10 11 c1: a