【软件测试】如果你的程序没有修复bug，先别修复，听我说（软件测试中的经典Bug概述）

总结：在现状分析之前，莫白身边的老测试员提到了打印文本溢出缺陷，但负责该缺陷的年轻程序员却表示，项目是这样的：我没时间修复它，因为它是。 随着越来越多的人上网，这个缺陷产生了巨大的影响。 尽管测试专家的抱怨很小，但他们却被严厉驳回。 从开始的坚持，到最后的妥协，墨白感触良多。

简介

今天的主题是每个测试人员都会经历的事情，也是很多人都在努力解决的问题。 椿白以此来表达自己的观点。 他并不是想解决目前的情况。 他希望大家看完这篇文章后，能够少一些痛苦。

情况分析

之前，莫白旁边的老测试员提到了打印文本溢出的缺陷，负责该缺陷的年轻程序员表示，项目中写道： 我试图转移到网上。 由于没有时间修复，该缺陷影响不大，被拒绝了。 测试专家态度恶劣（严重投诉）。 考试专家们自始至终的坚持，让墨白不得不妥协，这让墨白心里很不好受。

为什么程序员不想修复错误？

只是时间不够。 问题太小，无法重现或理解。 这在真实环境中不太可能发生。 此问题仅发生在无人使用的非常特定的设备配置中。 缺陷很难纠正。 风险太大（特别是当我们接近关闭时），但并不影响程序的实际用户。

为什么测试人员会遇到麻烦？

也许他们需要在版本关闭之前解决所有的bug（强迫症），或者程序员可能不了解问题的严重性？漏洞。 该错误可能明显违反规则。 或者该缺陷肯定会影响用户。

为什么说服程序员修复这些 bug 这么难？

让我们谈谈我所看到的：测试人员太执着了（没有必要修复它），测试人员不知道说服程序员的技巧，测试人员低估自己（程序员越强，测试人员越卑微），测试人员的技术水平越低（不知道修复bug的成本。也许）我可以通过添加一个字段来修复它，如果我说开发很昂贵，测试人员认为它真的很昂贵）。

对策

对策首先需要对问题进行分类，分析根源。然后一次一个地回答问题。 不过，本文并不是严谨的学术报告，仅描述了一般措施。

如何说服开发人员修复该错误？

·请解释该问题如何影响产品的正常使用。

·哪些数据被破坏？

·用户遇到此问题的频率如何？

·市场上对同类产品的评论

>

·指出类似问题给客户带来的问题

·引用技术支持收集的详细数据

p>

· 以前的版本已通过此功能的测试

· 与其他项目利益相关者沟通。 通过确定如果不更改程序错误谁将受到最大影响（或者如果更改程序错误谁将受益），确定程序错误造成的问题程度。 说服对此模块感兴趣的人。

· 我们列出了几个场景来说明合理的用户在正确使用该程序时可能遇到的程序错误和问题。

・运行额外的后续测试，以查找错误的更严重后果或在比错误报告中描述的情况更广泛的情况下发生的情况。

补充信息

1. 添加到上面的最后一点。 如果程序员没有修复错误而我们决定反驳它，请不要完全依赖原始测试报告中的措辞或信息。 只要有可能，就做补充测试或者引用更有效的例子。 如果不这样做，不仅会浪费您的时间，还会损害您的可信度并影响您的说服力。

2. 你不必坚持修复每个错误。 项目经理可能会出于风险或成本等原因拒绝修复特定错误。 在这种情况下，我们作为测试人员不必坚持修复每个缺陷，除非我们能够解释特定缺陷可能带来的重大风险。

此外，以下措施将有助于解决该错误：

1.养成写报告的好习惯。 例如，报告可能描述出现问题的多种配置（需要验证），或者报告可能预测某些可能性并在报告中提供相关信息（特别是对于难以重现的错误）。 正确的错误报告有助于修复。

2. 等待一段时间，阅读审核期间每个人的反馈，然后暂停并提供更多信息。

3. 使用更多事实我们来谈谈数据。 例如，“类似的系统也有这个问题。由于这个问题，客户对程序有很好的意见，因为他们平均每周浪费 XX 个小时。” /p>

4。 学习编程并了解错误发生的原因将帮助您编写更好的报告并了解修复错误的成本。

注释

1. 关于使用错误管理系统来监控程序员的表现。 一些测试经理使用错误跟踪数据来鼓励程序员修复错误。 例如，数据可用于提供有关程序员是否有大量未修复的错误、修复时间是否过长或修复是否不断推迟的反馈。 我不会在这里评论你是否应该实现这个系统，但我建议你在这样做时要小心引导程序员的情绪。 否则，你很容易激起一些程序员的愤怒。 有时，他们会强调测试人员的无能或做出不恰当的评论。 对测试部门有用的注释。 不过，这是正常的。 只要错误管理工具用于行政或人力资源管理而不是技术管理，就可能导致这些问题。

2. 关闭bug 的权限应该由测试人员控制。 除非经过测试人员验证，否则无法解决错误。 在某些情况下，程序员可能会将未修复的错误标记为“已较晚修复”、“未修复的非程序错误”或“未修复的重复缺陷”。 测试人员应该并且有义务就此提出问题。

3. 不要让“推迟的更改”变成“从未更改”。 在许多公司中，将错误标记为“后期修复”意味着“它永远不会被修复”。 避免这种情况的一个可行措施是在下一版项目范围审查时，在进度压力最小、项目经理最理性、头脑最清醒的时候指出这些缺陷。 我们还建议您在发现“延迟修复”Bug 后如有任何异议，请尽快联系您的测试经理或项目经理。

4.修复bug后尽快验证，回归失败后尽快联系程序员。 否则，延迟越长，程序员记住的内容就越少。

5. 如果一个bug多次失败，或者在版本临近结束时发现一个严重缺陷，不仅应该记录在缺陷管理工具中，还应该报告给相应的程序员。您需要直接找到并联系他们。

最后，我要感谢所有认真阅读我的文章并看到粉丝和关注度增加的人。，不是很值钱，但是礼貌总是有的。 如果可以使用的话，就可以直接领取。

这些资料对于软件朋友来说应该是最全面、最全面的【测试】完整战备仓库。 这个仓库也陪伴了数万名测试工程师走过了最艰难的旅程。 也希望对你有帮助！

我的QQ技术交流群（技术交流和资源共享，请勿打扰广告）

你也可以自己加入也可以。 群号：310357728的免费资料是作者10多年测试生涯的精华。 有时同行业的专家聚集在一起交流技术。

如果我能帮到你哪怕一点点，你的“赞”就是小编我创作的最大动力。 下一篇文章见。