测试流程版本管理规范
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
测试流程、版本管理规范
编制:
审核:
批准:
文件历史记录
目录
测试流程、版本管理规范 (1)
1.目的 (2)
2.适用范围 (3)
3.测试流程规范 (3)
3.1搭建环境 (3)
3.2冒烟测试 (3)
3.3禅道版本管理规范 (3)
3.4系统测试流程规范 (4)
3.6 缺陷管理流程 (5)
3.4上线版本 (8)
4.系统版本管理规范 (10)
1.目的
为了规范项目组的测试流程、版本规范,减少人为影响上线版本的质量
2.适用范围
项目组所有系统以及流程的版本
3.测试流程规范
3.1搭建环境
缺失本次版本变更说明或者部署文档不完整,需向开发人员说明,并要求提供齐全,保证文档有效性。
3.2冒烟测试
➢环境搭建完后,进行冒烟测试,如果冒烟测试不通过,需打回版本
➢如果未实现需求涉及的功能,打回版本(除非开发人员有说明按模块提交测试)
3.3禅道版本管理规范
产品
➢接到新的系统时,首先在产品模块新建产品名称,命名规则直接以系统名称为准,比如“移动OA”
➢产品新建成功后,需要把需求关联至产品,可以直接把文档或者git地址关联进来
项目
➢新项目或者目前版本的变更时,需要新建项目,项目需要关联产品,命名规则直接以版本名称为准,比如“移动OA3.0”
➢项目新建成功后,开发提交一次版本,需要把版本号进行维护,版本号命名规则。如“移动OA3.0_rc1”,以此类推,每一轮测试时,如果仍存在BUG,需要把下个版本号提前维护进来,方便开发变更BUG状态时,选择正确的版本号
测试
➢项目的模块需要分类维护,测试用例对应到模块下,每一轮测试完毕后,需要变更测试用例状态,并把测试用例与BUG进行关联
➢在测试过程中,如果测试用例有遗漏,需要补写
➢每一轮测试结束后,需要出测试报告
3.4系统测试流程规范
3.5 缺陷管理流程
3.5验收测试流程
3.7上线版本
测试结束后,需要把待上线的版本、部署文档、更新说明迁移到发布目录,进行封板。
4.系统版本管理规范
➢所有提测版本均需要上传到GIT,按照RC版本来区分
➢原则上如果不存在重大问题导致流程无法流转,需在第一轮测试完毕后才能发布RC2 ➢发布新版本后,需要在禅道中维护上新版本,提交的BUG需要关联到版本号
➢为了防止版本未合并,需要在新版本上验证上个版本新增的功能是否涵盖