成功时，返回JSON数据包：
{
"code":0,
"msg":"查询订单列表成功！",
"data":{
"pNo":1,
"rCount":5,
"orderTotalPriceTotal":23.3,
"platformTotalIncomePriceTotal":0,
"lst":[
{
"orderTitle":"kouxiangtang",
"settlePrice":15.89,
"cashTotal":15.89,
"posTotal":0,
"onLineTotal":0,
"orderTime":"2015-09-2913:44:26",
"orderId":"12345679282015092913440268141",
"mobile":"13424183952"
},
{
"orderTitle":"红塔山",
"settlePrice":7.5,
"cashTotal":7.5,
"posTotal":0,
"onLineTotal":0,
"orderTime":"2015-09-2911:37:58",
"orderId":"12345679282015092911370588273"
}
]
}
}
用例设计
存在问题：
如上，还没写完就有40几条用例了，要是接口参数再多点，接口数量再增加点，工作量可想而知，所以，问题来了，咋办呢？
个人见解：
1、根据接口的使用对象(外部，系统内部)，有选择的去、留部分用例
2、根据接口的是否核心接口，有选择的去、留部分用例
3、根据参数说明，及实际情况，有选择的去、留部分用例
实例：
上例这个接口，是供app、商铺后台调用的，且为系统内部调用，所以，以下用例可酌情略去：
test-E-按商铺id查询-商铺id非int型
test-E-按设备token查询-token非string类型
test-E-按订单时间类型查询-时间类型非int型
test-E-按起始日期查询-时间类型非date型
test-E-按结束日期查询-时间类型非date型
test-E-按订单状态查询-订单状态非string类型
test-E-按交易状态查询-交易状态非int型
test-E-按支付方式查询-支付方式非int值
test-E-按收银员查询-收银员id非int值
test-E-按导购员查询-导购员id非int值
test-E-按页码查询-页码非int值
理由：
这个接口是给其它开发于系统内部调用的，开发过程中，开发者肯定需要调用这些接口，如果类型错了，他们也就获取不到预期的数据，这些错误，他们肯定可以发现，所以，他们传递的参数值一般能保证类型正确。
test-N-按参数类型最大值查询所有参数
test-E-按商铺id查询-商铺id超过类型范围值
test-E-按订单状态查询-订单状态值超过类型最大值
test-E-按交易状态查询-交易状态值超过int类型最大值
略去的用例部分（参数值超过类型最大值）
理由：
1、内部调用，参数值不是外部手动输入的，输入数据长度、值大小可控，当然如果数据一直增长，那再大的类型可能都无法保证不超出，比如自动增长的商铺id
2、部分参数的参数值是自定义的，比如订单时间类型，就那几种，除非传错了，不然不可能超出范围
最后简化后的用例数差不多28条，如果是手工测试，对于正向用例，根据等价类原理，可以制造一条数据，覆盖多条用例，当然，也可以冗余处理，即一条用例一条数据，这样的好处就是每次的验证点比较单一一点，比较有针对性。
问题
如果是自动化测试呢，这里是设计一个方法覆盖多条用例呢(如上，一条数据，覆盖多条用例)？还是一个方法覆盖一条用例呢？
我个人的答案是一个方法一条用例，你的呢？
