Kiểm Thử Phần Mềm: Phương Pháp Hộp Trắng - Trường Đại Học Phương Đông

I. Tổng Quan Về Kiểm Thử Hộp Trắng Soi Sâu Vào Mã Nguồn

Kiểm thử hộp trắng, hay còn được biết đến với các tên gọi như kiểm thử hộp kính (Glass Box Testing), kiểm thử cấu trúc (Structural Testing), là một phương pháp kiểm thử phần mềm cốt lõi, nơi người kiểm thử (tester) có toàn quyền truy cập và hiểu biết sâu sắc về cấu trúc bên trong của hệ thống. Thay vì chỉ tương tác với giao diện người dùng như phương pháp hộp đen, kiểm thử hộp trắng tập trung vào việc phân tích mã nguồn (source code), các thuật toán, và luồng dữ liệu để xác minh rằng mọi thành phần hoạt động đúng như thiết kế. Mục tiêu chính không chỉ là tìm lỗi, mà còn là để tối ưu hóa code, đảm bảo logic chương trình chặt chẽ và tăng cường bảo mật. Phương pháp này thường được áp dụng ở các mức độ kiểm thử ban đầu như kiểm thử đơn vị (unit test) và kiểm thử tích hợp (integration test), do chính các lập trình viên hoặc các kỹ sư QA/QC có kỹ năng lập trình thực hiện. Bằng cách kiểm tra từng dòng lệnh, từng nhánh rẽ và vòng lặp, kiểm thử hộp trắng cung cấp một cái nhìn toàn diện về chất lượng bên trong của phần mềm, giúp phát hiện các lỗi logic và lỗ hổng tiềm ẩn mà các phương pháp khác có thể bỏ qua. Đây là một bước không thể thiếu trong quy trình phát triển phần mềm hiện đại, đặc biệt là trong các dự án đòi hỏi độ tin cậy và an toàn cao.

1.1. Định nghĩa kiểm thử hộp trắng Phương pháp hộp kính là gì

Theo định nghĩa từ tài liệu gốc, Kiểm thử Hộp Trắng (White Box Testing) là một phương pháp mà người kiểm thử "biết về cấu trúc nội bộ / thiết kế" của phần mềm. Tên gọi "hộp kính" hay "hộp trong suốt" (Transparent Box) mô tả chính xác bản chất của nó: mọi thứ bên trong phần mềm, từ mã nguồn, kiến trúc, đến luồng điều khiển và luồng dữ liệu, đều được phơi bày để kiểm tra. Người thực hiện không chỉ nhập dữ liệu đầu vào và xem kết quả đầu ra, mà còn phải chọn các đầu vào một cách chiến lược để thực thi các đường dẫn cụ thể trong mã, qua đó xác định xem đầu ra có chính xác với logic đã lập trình hay không. Điều này đòi hỏi người kiểm thử phải có kiến thức lập trình và hiểu biết sâu về hệ thống đang được xây dựng.

1.2. Mục tiêu chính Tại sao phải kiểm thử cấu trúc bên trong

Mục tiêu của kiểm thử hộp trắng vượt ra ngoài việc tìm lỗi đơn thuần. Nó hướng đến việc đảm bảo chất lượng từ gốc rễ của sản phẩm. Các mục tiêu chính bao gồm: 1) Xác minh tất cả các đường dẫn độc lập trong một module đã được thực thi ít nhất một lần. 2) Kiểm tra tất cả các quyết định logic (nhánh đúng/sai của câu lệnh if, case) đã được kiểm tra. 3) Thực thi tất cả các vòng lặp (loops) ở các cận trên, cận dưới và trong giới hạn hoạt động của chúng. 4) Kiểm tra các cấu trúc dữ liệu nội bộ để đảm bảo tính hợp lệ. Quan trọng hơn, phương pháp này giúp tối ưu hóa code bằng cách loại bỏ các đoạn mã không cần thiết hoặc kém hiệu quả và phát hiện lỗ hổng bảo mật tiềm ẩn ngay từ giai đoạn phát triển, giảm thiểu chi phí sửa lỗi về sau.

