zoukankan      html  css  js  c++  java
  • 从BRD到上线:一个需求的完整生命周期

    需求完整生命周期


    产品PRD评审:

    1. PRD评审邮件,评审是否通过,是否有补充点、待决议点,如果场景考虑不全或者主流程不通,评审不通过打回后重新提PRD。
    2. PRD中细节描述要清楚,比如特殊场景的处理,产品容错处理,做到开发人员可以以PRD为准。PRD的细节缺失会造成开发人员的开发场景缺失,测试人员测试场景缺失,大概率的出现线上BUG。此点需要产品、研发、测试的共同努力,争取将BUG消灭在PRD评审阶段。避免出现如下场景:测试完成后准备上线时产品发现需求考虑不全,需重新讨论需求;提测后产品发现有场景遗漏需要补需求;这些场景均会造成测试资源、开发资源的浪费。
    3. PRD评审通过后输出PRD评审报告。


    研发人员提测:

    1. 提测前执行测试人员提供的冒烟用例,保证100%通过。
    2. 根据实际情况进行小组codereview 或者结对codereview,review通过后方提测。
    3. 提测单上附属codereview通过截图、接口测试附属接口名称#方法#本地测试入参、涉及应用、应用代码地址、分支、修改点。


    测试人员测试:

    1. 在研发提测前准备好测试用例,其中涉及到主流程的标记为冒烟用例。
    2. 与研发人员、产品经理、项目经理一起评审测试用例,并输出测试报告,后将测试用例提供至研发人员。
    3. 研发人员提测后,测试人员进行冒烟,冒烟通过后继续执行其他测试用例,冒烟失败则打回提测单至研发人员。
    4. 测试人员在测试环境执行完毕所有测试用例后,进行分支预发,分支预发测试完毕后主干预发,主干预发测试完成后输出业务方验收报告。
    5. 业务方验收完成后,进行上线。上线后进行线上验证,输出测试报告。

    完整流程中共有11种文档输出:

    1. BRD(Business requirements document)
    2. PRD(Product requirements document)
    3. PRD评审报告
    4. PDD(Product design document)
    5. PDD评审报告
    6. 测试用例 (Test Case )
    7. 测试用例评审报告
    8. 提测单
    9. JIRA单
    10. UAT验收报告
    11. 需求测试报告
  • 相关阅读:
    JS的toFixed方法设置小数点位数后再进行计算,数据出错问题
    表单input项使用label,同时引用Bootstrap库,导致input点击效果区增大
    表单多文件上传样式美化 && 支持选中文件后删除相关项
    Fiddler使用AutoResponder进行本地文件和线上文件的映射
    ES6笔记(7)-- Promise异步编程
    ES6笔记(6)-- Set、Map结构和Iterator迭代器
    ES6笔记(5)-- Generator生成器函数
    ES6笔记(4)-- Symbol类型
    ES6笔记(3)-- 解构赋值
    ES6笔记(2)-- let的块级作用域
  • 原文地址:https://www.cnblogs.com/emma-lucas/p/10673827.html
Copyright © 2011-2022 走看看