Unit Test là gì? Những điều bạn nên biết về Unit Test

Vòng lặp của quy trình phát triển phần mềm có thể được kết thúc (tiến sang giai đoạn deploy) tại công đoạn kiểm tra. Vì vậy, các công ty đều rất chú trọng đến giai đoạn này. Unit Test là một kiểm thử phần mềm được sử dụng nhiều nhất trong thị trường hiện nay. Vậy phần mềm kiểm thử có tên Unit Test này là gì?

Trong bài viết dưới đây, GrowUpWork sẽ giải thích chi tiết về Unit Test và những điều cần biết và lưu ý về công đoạn test đầu tiên nhưng rất quan trọng này. 
Hãy cùng bắt đầu tìm hiểu nhé!

Giới thiệu về kiểm thử phần mềm

Việc chạy thử và kiểm tra sản phẩm phần mềm (kiểm thử phần mềm) trước khi giao cho khách hàng là một công việc cần thiết. Vậy các cấp độ kiểm tra (test levels) để đạt được chất lượng cao là gì? Dưới đây là 4 cấp độ kiểm thử phần mềm chính:

Có 4 cấp độ kiểm thử khác nhau:

• Kiểm thử đơn vị (Unit Testing): Kiểm thử ở mức cơ bản (kiểm tra mọi chức năng, mọi màn hình,…).  Kiểm tra xem từng đơn vị cần kiểm tra có thực hiện đúng chức năng mà đơn vị đó cần thực hiện hay không.
• Kiểm tra tích hợp (Integration Testing): Kiểm tra mức độ tích hợp. Tích hợp các chức năng với nhau, tích hợp màn hình trong một mô-đun hoặc theo cách dựa trên chức năng. 
• Kiểm tra hệ thống (System Testing): Kiểm tra mức hệ thống. Tích hợp tất cả các chức năng vào một phần mềm và mô-đun hoàn chỉnh. 
• Kiểm thử chấp nhận (Acceptance Testing): Mức độ kiểm thử này tương tự như kiểm thử hệ thống. Nhưng nó thường được khách hàng kiểm tra để xem phần mềm có đáp ứng được yêu cầu của khách hàng hay không.

Trong phạm vi bài viết này, chúng ta sẽ chỉ đi sâu vào kiểm thử đơn vị (Unit Testing).

Unit Testing là gì?

Kiểm thử đơn vị hay Unit Testing là công đoạn đầu tiên của quy trình kiểm thử phần mềm. Mục đích kiểm tra là xem mỗi đơn vị nhỏ nhất của phần mềm có đang phát triển theo kế hoạch hay không. Kiểm thử đơn vị là mức kiểm thử nhỏ nhất trong bất kỳ phần mềm nào. Các hàm (function), thủ tục (procedure), lớp (class) hoặc phương thức (method) có thể được xem như các đơn vị này. 

Thông thường nó có một hoặc nhiều đầu vào, nhưng chỉ có một đầu ra. Nó được thực hiện bởi các lập trình viên và là White-box testing. Nó được thực hiện càng sớm càng tốt trong giai đoạn mã hóa và trong suốt quá trình phát triển phần mềm.

Mục tiêu của Unit Testing

Mục tiêu của đơn vị kiểm thử là tập trung vào các thành phần có thể kiểm tra riêng biệt.

• Xác minh hoạt động chức năng và phi chức năng của thành phần.
• Để cải thiện chất lượng mã, Unit Testing tập trung vào nhiều khía cạnh của chức năng. Xác định bất kỳ khiếm khuyết nào có thể xảy ra để giúp giảm lỗi và cải thiện chất lượng mã.
• Phát hiện sớm các lỗi, sự cố thiết kế, xử lý hệ thống và thậm chí cả các mô hình thiết kế.
• Tạo hàng rào bảo vệ an toàn cho khối mã.

Tuy nhiên, bạn không nên hiểu rằng Unit Testing được sử dụng để tìm lỗi. Theo định nghĩa, các đơn vị kiểm thử kiểm tra từng đơn vị mã riêng biệt. Nhưng khi ứng dụng của bạn đang chạy trong thế giới thực, tất cả các đơn vị phải làm việc cùng nhau. Vì thế sẽ trở nên phức tạp hơn tổng các phần riêng lẻ của bài kiểm tra độc lập.

Viết Unit Test là một quá trình thiết kế, không phải là một quá trình kiểm tra sản phẩm. Viết một bài đơn vị kiểm thử buộc bạn phải suy nghĩ rõ ràng về thiết kế của mình. Xác định đầu vào và đầu ra mong đợi của từng đơn vị riêng lẻ và do đó chỉ định các thành phần, lớp, mô-đun,... 

Thành phần Test

Một đơn vị (Unit) là thành phần nhỏ nhất mà chúng ta có thể kiểm tra. Chẳng hạn như các hàm (function), thủ tục (thủ tục), Class (lớp) hoặc phương thức (method), mô-đun cơ sở dữ liệu ...

Developers nên thực hiện Unit Test khi nào? 

