本文假设项目团队使用基于数据库的缺陷管理系统来跟踪缺陷报告。团队成员可以向系统提交新的缺陷报告，修改和解决已有缺陷报告，查询符合一定条件的缺陷报告。在此过程中，缺陷管理系统提供审计跟踪功能，记录对缺陷报告所做的一切修改。

1　为每一个缺陷单独提交一份缺陷报告，小缺陷也是如此

为了提供完整的信息，测试人员应该报告他发现的所有缺陷。为了让每一个缺陷都得到审计跟踪，测试人员应该为其提供独立的缺陷报告。有时，测试人员会在一份报告中提交了几个缺陷。这可能会导致一些问题。缺陷报告的数目会少于缺陷的数目，这使缺陷统计不能获得准确的信息。
缺陷报告中的缺陷可能有不同的根源，需要不同的解决方案，需要不同的程序员（甚至不同的项目团队）来解决。一份报告不能很好地跟踪所有缺陷的修复。一份缺陷报告只有一个优先级和严重性，但是它所提交的缺陷可能拥有不同的优先级和严重性。这使得缺陷报告不能传递准确的优先级和严重性。因为不能很好地标识与跟踪每一个缺陷，某个缺陷可能被程序员和测试人员所忽略，以致于没有被修复。为了避免这些问题，测试人员需要将此类缺陷报告拆分成多个缺陷报告，让每一个缺陷得到独立的报告。
然而，缺陷管理系统的关键问题是行政性的，而不是技术性的。在某些项目环境中，测试人员提交缺陷报告的动力会被压抑。一个典型的情况是项目管理者用缺陷报告的数量来评价程序员的绩效，这势必导致程序员对缺陷报告很敏感。他也许会对测试人员说：“你如果发现缺陷，请不要提交缺陷报告，而是发邮件通知我。”这让测试人员处于两难的境地：一方面，他知道向项目团队提供高质量的信息是测试人员的基本责任，隐藏信息将伤害测试人员的“信誉”；另一方面，他不想破坏与开发伙伴的关系，这是高效测试的基本条件之一。
坦率地说，测试人员没有能力和资源去解决“不良管理”所带来的问题，这是项目经理或更高层经理的职责。面对此类情况，测试人员还是应该正常报告每一个缺陷，因为隐藏缺陷将伤害项目团队对测试人员的信赖，而“可信赖”是一个信息提供者的工作基础。同时，他需要向“受影响”的程序员解释他的做法，并强调缺陷报告从来都是对事不对人。更积极的行动是，他应该当面向他的领导（通常是测试经理或项目经理）解释当前的管理流程给测试工作带来了困难，并将对项目产生不好的影响。如果能联合其他测试同事一起提出建议，领导者会更容易看到问题之所在。

2　仔细编写缺陷报告的标题

在阅读缺陷报告时，读者总是先读到标题。例如，缺陷评审小组会查询所有活跃的缺陷，查询结果是一个缺陷标题的列表，缺陷标题为进一步的分拣提供了基础。再例如，程序员会查询所有指派给自己的缺陷，通过阅读缺陷列表，来了解当前待修复的缺陷。再例如，测试经理报告测试进展，其报告会列举当前活跃的缺陷（体现为一个缺陷标题的列表）来描述软件开发的状态，报告的读者对缺陷所有判断皆来自标题。为了帮助缺陷报告的读者更快、更准确地理解缺陷，测试人员需要认真编写标题。一个较好的模式是“条件?失败”，即阐述在何种情况下软件会发生什么样的失败。以下是一些具体的例子。
当软件不能申请到足够的内存时，打印结果将丢失页面上的一些图片。当打开一个旧版本的文件（版本号：2.0）时，软件报告打开文件失败（错误代码：XYZ）。当程序退出时，它可能引发间歇性崩溃（崩溃时所调用的函数是ABC）。
标题要客观陈述软件所遇到的问题，描述触发问题的情景和问题的症状。这有助于读到标题的人推断缺陷的严重性和可能的技术原因。测试人员还可以在标题中加入一些技术细节，如错误代码和函数名，这使得相似症状的问题可以相互区别。

3　像编写详细测试用例那样编写重现步骤

在编写缺陷的重现步骤时，测试人员可以参考详细测试用例的编写规则，使得重现步骤尽可能地具体、无歧义。如果缺陷与环境有关，在重现步骤之前增加“测试配置”一节，写下测试所使用的操作系统、网络服务、网页浏览器等信息。在重现步骤中，为每一个操作编号，以清楚地表明第1步做什么、第2步做什么。
不要假定缺陷报告的读者对软件很熟悉，要清楚地写下每一步操作的内容，例如点击了什么按钮、在哪个控件中输入了什么字符等。不要包含不必要的步骤。清楚地写下执行操作序列后的“预期结果”。清楚地写下执行操作序列后的“实际结果”。如果可以提供更多的信息，可以将它们写入“附加信息”一节。

4　使用缺陷模板来提交缺陷