1.3. So sánh nhanh Kiểm thử hộp trắng và kiểm thử hộp đen

Sự khác biệt cơ bản giữa hai phương pháp này nằm ở góc độ tiếp cận. Kiểm thử hộp trắng tập trung vào cấu trúc bên trong và logic của mã nguồn. Nó được thực hiện bởi những người có kiến thức lập trình (thường là lập trình viên) và áp dụng ở các cấp độ thấp như kiểm thử đơn vị và tích hợp. Kịch bản kiểm thử (test case) được thiết kế dựa trên tài liệu thiết kế chi tiết. Ngược lại, kiểm thử hộp đen xem phần mềm như một "hộp đen" bí ẩn, chỉ quan tâm đến chức năng: nhập đầu vào và kiểm tra đầu ra có đúng với yêu cầu hay không, mà không cần biết bên trong xử lý thế nào. Nó thường được thực hiện bởi đội ngũ QA/QC và áp dụng ở các cấp độ cao hơn như kiểm thử hệ thống và kiểm thử chấp nhận, dựa trên tài liệu yêu cầu người dùng.

II. Ưu và Nhược Điểm Của Phương Pháp Kiểm Thử Hộp Trắng

Giống như bất kỳ phương pháp kỹ thuật nào, kiểm thử hộp trắng sở hữu những ưu điểm vượt trội nhưng cũng đi kèm với những thách thức đáng kể. Việc hiểu rõ hai mặt của vấn đề giúp các đội ngũ phát triển phần mềm có thể áp dụng phương pháp này một cách hiệu quả và đúng thời điểm. Về mặt ưu điểm, khả năng "nhìn thấu" mã nguồn cho phép phát hiện lỗi sớm ngay từ giai đoạn coding, giúp tiết kiệm chi phí và thời gian sửa lỗi một cách đáng kể. Nó cho phép thực hiện kiểm thử một cách kỹ lưỡng, bao phủ gần như toàn bộ các đường dẫn logic, từ đó nâng cao chất lượng và độ tin cậy của sản phẩm. Hơn nữa, quá trình này còn thúc đẩy việc tối ưu hóa code, loại bỏ những đoạn mã thừa và cải thiện hiệu suất. Tuy nhiên, nhược điểm lớn nhất của nó là yêu cầu cao về kỹ năng. Người thực hiện phải có kiến thức sâu về lập trình và cấu trúc hệ thống. Quá trình này cũng tiêu tốn nhiều thời gian và nguồn lực, đặc biệt với các hệ thống lớn và phức tạp. Việc phải cập nhật lại các kịch bản kiểm thử mỗi khi mã nguồn thay đổi cũng là một thách thức không nhỏ. Ngoài ra, vì tập trung vào logic bên trong, kiểm thử hộp trắng có thể bỏ sót các lỗi liên quan đến yêu cầu người dùng hoặc lỗi thiết kế ở cấp độ cao.

2.1. Lợi ích vượt trội Tối ưu hóa code và phát hiện lỗi sớm

Ưu điểm lớn nhất của kiểm thử hộp trắng là khả năng can thiệp sâu vào quá trình phát triển. Tài liệu nghiên cứu chỉ rõ, "Test có thể bắt đầu ở giai đoạn sớm hơn, không cần phải chờ đợi cho GUI". Điều này cho phép phát hiện lỗi logic, lỗi thuật toán ngay khi chúng vừa được viết ra, giảm thiểu chi phí sửa chữa so với việc phát hiện ở giai đoạn sau. Thứ hai, nó cho phép kiểm thử một cách toàn diện. Với việc phân tích độ bao phủ mã (code coverage), đội ngũ có thể đảm bảo rằng hầu hết các đường dẫn quan trọng đều đã được kiểm tra. Cuối cùng, chính các lập trình viên khi viết test case cho mã của mình sẽ có cơ hội rà soát lại logic, từ đó giúp tối ưu hóa code và viết mã sạch hơn, dễ bảo trì hơn.

