测试部门管理规范
测试部门管理规范编写人
邮箱曾一岚[email protected]
目
一
1
2
3
4
5录测试流程规范..................................................................................................... 3需求分析阶段..................................................................................................................... 3用例设计阶段..................................................................................................................... 4测试实施阶段..................................................................................................................... 5性能测试............................................................................................................................. 6产品发布............................................................................................................................. 6二
1
2
3
4
5
6
7
8
9缺陷管理规范..................................................................................................... 7BUG 生命周期.................................................................................................................... 7BUG 判断规则.................................................................................................................... 7BUG 分类............................................................................................................................ 8BUG 状态类别.................................................................................................................... 9BUG 严重级别.................................................................................................................... 9BUG 处理级别.................................................................................................................. 10BUG 提交内容规范.......................................................................................................... 10有效的BUG 填写原则..................................................................................................... 11BUG 修复信息规范.......................................................................................................... 1110BUG 回归信息规范.......................................................................................................... 12三
1
2版本管理规范................................................................................................... 12版本管理日常工作流程.................................................................................................. 15紧急版本更新工作流程.................................................................................................. 17
一测试流程规范
1需求分析阶段
1. 需求分析人员搜集、提炼需求信息，形成初步的需求分析文档，发送给
开发部门经理、项目经理、测试部门经理，及相关的开发人员和测试人员审阅。
2. 需求分析人员、开发部门经理、项目经理、测试部门经理、开发人员、
测试人员组成需求评审小组，召开需求评审会议，确定需求的最终内容。
3. 需求分析人员根据需求评审会议决议，形成规范的需求分析文档，发送
给开发部门经理、项目经理、测试部门经理，及相关的开发人员和测试人员。
4. 测试部门经理整合项目相关信息，指派项目测试负责人负责开展测试工
作。
2用例设计阶段
1. 项目经理根据需求分析文档制订出相应的开发计划后，测试负责人根据
开发计划内容制订对应的测试计划，发送给开发部门经理、项目经理、需求分析人员、开发人员和测试人员。
2. 测试负责人将需求内容细分成任务单，分派给具体的测试人员。
3. 测试人员针对每一个测试任务单设计详尽的测试用例，发送给测试负责
人及项目组内相关的测试人员。
4. 测试负责人组织项目组内测试人员及开发相关人员召开用例评审会议，
对测试用例进行评审，提出完善方案。
5. 测试人员根据用例评审会议结果完善各自的测试用例，形成规范的系统
测试用例文档提交到文档服务器保存。
3测试实施阶段
1. 开发人员将自测通过的代码提交给BM （Build Master ），及将需求解决方
案提供给项目测试人员。
2. BM 将最新的代码部署到测试环境，通知测试人员启动测试。
3. 测试人员检查需求解决方案是否符合规范、内容完整，否则退回开发人
员重新完善。
4. 测试人员遵照测试计划、测试用例及需求解决方案对系统进行逐项测试，
测试过程中发现的BUG 通过缺陷管理工具反馈给对应的开发人员。
5. 开发人员将修复BUG 的相关代码提交给BM ，并通过缺陷管理工具回复
测试人员。BM 定时将代码更新到测试环境，通知测试人员测试。
6. 测试人员根据开发回复的BUG 修复说明对BUG 进行回归测试，直至BUG
测试通过。
7. 系统功能测试通过后，测试人员根据测试结果编写各自任务单的测试报
告，发送给测试负责人汇总。
8. 项目负责人汇总各测试人员的测试报告，形成完整的系统测试报告。4性能测试
系统功能测试通过之后，安排专业的性能测试人员使用性能测试工具对系统进行全面的性能测试，分析系统存在的瓶颈，协调相关人员采取相应措施进行优化，形成性能测试报告。
5产品发布
产品经理确认产品达到测试计划所制定的产品质量目标和测试质量目标后，安排人员整理产品发布包及编写相关文档，汇总到BM 处，择期正式发布。
产品发布包含的文档如下：
《产品白皮书》
《系统测试报告》
《性能测试报告》
《产品安装手册》
《产品维护手册》
《用户操作手册》
二缺陷管理规范
1BUG 生命周期
2BUG 判断规则
1. 软件未达到产品规格说明书标注的功能。
2. 软件出现了产品规格说明书指明不会出现的错误。
3. 软件功能超出了产品规格说明书指明的范围。
4. 软件未达到产品规格说明书未指出但应达到的目标（隐含需求）。
5. 测试人员认为软件难以理解、不易使用、不人性化、运行速度缓慢，或
用户体验需要改进。
3BUG 分类
1. 功能问题
功能未实现
功能实现与需求设计不符
功能重复
功能多余
2. 界面问题
界面风格、文字、按钮不符合规范操作繁杂
提示信息模糊
提示信息内容出现专业的代码错误信息
3. 数据问题
数据类型错误
数据计算错误
数据初始化错误
数据边界值相关错误
4. 安全性问题
数据有效性检测不合理
重要数据传输过程没有加密缺少身份认证机制或认证不合理系统日志未作级别控制
5. 性能问题
并发量
数据量
压缩率
响应时间
6. 配置问题
7. 兼容性问题
8. 编译问题
9. 设计问题
4BUG 状态类别5BUG 严重级别
1. P1级：严重问题
软件非法退出
软件运行导致机器死机软件出现死循环
软件运行导致数据库死锁数据通讯错误
数值计算严重错误
2. P2级：较严重问题
功能未实现
功能实现不符合原始需求
数据流错误
程序接口错误
数值计算错误
3. P3级：一般问题
界面错误
打印相关错误
附件上传失败
提示信息错误
字段类型控制错误
4. P4级：轻微问题
数据格式不规范页面显示不规整信息提示不明确必填字段未标识附件格式未定义
5. P5级：优化意见或建议6BUG 处理级别
紧急
优先
一般
低级
可延迟
7BUG 提交内容规范
8有效的BUG 填写原则
9BUG 修复信息规范
10BUG 回归信息规范
三版本管理规范
以SVN 作为版本管理工具为例制订以下管理流程。
代码库
代码库(repository)，也称为版本库，通常包含三个目录：主干（trunk）、分支（branches）、标签（tags）。这三个目录本质上一样都是分支，只是为了管理的方便，用来存放不同的版本。
主干（trunk）：开发组提交的稳定的版本。一般只有一个目录。
分支（branches）：开发组开发的版本目录。通常分为两类：
a、日常开发分支。如【./branches/dev】，一般只有一个。
b、紧急版本开发分支。如【./branches/dev_patch/XXX_V版本号_日期_P_编译版本号_补丁序号】，该分支是基于标签版本建立的模块增量分支，
可有建立多个。
标签tags：用来存放测试通过、已经发布的版本。通常分为两类：
a、大版本标签版本。如【ProName_V版本号_日期】。
b、补丁标签版本，为紧急更新的版本。如【ProName_V版本号_日期_P补丁序号】。
代码库的管理一般如下范例所示：
Subversion 的版本号按代码库的全局版本号从1开始自增长分配，和其它版本控制系统不同的是，Subversion的版本号是针对整个目录树的，而不是单个文件。每一个版本号代表了一次提交后版本库整个目录树的特定状态，需要注意的是，一个文件的版本M 和N 并不表示它们一定不同。
工作副本
工作副本是本地机器一个普通的目录，存放代码库上的文件拷贝，可以任意编辑。如果是源代码文件，可以直接进行编译。工作副本是私有工作区，在提交操作之前，Subversion不会把当前的修改与其他人的合并，也不会把当前的修
改展现给他人。
可以使用【Checkout】从版本库创建一个工作副本，然后使用【Commit】将改动上传到版本库。
工作副本与目标代码库的分支对应，可通过【Switch】命令切换目标库的分支。
分支合并merge
可从版本库的某个分支进行【merge】到工作副本的的修改，而不会破坏本地的修改，即自动合并。但当有冲突时，这些修改不会自动合并。
更新工作副本时若无冲突也会自动合并。
1版本管理日常工作流程
1. 版本组创建" 主干版本" （基准版本）。
2. 开发组根据需要基于" 主干版本" 建立" 分支" ，一般有两类开发分支：
日常开发分支，如：./branches/dev/
紧急更新开发使用的分支，
如：./branches/dev_patch/crm_vX.X.X_20131030_p01/
3. 开发人员提交自测通过后的代码到开发分支，各模块版本负责人合并模
块代码到主干，并添加更新说明文件。为了保持主干版本的稳定，只给版本负责人开放主干的写权限。
4. 开发提交截止后，版本组基于主干版本记录版本号N 。
5. 版本组从" 主干版本" 中提取代码进行编译，发布到测试环境。
6. 测试人员在测试环境进行测试，若测试中发现问题需要修改代码，由开
发人员在开发分支进行修改好后，再由合版人员合并到主干版本。
7. 版本组更新主干代码到编译环境，记录版本号M ，编译最新版本更新到
测试环境。
8. 测试完成版本组进行封版，为本次测试版本打好标签，并记录全局版本
号T 。
2紧急版本更新工作流程
1. 开发组提出紧急更新申请。
2. 版本组基于紧急更新对应的生产版本创建紧急更新的开发分支，
如：./branches/dev_patch/crm_vX.X.X_20131030_p01/。
3. 开发人员基于紧急更新开发分支进行开发，自测通过后提交到紧急更新
开发分支。
4. 版本组部署紧急更新编译环境，记录版本号X ，编译成功后发布到测试环
境。
5. 测试组进行测试，若发现问题通知开发修改，重复3~5步骤，直至测试
通过。
6. 测试完成版本组进行封版，为紧急更新分支打好标签，并记录该补丁版
本的全局版本号Z 。
7. 模块合版人员将本次紧急更新所涉及的修改代码合并到trunk 主干版本，
务必保持主干版本代码与发布的版本一致。