Report Bug trong Tester (Kiểm thử phần mềm)

02:12:45 - 03/07/2018 - admin

Trong Tester có hai loại test report chính là: Bug report và Test report. Hôm nay chúng ta sẽ đi tìm hiểu chi tiết hơn về Bug report nhé!

Bug report là gì

Nếu lỗi xảy ra (mà chắc chắn sẽ có), người tìm lỗi, sẽ phải báo cáo (tài liệu & gửi) lỗi cho những người chịu trách nhiệm sửa lỗi hoặc lỗi đó. Theo Yegor – một chuyên gia kiểm thử chia sẻ: “Chúng ta nên giải thích chính xác sản phẩm bị hỏng như thế nào” . Ông cho rằng một Bug report nên làm theo công thức đơn giản này.

Điều này nghe có vẻ dễ dàng, phải không? Tuy nhiên trong thực tế một Bug report cần xem xét những tài liệu liên quan một cách rõ ràng.

Hãy tưởng tượng bạn gặp lỗi và muốn gửi báo cáo lỗi. Bạn sẽ bao gồm thông tin gì? Tôi đoán mọi người sẽ trả lời khác nhau.

Trong quá khứ, báo cáo lỗi là các biểu mẫu dài bao gồm các trường và yêu cầu dữ liệu khác nhau. Ưu tiên của lỗi là gì? Mô tả sự cố là gì? Các thành phần là gì? Bạn đang sử dụng phiên bản trình duyệt nào? Và, vân vân…

Tại sao bug report là cần thiết?

Nếu báo cáo lỗi của bạn có hiệu quả, thì cơ hội của nó để được cố định cao hơn. Vì vậy, sửa lỗi phụ thuộc vào mức độ hiệu quả của báo cáo. Báo cáo một lỗi là không có gì ngoài một kỹ năng và bạn cần học tập tích lũy kinh nghiệm để đạt được kỹ năng này.
“Điểm viết báo cáo vấn đề (báo cáo lỗi) là để sửa lỗi” – Theo Cem Kaner. Nếu người kiểm tra không báo cáo lỗi chính xác, người lập trình sẽ rất có thể từ chối lỗi này nói rằng nó không thể sản xuất được.

Như thế nào là một bug report tốt?

Có số Bug được chỉ định rõ ràng: Luôn gán một số duy nhất cho mỗi báo cáo lỗi. Điều này, đến lượt nó, sẽ giúp bạn xác định hồ sơ lỗi. Nếu bạn đang sử dụng bất kỳ công cụ báo cáo lỗi tự động nào thì số duy nhất này sẽ được tạo tự động mỗi khi bạn báo cáo lỗi.
Lưu ý số và mô tả ngắn gọn về từng lỗi mà bạn đã báo cáo.
Có thể tái sản xuất: Nếu lỗi của bạn không thể sao chép được, thì nó sẽ không bao giờ được sửa. Bạn nên đề cập rõ ràng các bước để tạo lại lỗi. Đừng giả sử hoặc bỏ qua bất kỳ bước tái tạo nào. Một lỗi được mô tả Từng bước dễ tái tạo và sửa chữa.
Cụ thể: Hãy cố gắng tóm tắt vấn đề bằng các từ tối thiểu theo cách hiệu quả. Không kết hợp nhiều vấn đề ngay cả khi chúng có vẻ tương tự nhau. Viết các báo cáo khác nhau cho từng vấn đề.
Bug report là một khía cạnh quan trọng của kiểm thử phần mềm. Một báo cáo lỗi hiệu quả là báo cáo có liên kết với nhóm phát triển và tránh nhầm lẫn hoặc hiểu sai.
Bug report tốt phải rõ ràng và súc tích mà không có bất kỳ điểm chính nào bị thiếu. Bất kỳ sự thiếu rõ ràng nào cũng dẫn đến sự hiểu lầm và làm chậm quá trình phát triển. Lỗi viết và báo cáo là một trong những khu vực quan trọng nhất nhưng bị bỏ quên trong vòng đời thử nghiệm.
Điểm quan trọng nhất mà một người kiểm tra nên lưu ý là không sử dụng bất cứ một ký hiệu đặc biệt nào trong báo cáo. Điều này phá vỡ tính chuyên nghiệp và dễ gây nhầm lẫn.
Trước khi báo cáo, điều quan trọng không kém là kiểm tra xem liệu lỗi đó có được báo cáo hay không.
Một lỗi trùng lặp gây khó khăn trong chu kỳ kiểm tra. Kiểm tra toàn bộ danh sách các lỗi đã biết. Đôi khi, các nhà phát triển có thể đã biết vấn đề và bỏ qua cho một bản phát hành trong tương lai. Các công cụ như Bugzilla tự động tìm kiếm các lỗi trùng lặp cũng có thể được sử dụng. Tuy nhiên, tốt nhất là tìm kiếm thủ công bất kỳ lỗi trùng lặp nào.
Hãy nhớ rằng mục tiêu của việc viết bug report là để cho phép nhà phát triển trực quan hóa vấn đề.
Ngoài ra, hãy nhớ rằng một bug report sẽ được bảo tồn để sử dụng trong tương lai và cần được viết tốt với các thông tin cần thiết. Không sử dụng các câu lệnh khó hiểu làm lãng phí thời gian của người đánh giá.
Báo cáo từng lỗi dưới dạng vấn đề riêng biệt. Trong trường hợp có nhiều vấn đề trong một báo cáo lỗi, bạn không thể đóng nó trừ khi tất cả các vấn đề được giải quyết.
Do đó tốt nhất là chia các vấn đề thành các lỗi riêng biệt . Điều này đảm bảo rằng mỗi lỗi có thể được xử lý riêng. Một báo cáo lỗi được viết tốt sẽ giúp một nhà phát triển tạo lại lỗi tại nhà ga của họ. Điều này giúp họ chẩn đoán vấn đề là tốt.