2.2. Thách thức cần biết Yêu cầu kỹ năng và nguồn lực cao

Mặt trái của phương pháp này là những yêu cầu khắt khe. Nhược điểm chính là "yêu cầu những người thực hiện phải có kiến thức sâu sắc về nguồn mã hóa và phần mềm cấu trúc". Điều này giới hạn đối tượng có thể thực hiện, thường là các lập trình viên hoặc các kỹ sư Developer in Test. Đối với các hệ thống lớn, việc viết test case để bao phủ toàn bộ logic có thể trở nên cực kỳ phức tạp và tốn thời gian. Hơn nữa, kiểm thử hộp trắng gắn chặt với mã nguồn, do đó khi mã nguồn thay đổi, các test case cũng phải được cập nhật tương ứng, tạo ra gánh nặng bảo trì. Một điểm yếu khác là nó "không thể phát hiện lỗi thiết kế" ở mức độ tổng thể, vì nó chỉ tập trung vào việc mã có được triển khai đúng theo thiết kế chi tiết hay không, chứ không đánh giá được bản thân thiết kế đó có hợp lý không.

III. Top Các Kỹ Thuật Kiểm Thử Hộp Trắng Phổ Biến Nhất

Để thực hiện kiểm thử cấu trúc một cách hiệu quả, các kỹ sư phần mềm không dựa vào cảm tính mà áp dụng những kỹ thuật đã được chuẩn hóa. Các kỹ thuật này tập trung vào một mục tiêu chung: đạt được độ bao phủ mã (code coverage) cao nhất có thể, đảm bảo các phần quan trọng của mã nguồn đều được thực thi và kiểm tra. Độ bao phủ mã là một chỉ số đo lường mức độ mã nguồn của một chương trình được thực thi khi một bộ kiểm thử cụ thể chạy. Kỹ thuật cốt lõi và nền tảng nhất là phân tích luồng điều khiển (control flow) và luồng dữ liệu (data flow). Từ đây, các kỹ thuật cụ thể hơn được phát triển, bao gồm kiểm thử bao phủ dòng lệnh (statement coverage), yêu cầu mỗi dòng lệnh phải được chạy ít nhất một lần; kiểm thử bao phủ nhánh (branch coverage), yêu cầu mỗi nhánh quyết định (true/false của câu lệnh if) phải được kiểm tra; và phức tạp hơn là kiểm thử bao phủ đường đi (path coverage), nhằm mục tiêu kiểm tra mọi đường đi khả thi trong một chương trình. Việc lựa chọn kỹ thuật nào phụ thuộc vào mức độ quan trọng của module, yêu cầu của dự án và nguồn lực cho phép. Mỗi kỹ thuật cung cấp một mức độ đảm bảo chất lượng khác nhau.

3.1. Phân tích độ bao phủ mã Code Coverage chi tiết

Độ bao phủ mã là trái tim của các kỹ thuật kiểm thử hộp trắng. Nó không trực tiếp tìm ra lỗi, nhưng nó chỉ ra những phần nào của mã chưa được kiểm thử. Một tỷ lệ bao phủ 100% không đảm bảo phần mềm không có lỗi, nhưng một tỷ lệ thấp chắc chắn cho thấy việc kiểm thử chưa đầy đủ. Các công cụ hiện đại như JaCoCo cho Java hay gcov cho C/C++ có thể tự động đo lường chỉ số này. Việc phân tích kết quả bao phủ giúp đội ngũ xác định các lỗ hổng trong bộ kịch bản kiểm thử của mình và bổ sung các trường hợp cần thiết để tăng cường chất lượng và giảm thiểu rủi ro.

