从效率和难易程度的角度对接口测试用例进行分级

[TOC]

简单用例 - 10条/天

接口文档中有详细描述，必须包含：

• 参数的类型
• 是否为可选参数
• 明确该接口正常、异常返回值

尽量包含：

• 参数的可能取值范围

有些参数，比如int，一般情况下取值范围是-2147483648~2147483647；比如 timestamp，一般指“unix时间戳”，即从1970年1月1日开始所经过的秒数。类似这种参数可以不用特殊声明。

但是有些参数是该接口/项目特有参数，与通常意义上的取值不同，这种情况一定要说明。例如，微校的school_code（学校标识码），它的取值是int(10)

进阶用例 - 7条/天

相对简单用例，某些参数可能取值、或返回值的情况在文档中没有明确描述，例如：

• 微校-通知数据明细 接口，mark参数：当给mark参数取值为一个不存在的值，HTTP Status Code为200，返回值return code为1004；当请求中不携带mark参数时，HTTP Status Code为422，返回值return code为1000。也就是说，两种情况的HTTP Status Code和returun code均不相同。这种情况接口文档中并未详细列出，在编写测试用例时需要进行调试，并且根据经验判断是否BUG，还有可能需要与项目团队进行二次确认。

当HTTP Status Code能满足需求时，直接使用HTTP协议定义的返回值；当不满足需求（无法准确描述原因时），使用自定义返回值（return code）。这是一种常见的做法，并非BUG。

• 文档中未明确写明返回值（比较常见），或者只有一个通用的规则。这种情况，需要测试人员根据常理推断、逐条调试，还需要经常与项目组接口人或对应开发沟通确认，相对比较耗时。

复杂用例 - 1～3条/天

这里面可能包含几种情况：

• 用例逻辑复杂，前置条件较多。例如，需要通过调用多个接口才能实现的复杂逻辑；有些接口需要动态构造参数/测试数据，不能写死。
• 某些情况下复杂参数。例如，Tgit 的”给指定用户创建一个 SSH key”接口，这时候需要查阅资料才能知道SSH KEY除了rsa，还有dsa、ecdsa等类型；不同类型，取值范围也可能是1024~2048、256~512不等。并且因为平台不能安装第三方库，还需要借助外部（例如腾讯云的无服务器云函数-Serverless Cloud Function）来实现，有一定的开发工作量。
• 平台的限制，如不能控制用例执行顺序、用例之间不能共享数据。遇到这种问题，需要借助第三方服务来实现。
• 一些公有函数（方法）的封装，比较常见的就是签名/加密算法。一方面，接口文档未提供对应语言的实现（平台支持的是python），需要我们参照其他语言或干脆从零开始开发；另一方面，算法demo不能满足需求。例如，微校的接口文档明确指明了“如果参数的值为空不参与签名”，但是有种情况是参数值为’’(空字符串)，这里仅列出签名的第一步“排序”的不同：

# 按照文档编写的签名“排序”算法：
sorted_list = sorted(filter(lambda x: x[-1] and x[0].lower().strip() != 'sign', kwargs.items()), key=lambda x: x[0])

# 改进后的算法：
sorted_list = sorted(filter(lambda x: x[-1] is not None and x[0].lower().strip() != 'sign', kwargs.items()),key=lambda x: x[0])

# 如果不这么改进，测试接口时直接卡在了签名校验这一环节，不能真正到达“参数为空字符串”这一逻辑

因为测试人员不仅要在代码中找到编码实现的缺陷，更要发现设计和编程人员解决问题方法上的局限、思路中的狭隘和技能方面的不足。所以可能会提出一些，在开发人员看来“不合常理”的场景，而这些场景，可能需要测试人员花费精力去沟通，去编码和优化，所以遇到复杂的用例实际工作量是很难评估的，这里也只是根据经验提供一个效率供参考。