Kiểm Thử Đơn Vị Cho Hệ Thống Luận Văn Thạc Sĩ Công Nghệ Thông Tin

Luận văn thạc sĩ phân tích kiểm thử đơn vị cho hệ thống, đánh giá thực trạng, chỉ ra hạn chế, đề xuất giải pháp khả thi cho thực tiễn.

• Tác giả: Luyện Thị Lan Hương
• Người hướng dẫn: TS. Trần Thị Minh Châu
• Trường học: Đại Học Quốc Gia Hà Nội
• Chuyên ngành: Công Nghệ Thông Tin
• Đề tài: Kiểm Thử Đơn Vị Trong Hệ Thống Công Nghệ Thông Tin
• Loại tài liệu: luận văn thạc sĩ
• Năm xuất bản: 2014
• Địa điểm: Hà Nội

Mục lục chi tiết

• Lời cam đoan
• Lời cảm ơn
• Bảng các từ viết tắt
• Danh mục hình vẽ
• Danh mục bảng biểu
• 1. Chương 1: Giới thiệu
• 1.1. Đặt vấn đề
• 1.2. Nội dung nghiên cứu
• 1.3. Cấu trúc luận văn
• 2. Chương 2: Tổng quan về kiểm thử phần mềm
• 2.1. Chất lượng phần mềm
• 2.2. Kiểm thử và vai trò của kiểm thử
• 2.3. Các mục tiêu của kiểm thử
• 2.4. Các hoạt động kiểm thử
• 2.5. Các mức độ kiểm thử
• 2.5.1. Kiểm thử đơn vị
• 2.5.2. Kiểm thử tích hợp
• 2.5.3. Kiểm thử hệ thống
• 2.5.4. Kiểm thử chấp nhận
• 2.5.5. Kiểm thử hồi quy
• 3. Chương 3: Các kỹ thuật kiểm thử phần mềm
• 3.1. Kiểm thử hộp đen
• 3.1.1. Kỹ thuật phân lớp tương đương (Equivalence Class Testing)
• 3.1.2. Kỹ thuật phân tích giá trị biên (Boundary Value Testing)
• 3.1.3. Kỹ thuật bảng quyết định (Decision Table Testing)
• 3.2. Kiểm thử hộp trắng
• 3.2.1. Kỹ thuật dòng điều khiển (Control Flow Testing)
• 3.2.2. Kỹ thuật dòng dữ liệu (Data Flow Testing)
• 4. Chương 4: Bài toán áp dụng
• 4.1. Áp dụng kỹ thuật phân lớp tương đương
• 4.2. Áp dụng kỹ thuật Bảng quyết định
• 4.3. Áp dụng kỹ thuật kiểm thử dòng điều khiển
• 4.4. Áp dụng kỹ thuật kiểm thử dòng dữ liệu
• 4.5. Áp dụng kỹ thuật phân lớp tương đương
• 4.6. Áp dụng kỹ thuật bảng quyết định
• 4.7. Áp dụng kỹ thuật dòng điều khiển
• 4.8. Áp dụng kỹ thuật dòng dữ liệu
• 4.9. Áp dụng kỹ thuật Domain testing
• 4.10. Áp dụng kỹ thuật Bảng quyết định
• 4.11. Áp dụng kỹ thuật dòng điều khiển
• 4.12. Áp dụng kỹ thuật dòng dữ liệu
• 5. Chương 5: Kết luận
• 5.1. Kết quả của luận văn
• 5.2. Hướng nghiên cứu tiếp theo
• Tài liệu tham khảo

Tóm tắt

I. Tìm hiểu về Kiểm Thử Đơn Vị Tổng quan Lợi ích

Kiểm thử đơn vị, hay Unit Testing, là một phương pháp kiểm thử phần mềm quan trọng, tập trung vào việc kiểm tra từng thành phần riêng lẻ (đơn vị) của mã nguồn. Các đơn vị này có thể là hàm, phương thức, lớp hoặc module. Mục tiêu chính của Unit Testing là xác minh rằng mỗi đơn vị hoạt động đúng như thiết kế. Việc thực hiện kiểm thử đơn vị sớm và thường xuyên trong quy trình phát triển phần mềm (SDLC) giúp phát hiện và sửa lỗi kịp thời, giảm thiểu chi phí và rủi ro. TDD (Test Driven Development) là một phương pháp phát triển phần mềm mà việc viết Unit Test được thực hiện trước khi viết mã nguồn, giúp định hướng và đảm bảo chất lượng mã. Theo một nghiên cứu, việc áp dụng TDD có thể giảm đáng kể số lượng lỗi trong quá trình phát triển.

1.1. Định nghĩa chính xác về Unit Testing Kiểm Thử Đơn Vị

Unit Testing là quá trình kiểm thử phần mềm tập trung vào việc kiểm tra độc lập từng đơn vị mã nguồn. Đơn vị có thể là một hàm, một phương thức, một lớp hoặc một module. Mục đích là để đảm bảo rằng mỗi đơn vị hoạt động đúng theo đặc tả thiết kế và yêu cầu nghiệp vụ. Quá trình này thường được thực hiện bởi chính các lập trình viên hoặc các chuyên gia Software Testing. Việc sử dụng Framework kiểm thử như JUnit (Java), NUnit (.NET) giúp đơn giản hóa việc viết và thực thi các Test Case.

1.2. Tại sao Unit Testing lại quan trọng trong SQA

Unit Testing đóng vai trò then chốt trong Software Quality Assurance (SQA). Việc phát hiện sớm các lỗi ở mức đơn vị giúp ngăn chặn các lỗi phức tạp hơn xuất hiện ở các giai đoạn Integration Testing hay System Testing. Điều này giúp giảm chi phí sửa lỗi và tăng độ tin cậy của phần mềm. Kiểm thử tự động (Test Automation) Unit Testing là một phần quan trọng của quy trình Continuous Integration (CI) và Continuous Delivery (CD) trong DevOps, giúp đảm bảo chất lượng liên tục của phần mềm.

II. Thách Thức Vấn Đề Triển khai Unit Testing hiệu quả

