Nội dung
1. Khái niệm: Testcase là gì?
- Testcase là tập hợp tất cả các trường hợp có thể xảy ra mà Tester có thể dựa vào đó để xác định được liệu một ứng dụng hoặc hệ thống phần mềm có hoạt động đúng với yêu cầu mong muốn của khách hàng hay không.
2. Các bước tạo ra testcase
Bước 1: xác định mục đích test
- Đầu tiên, bạn phải đọc requirement của khách hàng và xác định được yêu cầu của hệ thống, phải hiểu rõ mục tiêu mình cần phải làm.
Bước 2: xác định hiệu suất testing
- Để viết được kịch bản thử nghiệm tốt, bạn phải hiểu được hệ thống mà mình sắp test.
- Bạn cần biết cái bạn đang test có chức năng gì, dữ liệu của nó có ảnh hưởng đến các phần khác hay không.
Bước 3: xác định các yêu cầu phi chức năng
- Ở bước này các bạn cần xác định về các yêu cầu phi chức năng (non-function) như yêu cầu về phần cứng, hệ điều hành, version, performance, security …
- Ngoài thực hiện test chức năng, việc test các yêu cầu phi chức năng là rất quan trọng.
- Ví dụ:
- Kiểm tra thời gian load 1 trang web, tốc độ xử lý 1 trang web khi có số lượng lớn user đăng nhập cũng 1 lúc (Performance test).
- Kiểm tra việc đăng nhập vào hệ thống = session của user khác (security test), kiểm tra thời gian đăng nhập (login) để đảm bảo phiên làm việc của người dùng không bị hết hạn.
Bước 4: xác định biểu mẫu cho testcase
- Trong các trường hợp thử nghiệm nên bao gồm giao diện (UI), chức năng (function), khả năng chịu lỗi, khả năng tương thích và hiệu suất của 1 số chức năng. Mỗi thể loại cần được xác định sao cho phù hợp với logic của sản phẩm phần mềm.
Bước 5: xác định sự ảnh hưởng giữa các module, chức năng (function) và màn hình (screen)
- Một hệ thống phần mềm bao gồm rất nhiều module, và các module đều có mối liên hệ với nhau, bạn cần hiểu rõ chức năng của từng module và sự tương tác của các module với nhau.
- Testcase nên được thiết kế để đảm bảo độ bao phủ tối đa giữa các module với nhau. Muốn biết được vấn đề đó, bạn cần xác định rõ được tính năng của từng module riêng biệt, cách thức nó hoạt động tương tác với module khác như thế nào?
- Ví dụ: khi test về việc book vé máy bay online, sau khi book vé thành công ngoài việc kiểm tra thông tin khách hàng, thông tin chuyến bay và giá tiền đã đúng hay chưa, còn phải kiểm tra nếu book thành công thì số lượng ghế thuộc chuyến bay đó có bị giảm không? nếu xoá chuyến bay đi thì số lượng ghế có tăng lại hay không?
3. Cấu trúc của 1 testcase
Bên dưới là cấu trúc 1 test case mẫu. Nó có thể sẽ thay đổi ở các công ty khác nhau.
- Testcase ID: số lượng testcase
- Function: dựa vào chức năng của hệ thống có thể chia nhỏ function ra để tạo testcase rõ ràng hơn
- Title: Mô tả ngắn gọn nội dung mình cần verify
- Pre-condition: điều kiện cần để có thể thực hiện test case
- Test steps: mô tả các bước thực hiện, nên mô tả ngắn gọn, rõ ràng, không nên bỏ qua các sự kiện thiết yếu để có thể dễ dàng tái hiện lại khi có lỗi. Thông thường Test steps sẽ thể hiện các action của 1 user
- Expected results: kết quả mong đợi từ các bước thực hiện trước
- Test result: thông thường sẽ là Pass, Fail và Pending. Đây là kết quả thực tế sau khi tự hiện Test steps
- Test Environment: mình có thể test trên Window (Chrome, Firefox, …) hoặc Mac book (Safari)
- Executed Date: ngày thực hiện test case
- Tester: người thực hiện test
- Comment/Note: cột này dùng để note lại các screen shoot, bug ID hoặc các thông tin liên quan khi thực hiện testcase
4. Xác định các trường hợp kiểm tra
Để thiết kế nên bộ test case hiệu quả, đảm bảo chất lượng phần mềm, các bạn có thể áp dụng các trường hợp kiểm tra sau:
- Normal case : Các trường hợp kiểm thử thông thường
- Abnormal case : Các trường hợp kiểm thử bất bình thường
- Boundary case: Các trường hợp kiểm tra giá trị biên
Ví dụ 1: requirement yêu cầu thêm mới button Close cho modal Add Template, khi bấm vào Close thì modal Add Template sẽ ẩn đi
- Normal case: click vào button Close -> đóng được modal
- Abnormal case: click chuột phải vào button Close -> modal không được đóng lại
Ví dụ 2: chương trình khuyến mãi được áp dụng cho những khách hàng từ 10 tuổi đến 20 tuổi
- Boundary case cho trường hợp này:
- = 10 tuổi
- < 10 tuổi
- > 10 tuổi và < 20 tuổi
- = 20 tuổi
- > 20 tuổi
5. Ví dụ: Thực hiện viết test case cho form login
B1: Xác định yêu cầu:
- User name:
- User name không được để trống
- Độ dài phải nằm trong khoảng 5-30 kí tự
- Password:
- Password không được để trống
- Độ dài ít nhất >= 8 kí tự
- Phải chứa kí tự đặc biệt, số và chữ
- Error message:
- User name không được để trống
- User name phải nằm trong khoảng 5-30 kí tự
- Password không được để trống
- Độ dài Password phải >= 8 ký tự
- Password phải chứa kí tự đặc biệt, số và chữ
- User name hoặc Password đã nhập sai
- Nhập đúng User name và password sẽ chuyển sang màn hình kế tiếp
B2: Xây dựng testcase:
- UI:
- Kiểm tra icon, font size, font style, font color của các text trên màn hình login & Error validation
- Kiểm tra placeholder Username, Password mờ hoặc biến mất khi click/nhập vào Username, Password textbox
- Kiểm tra chức năng copy, paste vào Username, Password textbox
- Kiểm tra button “Sign In” highlighted khi hover mouse
- Kiểm tra right click với button “Sign in”
- Function:
- User name:
- Đăng nhập không thành công với Username để trống -> hiển thị error message “User name không được để trống”
- Đăng nhập không thành công với Username < 4 kí tự -> hiển thị error message “User name phải nằm trong khoảng 5-30 kí tự
- Đăng nhập không thành công với Username > 30 kí tự -> hiển thị error message “User name phải nằm trong khoảng 5-30 kí tự
- Đăng nhập không thành công với Username không hợp lệ -> hiển thị error message “User name hoặc Password đã nhập sai”
- Đăng nhập thành công với Username hợp lệ
- Check kí tự thường, kí tự đặc biệt
- Check number character
- Check Japanese: Full size, half size, katakana, hiragana, kanji
- Password:
- Đăng nhập không thành công với Password để trống -> hiển thị error message “Password không được để trống”
- Đăng nhập không thành công với Password không có kí tự đặc biệt hoặc số hoặc chữ -> hiển thị error message: “Phải chứa kí tự đặc biệt, số và chữ”
- Đăng nhập không thành công với password không hợp lệ. => Hiện thị tin nhắn “Username hoặc Password đã nhập sai”
- Đăng nhập không thành công với password < 8 kí tự. => Hiện thị tin nhắn ” Độ dài Password phải >= 8 ký tự”
- Đăng nhập thành công với Password hợp lệ
- Check kí tự thường, kí tự đặc biệt
- Check Japanese: Full size, half size, katakana, hiragana, kanji
- Sign in:
- Chưa nhập text cho Username, Password -> Sign in disable
- Chỉ nhập text cho Username hoặc Password -> Sign in disable
- Nhập sai Username hoặc Password -> Sign in disable
- Nhập đúng Username và Password -> Sign in enable
- Click Sign in -> đăng nhập thành công
- Click Sign in nhiều lần -> đăng nhập thành công
- User name:
- Securiry/Session:
- Password không được lưu trong browser cookies
- Password phải được phân biệt Upper và lower case
- Khi reset/refresh màn hình, password, username phải clear
- User login từ 2 tab browser: Cùng mở 2 tabs, login từng tab. nếu sinh ra 2 session là lỗi
- User login 2 account trên cùng 1 browser, session account login trước phải kết thúc
- Performance:
- Ví dụ như thời gian phản hồi sau khi login xong không quá 3s
- API Test:
- Mặc dù trên UI đã chặn ko cho nhập textbox user < 5 or >30 kí tự. Nhưng trên khi mình test API, mình có thể nhập ít hoặc nhiều hơn. Do đó, mình sẽ test api và check response data nó sẽ trả về như thế nào? có đúng với expected của mình mong muốn không?
Bài viết được mình tham khảo từ:
https://viblo.asia/p/huong-dan-tao-test-case-co-ban-5y8Rr6dNRob3
https://viblo.asia/p/bai-tap-viet-test-case-cho-form-login-gDVK2GLXZLj