转载

智能正交请求参数自动化测试

为什么要进行正交请求参数测试

以后台服务的视角看,客户端往往在系统边界之外,不受系统控制。系统收到怎样的请求取决于客户端发出怎样的请求。例如,支付宝券平台,她的服务面向阿里全集团,淘宝、天猫、航旅、彩票等等,都是她的客户端。

客户端可以发出所有可能的正常请求和非法请求。因此,系统不应当对外部请求做任何限定性(如合法性)的假设。如果因为收到客户端发出的非法请求或某种特殊正常请求,而导致系统不能正常工作(严重的如停止服务等)——即使是客户端的错误,系统的容错性、健壮性也是不可接受的。

这是一个浅显的道理,很好理解:只有更强大的容错性和健壮性,才能为客户提供更高质量的服务;另一方面,即使客户端的错误也不应当成为我们犯错的理由,或者说,不能用别人的错误来折磨自己。

为确保系统的容错性、健壮性,就必须对系统进行 完备的正交请求参数测试。正交请求参数测试是一项重要的测试内容,是从源头上确保系统正确响应所有正常请求,并且不受任何非法请求影响的重要的方法。

什么是正交参数

智能正交请求参数自动化测试

一个请求对象往往具有多个参数。如果把每个参数看作一个维度,且每个维度都可以自由变化(即不受任何其他维度的约束),则所有参数的每2个参数都是正交的。

OrthotropicRequestTestBase把请求的每个参数作为一个维度。一个请求有多少个参数就有多少个维度。每个维度可以自由变化,选取所有可能的值,而不受其他维度的约束。显然,正交参数构成的请求对象,就一定能够覆盖所有可能的合法的请求、所有可能的非法的请求。

智能正交请求自动化测试实践

1. 背景

券平台的高可用性要求:以任何合法入参、非法入参及其组合来调用平台的服务接口(如创建券产品服务接口 VcpVoucherProductFacade#createVoucherProduct(VcpCreateVoucherProductRequest request)),都必须确保平台完全不受影响,并且进行恰当的处理。这就必须针对每个对外服务接口,以所有可能的request入参进行无遗漏的测试。如request为null,或者request不为null但它的productCode属性为null,等等。

券平台对外提供券产品创建服务接口是: VcpVoucherProductFacade#createVoucherProduct(VcpCreateVoucherProductRequest request)。如下图所示:

智能正交请求参数自动化测试

2. 编写测试类和测试方法

编写完成的测试类和测试方法如下图所示:

智能正交请求参数自动化测试

  • 编写测试类:从OrthotropicRequestTestBase派生测试类

    InvalidCreateRequestFuncExceptionTest派生自OrthotropicRequestTestBase。基类OrthotropicRequestTestBase将自动解析非法请求配置。所以你的测试类无须再做配置解析工作。另外,OrthotropicRequestTestBase将自动为你生成null request测试用例。你无须再关注整个request入参为null的非法情形。

  • 实现测试方法: 使用@Test(dataProvider=”OrthotropicRequestProvider”)注解。
  • 测试方法形如:
    @Test(dataProvider = "OrthotropicRequestProvider")  public void testXxx(OrthotropicRequest<VcpCreateVoucherProductRequest>  orthotropicRequest)

其中,@Test(dataProvider=”OrthotropicRequestProvider”)注解表明:ATS测试框架(拦截定制了TestNG测试方法调用过程)将向你的测试方法传递一个OrthotropicRequest入参。 OrthotropicRequest支持泛型,支持各类具体的请求类,如 VcpUpdateVoucherProductRequest等,这样测试其他场景和其他类型的请求时可以复用,从而降低同类测试的成本。

3. 生成测试驱动和正交参数配置

第一次运行测试时,OrthotropicRequestTestBase会智能地为你生成定义好格式的空的测试

驱动文件和非法值配置文件。

1) 自动创建测试驱动和正交参数配置提示

智能正交请求参数自动化测试

OrthotropicRequestTestBase已为你自动创建测试驱动和正交参数配置,内容仅包含格式定义和必要信息,需要你进一步完善配置。自动创建的配置中下图所示:

智能正交请求参数自动化测试

2) 测试驱动的内容

智能正交请求参数自动化测试

3) 正交参数配置的内容

智能正交请求参数自动化测试

4. 测试驱动——数据配置入口

采用符合ATS测试框架约定(约定的路径、约定的测试驱动文件名)的测试驱动,以平滑学习曲线并降低应用成本:如

testres/funcExp/InvalidCreateRequest/InvalidCreateRequestFuncExceptionTest.testInvalidCreateRequest.csv,主要内容如下图所示:

