Google测试之道
精彩语句
书内经典语句
- 与功能相比，Googler更看重质量；
- 质量不等于测试；当你把开发过程和测试放到一起，就像在搅拌机里混合搅拌的时候，知道不能区分彼此的时候，就得到了质量；
- 如果连测试没有做，如何保证你的软件具有很高的质量呢？=>停止开发与测试的隔离，开发和测试并驾齐驱；
- 质量不等于测试，当你把开发过程和测试放到一起，得到了质量；
- 测试人员的存在是为了让开发人员的工作更有效率；
- Google不会再一次产品发布中包含大量的功能，在一个产品的基本核心功能实现后，就立刻对外发布，然后得到真实反馈后再迭代开发；
- 通过定位点击的验证方式，录制技术可以把一些功能测试转变成自动化测试；
- 自动化测试每次建立之后都重复地运行，而手动测试更趋向于新功能；
- 如果自动化用例运行失败，系统会自动检查最后一次代码变更的内容；这些变更有可能是造成失败的罪魁祸首，系统会自动发一封邮件，提交并新开一个bug来记录这个问题；
- 面对问题，将问题有所化解，找寻最佳解决方案，让每个工程师都注重质量；
角色定位
- SWE：关注客户使用功能的开发；让开发很容易地编写测试代码，从而达到独立功能模块的质量要求；SET同时是SWE在diamante库上的合作伙伴，与增加功能性代码或提高性能的代码SWE相比，SET更加关注于质量的提升和测试覆盖率的增加；SET写代码的目的是让SWE测试自己的功能；
- SET:增加功能性代码或提高性能的代码；提升质量和增加测试覆盖率；
- 为了能够尽早可以运行继承测试，针对依赖服务，SET提供了mock和fake;
- SET 针对质量文档增加一些必要内容；
- SET需要熟悉了解所负责的系统设计；
- SET早起提出好建议会反馈在文档和代码里；
- SET对项目的整体了解程序超过了技术负责人；
- TE：把用户放到第一位来思考，代表用户的利益，TE组织整体质量实践，分析解释测试运行结果，驱动测试执行，构建端到端自动化测试；
版本分类
- 金丝雀版本：每日构建
- 开发版本：日常使用的版本，每周发布一个；
- 测试版本：1个通过持续测试的版本，一个月最佳的版本；
- beta或发布版本：非常稳定的测试版本发展而来，内部使用和通过所有质量考核的一个版本；
测试类型
- 小型测试：自动化实现，验证一个单独函数或独立功能模块的代码是否按照预期工作，着重于典型的功能性问题，数据损坏，错误条件或大小差异错误；(SWE)——一般使用Mock或fake;解决问题，这些代码是否按照预期的方式运行；
- 中型测试：自动化，功能近邻区（Fake或真实）；解决问题：一些列临近的模块相交互的时候，功能模块之间的测试；
- 大型测试：三个或三个以上模块，使用真实用户使用场景和实际用户数据，一般可能会消耗整个小时或更长时间才能运行所有模块测试(SWE,SWT,TE)——这个产品操作方式是否和用户期望相同；
- 所有平台有依赖的代码，都会强制要求使用公共的底层库；
目的性
- 完整性：找出文档中残缺不全或一些需要特殊背景知识的地方；
- 正确性：语法、拼写等
- 一致性：图文和文字描述；
- 设计：文档中的一些设计需要经过深思熟虑；
- 接口与协议；
- 测试：可测性（添加一些必要的可测接口）
自动化实施
- 把容易出错的接口做隔离，针对它们创建Mock和Fake
- 构建轻量级的自动化框架，控制mock的创建和执行；
- 提交代码服务器之前可运行相应的自动化测试；
- 公开产品质量信息给相关人，使用dashboar来展示手机收集到的测试结果和测试进度；
可测性
- CL（change list）在编码结束之后会提交审查(Mondrian)会将需要审查的代码发从给具有审阅资格的SWE或SET；
- CL提交之前，会经过一系列的自动化检查（静态检查）
-
提交队列（submit queue）所有测试必须全部通过；
- 测试自动化不仅仅是自动化测试程序的编写，如果想让这些测试程序有价值，必须要考虑如何编译测试程序，执行，分析，存储的报告所有测试正确结果；
- 实际项目中如何更大发挥自动化测试的价值；
- 能加速开发过程的自动化测试才有意义，必须与开发过程真正的集成在一起；
-
代码编译，测试执行，结果分析，数据存储，报表展示的通用测试框架
- 为了验证一个功能，一般与运行环境隔离（其中精力在函数级别的独立操作）
- 小型测试：外部服务（如文件系统，网络，数据库）必须通过提供mock或fake——时间目标（每个函数）<10ms——强制时间限制 1min之后强制结束
- 中型测试：验证两个或多个模块应用之间的交互（集成测试）——时间目标（每个函数）<1s——强制时间限制 5min之后强制结束
- 大型测试：为了验证整个系统作为一个整体是如何工作的（系统测试）——时间目标（每个函数）尽可能快——强制时间限制 15min之后强制结束
- 超大型测试：——时间目标（每个函数）尽可能快——强制时间限制 60min之后强制结束
大型测试
- 在考虑外部系统的情况下应用系统是如何工作的；
- 由外部系统依赖，是非确定性的；
- 寻找错误根源相对比较困难；
- 测试数据的准备工作会非常耗时；
中型测试
- 小型<->大型之间的过渡；
- 速度适中可频繁地运行；
- 依赖外部环境；
小型测试
- 较早的发现缺陷并及时反馈
- 可靠地运行；
- 很容易地做边界场景和错误条件的测试
- 很容易隔离错误
- 有时候子系统的模拟是有难度的
- 小型测试带来的代码质量，良好的异常处理，优雅的错误报告，大中型测试会带来整体产品质量的数据验证经验；
测试运行要求
- 每个测试和其他测试之间都是独立的，使它们就能够以仁义顺序来执行；
- 测试不做任何数据持久化方面的工作；(在测试离开环境的时候，要保证测试环境的状与测试用例开始执行之前的状态是一样的)
测试解决单一资源的依赖
- 在测试执行系统中，让每个测试用例获取一个未被使用的端口，并让被测系统动态地绑定到这个端口上；
- 在测试执行之前为每个测试用例在临时目录和文件并使用独一无二的目录名；
- 在每个测试运行在自己的数据库实例之上，使用与环境隔离的目录和端口，这些都是由测试执行来控制；
SET
- SET的面试重点在考察候选人如何思考问题的解决方案，而不是解决方案本身的重现上有多么高雅；
- 关心函数的正确性及如何验证期望的行为，一个问题值得更多的关注！
- 找寻最佳的解决问题的方法，优秀的SET在面对拙劣的API定义的情况下，在测试过程中也可以把这个API定义变得更加漂亮一些；
普通的SET
- 在通过编写代码解决问题的过程中很少遇到问题，在编码时，函数重写没有麻烦，很少出现基本的语法错误；
- 在理解指针方面没有明显的错误或者没有分配不必要的内存；
- 在代码开始的地方做一些输入验证，避免由于取值到空指针等引起比较麻烦的程序崩溃；
- 理解运行时刻效率或程序代码的大O（大O表示法描述了函数在运行时刻需要消耗的时间）
- 在被指出代码有小问题时，可以修正它们；
- 写的代码干净易读，如果使用了位操作或把所有的代码都写在一行，则是一个不好的现象；
- 针对大量并行计算使用自己的简单变量来提高响应速度；
- 在被要求功能测试之前做响应的测试；
- 在被要求停止之前，不停的尝试优化解决方案，在经过去去几分钟的编码和简单测试之后，没人敢说他的代码就是完美的；
更优秀
- 在开发过程中调用这个函数，去查看在串扰（cross talk）、死锁和内存泄漏方面是否存在问题；
- 构建长时间持续运行的测试场景；例如在一个while(true)循环中调用函数，并确保它们在不间断地长时间运行过程中保持功能正常；
- 在构建测试用例、测试数据的产生方法、验证和执行上保持浓厚的兴趣；
测试工程师(TE)
在研发的早期阶段，功能还在不断变化，最终功能列表和范畴还没有确定，TE通常没有太多的工作可以做，TE进入产品，需要考虑的一些问题：
- 当前软件的薄弱点在哪里；
- 有没有安全隐患，性能，可靠性，可用性，兼容性，和其他方面的问题；
- 主要用户场景是否功能正常？对于全世界不同国家和用户都是这样的吗
- 这个产品和其他产品(软/硬)操作便利？
- 当发生问题的时候，是否容易诊断问题所在；
测试计划
- 测试接话是最早出现，最先被遗忘的测试产物；
- 作出一个不直接指导测试的计划纯粹是在浪费时间；
- 测试计划应该让我们清楚地指导需要编写哪些测试用例；
- 风险原则：如果不能全测，就先测最重要的，也就是风险最大的；
淘汰手工测试用例方针
- 总是通过的测试淘汰！在高优先级的测试来不及做的时候，低优先级的测试淘汰；
- 确保正确理解即将被淘汰的测试用例；
- 把释放出来的时间用于测试自动化，高优先级测试或探索时测试；
- 抛弃之前可能发生误报或者行为反常的自动化测试；
维护模式
- 在撤离之前，把困难的问题解决掉，而不是轻易放过；
- 一个小型的负责端到端测试的工程师，也会运行为零的成本提供长期的质量保证；
- 留下一份how-to的文档，以使得任何人都可以运行测试集；
- 确保有问题解决通道，愿意承担一些责任；
- 时刻准备着到你曾经工作的项目帮忙；
零成本测试流程
- 通过GTA进行测试计划
- 测试覆盖率
- bug评审；
- 探索式测试；
- bug提交；
- Bug 分流和调试；
- 部署新的版本并回到第一步；
如何开始参加一个新项目——用户的角度了解这个产品
- 从头到尾的理解产品（设计文档）
- 在消化设计文档之后，开始关心项目的状态特别是质量状态(bug数量，问题的分组方式，正报告的bug类型，最后时间来处理的bug,最近一些bug的类型等)
- 检查应用代码库（UT）
- 自动化测试
- 电子邮件列表的加入
（Miao注: 吾日三省吾身，Google测试之道，是质量行业的标杆和圣经，是不是回顾和回归对自己现在的工作大有帮助）
