毕业设计-针对OB-制品项目业务测试方案

一、背景介绍

  • 项目名称:OB-制品项目
  • 项目简介:OceanBase中效能组的一个项目,主要功能就是OB团队各类制品的生产、管理、发布的一个平台。

二、业务介绍

模块:

  • 创建项目;
  • 创建计划;
  • 执行构建;
  • 产物转测试;
  • 产物转上线;

OB数据库有不同的组件:server、agent、procy、等等;这些组件不同团队的人负责,需要发版本、管理、等需求。针对这些组件去创建项目,每个组件有不同的版本,和不同的要求,对应的去创建计划执行构建,就是去做打包操作。完成打包后,转测试去给测试拿去测试、转上线,直接发布上线。

三、架构介绍

项目整体架构非常简单,没有那么多的服务,因为该项目只是去,提高其他项目效能的一个平台。
后端:python语言编写,调用jenkins的api,去执行构建操作。
前端:bigfish3.0 + TechUI +ant design +中台最佳实践(很优雅的一个组合)
环境部署

  • 测试环境,linux环境,拉取代码后,构建前端镜像和后端镜像;完成景象后执行docker-compose命令拉起服务;完成测试环境的搭建。
    后面会优化,利用k8s的namespace,分给测试一些资源,在k8s上搞一套测试环境。
  • 生产环境,k8s。

image

四、测试方案

其实来说,项目特别简单,没有性能上特别的需求(给到了jenkins的job节点压力)、兼容性几乎也不需要(chrome)、安全性(更不需要,蚂蚁网关直接杜绝任何后患~)。所以基本只进行和保障项目的功能即可。

  • 痛点1
    基于docker的测试环境部署;
    幸运的是在此阶段,没有那么多的测试需求,挤时间给敲过了一遍docker。并还写了笔记。
    学习视频地址:9、Swarm集群搭建_哔哩哔哩_bilibili
    个人笔记:我的docker笔记
    笔记中记录了docker课程阶段的一些面试题。
  • 解决方案,就是学。docker学了3个星期、k8s也算过了一遍,大致知道了是什么。
  • 痛点2
    缺少完成的项目流程(需求文档、概要设计文档)
    文档管理混乱

  • 解决方案:输出标准的项目流程,并要求项目组按流程执行项目流程通过。
    方案地址:研发提测的项目流程规范

五、测试过程产出

  • 接口用例
  • 接口自动化用例
  • 功能用例
  • ui自动化用例(主流程)
  • 测试报告

这边由于管控比较严重,任何文档形式的东西,都不让外传。所以接口自动化代码只能截图方式,去介绍怎么去完成的。

5.1 接口用例设计模板

在测试中,无论什么需求,对于测试来说,就是思考:我要怎么去测试它!
在此基础上,去完成测试的归档,等要求。根据当前的项目与进度,便写了这样的一个接口用例模板。


image

5.2 开发的接口文档展示

接口测试需要开发提供什么最重要?除了需求必不可少,其次就是接口文档了,一个好而全的文档,能够省去很多无用的沟通。但是作为测试一定先耐心去看它,然后在提出自己的一些想法。


5.3 接口自动化设计

由于项目属于很正常的项目,也比较简单;在用例中也没有遇到技术上的难点,接口用例设计直接像课程中教的,去直接“拿来”就可以了。但是自己去做的这第一步,真的非常重要,只有真正的去搞过,才能算是一个自动化测试工程师。也会沉淀下自己的一些见解,非常重要。

5.3.1 整体架构介绍

这里是大致介绍了下,整体接口自动化框架的组成。
api层;
数据层;
用例层;
通用功能层;
认真上过接口自动化实战课程的,都非常清楚;项目太大了,就可以分模块;我当前的项目,一般,不到50多个接口,但是我认为这个框架,支撑150个接口,没有丝毫臃肿。再多就得问老师了。

5.3.2 base_api.py介绍

比较基础的base_api;基本就是封装request、多环境的配置、获取唯一id、json_path校验的功能。

5.3.3 wework.py介绍

这里属于是“权限”层,我自己命名的,大的项目,每个业务都是需要不同的权限的,类似于企业微信;返回各个业务的访问权限。当前的我这个小项目,理论上用不到,但是依旧保存了。

5.3.4 业务层介绍

业务层,我的理解就是,系统有多个模块;那么我就给分多个业务;如果涉及到跨系统的,当我没说。。但是也可以通过命名,保留跨系统的模块。一个模块怎么也得20以上的接口数量。将这些接口,全部写到业务层里;保证接口它本身所有的属性“都有”,并且“可配置”即可。更好的优化,可以问下老师。

5.3.5 来个稍微复杂的业务

复杂的业务,其实就是通过调用多个接口,完成一个接口的测试,或者一个业务的测试。看着很多,其实每个接口理顺之后,也就那样。可能我还没遇到更复杂场景的业务有关。可以让老师举例下。

5.4异常场景用例

异常场景,有接口的正向测试;那么就肯定有接口的异常测试;除了接口本身的“功能性”参数之外的异常测试,可能也会有“非功能性”测试:测试方案模板
我把它前三个叫做接口的“功能性”测试,后三个叫做“非功能性测试”。

post或者put类型的接口,用到了json体,这里可以根据自己的需要,去链接数据库或者直接读取,都行。
也可以让老师,谈下自己的方式。




5.5 文件读取的封装

由于文件的不同格式,和所需的返回结果不一样,就干脆每个类型写了一个方法;也可以使用if、else方式,看自己;也可以看下老师的看法。

六、问题汇总

  1. 目前500多用例,执行需要13分钟左右;有什么方法去优化的,最好在10分钟之内。(内部有一个8000用例,执行8分钟的例子,有点恐怖)
  2. 异常场景的用例设计,不知道是否合理,有更好的建议吗?
  3. 接口测试的流程,不知道是否合理,不确定。第一次做,确实没啥信心。
3 个赞

23期小光头来占楼啦!

既然要完成文章输出,就要尽量避免口语化形容,比如 叫做: xxx ,可以优化为:

  • 项目名称: OB-制品项目
  • 项目内容: OceanBase中效能组的一个项目,主要功能就是OB团队各类制品的生产、管理、发布的一个平台。

注意格式问题, 另外如果描述产品形态或者业务架构,可以使用各种类型的图片来代替。比如可以替换为(简略图片)会让人更好理解

同样的问题, 口语化+图片替换文字表达

  • 测试需求:
    • 优先级最高: 功能完整可用
    • 其他需求: 兼容、性能
  • 目前的测试痛点:
    • 缺少完成的项目流程(需求文档、概要设计文档)
    • 文档管理混乱
  • 解决方案: 输出标准的项目流程,并要求项目组按流程执行

代码部分的截图建议补充一下文字说明