【分享吧】自动化测试–动态数据规则化构造实践

前言
  在实践中，我们都知道为被测系统模块提供动态的测试输入数据较之静态数据可以显著提高测试覆盖率。因此在自动化测试过程中，测试人员期望动态查询或构造具有多样性的测试数据以提高覆盖率，从而发现更多潜在的问题。因而如何自动生成这些具有多样性的测试输入数据成了软件测试领域的热点问题。为此本文描述并讨论在自动化测试并发执行条件下，动态数据生成技术，以及如何克服传统数据驱动下静态数据准备的弊端，并分享了相关实践。
传统静态数据驱动弊端
  对于传统的数据驱动来说，很多框架的测试数据都是从外部（Excel，Csv，数据库）逐条读取这些静态数据后，放入预先编写好的测试脚本片段中。然而这种手工准备静态数据策略存在多种弊端：
  第一，很多场景下测试数据需要动态改变。比如用户注册，注册后再次运行，很显然会失败。数据的可用性和维护性不好。
  第二，静态数据限于场景单一，数据多样性差，无法发现特殊数据引发的潜在问题，测试覆盖度低。
  第三，这些静态数据池是由业务人员手工进行维护，以简单的数据和脚本分离方式，无法根据场景关键字精确提取数据需求规则自动生成并有效规避构造冲突。
  第四，在用例并发执行的条件下，为了避免数据执行冲突，需要准备庞大测试数据，无法通过数据的循环使用，达到提高数据利用率的作用。
  在用例数量较少且场景比较简单的情况下，人工准备静态数据上述四种弊端表现的并不明显，可以忽略不计。但是如果用例数量达到十万左右，庞大的数据构造冲突和执行冲突的问题，通过人工几乎无法完成。因此我们必须依赖于规则化自动生成动态数据来解决。
动态数据构造面临的困难
  以交易系统举例，无论自动化还是手工测试，动态数据准备都是一项极其复杂的工作。在交易系统中，大概需要至少以下三个步骤
  1.根据测试用例场景的业务需要，划分测试用例中所需数据的种类
  2.从数据库中提取基础数据（如客户，合约等无法在用例执行阶段实时构造的数据）
  3.对基础数据进行构造，解决数据构造冲突（避免已经构造好的数据被重复获取构造）。
  可以看出，若使用手工准备数据，从分析到实施都需要大量人力。在分析上，需要对用例进行逐条分析，建立多个数据组。在构造上除了要查询大量数据之外，还需确保数据互不冲突。但随着准备数据的用例数量增多，数据冲突将呈指数级别增加。人工效率较低，很快达到维护极限，极限后将无法继续在同一数据库中构造更多数据。
自动化数据构造所需的三个能力
  若采用自动化脚本进行动态数据构造，就必须具有以下三个能力：
  1.数据分析：通过关键字提取测试场景所需数据业务需求。
  2.构造锁：永久资源分配，构造好的测试数据（永久性资源，这些数据一旦构造完成，将无法在执行阶段更改）不会被其他业务场景构造影响。
  3.执行锁：临时资源共享，用例执行阶段，共享使用临时性资源（如对账户，合约等仅需当前用例临时占用，使用后可以即时释放且可以随时改变的资源）在并行执行时不冲突。

数据分析：关键字驱动条件下实现动态数据规则化方法
  所谓关键字驱动，就是通过关键字的特定含义，表示用例需要何种类型的数据，需要经过什么样的测试流程，以及完成什么样的验证的设计方法。我们使用高耦合的测试方法，生成一组关键字用来表示一条用例。

  根据上述业务需要我们可以建立如下数据分析模型

  对数据模型进行资源消耗分析
  1.若用例完全成交后，交易限额在当日将无法恢复，因此分配给该用例数据为消耗数据。
  2.若用例未做完全成交，撤单后交易限额可以立即恢复，因此分配给该数据为共享数据。
构造锁：解决数据构造的资源分配问题
  对数据进行充分的分析后，我们还需要提供一种方法确保从数据库中取出的数据不会和其他数据构造脚本冲突。同时还需要创建一个资源池将数据构造阶段的构造好的数据写入，以备自动化用例执行时获取相应数据。
  构造锁-实现数据分配隔离

  构造锁是一种解决资源独占和共享关系的验证方法
  首先所有基础数据来源于数据库的随机查询，然后对基础数据进行构造锁检查，查看该数据资源是否被其他数据构造声明过。若该数据没有被其他数据构造声明，则当前数据构造会对该数据进行声明。声明后，可对数据进行相应的数据构造，使其符合用例对数据的业务需求。最后可以对构造好的数据以文件形式保存在数据包中，在后续执行脚本可以通过访问该文件直接获取所需数据。
  1.私有锁：将声明这条数据为完全独占，声明后任何形式的声明将无法得到该数据
  2.共享锁：将声明这条数据为可共享占用，声明后其他场景脚本可以通过共享声明方式重复使用该数据
执行锁：解决并发数据共享冲突问题
  在自动化测试并行的执行条件下，对同一个环境来说，有些共享资源涉及执行排他问题。多个用例共享一个账号进行测试。但是同一时刻系统又不允许多个用例同时使用同一个账号登录交易系统，那么就需要进入一种排他机制确保使用相同资源进行测试的用例无法在同一时刻并行执行。

  1.测试脚本通过数据包获取测试数据后，声明所使用的测试资源。
  2.检查所使用的测试资源是否已经被占用，若占用该条测试用例将暂停执行，等待数据释放后重新执行。
  3.若数据资源未被占用，则声明用例使用该资源后，用例开始正式执行。
总结
  动态数据构造通过构造锁和执行锁的共同作用完成了动态数据从分配构造到并发执行的一系列过程。确保了在自动化数据构造的过程中进行合理有序的资源分配，避免出现资源的相互抢占，以及动态数据在用例执行并发过程不会并发使用未释放共享资源。
  实际应用中，用例数量逼近十万，过去某些需要人工准备一周的数据量，现在通过自动化数据构造两个小时即可完成。且数据的准确性和完整性有了本质上的提升。彻底解决了数据冲突和无数据挂起等历史性难题。
  在效率上看，不仅实现了动态数据的规则化自动化构造，大幅提高了数据准备的效率和准确性。在质量上看，使用构造脚本根据业务规则进行生产数据的随机选取，构造数据的随机生成，充分保证了数据的多样性。显著提高了自动化测试的覆盖率，让自动化测试可以通过持续测试方式进行数据多样性输入发现更多系统隐藏问题。解决自动化测试数据构造效率与质量兼顾的难题。