-
1 电子教材
-
2 PPT
缺陷报告是大多数测试人员的主要工作产品。缺陷报告的读者通过这些文档认识测试人员。
报告写得越好，测试人员的声誉越高。程序员通过对测试人员的报告得到关键信息。对重要问题的准确报告会为测试人员带来良好声誉，差的报告会为程序员带来额外（在程序员看来时不必要的)的工作。如果测试人员浪费了程序员太多的时间，程序员就会躲避测试员及其工作。
程序员并不是缺陷报告的唯一读者，项目经理有时也通过阅读缺陷报告了解产品质量。问题描述不清、研究不充分或提出过于追究小问题的建议的报告，都会给测试人员和测试团队带来负面影响。因此，如果下工夫研究并写好报告，所有人都会受益，因此为编写出高质量的缺陷报告，最好牢记以下书写缺陷报告的规则和方法。
一个合格缺陷报告应该包括完整的内容，至少应该包括如图3-2所示的几个方面。
图3-2 合格的缺陷报告应包括的内容
1. 报告发现问题的版本
开发人员需要知道问题出现的版本，才能获取一个相同的版本来进行问题的重现。版本的标识有助于分析和总结问题出现的集中程度，例如，版本1.1出现了大量的缺陷，则需要分析是什么原因导致这个版本出现了大量的问题。
需要注意的是，有些缺陷可能会在不同的版本中出现，例如，某个缺陷在版本1.1中出现了，测试人员录入了缺陷，ID为10，开发人员也进行了修改，经验证关闭了。但是，该缺陷到了版木1.3时又出现了，这时，有些测试人员回过头来把缺陷10的状态改成重新打开（Reopen），这是错误的，因为这个缺陷是在新的版本中出现的，即使是同一种现象，甚至是同一个原因造成的，也不应该Reopen，而是新加一个，因为这代表了一个质量回归问题。这个缺陷确实又出现了，因为这个缺陷造成了损失，测试人员需要重新测试、验证并进行报告，开发人员需要再次修改程序并编译；如果Reopen，则可能造成质量统计时漏算了一个缺陷。
2．报告问题出现的环境
问题出现的环境包括操作系统环境、软件配置环境．有时候还需要包括系统资源的情况，因为有些错误只有在资源不足时才出现。
由于开发环境与测试环境存在差异，往往会导致有些问题只有在测试环境下才能出现。例如，开发环境中使用的某些第三方组件在测试环境没有注册，这时候，测试人员应该把这些差异记录清楚，以便开发人员在重现问题和进入调试之前把环境设置好。
3．报告问题重现的操作步骤
应该描述重现问题所必须执行的最少的一组操作步骤。有些测试人员往往一发现问题就把重现步骤录入下来，并报告缺陷。这些重现步骤可能是非常冗长的一个操作，而实际上可能仅仅是其中的一两个关键步骤的组合才会出现这样的错误。让开发人员重新执行这些多余的步骤其实是在浪费开发人员的宝贵时间，因为调试的周期会因此加长。
注意：
正确的做法是，录入之前再多作几次尝试．尽量把操作步骤减到必须要执行才能重现错误的几个步骤。
应该尽量地简化问题，例如，一个200行的SQL语句执行时出错，可能仅仅是因为其中的某几行语句有问题导致的，如果能把SQL语句简化到3行，而问题依然存在，这样的报告更容易受到开发人员的欢迎。
4．描述预期的行为
要让开发人员知道什么才是正确的，尤其是要从用户的角度来描述程序的行为应该是怎样的。例如，程序应该自动把文档同步到浏览界面。
经常见到一些测试人员描述的缺陷模棱两可，例如，“编辑单据时，列表中不出现日期信息”。这让人一眼看上去弄不清列表中应该出现日期信息还是不应该出现日期信息。尤其对于一些不熟悉需求的开发人员来说，不清楚测试人员是要求这样做，还是指出这样做是错误的。
注意：
明确地说明程序的预期行为才能更好地表达需求。
5. 描述观察到的错误行为
描述问题的现象，例如，“程序抛出异常信息如下……”。
注意：
记住，在描述这些错误行为时要客现地反映事实，不要人为地夸大．
除了上面提到的缺陷的版本、出现的环境、重现步骤、预期行为、错误行为这些必须记录的缺陷信息外，还有一些是需要及时登记，以备将来统计和报告使用的信息。例如，缺陷的严重程度、出现的功能模块、缺陷的类型、发现的日期等信息。
缺陷报告是测试人员辛勤劳动的结晶，是测试人员价值的体现，同时也是与开发人员交流的基础。缺陷报告是否正确、清晰与完整将直接影响开发人员修改缺陷的效率和质量，因此，在报告缺陷时，需要注意以下几个问题。
1. 尽量避免出现错误
测试人员会经常找出开发人员关于界面上的错别字、用词不当、描述不清楚等错误，但是，测试人员在录入缺陷的时候却很容易犯同样的错误，这种情况在测试人员中应该尽量避免发生，正所谓“己所不欲，勿施于人”。
2. 不要把几个缺陷录入到同一个ID下
即使一些缺陷的表面现象类似，或者是一些缺陷同时出现在同一个区域，也应该一个缺陷对应录入一个缺陷。因为这样才能清晰地跟踪所有缺陷的状态，并且有利于缺陷的统计和质量的衡量。
3．添加必要的截图和文件
一些涉及用户界面（User Interface）的软件缺陷可能很难用文字清楚地描述，所谓“一图胜千言”，把错误的界面截取下来，添加到缺陷报告中，可以让开发人员清楚地看到缺陷出现时的情形。最好能在截图中用画笔圈出需要注意的地方，这样能直观地表示缺陷发生在产品界面的什么位置、有什么问题等。
附件中添加截图是现在缺陷报告中最常见的形式，下面为大家详细介绍添加截图的一些规则。
(1）采用图片的格式
测试人员一般采用JPG 、GIF 的图片格式，因为这类文件占用的空间小，打开的速度快。
(2）什么情况下需要附上图片
通常情况下，出现在用户界面，并且影响用户使用或者影响产品美观的软件缺陷，附上图片比较直观，例如：
l）当产品中有一段文字没有显示完全，为了明确标识这段文字的位置，测试人员必须贴上图片。
2）在测试外国语言版本的时候，当发现产品中有一段文字没有翻译，测试人员需要附上图片标识没有翻译的文字。
3）在测试外国语言版本的时候，当发现产品中有一段外国文字显示乱码，测试人员必须附上图片标识那些乱码的文字。
4）产品中的语法错误、标点符号使用不当等软件缺陷，测试人员附上图片告诉开发人员缺陷在什么地方。
5）在产品中运用错误的公司标志和重要的图片没有显示等软件缺陷，也需要附上图片。
注意：
必要的异常信息文件、日志丈件、输入数据文件也可作为附件添加到缺陷报告中，以方便开发人员定位和重现错误。
4. 完成一个缺陷的录入后应进行检查
就像要求程序员在编写完代码后应自己编译并做初步的测试一样，应该要求测试人员在录入完一个缺陷后自己阅读一遍，检查语句是否通顺，表达是否清晰。
软件缺陷的描述是软件缺陷报告中测试人员对问题陈述的一部分，并且是软件缺陷报告的基础部分。同时，软件缺陷的描述也是测试人员就一个软件问题与开发小组交流的最初且最好的机会。
程序员并不是缺陷报告的唯一读者，项目经理有时也通过阅读缺陷报告了解产品质量。一个好的描述需要使用简单、准确、专业的语言来抓住缺陷的本质。否则，它就会使信息含糊不清，可能会误导开发人员，给测试人员和测试团队带来负面影响，因为人们了解测试人员通常是从其撰写的缺陷报告开始。下面来总结一下能编写出高质量缺陷报告的一些有效规则。
1. 单一准确
每个报告只针对一个软件缺陷，在一个报告中报告多个软件缺陷的弊端是常常会导致只有其中一个软件缺陷得到注意和修复。
2. 可以重现
提供这个缺陷的精确步骤，使开发人员容易看懂，复现缺陷并修复缺陷。
3. 完整统一
提供完整、前后统一的软件缺陷的复现步骤和信息，例如，图片信息、Log文件等。
4. 短小简练
通过使用关键词，可以使软件缺陷的标题描述短小简练，同时还能准确解释产生缺陷的现象，如“主页的导航栏在低分辨率下显示不整齐”中“主页”、“导航栏”、“分辨率”等是关键词。
5. 特定条件
许多软件功能在通常情况下没有问题，而是在某种特定条件下会存在缺陷，所以软件缺陷描述不要忽视这些看似细节但又必要的特定条件（如特定的操作系统、浏览器或某种设置等），能够提供帮助开发人员找到原因的线索，如“搜索功能在没有找到结果返回时跳转页面不对。
6. 补充完善
从发现缺陷那一刻起，测试人员的责任就是保证它被正确的报告，并且得到应有的重视．继续监视其修复的全过程。
7. 注意自己的语气
缺陷报告中带有责备或居高临下的语气是百害而无一利的。贬低程序员的技术水平，或许会让测试人员得到一时的痛快，但是由此带来的却是合作中的不愉快。测试本来就是一个需要充分交流和沟通的工作，由此带来的不愉快就会引发对立。所以，在描述一个缺陷的时候要严格遵守一个原则，即对事不对人。特别要注意描述时使用的语气，不要把情绪带到缺陷报告当中去。
遵循软件缺陷有效描述的规则会有以下好处：
l）清晰、准确的软件缺陷描述可以减少软件缺陷从开发人员返回的数量。
2）提高软件缺陷修复的速度，使每一个小组都能够有效地工作。
3）提高测试人员的信任度，可以得到开发人员对清晰的软件缺陷描述有效的响应。
4）加强开发人员、测试人员和管理人员之间的协同工作能力，提高工作效率。
