Bug là một thuật ngữ mà khi nhắc đến thì mỗi lập trình viên đều muốn tránh xa. Nên người ta đã đưa ra các rất nhiều phương pháp để hạn chế nó. Trong đó, có cả các kỹ thuật kiểm thử phần mềm (testing) được rất nhiều người áp dụng. Bài viết dưới đây sẽ phân thành 3 dạng testcase.
Dạng 1: Testcase dựa vào “Spec/Document”
Như mọi người đã biết, khi viết testcase, trước hết sẽ tập trung vào việc xây dựng những testcase cơ bản nhất, đặc biệt là những testcase liên quan đến các tính năng chính hoặc quan trọng nhất. Điều này nhằm đảm bảo rằng dự án của bạn có thể hoạt động đúng theo yêu cầu được mô tả trong tài liệu/spec. Sau khi những testcase cơ bản này đã chạy một cách ổn định, bạn mới chuyển sang việc xây dựng những testcase phức tạp hơn.
Dạng 2: Testcase dựa vào “User Flow”
Hãy tưởng tượng rằng nếu bạn là một người dùng bình thường, không biết gì về quy trình làm việc của ứng dụng hoặc dự án, điều này sẽ giúp bạn thực hiện kiểm thử một cách tự nhiên và sáng tạo. Quá trình kiểm thử sẽ diễn ra theo các bước từng buổi màn hình một, không cần phải biết rằng mỗi chức năng nên hoạt động như thế nào ở mỗi điểm, chỉ cần viết các testcase theo cách logic nhất có thể. Bởi vì người dùng cuối cùng không cần phải hiểu về tài liệu hay đặc tả kỹ thuật, họ chỉ quan tâm đến tính logic và sự thuận tiện của sản phẩm theo cách họ sử dụng.
Ví dụ:
Có những case vừa phải điền thông tin số tuổi, vừa phải điền CMND để đăng ký về BHXH. Nếu spec chỉ mô tả: số tuổi hợp lệ là nhỏ hơn hoặc bằng 90 và chỉ cần số CMND valid thôi thì user làm sao đăng ký được cho những người từ 14 tuổi trở xuống (vì họ chưa có CMND) => Nếu mà chỉ dựa theo doc, thì tester đã bị sót case này rồi! Nhưng user thì sẽ không sót vì họ không cần bám vào yêu cầu của doc/ spec <= Vì họ test theo logic của họ, theo thực tế của họ.
Dạng 3: Testcase dựa vào “Complicated Flow”
Sau khi bạn đã viết testcase theo 2 dạng trên một cách đầy đủ rồi, thì đây là khoảng thời gian bạn sẽ bắt tay vào viết những case mang tính chất “phức tạp”, “rối não”. Tùy vào kinh nghiệm của mỗi người, tùy vào độ sáng tạo của mọi người trong quá trình testing mà mình sẽ có những cách tạo ra những case phức tạp khác nhau. Để viết được những testcase dạng này, thì phải lựa khoảng thời gian nào mà mình cảm thấy minh mẫn nhất.
Ví dụ 𝟏: Một Feature tạo event thì có 5 steps.
- Nếu đi theo flow bình thường, thì bạn sẽ đi tuần tự từ step 1 đến step 5.
- Nếu đi theo flow phức tạp, thì có người sẽ đi từ step 1 đến step 4, sau đó back về step 2, rồi đi lên lại step 5. Và check xem có sự thay đổi gì giữa các steps hay không?
Ví dụ 2: Một Feature kết bạn bằng cách nhập sponsor code của bạn bè, click submit thì sẽ hiển thị trang congratulation.
- Nếu đi theo flow bình thường, thì tới screen nhập sponsor code bạn sẽ nhập sponsor code, click submit, hiển thị congratulation.
- Nếu đi theo flow phức tạp, thì sau khi nhập sponsor code, click submit, hiển thị trang congratulation:
- Click back button để trở về screen nhập sponsor code xem nó display như thế nào? Nó có cho back về screen này không? Nếu nó lại cho bạn nhập sponsor code thêm một lần nữa thì chuyện gì sẽ xảy ra? Rồi Database sẽ hiển thị ra sao?
- Nếu là web-app, hãy thử close window rồi access vào lại. Check thử xem nó có vô lại đúng màn hình congratulation hay không? Hay nó vô thẳng app và mặc định bạn đã đăng ký thành công? Hay nó lại buộc bạn nhập lại sponsor code…
Trên đây là ba dạng viết testcase mà bài viết muốn chia sẻ với các bạn để minh họa cho các trường hợp phức tạp và để giúp bạn hiểu rõ cách tổ chức và viết testcase. Tuy nhiên, đây chỉ là một số ví dụ về các trường hợp phức tạp ở mức độ thấp. Trong thực tế, có vô số các trường hợp phức tạp và những thách thức đòi hỏi sự sáng tạo và khéo léo trong quá trình kiểm thử.
Nếu bạn đang tìm kiếm các trường hợp phức tạp hơn hoặc muốn thách thức bản thân, hãy tự thêm các yếu tố như tính bảo mật, tương tác giữa các tính năng, và các tình huống đặc biệt. Bạn cũng có thể linh hoạt chuyển đổi giữa cách viết testcase và cách tìm lỗi để đảm bảo rằng bạn đang tận dụng tối đa kỹ năng của mình và mang lại hiệu quả tốt nhất cho công việc kiểm thử của mình.
Giảng viên Nguyễn Thị Thuỳ
Bộ môn Ứng dụng phần mềm
FPT Polytechnic Hà Nội
