Giáo trình kiểm thử phần mềm phần 1 - Phạm Ngọc Hùng, Trương Anh Hoàng, Đặng Văn Hưng

Giáo trình kiểm thử phần mềm phần 1 của Phạm Ngọc Hùng cung cấp nền tảng vững chắc về các phương pháp kiểm thử hiện đại và thực tiễn trong phát triển phần mềm.

• Tác giả: Phạm Ngọc Hùng
• Trường học: Đại học Công nghệ, Đại học Quốc gia Hà Nội
• Chuyên ngành: Công nghệ phần mềm
• Đề tài: Giáo trình kiểm thử phần mềm
• Loại tài liệu: Giáo trình
• Năm xuất bản: 2014
• Địa điểm: Hà Nội

Tóm tắt

I. Tổng quan giáo trình kiểm thử phần mềm Phạm Ngọc Hùng

Giáo trình kiểm thử phần mềm phần 1 của tác giả Phạm Ngọc Hùng, Trương Anh Hoàng và Đặng Văn Hưng được xuất bản tháng 1 năm 2014. Đây là tài liệu đào tạo quan trọng trong lĩnh vực đảm bảo chất lượng phần mềm tại Việt Nam. Giáo trình trình bày các kiến thức nền tảng về kiểm thử. Nội dung bao gồm tổng quan về kiểm thử, các ví dụ minh họa, cơ sở toán học rời rạc, khảo sát đặc tả và mã nguồn, cùng các kỹ thuật kiểm thử hàm. Mỗi chương được xây dựng có hệ thống. Từ lý thuyết đến thực hành. Người học được tiếp cận các khái niệm cơ bản như ca kiểm thử, kiểm thử hàm, kiểm thử cấu trúc. Giáo trình cũng giới thiệu cách phân loại lỗi và sai trong phần mềm. Các mức kiểm thử từ đơn vị đến hệ thống được giải thích rõ ràng. Với cấu trúc logic và ví dụ cụ thể, giáo trình trở thành tài liệu tham khảo hữu ích cho sinh viên và người làm nghề kiểm thử phần mềm.

1.1. Các thuật ngữ và định nghĩa cơ bản về kiểm thử

Giáo trình định nghĩa các thuật ngữ cốt lõi trong kiểm thử phần mềm. Ca kiểm thử là đơn vị cơ bản để đánh giá chất lượng sản phẩm. Khái niệm kiểm thử hàm xem chương trình như một hàm ánh xạ từ miền dữ liệu đầu vào sang đầu ra. Kiểm thử cấu trúc tập trung vào mã nguồn bên trong. Mối quan hệ giữa đặc tả và cài đặt được làm rõ qua biểu đồ Venn. Giáo trình phân biệt giữa lỗi (fault) và sai (failure). Mỗi thuật ngữ được giải thích kèm ví dụ minh họa. Cách tiếp cận hộp đen và hộp trắng được trình bày song song. Người học nắm vững nền tảng lý thuyết trước khi thực hành.

1.2. Các mức kiểm thử và phân loại lỗi phần mềm

Giáo trình trình bày các mức kiểm thử từ thấp đến cao. Kiểm thử đơn vị kiểm tra từng module riêng lẻ. Kiểm thử tích hợp đánh giá sự tương tác giữa các module. Kiểm thử hệ thống kiểm tra toàn bộ sản phẩm. Việc phân loại lỗi giúp xác định nguyên nhân gốc. Lỗi có thể xuất phát từ đặc tả, thiết kế hoặc lập trình. Mỗi loại lỗi yêu cầu phương pháp kiểm thử khác nhau. Giáo trình nhấn mạnh tầm quan trọng của việc phát hiện lỗi sớm. Chi phí sửa lỗi tăng theo giai đoạn phát triển. Do đó kiểm thử cần được thực hiện liên tục trong suốt vòng đời dự án.

II. Các vấn đề và thách thức trong kiểm thử phần mềm