3.2. Kỹ thuật bao phủ dòng lệnh nhánh và điều kiện

Đây là các cấp độ phổ biến nhất của độ bao phủ. Bao phủ Dòng lệnh (Statement Coverage) là mức cơ bản nhất, đảm bảo mọi dòng code thực thi đều được chạy qua. Bao phủ Nhánh (Branch Coverage), hay còn gọi là bao phủ quyết định, yêu cầu mọi kết quả của một biểu thức điều kiện (ví dụ, cả nhánh if và else) đều phải được thực thi. Đây là một tiêu chuẩn mạnh hơn bao phủ dòng lệnh. Cao hơn nữa là Bao phủ Điều kiện (Condition Coverage), yêu cầu mỗi điều kiện con trong một biểu thức logic phức hợp phải được đánh giá là true và false ít nhất một lần. Việc kết hợp các kỹ thuật này giúp đảm bảo logic chương trình được kiểm tra một cách toàn diện.

3.3. Phương pháp kiểm thử đường cơ bản và đồ thị dòng

Phương pháp kiểm thử đường cơ bản (Basis Path Testing), do Tom McCabe đề xuất, là một kỹ thuật nâng cao sử dụng đồ thị dòng điều khiển (control flow graph) để biểu diễn logic của chương trình. Kỹ thuật này tính toán một chỉ số gọi là Độ phức tạp Cyclomatic (Cyclomatic Complexity), đại diện cho số lượng các đường đi độc lập tối thiểu trong chương trình. Dựa vào chỉ số này, người kiểm thử sẽ thiết kế một bộ kịch bản kiểm thử tối thiểu nhưng vẫn đảm bảo rằng tất cả các câu lệnh và quyết định trong chương trình đều được thực thi ít nhất một lần. Đây là một cách tiếp cận có hệ thống để đạt được độ bao phủ nhánh 100%.

IV. Hướng Dẫn Quy Trình Thực Hiện Kiểm Thử Hộp Trắng A Z

Thực hiện kiểm thử hộp trắng không phải là một công việc ngẫu hứng mà cần tuân theo một quy trình có cấu trúc để đảm bảo hiệu quả và tính nhất quán. Quy trình này bắt đầu từ việc hiểu sâu về đối tượng cần kiểm thử và kết thúc bằng việc phân tích, báo cáo kết quả. Về cơ bản, quy trình này có thể được chia thành hai bước chính như tài liệu đề cập: (1) Hiểu mã nguồn và (2) Tạo và thực thi các trường hợp kiểm thử. Tuy nhiên, để chi tiết hóa cho một quy trình chuyên nghiệp, chúng ta có thể mở rộng thành các bước nhỏ hơn. Đầu tiên là giai đoạn phân tích, nơi các kỹ sư nghiên cứu mã nguồn, tài liệu thiết kế để xác định các luồng điều khiển, các nhánh logic và các đường đi quan trọng. Tiếp theo là giai đoạn thiết kế kịch bản kiểm thử (test case), nơi các bộ dữ liệu đầu vào được tạo ra một cách có chủ đích để kích hoạt các đường dẫn đã xác định. Giai đoạn thứ ba là thực thi, thường được tự động hóa bằng các framework như JUnit hay NUnit. Cuối cùng là giai đoạn phân tích kết quả, so sánh kết quả thực tế với mong đợi và đo lường độ bao phủ mã để đánh giá mức độ hoàn thiện của việc kiểm thử.

4.1. Bước 1 2 Phân tích mã nguồn và thiết kế kịch bản kiểm thử