Mặc dù Unit Testing mang lại nhiều lợi ích, việc triển khai nó một cách hiệu quả không phải lúc nào cũng dễ dàng. Một trong những thách thức lớn nhất là viết các Test Case tốt, bao phủ đầy đủ các trường hợp có thể xảy ra. Việc cô lập các đơn vị mã nguồn để kiểm thử cũng có thể gặp khó khăn, đặc biệt khi chúng phụ thuộc vào các thành phần khác. Ngoài ra, việc duy trì các Test Suite cũng đòi hỏi nỗ lực, đặc biệt khi mã nguồn thay đổi. Cần có chiến lược rõ ràng và sự hiểu biết sâu sắc về mã nguồn để vượt qua những thách thức này. Theo một nghiên cứu, nhiều dự án gặp khó khăn trong việc duy trì Code Coverage cao cho các Unit Test.

2.1. Khó khăn trong việc viết Test Case chất lượng Test Suite

Viết Test Case chất lượng đòi hỏi sự hiểu biết sâu sắc về yêu cầu nghiệp vụ và logic của mã nguồn. Cần phải xác định các trường hợp kiểm thử khác nhau, bao gồm cả trường hợp thông thường và trường hợp biên. Việc đảm bảo độ bao phủ mã (Code Coverage) cao cũng là một thách thức, đặc biệt đối với các module phức tạp. Cần sử dụng các kỹ thuật như Black Box Testing, White Box Testing và Gray Box Testing để thiết kế các Test Case hiệu quả.

2.2. Vấn đề phụ thuộc Giải pháp Mocking Stubbing trong Testing

Một trong những thách thức lớn nhất trong Unit Testing là xử lý các phụ thuộc. Khi một đơn vị mã phụ thuộc vào các thành phần khác (ví dụ: cơ sở dữ liệu, dịch vụ bên ngoài), việc kiểm thử độc lập trở nên khó khăn. Giải pháp là sử dụng Mocking và Stubbing. Mocking là tạo ra các đối tượng giả để thay thế các phụ thuộc thực, cho phép kiểm soát hành vi của chúng. Stubbing là cung cấp các giá trị trả về cố định cho các phương thức của đối tượng phụ thuộc. Cả hai kỹ thuật này giúp cô lập đơn vị mã cần kiểm thử và đảm bảo kết quả kiểm thử chính xác.

2.3. Bảo trì Test Suite Bài toán khó cho dự án phát triển phần mềm

Khi mã nguồn thay đổi, Test Suite cũng cần được cập nhật để phản ánh những thay đổi đó. Việc bảo trì Test Suite có thể tốn kém thời gian và công sức, đặc biệt đối với các dự án lớn. Tuy nhiên, việc bỏ qua bảo trì Test Suite có thể dẫn đến các kết quả kiểm thử không chính xác và làm giảm giá trị của Unit Testing. Regression Testing là một kỹ thuật quan trọng để đảm bảo rằng các thay đổi mã nguồn không gây ra các lỗi mới.

III. Phương Pháp Kiểm Thử Đơn Vị TDD BDD và Cách triển khai

Có nhiều phương pháp tiếp cận Kiểm Thử Đơn Vị, trong đó TDD (Test Driven Development) và BDD (Behavior Driven Development) là hai phương pháp phổ biến nhất. TDD tập trung vào việc viết Unit Test trước khi viết mã nguồn, giúp định hướng và đảm bảo chất lượng mã. BDD tập trung vào việc mô tả hành vi của phần mềm thông qua các kịch bản kiểm thử dễ hiểu, giúp tăng cường sự hợp tác giữa các bên liên quan. Việc lựa chọn phương pháp phù hợp phụ thuộc vào đặc điểm của dự án và kinh nghiệm của đội ngũ phát triển.

3.1. Test Driven Development TDD Quy trình Lợi ích

Test Driven Development (TDD) là một quy trình phát triển phần mềm lặp đi lặp lại, bao gồm các bước: Viết một Unit Test thất bại, Viết mã nguồn tối thiểu để vượt qua Unit Test, Refactoring mã nguồn để cải thiện cấu trúc và hiệu suất. TDD giúp đảm bảo rằng mọi dòng mã đều được kiểm thử và mã nguồn đáp ứng đúng yêu cầu. TDD giúp cải thiện Code Quality và giảm thiểu lỗi.

3.2. Behavior Driven Development BDD Tiếp cận từ hành vi

Behavior Driven Development (BDD) là một phương pháp phát triển phần mềm dựa trên việc mô tả hành vi của phần mềm thông qua các kịch bản kiểm thử dễ hiểu. BDD sử dụng ngôn ngữ tự nhiên để mô tả các kịch bản, giúp tăng cường sự hợp tác giữa các bên liên quan (ví dụ: lập trình viên, kiểm thử viên, chủ dự án). BDD thường sử dụng các Framework kiểm thử như Cucumber hoặc SpecFlow.

3.3. So sánh TDD BDD Chọn phương pháp Kiểm Thử phù hợp

Cả TDD và BDD đều là các phương pháp hiệu quả để phát triển phần mềm chất lượng cao. TDD tập trung vào việc kiểm tra mã nguồn ở mức thấp, trong khi BDD tập trung vào việc mô tả hành vi của phần mềm ở mức cao. Việc lựa chọn phương pháp phù hợp phụ thuộc vào đặc điểm của dự án và kinh nghiệm của đội ngũ phát triển. Trong nhiều trường hợp, kết hợp cả hai phương pháp có thể mang lại hiệu quả tốt nhất.

IV. Công Cụ Hỗ Trợ Kiểm Thử Đơn Vị Lựa chọn Framework tốt nhất

Có rất nhiều công cụ hỗ trợ Kiểm Thử Đơn Vị, từ các Framework kiểm thử phổ biến như JUnit (Java), NUnit (.NET), pytest (Python) đến các công cụ hỗ trợ Mocking và Stubbing. Việc lựa chọn công cụ phù hợp phụ thuộc vào ngôn ngữ lập trình, yêu cầu của dự án và kinh nghiệm của đội ngũ phát triển. Các công cụ này giúp đơn giản hóa việc viết, thực thi và quản lý các Test Case.

4.1. JUnit Java Framework kiểm thử đơn vị phổ biến nhất

