第二部分
动态生成pytest认可的测试用例
首先说明下pytest的运行机制，pytest首先会在当前目录下查找conftest.py文件，如果找到了，则先运行它，然后根据命令行参数去指定的目录下查找test开头或结尾的.py文件，如果找到了，如果找到了，再分析Fixture，如果有session或module类型的，并且参数autotest = True或标记了pytest.mark.usefixtures（a ...），则先运行它们；再去依次找类，方法等，规则类似。大概就是这样一个过程。
可以修剪，pytest测试运行起来的关键是，必须至少有一个pytest发现机制认可的testxx.py文件，文件中有TestxxClass类，类中至少有一个Def testxx（self）方法。
现在并没有任何pytest认可的测试文件，所以我的想法是先创建一个引导型的测试文件，它负责让pytest动起来。可以用pytest.skip（）让其中的测试方法跳过。然后我们的目标是在pytest动起来之后，怎么动态生成用例，然后发现这些用例，执行这些用例，生成测试报告，一气呵成。
# test_bootstrap.pyimport pytestclass TestStarter(object): def test_start(self): pytest.skip(' 此为测试启动方法 , 不执行 ')我想到的是通过夹具，因为夹具有设置的能力，这样我通过定义一个scope为session的夹具，然后在TestStarter上面标记使用，就可以在引入TestStarter之前预先处理一些事情，那么我把生成用例的操作放在这个灯具里就能完成目标了。
# test_bootstrap.pyimport pytest@pytest.mark.usefixtures('te', 'test_cases')class TestStarter(object): def test_start(self): pytest.skip(' 此为测试启动方法 , 不执行 ')pytest有一个--rootdir参数，该fixture的核心目的就是，通过--rootdir获取到目标目录，找到里面的.yml测试文件，运行后获得测试数据，然后为每个目录创建一份testxx.py的测试文件，文件内容就是内容变量的内容，然后把这些参数再传给pytest.main（）方法执行测试用例的测试，也就是在pytest内部再运行了一个pytest！最后把生成的测试文件删除。注意该夹具要定义在conftest.py里面，因为pytest对于conftest中定义的内容有自发现能力，不需要额外导入。
# conftest.py@pytest.fixture(scope='session')def test_cases(request): """ 测试用例生成处理 :param request: :return: """ var = request.config.getoption("--rootdir") test_file = request.config.getoption("--tf") env = request.config.getoption("--te") cases = [] if test_file: cases = [test_file] else: if os.path.isdir(var): for root, dirs, files in os.walk(var): if re.match(r'\w+', root): if files: cases.extend([os.path.join(root, file) for file in files if file.endswith('yml')]) data = main(cases) content = """import allurefrom conftest import CaseMetaClass@allure.feature('{}接口测试 ({}项目)')class Test{}API(object, metaclass=CaseMetaClass): test_cases_data = {}""" test_cases_files = [] if os.path.isdir(var): for root, dirs, files in os.walk(var): if not ('.' in root or '__' in root): if files: case_name = os.path.basename(root) project_name = os.path.basename(os.path.dirname(root)) test_case_file = os.path.join(root, 'test_{}.py'.format(case_name)) with open(test_case_file, 'w', encoding='utf-8') as fw: fw.write(content.format(case_name, project_name, case_name.title(), data.get(root))) test_cases_files.append(test_case_file) if test_file: temp = os.path.dirname(test_file) py_file = os.path.join(temp, 'test_{}.py'.format(os.path.basename(temp))) else: py_file = var pytest.main([ '-v', py_file, '--alluredir', 'report', '--te', env, '--capture', 'no', '--disable-warnings', ]) for file in test_cases_files: os.remove(file) return test_cases_files可以看到，测试文件中有一个TestxxAPI的类，它只有一个test_cases_data属性，并没有testxx方法，所以还不是被pytest认可的测试用例，根本运行不起来。那么它是怎么解决这个问题的呢？就是CaseMetaClass。
function_express = """def {}(self, response, validata): with allure.step(response.pop('case_name')): validator(response,validata)"""class CaseMetaClass(type): """ 根据接口调用的结果自动生成测试用例 """ def __new__(cls, name, bases, attrs): test_cases_data = attrs.pop('test_cases_data') for each in test_cases_data: api = each.pop('api') function_name = 'test' + api test_data = [tuple(x.values()) for x in each.get('responses')] function = gen_function(function_express.format(function_name), namespace={'validator': validator, 'allure': allure}) # 集成 allure story_function = allure.story('{}'.format(api.replace('_', '/')))(function) attrs[function_name] = pytest.mark.parametrize('response,validata', test_data)(story_function) return super().__new__(cls, name, bases, attrs)CaseMetaClass是一个元类，它读取test_cases_data属性的内容，然后动态生成方法对象，每一个接口都是单独一个方法，在相继被allure的细粒度测试报告功能和pytest提供的参数化测试功能装饰后，将该方法对象赋值给test + api的类属性，实际上，TestxxAPI在生成之后便有多个testxx的方法，此时内部再运行从pytest，pytest也可以发现这些用例并执行了。
def gen_function(function_express, namespace={}): """ 动态生成函数对象 , 函数作用域默认设置为 builtins.__dict__，并合并 namespace 的变量 :param function_express: 函数表达式，示例 'def foobar(): return "foobar"' :return: """ builtins.__dict__.update(namespace) module_code = compile(function_express, '', 'exec') function_code = [c for c in module_code.co_consts if isinstance(c, types.CodeType)][0] return types.FunctionType(function_code, builtins.__dict__)在生成方法对象时要注意namespace的问题，最好完全传递builtins .__ dict__，然后自定义的方法通过namespace参数传进去。
后续（yml测试文件自动生成）
至此之后，框架的核心功能已经完成了，经过几个项目的实践，效果完全超过预期，写起用例来不要太爽，运行起来不要太快，测试报告也整的明明白白漂漂亮亮的，但我发现还是有些累，为什么呢？
目前做接口测试的流程是，如果项目集成了swagger，通过swagger去获取接口信息，根据这些接口信息来手工启动项目创建用例。这个过程很重复很繁琐，因为我们的用例模板已经基本上固定了，其实用例之间就是一些参数示例目录，用例名称，方法等等的区别，那么这个过程我觉得完全可以自动化。
因为swagger有个网页，我可以去提取关键信息来自动创建.yml测试文件，就像搭起架子一样，待项目架子生成后，我再去设计用例填传参就可以了。
于是我试着去解析请求swagger首页得到的HTML，然后失望的是并没有实际数据，后来猜想应该是用了ajax，打开浏览器控制台的时，我发现了api-docs的请求，一看果然是json数据，那么问题就简单了，网页分析都不用了。
import reimport osimport sysfrom requests import Sessiontemplate ="""args: - {method} - {api}kwargs: - caseName: {caseName} {data_or_params}: {data}validator: - json: successed: True"""def auto_gen_cases(swagger_url, project_name): """ 根据 swagger 返回的 json 数据自动生成 yml 测试用例模板 :param swagger_url: :param project_name: :return: """ res = Session().request('get', swagger_url).json() data = res.get('paths') workspace = os.getcwd() project_ = os.path.join(workspace, project_name) if not os.path.exists(project_): os.mkdir(project_) for k, v in data.items(): pa_res = re.split(r'[/]+', k) dir, *file = pa_res[1:] if file: file = ''.join([x.title() for x in file]) else: file = dir file += '.yml' dirs = os.path.join(project_, dir) if not os.path.exists(dirs): os.mkdir(dirs) os.chdir(dirs) if len(v) > 1: v = {'post': v.get('post')} for _k, _v in v.items(): method = _k api = k caseName = _v.get('description') data_or_params = 'params' if method == 'get' else 'data' parameters = _v.get('parameters') data_s = '' try: for each in parameters: data_s += each.get('name') data_s += ': \n' data_s += ' ' * 8 except TypeError: data_s += '{}' file_ = os.path.join(dirs, file) with open(file_, 'w', encoding='utf-8') as fw: fw.write(template.format( method=method, api=api, caseName=caseName, data_or_params=data_or_params, data=data_s )) os.chdir(project_)现在要开始一个项目的接口测试覆盖，只要该项目集成了swagger，可以秒生成项目架子，测试人员只需要专心设计接口测试用例即可，我觉得对于测试团队的推广使用是很有价值的，也更方便了了我这样的懒人。以上，欢迎大家一起留言讨论。
TesterHome地址：https：//testerhome.com/topics/16206
（文章附带霍格沃兹测试学院）