Đây là bước nền tảng. Theo tài liệu, "điều đầu tiên mà người kiểm thử cần làm là học và hiểu mã nguồn của ứng dụng". Kỹ sư cần phân tích các module, hàm, các câu lệnh điều kiện, và vòng lặp để vẽ ra một sơ đồ luồng điều khiển. Dựa trên phân tích này, họ sẽ thiết kế các kịch bản kiểm thử. Ví dụ, đối với một hàm có câu lệnh if (a > 0), kịch bản kiểm thử phải bao gồm ít nhất hai trường hợp: một trường hợp với a dương để kiểm tra nhánh if, và một trường hợp với a không dương để kiểm tra nhánh else (nếu có).

4.2. Bước 2 3 Thực thi kiểm thử đơn vị và kiểm thử tích hợp

Sau khi có các kịch bản, bước tiếp theo là thực thi chúng. Ở cấp độ thấp nhất, kiểm thử đơn vị (unit test) được thực hiện trên từng hàm hoặc lớp riêng lẻ. Các lập trình viên sẽ viết mã kiểm thử (test code) sử dụng các framework chuyên dụng để gọi hàm cần test với các dữ liệu đã chuẩn bị và xác minh kết quả. Ở cấp độ cao hơn, kiểm thử tích hợp (integration test) được thực hiện để kiểm tra sự tương tác và luồng dữ liệu giữa các module đã được kiểm thử đơn vị. Quá trình này giúp đảm bảo rằng khi các thành phần được kết hợp lại, chúng vẫn hoạt động đúng như mong đợi.

4.3. Bước 4 5 Đánh giá kết quả và hoàn tất quy trình

Sau mỗi lần thực thi, kết quả sẽ được ghi lại. Các trường hợp thất bại (failed) chỉ ra sự tồn tại của lỗi và cần được báo cáo chi tiết để lập trình viên sửa chữa. Song song đó, các công cụ sẽ tạo ra báo cáo độ bao phủ mã. Dựa trên báo cáo này, đội ngũ sẽ đánh giá xem việc kiểm thử đã đủ toàn diện chưa. Nếu độ bao phủ còn thấp ở những khu vực quan trọng, cần phải bổ sung thêm kịch bản kiểm thử. Quy trình kết thúc khi các tiêu chí hoàn thành (exit criteria), ví dụ như tỷ lệ bao phủ đạt ngưỡng yêu cầu và không còn lỗi nghiêm trọng, được đáp ứng.

V. Ứng Dụng JUnit Để Kiểm Thử Hộp Trắng Case Study Cụ Thể

Lý thuyết sẽ trở nên dễ hiểu hơn khi được minh họa bằng một ví dụ thực tế. Tài liệu nghiên cứu đã cung cấp một case study chi tiết về việc sử dụng JUnit, một framework kiểm thử đơn vị hàng đầu cho ngôn ngữ Java, để thực hiện kiểm thử hộp trắng cho một chương trình máy tính đơn giản. Case study này cho thấy cách một lập trình viên hoặc developer in test có thể áp dụng các nguyên tắc của kiểm thử hộp trắng vào công việc hàng ngày. Quá trình bao gồm việc thiết lập môi trường, viết các lớp kiểm thử (test classes), định nghĩa các kịch bản kiểm thử cụ thể cho từng chức năng (cộng, trừ, nhân, chia, và xử lý lỗi chia cho 0), và cuối cùng là chạy kiểm thử và phân tích kết quả. Việc sử dụng một công cụ như JUnit không chỉ giúp tự động hóa quá trình thực thi mà còn cung cấp các cơ chế mạnh mẽ như Assertions để xác minh kết quả và các báo cáo trực quan. Hơn nữa, nó còn tích hợp với các công cụ đo độ bao phủ mã, giúp lượng hóa hiệu quả của việc kiểm thử, biến một khái niệm trừu tượng thành những con số cụ thể.

5.1. Giới thiệu JUnit Framework hàng đầu cho kiểm thử đơn vị Java

