Mẫu Test Cases để kiểm tra Web và ứng dụng Desktop – Danh sách kiểm tra toàn diện

Đây là một danh sách kiểm thử cho các ứng dụng web và máy tính để bàn.Mục tiêu của bài viết là để chia sẻ một trong những danh sách kiểm thử toàn diện nhất.

Danh sách kiểm thử là một phần không thể thiếu trong quá trình viết Test case. Sử dụng danh sách này, bạn có thể dễ dàng tạo ra hàng trăm test case để thử nghiệm web hoặc ứng dụng desktop. Đây là tất cả các trường hợp kiểm tra phổ biến và nên được áp dụng cho hầu như tất cả các loại ứng dụng. Hãy tham khảo các bài kiểm thử này trong khi viết test case cho dự án của bạn, ngoại trừ các quy tắc kinh doanh ứng dụng cụ thể được cung cấp trong tài liệu SRS.Mặc dù đây là một danh sách kiểm thử thông thường, bạn nên chuẩn bị một danh sách kiểm thử tiêu chuẩn phù hợp với nhu cầu cụ thể của bạn sử dụng trường hợp thử nghiệm dưới đây ngoài với các thử nghiệm ứng dụng cụ thể.

Tầm quan trọng của việc sử dụng checklist cho việc kiểm thử

Duy trì một kho lưu trữ tiêu chuẩn của các trường hợp thử nghiệm tái sử dụng cho các ứng dụng của bạn sẽ đảm bảo các lỗi phổ biến nhất sẽ bị bắt một cách nhanh chóng hơn.
Checklist giúp nhanh chóng hoàn tất viết test case các phiên bản mới của ứng dụng.
Sử dụng lại test case giúp tiết kiệm tiền về nguồn lực để viết kiểm tra lặp đi lặp lại.
Các trường hợp kiểm tra quan trọng sẽ được đảm bảo luôn luôn làm cho nó gần như không thể quên.
Kiểm tra checklist có thể bởi dev để đảm bảo các vấn đề phổ biến nhất được cố định trong giai đoạn phát triển bản thân.

Vài lưu ý cần nhớ:

Thực thi các kịch bản với vai trò người dùng khác nhau ví dụ như người dùng admin, người dùng khách, …
Đối với các ứng dụng web những tình huống này có thể được thử nghiệm trên nhiều trình duyệt như IE, FF, Chrome, và Safari với các phiên bản của khách hàng đã được phê duyệt.
Thử nghiệm với độ phân giải màn hình khác nhau như 1024 x 768, 1280 x 1024, …
Ứng dụng nên được thử nghiệm trên nhiều màn hình như màn hình LCD, CRT, điện thoại xách tay, máy tính bảng, và di động.
Ứng dụng thử nghiệm trên các nền tảng khác nhau như các hệ điều hành Windows, Mac, Linux.

Kiểm tra Checklist toàn diện để kiểm tra ứng dụng Web và Desktop

Giả định : Giả sử rằng ứng dụng của bạn hỗ trợ chức năng sau:

Các forms với các trường khác nhau.
Cửa sổ con.
Ứng dụng tương tác với cơ sở dữ liệu.
Tiêu chí tìm kiếm bộ lọc khác nhau và hiển thị kết quả.
Upload hình ảnh.
Chức năng gửi email.
Chức năng xuất dữ liệu.

Kịch bản thử nghiệm chung

