手把手带你设计接口自动化测试用例(二)：根据接口信息设计测试用例

上一篇文章 手把手带你设计接口自动化测试用例(一)：提取接口信息并分析 详细介绍了如何提取并分析登录、发布、修改、删除、查询等接口信息，这篇文章来看一下如何根据接口信息设计测试用例。

ZrLog 系统接口测试用例的字段可以设计为 3 个部分，分别是主测试用例的字段(重要)、配置信息的字段、执行结果记录的字段。下面分别介绍这 3 部分字段的名称和含义。

1、设计主测试用例的字段

主测试用例的字段一般包含用例标识的字段、请求信息的字段和响应信息的字段，响应信息的字段一般作为接口用例执行结果的断言字段；另外由于本书的接口涉及 cookies 信息及接口之间的关联信息，所以需要加上 cookies 字段及接口关联字段。基于以上规则，ZrLog 系统主测试用例的字段设计如表1 所示。

表1 主测试用例的字段

2、设计配置信息的字段

配置信息的字段一般用来存放接口自动化框架中所需要的各类环境配置信息，具体需要哪些字段，在实际中可根据项目需求灵活设置，在 ZrLog 系统中对配置信息设置了 4 个常用字段，如表2 所示。

表2 配置信息的字段

 3、设计执行结果记录字段

执行结果记录的字段主要用来存放测试用例执行的最终结果及相关的信息。具体需要设置哪些字段可根据项目情况灵活决定。

在 ZrLog 系统中对执行结果记录设置了以下常用的 5 个字段，如表3 所示。

表3 执行结果记录的字段

 4、设计主测试用例内容并解决关联关系

接口测试用例与功能测试用例本质上并无区别，常用的设计方法有：有效、无效、边界、错误推测、场景法、正交法等。接口测试包括单接口测试和多接口测试，单接口测试是指针对单个接口的用例设计，而多接口测试是指针对多个接口的用例设计，一般是基于正向的业务流程去设计用例，并且要处理上下游接口的关联关系。

基于此规则，对于文章 手把手带你设计接口自动化测试用例(一)：提取接口信息并分析 的 5 个接口，共设计出 11 个测试用例。其中登录接口为单接口，一共设计了 7 个用例；其他的 4 个接口为多个接口，一共设计了 4 个用例。主测试用例的内容及结构如图1、图2所示。

图1 主测试用例的内容及结构(1)

图2 主测试用例的内容及结构(2)

用例分析如下。

• 第 1 个测试用例为登录接口的测试用例，使用了错误的密码进行登录，登录过程无须携带 cookies，所以 cookies 字段设置为空，登录失败后，预期的业务状态码为 1。如果服务端响应的业务状态码不为 1，则代表此测试用例执行没有通过。

• 第 2个测试用例为登录接口的测试用例，请求主体信息中不携带密码这个参数，登录过程无须携带 cookies，所以 cookies 字段设置为空，预期的业务状态码为 1。如果服务端响应的业务状态码不为 1，则表明此测试用例执行没有通过。

• 第 3个测试用例为登录接口的测试用例，请求主体信息中使用了错误的用户名，登录过程无须携带 cookies，所以 cookies 字段设置为空，预期的业务状态码为 1。如果服务端响应的业务状态码不为 1，则表明此测试用例执行没有通过。

• 第 4个测试用例为登录接口的测试用例，请求主体信息中用户名参数使用非字符串类型的数据，登录过程无须携带 cookies，所以 cookies 字段设置为空，预期的业务状态码为 1。如果服务端响应的业务状态码不为 1，则表明此测试用例执行没有通过。

• 第 5个测试用例为登录接口的测试用例，请求主体信息中不携带用户名参数，登录过程无须携带 cookies，所以 cookies 字段设置为空，预期的业务状态码为 1。如果服务端响应的业务状态码不为 1，则表明此测试用例执行没有通过。

• 第 6个测试用例为登录接口的测试用例，请求主体信息中用户名为空字符串，登录过程无须携带 cookies，所以 cookies 字段设置为空，预期的业务状态码为 1。如果服务端响应的业务状态码不为 1，则表明此测试用例执行没有通过。

