1. 自动化测试

1.1. 单元测试

代码检查、编译和单元测试（Unit Test）。这一步还属于代码层面的行为活动，代码库特定分支上的变动，触发这一行为，只有在这样的执行成功以后，后面的步骤才能得到机会运行。单元测试通常都是是 dev 写的，即便是在有独立的测试团队的环境中。因为单元测试重要的一个因素就是要保证它能够做到白盒覆盖。单元测试要求易于执行，由于需要反复执行和根据结果修改代码，快速的反馈是非常重要的，几十秒内必须得到结果。我见过有一些团队的单元测试跑一遍要十分钟以上，那么这种情况就要保证能够跑增量的测试，换言之，改动了什么内容，能够重跑改动的那一部分，而不是所有的测试集合。

1.2. 集成测试

集成测试（Integration Test）。这一步最主要的事情，就是自动部署代码到一个拟真的环境，之行端到端的测试。比如说，发布的产品是远程的 API，UT 关注的是功能单元，测试的对象是具体的类和方法；而在 IT 中，更关心暴露的远程接口，既包括功能，也包括性能。集成测试的成熟程度，往往是一个项目质量的一个非常好的体现。在某些团队中，集成测试通过几个不同的环境来完成，比如α环境、β环境、γ环境等等，依次递进，越来越接近生产环境。比如α环境是部署在开发机上的，而γ环境则是线上环境的拷贝，连数据库的数据都是从线上定期同步而来的。

1.3. 冒烟测试

冒烟测试（Smoke Testing）。冒烟测试最关心的不是功能的覆盖，而是对重要功能，或者核心功能的保障。到了这一步，通常在线上部署完成后，为了进一步确保它是一次成功的部署，需要有快速而易于执行的测试来覆盖核心测试用例。这就像每年的常规体检，不可能事无巨细地做各种各样侵入性强的检查，而是通过快速的几项，比如血常规、心跳、血压等等来执行核心的几项检查。在某些公司，冒烟测试还被称作“Sanity Test”，从字面意思也可以得知，测试的目的仅仅是保证系统“没有发疯”。除了功能上的快速冒烟覆盖，在某些系统中，性能是一个尤其重要的关注点，那么还会划分出 Soak Testing 这样的针对性能的测试来，当然，它对系统的影响可能较大，有时候不会部署在生产环境，而是在前面提到的镜像环境中。