如何写好缺陷报告？

　　一切不满足用户需求的都是缺陷。

　　下面我们对缺陷的概念在详细的介绍一下。

　　佩腾在《软件测试》一书中说符合下面5个规则的就可以成为软件缺陷：

　　1、软件未达到产品说明书标明的功能。

　　2、软件出现了产品说明书中指明不会出现的错误。

　　3、软件功能超出了产品说明书指明的范围。

　　4、软件未达到产品说明书中虽未指出但应达到的目标。

　　5、软件测试员认为软件难以理解、不易使用、运行速度缓慢，或最终用户认为不好。

　　关于这 5点我们举例来说明一下。第一点，比如说我们开发一个记事本的软件，说明书中明确说了可以输入文字，结果开发的软件不具备输入文本的功能，肯定就是一个 defect了。第二点，说明书中明确说了在记事本软件中输入“联通”可以正确的保存并打开浏览，结果我们的记事本软件打开保存了的输入“联通”的文件出 现了乱码，这也是一个defect了。第三点，比如说我们的说明书中没有定义记事本会自动的对关键字高亮显示（这个主要是针对编程语言），结果我们的记事本程序自动对关键字高亮显示了，这也是defect，尽管这样对用户使用会更好，但是他超出了产品说明书中指明的功能范围，所以还是defect。第四点 不太好说，所以就不用记事本举例了，原谅我，呵呵。比如在我国开发财务管理软件必须要符合财政部的规定，尽管说明书中一般不会指出，但是软件必须要符合这个规定，不然是不能发行使用的啊！第五点就好理解，因为测试员是第一个使用软件的，必须要从客户的角度来对待，尽管这里会有主观感觉，但还是要尽量客观 （就是多参考一些标准，例如定义界面的，检察易用性的标准），比如在Windows下的程序对话框中“是”按钮都是在左边，“否”按钮在右边，如果发现在 我们的记事本程序中，提示是否保存文件的对话框里“是”按钮在右边了，这就是一个defect了，因为它不符合Windows下用户的使用习惯。

　　知道了什么是缺陷，我们就再来看看怎么去描述一个缺陷吧，看看缺陷都有哪些属性。

　　二、缺陷的属性

　　(1)、缺陷标识：就是缺陷的编号了，每个缺陷有一个唯一的编号。

　　(2)、缺陷类型：这是一个功能性还是性能的bug，是文档的还是界面的bug，还是本地化的bug。

　　(3)、缺陷的严重程度：

　　a、致命Fatal：系统崩溃、数据丢失、数据毁坏。无法进行后续的测试。

　　b、严重Critical：操作性错误、功能遗漏、影响用户使用。

　　c、一般Major：UI方面的，一些小的错误，不影响使用。

　　d、较小Minor：建议性的问题，可以不做修改。

　　(4)、缺陷的修复优先级：

　　a、立即修复：影响后续测试的问题。

　　b、高优先级：在产品发布前必须修复。

　　c、中优先级：严重程度一般的缺陷。

　　d、低优先级：有时间就要修复的。

　　(5)、缺陷的状态

　　a、open：新提交的bug

　　b、fixed：已修复等待测试人员验证的bug

　　c、reopen：测试人员验证发现没有修复的bug

　　d、closed：测试人员验证已修复的bug

　　(6)、缺陷的频率---是指缺陷出现的概率

　　a、总是：可以100%重现

　　b、通常：出现的概率为80%--90%

　　c、有时：出现的概率为30%--50%

　　d、较少：出现频率比较低，2%左右

　　这里要注意一下缺陷的严重程度和优先级并不是一回事，严重程度说明的是缺陷产生的后果，优先级是修复的优先级。通常严重程度和优先级是一一对应的，但不绝对是。缺陷的严重程度、频率、优先级、状态这些并不是只有这几种情况，每个公司都有自己的定义的。

　　三、bug处理的流程：

　　这个是最简单的方式了。

　　下面就是最重要的，我们发现了缺陷就要提交缺陷报告给开发人员，那么如何去写缺陷报告呢？

　　四、缺陷报告

　　下面的是一个缺陷报告的基本结构：

　　A、缺陷编号

　　B、OS、version、platform、projectname

　　C、缺陷类型

　　D、缺陷的严重程度

　　E、缺陷的频率

　　F、缺陷的优先级

　　H、缺陷的状态

　　I、Summary

　　J、ReproduceSteps

　　K、ActualResult

　　L、ExpectedResult

　　M、AdditionalInformation

　　摘要要简明扼要，尽量用执行什么动作发生了什么来描述，比如It pops up an error dialog after clicking the "OK" button on XXX screen.

　　重现步骤要完整简明，不要包含不必要的信息，每步尽量以动词开头，例如Click XXX button to go to XXX screen.

　　实际结果要如实的描述发生了什么，不要包含自己的猜想。如：The error dialog pops up about "……"。

　　期望结果尽量要有依据，比如是根据说明书啊，一般用should，例如：According to the spec page

　　120, It should ……。

　　注释可以加上不方便出现在重现步骤中的内容，也可以是图片，log等信息。

　　写缺陷的一些忠告：

　　1、要多读优秀的缺陷报告，学习他们是怎么写的。

　　2、每个缺陷报告尽量的截取图片和log，来帮助开发人员快速定位问题。

　　3、对重现步骤自己要多执行几遍，确保开发人员可以再现缺陷。

　　4、缺陷报告要客观得体，不要包含自己的主观情绪

　　最后和大家分享一下缺陷报告的5C准则：

　　–Correct（准确）

　　–Clear（清晰）

　　–Concise（简洁）

　　–Complete（完整）

　　–Consistent（一致）