13 MẸO ĐỂ VIẾT TESTCASE CHO BẤT KỲ ỨNG DỤNG NÀO

Test cases 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 kỳ chu kỳ thử nghiệm nào và nếu có bất cứ sai sót trong bước này, các tác động sẽ bị rất lớn khi bạn đi tiếp trong chu kỳ kiểm thử phần mềm.

Biết làm thế nào để viết các trường hợp kiểm thử tốt là điều cực kỳ quan trọng đối với chúng ta, nó là một nguồn lực thử nghiệm.

Viết Test cases là một hoạt động có ảnh hưởng lớn đến giai đoạn thử nghiệm và điều này làm cho các trường hợp thử nghiệm trở thành một phần quan trọng trong quá trình thực hiện thử nghiệm!

Vì vậy, việc viết các testcase có hiệu quả cũng như tái sử dụng là rất quan trọng; các trường hợp thử nghiệm tốt sẽ tiết kiệm rất nhiều thời gian trong các giai đoạn thử nghiệm sau (thực sự) nếu bạn thực hiện đúng trong lần thử đầu tiên ...

A. Thế nào là testcase?

Một Testcase chỉ đơn giản là một danh sách các hành động cần phải được thực hiện để xác minh một chức năng cụ thể hoặc tính năng của ứng dụng đang được kiểm tra.

B. LỜI KHUYÊN ĐƠN GIẢN ĐỂ VIẾT TESTCASE HIỆU QUẢ

Viết Testcase hiệu quả là một kỹ năng và bạn chỉ có thể đạt được nó thông qua việc thực hành và sự hiểu biết sâu sắc về ứng dụng để áp dụng cho trường hợp thử nghiệm đang được viết. Kết hợp một số mẹo đơn giản mà tôi sẽ đưa ra ở đây sẽ giúp bạn nắm vững được kỹ năng viết testcase tốt.

1. Quy ước đặt tên Testcase

Mặc dù đây là mẹo đơn giản nhất trong danh sách này, nhưng đa số chúng ta thực hiện nó chưa hiệu quả.

Chúng ta nên nhớ: Luôn đặt tên một cách có ý nghĩa nhất, dễ hiểu đối với bất kỳ ai sẽ thực hiện các trường hợp thử nghiệm trong tương lai (bao gồm BẠN!).

Mẹo nhanh: Đặt tên cho các testcase để mô tả tên mô-đun hoặc khu chức năng mà bạn sẽ xác minh trong trường hợp kiểm tra đó.

Ví dụ: Có hệ thống bán hàng online, trong đó có chức năng: Đăng Ký Vậy, khi viết testcase, thay cho việc viết tên TC_01, ta sẽ viết cụ thể thêm chức năng đang nói tới: TC_Đăng_Ký

2. Mô tả cho Testcase

Mô tả là nơi bạn đề cập đến tất cả các chi tiết về những gì sẽ kiểm tra, và hành vi đặc biệt được xác minh bằng kịch bản kiểm tra.

Các "mô tả" của một trường hợp thử nghiệm nên xác định "Tôi sẽ kiểm tra những gì? Kiểm tra như thế nào? (Những gì cần phải được xác minh, môi trường thử nghiệm nó cần được xác minh trong đó dữ liệu thử nghiệm được sử dụng - tất cả các thông tin này được cụ thể ở phần mô tả.)

Mẹo nhanh: Đưa càng nhiều thông tin càng tốt trong phần mô tả của testcase!

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

Trong khi viết các testcase, bạn nên truyền đạt tất cả các giả định áp dụng cho bài kiểm tra, cùng với các điều kiện tiên quyết cần phải đáp ứng trước khi kiểm tra có thể được thực hiện.

Dưới đây là loại chi tiết bạn muốn bao gồm như là một phần của phần này:

• Bất kỳ phụ thuộc dữ liệu người dùng nào (ví dụ: người dùng phải đăng nhập, trang nào người dùng bắt đầu cuộc hành trình, v.v ...)
• Sự phụ thuộc vào môi trường thử nghiệm
• Bất kỳ thiết lập đặc biệt nào được thực hiện trước khi thực thi thử nghiệm
• Sự phụ thuộc vào bất kỳ trường hợp kiểm tra nào khác - Trường hợp thử nghiệm cần được thực hiện trước / sau một số trường hợp kiểm tra khác không?

Mẹo nhanh: Đảm bảo thêm càng nhiều thông tin càng tốt để có thể đáp ứng các điều kiện trước khi chạy thử.

4. Dữ liệu truyền vào

Xác định dữ liệu thử nghiệm có thể rất tốn thời gian - bởi vì cần nhiều lần chuẩn bị dữ liệu thử nghiệm, nên mất nhiều thời gian trong một chu kỳ thử nghiệm.