JUnit là một Framework kiểm thử đơn vị phổ biến nhất cho Java. JUnit cung cấp các annotation và assertion để giúp viết các Test Case một cách dễ dàng. JUnit cũng tích hợp tốt với các IDE phổ biến như Eclipse và IntelliJ IDEA. JUnit hỗ trợ Test Automation và Continuous Integration.

4.2. NUnit .NET Công cụ kiểm thử cho .NET developers

NUnit là một Framework kiểm thử đơn vị phổ biến cho .NET. NUnit tương tự như JUnit, cung cấp các annotation và assertion để giúp viết các Test Case một cách dễ dàng. NUnit cũng tích hợp tốt với các IDE phổ biến như Visual Studio. NUnit hỗ trợ Test Automation và Continuous Integration.

4.3. pytest Python Kiểm thử đơn giản và hiệu quả

Pytest là một Framework kiểm thử đơn vị phổ biến cho Python. Pytest được biết đến với sự đơn giản và dễ sử dụng. Pytest hỗ trợ Test Automation và tích hợp tốt với các công cụ phân tích Code Coverage như Coverage.py.

V. Áp Dụng Kiểm Thử Đơn Vị Case study Bài học thực tế

Việc áp dụng Kiểm Thử Đơn Vị trong thực tế có thể mang lại những kết quả ấn tượng. Các dự án áp dụng TDD thường có ít lỗi hơn và Code Quality tốt hơn. Tuy nhiên, cần lưu ý rằng việc triển khai Unit Testing một cách hiệu quả đòi hỏi sự cam kết và nỗ lực của toàn bộ đội ngũ phát triển. Cần có kế hoạch rõ ràng, đào tạo đầy đủ và sự hỗ trợ từ ban quản lý.

5.1. Case Study Thành công nhờ triển khai Unit Testing

Nhiều công ty đã chia sẻ kinh nghiệm thành công nhờ triển khai Unit Testing. Ví dụ, một công ty phát triển phần mềm tài chính đã giảm đáng kể số lượng lỗi và tăng độ tin cậy của phần mềm sau khi áp dụng TDD. Một công ty khác đã cải thiện Code Quality và giảm chi phí bảo trì sau khi triển khai BDD.

5.2. Những sai lầm cần tránh khi thực hiện Unit Testing

Có một số sai lầm phổ biến cần tránh khi thực hiện Unit Testing. Ví dụ, viết các Test Case quá phức tạp hoặc không cô lập các đơn vị mã nguồn có thể làm giảm hiệu quả của Unit Testing. Việc bỏ qua bảo trì Test Suite cũng là một sai lầm nghiêm trọng. Cần tuân thủ các Best Practices để đảm bảo Unit Testing mang lại giá trị thực sự.

5.3. Đo lường hiệu quả của Testing Code Coverage và hơn thế nữa

Đo lường hiệu quả của Unit Testing là rất quan trọng để đảm bảo rằng nó mang lại giá trị thực sự. Code Coverage là một chỉ số quan trọng, cho biết tỷ lệ mã nguồn được kiểm thử bởi các Unit Test. Tuy nhiên, Code Coverage chỉ là một phần của bức tranh. Cần kết hợp Code Coverage với các chỉ số khác như số lượng lỗi phát hiện, thời gian sửa lỗi và phản hồi của người dùng.

VI. Tương Lai Kiểm Thử Đơn Vị AI Machine Learning ứng dụng

Tương lai của Kiểm Thử Đơn Vị có thể sẽ chứng kiến sự gia tăng của AI (Artificial Intelligence) và Machine Learning (ML). Các công cụ AI có thể giúp tự động hóa việc viết Test Case, phát hiện lỗi và phân tích kết quả kiểm thử. ML có thể được sử dụng để dự đoán các khu vực mã nguồn có khả năng chứa lỗi cao và tập trung nỗ lực kiểm thử vào các khu vực đó. Việc ứng dụng AI và ML có thể giúp tăng cường hiệu quả và giảm chi phí của Kiểm Thử Đơn Vị.

6.1. AI Machine Learning hỗ trợ viết Test Case tự động

AI và Machine Learning có tiềm năng lớn trong việc tự động hóa việc viết Test Case. Các thuật toán AI có thể phân tích mã nguồn và tạo ra các Test Case bao phủ đầy đủ các trường hợp có thể xảy ra. Điều này có thể giúp giảm đáng kể thời gian và công sức cần thiết để viết Test Case.

6.2. Phân tích lỗi thông minh nhờ Machine Learning trong Testing

Machine Learning có thể được sử dụng để phân tích kết quả kiểm thử và xác định các mẫu lỗi. Các thuật toán ML có thể dự đoán các khu vực mã nguồn có khả năng chứa lỗi cao và giúp tập trung nỗ lực kiểm thử vào các khu vực đó. Điều này có thể giúp phát hiện lỗi sớm hơn và giảm chi phí sửa lỗi.

Nội dung chính

Tổng quan nghiên cứu

Trong kỹ nghệ phần mềm hiện đại, chi phí khắc phục lỗi ở giai đoạn bảo trì hoặc vận hành thực tế thường cao gấp 30 đến 100 lần so với giai đoạn phát triển ban đầu. Thực tiễn sản xuất phần mềm chứng minh rằng hoạt động kiểm thử đơn vị (Unit Testing) có khả năng phát hiện hơn 25% tổng số lỗi tiềm ẩn của toàn bộ dự án ngay từ các dòng mã nguồn đầu tiên. Tuy nhiên, phần lớn các lập trình viên hiện nay vẫn thực hiện viết ca kiểm thử theo phương thức thủ công, thiếu một khung chiến lược rõ ràng để kết hợp hài hòa giữa các phương pháp kiểm thử hộp đen và hộp trắng. Thực trạng này dẫn đến việc số lượng ca kiểm thử sinh ra quá nhiều gây lãng phí tài nguyên, hoặc ngược lại, số lượng ca kiểm thử quá ít khiến độ bao phủ mã nguồn không đạt yêu cầu và bỏ sót các khiếm khuyết nghiêm trọng.

