测试用例之正交验证法
欢迎访问 中国软件工程网 http://www.rjgc.net
由于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相关。而且条件直接的组合可以产生很多种结果。为此我们想到了正交验证分析法（方法本身的定义详见转载），实战只是采用了它的思想并未完全遵循理论。实际测试用例中把第一点和第二点也分开了测试。实战测试用例如下。
|
|
前置条件 |
检查值（是否授权） |
备注 | |
|
|
含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 |
空 |
空 |
< 相关阅读:
导入论坛 引用链接 收藏 分享给好友 推荐到圈子 管理 举报
清空Cookie - 联系我们 - 软件测试网 - 交流论坛 - 空间列表 - 站点存档 - 升级自己的空间
Powered by X-Space
4.0.1 UC
© 2001-2008 Comsenz Inc.
| ||