产品研发流程说明

经过几个月的测试工作，根据实际的情况，将流程做了更新，完整如下：

流程图：

step 1 需求评审

• 产品经理从各个渠道获取需求，输出一份初步的需求分析(.doc或者pdf格式),通过禅道项目管理软件管理需求,将需求结构化、可追踪。
• 需求确定之前要经过开发、测试团的评审通过，再将文档完整化输出。
• 需求在禅道中的主要是通过产品-需求这两个维度来管 理，产品是指大的产品线，如pad,web端这种粒度，需求的粒度如绩效管理、收银功能这种粒度。

产品

产品

需求

需求

step 2 确立项目

• 评估工作时间：
  ** 设计同学 **评估设计需要工作量；
  ** 开发同学 **将需求切到更细的力度(页面+接口)，评估工作时间，单位是小时；
  测试同学根据项目设计开发评估的工作量评估测试时间。
• 确定提测时间（code complete）和上线时间，可通过邮件进行，产品经理根据评估的时间确立项目，创建** 发布计划** ，对应禅道的项目管理，从项目(对应产品或需求)-任务(需求切分成任务)维度进行管理：

项目关联产品

项目列表

项目关联产品

关联需求后可以将需求分解到任务级别：

需求分解为任务

* step3.测试编写测试用例*

在对应禅道中的测试模块制作测试用例:

测试模块

用例

* step4.测试用例评审*

完成测试用例后，测试发邮件邀请开发和产品进行测试评审，评审需提出意见。测试修改测试用例完毕后，请开发和产品邮件确认修改后的用例。评审通过备注来写意见。

添加备注

完成备注

step5.开发开发功能，持续交付体验

如果开发周期过长，可以在测试环境持续交付(可选)。开发在开发过程中需要不断的更新任务进度：

工时消耗

完成进度

项目进度

step6.开发自测，产品体验

1. 开发完成所有任务之后，必须按照测试用例自测完毕后才可以提交体验申请给产品。必须输出自测报告。
2. 产品收到开发的自测报告后，进行产品体验。必须输出体验报告。

测试会对体验报告进行评估，方法如下：

• 若测试发现产品的主逻辑不能走通，需求未能满足，该项目开发人员、产品经理的下一个项目的测试优先级都会下降。

step7.提测

1. 开发必须收到体验报告，并且开发修改完毕体验问题 。
2. 产品进行体验问题验收，验收标准必须邮件表明通过。
3. 如果有需求变更，产品、开发和测试一起重新评审新的修改点。
4. 开发写测试申请给测试人员，并附带产品体验报告和产品声明体验通过的邮件
5. 如果提交测试延期，测试需要按时发邮件并抄送相关负责人问清情况，并且在本周测试周报进行记录。

测试会对提测进行评估，方法如下：

• 若提测延期，该项目开发人员、产品经理的下一个项目的测试优先级会根据情况下降。

step8.测试执行，提交bug

测试开始执行测试用例，如果通不过对应用例则提bug给开发。

执行测试用例

提交bug

step9.开发修改bug，测试输出测试报告

1. 测试跑完测试用例后，向开发提出bug修复邮件。
2. 开发修改完所有的bug，通知测试进行bug验证。
3. 重复1、2，直至要解决bug为0的状态。
4. 此时测试将产品交与运营进行体验，运营提出体验问题，邮件输出和产品进行沟通，如果本版需要解决，则提出需求变更，回到step7
5. 通过运营体验后，bug存量为0，再次输出测试报告，测试报告按模版进行，并指出延期解决的bug

step10.开发拉发布周知群

开发拉发布周知群，需要产品leader、开发leader、运维leader（前期访问量不大可能不需要）、测试leade r、运营leader分别同意后方可发布外网。

• 开发需要在产品经理创建的发布计划中，描述清楚发布步骤、发布策略、影响模块、预计用户量、出错回滚策略等内容。
  
  

  15.jpg
• 产品需要整理出版本使用说明书或者版本升级模块说明，hotfix需要版本修复说明，整理完毕后发送给运营
• 测试需要关闭所有解决的bug，并记录延期bug，并给于说明，整理完后发送给产品、运营（运营也可有由产品统一发送）

step11.开发发布产品，测试进行线上产品验证

测试输出验证报告（通过or不通过）

hotfix发布：

• 开发修复bug后，测试进行验证，需输出验证报告。
• 开发收到测试的通过验证报告方可进行hotfix发布。
• 测试记录hotfix发布更改信息给产品、运营。
• 开发需要将hotfix修改代码合到开发环境，此处测试要记得提醒开发。

bug管理说明：

为能够给开发建立一个清晰的修复bug环境，测试和开发需要共同配合：

• 测试需要提出清晰有效的bug，对前端提出的bug要进行及时管理并和相关开发沟通好
• 开发在解决完bug后，需要对bug进行处理，如改变状态为“已解决”
• 测试验证完bug，发现bug不存在，则对bug进行关闭

环境部署说明：

• 开发环境，每个开发都有自己的开发环境。功能和权限：仅供拥有权限的开发进入
• 测试环境，测试人员唯一使用的环境（包括开发完后的测试和bug验证等）。该环境下的代码要确保为最新的线上代码和即将发布的功能代码，每次发布到正式环境之前必须通过的环境。
• beta环境，预发布环境
• 线上环境，测试验证完毕的最后代码，由测试人员push给运维，运维推送上线

PS：

所有要输出的报告都有模版，如果你“比较懒”的话，建议使用o(∩_∩)o ~