Luận văn tập trung nghiên cứu, khảo sát toàn diện các kỹ thuật kiểm thử đơn vị cốt lõi, bao gồm kỹ thuật phân lớp tương đương, bảng quyết định, kiểm thử dòng điều khiển và kiểm thử dòng dữ liệu. Mục tiêu trọng tâm là phân tích sâu ưu điểm, nhược điểm và khả năng phát hiện lỗi của từng kỹ thuật, từ đó xây dựng chiến lược kiểm thử tối ưu giúp giảm thiểu số lượng ca kiểm thử mà vẫn đạt độ bao phủ cấu trúc và độ bao phủ nghiệp vụ cao nhất.

Nghiên cứu được triển khai áp dụng thực nghiệm trên hệ số tính toán chỉ số chứng khoán thực tế tại Việt Nam vào năm 2014, với phạm vi khảo sát gồm 3 bài toán nghiệp vụ xử lý dữ liệu ngày giao dịch, tỷ lệ cổ tức và hệ số giao dịch tự do (Free-float). Ý nghĩa của nghiên cứu thể hiện qua việc giảm hơn 40% số ca kiểm thử dư thừa trong quá trình kiểm thử đơn vị, đồng thời nâng tỷ lệ bao phủ đường dẫn mã nguồn lên xấp xỉ 100%, đáp ứng đầy đủ các tiêu chuẩn quốc tế về chất lượng phần mềm theo khung ISO 9126.

Cơ sở lý thuyết và phương pháp nghiên cứu

Khung lý thuyết áp dụng

Nghiên cứu vận dụng nền tảng của mô hình phát triển phần mềm chữ V (V-Model), định vị kiểm thử đơn vị là giai đoạn kiểm chứng mức cơ sở tương ứng trực tiếp với pha thiết kế chi tiết và viết mã nguồn. Chất lượng phần mềm trong luận văn được đánh giá dựa trên 6 thuộc tính chuẩn hóa của tiêu chuẩn ISO 9126, bao gồm tính năng, độ tin cậy, tính tiện dụng, hiệu quả, khả năng bảo trì và tính khả chuyển.

Về phương diện kỹ thuật, khung lý thuyết phân tách thành hai nhánh chính:

• Nhánh kiểm thử hộp đen (Black-box testing): Khai thác kỹ thuật phân lớp tương đương (Equivalence Partitioning) nhằm chia không gian dữ liệu đầu vào thành các lớp đại diện hợp lệ và không hợp lệ; kỹ thuật bảng quyết định (Decision Table) nhằm mô hình hóa logic quan hệ nhân quả phức tạp giữa các điều kiện đầu vào và hành động đầu ra dưới dạng ma trận gồm 2 mũ n quy tắc kết hợp lý thuyết; kỹ thuật phân tích giá trị biên (Boundary Value Analysis) với các mô hình kiểm thử biên mở rộng sinh ra 6n+1 ca kiểm thử và kiểm thử trường hợp xấu nhất mở rộng sinh ra tới 7 mũ n ca kiểm thử cho n biến đầu vào độc lập.
• Nhánh kiểm thử hộp trắng (White-box testing): Ứng dụng kỹ thuật kiểm thử dòng điều khiển (Control Flow Testing) dựa trên đồ thị dòng điều khiển (CFG) với 3 cấp độ đo bao phủ: bao phủ câu lệnh (C1), bao phủ nhánh rẽ (C2) và bao phủ điều kiện phức hợp (C3), kết hợp kỹ thuật kiểm soát vòng lặp với 4 kịch bản cơ bản. Kèm theo đó là kỹ thuật kiểm thử dòng dữ liệu (Data Flow Testing) dựa trên đồ thị dòng dữ liệu (DFG) để theo dõi trạng thái định nghĩa (def) và sử dụng (use) của biến thông qua các tiêu chí All-defs, All-c-uses và All-p-uses trên các đường dẫn du-path.

Phương pháp nghiên cứu

Nghiên cứu sử dụng phương pháp đối sánh định lượng thực nghiệm (empirical comparative analysis). Nguồn dữ liệu thực nghiệm được xây dựng từ 3 bài toán nghiệp vụ tài chính chứng khoán phức tạp, cấu hình thành 2 phiên bản mã nguồn C# song song cho mỗi bài toán (gồm 1 phiên bản mã nguồn chuẩn và 1 phiên bản mã nguồn cố tình cài cắm lỗi logic biên), tạo nên cỡ mẫu thực nghiệm gồm 6 đơn vị hàm xử lý độc lập.

Phương pháp chọn mẫu là chọn mẫu phi ngẫu nhiên có chủ đích (purposive sampling), tập trung vào các đoạn mã nguồn có độ phức tạp xoay vòng cao, chứa nhiều cấu trúc điều kiện if-else lồng nhau, hàm kiểm tra ngày nghỉ lễ và vòng lặp while dịch chuyển thời gian giao dịch. Lý do lựa chọn phương pháp này là nhằm tạo ra môi trường kiểm thử tương đương với các hệ thống giao dịch thực tế, cho phép đo lường chính xác các chỉ số định lượng về tỷ lệ phần trăm độ bao phủ (coverage metric), số lượng ca kiểm thử cần thiết và số lỗi phát hiện được. Toàn bộ quá trình nghiên cứu, thiết kế ca kiểm thử và chạy nghiệm thu được thực hiện liên tục trong khoảng thời gian 6 tháng năm 2014.

Kết quả nghiên cứu và thảo luận

Những phát hiện chính

Quá trình thực nghiệm 4 kỹ thuật kiểm thử trên các bài toán tính toán chỉ số chứng khoán mang lại 4 phát hiện định lượng quan trọng:

Thứ nhất, kỹ thuật bảng quyết định thể hiện năng lực tối ưu hóa số lượng ca kiểm thử xuất sắc đối với các bài toán có ràng buộc logic phụ thuộc. Cụ thể ở bài toán xác định ngày giao dịch, từ 16 tổ hợp điều kiện lý thuyết ban đầu, bảng quyết định đã sàng lọc và loại bỏ các trường hợp không khả thi để thu gọn còn 5 ca kiểm thử hợp lệ, giúp giảm tới 68.75% khối lượng ca kiểm thử mà vẫn giữ nguyên vẹn khả năng kiểm tra toàn bộ các quy tắc nghiệp vụ rẽ nhánh.

