Bỏ qua menu, vào nội dung chính

Kiểm thử phần mềm là gì?

Kiểm thử phần mềm (software testing) là quá trình kiểm tra một phần mềm có hoạt động đúng như yêu cầu hay không, tìm ra lỗi trước khi người dùng thật gặp phải, và xác nhận phần mềm đủ ổn định để đưa vào sử dụng. Kiểm thử được chia thành nhiều loại theo phạm vi (kiểm thử đơn vị, tích hợp, toàn hệ thống) và theo cách thực hiện (kiểm thử thủ công do người thao tác trực tiếp, và kiểm thử tự động do các đoạn mã kịch bản chạy lại nhiều lần).

Kiểm thử không phải là bước làm sau cùng khi lập trình xong mà nên chạy song song trong suốt dự án. Kiểm thử đơn vị (unit test) kiểm tra từng hàm nhỏ ngay khi vừa viết. Kiểm thử tích hợp (integration test) kiểm tra các phần ghép lại có hoạt động đúng với nhau không. Kiểm thử toàn hệ thống (end-to-end test) mô phỏng một luồng thao tác thật của người dùng từ đầu đến cuối. Phát hiện lỗi càng sớm trong quá trình này thì chi phí sửa càng thấp; lỗi lọt ra đến khi người dùng thật gặp phải thường tốn kém hơn nhiều để khắc phục và có thể ảnh hưởng đến uy tín.

Thành phần

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

    Kiểm tra từng hàm hoặc thành phần nhỏ nhất của code một cách riêng lẻ, chạy tự động mỗi khi có thay đổi mã nguồn.

  2. Kiểm thử tích hợp (Integration Test)

    Kiểm tra các thành phần đã ghép lại (ví dụ giao diện gọi đúng máy chủ, máy chủ ghi đúng dữ liệu) có hoạt động ăn khớp với nhau không.

  3. Kiểm thử toàn hệ thống (End-to-End Test)

    Mô phỏng một luồng thao tác thật của người dùng, từ mở trang đến hoàn tất một việc, để xác nhận toàn bộ luồng chạy đúng.

  4. Kiểm thử thủ công (Manual Testing)

    Người kiểm thử tự thao tác trực tiếp trên phần mềm, phù hợp để đánh giá trải nghiệm và các trường hợp khó viết kịch bản tự động.

  5. Kiểm thử hồi quy (Regression Test)

    Chạy lại các kịch bản kiểm thử cũ sau khi sửa hoặc thêm tính năng mới, để chắc chắn phần cũ không bị hỏng theo.

Lợi ích và thời điểm triển khai

Lợi ích

  • Lỗi được tìm ra và sửa trong lúc phát triển, tốn ít công sức hơn nhiều so với sửa sau khi đã đưa vào dùng thật.
  • Bộ kiểm thử tự động chạy lại nhanh chóng để xác nhận phần cũ không bị hỏng khi thêm tính năng mới.
  • Một lỗi lọt ra đến người dùng thật thường phải xử lý gấp, ảnh hưởng uy tín, và tốn công điều tra nguyên nhân hơn nhiều so với lúc còn đang phát triển.
  • Kết quả kiểm thử là căn cứ khách quan để xác nhận phần mềm sẵn sàng bàn giao, không chỉ dựa vào cảm nhận.

Nên triển khai khi

  • Mỗi lần sửa một tính năng lại phát sinh lỗi ở một chỗ khác không liên quan
  • Phần mềm chỉ được kiểm tra bằng cách người dùng thật báo lỗi sau khi đã đưa vào dùng
  • Đội phát triển không dám thay đổi code cũ vì không chắc có làm hỏng phần đang chạy hay không
  • Chuẩn bị đưa một hệ thống quan trọng (thanh toán, dữ liệu khách hàng) vào dùng thật lần đầu

Câu hỏi thường gặp

Kiểm thử thủ công và kiểm thử tự động, cái nào cần hơn?

Cả hai đều cần, cho mục đích khác nhau. Kiểm thử tự động phù hợp cho các luồng lặp lại nhiều lần (đăng nhập, thanh toán, các thao tác cốt lõi) vì chạy nhanh và chạy lại được liên tục. Kiểm thử thủ công phù hợp để đánh giá trải nghiệm thực tế, giao diện, và các trường hợp bất ngờ mà kịch bản tự động chưa lường tới.

Không viết kiểm thử tự động có sao không?

Dự án nhỏ, ít thay đổi có thể tạm ổn khi chỉ kiểm thử thủ công. Nhưng khi dự án phát triển lâu dài, thường xuyên sửa và thêm tính năng, thiếu kiểm thử tự động khiến mỗi lần sửa đều có nguy cơ làm hỏng phần khác mà không ai phát hiện kịp thời.

Kiểm thử phần mềm nên bắt đầu từ giai đoạn nào của dự án?

Nên bắt đầu song song với lúc lập trình, không phải đợi đến khi làm xong toàn bộ mới kiểm thử. Kiểm thử đơn vị viết ngay khi viết hàm mới; kiểm thử tích hợp và toàn hệ thống chạy khi các phần đã ghép lại đủ để mô phỏng một luồng thao tác thật.

Ai nên là người kiểm thử: chính lập trình viên hay một người khác?

Cả hai. Lập trình viên tự viết kiểm thử đơn vị cho code của mình. Nhưng kiểm thử toàn hệ thống nên có thêm một người khác thực hiện độc lập, vì người viết code thường có xu hướng chỉ thử theo cách mình nghĩ là đúng, dễ bỏ sót các trường hợp mà người dùng thật gặp phải.

Trao đổi về dự án