Format của một bug report tốt.

Sử dụng mẫu báo cáo lỗi đơn giản sau:

Đây là một định dạng báo cáo lỗi đơn giản. Nó có thể khác nhau tùy thuộc vào công cụ báo cáo lỗi mà bạn đang sử dụng. Nếu bạn đang viết một báo cáo lỗi theo cách thủ công thì một số trường cần được đề cập cụ thể như số lỗi, cần được gán thủ công.

PV: Tên và địa chỉ email của bạn.
Sản phẩm: Trong đó sản phẩm bạn tìm thấy lỗi này.
Phiên bản: Phiên bản sản phẩm nếu có.
Thành phần: Đây là các mô-đun phụ chính của sản phẩm.
Nền tảng: Đề cập đến nền tảng phần cứng nơi bạn tìm thấy lỗi này. Các nền tảng khác nhau như ‘PC’, ‘MAC’, ‘HP’, ‘Sun’, v.v.
Hệ điều hành: Đề cập đến tất cả các hệ điều hành mà bạn đã tìm thấy lỗi. Các hệ điều hành như Windows, Linux, Unix, SunOS, Mac OS. Đề cập đến các phiên bản hệ điều hành khác nhau cũng như Windows NT, Windows 2000, Windows XP, v.v..
Ưu tiên: Khi nào một lỗi nên được sửa? Ưu tiên thường được thiết lập từ P1 đến P5. P1 là “sửa lỗi có mức độ ưu tiên cao nhất” và P5 là “Khắc phục khi thời gian cho phép”.
Mức độ nghiêm trọng: Điều này mô tả tác động của lỗi.
Các loại mức độ nghiêm trọng

Trình chặn: Không thể thực hiện thêm công việc kiểm tra nào.
Quan trọng: Sự cố ứng dụng, Mất dữ liệu.
Chuyên ngành: Thiếu chức năng.
Nhỏ: Mất chức năng nhỏ.
Tầm thường: Một số cải tiến giao diện người dùng.
Tăng cường: Yêu cầu một tính năng mới hoặc một số tính năng nâng cao trong tính năng hiện có.

Trạng thái: Khi bạn đang đăng nhập lỗi vào bất kỳ hệ thống theo dõi lỗi nào thì theo mặc định, trạng thái lỗi sẽ là ‘Mới’. Sau đó, lỗi đi qua các giai đoạn khác nhau như Cố định, Xác minh, Mở lại, Sẽ không khắc phục được v.v.
Giao cho: Nếu bạn biết nhà phát triển nào chịu trách nhiệm về mô-đun cụ thể trong đó lỗi xảy ra, thì bạn có thể chỉ định địa chỉ email của nhà phát triển đó. Người khác giữ nó trống vì điều này sẽ gán lỗi cho chủ sở hữu mô-đun nếu không phải Người quản lý sẽ gán lỗi cho nhà phát triển. Có thể thêm địa chỉ email của người quản lý vào danh sách CC.
URL: URL trang mà trên đó lỗi xảy ra.
Tóm lược: Bản tóm tắt ngắn gọn về lỗi này chủ yếu là từ 60 từ trở xuống. Đảm bảo tóm tắt của bạn phản ánh vấn đề là gì và nó ở đâu.
Sự miêu tả: Mô tả chi tiết lỗi.

Sử dụng các trường sau cho trường mô tả:

Các bước tái tạo: Rõ ràng, đề cập đến các bước để tạo lại lỗi.
Kết quả mong đợi: Cách ứng dụng hoạt động trên các bước nêu trên.
Kết quả thực tế: Kết quả thực tế của việc chạy các bước trên nghĩa là hành vi lỗi.

Đây là những bước quan trọng trong báo cáo lỗi. Bạn cũng có thể thêm “Loại báo cáo” dưới dạng một trường khác sẽ mô tả loại lỗi.

Các loại báo cáo bao gồm:

1) Lỗi mã hóa

2) Lỗi thiết kế

3) Đề xuất mới

4) Vấn đề về tài liệu

5) Sự cố phần cứng