【测试左移专栏】测试左移实践探讨 ——测试左移在腾讯地图SDK的实践

作者:赵丽娜

团队:腾讯移动品质中心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:

版权所属,禁止转载

已标记关键词 清除标记
相关推荐
©️2020 CSDN 皮肤主题: 编程工作室 设计师:CSDN官方博客 返回首页