《Google软件测试之道》心得笔记

• Google软件测试介绍

1. 把开发和测试融合在一起——开发和测试必须同时展开
2. 开发人员自己要对自己写的代码负责，比专职的测试人员更适合做测试工作。
3. 测试开发工程师SET
4. 对于Google拥有很少量的测试人员的情况下，还可以取得不错的成果，核心原因在于Google从来不会再一次产品发布中包含大量的功能，实际上，做法恰恰相反，在一个产品的基本核心功能实现之后，就立即对外发布使用，然后从用户那里得到真实的反馈。

• 软件测试开发工程师（SET）

• Google的四大主要开发语言：C++、Java、Python、Js
• 一个产品如果在概念上还没有完全确定成型时就去关心质量，这就是优先级混乱的表现。许多来源于Google百分之二十努力的产品原型，在其以后的dogfood或beta版本发布时，还要经历重新设计，原始代码保留的概率几乎为零。很明显，在试验初期阶段强调测试是一件非常愚蠢的事情。
• 项目的技术负责人和发起人要做的第一件事就是设计文档。最早期的项目设计文档，主要包括项目的目标、背景、团队成员、系统设计。这是一个动态的文档，随着项目的演化也在不断地保持更新。
• 单元测试、代码级别测试、白盒测试、集成测试、系统测试、端到端测试
• UI界面的自动化测试——来模拟用户操作，像“单击向后按钮……回到之前页面……”
• 模糊测试：发送随机的输入数据给被测应用系统
• 小型测试：小型测试是所有测试类型里范畴最小的，一般集中精力在函数级别的独立操作与调用上。对于小型测试的执行频率更加频繁，并且很快就会发现问题，并且要减少依赖。
• 中型测试：中型测试是验证两个或多个模块应用之间的交互，和小型测试相比，中型测试有着更大的范畴且运行所需要的时间也更久。在Google之外，中型测试经常被称为“集成测试”。对于中型测试，鼓励使用模拟技术（mock）来解决外部服务的依赖问题。
• 大型测试：在Google之外通常被称为“系统测试”或“端到端测试”，大型测试在一个较高的层次上运行，验证系统作为一个整体是如何工作的。这涉及应用系统的一个或所有子系统，从前端界面到后端数据储存。
• 大型测试优缺点：

1. 测试最根本最重要的：在考虑外部系统的情况下应用系统是如何工作的；
2. 由于对外部系统有依赖，因此它们是非确定性的；
3. 很宽的测试范畴意味着如果测试运行失败，寻找精准失败根源就会比较困难；
4. 测试数据的准备工作会非常耗时；
5. 大型测试是较高层次的操作，如果想要走到特定的代码路径区域是不切实际的，而是一部分却是小型测试的专长。

• 中型测试的优缺点：

1. 由于不需要使用mock技术，且不受运行时刻的限制，因此该测试是从大型测试到小型测试之间的一个过渡；
2. 因为它们运行速度相对较快，所以可以频繁地运行它们；
3. 它们可以在标准的开发环境中运行，因此开发人员也可以很容易运行它们；
4. 它们依赖外部系统；由于对外部系统有依赖，因此它们本身就有不确定性；
5. 它们的运行速度没有小型测试快

• 小型测试的优缺点：

1. 为了更容易地被测试到，代码赢清晰干净、函数规模较小且重点集中。为了方便模拟，系统之间的接口需要有良好的定义；
2. 由于它们可以很快运行完毕，因此在有代码变更发生的时候就可以立刻运行，从而可以较早地发现缺陷并提供及时的反馈；
3. 在所有的环境下它们都可以可靠地运行；
4. 它们有较小的测试范畴，这样可以很容易地边做场景与错误条件的测试，例如一个空指针；
5. 它们有特定的范畴，可以很容易地隔离错误；
6. 不要做模块之间的集成测试，这是其他类型的测试要做的事情（中型测试）；
7. 有时候对子系统的模拟是有难度的；
8. 使用mock或fake环境，可以不与真实的环境同步。

• 关于测试类别的总结：

小型测试是为了验证一个代码单元的功能；中型测试验证两个或多个横块之间的交互；大型测试是为了验证整个系统作为一个整体是如何工作的。小型测试带来优秀的代码质量、良好的异常处理、优雅的错误报告；大中型测试带来整体产品质量和数据验证。对于测试的占比，总体上有一个经验法则：即70/20/10原则：70%的小型测试，20%的中型测试，10%的大型测试。

