在我写这篇文章时，首先进入我脑海的是Cem Kaner的话-“最好的测试人员不是发现缺陷最多的人或者让最多程序员尴尬的人。最好的测试人员是让最多的缺陷得到修复的人。”

那么-发现最多的缺陷和让最多的缺陷得到修复这两者之间的区别是什么？

难道不是很明显记录在缺陷管理系统里的任何缺陷都应该被修复吗？答案是否定的。有很多因素比如推广产品的时间，日程表上完成项目的时间，开发在不切实际的紧张日程中工作等。迫使公司发布有一些缺陷的产品大部分情况下不会影响用户使用。

谁给了管理层信心-呈现在产品里的缺陷不会影响客户对利益相关人的信心、信赖以及兴趣？-是测试工程师或者测试团队-测试工程师有职责使得那些可能对产品质量产生负面影响的缺陷得到修复。

缺陷的优先级，在我看来大部分取决于测试人员是如何将一个问题呈现给开发和管理团队的。

将其视为像对缺陷做广告或推销

– 这个涉及到2个步骤：

1. 正确地描述或汇报缺陷

2. 了解缺陷相关的所有信息使得更进一步地细节得到更好的解释

缺陷汇报的艺术

是的，缺陷汇报是一门艺术。缺陷被描述的方式呈现了一个人测试工程师的技术能力，领域知识以及沟通能力。

通常，一个缺陷应该包含如下信息：

• 缺陷总结
• 重现步骤
• 附件（截图，日志文件等）
• 缺陷重现性
• 缺陷严重程度
• 软件版本，环境信息
• 基于企业需求的其他信息。

一个重要的提示：

始终深入挖掘以发现问题的根本原因并汇报。比如，用户名和密码的正确组合导致一个简单的登录失败可以和各种不同原因有关：

1. 根本就没有做登录凭证验证

2. 远程登录网络超时问题

3. 系统可能将所有大写字母认为是非大写.

因此，作为一名测试人员你应该能够解读出如下缺陷总结语句的不同之处：

• 用正确的用户名和密码无法登录”
•  “当用户名或密码包含了大小写混合字母时，用正确的用户名和密码无法登录。”

后者显然对问题的描述更清晰而且没有歧义。这样，你不仅增加了你作为一名测试人员的可靠性，而且汇报了实际问题并非只汇报了一个症状。

现在我们看看一个缺陷报告中的每一个要素并且讨论下每一个要素的重要方面：

#1.缺陷概要

一个缺陷概要应该提供确切问题的快照。它必须精确且定向。

例子:

我会尽量用例子而非理论来解释。

我们假设有一个简单的登录模块。一位新用户无法用他的缺省密码登录并浏览网站是个问题。当我把同样的场景呈现给我培训过的许多学生时，在培训的开始阶段，有一些这样的概要示例：

”新用户无法登录”

 “用户登录没有按预期工作”

 “用户无法用正确的密码登录”

从上述示例中，你能挑出一个确实描述了实际问题的语句吗？我觉得不能。概要应该总是给出有关失败场景的全面信息。

考虑如下语句：

 “新用户无法用电子邮件或手机短信里提供的缺省密码登录系统”

正如你所看到的，从上述描述里一名开发人员能清楚地知道问题是什么并且问题在哪里。

因此，尽量找出正确的词汇来描述可以直接给出信息的概要。必须避免使用通用描述比如“没有正常工作”，”没有按预期工作”等。

#2.重现步骤以及附件

无法重现的缺陷总是退居次位，即使它们可能非常重要。因此，要认真书写描述正确的步骤。重现步骤应该是精确的并且和导致问题的步骤完全一样。就功能相关的缺陷，如下示例可以提供你一个例子。

例子:

考虑上一部分陈述的问题。

1. 在主页面用注册选项创建一个新用户（示例用户名：HelloUser）

2. 缺省密码会通过邮件和短信发送。在第一步创建用户时，会提供邮箱账号和收短信的手机号码。（邮件示例：HelloUser@hello.com, 手机号码示例: 444-222-1123）

3. 在主页面选择登录选项

4. 在用户名文本框里，提供第一步里的示例用户名。

5. 在密码框中，提供电子邮件或短信收到的缺省密码。

6. 点击登录按钮

7. 期望结果： 用户应该能够用提供的用户名和密码登录并进入用户账户页面。

8. 实际结果： “无效用户名/密码”的消息显示。

------------

上述示例中的任何一个信息没有提供都会导致沟通障碍并且开发人员将无法重现问题。步骤必须具体并且包含测试中你使用的详细样本数据。

如果有可能或者无论在哪适用，提供你确切在屏幕上所看到的问题的截图。这样，不仅从一个很好的角度给开发人员提供了问题，也对你的测试结果提供了一个证据。

