概述

　　数据驱动在PS产品线是一种常见的自动化方式，由于想法自然、设计简单、收益显著，是一种自动化的常见方案。然而数据驱动却存在着一些缺点让我们很头疼，首先是数据的维护问题，我们需要保存大量的输入和预期输出，模块一旦涉及功能上的升级，我们就需要手动添加测试用例来保证自动化工具的case覆盖率和有效性，同时随着模块不断地升级，数据集不断增大，自动化的执行时间也越来越长；其次是数据驱动在回归测试方面引用广泛，但在新功能测试方面显得不是很有效，新功能测试一般来讲注重的是策略的分析和数据的构造，而数据驱动的思想则不能够很好地支持数据的自动构造，最主要的数据构造过程还是需要手动完成；再次，数据驱动最大的问题就是数据失效问题，一般一个测试点需要对应多组数据，如果模块的一次升级在某个功能点上发生变化，那么对应测试点的几组数据全部都需要修改，前面提到数据驱动的数据集会不断增大，所以数据失效引起的维护成本是不可忽略的，随时间的推移，会越来越大，并且一旦模块功能发生重大升级（如切词升级），很可能引起大片数据的失效，导致工具运行时出现大片的“FAIL”，这时的数据维护成本会急剧上升。在这里我们提出一种基于特征驱动的自动化方案，能够较好解决上述数据驱动方式的三个不足，大大减轻了数据成本的维护工作量，测试工程师的焦点更关注于策略本身，而不必手动构造、添加大量的case。我们首先在架构、代码较为清晰的DA模块上做了尝试，通过该自动化思想下的指引做了DA模块的自动化改造，通过投入试用后发现，相比之前的数据驱动方式，测试效率有了明显的提升。

　　关键词：自动化方案；数据驱动；特征驱动；数据维护

　　介绍

　　所谓特征驱动，是指通过数据的特征来驱动case的验证。所谓基于特征驱动的自动化方案，是指通过保存每个功能点数据的特征来实现case的回归自动化，通过构造特征来实现case的新能能自动化。那么何为特征呢？其实很简单，就是指数据的一些特定属性。看一个DA的数据驱动case，构造输入：“無料アニメ画像掲示板”& 构造预期输出：“R_IBD 11”，这个query之所以返回R_IBD是因为满足两个属性 —— 论坛属性和写真属性，那么这个数据驱动的case，我们就可以改写为，输入特征：“isForum=1,isPhoto=1”& 预期输出：“R_IBD 11”。

　　从case书写的角度看，似乎两者并没有什么本质的区别，只不过一边是真实的query，一边是一串符号，但带来的变化是不可忽视的，第一，case的可读性增强，显然，“isForum=1,isPhoto=1”清楚表达了输入数据的特点以及策略的思想，而单纯一个query放在那儿，只能靠感觉来判断这个输入数据的策略预期；第二，case的表达性增强，用集合论的术语来讲，数据驱动中一组case表示的只是一个元素，而特征驱动中一组case表示的是一个集合，换句话说，“isForum=1,isPhoto=1”不仅代表了“無料アニメ画像掲示板”，而且代表了所有满足论坛属性和写真属性的query；第三，case的有效性加强，直接使用输入数据来存储，一旦切词程序、属性词典等其他因素发生变化，保存数据就可能失效，而属性表达的是数据之上的高级特征，不存在特征失效的问题，除非策略发生了变化或者出现了冲突，即便出现策略冲突情况时，case的可读性也会发挥作用，不会在追查问题上耗费大把的时间。

　　那么在使用了特征表示case以后，如何进行测试点的验证呢？有了一系列特征表示输入，我们首先要通过一个转换工具将特征还原为输入数据，然后再将输入数据导入到数据驱动模式下的自动化。其中重点问题在于如何将特征还原为数据，我们的思路是准备一个比较大的数据集合，如果我们需要构造query就应获取一个比较庞大的query集合，如果需要构造网页就先获取一个比较庞大的url集合，这样我们不需要直接去构造我们想要的数据，而是通过特征从这个数据集当中选取出来即可。当然，有可能满足特征的数据不在这个集合当中，而从实际的情况看，基本不存在这个问题，那query集合举例，从线上随机获取的10w左右的query，基本就能覆盖到大多数的特征，100w基本已经覆盖完毕，从另一种角度上去看，如果从10w随机query中都选取不到，那么我们可以认为策略的影响面已经小于0.001%，要么这个策略本身有问题，要么这个策略其实可以忽略了。

　　应用

　　依据特征驱动的思想，首先在架构清晰、代码简洁的DA模块下进行了尝试。DA是一个典型的对query进行分析的模块，能够根据线下挖掘或实时挖掘得到的一些专名/属性词典，判断query的时效性、图片、视频需求以及同义词、term重要性等信息。DA的现有自动化工具是一个非常完整的基于数据驱动的自动化工具，能够保存query和对应的预期分析结果，并且能够支持相应属性词典的构造，从数据驱动自动化的实现角度可以说非常完整。但不足之处正如前面所提到的几个数据驱动的弱点，需要人工编辑大量的用例数据以及相应的词典，并且升级过程时常会伴有输入数据的失效问题，虽然自动化工具有效提高了自动化率，但显然仍需消耗大量人力在数据的维护上。

　　将数据驱动改造为特征驱动，首先需要将数据进行抽象化，所谓抽象化，就是将数据用更浅显易懂且方便的方式表示，同时大大降低对数据的维护成本。根据DA输入数据以及测试方案的特点，可以考虑将query的某些query级、term级属性抽象出来，用特征来表示输入数据。

　　收益

　　由维护大量的输入数据转变为功能点相关的输入特征，极大简化了数据的维护方式，降低了维护成本。

　　通过一个特征可以抽取出多组数据，测试充分性得到了加强。

　　数据的失效性问题得到了很好地解决，有效防止了策略升级引起的输入数据的大面积失效。

　　总结

　　特征驱动是一种建立在数据驱动之上的一种自动化方案，其思想是通过特征代替原数据来减少维护成本。通过实践，该方案思想主要适用于数据处理密集型的模块，在复杂数据处理的功能测试方面表现良好。10年首先在DA模块上进行了试用，根据DA的策略分析进行了对DA自动化方面的改造，并在10年Q2将自动化工具投入使用，投入的第一个项目就发现了7例bug，其中特征构造时间为5分钟，运行时间为10分钟，DA模块的整体测试效率和项目周期都得到了很大程度上的改善。