软件测试的完整流程

hml123456

　一、文档评审

首先是需求文档

在系统开始开发之前，产品经理会根据收集到的用户意见和最终方案编写需求文档，编写完成后，要进行需求文档评审；说是评审，实际上主要是需求讲解。给开发们讲解业务知识、我们要做什么东西、为什么这么做、要做成什么样子。从这个环节开始，测试人员就应该介入进来。

因为需求文档是测试人员测试的唯一标准！

将来做测试的时候，如果开发做出来的东西和需求文档里写的、画的不一样，都属于BUG！如果开发说是需求改了或者说是产品经理说的，那么抱歉，请修改需求文档！所以，严格来说，测试人员在测试时只认文档不认人。可能有人会说，那这样测试人员就没必要参加评审了，直接等文档就行。

测试人员参加需求文档的评审的必要性：

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

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

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

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

然后是开发文档

需求文档定型之后，开发经理会根据需求文档来编写开发文档。

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

为什么测试要参加开发文档的评审？其实主要是去听测试人员需要了解系统的基本架构和实现原理，方便分析问题原因：

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

· 测试人员可以提出一些规范性的要求，便于后面的测试。（比如要求前端人员尽量给所有前端组件加上id或name属性，方便自动化测试时定位元素）。

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

最后是测试计划

测试计划是测试人员的工作量预估，也是将来测试人工作考核绩效的重要依据。

测试计划的内容包括：测试范围是什么、分为哪些阶段、什么时间点完成什么、测试的具体内容列表（流程、功能、接口）、测试资源的成本（人/天）等等。

测试计划是测试人员的工作守则和规范。

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

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

最终的测试过程和测试结果还是以 测试报告 为准。

二、单元测试（又称组件测试 component testing）

单元测试其实在平时比较少做，并不是因为它不重要，因为单元测试就是代码级别的测试。组件测试（也称为单元或模块测试）关注在可单独测试的组件。组件测试的目标包括：

1.降低风险

2.验证组件的功能和 非功能行为是否符合设计和规定

3.建立对组件质量的信心

4.发现组件中的缺陷

5.防止缺陷遗漏到更高的测试级别

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

单元测试就是要写一个测试类或测试方法，调用开发的新增方法（新增肯定还要传值），并且在调用过程中模拟一些异常情况或者传输错误的值。所以单元测试一般由开发人员来完成，测试人员也可以去做，但是首先测试人员需要有一定的编码能力并搭建开发环境，其次测试人员需要去理解和分析开发的相关代码，甚至是要了解和学习相关架构。

现在成熟的开发框架已经自带的很多测试的组件和工具，以Springboot为例，可以直接导入测试依赖包。

Victor00

黑我家鸽鸽是吧,小黑子