深度介入需求和技术方案
快速迭代的过程中时间都比较赶，很容易进入的一个误区是为了缩短工时对需求和技术方案了解不深，测试用例侧重主流程分析，细节问题在前期没进行深挖。随着迭代的进行，对项目的整体结构了解会越来越混乱，在不断并快速的有新的需求提出时，无法将需求点对应在系统中的改动点get到，只根据需求文档过一遍需求流程，纯黑盒的考虑测试，迭代的越久对质量的把控就会越低。
个人认为测试可以在各个阶段做比较深的介入
1、需求阶段
迭代中的现状不断地有需求过来的时候，一些小的需求会只有一句话描述，可能只是对原始需求的一个表述。这样的需求，测试要根据需求做深入的思考，明确需求的内容以及想要达到的目的。对于需求的实现方式可以提出自己的方案，对于需求的整体链路流转需要非常清楚。
2、 技术方案
参与技术方案的讨论，在快速迭代中，技术方案因为时间关系会比较粗糙，测试需要提高警惕，结合需求阶段已理得很明确的需求，对技术方案做深入的挖掘，明确每个数据库流转的点，每个业务逻辑的技术实现。同事在快节奏下开发考虑技术在前期很可能只考虑了常规流程的情况，一般坑比较大的都是复杂情况以及异常情况，测试在这部分需要跳出开发给的思维，更广的去考虑问题，看技术方案是否给出对应的技术解决方法。
3、参与需求筛选
在大量需求提交过来的时候，除了产品去筛选需求，测试也可以参与到需求优先级的讨论中。
例如可以根据之前的需求实现以及使用情况来看，可以发现需求方提交的一些某些方面的需求上线后使用率比较低，那么后续对这方面的需求可以进行着重的把控，对使用场景和重要程度做深入的了解，再确定是否优先级高是否要做。
项目干预
1、寻找出适合项目的可持续的可控的计划方式。
快速试错业务一般是很多小日常掺杂着一些稍大的日常同步在做，在做计划的时候对于工作的分配很难预估准，有些时间直接定死deadline，时间都是压缩的。基于这种情况对于稍大的日常经常会在第一个计划没有达到的情况下，延期后又没有具体的延期计划，从而使后面的流程失控。
可采取的措施：根据实际情况可在项目组内提出两种情况的约定。
一、直接拍死上线时间的需求，就算只有几天，也需要反推开发开始时间，提测时间上线时间，不能只拍deadline，而不定期间的里程碑时间
二、如果预估到肯定不能够按期上线需要延期，则需要根据当前情况更新计划，而不能在延期后走一步算一步
2、提升项目测试质量。
一、将各个功能区分质量优先级。比如小程序质量优先级高，运营后台的质量优先级次之。下单、佣金、优惠券等主流程以及营销结算主流程的优先级高，交互类的需求优先级次之，比如商品分类排序等。有限的精力优先保障高优先级的部分质量
二、对测试分析要求严格。必须TC评审，并且要开发参与TC的设计，并且和开发一起讨论测试重点、测试遗漏点
三、把控项目节奏，对风险点一定要提前预估，并且努力去降低风险。比如说时间预期，工作量预期，有并行任务的时候需要考虑资源冲突等等情况
项目流程探索
有非常多的小需求，穿插一些稍大的功能日常需求。需要严格的把控上线的节奏，可约定上线窗口。迭代基本流程入下图。实际操作中可能存在一点偏差，但是在有基线的情况下，整体情况才能可控
测试策略制定原则
鼓励开发自测，测试充分把控自测标准。
- 文案改动-包括页面文案、前后端提示文案、通知类文案
- 仅运营使用的小功能点改动-比如导出报表
- 已有功能的小的优化需求-后台以及后端-比如排序方式等
对于自测的需求点测试也需要做深入的需求了解，同时对于自测可以做一定的干涉。在自测的需求上，根据经验做一些灵活的把控。比如针对不同需求对应开发、不同的需求优先级、不同的需求复杂度等方面做考量。
例如功能简单，但是可能有场景交叉需要测试时注意的，此时有两种解决方案，一是该需求纳入测试介入的范围进行质量保障，二是将测试点列出给开发以免自测范围遗漏。
针对不同需求把控测试轮次
一、简单需求小点组成的一个需求集合，测试一轮，bugfix，做基本的回归则完成测试上线。
二、有完整的功能模块、流程、闭环的需求，基本会走一轮日常、一轮预发以及回归测试完成上线。
需求筛选以及上线内容干预
项目初期的时候完全根据需求小点随意组合一个版本，小程序端的需求也很随意，有需求就发版。在后续会对一周的需求做评估，把功能模块比较近的需求放在一起，小程序也尽量控制一周的需求发版一次。每次上线的内容功能模块集中，开发减少影响面，测试需要回归面也可以适当减少。效率及质量可以提升，项目更加可控。
测试分析阶段性分割
快速迭代、多需求并发并且业务方需求紧迫时，需要预估到一期的需求很可能因为各种原因会延期，根据以往的经验很可能会将需求分割先上一部分再上另一部分的情况。在我们做测试分析以及测试用例准备的时候可以对这种状况做准备。以下通过一个需求例子来分析。
先看一下代理商佣金结算需求的测试用例分析：
需求主流程：运营在后台给网点设置代理商和佣金，在对应的网点下单付款会给代理商佣金，佣金在每个月月初结算上个月的，结算后进行打款。
预估风险：该需求前期没有进行估时，PM直接拍定提测时间以及上线时间。测试这边根据当周的需求预估到无法按期提测，并且根据业务方迫切要求和实际时间，预估到实际最后只能先上一部分需求，考虑到结算是下个月初进行的，对当前操作需求不紧迫，所以评估会是代理商佣金设置以及待结算的信息入库部分会需要第一时间上线。在做测试分析的时候考虑到由于其他需求导致资源不稳定，一个流程上的前后端可能开发进度会不一致，所以根据当时的技术方案、需求以及考虑到的可能存在的风险，测试用例落地的时候就做了各个流程阶段性的切割，以便后续的测试。
实际切割 如上图的xmind所示，将整个流程先切分了前端和后端的模块，前端主要是小程序和H5的对终端用户的展示，后端是后台功能以及后端的处理逻辑。在流程上把整个过程切分了佣金和代理商设置以及库更新、下单付款可分佣订单入库逻辑校验、前端订单以及数据统计筛选校验、结算校验、打款校验进行分割。该需求实际过程中提测点也基本是按照预期的分割点走，通过该分割极大的提高了测试效率以及项目质量。