软件测试中OPENAPI的测试用例编写方法
接口测试用例的编写方式实际上和普通测试用例即有相似的地方也有自身的特点。首先编写测试用例都有用例编号，用例说明，前置条件，测试步骤和检验点五个要素。而前置条件的准备是区别最大的，通常前置条件的准备都是指测试环境（如host配置文件的准备）和测试数据的准备。由于配置文件在每个项目都是相同的。所以一般整个项目只写一次，即在所有TestCase开始的部分进行声明。
接口测试的数据准备通常是通过直接往数据库里边插入数据来实现的。为了保证测试用例之间相互不会干扰，通常需要为每个测试用例单独准备测试数据。这点是和功能自动化测试用例有相似之处，因为他们都是自动化测试。
至于测试步骤和校验点的描述由于接口测试本身也是开发人员，所以可以借鉴程序开发的一些优良习惯，如使用变量来取代具体的描述，这样可以让用例显得简洁。
如@T1=传入参数起始时间
@T2=传入参数结束时间
这样在实际用例编写过程中可以用@T1来表示传入参数起始时间了。
而在用例说明中，实际上有些API用例涉及的流程非常复杂，而需求文档又是条条框框的文字说明。非常难以帮助测试人员理解需求。而且在测试用例评审的时候也很难描述清楚问题，这时候测试人员有必要借助流程图。下面是两个例子
一个例子的图用于描述程序流程
一个例子的图用例描述和时间轴关联比较强烈的用例。之所以涉及时间轴的用例我用图形来表示，是因为我觉得比较直观。所以建议写测试用例的同行在写测试用例的时候不要拘泥于形式，只要能清晰的描述问题，不管黑猫白猫能抓老鼠就是好猫。
如下例：
| Case1 | app_subsc_ctrl的记录行中Statues=1 |
| 测试方法 | TestgetAppSubscCtrlByAppAndInstanceId1 |
| 输入参数 | Appid=”getSubscCtrlApp01” InstanceId= “ getSubscCtrlInstance01” |
| 期望输出，检查点 | return null |
| 测试数据 | 准备Isv_User_Profile表数据,准备APP表数据，准备app_subsc_ctrl记录 |
| Case2 | 应用不存在 |
| 测试方法 | TestgetAppSubscCtrlByAppAndInstanceId2 |
| 输入参数 | Appid=”getSubscCtrlApp01” InstanceId= “ getSubscCtrlInstance02” |
| 期望输出，检查点 | return null |
| 测试数据 | 准备Isv_User_Profile表数据，准备app_subsc_ctrl记录 |
| Case3 | ISV不存在 |
| 测试方法 | TestgetAppSubscCtrlByAppAndInstanceId3 |
| 输入参数 | Appid=”getSubscCtrlApp01” InstanceId= “ getSubscCtrlInstance03” |
| 期望输出，检查点 | return null |
| 测试数据 | 准备Isv_User_Profile表数据,准备APP表数据，准备app_subsc_ctrl记录 |
例二：
| 续订:如图CaseA | 前置条件: 1.准备合法的应用（uu插件） 2.准备合法的isv（国际站） 3.准备合法的用户 4.数据库中存在正在使用的订购 测试步骤 1.设置合法的参数 2.拼装url 3.根据url调用接口 |
其他检查同上，再检查app_subsc_ctrl.begindate=tb1 app_subsc_ctrl.enddate=te2 |
| 续订:如图CaseB | … | 其他检查同上，再检查app_subsc_ctrl.begindate=tb1 app_subsc_ctrl.enddate=te2 |
| 续订:如图CaseC | … | 其他检查同上，再检查app_subsc_ctrl.begindate=今天 app_subsc_ctrl.enddate=te2 |
| 续订:如图CaseD | … | 其他检查同上，再检查app_subsc_ctrl.begindate=today app_subsc_ctrl.enddate=te1 |
| 续订:如图CaseE | … | 其他检查同上，再检查app_subsc_ctrl.begindate=tb1 app_subsc_ctrl.enddate=te1 |
| 续订:如图CaseF | … | 其他检查同上，再检查app_subsc_ctrl.begindate=today app_subsc_ctrl.enddate=te1 |
文章来源于领测软件测试网 https://www.ltesting.net/
