常见分布式系统 Mock+Proxy在SDK项目的自己主动化测试实战(2)

Q:手工测试方法效率低，且easy漏测

A: 正常的功能我们通过手工测试的方法覆盖，而对于client拿到的异常情况的error code要有全量的覆盖，比方我们的错误代码约定了21种，那么针对全部可能出现的错误代码都要想办法触发，这一部分工作希望从case生成到用例运行能100%的自己主动化实现。

有了解决思路，那么须要想办法把想法落地。我们提炼出几个须要攻克的技术难点：

难点一：mock框架选型

做过单元测试的同学应该了解“桩（stub）测试”。即通过hard code方式验证函数的输入输出是否准确和健壮，而mock测试和桩测试相似，功能要更加丰富一些，能够模拟产品交互环节中的部分场景，换句话说，能够让测试工作提前介入研发流程中。

多用于须要联调的环节，比方支付场景，购买流程，第三方插件调用等等业务。之前我们采用的Fiddler重定向请求结果到本地文件的方式模拟服务端的response来欺骗client，也能够理解为mock测试。

最初我们计划自己写一个proxy server指定port，截取全部的http/https请求。再替换response内容完毕mock测试。后来一次偶然的机会接触了阿里开源出来的anyproxy（），了解了一下该工具，发现这款工具刚好满足了我们的几个需求：

代码开源

规则可定制

支持https可视化

易部署、学习成本低

UI可视化。相似fiddler

实际使用截图（我们对response展示做了点优化）：

难点二：可靠的测试用例设计策略

在讨论接口测试用例设计之前，我们须要预先圈定一个思考范围，以免过度的思维发散。

结合我们的业务特征，因为SDK的功能大部分是单接口。少部分是关联接口。因此我们的设计基于单接口而非单个业务场景。

接口的测试用例设计有别于其它测试用例，其业务逻辑主要体如今字段的取值上，每一个取值体现了一种业务逻辑，我们做了一些调研。学习了其它业务团队的接口测试用例写法。发现测试人员喜欢这样设计case：

这种case无疑是工整、直观的，可读性比较强。非常方便的复制粘贴，再通过改动当中的一个或者几个值，形成一个庞大的二维数组。

看到这个表格。一些熟练的测试project师会立刻联想到边界值、等价类设计、正交试验法等。

然而要想保证每一个场景都被完整的覆盖。理论上我们须要测试全部字段的笛卡尔积。这种方式能够保证不论什么取值都会被覆盖到。可是当字段比较多的时候。测试用例的数量会呈爆炸式的增长。常见分布式系统毫无疑问这种方式是不可行的。我们须要一个算法，能做到以下几点：

1、 以最少的组合覆盖尽可能多的场景

2 、覆盖全部字段的全部取值

3 、有统计学支撑，生成的数据有规律可循

有了需求，我们开始进行了可行性方案的研究，秉承不反复造轮子的理念，我们查阅了非常多的资料，逐渐的缩小了范围，在说出解决方式之前，先给大家简介两个重要的算法：“ OATS（Orthogonal Array Testing Strategy）”和“Pairwise/All-Pairs Testing”。简称“正交表法”和“配对测试法”。

正交表法

正交表法有两个重要的特性，大家尝试着理解一下：

1.每列中不同数字出现的次数相等

备注：这一特点表明每一个因素的每一个水平与其它因素的每一个水平参与试验的几率是全然同样的。从而保证了在各个水平中最大限度地排除了其它因素水平的干扰，能有效地比较试验结果并找出最优的试验条件。

2.在随意两列其横向组成的数字对中，每种数字对出现的次数相等

备注：这个特点保证了试验点均匀地分散在因素与水平的全然组合之中，因此具有非常强的代表性。

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-81263-2.html