Test case

Trường hợp kiểm thử

Test case mau
Test case mau

✅ Trường hợp kiểm thử là cụm từ tiếng Việt của “test case.” Bạn có thể xem bài test case là gì ở đây để hiểu rõ hơn khái niệm cũng như cách sắp xếp test case hợp lý và hiệu quả.

Theo wiki tiếng Việt, thì Trường hợp kiểm thử là một tập hợp các thông số đầu vào kiểm thử, điều kiện thực thi, và kết quả mong đợi được phát triển cho một mục tiêu cụ thể, như thực hiện một chương trình cụ thể hay kiểm tra sự tuân thủ với một yêu cầu cụ thể. Một trường hợp kiểm thử có thể chỉ đơn giản là một câu hỏi cho chương trình. Mục đích mà kiểm thử cần chạy là để lấy thông tin, ví dụ như chương trình sẽ vượt qua bài kiểm thử hay không. Trường hợp kiểm thử là nền tảng của Đảm bảo chất lượng trong khi chúng được phát triển để xác minh chất lượng và hành vi của sản phẩm.

https://vi.wikipedia.org

Cách viết và sắp xếp test case

Cấu trúc của test case

Cấu trúc (hay gọi là các thành phần) của test case sẽ khác nhau ở mỗi dự án hay công ty. Tuy nhiên, về cơ bản thì cấu trúc của 1 test case sẽ bao gồm:

  1. Test case ID (hay gọi tắt là Test ID): Mã trường hợp kiểm thử
    Là mã số được gán cho mỗi test case để tiện quản lý, ví dụ ADD-01
    Trong đó, “ADD” là viết tắt của Tên Chức năng hoặc Màn hình tương ứng. “01” là số thứ tự.
    Lưu ý Test case ID không được trùng nhau.
  2. Test summary (hay còn có tên khác là test description)
    Tóm tắt trường hợp đang được kiểm thử. Ví dụ:
    TC1: Kiểm tra trường hợp đăng nhập thành công với một bộ tài khoản hợp lệ
    TC2: Người dùng không thể đăng nhập thành công với tài khoản đang bị khoá
  3. Test precondition (hoặc là setup steps)
    Các điều kiện tiên quyết, bắt buộc phải hoàn thành trước khi thực hiện trường hợp kiểm thử này. Ví dụ: Với test case TC1 ở trên (Kiểm tra trường hợp đăng nhập thành công với một bộ tài khoản hợp lệ) thì bạn phải chuẩn bị sẵn một bộ tài khoản hợp lệ bao gồm username và password
  4. Test steps (hoặc steps)
    Các bước chi tiết của một trường hợp kiểm thử. Bạn có thể viết cơ bản, ngắn gọn hoặc viết chi tiết bao gồm dữ liệu cụ thể (test data)
  5. Expected result
    Kết quả mong đợi là điều mà bạn mong đợi chương trình/hệ thống thực hiện sau khi bạn đã thực hiện các bước ở phần “Test steps”
  6. Status (hoặc Test result)
    Nếu kết quả quan sát giống như kết quả mong đợi thì chỗ này sẽ được điền là “OK” hay “ĐẠT”
    Ngược lại, thì là “NG” hay “KHÔNG ĐẠT”
  7. Bug ID
    Nếu trường hợp kiểm thử vừa được thực hiện là KHÔNG ĐẠT thì bạn sẽ POST BUG, sau đó ghi ID của con bug đó vào đây.
  8. Và nhiều thông tin khác nữa tuỳ nhóm bạn hay khách hàng muốn quản lý thêm thông tin gì.

Lưu ý khi viết test case cho ứng dụng web

Khi bạn kiểm thử ứng dụng web thì thường sẽ có các trường hợp kiểm thử cho các nhóm sau:

  1. Layout và UI
    1. Đừng quên kiểm thử trên nhiều trình duyệt khác nhau
    2. Và hỏi khách hàng có cần kiểm thử trên các loại màn hình điện thoại lớn nhỏ (cả Android và iOS)
  2. Chức năng
    1. Tuỳ vào yêu cầu mà bạn sẽ thiết kế các test case tương ứng.
    2. Nhớ test cả trường hợp happy case (positive case) và unhappy case nhé.
  3. Kiểm thử hiệu năng và bảo mật
    1. Nếu được thì hãy hỏi về các khía cạnh này nhé
    2. Hiệu năng thì có thể nghĩ đến 2 trường hợp khác nhau
      1. Kiểm thử để đánh giá hiệu năng cho hệ thống (server side). Ví dụ JMeter hay K6 là công cụ hữu ích.
      2. Kiểm thử để đánh giá hiệu năng ở phía client side (front end). Trường hợp này thì thử xem Google – PageSpeed Insights

Cám ơn bạn đã đọc hết bài viết.
Happy testing!

You Might Also Like

2 Comments

Leave a Reply

Your email address will not be published. Required fields are marked *