主线版本软件测试入口条件
序号 |
检查项描述 |
衡量标准 |
备注 |
首轮提测 |
|||
1 |
产品规划路标是否基线 |
已通过评审并发布 |
如有变更,则重新评审发布,并须评估对当前项目影响,出具影响分析报告,产品经理 |
2 |
产品需求规格是否基线 |
已通过评审并发布 |
需求中需要明确需求分类,比如那类需求是与竞聘PK需求,哪些需求是用户个性化需求,哪些是功能补充需求等 |
3 |
产品总体设计是否基线 |
已通过评审并发布 |
|
4 |
软件需求规格是否具备 |
已通过评审并发布 |
软件需求规格应该详细说明,能拆分出测试点 |
5 |
软件总体设计是否具备 |
已通过评审并发布 |
若项目组规划无此文档,可忽略 |
6 |
软件概要设计是否具备 |
已通过评审并发布 |
若项目组规划无此文档,可忽略 |
7 |
产品(软件)功能清单是否具备 |
已通过评审并发布 |
功能细化需求、功能间关系图 |
8 |
联调用例是否具备 |
已通过评审 |
|
9 |
联调报告是否具备 |
已通过评审随提测版本发布 |
验收代表(产品经理、需求总体、质量代表、测试代表、开发代表)按照联调用例验收通过并签字确认 1、首轮提测:全功能验收 2、需求变更(引起联调用例变更):重点验收变更需求点,其他未变更需求点有开发进行评估分析是否需要验收 项目涉及网元多,联调规模大时,联调报告需评审 项目涉及网元单一,联调规模小,建议由网元开发代表对联调报告负责 |
10 |
环境部署指导说明书是否具备 |
测试部严格按照说明书可完整部署测试环境 |
环境部署指导说明书由研发撰写 |
11 |
配置清单是否具备 |
提测前输出,并在项目组确认通过 |
1.提测软件清单及版本匹配关系表 |
12 |
各网元是否完成了新增功能对老功能影响分析,并输出相关文档,供测试参考 |
出具新增功能对老功能影响报告 |
需求有增加、修改、剔除,须走需求变更 开发需要对当前提测版本与上一版本进行差异性分析,并输出分析报告附加在release Notes中 |
13 |
如有第三方产品,须提供第三方产品规格说明或同类文档,并产品软件上传至SVN |
|
如果第三方是硬件产品,需提供入库质量验收报告 如果没有,由项目组协调处理第三方相关问题 |
14 |
《软件测试方案》、《软件测试用例》、《测试工具及脚本》 |
通过评审 |
《软件测试方案》:在提测之前完成评审 《软件测试用例》:提测前完成评审 《测试工具及脚本》:完成规划工具的开发 |
15 |
提测产品的硬件和结构须与发货版本一致,并保证测试数量 |
|
|
非首轮提测 |
|||
1 |
在首轮提测基础上,新增软件修改说明及影响分析 |
输出修改文档,上传svn |
写在release notes里 |
2 |
出具软件需求变更报告 |
提测前完成,评审通过 |
如果需求无变化,可忽略。需求变更应谨慎,切忌出现重大需求项变更 |
3 |
最新软件测试策略及计划 |
提交项目组评审通过 |
依据上一次测试执行结果,结合最新提测需求进行相应测试策略和测试计划变更 |
维护版本软件测试入口条件
维护版本在满足主线版本的提测条件之外,研发需要单独提供该版本修改点及影响分析,并提供自测报告;测试需要提交针对性测试方案及精简后测试用例,并通过项目组评审。
- 项目计划或提测计划至少提前7天通知测试(重要保障期间可特批)
- 填写并提供维护版本说明,分析影响,自测情况
- 研发与测试、项目经理/产品经理根据版本具体情况共同分析和确认测试项、测试策略、测试用例。
定制版本软件测试入口条件
定制版本主要表现为在主线版本上增删改需求项、在维护版本上增删改需求项等形式。
定制版本需要同时满足主线版本及维护版本测试入口条件。
快反版本软件测试入口条件
快反版本需要提供主线版本入口条件中所需文档,但无需通过评审,项目组需要单独提供快反版本主要关注功能点及测试范围。(视后期项目实际情况,进行简单测试)。