软件测试管理办法

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

2、能与压力测试。1.3质量保证QA组1. 对测试过程进行质量监督；2. 保证项目按照正常的计划执行；3. 并进行阶段性的质量评估。2. 作业流程详细规定了测试组在整个项目中各个阶段的职责及相关测试输出文档:STAGE作业过程名作业内容/管理方法PIC输出结果项目启动了解和识别软件 要求了解 <<产品疋义 >>中规疋的软件相关的主要功能。参 加软件项目启动大会，搜集、分析软件测试输入内容。测试组长软件需求分 析报告测试相关 文档准备测试计划相关测试人员参加<<软件开发计划 >>, <<软件开发时间表>><<软件需求

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

4、>>测试组长<<软件测试用例>>更新测试用例完成模块的软件测试用例，性能测试用例、压力测试用例；软件需求变更时，根据更新的软件开发计划和需求文 档相应变更和修改 软件测试用例 和软件测试 计戈y 。当软件需求发生变更时，要及时更新测试用例。测试组长测试工程师更新后的软件测试计划、软件测试用例测试版本 准备新版本发布1. 开发部准备测试版本；2. 软件配置管理工程师进行系统冒烟测试版本的编 译；软件配置 管理工程 师冒烟测试冒烟测试3.项目测试组进行系统的冒烟测试；并记录测试结 果；整理测试报告并发送给相关人员；计算FailRatio并判断该版本是否可以进仃测

5、试；（判疋标准：模块实现100%;Fail Ratio10% ;）；如果达到测试要求；软件配置管理工程师正式发布测试版本，测试组长冒烟测试 报告测试执行测试记录 缺陷提交1.测试组长在项目经理处申请相关测试资源。项目测试人员依据测试用例对该版本进行全面的测试，确保软件所有功能的正确性，性能测试和压力测试达到预 期结果。测试工程师测试组长项目测试日 报；项目测试周报；2.要求测试工程师将当天发现的缺陷在下班前提交 到QC测试工程 师QC缺陷记录缺陷处理 缺陷确定 缺陷报告 缺陷修改 缺陷关闭3.软件项目经理组织对缺陷管理系统中提交的各个 缺陷讨论和分析，确定每个缺陷是否是真正的软件问 题,缺陷所

6、属的模块，严重程度和修改紧急度等，同时 把每个缺陷分配给相应的开发人员。软件项目 经理开发工程师测试工程师QC缺陷记录4.开发人员修改缺陷后，及时将QC数据库中的状态 置为解决状态。测试人员在收到新的测试版本后及时（1天内）地验证解决状态的缺陷是否确实可以关 闭。如果确认缺陷已经修改后，将QC上相应的缺陷置为关闭状态 。测试任务表5.测试组长每周一在 & 30将测试任务表发送给组内 成员；组内成员按照测试任务表执行测试；测试组长接收到开发组要求的临时加急任务时需要更新任务 表；测试组长在周五统计本周的测试完成状态并安排 下周任务；测试组长测试任务表测试报告6. 软件测试组长汇总相关测试

7、人员的测试结果，定期总结项目测试报告；测试报告提交给软件项目经理和 部门经理。7. 测试组在测试时，对变动比较大的功能； 测试组长 安排测试经验丰富的测试工程师执行测试， 确保软件 功能没有衰退现象。测试组长 测试工程 师项目测试 日报项目测试 周报1退回缺陷F自的处理8.对于被软件项目经理置为缺陷退回状态的记录；要求有详细的原因分析；测试组才可以进行缺陷的关 闭。软件项目 经理测试工程 师QC缺陷记录测试工具 开发测试工具开发和 维护1.软件测试工具研发组；根据具体测试需求进行测试 工具研发。测试工具 开发组项目总结项目总结1.开发项目结束后，软件测试组应进行软件测试总 结，对软件测试管理过

8、程， 活动进行分析，为将来的 项目和持续改进积累经验数据 .测试组长项目测试 总结报告维护测试项目上线后 客户反馈1.当项目上线后，对产品的软件进行维护和售后服 务，在此期间，测试组根据客户的反馈的问题列表进 行专项测试；测试组长软件专项 测试报告问题分析和修改2.软件项目经理组织对缺陷管理系统中提交的各个 缺陷讨论和确定每个缺陷是否是真正的软件问题，缺陷所属的模块，严重程度和修改紧急度等 ，同时把每 个缺陷分配给相应的开发人员。软件项目 经理开发工程师问题验证和关闭3.开发人员修改缺陷后，及时通知软件测试人员， 测试人员及时（1天内）地验证开发人员修改的缺陷 是否确实可以关闭。然后对所有功能

