《Google软件测试之道》——笔记（二）

        测试是什么？这个定义很难，但是测试不是“教条式的、强流程的、体力密集型的、耗时的”，测试不应该成为导致创新和开发过程变慢的阻碍。

        Google成功的关键是什么？书中给出的建议是：不要招聘太多的测试。笔者所在的公司测试部门负责公司十几条不同产品线，每个产品线带有不同的项目分支，频繁的新需求、新适配对于笔者而言，测试工作常常是枯燥且重复的。而随着测试人员的增加，我们发现软件质量提升缓慢，测试工作效率没有明显上升，我们正在做事倍功半的测试。

Google测试方式看起来是违背常理的——在整个公司，我们只有非常少的专职测试人员，甚至比我们竞争对手公司的单个产品的测试人员还要少。在通往成功的道路上，Google的测试团队并非雄兵百万，我们更像是小而精的特种部队。

在Google，写代码的开发人员也承担了质量的责任，质量从来就不仅仅是一些测试人员的问题，在Google，每个写代码的开发者本身就是测试者。

        质量不等于测试。

        质量不是被测试出来的，这句话已经是老生常谈。如果最开始设计就是错误的，那么它永远不会因为测试而变成正确的。

当你把开发过程和测试放到一起，就像在搅拌机里混合搅拌那样，直到不能区分彼此的时候，你就得到了质量。

        Google能用很少的专职测试人员的原因就是提升开发对质量的负责，如果一个产品出现了问题，第一个跳出来的是开发人员而不是遗漏这个缺陷的测试人员。测试是是一种预防行为而不是检测。在Google，测试工程师（TE）会把大量的时间花在模拟用户使用场景与自动化脚本编写上，TE是真正的产品专家。软件开发工程师（SWE）负责功能实现与独立模块的质量，而另一个角色，软件测试开发工程师（SET）则是负责编写代码提供给SWE用来更好的测试自己的功能模块，TE需要确认开发人员的测试工作是否到位，任何明显的bug都表明开发人员对于质量的马虎，当明显的bug逐渐收敛，TE就将精力放到用户使用场景中去，去关注安全性、访问速度等性能上。