万一有非功能性测试用例比如在上述细节中还有压力，稳定性或者性能测试用例，关于导致系统压力的场景信息也要如实汇报。此外，还有一些系统对每一个操作汇报日志。日志通常会打印出开发人员在他们代码中提供的语句。每当执行一个模块，相应的日志会打印或显示出来。如果有日志，那将有助于开发人员很大程度上重现问题。

#3.缺陷重现性

一个问题或大或小将会依据重现性被划分优先级。问题总是，有时，很少或只有一次被发现。一个总是被重现的问题优先级比其他的都要高。

那么，测试工程师有责任去追踪一个总是能被重现的问题被完全下降到下一个级别的场景。有时候可能有一些测试工程师不可控的问题会导致一个问题在多次尝试中仅能重现几次。在这样的情况下，需要总是提到执行某一特定场景的次数以及在那些次数中问题被重现的次数。

这样会增加你所提到的缺陷报告的可信性。此外，还会提高你作为一名测试人员的信誉。

#4.缺陷严重性

显然严重性是对优先级处理的最大影响因素之一。

如下是严重程度的不同类别。请注意这些只是通用示例，每个公司定义都不同。

1. 级别1 – 致命 – 灾难性的缺陷，如果不修复用户无法继续使用软件并且没有可能的变通方案

2. 级别2 – 高级 – 和级别1的缺陷类似但是有变通方案

3. 级别 3 – 中级

4. 级别4 – 低级

5. 级别5 – 不重要的

例如，我们来比较两个相似的问题。

在我们的机顶盒里，一些服务供应商提供了目前服务调整的频率信息。我们假设频率显示为100MHz而不是100.20MHz。这可能不会影响客户查看服务但是可能会影响机顶盒的监测诊断。因此这个可以被展现为级别3的问题。

假设类似的问题在银行领域：如果你的账户余额显示为$100,而不是$100.20，想象这个问题的影响。这必须是级别1的缺陷。如你所看到的在两个场景中界面没有显示小数点后的数字的问题非常相似。但是依据涉及到的领域不同，影响也不同。

有效参与软件版本控制会议

通常，每一家公司都有它自己的流程来调查和定义缺陷优先级。一般来说在项目中会有定期会议来讨论缺陷并定义缺陷优先级。

这些会议的流程如下：

1. 根据严重性从缺陷管理系统里查询出缺陷列表

2. 看概要讨论缺陷在软件产品使用过程中对用户体验的影响

3. 基于风险和影响评估对缺陷设置优先级并分给合适的开发人员来修复。

在步骤2中，如果缺陷没有收到它应得的优先级，那每一位测试工程师有必要为缺陷对用户体验所造成的影响来辩护。毕竟，是我们测试工程师从用户的角度考虑来写的测试用例并进行产品测试。

考虑银行领域里小数点后的数字不显示的问题例子。对开发人员来说，这看起来可能是个不太严重的问题。他可能会争论将变量声明为浮点型来代替整型以解决这个问题，因此是不太严重的问题。

但是作为一名测试人员，你的角色是解释客户的处境。你的观点应该是在这种场景下用户会如何抱怨。测试人员应该说这在用户中将会引起恐慌因为客户在美分上损失了他的金钱。

没有适当推销一个缺陷产生的影响

如果一个缺陷没有被适当推销，可能会产生如下问题:

• 不正确的缺陷优先级
• 延迟修复重要问题
• 带有严重缺陷的产品被发布
• 客户的负面反馈
• 品牌价值贬低

除了上述提到的所有原因，建立你作为一名测试工程师的的信誉非常重要。这更像为你自己发展品牌价值。

在你职业生涯的初始阶段，如果你能保持你关于“无法重现”或“需要更多的信息”或“不是有效缺陷”或严重程度改变的数量尽可能少，在一定阶段你提交的缺陷将不会被仔细审查而是直接分配给合适的开发人员去修复。

为了发展这样的品牌价值以及赢取你的团队和开发团队以及管理团队的信任，你必须发展你的技术技能如测试知识，领域知识以及沟通技能。

结论

任何产品或服务，或大或小，如果没有恰当地推销，势必会失败。一旦一个品牌确立了，任何小产品对用户都会成为超级一击。

话虽如此，过度推销一个产品也会对声誉造成损害。

因此，一个缺陷应该总是被以清晰、精确的方式展现，以便于在广泛而详尽的软件地图中给出缺陷一个确切的位置。我重申下，这不仅提高了软件的质量而且减少了测试的成本并且在更大程度上开发了软件。

好吧！现在我们马上就去发现缺陷并让缺陷得到修复吧！

【英文原文：http://www.softwaretestinghelp.com/bug-reporting-get-your-bugs-fixed/】

{测试窝原创译文，译者：思雨}
译者简介：思雨，从事软件测试7年，热爱自动化测试和手工测试