智能正交请求参数自动化测试

  • orthotropicRequestConfigFile:指定非法券产品创建请求配置(将由OrthotropicRequestTestBase自动解析)。

5. 券产品创建请求的非法值的配置

orthotropicCreateRequestConfig.csv

智能正交请求参数自动化测试

  • 为请求的每个属性配置所有可能的非法值

    券产品创建请求VcpCreateVoucherProductRequest具有11个属性。原则上说,要逐条配置11个属性的非法值。另外此处简要提及,OrthotropicRequestTestBase提供按类型配置非法值的低成本配置方式。例如:productCode和assetsCode都是“必填的、长度不超过32的字符串”,那么,可以不逐条配置2条属性,取而代之针对java.lang.String类型配置非法值,不再详述。

  • orthotropicValueList——属性非法值列表

    属性非法值列表非常关键,它由一组枚举的非法值构成, 覆盖所有可能的非法 。举几个具有代表性的例子:

    • pid是“必填的、长度不超过16的字符串”。那么,pid所有可能的非法值类型为:

      • 不填,即null或空串
      • 长度超过16的字符串,如“123456789012345678901234567”

      综合起来如上图中pid属性所示。

    • useScene。必填的、存储要求为“长度不超过8的字符串”。业务对useScene的约束为“订单券(‘ORDER’)或支付券(‘PAY’)”。那么,useScene所有可能为非法值的情形为:

      • 不填,即null或空串。
      • 长度超过8的字符串。如“123456789”。
      • 长度不超过8,但字符串内容不为“ORDER”、“PAY”。如“INV”。

      综合起来如上图中useScene属性所示。

    • fundAccounts,保证金账号列表。选填项,即至少应当具有一个保证金账号;存储要求整个列表是“长度不超过1024的字符串”。所以,fundAccounts所有可能的非法值类型为:

      • 不填,即null或空列表。
      • 整个列表的长度超过1024个字符。如,列表包含2个保证金账号,每个账号的长度为513个字符,从而整个列表的长度将超过1024。

      综合起来如上图中fundAccounts属性所示。

6. 验证测试结果

智能正交请求参数自动化测试

从测试报告可以很清晰的看到:

你只编写一个测试方法,但却执行了53个测试用例,并且能够从理论上根据 加法原理 判断完全覆盖了所有请求非法的情形。

思考题

对于一份给定的请求非法值配置,如何计算出将执行的测试用例的个数?这个问题很有思考价值,因为搞清楚这个问题,我们才能判断是否完全覆盖了所有的请求非法的情形!

  • 每个测试用例测试了哪个非法值情形。上图一望而知,不再赘述。

成本收益分析

以券平台创建券产品服务来说,成本收益分析如下表所示:

基于OrthotropicRequestTestBase

传统测试方法

成本收益分析

一个测试方法,执行53个测试用例

53个测试方法

测试方法开发成本为传统方法的 1.9% 。

逐个属性配置非法值:15条配置

逐个非法值罗列:53条组合配置甚至53个配置文件!

配置成本为传统测试方法的 28% 。

测试结果清晰,便于验证是否完全覆盖所有非法情形

容易遗漏个别非法情形,并且很难从数量上予以分析和发现

/

正交请求参数测试的简要分析

典型问题

当客户端以特定请求参数调用服务时,系统需要对请求参数进行完备的校验,以便确定请求的合法性,同时确保系统的正常工作完全不受非法请求的干扰。

为了便于说明问题,选取券平台创建券产品作为简单示例予以说明。券平台对外提供创建券产品服务接口,客户端调用此接口创建券产品。

VcpVoucherProductFacade#createVoucherProduct    (VcpCreateVoucherProductRequest request)

当券平台收到请求后,首先对请求进行合法性校验,然后创建券产品VpProduct对象并将它存储到数据库vp_product数据表中。

服务的定义

智能正交请求参数自动化测试

接口

VcpVoucherProductFacade#createVoucherProduct(VcpCreateVoucherProductRequest request)

接口参数

请求由VcpCreateVoucherProductRequest定义。它有11个属性(如下图所示。不计其中的serialVersionUID),除资金账号fundAccounts的值是字符串列表List<String>外,其余属性的值均为字符串String。

智能正交请求参数自动化测试

之所以属性值多定义为字符串String,是为了将系统与客户端解藕,系统升级(如资金计算类型calcType属性,由现在的“定额”FIXED、“不定额”FLOAT,扩展一种新的类型假设为“按比例”RATIO)时,无须捆绑客户端强制升级。

存储

