第一章
我发现谷歌对于测试的定位与我们目前测试的定位是不同的，谷歌比较看重开发自测，而所谓测试者，就是帮助开发更好、更快地进行测试。
他们也有测试开发和测试，不过他们对于测试开发而言，就是更偏向于开发，跟开发紧密结合，通过代码评审，编写自动化测试，单元测试等手段进行测试。
而测试工程师是处于用户的角度上，模拟用户的使用场景，进行自动化测试。
他们的测试人员并没有绑定在产品上，而是十分流动的，此举在书中写明是使测试保持新鲜感且总是很忙碌，另外还能保证一个好的测试想法可以快速在公司内部蔓延。
从文章中能看出来，谷歌尽量在推行自动化测试，甚至自动化用例运行失败还会自动检测最后一次代码变更的内容。
第二章-软件测试开发工程师
这里所提到的“百分之二十时间”计划倒是蛮有趣的，四天工作，一天自我拓展的形式，可以鼓励人去进行技术上的探索。
另外谷歌十分注重分享，分享可以帮助团队新人快速成长。
谷歌十分注重环境的一致性，他们希望在线上发现的BUG，也能在测试环境和开发环境复现出来，这样能方便更好地排查问题和发现问题。
在与Ted Mao的访谈中，可以了解到，他并没有停止在一个区域，而是进行不断地探索。而他觉得遇到的难题是，工具变得越来越强大且复杂，但这样理解和使用这些工具也会变得越来越困难。
第三章-测试工程师
TE的重点在于评估对用户的影响以及软件产品整体目标上的风险。
谷歌对于测试工程师的定义，是一个很广泛的开发者，对技术能力、领导力、深刻理解产品的能力等多方面都有要求。他们经常将TE的工作描述为“从中间开始”，因为需要TE快速融入一个产品团队的文化和现状。
理想情况下，测试计划应当在项目执行中发挥核心作用，应当在软件的整个生命周期中持续有效。
对于风险，有风险发生频率（罕见、少见、偶尔、常见）和风险影响（最小、一些、较大、最大），通过这两个维度进行风险分析。
风险是关于选择的，知道一个特性比另一个特性的风险更大，可以帮助测试经理更好地分配测试人员到各个特性上。
因为围绕一个bug的跟踪和流程占据了很多工程师一大块时间，我们投入了大量工作来进行流程的自动化。这一点目前我司也有在做流程上的自动化和简化，但我认为仍然要注意流程的必要性。
测试人员发现bug，花些时间细细品味。这一点很重要，这也是我司常说的拓展，发散性思维，联想。
理想的免费测试：成本几乎为零、瞬间可得的测试结果、极少或者无需人工干预、非常灵活。
在访谈中，表明Google的TE和SET更技术化，而且有大量的自动化，绝大多数的自动化测试在手工测试人员拿到产品之前就执行完毕了，这也导致到手工测试这一步，代码质量已经相当高了。
探索性测试的模式：money tour、landmark tour、neighborhood tour、一有机会就输入最不可能的输入、重复同一动作、只给最小输入、接受一切默认值
一定要记住自动化并不能解决所有问题，你总会需要聪明的、探索式的测试并跟踪测试数据。
第五章-Google软件测试改进
Google流程中的致命缺陷：
1、测试成为了开发的拐杖。我们越不让开发考虑测试的问题，把测试变得越简单，开发就越来越不会去做测试。
2、测试人员更关注自己的角色，而不是他们的产品。
每一个工程师的角色都是为总体产品服务的，而角色本身是次要的。健康组织的一个标志是，人们会说"我在为Chrome工作"，而不是"我是测试"。
3、测试人员往往崇拜测试产物，胜过软件本身。测试的价值在于测试的动作，而不是测试产物。
4、产品在经过最严格的测试发布以后，用户仍有可能发现测试中遗漏的问题。
SET本质就是开发工程师，这个角色正在逐步淡化。
对优秀TE的需求之大前所未有，然而，我们认为这种需求即将达到顶峰并会迅速下降。我们相信，测试工程会转型成测试设计。测试工程师会转变成像安全工程师这样的专家型角色，或者他们会变成测试活动的管理者。
这些对于TE和SET的看法，我个人觉得目前不太适用于国内的测试行业，目前的国内测试行业，测试工程师的需求量还是极大的，国内SET还是很少有那么纯正的SET，而专家型角色虽然一直存在，但底层的测试工程师们目前最需要的是广度，而非深度，这两种已经有比较明显的区别了。
第四章因为偏管理所以被我跳过了。
|