JUnit là một framework mã nguồn mở, miễn phí và cực kỳ phổ biến trong cộng đồng Java, được thiết kế để viết và chạy các bài kiểm tra lặp lại. Theo tài liệu, nó "cung cấp các annotation để định nghĩa các phương thức kiểm thử" (ví dụ @Test) và "cung cấp các Assertion để kiểm tra kết quả mong đợi" (ví dụ assertEquals). Các tính năng này giúp cấu trúc mã kiểm thử trở nên rõ ràng, dễ đọc và dễ bảo trì. JUnit là công cụ lý tưởng để thực hiện kiểm thử đơn vị, mức kiểm thử mà phương pháp hộp trắng được áp dụng phổ biến nhất.

5.2. Case study Thực hiện test chương trình máy tính với JUnit

Trong ví dụ, chương trình máy tính với giao diện đồ họa được chọn làm đối tượng kiểm thử. Các kịch bản kiểm thử được thiết kế để bao phủ các chức năng chính: phép cộng (5+3=8), phép trừ (9-4=5), phép nhân, phép chia, và một trường hợp đặc biệt là chia cho 0 (9/0 = Error). Người thực hiện đã viết một lớp MayTinhTest với các phương thức tương ứng cho mỗi kịch bản. Bên trong mỗi phương thức, mã sẽ mô phỏng hành động của người dùng (bấm nút) và sau đó sử dụng assertEquals để so sánh kết quả hiển thị trên màn hình với kết quả mong đợi. Kết quả "Pass 100%" cho thấy logic tính toán bên trong của chương trình đã hoạt động chính xác theo các trường hợp đã kiểm tra.

5.3. Phân tích kết quả Đo lường độ bao phủ và đánh giá lỗi

Ngoài việc kiểm tra tính đúng đắn, case study còn tiến hành kiểm thử độ bao phủ code. Bằng cách sử dụng plugin trong Eclipse, sau khi chạy các chức năng, một báo cáo trực quan được tạo ra, tô màu những dòng code đã được thực thi và những dòng bị bỏ qua. Kết quả cho thấy "độ bao phủ code của chương trình khá cao, chỉ 1 số dòng code không được thực hiện". Phân tích này cực kỳ giá trị, nó giúp người kiểm thử biết chính xác những phần nào của mã nguồn chưa được chạm tới, từ đó có thể thiết kế thêm các kịch bản kiểm thử bổ sung để cải thiện chất lượng.

VI. Tương Lai Của Kiểm Thử Hộp Trắng Tích Hợp AI Bảo Mật

Kiểm thử hộp trắng, dù là một phương pháp lâu đời, vẫn đang liên tục phát triển để đáp ứng những thách thức của ngành công nghiệp phần mềm hiện đại. Trong tương lai, vai trò của nó sẽ càng trở nên quan trọng hơn, đặc biệt trong hai lĩnh vực: bảo mật ứng dụng và tự động hóa thông minh. Với sự phức tạp ngày càng tăng của các ứng dụng, việc phát hiện lỗ hổng bảo mật sớm trong chu trình phát triển (Shift-Left Security) là một yêu cầu cấp thiết. Các kỹ thuật kiểm thử hộp trắng là nền tảng cho các công cụ Kiểm thử Bảo mật Ứng dụng Tĩnh (SAST), tự động quét mã nguồn để tìm ra các mẫu code nguy hiểm. Bên cạnh đó, sự trỗi dậy của Trí tuệ Nhân tạo (AI) và Học máy (Machine Learning) hứa hẹn sẽ cách mạng hóa phương pháp này. AI có thể được sử dụng để tự động tạo ra các kịch bản kiểm thử hiệu quả, ưu tiên các đường dẫn có rủi ro cao, hoặc thậm chí dự đoán các khu vực có khả năng chứa lỗi dựa trên lịch sử thay đổi mã nguồn. Vai trò của kỹ sư QA/QC và Developer in Test cũng sẽ thay đổi, tập trung nhiều hơn vào việc thiết kế các chiến lược kiểm thử thông minh thay vì thực thi thủ công.

