Trong quá trình kiểm thử phần mềm giai đoạn thiết kế test case và viết ra được bộ testcase hiệu quả có thể tái sử dụng được để tiết kiệm được nhiều thời gian trong các giai đoạn sau của test cũng như hạn chế tối đa việc lọt bug đóng vai trò rất quan trọng, ảnh hưởng trực tiếp đến kết quả kiểm thử.
Để viết được testcase trước tiên cần hiểu testcase là gi?
Một test case đơn giản là một tập hợp các bước cần được thực hiện để kiểm tra các chức năng riêng biệt trong ứng dụng khi test.
Nên đặt theo một cách dễ hiểu cho chính người tạo cũng như người sưr dụng để testcase đó. Thường thì tên test case nên thể hiện được tên của module, hoặc chức năng mà bạn sẽ test trong test case đó
Ví dụ
Có một dự án là “AC” có chức năng “Login”.
Bây giờ mình muốn viết một test case để kiểm tra xem người dùng có thể đăng nhập vào trang web sử dụng email và mật khẩu không.
Theo đó, thay vì đặt tên test case là TC_01, mình có thể sử dụng quy ước đặt tên cho testcase của mình để khi nhìn vào ta sẽ có một gợi ý ngắn gọn những gì mà test case đó sẽ test.
TC_01_AC_Login_Success or,
TC_01_AC_Valid_Case,…
=> Tóm lại khi đặt tên ta nên đặt làm sao cho cho nó có liên quan đến dự án, module, chức năng của test case đó. Tùy thuộc vào mỗi dự án ta cũng sẽ có những cách đặt tên phù hợp và dễ quan sát hơn.
Miêu tả của test case là phần mà bạn sẽ mô tả chi tiết tất cả những gì mà bạn sẽ thực hiện để test
“Miêu tả” ở đây có thể hiểu đơn giản là “Mình sẽ test những gì”?
Bao gồm: Phần mềm cần được test những gì? trên những môi trường nào? cần những dữ liệu nào để test?
=>Tóm lại: Bạn cần cố gắng đưa ra nhiều thông tin cần thiết nhất có thể trong phần miêu tả test case.
Những thông tin này có thể là:
Khi viết test case, bạn nên kiểm tra tất cả các giả định có thể dùng cho một test case và bất kì điều kiện nào cần có trước khi thực hiện test. Ví dụ:
=> Tóm lại: Hãy cố gắng liệt kê tất cả các thông tin cần thiết nhất có thể có về các giả định cũng như điều kiện cần trước khi thực hiện test
Việc xác định dữ liệu đầu vào trước khi test tiêu tốn khá nhiều thời gian, có một số trường hợp việc tạo data nó chiếm phần lớn thời gian trong giai đoạn test. Nhưng cũng có khi việc tạo mới hoặc tạo lại dữ liệu lại tốn it thời gian hơn so với việc xác minh kết quả.
Để dễ dàng và tiết kiệm thời gian hơn khi test hãy cố gắng đưa những dữ liệu test sẽ được sử dụng cho việc kiểm thử vào trong phần miêu tả hoặc tại các bước đặc tả của test case như vậy sẽ ko mất thời gian để bạn và những người tester khác phải mất công tìm dữ liệu khi test.
Ví dụ như:
Một phần quan trọng khác để viết được test case tốt là các bước xác minh xem testcase đã bao phủ được tất cả các điểm chức năng của hệ thống hay chưa?
=> Các bước thiết kế test không chỉ đảm bảo luồng chức năng mà còn phải đảm bảo mỗi điểm chức năng cũng cần được kiểm tra.
Bằng việc so sánh các test case với tài liệu (spec, usecase, kịch bản người dùng,…) của dự án, bạn có thể xác định được test case có thể đảm bảo được các trường hợp cần kiểm tra.
Như đã nói ở trên, hãy cố gắng đính kèm tài liệu liên quan nếu có vào test case. Nếu dự án của bạn không có quá nhiều sự thay đổi thì có thể đính kèm nó vào từng bước test. Nhưng nếu nó bao gồm một phần đặc biệt trên màn hình, rất khó để ghi lại trong từng bước test thì hãy đính kèm tài liệu đặc tả hoặc thiết kế màn hình tới các bước cụ thể đó.
Một test case tốt cần phải ghi 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ế test cần chỉ ra rõ ràng những gì bạn mong đợi như là đầu ra của bước kiểm tra đó.
Nên trong khi viết test case hãy cố gắng chỉ ra cụ thể trang nào, màn hình là kết quả mong đợi khi test và bất kì sự thay đổi nào trong mong đợi như đầu ra được tạo ở phần back-end của hệ thống hoặc cơ sở dữ liệu. (ví dụ: sự tạo mới một đối tượng thì đối tượng đó cần được thêm vào bảng 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 được hệ thống cần xử lý đúng như những gì trong tài liệu yêu cầu.
Để viết test case hiệu quả, bạn nên cân nhắc việc chia test case của bạn thành các nhóm nhỏ theo nhóm các trình tự đặc biệt như cách xử lý của trình duyệt, kiểm tra cookie, test tính khả dụng, web service, kiểm tra điều kiện lỗi.
Nếu bạn cố gắng để viết testcase hiệu quả, bạn nên viết những test case chức năng riêng.
Cụ thể như test case để kiểm tra điều kiện lỗi nên được viết riêng với test case chức năng và nên có các bước kiểm tra thông báo lỗi. Hoặc khi viết testcase cho các chức năng đặc thù có nhiều sự kết hợp điều kiện đầu vào, bạn có thể chia thành các nhóm nhỏ hơn.
Ví dụ: Nếu bạn cần kiểm tra xem chức năng đăng nhập cho ứng dụng nào đó với dữ liệu đầu vào không đúng, bạn có thể chia việc test chức năng đăng nhập không hợp lệ thành các nhóm sau:
Bất kì dự án nào khi làm việc thì người thiết kế testcase có thể sẽ không phải là người thực hiện test chính vì vậy test case nên dễ hiểu và dễ đọc, chi tiết cho tất cả mọi người. Vì trong quá trình test người viết ra testcase có thể nghỉ vì một lý do nào đó hoặc chuyển qua dự án khác nếu bạn viết testcase mà chỉ mình bạn hiểu thì có thể bạn sẽ 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 nó đúng ngay lần đầu tiên:
Test case đóng một vai trò quan trọng trong vòng đời test, vì vậy việc đảm bảo nó đúng và hợp chuẩn trở nên rất cần thiết – điều này sẽ được xác định qua quá trình kiểm tra lại testcase
=> Kiểm tra lại test case có thể thực hiện giữa những người tester trong team, leader của đội kiểm thử, 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.
Một lưu ý nhỏ cho quá trình này đó là cần xác định một vài điều kiện cần có trước khi bắt đầu kiểm tra lại vì quá trình kiểm tra lại cũng có thể gây hại.
Điều này rất quan trọng để chắc chắn rằng test case luôn được cập nhật theo những thay đổi mới theo yêu cầu từ phía khach hàng và những cải thiện tốt hơn cho ứng dụng. Luôn chú ý cập nhật test case đã tồn tại trước đó trước khi bạn bắt đầu viết hoặc thêm test case mới hoặc ngày cả trong quá trình test.
=> Tóm lại trong trường hợp có bất kì sự thay đổi nào tới chức năng đã tồn tại, bạn phải cập nhật test case đã tồn tại thay vì viết mới để tránh việc dư thừa và bạn luôn có một một testcase cập nhật mới nhất phù hợp với những thay đổi.
Điều kiện đầu ra cơ bản là đặc tả các kết quả bạn cần kiểm tra sau khi thực hiện test. Ngoài ra điều kiện đầu ra cũng được sử dụng để đưa ra hướng dẫn phục hồi lại hệ thống với trạng thái gốc cho nó không ảnh hưởng đến việc test sau này.
Ví dụ: nếu bạn đề cập những thay đổi được tạo ra tới tập dữ liệu test cho nó, được sử dụng cho testcase sau này cho cùng chức năng.
Dưới đây mình sẽ viết một ví dụ đơn giản về testcase cho màn hình tạo mới một đối tượng với yêu cầu như sau:
=> Nhìn vào testcase trên các bạn có thể thấy định hướng viết của mình sẽ là đi từ:
Hy vọng bài viết trên sẽ giúp các bạn viết được bộ testcase tốt cho dự án của mình
Nguồn tham khảo: http://quicksoftwaretesting.com/test-case-writing-tips/
You need to login in order to like this post: click here
YOU MIGHT ALSO LIKE
SUBSCRIBE TO OUR NEWSLETTER
