软件测试管理办法.doc

软件测试管理办法（试行）
1. 职责划分
1.1测试组长
1.参与软件需求设计的评审及项目可行性分析，风险预估，测试资源的申请；
2.编制软件测试计划、软件测试用例，定期进行维护更新；
3.根据测试组的冒烟测试结果判定是否接受该测试版本；如果达到测试标准则进入测试；
4.实施软件测试并对测试过程进行跟踪监控，对软件质量进行控制；
5.参与搭建测试环境；
6.编写测试脚本；
7.与其他部门的协调和合作。
1.2软件测试工程师
1.按照测试计划进行测试用例的执行，维护；
2.测试记录的整理，提交、验证、关闭缺陷；
3.跟踪缺陷退回的问题，必须有详细的原因分析我们才可以进行缺陷退回缺陷的否决；
4.完成性能与压力测试。
1.3质量保证QA组
1.对测试过程进行质量监督；
2.保证项目按照正常的计划执行；
3.并进行阶段性的质量评估。
2. 作业流程
详细规定了测试组在整个项目中各个阶段的职责及相关测试输出文档：

STAGE
作业过程名
作业内容 / 管理方法
PIC
输出结果
项目启动
了解和识别软件要求

了解<<产品定义>>中规定的软件相关的主要功能。参加软件项目启动大会，搜集、分析软件测试输入内容。
测试组长

软件需求分析报告

测试相关文档准备

测试计划
相关测试人员参加
<<软件开发计划>>，<<软件开发时间表>>
<<软件需求规格说明>>
<<软件功能菜单树>>的评审会议。
测试组长依据
<<软件开发计划>>
<<软件开发时间表>>
编写<<软件测试计划>>
测试组长
<<软件测试计划>>
测试计划
测试用例评审、封板
1.测试组长依据
<<软件需求规格说明>>，
<<软件功能菜单树>>
编写<<冒烟测试用例>><<测试用例>>并组织评审。
2.升级项目的测试用例选择依据<<测试用例管理办法>>
测试组长
<<软件测试用例>>

更新测试用例
完成模块的软件测试用例，性能测试用例、压力测试用例；
软件需求变更时，根据更新的软件开发计划和需求文档相应变更和修改<<软件测试用例>>和<<软件测试计划>>。
当软件需求发生变更时，要及时更新测试用例。
测试组长
测试工程师
更新后的<<软件测试计划>>、
<<软件测试用例>>
测试版本准备
新版本发布
1.开发部准备测试版本；
2.软件配置管理工程师进行系统冒烟测试版本的编译；
软件配置管理工程师

冒烟测试
冒烟测试
3.项目测试组进行系统的冒烟测试；并记录测试结果；整理测试报告并发送给相关人员；计算Fail Ratio并判断该版本是否可以进行测试；（判定标准：模块实现100%;Fail Ratio≤10％;）；如果达到测试要求；软件配置管理工程师正式发布测试版本，
测试组长
《冒烟测试报告》
测试执行
测试记录
缺陷提交
1.测试组长在项目经理处申请相关测试资源。项目测试人员依据测试用例对该版本进行全面的测试，确保软件所有功能的正确性，性能测试和压力测试达到预期结果。
测试工程师
测试组长
项目测试日报；
项目测试周报；
2.要求测试工程师将当天发现的缺陷在下班前提交到QC；
测试工程师
QC缺陷记录
缺陷处理
缺陷确定
缺陷报告
缺陷修改
缺陷关闭
3. 软件项目经理组织对缺陷管理系统中提交的各个缺陷讨论和分析,确定每个缺陷是否是真正的软件问题,缺陷所属的模块,严重程度和修改紧急度等,同时把每个缺陷分配给相应的开发人员。
软件项目经理
开发工程师
测试工程师
QC缺陷记录
4. 开发人员修改缺陷后，及时将QC数据库中的状态置为解决状态。测试人员在收到新的测试版本后及时（1天内）地验证解决状态的缺陷是否确实可以关闭。如果确认缺陷已经修改后，将QC上相应的缺陷置为关闭状态 。

测试任务表

5.测试组长每周一在8：30将测试任务表发送给组内成员；组内成员按照测试任务表执行测试；测试组长接收到开发组要求的临时加急任务时需要更新任务表；测试组长在周五统计本周的测试完成状态并安排下周任务；
测试组长
<测试任务表>

测试报告

6.软件测试组长汇总相关测试人员的测试结果，定期总结项目测试报告；测试报告提交给软件项目经理和部门经理。
7.测试组在测试时，对变动比较大的功能；测试组长安排测试经验丰富的测试工程师执行测试，确保软件功能没有衰退现象。
测试组长
测试工程师
<项目测试日报>
<项目测试周报>

退回缺陷的处理
8.对于被软件项目经理置为缺陷退回状态的记录；要求有详细的原因分析；测试组才可以进行缺陷的关闭。
软件项目经理
测试工程师
QC缺陷记录
测试工具开发
测试工具开发和维护
1.软件测试工具研发组；根据具体测试需求进行测试工具研发。
测试工具开发组

项目总结
项目总结
1.开发项目结束后, 软件测试组应进行软件测试总结，对软件测试管理过程，活动进行分析，为将来的项目和持续改进积累经验数据.
测试组长

