软件测试模型与软件测试流程5个阶段

https://www.cnblogs.com/linxiu-0925/p/7761392.html

软件测试流程：需求分析阶段-软件设计和编码阶段（进行单元测试）-集成、系统、验收测试阶段。

软件测试模型：

    传统：项目计划——需求分析——软件设计——程序开发——软件测试——集成维护 
    V模型：需求分析-概要设计-详细设计-软件编码-单元测试-集成测试-系统测试-验收测试
    W模型：用户需求-需求分析-概要设计-详细设计-编码-单元测试-集成测试-验收测试-单元测试设计-集成测试设计-系统测试设计-验收测试设计-集成-实施-交付
    X模型：程序片断1-测试设计-工具配置-执行测试-编码完成-执行测试-工具配置-测试设计-程序片断N；封版-执行测试-测试设计-工具配置-迭代1...N-探索式测试-执行测试
    H模型：测试准备-测试就绪点-测试执行-测试流程-其余流程
软件V模型图：

软件测试W模型图：

软件H模型图：

软件X模型图：

总结：在W模型基础上结合H模型思想进行测试，当变动发生时，采用X模型思想进行处理，将开发和测试紧密结合，寻找恰当的就绪点开始测试，并反复迭代。

---

软件测试按照研发阶段通常分为5个部分：单元测试、集成测试、确认测试、系统测试、验收测试，下面将不一样阶段须要的一些工做内容作一下梳理但愿能够帮助到你们。

//No.1//

单元测试（也称为模块测试）

 

单元测试又称为模块测试，是针对软件设计的最小单位程序模块进行正确性检查的测试工做，单元测试须要从程序内部结构出发设计测试用例，多个模块能够平行地独立进行单元测试。

 

1、单元测试的内容：（白盒为主，黑盒为辅）

一、模块接口测试

• 应对经过所测模块的数据流进行测试

• 调用所测模块时的输入参数与模块的形式参数的个数、属性和顺序是否匹配

• 所测模块调用子模块时，输入子模块的参数与子模块的形式参数在个数、属性和顺序上是否匹配。

• 输出给标准函数的参数的个数、属性和顺序是否正确。

• 全局变量的定义在各个模块中是否一致。

• 当模块经过外部设备进行输入/输出操做，文件属性是否正确、open和close语句是否正确，规定的I/O格式说明与I/O语句是否匹配；缓冲区容量是否与记录长度匹配，在读写以前是否打开了文件，读写以后是否关闭了文件，对I/O错误是否作了处理。

 

二、 局部数据结构测试

• 局部数据结构是最多见的错误来源

• 不一致的数据类型

• 不正确或不一致的数听说明

• 使用还没有赋值或还没有初始化的变量

• 错误的初始值或错误的缺省值

 

三、 路径测试

运算的优先次序、常见的比较和控制流

 

四、错误处理测试

碰见出错的条件，并设置适当的出错处理

  

五、边界测试

例如循环的次数，最大或最小值

 

六、增量测试【包括自顶向下测试：从程序顶部或初始化模块开始 与自底向上测试：程序中的终端模块开始】与非增量测试

 

 

2、单元测试步骤：

• 利用设计文档设计测试用例；

• 建立被测模块的桩模块或驱动模块；

• 利用被测试模块、驱动模块和桩模块来创建测试环境，进行测试

• 驱动模块：至关于所测模块的主程序，它接收测试数据，把这些数据传送给所测模块，最后再输出实际结果

• 桩模块：用以代替所测模块调用的子模块。

 

 

 //No.2//

集成测试（白盒和黑盒结合）

 

又称为组装测试或联合测试，在单元测试的基础上，须要将全部模块按照概要设计说明书和详细设计说明书的要求进行组装。

 

• 在把各个模块链接起来的时候，穿越各个模块的接口的数据时候会丢失

• 一个模块的功能是否会对另外一个模块的功能产生不利的影响

• 各个子功能组装完成后，可否达到预期的父功能

• 全局数据结构是否有问题

• 单个模块产生的偏差累计起来是否会放大

 

集成测试层次：子系统内集成测试；子系统间集成测试；模块间集成测试。

模块组装成系统的方式：一次性组装方式和增殖式组装方式

 

