最近在准备面试，总会看到一个经典的面试题目“说一下你之前产品的测试流程时什么样的” ，因此我想在这里总结一下我在测试工作中的测试流程；并且拆解测试流程中的关键细节和一些优化的思考。
测试流程的核心阶段
在整个规范的软件测试过程中，无论是大厂还是小公司都存在的核心阶段有以下几个：.png)
在我之前的测试过程中，在每个阶段我都重点参与了。因此对测试流程的把握相对成熟，我会在接下来的内容中具体讲述每个阶段的核心和我的实践方式。
1. 需求分析阶段
需求分析阶段的核心
在需求阶段，由于项目的快速迭代性，团队只有我和另一名同事全程参与需求阶段，包括和BG一起讨论需求的来源，背景以及需求的紧急程度等。因此，在经历了很多轮的需求阶段后，我总结了测试人员在需求阶段需要做的事情有：了解项目的背景，用户对象，交付目的，项目盈利点，需要实现的功能点 。
也许你会困惑，测试人员为什么要了解项目的用户对象和盈利点呢？
在我看来，了解用户对象有利于我们在掌握测试重点，能更贴近用户的使用方式，进而更大程度的避免上线后客户问题的发生。
对于盈利点，测试人员不仅需要保障产品的质量也需要识别项目的核心业务路径，比如线上问题发生后，测试人员需要迅速识别问题可能引发的后果，能判断问题修复的优先级，并且快速制定合理的测试方案。
总的来说，通过前置理解项目背景，用户对象，交付目的，项目盈利点等方面，可以让测试人员获得更多的主动权。
需求分析的实践方法
需求文档：
需求文档研读：标注疑问点（比如是否有边界条件，权限限制等不清晰）
针对负责的模块，从用户视角整理出操作流程
思考当前模块/功能是否存在关联模块，关联模块在当前版本是否有改动。
需求评审会议：
在完成需求文档研读后，整理出所有疑问点，并且可以提前发送给PM, DEV 进行确认，避免现场讨论花费大量时间。
确认边界条件（比如：某字段允许的最大值，DB存储时是否有长度限制等）
异常处理：文件/ 网站在备份过程中，第三方API异常导致备份中断时，之前备份的数据如何处理？是否有重试机制？
兼容性：产品的兼容性如何，是否对哪些特殊浏览器有限制？
测试点分解：
根据需求分析得到的结论，整理脑图或者重点列表。
功能维度：整理出主流程，异常场景
页面输入：整理出输入数据是否有格式，长度，类型限制等 ；以及是否与其他服务有依赖关系。（比如创建的数据会在其他子系统中被调用）
关联模块：提前整理出该功能所关联的模块，以便于在设计评审阶段与开发确认接口协议是否有改动
2. 设计评审阶段
设计评审阶段的核心
在设计评审阶段，我会参与开发人员的研发讨论会。在这个阶段我总结了需要测试人员在该阶段需要重点关注的核心内容：
熟悉底层数据流转的过程
了解当前业务中存在的数据源（数据存储位置，缓存机制，是否有第三方数据来源等）
熟悉当前业务中的接口（检查接口设计的完整性，为接口用例输出做准备）
熟悉业务流程
明确功能点的预期值
明确测试颗粒度
明确当前版本的测试 是否需要进行接口测试，性能测试，安全扫描等。并且需要确认如果需要接口/性能/安全测试，是否会影响测试周期，测试时间是否充足。
确定项目的交付周期
是否存在开发交付延期，如果交付延期对测试的影响等都需要尽可能在这个阶段确定。
设计评审阶段的实践
注意事项：
在会议中明确各个模块对应的数据流转过程（从数据的起点-> 传输路径 -> 数据存储位置）每个节点和路径可能存在的问题都需要确认。对于待定项/不确定内容，需要在会后尽快补齐，并且同步给团队成员。
测试点总结：
当有数据在系统组件之间流转时，需要确保各组件之间接口协议是否同步，有没有可能存在消息积压等
例如：我之前测试中遇到的一个问题就是由于，同域其他产品调用子系统A的数据进行批量删除时，由于双方开发的接口协议没有统一，导致数据删除业务失败，并且在线上遗留了脏数据。
当数据在不同的存储介质中流转时，需要考虑数据的一致性。
例如：A[应用服务器] --> B[(Redis缓存)] --> C[(MySQL主库)] 这种情况下我们需要考虑缓存测试，确保数据的一致性。
3. 测试计划阶段
测试计划阶段主要由团队测试leader 负责，主要是制定相应的测试计划，测试周期的确认，和团队讨论并制定交付结果的衡量标准。
并且需要将 测试计划抄送给开发团队，产品负责人等，确保协作团队都认同当前版本的测试计划。（能有效避免需求改动或者开发延期导致交付与测试计划不符。）
测试计划阶段的核心
明确当前版本项目背景，资源情况，当前版本的任务，各个模块的责任人，测试周期，交付结果衡量的方式。
测试计划阶段的实践
分析当前版本测试任务的工作量，根据当前团队的人力资源情况合理安排各个模块的测试负责人。
确认当前版本是否存在“可能延期交付的模块”，如果存在，需要当前模块的测试负责人及时同步给测试leader，然后与开发团队确认好最晚交付时间。
根据团队成员的业务能力分配不同的测试任务，确保能按照计划完成测试工作。
制定交付结果衡量方式
例如： A同学负责接口用例的设计，交付结果衡量方式就是通过用例评审。
4. 用例编写阶段
用例编写阶段需要每个人按照各自负责的模块进行用例编写。我之前的团队中由于业务扩大，招聘了一些新成员。因此对于业务熟练的老Tetser还需要负责新同学的用例编写规范检查。确保新同学的用例符合团队一贯风格和要求，并且确保用例编写符合业务逻辑。
如果团队中存在新成员，那么用例编写阶段需要尽早确认他们的用例符合要求，如果等到用例评审阶段再发现问题可能会影响测试进度。
5. 用例评审
在用例评审阶段，我会按照不同模块的功能制定会议时间，尽可能将用例评审会议拆分开，减少会议时长。根据之前的经验发现，如果评审会议时间超过1.5H，会导致大家的专注度下降。因此我会避免将所有用例放在同一次会议中进行评审。
用例评审阶段的实践
邀请各个模块的责任开发和PM 一起参与用例评审，确保开发，产品，测试 对业务的理解是一致的
提前将用例发给对应模块的开发进行review，在评审会议中按照主分支进行讲解。避免逐条用例讲解导致花费太多时间。
对用例中存在的问题进行标注，并且在会后及时完善，确保闭环。
6. 冒烟测试
冒烟测试的核心
将各个模块主流程用例发送给开发，让开发人员进行自测。
冒烟通过的模块才能算开发完成交付
7. 用例执行
用例执行阶段属于正式测试阶段，在该阶段是bug 集中爆发的时期。因此需要注意以下几点：
用例执行阶段的实践
定期查看当前版本bug数据，收集严重/ 紧急程度的bug。需要及时提醒开发修复，避免bug导致测试流程不顺利。
对于严重bug，需要开发修复后自测，并且在jira中添加修复该bug的影响范围。测试人员在确认bug时，也需要注意该bug影响范围的测试。
8. 回归测试
回归测试阶段的核心
设计合理的回归测试策略：
1.明确测试目标：重点在于确保新功能主流程没有问题
2.定位bug集中的模块：对用例执行过程中 bug较多的模块再次回归。
3.涉及关联模块交互的功能：对于跟其他子系统或者三方服务交互频繁的模块进行回归。
4.可以收集开发的建议：针对改动较多的模块/接口进行回归
【注】对于回归采取什么样的策略，取决于产品的当前的特性。比如：之前产品在某次迭代中进行了新UI的更换，并且依赖服务也进行了版本升级。那么，为了确保产品上线后的稳定性，我们在回归时采用了全量 high level 用例的回归。
9. 报告输出
测试报告是测试活动的最终交付物，直接影响团队对质量状况的认知和后续决策。一份规范的的测试报告不仅需要数据详实，还要逻辑清晰、重点突出，并能驱动问题解决。
测试负责人需要根据当前版本的测试范围，测试结果，质量评估，缺陷分析，优化建议等方面输出测试报告。根据以上内容的分析，总结当前版本遗留的问题以及后续方案，还需要对当前版本中存在的问题（例如：开发修复bug不及时，测试人员对需求分析不透彻等）进行分析和总结并且给出优化建议。