关键词：
目的:
由于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项目里程碑管控参考--开发视角
...线容易产生大量问题,故为此类项目的开发工作提供指导里程碑(以40个工作日为标准): 准备阶段目的:完成项目前期调研，明确项目的核心业务需求和定位，确定系统技术方案选型，负责人完成核心功能论证。持续时间... 查看详情
中型研发组织管理--项目管理
...f09;Master传帮带--敏捷1.0项目流程1.0项目MVP阶段时间规划和里程碑规划1.0项目里程碑管控参考--开发视角1.0项目里程碑管控参考--测试视角1.0项目 查看详情
1.0项目里程碑管控参考--开发视角
...线容易产生大量问题,故为此类项目的开发工作提供指导里程碑(以40个工作日为标准): 准备阶段目的:完成项目前期调研，明确项目的核心业务需求和定位，确定系统技术方案选型，负责人完成核心功能论证。持续时间... 查看详情
中型研发组织管理
...f09;Master传帮带--敏捷1.0项目规范1.0项目MVP阶段时间规划和里程碑规划1.0项目里程碑管控参考--开发视角1.0项目里程碑管控参考--测试视角1.0项目里程碑管控总表制度&罚则日常入职新成员入职须知试用期考核制度&导师制度培... 查看详情
中型研发组织管理
...f09;Master传帮带--敏捷1.0项目规范1.0项目MVP阶段时间规划和里程碑规划1.0项目里程碑管控参考--开发视角1.0项目里程碑管控参考--测试视角1.0项目里程碑管控总表制度&罚则日常入职新成员入职须知试用期考核制度&导师制度培... 查看详情
测试方案参考
...力安排必选 需要对方邮件或文档告知项目交付计划和里程碑 需要和负责的产品经理沟通上线时间点和紧急程度 需要和研发负责人确认日常工作的沟通渠道和频率编写测试计划(里程碑管控)必选所有1.0项目启动需要根... 查看详情
1.0项目里程碑管控总表
excel版表格下载：点击下载 查看详情
1.0项目里程碑管控总表
excel版表格下载：点击下载 查看详情
1.0项目mvp阶段时间规划和里程碑规划
...：研发组织管理--项目管理--1.0项目MVP阶段时间规划和里程碑规划环节启动阶段开发测试阶段上线阶段项目启动会需求讲解会需求确认架构设计评审业务领域评审核心初版开发（core迭代，迭代0）增量迭代1增量迭代... 查看详情
测试方案参考
...力安排必选 需要对方邮件或文档告知项目交付计划和里程碑 需要和负责的产品经理沟通上线时间点和紧急程度 需要和研发负责人确认日常工作的沟通渠道和频率编写测试计划(里程碑 查看详情
版本管理介绍
...的过程。这个过程里有每个项目的生命周期和各个功能的里程碑。一般会把这些周期和里程碑确定成一个个的版本，以便对整个项目实行历程的管理和阶段目标的控制。那怎样科学地管理项目的版本呢？接下来就讨论这个问题。... 查看详情
软件测试的模型
...只需要关注后续阶段③为项目提供按阶段划分的检查点，里程碑清晰④文档规范缺点：①难以适应需求频繁变化②强制的里程碑、完成时间点③项目周期后段才能看到结果④文档工作量大 2.V模型：需求分析->概要设计->... 查看详情
性能测试-4.性能测试理论知识1.0
...性、安全性、兼容性、可扩展性、可靠性等等。 性能测试用来保证产品发布后系统的性能满足用户要求。性能测试在软件质量保证中起重要作用，主要是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统... 查看详情
测试文档
...用例缺陷测试计划测试资源（人员时间安排）测试进度（里程碑）提交文档（交付件）测试风险完成标准测试方案测试目的测试范围测试工具和方法开始标准完成标准测试重点测试报告用例分类统计bug分类统计bug按严重程度统计... 查看详情
项目角色职责分配表
...计方案，确保产品设计符合客户要求 确保每个版本按里程碑约定准时提交给质量保证团队组建项目团队， 查看详情
bjqa-iiatf1.0框架之《自动生成有效请求json串》
2017年7月28日，今天是一个里程碑的日子，根据参数及数值通过结对有效算法自动生成字典形式的测试用例功能模块完成，鼓掌，鼓掌！替换postdata模板内指定元素值的代码如下：1importcopy2importcreatePWtestcase3dicta={4"H":{5"ACID":"aaaaa",6"... 查看详情
项目群管理
项目群的关键里程碑必须是每个子项目的关键里程碑，每个子项目的里程碑务必不要都设置为和项目整体里程碑同一个时间点，能够提前的尽量提前，这样对于子项目里程碑能够提前的就已经具备了一定的关键链中的缓冲时间。... 查看详情
浅谈项目群管理
项目群的关键里程碑必须是每个子项目的关键里程碑，每个子项目的里程碑务必不要都设置为和项目整体里程碑同一个时间点，能够提前的尽量提前，这样对于子项目里程碑能够提前的就已经具备了一定的关键链中的缓冲时间。... 查看详情