接口测试原则之测试代码中的判断
作者:网络转载 发布时间:[ 2012/7/9 11:18:07 ] 推荐标签:
前几天把我之前整理的接口测试原则发了上来,不过没有人评论,想想估计写的太简单了,没有几个人明白我说什么,不过前几天有个同学关注到我的这个blog,还问了我问题,我真是很激动,边把他提的问题与关于这条原则的一些理解,发出来与大家分享。
接口测试原则
1、用例代码简单,只覆盖单个场景,不能写判断,如if怎样,则这判断什么,否则判断什么。尽量不catch异常,使用时要配置fail断言一起使用。
2、接口测试代码做到只依赖被测试接口,不要准备数据或者验证数据时调用你还不能完全信任的系统接口(这点可能会有很多争议)。
3、接口要操作数据不能依赖数据库原有的数据,接口产生的数据必须清理。
4、对于接口返回要通过断言进行验证,必须做到用例设计要求。
5、Mock的原则是为了把测试的重点与精力放到我们代码逻辑上来,mock的目标是成功模拟场景。
他的问题和我提的第一个原则有关,是关于测试代码中的含有if的问题,他觉得一些数据校验的方法,实在是太乱了,不好维护。
我研究了一下他发给的代码,有两种情况,第一种
public void doAssertItemConfirmStatus(long itemId, int sign) {
String resultSql = "select * from wlb_order_item where id =" + itemId;
Map sqlMap = wlbJdbcTemplate.queryForMap(resultSql);
if (sign == 1) {
assertThat(sqlMap.get("confirm_status").toString(), equalTo("1"));
} else if (sign == 2) {
assertThat(sqlMap.get("confirm_status").toString(), equalTo("2"));
}
。。。
}
对于这类来讲,由于判断的值是我们调用传递的,是明确知道值的,所以问题不大,一般这种我一般会这样写
assertThat(getConfirmStatus(), equalTo("1"));
下面代码是封装了返回状态的方法
String getConfirmStatus() {
String resultSql = "select * from wlb_order_item where id =" + itemId;
Map sqlMap = wlbJdbcTemplate.queryForMap(resultSql);
return sqlMap.get("confirm_status").toString()
}
还有一类:
public void doAssertWeightAndVolume(FillBackOrderDTO orderDetail, int sign) {
String resultSql = "select * from wlb_order where order_code=‘"
+ orderDetail.getOrderCode() + "‘";
Map sqlMap = wlbJdbcTemplate.queryForMap(resultSql);
if (sign == 1) {
String attributes = sqlMap.get("attributes").toString();
int flag = 0;
Map optionalPropertiesMap = KeyValueParser.parseString2Map(attributes);
if (orderDetail.getPackageWeight() != null) {
assertThat(optionalPropertiesMap.get(OrderConstant.ATT_PACKAGE_WEIGHT).toString(),
equalTo(orderDetail.getPackageWeight().toString()));
}
if (orderDetail.getPackageHeight() != null) {
flag++;
assertThat(optionalPropertiesMap.get(OrderConstant.ATT_PACKAGE_HEIGHT).toString(),
equalTo(orderDetail.getPackageHeight().toString()));
}
。。。
if (flag == 3) {
Double volume = orderDetail.getPackageHeight() * orderDetail.getPackageWidth()
* orderDetail.getPackageLength();
assertThat(optionalPropertiesMap.get(OrderConstant.ATT_PACKAGE_VOLUME).toString(),
equalTo(volume.toString()));
}
} else {
if (sqlMap.get("attributes") == null) {
assertThat(sqlMap.get("attributes"), equalTo(null));
} else {
assertThat(sqlMap.get("attributes").toString(), equalTo(""));
}
}
}
这段中含有 if (orderDetail.getPackageWeight() != null)
因为这个判断的值 orderDetail是接口调用后返回的,根据这个返回值的情况再去判断,比较危险了,一般对我们的case来讲,我们必须要明确这个返回值是什么的。当出现返回值不是你期望的结果时,用例可能发挥不出他的作用了。
对于出现这类判断的原因,我想主要在于我们对于预期值的理解上,我们的每个断言,都必须要清楚要比较什么字段,有明确的字段预期值,而测试代码出现if的原因在于:没有搞清楚预期,如果一个断言要验证什么,还要根据一些情况进行判断,或者预期值还要经过计算,查询数据库之类的操作获得这样其实有出问题的可能了
举个简单的例子
我们要测试这样一个方法 int add(a,b)
我们的正确的断言应是 assertEquals(add(1+2),3),而不是assertEquals(add(1+2),validAdd(2+1))
相关推荐
更新发布
功能测试和接口测试的区别
2023/3/23 14:23:39如何写好测试用例文档
2023/3/22 16:17:39常用的选择回归测试的方式有哪些?
2022/6/14 16:14:27测试流程中需要重点把关几个过程?
2021/10/18 15:37:44性能测试的七种方法
2021/9/17 15:19:29全链路压测优化思路
2021/9/14 15:42:25性能测试流程浅谈
2021/5/28 17:25:47常见的APP性能测试指标
2021/5/8 17:01:11