Na Alfastrakhovanie, usamos o SAP ERP como um sistema de liquidação de perdas de processos. E aconteceu que estamos finalizando um pouco, isso inevitavelmente leva a erros no código. Se os erros atingem um sistema produtivo, isso é ruim. Isso deve ser evitado, uma maneira é o teste de regressão. Neste artigo, falarei sobre exatamente como conduzimos a "regressão" para SAP, porque fazemos isso (oh!) Não-padrão.
Tudo começou há alguns anos atrás. Naqueles anos, já usamos ativamente o teste de regressão, mas não conseguimos fazê-lo no SAP - as ferramentas usadas não funcionavam com o SAP, a equipe de teste não queria estudar as ferramentas "afiadas" para SAP. Não me lembro exatamente o motivo, mas tomei isso como um desafio (isso foi antes de mudar para a engenharia de data) e decidi "estudar" o problema.
Os resultados do estudo (além de "fazer") - neste artigo (abaixo), direi brevemente: testamos automaticamente o SAP (e seu ambiente imediato), fazemos isso com bastante eficácia (em todos os sentidos), não gastamos um único rublo em licenças e treinamento, nossa abordagem é simples e totalmente reproduzível. E não usamos nenhuma ferramenta SAP para teste automático do SAP (exceto no local em que incorporamos ao seu sistema de transporte).
Traços grandes
Existe o perigo de entrar em detalhes e perder leitores; tentarei não fazer isso (como autor, conheço todos os detalhes).
Tudo começou com o estudo, a comunicação com a SAP, nossos parceiros e o Sr. Google.
O resultado desta comunicação foi o seguinte:
- A SAP possui ferramentas para automação de testes (analisamos o eCATT, de perto o SAP CBTA)
- eles exigem imersão substancial (especialmente SAP CBTA)
- restrições podem ser necessárias, se necessário, ir além dos limites do SAP (ele não está no "vácuo" conosco)
- existem produtos de terceiros (por exemplo, HP), mas não temos competências para eles, assim como compramos licenças
- existe uma maneira de "gerenciar" o SAP de fora (a empresa Convista me contou essa idéia, muito obrigado por isso)
Como eu pessoalmente não tinha conhecimento do SAP, decidi tentar ir na última direção - gerenciar o SAP não é da SAP. O Sr. Google forneceu rapidamente o documento "API SAP Scripting API para as plataformas Windows e Java", que serviu como um excelente começo para esta iniciativa. Um teste rápido no meu python favorito mostrou que funciona.
Em seguida, era uma questão pequena - encontrar uma estrutura adequada para a automação de testes. Como python era minha linguagem favorita, o Robot Framework rapidamente entrou em consideração. E, de fato, depois que ele entrou na lista e foi julgado, somente ele permaneceu na lista. Subornado pelo fato de que "ele" funcionou imediatamente (olhando para o futuro - e ainda funciona, não me arrependo de um minuto sequer sobre a minha escolha).
Um pequeno piloto mostrou que a SAP é perfeitamente "controlada" por um robô (chamarei de Robot Framework essa palavra russa): rápida, síncrona, previsível e confiável. Ao mesmo tempo, enfatizo, usamos a maneira documentada pela SAP de interagir com a GUI do SAP (não algum tipo de “muleta”).
Arquitetura
(sim, deixe-me usar esta palavra aqui)
Como funciona:
- o script é executado no servidor (a palavra "servidor" é usada aqui no sentido em que este computador atende às nossas solicitações de teste. Nesse caso específico, é mais correto usar a palavra "cliente" porque é o script que controla o processo de teste)
- através do mecanismo padrão do robô remoto, o script interage com o componente servidor do robô em execução no SUT (sistema em teste)
- esse componente do servidor chama os métodos da biblioteca de gerenciamento SAP
- A GUI do SAP processa essas solicitações (de forma síncrona, isso é importante)
- os resultados da execução de consultas ou simplesmente "batidas" são retornados ao script no "servidor", onde são usados no processo de teste
Tecnicamente
- "server" é uma máquina virtual no Ubuntu
- SUT - a estação de trabalho em que a estação de trabalho SAP está instalada e configurada (no nosso caso, é um computador Windows ou máquina virtual)
- a biblioteca de gerenciamento SAP é escrita em python (existem algumas - algumas centenas de linhas)
- "script" é um "programa" em um idioma entendido pelo Robot Framework
- o robô (como tal) implica uma linha de comando, como os desenvolvedores do ABAP não estão acostumados a isso, criei uma interface WEB que fornece, em particular, trabalho coletivo (um pouco mais tarde).
O que é maravilhoso
Na verdade, o que recebemos, exceto pela falta de carga de licenciamento?
Muitas coisas, se brevemente e sobre a principal:
Idioma russo
O script é mais ou menos assim:
No começo da jornada (provavelmente durante o piloto), pensei - e que quebraremos a língua e criaremos algumas palavras incompreensíveis até para nós? O robô implica a criação de suas próprias palavras-chave (desculpe pela terminologia - é assim que ele chama). Então, por que não os encontramos imediatamente em russo? Ele perguntou na comunidade de testadores (em algum lugar nas entranhas da Internet) - eles "me chatearam": é perigoso, por que, quem disse isso etc. Eu segui meu próprio caminho - temos tudo em russo (variáveis, palavras, apenas as estruturas de controle do robô permanecem, mas elas devem estar ocultas nas palavras-chave - se você vê o inglês, é hora de refatorar).
O que há de bom no idioma russo (exceto a capacidade de compreensão sem um dicionário) - o script pode ser mostrado a um especialista não de TI, uma pessoa de negócios. Você pode escrever esse script diretamente com ele (eu nem tentarei entrar no tópico do ATDD aqui - este é um post grande e separado, escreverei algum dia).
Controle e extensibilidade total e total
Eu sei exatamente o que acontece durante o processo de teste. Não há mágica - tudo é extremamente claro. Eu não sei como alguém, eu gosto disso.
Sobre extensibilidade - a funcionalidade pode ser desenvolvida em qualquer direção, que usamos ativamente:
- Consegui criar minha própria "linguagem" de scripts de teste, compreensível para os negócios
- foi possível verificar automaticamente se os campos na interface foram preenchidos corretamente no final do teste (para isso, em particular, dividimos as variáveis do robô em parâmetros de inicialização e parâmetros de interface, possibilitou determinar qual elemento da interface deveria ter qual parâmetro de inicialização)
- pontos de interrupção podem ser adicionados aos testes; durante os pontos de interrupção, observe os valores das variáveis
- Implementamos um mecanismo para criar modelos de arquivos e colocá-los no processo de execução - sem isso, seria impossível testar um animal como um VLP (e o testamos em um modo completamente automático - da geração de um aplicativo à análise de uma extração)
A presença de nossa própria interface da Web adicionou mais oportunidades de expansão - por exemplo, podemos modificar a linguagem do robô (criamos, por exemplo, nosso operador condicional - nós e nossos usuários corporativos não gostamos do padrão "Executar palavra-chave se"). Isso se tornou possível porque os arquivos com código-fonte de teste são gerados para o robô por um aplicativo da web.
Facilidade de entrada
Como regra, os testadores não têm conhecimento da infraestrutura SAP e, principalmente, da programação SAP. Eles conseguem dominar o robô e nossas melhorias em algumas semanas.
Instruções para o Usuário
Também nos voltamos para "Our William ..." - para a documentação. Não é segredo para ninguém - como regra, não existe documentação para o sistema e, mesmo que exista, ele rapidamente se torna desatualizado. Os usuários aprovam as regras de trabalho com o sistema "boca a boca". Se o código de teste automático é uma descrição de como usar o sistema de acordo com o autor, por que não convertê-lo em uma instrução?
Obviamente, é difícil ver os detalhes desse fragmento, é importante que a instrução seja gerada e atualizada em um modo totalmente automático, incluindo capturas de tela. A instrução está sempre atualizada (porque os autotestes sempre funcionam). No caso do SAP, as capturas de tela geralmente são bem recebidas - no SAP, você sempre pode encontrar um elemento de interface - um retângulo cujas coordenadas serão relevantes para o local atual no código de teste, este controle (invisível aos olhos) é usado como parâmetro para a palavra-chave "tirar uma captura de tela" (esta palavra é claro, funciona apenas com o modo de inicialização de teste apropriado - por que gastar apenas eletricidade assim)?
Formatamos as instruções usando o Sphinx (tenho certeza que muitos aprenderam o esquema de cores), portanto, elas estão disponíveis no manual on-line e na impressão.
Um pouco sobre o Robot Framework
No entanto, nada pode ser dito sobre o robô - ele ficará muito incompreensível e superficial. Vou tentar brevemente.
A idéia principal dessa estrutura é a capacidade de criar sua própria linguagem de teste (na terminologia do robô, a unidade executável é a palavra-chave - a palavra-chave). A estrutura fornece
- ambiente de execução de programa (programadores - não se ofenda) nesse idioma
- bibliotecas funcionalmente ricas (do trabalho com strings e listas ao ssh e selenium)
- relatórios (no processo de uso, não havia nem o pensamento de escrever qualquer tipo de relatório)
- um paradigma simples de formar um programa a partir de palavras-chave (um pouco peculiar, mas você pode se acostumar), existem variáveis como parâmetros, parâmetros e resultados de "chamadas" (palavras-chave)
- extensibilidade simples e poderosa - é muito simples criar sua própria biblioteca em python (por exemplo, trabalhamos dessa maneira com o Excel), local (ou seja, executado no mesmo local que o código de teste) e remoto (por exemplo, que controla a GUI do SAP)
O processo de criação de um teste é bastante direto
- formamos uma sequência de ações e a traduzimos em termos de robô (um pouco mais baixos serão específicos sobre a interação com o sistema em teste)
- seqüências repetidas refatoram em suas (novas) palavras-chave
- executar o teste, ver como funciona, corrigir, melhorar
- a depuração é fornecida por pontos de interrupção (com a capacidade de visualizar variáveis - é fornecida pela arquitetura, mais precisamente - o uso da biblioteca remota do robô)
O resultado nem é um programa (veja os exemplos acima), mas uma sequência formal de ações, que, aliás, descrevem o uso do programa na forma que o autor pretendia (veja o ATDD acima).
Interação com o sistema em teste
No nosso caso, testamos no nível da interface do usuário (ou seja, nossos testes interagem com o SAP no nível da GUI - eles "clicam" nos botões, preenchem os campos de texto etc.). É geralmente aceito que essa maneira de escrever testes não é a melhor. Concordo parcialmente com isso, mas estou pronto para ouvir e discutir como testar aplicativos SAP GUI (como nosso SAP FS CM).
Existe um guru desse tipo - Robert Martin (também conhecido como "tio Bob" - o autor de "Clean coder", se alguém ler), correspondemos um pouco sobre isso. Eles concordaram que, se não é muito difícil de fazer, não muda com muita frequência (testes de ruptura), tudo bem - você também pode testar através da interface.
Da minha parte, posso dizer o seguinte: no caso da SAP GUI, não há muitas opções para implementar a interface do usuário. Se você precisar adicionar a capacidade, por exemplo, de rastrear o código IMEI, poderá fazer isso de quase uma maneira - adicionando o campo apropriado a um dos favoritos. Então, acho que todas as nuances dessa "adição" podem e devem ser pensadas pelo cliente (como esse campo será chamado na interface, largura, ordem de uso etc.). E ele pode fazer isso diretamente em um script, que o testará automaticamente. Se você não consegue pensar em uma revisão até o fim (como eles dizem - bem, faça-o e veremos), é melhor não fazer essa revisão. E para fazer o que você pode pensar. Bem, entrei no ATDD de novo ...
Voltando à interação com a SAP GUI: obtivemos, como já escrevi, cerca de 200 linhas em python e cerca de 10 funções diferentes de gerenciamento de interface (como "ir para o favorito", "preencher o campo", "pressionar o botão"). Esse conjunto foi formado quase nos primeiros dias e, posteriormente, não se expandiu muito. Para o crédito da SAP, observo que tudo funciona muito rapidamente - os olhos não têm tempo para acompanhar como a interface pisca, foram inseridos atrasos no ciclo de controle para diminuir a velocidade (nos casos em que o monitoramento visual é necessário). Também observo as vantagens da operação síncrona - em nenhum lugar do código você precisa esperar por algo, se, por exemplo, o botão for pressionado, a ação correspondente ao clique no botão foi concluída (por exemplo, a perda foi salva).
def get_ctrl_attr ( self, uid, attr ): """ ( ) ( ) exception = ( log) """ ctrl = self._get_ctrl(uid) try: retText = getattr( ctrl, attr ) except: raise AssertionError(" {1} {0}".decode("utf-8").format(attr,uid)) return retText
Alguns comentários sobre o código
- fragmento da biblioteca de gerenciamento SAP GUI
- uma biblioteca é um objeto, os métodos estão diretamente disponíveis nos testes (em palavras-chave); por exemplo, o método acima pode ser chamado assim: "res = get ctrl attr $ {UID} text" (usando notação de robô)
- em caso de erro, o texto da exceção será visível no log do robô (você não precisa fazer nada para isso - basta "matar" a exceção
O código é muito simples, agrada.
Executando testes
Seguindo a lógica do robô, testes individuais são combinados em nossos projetos. Um teste ou projeto pode ser iniciado manualmente a partir da interface da web. O processo de teste de regressão também é integrado ao sistema de transporte SAP:
- o proprietário do produto, no final da fase de teste comercial, aprova solicitações de transporte para transferência
- solicitações aprovadas "mudam" uma de cada vez para o ambiente de pré-produção, onde, de acordo com as configurações, um ou outro conjunto de testes é iniciado (mais precisamente, projetos)
- se o resultado do teste for positivo, a solicitação é liberada e "vai" para o ambiente de produção
- Quando ocorrem erros, o autor da solicitação recebe uma carta com um link para o relatório de teste (gerado pelo robô), a solicitação não vai além
Importante - a interface da web reduz significativamente o limite de entrada no processo de teste: para iniciar o teste é simples - clique no botão "Iniciar". Ao mesmo tempo (devido ao uso do Robot Framework), todas as vantagens da representação de arquivo dos testes (controle de versão, linha de comando e automação relacionada, etc.) são preservadas.
Não sap om
Aplicamos com sucesso nosso desenvolvimento para testar não apenas a SAP GUI, mas também desenvolvi um pequeno (interface de registro de perdas simplificado) em python e django. Como já havíamos implementado todos os pontos básicos, tudo o que era necessário era escrever uma biblioteca de gerenciamento de navegador (o mesmo que eu tinha para gerenciar a SAP GUI, apenas através do Selenium). E ficou ótimo:
- os testes ainda funcionam na máquina virtual Linux (na mesma - testes SAP e não testes SAP vivem na mesma "instância")
- o navegador "pisca" no local de trabalho do testador (controle visual completo sem truques)
- relatórios padrão, ferramentas familiares
Nos testes deste sistema, fui mais longe (em direção ao ATDD) - elementos visualmente visíveis (rótulos e espaços reservados) foram formados inicialmente nos testes, lá eles concordaram com o negócio e a partir daí "caíram" no código fonte do próprio sistema (ficou um pouco SECO) - você não pode escreva código sem escrever o teste primeiro. Cool
Obviamente, muitas ferramentas foram desenvolvidas para aplicativos da Web, mas não posso dizer que experimentei algum inconveniente durante o trabalho. Acabou bem aqui ...
Resumir
O mundo da SAP é grande e contém, ao que parece, tudo o necessário para a completa felicidade dos desenvolvedores. Mas isso não significa que você precisa apenas percorrer os caminhos que o SAP e seu ecossistema "seguiram". É útil no início do caminho fazer a si mesmo a pergunta: eu definitivamente quero fazer "como todo mundo"? Nós da Alfastrakhovanie perguntamos a ele mesmos, e não apenas em TI.
E, mais uma vez, tudo é possível na programação, a questão é apenas tempo e dinheiro (motivação).