读《Google软件测试之道》的几点思考

作为一个在世界500强工作过17年的人，读《Google软件测试之道》的时候感受颇多。

首先我想和大家一起思考几个问题

 1. 产品质量重要吗strong>

 答案是只有在软件产品变得重要的时候质量才显得重要！

 说实话保证质量是需要大量投入的，高投入，肯定是需要高回 的，

 咱们不要道德绑架，人人都要吃饭的，企业是要盈利的，如果产品本身不足够有价值，

 肯定是不值得投入过多的人力财力去保证高质量的。

2. 质量是测试出来的吗strong>

 答案是质量不等于测试

 质量不是测试出来的，

 质量是开发过程的问题，

 测试和开发浑然一体就是质量达成之时，

 质量也是效率的一部分。

3. 谷歌的工程师的三种角色职责如何strong>

 答案是三种角色职责各有重点，但也重叠

  ??

 4. 测试开发比多少才合理strong>

答案是事实上质量和开发测试比没有多大关系，讨论这个毫无意义。

质量应该是开发和测试共同保证的，彼此是合作共赢的关系，有着相同的目标。

不同产品，不同公司的流程导致比例各异，大家都在寻找符合自己公司产品的最佳模式。

随着测试方法和手段的智能化，多样化，开发和测试都是具有技术能力的工程师，只是测试站在用户的利益去考虑问题，而开发着重产品的实现。测试是需要更强的沟通能力，因为需要和所有相关人员进行交流。

就像我前面提到的google工程师有三个角色，SWE 开发工程师，SET 开发测试工程师，TE 测试工程师，也称为用户工程师，彼此重叠的工作很多。

SWE着重产品的实现，完成产品需求，负责小型测试，中型测试，类似单元测试

SET着重服务与SWE，保证产品可测试，提供测试工具，测试方案，也帮忙写小型测试，中型测试

TE着重负责端对端端的大型测试，测试评审，完成用户需求验收。

 5. 测试人员是不是越早参与到产品中去越好strong>

答案是否定的，早期如果产品变化频繁，测试人员过早参与是一种严重的资源浪费。

2007年，我们公司曾经验证TDD，也开发了适用于测试先行的工具，我也幸体验了这一劫难，

在开发写代码之前，我就根据需求文档和UI mock 文档，写完了测试脚本，

随着开发代码逐步的交付，脚本也跟着逐步执行，验证，

这个过程中需求文档改了3词，开发的实现改动了8次，毋容置疑，脚本也都要随之改动。

此尝试，以失败告终！

如果产品是不变的，测试先行当然是好的，可是这个世界上有需求不变，实现不变这种理想状态发生吗可能！

 6. 自动化测试比例是不是越高越好strong>

答案这个不是绝对的。

有些逻辑过于复杂的产品，大型测试里面，也就是端对端的测试，自动化测试性就不便投入过多。执行次数越多，产品逻辑越简单的，自动化测试投入越大越好

google 小型测试自动化70%，中性测试自动化20%，大型测试自动化10%