Kiểm thử phần mềm: Các kỹ thuật thiết kế kiểm thử (Phần 1).

Tiếp tục series tóm tắt từ cuốn sách: FOUNDATIONS OF SOFTWARE TESTING ISTQB CERTIFICATION của tác giả Dorothy Graham, Erik van Veenendaal, Isabel Evans và Rex Black và một số kinh nghiệm của cá nhân trong quá trình làm việc nhằm cung cấp cho các bạn một cái nhìn tổng quan về kiểm thử phần mềm và các kiến thức cơ bản về kiểm thử, các kỹ thuật dùng trong kiểm thử và các công cụ hỗ trợ.

Tiếp nối bài viết trước Kiểm thử phần mềm: Các kỹ thuật tĩnh (Static techniques) trong bài viết lần này mình sẽ giới thiệu với các bạn các kỹ thuật thiết kế kiểm thử bài đầu tiên là cách Xác định điều kiện test và thiết kế các test case.

1. Giới thiệu.

Trước khi bắt đầu kiểm thử chúng ta cần xác định mình đang cố gắng kiểm tra cái gì, đầu vào, các kết quả cần đạt được. Trong phần này chúng ta sẽ xem xét ba điều kiện sau: điều kiện kiểm thử, testcase và các thủ tục kiểm thử (hoặc các kịch bản). Các điều kiện kiểm thử được ghi lại trong tài liệu chi tiết kỹ thuật thiết kế kiểm thử và chúng ta sẽ xem xét chọn điều kiện kiểm thử và ưu tiên chúng như thế nào. Cách viết testcase như thế nào cho tốt, nguồn gốc để có cơ sở của kiểm thử. Các thủ tục được ghi lại trong quy trình kiểm thử như thế nào, xem xét việc tạo ra một kế hoạch thực thi kiểm thử và sử dụng các ràng buộc về sự ưu tiên, kỹ thuật và logic như thế nào?.

Trong phần này chúng ta sẽ đi tìm hiểu các định nghĩa của các thuật ngữ sau: test case, testcase specification, test condition, test data, test procedure specification, test script and traceability.

2. Hình thức của tài liệu test.

Kiểm thử chính thức(formal testing) giúp kiểm soát tốt hơn các tài liệu có phạm vi rộng. Tài liệu chi tiết ghi lại, bao gồm: các đầu vào cụ thể và chính xác, kết quả kỳ vọng.

Kiểm thử không chính thức có thể không có tài liệu hướng dẫn hoặc chỉ được ghi chú lại bởi cá nhân người kiểm thử.
Mức độ hình thức của tài liệu cũng chịu ảnh hưởng từ công ty như: văn hóa, nhân viên, các quy trình phát triển hoàn thiện như thế nào?, quy trình kiểm thử hoàn thiện như thế nào?. Tính toàn vẹn của tài liệu kiểm thử cũng phụ thuộc vào ràng buộc thời gian, áp lực thời gian qua hạn, một tài liệu tốt có thể bị xâm phạm.

3. Xác định điều kiện kiểm thử (test conditions).

Một điều kiện kiểm thử là một vấn đề đơn giản nào đó mà chúng ta có thể kiểm tra được hay nói cách khác: một điều kiện kiểm thử được xác định là một mục hoặc một sự kiện của một thành phần hoặc hệ thống có thể được xác nhận bởi một hoặc nhiều trường hợp kiểm tra. Nếu muốn đo độ bao phủ của các quyết định code thì cơ sở kiểm thử sẽ chính là code và danh sách điều kiện kiểm thử sẽ là kết quả của các quyết định ( đúng hoặc sai).

Khi xác định điều kiện kiểm thử chúng ta mong muốn mở rộng để xác định được nhiều nhất có thể các điều kiện kiểm thử, rồi sau đó chọn lọc cái nào cần phát triển chi tiết hơn và đưa vào test case (gọi là khả năng kiểm thử-test possibilities). Các điều kiện kiểm thử có thể xác định cho dữ liệu kiểm thử cũng như kiểm tra các đầu vào, kết quả đầu ra.