Tất cả trường bắt buộc phải được đánh giá và chỉ định bởi biểu tượng dấu hoa thị (*) .
Thông báo lỗi validate nên được hiển thị chính xác ở đúng vị trí .
Tất cả các thông báo lỗi sẽ được hiển thị trong cùng một phong cách CSS (ví dụ như sử dụng màu đỏ) .
Xác nhận chung thông điệp sẽ được hiển thị sử dụng phong cách CSS khác hơn so với thông báo kiểu lỗi (ví dụ như sử dụng màu xanh lá cây) .
Công cụ lời khuyên văn bản phải có ý nghĩa .
Trường Dropdown nên nhập đầu tiên là trống hoặc văn bản như ‘Select’ .
Xóa chức năng cho bất cứ hồ sơ trên trang nên yêu cầu xác nhận .
Chọn/ bỏ chọn tất cả các hồ sơ tùy chọn cần được cung cấp nếu trang hỗ trợ ghi thêm/ xóa/ cập nhật chức năng .
Giá trị tối đa sẽ được hiển thị với các biểu tượng chính xác .
Mặc định trang phân loại cần được cung cấp .
Cài đặt lại nút chức năng nên thiết lập các giá trị mặc định cho tất cả các trường.
Tất cả các giá trị bằng số phải được định dạng đúng .
Nhập các trường cần được kiểm tra giá trị trường tối đa. Đầu vào giá trị lớn hơn giới hạn tối đa quy định –> không được chấp nhận hoặc được lưu trữ trong cơ sở dữ liệu .
Kiểm tra tất cả các trường đầu vào cho các ký tự đặc biệt .
Trường label nên được tiêu chuẩn, ví dụ như trường chấp nhận tên đầu tiên của người dùng phải được dán nhãn đúng là ‘First Name’.
Kiểm tra phân loại chức năng sau khi thêm / sửa / xóa các hoạt động trên bất kỳ bản ghi.
Kiểm tra các chức năng thời gian chờ. Các giá trị thời gian chờ nên được cấu hình. Kiểm tra hành vi ứng dụng sau khi hoạt động thời gian chờ .
Kiểm tra các tập tin cookie được sử dụng trong một ứng dụng .
Kiểm tra nếu tập tin tải về được trỏ đến sửa đường dẫn tập tin .
Tất cả các phím nguồn lực phải được cấu hình trong tập tin cấu hình cơ sở dữ liệu hoặc thay vì mã hóa cứng.
Tiêu chuẩn phải được theo sau suốt để đặt tên cho phím nguồn .
Xác nhận đánh dấu cho tất cả các trang web (xác nhận HTML và CSS cho các lỗi cú pháp) để chắc chắn rằng nó phù hợp với các tiêu chuẩn .
Crash ứng dụng hoặc các trang không có sẵn nên được chuyển đến lỗi trang .
Kiểm tra văn bản trên tất cả trang chính tả và lỗi ngữ pháp
Kiểm tra các trường đầu vào dạng số với giá trị ký tự đầu vào. Tin nhắn xác nhận thích hợp sẽ xuất hiện .
Kiểm tra cho số âm nếu được phép cho trường số .
Kiểm tra các trường nhập số với giá trị số thập phân .
Kiểm tra chức năng của nút có sẵn trên tất cả các trang .
Người dùng không thể submit trang hai lần bằng cách nhấn nút submit liên tiếp nhanh chóng.
Chia cho 0 có lỗi nên được xử lý cho bất kỳ tính toán .
Dữ liệu đầu vào trống với vị trí đầu tiên và cuối cùng phải được xử lý một cách chính xác.

GUI và khả năng sử dụng các kịch bản thử nghiệm

Tất cả các mục trên trang (ví dụ như hộp văn bản, tùy chọn radio, danh sách thả xuống) nên được sắp xếp đúng.
Các giá trị số nên được quyền biện minh trừ khi có quy định khác.
Đủ không gian cần được cung cấp giữa các trường nhãn, cột, dòng, thông báo lỗi, …
Thanh Scroll nên được kích hoạt khi cần thiết .
Kích thước font chữ, phong cách và màu sắc cho dòng tiêu đề, mô tả văn bản, nhãn, dữ liệu infiled, và thông tin điện lưới nên được tiêu chuẩn theo quy định tại SRS.
Mô tả hộp văn bản nên đa đường.
Trường Disabled nên được chuyển sang màu xám và người sử dụng không nên thiết lập tập trung vào các trường này.
Sau khi bấm vào bất kỳ trường văn bản đầu vào, con chuột mũi tên con trỏ nên được thay đổi để trỏ.
Người dùng không nên gõ vào thả xuống chọn danh sách.
10 Thông tin lấp đầy bởi người sử dụng sẽ được giữ nguyên khi có thông báo lỗi trên trang submit. Người sử dụng sẽ nộp submit lại bằng cách sửa chữa các lỗi.
Kiểm tra nếu trường nhãn thích hợp được sử dụng trong các thông báo lỗi.
Giá trị trường Dropdown sẽ được hiển thị trong định nghĩa thứ tự sắp xếp.
Tab và Shift + Tab nên hoạt động đúng.
Tùy chọn mặc định radio nên được lựa chọn trước khi load trang.
Dòng mức cụ thể và trang trợ giúp thông điệp nên có sẵn.
Kiểm tra nếu các trường chính xác đã được nhấn mạnh trong trường hợp lỗi.
Kiểm tra xem tùy chọn danh sách thả xuống là có thể đọc được và không phải cắt ngắn nhờ vào trường kích thước giới hạn.
Tất cả các nút trên trang nên có thể truy cập bằng phím tắt và người dùng sẽ có thể thực hiện tất cả các hoạt động sử dụng bàn phím.
Kiểm tra tất cả các hình ảnh bị broken.
Kiểm tra tất cả các trang liên kết hỏng.
Tất cả các trang nên có tiêu đề.
Thông báo xác nhận sẽ được hiển thị trước khi thực hiện bất kỳ bản cập nhật hoặc xóa các hoạt động.
Giờ glass sẽ được hiển thị khi ứng dụng đang bận.
Trang văn bản nên để biện minh.
Người sử dụng nên có thể chỉ chọn một tùy chọn radio và bất kỳ sự kết hợp với hộp kiểm tra.