Thứ hai, kỹ thuật kiểm thử hộp trắng (dòng điều khiển và dòng dữ liệu) đạt độ bao phủ cấu trúc tuyệt đối 100% đối với các lớp tương đương hợp lệ và không hợp lệ của kiểm thử hộp đen. Ngược lại, bộ ca kiểm thử sinh ra từ kỹ thuật bảng quyết định chỉ bao phủ được 5 trên 8 đường đi (đạt tỷ lệ 62.5%) của đồ thị dòng điều khiển, cho thấy kiểm thử hộp đen đơn thuần không thể bao quát hết các đường dẫn thực thi nội bộ.

Thứ ba, về năng lực phát hiện khiếm khuyết trên mã nguồn lỗi, kỹ thuật phân lớp tương đương phát hiện được 2 lỗi logic biên thời gian, trong khi kỹ thuật bảng quyết định, dòng dữ liệu và dòng điều khiển đều phát hiện chính xác 1 lỗi cốt lõi. Lỗi này làm sai lệch kết quả trả về từ ngày 21 tháng 11 năm 2014 thành ngày 22 tháng 11 năm 2014 do không xử lý triệt để khoảng lùi ngày làm việc qua kỳ nghỉ cuối tuần.

Thứ tư, kỹ thuật kiểm thử dòng dữ liệu (DFG) chứng minh tính ưu việt khi phát hiện ra lỗi tiềm ẩn liên quan đến giá trị khởi tạo mặc định (ngày 01/01/1900 của kiểu DateTime) trên cả mã nguồn chuẩn khi tham số đầu vào nằm ngoài miền hình thức thực hiện quyền, điều mà các kỹ thuật kiểm thử hộp đen hoàn toàn bỏ sót.

Thảo luận kết quả

Sự chênh lệch về hiệu năng và độ bao phủ giữa các kỹ thuật bắt nguồn từ góc nhìn tiếp cận cấu trúc phần mềm. Kiểm thử hộp đen chỉ căn cứ trên đặc tả yêu cầu bên ngoài, do đó không thể nhận biết được sự hiện diện của các vòng lặp nội bộ (như vòng lặp while kiểm tra ngày nghỉ lễ liên tiếp). Khi mô hình hóa mã nguồn bằng đồ thị dòng điều khiển (CFG), cấu trúc chương trình được phân rã thành 8 đường đi cơ bản, sau đó mở rộng thành 10 ca kiểm thử để kiểm soát đầy đủ 4 trạng thái vòng lặp (0 lần, 1 lần, 2 lần và nhiều lần).

Dữ liệu thực nghiệm của nghiên cứu có thể được trực quan hóa thông qua bảng ma trận so sánh độ bao phủ chéo và biểu đồ cột so sánh tỷ lệ phát hiện lỗi giữa các kỹ thuật. Trên biểu đồ, tỷ lệ bao phủ của kỹ thuật dòng điều khiển đạt mức đỉnh 100% so với tất cả các kỹ thuật khác trên mã nguồn chuẩn, trong khi tỷ lệ bao phủ của bảng quyết định dao động từ 62.5% đến 83.3%.

Kết quả này hoàn toàn tương thích với các nghiên cứu học thuật quốc tế về công nghệ phần mềm, khẳng định rằng không tồn tại một kỹ thuật kiểm thử đơn vị vạn năng. Kiểm thử hộp đen là bắt buộc để đảm bảo sự phù hợp với yêu cầu nghiệp vụ của khách hàng, nhưng kiểm thử hộp trắng là mắt xích không thể thiếu để triệt tiêu các nhánh rẽ lỗi và trạng thái biến rác trong mã lệnh.

Đề xuất và khuyến nghị

Dựa trên các bằng chứng thực nghiệm, nghiên cứu đề xuất 4 giải pháp hành động cụ thể nhằm nâng cao chất lượng kiểm thử đơn vị:

• Áp dụng quy trình kiểm thử đơn vị lai (Hybrid Unit Testing): Lập trình viên cần chủ động phối hợp kỹ thuật bảng quyết định ở giai đoạn phân tích đặc tả để tinh giản tối thiểu 50% số ca kiểm thử trùng lặp, sau đó áp dụng kỹ thuật dòng điều khiển (CFG) để rà soát mã nguồn, cam kết đạt độ bao phủ nhánh rẽ tối thiểu 90% trước khi đưa mã nguồn vào nhánh tích hợp chung. Quy trình này cần được áp dụng ngay trong các chu kỳ phát triển 2 tuần của dự án.
• Chuẩn hóa tiêu chuẩn kiểm thử dòng dữ liệu cho các mô-đun tính toán tài chính: Trưởng nhóm kỹ thuật và bộ phận đảm bảo chất lượng (QA) cần ban hành quy định bắt buộc áp dụng tiêu chí All-p-uses và All-c-uses cho 100% các biến tính toán số học phức tạp, hoàn thành xây dựng bộ khung kiểm thử này trong thời hạn 1 tháng.
• Thiết lập kịch bản kiểm thử vòng lặp và giá trị biên tự động: Đội ngũ kỹ sư phần mềm thực hiện viết mã kiểm thử tự động bao phủ tối thiểu 4 trường hợp biên của vòng lặp (vòng lặp chạy 0 lần, 1 lần, 2 lần và k lần lặp), đặt mục tiêu phát hiện sớm 80% lỗi treo ứng dụng và tràn bộ nhớ trong lộ trình 3 tháng tới.
• Tích hợp công cụ đo lường độ bao phủ vào hệ thống CI/CD: Doanh nghiệp công nghệ và quản trị dự án cần tích hợp các công cụ kiểm thử đơn vị tự động vào quy trình phân phối liên tục, thiết lập ngưỡng chặn chất lượng (quality gate) yêu cầu độ bao phủ câu lệnh (C1) đạt trên 85% và độ bao phủ nhánh (C2) đạt trên 80% trước khi bàn giao phần mềm, triển khai đồng bộ trong vòng 6 tháng.

Đối tượng nên tham khảo luận văn

Nội dung và kết quả thực nghiệm của luận văn mang lại giá trị thiết thực cho 4 nhóm đối tượng:

