1 测试流程概述
软件测试流程包括:
- 测试计划:测试计划是指根据用户需求报告中关于功能要求和性能指标的规格说明书,定义相应的测试需求报告,使得随后所有的测试工作都围绕着测试需求来进行,同时适当选择测试内容,合理安排测试人员、测试时间和测试资源等
- 测试设计:测试设计是指将测试计划阶段制订的测试需求分解,细化为若干个可执行的测试过程,并为每个测试过程选择适当的测试用例,保证测试结果的有效性
- 测试开发:测试开发是指建立可重复使用的自动测试过程
- 测试执行:测试执行是指执行测试开发阶段建立的自动测试过程,并对所发现的缺陷进行跟踪管理,一般有单元测试、集成测试、确认测试等步骤组成
- 测试评估:测试评估是指结合量化的测试覆盖域及缺陷跟踪报告,对应用软件的质量和开发团队的工作进度以及工作效率进行综合评价
其中测试执行由以下步骤组成:
- 单元测试:通过对每个最小的软件模块进行测试,对源代码的每一个程序单元实行测试,来检查各个程序模块是否正确地实现了规定的功能,确保其能正常工作
- 集成测试:对已测试过的模块进行组装集成,目的在于检验与软件设计相关的程序结构问题
- 确认测试:检验软件是否满足需求规格说明中的功能和性能需求,确定软件配置完全、正确,并检验软件产品能否与实际运行环境中整个系统的其他部分协调工作
- 验收测试:主要让用户对软件进行测试,并重新执行已经做过的测试的某个子集,保证没有引入新的错误
2 单元测试
2.1 定义
单元测试用于判断一小段代码的某个特定条件或场景下某个特定函数的行为,主要测试软件设计的最小单元在语法、格式、逻辑等方面的缺陷以及是否符合功能、性能等需求,程序的多个模块可以并行地进行单元测试工作。
2.2 内容
主要包括5个任务:
- 模块接口测试:通过对被测试模块的数据流进行测试,检查进出模块的数据是否正确,因此必须对模块接口,包括参数表、调用子模块参数、全程数据、文件输入输出操作进行测试
- 局部数据结构测试:测试用例检查局部数据结构的完整性,如数据类型说明、初始化、缺省值等方面的问题
- 执行路径测试:对模块中重要的路径进行测试,对基本执行路径和循环进行测试往往可以发现大量路径错误,测试用例必须能够发现由于计算错误、不正确的判定或不正常的控制流而产生的错误
- 错误处理测试:检查模块的错误处理功能是否包含错误或者缺陷,例如,是否拒绝不合理的输入等
- 边界条件测试:必须采用边界值分析方法来设计测试用例,测试在为限制数据处理而设定的边界处,测试模块是否能够正常工作
2.3 步骤
一般单元测试需要辅助模块去帮助完成测试,辅助模块分为两种:
- 驱动模块:用来模拟被测试模块的上一级模块,相当于被测模块的主程序,用于接收测试数据,并把这些数据传送给被测模块,启动被测模块并输出结果
- 桩模块:用来模拟被测试模块工作过程中所调用的模块
被测试模块、驱动模块和桩模块共同构成了一个测试环境去进行测试。
3 集成测试
3.1 定义
将经过单元测试的模块连接起来,组成所规定的软件系统的过程称为集成,集成测试就是针对这个过程,按模块之间的依赖接口的关系图进行测试。
3.2 任务
主要任务是解决如下问题:
- 将各模块连接起来,检查模块相互调用时,数据经过接口是否丢失
- 将各个子功能组合起来,检查能否到达预期要求的各项功能
- 一个模块的功能是否会对另一个模块的功能产生不利的影响
- 全局数据结构是否有问题,会不会被异常修改
- 单个模块的误差积累起来,是否被放大,从而达到不可接受的程度
3.3 方法
集成测试的方法,包括:
- 非增量式集成测试方法
- 增量式集成测试方法
3.3.1 非增量式集成测试方法
非增量式集成测试方法采用一步到位的方法来进行测试,对所有模块单元进行个别的单元测试后,按程序结构图将各模块连接起来,把连接后的程序当作一个整体进行测试。
3.3.2 增量式集成测试方法
增量式测试集成方法可以分为:
- 自顶向下增量式测试
- 自底向上增量式测试
- 三明治集成测试
3.3.2.1 自顶向下增量式测试
自顶向下增量式测试按照结构图自上而下逐步集成和逐步测试,模块集成的顺序首先是集成主控模块(主程序),然后按照软件控制层次结构向下进行集成,集成策略可以选择广度优先或深度优先。
优点包括:
- 在测试过程中较早地验证主要的控制点
- 功能性的模块测试可以较早地得到证实
- 最多只需要一个驱动模块就可以进行测试
- 支持缺陷故障隔离
缺点:
- 随着底层模块不断增加,会导致底层模块的测试不充分
- 每次组装都需要提供桩,导致桩的数据急剧增加,从而维护桩的成本会快速上升
3.3.2.2 自底向上增量式测试
从原子模块(软件结构中最底层的模块)开始,按结构图从下而上逐步进行集成和测试。
优点:
- 总体上减少了桩模块的工作量
- 允许对底层模块行为进行早期验证
- 测试初期可以并行集成
缺点:
- 随着集成到顶层,整个系统变得越来越复杂,对于底层的一些模块很难覆盖
- 驱动模块的开发工作量大
3.3.2.3 三明治集成测试
也叫混合集成,将自顶向下和自底向上的优缺点集于一身,三明治集成就是把系统分为三层,中间一层为目标层,对目标层上层采用自顶向下的集成测试方式,对目标层下层采用自底向上集成策略,最后对目标层进行测试。
4 确认测试
4.1 定义
用于验证软件的有效性,也就是验证软件的功能和性能以及其他特性是否与用户要求一致。
4.2 内容
内容包括:
- 有效性测试:在模拟的环境下,运用黑盒测试的方法,验证被测试软件是否满足需求规格说明书列出的需求
- 软件配置审查:保证软件配置的所有成分,包括与实际运行环境中整个系统的支持环境都应齐全,各方面的质量都符合要求
5 验收测试
5.1 定义
验收测试是以用户为主的测试,但是软件开发人员和质量保证人员也需要参加。由用户参加设计测试用例,通过用户界面输入测试数据,分析测试的输出结构。
5.2 内容
内容包括:
alpha
测试beta
测试- 回归测试
5.2.1 alpha
测试
alpha
测试是由一个用户在开发环境下的测试,也可以是公司内部用户在模拟实际操作环境下进行的测试。这是在受控制环境下进行的测试,目的是评价软件产品的功能、可使用性、可靠性、性能和支持,尤其注重产品的界面和特色。
5.2.2 beta
测试
beta
测试由软件的多个用户在一个或多个用户的实际使用环境下进行的测试,与alpha
测试不同,开发者通常不在测试现场。在beta
测试中,由用户记录遇到的所有问题,包括真实的以及主观认定的问题,定期向开发者报告,开发者综合用户的报告后做出修改。
5.2.3 回归测试
5.2.3.1 定义
回归测试是一种验证已变更的系统的完整性与正确性的测试技术,是指重新执行已经做过的测试的某个子集,以保证修改没有引入新的错误或者发现由于更改而引起的之前未发现的错误。
5.2.3.2 实施前提
回归测试的实施前提包括:
- 当软件中所含错误被发现时,如果错误跟踪和管理系统不够完善,可能会遗漏对这些错误的修改
- 开发者对错误的理解不够透彻,也可能导致所做的修改只修正了错误的外在表现,而没有修改错误本身
- 修改还有可能产生副作用,从而导致软件未被修改的部分产生新的问题
5.2.3.3 回归测试的两个策略
- 完全重复测试:选择完全重复测试是指将所有的测试用例,全部再完全执行一遍,缺点是要把用例全部执行,会增加项目的成本以及影响项目的进度
- 选择性重复测试:选择一部分测试执行,以确认问题修改的正确性和修改后周边是否受到影响,常见的方法包括覆盖修改法、周边影响法、指标达成法、基于操作剖面、基于风险选择测试
5.2.3.4 流程
- 在测试策略指定阶段,制定回归测试策略
- 确定回归测试版本
- 回归测试版本发布,按照回归测试策略执行回归测试
- 回归测试通过,关闭缺陷跟踪单
- 回归测试不通过,缺陷单返回开发人员,重新修改后再次回归测试
最后感谢每一个认真阅读我文章的人,礼尚往来总是要有的,这些资料,对于【软件测试】的朋友来说应该是最全面最完整的备战仓库,虽然不是什么很值钱的东西,如果你用得到的话可以直接拿走:
这些资料,对于【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴上万个测试工程师们走过最艰难的路程,希望也能帮助到你!