9、进行全面的测 试，确保产品基本功能的正确性；测试工程师测试报告3. 测试类型和策略按照目前的产品类型和规模，需要执行的测试类型及策略如下:测试类型实施标准类型描述通过标准责任人冒烟测试系统功能集成度80%以上。剩余未集成功能不 影响已集成功能。在版本进入系统测试之前需要执行的 基本功能通过性验证。发现的缺陷 95%已经解 决，其中2级以上的缺陷 100%解决。测试组长功能测试冒烟测试通过。 未集成模块有明确 的完成日期。全部功能系统测试，包括：通过性、 失效性、兼容性、；视测试系统的成熟 度，缺陷的分布及解决情况安排测试 轮次及各轮次的内容。1. 所有的模块全部集成 且测试完成。2. 没有遗留

10、的功能性Bug。3. 发现的缺陷95%已经解 决，其中2级以上的缺陷 100%解决。测试工程师兼容测试可以在功能测试完 成第一轮后开始软件在各个产品平台上面都能够正常的下载、安装、运行、卸载无缺陷测试工程师升级测试可以在功能测试完 成第一轮后开始产品的升级功能测试，全包及部分更 新文件的测试。无缺陷测试工程师性能测试视系统的稳定情 况，可以在功能测 试完成第一轮后开 始注册、登录、评论等与服务器有频繁 交互的压力测试，性能评估。满足软件设计时的性能 标准测试主导，开 发配合用户模拟 测试功能测试完成模拟用户日常使用，综合各类用户的 使用习惯设计专门的测试案例。无遗留的的用户体验类 缺陷测试组长

11、自由测试回归测试通过用户体验测试，小范围用户的实际使 用，主要关注：易用性、实用性。使用者的反馈全部解答 或修改测试组长回归测试以上所有的测试类 型通过且软件版本 不再会有较大变化产品上线之前对项目中Level 3,4 级的Bug进行回归验证；全部通过测试组长4. 缺陷级别定义等级说明描述4严重错误由于程序所引起的死机，非法退出死循环导致数据库发生死锁数据通讯错误：系统与其他系统进行数据传递时出现错误交易类的数值计算错误，分析类的数值计算偏差在 0.2%以上没有达到性能指标3较严重错误功能不符数据流错误：数据在系统内部流转中计算错误程序接口错误2一般性错误界面错误，与详细文档不符界面内容、格式

12、错误简单的输入限制未放在前台进行控制 删除、保存操作未给出确认提示信息 辅助说明描述不清楚显示格式不规范长时间操作未给用户进度提示或提示信息1较小错误窗口文字未米用行业术语可输入点击区域和只读区域没有明显的区分标志 系统处理未优化：系统易用性方面的问题，例如查询条件 值为空时通常默认为查询全部，如果还需要用户选择查询 条件为“全部”则可以认为系统处理未优化0测试建议（非缺陷）系统设计之外的优化建议5. 缺陷管理流程1. 缺陷描述中要包括详细、准确的操作步骤、预期结果、实际结果、测试环境。2. 缺陷提交时在“实际结果”栏目中填写测试数据、执行结果内容，尽量将缺陷的界面截图作为附件上传至 对应的记

13、录。3. “否决缺陷”、“暂缓处理”此两类缺陷要求在缺陷“注释”中注明否决原因或后续处理方案。4. 对“紧急”级别的缺陷，测试人员应进行随时地检查并验证，及时修改对应缺陷的状态。5. 缺陷跟踪遵循：谁发现谁跟踪；开发管理组进行确认、分配缺陷；开发人员及时修改缺陷或反馈意见。6. 开发管理组人员在自己无法及时分配缺陷的情况下要提前找到代理人员完成该工作，避免缺陷在此环节滞 留。7. 开发人员必须对缺陷进行及时修改，缺陷提交后，24小时内必须进行处理。如果开发人员没有及时修改缺陷，则将缺陷严重程度的等级升级（低级 -> 中级，中级-> 高级，高级->紧急）。8. 如果缺陷经开发人员多次修改（修改次数>2次），测试验证后仍存在问题，则将缺陷的严重程度的等级升级（低级-> 中级，中级-> 高级，高级-> 紧急）。9. 开发人员必须随时查看 QC中的缺陷状态变化信息，每天最低查看次数不得少