Đôi khi bạn cần tạo một dữ liệu thử nghiệm một lần nữa vì việc tạo ra một dữ liệu mới có thể mất ít thời gian hơn so với việc xác định nó

Để dễ dàng cho một người thử nghiệm (và những người kiểm thử khác), Bất cứ khi nào có thể, bạn có thể cung cấp cho họ dữ liệu thử nghiệm để sử dụng cho các trường hợp thử nghiệm trong mô tả của testcase hoặc với từng bước cụ thể trong testcase Điều này sẽ tiết kiệm rất nhiều thời gian trong quá trình bạn cần phải thực hiện lại các testcase

Một vài gợi ý:

• Trong nhiều trường hợp bạn biết dữ liệu thử nghiệm có thể được sử dụng lại theo thời gian, bạn có thể đề cập đến chính xác dữ liệu kiểm tra để sử dụng cho việci kiểm thử.
• Nếu thử nghiệm chỉ bao gồm một số giá trị được xác minh, bạn có thể chọn để chỉ định phạm vi giá trị hoặc mô tả những giá trị nào sẽ được kiểm tra cho trường nào.
• Kiểm tra với mỗi giá trị là không thực tế, do đó bạn có thể chọn một vài giá trị từ mỗi lớp tương đương mà nên cung cấp cho bảo hiểm tốt cho bài kiểm tra của bạn.
• Bạn cũng có thể quyết định đề cập đến loại dữ liệu được yêu cầu để chạy thử nghiệm chứ không phải giá trị dữ liệu thử nghiệm thật sự. Điều này áp dụng cho các dự án mà dữ liệu thử nghiệm vẫn tiếp tục thay đổi khi nhiều nhóm sử dụng nó và có thể không ở trong cùng một trạng thái khi sử dụng nó trong lần tiếp theo

5. Xác nhận bao gồm tất cả các bước Thiết kế thử nghiệm

Một phần quan trọng khác của một trường hợp thử nghiệm tốt, là các bước xác minh trường hợp thử nghiệm được xác định chính xác bao gồm tất cả các điểm xác minh đối với tính năng được thử.

Mẹo nhanh: Các bước Thiết kế Thử nghiệm không chỉ bao gồm các luồng chức năng mà còn phải đảm bảo mỗi điểm được kiểm tra!

Bằng cách so sánh các bước Test Case của bạn với các tài liệu (Tài liệu yêu cầu, trường hợp sử dụng, bản đồ quy trình) dự án của bạn, bạn có thể đảm bảo rằng Test Case tối ưu bao gồm tất cả các điểm xác minh.

6. Đính kèm các tài liệu liên quan

Như tôi đã đề cập ở trên, nếu có thể, bạn nên đính kèm các hiện vật có liên quan vào trường hợp thử nghiệm của bạn.

Nếu sự thay đổi bạn đang thử nghiệm không lớn, bạn có thể cân nhắc đề cập đến nó trong bước kiểm tra.

Tuy nhiên, nếu nó liên quan đến một phần cụ thể trên màn hình, nó có thể là khó khăn để đề cập đến trong bước kiểm tra, gắn tài liệu đặc tả hoặc thiết kế màn hình với bước cụ thể giúp.

7. Kết quả mong đợi

Một testcase rõ ràng sẽ đề cập rõ kết quả dự kiến của ứng dụng hoặc hệ thống đang thử nghiệm. Mỗi bước thiết kế thử nghiệm cần đề cập rõ ràng những gì bạn mong đợi như là kết quả của bước xác minh đó.

Vì vậy, trong khi viết các trường hợp thử nghiệm, hãy đề cập chi tiết về trang / màn hình mà bạn mong đợi xuất hiện sau bài kiểm tra, và bất kỳ bản cập nhật nào bạn mong đợi như là một kết quả sẽ được thực hiện trong hệ thống hoặc cơ sở dữ liệu back-end (ví dụ như một mục nhập mới nên ghi vào Bảng dữ liệu).

Bạn cũng có thể đính kèm ảnh chụp màn hình hoặc tài liệu đặc tả cho bước tương ứng đề cập đến hệ thống nên hoạt động như đã nêu trong tài liệu cho trước để làm cho mọi thứ đơn giản hơn.

8. Phân chia các trường hợp kiểm tra chức năng đặc biệt thành các bộ

Để viết bài kiểm tra hiệu quả, bạn nên xem xét việc phân chia các testcase thành các bộ và các bộ phụ để kiểm tra một số tình huống đặc biệt như các hành vi cụ thể của trình duyệt, xác minh cookie, kiểm tra khả năng sử dụng, kiểm tra dịch vụ Web và kiểm tra các điều kiện lỗi ...