Khi bạn nhận được một công việc, bạn thường làm như sau: Đọc Yêu cầu - Viết Mã - Có lỗi - Sửa lỗi.
Tuy nhiên, có một gợi ý hữu ích cho bạn là viết Unit Test trước khi triển khai mã code. Điều đó giúp ích cho việc định hướng hơn. Thiết kế chương trình chi tiết, giúp bạn xác định rõ các yêu cầu, những gì cần có trong mã và những gì mã của bạn phải đạt được. 

Unit Test nên được viết dựa trên ý tưởng được chứa trong yêu cầu, chúng tôi xác định các thành phần phần mềm, lớp, giao diện cần thiết từ phân tích đặc tả và logic tương tác giữa các đơn vị này được chuyển từ mô tả trong đặc tả sang phương pháp trường hợp kiểm thử trong đặc tả đơn vị kiểm thử.

Quá trình viết Test thường bao gồm: 

1. Viết một kịch bản test và đảm bảo rằng nó sẽ thất bại (vì chưa có mã code nào nên việc thất bại là điều có thể khẳng định).
2. Mã Code để vượt qua kịch bản test đã viết. 
3. Viết thêm test case mới.
4. Tiếp tục mã Code để vượt qua trường hợp thử nghiệm mới.
5. Lặp lại quá trình trên. Thêm các trường hợp thử nghiệm và mã cho đến khi tất cả các trường hợp thử nghiệm vượt qua.
6. Cấu trúc lại mã, điều chỉnh mã để rõ ràng và dễ hiểu.

Các kỹ thuật viết Unit Test

Như đã chia sẻ ở trên, đơn vị kiểm thử Unit Test là một kỹ thuật kiểm thử White Box Testing. Trong ngành kiểm thử phần mềm, có hai chiến lược kiểm thử điển hình là black box testing và whitebox testing. 

Black-box testing

Black-box testing thực hiện quá trình kiểm thử mà không cần biết mã nguồn của chương trình. Và White-box testing được sử dụng khi mã nguồn của chương trình có sẵn. Logic của chương trình có thể được kiểm tra bằng cách truy cập cấu trúc dữ liệu và thuật toán bên trong chương trình. 

White-box testing

White-box testing được chia thành hai loại: luồng điều khiển (Control flow) và luồng dữ liệu (Data flow). 

• Luồng điều khiển: dựa trên luồng mã để đưa ra trường hợp thử nghiệm.
• Luồng dữ liệu: dựa trên luồng dữ liệu để đưa ra trường hợp thử nghiệm.

Trong khi viết Unit Test, bạn đã bao giờ tự hỏi mình “Có bao nhiêu phần của ứng dụng đã được thử nghiệm?”. Trong bài viết này, mình sẽ chia sẻ phương pháp đánh giá test case theo luồng điều khiển. 

Phương pháp đánh giá Test Case

Code coverage là một phương pháp được sử dụng để mô tả mức độ mà mã code của chương trình đã thực thi khi chạy một Test. Nói cách khác, Code Coverage là một cách để đảm bảo rằng các thử nghiệm của bạn kiểm tra mã của bạn.

• Test coverage = số lượng test được kiểm tra ((pass, fail) /Tổng số test case.
• Tested successful coverage = Tống lượng test được kiểm tra (pass) / Tổng lượng test - N/A.

Phân loại Code Coverage 

Code Coverage có thể chia thành các loại sau:

Phạm vi câu lệnh (Statement Coverage): 

Đảm bảo rằng tất cả các dòng trong mã nguồn đã được kiểm tra ít nhất một lần. 

Mức độ bao phủ của câu lệnh = (Số câu lệnh mã được kiểm tra / Tổng số câu lệnh mã) x100 

Ví dụ: Có 100 lệnh, 87 lệnh có thể kiểm tra độ phủ của câu lệnh = 87%. Đối với ví dụ này, để bao phủ 100% câu lệnh dc, mỗi lệnh bắt buộc phải được kiểm tra ít nhất một lần. 

Phạm vi quyết định (Decision Coverage): 

Mọi câu lệnh if, case, do-while... hay bất cứ hàm nào đều được coi là một quyết định. Một quyết định có 2 đầu ra, TRUE hoặc FALSE, được gọi là kết quả quyết định. Để đảm bảo độ phủ 100%, mỗi đầu ra TRUE FALSE phải được kiểm tra ít nhất một lần. 

Được tính theo công thức: 

Mức độ bao phủ quyết định = (Tổng kết quả ra quyết định của bài kiểm tra / Tổng kết quả ra quyết định) * 100.
Lưu ý: Khi bạn đảm bảo kiểm tra tất cả các quyết định, bạn cũng có thể đảm bảo vượt qua tất cả các dòng lệnh. 100% phạm vi quyết định ⇒ 100% phạm vi tuyên bố.

Phạm vi bao phủ của đường dẫn (Path Coverage): 

Đảm bảo rằng tất cả các đường dẫn có thể có từ đầu đến cuối của bài kiểm tra đều được kiểm tra. Có đảm bảo 100% đường dẫn có nghĩa là bạn có 100% phạm vi quyết định.

Kết luận

Trên đây là những hiểu biết của GrowUpWork về Unit Test và những điều bạn cần biết về kiểm thử phần mềm này. Hy vọng bài viết trên có thể giúp các bạn có những hiểu biết chung về Unit Test và đề xuất các test case phù hợp!