Kịch bản thử nghiệm cho bộ lọc tiêu chuẩn

Người sử dụng sẽ có thể lọc kết quả sử dụng tất cả các thông số trên trang chức năng tìm kiếm.
Tinh chỉnh nên tải trang tìm kiếm với tất cả người sử dụng lựa chọn các thông số tìm kiếm.
Khi có ít nhất một trong các tiêu chí lọc là cần thiết để thực hiện các hoạt động tìm kiếm, đảm bảo đúng thông báo lỗi được hiển thị khi người dùng gửi trang mà không chọn bất kỳ tiêu chí lọc.
Khi có ít nhất một trong các tiêu chí lọc lựa chọn không phải là người sử dụng bắt buộc sẽ có thể gửi trang và mặc định tiêu chí tìm kiếm nên được sử dụng để truy vấn kết quả.
Tin nhắn xác nhận đúng sẽ được hiển thị cho các giá trị hợp lệ cho tiêu chí lọc.

Kịch bản thử nghiệm cho lưới kết quả

Biểu tượng tải trang sẽ được hiển thị khi nó lấy nhiều hơn thời gian mặc định để tải các trang kết quả.
Kiểm tra tất cả các thông số tìm kiếm được sử dụng để lấy dữ liệu hiển thị trên lưới kết quả.
Tổng số kết quả sẽ được hiển thị trên lưới kết quả.
Tiêu chí tìm kiếm sử dụng để tìm kiếm sẽ được hiển thị trên lưới kết quả.
Giá trị lưới kết quả nên được sắp xếp theo cột mặc định.
Sắp xếp các cột sẽ được hiển thị với biểu tượng phân loại.
Lưới kết quả nên bao gồm tất cả các cột chỉ định với giá trị đúng.
Tăng dần và giảm dần phân loại chức năng nên làm việc cho cột được hỗ trợ với các dữ liệu phân loại.
Lưới kết quả sẽ được hiển thị với cột thích hợp và khoảng cách giữa các hàng.
Phân trang nên được kích hoạt khi có nhiều kết quả hơn so với kết quả mặc định đếm mỗi trang.
Kiểm tra trang kế tiếp, trước, đầu tiên và trang cuối chức năng phân trang.
Bản ghi trùng lặp không được hiển thị trong kết quả lưới.
Kiểm tra tất cả các cột là nhìn thấy và ngang thanh cuộn được kích hoạt nếu cần thiết.
Kiểm tra dữ liệu cho cột động (cột có giá trị được tính toán tự động dựa trên các giá trị cột khác).
Đối với lưới kết quả cho thấy các báo cáo kiểm tra hàng ‘Totals’ và xác minh tổng thể cho mỗi cột.
Đối với lưới kết quả cho thấy các báo cáo kiểm tra dữ liệu hàng ‘Totals’ khi pagination được kích hoạt và dùng điều hướng đến trang tiếp theo.
Kiểm tra xem các ký hiệu thích hợp được sử dụng để hiển thị các giá trị cột ví dụ như biểu tượng % sẽ được hiển thị để tính tỷ lệ phần trăm.
Kiểm tra dữ liệu lưới kết quả nếu phạm vi giá trị ngày được kích hoạt.

