本书核心内容：
（1）测试人员的作用
（2）google如何解决软件在扩展性、复杂性和大并发方面的问题
如果你的岗位头衔拥有测试字样，那你的任务就是怎么样让非测试人员可以更好的测试
“我并不在乎产品中是否少了一个很酷的功能， 与之相比， 我更在意产品的可靠性和稳定性”
1. 质量不等于测试
- 质量不是被测试出来的：测试通过不意味着质量没有问题， 因为前提条件是软件设计创建的思路是正确的， 此处强调最开始设计创建；
- 未经测试不可能开发出有质量的软件
- 测试是开发过程中必不可少的一部分， 当开发过程和测试一起携手联姻时， 即是质量达成之时
2. 人员角色
测试人员的存在是为了让开发人员的工作更有效率， 避免开发人员因马虎粗心而导致的返工
- 软件开发工程师
- 工作重心：实现用户所使用的功能代码活提高性能代码：创建设计文档、选择最优数据结构、软件整体架构， 并进行代码实现和审核
- 软件测试开发工程师
- 工作重心：为质量服务： 评估软件的可测试性和设计通用测试基础架构、质量提升和测试覆盖率的增加
- 软件测试工程师
- 工作重心：用户放在第一位来思考， 代表用户的利益：分析、解释、测试运行结果，驱动测试执行、推进产品发布，是真正的产品专家、质量顾问和风险分析师
- 考虑用户使用场景， 是否满足性能期望， 在安全性、国际化、访问权限等方面是否满足用户要求
3. 组织结构
google的工程生产力团队（独立的测试部门）：根据不同产品的优先级、复杂度， 并与其他产品比较厚， 再分配测试人员。有时会搞错， 但总体保持实际的需求与不明确的需求之间的某种平衡
4. 爬走跑（软件版本）
google经常在最初的版本众只包含最基础的可用功能， 然后在后续的迭代中得到内部和外部用户的反馈， 每次迭代非常注重产品质量
- 金丝雀版本：需要极强的容忍度， 此版本可能无法使用应有的基本功能， 只有产品的工程师才会安装使用
- 开发版本：开发人员使用的版本
- 测试版本： 持续测试的版本， 日常工作中最稳定最信任的版本
- beta或发布版本：非常稳定的测试版本演变而来
上述各种版本的模式， 给我们的应用程序尽早地提供一个测试验证的机会
5. 测试类型（规模）
google按照小型测试、中型测试、大型测试的命名方式， 而非代码测试、集成测试、系统测试
- 小型测试：自动化实现， 验证单独函数或者独立功能模块的代码是否按照预期工作， 一般使用mock和fake
- 中型测试：涉及两个或两个以上模块的交互， 验证“功能近邻区”之间的交互， 彼此调用时的功能是否正确
- 大型测试： 涵盖三个或以上的功能模块， 使用真实用户使用场景和实际用户数据， 关注所有模块的集成， 但更倾向于结果驱动， 验证是否满足最终用户的需求
以上三者区别主要在于测试涵盖模块不同， 运行环境可能不同
最后， 自动化测试和手动测试的比例， 对于上述三种类型的测试， 当然更倾向与自动化测试， 但是某些情况下需要人类的智慧判断，例如， 用户界面是否漂亮、保留的数据是否包含隐私等， 则需要手动测试
自动化测试在每次建立之后都会重复地回归运行， 而手动测试更关注与新功能；把开bug和日常的手动工作都自动化实现：如果自动化运行失败， 系统会自动检查到最后一次代码变更的内容，这些变更极有可能是造成失败的罪魁祸首，系统会自动给代码变更的递交者发送邮件， 并开一个bug来记录这个问题（本人工作未涉及到这部分， 应试图去了解了解）