Làm thế nào để viết được TestCase tốt?

Viết TestCase là một trong những bước quan trọng của Tester trong quá trình kiểm thử phần mềm. (Software Testing Life Cycle(STLC) Nhưng làm thế nào để viết được TC hiệu quả? Môt trong những phương pháp đó là: Biết xác định và phân tích rõ yêu cầu .

1. Testcase là gì? Những mục cần có trong file Testcase:

1 file Test case mô tả một dữ liệu đầu vào (input), hành động (action) hoặc sự kiện (event) và một kết quả mong đợi (expected response). Để xác định một chức năng của ứng dụng phần mềm hoạt động đúng hay không.

Bạn có thể dùng excel , word hoặc chọn công cụ (tools) nào đó để tạo file Testcase. Nhưng trong một file Testcase nhất định cần phải có những trường sau:

2. Làm thế nào để tạo được test case tốt?

Trong khi tạo testcase bạn phải làm theo một số bước để đảm bảo rằng bạn sẽ tạo ra file testcase tốt và hiệu quả.

2.1. Xác định phạm vi và mục đích của việc test: Điểm quan trọng đầu tiên là bạn phải:

• Xác định được những điểm có thể test được trong đống đặc tả yêu cầu đó.
• Hiểu mục đích của việc test
• Bạn phải hiểu được nội dung requirements.

2.2. Xác định được cách thực hiện test : Trước khi bắt đầu viết Testcase bạn nên tạo ra test scenarios (kịch bản test) trước. Để tạo đc test scenarios thì bạn phải chắc chắn hiểu rõ chức năng bạn định viết. Phải biết được các hoạt động chính cũng như sự ảnh hưởng tới các chức năng khác như thế nào.

Thông thường thì Thực hiện theo quy trình sau: Test scenario -> test case -> Test Step

Nếu ai chưa rõ sự khác nhau giữa test scenario và test case như thế nào thì tôi định nghĩa qua như dưới đây.

• Test Scenario – thường có được trực tiếp từ các đặc tả yêu cầu của khách hàng hoặc user-story. Các công cụ quản lý thường bỏ qua test scenario để kết nối với một danh sách các đặc tả yêu cầu. Scenario chứa một danh sách các Testcase.

• Test Case – là một danh sách các test step. Cũng định nghĩa trạng thái môi trường và có thể liên kiết đến các bug, spec (đặc tả yêu cầu) liên quan,…

• Test Step – quy định cụ thể một hành động để thực hiện, và đáp ứng mong đợi của ứng dụng test.

2.3. Xác định yêu cầu phi chức năng (Non-Functional Requirements). Cùng với yêu cầu chức năng thì yêu cầu Phi chức năng cũng quan trọng không kém. Về cơ bản thì các yêu cầu Phi chức năng gồm những mục như dưới đây:

(1) Hiệu năng hoạt động:

• Yêu cầu về thời gian
• Tài nguyên sử dụng
• Công suất tối đa

(2) Tương thích:

• Cùng tồn tại
• Tương tác liên thông

(3) Tính khả dụng: là mức độ sử dụng được và làm hài lòng người sử dụng như:

• Phù hợp với nhu cầu
• Dễ dàng học cách sử dụng
• Giao diện người sử dụng
• Khả năng truy cập, khai thác

(4) Tính tin cậy:

• Khả năng chịu lỗi
• Khả năng phục hồi
• Thời gian giữa các lần xảy ra sự cố gián đoạn hoạt động của hệ thống.

(4) An toàn thông tin:

• Bảo mật
• Toàn vẹn
• Xác thực

(5) Duy trì được là Phân tích được.

• Thích ứng: là hỗ trợ và sử dụng các trình duyệt thông dụng hiện nay như Micrsoft Internet Explorer, Google Crome, Mozila Firefox…
• Cài đặt được
• Vận hành
• Khai thác
• Khả năng thay thế được

Nếu bạn chưa hiểu rõ về Non-Function thì có thể tham khảo link sau : http://www.slideshare.net/vuhung16plus/non-functional-requirements-checklist

2.4. Xác định được quan điểm cần có trong file testcase:

Tùy vào requirements của hệ thống mà quyết định thiết kế file test case như thế nào. Thông thường trong file testcase phải cover được: các chức năng cơ bản, tính tích hợp, giao diện UI, khả năng chịu lỗi, Hiệu suất.

2.5. Cấu trúc file Testcase:

Tại thời điểm này bạn đã có tất cả các thông tin cần thiết để bắt đầu viết scenarios và testcase. Mỗi test scenarios có một hoặc nhiều testcase.

3. Những điểm quan trọng để file Testcase của bạn tốt hơn:

3.1 File testcase cần có những step test đơn giản, minh bạch, dễ hiểu :

• Step test phải viết chi tiết rõ rạng để khi thực hiện không gặp vướng mắc gì.
• Mục đích và phạm vi của testcase cũng được mô tả chi tiết.
• Điều kiện tiền đề, data test cũng phải được ghi ở từng testcase nếu cần.
• Testcase nên được review chéo bởi member trong team.

3.2 Các trường hợp thử nghiệm nên có giá trị, tóm tắt và ngắn:

• Các testcase chỉ nên có các bước cần thiết và hợp lệ. Nếu một case có quá nhiều step, nội dung lan man. Khi thực hiện sẽ gây ra mất tập chung và sai mục đích Test của testcase.
• Không nên gộp quá nhiều kết quả confirm vào 1 case mà nên tách mỗi kết quả confirm ra từng case.
• Khi tạo testcase Nên đứng ở vị trí End use.
• Không nên lặp lại test case.

3.3 Testcase nên có sự liên kết: + Mỗi một testcase hay một cụm test case nên đánh ID của requirement để đảm biết rằng testcase đã cover đủ 100% spec chưa. + Việc đánh ID requirement với Testcase nhằm mục đích khi thay đổi 1 phần req thì chúng ta có thể dễ dàng biết được số lượng testcase cần thay đổi theo.

3.4 Test Case có thể bảo trì. (Maintainable)

Testcase nên viết theo cách mà có thể dễ dàng được bảo trì, update. Nên đánh ID làm sao có thể link được tới req để khi thay đổi yêu cầu thì dễ dàng thấy được mức ảnh hưởng tới testcase.

3.5 Testing Techniques – Positive And Negative Test Cases + Testcase nên cover các trường hợp kiểm thử như: Phân lớp tương đương, giá trị biên, điều kiện normal và abnormal. + Nên cover cả các trường hợp của stress test, điều kiện error… + Cả các trường hợp free test không có trong đặc tả yêu cầu.

3.6 Chuẩn bị dữ liệu Test. Dữ liệu test nên đa dạng ướng với các trường hợp kiểm thử. Các dữ liệu hợp lệ, không hợp lệ, data lỗi…

3.7 Non-Functional testing: gồm các kiểu test như sau + Performance testing + Khả năng chịu tải + Tính bảo mật + Tính quyền hạn + Quản lý session, loggin methods.

3.8 Usability Testing + Khả năng ứng dụng cao + UI thân thiện với người dùng : mầu sắc, font chữ, size chữ, ngữ pháp câu chữ…

Kết luận:

Test case được viết ra để check các hoạt động của chức năng có đúng như spec mong muốn không. Testcase cơ bản bao gồm: Testcase ID, Test step, Kết quả mong muốn, Kết quả thực tế.

Trong khi viết Testcase nên cố gắng viết đơn giản, dễ hiểu.

Trước hết là các yêu cầu chức năng sau đó đến trường hợp kiểm thử phi chức năng, Vì cả 2 trường hợp kiểm thử đó đều quan trọng không kém để cải thiện chất lượng của ứng dụng.