Get in touch
or send us a question?
CONTACT

Các cách để viết Testcases hiệu quả

Các cách để viết Testcases hiệu quả

This post has been more than 3 years since it was last updated.

Testcases rất quan trọng đối với bất kì dự án nào vì đây là bước đầu tiên trong bất cứ chu trình kiểm thử nào, và nếu có sai sót nào trong bước này nó sẽ ảnh hưởng đến suy luận của bạn trong quá trình kiểm thử. Vậy nên biết làm thế nào để tạo được những testcase tốt là điều vô cùng quan trọng với bất cứ QA/Tester nào.

Dưới đây là một số tips có thể tham khảo trong quá trình viết testcase để viết được những testcase hiệu quả, dễ hiểu và có thể tái sử dụng…

Các Tips đơn giản để viết testcase hiệu quả

1. Quy ước tên Testcase

Dù đây là 1 tip rất đơn giản nhưng phần lớn chúng ta chưa thực hiện nó hiệu quả. Hãy đặt tên testcase đại diện cho tên module và chức năng mà bạn sẽ kiểm chứng trong testcase. Ví dụ Một project có tên “TMS” trong đó có chức năng là đăng nhập: * TC_01_TMS_Login_Success, hoặc * TC_01_TMS_Valid_Case… * TC_02_TMS_Invalid_Case…

2. Miêu tả Testcase

Description là trường bạn miêu tả chi tiết những gì bạn sẽ test và hành vi đặc biệt được xác minh bằng việc test Trường “Description” của testcase nên được định nghĩa bằng câu hỏi “Tôi sẽ test cái gì?” Tip: Hãy thêm càng nhiều thông tin càng tốt cho bất cứ điều kiện nào trước khi chạy testcase

3. Giả định và tiền điều kiện

Trong khi viết testcase, bạn nên truyền đạt tất cả các giả định áp dụng cho việc test, cùng với các tiền điều kiện cần phải được đáp ứng trước khi thực hiện test. Các loại điều kiện chi tiết bạn nên biết trong tiền điều kiện: * Bất cứ phụ thuộc dữ liệu người dùng nào (ví dụ: người dùng phải đăng nhập, phải đăng kí…) * Bất cứ cài đặt đặc biệt nào được thực hiện trước khi test * Sự phụ thuộc vào bất kì testcase nào khác (ví dụ: testcase này cần được thực hiện trước hoặc sau testcase khác…) * Sự phụ thuộc vào môi trường test

4. Dữ liệu test

Chuẩn bị dữ liệu test là một bước vô cùng quan trọng trong quá trình tạo testcase, nó giúp tester kiểm tra hệ thống một cách trực quan hơn cũng như sẽ tiết kiệm rất nhiều thời gian trong một thời gian dài vì bạn sẽ không phải tìm dữ liệu test mới mỗi khi thực hiện test. Gợi ý:

  • Trong nhiều trường hợp bạn biết ở đâu dữ liệu test các thể được sử dụng lại nhiều lần, bạn có thể đề cập dữ liệu test chính xác được sử dụng cho test
  • Nếu test chỉ liên quan đến một vài giá trị được kiểm tra, bạn có thể chọn để chỉ rõ khoảng giá trị hoặc mô tả giá trị nào được test cho trường nào. Bạn cũng có thể thực hiện việc này cho các trường hợp phủ định.
  • Test với mỗi giá trị là không thực tế nên bạn có thể chọn một vài giá trị từ phân vùng cho giá trị bao phủ tốt cho test case của bạn.
  • Bạn có thể quyết định chỉ ra kiểu dữ liệu test được yêu cầu và không phải là dữ liệu test thật. Cách này áp dụng cho các dự án mà dữ liệu test thay đổi khi nhiều nhóm sử dụng nó và có thể không có trạng thái giống nhau trong lần sử dụng tiếp theo – chỉ ra kiểu hay trạng thái của dữ liệu người dùng được sử dụng hỗ trợ nhiều cho người chạy test case sau đó.

5. Độ bao phủ phải là 100%

Phạm vi test là một phương pháp hữu ích để tìm các phần chưa được test của một ứng dụng. Để có thể bao phủ 100% , cần viết các testcase cho tất cả các yêu cầu phần mềm được đề cập đến trong tài liệu đặc tả.

6. Kết quả mong đợi