Kiểm thử phần mềm đối mặt nhiều thách thức phức tạp. Một vấn đề lớn là xác định ca kiểm thử hiệu quả. Kiểm thử hàm dựa trên đặc tả nhưng có thể tạo ra nhiều ca kiểm thử dư thừa. Kiểm thử cấu trúc phụ thuộc vào mã nguồn, thay đổi khi cài đặt thay đổi. Cuộc tranh luận giữa hai phương pháp này kéo dài nhiều năm. Giáo trình của Phạm Ngọc Hùng phân tích ưu nhược điểm từng cách tiếp cận. Bài toán tam giác được dùng làm ví dụ điển hình. Nhiều chi tiết đời thực bị bỏ qua để đảm bảo tính đơn giản. Ví dụ như hệ thống ATM có nhiều câu hỏi về giới hạn giao dịch chưa được giải quyết đầy đủ. Bộ điều khiển gạt nước ô tô minh họa sự phức tạp của hệ thống thực. Việc mô tả đúng các điều kiện kiểm thử đòi hỏi sự tỉ mỉ. Người kiểm thử phải cân nhắc nhiều trường hợp biên. Các vấn đề về khởi tạo dữ liệu cũng cần được xem xét kỹ lưỡng.

2.1. Tranh luận giữa kiểm thử hàm và kiểm thử cấu trúc

Kiểm thử hàm xem phần mềm như hộp đen. Thông tin duy nhất là đặc tả của hệ thống. Các ca kiểm thử độc lập với cách cài đặt. Điều này giúp rút ngắn thời gian phát triển dự án. Tuy nhiên kiểm thử hàm thường có tính dư thừa cao. Kiểm thử cấu trúc tập trung vào mã nguồn bên trong. Phương pháp này đảm bảo kiểm tra được các đường dẫn chương trình. Nhưng ca kiểm thử thay đổi khi mã nguồn thay đổi. Giáo trình trình bày cả hai cách tiếp cận để người học tự đánh giá. Sự kết hợp hai phương pháp thường mang lại kết quả tốt nhất.

2.2. Xác định ca kiểm thử từ đặc tả phần mềm

Việc xác định ca kiểm thử là bước quan trọng trong quy trình kiểm thử. Với kiểm thử hàm, đặc tả là nguồn thông tin chính. Người kiểm thử phải phân tích từng chức năng của hệ thống. Bài toán NextDate minh họa cách xây dựng ca kiểm thử cho hàm ngày tháng. Bài toán tam giác đòi hỏi xem xét nhiều loại tam giác khác nhau. Giáo trình nhấn mạnh việc phát triển ca kiểm thử song song với cài đặt. Điều này giúp tiết kiệm thời gian và tăng hiệu quả. Mỗi ca kiểm thử cần được mô tả rõ ràng với đầu vào và đầu ra kỳ vọng. Việc ghi chép kết quả kiểm thử cũng rất quan trọng để theo dõi tiến độ.

III. Phương pháp và kỹ thuật kiểm thử hàm hiệu quả

Giáo trình giới thiệu nhiều kỹ thuật kiểm thử hàm chuyên sâu. Kiểm thử giá trị biên là phương pháp quan trọng đầu tiên. Kỹ thuật này tập trung vào các giá trị ở ranh giới miền dữ liệu. Kiểm thử lớp tương đương phân chia dữ liệu đầu vào thành các nhóm tương đương. Mỗi nhóm đại diện cho một tập hợp giá trị có hành vi giống nhau. Kiểm thử bằng bảng quyết định phù hợp với hệ thống có nhiều điều kiện phức tạp. Giáo trình trình bày cả kiểm thử giá trị biên mạnh và yếu. Kiểm thử tổ hợp xem xét sự kết hợp giữa các tham số đầu vào. Các ví dụ cụ thể như bài toán Triangle và NextDate minh họa rõ ràng. Người học được hướng dẫn cách áp dụng từng phương pháp. Giáo trình cũng chia sẻ kinh nghiệm thực tế khi triển khai các kỹ thuật này. Việc lựa chọn phương pháp phù hợp phụ thuộc vào đặc thù của từng dự án.

3.1. Kiểm thử giá trị biên và lớp tương đương

