Em um futuro próximo, pretendo dar prioridade à cobertura de testes de interface. Para isso, precisamos desenvolver uma estrutura de teste. Depois de pensar, ainda quero fazer algo diferente desta vez.
- O teste de interface é mais eficiente. Os testadores esperam obter feedback sobre os resultados em breve. No entanto, o número de interfaces é geralmente grande e aumentará. Portanto, é necessário melhorar a eficiência de execução.
- Na verdade, os casos de uso de teste de interface também podem ser usados para teste de estresse simples, e o teste de estresse requer simultaneidade
- Há muitas coisas repetitivas nos casos de uso de teste de interface. Os testadores devem prestar atenção apenas ao design do teste de interface. É melhor automatizar essas
tarefas repetitivas . Pytest e allure são tão fáceis de usar. A nova estrutura deve integrá-los. - Os casos de uso para teste de interface devem ser o mais concisos possível, de preferência usando yaml, para que os dados possam ser mapeados diretamente para solicitar dados. Escrever um caso de uso é o mesmo que preencher os espaços em branco. É fácil promover para membros que não têm experiência em automação e estou muito impressionado com a corrotina Python. Interesse, estudei por um período de tempo e sempre espero aplicar o que aprendi, então decidi usar aiohttp para implementar solicitações http. Mas o pytest não oferece suporte a loops de eventos e é necessário algum esforço se você quiser combiná-los. Continuei pensando, e o resultado desse pensamento é que posso realmente dividir tudo em duas partes. A primeira parte é ler casos de teste yaml, interfaces de teste de solicitação de http e coletar dados de teste. A segunda parte é gerar dinamicamente casos de teste aprovados por pytest com base nos dados de teste e, em seguida, executá-los para gerar relatórios de teste. Desta forma, os dois podem ser perfeitamente combinados e se encaixa perfeitamente na minha visão. A ideia é estabelecida e então realizada.
A primeira parte (todo o processo deve ser assíncrono e não bloqueador)
Leia o caso de teste do yaml
Projetei um modelo de caso de uso simples como este. A vantagem disso é que o nome do parâmetro e aiohttp.ClientSession (). Request (method, url, ** kwargs) são diretamente correspondentes e posso passá-lo diretamente para O método de solicitação evita várias conversões, é conciso, elegante e expressivo.
args:
- post
- /xxx/add
kwargs:
-
caseName: 新增xxx
data:
name: ${gen_uid(10)}
validator:
-
json:
successed: True
Aiofiles, uma biblioteca de terceiros, pode ser usada para ler arquivos de forma assíncrona. Yaml_load é uma corrotina que pode garantir que o processo principal não seja bloqueado durante a leitura de casos de teste yaml. Os dados dos casos de teste podem ser obtidos por meio de await yaml_load ()
async def yaml_load(dir='', file=''):
"""
异步读取yaml文件，并转义其中的特殊值
:param file:
:return:
"""
if dir:
file = os.path.join(dir, file)
async with aiofiles.open(file, 'r', encoding='utf-8', errors='ignore') as f:
data = await f.read()
data = yaml.load(data)
# 匹配函数调用形式的语法
pattern_function = re.compile(r'^\${([A-Za-z_]+\w*\(.*\))}$')
pattern_function2 = re.compile(r'^\${(.*)}$')
# 匹配取默认值的语法
pattern_function3 = re.compile(r'^\$\((.*)\)$')
def my_iter(data):
"""
递归测试用例，根据不同数据类型做相应处理，将模板语法转化为正常值
:param data:
:return:
"""
if isinstance(data, (list, tuple)):
for index, _data in enumerate(data):
data[index] = my_iter(_data) or _data
elif isinstance(data, dict):
for k, v in data.items():
data[k] = my_iter(v) or v
elif isinstance(data, (str, bytes)):
m = pattern_function.match(data)
if not m:
m = pattern_function2.match(data)
if m:
return eval(m.group(1))
if not m:
m = pattern_function3.match(data)
if m:
K, k = m.group(1).split(':')
return bxmat.default_values.get(K).get(k)
return data
my_iter(data)
return BXMDict(data)Como você pode ver, os casos de teste também suportam certa sintaxe de modelo, como $ {function}, $ (a: b), etc., o que pode expandir muito a capacidade do testador de escrever casos de uso
http请求测试接口
Solicitações HTTP podem ser usadas diretamente aiohttp.ClientSession (). Request (method, url, ** kwargs), http também é uma corrotina, o que pode garantir que as solicitações de rede não sejam bloqueadas e os dados de teste de interface possam ser obtidos através de await http ()
async def http(domain, *args, **kwargs):
"""
http请求处理器
:param domain: 服务地址
:param args:
:param kwargs:
:return:
"""
method, api = args
arguments = kwargs.get('data') or kwargs.get('params') or kwargs.get('json') or {}
# kwargs中加入token
kwargs.setdefault('headers', {}).update({'token': bxmat.token})
# 拼接服务地址和api
url = ''.join([domain, api])
async with ClientSession() as session:
async with session.request(method, url, **kwargs) as response:
res = await response_handler(response)
return {
'response': res,
'url': url,
'arguments': arguments
}Colete dados de teste
A simultaneidade da co-rotina é muito rápida. Para evitar que a resposta do serviço cause o fusível, você pode introduzir asyncio.Semaphore (num) para controlar a simultaneidade
async def entrace(test_cases, loop, semaphore=None):
"""
http执行入口
:param test_cases:
:param semaphore:
:return:
"""
res = BXMDict()
# 在CookieJar的update_cookies方法中，如果unsafe=False并且访问的是IP地址，客户端是不会更新cookie信息
# 这就导致session不能正确处理登录态的问题
# 所以这里使用的cookie_jar参数使用手动生成的CookieJar对象，并将其unsafe设置为True
async with ClientSession(loop=loop, cookie_jar=CookieJar(unsafe=True), headers={'token': bxmat.token}) as session:
await advertise_cms_login(session)
if semaphore:
async with semaphore:
for test_case in test_cases:
data = await one(session, case_name=test_case)
res.setdefault(data.pop('case_dir'), BXMList()).append(data)
else:
for test_case in test_cases:
data = await one(session, case_name=test_case)
res.setdefault(data.pop('case_dir'), BXMList()).append(data)
return res
async def one(session, case_dir='', case_name=''):
"""
一份测试用例执行的全过程，包括读取.yml测试用例，执行http请求，返回请求结果
所有操作都是异步非阻塞的
:param session: session会话
:param case_dir: 用例目录
:param case_name: 用例名称
:return:
"""
project_name = case_name.split(os.sep)[1]
domain = bxmat.url.get(project_name)
test_data = await yaml_load(dir=case_dir, file=case_name)
result = BXMDict({
'case_dir': os.path.dirname(case_name),
'api': test_data.args[1].replace('/', '_'),
})
if isinstance(test_data.kwargs, list):
for index, each_data in enumerate(test_data.kwargs):
step_name = each_data.pop('caseName')
r = await http(session, domain, *test_data.args, **each_data)
r.update({'case_name': step_name})
result.setdefault('responses', BXMList()).append({
'response': r,
'validator': test_data.validator[index]
})
else:
step_name = test_data.kwargs.pop('caseName')
r = await http(session, domain, *test_data.args, **test_data.kwargs)
r.update({'case_name': step_name})
result.setdefault('responses', BXMList()).append({
'response': r,
'validator': test_data.validator
})
return resultO loop de eventos é responsável por executar a co-rotina e retornar os resultados. Na coleta de resultados final, usei o diretório de casos de teste para classificar os resultados, o que estabeleceu uma boa base para a geração automática subsequente de casos de teste reconhecidos por pytest
def main(test_cases):
"""
事件循环主函数，负责所有接口请求的执行
:param test_cases:
:return:
"""
loop = asyncio.get_event_loop()
semaphore = asyncio.Semaphore(bxmat.semaphore)
# 需要处理的任务
# tasks = [asyncio.ensure_future(one(case_name=test_case, semaphore=semaphore)) for test_case in test_cases]
task = loop.create_task(entrace(test_cases, loop, semaphore))
# 将协程注册到事件循环，并启动事件循环
try:
# loop.run_until_complete(asyncio.gather(*tasks))
loop.run_until_complete(task)
finally:
loop.close()
return task.result()a segunda parte
Gerar dinamicamente casos de teste aprovados por pytest
Primeiro, explique o mecanismo de operação do pytest. O pytest encontrará primeiro o arquivo conftest.py no diretório atual. Se o encontrar, execute-o primeiro e, em seguida, encontre o arquivo .py no início ou no final do teste no diretório especificado de acordo com os parâmetros da linha de comando. Se encontrado, se encontrado, analise o aparelho, se houver sessão ou tipo de módulo, e o parâmetro autotest = True ou marcado pytest.mark.usefixtures (a ...), execute-os primeiro; em seguida, vá para encontrar a classe e o método por sua vez As regras são semelhantes. Provavelmente esse processo.
Pode-se ver que a chave para executar o teste pytest é que deve haver pelo menos um arquivo testxx.py reconhecido pelo mecanismo de descoberta pytest, o arquivo contém a classe TestxxClass e a classe tem pelo menos um método def testxx (self).
Não há nenhum arquivo de teste reconhecido pelo pytest, então minha ideia é criar um arquivo de teste guiado primeiro, que é responsável por fazer o movimento do pytest. Você pode usar pytest.skip () para pular o método de teste. Em seguida, nosso objetivo é como gerar dinamicamente casos de uso depois que o pytest é ativado e, em seguida, descobrir esses casos de uso, executar esses casos de uso e gerar relatórios de teste de uma só vez.
# test_bootstrap.py
import pytest
class TestStarter(object):
def test_start(self):
pytest.skip('此为测试启动方法, 不执行')O que penso é em acessórios, porque os acessórios têm a capacidade de configuração, então, definindo um acessório cujo escopo é a sessão e, em seguida, marcando o uso no TestStarter, posso pré-processar algumas coisas antes de importar o TestStarter, então gerarei operações de caso de uso Coloque-o neste acessório para completar o objetivo.
# test_bootstrap.py
import pytest
@pytest.mark.usefixtures('te', 'test_cases')
class TestStarter(object):
def test_start(self):
pytest.skip('此为测试启动方法, 不执行')pytest tem um parâmetro --rootdir. O objetivo principal deste fixture é obter o diretório alvo através de --rootdir, descobrir os arquivos de teste .yml nele, e obter os dados de teste após a execução, e então criar um testxx.py para cada diretório O conteúdo do arquivo é o conteúdo da variável content, e então esses parâmetros são passados para o método pytest.main () para executar o teste do caso de teste, ou seja, outro pytest é executado dentro do pytest! Finalmente, exclua o arquivo de teste gerado. Observe que o fixture deve ser definido em conftest.py, porque pytest tem a capacidade de autodescobrir o conteúdo definido em conftest e não requer importação adicional.
# 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 allure
from 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_filesComo você pode ver, há uma classe TestxxAPI no arquivo de teste, que tem apenas um atributo test_cases_data e nenhum método testxx, portanto, não é um caso de teste reconhecido por pytest e não pode ser executado. Então, como isso resolve esse problema? A resposta é 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 é uma metaclasse. Ela lê o conteúdo do atributo test_cases_data e, em seguida, gera objetos de método dinamicamente. Cada interface é um único método. Depois de ser decorada pela função de relatório de teste refinado de allure e a função de teste parametrizada fornecida por pytest, Atribua o objeto de método ao atributo de classe de test + api, ou seja, TestxxAPI possui vários métodos testxx após ser gerado.Neste momento, quando pytest é executado internamente, pytest também pode encontrar esses casos de uso e executá-los.
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__)No método de geração de um objeto a ser observado que o namespace do problema, de preferência o padrão passar os builtins. Dict , em seguida, passar para o método por parâmetros de namespace personalizados.
Acompanhamento (o arquivo de teste yml é gerado automaticamente)
Neste ponto, as funções principais do framework foram concluídas. Depois de vários projetos, o efeito excedeu completamente as expectativas. Não seja muito legal para escrever casos de uso, não execute muito rápido e o relatório de teste é claro e bonito, mas eu Ainda estou um pouco cansado, por quê?
Meu processo atual de teste de interface é, se o projeto integrar swagger, usar swagger para obter informações de interface e criar manualmente casos de uso para o projeto com base nas informações de interface. Este processo é muito repetitivo e complicado, porque nosso modelo de caso de uso foi corrigido de forma grosseira e os exemplos práticos são as diferenças entre alguns parâmetros, como diretório, nome do caso de uso, método, etc., então acho que este processo pode ser totalmente automatizado.
Como o swagger tem uma página da web, posso extrair informações importantes para criar arquivos de teste .yml automaticamente, assim como configurar uma prateleira. Depois que a prateleira do projeto é gerada, posso ir para o caso de design para preencher os parâmetros.
Tentei analisar o HTML da página inicial da solicitação swagger e fiquei desapontado por não haver dados reais. Mais tarde, imaginei que o ajax foi usado. Quando abri o console do navegador, encontrei a solicitação api-docs. São dados json, então o problema é simples e a análise da página da web é desnecessária.
import re
import os
import sys
from requests import Session
template ="""
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_)Agora, quero iniciar a cobertura de teste de interface de um projeto. Contanto que o projeto integre swagger, a prateleira do projeto pode ser gerada em segundos. Os testadores só precisam se concentrar em projetar casos de teste de interface. Acho que é muito significativo para a equipe de teste promover e usar. Também é mais conveniente para pessoas preguiçosas como eu.