Mẹo nhanh: Nếu trong khi viết các kịch bản này thành tập hợp, một tính năng cụ thể có nhiều kết hợp đầu vào, bạn có thể tách thử nghiệm thành các testcase phụ

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

Dù dự án bạn làm việc, khi thiết kế các trường hợp thử nghiệm, bạn nên luôn luôn xem xét rằng Các trường hợp kiểm tra sẽ không phải luôn luôn được thực hiện bởi người thiết kế chúng. Vì vậy, các bài kiểm tra phải dễ hiểu, dễ đọc và chính xác.

Bộ phần mềm thử nghiệm chỉ có thể hiểu được bởi những người thiết kế chúng là phổ biến. Vì vậy, bạn nên tập trung vào việc viết các testcase mà:

• Đều đơn giản và dễ hiểu bởi tất cả mọi người (kể cả BẠN!)
• Chia nhỏ các thử nghiệm một cách tối giản thành một Thử nghiệm mới vẫn có đủ độ phủ sóng

10. Kiểm tra lại

Các testcase đóng một vai trò quan trọng trong vòng đời Kiểm thử Phần mềm. Hãy đảm bảo rằng chúng là chính xác và phù hợp với các tiêu chuẩn, thậm chí còn rất cần thiết

Mẹo nhanh: Kiểm tra lại trường hợp thử nghiệm có thể được thực hiện bởi các tester khác, BA, nhà phát triển, chủ sở hữu sản phẩm hoặc bất kỳ bên liên quan nào.

11. Có thể tái sử dụng

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

• Chú ý rằng, trước khi viết một Test case mới cho dự án hay module của bạn, luôn luôn cố gắng tìm ra nếu các test case đã được viết sẵn đối với vùng giống nhau? Điều đó thực sự giúp tiết kiệm được nhiều thời gian.
• Nếu bạn dành chút thời gian với các nhóm khác để tìm ra các test case đã có sẵn thì bạn có thể may mắn là sẽ không lặp lại một số test case, từ đó tránh được sự dư thừa trong các công cụ quản lý test (như ALM hoặc QC).
• Ngoài ra, nếu bạn có được các test case đã được viết sớm hơn xung quanh module giống nhau, bạn sẽ phải cập nhật chúng thay vì viết các test case mới. Do đó, với bất kỳ tiến trình nào cũng luôn có các test case được cập nhật ở mọi nơi. Điều này có thể không được áp dụng nếu dự án của bạn là một dự án mới, tuy nhiên, bạn có thể cố gắng viết các test case mới bằng cách mà chúng có thể được tái sử dụng đối với một vài dự án khác trong tương lai. Ngoài ra, nếu bạn cần một test case cụ thể để thực hiện một số test case khác, bạn có thể gọi đơn giản test case đã tồn tại trong tiền điều kiện (pre-condition) hoặc tại một bước của test design.

12. Bảo trì & Cập nhật

• Nó rất quan trọng để đảm bảo rằng các Test case luôn được cập nhật theo những thay đổi đã được đề cập ở hiện tại trong ứng dụng mà họ áp dụng.

• Việc nhắc lại điểm của tôi về khả năng sử dụng lại, trong trường hợp có thay đổi đối với tiến trình hoặc chức năng hiện tại, bạn PHẢI xem xét cập nhật các Test case hiện tại thay vì viết thêm bất kỳ Test case mới nào, từ đó tránh sự dư thừa đối với bộ test case hiện tại.

• Điều này cũng đảm bảo bạn luôn cập nhật các Test case cho bất kỳ tiến trình nào trong ứng dụng của bạn.

13. Các điều kiện công bố

Các điều kiện công bố xác định dựa trên những điều khác nhau cần được xác minh sau khi Kiểm thử đã được thực hiện Thêm nữa, các điều kiện công bố cũng được sử dụng để hướng dẫn để khôi phục lại hệ thống về trạng thái ban đầu của nó vì nó không liên quan tới việc kiểm thử sau này. Ví dụ, điều này khá hữu ích nếu bạn đề cập đến những thay đổi được thực hiện với một dữ liệu kiểm thử mà nó sẽ được sử dụng cho một trường hợp thử nghiệm sau đối với cùng một chức năng.

Kết Luận: Trên đây, tôi đã cố gắng để tổng hợp các mẹo đơn giản và hữu ích nhất mà bạn có thể áp dụng trong khi bạn đang trong giai đoạn thiết kế các trường hợp thử nghiệm. Bạn chắc chắn suy nghĩ từ quan điểm của người dùng cuối, biết ứng dụng từ đầu đến cuối, và làm theo các bước thực hành tốt nhất mà tôi đã đề cập ở đây. Hy vọng những điều trên sẽ giúp ích cho các bạn.

Tài liệu tham khảo: http://quicksoftwaretesting.com/test-case-writing-tips/