其实测试的流程这个描述不够准确，
在国际软件测试委员会的大纲《ISTQB认证测试工程师 FL大纲-2018版 V3 1》中，
把这个测试的过程和步骤叫做测试过程（test process）
它又牵扯到测试活动和测试策略的概念
国际软件测试认证委员会2018版
尽管没有统一的软件测试过程，但是有些常见的测试活动，如果没有这些测试活动就不太可能实现既定的目标。这些测试活
动就组成了一个测试过程。
在任何给定的情况下，适当的、特定的软件测试过程取决于很多因素。
测试过程中涉及哪些测试活动，如何实施这些测试活动，以及何时开始这些测试活动，都可以在组织的测试策略中进行讨论。
在组织的测试策略中进行讨论。
感兴趣的朋友可以查一下测试过程、测试活动、测试策略的相关概念。
为了方便大家理解，我就统称测试过程。
前言：测试的过程并不是固定的，要灵活的变化
言归正传，其实这个测试的过程并不是固定的，它只是一种规范，也可以把它当作一种指导。但是真实的产品测试中，一定是
要灵活运用的，甚至是在不断的根据实际情况变化，我在其他平台、app上讨论软件测试时，经常提到：项目测试和产品测
试一定是不一样的
产品测试一定是非常完整的发版计划，有充足的时间，有充足的资源进行协调，即使因为一些特殊的原因未能按时完成发版
计划，也可以进行延期。所以产品测试都会尽量的去进行完成的全级别测试。
项目测试一般时间都是非常紧，资源有限，发生意外的情况很多，任务时间都是被极度压缩，到目前为止我经历过大大小小几
十个项目，没有一个是能按计划时间充足的上线。所以项目测试一般会大量的精简测试过程，甚至为了按时上线做出一些牺牲
牺牲掉一些不重要的功能，来优先保证重点功能、常用功能。
一、文档评审
首先是需求文档，在系统开始开发前，产品经理会根据收集到的用户意见和最终方案编写需求文档
编写完成后，要进行需求文档评审；
说是评审，实际上主要是需求讲解。
给开发们讲解业务知识、我们要做什么东西、为什么这样做、要做成什么样子。
从这个环节开始，测试员就应该介入进来。
因为需求文档是测试人员测试的唯一标准！
将来做测试的时候，如果开发做出来的东西和需求文档里写的、画的不一样，都属于BUG！
如果开发说是需求改了或者说是产品经理说的，那么抱歉，请修改需求文档！
所以严格来说，测试人员在测试时只认文档不认人！
可能有人会说，那这样测试人员就没必要参加评审了，直接等文档就行。
测试人员参加需求文档的评审的必要性：
测试人员也需要了解和学习相关的业务知识。
测试人员需要知道产品最终的上线目标是什么，来判断什么时候能达到交付的程度。
测试人员可能凭借经验对需求文档中的部分设计提出不同的意见。
测试人员可以凭借经验对需求文档中没有涉及到的一些异常情况和特殊场景进行讨论。
然后是开发文档，需求文档定型后，开发经理会根据需求文档来编写开发文档。
开发文档的内容大概包括：开发模型、代码构架、代码规范、接口规范、数据库设计…
为什么测试要产假开发文档的评审（其实主要是去听）
测试人员需要了解系统的基本架构和实现原理，方便分析问题原因
测试人员需要了解数据库表结构，对后续的测试很有必要
测试人员可以提出一些规范性的要求，便于后面的测试。（比如要求前端人员尽量给所有前端组件加上id或name属性，
方便自动化测试时定位元素）
测试人员可以发现代码中缺少对某些异常场景的逻辑判断。
最后时测试计划，
测试计划时测试人员的工作量预估，也是将来测试人工作考核绩效的重要依据。
测试计划的内容包括：测试范围是什么、分为哪些阶段、什么时间点完成什么、测试的具体内容列表（流程、功能、接口）、
测试资源的成本（人/天）等等。
测试计划是测试人员的工作守则和规范。
但是产品的诞生过程中，免不了出现各种各样的特殊情况，所以实际的测试可能会跟测试计划有所出入。
所以测试报告中需要写明测试计划产生偏差的原因，并计算变差量，分析偏差的风险。
最终的测试过程和测试结果还是以测试报告为准。
二、单元测试（又称组件测试component testing）
单元测试其实在平时比较少做，并不是因为它不重要，因为单元测试就是代码级别的测试
组件测试（也称为单元或模块测试）关注在可单独测试的组件。组件测试的目标包括：
降低风险
验证组件的功能和非功能行为是否符合设计和规定
建立对组件质量的信心
发现组件中的缺陷
防止缺陷遗漏到更高的测试级别
简单举个例子，现在开发做了一个新增的方法
单元测试就是要写一个测试类或测试方法，调用开发的新增方法（新增肯定还要传值），并且在调用过程中模拟一些异常
情况或者传输错误的值
所以单元测试一般由开发人员来完成，
测试人员也可以去做，但是首先测试人员需要有一定的编码能力并搭建开发环境，其次测试人员需要去理解和分析开发的相关
代码，甚至是要了解和学习相关架构
现在成熟的开发框架已经自带的很多测试的组件和工具，以springboot为例。
可以直接导入测试依赖包
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
</dependency>
使用idea自动创建测试类，也可以自己手动创建
写测试类：
@RunWith(SpringRunner.class)
@SpringBootTest
public class TestImpl2Test {
@Autowired
@Qualifier("testImpl2")
ITestServer iTestServer;
@Test
public void test(){
iTestServer.showClassName();
}
}
综上所述，由开发人员来进行单元测试，要更加便捷和高效，更节约成本，几乎是举手之劳，而且能培养开发自测的良好习惯
关注代码质量的重要性。
三、敏捷测试（agile testing）可选
在开发人员进行开发的这个阶段，测试人员无法对产品直接进行测试，工作任务较轻