Explore

Test report nên bao gồm những thông tin gì?

Mặc dù các tài liệu test report thường được liên kết với Waterfall, nhưng chúng cũng có thể đóng góp vào quá trình phát triển Agile.

trung tâm testerpro

Test report chứa tất cả các thông tin chi tiết về môi trường nơi đã được kiểm thử, ai đã thực hiện, khi nào được thực hiện và nó đã được kiểm thử như thế nào. Tài liệu này đóng vai trò là nhật ký ghi lại chính xác các thông tin cần thiết của quá trình kiểm thử. Điều này cho phép các nhóm đưa ra quyết định đúng đắn về những cải tiến quy trình nào có thể được thực hiện có các kiểm thử trong tương lai. Hãy cùng

trung tâm tester Hà Nội - TesterproVN⁠

xem xét các thành phần cơ bản của cách viết test case và tại sao tài liệu này có thể hữu ích trong phát triển phần mềm Agile.

Có gì trong Test report?

Mục tiêu kiểm thử

Mục tiêu là loại kiểm thử mà nhóm và những tester đã thực hiện và tại sao. Ví dụ nếu test report bao gồm kiểm thử chức năng, hồi quy... thì người viết báo cáo sẽ cần mô tả cho từng loại kiểm thử trên

Trong hầu hết các trường hợp, kiểm thử hồi quy là mục đích chính của việc thực hiện kiểm thử phần mềm. Mục tiêu của kiểm thử hồi quy có thể khác nhau, nhưng một nhóm thường thực hiện phương pháp này để tìm kiếm các lỗi sau khi nhà phát triển thêm code của tính năng vào cơ sở code hiện có

Test case, phạm vi thực hiện và chi tiết

Cụ thể bao gồm loại kiểm thử nào đã được thực hiện, nơi được lưu trữ và khi nó được thực hiện. Người viết cũng có thể thêm tên của chuyên gia QA đã thực hiện, nhưng đó không phải là một yêu cầu cụ thể. Thay vào đó, điều quan trọng hơn là bao gồm cách thức/cái gì/ tại sao và kết quả kiểm thử thực tế.

Người viết nên trình bày có bao nhiêu bài kiêm thử đã được thực hiện, vượt qua, thất bại hoặc bỏ qua. Các bài kiểm thử bị bỏ qua đại diện cho các bài mà một nhóm đã lên kế hoạch nhưng bị bỏ qua do hạn chế về thời gian hoặc bị chặn do báo cáo lỗi. Trong những trường hợp như thế này, các nhóm cũng nên bao gồm số lượng code mà họ đã kiểm thử. Một nhóm có thể sử dụng các ứng dụng và công cụ quản lý kiểm thử để chỉ định lượng code mà các chuyên gia QA của họ đã kiểm tra. Nếu những công cụ như vậy không có sẵn, hãy liên hệ với nhóm phát triển để ước tính phạm vi kiểm thử

Số lượng lỗi

Một khía cạnh quan trọng khác là ghi lại những lỗi đã được tìm thấy. Phần này rất quan trọng đối với các phân tích hậu kiểm thử, có nghĩa là người viết

test report⁠

không nên chỉ liệt kê các số nhận dạng lỗi. Chúng nên bao gồm một mô tả ngắn gọn về từng lỗi để giúp tiết kiệm thời gian sau đó. Tuy nhiên người viết không cần thiết phải liệt kê mọi lỗi được tìm thấy. Có thể cân nhắc đợi cho đến khi nhóm quản lý sản phẩm xác nhận sự tồn tại của một lỗi trước khi đưa vào báo cáo

Tester cần xem xét cẩn thận danh sách lỗi để xác minh rằng họ không báo cáo lại các lõi đã có. Dự liệu trong phần này nên tập trung vào các lỗi được tìm thấy trong bản phát hành đã nêu được sắp xếp theo mức độ ưu tiên

Nền tảng, môi trường kiểm thử

Phần cấu hình và môi trường kiểm thử rất phức tạp. Thông tin chi tiết là quan trọng, nhưng người viết

test report⁠

cũng cần xem xét tính bảo mật và tuân thủ khi họ chia sẻ thông tin liên quan đến code của ứng dụng. Người viết nên cho rằng đối tượng mục tiêu nói chung hiểu hệ thống kiểm thử, đây không phải là nơi tiết lộ thông tin chi tiết về máy chủ và kho lưu trữ code của ứng dụng

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.