• 测试运行要求：

1. 每个测试和其他测试之间都是独立的，使它们就能够以任意顺序来执行；
2. 测试不做任何数据持久化方面的工作，在这些测试用例离开测试环境的时候，要保证测试环境的状态与测试用例开始执行之前的状态是一样的；
3. 在测试执行系统中，让每个测试用例获取一个未使用的端口，并让被测系统动态地绑定到这个端口上留在测试执行之前，为每一个测试用例在临时目录下创建目录和文件，并使用独一无二的目录名；
4. 每个测试运行在自己的数据库实例之上，使用与环境隔离的目录和端口。

• 依赖于自动化测试去验证产品功能。
• 如何优化每次代码变更后触发的测试执行次数。
• Google寻找SET期望：对测试有强烈兴趣和天资的开发人员。一个通用且有效的招募优秀SET的方法是：给候选者和其他开发角色一样的编程问题，并考察他们在处理质量问题与测试方面的方法。
• 注意垃圾收集、类型安全、编译和运行时刻的不同关注点。
• 普通的候选人可以做到：

1. 在通过编写代码解决问题的过程中很少遇到问题。在编码时，函数重写没有麻烦，很少出现基本语法错误，也不会混淆不同语言的语法和关键词；
2. 在理解指针方面没有明显的错误，或者没有分配不必要的内存；
3. 在代码开始的地方做一些输入验证，避免由于取值到空指针等引起比较麻烦的程序崩溃；
4. 理解运行时刻效率或陈旭代码的所消耗的时间；
5. 在被指出代码中有小问题时，可以修正；
6. 写的代码干净易读；
7. 在输入为一个A或null的时候，走查代码确保能正常工作；
8. 会比较有条理地或体系化地提供特定的字符串而不是随机的字符串；
9. 专注于产生有意义的测试数据，考虑如何去运行大型测试和使用真实环境的数据做测试。

• 更优秀的候选人：

1. 考虑使用64位整型int64作为计数器变量和返回值，为了以后的兼容性和避免用户使用非常长的字符串而导致溢出；
2. 在代码注释中对条件假设和常量做解释说明；
3. 在有很多不同的数据输入时可以走查代码，修复所发现的错误；
4. 在被要求停止之前，不停地尝试优化解决方案；
5. 在并发线程中调用这个函数，去查看在串扰、死锁和内存泄漏方面是否存在问题；
6. 构建长时间持续运行的测试场景；
7. 在构建测试用例、测试数据的产生方法、验证和执行上保持浓厚的兴趣。

• 软件测试工程师（TE）

• Google的关于TE职责的一般性描述：

1. 测试计划和风险分析；
2. 评审需求、设计、代码和测试；
3. 探索式测试；用户场景；
4. 编写测试用例；
5. 执行测试用例；
6. 众包（大众一块进行测试）；
7. 使用统计、用户反馈。

• 期望的测试计划具有的一些特性：

1. 及时地更新；
2. 描述了软件的目标和卖点；
3. 描述了软件的结构、各种组件和功能特性对的名称；
4. 描述了软件的功能和操作简介；
5. 应该描述必测点；
6. 应该能在测试中提供有用的信息，从而帮助确定进展以及覆盖率上的不足。

• 风险：影响风险的因素很多，试图精确地、定量地计算风险比环节风险还要麻烦。在Google，我们确定了两个要素：失败频率和影响。风险是一个定性的相对值。
• 风险缓解：

1. 我们可以围绕风险大的能力点编写用户故事，并从中确定低风险的使用场景，然后反馈到开发团队，请他们有针对性地增加约束；
2. 可以编写回归测试用例，以确保问题在重现时可以被捕捉到；
3. 可以编写和运行引发故障的测试用例，来推动开发实现恢复和回滚的特性；
4. 可以插入监听代码，以便更早地检测到故障；
5. 可以插入代码监听软件，发现新旧版本间的行为变化以发现回归问题。

• 需要按照风险顺序进行测试。颜色标识
• 测试计划这个任务的时间是以小时到天为单位来计算的。
• 一个孤立的数字意义很小。