180+ mẫu testcase cho test web và Desktop application
Như các bạn đã biết tạo ra bộ testcase chất lượng trước khi bắt đầu thực hiện công việc kiểm thử phần mềm, là một bước rất quan trọng trong việc quản lý chất lượng sản phẩm phần mềm. Chúng ta cần tạo bộ testcase đảm bảo các tiêu chí - số lượng testcase vừa đủ, không dư thừa case hay thiếu case, nội ...
Như các bạn đã biết tạo ra bộ testcase chất lượng trước khi bắt đầu thực hiện công việc kiểm thử phần mềm, là một bước rất quan trọng trong việc quản lý chất lượng sản phẩm phần mềm. Chúng ta cần tạo bộ testcase đảm bảo các tiêu chí - số lượng testcase vừa đủ, không dư thừa case hay thiếu case, nội dung có thể cover hết các trường hợp cần phải kiểm thử để đảm bảo không bỏ sót lỗi. Trong quá trình tìm hiểu để tạo bộ testcase, mình có tham khảo được một bài báo "180+ Sample Test Cases for Testing Web and Desktop Applications – Comprehensive Testing Checklist" - tổng hợp những trường hợp cho test web và application trên desktop khá hay. Mình xin chia sẻ để mọi người cùng tham khảo.
** 1. Tầm quan trọng của việc sử dụng checklist cho việc kiểm thử phần mềm**
- Giữ gìn, duy trì một bộ testcase tiêu chuẩn, có khả năng sử dụng lại sẽ đảm bảo hầu hết lỗi phổ biến sẽ được tìm thấy một cách nhanh chóng.
- Checklist giúp có thể nhanh chóng hoàn thành viết testcase cho version mới của application
- Việc sử dụng lại testcase sẽ giúp tiết kiệm được chi phí cho resource viết những nội dung test bị lặp lại.
- Những testcase quan trọng được cover sẽ giúp người viết không thể nào có thể quên, bỏ sót testcase đó được.
- Checklist có thể được đưa cho nhóm phát triển tham khảo để đảm bảo phần lớn những vấn đề quan trọng sẽ được fix trước ngay trong quá trình thực hiện code ban đầu.
** 2. Một số điểm cần nhớ**
- Cần phải test những scenarios này với các user có các role khá nhau như admin user, guest user v.v
- Với những scenarios cho ứng dụng web thì cần test trên nhiều loại browser khác nhau như IE, FF, Chrome, Safari với nhiều version khác nhau mà client support.
- Test với nhiều loại màn hình có size khác nhau như 1024x768, 1280 x 1024 v.v
- Ứng dụng nên được test với nhiều display khác nhau như LCD, CRT, Notebooks, Tables, Mobile phones.
- Ưng dụng nên được test trên nhiều platform khác nhau như Windows, Mac, Linux.
Giả sử rằng ứng dụng support những chức năng dưới đây
- Form với nhiều trường khác nhau
- Cửa sổ con
- Ứng dụng có tương tác với database
- Những tiêu chí chọn lọc khác nhau và hiển thị kết quả
- Có thực hiện upload image
- Có thực hiện gửi mail
- Có thực hiện export data
Test Scenario chung
- Tất cả các trường bắt buộc phải được validate và phải được chỉ định bằng dấu hoa thị *
- Message lỗi hiển thị khi thực hiện validate phải được hiển thị hợp lý ở đúng vị trí
- Tất cả các message lỗi cần phải được hiển thị cùng kiểu CSS (ví dụ như cùng màu đỏ)
- Các message confirm thông thường nên hiển thị với kiểu CSS khác với message lỗi (Ví dụ như để message màu xanh, chứ ko phải màu đỏ như message lỗi)
- Dòng tool tip text phải có ý nghĩa
- Các trường dropdown nên có giá trị nhập vào đầu tiên là blank hoặc dòng text như 'Select'
- Việc xóa bất cứ record nào trong page nên có hiển thị message hỏi confirm có thật sự muốn xóa hay không
- Option select hay deselect tất cả các record nên được cung cấp nếu như page có hỗ trợ chức năng add thêm record, delete record hay update record
- Giá trị số tiền sẽ được hiển thị bằng các ký hiệu tiền tệ chính xác.
- Nên có thực hiện sort cụ thể khi mở trang default
- Button reset nên set tất cả các trường về giá trị default
- Các giá trị kiểu số nên có format hợp lý
- Những trường nhập vào nên có check giá trị tối đa. Việc nhập giá trị lớn hơn giá trị tối đa sẽ không được chấp nhận hoặc không được lưu vào trong database
- Kiểm tra tất cả các trường nhập vào với ký tự đặc biệt
- Label của các trường nên theo đúng tiêu chuẩn. Ví dụ như trường first name của accepting user nên có label là First name
- Kiểm tra chức năng sort page sau khi thực hiện add/edit/delete record
- Kiểm tra chức năng timeout.Giá trị timeout nên được set rõ ràng. Kiểm tra xử lý của hệ thống sau khi bị timeout
- Check các cookies được sử dụng trong application
- Check xem các file có thể download có được chỉ đến đường dẫn file chính xác không
- Tất cả các key nguồn nên được thiết lập trong file config hoặc database, thay vì thiết lập cố định trong code
- Những quy ước chuẩn cần phải được triệt để áp dụng xuyên suốt cho việc đặt tên key nguồn (resource key)
- Thực hiện validate markup cho tất cả các trang web để đảm bảo rằng nó phù hợp với tiêu chuẩn
- Khi ứng dụng bị crash hay có những trang web không access vào được thì cần chuyển tới trang error page
- Kiểm tra nội dung text hiển thị trên tất cả các trang cho lỗi chính tả và lỗi ngữ pháp
- Kiểm tra xử lý khi nhập giá trị chữ vào các trường số. Cần hiển thị ra message validate hợp lý
- Kiểm tra với các số âm nếu cho phép nhập số âm vào các trường số
- Kiểm tra các trường tiền khi nhập giá trị là số thập phân
- Kiểm tra hoạt động của tất cả các button có trên tất cả các trang web
- Không để cho user có thể submit trang web 2 lần bằng cách ấn nhanh button submit
- Lỗi khi chia cho 0 nên được xử lý cho tất cả các công thức tính toán
- Việc nhập dữ liệu ở vị trí blank đầu tiên và vị trí blank cuối cùng cần được xử lý chính xác
Test Scenario cho GUI và Usability
- Tất cả các trường trên website như text box, radio button, dropdown list nên được chỉnh thẳng hàng
- Những giá trị số nên được căn chỉnh hiển thị về bên phải trừ khi có những yêu cầu đặc biệt khác
- Giữa label của trường, cột hàng, hay message cần có khoảng trống vừa đủ
- Scroll bar chỉ nên được enable lên khi cần thiết
- Cỡ font, kiểu style và màu sắc của headline, dòng text miêu tả, label, infield data, grid info nên theo đúng tiêu chuẩn như đã được mô tả trong SRS
- Text box miêu tả nên hiển thị thành nhiều dòng
- Các trường disable nên được bôi xám và user không thể click con trỏ vào những trường này
- Khi click vào các trường nhập text thì dấu mũi tên của con chuột nên được chuyển sang dấu nháy
- User không thể gõ nhập vào list chọn dropdown
- Sau khi user nhập thông tin, khi ấn submit mà hiển thị message lỗi thì những thông tin đã nhập vào phải được giữ nguyên. Sau khi sửa lại lỗi theo message thì user sẽ submit lại được.
- Kiểm tra xem trên message lỗi thì label các trường có được sử dụng hợp lý chưa
- Giá trị trường dropdown nên được hiển thị với một trật tự sort đã được định nghĩa sẵn
- Thứ tự chạy focus khi ấn Tab hay Shift+Tab hoạt động đúng
- Radio option default cần được chọn sẵn khi load trang web
- Nên có sẵn đặc tả cho các trường hay message hướng dẫn cho trang web
- Kiểm tra xem các trường bị nhập/thiết lập sai có bị highlight lên không
- Kiểm tra xem các option trong list dropdown có thể đọc được không và không bị cắt cụt do size của trường không đủ
- Tất cả các button trong website cần phải chọn được bằng shortcut keyboard và user có thể thực hiện được mọi thao tác bằng cách sử dụng keyboard
- Kiểm tra tất cả các trang xem có image hỏng không
- Kiểm tra tất cả các trang xem có link hỏng không
- Tất cả các trang nên có title
- Message confirm nên hiển thị khi thực hiện nghiệp vụ upate hay delete
- Đồng hồ cát nên được hiển thị khi application đang bị busy
- Các dòng text trong trang web nên được căn chỉnh thẳng hàng về bên trái
- User chỉ có thể lựa chọn 1 radio option và có thể chọn kết hợp nhiều lựa chọn với checkbox
Test scenario cho tiêu chuẩn filter
- User có thể filter các kết quả sử dụng các parameter trên website
- Chức năng tìm kiếm lọc (refine search) nên load tất cả các trang search với tất cả các user đã lựa chọn search parameter
- Khi yêu cầu bắt buộc phải có ít nhất 1 filter criteria để thực hiện search, thì cần check khi user không chọn bất kỳ một filter criteria nào rồi submit trang web thì sẽ hiển thị lên message lỗi với nội dung hợp lý
- Khi không bắt buộc phải có ít nhất 1 filter criteria thì user pahir thực hiện submit page được và search criteria default sẽ được sử dụng để query kết quả
- Message validate cần phải được hiển thị lên khi có những value không valid trong filder criteria
Trong bài viết này, do thời gian có hạn nên mình xin được trình bày trước 3 test scenario. Các scenario còn lại, mình xin được trình bày tiếp ở các bài viết sau. Cảm ơn các bạn đã quan tâm.