问题1：比如我们软件有个帮助功能，是个H5页面，文案内容由运营提供，他们在后台可以随时改，后面发现一个文章的内容有误，就说测试漏测，然后测试肯定不背锅啊，就说应该找运营，然后就被说没有责任心，找借口，考核直接不及格
秘籍1:
上线前会对发布的说明类内容做检查，算是我们测试范围之内的工作。如果我处在你的位置上，刚发现这个问题时，我会以退为进，告诉领导在这个问题上我们测试工作确实存在实物，当初的测试范围没有定义清楚，跟业务没有沟通好。--先把责任推到“沟通不到位”上面，另外“测试范围不清楚”一般领导会分摊责任。-再说，为了避免以后出现类似的情况，我跟业务做了约定，以后由我们共同检查。同时建议增加一个上线前验证的环节，专门检查这一类的问题。---这样说，也不会让人觉得遇到事情推脱责任，而是积极的反思工作中的不足，想法解决------有时候出了问题，不一定是坏事，利用好了也可以转化为自己的幸事。不要害怕“背锅”，有些责任可以主动承担。记住，出了质量问题，无论责任在哪里，先思考自己的工作是不是有可以改善的地方，在很多地方，测试部想提高话语权，想改善流程是很困难的，正好可以利用这些“事故”来推进工作。
问题2 ：测试的时候提出响应有点慢，然后产品经理说先不考虑性能，把功能上上去再改，然后上上去后其他部门的老大说慢，然后就是测试的责任
秘籍2：
很常见的情况。可以跟其他部门老大说明一下情况，不过从结果来看，测试做的确实有欠妥的地方，毕竟测试人员没有及时的把问题影响性跟干系人说清楚。记录好bug，bug未修复不关闭，如果有上线前评审，把这些问题拿出来让大家都知道。无论问题最后怎么样，测试人员先把自己的立场摆清楚。
问题3：怎么避免测试遗漏
秘籍3：
1、很难完全避免遗漏 。
2、提高用例覆盖度有两种主要方式，一是过程控制，一个是自身实力。
3、过程控制方面，比如团队中是否进行了有效的需求调研和评审，是否进行了有效的用例评审，沟通渠道（信息传递）是否顺畅等。
4、自身实力方面，是否拥有足够的相关业务知识，对产品相关的业务和领域知识有足够理解； 自己是否拥有一套成熟的用例设计框架（思维框架）。
5、还可以通过以下几点提高覆盖率： 结对测试（交叉测试、定期更换测试项目）； 网上查找类似项目的测试点； 总结该类项目的风险和重点； 多看书。