软件测试的完整流程过程（原创）

测试的完整流程/过程

Hello~大家好，我是祁丽蕊，主要负责智家平台服务端测试工作。今天我要和大家分享

的是智家平台服务端测试的完整流程。

其实测试流程这个描述不够准确，在国际软件测试委员会的大纲中，把这个测试的过程和步骤叫做测试过程（test process ）。

这个测试过程并不是固定的，它只是一种规范，也可以把它当作一种指导。

但在实际的产品和项目测试中，一定要灵活运用，甚至是需要根据实际情况不断变化和调整的。

下面开始介绍智家平台服务端测试的完整过程，也就是测试人员拿到一个需求该怎么开展测试工作。

总体来看，共有6大步：

测试计划，测试设计，测试开发，测试执行，质量评估，功能发布

第一步：制定测试计划

要制定测试计划，那首先就要了解需求：

（1）需求分析，也可以说是文档评审，哪些文档呢？ 需求文档、开发文档

① 需求文档

在系统开始开发之前，要进行需求评审，说是评审，实际上主要是需求讲解。

给开发们讲解业务、我们要做什么东西、为什么这么做、要做成什么样子。

从这个环节开始，测试人员就该介入。因为需求文档是测试人员测试的唯一标准！

在后续测试过程中，如果开发做出来的东西和需求文档中写的、画的不一样，都属于bug!

所以，严格来说，测试人员在测试时只认文档不认人。

那可能有人会说，那这样测试人员就没有必要参加评审了，直接等文档不就好了。

其实不是，那我说下 测试人员参加需求评审的必要性:

1. 测试人员也需要了解和学习相关的业务知识

2. 测试人员需要知道产品最终的上线目标是什么，来判断什么时候能达到交付的程度。

3. 测试人员可凭经验对需求文档中的部分设计提出不同的意见。

4. 测试人员可凭经验对需求文档中没有涉及到的一些异常情况和特殊场景进行讨论。

5. 提出疑问点，以保证产品、研发、测试对需求的理解一致。

② 开发文档

需求文档定型后，研发负责人会根据需求文档来编写开发文档。

开发文档的内容大概包括：代码架构、代码规范、接口规范、数据库设计.....

为什么测试要参加开发文档的评审？（其实主要是去听）

1. 测试人员需要了解系统的基本架构和实现原理，方便分析问题原因

2. 测试人员需要了解数据库表结构，对后续的测试很有必要

3. 测试人员可以提出一些规范性的要求，便于后续测试

4. 测试人员可以发现代码中缺少对某些异常场景的逻辑判断

（2）制定测试计划

需求明确后，就可以制定测试计划，测试计划的内容包括：

测试范围是什么，

分哪些阶段，

什么时间点完成什么，

测试的具体内容列表（流程、功能、接口）.....

测试计划是测试人员的工作量评估，是绩效考核的重要依据，也是测试人员的工作守则和规范。

但在产品的诞生过程中，免不了出现各种各样的特殊情况，所以实际的测试可能会跟计划有所出入。

所以测试报告中需要写明与测试计划产生偏差的原因，分析偏差的风险。

第二步：测试设计（很重要）

第三步：测试开发

第四步：测试执行

1. 单元测试（又叫组件测试 component testing）

单元测试其实在平时比较少做，并不是因为它不重要，因为单元测试就是代码级别的测试。关注点在 可单独测试的组件。

简单的举个例子，现在开发新增了一个方法。

单元测试就是要写一个测试类或测试方法，调用开发的新增方法，并且在调用过程中模拟一些异常情况或者传输错误的值。

所以单元测试一般由开发人员来完成，

测试人员也可以去做，但是首先测试人员要有一定的编码能力并能搭建开发环境，其次测试人员需要去理解和分析开发的相关代码，甚至是要了解和学习相关架构。

综上所述，由开发人员来进行单元测试，要更加便捷和高效，更节约成本，几乎是举手之劳。而且能培养开发自测的良好习惯，关注代码质量的重要性。

2. 集成测试（integration testing）、系统测试（system testing）

① 集成测试

重点是测试各模块的接口，也就是组件或系统之间的交互。

与组件测试一样，在某些情况下，自动化集成的回归测试可以增强信心，因为即使产品有变更也不会破坏已有的接口、组件或系统 。

② 系统测试

侧重于整个系统或产品的行为和能力 ，通常会考虑系统可开展的端到端任务和开展这些任务时所展现的非功能行为。

一般情况下，系统测试的测试环境应该与集成测试的相同。

我为什么把集成测试和系统测试放在一起，因为我们在做测试的时候，经常是集成测试和系统测试同时进行。

集成测试意味着开发已经完成所有模块的开发，并且对产品有了一定的信心。

所以我们通常是直接进行集成和系统测试，也就是全用例、全流程、全功能、全接口的测试。

测试环境由测试人员进行搭建，尽量与生产环境一致。

测试期间测试环境不允许开发人员访问，直到一轮测试结束。

一轮结束后会将测试环境包括数据库移交给开发，用来复现相关问题，并查找问题原因。

开发提交新一轮测试后，测试人员重新搭建环境进行测试。

3. 确认测试

修复缺陷后， 一定要在最新版本上，重新执行之前因该缺陷而导致失败的测试用例 。目的是确认是否已成功修复原来的缺陷。

4. 回归测试

部分代码所做的变更， 无论是修复代码，还是其他类型的更改，都可能会意外地 影响到除更改代码外的其他部分代码的行为，不管是在同一组件内，还是在同一系统的其他组件中，甚至在其他系统中。 变更也可能包括环境的变化 ，例如操作系统或数据库管理系统的新版本。回归测试的目的是运行测试来检测这些意外的副作用。

第五步、质量评估

第六步、功能发布