接口自动化测试的一点总结

前言

本文是我在公司总结的一点点个人建议, 可能有非常多的遗漏, 先记录下来这时候我的理解。公司是做共享单车业务的, 所以场景基本上也可以复用, 毕竟大家都骑过单车。注明: code是我司接口返回的标志。

编写之前

• 接口相关(这块总结不全)

  了解接口的功能及其使用场景(正常/异常)及接口具体做的事情。

  • 接口实现了什么功能

  • 接口是否有操作了数据库对应字段

  • 接口是否有操作了redis对应key

  • 接口的入参

    包括必填项和选填项丢失/多余带来的影响, 入参字段的长度是否有限制, 如身份证姓名等

  • 接口的出参

    包括正常/异常场景下code, msg等字段的校验, 如有返回数据, 对返回数据的校验如何去做

  • 接口的设计是否符合功能的预期

    如数据不允许重复时, 连续调用接口2次是否会插入2条数据

• 场景准备

  • 掌握每个场景所需要的前置条件

    如关锁接口在 正常使用时，他的前置条件为该车辆的锁已经打开。

  • 考虑如何设计场景

    可选择数据库/redis添加测试数据或调用接口新增数据的办法(接口之间会存在依赖, 一旦添加数据的接口出错, 此场景也无法验证)

• 用例数据准备

  • 尽可能的动态准备测试数据

    如车辆编号, 可选择从数据库捞取。如有身份证号+姓名这种较为复杂的数据, 可写在变量里。但需要多挑选几组数据, 随机读取

  • 数据依赖

    优先采取新增数据的方式, 保证之前数据完好, 新增数据如有name等字段, 可带上特定标识+时间戳的方式。在用例执行完成之后将其清除, 如果出现垃圾数据, 也便于使用定时任务进行清理。

  • 尽量不要把数据写死

• 断言

  对比较重要的字段作断言, 如需要展示给用户的字段。

  • http状态码校验

  • code/msg校验

  • db校验(业务相关, 如无类似情况可忽略)

    存在接口名返回与数据库不一致的情形, 应以接口为主。db目前多使用下划线式, 接口出参常使用驼峰式。编写sql查询语句的时候, 使用select ride_type as rideType此类。

  • 异常场景db校验

    为了防止: 接口出参返回code不为0, 但db却被修改。

  • redis校验

    如有涉及到redis, 需要对redis字段做断言。

  • 最近比较火的异步接口

    异步接口如何做断言, 本人没有太多接触。由于http协议是无状态的, 异步接口一般是调用后将任务放入消息队列, 接口就成功返回了。我的理解是去检查消息队列是否存在消息, 如有如果被消费了, 可起一个收尾类似tearDown的用例专门针对异步接口, 当他们消费完毕之后, 再对数据库/redis进行相关校验。

开始编码

• 编码

  gat是公司内部封装的基于golang的自动化测试框架, 其实只封装了http请求和做了一部分单元测试框架的工作。

  • 用例描述

    用例编写之前, 脑海里应该有以下几点。如何设计场景, 覆盖哪些场景, 如何做断言。可以在文件顶部, 写入自己的思路, 这样在编码过程中会游刃有余, 不至于乱了方寸。之后维护的时候也不至于被业务逻辑绕晕。

  • setUp和tearDown

    目前gat框架是由TestFuncName为入口, 我们可以在函数开始执行后, 调用setUp()函数, 将自己想处理, 想得到的数据都处理完成。再后面就是逻辑的代码, 到最后使用tearDown进行清理。

  • 用例名称与Action对应, 文件名尽量与结构体名一致

  • 大体结构

  • 注释要多写, 常用方法可以封装

    1. /*

    2. 测试功能点: 检查用户行程

    4. 覆盖到的场景:

    5. 1. 用户正在骑行中

    6. 2. 用户未骑行

    8. 数据准备:

    9. 这里填写, 你将怎样制作数据

    11. 数据清理:

    12. 这里填写, 你将如何清理脏数据

    14. 用例执行流程:

    15. 这里写你的执行思路, 首先检测什么测试点, 然后....

    17. 断言:

    18. 写出断言的标准, 理由, 如何做(这也是评审的一部分)

    20. */

    22. package UserCenter

    24. import (

    25. "fmt"

    26. "testing"

    27. )

    29. type struct UserRideCheck {

    30. Data []map[string]interface{} // 测试数据

    31. Action string //调用接口名

    32. }

    34. func (u *UserRideCheck) setUp() {

    35. fmt.Println("用例正准备执行!")

    36. }

    38. func (u *UserRideCheck) tearDown() {

    39. fmt.Println("用例执行完毕, 正在清理!")

    40. }

    42. func (u *UserRideCheck) TestUserRideCheck() {

    43. setUp() // 初始化

    44. //主逻辑, 可再封装函数

    45. defer tearDown() // 清理(后续可添加Recovery防止用例失败阻塞)

    46. }

    48. func init() {

    49. // 自己框架添加用例的逻辑

    50. data := initStruct()

    51. testcase.Cases["UserCenter"] = append(testcase.Cases["UserCenter"], data)

    52. }

    54. func initStruct() *UserRideCheck{

    55. return &UserRideCheck {

    56. Action: "user.ride.check"

    57. }

    58. }

    60. // unittest

    61. func UnitTestUserRideCheck(t *testing.T) {

    62. u := initStruct()

    63. u.TestUserRideCheck()

    64. }

附加:

• 如果可能的话, 对开发做代码走查, 尽可能覆盖其if else分支

• 我们自身的代码也会出错, 我们需要用日志记录测试过程中接口出现的问题以及自己的问题

• 如果可以, 与CI结合

总结：

感谢每一个认真阅读我文章的人！！！

作为一位过来人也是希望大家少走一些弯路，如果你不想再体验一次学习时找不到资料，没人解答问题，坚持几天便放弃的感受的话，在这里我给大家分享一些自动化测试的学习资源，希望能给你前进的路上带来帮助。

1. 文档获取方式：

3. 加入我的软件测试交流群：1007119548免费获取~（同行大佬一起学术交流，每晚都有大佬直播分享技术知识点）

这份文档，对于想从事【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！

以上均可以分享，只需要你搜索vx公众号：程序员雨果，即可免费领取