之所以要把存储的定义予以说明,是因为对于请求合法性校验来说,存储定义往往是请求合法性重要的和主要的依据。券产品领域对象VpProduct最终将存储到vp_product数据表中,如下图所示。

智能正交请求参数自动化测试

定义参数的合法性

一个参数是否合法,取决于它的值是否在其值域内。在值域内则合法,否则就是非法的。所以,要定义参数的合法性,关键是要定义它的值域。

定义参数的值域

决定参数值域的因素,一般包括存储、业务约束等。以券产品创建请求的pid、useScene和fundAccounts参数为例分析如下:

请求参数

存储约束

业务约束

值域

pid

  • nullable:NO。所以pid为必填。
  • varcher(16)。所以pid字符串长度不能超过16。

长度不超16的、非空的字符串。

useScene

  • nullable:NO。所以pid为必填。

业务定义useScene为2种:

2个字符串构成的集合:{“ORDER”,

  • varchar(8)。所以useScene字符串长度不能超过8。
  • “ORDER”(订单券)
  • “PAY”(支付券)两种。

“PAY”}

fundAccounts

  • nullable:NO。所以fundAccounts为必填。
  • varchar(1024)。所以fundAccounts字符串长度不能超过1024。

业务定义fundAccounts为保证金账号列表。

一个或多个保证金账号构成的列表,并且整个列表字符串最终的长度不能超过1024。

请求合法性测试用例设计

合法性测试的目的,是要确保所有的非法的情形下都能正确地工作。合法性用例设计的关键,是要发挥创造力,找出所有的非法值。注意,是非法值而不是合法值。如果请求合法性测试是黄药师的碧海潮生曲,那么,找出所有非法值就是郭靖的鼓点——要把每一个点都敲在“反节奏”上。背后的逻辑是:扛的住所有“反节奏”的鼓点方显碧海潮生曲的功力!才可能是

靠谱的系统服务。

在值域定义清楚以后,非法请求的测试用例设计就很容易了。仍以券产品创建请求的pid、useScene和fundAccounts参数为例分析如下:

请求参数

存储约束

业务约束

值域

非法值用例

pid

  • nullable:NO。所以pid为必填。
  • varcher(16)。所以pid字符串长度不能超过16。

长度不超16的、非空的字符串。

  • null
  • 空字符串
  • 非空串且长度为17

useScene

  • nullable:NO。所以pid为必填。
  • varchar(8)。所以useScene字符串长度不能超过8。

业务定useScene为2种:

  • “ORDER”(订单券)
  • “PAY”(支付券)两种。

2个字符串构成的集合:{“ORDER”, “PAY”}

  • null
  • 空串
  • 非空串且长度为9
  • 非空串且值为“INV”

fundAccounts

  • nullable:NO。所以fundAccounts为必填。
  • varchar(1024)。所以fundAccounts字符串长度不能超过1024。

业务定义fundAccounts为保证金账号列表。

一个或多个保证金账号构成的列表,并且整个列表字符串最终的长度不能超过1024。

  • null
  • 空列表 Collections.EMPT Y_LIST对象
  • 2个保证金账号构成的列表,并且每个
  • 保证金账号字符串的长度均为513

设计出正交的非法值用例,就可以将它们配置到非法值列表中,利用OrthotropicRequestTestBase进行自动化测试及回归了。

常见扩展性问题

智能正交请求参数测试方法在扩展性、高效性方面具有显著优势。比如,当系统发生重构时,如DB重构增删请求参数,或者根据测试覆盖率而增加相应参数值组合,智能正交请求参数测试方法易于扩展,可以随系统进行低成本的重构,并迅速得到回归测试的结果。

智能正交请求参数自动化测试

结论

综合以上,地毯式请求合法性自动化测试——OrthotropicRequestTestBase,具有如下优势:

  1. 遵从ATS框架约定因而易于理解和使用;
  2. 高度可复用的OrthotropicRequestTestBase及其@Test(dataProvider=”OrthotropicRequestProvider”)注解,大幅降低测试的开发成本;
  3. 非法值配置简单易用不易出错且易于提供工具支持;
  4. 测试结果清晰,便于判断是否完全覆盖所有可能的非法的或合法的请求。
  5. 易于扩展。当DB或领域模型重构时,测试用例易于同步演化。

它在工程实践中具有简化测试工作,事半功倍的效果。也在一定程度上把boring乏昧的测试工作变得轻松有趣,快乐工作。

感谢侯伯薇对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ,@丁晓昀),微信(微信号: InfoQChina )关注我们,并与我们的编辑和其他读者朋友交流。

正文到此结束
Loading...