摘要：现状分析之前，墨白身边一位测试老人提了一个打印文字溢出的缺陷，但该缺陷的负责人，一个年轻的程序员以项目临近上线没时间修改，且该缺陷影响很小而驳回，态度强硬强硬的诉苦，那位测试专家从开始的坚持到最后无奈妥协，让墨白感触良多。
前言
今天的话题，是所有测试员都会经历的，也多为此苦恼过。墨白借此谈谈自己的看法，不求解决现状，只希望大家看完此文后能少一些苦恼。
现状分析
之前，墨白身边一位测试老人提了一个打印文字溢出的缺陷，但该缺陷的负责人，一个年轻的程序员以项目临近上线没时间修改，且该缺陷影响很小而驳回，态度强硬（强硬的诉苦），那位测试专家从开始的坚持到最后无奈妥协，让墨白感触良多。
程序员为什么不愿意修改bug？
无非是没时间，问题太小，重现不了，理解不了，在实际环境中不太可能发生，问题只出现在没有人用的非常特殊的设备配置上 ，改正缺陷的风险太大（特别是临近封版），不会影响程序的实际用户等。
我们测试人员为什么苦恼？
可能是觉得封版之前bug就应该全部解决（强迫症），也可能是觉得程序员没有理解bug的严重性，也许是bug明显违反规范，也可能是觉得缺陷肯定会影响到用户。
我们为什么难以说服程序员去修改那些bug？
说一说我看到的：测试员过于执着（bug并非必须修改），测试员不清楚说服程序员的技巧，测试员看轻自己（程序员一旦强势，测试员就低声下气），测试员技术水平低（不清楚修改bug的成本，可能只是加一个字段就能修复，开发说成本大，测试员就以为真的很大）。
应对措施
应对措施本应跟先将问题分类，分析根源之后再一一作答。不过本文不是严谨的学术报告，只谈几点一般性的措施。
如何说服开发改正bug？
· 解释问题会怎样影响产品的正常使用？
· 会破坏什么数据？
· 用户如何经常遇到这个问题？
· 市面上类似产品的有关评论
· 指出类似的问题给客户带来的麻烦
· 多引用技术支持收集的数据
· 以前的版本通过了这个功能的测试
· 与其他项目干系人沟通。找出如果程序错误不修改受影响最大的人（或修改后受益的人），确定程序错误会给他们带来多大麻烦。让关心这个模块的人去说服。
· 列举一些场景，说明合理的用户在合理地使用程序时会遇到的程序错误，或产生的疑问。
· 补充做一些后续测试，寻找该程序错误更严重的后果，或寻找比在错误报告中所描述的更广环境下出现的情况。
补充
1、对于上面最后一点做点补充：如果程序员不修改某bug而我们决定反驳，不要完全依赖自己最初测试报告中的语言和信息。尽可能做一些补充测试，或列举更有效的例子，否则不仅浪费自己的时间，而且损害自己的信誉，影响自身的说服力。
2、不必坚持修改所有bug。项目经理可能会因为风险、费用等方面的原因，拒绝修改某些bug，这种情况下，我们测试员不需要坚持修改全部缺陷，除非能说明某缺陷可能引入的严重风险。
另外，以下措施有助于推动bug的解决：
1、养成良好的报告编写习惯：比如在报告中描述问题出现的多种配置（需核实），或者在报告中预测某种可能并提供相关信息（特别是难以复现的bug） 。好的错误报告会推动问题的修正。
2、先等一等，在评审时看看大家反映，以静制动，提供补充信息。
3、多用事实和数据说话，例如“某个类似系统也有这个问题，客户因为那个问题，对程序的意见很大，因为客户平均每周要浪费XX时间在上面”
4、学习编程，理解bug产生的原因，助于写出更好的报告，以及理解bug修复成本。
注意点
1、关于利用bug管理系统监视程序员的表现。有的测试经理尝试用bug跟踪数据来促使程序员修改bug，比如利用数据反馈某程序员是否存在大量的bug未修改，或是否修改时间过长，或是否总是推迟修改。是否应该推行这种制度这里不做评论，不过建议推行时需注意引导程序员的情绪，否则很容易引起某些程序员的反感，他们会在某些时候大肆放大测试员的无能，或者发表不利于测试部的言论。不过这也是正常的，bug管理工具只要被用于行政或人事管理，而不是技术管理，就会产生这些问题。
2、关闭bug的权限应控制在测试员手中。除非经过测试员的验证，否则bug都不能闭环。在某些情况下，程序员会将未修复的bug置为“延期修改 ”、“非程序错误不予修改”“重复缺陷不予修改 ”，测试员需要且有义务对此提出质疑。
3、尽量避免“延期修改”变为“永不修改”。在很多公司中，bug标记为“延期修改”即意味着“永不修改”。为避免这种情况，有一种可行的措施是在下一版本做项目范围评审时即提出这些缺陷，那时候的进度压力最小，而且项目经理也最理智、最清醒。另外，发现“延期修改”的bug后，若持反对意见，建议尽快跟测试经理或者项目经理进行沟通。
4、bug修改后尽快验证，回归不通过后尽快跟程序员沟通，否则时间耽误越久，程序员记得的内容越少。
5、如果bug多次回归不通过，或在临近封版时发现严重缺陷，不仅要在缺陷管理工具中记录，更应该直接找到相应的程序员进行沟通。
最后感谢每一个认真阅读我文章的人，看着粉丝一路的上涨和关注，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：
这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!
在我的QQ技术交流群里（技术交流和资源共享，广告勿扰）
可以自助拿走，群号：310357728群里的免费资料都是笔者十多年测试生涯的精华。还有同行大神一起交流技术哦
如果对你有一点点帮助，各位的「点赞」就是小编创作的最大动力，我们下篇文章见！
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/119495.html
摘要：我说，那也不是人人，都像你弟弟那样，加班加没了生活。说到，一般人就会想到加班熬夜猝死每当圈出现了人员伤亡，就绕不开两个字加班。加班，是不可避免的，尤其是在这个行业。看到这篇文章的你，是不是也正在加班呢 给同学的弟弟介绍了份工作，上周给我打电话，说他弟弟报怨，公司加班太多。我说，都这样啊，刚入行，适应段时间就好了。同学问我：是不是干个三五年，或者混个主管，就没那么忙了？我说，我还见过42...
摘要：背景最近时运不佳，几乎天天被线上问题骚扰。工具分析所以最好的方式就是不改动一行代码把这个问题分析出来。我们选用了阿里以前开源的来使用。因为这个项目阿里多年没有维护了，还残留一些我在它原有的基础上修复了个影响使用的，同时做了一些优化。 showImg(https://segmentfault.com/img/remote/1460000016978923?w=1920&h=1080); ...
摘要：接手垃圾代码当然比较恶心，但需要从时间成本和人力成本上去考虑，只有资源充足的情况下才去做重构优化，否则最好还是以平常心对待。不是一朝一夕的事情马方华垃圾代码的框架一般很难改。管振伟再垃圾的项目代码，也不能开始就推倒重来。 曾经有一段「垃圾代码」放在我的面前，我没有拒绝，等我真正开始接手的时候我才后悔莫及，程序员最痛苦的事莫过于此！当然，这些都是改编自周星星同学的经典台词，不过相信读者看...
摘要：仿又来了又写了一个，别急呀，我可没上次写的代码这是用写的基本界面都已经实现，当然了，有些地方图省事搞不定追求速度写的，就自然会导致退而求其次的实现方式代码结构可能不太规范清晰可能还有呢我不听我不听项目地址我的个人主页尽管风光无限几乎对各大 仿《ONE》APP又来了！ 又写了一个《ONE》，别急呀，我可没copy上次写的代码~ 这是用ReactNative写的《ONE》 基本界面都已经实...
摘要：仿又来了又写了一个，别急呀，我可没上次写的代码这是用写的基本界面都已经实现，当然了，有些地方图省事搞不定追求速度写的，就自然会导致退而求其次的实现方式代码结构可能不太规范清晰可能还有呢我不听我不听项目地址我的个人主页尽管风光无限几乎对各大 仿《ONE》APP又来了！ 又写了一个《ONE》，别急呀，我可没copy上次写的代码~ 这是用ReactNative写的《ONE》 基本界面都已经实...
阅读 2655·2021-11-25 09:43
阅读 2829·2021-09-28 09:43
阅读 642·2021-09-08 09:35
阅读 1140·2019-08-30 15:56
阅读 984·2019-08-30 13:00
阅读 2510·2019-08-29 18:35
阅读 1605·2019-08-29 14:07
阅读 3244·2019-08-29 13:13
