QECon上海站｜蚂蚁测试用例智能生成技术架构与实践

以下内容来自公众号【蚂蚁技术风险TRaaS]

前言

今年开始，我们看到了越来越多的人开始关注测试用例自动生成这个领域，包括一些Devops产品也在做用例自动生成方面的工作。这里我主要和大家来介绍下测试用例自动生成这个领域的背景、相关研究方向、研究难点，以及在蚂蚁我们是怎么来做测试用例自动生成这件事情的。
 

文章来源于蚂蚁集团技术专家周海莲

一.背景

首先我们来看测试用例自动生成这件事情的背景。随着业务的不断积累和发展，工业界中可以看到大型复杂系统的数量是持续在积累和增长的。在这个过程中，我们对这些复杂系统的测试和维护成本是不断在增加的。不管是开发同学还是测试同学，都需要投入大量的时间在测试用例编写环节。我们也经常会收到一些同学的反馈，比如在一次功能迭代过程中，开发业务代码所需要的时间和开发测试用例所需要的时间可能会达到1 : 1。从这里我们可以看出，开发测试用例环节是存在非常大的提效空间的。
 

在整个快速迭代的背景之下，我们希望能够通过智能化的手段来解决测试时间的投入，其中单测首当其冲。

图1 问题修复成本

从图1可以看出，在迭代环节逐步推进的过程中，环节越靠后时问题修复成本越高，因此我们希望把发现问题的环节尽可能提前，单测就是最早的这个阶段。在单测阶段拦截问题，解决问题的成本是最低的。

单测具备Fast 、 Stable、QuickDiagnosis特性，更适合集成至Devops流水线中进行持续回归

图2 Google测试金字塔

大家应该对Google的测试金字塔比较熟悉，Google测试金字塔中占比最高的是单测用例，达到了80%，再往上才是集成测试、端到端测试。为什么单测能够作为大底座这样的存在呢？主要原因在于单测具备Fast 、 Stable、QuickDiagnosis特性，这些特性使得单测更适合于集成到Devops流水线里面去做持续回归，在我们的项目里面更多比例的测用例也应该是单元测试用例。

实际研发流程中单测比例低，面临开发成本高、运维难等问题

然而，在实际研发流程中，我们看到更多的并不是一个正金字塔，反而是一个倒金字塔。实际项目中单测用例占比往往很低，更多的测试被推到了集成测试、甚至是联调测试阶段。我们发现造成这种现象的主要原因