我们说测试，一般都在说质量，因为质量，所以有了测试，正如因为有了老鼠，所以猫才格外的重要。白猫黑猫，抓住老鼠就是好猫，所以在外人看来，评价一个好测试的标准，很容易想到是能找到bug的测试就是好测试。

不过这时候，问题来了：

1、光靠测试是不是能找到所有的bug呢？

2、一个好的测试，真的只是靠自己不断地摸索去找bug就可以么？

先说一句话，测试不是完美的……

这句话应该不陌生，之前面试同学，问一道用例题，最后这位同学回答的很一般，给我撂下一句，测试不是完美的。当时我真的不知道该怎么反驳他，我只是反问他，你这句话没有问题，但是用在这里觉得合适么？

因此这句话不完整，合理不合理是要看下半句的，得看怎么接……

第一种，面试同学的接法是，由于测试不是完美的，那么测试测得差不多就行了，反正也想不全。很显然是错的……

第二种，还有一种比较普遍的接法，由于测试不是完美的，所以我们要追求完美。这句话对么？力求完美就可能会和商业目标冲突，再完美的质量，如果影响了发布节奏，就仿佛一坛美酒，无人问津，只能孤芳自赏。所以我个人认为也不好。

第三种，我建议的接法是，由于测试不是完美的，所以单靠测试是不够的，我们要一起来保证质量。就是说，项目中的每个人都有责任为质量负责。

上面的两个问题，不是测试追求极致就可以"完全"搞得定的，例如客户端类产品的环境问题，重现率较低的问题，跨松散耦合模块影响的问题，时间紧张情况下、回归不足的问题……

那么， 我今天想说的并不是如何找bug，所以所有和找bug相关的方法、流程，规范，我都不想在这里说。

质量保证，既在于测，又在于防。如果说测是测试的职责，那么防则是所有人的责任。

想要防，如何防，核心原则是推进项目中的所有人都有质量意识，在每个软件测试的书里，其实都会有一行不起眼的文字，就是测试要去推动上游环节重视质量。

可是大家在实际工作中却很容易忽略这点，我遇到的情况，无非是两个极端：

1）一个极端是，无所谓的态度，闭上眼睛干就是了。有什么问题我不管，不是我责任就行。

2）另一个极端则是，恨铁不成钢的态度，以暴制暴。你有问题会影响质量，我就说你。

这两种方法带来的弊端显而易见，其实第二种好歹还是比第一种好，不管怎么说，第二种还是愿意去解决问题的，只是方法问题。相比第一种事不关己高高挂起的态度，是一种不负责任的态度。

第一种极端下，本来应该其他方保证的质量，被容忍后，造成整个项目团队对测试产生依赖，整体来看，存在内耗，时间周期必然会加长。并且随着质量意识逐渐淡薄，不仅会有进度问题，还会有更多的质量问题不能被保证。

第二种极端下，偶尔还是有可能会有一些效果，例如确实吓到了对方，对方有所改变，有所收敛。但是并不一定所有人都会买这个账，并且经常发飙产生的副作用，有时往往杀敌一千，自损八百。并且用多了可能会面临不灵的问题。

所以我心目中的测试，分三等。

第一等，是能够推动相关项目人员，拥有质量意识，并且愿意为质量改进作出一些事情的测试改进者。

第二等，是能够把项目相关问题发现并反馈给相关配合方的测试监督评估者。

第三等，是能够不管在任何情况下都只是把活儿干完的测试执行者。

开发和产品天然是不会重视质量的，产品会关注KPI，关注用户，关注需求，关注进度。开发则会关注实现，关注技术。这个光去怪他们是没有用的。此所谓闻道有先后，术业有专攻，我不是测试，让我去保证质量本身这件事情，就是一件不容易的事情。就像测试不是UED，让测试在测试过程中对产品合理性做个评价，也是很难。例如我们要说服产品发动内测，说服产品少做需求变更……说服开发做实现讲解，说服开发自己对自己模块做测试……

但不容易不代表不可能。例如我们的浏览器团队，开发就做了一些单元测试，包括为测试去写一些自动化接口。也就是说，只要我们不懈努力，还是有可能做的到的，毕竟我们的配合团队不是打心眼里不愿意做，而我认为更多的是我们的说服力匮乏，没有能力把质量意识贯彻给别人。茶壶里煮饺子，干憋气倒不出来，结果项目团队和测试团队对于质量的理解和认识不一致造成了各种各样的问题。

意识不可能一蹴而就，更不可能天生具备。就像共产主义思想进入中国，需要宣传，让别人了解你的想法，你的诉求，你的观点。需要反复不断地培养，让培养成的人，成为老师，进一步培养传递给更多的人。

因此，质量意识不是一开始就在项目中、在每个人的意识里就天然存在，需要我们测试去贯彻。

入行时写过一篇文章，测试不是一项纯技术岗位，需要好多非技术技能，例如需要沟通，就不只是说明白，还需要技巧，需要情商……，因为有很多问题，需要沟通来解决。而不是靠测来解决，全靠测，累的半死，效果也未必好。自己做事固然重要，有的时候需要我们改变别人，也是一种能力。

原文链接

如需转载该篇文章，请注明来自“搜狗测试”