功能测试用例深入设计_花样案例汇总

一些定义：

客户端：安卓版app，IOS版app

服务器端：服务器服务范畴内的所有服务（不含数据库，不含nginx，不含防火墙）

接口文档：特指客户端和服务器端的接口文档（两个部门开发协商后的产物）

 

案例一、客户端行为与接口文档中某接口的极度隐晦关系

客户端结构：一层外壳Demo（有游戏，社交软件等），内部支付SDK（被外壳包围，需要支付时调用该SDK）

Demo

SDK

 

 

 

 业务交互场景：

1、DemoA把一个加密后的token传递给服务器端，其中token=md5("DemoA的包名":"com.demoA"+私钥:'ABCDEF123')

2、SDK主动获取DemoA的包名定义为一个变量  sdk_getDemoA_packageName(注意，这里sdk_getDemoA_packageName可能与com.demoA相等或不相等）

3、SDK会把Demo的token和sdk_getDemoA_packageName传递给服务器端

4、服务器端得到2个变量值token和sdk_getDemoA_packageName，服务器端使用"公钥“:"321FEDCBA"对Token进行解密，等到"DemoA的包名":"com.demoA"。用com.demoA与sdk_getDemoA_packageName进行是否相等对比？对比结果=“相等”，则允许客户端继续XXXXX，对比结果≠“相等”则阻止客户端继续XXXXX；

协议：

 

 接口测试：

 TC_1、会给App.Package写一个真实存在的值Value_Pa，给App.Sign写一个 MD5（Value_Pa+“ABCDEF123”）值，请求时把2个参数传递服务器；预期结果：服务器判断App.Package与App.Sign“相等”，验签成功；

 TC_2、会给App.Package写一个真实存在的值Value_Pbbb，给App.Sign写一个 MD5（Value_Pa+“ABCDEF123”）值，请求时把2个参数传递服务器；预期结果：服务器判断App.Package与App.Sign“不相等”，验签失败；

 功能测试：

TC_1、符合登录条件；预期结果：登录成功；

TC_2、账号错误，密码错误，验证码错误，账号被冻结；预期结果：登录失败；

阐述极度隐晦关系的形成原因：

1、接口测试的时候很自然的会忽略掉App.Package，App.Sign的真实来源，只会按照测试用例直接进行赋值并请求接口，“由SDK主动获取，不能商户传入。”是客户端行为，是客户端获取数据后，赋值给app.package。这个时候已经超出接口测试范畴了。这可能是忽略App.Package描述的第一个情况；

2、功能测试的时候，更多参考的是有UI的需求文档，且由于没有明显的界面可见App.Package，Value_Pa，只能通过日志查看，且日志内容项极多事，会忽略App.Package，Value_Pa的真实来源，这可能是忽略App.Package描述的第二个情况；

3、很大可能是，做功能tester和做接口tester不是同一个人，他们之间没有太多交流。甚至功能测试工程师根本就不关心这份接口文档的存在。

综上：真空地带的功能点才是容易会略的地方，将这种功能点的接口文档与功能测试建立联系很难，一旦建立联系测试出BUG的几率很大。

So，功能测试用例应该补充用例TC_3、用户登录符合登录条件，但App.Package和App.Sign在服务器端验签失败，登录失败

解决方案：1、所有测试都看接口文档和需求文档；2、客户端开发和服务器端开发出交互文档，详细描述输入与输出之间关系，供tester参考测试；3、tester看客户端和服务器端代码。。。

 

案例2、期待ing... ...