• 第 7个测试用例为登录接口的测试用例，请求主体信息中使用了正确的用户和密码进行登录，登录过程无须携带 cookies，所以 cookies 字段设置为空，登录成功之后服务端响应的预期的业务状态码为 0。如果服务端响应的业务状态码不为 0，则表明此测试用例执行没有通过。另外， 用户登录成功之后，会在服务端产生 cookies 信息。在 relation 字段中设置了 token=cookiess.admin-token，它代表的含义是取得 cookies 信息中的 admin-token 字段的值，并把这个值赋给变量 token，以便下游接口引用 token 变量而得到 cookies 的秘钥。

• 第 8个测试用例为发布文章接口的测试用例，在 cookies 字段中设置了{"admin-token" : "${token}"}，这说明发布文章过程中需要携带 cookies信息，且 cookies 信息中键为“admin-token”，其值引用了登录接口中所设置的 token 这个变量。从 request_body 字段的信息中可以看到发布文章的标题(title 为标题参数)为“付出”，文章别名(alias 为别名参数)为“付出”。在文章发布成功后，将会产生文章的 id 号和文章的 alias (文章别名)，所以又在 relation 字段中设置了 id_name=body.id,alias_ name=body.alias，它代表的含义是取到响应正文中的 id 号，并把它赋给变量 id_name；同时取到响应正文中的 alias(文章别名)，并把它赋给变量 alias_name，以便下游接口可以引用这两个变量。最后，当文章发布成功之后，服务端响应的预期业务状态码为 0。如果服务端响应的业务状态码不为 0，则表明此测试用例执行没有通过。

• 第 9个测试用例为修改文章接口的测试用例，在 cookies 字段中设置了{"admin-token" : "${token}"}，这说明修改文章过程中需要携带 cookies 信息，且 cookies 信息中键为“admin-token”，其值引用了登录接口测试用例中所设置的 token 这个变量。从 request_body 字段的信息中可以看到，文章的 id 号引用的是发布文章接口测试用例中设置的 id_name 这个变量的值，文章的 alias 引用的是发布文章接口测试用例设置的 alias_ name 这个变量，也就是说要修改的文章是 id 为 id_name 的文章，并且在修改过程中把文章的标题修改成了“付出才能杰出”。最后，在文章修改成功之后，服务端响应的预期业务状态码为 0。如果服务端响应的业务状态码不为 0，则表明此测试用例执行没有通过。

• 第 10 个测试用例为删除文章接口的测试用例，在 cookies 字段中设置了{"admin-token" : "${token}"}，这说明文章过程中需要携带 cookies 信息，且 cookies 信息中键为“admin-token”，其值引用了登录接口测试用例中所设置的 token 这个变量。从 request_body 字段的信息中可以看到，要删除的文章的 id 号引用的是发布文章接口测试用例中设置的 id_name这个变量的值，这说明要删除的文章是 id 为 id_name 的文章。最后，在文章删除成功之后，服务端响应的预期业务状态码为 0。如果服务端响应的业务状态码不为 0，则表明此测试用例执行没有通过。

• 第 11 个测试用例为查询文章接口的测试用例，在 cookies 字段中设置了{"admin-token" : "${token}"}，这说明查询文章过程中需要携带 cookies 信息，且 cookies 信息中键为“admin-token”，其值引用了登录接口测试用例中所设置的 token 这个变量。因为此接口的请求方式为 GET 请求，所以 request_body 字段中信息为空，请求的参数直接放在 url 中。最后，由于文章已删除，查询的结果为空才是正常的，服务端响应的预期业务状态码应该为 0。如果服务端响应的业务状态码不为 0，则表明此测试用例执行没有通过。

 5、设计配置信息的内容

本框架中所涉及的配置信息是被测环境服务器的 IP 地址，在配置信息中设置服务端的 IP 地址，其原因在于可以将服务器的 IP 地址从接口地址中分离出来，主要是因为一旦服务器的 IP 地址要改变，只需要在配置信息的字段进行更改便可，而不需要到每个接口用例当中对 url 中的 IP 地址进行一一更改，以实现公共数据的分离。在实际项目中具体需要在配置信息的字段中设置哪些内容，可根据项目需求灵活设置。ZrLog 系统配置信息字段的内容如图3所示。

图3 配置信息字段的内容

6、执行结果记录的内容

执行结果记录字段的内容是由程序运行之后自动填充，无须手工填写。

下一篇文章将分享如何建立数据库实例和主测试用例表，敬请期待！