Kiểm thử giá trị biên tập trung vào các giá trị ở biên miền xác định. Ví dụ với bài toán tam giác, các giá trị như 0, 1, 200 được kiểm tra kỹ. Kiểm thử giá trị biên mạnh bao gồm cả giá trị ngay trên và ngay dưới biên. Kiểm thử lớp tương đương chia dữ liệu thành các lớp tương đương yếu và mạnh. Lớp tương đương yếu chỉ cần một giá trị đại diện cho mỗi lớp. Lớp tương đương mạnh yêu cầu kiểm tra nhiều giá trị hơn. Giáo trình minh họa qua bài toán NextDate với các tháng có 30 và 31 ngày. Việc áp dụng đúng kỹ thuật giúp giảm số ca kiểm thử mà vẫn đảm bảo chất lượng. Kinh nghiệm thực tế cho thấy kết hợp cả hai phương pháp mang lại hiệu quả cao nhất.

3.2. Kiểm thử bằng bảng quyết định và kiểm thử tổ hợp

Bảng quyết định là công cụ mạnh mẽ cho hệ thống phức tạp. Phương pháp này liệt kê tất cả điều kiện và hành động tương ứng. Giáo trình dùng ví dụ bộ điều khiển gạt nước ô tô để minh họa. Chốt có bốn vị trí và núm vặn có ba vị trí tạo thành nhiều tổ hợp. Kiểm thử tổ hợp xem xét sự kết hợp giữa các tham số. Kỹ thuật này hữu ích khi có nhiều biến đầu vào tương tác với nhau. Việc xây dựng bảng quyết định đòi hỏi sự cẩn thận và chính xác. Mỗi điều kiện phải được xác định rõ ràng. Giáo trình cung cấp hướng dẫn từng bước để áp dụng phương pháp này. Kết quả kiểm thử dễ đánh giá và tái sử dụng cho các dự án tương tự.

IV. Ứng dụng thực tiễn và giá trị giáo trình kiểm thử

Giáo trình kiểm thử phần mềm phần 1 của Phạm Ngọc Hùng có giá trị thực tiễn cao. Nội dung được áp dụng rộng rãi trong đào tạo đại học Việt Nam. Các bài toán minh họa gần gũi với thực tế phát triển phần mềm. Bài toán tam giác, NextDate, hệ thống ATM và bộ điều khiển gạt nước đều là những ví dụ điển hình. Giáo trình giúp sinh viên hiểu rõ quy trình kiểm thử từ lý thuyết đến thực hành. Các kỹ thuật như kiểm thử giá trị biên, lớp tương đương được trình bày có hệ thống. Cơ sở toán học rời rạc cung nền tảng vững chắc cho việc phân tích kiểm thử. Giáo trình cũng nhấn mạnh vai trò của khảo sát đặc tả và mã nguồn. Việc áp dụng các chuẩn và hướng dẫn lập trình giúp tăng chất lượng sản phẩm. Tài liệu này đóng góp quan trọng vào lĩnh vực đảm bảo chất lượng phần mềm tại Việt Nam. Nó giúp chuẩn bị đội ngũ kỹ sư kiểm thử chuyên nghiệp cho ngành công nghệ thông tin.

4.1. Áp dụng vào các bài toán thực tế trong đào tạo

Giáo trình sử dụng nhiều bài toán thực tế để minh họa lý thuyết. Bài toán tam giác là ví dụ kinh điển trong kiểm thử phần mềm. Người học phải xác định loại tam giác dựa trên ba cạnh đầu vào. Bài toán NextDate tính ngày kế tiếp, đòi hỏi xử lý nhiều trường hợp đặc biệt. Hệ thống ATM rút tiền đơn giản mô phỏng giao dịch ngân hàng thực tế. Bộ điều khiển gạt nước ô tô thể hiện hệ thống nhúng điển hình. Mỗi bài toán đều có phát biểu rõ ràng và cài đặt mẫu. Sinh viên được thực hành viết ca kiểm thử cho từng bài toán. Cách tiếp cận từ đơn giản đến phức tạp giúp người học tiến bộ dần. Giáo trình khuyến khích phát triển tư duy kiểm thử có hệ thống.

4.2. Giá trị của giáo trình trong đào tạo kiểm thử phần mềm