《项目测试总结报告》
维护测试
项目上线后
客户反馈
1.当项目上线后，对产品的软件进行维护和售后服务，在此期间，测试组根据客户的反馈的问题列表进行专项测试；
测试组长
<<软件专项测试报告>>
问题分析和修改
2.软件项目经理组织对缺陷管理系统中提交的各个缺陷讨论和确定每个缺陷是否是真正的软件问题,缺陷所属的模块,严重程度和修改紧急度等,同时把每个缺陷分配给相应的开发人员。
软件项目经理
开发工程师

问题验证和关闭
3. 开发人员修改缺陷后，及时通知软件测试人员，测试人员及时（1天内）地验证开发人员修改的缺陷是否确实可以关闭。然后对所有功能进行全面的测试，确保产品基本功能的正确性；
测试工程师
<测试报告>
3. 测试类型和策略
按照目前的产品类型和规模，需要执行的测试类型及策略如下：

测试类型
实施标准
类型描述
通过标准
责任人
冒烟测试
系统功能集成度80%以上。
剩余未集成功能不影响已集成功能。
在版本进入系统测试之前需要执行的基本功能通过性验证。
发现的缺陷95%已经解决，其中2级以上的缺陷100%解决。
测试组长
功能测试
冒烟测试通过。
未集成模块有明确的完成日期。
全部功能系统测试，包括：通过性、失效性、兼容性、；视测试系统的成熟度，缺陷的分布及解决情况安排测试轮次及各轮次的内容。
1.所有的模块全部集成且测试完成。
2.没有遗留的功能性Bug。
3.发现的缺陷95%已经解决，其中2级以上的缺陷100%解决。
测试工程师
兼容测试
可以在功能测试完成第一轮后开始
软件在各个产品平台上面都能够正常的下载、安装、运行、卸载
无缺陷
测试工程师
升级测试
可以在功能测试完成第一轮后开始
产品的升级功能测试，全包及部分更新文件的测试。
无缺陷
测试工程师
性能测试
视系统的稳定情况，可以在功能测试完成第一轮后开始
注册、登录、评论等与服务器有频繁交互的压力测试，性能评估。
满足软件设计时的性能标准
测试主导，开发配合
用户模拟测试
功能测试完成
模拟用户日常使用，综合各类用户的使用习惯设计专门的测试案例。
无遗留的的用户体验类缺陷
测试组长
自由测试
回归测试通过
用户体验测试，小范围用户的实际使用，主要关注：易用性、实用性。
使用者的反馈全部解答或修改
测试组长
回归测试
以上所有的测试类型通过且软件版本不再会有较大变化
产品上线之前对项目中Level 3,4级的Bug进行回归验证；
全部通过
测试组长
4. 缺陷级别定义
等级
说明
描述
4
严重错误
l 由于程序所引起的死机,非法退出
l 死循环
l 导致数据库发生死锁
l 数据通讯错误：系统与其他系统进行数据传递时出现错误
l 交易类的数值计算错误,分析类的数值计算偏差在0.2%以上
l 没有达到性能指标
3
较严重错误
l 功能不符
l 数据流错误：数据在系统内部流转中计算错误
l 程序接口错误
2
一般性错误
l 界面错误，与详细文档不符
l 界面内容、格式错误
l 简单的输入限制未放在前台进行控制
l 删除、保存操作未给出确认提示信息
l 辅助说明描述不清楚
l 显示格式不规范
l 长时间操作未给用户进度提示或提示信息
1
较小错误
l 窗口文字未采用行业术语
l 可输入\点击区域和只读区域没有明显的区分标志
l 系统处理未优化：系统易用性方面的问题，例如查询条件值为空时通常默认为查询全部，如果还需要用户选择查询条件为“全部”则可以认为系统处理未优化
0
测试建议（非缺陷）
系统设计之外的优化建议

5. 缺陷管理流程
1. 缺陷描述中要包括详细、准确的操作步骤、预期结果、实际结果、测试环境。
2. 缺陷提交时在“实际结果”栏目中填写测试数据、执行结果内容，尽量将缺陷的界面截图作为附件上传至对应的记录。
3. “否决缺陷”、“暂缓处理”此两类缺陷要求在缺陷“注释”中注明否决原因或后续处理方案。
4. 对“紧急”级别的缺陷，测试人员应进行随时地检查并验证，及时修改对应缺陷的状态。
5. 缺陷跟踪遵循：谁发现谁跟踪；开发管理组进行确认、分配缺陷；开发人员及时修改缺陷或反馈意见。
6. 开发管理组人员在自己无法及时分配缺陷的情况下要提前找到代理人员完成该工作，避免缺陷在此环节滞留。
7. 开发人员必须对缺陷进行及时修改，缺陷提交后，24小时内必须进行处理。如果开发人员没有及时修改缺陷，则将缺陷严重程度的等级升级（低级->中级，中级->高级，高级->紧急）。
8. 如果缺陷经开发人员多次修改（修改次数>2次），测试验证后仍存在问题，则将缺陷的严重程度的等级升级（低级->中级，中级->高级，高级->紧急）。
9. 开发人员必须随时查看QC中的缺陷状态变化信息，每天最低查看次数不得少于5次。
缺陷管理跟踪流程如下：