Bug Report Là Gì

1) Bug report là gì ?

Để phân tích và lý giải được thắc mắc đó, bạn phải hiểu được ý nghĩa sâu sắc của Bug, Bug report và Bug Reporting Software.

Bạn đang xem: Bug report là gì

*

Vậy Bug là gì?

Trích trường đoản cú wikipedia:“A software bug is an error, flaw, failure, or fault in a computer program or system that causes it khổng lồ produce an incorrect or unexpected result or to behave in unintended ways.”

Hay gọn ghẽ lại:"Software Bug là đông đảo sai lầm, hư hóc, lỗi, khuyết thiếu để tạo thành một công dụng sai, hoặc ko lường cho được."

Theo lý thuyết, hoàn toàn có thể coi nó như 1 thứ nào đó không vận động đúng theo thiết kế.

*

Vậy nếu trả sử loại phát sinh kia đó vốn dĩ không còn có vào thiết kế, vậy nó có phải là Bug? Đây đó là điều khiến cho người ta có tầm khoảng trống nhằm diễn giải nó theo khá nhiều cách, và phần nhiều mâu thuẫn giữa dev và tester đều xuất phát từ vấn đề này.

Bug report là gì?

Giả sử 1 bug xuất hiện (tất nhiên là nó đang xuất hiện) người tìm ra Bug phải rất có thể report nó (bằng văn bản và gửi) cho người có tương quan để sửa lỗi đó.

Theo Yegor: Bug report nên giải thích được sản phẩm của người tiêu dùng hỏng hóc và đúng là ở nơi nào.Ông nói thêm rằng Bug report yêu cầu theo một quy cách thức tối giản như sau:"Nó như thế này, nó ĐÚNG RA phải hoạt động như cố kỉnh khác. Fix đi."Nghe tất cả vẻ đơn giản nhỉ, nhưng thực tiễn thì rất nhiều sự lại không diễn ra suôn sẻ như vậy.

Tưởng tượng rằng bạn gặp gỡ phải 1 bug và ước ao send bug report. Bạn sẽ trình bày những tin tức gì? số đông mỗi người đều phải có một câu trả lời của riêng biệt mình, 9 fan 10 ý.

2) tại sao cần một bug report chuẩn?

Nếu bug report hiệu quả, tỉ trọng được fix của chính nó sẽ cao hơn. Câu hỏi fix bug phụ thuộc vào vấn đề bạn report nó có hiệu quả hay không. Nó là một trong nghệ thuật, và bài viết này giải đáp bạn làm sao để đổi thay một nghệ sỹ.“The point of writing problem report(bug report) is to lớn get bugs fixed” – Cem Kaner.

Khi tester report bug không chủ yếu xác, dev có thể reject bug do không thể tái hiện (reprod ) được bug. Điều này ảnh hưởng đến tự tin và chiếc tôi của tester (Và theo như mình thì cực tốt là đừng gồm cái tôi như thế nào hết. Kiểu gượng nhẹ như "Tao report đúng mà", "Tao làm cho lại được mà", "Sao nó reject bug của mình", "Không buộc phải lỗi của mình" ..v..v.. Là rất ăn hại cho bạn dạng thân bạn và đề xuất tránh)

3) Điều gì đưa ra quyết định một bug report tốt?

Bạn sẽ thắc mắc rằng điều gì khiến cho một bug report tốt, cùng điều gì làm nó dở. Và vì sao cái dở lại nhiều hơn thế cái tốt?

Dưới trên đây mình sẽ liệt kê ra một số phát biểu về vụ việc này để tách biệt giữa một bug report tốt, với một bug report tệ:

Bug report xuất sắc chứa đủ tin tức để reprod cùng sửa lỗi.Bug report tệ không đựng đủ thông tin để reprod với sửa lỗi.Bug report tốt là một biện pháp hữu hiệu để liên lạc giữa người report bug và người sửa bug.Bug report tệ thường quá dài, với là phương tiện đi lại thiếu có lợi để liên lạc trong số những người liên quan.Bug report giỏi được sửa nhanh.Bug report tệ không bảo tiếng được fix.Bug report giỏi được gửi mang lại đúng bạn chịu trách nhiệm.Bug report tệ thì chẳng gởi ai, hoặc gửi nhầm người.Bug report giỏi mô tả đúng vật dụng gì đề xuất sửa.Bug report tệ không đựng đủ thông tin chi tiết.Bug report xuất sắc được gửi theo đúng cách.Bug report tệ gởi theo đủ cách, nhưng lại không đúng (qua facebook giỏi mail chẳng hạn)Bug report giỏi tạo đề xuất được tiền đề nhằm phối hợp.Bug report tệ sẽ khiến cho người ta không chịu đựng hợp tác.

Sau khi hiểu xong bạn có thể biết được report của khách hàng tệ hay giỏi rồi. Vậy làm thế nào để viết một bug report tốt?

