接口测试设计浅谈

接口测试时属于灰盒测试，是功能测试一种，但是它要求测试工程师熟悉代码，同时还需了解系统设计和接口定义。

API定义

名称                                          访问规则                                  描述

api_trade                               须用户访问                            新增单个评价

 

名称                                             类型                                     描述

Tid                                             String                                交易ID

Oid                                            String                               子订单ID

Result                                       String            评价结果，可选值：good(好评),neutral(中评),bad(差评)

Role                                           String              评价者角色,可选值：seller(卖家)，buyer(买家)              

Content                                     String        评价内容，最大长度：500个汉字。注意：当评价结果为good时就不用输入评价内容。

Anony                                        String         是否匿名，卖家评不能匿名。可选值：true(匿名),false(非匿名)。注意：输入非可选值将会自动转为false

 

 

返回描述

名称                                           类型                                      描述

Tid                                           String                                  交易ID

Oid                                          String                                  子订单ID

Created                                    Date                       评价时间。格式：yyy-MM-dd  HH:mm:ss

 

开发工程师会对这些函数或接口进行定义，描述它的功能、参数列表以及各参数的含义。

 

 

等价类划分设计测试用例

编号              参数名称               有效等价类                                                             无效等价类

A                     Tid                    A1:{正确交易id}                                                  ~A1:{错误交易id}

B                     Oid                   B1:{正确子交易id}                                               ~B1:{错误子交易id}

C                     Result              C1:{"good"};C2:{"neutral"};C3{"bad"}          ~C1:{"others"}

D                     Role                 D1:{"buyer"};D2{"seller"}                                ~D1:{"others"}

E                     Content           E1:{0<len<500};E2{len=0};E3{len=500}        ~E1:{len<500}

F                     Anony              F1:{"true"};F2{"false"}                                     ~F1:{"others"}

 

根据等价类设计测试用例的原则

如下：

1.为每个等价类规定唯一编号

2.设计一个新的测试用例,使其尽可能多的覆盖尚未被覆盖的有效等价类,直到所有的有效等价类都被覆盖为止

3.设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,直到所有的无效等价类都被覆盖为止

按照以上原则，可以得到如表3所示的测试用例设计

表3 改进等价类划分的测试用例

用例编号                          用例组合

1                                  A1B1C1D1E1F1

2                                  A1B1C2D1E1F1

3                                  A1B1C3D1E1F1

4                                  A1B1C1D2E1F1

5                                  A1B1C1D1E2F1

6                                  A1B1C1D1E1F2

7                                  ~A1B1C1D1E1F1

8                                 A1~B1C1D1E1F1

9                                  A1B1~C1D1E1F1

10                                A1B1C1~D1E1F1

11                                A1B1C1D1~E1F1

12                                A1B1C1D1E1~F1

在运用改进等价类划分进行测试用例设计后，测试用例设计仍然可能存在主要逻辑的遗漏，这是因为我们在进行测试用例设计的时候并没有考虑参数间的关联关系。例如：参数Content的描述为：“评价内容，最大长度：500个汉字。注意：当评价结果为good时就不用输入评价内容，评价内容为neutral/bad时需要输入评价内容。”这时，可以发现参数Result的内容与参数Content之间存在关联关系。因此，我们需要对参数间的关联关系进行分析，来完善我们的测试用例。根据因果图法分析，可以定义如下的原因和结果：

原因：

1——Result为"good"

2——Result为"neutral"

3——Result为"bad"

4——Content为""

5——Content为"something"

6——Role为"buyer"

7——Role为"seller"

8——Anony为"true"

9——Anony为"false"

结果：

21—{"traderate_add_resopnse":{"trade_rate":{"created":"2009-10-20 15:53:27","tid":"2230736795","oid";"2230736795"}}};

22—{"error_rsp":{"code":581,"msg":"Rate service and error:中评或差评必须填写评价内容"}}

23—{"error_rsp":{"code":570,"msg":"Rate service and error:中评或差评必须填写评价内容"}}

根据以上分析画出因果图，这里不再画出，根据因果图很容易看到如下3条因果关系

3、4、11(A1B1C2D1E2F1) 结果为22

2、4、11(A1B1C3D1E2F1)结果为22

7、8(A1B1C1D2E1F2)结果为23