完整研发流程 需求阶段 需要注意的问题 开发阶段 需要注意的问题 测试阶段 需要注意的问题 上线阶段 需要注意的问题 推荐阅读 完整研发流程
流程中标红的部分是平时比较容易忽略的节点，需要重点关注！！！
需求阶段
负责人：PM
里程碑节点：需求评审
需求评审参与人员：该需求所有参与人员，PMRDFEQAUI 需要注意的问题 1. 由于UI资源是各组公用的，所以建议在需求方案确认之后，PM就尽快联系UI妹子 沟通需求，并确定UI图的产出计划和交互，以便UI妹子能协调好自己的工作，最好能 在需求评审之前完成所有UI图的产出和确认，并更新至MRD中；如果由于各种原因 协调不开，至少要在需求评审之前确认出交互逻辑和UI图的产出计划，保证不影响后 面FE同学们的设计和开发，也避免出现由于交互设计导致FE同学估排期出现偏差，进 而导致的项目延期； 2. 在公开进行需求评审之前，建议先找相关技术同学（RD&FE）过一下需求内容， 尤其是大需求，避免由于需求设计不合理导致的需求评审时间过长或需求评审多次， 进而导致的项目延期； 3. 需求评审尽量一次通过，且要在前期做好充足的准备，比如上面提到的1和2的问 题，尽量控制需求评审的时间，保证需求评审的质量。如果在需求评审中出现了较大 的问题，建议暂停，讨论清楚之后再发起会议。禁止在需求评审时过度发散讨论，甚 至是技术设计细节的讨论，记住需求评审的核心是了解需求，讨论需求设计是否合理 和全面！！！ 4. 需求文档在需求评审之后，需要根据大家提出的问题做更新，并在文档中标记出， 且PM需要保证同步给所有需求参与人员，避免后期出现信息不一致的问题！且在需
求的整个研发过程中，MRD都要持续维护，并保证确实同步给所有参与人员，保证 大家的理解一致性。还有，要注意图文一致！！！ 5. 需求评审完成之后，需要在禅道中建立对应项目，并将对应团队人员加入进来，参 见项目立项后的操作 6. 需求文档编写完成之后，由PM建立该需求的钉钉群，将所有参与人员拉进来，并 且把文档提前发出来，让参与人员能够提前了解需求的内容，便于在过方案或者需求 评审时能够提出更多有意义的问题，而不仅仅是接受当前需求的内容，尤其是大需 求。 7. 为了上线后期对于用户使用情况的观察，所有需求需要在MRD里面包含数据埋点 的说明，如果特殊的小需求不需要埋点，也需要标明“无需数据埋点”； 8. 需求中如果出现APP字眼（注意：推送、页面跳转等细节点），最好提前找APP组 的同学过一下，确认有没有APP的改动。 开发阶段
负责人：RD&FE
里程碑节点：设计评审、用例评审
设计评审参与人员：PMRDFEQA
用例评审参与人员：PMRDFEQA 需要注意的问题 1. 设计评审需要达到的目的是： a. PM、RD&FE、QA确认三方需求理解的一致性 b. RD和FE各自讲解自己的设计，包括接口、表结构等变动 c. RD和FE各自的排期，为了保证排期合理，最好能列出任务的拆 分方式以及每部分的排期计划，排期时除了正常的需求内容开发， 不要忽略洗数据、联调和自测几部分的时间 2. 用例评审需要达到的目的是： a. PM、RD&FE、QA确认三方需求理解的一致性 b. QA讲解自己的用例设计 遇到较大的需求，用例评审时间较长时，可以合理安排，有针对性的给对应人员讲解，保证
评审的效果 3. 若需求中有涉及到洗数据的部分，需要注意： a. 设计时需考虑洗数据的部分具体实现方式，是sql洗还是程序洗， 是否需要断服等等，以便测试人员在准备洗数据部分的用例时能更
有针对性，以及在测试环境提前准备好数据。 b. 在测试环境洗数据之前需要和对应的测试人员沟通好，避免反复 多次洗数据。 c. 非特殊情况下，洗数据无论是用何种方式，都需要具备反复多次 洗的能力，避免出问题之后再次验证时麻烦！！！ d. 在预发布环境使用之前需要联系op同学同步一次线上数据库，如 果验证洗数据的部分造数据工作量较大，需要让测试同学提前在线 上造好数据之后再同步线上的数据库，这样就能省去一次造数据的 时间 e. 在预发布环境洗数据时，需要记录一下每个洗数据的步骤都花费 多少时间，帮助判断对线上用户的影响大小 f. 在洗数据之前提醒OP同学备库！！！ 4. 设计评审完成之后RD或FE从薪人薪事中申请“测试环境申请”（参见测试环境使 用流程），想要知道当前各环境的占用情况，请参见RD使用中的测试环境与版本分 支，如果rpc接口有变化，则需要在该文档中标出libjava的版本号，避免多个需求并 发时上线有冲突 5. 提测流程参见测试流程规范，其中的“提测流程”部分 6. 开发过程中需要注意的是： a. 分支的使用：设计评审完成之后，在git上新建自己的分支，并 且在测试环境分配下来之后，使用jenkins部署在对应测试环境 中，即可开始开发；在一轮测试完成之后，按照以下“周期上线规 则”确定最近可上线的时间，将自己需求的上线清单放在对应日期 的项目上线单目录中（项目上线单），并和当天一起上线的其它需 求一起合并到名为“sprint-日期”（如sprint-20180810）的分 支名下，在预发布和灰度环境使用该分支进行部署，在灰度测试完 成之后，再将sprint分支合并至master并发线上环境，禁止提前合 并至master，避免其它hotfix上线时直接将未测试完成的代码带上 线！！！同时注意，在预发布测试期间，为了保证代码兼容线上最 新发布的功能，要每天定期合并master代码！！！ b. 在需求开发过程中，需要关注期间的每次上线，需要在每个功能 甚至是hotfix上线之后及时合代码，由于上线较频繁，建议每天早
上来了先拉取最新的master合并到当前开发的分支上，避免最后上 线前合代码的痛苦，以及避免最后上线前合完代码，而测试已经没 有充足的时间走一遍全流程，风险比较大。 c. 若需求有表结构变化或者有sql洗数据的设计，则需要在对应工程 的sql/database_structure/对应日期目录下新建自己的sql文件， 比如： waves/sql/database_structure/2018Q3/20180807_company_ modules_setting.sql 保证大家能够在功能上线之后拉完master代 码后能正常运行 d. 测试环境相关文档参见docker测试环境使用指南、非docker环 境使用指南，阿里云测试环境jenkins地址 http://60.205.107.75:8999，腾讯云测试环境地址 http://192.144.199.76:8999/，若需要添加用户，请联系孟蓝茹 e. 对于大需求上线，需要给对应review代码的责任人留出充足的时 间，不要草草了事 f. 需求中如果有表结构变化或者有sql洗数据的设计，需要在预发布 环境操作时，记录每个sql花费的时间，如果sql能够提前执行对线 上用户不会造成影响，可以在上线前一天晚上执行，避免白天执行 时影响用户使用 g. 在提测之后一轮测试完成之前，需要提前准备好上线清单，交给 OP进行预发布环境及线上环境部署所用 测试阶段
负责人：QA
里程碑节点：测试环境一轮测试完成、预发布测试完成 需要注意的问题 1. 严格按照开bug的规范来做，在开完bug之后保留现场，禁止出现极其简单的bug 描述，至少要讲清楚“什么地方的什么功能怎么不好使了”，提供日志、接口返回 值、现象报错截图、报错账号等尽可能多的信息，参见提bug标准； 2. 开发人员按照bug描述去寻找问题，如果出现信息不全、描述不清楚的找对应测试 人员了解详细信息，禁止出现bug描述清晰，但仅仅是懒得看而一遍遍去找测试人员 复现bug，这样不仅影响了测试人员的工作效率，更影响了整个项目的上线进度；
3. 不要陷入需求中“难以自拔”，还需要考虑到权限、版本&功能开关、分子公司、 员工状态、老用户&新用户等系统横向功能点（可参考测试用例设计），还有洗数 据！！！对于洗数据，需要提前设计好用例和数据，并且一定要和开发沟通洗数据的 规则，便于设计用例； 4. 对于测试范围不明确的时候，禁止根据描述随意猜测，很容易导致测试范围不准或 测试范围扩大的情况，要找对应的开发人员了解对方的改动范围，再结合自己对于需 求的理解，综合确定出合理的测试范围，避免漏测或过度测试； 5. 在提测之后，每天下班之前该需求的测试负责人需要汇总所有测试人员的进度，在 需求的钉钉群里发测试进度给大家，让需求组里的其他人员也了解到最新的测试进 度，以及便于各角色之间更好的配合； 6. 需求测试一共4轮，分别是测试环境、预发布环境、灰度环境和正式环境，测试环 境和预发布环境最大的区别是预发布环境会定期同步线上数据，和一定时间段的线上 数据完全一致，便于测试洗数据以及复杂功能，由于测试环境每次需求结束之后都会 初始化清空数据库，所以预发布环境的测试数据也会更丰富；灰度和正式环境都是线 上环境，共用一套数据库、一个微信公众号、一套redis，其它都是隔离的，比如 rabbitmq、代码、域名等。 7. 消息推送：在预发布、灰度环境暂时无法测消息推送，另外在测试环境测消息推送 时，容易被本地的mq抢走，为了避免抢mq，在测试人员测推送时，建议让对应的开 发本地服务先停掉，或者临时修改一下测试环境mq的端口号； 8. 线上注册账号需要注意以下规则：
上线阶段
负责人：OP
里程碑节点：灰度测试完成、上线回归完成 需要注意的问题 1. 在准备好上线清单并且在预发布环境执行之后，后端RD同学要结合业务准确判断 出是否需要断服，如果需要则需要联系时阳或者蓝茹在上线当天提前发出断服公告 （公告内容由PM给出），并且在上线完成之后通知时阳或蓝茹下掉断服公告； 2. 周期上线规则：考虑到上线频率对于稳定性的影响，目前执行的是固定上线的流 程，参见项目管理（需要更新的是预发布目前只有一套），每周二和周四进行功能上 线，hotfix在非早晚高峰期间（早高峰8:30到10:30，晚高峰5:30到7:30）可随时上 线。对于小需求（开发周期在3天以内的）且不需要洗数据的需求，可走hotfix的快 速上线通道，申请走非周二周四的上线班车。对于极少数需要洗数据的hotfix，建议 走预发布灰度和正式环境的功能上线“慢车道“！
3. 灰度环境测试时，记得切灰度mq的分支！如果在晚高峰来临时，灰度测试未完 成，要记得在晚5:30之前切回全量，保证线上服务器的数量来“迎接”晚高峰”的压 力，在晚高峰过后再切回灰度环境继续测试。同时，在每天早上凌晨4点有考勤相关 的定时任务执行，所以如果有上线到凌晨4点还未完成的时候，记得在凌晨4点之后不 能发布代码，一直要等到确定定时任务完成之后或早高峰过了之后才可继续上线！每 月最后一天晚上的11点半开始定时任务（员工&组织&统计）自动生成月报，所以在 这一天要在定时任务开始之前完成上线，否则就需要先停掉定时任务等上线完成之后 再打开；每月3号凌晨0点左右，有统计针对招聘的定时任务，上线时也尽量避开。 4. 由于灰度已经是线上服务器，所以在灰度测试时不能频繁发代码； 5. 在正式上线之后，要通知PM和QA分别进行产品验收和线上回归，PM在验收之后 记得发邮件通知公司内部，并且在管理后台发布新功能介绍。 6. 在上线清单和新功能介绍中PM需要将对于新老用户的影响描述清楚，对于对旧用 户影响较大的功能，需要提前与客服同学们联系，做好老用户的提前告知。 7. 需求技术负责人请确定需求是否涉及到APP、mapi的修改，上线前通知相关负责 人配合上线。 推荐阅读
RD新人指南：研发同学新人指南、系统定时任务一览、Java工作规范、开发环境搭建
Java、2017 Q4发现的 安全相关bug
QA新人指南：QA新人导读
FE新人指南：编码规范、主系统 waves + storm 联调环境搭建（storm 部分）
环境相关：docker测试环境使用指南、非docker环境使用指南、测试环境使用流程、测试机
型统计
工具相关：禅道使用相关
安全相关：WEB应用安全培训.pptx