刚入门，理解有限，欢迎讨论
这里将测试流程简单分为4个阶段：需求阶段、测试准备阶段、测试执行阶段、总结阶段
每个阶段对应不同的“目的、测试工作内容、关注点、产出”
每个阶段的工作内容，可以视项目紧急程度适当灵活调整
一、需求阶段（目的：让项目多方人员对需求的理解达成一致，方便后续工作交流）
内容1：阅读需求文档，结合产品设计图理解需求
关注1：需求不合理的点
关注2：需求不明确的点
关注3：自己不明确的点
内容2：参加需求评审，在评审过程中提出自己的疑惑点
关注1：解决上述疑惑点
关注2：深入理解需求
关注3：记录评审过程中未解决的点
内容3：梳理需求，将需求不明确的点以文档形式记录，同时进一步熟悉需求
关注1：记录上述未解决的点
关注2：记录梳理需求中不明确的点
产出：《测试需求反馈表》
内容4：反馈跟踪需求，将上述产出提交给产品，持续跟踪反馈结果
关注1：根据公司对应流程进行提交（例如：通过Ones以bug的形式提交给对应产品）
关注2：若元素需求有变动，需提醒产品更新到需求文档，需提醒设计更新设计图
内容5：明确测试任务
关注1：测试时间和测试范围
关注2：对应开发人员及产品
二、测试准备阶段（目的：尽可能覆盖所有测试点，保障软件质量）
内容1：根据最新的需求文档和设计图，编写测试用例或提取测试点
关注1：根据时间来确定是编写用例还是提取测试点
关注2：测试人员应确定回归测试的范围，体现在测试用例（测试点）中
内容2：组织人员进行用例评审
关注1：完善测试用例（测试点）
关注2：提高设计用例的能力
内容3：熟悉对应的数据库
关注1：梳理本次功能涉及的数据表
关注2：梳理表中各字段的意义以及数据流向
三、测试执行阶段（目的：有条不紊的执行测试，推进软件开发完善的过程，保障最终能成功上线）
内容1：开发交测后，先进行一轮冒烟测试
关注点1：确保主流程畅通，如果不通，以文档形式记录下来
产出：《冒烟测试反馈表》
内容2：对接开发，沟通本次迭代修改的范围及可能影响的功能，完善回归测试
内容3：按照测试用例（测试点）执行功能测试，发现与预期不符的地方以bug的形式在平台上提交给对应人员
关注1：确定好修复优先级
关注2：标题和描述尽量清晰简洁
内容4：测试过程中，遇到未覆盖的点，及时补充到测试用例中（测试点）
关注1：与已执行的用例做好区分
内容5：验证已修复的bug
关注1：验证前跟开发确认，测试环境是否为最新代码
关注2：验证时间在开发解决并发包的第二天之内完成
关注3：bug解决过程中，如有分歧，记录下来，将该问题和产品、开发形成三方解决方案
内容6：所测模块的bug全部验证后，进行回归测试
关注1：根据上线时间灵活决定是否全部修复（未正式上线项目）
关注2：回归测试包括上述关联功能的回归以及固定流程的回归
内容7：不同功能负责人进行交叉测试
内容8：上线前验证（再次回归）
关注1：上线内容
关注2：回归内容
内容9：上线后测试（线上测试，一天时间）
关注1：上线内容
关注2：回归内容
关注3：随机测试
四、总结阶段（目的：逐步修复自身的测试盲点，提升测试水平）
内容1：项目基本信息
关注1：项目名称、测试时间、测试内容（具体到功能或需求点）
内容2：数据总结
关注1：测试用例数（测试点可不做统计）
关注2：补充用例数
关注3：漏测bug数
内容3：经验总结
关注1：测试思路的梳理补充
关注2：测试过程中遇到的问题以及解决方案
内容4：产出《测试报告》
标签：需求,测试点,流程,规范,关注,内容,测试,bug From： https://www.cnblogs.com/cly9/p/17096273.html