序
本文分为四部分：版本规划、任务拆解和执行、代码版本管理、质量管理。
版本规划阶段
产品负责人、项目经理（假设有的话）应确定版本目标和明确版本迭代的几个时间节点的任务。
任务拆解和执行
在项目实现的各个阶段，每个角色的任务和职责。
代码版本管理
技术负责人创建迭代，管理不同的代码分支和代码评审。
质量管理
明确测试的任务，测试用例、缺陷单的规范管理。
版本规划
确定版本目标与时间计划
- 项目经理和产品 leader 确定 V1 阶段、V2阶段功能目标，然后再确定V1阶段，各功能优先级，输出需求列表，创建迭代、父需求单。
- 产品leader拆解任务创建子需求单，标记优先级。
- 项目经理和产品leader确定版本各个预期时间节点：封版、测试、提交审核、上线。
- 汇报老板审核（建议与技术负责人先沟通）。
- 建议版本时间<实际所需时间，预期时间（也是对外时间）>实际所需时间。
任务拆解
- 分配具体需求单给产品、UI设计、开发、测试，同时确认实际版本规划时间。
- 该版本所有需求交互完成评审后，可以着手规划下个版本需求。
封版
- 封版要求
要求当前迭代的所有需求都已实现，开发联调自测通过并提测。
- 各个需求负责人、测试也应关注自己所负责需求的进度。
- 封版后，不允许再合入新的需求代码。
- Bugfix代码不受这个时间约束。
- 风险以及规避方法
为保证需求按时完成，测试管理人在封版前n天（根据需求量、版本迭代时间调整），每天确认需求提测情况和测试情况，及时同步风险给项目经理、产品leader、技术负责人，调整人力分配、需求迭代时间、测试时间和内容，确保需求的研发、测试按时完成。
集成测试
- 启动条件
需求测试已完成，并且所有致命、严重问题已修复，遗留问题已周知开发
- 产品leader发布体验版本给内部同事进行体验，各个需求测试人员跟进所负责模块的反馈，同步研发进行修改，重点需求还需由产品leader确认修改逻辑。
- 如有重点需求需要给内部领导层体验
在交付体验版本前，测试迅速过“小集成”，即小程序重点场景、重点需求主要场景
交付体验后，需求负责人跟进反馈结果，同步研发修改，如有重要逻辑修改，需要同步产品leader和项目经理。
提交审核
- 启动条件
用例全覆盖、无未处理bug单、致命和严重问题都已修复。
- 技术负责人负责提交
- 审核负责人（技术负责人或者产品leader）跟进审批情况
- 风险以及处理
如有审核问题，及时同步项目经理、有问题的模块负责人，进行修改。
上线
- 项目经理或者产品leader确认上线
- 上线后，测试迅速在生产环境测试重点场景
- 风险以及处理
上线后如有问题及时反馈项目经理进行回退，并周知技术负责人、产品。
任务拆解与执行
分配任务，输出交互图
- 产品leader流转需求单给需求负责人，状态为“新”
- 产品leader分配子需求单给产品A、产品C或者其他产品，同时确认交互图、文案、需求说明书交付时间。
- 需求负责人需明确自己所负责需求的逻辑、时间节点、优先级。
需求评审
- 需求负责人交互图、文案输出后，同步产品leader、技术负责人（包括前端和后台，同下文）、测试管理人，约定评审时间。
- 为快速完成评审，应合理安排评审计划，建议优先级高的先过。
- 评审内容
- 产品leader确认交互图、文案是否符合预期，并且和开发、测试确认实际研发、测试所需的时间和人力，根据需要调整版本发布计划。
- 技术负责人确认需求优先级、需求后续变更的可能性、实际研发所需时间、需求逻辑是否可实现、版本规划。
- 测试明确需求优先级、产品逻辑、测试项目（功能、接口、性能）、测试时间、版本时间规划。
- 需求负责人明确UI图交付时间，会后快速整理修改最后的产品交互图，交付UI设计师并跟进UI设计进度和质量、同步技术负责人和测试负责人。
开发实现
- 需求负责人流转需求单为“实现中”，分配单给技术负责人和测试管理人。
- 技术负责人创建版本迭代，管理代码（代码版本管理详细可见章节三）；分配需求单给具体的开发，并且需求单上增加该负责人；技术负责人应关注UI图设计进度，UI设计图交付后，分配前端任务。
- 测试管理人分配需求任务给测试员，并且需求单上增加该负责人；同步产品交互图，开始设计测试用例，前端UI设计图出来后，增加UI测试用例（质量管理详细可见章节三）。
- 需求负责人、前端研发、后台研发、测试敲定需求的具体时间。
代码审查合并
- 需求实现后，前端和后台联调并且自测通过后，申请提交代码到merge分支，等待技术负责人审核、确认合入，并且流转单状态为“待合入”
测试
需求测试
- 代码合入后，开发流转需求单流转为“待测试”。
- 测试员与开发确认除了功能测试是否还有其他特殊测试需求后（例如兼容测试），开始测试，流转需求单为“测试中”，如有问题，提交bug单（详细bug单规范见章节四）
- 需求负责人（产品）验收需求实现是否符合预期：UI、体验、主要功能，如有问题提交bug单进行修改。
- 测试结束，并且严重、致命问题均已修改，测试员流转需求单为“已测试”，同步开发提交代码到主干，等待过集成。
集成测试
- 测试范围
主要场景、需求改动的代码相关的场景、需求主要场景，跟开发确认是否有补充测试需求；测试发现问题提交bug单，并跟进处理。
- 内部体验，测试跟进所负责需求的问题。
- 如有给领导体验的需求
在交付前，测试人员应先快速测试一遍主要场景，确保交付可靠产品
需求负责人跟进反馈意见，确认是否需要修改后，提交bug单给开发进行修改。
上线
- 上线条件：用例已全覆盖、无未处理bug单，严重、致命问题均已修复，遗留bug周知开发和技术负责人、测试管理人。
- 技术负责人提交上线版本，项目负责人跟进审核进度，审核不通过时及时同步产品、技术负责人、测试管理人进行修改。
发布
- 项目负责人确认上线。
- 测试人员快速测试生产环境中的产品
如有严重问题及时同步项目负责人回退版本、同步技术负责人、需求开发人进行修复。
- 测试人员流转需求单状态为“已上线”
代码版本管理
- 技术负责人收到迭代计划后
创建对应的迭代版本，并且周知开发基于该迭代开发、合入需求
活动需求基于现网版本代码进行开发和测试。 - 技术负责人制定代码规范，统一编码要求
- 创建test、merge、主干分支(至少)
Test：体验和开发自测
Merge：需求合入分支。需求完成开发后，提交到这个分支上，技术负责人审核后，合入代码，测试在这个分支上进行需求测试，产品进行体验测试，同时也是提交到小程序管理后台的“开发版”
主干：集成和内部体验测试。需求通过主干分支的需求测试后，才能合入。提交到小程序后台“开发版”，测试通过后，技术负责人提交审核
质量管理
用例设计
- 测试管理人分配需求任务并明确用例输出时间，测试员领取交互图、版本发布计划、UI图输出时间、技术设计文档输出时间后，开始用例设计。
- 完成用例设计并且自我完善后，邀请测试管理人、产品、开发进行评审；评审结束，修改后上传用例到用例库。
- 用例应有清晰的输入和预期输出。
- 测试用例可能使用工具：xmind
- 如项目实施过程中，有突发情况无法进行详细用例设计时，应先划分模块，设计主要路径的测试用例；实际实现与预期相差较大时，应先与产品确认，并做好记录。
- 项目初期集成测试用例无法先行设计，在需求测试后，再设计用例，并后期迭代中完善。
- 测试结果后，归档测试用例，完善集成用例（每次迭代时，测试的内容）
Bug管理
- Bug流转：
- 新-接受/处理-已修复-验证修复，关闭（正常bug处理流程）
- 新-接受/处理-已修复-重新打开（验证未修复）
- 新-已拒绝（不是bug或者不符合提单要求）
- 新-挂起/后期处理
- Bug内容
- 复现步骤、复现时间、账号、截图或者录屏、机型、必要时提供日志、发现版本、迭代、需求单号或者标记为集成、严重程度、处理人、当前状态
- 复现操作（或者发送参数）、截图或者（小程序）录屏、接口返回、关联需求、严重等级、发现阶段、软件平台、处理人
- 严格按照bug模板提交，减少沟通成本
- bug提交后，测试需要跟进bug进度，push开发尽快解决
- 划分bug严重程度，严重问题必须在发版前解决
- 非严重问题，可以延后处理，但是要和开发确认后续修复时间，并且同步产品遗留bug，bug备注遗留原因和修复排期
测试
- 跟进开发进度，推动需求提测：晨会、甘特图时间节点、日常代码合并事件等
- 需求测试：测试点为需求，以及产品体验后的变更，集成前要完成需求测试，并且所有bug单都要处理完
- 集成测试：测试点包括所有需求合入后，测试需求改动相关的模块和主要功能：启动、登录、注册、常用场景，以及内部体验后的变更。
