一、敏捷下移动测试痛点
当前在互联网特别是移动端的快速发展下，企业间的竞争日益激烈，绝大部分企业研发体系都转变为业务、产品驱动模式，研发流程为了适应快速响应、快速迭代，大多也都采用敏捷的模式来进行管理。
1、敏捷
在产品+开发+测试进行螺旋式迭代的研发中，要求快速跟进竞品，新功能快速上线试错，有些时候上线时间是根据业务方的需求而定，这样工作排期往往是倒推制定的，测试阶段很可能会被压缩。
加之敏捷研发下需求任务拆分较细，研发过程中可能会临时塞入一些紧急需求，负责这些需求的产品经理可能都会以任务紧急同时任务量不大的理由来说服开发和测试人员接受。这样对于整体质量和回归测试范围都会带来一定的风险。
2、移动测试
移动端的测试对象一般包含：服务端、Android客户端、iOS客户端、H5、Hybrid、RN等系统，同时面临着多机型、多版本的情况，一个点的改动涉及则是多面的。因此开发小范围的改动也可能造成大范围的影响，在复杂业务和高耦合的系统架构情况下就会更为明显。
在有限的测试周期内，如何评估测试范围，用尽可能少的测试用例去覆盖尽可能多的业务场景则是考验测试人员的关键点，即使如此，效率和质量也还是需要平衡的关键。
严格意义上说，只要是需要划定测试范围而不是进行全范围的全量测试，都属于基于风险的测试，只是风险可控还是不可控的问题。基于风险的测试必然导致基于风险的发布，因此，灰度也是为质量风险做的一项兜底工作。这一点在追求速度，快速占领市场和用户的互联网企业尤为明显。
因此，在敏捷下移动端的测试，如何在研发全流程阶段去暴露风险和问题，进行全程的质量保证，而不是将风险全部积压在测试阶段，就显得更加重要。
二、测试前置
测试前置也可称为测试左移，它并不是单纯意义上的让测试人员和测试工作更早的介入。而是建立一整套全流程质保和全员质保的理念，这些工作更多的是需要测试人员去驱动和引导。
测试前置的工作初期可能会造成测试和开发人员的工作量加大，但是如果流程逐步顺畅、产品设计质量和代码质量逐步提升，进入良性循环后，研发整体的效率和过程中的工时浪费将会得到明显的改善。
推进测试前置工作中需要把握几个重点：
1）作为测试团队leader，需要得到上级领导的认可与支持，制定出可行方案由上而下推行，并且得到平行的开发团队和产品团队的认同与配合。
2）产品、开发、测试等角色中涉及到测试前置的工作，需要评估入工作量，例如scrum工作模式下，sprint中每个story涉及到的UT、开发自测、产品自测、测试验收等工作耗时都需要计入工作量，否则即使全员有质量意识但在高强度的工作下也可能有心无力。当然前期可能对scrum team的任务吞吐量造成一些影响，但是从长远看是有利于质量和效率的提升的。
3）产品的PRD和开发人员的代码在结构上均需要优化可测试性。产品文档主要是在格式和逻辑梳理上方便进行场景分类测试。
5）测试人员在这个过程需要扮演串联各个环节和监督、总结的角色（当然Scrum Master也可以承担其中一些工作）。每个sprint结束回归会议上，测试人员需要提供每个节点各个角色的工作数据，例如代码静态扫描的问题及改善、UT的覆盖率、开发的自测覆盖率、自测通过率、入测准时率等等。
这些客观数据用于鼓励团队成员持续改善我们的前置测试工作，并且也是帮助发现sprint过程中的问题点。这项工作非常重要，数据的客观和准确需要得到每一位成员的认同，只有这样才能降这项工作长久持续的坚持并且优化好。
例如，以下是我们一个日常发布的一次开发过程数据：
三、自动化测试&测试自动化
1、分层测试
前面提到移动端属于系统结构中的最末端，其后台的支持系统庞大复杂，调用关系多、系统架构分层多。因此，我们的测试工作也是需要根据系统结构进行很好的分层、隔离测试。
例如，下图是携程机票移动端大致的一个调用结构图：
互联网应用的分层测试一般情况下可以分成以下测试层面：
以下是携程机票分层测试的比重分布的目标，其中单元测试的工作由开发人员完成是效率较高的选择，测试人员可以承担代码静态扫描和UT覆盖率的统计、改善跟进工作。
其中UT部分，前期大家追求行覆盖率，到一定程度后则需要更重视代码分支覆盖。后期在尽可能增长分支覆盖率的阶段，测试人员可以参与到UT的Test Case扩充的工作中。
2、服务接口测试
接口自动化技术相对成熟，在基本的框架层面上并没有太多的技术难度问题，主要将公司服务各种协议契约的序列化、报文发送接收解析处理类封装好，加上数据驱动和基本工具类，基于Nunit即可将接口测试代码基本跑起来。
但是接口测试真正要做好产生收益，首先必须要深入业务做到足够的覆盖面和测试深度，其次项目运行的通过率要足够高，以避免测试过程中的人为干预和排错的成本过高以及降低测试结果的权威性。因此，需要在这几个方面重点做工作：
l基于业务场景的动态测试数据
l接口依赖
l多接口串联测试
l环境稳定性、性能
l基于测试数据的校验方法
这里重点提一下动态数据，我们的接口自动化失败的test case很多情况下并不是bug，而是发生了未期望的异常情况，其中有一部分都是由于测试数据问题造成的。
因此我们的数据驱动的数据很大程度上不应该是静态的，而是需要是符合现有测试环境的动态数据。不管是通过mock还是做Data Provider，都要保证测试接口的数据需要既符合测试场景又能自动化的做动态调整。
下图是携程机票的测试数据模板，其中数据的模板只涉及请求和响应报文的契约结构（可以自动生成），具体的数据填充则由其他接口在代码中动态填充。
