第一章 Google软件测试介绍

本书核心内容：

（1）测试人员的作用

（2）google如何解决软件在扩展性、复杂性和大并发方面的问题

如果你的岗位头衔拥有测试字样，那你的任务就是怎么样让非测试人员可以更好的测试

“我并不在乎产品中是否少了一个很酷的功能， 与之相比， 我更在意产品的可靠性和稳定性”

1. 质量不等于测试

• 质量不是被测试出来的：测试通过不意味着质量没有问题， 因为前提条件是软件设计创建的思路是正确的， 此处强调最开始设计创建；
• 未经测试不可能开发出有质量的软件
• 测试是开发过程中必不可少的一部分， 当开发过程和测试一起携手联姻时， 即是质量达成之时

2. 人员角色

测试人员的存在是为了让开发人员的工作更有效率， 避免开发人员因马虎粗心而导致的返工

1. 软件开发工程师
   1. 工作重心：实现用户所使用的功能代码活提高性能代码：创建设计文档、选择最优数据结构、软件整体架构， 并进行代码实现和审核
2. 软件测试开发工程师
   1. 工作重心：为质量服务： 评估软件的可测试性和设计通用测试基础架构、质量提升和测试覆盖率的增加
3. 软件测试工程师
   1. 工作重心：用户放在第一位来思考， 代表用户的利益：分析、解释、测试运行结果，驱动测试执行、推进产品发布，是真正的产品专家、质量顾问和风险分析师
   2. 考虑用户使用场景， 是否满足性能期望， 在安全性、国际化、访问权限等方面是否满足用户要求

3. 组织结构

google的工程生产力团队（独立的测试部门）：根据不同产品的优先级、复杂度， 并与其他产品比较厚， 再分配测试人员。有时会搞错， 但总体保持实际的需求与不明确的需求之间的某种平衡

4. 爬走跑（软件版本）

google经常在最初的版本众只包含最基础的可用功能， 然后在后续的迭代中得到内部和外部用户的反馈， 每次迭代非常注重产品质量

• 金丝雀版本：需要极强的容忍度， 此版本可能无法使用应有的基本功能， 只有产品的工程师才会安装使用
• 开发版本：开发人员使用的版本
• 测试版本： 持续测试的版本， 日常工作中最稳定最信任的版本
• beta或发布版本：非常稳定的测试版本演变而来

上述各种版本的模式， 给我们的应用程序尽早地提供一个测试验证的机会

5. 测试类型（规模）

google按照小型测试、中型测试、大型测试的命名方式， 而非代码测试、集成测试、系统测试

• 小型测试：自动化实现， 验证单独函数或者独立功能模块的代码是否按照预期工作， 一般使用mock和fake
• 中型测试：涉及两个或两个以上模块的交互， 验证“功能近邻区”之间的交互， 彼此调用时的功能是否正确
• 大型测试： 涵盖三个或以上的功能模块， 使用真实用户使用场景和实际用户数据， 关注所有模块的集成， 但更倾向于结果驱动， 验证是否满足最终用户的需求

以上三者区别主要在于测试涵盖模块不同， 运行环境可能不同

最后， 自动化测试和手动测试的比例， 对于上述三种类型的测试， 当然更倾向与自动化测试， 但是某些情况下需要人类的智慧判断，例如， 用户界面是否漂亮、保留的数据是否包含隐私等， 则需要手动测试

自动化测试在每次建立之后都会重复地回归运行， 而手动测试更关注与新功能；把开bug和日常的手动工作都自动化实现：如果自动化运行失败， 系统会自动检查到最后一次代码变更的内容，这些变更极有可能是造成失败的罪魁祸首，系统会自动给代码变更的递交者发送邮件， 并开一个bug来记录这个问题（本人工作未涉及到这部分， 应试图去了解了解）