许多缺陷管理系统支持缺陷报告模板，测试人员应该充分利用该功能。首先，他可以利用模板为一些缺陷报告字段设置默认值，这提高了编写报告的速度。其次，缺陷模板定义了缺陷报告的结构，能提醒测试人员报告一些重要的信息。以下是一份简化了的缺陷模板，它用于提交“打印”相关的错误。
标题 ：[打印] 在什么情况下，打印发生何种故障
功能路径 ：产品家族X\产品Y\打印
严重程度 ：严重
测试配置：请提供操作系统、打印机型号等信息
重现步骤 ：
1.
2.
3.
预期结果 ：
实际结果 ：
附加信息 ：
请考虑提供如下信息。
用户影响
重现此缺陷的其他情景
有助于调试的任何信息（如屏幕截图、函数调用栈、运行日志、内存转储等）
该缺陷能否稳定重现？如果是间歇性重现，重现概率是多少？有没有更多的信息？
相关缺陷
这份缺陷模板包含“用户影响”等提示词，它们提醒测试人员从特定的角度来提供信息。测试人员可以根据项目的特点，在缺陷模板中加入恰当的提示词。在报告某个缺陷时，测试人员可能会忽略一些提示词，因为它们并不适用于当前缺陷，但这是测试人员思考后的决定，而不是遗忘此类信息而导致的疏漏。
在日常工作中，我会制作几份缺陷模板，分别针对不同的功能模块或缺陷类型。随着项目的进展，我会修订缺陷模板或增加新的模板，使得它们符合项目团队对缺陷的要求。

5　在编写缺陷报告时，要考虑缺陷查询

有时，测试人员需要查询缺陷管理系统。例如，他发现了一个缺陷，在提交缺陷之前，他会搜索缺陷管理系统，以了解该缺陷是否已经被提交。又例如，在发现一个缺陷后，他想起以前曾经提交过一个相似的缺陷，为了了解那个缺陷是如何解决的，他会查询缺陷管理系统。再例如，有人询问测试人员为什么软件是如此设计的，他回忆起是某个缺陷修复决定了当前的设计，于是他会搜索那个缺陷。
可见，查询缺陷是一件常见的任务。为了使查询更轻松，测试人员在编写缺陷报告时要略加斟酌。在编写缺陷标题时，他可以自问：“如果几周后我查询此报告，我会使用什么关键词来搜索标题？其他测试人员会使用什么关键词？”在列举了一组关键词之后，他可以选择一两个写入标题。如果缺陷报告提供了“关键词”字段，他可以将关键词们一起写入该字段。如果没有专属的“关键字”字段，测试人员可以将这些关键词写入报告正文。
有时，测试人员会搜索“重现步骤”或“附加信息”。为此，测试人员应该将尽可能多的细节写入这些部分。最典型的例子是软件崩溃时的函数调用栈。如果缺陷报告总是包含崩溃时的函数调用栈，测试人员用函数名搜索就可以发现此函数有关的软件崩溃。

6　链接相关的缺陷

有些缺陷出现在常见场景或共享模块中，会被多人发现。为了避免重复提交某个缺陷，测试人员需要在缺陷管理系统中搜索相似的缺陷。如果该缺陷已经被提交，测试人员可以将自己发现的信息补充到已有的缺陷报告中。测试人员不应该假设很明显的缺陷一定会被同事提交，根据查询结果采取行动才是合理的策略。
有时，测试人员会发现一些症状相似的缺陷，但并不能确认它们的错误原因是相同的。对于这种情况，他应该为每一个缺陷单独提交一个缺陷报告，并将它们链接在一起，从而让程序员或缺陷评审者了解完整的信息。有些缺陷管理系统支持“链接”缺陷，只要输入相关缺陷的编号，系统就可以将几个缺陷链接在一起。如果缺陷管理系统不支持“链接”，测试人员可以选择一个缺陷作为“主缺陷”，在其他缺陷报告中写下主缺陷的编号，并在主缺陷中记录其他缺陷的编号。

7　注意缺陷报告的可读性

缺陷报告是面向整个团队的公开文档，应该提高可读性以服务读者。测试人员不必反复推敲报告的字句，他只需要注意一些基本规则，就可以提高报告的可读性。避免错别字和病句 。如果用英语撰写报告，利用字处理软件进行拼写和语法检查，能够立即发现并修正明显的问题。对于中文报告，写完之后通读一遍就可以改正大多数文字错误。

尽量用数字列表来记录重现步骤 。尽量用符号列表来罗列事实 。用空行分隔报告的不同部分，在视觉上突显报告的结构 。用屏幕截图、视频录像、内存转储等附件来提供更多的信息 。有些缺陷用文字很难描述，但是一幅截图或一段录像就可以很好地说明问题。关于视频录像工具，智能手机是一个很好的选择。它适用于任何软件和操作系统，且对被测软件的运行没有任何影响。

8　客观中立地书写缺陷报告

缺陷报告是对缺陷的客观陈述，只传递事实，不评价任何人的工作。客观的风格使得测试报告更加可信，倾向性明显的报告则让读者怀疑测试人员的专业态度，反而不利于缺陷的修复。测试人员需要了解项目团队对缺陷严重程度和优先级的定义。坚持按照团队约定来填写这些字段，不但能够保证缺陷报告的一致性，还可以避免一些不必要的争执。有时，测试人员要对缺陷的用户影响或可能原因做一些评论，他应该先列举事实，然后再进行谨慎的推断，并写清楚推理过程的因果逻辑。缺陷报告只报告错误，不要评价软件设计，也不建议解决方案。测试人员可以当面与产品经理、程序员等讨论软件设计，询问实现细节，了解对方观点，并发表自己的意见。