1、一次性组装方式(非增式集成）

 

先对模块分别进行测试，再把全部模块组装进行测试

  缺点：发现错我不容易定位 

 

2、增值式组装测试：自顶向下；自底向上；分层集成；三明治集成；基层集成；高频集成。

 

先对一个个模块进行模块测试，而后将这些模块逐步组装成系统，分为两种方式：自顶向下的增殖方式和自底向上的增殖方式

 

一、自顶向下的增殖方式（不须要驱动模块）

 

将模块铵系统程序结构，严控制层次自顶向下进行组装。

首先以主模块做为被测模块兼驱动模块，全部直属主模块的下属模块所有用桩模块代替，对主模块进行测试。再采用深度优先或广度优先的策略，用实际模块代替桩模块，再用桩模块代替它们的直接下属模块，与已经测试的模块构成新的子系统。而后进行回归测试。

 

二、自底向上的增殖方式（不须要驱动模块）

 

由驱动模块控制最底层模块的并行测试。

 

三、混合增殖式

 

• 自顶向下增殖方式：

优势：可以较早的发现主要控制方面的问题

缺点：须要创建桩模块，增长了一些附加的测试，涉及算法和输入输出的模块通常在底层，这些底层模块要到组装和测试的后期才能发现。一旦发现问题就会出现过多的回归测试。

 

• 自底向上增殖方式：

优势：不须要创建桩模块，创建驱动模块要比创建桩模块要简单得多，同时涉及到算法已近输入输出的模块要先测试，把最容易出现问题的部分在早期解决。

缺点：程序一直未能做为一个实体存在，直到最后一个模块加上才能造成一个实体,控制方面最后才能接触。

 

3、集成测试完成的标志：

 

一、成功执行了测试计划中规定的全部集成测试

二、修改了所发现的错误

三、测试结果经过专门小组的评审

四、集成测试须要提交的测试报告：

五、集成测试计划、集成测试规格说明书以及集成测试分析报告

 

 //No.3//

确认测试（黑盒）

 

 确认测试的目标是验证软件的功能和性能以及其余特性是否与用户的要求一致。确认测试通常包括有效性测试和软件配置复查。通常有第三方测试机构进行。

 

 1、进行有效性测试

 

现软件确认要经过一系列黑盒测试。确认测试一样须要制订测试计划和过程，测试计划应规定测试的种类和测试进度，测试过程则定义一些特殊的测试用例，旨在说明软件与需求是否一致。

 

无是计划仍是过程，都应该着重考虑软件是否知足合同规定的全部功能和性能，文档资料是否完整、准确人机界面和其余方面（例如，可移植性、兼容性、错误恢复能力和可维护性等）是否令用户满意。

 

确认测试的结果有两种可能，一种是功能和性能指标知足软件需求说明的要求，用户能够接受；

 

另外一种是软件不知足软件需求说明的要求，用户没法接受。项目进行到这个阶段才发现严重错误和误差通常很难在预约的工期内改正，所以必须与用户协商，寻求一个妥善解决问题的方法

 

2、软件配置复查

 

保证软件配置的全部成分齐全，质量都符合要求。应该遵照用户手册和操做手册中的规定步骤。

 

//No.4//

系统测试  一般意义上的系统测试包括 压力测试（也称为强度测试），容量测试，负载测试，性能测试，安全测试，容错测试等。

 

 软件做为计算机系统的一部分，与硬件、网络、外设、支撑软件、数据以及人员结合在一块儿，在实际或模拟环境下，对计算机系统进行测试，

目的在于与系统需求比较，发现问题。      

 

利用程序的用户文档或书面材料。经过分析目标文档来设 计系统测试，分析用户文档来阐明测试用例。

因为没有一个方法，系统测试须要大 量的创造性。事实上，设计好的系统测试用例比设计系统或程序须要更多的创造性、 智慧和经验。

 为了不有所遗漏，设计测试用例时应考虑所有的 15 种类型。

能力测试、容量测试、强度测试、易用性测试、安全性测试、

性能测试、存储测试、配置测试、兼容性/配置/转换测试、安装测试、

可靠性测试、可恢复性测试、适用性测试、文档测试、过程测试。

 

 

//No.5//

验收测试  包括：正式验收，alpha测试，Beta测试。

 

 以用户为主的测试，软件开发人员和质量保证人员参加，由用户设计测试用例。

不是对系统进行全覆盖测试，而是对核心业务流程进行测试。

根据合同、《需求规格说明书》或《验收测试计划》对产品进行验收测试。

对于经过验收测试的软件产品/参照《配置管理规范》中所规定的标识方法更改测试状态，同时项目经理负责编制《验收报告》。