Giáo trình Phạm Ngọc Hùng là tài liệu chuẩn cho nhiều trường đại học. Nội dung bao quát từ cơ bản đến nâng cao về kiểm thử phần mềm. Cấu trúc chương logic giúp người học tiếp cận kiến thức theo trình tự hợp lý. Phần cơ sở toán học cung cấp công cụ phân tích mạnh mẽ. Các kỹ thuật kiểm thử hàm được trình bày chi tiết với ví dụ cụ thể. Giáo trình nhấn mạnh mối quan hệ giữa lý thuyết và thực hành. Người học không chỉ biết cách kiểm thử mà còn hiểu tại sao phải kiểm thử như vậy. Tài liệu này giúp xây dựng nền tảng vững chắc cho nghề kiểm thử chuyên nghiệp. Nó cũng phục vụ nghiên cứu và tham khảo trong các dự án phần mềm thực tế tại Việt Nam.

Trích đoạn nội dung tài liệu

CHƯƠNG 1. TỔNG QUAN VỀ KIỂM THỬ có thể dẫn đến sai lầm về thiết kế và càng sai khi lập trình theo thiết kế này. Lỗi là nguyên nhân dẫn đến sai. Sai (Fault): Sai là kết quả của lỗi, hay nói khác đi, lỗi sẽ dẫn đến sai.

Cũng có thể nói sai là một biểu diễn của lỗi dưới dạng một biểu thức, chẳng hạn chương trình, văn bản, sơ đồ dòng dữ liệu, biểu đồ lớp,. Sai lầm có thể khó bị phát hiện. Khi nhà thiết kế mắc lỗi bỏ sót trong quá trình thiết kế, sai kết quả từ lỗi đó là thiếu mất cái gì đó mà lẽ ra cần phải có. Sai về nhiệm vụ xuất hiện khi vào sai thông tin, còn sai về bỏ quên xuất hiện khi không vào đủ thông tin.

Loại sai thứ hai khó phát hiện và khó sửa hơn loại sai thứ nhất. Thất bại (Failure): Thất bại xuất hiện khi một lỗi được thực thi. Có hai điều cần lưu ý ở đây. Một là thất bại chỉ xuất hiện dưới dạng có thể chạy được mà thông thường là mã nguồn.

Hai là các thất bại chỉ liên kết với các lỗi về nhiệm vụ. Còn các thất bại tương ứng với các lỗi về bỏ quên thì xử lý thế nào? Những cái lỗi không bao giờ được tiến hành, hoặc không được tiến hành trong khoảng thời gian dài cần được xử lý thế nào? Virus Michaelangelo là một ví dụ về lỗi loại này. Nó chỉ được tiến hành vào ngày sinh của Michaelangelo, tức ngày 6/3 mà thôi. Việc khảo sát có thể ngăn chặn nhiều thất bại bằng cách tìm ra các lỗi thuộc cả hai loại.

Sự cố (Incident): Khi thất bại xuất hiện, nó có thể hiển thị hoặc không, tức là rõ ràng hoặc không rõ ràng đối với người dùng hoặc người kiểm thử. Sự cố là triệu chứng liên kết với một thất bại và thể hiện cho người dùng hoặc người kiểm thử về sự xuất hiện của thất bại này. Yêu cầu của khách hàng và đặc tả của phần mềm: Phần mềm được viết để thực hiện các nhu cầu của khách hàng. Các nhu cầu của khách hàng được thu thập, phân tích và khảo cứu và là cơ sở để quyết định chính xác các đặc trưng cần thiết mà sản phẩm phần mềm cần phải có.

Dựa trên yêu cầu của khách hàng và các yêu cầu bắt buộc khác, đặc tả được xây dựng để mô tả chính xác các yêu cầu mà sản phẩm phần mềm cần đáp ứng, và có giao diện thế nào. Tài liệu đặc tả là cơ sở để đội ngũ phát triển phần mềm xây dựng sản phẩm phần mềm. Khi nói đến thất bại trên đây là nói đến việc sản phẩm phần mềm không hoạt động đúng như đặc tả. Lỗi một khi được 1.

CÁC THUẬT NGỮ VÀ ĐỊNH NGHĨA CƠ BẢN VỀ KIỂM THỬ 3 tiến hành có thể dẫn đến thất bại. Do đó, lỗi về bỏ quên được coi là tương ứng với các lỗi khi xây dựng đặc tả. Kiểm chứng và thẩm định: Kiểm chứng (verification) và thẩm định (validation) hay được dùng lẫn lộn, nhưng thực ra chúng có ý nghĩa khác nhau. Kiểm chứng là quá trình để đảm bảo rằng một sản phẩm phần mềm thỏa mãn đặc tả của nó.

