Bài viết hôm nay chúng ta sẽ cùng nhau tìm hiểu về kỹ thuật đầu tiên và cơ bản nhất trong Kiểm thử hộp trắng. Đó là Statement Testing – Kiểm thử câu lệnh. Nhưng trước khi bắt đầu, hãy cùng mình tìm hiểu kỹ thuật kiểm thử hộp trắng là gì nhé.
Kiểm Thử Hộp Trắng – White-box Testing Là Gì?
Kiểm thử hộp trắng (White-box Testing hay Structural-based testing) dựa vào cấu trúc bên trong của hệ thống làm cơ sở kiểm thử để rút ra các trường hợp kiểm thử động. Nói cách khác, chúng ta sẽ sử dụng thông tin về cách hệ thống được thiết kế và xây dựng để rút ra các trường hợp kiểm thử.
Câu hỏi đặt ra là: Chúng ta có rất nhiều phương pháp kiểm thử dựa trên đặc điểm kỹ thuật (kiểm thử hộp đen) để lựa chọn. Tại sao chúng ta cần nhiều hơn?
Một hệ thống tốt sẽ cần rất nhiều code xử lý các điều kiện bất thường, các trường hợp đặc biệt có thể xảy ra. Bởi không phải mọi người dùng đều là chuyên gia, chúng ta đôi khi cũng mắc sai lầm. Chúng ta có thể mắc lỗi, nhấn nhiều phím rồi quay đi không đúng lúc. Đôi khi hệ thống ngừng hoạt động, mạng gặp sự cố, hoặc cơ sở dữ liệu bận rộn. Và rồi mọi thử xảy ra… Do vậy, phần mềm cần được viết sao cho khi có sự cố xảy ra, nó không bị crash.
Phần lớn kiểm thử hộp trắng có liên quan đến phạm vi bao phủ. Nó đảm bảo rằng chúng ta đã kiểm thử mọi thứ có thể dựa trên bối cảnh nhu cầu của dự án. Việc sử dụng kiểm thử hộp trắng thay vì kiểm thử hộp đen cho phép chúng ta đo lường mức độ bao phủ mà chúng ta có. Đồng thời nó cũng bổ sung thêm kiểm thử khi cần để đảm bảo rằng chúng ta đã kiểm tra tất cả những thứ chúng ta muốn.
Bao Phủ Câu Lệnh – Statement Coverage
Bao phủ câu lệnh – Statement coverage (Instruction hoặc Code Coverage) là phương pháp kiểm thử phần mềm đo lường mức độ mà các dòng code (hay câu lệnh) trong chương trình đã được thực thi trong quá trình kiểm thử. Để đạt được phạm vi bao phủ của câu lệnh, chúng ta chọn dữ liệu kiểm thử buộc luồng thực thi phải đi qua từng dòng code mà hệ thống chứa.
Khi bạn sử dụng statement coverage, hãy cố gắng đảm bảo rằng mỗi dòng code trong chương trình đã được thực thi ít nhất một lần trong quá trình kiểm thử. Mục tiêu của phương pháp này là tìm ra các dòng code chưa được kiểm tra hoặc không được thực thi trong quá trình kiểm thử. Từ đó giúp chúng ta xác định các lỗ hổng tiềm tàng trong source code của mình.
Tại Sao Phải Kiểm Tra Độ Bao Phủ Câu Lệnh?
Bao phủ câu lệnh là cần thiết bởi những lý do sau đây:
- Việc không kiểm tra một đoạn code sẽ để lại dư lượng lỗi trong chương trình tương ứng với kích thước của code chưa được kiểm tra và xác suất xảy ra lỗi.
- Các đường dẫn có xác suất cao luôn được kiểm tra kỹ lưỡng chỉ để chứng minh rằng hệ thống hoạt động bình thường.
- Lỗi logic và suy nghĩ mờ nhạt tỷ lệ nghịch với xác suất thực hiện đường dẫn.
- Xác suất chủ quan của việc thực hiện một đường dẫn mà người thiết kế quy trình nhìn thấy và xác suất thực hiện khách quan của nó là rất xa nhau. Chỉ phân tích mới có thể tiết lộ xác suất của một đường dẫn và trực giác của hầu hết các lập trình viên về xác suất của đường dẫn đều rất kém.
- Khi đánh giá chủ quan về tầm quan trọng của một đoạn code, người lập trình thường đánh giá thiên vị bởi cảm quan thẩm mỹ, cái tôi và sự quen thuộc. Code thanh lịch có thể được kiểm tra kỹ lưỡng để chứng minh tính sang trọng của nó hoặc để bảo vệ quan niệm cá nhân. Trong khi code đơn giản có thể được kiểm tra sơ sài vì “Làm sao có thể xảy ra sai sót với điều đó?”
Khả Năng Áp Dụng
Việc đạt được phạm vi bao phủ toàn bộ câu lệnh phải được coi là mức tối thiểu đối với tất cả các code đang được kiểm tra, mặc dù điều này không phải lúc nào cũng có thể thực hiện được trong thực tế.
Hạn Chế/ Khó Khăn
Bao phủ mức câu lệnh cũng bị coi là kém hiệu quả nhất trong tất cả các kỹ thuật luồng điều khiển – control flow. Để đạt được mức độ bao phủ khiêm tốn này, người kiểm tra phải đưa ra đủ các trường hợp kiểm thử để buộc mỗi dòng thực thi ít nhất một lần. Mặc dù điều này nghe có vẻ không quá nặng nề nhưng nó phải được thực hiện có mục đích. Một phương pháp hay dành cho nhà phân tích kiểm thử kỹ thuật nâng cao là đảm bảo rằng các nhà phát triển mà họ làm việc cùng quen thuộc với các khái niệm mà chúng ta đang thảo luận ở đây. Việc đạt được (ít nhất) mức độ bao phủ của câu lệnh phải được thực hiện trong khi kiểm thử đơn vị (unit test).
Ví Dụ Về Kiểm Tra Độ Bao Phủ Câu Lệnh
Hãy cùng mình xem xét ví dụ dưới đây để hiểu hơn về kỹ thuật bao phủ câu lệnh này nhé.
Hình trên hiển thị một đoạn code thực sự đơn giản và biểu đồ luồng điều khiển phù hợp.
Test 1 được biểu thị bằng mũi tên màu xám. Ở đây a = 3 và b = 2, rõ ràng a > b thoả mãn điều kiện ở dòng 2 nên z được gán bằng 12 ở dòng 3. Và dòng 4 sẽ thực hiện phép tính 72/12 ta có Rep có kết quả bằng 6.
Như vậy, chỉ cần thực hiện Test 1, độ bao phủ câu lệnh đã đạt được 100%.
Câu hỏi đặt ra là: Liệu mức độ bao phủ câu lệnh có đủ cho kiểm thử hay không?
Ở đây, chúng ta có thể thấy một vấn đề tiềm ẩn khi chỉ dừng lại ở mức độ bao phủ câu lệnh.
Tiếp tục xem xét Test 2 (a = 2, b = 3)
Trong trường hợp này, a không lớn hơn b (tức là quyết định chuyển thành FALSE) và dòng 3 không được thực thi. Không có vấn đề gì lớn phải không? Chúng ta vẫn nằm ngoài if ở dòng 4. Ở đó, phép tính 72/z được thực hiện, chính xác như cách chúng ta mong đợi. Tuy nhiên, có một bất ngờ nhỏ khó chịu vào thời điểm này. Vì z không được đặt lại thành 12 bên trong nhánh nên nó vẫn được đặt thành 0. Do đó, mở rộng phép tính được thực hiện ở dòng 4, chúng ta có 72 chia cho 0.
Ối!
Bạn có thể nhớ ở trường tiểu học rằng bất cứ thứ gì chia cho 0 đều không được xác định. Nghiêm túc mà nói, trong toán học của chúng ta, điều đó đơn giản là không được phép. Vậy máy tính nên làm gì vào thời điểm này? Nếu có một trình xử lý ngoại lệ ở đâu đó trong ngăn xếp thực thi, nó sẽ kích hoạt, giải phóng tất cả các phép tính đã được thực hiện kể từ khi nó được thiết lập. Nếu không có trình xử lý ngoại lệ, hệ thống có thể gặp sự cố!
Bộ xử lý mà hệ thống hiện nay đang chạy có thể có một “điểm dừng cứng – hard stop” được tích hợp trong vi mã cho mục đích này. Trên thực tế, hầu hết các hệ điều hành sẽ không để CPU gặp sự cố với lỗi chia cho 0. Nhưng hệ điều hành có thể sẽ khiến ứng dụng vi phạm biến mất như một cơn ác mộng.
Bạn có thể nói, “chúng tôi đã đạt được mức bao phủ câu lệnh khi tiến hành kiểm thử. Điều này thật không công bằng!” Như chúng tôi đã lưu ý trước đó, bản thân phạm vi bao phủ của câu lệnh đã là mức bao phủ tối thiểu gần như chắc chắn sẽ bỏ sót các lỗi. Chúng ta cần xem xét một mức độ bảo hiểm khác cao hơn có thể phát hiện được loại khiếm khuyết cụ thể này. Cùng mình tiếp tục với các bài viết tiếp theo về kỹ thuật kiểm thử hộp trắng nhé.
Mình xin dừng bài viết hôm nay tại đây. Hẹn gặp lại các bạn trong các bài viết tiếp theo!
Happy Testing!