• Kỹ sư phát triển phần mềm (Developers): Nhận được hướng dẫn chi tiết về cách thức xây dựng đồ thị dòng điều khiển và dòng dữ liệu từ mã nguồn thực tế, giúp nâng cao kỹ năng tự kiểm thử đơn vị, giảm khoảng 30% thời gian gỡ lỗi và ngăn ngừa lỗi logic phát sinh trong quá trình lập trình.
• Kỹ sư đảm bảo chất lượng và kiểm thử viên (QA/QC Engineers): Tiếp cận phương pháp luận chuẩn xác về kỹ thuật bảng quyết định và phân lớp tương đương, ứng dụng trực tiếp vào việc thiết kế bộ dữ liệu kiểm thử tối ưu cho các hệ thống phần mềm tài chính, ngân hàng và chứng khoán có quy tắc phức tạp.
• Quản trị dự án phần mềm (Project Managers): Có cơ sở khoa học và số liệu thực nghiệm để lập kế hoạch phân bổ nguồn lực kiểm thử hợp lý, cân đối chi phí giữa kiểm thử hộp đen và hộp trắng, giúp tiết kiệm hơn 20% tổng chi phí bảo trì hệ thống sau bàn giao.
• Giảng viên và học viên chuyên ngành Kỹ thuật phần mềm: Sử dụng luận văn làm tài liệu tham khảo học thuật chuyên sâu với hệ thống bài tập thực hành, ví dụ minh họa trực quan và các công thức tính toán độ đo C1, C2, C3 chuẩn mực trong giảng dạy bộ môn kiểm thử phần mềm.

Câu hỏi thường gặp

Kiểm thử đơn vị đóng vai trò gì trong việc cắt giảm chi phí phát triển phần mềm?
Kiểm thử đơn vị cho phép phát hiện hơn 25% tổng số lỗi ngay tại giai đoạn lập trình ban đầu. Trong thực tế, chi phí để sửa một lỗi ở mức đơn vị thấp hơn từ 10 đến 30 lần so với việc phát hiện và sửa lỗi đó ở giai đoạn kiểm thử hệ thống hoặc khi phần mềm đã vận hành thực tế.

Khi nào nên ưu tiên sử dụng kỹ thuật bảng quyết định trong kiểm thử đơn vị?
Bảng quyết định nên được ưu tiên sử dụng khi hàm xử lý chứa nhiều câu lệnh if-else lồng nhau và các biến đầu vào có mối quan hệ phụ thuộc logic phức tạp. Ví dụ trong bài toán chứng khoán, bảng quyết định giúp rút gọn 16 tổ hợp điều kiện xuống còn 5 ca kiểm thử thực thi có độ bao phủ nghiệp vụ hoàn chỉnh.

Tại sao kiểm thử dòng điều khiển vẫn có thể bỏ sót lỗi nếu không kiểm tra vòng lặp?
Độ đo bao phủ nhánh (C2) chỉ đảm bảo các điểm rẽ nhánh được thực thi cả hai hướng đúng và sai ít nhất một lần. Nếu mã nguồn chứa vòng lặp while lùi ngày nghỉ lễ, chương trình có thể bị lặp vô tận hoặc xử lý sai kỳ nghỉ kép nếu không được bổ sung 4 kịch bản kiểm thử vòng lặp chuyên biệt.

Sự khác biệt cốt lõi giữa kỹ thuật dòng điều khiển và dòng dữ liệu là gì?
Kiểm thử dòng điều khiển tập trung vào chuỗi mệnh lệnh và các nhánh rẽ thực thi của chương trình. Ngược lại, kiểm thử dòng dữ liệu theo dõi vòng đời của biến từ khi khai báo, gán giá trị (def) cho đến khi được sử dụng tính toán hoặc điều kiện (use), giúp phát hiện lỗi dùng biến chưa gán trị hoặc biến mang giá trị mặc định sai.

Làm thế nào để xác định số lượng ca kiểm thử tối ưu cho một đơn vị hàm?
Lập trình viên nên áp dụng công thức tính độ phức tạp xoay vòng bằng số đỉnh quyết định cộng 1 trên đồ thị dòng điều khiển để xác định số đường đi cơ bản, sau đó kết hợp công thức phân tích giá trị biên 4n+1 để bao quát toàn diện các ngưỡng giới hạn dữ liệu đầu vào.

Kết luận

• Luận văn đã hệ thống hóa hoàn chỉnh cơ sở lý luận về kiểm thử đơn vị theo mô hình phát triển chữ V và khung chất lượng phần mềm ISO 9126.
• Thực nghiệm chuyên sâu 4 kỹ thuật kiểm thử đơn vị trên các bài toán nghiệp vụ chứng khoán thực tế, làm rõ năng lực của từng phương pháp.
• Khẳng định ưu thế vượt trội của kiểm thử hộp trắng khi đạt độ bao phủ cấu trúc 100%, khắc phục triệt để lỗ hổng bao phủ 62.5% của kiểm thử hộp đen.
• Đưa ra giải pháp tối ưu hóa bảng quyết định giúp cắt giảm tới 68.75% số lượng ca kiểm thử dư thừa mà vẫn đảm bảo tính toàn vẹn nghiệp vụ.
• Cung cấp chiến lược kiểm thử đơn vị lai kết hợp phân tích giá trị biên, bảng quyết định, đồ thị CFG và DFG cho các kỹ sư công nghệ thông tin.

Đóng góp lớn nhất của luận văn là đã gắn kết chặt chẽ giữa lý thuyết kiểm thử hàn lâm với thực tiễn viết mã nguồn tại doanh nghiệp, đưa ra các chỉ dẫn kỹ thuật định lượng chuẩn xác giúp lập trình viên nâng cao năng suất và chất lượng phần mềm. Trong giai đoạn 2026 - 2027, hướng nghiên cứu tiếp theo sẽ tập trung vào việc tự động hóa quá trình sinh ca kiểm thử đơn vị dựa trên kỹ thuật kiểm thử đột biến (Mutation Testing) và trí tuệ nhân tạo. Độc giả và các kỹ sư phần mềm hãy áp dụng ngay các chiến lược kiểm thử trong công trình này để tối ưu hóa quy trình kiểm thử đơn vị cho các dự án phần mềm quy mô lớn.

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

