5 loại test phần mềm mà một developer cần biết, dựa trên mô hình kim tự tháp.
Càng lên cao thì đồ phức tạp, chi phí, thời gian tốn cho việc test càng nhiều

1. Kiểm thử đơn vị (Unit Tests):

  • Là nền tảng của kim tự tháp, chiếm phần lớn các bài kiểm thử.
  • Kiểm tra các phương thức và chức năng riêng lẻ ở cấp độ thấp nhất để đảm bảo chúng hoạt động đúng.
  • Mức độ bao phủ mã (code coverage) có thể khác nhau tùy ngành
    (ví dụ: 100% dòng lệnh hoặc Modified Condition/Decision Coverage – MCDC trong ngành quân sự/hàng không).
  • Nếu một hàm khó kiểm thử hoàn toàn, đó có thể là dấu hiệu hàm đó đang làm quá nhiều việc hoặc không được viết để dễ kiểm thử.

2. Kiểm thử thành phần (Component Tests):

  • Kiểm tra một phần hoàn chỉnh của ứng dụng (ví dụ: API) trong sự cô lập.
  • Các thành phần khác (như cơ sở dữ liệu, giao diện người dùng) sẽ được “mock” (giả lập) để chỉ tập trung vào thành phần đang được kiểm tra.
  • Mục đích là đảm bảo thành phần hoạt động như mong đợi mà không bị ảnh hưởng bởi các yếu tố bên ngoài, đồng thời kiểm tra cả trường hợp “happy path” và “unhappy path” (ví dụ: khi cơ sở dữ liệu gặp sự cố).

3. Kiểm thử tích hợp (Integration Tests):

  • Kiểm tra sự tương tác giữa các thành phần thực tế (ví dụ: API với cơ sở dữ liệu thực, gọi các API khác, ghi tin nhắn vào hàng đợi).
  • Thường phát hiện các lỗi liên quan đến cấu hình, lỗi chính tả trong truy vấn SQL, hoặc sự không nhất quán về quy ước đặt tên giữa các nhóm.
  • Thường chạy như một phần của quá trình build hoặc trước khi phát hành, thường sử dụng Docker để dễ dàng khởi tạo môi trường.
  • Có thể là kiểm thử hộp trắng (developer viết, biết chi tiết bên trong) hoặc hộp đen (tester viết, chỉ quan tâm đến đầu vào/đầu ra).

4. Kiểm thử đầu cuối (End-to-End Tests):

  • Kiểm tra toàn bộ ứng dụng từ đầu đến cuối, thường dưới dạng kiểm thử UI tự động (ví dụ: với Selenium, Cypress cho ứng dụng web).
  • Bao gồm kiểm thử chức năng (login, hiển thị danh sách) và kiểm thử chấp nhận (đảm bảo đáp ứng yêu cầu nghiệp vụ).
  • Thường được viết bằng ngôn ngữ Gherkin (theo mẫu Given-When-Then) để dễ hiểu cho các bên liên quan trong kinh doanh.
  • Mất nhiều thời gian để chạy, thường không chạy trên mỗi bản build mà có thể chạy qua đêm.
  • Cần môi trường ổn định (QA/UAT) và đôi khi cần người chuyên trách để duy trì vì dễ bị lỗi do các thay đổi nhỏ trong ứng dụng.

5. Kiểm thử thủ công (Manual Tests):

  • Là loại kiểm thử ở đỉnh kim tự tháp, dành cho những trường hợp quá phức tạp để tự động hóa hoặc không đáng để đầu tư thời gian vào việc tự động hóa.
  • Lý tưởng nhất là tự động hóa phần lớn các bài kiểm thử để tránh vòng lặp thiếu thời gian kiểm thử trước mỗi lần phát hành.
  • Việc phát hiện lỗi ở cấp độ thấp hơn (kiểm thử đơn vị) sẽ hiệu quả hơn nhiều so với phát hiện lỗi ở cấp độ cao hơn (kiểm thử thủ công) vì nó cung cấp thông tin chi tiết hơn về vị trí lỗi.

Nội dung ở link video này: https://www.youtube.com/watch?v=YaXJeUkBe4Y