Còn thẩm định là quá trình để đảm bảo rằng sản phẩm đáp ứng được yêu cầu của người dùng (khách hàng). Trong thực tế, chúng ta cần thực hiện kiểm chứng trước khi thực hiện việc thẩm định sản phẩm phần mềm. Vì vậy, chúng ta có thuật ngữ V&V (Verification & Validation). Lý do của việc này là chúng ta cần đảm bảo sản phẩm đúng với đặc tả trước.

Nếu thực hiện việc thẩm định trước, một khi phát hiện ra lỗi, chúng ta không thể xác định được lỗi này do đặc tả sai hay do lập trình sai so với đặc tả. Chất lượng và độ tin cậy của phần mềm: Theo từ điển, chất lượng của một sản phẩm được thể hiện bằng các đặc trưng phù hợp với đặc tả của nó. Theo cách hiểu này, chất lượng của một sản phẩm phần mềm là sự đáp ứng các yêu cầu về chức năng (tức là các hàm cần được tính toán), sự hoàn thiện và các chuẩn đã được đặc tả, cùng các đặc trưng mong chờ từ mọi sản phẩm phần mềm chuyên nghiệp. Chất lượng phần mềm đặc trưng cho “độ tốt, độ tuyệt hảo” của phần mềm, và gồm có các yếu tố về chất lượng như: tính đúng đắn (hành vi đúng như đặc tả), tính hiệu quả (tiết kiệm thời gian và tiền bạc), độ tin cậy, tính khả kiểm thử (kiểm thử được và dễ), dễ học, dễ sử dụng, dễ bảo trì.

Như vậy, độ tin cậy chỉ là một yếu tố để đánh giá chất lượng phầm mềm. Người kiểm thử hay nhầm lẫn độ tin cậy với chất lượng. Khi kiểm thử đạt tới mức phần mềm chạy ổn định, có thể phụ thuộc vào nó, người kiểm thử thường cho rằng phần mềm đã đạt chất lượng cao. Các yếu tố về mặt chất lượng mà liên quan trực tiếp đến việc phát triển phần mềm được gọi là các tiêu chuẩn chất lượng như tính có cấu trúc, tính đơn thể, tính khả kiểm thử,.

Độ tin cậy của phần mềm là xác suất để phần mềm chạy không có thất bại trong một khoảng thời gian nhất định. Nó được xem là một yếu tố quan trọng của chất lượng phần mềm. Ngoài ra, thời gian trung bình cho việc khắc phục một sự cố cũng là một thông số quan trọng trong việc đánh giá độ tin cậy của sản phẩm phần mềm. TỔNG QUAN VỀ KIỂM THỬ Kiểm thử: Rõ ràng việc kiểm thử liên quan đến các khái niệm trên: lỗi, sai, thất bại và sự cố.

Có hai mục đích chính của một phép thử: tìm thất bại hoặc chứng tỏ việc tiến hành của phần mềm là đúng đắn. Vai trò của kiểm thử phần mềm: Kiểm thử phần mềm đóng vai trò quan trọng trong việc đánh giá và thu được chất lượng cao của sản phẩm phần mềm trong quá trình phát triển. Thông qua chu trình “kiểm thử - tìm lỗi - sửa lỗi”, ta hy vọng chất lượng của sản phẩm phần mềm sẽ được cải tiến. Mặt khác, thông qua việc tiến hành kiểm thử mức hệ thống trước khi cho lưu hành sản phẩm, ta biết được sản phẩm của ta tốt ở mức nào.

Vì thế, nhiều tác giả đã mô tả việc kiểm thử phần mềm là một quy trình kiểm chứng để đánh giá và tăng cường chất lượng của sản phẩm phần mềm. Quy trình này gồm hai công việc chính là phân tích tĩnh và phân tích động. • Phân tích tĩnh: Việc phân tích tĩnh được tiến hành dựa trên việc khảo sát các tài liệu được xây dựng trong quá trình phát triển sản phẩm như tài liệu đặ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 phần mềm. Các phương pháp phân tích tĩnh truyền thống bao gồm việc khảo sát đặc tả và mã nguồn cùng các tài liệu thiết kế.

