【SIP】OPEN API测试用例之正交验证法

我在上篇关于OPEN API测试用例编写方法中写到，由于OPEN API是相对于设计层面的测试，所以测试用例的编写方法是多种多样的，此所谓不管黑猫白猫能抓老鼠就是好猫。本次在SIP5.4的测试中更是印证了这个道理。在SIP5.4的测试中我采用了正交试验法。

原始需求如下：SIP对用户访问的权限做了新的定义。对ISV的应用（APP）做了等级划分。规定了属于某个等级（APP_LEVEL）的应用只能访问这个等级管辖的API群,而且受该APP_LEVEL的访问频度约束。

新增概念：

API群：指由ISP提供的所有服务+需要单独增添的服务-ISP服务中不可以访问的服务

需求分析。

从原始需求中，我们可以提炼出原始需求其实分为两个部分的内容。

1. 应用对API的访问是否被APP_LEVEL授权的机制。
2. 授权的应用是否被频度控制正确的控制。
再来分析授权机制的影响因素，主要有以下几点
1. 由于主要是通过APP_LEVEL中包含API群的情况来约束对某个API的访问权限。
所以群的因素（A群的个数，B是否在群中）影响测试的结果。
2. 由API群本身组成的机制，又可以得出实际上访问授权机制还受以下的因素影响
C. ISP提供的所有服务(ISPS);D.需要单独添增的服务(INCLUDE_APINAMES);F. 需求排除的服务(EXCLUDE_APINAMES)
我们再深入分析，发现测试的步骤其实都非常简单，不影响测试的结果。也就是说测试结果只和测试的前置条件A,B,C,D,E,F相关。而且条件直接的组合可以产生很多种结果。为此我们想到了正交验证分析法（方法本身的定义详见转载），实战只是采用了它的思想并未完全遵循理论。实际测试用例中把第一点和第二点也分开了测试。实战测试用例如下。

授权测试用例1

	前置条件	检查值（是否授权）	备注
	含Group数量	是否在group中
Case1	0	*	Y	属于该app_leavle的app访问任何api都授权
Case2	1	Y	Y
Case3	1	N	N（报1025）
Case4	5	Y	Y
Case5	5	N	N（报1025）
Case6	n=max	Y	Y

授权检查测试用例2

受权检查2
	前置条件		检查值（是否授权）
	INCLUDE_APINAMES	EXCLUDE_APINAMES	ISPS	是否在（ISPS+IN-EX）中
Case1	空	空	1个	Y	Y
Case2	空	空	1个	N	N
Case3	空	空	多个	Y	Y
Case4	空	空	多个	N	N
Case5	空	非空	1个	Y	Y
Case6	空	非空	1个	N	N
Case7	空	非空	多个	Y	Y
Case8	空	非空	多个	N	N
Case9	非空	非空	1个	Y	Y
Case10	非空	非空	1个	N	N
Case11	非空	非空	多个	Y	Y
Case12	非空	非空	多个	N	N
Case13	非空重复	非空	多个	Y	Y
Case14	非空重复	非空	多个	N	N
Case15	非空多个	非空多个	1个	Y	Y
Case16	非空多个	非空多个	1个	N	N
Case17	非空多个	非空多个	多个	Y	Y
Case18	非空多个	非空多个	多个	N	N
Case19	非空多个	非空多个	空	Y	Y
Case20	非空多个	非空多个	空	N	N
Case21	非空	非空重复	多个	Y	Y
Case22	非空	非空重复	多个	N	N
Case23	非空	api不在isps.apis中	多个	Y	Y
Case24	非空	api不在isps.apis中	多个	N	N

由于SIP的频度控制，之前就有机制。所以必须测试和之前机制的兼容性。这里先介绍一下本次APP_LEVEL对API访问频度的控制和之前的频度控制的关系。如下：应用定制API频率（SIP_CUSTOM_CONFIG本次新增）优先于 API设置频率 （SIP_API原有需求）优先于 默认应用级别频率 （SIP_APP_LEVEL本次新增）优先于 系统默认频率（配置文件原有需求）。

	前置条件	检查值
	SIP_CUSTOM_CONFIG的频度值	SIP_API的频度值	SIP_APP_LEVEL频度值	antx.property.accessValve	antx.property.MaxaccessValve
Case1	10	20	30	40	50	10
Case2	10	20	30	40	5	5
Case3	不限制	30	20	40	50	30
Case4	不限制	不限制	45	40	50	45
Case5	不限制	不限制	不限制	40	50	40

在文章的结尾，感谢一下我们公司的文初同学对本次测试用例的建议和对测试工作一贯的支持！