ví dụ: các loại bản ghi khác nhau, sự phân bố khác nhau của các loại tài liệu trong một file hoặc cơ sở dữ liệu, kích thước khác nhau của tài liệu hoặc các trường trong một bản ghi.

4. Xác định test case.

Một test case bao gồm một tập hợp các giá trị đầu vào, điều kiện tiên quyết thực hiện, kết quả mong đợi và hậu thực hiện, phát triển cho một điều kiện khách quan hoặc kiểm tra cụ thể. Khi xác định một test case cần đầu vào cụ thể, chính xác và chi tiết để những người không biết gì về hệ thống cũng có thể test được.
Khi một giá trị đầu vào của hệ thống đã cho được chọn, tester cần xác định kết quả mong đợi ban đầu là gì và ghi lại nó như một phần của test case. Kết quả mong đợi bao gồm thông tin được hiển thị trên màn hình để phản hồi đầu vào, các thay đổi đối với dữ liệu hoặc trạng thái và bất kỳ ảnh hưởng nào khác của kiểm thử.
Các test case có độ ưu tiên cao hơn sẽ được thực hiện trước, test case có độ ưu tiên thấp sẽ được thực hiện sau hoặc có thể không được thực hiện.

5. Xác định các thủ tục/kịch bản kiểm thử(Test procedures or scripts).

Bước tiếp theo là nhóm các testcase một cách hợp lý để thực hiện chúng và xác định các bước tuần tự cần phải được thực hiện để chạy thử.

Thủ tục kiểm thử: Tài liệu quy định một chuỗi các hành động để thực hiện một kiểm tra. Còn được gọi là kịch bản kiểm thử. Nó phụ thuộc vào kĩ năng và kiến thức của tester, đồng thời cũng phụ thuộc vào yêu cầu từ tài liệu.
Kế hoạch kiểm thử sẽ cho biết khi nào thì một kịch bản được thực hiện và được thực hiện bởi ai, kế hoạch có thể thay đổi tùy thuộc vào những rủi ro mới có ảnh hưởng đến mức độ ưu tiên của một kịch bản nhằm giải quyết những rủi ro đó. Các sự phụ thuộc về logic và kỹ thuật giữa các kịch bản cũng sẽ được tính đến khi lên kế hoạch cho các kịch bản. Ví dụ một kịch bản hồi quy có thể luôn được chạy đầu tiên khi có phiên bản mới của phần mềm đến, như smoke test hoặc sanity check.
Chúng ta sẽ tìm hiểu một chút về smoke test và sanity check nhé.

• Smoke test là một loại kiểm thử phần mềm giúp đảm bảo rằng các chức năng chính của ứng dụng hoạt động tốt. Loại thử nghiệm này còn được gọi là "Build Verification testing". Nó là một kiểu thử nghiệm không đầy đủ với các trường hợp kiểm tra rất hạn chế nhằm đảm bảo những tính năng quan trọng hoạt động đúng và sẵn sàng để test chi tiết.
• sanity check là một kỹ thuật kiểm thử phần mềm được thực hiện sau khi nhận được software build, với sự thay đổi nhỏ trong mã, hay chức năng, để xác định rằng các lỗi đã được fix và không còn vấn đề do thay đổi này nữa.

Sự khác nhau giữa smoke test và sanity check:

Viết các thủ tục kiểm thử để ưu tiên các kiểm thử quan trọng được thực hiện trong giới hạn thời gian có sẵn. Có một nguyên tắc mà chúng ta cần áp dụng đó là "Find the scary stuff first" có nghĩa là tìm những thứ đáng sợ trước, còn "đáng sợ" như thế nào thì phải tùy vào nghiệp vụ, hệ thống hay dự án.
Bài viết sau mình sẽ giới thiệu các loại kỹ thuật thiết kế kiểm thử.
Link bài viết tiếp theo Kiểm thử phần mềm: Các kỹ thuật thiết kế kiểm thử (Phần 2).