Một test case được viết tốt cần phải đề cập một cách rõ ràng kết quả mong đợi của ứng dụng hoặc hệ thống. Mỗi bước thiết kế testcase nên chỉ ra rõ ràng những gì bạn mong đợi như là đầu ra của bước test đó. Vậy nên khi viết test case, chỉ ra cụ thể trang nào, màn hình nào bạn mong đợi xuất hiện khi test và bất kì thay đổi nào bạn mong đợi như là đầu ra được tạo ở phần back-end của hệ thống hoặc cơ sở dữ liệu. Bạn có thể đính kèm màn hình hoặc tài liệu đặc tả tới các bước liên quan chỉ ra hệ thống nên làm việc như đã được đưa ra trong tài liệu.

7. Dễ đọc và dễ hiểu

Bất kì dự án nào, khi thiết kế test case, bạn nên luôn suy nghĩ rằng test case sẽ không được thực hiện bởi người thiết kế. Vì vậy, test case nên dễ đọc, dễ hiểu và chi tiết.

Tưởng tượng trường hợp mà người viết tất cả test case nghỉ vì lý do nào đó và bạn có một nhóm mới làm việc thực hiện test case đó, toàn bộ công sức dùng cho giai đoạn thiết kế sẽ đổ xuống sông.

Nếu bạn là người rời tổ chức, bạn không thể tham gia được nhưng nếu bạn vẫn ở công ty và chỉ chuyển qua nhóm khác, bạn có thể phải dành hết thời gian để giải thích những gì bạn viết.

Nên tốt hơn hãy làm đúng ngay lần đầu tiên.

Test case tốt cần:

  • Đơn giản và dễ hiểu với mọi người (gồm cả bạn)
  • Rõ ràng, chi tiết (nếu bạn thấy test case có nhiều bước thì nên tách thành test case mới).
  • Đảm bảo đủ các trường hợp.

8. Kiểm tra lại

Test case đóng một vai trò quan trọng trong vòng đời test, cần đảm bảo chúng đúng và hợp với chuẩn, trở nên rất cần thiết – khi quá trình kiểm tra lại cần thực hiện.

Kiểm tra lại test case có thể thực hiện giữa những người test ngang hàng, người phân tích nghiệp vụ chức năng, lập trình viên, chủ sản phẩm hoặc các bên liên quan.

9. Có thể sử dụng lại

Bạn nên viết test case với suy nghĩ rằng chúng có thể được sử dụng lại trong tương lai cho các dự án khác, team khác.

Trước khi viết test case cho dự án của bạn, luôn cố gắng và kiểm tra xem có test case nào được viết rồi. Điều này thực sự tiết kiệm được nhiều thời gian.

Nếu bạn dành một chút thời gian với nhóm khác để tìm ra test case đã có rồi, bạn thật may mắn – bạn sẽ không phải lặp lại bất kì test case nào vì thế sẽ tránh được việc dư thừa trong quản lý test của bạn.

Cũng như thế, nếu bạn có test case sẵn có được viết trước đó ở cùng module, bạn nên chỉnh sửa chúng thay vì viết mới để bạn luôn có được test case mới đã sửa.

Điều này có thể không dùng được nếu như dự án của bạn là dự án mới, dù thế nào, bạn có thể cố gắng để viết test case theo cách chúng có thể được sử dụng cho dự án nào đó trong tương lai.

Cũng vậy, nếu bạn cần một test case cụ thể để thực hiện test case khác, bạn có thể đơn giản gọi đến test case đã tồn tại trong phần điều kiện trước hoặc ở bước thiết kế test.

10. Bảo trì và cập nhật

Việc cập nhật các test case theo những thay đổi vừa được giới thiệu trong các yêu cầu luôn luôn là một việc cần thiết.

Điều quan trọng là đảm bảo rằng các test case hiện tại của bạn luôn được cập nhật theo yêu cầu mới trước khi bắt đầu các test case mới.

Kết luận chung:

Mục đích cuối cùng của việc tạo test case là để đáp ứng yêu cầu của khách hàng, bởi vậy hãy viết test case trên quan điểm của người dùng cuối. Trên đây là một số kinh nghiệm để bạn có thể viết test case hiệu quả. Mong là bài viết sẽ giúp phần nào cho các bạn trong quá trình viết test case.