当前位置：网站首页>遇到程序员不修改bug时怎么办？我教你

对于上面最后一点做点补充：如果程序员不修改某bug而我们决定反驳，不要完全依赖自己最初测试报告中的语言和信息。尽可能做一些补充测试，或列举更有效的例子，否则不仅浪费自己的时间，而且损害自己的信誉，影响自身的说服力。
不必坚持修改所有bug。项目经理可能会因为风险、费用等方面的原因，拒绝修改某些bug，这种情况下，我们测试员不需要坚持修改全部缺陷，除非能说明某缺陷可能引入的严重风险。

8、另外，笔者认为以下措施有助于推动bug的解决：

养成良好的报告编写习惯：比如在报告中描述问题出现的多种配置（需核实），或者在报告中预测某种可能并提供相关信息（特别是难以复现的bug）。好的错误报告会推动问题的修正。
先等一等，在评审时看看大家反映，以静制动，提供补充信息。
多用事实和数据说话，例如“某个类似系统也有这个问题，客户因为那个问题，对程序的意见很大，因为客户平均每周要浪费XX时间在上面”
学习编程，理解bug产生的原因，助于写出更好的报告，以及理解bug修复成本。

9、注意点

关于利用bug管理系统监视程序员的表现。有的测试经理尝试用bug跟踪数据来促使程序员修改bug，比如利用数据反馈某程序员是否存在大量的bug未修改，或是否修改时间过长，或是否总是推迟修改。是否应该推行这种制度笔者不做评论，不过笔者建议推行时需注意引导程序员的情绪，否则很容易引起某些程序员的反感，他们会在某些时候大肆放大测试员的无能，或者发表不利于测试部的言论。不过这也是正常的，bug管理工具只要被用于行政或人事管理，而不是技术管理，就会产生这些问题。
关闭bug的权限应控制在测试员手中。除非经过测试员的验证，否则bug都不能闭环。在某些情况下，程序员会将未修复的bug置为“延期修改 ”、“非程序错误不予修改”“重复缺陷不予修改 ”，测试员需要且有义务对此提出质疑。
尽量避免“延期修改”变为“永不修改”。在很多公司中，bug标记为“延期修改”即意味着“永不修改”。为避免这种情况，有一种可行的措施是在下一版本做项目范围评审时即提出这些缺陷，那时候的进度压力最小，而且项目经理也最理智、最清醒。另外，发现“延期修改”的bug后，若持反对意见，建议尽快跟测试经理或者项目经理进行沟通。
bug修改后尽快验证，回归不通过后尽快跟程序员沟通，否则时间耽误越久，程序员记得的内容越少。
如果bug多次回归不通过，或在临近封版时发现严重缺陷，不仅要在缺陷管理工具中记录，更应该直接找到相应的程序员进行沟通。