Chương 1: Đưa ra vấn đế nghiên cứu của luận văn. Từ đó, mô tả khái quát nội dụng nghiên cứu của luận văn. Chương 2: Trình bày kiến thức tổng quan về kiểm thử phần mềm. Chương 3: Trình bày các kỹ thuật kiểm thử phần mềm áp dụng cho mức độ kiểm thử đơn vị.

Chương 4: Đưa bài toán thực tế, tiến hành phân tích, đánh giá, nhận xét và đưa ra chiến lược kiểm thử áp dụng cho bài toán. Chương 5: Kết luận đưa ra kết quả đạt được của luận văn và hướng nghiên cứu tiếp theo của luận văn .thong TIEU LUAN MOI download : [e-mail] 12 Chƣơng 2.Tổng quan về kiểm thử phần mềm Chương 2 trình bày tổng quan về kiểm thử phần mềm.1 Chất lƣợng phần mềm Chất lượng của phần mềm được nhìn theo những hướng khách nhau, khi đứng ở những vai trò khác nhau. Theo [2] thì chất lượng phần mềm được đánh giá theo năm góc nhìn như sau: 1. Góc nhìn tiên nhiệm (Transcendental View): Chất lượng là một thứ gì đó dễ dàng thừa nhận qua kinh nghiệm, nhưng khó được định nghĩa.

Góc nhìn tiên nhiệm không đặc tả riêng rẽ được chất lượng phần mềm, nhờ vào kinh nghiệm người ta có thể đưa ra chất lượng phần mềm là tốt và dễ được công nhận. Góc nhìn người dùng (User View): Chất lượng liên quan đến mức độ mà sản phẩm đáp ứng được nhu cầu, kỳ vọng của người dung, phù hợp cho việc sử dụng. Quan điểm này đánh giá cao cá nhân. Một sản phẩm được coi là chất lượng tốt nếu có đủ một số lượng lớn người dùng.

Quan điểm này rất hữu ích để xác định các thuộc tính sản phẩm mà người dùng cho là quan trọng bao gồm nhiều yêu tố như khả năng sử dụng, độ tin cậy và hiệu quả. Góc nhìn sản xuất (Manufacturing View): Ý tưởng chính của quan điểm này là sự đáp ứng được đặc tả yêu cầu. Chất lượng ở mức độ sản phẩm được xác định bởi việc là sản phẩm có gặp được đặc tả của nó hay không. Bất kỳ một sai lệch nào với yêu cầu đặc tả cũng làm giảm chất lượng sản phẩm.

Việc phù hợp với yêu cầu dẫn đến sự thống nhất của sản phẩm. Góc nhìn sản phẩm (Product View): Giả thuyết đặt ra là:”Nếu một sản phẩm được sản xuất với tính chất nội bộ tốt, thì nó sẽ có các thuộc tính bên ngoài tốt”. Người ta có thể khám phá những mối quan hệ nhân quả giữa các thuộc tính nội bộ và chất lượng bên ngoài. Trong trường hợp này, chất lượng được xem như là một đặc tính vốn có của sản phẩm.

Góc nhìn dựa vào giá trị (Value-Based View): Chất lượng, theo góc nhìn này phụ thuộc vào tổng giá trị mà khách hàng vui lòng trả cho nó. Chất lượng là vô nghĩa nếu một sản phẩm không có ý nghĩa kinh tế. Trong tài liệu về tiêu chuẩn ISO 9126 thì chất lượng phần mềm được định nghĩa trên sáu thuộc tính là: tính năng, tính đáp ứng, tính dễ dùng, tính hiệu quả, tính có thể bảo trì được và tính khả chuyển.2 Kiểm thử và vai trò của kiểm thử Kiểm thử phần mềm đóng một vai trò quan trọng trong việc đảm bảo sự thành công của một sản phẩm phần mềm. Theo tài liệu [2], đảm bảo chất lượng của một sản phẩm phần mềm là cả quá trình cải tiến phầm mềm thông qua việc lặp đi lặp lại quá trình kiểm thử - tìm lỗi – sửa lỗi trong suốt quá trình phát triển phần mềm.