I) Title rõ ràng

Khi dev gọi bug, thứ đầu tiên đập vào mắt là Bug title. Nó cũng là phần được đọc các nhất, không phải là description. Một bug title tốt phải ngăn nắp và biểu đạt được bug một giải pháp tối giản. Ví dụ:Title hèn : Notes don"t display correctlyKhông bỏ ra tiết. Trong khoảng 1 tháng sẽ không còn thể phân biệt được vấn đề tới từ đâuTitle giỏi : Text is truncated for 32nd and 64th notesSo với title trước, title này cải thiện rất nhiều. Nó chỉ ra rằng được vấn đề chạm mặt phải cùng nơi xuất hiện thêm của bug.

II) có thể Reprod:

Nếu bug của doanh nghiệp không thể reprod, nó sẽ không khi nào được fix. Ghi rõ từng step. Không nhảy đầm cóc, không tiết kiệm chi phí dòng. Nếu khách hàng hình dung là bản thân viết để cho một thằng bé dại 5 tuổi cũng có thể tìm được bug, tức là bạn đã từng đi đúng hướng.

III) Be Specific:

Không viết luận vào description. Ngắn gọn với vào trọng tâm. Cố gắng viết không nhiều chữ nhất rất có thể nhưng vẫn vừa đủ ý. Khi gồm 2 sự việc trong cùng 1 step như là nhau, hãy bóc ra 2 bug report. Khi gồm cùng 1 sự việc trong 2 step khác nhau, hãy bóc ra 2 bug report.

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

Đây là 1 trong những format dễ dàng của bug report. Tuỳ ở trong vào tool ai đang dùng. Nếu bạn viết bug thủ công bằng tay (excel...) thì có một số trường cần đon đả đặc biệt, ví dụ như BUG ID hoặc priority.

Reporter: tên và thư điện tử của bạnProduct: tên của Application Under thử nghiệm (AUT)Version: Version đã test.**Component:**Module to của app.Platform: mô tả căn nguyên bạn dùng làm chạy sản phẩm. Vd: Android, PC ..v...vOperating system: biểu lộ hệ điều hành và quản lý bạn dùng để test sản phẩm. Vd: Windows 10, apk 4.4.2....v..v.

Xem thêm: Quản Trị Mạng Máy Tính - Học Quản Trị Mạng Ra Làm Gì

Priority: Bug yêu cầu được fix khi nào? thường thì sẽ được set từ P.1 cho tới P.5 trong đó P.1 là "Fix càng sớm càng tốt" cùng P.5 là "Cho vào backlog"Severity: Types of Severity:Blocker: ko thể liên tiếp test.Critical: tiện ích crash, mất data.Major: Lỗi tính năng nghiêm trọng.Minor: Lỗi tính năng nhỏ.Trivial: Lỗi UI, lỗi alignment..v..v.Enhancement: Request để thêm feature new hoặc nâng cao feature có sẵn.Status: Khi new được log in hệ thống, bug đã ở tâm trạng new với tuỳ ngôi trường hợp mà thành Verified, Fixed, Won"t Fix, Reopen..v..v. điều này sẽ nói rõ rộng vào bài khác.Assign To: fan nhận trọng trách fix bug của bạn. Ở nhiều cty trường này được để trống để PM từ bỏ assign người.URL: URL xẩy ra bug.Summary: giới hạn trong 60 từ. Biểu thị bug chỗ nào và bug xẩy ra thế nào.Description: description của bug. Ở phía trên ta có thể dùng giải pháp viết sau.Reproduce steps: biểu đạt rõ ràng công việc để xẩy ra bug. Tuyệt vời nhất không trả dụ, không quăng quật step. Cứ nghĩ về là bạn đang viết cho 1 đứa bé dại 5 tuổi đọc và tìm bug.Expected result: họ trông đợi mẫu gì.Actual result: Và họ nhận được gì (I.E đó là bug)

Trên đấy là những step quan trọng cần phải có trong 1 bug report. Bạn có thể thêm ngôi trường Bug Type để biểu lộ dạng bug report.

Thường là:

Lỗi CodingLỗi DesignNew suggestionDocumentation issueHardware problem5) Kết luận

Bug report là một phần rất đặc biệt quan trọng và luôn luôn phải có trong khi thực hiện testing. Một Bug report được viết rõ ràng và rành mạch, sẽ luôn luôn gây tuyệt hảo và hiệu ứng xuất sắc hơn so với một bug report sơ xài với cẩu thả. Làm cho những người fix bug kia và toàn bộ cơ thể confirm lại bug đó không có cảm giác khó chịu đựng khi bắt buộc đọc một bug report sơ xài. Hy vọng nội dung bài viết đã cung ứng được một trong những những định nghĩa cơ bản và một vài nhắc nhở cho chúng ta để các chúng ta cũng có thể viết rất nhiều bug reports tốt.