【软体测试】【好文共享】撰写Bug的艺术

今天读到一篇关于撰写Bug的艺术，来记录一下

原文网址：The Art of Bug Reporting: How to Market and Get Your Bugs Fixed?

如何写一个好Bug？如何描述一个Bug？这是一个老生常谈也是一个很重要的议题，

因为bug 描述的品质，关系到问题是不是真正有被看到，真正的问题有被修复的关键，但往往也很容易被测试人员给忘记，

因此看到这篇，真有点心有戚戚焉，来记录一下我看到的部份。

【以下部分有部分为文章内文，及我个人的一些经验，这不是圣经，每个单位有他的游戏规则，看看就好，就当是个参考，但建议还是看原文比较好 ...】

“The best tester isn’t the one who finds the most bugs or who embarrasses most programmers. The best tester is the one who gets most bugs fixed.”
一个好的测试人员不适发现最多的bug或照出谁是不好的程式设计师，最好的测试员是找到最多可被修复的Bug
Bug report上的问题都应当被修复吗?答案是"否"
Bug是否要被修复，需视情况而定，RD并非要照单全收，对于使用者有直接且重大的影响当然要修复，至于非直接重要的问题，可在进行讨论进行筛选后再修复

针对Bug report，有个很重要的观念就是 ==> 看到 Bug要针对问题深入探索，尽可能找到bug发生的真正原因

大部分的测试人员，找到bug会异常的兴奋，或是有时为了时效性，就很开心的report了bug，却忽略了针对Bug进行更深入的探索，反复的测试，针对bug找出尽可能地找出真正的root cause，

在经过反复的测试，我们可以找出一些资讯，附加到Bug当中，将对于修复bug将有所帮助

Bug Report应包含下列讯息：

Bug Summary (Bug的描述)
Steps to reproduce (重现的步骤)
Attachments (Snapshot, Log files etc.,) (附档：萤幕撷取图片、Log纪录...等)
Bug reproducibility(bug 可被重现的机率 ex:100% or 4/5)
Bug Severity(Bug的严重程度)
Software Version, Environment Information (软体版本资讯、测试环境..等)
Other information based on organizational requirements.(其他相关的资讯...例如：发生时的现场条件)

以下针对几个比较重要的讯息进行说明：

#1. Bug Summary:

应简洁明了

Bug Summary内容可简短扼要的点出问题

应包含When (哪个时间或状态)/ what(发生甚么问题) /how(如何发生)

应尽量避免使用一些含糊不清的字眼(ex:“not working properly”, “not working as expected” etc.)

#2. Steps to Reproduce and Attachments

尽量找出重复可重现的步骤，一个无法重现的bug其价值并不是那么的重要

在某些bug当中，会有些关键性的步骤，因此在描述步骤时，可附加说明(ex:Key point)，提醒RD

针对问题描述，可加上预期结果(expect result)与实际结果(current result)以供比对

对于较精简且不是很重要的步骤，若非必要步骤，可简单描述即可

无法使用文字描述，可用附档辅助 rd厘清问题

若有系统的log或是其他纪录资讯，可一并附上，以助于厘清问题

#3. Bug Reproducibility

一个问题的大或小，可从是否能被重现来参考

可以被重现的问题，其priority永远比其他只能被重现一次，或是偶而才重现的问题还要高

找出正确的重现步骤，是一个测试工程师的职责

#4. Bug Severity

严重程度是一个问题的影响范围的表示，影响程度越大，其serverity越高

severity的定义如下：

Severity 1 – Show Stopper – for bugs that are catastrophic, without being fixed the user will not be able to continue using the software and there is no possible work around(非常严重会造成功能停摆，造成该功能无法继续使用，且没有其他解决方法；例如：所有储存功能皆无效save键就当机了，导致于文件文法储存)

Severity 2 – High – for bugs similar to Severity 1, but there is a work around(会造成功能停摆，但是有其发方法可解决；例如：按下save键不动作，但是使用CTRL+S可使用)

Severity 3 – Medium (中等)

Severity 4 – Low

Severity 5 – Trivial.

身为一个测试人员，就是在重现使用者的状况，因此在测试时应站在客户的立场，模拟客户的行为与需求进行测试。

应尽量键少这几种BUG的状况：“Cannot Reproduce” or “Need more Info” or “Not a Valid Bug” or changes in severity as low as possible,

以下是我个人的碎碎念时间：