干货 | 携程机票无线测试技术与效能提升

作者简介

罗昭君，携程机票无线高级测试经理，负责机票移动端功能测试、自动化测试、平台开发等。从事开发、测试工作近12年，先后在阿里巴巴、携程任职。

一、敏捷下移动测试痛点

当前在互联网特别是移动端的快速发展下，企业间的竞争日益激烈，绝大部分企业研发体系都转变为业务、产品驱动模式，研发流程为了适应快速响应、快速迭代，大多也都采用敏捷的模式来进行管理。

1、敏捷

在产品+开发+测试进行螺旋式迭代的研发中，要求快速跟进竞品，新功能快速上线试错，有些时候上线时间是根据业务方的需求而定，这样工作排期往往是倒推制定的，测试阶段很可能会被压缩。

加之敏捷研发下需求任务拆分较细，研发过程中可能会临时塞入一些紧急需求，负责这些需求的产品经理可能都会以任务紧急同时任务量不大的理由来说服开发和测试人员接受。这样对于整体质量和回归测试范围都会带来一定的风险。

2、移动测试

移动端的测试对象一般包含：服务端、Android客户端、iOS客户端、H5、Hybrid、RN等系统，同时面临着多机型、多版本的情况，一个点的改动涉及则是多面的。因此开发小范围的改动也可能造成大范围的影响，在复杂业务和高耦合的系统架构情况下就会更为明显。

在有限的测试周期内，如何评估测试范围，用尽可能少的测试用例去覆盖尽可能多的业务场景则是考验测试人员的关键点，即使如此，效率和质量也还是需要平衡的关键。

严格意义上说，只要是需要划定测试范围而不是进行全范围的全量测试，都属于基于风险的测试，只是风险可控还是不可控的问题。基于风险的测试必然导致基于风险的发布，因此，灰度也是为质量风险做的一项兜底工作。这一点在追求速度，快速占领市场和用户的互联网企业尤为明显。

因此，在敏捷下移动端的测试，如何在研发全流程阶段去暴露风险和问题，进行全程的质量保证，而不是将风险全部积压在测试阶段，就显得更加重要。

二、测试前置

测试前置也可称为测试左移，它并不是单纯意义上的让测试人员和测试工作更早的介入。而是建立一整套全流程质保和全员质保的理念，这些工作更多的是需要测试人员去驱动和引导。

其中涉及到的工作大致可分为PRD静态测试、服务契约测试、代码静态扫描、单元测试、服务接口测试、开发自测、测试准入检查、入测质量数据统计等。

测试前置的工作初期可能会造成测试和开发人员的工作量加大，但是如果流程逐步顺畅、产品设计质量和代码质量逐步提升，进入良性循环后，研发整体的效率和过程中的工时浪费将会得到明显的改善。

推进测试前置工作中需要把握几个重点：

1）作为测试团队leader，需要得到上级领导的认可与支持，制定出可行方案由上而下推行，并且得到平行的开发团队和产品团队的认同与配合。

2）产品、开发、测试等角色中涉及到测试前置的工作，需要评估入工作量，例如scrum工作模式下，sprint中每个story涉及到的UT、开发自测、产品自测、测试验收等工作耗时都需要计入工作量，否则即使全员有质量意识但在高强度的工作下也可能有心无力。当然前期可能对scrum team的任务吞吐量造成一些影响，但是从长远看是有利于质量和效率的提升的。

3）产品的PRD和开发人员的代码在结构上均需要优化可测试性。产品文档主要是在格式和逻辑梳理上方便进行场景分类测试。

4）技术层面上需要为测试前置提供有力的框架和工具支持，例如低门槛高效率的自动化测试框架、持续交付、持续集成平台、方便开发产品自测的测试数据构造工具等等。

5）测试人员在这个过程需要扮演串联各个环节和监督、总结的角色（当然Scrum Master也可以承担其中一些工作）。每个sprint结束回归会议上，测试人员需要提供每个节点各个角色的工作数据，例如代码静态扫描的问题及改善、UT的覆盖率、开发的自测覆盖率、自测通过率、入测准时率等等。

这些客观数据用于鼓励团队成员持续改善我们的前置测试工作，并且也是帮助发现sprint过程中的问题点。这项工作非常重要，数据的客观和准确需要得到每一位成员的认同，只有这样才能降这项工作长久持续的坚持并且优化好。

例如，以下是我们一个日常发布的一次开发过程数据：

三、自动化测试&测试自动化

1、分层测试

前面提到移动端属于系统结构中的最末端，其后台的支持系统庞大复杂，调用关系多、系统架构分层多。因此，我们的测试工作也是需要根据系统结构进行很好的分层、隔离测试。

例如，下图是携程机票移动端大致的一个调用结构图：

互联网应用的分层测试一般情况下可以分成以下测试层面：

以下是携程机票分层测试的比重分布的目标，其中单元测试的工作由开发人员完成是效率较高的选择，测试人员可以承担代码静态扫描和UT覆盖率的统计、改善跟进工作。

其中UT部分，前期大家追求行覆盖率，到一定程度后则需要更重视代码分支覆盖。后期在尽可能增长分支覆盖率的阶段，测试人员可以参与到UT的Test Case扩充的工作中。

2、服务接口测试

