一

 

《Google 软件测试之道》这本书我已经读完好几天了，并且是读的第三遍了，本来一直想写下读后感，但是一直迟迟不敢下笔。

 

一个原因是这本书里面的信息太多，可以说 Google 这个测试模式已经是超越了国内大多数公司好几个层级，很多公司完全可以把这个模式作为模版来学习。

 

另一个原因是，国内环境的现状，决定了我们肯定不会很快达到这个高度，看见摸不见，那感觉真是贼难受。

 

今天下笔，也仅仅是从自己角度出发，进行浅层次的解读，希望有更多的人一起加入探讨。

 

二

 

本书在一开篇的定位，就打破了「测试」的局限，Google 最开始的测试团队叫「测试服务」，之后演进为「工程生产力」团队，别看仅仅是名称的变化，不同的名称所代表的职责范围和目标却是完全的不同。

 

国内公司目前大部分团队的称呼还是「测试」，和 Google 的「测试服务」有些类似，工作重点都是表示层的验证，并且随时响应不同项目的测试（验证）需求。

 

还有一部分团队的称呼是「QA」，相对与「测试」，「QA」的职责会更宽泛一些，可以涵盖流程质量、测试质量和发布质量，以及各环节中所有可以更好保证质量的事，都可以由「QA」来推进。

 

「工程生产力」是相对「QA」更进一步的职责扩展了，就是除了测试和质量之外，还会跟进生产力提升，比如帮助开发更好的完成测试和质量保证工作，就是把测试和质量保证前置，转移给开发，测试人员给开发提供必要的支持。

 

听起来是不是很给力？但是要达到这个程度，测试人员就需要兼具开发的技能和测试的思维，需要会编程、能实现工具、平台和测试自动化。

 

每个新的机遇总是伴随着更大的挑战。

 

三

 

针对本书的阅读人群，我的建议是：

1.开发人员：质量不是某一个角色的事，是整个团队的事，可以了解作为开发角色应该如何更好的为保证质量做贡献。

2.有一定经验的测试开发人员：通过第二章关于 SET 工作的说明，可以对比下自己目前的工作内容，更好的明确自己的目标，更好的为保证质量做贡献。

3.有一定经验的测试人员：通过第三章关于 TE 工作的说明，可以对比下自己目前的工作内容，更好的明确自己的目标，更好的为保证质量做贡献。

 

不太建议初学者关注，原因最开始我已经讲了，对目前国内环境来说，这本书的内容更多的只是作为我们的愿景和目标，初学者往往会把这个作为现实去比照，然后就会大失所望。

 

另外，针对各章节的阅读方法，我的建议是：

1.精读：第 1、2、3、5 章，这几个章节分别介绍了 Google 测试的现在和未来，个人觉得非常有借鉴意义，可以尝试把部分内容逐步在一些发展比较好的团队中进行推进。

2.粗读：第 4 章以及附录 C，第四章是访谈，更真实的反映了 Google 真实的项目情况，所以看的时候需要做个提取，吸取自己关注的内容即可，附录 C 里面提供了几个工具，个人觉得挺有用，可以看看目前团队里面是否可借鉴。

3.略读：附录 A、B、D，略读是指不适合大部分人去读，同时这部分内容也不是本书的重点，如果有对这部分特别感兴趣的，可以按需调整即可。

 

最后，我再叨叨一句，看书最重要的是效果。