适合中小型公司的自动化测试的测试框架，OpenSourceTest

适合中小型公司的自动化测试的测试框架，OpenSourceTest
文档地址：

http://docs.opensourcetest.cn/

代码仓库：

https://github.com/chineseluo/opensourcetest

安装方式：

pip3 install opensourcetest -i https://pypi.tuna.tsinghua.edu.cn/simple

适用人群： OpenSourceTest面向的测试人员，只需要具备基础的python语言基础即可，想要学习自动化，又不会搭建项目架构，对于接口请求响应封装比较弱项的小伙伴，都可以使用OpenSourceTest进行学习。

OpenSourceTest框架（后文简称OST），OST开发于2021年，距今已经三个多年头，历经多个大中小型的项目检验，被频繁集成于各个流水线和多个测试平台中作为基础设施而存在，也可以独立运行，或者集成于jenkins中。内部核心框架使用的pytest，allure，requests，OST本身只基于requests进行了基础封装，帮助测试人员创建干净整洁的项目架构。
为什么OST不进行高度封装，提供更加简单的使用方式，例如类似postman这种工具。
首先我们要明白，对于基础框架进行高度简化使用人操作的封装有哪些优缺点？

• 优点是降低了使用门槛，使很多人知其然，不知其所以然，主打一个能用就行，例如postman，jmeter等，其实对于测试人员的能力发展是相当不友好的。
• 缺点是必然会导致弱化基础框架的功能，越是高度封装，越会使代码变得冗余，基础框架的特性也会被限制的越死，当面对某些复杂的场景，例如物联网/人工智能/大数据等，想要定制化某些功能的时候，变得很困难。
  基于上面两个方面的考虑，OST不会进行过多简化操作的封装，即使封装也不会变更任何基础框架的功能，只是提供一种简化使用的方式，下面简单介绍一下。

首先我们必须明白一些概念，先抛开自动化运行环境/任务调度/统计/平台那些东西，仅从自动化编写来讲，其与测试用例是高度一致的，用例模块划分、前置操作、测试标题、测试步骤、预期结果，实际结果，后置操作，当然还有一些其他的要素，核心都是这几个。

用例模块划分，主要是测试人员对于系统被测功能进行的人为主观上的划分，通常来说建议和业务系统的菜单级别一致，通过一二三级菜单来划分用例模块，在OST中，使用allure的feature/story注解来进行标记，意味着你可以使用所有的allure注解
import allure

@allure.feature(“用户管理”)
@allure.story(“用户列表”)
class TestUserList:
@allure.title(“通过用户名称搜索”)
def test_search_name(self, token):
…
测试标题，测试功能点的简要描述，在OST中，使用allure的title注解来进行标记
@allure.feature(“用户管理”)
@allure.story(“用户列表”)
class TestUserList:
@allure.title(“通过用户名称搜索”)
def test_search_name(self, token):
…
前置步骤/后置步骤，在OST中，直接使用pytest的方式进行编写即可，通过@pytest.fixture(scope=“session”)的作用域进行控制
测试步骤，在OST中，使用allure的step注解来进行标记
@allure.step(“查询成本详情”)
def get_order_cost_detail(token, resellerOrderId, checker=None):
payload = {
“resellerOrderId”: resellerOrderId
}
return start_run_case(OrderList, “订单成本详情”, session_connection=token, checker=checker,
json=payload)

问题来了，从上面的描述来看，似乎OST本身什么都没做，用的都是allure，pytest本身的能力，和平时直接编写自动化脚本没什么不同。
接下来我们看一下OST到底做了什么？
1、帮助测试用户搭建自动化项目测试架构，在你安装opensourcetest之后，可以在控制台通过OST -h 找到OST提供的命令，通过OST start_http_project 项目名称，就会在当前路径，创建一个自动化项目，直接使用pycharm打开即可，内置了一个Login的demo，仿写即可上手。

2、配置了pytest的日志级别，用户根据需要直接修改pytest.ini
3、在run.py中封装了allure的报告生成操作，用户可以根据自己的需求进行修改
4、重点部分，OST创建的项目架构中，有两个比较方便的操作

• 测试接口数据YAML化，通过在YAML中编写接口配置，然后进行YAML对象注册，直接调用对象即可
• requests封装，基于三个维度进行封装，请求/响应/断言
  YAMl对象
  先编写YAML文件，如下所示，通常是基于业务系统的功能模块进行增删改查接口分类
  description: 用户管理-用户列表
  parameters:

  • url: /user/list
    desc: 获取用户列表
    method: post
    headers: {
    “Content-Type”: “application/json”
    }
    params: {}
    data: {}
    json: {}
    files: {}

  • url: /user/delete/$
    desc: 删除用户
    method: delete
    headers: {
    “Content-Type”: “application/json”
    }
    params: { }
    data: { }
    json: { }
    files: { }
    注册YAML对象，在OST创建的项目架构的Parameter中的yamlChoice.py中进行注册
    from opensourcetest.builtin.autoParamInjection import AutoInjection

class User(AutoInjection):
def init(self):
super(User, self).init(self.class.name)
接口请求
在OST创建的项目架构的Base中的requestEngine.py中有一个start_run_case方法，引入即可
[图片]

import allure
from Parameter.yamlChoice import User
from Base.requestEngine import start_run_case

@allure.step(“查询用户列表”)
def get_user_list(token, page=1, pageSize=20, checker=None):
payload = {
“page”: {
“page”: page,
“pageSize”: pageSize
}
}
return start_run_case(User, “获取用户列表”,json=payload, session_connection=token, checker=checker)
在start_run_case中使用yamlChoice中注册的YAML对象User，通过desc和索引进行定位，上面的写法还可以写成
import allure
from Parameter.yamlChoice import User
from Base.requestEngine import start_run_case

@allure.step(“查询用户列表”)
def get_user_list(token, page=1, pageSize=20, checker=None):
payload = {
“page”: {
“page”: page,
“pageSize”: pageSize
}
}
return start_run_case(User, 0,json=payload, session_connection=token, checker=checker)
start_run_case中害包含了session_connection，checker，url_converter，以及隐式重试ost_timeout/ost_poll_frequency，更多内容参考文档：http://docs.opensourcetest.cn/