缺陷报告的书写逻辑和艺术

缺陷报告的书写逻辑和艺术"/>

缺陷报告的书写逻辑和艺术

最前面的话

当面试测试工程师的时候，有时候我会问面试者，“要写好一个缺陷报告，在描述缺陷的时候最需要注意的是哪些点？”

大部分面试者，会熟练地回答：“要有缺陷的标题，要有步骤，要有实际结果，要有期望结果，要标注环境，要标注。。。”

如同教科书般的回答，但是，这样的答案并不对。

这些是格式，但不是要点。要点是能否使阅读者确切明白缺陷的表现形式，以及明白缺陷出现的准确条件。

因此，这里我们讨论的是写好缺陷报告的逻辑和艺术，而不是研究缺陷报告的模板或流程规范与否。

1.  通往世外桃源之路

     --------- 要反复试验出缺陷出现的各个必要条件，保证缺陷可重现 ---------

     武陵捕鱼人偶然发现了桃花源后，在回来的路上每一步都做了标记，却再也没能够第二次找到桃花源。以我们现在的话说，他并没有掌握去桃花源的关键方法。于是他费尽心机刻下的那么多标记，全都没有用。桃花源除了作为一个梦想的仙境之外，也没有任何现实意义。

     同样地，缺陷只有当能被再次并多次重现，缺陷才具备了被修正的可能，因而提交缺陷这一工作才具备意义。

     作为测试人员，第一次发现缺陷的步骤，带有很强的偶然性，往往不是能重现这个缺陷的准确步骤。这个“偶然性”导致的“不准确”存在两层含义，一是按步骤不能重现缺陷，还有是描述的范围并不充分。我们必须要解决的是不能重现的描述。

     不能重现的根本原因是缺失了一个或多个必要的条件。如果缺陷报告的步骤写得没有差错，那么缺失的就是缺陷报告的前置条件。前置条件和步骤有同样的重要性，但是在实际中，前置条件的描述往往容易被忽略。前置条件的缺失解释了为什么缺陷不能被重现的原因。一个常见的缺陷案例：缺陷在测试环境下可以被重现，但开发环境下却不能被重现。这可以归结为开发环境不存在测试环境的某种状态，或者可理解为缺少某种数据，开发环境因此并不具备同样的前置条件。还有一些在测试环境下的重现率都不是100%的缺陷，甚至有的缺陷被发现后再也没能被重现过。我们可以想象，导致这个缺陷产生的前置条件包含了某个关键因子，而它的值一直持续在变化，因而测试环境无法持续具备重现该缺陷的前置条件。

     要让缺陷能被重现，这需要测试人员在发现缺陷的步骤基础上，对缺陷的成因有一定的猜想能力，然后小心求证每个猜想的因子是否和缺陷的结果存在相关性。

     --------- 能做出归纳是测试专业性的重要体现 ---------

     到这里，测试人员已经达到了最基本的要求。要让缺陷报告变得更为有效，并体现出测试人员的专业性，还需要考虑已有描述的充分性。

     在描述方式中，更重要的是能说明出错的机制，而不是出错的现象。这里的机制指的是程序本身的因果关系逻辑，而现象是指程序运行在某个实例上的表现。换简单的方式说，就是要归纳的方式，而不是仅靠具体的测试数据去描述缺陷。尝试区分以下的三种描述缺陷的方式：

案例1

Icon

1. 创建一个名字为“applepie”的商品失败。                                 （如果系统里没有类似于“apple”的商品存在，则无法重现）
2. 系统存在一个名为“apple”的商品的情况下，创建一个名字为“applepie”的商品会导致失败。      （创建“pineapple”呢？）
3. 用一个包含已存在的商品名字的名称创建新商品会导致失败

      按第一种方式很可能不能重现缺陷，按第二种方式能重现缺陷但容易被理解为一个更特殊的情况，而第三种方式真正说明清楚了这个问题的边界范围。一个清楚的描述，将有效减少对缺陷的误解，将对项目经理判断缺陷的严重程度，开发人员定位问题的原因，和测试人员验证该缺陷，起到至关重要的作用。