Kịch bản thử nghiệm cho một cửa sổ

Kiểm tra xem kích thước cửa sổ mặc định là chính xác.
Kiểm tra xem kích thước cửa sổ con là đúng.
Kiểm tra nếu có bất kỳ trường trên trang tập trung mặc định (trọng tâm cần được thiết lập trên trường input đầu tiên của màn hình).
Kiểm tra xem cửa sổ con đang nhận được đóng vào đóng cửa sổ cha / mở window.
Nếu cửa sổ con được mở ra, người sử dụng không nên sử dụng hoặc cập nhật bất kỳ trường trên nền hoặc cửa sổ cha.
Kiểm tra cửa sổ tối thiểu, tối đa và chức năng đóng cửa sổ.
Kiểm tra nếu cửa sổ khá lớn.
Kiểm tra chức năng thanh cuộn cho cửa sổ cha và con.
Kiểm tra hủy bỏ chức năng của nút cho cửa sổ con.

Cơ sở dữ liệu kiểm tra kịch bản thử nghiệm

Kiểm tra xem dữ liệu chính xác là nhận được lưu trong cơ sở dữ liệu trên trang submit thành công.
Kiểm tra các giá trị cho các cột mà không chấp nhận giá trị null.
Kiểm tra tính toàn vẹn dữ liệu. Dữ liệu sẽ được lưu trữ trong một hoặc nhiều bảng dựa trên thiết kế.
Tên Index nên được đưa ra theo các tiêu chuẩn như IND <tablename> <ColumnName>.
Tables nên có cột chính quan trọng.
Cột bảng nên có thông tin mô tả có sẵn ( trừ các cột kiểm toán như ngày tạo ra, tạo ra bởi, …).
Đối với mỗi cơ sở dữ liệu thêm/ cập nhật hoạt động đăng nhập nên được bổ sung.
Chỉ mục bảng buộc phải được tạo ra.
Kiểm tra, nếu dữ liệu được cam kết cơ sở dữ liệu chỉ khi hoạt động được hoàn thành.
Dữ liệu nên được cuộn lại trong trường hợp giao dịch thất bại.
Tên cơ sở dữ liệu nên được đưa ra theo các loại ứng dụng thử nghiệm: test, UAT, sandbox, live (mặc dù đây không phải là một tiêu chuẩn, nhưng nó là hữu ích để bảo trì cơ sở dữ liệu).
Cơ sở dữ liệu logic tên cần được theo tên cơ sở dữ liệu (hữu ích để bảo trì DB).
Thủ tục lưu trữ không nên được đặt tên với tiền tố “sp_”.
Kiểm tra là giá trị cho các cột kiểm toán bảng (như CreatedDate, createdby, UpdateDate, updatedby, isDeleted, deleteddate, deletedby, …) là thuộc tính đúng.
Kiểm tra xem dữ liệu đầu vào không được cắt ngắn trong khi lưu. Độ dài trường cho thấy người sử dụng trên trang và trong lược đồ cơ sở dữ liệu nên như nhau.
Kiểm tra số trường với mức tối thiểu, tối đa, và giá trị thực.
Kiểm tra số trường có giá trị âm (cho cả chấp nhận và không chấp nhận).
Kiểm tra nếu nút radio và các tùy chọn danh sách thả xuống được lưu trong cơ sở dữ liệu một cách chính xác.
Kiểm tra nếu các trường cơ sở dữ liệu được thiết kế với kiểu dữ liệu chính xác và độ dài dữ liệu.
Kiểm tra tất cả các ràng buộc bảng: Khóa chính, khóa ngoại, … được thực hiện một cách chính xác.
Kiểm tra thủ tục lưu trữ và trigger với dữ liệu đầu vào mẫu.
Trường nhập đầu tiên và dấu spaces nên được cắt ngắn trước khi cam kết dữ liệu vào cơ sở dữ liệu.
Giá trị rỗng không được phép trong cột khóa chính.

Kịch bản thử nghiệm cho hình ảnh tính năng tải lên

(Cũng được áp dụng cho các chức năng upload file khác)

