接口测试演练

接口测试演练

• 实现最基础的测试用例；
• 按照 Page Object 模式封装；
• 业务拆分。

企业微信 API

首先，我们来了解业务模型，先来看下企业微信的项目，它包含了很多功能，在最顶层有一个 API 文档。

这里记录了一些非常重要的功能 API 和服务端 API，今天我们主要使用服务端 API，服务端开发前必读会告诉你一共有多少种重要的 API 说明，比如企业微信需要对外提供服务首先需要提供一个 API，这个 API 会告诉你具体的请求方式，请求地址，请求体，等等。它会以这样的一个格式文档显示给你。

然后，每个接口在调用前都会要求提供一个 access_token，所以你需要先获取一个 access_token 然后才能访问对应的接口，access_token 里面包含过期时间，如果一旦发现 access_token 不可用了就需要刷新它，以上就是企业微信接口的调用流程。

基础测试用例

我们点击外部联系人管理，然后选择客户标签，以这个案例来教你如何编写测试用例。我们先来看下管理企业标签这个接口都有哪几个 case，首先需要获取企业标签库，了解企业微信里有多少个标签，第二个添加一个企业客户标签，第三个是编辑标签，第四个是删除。因为课时原因，今天就以获取、添加和删除企业标签来完成测试用例。

点击获取企业标签库你可以看到请求方式和请求地址，以及包含的参数，你就可以根据这些参数需求来构建你的测试用例，因为时间关系，这里我拿现有的传统类型的 case 来做演示。

在 case 中你可以发现首先需要一个 gettoken，token 中要求提供 corpid 和 corpsecret，所以获取 token 的过程放到了 setup 中。

第二步，需要列举所有已有的标签，所以我们创建了一个获取所有标签的测试用例。

第三个是添加标签的测试用例，添加标签首先需要发起一个 post 请求，然后指明一个 tag。

接下来是删除标签，删除标签的逻辑是先获取所有标签，然后从里面挑出来一个demo04，因为我在添加的测试案例里会添加了一个 demo04，所以需要找到 demo04 的 id，然后删除它，最后通过 format 简单的打印 json 格式。

接下来运行整个 case，你可以发现它包含了 tag_list、tag_add、tag_delete 这三个小 case，整个 case 包含了大量的 request 调用，但这样就会有一个问题，我们举个例子，比如 tag_list，添加标签后你不能只断言结果和状态码是否等于 0，还需要校验是否添加成功，而删除标签也是一样的，它需要先添加一个标签后才可以删除，删除之后也需要断言已删除的标签在列表中已经不存在了，所以 case 中存在大量的重复逻辑，这明显不符合工程规范，这个时候你就可以使用前面我们学习过的 Page Object 模式，我们利用 Page Object 思想把 API 抽象成具体的业务对象，然后调用它就可以了。

Page Object 模式改造

基于这样的思路我们进行一次改造，来学习怎么规范化维护 case，首先在 test_http下面创建一个 wework，然后在 wework 中定义一个类，我们假设 wework 中提供了四个功能，分别是get_token，tag_list，tag_add，tag_delete，我们尝试把原来的 case 进行改造，以便可以支持 PO 思想。

我们先从 get_token 开始改造，代码中你可以看到断言状态码等于 200，学过 PO 的你会知道 PO 有一个原则，就是不要在封装方法内调用断言，我们对它进行改造，首先把这段代码粘贴到 wework中，然后 return 一个 r 就可以了，通过这样一个小的改造我们就把它封装到 get_token 里面了，然后在 TestWeWork 中使用 self.wework=WeWork() 就可以了，接着调用 work 的 get_token 方法，随后给它一个返回值就可以直接调用了，为了确保 case 没问题我们跑下测试用例，有了测试用例的保护我们重构起来也会更放心，整个 case 通过说明我们的改造是成功的。

然后我们继续改造 tag_list，我们把代码粘贴过来，这里面有一个 self.token，这个 token 是当前类实例下面的，如果需要引用它则需要将 WeWork 里面的 self.token 复制到 get_token 中，在当前的实例里面保存一个 token。

然后我们在 tag_list 中改造它，让 r 等于 self.wework.tag_list，然后再跑一边 case，这时有一个报错，提示没有 token，而此时 token 已经被我们挪走了，就可以直接使用 self.wework中的token，但是这些内容也是需要封装的，所以我们一步到位把这段代码粘贴到 wework 里面，放在 tag_add中，然后 return 一个 r。

接下来在 add 中修复它，令 r 等于 self.wework.tag_add，此时需要注意这里需要一个参数，我们看下刚才的内容，在 wework 下面需要在标签中传入一个名字，我们在 wework 中添加一个 demo04，然后就可以添加一个这样的 case 了。

再次执行，发现 add 已经被我们修复了，但是 delete 还没有改造，我们继续修复 delete，将这段代码粘贴到 wework 的 delete 中，同时 return 一个 r，同理在 delete 下面令 r 等于self.wework.tag_delete。

delete 也需要一个名字，我们输入 demo04，delete 中的逻辑首先是获取所有标签，然后在进行删除，所以首先需要有个参数传递。

然后我们从头开始先跑下 tag_list 发现列表中不包含 demo04，然后 add 中会创建一个 demo04并添加到列表中，然后下一步删除 demo04 也成功，所以整个 case 就可以完成了。

但是这个 case 是非常不稳定的，虽然我们对它进行了封装，但是还会存在问题，这时就需要再次进行改造以便让 case 变得更加稳定，比如以 delete 为例，首先需要添加，添加完成之后需要断言标签是否存在。

删除操作也是类似的，删除操作依赖上一次添加成功，如果上一步添加失败了删除也必定受影响，所以通常情况下我们不会依赖上一步的操作结果，除非对上一个操作的结果依赖很重，比如说无法便捷重复的执行依赖步骤，所以大多数情况下会独立创建一个 case，以 delete 为例，我们把添加的代码复制过来，然后为了避免数据冲突我们先添加一个 demo05，因为 deme05 会多次使用，所以我们把它改写成一个 name 参数并完成改造，这样就算上个 case 添加失败也不会影响 delete 操作

这时运行有一个报错显示这个标签是存在过的，这时就涉及另外一个测试话题，如何保障我们的测试环境是干净的，所以要在 setup 中使用 clear 把脏数据提前清理掉，这个你可以课后自己完善，setup 中还有一个需要改进的地方是 self.work，目前是每次执行一次 case 都会初始化，这样成本是比较大的，我们把它改造成 setup_class，升级为 classmethod，然后把 self 换成 cls，通过这个办法就可以不用每次都进行初始化了。

搞定了 case 结构，接下来如果我想添加更多的标签，删除更多的标签，可以使用 Pytest 的一个参数化功能，举个例子，我们可以利用参数化功能为整个 case 添加一个参数 name，然后我们向参数中添加一个特殊字符，比如“中文”“english”“a_b”等等各种复杂的字符，这个你可以课后进行补充，然后执行 case。

---