谷歌的软件测试之道读书笔记

谷歌的软件测试之道读书笔记

Google 的测试流程可以非常简练地概括为：让每个工程师都注重质量。如果我们都诚实认真地这么做，质量就一定会提高。代码质量从一开始就能更好，早期构建版本的质量会更高，集成也不是必须的，系统测试可以关注与真正面向用户的问题。所有的工程师和项目才能从堆积如山的 bug 中解脱出来。

对于 Google 软件测试之道，其实我更关注的是 Google 现在正在做的测试改进，因为书中所写的内容，已经是谷歌6-7年前的流程实践了，也许国内大部分公司的研发基础没有 Google 的完善，但通过参考 Google 自身对自己流程的改进的思考，发现这个国际领先的科技公司是怎么思考研发生产力的，并通过结合公司目前的实际，寻找一条更高效的改进之道。

我们不倡导直接步伐太大，因为很容易导致改进失败，所以了解未来趋势，迭代去改进，也许能让我们走更少的弯路。故核心我还是以《谷歌的软件测试之道》第五章为核心。

Google 的测试流程还有什么致命的缺陷？对我们的借鉴意义是什么？

第一个缺陷：测试成了开发的拐杖

或者换一个说法能更容易理解：测试变成了开发的保姆。

这个是目前国内存在的，特别突出的问题。各个公司测试最常吐槽的就是：开发自测都不自测就提交代码，导致测试过程中经常会流程阻塞，完全无法测试，无形中测试有一大部分的排期时间就这样被吃掉了，而且会造成开发和测试团队内部的严重推诿和互相指责。特别是如果测试是单独一个部门，并且不和开发坐在一起的时候，会显得更加严重。开发会认为保证质量是另外一个部门，另外一群人的责任，跟他无关，他只需要把代码快速堆砌好就可以了。

第二个缺陷：开发和测试的分离造成了基于角色的关联，阻碍了测试人员对产品的关注

在团队内部，任何角色被过分强调都是不合理的，团队的目标不是一个角色就能完成的。团队的每个成员都应该以团队的核心目标为主，我们是为了产品变得更好而努力，而不是单独做好某个流程，因为用户爱上的是产品，而不是开发产品的流程。

第三个缺陷：测试人员往往崇拜测试产物胜过软件本身

对于被测代码来讲，测试工程师生成的测试产物都是次要的：测试用例是次要的，测试计划是次要的，bug 报告是次要的。……所有测试产物的价值，在于他们对代码的影响，进而通过产品来体现。

虽然不可否认这个说法会很伤测试工程师的士气，但是这个前提是没有错的。如果太过于重视测试用例、测试计划和 bug 的报告，但不关注测试活动对代码的影响，我认为更直接的说法应该是：测试活动对代码的覆盖广度和深度，并且这种覆盖要是有效的。

最近测试正在推进的精准测试和测试参与 code review 的活动，就是为了让测试活动重点放在产品的源码上，让测试活动集中在更重要的功能代码，并且有数据可衡量。

第四个缺陷：过于强调测试职位人的测试，忽略了“谁做测试并不重要，关键是进行了测试”。

测试流程再严格，都很难避免线上用户遇到问题，所有，让更多的人，包括但不限于开发者本身、内部使用者、可信赖的测试者、众包测试者或者早期的外部用户都比测试更容易发现问题，所以，其实使用 A/B 测试的方式，指定用户进行使用，并加强跟踪，做好问题的及时响应，对于企业来讲是速度和效率更平衡的方式。

SET 的未来

• 简单地讲，SET 没有未来，它本来就是开发工程师。
• 测试特性应该由团队的新成员负责，特别是那些资历尚浅的员工。
• 测试的技能被平均地分散到各个层级的开发工程师身上，而不是集中于测试开发工程师那里。

从这一点上可以看出，SET 是技术开发在发展中必然会经历的一个阶段，它更多是弥补开发团队对测试技能和质量意识掌握不够导致的团队能力缺陷，能够给整个团队带来很好的技术补充，但是普通的测试开发往往很难将开发出来的工具和技术框架落地，并惠及到大部分的团队成员，其实核心也在于如果团队成员不具备对测试的理解技能和开发技能，但这一点在国内行业未来几年基本还得不到太大的改善，毕竟中国的开发者水平和国外的开发者水平差距还是比较大的。全栈工程师不是必要的，但全栈工程师能带给团队一些技术和意识上的补充，并在各个模块中间起到很好的技术推进和优化作用，是团队升级的引擎。SET 在我看来，有很好的成为全栈工程师的基础。

TE 的未来

• 通过互联网交付软件，意味着我们有能力选择部分用户进行发布，响应这部分用户的反馈，并迅速进行更新，降低用户对错误的感知，从而降低 bug 修复成本。
• 测试工程会转变为测试设计。
• 少量的测试设计师快速地规划处测试范围、风险热图和应用程序的漫游路线。
• 然后内部社用着、可信赖的测试者、早期用户和众包测试者提交反馈，由测试设计师来评估覆盖率，计算风险影响，确保发现的问题不断减少，并相应地对测试活动进行调整。

核心我觉得就是一句话：测试工程师会转变成像安全工程师这样的专家型角色，或者他们会变成测试活动的管理者，而那些具体的测试活动则由其他人来完成。

这个角色真的是一个非常有挑战性的工作，需要非常丰富的专业技能，并且对产品有深刻的认识，对业务价值的准确的理解力和判断力，通过对功能的分析，能够快速定义测试活动的内容和范围，并找到合适的测试资源去执行测试活动。

测试总监和经理的未来

这些人的数量将会大幅减少。会作为思想领袖，为维系松散的测试工程师和负责质量的软件工程师的关系而存在，但不会最终为某个特别的质量或管理负责。

总而言之，纯管理的测试基本不存在。

未来的测试基础设施

测试基础设施最终会整体迁移到云端。

也可以换个角度看：目前的测试框架和工具，都可以实现云端一键执行，云服务化带来的是测试活动成本的进一步降低，但对测试的技术要求会更高。也就是说，核心在于云端工具的开发和进一步维护，并且在有效的活动范围内结合必要的工具进行测试活动。

结论

我们熟知和喜爱的测试方式即将终结，随着敏捷开发、持续构建、早期用户介入、众包测试、在线软件交付的不断兴起，软件开发的问题也已经彻底改变。

也许，国内离这种改变还有几年，但是这种趋势对我们来讲，只是时间上的问题而已。这种变革，其实给了测试更大的机会，从技术和业务价值上，测试这个活动会融入到研发的流程细节中，而测试团队将更精英化，更技术化，不再是以前的人海战术，从一定层面上来讲，也将逐渐脱离看不到边的 bug 海，做到上线心里有底，研发质量不断提升的目的。而且，这个时候，人工智能和测试这个活动的结合，魅力就更加无穷了。