6.1. Vai trò trong phát hiện lỗ hổng bảo mật ứng dụng SAST

Kiểm thử hộp trắng là cốt lõi của SAST. Các công cụ SAST hoạt động bằng cách phân tích 100% mã nguồn của ứng dụng mà không cần chạy nó. Chúng xây dựng một mô hình của ứng dụng, theo dõi các luồng dữ liệu và luồng điều khiển để tìm ra các lỗ hổng bảo mật phổ biến như SQL injection, cross-site scripting (XSS), hay tràn bộ đệm. Kỹ thuật này, vốn là một dạng kiểm thử hộp trắng tự động hóa ở quy mô lớn, giúp phát hiện lỗ hổng bảo mật từ rất sớm, ngay tại máy của lập trình viên, trước khi mã được đưa vào hệ thống quản lý phiên bản, giúp tiết kiệm chi phí khắc phục một cách khổng lồ.

6.2. Xu hướng tự động hóa và vai trò của Developer in Test

Để đáp ứng tốc độ của các quy trình DevOps và CI/CD, việc tự động hóa kiểm thử là bắt buộc. Kiểm thử hộp trắng, đặc biệt là kiểm thử đơn vị và kiểm thử tích hợp, là những ứng cử viên hàng đầu cho tự động hóa. Xu hướng này đã làm nổi bật vai trò của Software Developer in Test (SDET). Đây là những kỹ sư có kỹ năng của cả lập trình viên và người kiểm thử. Họ không chỉ thực hiện kiểm thử mà còn xây dựng các framework, công cụ và hạ tầng để tự động hóa quá trình kiểm thử một cách hiệu quả. Họ chính là những chuyên gia về kiểm thử hộp trắng, đảm bảo chất lượng được tích hợp liền mạch vào quy trình phát triển.

Bài Tập Lớn: Kiểm Chứng Phần Mềm Bằng Phương Pháp Hộp Trắng (ĐH Phương Đông)

Mục lục

1. CHƯƠNG I. KIỂM THỬ PHẦN MỀM

1.1. Kiểm thử phần mềm

1.2. Các mức kiểm thử (test levels)

1.3. Các loại kiểm thử (test types)

1.4. Quy trình kiểm thử phần mềm

2. CHƯƠNG II. KIỂM THỬ HỘP TRẮNG

2.1. Kiểm thử hộp trắng là gì?

2.2. Đối tượng áp dụng

2.3. Ưu điểm và nhược điểm

2.4. So sánh phương pháp kiểm thử hộp trắng với phương pháp kiểm thử hộp đen

2.5. Các dạng kiểm thử hộp trắng

2.5.1. Kiểm thử đơn vị

2.5.2. Kiểm tra rò rỉ bộ nhớ

2.5.3. Thử nghiệm thâm nhập

2.5.4. Kiểm thử đột biến trắng

2.6. Các phương pháp và kỹ thuật kiểm thử hộp trắng

2.6.1. Phương pháp kiểm thử đường cơ bản – đồ thị dòng

2.6.2. Phương pháp kiểm thử dựa trên luồng điều khiển

2.7. Các bước thực hiện kiểm thử hộp trắng

3. CHƯƠNG III. KIỂM THỬ CHƯƠNG TRÌNH MÁY TÍNH SỬ DỤNG JUNIT TRONG ỨNG DỤNG ECLIPSE

3.1. Giới thiệu JUnit

3.2. Một số khái niệm trong JUnit

3.3. Các bước tiến hành kiểm thử với JUnit trong IDE Eclipse

3.4. Kiểm thử chương trình với JUnit

3.4.1. Chương trình cần kiểm thử

3.4.2. Thiết lập JUnit để tiến hành kiểm thử (Tạo lớp kiểm thử trong Eclipse)

3.4.3. Thực hiện kiểm thử:

3.5. Kiểm thử độ bao phủ code (Coverage):

TÀI LIỆU THAM KHẢO