产品
产品内部需要先进行需求评审，确定需求后，才能跟技术进行需求宣讲；
需求宣讲前，至少提前1天把需要宣讲的需求发出来，通知测试和开发宣讲时间和地点；
需求宣讲后，测试和开发有疑问，产品需进行Q&A，维护到对应需求文档上，并及时更新需求；
需求宣讲完成，原则上不允许进行需求变动；如果进行需求变动，需要在协作平台提需求变更，开发和测试重新评估时间；
产品新增/变更需求，需要进行三方周知，不能只单方通知到测试或单方只通知开发；
产品规划需求前，涉及多方业务时，需要跟多方业务部门沟通清楚，避免出现上线后临时又要优化需求的现象；
开发
开发在需求宣讲后，需要理解并拆分需求，及时跟产品沟通并督促 产品更新需求；
开发前期需求需要完全了解，非自己开发部分也需要大概了解；
开发完成后需要重新核对一遍需求，有些需求变更才不会漏掉；
开发需要测试部署时，要提供完整的部署信息（包括：环境、服务、分支）和部署说明（本次部署的目的）；
开发在设计评审阶段，可以让测试一起参加了解；
开发不允许私自修改或优化代码但没有告知测试，很容易导致测试漏测；
开发bug原则上需要日清，紧急和严重问题非特殊情况必须日清；
开发提测前，需要将全流程都跑通（执行冒烟测试用例）才能提交测试，不能只是每个开发模块开发完成，独自模块自测完成后就算提测；
涉及到迭代开发的所有人员都需要清楚每个迭代的节点时间（提测时间、预生产时间、上线时间）；
开发身上的bug，如果需要流转到其他开发，需要备注下一个开发需要帮忙做的事情，然后私下再通知对应开发帮忙排查问题；
开发解决bug后，需要备注出现问题的原因和影响范围，方便测试回归验证；
开发提测，需要有提测说明和影响范围说明（开发全功能提测后，发现有不影响主流程的问题，正在修复，也可以写到提测说明中）；
开发不能私下接需求，产品新增或修改需求，需要测试也评估后才能决定是否新增/修改；
开发提测后，可以多对自己的代码和本次迭代流程进行测试，在测试发现问题前先消灭掉（建议）；
最好是能前紧后松，不要所有东西都堆积到后面来处理，导致后面发布风险；
开发过程中碰到有2个小时内自己都解决不了的问题，要向上寻求帮助，不要耗上一天或者半天的时间；
群里或者私聊的时候，有看到消息开始处理了要通知一声让对方了解情况，所有消息都最好能稍微回复/反馈；
测试提测问题单，如有描述多个问题场景，要所有场景都处理才算修复，修改好的问题自己要先核对正确了再提测，不要反复浪费时间；
上预生产，上生产，负责人要提前做好脚本和配置的工作，同时要核对下预生产和生产是否跟测试环境有差别，提前规避因为此类问题导致上预生产/生产的时候才发现问题，耗费时间；
问题修复及时更新状态给测试，所有问题到测试手中都必须是已解决的，同时要区分延期，不处理，已处理。已处理代表是有修改内容，不处理和延期必须要跟测试和产品沟通确定ok才能改成这类状态，非缺陷的请备注好原因通知测试重新验证；
多版本同时在测试环境的时候，要注意不要版本之间混杂在一起；
多个需求在同个版本上线，各负责人合并代码，上线等各个节点需要互相通知，保证最后合并后的分支包含各部分内容，同时同一个版本打tag前最好使用相同分支号，这样打包部署才不会混乱；
开发提交上线单子（线上变更）标题规范：标题：【上线任务】系统+版本+上线内容+上线时间
如：【上线任务】财务中台-结算中心V1.6.1 大兴机场资金结算 上线 2019-11-01 22:30
测试
需求分析
.拆分需求，需要确认的问题，整理成文档发给产品确认，并督促产品维护Q&A到对应需求文档上，及时更新需求文档；
测试用例编写
.编写测试用例时，要100%覆盖到产品需求，覆盖完整后再补充场景、边界、异常等测试用例；
.编写测试用例，标注测试用例级别，1级用例为开发提测前必须自测通过的主流程case，提测后测试以此进行冒烟测试；
.测试用例编写完成后，至少要在测试用例评审的前1天把发出用例发到群里@开发负责人、测试负责人、对应开发和对应产品，通知大家用例评审的时间和地点；
.需求宣讲完成后，所有的需求变动和新增，都需要开发和测试一起评估，同意变更后，需让产品补充需求文档和提需求变更单子，不接受口头需求变更，不接受单方面需求变更
测试前
.提测前1天跟开发确认提测情况，确保提测日期当天可以顺利提测；
.提测后优先进行冒烟测试，冒烟测试结果发群里@开发负责人、测试负责人、对应开发和对应产品（PMO）；
.冒烟测试不通过，不算提测；冒烟测试通过，提测成功，测试进入测试阶段；
.冒烟测试模板规范：
冒烟测试模板
【系统+版本号】
【冒烟测试结果】冒烟通过/冒烟不通过
冒烟项1：冒烟结果（通过/不通过）
冒烟项2：冒烟结果（通过/不通过）
冒烟项3：冒烟结果（通过/不通过）
……
艾特开发、测试、产品负责人
（冒烟测试不通过的，需要写明不通过的原因/存在的bug）
测试中
.测试中，遇到阻塞问题，及时群里@对应开发和开发负责人，督促问题及时解决，不要私聊；
.测试中发现开发私自修改代码没有同步测试，群里周知，督促开发规范性；
.开发解决bug，要求开发需要备注修复原因和影响范围，方便测试验证回归；
.开发需要把bug解决后测试才能验证关闭，测试不能自己修改bug状态进行关闭操作；
.测试中提的bug，原则上需要日清，紧急和严重问题非特殊情况必须要求开发日清，测试及时验证开发日清的bug
.测试环境测试完成，计划上预生产，提前在群里@开发和开发负责人，安排准备上预生产的脚本和配置，不要私聊；
.预生产流程走通后@产品同步验收；
.预生产测试完成前，提前群里@开发和开发负责人打tag；
.tag验证没问题，上线当天群里@开发、开发负责人和产品 ，上线通知；
.及时更新协作平台上测试任务状态；
.多项目或多人配合时，环境部署（开始部署和部署完成）需要再群里通知；
.遇到任何不清楚，不明确，有疑问的都需要在群里跟产品/开发确认，涉及修改需求时督促产品更新需求；
.测试中发现的问题，都要提交协作平台记录，不能只是口头传达；
.测试不能100%确定要延期的问题都需要跟产品确认，原则上需要延期的问题都要跟产品沟通；
测试完成
.上线完成，@产品已经上线完成；
.jira上线单子，上线完成后，需要@2个群组（@tech_pm和@tech_leader），备注测试情况，并把jira单子指派给对应开发；
.协作平台上线单子，上线完成后，备注测试情况，关闭上线任务；
线上操作
.上线后，本次上线的内容能验证的都需要验证，不能验证的群里通知产品，产品第二天需要配合业务部门进行相应功能验证；
上线后第二天跟踪
.上线后，第二需要关注并响应群里的消息和问题；
.上线较晚，第二天在家支持，也需要关注并响应群里的消息和问题；
标签：需求,上线,职责,流程,冒烟,研发,开发,测试,提测 来源： https://www.cnblogs.com/zourui4271/p/15481280.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。