一、需求分析
拿到需求文档或原型图首先进行需求分析，对有疑问的地方进行标注。分析产品功能，从业务逻辑、数据约束（数据显示范围，关系，长度，类型等方面）、权限需求、场景约束等方面分析需求是否有未实现和实现方式是如何的。挖掘隐形需求，以异常或者不符合规定的操作进行业务和功能便利，看最终的实现情况和错误提示。
二、需求评审
根据自己的疑问在评审会议上进行讨论，记录会议上讨论的结果、修改方案等，以免产品在后期不修改需求在测试中出现问题有探讨依据。或者是研发根据讨论结果进行开发，需求没有更改导致出现无效bug。
三、编写测试用例
a.使用思维导图列举测试大纲，尽量发散，想到什么写什么，先放后收，对知识点进行总结和归纳，标记重点测试模块，删除冗余及重复测试点。
b.依据测试点和设计测试用例方法（边界值、等价类、错误推测、因果图等）
四、用例评审
联合开发、产品、PM进行用例评审，先讲解测试点让大家对用例有个大概，再逐条讲解用例，结束进行修改和调整。将最终结果以消息或者邮件方式通知大家。
五、提测演示
根据开发自测演示把需求中涉及到的基本功能过一遍，还有在需求评审阶段调整的需求进行演示。防止有遗漏的功能和致命问题导致在测试时无法进行。如果出现致命问题或者功能未实现的问题与产品沟通进行提测延期或不开展测试。
六、提交bug并推动bug解决
在bug管理工具上提交bug，详细记录操作步骤。与开发积极沟通，推动问题解决。
七、回归测试
对已修复的问题进行验证，对bug涉及的模块进行基本功能测试，整体进行冒烟测试，确保已修改的问题不会引起其他问题。
八、编写提交测试报告、归档、总结
依据测试情况进行bug总结，未解决的问题选择遗留或者是继续完成。评估是否发布上线。结束测试。
标签：需求,测试点,流程,评审,工作,测试,bug,进行 来源： https://www.cnblogs.com/studyorg/p/15979005.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。