Prefácio
O ecossistema de pagamento Mir Plat.Form inclui várias dezenas de sistemas, muitos dos quais interagem entre si usando vários protocolos e formatos. Nós, equipe de Teste de Integração, verificamos se essas interações atendem aos requisitos estabelecidos.
No momento, a equipe está trabalhando com 13 sistemas essenciais para a missão e os negócios. Os sistemas de missão crítica garantem que o Mir Plat.Form desempenhe suas funções principais, garantindo a estabilidade e a continuidade do sistema de cartão bancário russo. Os sistemas críticos para os negócios são responsáveis pelo suporte aos serviços adicionais prestados aos clientes Mir Plat.form, dos quais dependem as atividades operacionais diretas da empresa. A frequência de lançamento de releases para o PROD varia de uma vez por semana a uma vez por trimestre, tudo depende do sistema e da prontidão dos participantes para a frequência de atualizações. No total, contamos cerca de 200 lançamentos que passaram por nossa equipe no ano passado.
A matemática simples diz o seguinte: o número de cadeias testadas é N-systems * M-integrações entre eles * K-releases. Mesmo usando o exemplo de 13 sistemas * 11 integrações * 27 versões de lançamento, existem aproximadamente 3.861 opções de compatibilidade de sistema possíveis. A resposta parece óbvia - autotestes? Mas o problema é um pouco mais sério, só os autotestes não vão te salvar. Dado o número crescente de sistemas e suas integrações, e a frequência variável de lançamentos, sempre existe o risco de testar a cadeia de versão do sistema errada. Portanto, existe o risco de perder um defeito na interação intersistêmica, por exemplo, afetando o correto funcionamento do sistema de pagamentos Mir (PS).
Naturalmente, no PRODA a presença de tais bugs é inaceitável, e a tarefa de nossa equipe é reduzir esse risco a zero. Se você se lembra do texto acima, qualquer “espirro” afeta não apenas os sistemas internos da Mir Plat.form, mas também os participantes do mercado: bancos, comerciantes, pessoas físicas e até outros sistemas de pagamento. Portanto, para eliminar os riscos, percorremos o seguinte caminho:
- Introduziu uma base de lançamento unificada. Para esta tarefa, bastou o calendário de lançamentos no Confluence, indicando as versões dos sistemas instalados no PROD;
- Rastreamos cadeias de integração de acordo com as datas de lançamento. Aqui também não começamos a reinventar a roda, vamos precisar dela ainda mais. Para resolver este problema, usamos estruturas Epic no JIRA para testes de integração de lançamentos. Um exemplo de estrutura para a versão 1.111.0 do System3:
Por um lado, todas essas ações ajudaram a melhorar o entendimento da equipe sobre as integrações testadas, as versões dos sistemas e a sequência de sua liberação para o PROD. Por outro lado, ainda existe a probabilidade de testes incorretos devido ao fator humano:
- Se a data de lançamento de qualquer sistema foi movida, um membro da equipe precisa corrigir manualmente o calendário e toda a estrutura do JIRA, incluindo os prazos para conclusão das tarefas e, possivelmente, as versões dos sistemas testados;
- Antes de testar a integração, você precisa se certificar de que o ambiente de teste consiste nas versões corretas dos sistemas. Para fazer isso, você precisa revisar manualmente os bancos de teste e executar alguns comandos do console.
Além disso, o trabalho rotineiro adicional apareceu, às vezes ocupando uma parte significativa do tempo.
Tornou-se óbvio que esse processo de preparação para o teste de integração de versões precisa ser de alguma forma automatizado e, se possível, combinado em uma interface. É aqui que entra a nossa bicicleta salva-vidas: Sistema de monitoramento de teste de integração ou simplesmente SMIT.
Que opções você gostaria de implementar no sistema em desenvolvimento?
1. Um calendário de lançamento claro com a capacidade de exibir versões de todos os sistemas para uma data específica;
2. Ambiente de monitoramento para teste de integração:
- lista de ambientes;
- exibição visual de bancos de teste e sistemas que fazem parte de um ambiente separado;
- controle de versão de sistemas implantados em bancos de teste.
3. Trabalho automatizado com tarefas no Jira:
- criando uma estrutura de lançamento épica;
- gerenciamento do ciclo de vida de tarefas de teste;
- atualização de tarefas em caso de mudança na data de lançamento;
- colocar relatórios de fascinação em tarefas de teste.
4. Trabalho automatizado com ramos no Bitbucket, nomeadamente a criação de ramos de lançamento em projetos:
- autotestes de integração;
- auto-aquecimento do ambiente de integração.
5. UI intuitiva para executar autotestes e atualizar versões do sistema.
O que é SMITH
Como o sistema não é complicado, não nos tornamos muito espertos com a tecnologia. O back-end foi escrito em Java usando Spring Boot. O frontend é React. Não havia requisitos especiais para o banco de dados, então escolhemos o MySql. Como é comum trabalharmos com contêineres, todos os componentes acima foram embalados no Docker, construindo com o Docker Compose. O SMITH funciona de forma rápida e confiável como outros sistemas Mir Plat.Form.
Integração
- Atlassian Jira. No jir, tarefas para testar cada integração específica são criadas, abertas, colocadas em funcionamento e fechadas; se todos os testes forem bem-sucedidos, um link para o relatório de fascinação é anexado nos comentários.
- Atlassian BitBucket. , , / . “” , .
- Jenkins. Jenkins, . , , glue Cucumber.
- . . ssh.
Antes de poder manter um calendário e monitorar o estado dos ambientes no SMIT, é necessário criar uma lista de sistemas em teste e os relacionamentos entre eles. Todas as configurações podem ser feitas por meio da interface da web:
Após adicionar o sistema em teste à lista SMIT:
- Irá "bater" em todos os hosts de sistemas denominados SYS_CMD na lista de ambientes;
- descobre a versão deste sistema usando o comando especificado na configuração;
- gravará em seu banco de dados a versão atual deste sistema e o ambiente no qual ele aparece.
Como resultado, o SMIT conterá informações sobre todos os sistemas implementados nos ambientes usados, incluindo seus números de versão. Com base nessas informações, você pode visualizar o calendário de lançamentos.
Calendário de lançamento
Após os proprietários dos sistemas ou chefes de equipe das equipes de desenvolvimento de produto nos informarem a data de instalação de um novo lançamento no PROD, registramos esse lançamento no calendário. Acontece que esta é a imagem:
Você pode facilmente notar conflitos, onde vários lançamentos são instalados ao mesmo tempo em alguns dias e um "aquecimento" é possível. Os proprietários do produto são notificados desses conflitos, porque é realmente perigoso instalar várias versões novas de sistemas no mesmo dia.
Também na página com o calendário há uma função para exibir versões de todos os sistemas para uma data específica:
Vale a pena observar que ao registrar um novo release no calendário, o SMIT cria automaticamente uma estrutura Epic em Jira e libera ramificações em projetos no Bitbucket.
Estado do ambiente
Outra função muito conveniente do SMITH é visualizar o estado atual de um ambiente específico. Nesta página você encontra uma lista dos sistemas incluídos no ambiente e a relevância de suas versões.
Como você pode ver na captura de tela, a SMITH encontrou uma versão desatualizada do System 4 em host-4.nspk.ru e se oferece para atualizá-la. Se você pressionar o botão vermelho com uma seta branca, SMITH chamará Jenkins job para implantar a versão atual do sistema no ambiente atual. Também é possível atualizar todos os sistemas após pressionar o botão correspondente.
Ambientes de teste de integração
Vale a pena contar um pouco sobre como definimos ambientes de teste. Um ambiente é um conjunto de estandes com sistemas Mir Plat.form implantados e integração personalizada (um sistema em um estande). No total, são 70 estandes, divididos em 12 ambientes.
No projeto de autotestes de integração, temos um arquivo de configuração no qual os testadores definem os ambientes de teste. A estrutura do arquivo é semelhante a esta:
{
"properties":{
"comment":" system property Environment. property, , System.getProperties()",
"common.property":"some global property"
},
"environments":[
{
"comment":" name, Environment common + . common1",
"name":"env_1",
"properties":{
"comment":" system property Environment. property. , System.getProperties()",
"env1.property":"some personal property"
},
"DB":{
"comment":" TestResource' DbTestResource. id, ",
"url":"jdbc:mysql://11.111.111.111:3306/erouter?useUnicode=yes&characterEncoding=UTF-8&useSSL=false",
"driver":"com.mysql.jdbc.Driver",
"user":"fo",
"password":"somepass"
},
"SYS_CMD":{
"comment":" TestResource' RemoteExecCmd. type = remote",
"type":"remote",
"host":"10.111.111.111",
"username":"user",
"password":"somepass"
}
}
]
}Além do fato de que esse arquivo é necessário para que o projeto de autoteste de integração funcione, ele também é um arquivo de configuração adicional para SMIT. Quando você solicita a atualização de informações sobre ambientes no SMIT, uma solicitação HTTP é enviada para a API de nosso bitbucket, onde armazenamos o projeto com autotestes de integração. Desta forma, o SMITH obtém o conteúdo real do arquivo de configuração do branch master.
Executando testes
Um dos objetivos da criação do SMIT era simplificar o procedimento para lançar autotestes de integração tanto quanto possível. Vamos considerar o que terminamos usando um exemplo:
Na página de teste do sistema (neste exemplo, Sistema 3), você pode selecionar uma lista de sistemas com os quais deseja verificar a integração. Depois de selecionar as integrações requeridas e clicar no botão “Iniciar teste”, SMITH:
1. Forma uma fila e inicia sequencialmente os trabalhos Jenkins correspondentes;
2. monitora a execução do trabalho;
3. altera o status dos problemas correspondentes em Jira:
- Se o trabalho foi concluído com sucesso, a tarefa no Jira será fechada automaticamente, um link para o relatório de fascinação e um comentário serão anexados a ele informando que nenhum defeito foi encontrado nesta integração.
- Se o job estiver falhando, a tarefa no Jira permanecerá aberta e aguardará uma decisão do funcionário responsável pela integração, que poderá determinar o motivo das falhas no teste. O responsável pela integração pode ser visto no cartão de integração.
Resultado
A SMITH foi criada para minimizar os riscos dos testes de integração, mas como equipe queríamos mais! Em particular, um dos desejos era que com um clique do botão, os autotestes fossem iniciados com o ambiente de teste correto, tudo fosse verificado nas partidas de integração necessárias e as tarefas no Jira fossem abertas e fechadas junto com os relatórios. Essa utopia dos testadores automáticos: diga ao sistema o que verificar - e vá tomar um café :)
Vamos resumir o que conseguimos implementar:
- Calendário de lançamento visual com a capacidade de exibir versões de todos os sistemas em uma data específica;
- UI , , ;
- ;
- UI ;
- Epic Task Jira, Allure ;
- Bitbucket.
No momento, o sistema está passando por um teste beta fechado entre os membros diretos da equipe de teste de integração. Quando todos os defeitos encontrados forem eliminados e o sistema executar de forma estável suas funções, abriremos o acesso a funcionários de equipes relacionadas e proprietários de produtos para que possam executar nossos testes de forma independente e estudar o resultado.
Assim, em um cenário ideal, tudo o que precisa ser feito para verificar se o sistema atende aos requisitos de integração é ir para a interface da web do SMIT, atualizar o sistema necessário por meio dela, selecionar todas as caixas de seleção e executar os testes e, em seguida, verificar se todos foram concluídos com sucesso. As tarefas serão criadas automaticamente, relatórios de fascinação serão preenchidos, os status correspondentes serão atribuídos a essas tarefas.