Software Test CheatSheet

单元测试

单元测试是针对代码单元的测试，通常只测试一个函数和方法调用，验证其运行结果是否符合预期，是对代码质量最快速的反馈。高覆盖率、高质量的单元测试是保障代码质量的第一道保护伞。在掌握TDD（Test-Driven Design，测试驱动开发）的前提下，单元测试更是对代码重构起到了非常关键的作用。

集成测试

虽然单独测试模块非常重要，但是测试各个模块之间交互是否正常，同样也占据了重要的地位。在微服务架构下，集成测试的目的是把一些子模块组合在一起，测试其作为子系统是否存在缺陷，检查模块之间的通信和交互是否通畅且准确，是否以预期的方式协作。

组件测试

在微服务架构中，组件实际上就代表着微服务本身，所以组件测试就是检查服务内部功能实现是否完整，内部逻辑是否正确，异常处理是否正常等。

契约测试

契约测试称之为消费者驱动的契约（Consumer-Driven Contracts，简称CDC）测试。契约测试是为了测试服务之间连接的正确性，测试服务能否符合契约预期，即是否能真正满足服务消费者的需求。

端到端测试

端到端测试是从UI层开始执行，目的是检查整个软件系统是否符合用户的预期需求。一个常规页面功能展示的背后往往涉及多个服务，所以运行端到端测试需要部署多个服务。这样的测试能够达到更广的覆盖面，但是也面临测试不稳定，定位问题难等问题。

压力测试

请求测试

# 其中－n表示请求数，－c表示并发数
$ ab -n 100 -c 10 http://test.com/

数据库测试

单元测试

在企业应用中，一个问题的完整解决方案通常包括很多的流程，这其中每个环节都需要反复迭代 优化调试，如何能够将复杂任务进行模块划分，并且保证整体流程的正确性呢?最实用的方法就是单元测试。 单元测试并不只是简单的一种测试技能，它首先是一种设计能力。并不是每份代码都可以做单元

接口测试

接口测试是测试系统组件间接口（API）的一种测试，主要用于检测内部与外部系统、内部子系统之间的交互质量，其测试重点是检查数据交换、传递的准确性，控制和交互管理过程，以及系统间相互逻辑依赖关系等。

现在的互联网应用（App）已经普遍基于前后端分离架构思路构建，即后端提供数据接口，前端调用接口返回JSon数据渲染到UI。而随着微服务的流行，后端服务模块越来越多，技术团队迫切需要一个效率更高更稳定的获取系统质量信息的方法，以便进行缺陷检测和质量监督。

之前基于UI自动化测试技术的思路和手段由于低效繁杂且容易出错已经无法满足实际需要，而面向服务的接口自动化测试体系则应运而生，成为业界最主流的质量管理手段。尤其是对高复杂性的互联网企业平台，系统越复杂庞大，接口测试自动化和持续集成的效果就越明显。业界已经有成熟的低成本、高效率的解决方案、开源工具和案例经验。当下，熟悉和掌握接口自动化测试技术也成为了一线互联网企业对中高级测试开发工程师的基本要求。

质量维度 功能正常：保持新老版本的兼容 性能正常：单次请求的响应时间跟总体的qps相关 变更检测：字段的缺失，字段的类型变更 异常和健壮性测试

质量体系 构建接口层的快速稳定的质量保证体系 构建接口监控体系

接口测试流程

在企业内部实施接口测试的实际流程如下：

接口的范围：需要覆盖多少业务和接口 接口分析：接口的协议、上下游依赖 接口测试用例设计：业务用例如何模拟和覆盖 接口测试框架选择：选择合适的框架 测试用例编写与维护：用例编写与维护更新 持续集成：不断集成测试

待测接口范围

常见的待测接口范围如下：

业务需求调研：研发和产品反馈常出问题的业务 接口文档：人工文档、Swagger自动生成的文档 代码分析：分析Spring等框架的代码 线上Log和数据：线上的生产监控和接口Log 客户端抓包：基于用户角度的接口行为分析

常见抓包分析

监听分析：TCPDUMP + WireShark + HAR提取工具 代理分析：Charles + BurpSuite 转发分析：修改Host域名+反向代理转发

测试用例设计

接口调用的流程分析 代理抓包 线上Log提取 人工用例补充：用流程图和思维导图进行业务建模 正常场景用例Right Path 异常场景用例 安全和稳定性用例

接口测试框架选择

关于如何选择接口测试框架，列举几个常见的框架特性供参考：

早期阶段：基于各种语言的HTTPClient封装 JMeter：性能测试工具，不具备完备的接口测试框架功能 RobotFramework：强大的ATDD工具，不过约束性太大 RestAssured + Swagger SoapUI [商业化]

这里推荐开源的Rest-Assured，它有如下优点：

简约的接口测试DSL 支持XML JSon的结构化解析 支持XPath JSonPath GPath等多种解析方式 对Spring的支持比较全面质量维度 功能正常：保持新老版本的兼容 性能正常：单次请求的响应时间跟总体的qps相关 变更检测：字段的缺失，字段的类型变更 异常和健壮性测试

质量体系 构建接口层的快速稳定的质量保证体系 构建接口监控体系

接口测试流程

在企业内部实施接口测试的实际流程如下：

接口的范围：需要覆盖多少业务和接口 接口分析：接口的协议、上下游依赖 接口测试用例设计：业务用例如何模拟和覆盖 接口测试框架选择：选择合适的框架 测试用例编写与维护：用例编写与维护更新 持续集成：不断集成测试

待测接口范围

常见的待测接口范围如下：

业务需求调研：研发和产品反馈常出问题的业务 接口文档：人工文档、Swagger自动生成的文档 代码分析：分析Spring等框架的代码 线上Log和数据：线上的生产监控和接口Log 客户端抓包：基于用户角度的接口行为分析

常见抓包分析

监听分析：TCPDUMP + WireShark + HAR提取工具 代理分析：Charles + BurpSuite 转发分析：修改Host域名+反向代理转发

测试用例设计

接口调用的流程分析 代理抓包 线上Log提取 人工用例补充：用流程图和思维导图进行业务建模 正常场景用例Right Path 异常场景用例 安全和稳定性用例

接口测试框架选择

关于如何选择接口测试框架，列举几个常见的框架特性供参考：

早期阶段：基于各种语言的HTTPClient封装 JMeter：性能测试工具，不具备完备的接口测试框架功能 RobotFramework：强大的ATDD工具，不过约束性太大 RestAssured + Swagger SoapUI [商业化]

这里推荐开源的Rest-Assured，它有如下优点：

简约的接口测试DSL 支持XML JSon的结构化解析 支持XPath JSonPath GPath等多种解析方式 对Spring的支持比较全面

驱动模式(Driven Pattern)

TDD

测试驱动开发的基本思想就是在开发功能代码之前，先编写测试代码。也就是说在明确要开发某个功能后，首先思考如何对这个功能进行测试，并完成测试代码的编写，然后编写相关的代码满足这些测试用例。然后循环进行添加其他功能，直到完全部功能的开发。我们这里把这个技术的应用领域从代码编写扩展到整个开发过程。应该对整个开发过程的各个阶段进行测试驱动，首先思考如何对这个阶段进行测试、验证、考核，并编写相关的测试文档，然后开始下一步工作，最后再验证相关的工作。下图是一个比较流行的测试模型：V测试模型。