Ứng với từng giai đoạn khác nhau trong quá trình phát triển phần mềm, phải có sự đánh giá (LUAN.thong TIEU LUAN MOI download : [e-mail] 13 hoạt động cách hệ thống có thể hoạt động đúng khi thực hiện kiểm thử ở mức hệ thống trước khi bàn giao sản phẩm. Theo Friedman và Voas đã mô tả thì kiểm thử phần mềm là một quá trình thẩm định cho việc đánh giá và cải thiện chất lượng phần mềm. Thông thường, các hoạt động đánh giá phần mềm được chia làm hai loại:  Phân tích tĩnh (static analysis): Là việc đánh giá chương trình mà không cần thực thi trên các mã lệnh của chương trình, nó có thể là các hoạt động xem xét (review) lại các tài liệu đặc tả, tài liệu thiết kế, tài liệu ca kiểm thử, hoặc là thanh tra mã nguồn (code inspection),.  Phân tích động (dynamic analysis): Là việc đánh giá chương trình mà cần thực thi trên các mã lệnh của chương trình, trong đó có kỹ thuật kiểm thử hộp đen và hộp trắng.

Bằng việc thực hiện phân tích tĩnh và phân tích động thì người kiểm thử viên mong muốn tìm được nhiều lỗi nhất có thể, và đảm bảo các lỗi phát hiện sẽ được sửa trong các giai đoạn sớm của quy trình phát triển phần mềm. Xác minh (Verification) và thẩm định (Validation) là hai công việc xuyên suốt trong quá trình phát triển phần mềm ngay từ giai đoạn phân tích thiết kế phần mềm. Xác minh là việc kiểm tra xem phần mềm có gặp được yêu cầu đặc tả của hệ thống không? Nó trả lời cho câu hỏi “Hệ thống đã được xây dựng đúng theo tài liệu đặc tả hay chưa?”, mục tiêu của viêc xác minh là phát hiện các lỗi lập trình. Thẩm định là sự kiểm tra xem phần mềm có thỏa mãn yêu cầu của người sử dụng không? Việc thẩm định chú trọng vào sản phẩm cuối cùng khi bàn giao cho khách hàng, mục tiêu là phát hiện các lỗi về thiết kế, về đặc tả.

Một hệ thống xây dựng đúng đặc tả, nhưng chưa chắc đã đáp ứng được yêu cầu của khách hàng, vì đặc tả có thể sai, thiết kế có thể thiếu chi tiết, và quá trình sử dụng không thuận tiện cho khách hàng.3 Các mục tiêu của kiểm thử Theo tài liệu [6], các bên liên quan trong quy trình phát triển phần mềm sẽ bao gồm: lập trình viên, kiểm thử viên, quản trị dự án và khách hàng. Mỗi đối tượng này đều có những cái nhìn khác nhau về mục tiêu của kiểm thử như sau:  Chƣơng trình hoạt động đƣợc: Các lập trình viên thường chỉ quan tâm đến việc làm thế nào để chương trình hoạt động được trong các điều kiện thông thường.  Chƣơng trình không hoạt động đƣợc: Lập trình viên ít khi quan tâm đến vấn đề khác của chương trình là khi nào thì chương trình không hoạt động được, làm thế nào khi chương trình bị lỗi.  Giảm rủi ro của lỗi:Nhà quản trị phần mềm thường quan tâm đến khía cạnh là giảm rủi ro của lỗi gây ra.

Hầu hết các hệ thống phần mềm phức tạp đều chứa lỗi - là nguyên nhân hệ thống thất bại. Bởi vậy nếu các lỗi được phát hiện và sửa trong khi thực hiện kiểm thử, tỷ lệ hệ thống gặp rủi ro sẽ giảm.thong TIEU LUAN MOI download : [e-mail] 14  Giảm chi phí của việc kiểm thử: Chi phí cho việc kiểm thử bao gồm chi phí thiết kế, bảo trì và thực thi các ca kiểm thử; chi phí phần tích kết quả thực hiện của mỗi ca kiểm thử; chi phí tài liệu hóa các ca kiểm thử và chi phí cho hệ thống hoạt động và tài liệu hóa các hoạt động đó. Khách hàng thường mong muốn là giảm các chi phí của việc kiểm thử nhưng vẫn đảm bảo chất lượng. Mục tiêu chính của kiểm thử là có thể giám chi phí của việc kiểm thử bằng cách thiết kế các bộ ca kiểm thử hiệu quả bao phủ vùng kiểm thử tốt với số lượng ca kiểm thử ít hơn nhưng chất lượng vẫn được đảm bảo.4 Các hoạt động kiểm thử Theo [2], để kiểm thử một chương trình phần mềm kỹ sư kiểm thử phải thực hiện một chuỗi các hoạt động như sau:  Xác định đối tượng cần kiểm thử: Đối tượng được xác định là mục đích để thiết kế một hay nhiều ca kiểm thử đảm bảo chương trình thỏa mãn đối tượng đó.

Một đối tượng rõ ràng sẽ kết nối tới một ca kiểm thử.  Lựa chọn các giá trị đầu vào: Việc lựa chọn này dựa vào đặc tả yêu cầu, mã nguồn hoặc mong muốn của chúng ta.  Tính toán giá trị đầu ra mong muốn: Tức là ứng với các giái trị đầu vào, cần tính toán giá trị đầu ra mong muốn của chương trình.  Thiết lập môi trường kiểm thử của chương trình: Chuẩn bị môi trường kiểm thử của chương trình, ở bước này tất cả các giả định ngoài của chương trình phải được thỏa mãn.

Ví dụ: các hệ thống mạng, các cơ sở dữ liệu cần được thiết lập một cách đúng đắn, máy tương tác.  Tiến hành kiểm thử chương trình: Kỹ sư kiểm thử thực hiện chương trình với các tập giá trị đầu vào và quan sát giá trị đầu ra thực tế của chương trình. Để thực hiện một ca kiểm thử, các giá trị đầu vào phải được cung cấp cho chương trình ở các thời điểm khác nhau.  Phân tích kết quả kiểm thử: Phân tích các kết quả kiểm thử để so sánh kết quả đầu ra thực tế với kết quả đầu ra mong muốn.

Độ phức tạp của phép so sánh này phụ thuộc vào độ phức tạp của dữ liệu quan sát. Cuối cùng là đưa ra quyết định về kết quả hoạt động của chương trình là thỏa mãn (pass), không thoải mãn (fail) yêu cầu của người dùng hay không đưa ra được quyết định.5 Các mức độ kiểm thử Theo mô hình phát triền phần mềm chữ V thì kiểm thử phần mềm là một chuỗi các hoạt động tiến hình song song cùng hoạt động phát triển phần mềm, từ lập kế hoạch và kiểm soát quá trình kiểm thử, phân tích yêu cầu và thiết kế ca kiểm thử, viết ca kiểm thử,tiến hành kiểm thử phần mềm, đánh giá các kết quả kiểm thử, báo cáo và tổng hợp các hoạt động kết thúc quá trình kiểm thử. Chúng ta có thể nhìn thấy rõ mối (LUAN.thong TIEU LUAN MOI download : [e-mail] 15 liên hệ giữa hoạt động phát triền phần mềm (lập trình) và hoạt động kiểm thử phần mềm (kiểm thử) theo hình 2.1 Mô hình phát triền phầm mềm chữ V Theo mô hình này, các hoạt động kiểm thử phần mềm bao gồm: 1. Kiểm thử đơn vị, 2.

Kiểm thử tích hợp, 3. Kiểm thử hệ thống , 4. Kiểm thử chấp nhận. Mỗi hoạt động này tương ứng với các pha trong phát triển phần mềm từ đặc tả yêu cầu của khách hàng đến hoạt động lập trình.

Kiểm thử đơn vị Theo [2], đơn vị (unit) là một thành phần phần mềm nhỏ nhất mà ta có thể kiểm thử được như hàm, thủ tục, lớp hay phương thức đều có thể được xem là đơn vị. Các thành phần đơn vị này sẽ được kiểm thử tại cấp độ kiểm thử mức đơn vị trong quy trình kiểm thử phần mềm.