读程序员的README笔记06_测试（上）

1. 行为准则

2. 编写、运行和修复测试用例会让人感觉很忙碌

2.1. 测试本身才更容易成为繁忙的工作

2.2. 糟糕的测试会增加开发人员的开销而不提供价值，并且还会增加测试套件的不稳定性

3. 测试用途

3.1. 测试可以检查代码是否正常工作

3.1.1. 测试本身就可以验证软件的行为是否符合预期

3.1.2. 预料之外的软件行为会给用户、开发人员和运维人员带来很多困扰

3.1.3. 测试这道工序可以证明代码已经按规定生效了

3.2. 保护代码不会被将来那些无意中的修改所影响

3.2.1. 测试可以保护现有的行为不受新变化的影响

3.3. 鼓励清爽的代码

3.4. 强迫开发者试用他们自己的API

3.4.1. 编写测试也迫使开发人员思考他们程序的接口和实现过程

3.4.2. 编写测试也可以迫使开发人员分别通过改进关注点分离和降低紧耦合的方式来确保他们的代码拥有良好的构造

3.5. 记录组件之间如何交互

3.5.1. 测试其实是另一种形式的文档，它说明了代码是如何被交互的

3.6. 作为一个实验的“游乐场”

3.7. 测试驱动的开发

3.7.1. test driven development，TDD

3.7.2. TDD是指在写代码之前先编写测试的实践，如果测试写好之后运行测试失败了，那么就去编写代码使其通过

4. 测试类型

4.1. 成功的项目会在现实世界中做出务实的测试决定

4.2. 单元测试

4.2.1. 验证代码的“单元”

4.2.2. 通常指某个单一的方法或行为

4.2.3. 单元测试应该快速、简短且集中

4.2.3.1. 消除外部依赖性可以使单元测试快速而集中

4.2.4. 模拟远程系统允许测试绕过网络调用，可简化设置，并且避免缓慢的运行过程

4.2.5. 模拟方法和对象允许开发人员编写集中的单元测试，这些单元测试可以只完成一个特定的行为动作

4.3. 集成测试

4.3.1. 验证多个组件集成在一起之后是否还能正常工作

4.3.2. 如果你发现自己在测试中实例化了多个相互作用的对象，那么你正在写的可能就是集成测试

4.3.3. 开发人员运行集成测试的频率较低，所以反馈的周期更长

4.3.4. 可以找出那些通过各自独立的单元测试难以发现的问题

4.4. 系统测试

4.4.1. 验证整个系统的整体运行情况

4.4.2. 端到端(end-to-end，e2e)的工作流程是为了模拟在预生产环境中系统与真实用户的互动

4.5. 性能测试

4.5.1. 监控不同配置下的系统性能

4.5.2. 负载测试可以监控不同负载水平下的性能

4.5.3. 压力测试将系统负载推高到崩溃的程度

4.5.3.1. 压力测试可暴露系统的负载能力究竟有多大，以及在过度负载下会发生什么状况

4.5.4. 对于容量规划和服务等级目标定义非常有用

4.6. 验收测试

4.6.1. 指由客户或其代理人进行的，以验证交付的软件是否符合验收标准的测试

4.6.2. 正式的验收测试及验收标准是作为昂贵的合同中的一部分来规定的

4.6.3. 国际标准化组织(International Standards Organization，ISO)要求验收测试可以验证明确的业务需求，作为其安全标准的一部分

4.6.3.1. ISO认证审核委员会要求提供需求和相应的测试文件证据

5. 测试工具

5.1. 测试用例的编写工具

5.1.1. 如模拟库，可以帮助你编写干净和高效的测试

5.1.2. 模拟库通常用于单元测试，特别是在面向对象的代码中

5.1.3. 模拟库还可以防止应用程序的代码中充斥着测试专用的方法、参数或变量

5.1.4. 模拟库可以帮助开发人员访问受保护的方法和变量，而无须修改常规代码

5.1.5. 对模拟库的过度依赖是一种代码异味，它表明代码紧紧地耦合在了一起

5.2. 测试框架

5.2.1. 通过模拟测试的生命周期，从setup到teardown，帮助测试的运行

5.2.1.1. 管理测试的setup和teardown

5.2.1.2. 管理测试执行和编排

5.2.1.2.1. 可以通过编排测试流程来帮助控制测试的速度和隔离度

5.2.1.2.2. 串行测试是一个接一个地执行，一次执行一个测试会更安全，因为测试之间相互影响的机会比较少

5.2.1.2.3. 并行执行更快捷，但由于共享的状态、资源或其他污染，因而更容易出错

5.2.1.3. 生成测试结果报告

5.2.1.3.1. 帮助开发人员调试那些失败的构建任务

5.2.1.4. 提供工具，如扩展的断言方法

5.2.1.5. 与代码覆盖率工具集成

5.2.2. 还可以保存测试结果，与构建系统集成，并提供其他的辅助功能

5.3. 代码质量工具

5.3.1. 强制执行代码质量规则的工具被称为linter，linter可以运行静态分析并执行代码风格检查

5.3.2. 对那些未能通过质量检查的代码库要有务实精神

5.3.3. 不要让代码变得更糟，但也要避免以破坏性地停止一切的方式来清理工程

5.3.4. 用来分析代码覆盖率和代码复杂性

5.3.4.1. 代码复杂度工具可以通过计算圈复杂度

5.3.4.1.1. 大致上通过代码的路径数量来防范过于复杂的逻辑

5.3.4.1.2. 你的代码复杂度越高，就越难测试，也越有可能包含更多的bug

5.3.4.1.3. 圈复杂度通常随着代码库的大小而增加，所以总体得分高并不一定是坏事

5.3.4.2. 代码覆盖率工具衡量的是有多少行代码被测试套件执行过

5.3.4.2.1. 如果你修改的代码降低了代码覆盖率，你应该编写更多的测试用例

5.3.4.2.2. 确保测试用例可以对你所做的任何新的修改进行验证，以合理的覆盖率为目标

5.3.4.2.2.1. 经验值是65%到85%

5.3.4.2.3. 仅仅依靠覆盖率并不能够衡量测试质量的优劣

5.3.4.2.3.1. 它可能会有很大的误导性，无论是在高覆盖率还是低覆盖率的时候

5.3.4.2.3.2. 为了达到100%的覆盖率而痴迷于创建单元测试并不能保证你的代码能够安全地集成

5.3.5. 通过静态分析来寻找bug

5.3.6. 检查代码风格错误

5.3.6.1. 代码风格检查工具可以确保所有源代码的格式相同

5.3.6.2. 每行最大字符数、驼峰命名法与蛇形命名法、适当的缩进

5.3.6.3. 一致的风格有助于多名程序员在一个共享代码库上进行协作

5.3.6.4. 强烈建议你设置你的IDE，以便可以自动应用所有的风格规则

5.3.7. 通常被设置为构建或编译步骤的一部分来运行