zoukankan      html  css  js  c++  java
  • 接口自动化测试的一点总结

    前言

    本文是我在公司总结的一点点个人建议, 可能有非常多的遗漏, 先记录下来这时候我的理解。公司是做共享单车业务的, 所以场景基本上也可以复用, 毕竟大家都骑过单车。注明: 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. 用户未骑行
        
        数据准备:
        这里填写, 你将怎样制作数据
        
        数据清理:
        这里填写, 你将如何清理脏数据
        
        用例执行流程:
        这里写你的执行思路, 首先检测什么测试点, 然后....
        
        断言:
        写出断言的标准, 理由, 如何做(这也是评审的一部分)
        
        */
        
        package UserCenter
        
        import (
                "fmt"
                "testing"
                )
        
        type struct UserRideCheck {
            Data []map[string]interface{} // 测试数据
            Action string  //调用接口名
        }
        
        func (u *UserRideCheck) setUp() {
            fmt.Println("用例正准备执行!")
        }
        
        func (u *UserRideCheck) tearDown() {
            fmt.Println("用例执行完毕, 正在清理!")
        }
        
        func (u *UserRideCheck) TestUserRideCheck() {
            setUp()  // 初始化
            //主逻辑, 可再封装函数
            defer tearDown()  // 清理(后续可添加Recovery防止用例失败阻塞)
        }
        
        func init() {
            // 自己框架添加用例的逻辑
            data := initStruct()
            testcase.Cases["UserCenter"] = append(testcase.Cases["UserCenter"], data)
        }
        
        func initStruct() *UserRideCheck{
            return &UserRideCheck {
                Action: "user.ride.check"
            }
        }
        
        // unittest
        func UnitTestUserRideCheck(t *testing.T) {
            u := initStruct()
            u.TestUserRideCheck()
        }
        

    附加:

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

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

    • 如果可以, 与CI结合

  • 相关阅读:
    poj 2411 Mondriaan's Dream 骨牌铺放 状压dp
    zoj 3471 Most Powerful (有向图)最大生成树 状压dp
    poj 2280 Islands and Bridges 哈密尔顿路 状压dp
    hdu 3001 Travelling 经过所有点(最多两次)的最短路径 三进制状压dp
    poj 3311 Hie with the Pie 经过所有点(可重)的最短路径 floyd + 状压dp
    poj 1185 炮兵阵地 状压dp
    poj 3254 Corn Fields 状压dp入门
    loj 6278 6279 数列分块入门 2 3
    VIM记事——大小写转换
    DKIM支持样本上传做检测的网站
  • 原文地址:https://www.cnblogs.com/we8fans/p/9156488.html
Copyright © 2011-2022 走看看