资源描述
软件测试步骤
1 软件项目测试过程
测试阶段从横向看有以下活动:
1.1 需求分析
测试从需求分析开始介入,测试人员参与需求分析活动,确定测试需求。需要了解测试需求及测试进度,即需要验证什么功效需求点,采取什么测试策略,描述现在在进行哪一阶段测试(单元测试、集成测试、系统测试)和每个阶段内在进行测试种类(功效测试、性能测试、压力测试等)。具体阅读分析需求文档,进行逻辑梳理并勾勒出功效大约步骤图;和产品经理等相关人员探讨表述不清楚地方,细化业务步骤;考虑正常步骤中测试难点;考虑和其它功效关联;考虑非正常步骤;考虑版本数据兼容。
目标:
(1) 了解产品设计意图和设计思绪。
(2) 功效确定,充足了解个功效细节。
(3) 依据功效大小、复杂预估测试需要工具、环境、时间
1.2 项目整体计划及评审
测试计划在需求分析完成后,程序修改完成前准备。测试计划要描述测试活动范围、方法、资源和进度。
目标:
(1) 为测试各项活动制订一个现实可行、综合计划,包含每项测试活动对象、范围、方法、进度和预期结果。
(2) 为项目实施建立一个组织模型,并定义测试项目中每个角色责任和工作内容。
(3) 开发有效测试模型,能正确地验证正在开发软件系统。
(4) 确定测试所需要时间和资源,以确保其可取得性、有效性。
(5) 确立每个测试阶段测试完成和测试成功标准、要实现目标。
(6) 识别出测试活动中多种风险,并消除可能存在风险,降低由不可能消除风险所带来损失。
输入:
项目计划和测试需求
输出:
《项目测试计划》
《项目测试计划评审会议纪要》
1.3 测试用例设计及评审
内容:使用多种测试用例设计方法进行用例设计。测试用例基础要素包含测试用例编号、测试标题、关键基础、测试输入、操作步骤、预期结果等。
测试用例文档是“活”,测试用例在形成文档后也还需要不停完善。关键来自三方面缘故:第一、在测试过程中发觉设计测试用例时考虑不周,需要完善;第二、在软件交付使用后反馈软件缺点,而缺点又是因测试用例存在漏洞造成;第三、软件本身新增功效和软件版本更新,测试用例也必需配套修改更新。
目标:
(1) 使测试用例反应不一样场景、条件或经由产品事件流
(2) 测试用例必需要能完整覆盖测试需求
输入:
测试计划
输出:
《项目测试用例》
《项目测试用例评审会议纪要》
1.4 测试实施
当测试用例编写完成经过评审后,并已提交可测试系统, 然后根据测试计划和测试用例搭建测试环境,开始测试实施。对修改bug进行回归测试。
测试具体步骤:
(1) 建立测试系统,搭建测试环境
(2) 准备测试材料、测试工具
(3) 实施测试
(4) 验证预期结果,测试不经过,反馈回给编码人员修改。代码修改重新提交后,返回2继续
(5) 统计缺点
(6) 评定测试需求覆盖率
(7) 分析缺点
测试开始标准:
(1) 测试计划评审经过;
(2) 测试用例已编写完成,并已经过评审;
(3) 存在已提交可测试系统;
(4) 测试环境已搭建完成。
测试退出标准:
(1) 测试用例全部经过;
(2) 存在问题已得到合理处理。
测试停止标准:
(1) 近半数以上测试用例无法实施;
(2) 测试环境和要求不符;
(3) 开发中需求频繁变动。
目标:
(1) 全部测试用例全部被实施,并每条用例最少被实施一遍。
(2) 存在问题已得到合理处理。
输入:
测试用例
测试环境
测试脚本
输出:
《测试实施统计》
《系统bug清单》
1.5 测试评定
测试汇报是对测试过程和测试结果进行分析和评定,确定测试计划是否得到完整推行、测试覆盖率是否达成预定要求并最终在汇报中给出测试和产品质量评定结论。
输入:
《测试实施统计》
《系统bug清单》
输出:
《测试汇报》
1.6 产品试用及用户培训
软件布署后,给用户提供产品试用,给用户做相关培训。
输出:
《用户手册》
《用户培训PPT》
2 软件测试阶段
软件V模型结构图如:
2.1 单元测试
关键是测试程序代码,为是确保各单元模块被正常编译。有具体到模块测试,也有具体到类、函数测试等。——通常是由开发来完成
2.2 集成测试
单元测试后,将各单元组成完整体系,测试软件单位之间接口是否正确,数据能否正常传输。——比如注册和充值这两个功效能否连通
2.3 系统测试
把软件系统搭建起来,根据《软件规格说明书》中要求对各项功效进行测试,看是否符合需求、在系统运行是否存在漏洞等——依据测试用例,进行完整系统测试
系统测试关键包含功效测试、界面测试、可靠性测试、易用性测试、性能测试。 功效测试关键针对包含功效可用性、功效实现程度(功效步骤&业务步骤、数据处理&业务数据处理)方面测试。
2.4 验收测试
根据项目任务书或协议、供需双方约定验收依据文档进行对整个系统测试和评审,决定是否接收或拒收系统——用户对软件进行验收
2.5 回归测试
回归测试是指反复以前全部或部分相同测试。新加入测试模组,可能对其它模组产生副作用,故须进行一些程度回归测试。
3 附录
3.1 测试文档清单
阶段
活动
产出物
模板
设计
系统设计
测试计划
测试计划评审会议纪要
无
开发
测试用例设计
测试用例
测试用例评审统计
无
需求跟踪表
无
测试
测试实施
测试用例实施统计
无
测试工作阶段汇报
无
测试日报
缺点管理
缺点bug清单
无
验收
系统验收
验收测试汇报
系统公布
用户手册
无
3.2 缺点管理步骤
缺点状态通常分为:新建、打开、已分配、已修复、关闭、重新打开
中间会有:延期、反复、拒绝等状态
缺点管理步骤:
3.3 缺点等级划分
A类--严重错误,包含以下多种错误:
1、因为程序所引发死机,非法退出
2、死循环
3、数据库发生死锁
4、因错误操作造成程序中止
5、功效错误
6、和数据库链接错误
7、数据库通讯错误
B类--较严重错误,包含以下错误:
1、程序错误
2、程序接口错误
3、数据库表、业务规则、缺省值未加完整性等约束条件
C类--通常性错误,包含以下多种错误:
1、操作界面错误(包含数据窗口内列名定义、含义是否一致)
2、打印内容、格式错误
3、简单输入显示未放在前台进行控制
4、删除操作未给出提醒
5、数据库表中有过多空字段
D类--较小错误,包含以下多种错误:
1、界面不规范
2、辅助说明描述不清楚
3、输入输出不规范
4、长操作未给用户提醒
5、提醒窗口文字未采取行业术语
6、可输入区域和只读区域没有显著区分标志
E类--测试提议
展开阅读全文