测试人员在实际项目中遇事的一些正确的处理姿势

问题1：

比如我们软件有个帮助功能，是个H5页面，文案内容由运营提供，他们在后台可以随时改，后面发现一个文章的内容有误，就说测试漏测，然后测试肯定不背锅啊，就说应该找运营，然后就被说没有责任心，找借口，考核直接不及格

处理方式:

上线前会对发布的说明类内容做检查，算是我们测试范围之内的工作。如果我处在你的位置上，刚发现这个问题时，我会以退为进，告诉领导在这个问题上我们测试工作确实存在实物，当初的测试范围没有定义清楚，跟业务没有沟通好。--先把责任推到“沟通不到位”上面，另外“测试范围不清楚”一般领导会分摊责任。再说，为了避免以后出现类似的情况，我跟业务做了约定，以后由我们共同检查。同时建议增加一个上线前验证的环节，专门检查这一类的问题。这样说，也不会让人觉得遇到事情推脱责任，而是积极的反思工作中的不足，想法解决------有时候出了问题，不一定是坏事，利用好了也可以转化为自己的幸事。不要害怕“背锅”，有些责任可以主动承担。记住，出了质量问题，无论责任在哪里，先思考自己的工作是不是有可以改善的地方，在很多地方，测试部想提高话语权，想改善流程是很困难的，正好可以利用这些“事故”来推进工作。

问题2：

测试的时候提出响应有点慢，然后产品经理说先不考虑性能，把功能上上去再改，然后上上去后其他部门的老大说慢，然后就是测试的责任

处理方式：

很常见的情况。可以跟其他部门老大说明一下情况，不过从结果来看，测试做的确实有欠妥的地方，毕竟测试人员没有及时的把问题影响性跟干系人说清楚。记录好bug，bug未修复不关闭，如果有上线前评审，把这些问题拿出来让大家都知道。无论问题最后怎么样，测试人员先把自己的立场摆清楚。

问题3：

开发人员不修改bug怎么办？

处理方式：

这个问题，从事软件测试这一行的绝大多数人都会遇到。 跟很多公司很多员工就这个问题进行过沟通？多数人对于开发人员不修改bug的现象可以举出很多例子，言语间也颇多不满、迷茫。但少有人能找到有效的解决方法。今天就说一下我的看法。 开发不改bug这个问题，有指标的方法，也有治本的措施，但没有一劳永逸的方案。不同的公司、不同的团队、不同的项目背景，采取的方法都可能不同。想解决问题，首先得研究问题，弄清楚开发为什么不修改bug。有些动作要从做事的角度考虑，也有的方法要从“人”方面下手。 下面我贴一下以前写的一篇文章，仅供参考。

程序员为什么不愿意修改bug？ 无非是没时间，问题太小，重现不了，理解不了，在实际环境中不太可能发生，问题只出现在没有人用的非常特殊的设备配置上 ，改正缺陷的风险太大（特别是临近封版），不会影响程序的实际用户等。

我们测试人员为什么苦恼？ 可能是觉得封版之前bug就应该全部解决（强迫症），也可能是觉得程序员没有理解bug的严重性，也许是bug明显违反规范，也可能是觉得缺陷肯定会影响到用户。

 

我们为什么难以说服程序员去修改那些bug？ 说一说我看到的：测试员过于执着（bug并非必须修改），测试员不清楚说服程序员的技巧，测试员看轻自己（程序员一旦强势，测试员就低声下气），测试员技术水平低（不清楚修改bug的成本，可能只是加一个字段就能修复，开发说成本大，测试员就以为真的很大）

应对措施：本应跟先将问题分类，分析根源之后再一一作答。不过本文不是严谨的学术报告，笔者只谈几点一般性的措施

 

如何说服开发改正bug？

1、解释问题会怎样影响产品的正常使用？ 

2、会破坏什么数据？ 

3、用户如何经常遇到这个问题？ 

4、市面上类似产品的有关评论 

5、指出类似的问题给客户带来的麻烦 

6、多引用技术支持收集的数据 

7、以前的版本通过了这个功能的测试 

8、与其他项目干系人沟通。找出如果程序错误不修改受影响最大的人（或修改后受益的人），确定程序错误会给他们带来多大麻烦。让关心这个模块的人去说服。 列举一些场景，说明合理的用户在合理地使用程序时会遇到的程序错误，或产生的疑问。 

9、补充做一些后续测试，寻找该程序错误更严重的后果，或寻找比在错误报告中所描述的更广环境下出现的情况。

补充

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多次回归不通过，或在临近封版时发现严重缺陷，不仅要在缺陷管理工具中记录，更应该直接找到相应的程序员进行沟通。

问题4：

怎么避免测试遗漏？

处理方式：

1、很难完全避免遗漏 

2、提高用例覆盖度有两种主要方式，一是过程控制，一个是自身实力。

3、过程控制方面，比如团队中是否进行了有效的需求调研和评审，是否进行了有效的用例评审，沟通渠道（信息传递）是否顺畅等；  

4、自身实力方面，是否拥有足够的相关业务知识，对产品相关的业务和领域知识有足够理解； 自己是否拥有一套成熟的用例设计框架（思维框架）；

5、还可以通过以下几点提高覆盖率： 结对测试（交叉测试、定期更换测试项目）； 网上查找类似项目的测试点； 总结该类项目的风险和重点； 多看书