2. 冰山的一角还是全部

     ---------- 要包括全部的错误症状，而不是最先出现的 ---------

     冰山的绝大部分体积隐藏在水平面之下，能进入视野的只有在水面上的的一小部分顶部。如果只是靠一瞥之下来下定义冰山的规模，就可能会得到相距甚远的结果。

     一个缺陷在程序内产生，表现出来的可能会有多个错误的症状。更进一步来说，一个严重的缺陷，也可能伴随着出现若干较轻微的症状。造成测试人员描述失误的一种常见情况是，以一个较轻的错误症状掩盖了一个严重的错误症状。而阅读者的逻辑是，描述出来的是缺陷的所有症状，因而没有描述的部分都是运行正常的。这样就会造成阅读者错误的理解。

案例2

Icon

     以创建商品的功能为例。按照需求，创建成功时系统出现提示信息提示成功，创建失败的时候系统出现提示信息提示失败。测试人员在测试创建商品的基本功能时，尝试了创建不同的商品，看到系统都出现了提示信息，但提示信息都是乱码，于是提交了一个“实际结果”为“创建商品时出现乱码的提示信息”的缺陷。阅读者可能会理解这个缺陷为文字样式错误，但实际上那原本是个因为创建失败而显示的消息，而创建商品也并没有成功。

     因此在这个案例里，更重要的是关键的功能(创建商品)到底成功了没有。如果创建商品失败了，这个缺陷一定要包括这个信息，“实际结果”应该类似于：“创建商品失败，并且出现乱码的提示信息”。

     测试人员在写缺陷报告前需要确认，已经找到了全部的错误症状，特别是重要的症状。

3. 图书馆的书架

      --------- 标题要简要且易于被辨识和区分 ---------

      图书馆的书架上摆满了书，每一本都有几百页，但都只有一个简短的名字。阅读者不指望通过简短的书名能直接找到书，但是可以通过快速瞥一下书名而马上排除那些不相干的书。想象一下，如果每本书的书名都是几十个字的长名字，密密麻麻地堆积在书架上，这对查阅的读者来说，将会是个灾难。

      缺陷的内容没有书那么丰富，有的时候缺陷标题本身可以描述清楚缺陷，但更多的时候是为了作者日后看到这个标题时能回想起缺陷内容，或者是为了便利其他人查询缺陷。从这个意义上出发，能否标识缺陷的特征是最重要的。在同一个项目中的缺陷的标题，要能具备唯一性。

      如果能在标题中概述得足够详细当然好。但是，标题也有它自身的限制，即不宜过长过繁琐。标准的做法是用一个短句，而不是用一个完整的句子来描述缺陷的标题。借用上面的案例1比较以下两种写法：

Icon

1. 【创建商品】用一个包含已存在的商品名字的名称导致失败
2. 在新建商品的时候，输入一个商品名称（如：applepie），而该名称的部分和已存在的一个商品名称（如：apple）相同的时候， 保存会失败，显示信息“该商品名称已存在”。

      两种标题虽然都对，但是当阅读者是在整屏缺陷列表中寻找一个缺陷的时候，第一种书写方式要显得清晰效率得多。

      要把繁琐的标题改写成简单易懂，可以用下面的方式： 

•  将缺陷的前置条件，步骤和实际结果整合起来，在不损失语义的前提下尽最大可能地压缩字数。
•  可在标题内辅助少量文字标签，来帮助阅读者查找。如：发现缺陷的阶段（是冒烟测试，功能测试还是回归测试），或者缺陷所在的测试场景名。

4. 叙述的风格

       --------- 文字为主，截图和日志为辅 ---------

       尽管有“一图胜千言”的说法，文字仍然是我们最精准最强大的沟通方式。只要使用得当，文字可以描述清楚任何现象，但是截图不能，不同的人看同一副图也有可能得出不同的理解。  

       所以，在提交缺陷的时候，如果描述得当不一定要有截图或日志，但不能没有文字描述。

       --------- 保持严谨 ---------

       项目中使用的文档，包括缺陷报告，最需要的风格是严谨。要去除多余的言语，讲多错多，只可能带给阅读者不必要的误解。

       写一个缺陷的报告不同于写小说，不需要有修饰、比喻、夸张、映射，不需要华丽的辞藻，不需要带主观感情色彩，不需要非陈述的语气。要枯燥而不是有趣，要务实而不是花哨，要还原而不是渲染，要直接而不是含蓄。