摘要：
为什么做了测试，可系统上线后还是有很多BUG？为什么所有的测试案例都执行了，可还是有很多漏测的点？为什么测试规范和模板都已经很明确了，测试体系也已经完善了，但是测试分析出来的案例还是一团糟，其他人看不懂？为什么每个步骤和阶段都有对应的说明，测试方案也很清楚明了，但计划却总是赶不上变化？为什么？这里有很多很多为什么？
正文：
在座的各位都是做测试的，我们有充分的理由去对别人发起指责，去挑刺，去跟踪、监督、控制，有时候PMO都杠不过我们，论抬杠，我们是专业的，若是排个辈分，抬杠星人得称我们是祖宗。
这个时候就有不服的站出来了，凭什么测试说的都是对的？是的，测试说的就是对的。
如果要这样装逼，请忍耐一下，你的开发可能会跟你进行一场亲切的交流。这个时候千万别提BUG。
测试和开发相爱相杀的日常互动固然让人欣喜，有时也让人激动。但是在生产上出现BUG的那一刻，是不是感觉芜湖完了，曾经的五杀也不香了。
测试是发现产品的问题，提出相应的改进，同时也是对质量的一个评估。简单片面点说，是对开发实施成果的评估。既然产品质量交给了测试来评估，那么又有谁来评估测试呢？
现在有个词叫测试效能提升，或者效率提升，那么是不是该好好想想如何进行测试质量提升呢。既然有运动员，有裁判，也应该有对裁判裁判的裁判。
有部分企业使用的是KPI的方式，考核缺陷数量，案例执行数量，确实有些效果，但是效果也是微乎其微。凡是数据皆可造假，而查询造假（打假）的代价比造假的代价高的多了去了。
现在使用KPI的企业有相当一部分，最终结果如何大家也心知肚明或心照不宣，大家都愿意给别人戴上枷锁，却很少有人愿意给自己带上枷锁。但是我仍然觉得，我们应该追求公平和正义，去掉那些不公平不客观的枷锁，戴上公平的枷锁未必就是坏事，有想法才能进步，宁在一思进，莫在一思停。在此我提出几点拙见供大家参考。
一、加强培训学习，对于体系、制度、模板进行定期且深入的培训，每隔一段时间就进行一次培训，每次培训都尽量讲解深入，多使用实例分析的方法进行，对于参会者或参与培训者进行回访调研，逐步建立完善的培训机制；
二、善用数字化发现问题进行分析，对于具体的工作量进行深入分析，而不仅仅是考核KPI，比如测试周期的长短、缺陷的多少是否和不同系统类型有关，是否和投入有关，是否和人员或者业务的专业性有关；缺陷与测试案例比例过小说明案例命中率差，分析是否和范围分析不准确有关，是否和测试人员能力有关，是否和系统复杂度有关，或者其他因素；又或者漏测内容较多，是否和案例编写者编写方式编写习惯有关，是否和编写者情绪有关，是否和需求不明确有关等等；
三、建立监督反馈改进机制，对于制定的测试规范和模板进行监督检查，除去格式检查还需要认真分析执行程度是否符合要求，可以抽查。对于不合理的模板或者不关注的点进行删改，优化模板内容，也可分不同类型需求/系统设置模板字段的裁剪表。对测试规范进行意见收集以及效果评定，对于无关项进行删除，对于相关项进行确认，优化规范、制度、模板，以及考核方式。
以上都是个人的一些想法，有实践的也有一些还处于想法阶段，欢迎大家留言交流，提供更多想法和建议。也希望大家做的工作越来越顺利，专业，使人认可。可怕的不是不做，而是随便做做，敷衍做做。共勉！！！
谢谢关注，祝您工作顺利，天天加薪！！！
