51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 1058|回复: 0
打印 上一主题 下一主题

[转贴] 如何搭建接口自动化测试框架?

[复制链接]
  • TA的每日心情
    擦汗
    昨天 09:05
  • 签到天数: 1048 天

    连续签到: 1 天

    [LV.10]测试总司令

    跳转到指定楼层
    1#
    发表于 2022-4-29 09:15:33 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
    为什么要做(自动化)接口测试
      1、由于现在各个系统的复杂度不断上升,导致传统的测试方法成本上升且测试效率大幅下降,而接口测试相对于UI测试更加稳定,且相对容易实现自动化持续集成,可以减少人工回归测试的时间成本,缩短测试周期。
      2、接口测试可以更早的介入到项目开发中,一般只要接口定义好了,就可以写代码了。而功能测试必须要等系统提供可测的界面后才能进行。
      3、相对于UI测试(某些测试环境搞起来贼麻烦)来说,接口测试可以更简单全面地覆盖到底层的代码逻辑,从而发现一些隐藏bug。
      4、从安全层面来说,现在大部分系统前后端框架是分离的,只依赖前端进行限制已经不能满足系统的安全要求,需要后端同步进行控制,所以测试也需要从接口层面进行验证。
      5.越来越多的团队开始接收DevOps所倡导的高度协同,研发、测试、运维及交付一体化的思维,对测试效能提出了更高的要求。
      接口测试原理
      模拟客户端向服务器发送请求,服务器接收后进行处理并向客户端返回应答,客户端再接收应答的过程。
      测试范围
      ·业务功能(包括正常、异常场景是否实现)
      · 业务规则(覆盖度是否全面)
      · 参数验证(边界、业务规则是否达到要求)
      · 异常场景(重复提交、并发提交、事务中断、多机环境、大数据量测试)
      · 性能测试(响应时间、吞吐量、并发数、资源要求)
      · 安全测试(权限验证、SQL注入等)
      一、自动化测试框架规划思路
      1.选择语言
      · python
      · java
      自己擅长哪个选哪个,推荐python
      2.编程工具选型
      · pycharm
      · vscode
      自己擅长哪个选哪个?
      3.测试框架选型
      · unittest ---python自带的测试框架
      · pytest ---unittest升级版,推荐
      · httprunner
      · rf框架 ---关键字
      4.报告可视化方案选型
      · htmltestrunner
      · beautifulreport
      · allure
      5.持续集成方案
      · jenkins
      6.仓库服务器选型
      · github ---服务器在国外
      · gitlab
      · gitee
      7.测试管理工具选型
      · 禅道
      · jira
      接口自动化测试框架的搭建一般有两种思路:
      1.基于工具的
      例如:Postman+Newman+Jenkins+Git/svn Jmeter+Ant+Jenkins+Git/svn
      2.基于代码的
      例如:Python+Requests+Pytest+Allure
      个人建议:如果是学习阶段,选择基于代码的模式,通过自己一步一步的规划项目、编写代码,可以更好的理解接口自动化的实现原理,之后再学习一些工具会更得心应手。
      我这里选择的是: Python+pycharm+pytest+allure+gitlab+jira
      规划好方案后就可以创建我们的项目代码工程了(可以与编写测试用例并行,需要提前约定好测试用例的格式,方便后续代码设计)。
      二、项目代码工程构建思路
      设计框架的原则:
      · 封装基类方法
      对于一些较通用的方法,可以封装,比如发送请求、增、删、改、查。
      · 高内聚低耦合
      每个模块尽可能独立完成自己的功能,不依赖于模块外部的代码。
      模块与模块之间接口的复杂程度尽量低,比如在类内部尽可能减少方法之间的调用,否则一个方法的变动会影响调用它的另一个方法。
      · 脚本分离
      业务代码、测试数据应该相互剥离、灵活调用。理念类似初识PO模式并在Selenium中简单实践中的PO设计模式。代码中应该不出现具体的数据、配置。而是调用对应的数据文件。
      三、一个比较完善的项目代码工程结构:
    - common  #包文件,公共模块,存放一些通用方法
          - baseapi.py
              - class BaseApi()#基类
                  - 方法1:发送请求
                  - 方法2:增
                  - 方法3:删
                  - 方法4:改
                  - 方法5:查
      - libs  #包文件,存放业务层代码
          - login.py #登陆模块
              - class Login(BaseApi) #继承基类里的BaseApi
                  - 方法1:发送登陆请求
                  - 方法2:发送登出请求
          - logout.py #登出模块
              - class Logout(BaseApi)
      - configs  #包文件,存放配置
          - config.py
              - HOST='xxx'#用于切换测试环境
              - url='xxx'
      - datas #文件夹,存放数据/测试用例
          - xxx.xls
          - xxx.yaml
      - testCase #包文件,存放测试用例代码,注意符合pytest命名规范
          - test_login.py
              - class Test_login
                  - 方法1:test_login01
                  - 方法2:test_login02
          - test_logout.py
              - - class Test_logout
                  - 方法1:test_logout01
                  - 方法2:test_logout02
      - outFiles #文件夹,输出文件
          - logs #存放log文件
          - report #存放报告
          - screenShot #存放截图
      - tools #包文件,工具类
          - handle_data.py
          - handle_excel.py
          - handle_path.py
          - handle_yaml.py
      - docs #文件夹,存放说明类文档
          - 代码规范.doc
          - 需求文档.doc

    框架搭建:


     四、后续代码编写思路:
    框架写好后的代码编写思路,大体上为
      1.基类封装,把一些常用的方法比如发送请求、增、删、改、查放到我们的基类里。
      2.编写业务层的接口代码。
      3.编写测试用例代码,过程中发现缺什么就去写什么方法,思考这个方法应该放在具体业务内还是基类还是tools内,这个过程是对代码不断优化的过程。直到我们的用例代码写完。
      比如,写测试用例代码过程中需要读取yaml文件,就在tools内加一个get_yml_data的方法
      再比如,两个业务模块之间需要关联,需要A方法返回对象给B方法用,则去优化A方法,给出返回值。
      再再比如,一些关键节点需要截图,则去补充截图的方法。


    本帖子中包含更多资源

    您需要 登录 才可以下载或查看,没有帐号?(注-册)加入51Testing

    x
    分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
    收藏收藏
    回复

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-11-19 00:32 , Processed in 0.067331 second(s), 24 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表