Các kỹ thuật khảo sát này sẽ được giới thiệu trong chương 4. Người ta cũng có thể dùng các kỹ thuật phân tích hình thức như kiểm chứng mô hình (model checking) và chứng minh định lý (theorem proving) để chứng minh tính đúng đắn của thiết kế và mã nguồn. Các kỹ thuật này tương đối phức tạp và nằm ngoài khuôn khổ của cuốn giáo trình này. Công việc này không động đến việc thực thi chương trình mà chỉ duyệt, lý giải về tất cả các hành vi có thể của chương trình khi được thực thi.

Tối ưu hóa các chương trình dịch là các ví dụ về phân tích tĩnh. • Phân tích động: Phân tích động liên quan đến việc thực thi chương trình để phát hiện những thất bại có thể có của chương trình, hoặc quan sát các tính chất nào đó về hành vi và hiệu quả (performance). Vì gần như không thể thực thi chương trình trên tất cả các dữ liệu đầu vào có thể, ta chỉ có thể chọn một tập con các dữ liệu đầu vào để thực thi, gọi là các “ca kiểm thử”. Chọn như thế nào để được các bộ dữ liệu đầu vào hiệu quả (tức là các bộ dữ liệu có xác suất phát hiện thất bại (nếu có) cao hơn là công việc cần suy nghĩ và là nội dung chính của các giáo trình này.

CÁC THUẬT NGỮ VÀ ĐỊNH NGHĨA CƠ BẢN VỀ KIỂM THỬ 5 Bằng việc phân tích tĩnh và động, người kiểm thử muốn phát hiện nhiều lỗi nhất có thể được để chúng có thể được sửa ở giai đoạn sớm nhất trong quá trình phát triển phần mềm. Phân tích tĩnh và động là hai kỹ thuật bổ sung cho nhau và cần được làm lặp đi lặp lại nhiều trong quá trình kiểm thử. Ca kiểm thử: Mỗi ca kiểm thử có một tên và được liên kết với một hành vi của chương trình. Ca kiểm thử gồm một tập các dữ liệu đầu vào và một xâu các giá trị đầu ra mong đợi đối với phần mềm.1: Một vòng đời của việc kiểm thử.1 mô tả vòng đời của việc kiểm thử ứng với mô hình thác nước.

Lưu ý rằng trong giai đoạn phát triển phần mềm, lỗi có thể được đưa vào tại các gia đoạn đặc tả yêu cầu, thiết kế và lập trình. Các lỗi này có thể tạo ra những sai lan truyền sang các phần còn lại của quá trình phát triển. Một nhà kiểm thử lỗi lạc đã tóm tắt vòng đời này như sau: Ba giai đoạn đầu là “đưa lỗi vào”, giai đoạn kiểm thử là để tìm lỗi, và ba giai đoạn cuối là “khữ lỗi đi” [Pos90]. Bước sửa sai là cơ hội mới cho việc đưa vào lỗi (và các sai mới).

Vì vậy, việc sửa sai này có thể làm cho phần mềm từ đúng trở thành sai. Trong trường hợp này, việc sửa sai là không đầy đủ. Kiểm thử hồi quy (sẽ được giới thiệu trong chương 11) là giải pháp tốt để giải quyết vấn đề này. TỔNG QUAN VỀ KIỂM THỬ Các thuật ngữ trên đây cho thấy các ca kiểm thử chiếm vị trí trung tâm trong việc kiểm thử dựa trên phân tích động.

Quá trình kiểm thử dựa trên phân tích động được chia thành các buớc sau: lập kế hoạch kiểm thử, phát triển ca kiểm thử, chạy các ca kiểm thử và đánh giá kết quả kiểm thử. Tiêu điểm của cuốn giáo trình này là việc xác định tập hữu ích các ca kiểm thử, tức là các ca kiểm thứ giúp ta cải tiến tốt hơn chất lượng của sản phẩm.2 Ca kiểm thử Cốt lõi của kiểm thử phần mềm dựa trên phân tích động là việc xác định tập các ca kiểm thử sao cho chúng có khả năng phát hiện nhiều nhất các lỗi (có thể có) của hệ thống cần kiểm thử. Vậy cái gì cần đưa vào các ca kiểm thử? Rõ ràng thông tin đầu tiên là đầu vào.