截止到目前，团队现有成员已基本具备一个中高级测试人员应有的工作方法和工作经历。
在不断的增加工作经验的同时，哪些方面限制了我们的发展，哪些方面掣肘我们的思维边界，我们应以何种姿态和思维应对时代所赋予的动荡和不稳定，应对公司业务发展中出现的业务复杂性增高带来的测试效率降低和业务量提升带来的质量问题权重升级。当开发人员以微小的变动来实现新需求、新功能时，我们怎样去说服对方所需测试耗时成倍于开发时，系统模块化的积淀和迭代的势能是否传导到了QA团队？当生产环境出现微小问题频发且影响用户量呈用户总量的小百分比但影响上万人的使用体验时？
我们如何进化，才足以应付这些问题！
时代赋予了人们大量生命体验由网络服务提供，同时也相应给予网络服务供应商崛起的契机，但如何应对呢？往大了说我们应给予时代发出我们的声音，小了说我们应能够承担为组织在市场变动中提供足够的支撑，才不负于我们随同组织的共同成长。
软件质量保证是个系统性工程，可以采取的策略有多种多样，目前实施的针对研发代码实现逻辑符合性测试仅仅是工业产品对应的最低标准，不同于工业产品，软件系统的测试具备更多的知识型劳动付出，需要测试人员发挥专业素质和自主想象力应对不同项目中的具体实际情况。
如同物理产品那样，我们也可以实现指向性产品投放且对比物理产品能够获得更高的反馈，灵活性亦远高于物理产品，这就是脱胎于销售市场反馈评估的AB测试（类似的思想也有为灰度测试），即小规模指向性投放产品到市场，以对产品进行验证分析，经过充分验证后将产品投放市场。这当然是一个系统性工程，但也是一个必经之路。
上面所讲的是针对产品发布后进行的验证分析，那如何在发布前的开发阶段，甚至需求提出时进行验证呢？我们常常讲，测试工作伴随系统研发的整个生命周期，这个概念太笼统，且提出的时机已经较久，对应国内的企业运作环境和行业特性颇不适应。我们需要分拆且尽量提出能够具体实施的目标和方案来。
早期在进行需求分析时，针对具有一定复杂性沉淀的系统，通常由于人员流动频繁（从hr朋友那里了解到互联网类公司两年一波，事实情况也大体如此），对现有系统的逻辑和约束边界已经出现断层和丢失，很多情况下是产品拉着开发看代码来获取既有逻辑，以此为基础提出后续产品方案，这种现象在互联网类公司真不是少数。那么可否提出一种方案，在产品需求提出阶段，能够产出一个具有机器可识别的逻辑文档，此文档能够指导后续的开发和测试工作，使之更容易达成一致认知。同时在进行需求迭代时，此文档能够与系统逻辑锚点被动保持一致，便于产品在后续需求提出时进行参考，以提出更加合理的不会对系统现有逻辑产生抵触和背离的需求。同时，基于此系统，业务线相关人员也能够更加清晰的了解系统现状以更好的进行部门间团队协作。
在研发已经给出可测代码时，如何进行逻辑一致性验证呢？提供了一个思路。利用大数据分析用户行为保证核心逻辑覆盖，进行全量代码逻辑路径进行覆盖。尝试实施接口黑盒数据冲撞，逻辑冲撞，异常冲撞等。在保证数据逻辑覆盖的前提下逐步实施规约型自动组装数据冲撞，自动根据接口描述和历史数据，只能生成冲撞数据，捕捉采集数据冲撞结果和日志，用以后续分析和AI进化。分析冲撞路径覆盖度和最终成果，不断优化迭代，得以持续提高自动化测试的有效性和覆盖率。比对人工执行和自动化测试的效果，测试人员则需要发挥主观能动性进行规则编写和进化方向设计。
