测试作业流程及标准规范.docx
《测试作业流程及标准规范.docx》由会员分享，可在线阅读，更多相关《测试作业流程及标准规范.docx（26页珍藏版）》请在冰点文库上搜索。
测试作业流程及标准规范
1目标
侧重测试工作步骤及规范控制，明确产品研发各阶段测试组应完成工作。
测试技术和策略等问题不在本文档描述范围内。
本规范作为全部测试组成职员作前必需掌握工作规范，也供给其它部门其它组查阅参考，方便于组间协调沟通，愈加好合作完成产品研发工作。
2概念和术语
在整个产品研发过程中，测试类型根据前后次序关键分为：
单元测试、集成测试、系统测试及产品确定，整个过程以下面W模型所表示：
设计规格
模块设计
集成测试
系统测试
产品确定N
概要设计
需求规格
单元测试
三
绘图/编码
测试需求
测试计划
测试计划
测试纲领
走查/审核
实施单元测试
实施集成测试
实施系统测试
产品试用
图1
相关测试类型概念以下：
1）单元测试：
验证产品中模块，测试依据关键为模块具体设计或模块需求规格。
能使问题及早暴露，也便于问题定位处理，单元测试属于早期测试，所以错误发觉后能明确知道是某一单元产生，单元测试允很多个被测单元测试工作同时开展。
依据企业研发步骤实际情况，此测试也可由设计研发人员实施。
2）集成测试是验证模块间接口及匹配关系，测试依据关键为概要设计。
通常采取自底向上或自顶向下模块集成方法，逐步集成。
在此步骤中测试组还负责验收研发人员提供转测试材料，假如材料不完备，测试组能够拒绝接收。
3）系统测试是对系统一系列整体、有效性、可靠性测试，测试依据关键为设计规格及产品需求规格。
目标是确定产品和设计规格、需求、行业标准及企业标准符合性，同时还要确定性能和系统稳定性，和之前集成测试应遵照“相同被测对象不要做两遍相同测试”基础标准。
4）除单元测试、集成测试和系统测试之外，还应有“产品确定”步骤，即在用户环境中或模拟用户环境测试和验证产品，在有限试用用户中或模拟用户环境中发觉产品问题并加以妥善处理，确保产品质量，提升用户满意度。
确定和试验室内部测试区分在于：
试验室内部测试要尽可能多做，多发觉问题；确定要在达成质量目标情况下尽可能少做；二者要在质量和成本之间权衡、综合考虑。
5）TD：
全称MercuryTestDirector，一个测试管理工具。
6）黑盒测试：
黑盒测试也称功效测试，它是经过测试来检测每个功效是否全部能正常使用。
在测试中，把程序看作一个不能打开黑盒子，在完全不考虑程序内部结构和内部特征情况下，在程序接口进行测试，它只检验程序功效是否根据需求要求正常使用，程序是否能合适地接收输入数据而产生正确输出信息。
黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，关键针对软件界面和软件功效进行测试。
黑盒测试是以用户角度，从输入数据和输出数据对应关系出发进行测试。
3职责
角色名称
相关关键责任
测试主管
●组建测试小组
●协调测试小组内外部沟通
●组织编制测试纲领（含测试用例）和计划
●组织测试准入检验
●测试过程中进度控制、风险管理
●测试过程汇报
●编写测试汇报
●召集测试评审
测试人员
●识别测试需求
●参与编制测试纲领（含测试用例）和计划
●帮助测试准入检验
●实施测试用例，测试结果统计
●测试缺点统计和跟踪
●帮助测试评审
支持人员
●为测试工作提供技术支持，比如环境安装、版本布署、测试工具支持等
备注：
该角色可选，可依据项目实际情况设置，通常情况下由研发人员担任。
【注】：
当某个项目仅有一个测试人员时，该测试人员同时也为该项目内测试主管，需要担负起测试主管职责。
4测试类型和测试方法
测试类型
测试工作通常分为4个类型，功效测试、联合测试、性能测试及稳定性测试。
测试类型
测试意义
功效测试
●确保功效符合需求定义
●确保全部功效能够正常完成工作
联合测试
●一个新产品或一个产品新版本公布时，要确保和之相配合产品能够正常配合使用
性能测试
●在产品有性能要求部分，进行性能测试和调优，确保产品性能符合需求
稳定性测试
●模拟用户真正使用情况，设计对应测试用例，确保产品能够稳定可靠长时间运行
测试方法
测试类型
测试方法
功效测试/
联合测试
●以手工黑盒测试为主，手工实施功效测试用例。
●正规测试和随机测试相结合：
依据需求文档撰写测试方案及测试用例来进行常规测试，考虑到测试用例有可能写不全方面，所以在进行常规测试过程中，能够加入随机测试。
同时，对估计试出来缺点，将其实施过程写成一个测试用例，添加到测试用例集合中，以完善测试用例；
●采取测试工具TD进行测试用例管理和缺点统计、跟踪。
性能测试
●性能测试要求满足两种情况：
1）产品在特定工况下能够达成最高性能（比如：
测试时将日志等影响性能选项关闭）；
2）模拟用户真正使用环境（如：
日志功效打开，在一定用户数量情况下），
产品真实能够达成性能；
稳定性测试
●稳定性测试要求模拟用户真正使用情况，设计对应测试用例，确保产品能够稳定可靠长时间运行
【注】：
黑盒测试过程参考准则：
（1）必需采取边界值分析法；
（2）必需时采取等价类划分法补充测试用例；
（3）采取错误判定法，追加测试用例；
（4）对照程序逻辑，检验已设计出测试用例逻辑覆盖程度。
假如没有达成要求覆盖标准，应该补充更多测试用例；
（5）测试数据应准备充足，应采取有效数据、无效数据、边界数据分别测试验证；
5工作步骤、模式及规范
测试提交文件及裁剪说明
阶段
提交文件
必需提交
模板定义
裁剪条件说明
测试需求
测试需求分析汇报
否
项目组自定义
无特殊需求，可省略
测试计划
测试纲领
是
项目组自定义
各项目组依据测试任务规模可自定义模板
测试计划
否
项目组自定义
假如测试纲领或设计开发计划中已包含了测试计划内容，则本文档可省略
测试纲领计划评审统计
否
企业模板
各项目酌情选择
测试用例
是
企业模板
采取企业统一测试用例模板
测试用例评审统计
否
企业模板
各项目酌情选择
测试实施
测试准入检验表
否
企业模板
各项目酌情选择
测试统计
是
项目组自定义
各项目组依据测试任务规模可自定义模板
测试收尾
测试汇报
是
企业模板
采取企业统一测试汇报模板
测试汇报评审统计
否
企业模板
各项目酌情选择
测试工作改善汇报
否
项目组自定义
各项目酌情选择
测试结果提交
否
项目组自定义
各项目酌情选择
评审点
评审点定义参考《设计开发控制程序》。
灵敏测试模式
灵敏测试概念
灵敏测试即是不停修正质量指标，正确建立测试策略，确定用户有效需求得以圆满实现和确保整个生产过程安全、立即公布最终产品。
灵敏增量测试方法
测试是灵敏开发过程关键步骤，自始自终测试贯穿于每个迭代。
整个产品灵敏开发生命周期能够分为4个阶段，即初始阶段，项目标建设阶段，产品公布阶段和产品维护阶段，在关键项目建设阶段中，测试被分成两个部分，验证测试和系统测试。
验证测试：
静态测试和关键功效测试。
系统测试：
功效测试、联合测试、性能测试、稳定性测试。
灵敏测试步骤
灵敏测试步骤依据业务场景制订测试策略。
在每次灵敏测试过程中包含验证测试和联合测试。
而且不停进行迭代测试。
在系统全部业务场景全部经过灵敏测试过后，进入系统测试阶段。
进行全部业务场景功效测试、联合测试、性能测试、稳定性测试。
依据业务场景制订测试策略步骤图
产品
业务场景一
业务场景二
。
。
。
。
。
。
业务场景N
模块一
模块二
模块三
三
。
。
。
。
。
。
模块N
模块四
三
业务场景一
缺点管理
缺点管理
业务场景三
TR5
业务场景二
TR5
业务场景N
TR5
业务场景四
TR5
灵敏测试步骤图
测试传输项汇报
灵敏测试
测试总结
测试经过
进入下一次灵敏迭代
测试计划
提交测试
N
Y
Y
N
满足准入条件
系统测试条件
Y
软件测试总结
软件评定
满足公布条件
产品公布
测试案例维护
系统测试和回归测试
测试是否经过
Y
Y
依据缺点性质来判定更新提交测试依据：
1）严重等级为Urgent和High修改后立即更新，要确保更新后不能影响其它功效测试。
2）功效等级为Medium以下能够等候下一次提交灵敏测试时候更新。
传统瀑布模式
测试需求分析
过程关键点
具体说明
开启条件
需求阶段工作开启
工作内容
由测试主管依据项目任务复杂程度组织或指定测试人员进行测试需求分析，从用户角度考虑软件测试需要达成验证状态，并确定是否要形成测试需求分析汇报
结束条件
需求分析完成
例外
对于简单设计更改、衍生产品等只需例行测试，可不进行测试需求分析
责任人
项目经理
参与人
测试主管
成立测试小组或确定测试人员
过程关键点
具体说明
开启条件
测试任务明确，前期工作开启
工作内容
●确定项目标测试人员，若整个项目标测试需要若干个测试人员，则需要成立一个测试小组；
●为测试小组任命一名测试主管，若只有一个测试人员，则该测试人员同时也为该测试组测试主管，同时确定测试小组其它组成人选；
●小组内进行必需培训。
结束条件
测试小组成立
例外
●若以前测试任务已成立过测试小组，则能够复用以前组织人员和形式
责任人
项目经理
参与人
测试主管
编制测试计划
过程关键点
具体说明
开启条件
项目阶段性计划确定
需求规格说明书、具体设计说明书等已评审
工作内容
测试纲领最少包含以下关键内容：
●测试目标——对此次测试要求和要达成目标
●测试范围——需要测试小组测试范围，和各个测试需求测试优先级
●工作分工——明确测试小组内部及外部配合方相关责任和工作关系
●测试策略——整体测试总体测试策略、环境、方法和工具等
●完成标准——达成何种条件能够认为测试完成
●交付文件——测试完成时应提交文件，比如测试纲领（含测试用例）、测试汇报等等
测试计划最少应包含以下关键内容：
●关键任务——每项任务时间计划、前置条件及资源
●关键里程碑——关键任务及完成时间点
●在项目研发过程中，要适时对测试计划进行跟踪，以评定此计划完整性、可行性，在项目结束时还要最终评定一下测试计划质量
结束标准
测试计划评审经过或得到相关各方审批
输出文件
测试计划、测试计划评审统计
例外
●对于多个系统参与同一个测试任务，可由主项目组或牵头方统一编制测试纲领和计划，不用每个系统单独编制和出具
●测试计划能够在测试纲领中直接具体列明，而不用单独编制
责任人
测试主管
参与人
研发总监、项目经理、测试人员
编制测试纲领、设计测试用例
在技术规格书评审经过以后，测试小组需要针对项目标测试范围编制测试纲领、设计测试用例。
在实际测试过程中，测试用例可依据实际需要进行更新和调整。
在测试用例设计过程中，具体任务和责任人以下：
过程关键点
具体说明
开启条件
此次测试范围、业务需求已经明确
需求规格说明是、具体设计说明书已经过评审
工作内容
●准备此次测试测试用例
●测试用例在该产品测试用例库中进行选择，如有需要，能够进行增加；
●每个测试用例须包含用例编号、测试概述、测试数据、操作步骤说明、预期结果等要素；
●测试用例须覆盖全部测试需求和功效点；
●采取统一模板进行用例设计。
结束标准
测试用例覆盖全部待测试需求或功效点，而且评审经过
输出文件
测试纲领、测试用例、测试纲领评审统计
责任人
测试人员
参与人
研发总监、研发人员、项目经理、测试主管
测试实施阶段
测试准入检验
过程关键点
具体描述
开启条件
测试实施准备工作完成
工作内容
●测试主管依据本项目标特点，事先确定测试准入标准中哪些条目能够进行裁剪，并和项目经理及研发人员商讨确定
●准入标准中“计划准入标准”是指编制测试计划、测试纲领、测试用例设计时就需要含有前提条件，应提前进行检验；“实施准入标准”是指在实施测试之前需要进行检验。
以上两类检验应分两次进行
●测试主管和测试人员依据测试准入标准，逐项进行检验，并填写测试准入检验表
●对于不满足条件检验项，要求相关方面进行处理，处理后重新进行检验
●必需要经过检验项，而没检验经过，视为准入检验不经过，不能进入下一阶段工作
结束条件
测试准入检验经过
输出文件
测试准入检验表
责任人
测试主管
参与人
测试人员、项目经理、研发人员
实施测试用例
过程关键点
具体描述
开启条件
测试实施阶段准入检验经过
工作内容
●测试人员依据计划，实施对应测试用例，并做好测试统计
●测试人员进行缺点登记，并跟踪处理情况，立即复测，关闭缺点
●测试主管跟踪测试用例实施情况，了解影响测试用例实施原因，立即跟进相关协调、汇报测试状态
●测试主管依据项目标情况，选择相关汇报形式，将测试进展情况立即通报给相关各方
结束条件
测试用例实施完成
责任人
测试人员、测试主管
参与人
研发人员、项目经理
回归测试
在每轮测试结束以后，当研发人员处理完相关问题，重新提交，进行回归测试。
过程关键点
具体描述
开启条件
在每轮测试中，按现有测试用例没有新缺点被发觉，测试汇报中全部活动缺点全部被处理
工作内容
测试组将根据测试计划中对于回归测试策略对产品进行回归测试，回归测试用例属于测试用例一部分或是全部测试用例，但不能超出原先预定测试用例范围
结束条件
回归测试所运行用例全部经过
责任人
测试人员
参与人
研发人员、项目经理
缺点管理
过程关键点
具体描述
开启条件
测试用例开始实施
工作内容
●测试人员在测试过程中，统计被测产品缺点，跟踪缺点分析、处理过程
●研发人员立即分析处理缺点，并按要求统计缺点分析处理信息，更新缺点状态，填制缺点起源；对需要其它人员参与分析处理时候，需立即将缺点分配给下一步骤人员
●测试人员对待验证缺点需立即进行复测，测试经过后关闭缺点
结束条件
测试用例实施完成，而且缺点跟踪完成
责任人
测试人员、研发人员、测试主管
参与人
项目经理
测试收尾阶段
测试实施阶段结束或立即结束时，测试小组能够开始着手准备进行总结汇报及收尾工作。
编制测试汇报
在测试实施完成以后，测试主管或测试人员需依据实施测试情况，编制测试汇报。
过程关键点
具体描述
开启条件
测试小组完成了全部测试实施工作或测试时间已结束
工作内容
测试主管或测试人员依据测试结果，根据测试汇报文档模板编写测试汇报，测试汇报必需包含以下关键内容：
●测试用例实施情况分析――测试阶段用例实施数量、轮次、经过率等
●测试过程中已发觉缺点分析――分析缺点数量、分布、起源等
●未实施用例风险分析――分析未实施用例对系统形成风险
●未关闭缺点风险分析――分析未关闭缺点对系统形成风险
●测试结论――评价测试纲领中定义测试完成标准是否达成，被测系统质量评价，存在风险，和相关提议
结束条件
测试汇报评审经过，发送给相关人员
输出文件
测试汇报、测试汇报评审统计
责任人
测试主管、测试人员
参与人
研发总监、研发人员、项目经理
测试工作过程改善
测试过程改善在测试实施阶段工作全部结束以后进行。
它目标是评定此次测试工作，总结经验，使下一次工作做得愈加好。
本项工作不是一个必需过程，各项目可依据情况采取。
过程关键点
具体描述
开启条件
测试实施阶段结束
工作内容
●测试主管召集测试参与人员，讨论此次测试过程得和失，总结经验，提出改善方法和意见
●编写测试工作过程改善汇报
结束条件
测试工作过程改善汇报编制完成
输出文件
测试工作改善汇报
责任人
测试主管
参与人
测试人员
测试结果提交
测试资产提交在测试实施阶段工作结束以后进行，对测试过程中包含到多种标准文档进行归类，存档。
过程关键点
具体描述
开启条件
测试实施阶段结束
工作内容
提交此次测试过程产生，能为其它项目或本项目后续测试提供借鉴，测试用例等
结束条件
全部结果归档完成
输出文件
测试结果清单
例外
假如结果内容不多，结构清楚，则能够省略测试结果清单
责任人
测试主管
参与人
测试人员
软件测试实施模式
现在采取3+1模式。
即三轮系统测试加一轮回归测试。
6缺点管理机制
缺点经过测试管理工具TD进行管理
测试团体研发团体
提交缺点
缺点分析
缺点修复
复测缺点
是否修复
关闭缺点
测试人员提交缺点到TD，提交缺点状态为open，并制订严重等级
研发部门对测试人员提出缺点进行分析，确定是否对缺点进行修改
修改后将缺点置为fixed，不进行修复或不是缺点问题应该修改缺点状态。
测试人员在新一轮测试时复测研发修复缺点
测试过程中发觉修复缺点仍然存在问题，缺点状态置为reopen，重新提交至研发部门。
测试验证后不出现问题缺点，即可关闭。
缺点严重等级和怎样分类
严重等级
描述
5-Urgent
阻碍步骤、系统瓦解造成重大任务不能正常进行缺点，比如：
1、因为程序所引发死机，非法退出。
2、死循环
4-High
1、数据库发生死锁
2、错误操作造成程序中止
3、严重计算错误
4、和数据库连接错误
5、数据通讯错误等
3-Medium
缺点造成失去系统关键功效，基础功效不能完整使用。
比如：
1、功效不符
2、程序接口错误
3、数据流错误
4、轻微数据计算错误等
2-Low
操作性错误、错误结果、遗漏功效等影响系统要求或基础功效实现。
比如：
1、界面错误
2、打印内容、格式错误
3、简单输入限制未放在前台进行控制
4、删除操作未给出提醒
5、数据输入没有边界值限定或不合理
6、错别字等
1-suggest
提议，不影响使用瑕疵或愈加好实现等。
7新产品测试步骤
新产品测试输入输出
测试步骤
输入
输出
测试准备
需求分析阶段
产品需求分析文档
评审结果
软件开发设计阶段
概要设计阶段
具体设计阶段
评审结果
测试方案和测试计划
软件测试设计阶段
《概要设计》
《具体设计》
《测试方案和测试计划》
测试案例
测试环境准备
《概要设计》
《具体设计》
《测试方案和测试计划》
测试环境清单
测试环境准备完成
测试实施
冒烟测试
《测试项传输汇报》
冒烟测试结果
系统测试和回归阶段
《测试方案和测试计划》
测试案例
《测试项传输汇报》
《测试日志》
《轮次总结测试汇报》
测试分析和维护
软件测试总结
《系统测试总结汇报》
软件评定
《系统测试总结汇报》
评定结果
软件测试维护
测试案例修改
新产品测试步骤图
需求调研阶段
需求规格说明书
概要设计
具体设计
测试方案和测试计划
测试案例编写
评审结果
评审结果
单元测试和集成测试
测试结果
提交测试
经过冒烟测试和送测清单
系统测试和回归测试
测试是否经过
软件测试总结
软件评定
满足需求
产品公布
测试案例维护
走新增或修改需求步骤
Y
N
N
N
Y
Y
N
Y
N
N
N
Y
Y
8生产缺点测试步骤
生产缺点测试输入和输出
测试阶段
输入
输出
测试准备阶段
生产缺点描述和处理措施
《测试方案和测试计划简报》
测试实施阶段
《测试项传输汇报》
《测试总结简报》
软件评定
《测试总结简报》
评定结果
测试案例维护
测试案例修改
生产缺点测试步骤图
生产缺点调研
生产缺点描述和处理措施
准入条件
生产缺点测试
软件评定是否满足用户要求
测试总结简报
测试是否经过
测试结束
提交测试
Y
N
N
Y
Y
9新增和修改需求测试步骤
新增和修改需求测试输入和输出
测试阶段
输入
输出
测试准备阶段
新增和修改需求调研
新增和修改需求概要设计和具体设计
《测试方案和测试计划》
测试实施阶段
《测试项传输汇报》
《测试总结汇报》
软件评定
《测试总结汇报》
评定结果
测试案例维护
测试案例修改
新增和修改需求测试步骤图
新增和修改需求调研
概要和具体设计
是否满足准入条件
系统测试和回归测试
软件评定是否满足用户要求
测试总结汇报
测试是否经过
测试结束
测试方案和测试计划
提交测试
N
Y
Y
N
Y
N
10公布评定标准
检验合格依据:
Ø遗留问题中不能有Urgent、High等级问题；
Ø遗留问题中Medium等级问题数要小于等于8，而且经过研发、测试及产品经理讨论一致同意。
Ø软件达成设计性能指标。
Ø软件稳定性测试经过，没有不稳定现象。
Ø联合测试经过，无Bug。
满足以上五点，视为产品检验合格。
假如产品不满足上述五点，但还需要公布，则应该取得软件总监同意。
11问题处理
如研发团体对测试结论有争议，应经过评审处理。
12相关文件
《设计开发控制程序》
《设计更改控制程序》
《研发评审要求》
《研发测试要求》
13相关统计
《测试计划》
《测试纲领》
《测试用例》
《测试统计》
《测试汇报》
《缺点跟踪汇报》
《评审统计》
《评审汇报》
文件修订信息页
编
号
章节
名称
修订内容简述
修订
日期
订前
版本
订后
版本
拟制
审核
同意
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
升级会员 