Phương pháp kiểm thử hộp trắng

Mục Lục Mục Lục 1 LỜI NÓI ĐẦU 2 Phần I. Khái Quát Về Kiểm Thử Phần Mềm- Tổng Quan Về Phương Pháp Kiểm Thử Hộp Trắng 3 I.1. Cơ sở kiểm thử phần mềm 3 I.2. Các mục tiêu kiểm thử 3 I.3. Tiến trình kiểm thử 3 I.4. Chiến lược kiểm thử (Test Strategy) 4 I.4.1Các loại kiểm thử 4 1. Unit Test – Kiểm tra mức đơn vị 5 2. Integration Test – Kiểm tra tích hợp 5 3. System Test - Kiểm tra mức hệ thống 5 4. Acceptance Test 6 I.5. Phương pháp kiểm thử hộp trắng là gì? 6 I.6. Nguyên tắc kiểm thử phần mềm 7 Phần II. Kỹ Thuật Kiểm Thử Hộp Trắng 7 II.1. Làm Thế Nào Để Thực Hiện Kiểm Thử Hộp Trắng 7 II.1.1. Đầu vào 7 II.1.2. Phân tích rủi ro và Chiến lược kiểm thử hộp trắng 8 II.1.3. Xây dựng kế hoạch kiểm thử 9 II.1.4. Xây dựng các ca kiểm thử 9 II.1.5. Môi trường kiểm thử 9 II.1.6. Thực hiện kiểm thử 9 II.2. Các Kỹ Thuật Kiểm Thử Hộp Trắng 10 II.2.1. Kiểm Thử Đường Cơ Bản – Đồ Thị Dòng 10 II.2.2. Kiểm thử dựa trên luồng điều khiên (Control-flow Testing) 16 1) Kiểm thử các biểu thức điều khiển 16 2) Kiểm thử vòng lặp 17 II.2.3. Kiểm thử dựa trên luồng dữ liệu (Data-flow Testing) 19 II.2.4. Kiểm thử đột biến (Mutation Testing) 21 Phần III. Chương trình minh họa 21 III.1. Xây dụng Test Case một chương trình trong Java 21 Các phương pháp hộp trắng 23 TÀI LIỆU THAM KHẢO 27 LỜI NÓI ĐẦU Kiểm thử phần mềm là một phần quan trọng tạo nên thành công của các dự án phần mềm bởi vì một chương trình cho dù có hoàn hảo đến mấy thì cũng sẽ vẫn mang những lỗi về đặc tả. Hiện nay kiểm thử đang rất phổ biến và hấp dẫn đối với những người làm công nghệ thông tin. Kiểm thử phần mềm gồm hai phần việc đòi hỏi những kỹ năng khác nhau đó là kiểm thử hộp trắng (white-box testing) và kiểm thử hộp đen (black-box testing). Trong đề tài này, chúng em đi sâu vào tìm hiểu kiểm thử hộp trắng. Phương pháp này đi sâu đến từng thành phần nhỏ của chương trình, nó đòi hỏi sự hiểu biết cả đến ngôn ngữ lập trình và được sử dụng nhiều. Nếu như kiểm thử phần mềm là cần thiết trong các dự án phần mềm thì kỹ thuật kiểm thử hộp trắng là quan trọng để thiết kế nên các ca kiểm thử đó. Chúng em xin trình bày nội dung đề tài thông qua 3 phần chính: Khái quát về kiểm thử phần mềm – tổng quan về kiểm thử hộp trắng Kỹ thuật kiểm thử hộp trắng Chương trình minh họa xây dựng test case Phần I. Khái Quát Về Kiểm Thử Phần Mềm- Tổng Quan Về Phương Pháp Kiểm Thử Hộp Trắng I.1. Cơ sở kiểm thử phần mềm Quá trình phát triển một hệ thống phần mềm bao gồm một chuổi các hoạt động sản sinh ra mã lênh, tài liệu. Nơi mà những sai sót của con người có thể xãy ra bất kỳ lúc nào. Một lỗi có thể bắt đầu xuất hiện ngay tại lúc bắt đầu của quá trình phát triển, thiết kế, cài đặt. Do đó quá trình phát triển một phần mềm phải kết hợp với một quá trình kiểm thử. Có thể định nghĩa một cách dễ hiểu như sau: Kiểm thử phần mềm là một tiến trình hay một tập hợp các tiến trình được thiết kế để đảm bảo mã hóa máy tính thực hiện theo cái mà chúng đã được thiết kế để làm, và không thực hiện bất cứ thứ gì không mong muốn. Đây là một pha quan trọng trong quá trình phát triển hệ thống, giúp cho người xây dựng hệ thống và khách hàng thấy được hệ thống mới đã đáp ứng yêu cầu đặt ra hay chưa? Kiểm thử phần mềm có thể đươc hiểu như là một bộ đệm giữa quá trình xây dựng phần mềm và triển khai sử dụng phần mềm. I.2. Các mục tiêu kiểm thử Kiểm thử hệ thống là rất đắt đỏ, đối với một vài hệ thời gian thực có các ràng buộc thời gian phức tạp thì việc kiểm thử có thể ngốn hết khoảng nửa tổng chi phí phát triển. Vì thế mà phải lập kế hoạch kiểm thử và khống chế chi phí thử. Mục tiêu của kiểm thử phần mềm là thiết kế những trượng hợp kiểm thử để có thể phát hiện một cách có thệ thống những loại lỗi khác nhau và thực hiện việc đó với lượng thời gian và tài nguyên ít nhất có thể. Đồng thời, quá trình kiểm thử phải thỏa mãn một số yêu cầu sau: Dữ liệu/trạng thái phải mô tả được I.3. Tiến trình kiểm thử Là trình tự thực hiện kiểm tra hệ thống phần mềm từ khi có yêu cầu kiểm tra cho đến khi sản phẩm được thông báo phát hành. Một tiến trình kiểm thử bao gồm các bước Lập kế hoạch kiểm thử (Test Plan) Chuẩn bị môi trường kiểm thử Thiết kế kiểm thử (Test case) Thực hiện kiểm thử Theo dõi và xử lý lỗi Thống kê báo cáo kết quả kiểm tra (Test report) Thông báo phát hành sản phẩm I.4. Chiến lược kiểm thử (Test Strategy) Chiến lược kiểm thử trình bày những phương pháp để kiểm thử các ứng dụng phần mềm. I.4.1Các loại kiểm thử Kiểm thử mức đơn vị lập trình Kiểm thử mức tích hợp các đơn vị Kiểm thử mức hệ thống Kiểm thử để chấp nhận sản phẩm
Tùy yêu cầu và đặc trưng của từng hệ thống, tuỳ khả năng và thời gian cho phép của dự án, khi lập kế hoạch, trưởng dự án sẽ quyết định áp dụng những loại kiểm tra nào. Unit Test – Kiểm tra mức đơn vị Một Unit là một thành phần PM nhỏ nhất mà ta có thể kiểm tra được. Theo định nghĩa này, các hàm (Function), thủ tục (Procedure), lớp (Class), hoặc các phương thức (Method) đều có thể được xem là Unit. Unit Test cũng đòi hỏi phải chuẩn bị trước các tình huống (test case) hoặc kịch bản (script), trong đó chỉ định rõ dữ liệu vào, các bước thực hiện và dữ liệu mong chờ sẽ xuất ra. Các test case và script này nên được giữ lại để tái sử dụng. Integration Test – Kiểm tra tích hợp Integration test kết hợp các thành phần của một ứng dụng và kiểm tra như một ứng dụng đã hoàn thành. Trong khi Unit Test kiểm tra các thành phần và Unit riêng lẻ thì Intgration Test kết hợp chúng lại với nhau và kiểm tra sự giao tiếp giữa chúng. tại một thời điểm được tích hợp vào một nhóm các Unit khác đã tích hợp trước đó và đã hoàn tất (passed) các đợt Integration Test trước đó. Lúc này, ta chỉ cần kiểm tra giao tiếp của Unit mới thêm vào với hệ thống các Unit đã tích hợp trước đó, điều này làm cho số lượng kiểm tra sẽ giảm đi rất nhiều, sai sót sẽ giảm đáng kể. Có 4 loại kiểm tra trong Integration Test: • Kiểm tra cấu trúc (structure): Tương tự White Box Test (kiểm tra nhằm bảo đảm các thành phần bên trong của một chương trình chạy đúng), chú trọng đến hoạt động của các thành phần cấu trúc nội tại của chương trình chẳng hạn các lệnh và nhánh bên trong. • Kiểm tra chức năng (functional): Tương tự Black Box Test (kiểm tra chỉ chú trọng đến chức năng của chương trình, không quan tâm đến cấu trúc bên trong), chỉ khảo sát chức năng của chương trình theo yêu cầu kỹ thuật. • Kiểm tra hiệu năng (performance): Kiểm tra việc vận hành của hệ thống. • Kiểm tra khả năng chịu tải (stress): Kiểm tra các giới hạn của hệ thống. System Test - Kiểm tra mức hệ thống Mục đích System Test là kiểm tra thiết kế và toàn bộ hệ thống (sau khi tích hợp) có thỏa mãn yêu cầu đặt ra hay không. System Test bắt đầu khi tất cả các bộ phận của PM đã được tích hợp thành công. Thông thường loại kiểm tra này tốn rất nhiều công sức và thời gian. Trong nhiều trường hợp, việc kiểm tra đòi hỏi một số thiết bị phụ trợ, phần mềm hoặc phần cứng đặc thù, đặc biệt là các ứng dụng thời gian thực, hệ thống phân bố, hoặc hệ thống nhúng. Ở mức độ hệ thống, người kiểm tra cũng tìm kiếm các lỗi, nhưng trọng tâm là đánh giá về hoạt động, thao tác, sự tin cậy và các yêu cầu khác liên quan đến chất lượng của toàn hệ thống. Điểm khác nhau then chốt giữa Integration Test và System Test là System Test chú trọng các hành vi và lỗi trên toàn hệ thống, còn Integration Test chú trọng sự giao tiếp giữa các đơn thể hoặc đối tượng khi chúng làm việc cùng nhau. Thông thường ta phải thực hiện Unit Test và Integration Test để bảo đảm mọi Unit và sự tương tác giữa chúng hoạt động chính xác trước khi thực hiện System Test. Acceptance Test Mục đích của Acceptance Test là để chứng minh PM thỏa mãn tất cả yêu cầu của khách hàng và khách hàng chấp nhận sản phẩm (và trả tiền thanh toán hợp đồng). Acceptance Test có ý nghĩa hết sức quan trọng, mặc dù trong hầu hết mọi trường hợp, các phép kiểm tra của System Test và Accepatnce Test gần như tương tự, nhưng bản chất và cách thức thực hiện lại rất khác biệt. I.5. Phương pháp kiểm thử hộp trắng là gì? Quá trình thiết kế trường hợp thử là quá trình xây dựng các phương pháp kiểm thử có thể phát hiện lổi ,sai sót khiếm khuyết của phần mềm để xây dựng một phần mềm đạt tiêu chuẩn .Kỹ thuật kiểm thử hộp trắng hay kiểm thử hướng logic cho phép bạn khảo sát cấu trúc bên trong của chương trình. Kỹ thuật này xuất phát từ dữ liệu kiểm thử bằng sự kiểm thử tính logic của chương trình. Kiểm thử viên sẽ truy cập vào cấu trúc dữ liệu và giải thuật bên trong chương trình (và cả mã lệnh thực hiện chúng). Mục đích của bất cứ phương pháp kiểm tra an ninh nào cũng là để đảm bảo rằng tình trạng tốt của một hệ thống trên bề mặt của những sự tấn công độc hại hoặc là những sự thất bại phần mềm thông thường.Kiểm thử hộp trắng là sự thực hiện dựa trên sự hiểu biết về những phần tử của một hệ thống.Kiểm thử hộp trắng bao gồm phân tích dòng dữ liệu, điều khiển dòng, dòng thông tin, mã thực hành, ngoại lệ và những lỗi trình bày trong hệ thống để kiểm tra những hành động của phần mềm không được định hướng trước.Kiểm thử hộp trắng có thể thực hiện để xác định tính hợp lệ cho dù việc triển khai thực hiện sau mã nhằm thiết kế, xác nhận tính hợp lệ để triển khai thực hiện chức năng bảo mật và giảm rủi ro việc bị tấn công ở những chỗ mở có thể khai thác được. Kiểm thử hộp trắng yêu cầu truy nhập vào mã nguồn mặc dù kiểm thử hộp trắng có thể thực hiện tại bất cứ thời điểm nào trong vòng đời của phần mềm sau khi mã được phát triển.Đó là một hành động tốt để thực hiện kiểm thử hộp trắng trong suốt giai đoạn kiểm thử đơn vị. I.6. Nguyên tắc kiểm thử phần mềm Để kiểm thử đạt hiệu quả thì khi tiến hành kiểm thử phần mềm cần phải tuân thủ một số quy tắc sau: Quy tắc 1: Một phần quan trọng của 1 ca kiểm thử là định nghĩa của đầu ra hay kết quả mong muốn. Quy tắc 2: Lập trình viên nên tránh tự kiểm tra chương trình của mình. Quy tắc 3: Nhóm lập trình không nên kiểm thử chương trình của chính họ. Quy tắc 4: Kiểm tra thấu đáo mọi kết quả của mỗi kiểm tra. Quy tắc 5: Các ca kiểm thử phải được viết cho các trạng thái đầu vào không hợp lệ và không mong muốn, cũng như cho các đầu vào hợp lệ và mong muốn. Quy tắc 6: Khảo sát 1 chương trình để xem liệu chương trình có thực hiện cái mà nó cần thực hiện chỉ là 1 phần, phần còn lại là xem liệu chương trình có thực hiện cái mà nó không cần phải thực hiện hay không. Quy tắc 8: Không dự kiến kết quả của kiểm thử theo giả thiết ngầm là không tìm thấy lỗi. Quy tắc 9: Xác suất tồn tại lỗi trong 1 đoạn chương trình là tương ứng với số lỗi đã tìm thấy trong đoạn đó. Quy tắc 10: Kiểm thử là 1 nhiệm vụ cực kỳ sáng tạo và có tính thử thách trí tuệ Phần II. Kỹ Thuật Kiểm Thử Hộp Trắng II.1. Làm Thế Nào Để Thực Hiện Kiểm Thử Hộp Trắng II.1.1. Đầu vào Những thứ chúng ta tạo ra có liên quan đến kiểm thử hộp trắng bao gồm mã nguồn, bản phân tích rủi ro, đặc tả an toàn, tài liệu yêu cầu, tài liệu thiết kế và tài liệu liên quan tới đảm bảo chất lượng. Mã nguồn là quan trọng nhất để thực hiện kiểm thử hộp trắng.Không truy nhập vào mã nguồn thì không thể thực hiện được kiểm thử hộp trắng. Thiết kế kiến trúc và phân tích rủi ro nên được dùng làm chỉ dẫn cho tất cả những hoạt động có liên quan đến kiểm thử hộp trắng, bao gồm kế hoạch kiểm thử, tạo các ca kiểm thử, lựa chọn dữ liệu kiểm thử, lựa chọn kỹ thuật kiểm thử và lựa chọn tiêu chuẩn dừng kiểm thử. Tài liệu thiết kế là cốt yếu để cải thiện việc hiểu chương trình và để phát triển một cách có hiệu quả các ca kiểm thử cái mà thông qua những quyết định thiết kế và giả định. Đặc tả an toàn hay yêu cầu là phải có để hiểu và kích hoạt các tính năng bảo mật của việc thử nghiệm bên dưới phần mềm. Người kiểm thử an toàn nên xem các tài liệu đảm bảo chất lượng để hiểu về chất lượng phần mềm một cách chi tiết để dựa vào đó dự định các chức năng của nó.Tài liệu đảm bảo chất lượng nên bao gồm một chiến lược kiểm thử, một bản kế hoạch kiểm thử, và bản báo cáo những khuyết điểm.Kiểm tra sự thực hiện và vận tải là quan trọng để hiểu những ràng buộc của hệ thống và hành vi của hệ thống bên dưới ứng suất. II.1.2. Phân tích rủi ro và Chiến lược kiểm thử hộp trắng Công việc kiểm thử đòi hỏi người kiểm thử phải phân tích sự hợp lí của qui trình phần mềm, để nhận diện các lỗi và để bảo đảm sản phẩm cuối cùng đáp ứng các yêu cầu. Kiểm thử các phần mềm mấu chốt như hệ thống máy tính của vệ tinh hay máy bay yêu cầu người kiểm thử phải hội tụ vào mọi kịch bản có thể để khử bỏ mọi rủi ro và ngăn ngừa thảm hoạ. Phân tích rủi ro nên được dùng làm chỉ dẫn cho tất cả những hoạt động có liên quan đến kiểm thử hộp trắng, từ chiến lược kiểm thử, đến việc xây dựng các ca kiểm thử. Bước đầu tiên trong kiểm thử hộp trắng là phát triển một chiến lược kiểm thử dựa trên sự phân tích rủi ro.Mục đích của một chiến lược kiểm thử là lọc ra những hoạt động chính phức tạp, tạo những quyết định khóa, và đối mặt những thách thức trong sự nỗ lực kiểm thử.Điều này bao gồm sự nhận biết phạm vi kiểm thử, những kỹ thuật kiểm thử, luận điệu của những thông tin được đưa ra, môi trường kiểm thử và những yêu cầu kỹ năng kiểm thử theo nhóm.Chiến lược kiểm thử phải tính toán một cách xác thực thời gian và tiền bạc kiểm tra những ràng buộc cấm đối với từng thành phần của hệ thống phần mềm, và nên cân bằng hiệu lực kiểm thử với hiệu quả kiểm thử dựa trên phân tích rủi ro hệ thống.Mức độ của hiệu lực tất nhiên phụ thuộc vào mục đích của phần mềm và kết quả những thất bại của nó, chi phí cho sự thất bại của phần mềm càng cao thì sự phức tạp và khắt khe của phương pháp kiểm thử phải đảm bảo hiệu lực. Chiến lược kiểm thử về cơ bản là quản lý hoạt động. Người quản lý kiểm thử chịu trách nhiệm cho phát triển và quản lý một chiến lược kiểm thử. II.1.3. Xây dựng kế hoạch kiểm thử Kế hoạch kiểm thử nên kê khai các chiến lược kiểm thử. Mục đích của kế hoạch kiểm thử là tổ chức cho các tiến trình kiểm thử sau. Nó bao gồm những vùng kiểm thử kín, sự thực hiện của kỹ thuật kiểm thử, các ca kiểm thử và lựa chọn dữ liệu, xác nhận tính hợp lệ của kết quả kiểm thử, chu kỳ kiểm thử, mục nhập và tiêu chuẩn thoát dựa vào ngôn điệu của thông tin được đưa ra. Kế hoạch kiểm thử rất có ích cho việc quản trị, lập kế hoạch và báo cáo. Càng mô tả chi tiết thì ca kiểm thử diễn ra càng trôi chảy. II.1.4. Xây dựng các ca kiểm thử Xây dựng các ca kiểm thử bao gồm những điều kiện tiên quyết, những đặc điểm chung và riêng của những đầu vào kiểm thử, kết quả mong đợi và từng bước thực hiện kiểm thử. Có rất nhiều định nghĩa và các định dạng trong việc mô tả các ca kiểm thử. Mục đích của các ca kiểm thử là để nắm bắt những gì cụ thể mà kiểm thử muốn đạt tới. Phân tích rủi ro, chiến lược kiểm thử, và kế hoạch kiểm thử nên dùng làm hướng dẫn cho sự phát triển các ca kiểm thử. II.1.5. Môi trường kiểm thử Kiểm thử yêu cầu sự tồn tại của một môi trường kiểm thử. Phần cứng và mềm (gồm cả công cụ, ngôn ngữ, phần mềm lớp giữa, và...) đáp ứng yêu cầu người dùng được lựa chọn II.1.6. Thực hiện kiểm thử Thực hiện kiểm thử liên quan đến việc chạy các ca kiểm thử đã được phát triển cho hệ thống và báo cáo các kết quả kiểm thử. II.2. Các Kỹ Thuật Kiểm Thử Hộp Trắng II.2.1. Kiểm Thử Đường Cơ Bản – Đồ Thị Dòng Là một kỹ thuật dùng trong kiểm thử hộp trắng được Tom McCabe đưa ra đầu tiên. Đồ thị dòng gần giống đồ thị luồng điều khiển của chương trình. Nó nhận được từ đồ thị luồng chương trình bằng cách gộp các lệnh tuần tự và thay lệnh rẽ nhánh và các điểm kết thúc của các đường điều khiển bằng một nút vị tự. Kỹ thuật luồng điều khiển là một chiến lược kiểm thử có cấu trúc mà sử dụng luồng điều khiển chương trình như một mô hình. Kỹ thuật luồng điều khiển dựa trên sự lựa chọn cẩn thận một bộ những đường kiểm thử thông qua chương trình. Kỹ thuật đường cơ bản – đồ thị dòng có thể giúp những người thiết kế ca kiểm thử nhận được một độ phức tạp logic của một thủ tục và sử dụng độ phức tạp này như một hướng dẫn hạn chế sự thực hiện một bộ các đường cơ bản. Cấu trúc của đồ thị dòng bao gồm các nút hình tròn biểu thị một hay một số lệnh tuần tự, hoặc thay cho điểm hội tụ các đường điều khiển. Mỗi cạnh nối hai nút biểu diễn dòng điều khiển. Đồ thị dòng chia mặt phẳng thành nhiều miền có nút vị từ biểu thị sự phân nhánh. Các kiểu cấu trúc thành phần đồ thị dòng:
Xét một ví dụ về đồ thị dòng: Biểu đồ điều khiển của chương trình:
Ta được đồ thị dòng như sau: theo quy tắc chuyển đổi ta có: Gộp các lệnh tuần tự ta có các lệnh số: (2,3); (4,5,6) và (9,10). Các điểm rẽ nhánh và kết thúc của các đường điều khiển:1,3, 7, 11 và 12.
Đồ thị trên gồm có: 9 nút trong đó các nút vị tự là: 1,(2,3),7,11 và 12 (màu vàng), 11 cung chia mặt phẳng thành 4 miền. Độ phức tạp của chu trình: Để đảm bảo rằng mọi câu lệnh được thực hiện ít nhất một lần cần tìm được tất cả các đường điều khiển độc lập trong chương trình (khác với các đường khác ít nhất một lệnh). Số các đường độc lập trong một chương trình là giới hạn trên số các kiểm thử cần được tiến hành.Nó được gọi là độ phức tạp chu trình của chương trình. Các đường độc lập của một chương trình trùng với các đường độc lập của đồ thị dòng. Một đường dẫn là một chuỗi các chỉ lệnh mà bắt đầu từ cổng vào của một thủ tục (phương thức) và kết thức ở cổng ra của nó. Một con đường độc lập là một con đường mà đưa vào ít nhất một lệnh hoặc một điều kiện mới hoặc đưa vào ít nhất một cạnh mới trong đồ thị dòng. Một con đường độc lập phải di chuyển tiến lên ít nhất một cạnh mà chưa được đi ngang qua trước khi đường dẫn được định nghĩa. Có ba cách tính độ phức tạp V(G) của đồ thị G như sau: V(G)= E-N+2 đối với ví dụ trên V(G)=11-9+2=4. V(G)= số miền (=4). V(G)= P-1 (=5-1=4). Trong đó E là số cung; N là số nút; P là số nút vị từ. Xác định các ca thử nghiệm: B1: từ một thiết kế hoặc mã vẽ một đồ thị dòng G tương ứng. B2: xác định độ phức tạp của chu trình V(G) tương ứng của nó. B3: xác định tập cơ bản các con đường độc lập. Ví dụ với đồ thị trên ta có độ phức tạp là 4 vậy sẽ có 4 con đường độc lập.Đó là: (1,13); (1,2,3,4,5,6,12,1,13); (1,1,3,7,8,11,12,1,13); (1,2,3,7,9,10,11,12,1,13). B4: chuẩn bị các ca kiểm thử cho mỗi con đường trong tập các con đường đó. B5: chạy các ca kiểm thử và kiểm tra kết quả của chúng. Ma trận kiểm thử: ma trận kiểm thử là một ma trận vuông có kích thước bằng số các nút trong đồ thị dòng. Mỗi dòng/cột tương ứng với tên một nút. Mỗi ô là tên một cung nối nút dòng với nút cột. Nhân liên tiếp k ma trận này được ma trận chỉ số con đường k cũng từ nút dòng tới nút cột. Ma trận kiểm thử được sử dụng như một dữ liệu có cấu trúc để kiểm tra các con đường cơ bản. Khi kiểm thử ta nên thêm trọng số cho các cung của ma trận kiểm thử như sau: Xác suất cung đó được thực thi. Thời gian xử lý của tiến trình đi qua cung đó. Bộ nhớ đòi hỏi của tiến trình đi qua cung đó. Nguồn lực đòi hỏi của tiến trình đi qua cung đó. Xét ví dụ với đồ thị dòng như trên ta có ma trận sau:
Kiểm thử điều kiện mục đích là để sử dụng tất cả những điều kiện logic trong mô-đun chương trình. Có thể xác định: Biểu thức quan hệ ( E1,E2): khi E1 và E2 là các biểu thức số học. Điều kiện đơn: biến Boolean hoặc biểu thức quan hệ có thể được xếp thứ tự bởi một toán tử điều hành NOT. Điều kiện phức hợp: gồm có hai hoặc nhiều hơn những điều kiện đơn toán tử Boolean và những dấu ngoặc đơn. Biểu thức Boolean: điều kiện không có biểu thức quan hệ. Những kiểu lỗi trong điều kiện logic kiểm thử: Sai biến Bool Sai toán tử bool Sai số hạng trong biểu thức toán tử bool Sai toán tử quan hệ Sai biểu thức số học. Phương pháp kiểm thử điều kiện tập trung vào kiểm thử mỗi điều kiện đơn trong chương trình.Một vài chiến lược kiểm thử điều kiện đó là kiểm thử phân nhánh và kiểm thử miền. Chiến lược kiểm thử phân nhánh: là chiến lược mà kiểm thử từng điều kiện trong chương trình.Với mỗi điều kiện phức hợp C thì với mỗi nhánh true và false của C, mỗi điều kiện đơn trong C phải được thực hiện ít nhất một lần. Chiến lược kiểm thử miền: đ