作者:赵丽娜

团队：腾讯移动品质中心TMQ

我理解的”测试左移”，即将测试活动与开发活动结合更加紧密， 同步于开发活动甚至早于开发活动便开始的质量保障活动。业界已有关于测试前置的一些讨论, 因此本文也沿用测试前置的概念. 本文将讲解测试前置在腾讯地图SDK的实践情况。鉴于APP与SDK的不同形式，APP类产品在实践测试前置方法时需做适当调整。

一、持续测试过程

测试前置的前提是持续集成和持续测试，持续测试的前提是自动化测试。自动化测试的实现离不开好的测试框架和测试平台的支持。地图SDK之所以能逐渐做到测试前置，正是依赖于地图SDK在自动化测试的积累。详细的测试框架介绍请期待后续tmq相关文章。

持续测试过程中，开发工程和测试工程的统一使得自动化测试校验点增强，同时也使得测试用例开发与开发功能开发同步进行变得可能。

二、测试前置活动

1、引入测试前置活动的原因

通过对版本bug的系统分析，我们发现基础类问题占比达到30%(如图1)，基础类问题是可以通过codereview，静态扫描，或者单元测试活动发现的，大量的基础类问题遗留到测试执行阶段，浪费了测试成本，也增加了问题定位成本。另外通过Coverity扫描发现静态扫描问题多 (如图2)，潜在稳定性风险大。因此我们认为测试前置活动是有必要的。

图1 Bug根因构成

图2 静态扫描问题对比

2、测试前置活动

测试前置活动包含两方面内容，一是开发参与质量保证；二是测试活动提前。开发参与质量保证的活动有CodeReview，进行静态扫描并扫清扫描中出现的问题，和高质量的自测。业界开发自测通常采用UT的方式。在本产品中，自测以功能验证方式为主。

图3描述了从需求评审开始，测试线与开发线并行进行的活动过程。在开发线，开发通过需求文档映射到设计文档（由于互联网应用的快节奏，在小feature中可跳过。） 这时测试线同步进行手工测试用例的设计和编写。开发线进一步在梳理接口后输出比较确定的接口定义，测试线基于接口定义进行自动化用例和测试demo的实现。开发代码完成时，由于在同一工程下，测试用例代码可实时（或相对实时）与开发代码集成和调试，开发code review，自测的过程的同时自动化测试用例也在调试中。提测后，测试进入手工测试环节，关注在复杂逻辑和效果验证。

图3: 测试前置流程

汇而总之,目前采用的测试前置活动如下:

（1）手工用例提测前输出；

（2）自动化用例提测前编写和调试；

（3）代码静态扫描；

（4）code review。

3、测试前置效果检测

我们定义测试交付件包括手工用例，自动化用例，bug和符合测试准出标准的被测包。我们通过每个版本中的bug ODC分析来检查是否有基础问题遗留到后期手工测试阶段，遗留的问题是由于什么原因引起的，进而反作用于测试前置流程，完善测试前置流程。

以下举例说明。图4和图5为一次ODC分析结果，从图中可以看出基本功能覆盖引起的问题占问题总量40+%，基础类的问题(条件检查、初始化、算法基本逻辑等)占有效问题50%。说明本次测试中，测试前置效果不好。进一步分析，基础类问题集中在一个feature上，最终调研发现，该feature没有开展测试前置活动。

图4: ODC触发原因分析

图5: ODC缺陷类型分析

汇总一下, 检测步骤如下:

（1）测试结果ODC分析；

（2） 结果反馈跟进；

（3）反馈完善测试前置流程和方法。

三、测试前置的下一步——UT

从上面的讨论我们已了解，单元测试也是测试前置的重要活动。但单元测试在互联网产品尤其是前端实施阻力非常大，因此我们通过一定原则筛选出一些适合做单元测试的模块，目前正在实践中，有一定实践效果再与大家分享。

筛选的原则如下：

1、逻辑性强的模块；

2、当前测试用例代码覆盖率低的模块；

3、代码可测性高的模块：我们是从函数扇入扇出、函数行数、函数深度、函数圈复杂度等方面进行函数分级。

原文链接：http://tmq.cs0309.3g.qq.com/2017/06/sdk/

获取更多测试干货，关注腾讯移动品质中心TMQ：

版权所属，禁止转载