1.0项目里程碑管控参考--测试视角
Posted 杨不羁
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了1.0项目里程碑管控参考--测试视角相关的知识，希望对你有一定的参考价值。
目的:
由于1.0项目/2.0项目的需求复杂, 开发上线周期长, 变更多, 初次上线容易产生大量问题, 故为此类项目的测试工作拟定测试方案供指导
里程碑(以40个工作日为标准):
启动阶段 | 目的: 对项目整体测试相关工作进行必要的评估和计划, 并且对需求的理解和整个团队达成一致 | 持续时间: 5个工作日(以项目总时间12.5%评估) | ||
| 前提条件 | 测试具体工作内容 | 时间表 | 输出或完成标志 | 备注 |
|---|---|---|---|---|
| 开发测试人员配置满足项目基本需求 | 参与项目启动会 | 第1天 | ||
| 项目有原型文档(功能页面>80%) | 参与需求讲解会 | 第2天 | ||
| 所有功能有对应的行云卡片(覆盖>80%功能点) | 评估测试工作量(粗略) | 第3天 | 将测试工作量填入每个行云卡片中 | |
| 测试和产品1V1详细确认每个卡片的功能边界 | 细化功能边界 | 第3天-第4天 | 督促产品将功能边界填入卡片和原型文档 修正测试工作量 | |
| 产品经理提供明确的上线时间及确定的上线功能 开发和测试对需求卡片完成工作量最终评估 | 拟定提测时间线和发送测试计划 | 第4天 | 以上线计划为模板, 所有story都需要在行云中用卡片记录 | |
| 卡片P0用例设计 | 第5天 | 将卡片P0用例填入每个行云卡片中 | ||
| Core迭代功能交付规划已确定 | 主干流程P0用例设计 | 第5天 | 通过邮件发送整个应用的主干流程P0用例(UI+接口合并覆盖) |
|
| 可测性需求准备 | 第5天 | 例如暴露内部接口, 前端添加id, 测试账号准备, 域名映射等 | ||
Core迭代-1 | 目的: 确保测试工作的启动项目准备完成 | 持续时间: 5个工作日(以项目总时间12.5%评估) | ||
| 前提条件 | 测试具体工作内容 | 时间表 | 输出或完成标志 | 备注 |
|---|---|---|---|---|
| 测试方案设计和评审 | 第6天 | |||
| core迭代30%接口文档提供并完成评审 | core迭代30%接口的自动化 | 第6天-第8天 | ||
| core迭代30%接口文档提供并完成评审 | 对接口中有性能测试和并发性测试需求的接口做测试计划和脚本(批次1) | 第6天-第8天 | 完成批次1接口的部分脚本(50%) | |
| 搭建测试环境 | 第6天-第8天 | 独立可用的Linux服务器, JCI任务及对应脚本部署(完成测试环境测试账号, 入口, 域名, 登录, 前端静态文件等基本配置的确认) | ||
| MVP测试用例设计 | 第6天-第9天 | 覆盖所有行云卡片需求的详细测试用例及步骤, 需要以xmind文档发送 给团队, 等待评审 | ||
| 测试用例设计完成 | MVP测试用例评审 | 第10天 | 测试组织测试用例评审会, 参与人: 产品经理, 研发团队 | |
| 开发提供项目可运行项目框架代码 | 测试环境预部署 | 第10天 | 测试利用JCI将项目部署到测试环境, 确认部署成功无错误及环境异常 应用可正常运行及展示 | |
Core迭代-2 | 目的: 测试 + 确保代码的辅助环境配置都正常运行 | 持续时间: 5个工作日(以项目总时间12.5%评估) | ||
| 前提条件 | 测试具体工作内容 | 时间表 | 输出或完成标志 | 备注 |
|---|---|---|---|---|
| core迭代60%接口文档提供并完成评审 | core迭代60%接口自动化编写 | 第11天-第13天 | ||
| core迭代30%接口自动化运行 | 第11天-第13天 | |||
| core迭代60%接口文档提供并完成评审 | 对接口中有性能测试和并发性测试需求的接口做测试计划和脚本(批次2) | 第11天-第13天 | 完成批次2接口的部分脚本(50%) | |
| 完成批次1脚本(100%) | 对批次1的接口进行并发性测试 | 第11天-第13天 | ||
| core迭代部分卡片(后端+前端)提测(20%) | 完成core迭代1阶段测试 | 第11天-第15天 | ||
| core迭代30%接口提测 | 完成core迭代1阶段测试 | 第11天-第15天 | ||
| core迭代部分卡片提测(20%) | 主干流程P0 UI自动化编写(1个) | 第13天-第15天 | 启动UI自动化脚本编写 | |
| 测试环境搭建完成 | 设置测试环境持续部署功能 | 第15天 | 可以通过持续部署工具部署测试环境 | |
Core迭代-3 | 目的: 测试 | 持续时间: 5个工作日(以项目总时间12.5%评估) | ||
| 前提条件 | 测试具体工作内容 | 时间表 | 输出或完成标志 | 备注 |
|---|---|---|---|---|
| core迭代100%接口文档提供并完成评审 | core迭代100%接口自动化编写 | 第16天-第18天 | ||
| core迭代60%接口自动化运行 | 第16天-第18天 | |||
| core迭代100%接口文档提供并完成评审 | 对接口中有性能测试和并发性测试需求的接口做测试计划和脚本(批次3) | 第16天-第18天 | 完成批次3接口的部分脚本(50%) | |
| 完成批次2脚本(100%) | 对批次2的接口进行并发性测试 | 第16天-第18天 | ||
| core迭代部分卡片(后端+前端)提测(50%) | 完成core迭代2阶段测试 | 第16天-第20天 | ||
| core迭代60%接口提测 | 完成core迭代2阶段测试 | 第16天-第20天 | ||
| core迭代部分卡片(后端+前端)提测(50%) | 主干流程P0 UI自动化编写(10%视情况而定) | 第18天-第20天 | 取决于提测的功能是否前后端完整 | |
| 开发提供具体环境安排 | 督促开发搭建预发环境 | 第17天 | 完成服务器申请及JCI控制 | |
| 开发提供具体环境安排 | 督促开发搭建生产环境 | 第17天 | 完成服务器申请及JCI控制 | |
| 制定性能测试计划 | 第19天 | 输出性能测试计划 | ||
| 制定评估其他类测试计划 (需求收集+粗略执行计划) | 第20天 | 输出其他类测试计划 (除性能测试和并发性测试) | ||
增量迭代-1 | 目的: 测试 + 确保核心功能运行状态符合要求 | 持续时间: 7个工作日(以项目总时间17.5%评估) | ||
| 前提条件 | 测试具体工作内容 | 时间表 | 输出或完成标志 | 备注 |
|---|---|---|---|---|
| core迭代100%接口自动化运行 | 第21天-第23天 | |||
| 增量迭代1接口文档提供并完成评审 | 对接口中有性能测试和并发性测试需求的接口做测试计划和脚本(批次4) | 第21天-第23天 | 完成批次4接口的部分脚本(50%) | |
| 完成批次3脚本(100%) | 对批次3的接口进行并发性测试 | 第21天-第23天 | ||
| core迭代全部卡片(后端+前端)提测(100%) | 完成core迭代3阶段测试 | 第21天-第25天 | ||
| core迭代100%接口接口提测 | 完成core迭代3阶段测试 | 第21天-第25天 | ||
| core迭代全部卡片(后端+前端)提测(100%) | 主干流程P0 UI自动化编写(20%视情况而定) | 第23天-第27天 | 取决于提测的功能是否前后端完整 | |
| 确认其他类测试计划 | 完成其他类测试用例准备(100%) | 第26天 |
| |
| core迭代PO流程自动化展示 | 第27天 | |||
| 系统主干流程测试完成 | 核心功能运行展示 | 第27天 | 需要Boss参与评判, 产品确认业务逻辑符合需求 | |
增量迭代-2 | 目的: 测试 + 为上线做准备 | 持续时间: 7个工作日(以项目总时间17.5%评估) | ||
| 前提条件 | 测试具体工作内容 | 时间表 | 输出或完成标志 | 备注 |
|---|---|---|---|---|
| 增量迭代1 UI提测 | 测试 | 第28天-第30天 | ||
| 增量迭代1 接口提测 | 测试 | 第28天-第30天 | ||
| 增量迭代2接口文档提供并完成评审 | 对接口中有性能测试和并发性测试需求的接口做测试计划和脚本(批次5) | 第28天-第30天 | 完成批次5接口的部分脚本(50%) | |
| 完成批次4脚本(100%) | 对批次4的接口进行并发性测试 | 第28天-第30天 | ||
| 执行其他类测试 | 第31天-第33天 | 测试报告需要发送项目组 | ||
| 主干流程P0 UI自动化编写(30%视情况而定) | 第31天-第33天 | 取决于提测的功能是否前后端完整 | ||
| 参与预发环境预部署 | 第34天 | 确认部署成功无错误及环境异常应用可正常运行及展示 | ||
| 参与生产环境预部署 | 第34天 | 确认部署成功无错误及环境异常应用可正常运行及展示 | ||
| 包括批次1,2,3,4脚本 | 执行性能测试 | 第34天 | 基于生产环境 | |
上线阶段 | 目的: 确保上线前中后的质量 | 持续时间: 6个工作日(以项目总时间15%评估) | ||
| 测试具体工作内容 | 需要时间 | 输出或完成标志 | 备注 | |
|---|---|---|---|---|
| 增量迭代2 UI提测 | 测试 | 第35天-第37天 | ||
| 增量迭代2 接口提测 | 测试 | 第35天-第37天 | ||
| 主干流程P0 UI自动化编写(40%) | 第35天-第37天 | |||
| 完成批次5脚本(100%) | 对批次5的接口进行并发性测试和性能测试 | 第35天-第37天 | 基于生产环境 | |
| 线上全功能回归 | 第37天 | |||
| 完成所有非功能测试结果回顾 | 第35天-第37天 | 其他类测试没有任何不可延后修复bug | ||
| 主干流程P0用例接口自动化每日部署后运行 | 第35天-第40天 | 每日运行通过 | ||
| 主干流程P0用例UI自动化每日部署后运行 | 第35天-第40天 | 每日运行通过 | ||
| 联系好批量用户试用, 确认试用 账号和用例 | 批量用户试用安排 | 第35天-第40天 | 保证没有任何不可延后修复bug | 由于测试对系统的测试方法已检查功能为主, 和最终用户对系统的使用方式习 惯有一定的区别, 在系统预上线后, 需要一定量的最终用户 (包括业务负责人,产品经理) 对系统进行自助试用, 用户量尽量达到最终使用量的5-10%.
|
| 上线 | 第40天 | 上线后回归测试通过 | 以2个月(40个工作日)为总研发上线时间为标准 | |
| 上线完成 | 上线现场支持安排 | 第40天 | 上线日1周内 | 由于用户对新系统的使用可能会有疑问点, 不一定所有提出的问题都是系统缺陷, 为了避免聊天工具沟通的缺陷, 建议安排团队成员在上线当天在用户现场进行使用指导和答疑 |
以上是关于1.0项目里程碑管控参考--测试视角的主要内容，如果未能解决你的问题，请参考以下文章