Kiểm tra đường dẫn hình ảnh tải lên.
Kiểm tra tải lên hình ảnh và chức năng thay đổi hình ảnh.
Kiểm tra chức năng tải hình ảnh với các tập tin hình ảnh của các phần mở rộng khác nhau (ví dụ như JPEG, PNG, BMP, …).
Kiểm tra chức năng tải lên hình ảnh với những hình ảnh có không gian hoặc bất kỳ ký tự đặc biệt khác trong tên tập tin.
Kiểm tra tải lên hình ảnh có tên trùng lặp.
Kiểm tra tải lên hình ảnh với kích thước hình ảnh lớn hơn tối đa kích thước cho phép. Thông báo lỗi thích hợp nên được hiển thị.
Kiểm tra chức năng tải hình ảnh với các loại file khác với hình ảnh (ví dụ như txt, doc, pdf, exe,…). Thông báo lỗi thích hợp nên được hiển thị .
Kiểm tra nếu hình ảnh của chiều cao và chiều rộng (nếu đã xác định) quy định được chấp nhận nếu không từ chối.
Tiến trình tải hình ảnh lên sẽ xuất hiện cho hình ảnh kích thước lớn.
Kiểm tra nếu hủy chức năng của nút đang làm việc ở giữa quá trình tải lên.
Kiểm tra xem hộp thoại chọn tập tin cho thấy chỉ những tập tin được liệt kê hỗ trợ.
Kiểm tra chức năng nhiều hình ảnh tải lên.
Kiểm tra chất lượng ảnh sau khi upload. Chất lượng hình ảnh không được thay đổi sau khi tải lên.
Kiểm tra xem người dùng có thể sử dụng / xem các hình ảnh tải lên.

Kịch bản thử nghiệm cho việc gửi email

(Không bao gồm trường hợp thử nghiệm để tạo hoặc xác nhận email ).
(Hãy chắc chắn để sử dụng địa chỉ email giả trước khi thực hiện các bài kiểm tra email liên quan).

Gửi email mẫu nên sử dụng CSS tiêu chuẩn cho tất cả các email .
Địa chỉ Email phải được xác nhận trước khi gửi email.
Ký tự đặc biệt trong trường email nên được xử lý đúng cách.
Ký tự ngôn ngữ cụ thể (ví dụ như ký tự ngôn ngữ Nga, Trung, Đức) phải được xử lý đúng cách trong trường email.
Tiêu đề email không nên để trống.
Trường placehoder được sử dụng trong mẫu email phải thay thế bằng giá trị thực tế ví dụ như {FirstName} {Lastname} nên được thay thế với các cá thể đầu tiên và cuối cùng tên đúng cho tất cả người nhận.
Nếu báo cáo với các giá trị động mới có trong nội dung email, dữ liệu báo cáo phải được tính toán một cách chính xác.
Email tên người gửi không nên được trống.
Email nên được kiểm tra trong các khách hàng email khác như Outlook, Gmail, Hotmail, Yahoo! Mail, …
Kiểm tra chức năng gửi email sử dụng TO, CC và BCC.
Kiểm tra văn bản email thô.
Kiểm tra HTML định dạng email.
13 . Kiểm tra tiêu đề email và footer cho logo của công ty, chính sách bảo mật và các liên kết khác.
Kiểm tra email với file đính kèm.
Kiểm tra chức năng gửi email tới đơn, đa hoặc phân phối người nhận danh sách.
Kiểm tra nếu trả lời vào địa chỉ email là chính xác.
Kiểm tra gửi khối lượng lớn các email.

Kịch bản thử nghiệm cho chức năng Excel Export