接口自动化技术相对成熟，在基本的框架层面上并没有太多的技术难度问题，主要将公司服务各种协议契约的序列化、报文发送接收解析处理类封装好，加上数据驱动和基本工具类，基于Nunit即可将接口测试代码基本跑起来。

但是接口测试真正要做好产生收益，首先必须要深入业务做到足够的覆盖面和测试深度，其次项目运行的通过率要足够高，以避免测试过程中的人为干预和排错的成本过高以及降低测试结果的权威性。因此，需要在这几个方面重点做工作：

• 基于业务场景的动态测试数据

• 接口依赖

• 多接口串联测试

• 环境稳定性、性能

• 基于测试数据的校验方法

这里重点提一下动态数据，我们的接口自动化失败的test case很多情况下并不是bug，而是发生了未期望的异常情况，其中有一部分都是由于测试数据问题造成的。

因此我们的数据驱动的数据很大程度上不应该是静态的，而是需要是符合现有测试环境的动态数据。不管是通过mock还是做Data Provider，都要保证测试接口的数据需要既符合测试场景又能自动化的做动态调整。

下图是携程机票的测试数据模板，其中数据的模板只涉及请求和响应报文的契约结构（可以自动生成），具体的数据填充则由其他接口在代码中动态填充。

3、UI 自动化测试

Appium在1.6.3开始对IOS新的自动化测试工具XCUITest进行支持，相比较IOS早先使用UIautomation测试，在控件识别的效率和稳定性上都有明显的提升。

外需要使用Facebook提供的开源WebDriverAgent来操控手机与Server通信，但是这个WDA在inspector和获取page resource方面还不足够稳定和完善，目前在支持Native和Hybrid的切换上也还不够便利。大家在实际使用时也可以尝试Macaca团队开发的XCTestWD。

UI自动化测试工作的落地最大的挑战并不是单纯的技术问题，而是如何能够贴近业务利用技术手段来解决实施过程中的阻碍。

UI自动化的目标是提高测试效率以加快迭代速度、降低资源成本、覆盖更大测试范围等，但是UI自动化的特点就是维护和调试成本高，稳定性比起底层自动化差，mobile相对于PC端则更为明显。

因此涉及到的核心问题就是ROI，很多团队无法将UI自动测试一直坚持做下去主要的原因也是ROI无法达到预期。所以需要我们思考如何降低UI自动化的实施成本，其中包括开发成本和运行成本。

UI自动化需要重点关注的领域：

• 降低框架使用门槛（关键字驱动、录制、自然语言解析等…）

• 框架和平台的debug、排错功能

• 脚本跨平台、跨机型、跨版本的复用性

• 基于场景的动态测试数据

• 分布式执行平台（测试设备管理、Test case动态分配、执行、错误重试、远程调试、日志管理…）

• 后台服务依赖Mock

四、自动化测试配套

为了解决上文中提到的自动化过程中动态测试数据、系统依赖、环境稳定、业务校验、脚本执行效率等问题，我们在自动化周边建设配套设施，主要包括提供：

• 动态测试数据工厂：主要包括测试数据的自动化构造、数据库数据后台自动轮询、已使用数据还原

• Mock平台：人工配置接口报文、自动化配置报文、生产流量报文导入等

• 测试校验：可配置化断言、业务报文比对、页面图像比对

• 持续集成环境：自动化构建、测试用例分发、分布式执行、远程调试

在mock平台的建设上，需要把握以下重点：

• 调用方相互隔离

• 支持多种协议报文

• 上下文多接口串联mock

• 生产流量配置报文

• 支持场景化配置报文

• 跨团队的报文配置共享

五、精细化模糊测试

模糊测试是用自动化或者半自动化的方式，采用大量随机的数据输入，来测试系统的响应逻辑的一种测试技术方法。我们提出的精细化模糊测试，就是将大量的随机测试输入进行场景细分，以便于我们能够在测试过程中根据场景需要进行细分测试。

携程机票团队进行精细化的模糊测试，主要是依靠mock平台为中心来设置测试输入数据、利用比对工具的方式来进行结果校验。

具体方法:

• 系统代码中预先根据场景埋入对于标签

• Mock平台通过标签拉取生产环境报文

• Mock平台根据场景建立测试用例填入生产报文

• Mock作为统一数据源接入两套被测系统测试环境

• 批量执行测试用例调用两套测试环境

• 将待测代码的响应结果与基准代码的响应结果对比

小结

综上所述，在敏捷研发模式下，测试基于风险测试同时要兼顾质量和效率的双保障，那么自自动化测试等技术的应用则是势在必行的。

自动化测试并非单一的技术个体，它分布于系统架构的各个层面，也融入于白盒测试、黑盒测试、灰盒测试等多种测试方式中，更重要的是它需要全方位的配套体系的支持，包含且不仅局限于测试前的测试数据、测试用例的自动化构造、测试环境的自动化搭建、后台依赖的隔离，测试中的自动化运行管理、个性化的校验方式，测试后的数据还原、恢复、测试结果聚合报告、排错等等。

这些都属于测试自动化体系中的多个重要环节，每个环境协同配合好才能将自动化测试工作顺畅、健壮、低成本的运行起来，只有这样，我们才能做到不是为了自动化测试而自动化测试。