Tập tin nên được xuất trong hợp phần mở rộng tập tin.
Tên tập tin cho tập tin Excel được xuất nên được theo các tiêu chuẩn, ví dụ như nếu tên tập tin được sử dụng dấu thời gian, nó nên được thay thế đúng vào thời điểm thực tế tại thời điểm xuất các tập tin
Kiểm tra định dạng ngày nếu tập tin Excel xuất chứa các cột ngày.
Kiểm tra số định dạng cho giá trị số hoặc tiền tệ. Định dạng nên được giống như hiển thị trên trang.
Tệp tin xuất nên có cột với tên cột thích hợp.
Mặc định trang phân loại phải được tiến hành trong tập tin xuất như vậy.
Dữ liệu tập tin Excel nên được định dạng đúng với tiêu đề và văn bản footer, ngày, số trang, … giá trị cho tất cả các trang.
Kiểm tra xem dữ liệu hiển thị trên trang và tập tin Excel xuất là như nhau.
Chức năng xuất khi pagination được kích hoạt.
Kiểm tra nếu nút xuất là hiển thị biểu tượng thích hợp theo loại tập tin xuất biểu tượng như file Excel là xls.
Kiểm tra chức năng xuất cho các tập tin có kích thước rất lớn.
Kiểm tra chức năng xuất cho các trang có chứa ký tự đặc biệt. Kiểm tra xem các ký tự đặc biệt được xuất đúng trong tập tin Excel.

Hiệu suất kịch bản thử nghiệm

Kiểm tra thời gian tải trang nằm trong phạm vi chấp nhận được.
Kiểm tra tải trang trên các kết nối chậm.
Kiểm tra thời gian phản ứng đối với bất kỳ hành động dưới ánh sáng, bình thường, trung bình và điều kiện tải nặng.
Kiểm tra thực hiện các thủ tục cơ sở dữ liệu được lưu trữ và gây nên.
Kiểm tra thời gian thực hiện truy vấn cơ sở dữ liệu.
Kiểm tra tải trọng của ứng dụng.
Kiểm tra thử nghiệm stress của ứng dụng.
Kiểm tra CPU và bộ nhớ sử dụng trong điều kiện tải cao điểm.

An ninh kiểm tra kịch bản thử nghiệm

Kiểm tra các cuộc tấn công SQL injection.
Trang an toàn nên sử dụng giao thức HTTPS.
Page crash không nên tiết lộ ứng dụng hoặc thông tin máy chủ. Trang lỗi sẽ được hiển thị cho điều này.
Thoát ký tự đặc biệt trong đầu vào.
Thông báo lỗi không nên tiết lộ bất kỳ thông tin nhạy cảm.
Tất cả các thông tin cần được chuyển qua một kênh được mã hóa .
An ninh kiểm tra mật khẩu và thực thi chính sách mật khẩu.
Kiểm tra chức năng đăng xuất ứng dụng.
Kiểm tra cho Brute Force Attacks.
Thông tin cookie sẽ được lưu trữ trong chỉ định dạng mã hóa.
Kiểm tra thời gian phiên cookie và kết thúc phiên sau khi thời gian chờ hoặc logout.
Phiên tokens nên được truyền qua kênh bảo đảm.
Mật khẩu không nên được lưu trữ trong cookie.
Kiểm tra cho Denial of Service attacks.
Kiểm tra bộ nhớ rò rỉ.
Kiểm tra ứng dụng truy cập trái phép bằng cách thao tác các giá trị biến trong thanh địa chỉ trình duyệt.
Kiểm tra phần mở rộng tập tin bàn giao để các file exe không được tải lên và thực hiện trên máy chủ.
Các trường nhạy cảm như mật khẩu và thông tin thẻ tín dụng không nên có tự động hoàn toàn kích hoạt.
Tập tin chức năng tải lên nên sử dụng hạn chế loại tập tin và cũng chống virus để quét các tập tin được tải lên.
Kiểm tra xem danh sách thư mục bị cấm.
Mật khẩu và các trường nhạy cảm khác nên được đeo mặt nạ trong khi gõ.
Kiểm tra xem chức năng quên mật khẩu được đảm bảo với các tính năng như tạm thời mật khẩu hết hạn sau giờ quy định và câu hỏi bảo mật được yêu cầu trước khi thay đổi hoặc yêu cầu mật khẩu mới.
Xác chức năng CAPTCHA.
Kiểm tra xem các sự kiện quan trọng được ghi lại trong các file bản ghi.
Kiểm tra nếu truy cập đặc quyền được thực hiện một cách chính xác.

Bài viết này cố gắng để đảm bảo tất cả các kịch bản thử nghiệm tiêu chuẩn cho các chức năng ứng dụng web và máy tính để bàn. Nhưng đây không phải là một danh sách kiểm tra đầy đủ. Với các dự án khác nhau có danh sách kiểm tra thử nghiệm của riêng mình dựa trên kinh nghiệm của tester.

Via Techtalk.vn