Não desde o começo
Você conhece muitas ferramentas de teste que podem:
- Obtenha etapas no idioma Gherkin diretamente a partir do que o usuário solicitou?
- Deseja criar instruções em vídeo automaticamente, com legendas, Jack preto e Elena ?)
- Criar um arquivo * .feature em inglês na interface romena, para um usuário que fala italiano?
Está disponível e claramente (com imagens) neste artigo, não mude ...
Entrada
Este artigo é uma visão geral da ferramenta de teste de aplicativos 1C criada nas entranhas do OpenSource chamada vanessa-automation . Este projeto é uma continuação direta do projeto vanessa-behavior, amplamente conhecido em círculos estreitos (o fork foi criado na versão 1.1.131). A propósito, existem outros garfos .
Contexto
Não seria legal pensar que todo leitor deste artigo no habr conhece 1C, mesmo assim, trapacear não é uma opção. Portanto, não ousarei continuar sem formar o entendimento do leitor sobre a plataforma 1C e seus recursos usados na automação de vanessa (daqui em diante va ou Vanessa ).
Portanto, depois de instalar a plataforma 1C, é necessário executá-la no modo Enterprise ou no modo Configurator .
As configurações estão sendo desenvolvidas no configurador e os usuários da empresa trabalham com essas configurações: eles criam, editam e salvam todos os tipos de diretórios e documentos, preenchendo assim o banco de dados e, em seguida, geram relatórios: cria, edita e salva ... e assim por diante. No entanto, o cenário usual para o desenvolvedor usar a plataforma externamente não é muito diferente do usuário:
eles iniciam a configuração necessária no modo configurador e, em seguida, no ciclo → desenvolvem ou modificam algo → (re) iniciam no configurador 1C no modo corporativo e verificam com suas próprias mãos se eles desenvolveram ou finalizaram.
A situação é salva pela funcionalidade de uma plataforma chamada Teste Automatizado , que possibilita registrar, reproduzir e verificar as ações do usuário. Como essa funcionalidade altera o cenário de uso pelo desenvolvedor da plataforma, consideraremos um exemplo, MAS primeiro sobre o processamento externo .
Objetos de configuração aplicados (também conhecidos como Metadados , "Objetos de configuração" , ela é Ella Katznelbogen, ela é Valentina Paniyad )
descreva a área de assunto e os nomes desses objetos falam por si.
"Documentos" refletem transações comerciais, por exemplo, a entrada de mercadorias. "Diretórios" são necessários para inserir, por exemplo, o nome da contraparte 1 vez e depois selecioná-lo, e não inseri-lo novamente a cada vez. Os dados são armazenados nos "Registros" e as tabelas virtuais são construídas sobre eles para executar cálculos complexos e gerar "Relatórios" . Então, chegamos ao processamento , com a ajuda deles, as informações do banco de dados são processadas (por exemplo, um mês é fechado em contabilidade ou em várias trocas entre os bancos de dados de informações), mas estamos interessados na possibilidade de enviá-las para processamento externo .
As configurações fornecidas pelo 1C são suportadas (é impossível alterá-las para não perder atualizações automáticas), e o processamento externo torna possível executar várias manipulações de dados sem remover o suporte e, é claro - para testar!
ExtensõesApós o lançamento da plataforma versão 8.3.10, tornou-se possível, para fins de teste, usar, além do processamento externo, também extensões (elas são patches).
Com um certo grau de simplificação, pode-se dizer que tecnicamente, o processamento externo 1C é um arquivo com a extensão epf que você pode abrir no configurador, você pode criar muitos formulários → colocar controles nos formulários e programar alguma funcionalidade nos módulos desses formulários. O processamento externo também possui um módulo "comum" (também conhecido como "Módulo de Objeto" ) e layouts, mas essa é uma história completamente diferente e voltamos aos testes.
Para usar a funcionalidade Teste automatizado , é necessário executar duas instâncias da 1C enterprise, a primeira com a chave do gerenciador de teste (/ TESTMANAGER), a segunda com a chave do cliente de teste (/ TESTCLIENT) e estabelecer uma conexão entre o gerenciador de teste e o cliente. Assim, o cenário de uso pelo desenvolvedor da plataforma passa a ser o seguinte:
No configurador, inicie 1C no modo corporativo com a chave do gerenciador de testes → na empresa, abra va e use-o para iniciar outra instância
1C no modo corporativo com uma chave de cliente de teste. A conexão va entre o gerente e o cliente de teste é estabelecida automaticamente após o início do cliente de teste. O cliente de teste pode ser um thin client ou um web client.
Total: 1C escreveu seu Selenium, incorporado à plataforma 1C: Enterprise. E esse selênio da 1C tem vantagens. Por exemplo, qualquer controle (também conhecido como controle) em um formulário sempre tem um nome exclusivo, que em 99,99% dos casos é conhecido antecipadamente. Portanto, não há problemas com localizadores e, para encontrar um controle, basta escrever:
= .(,,);
Fixar o material com um exemplo
É necessário desenvolver uma configuração para contabilizar a venda de mercadorias com a impressão de faturas.
O espectador atento pode notar o design
<>
e você não se enganou, sim - Vanessa usa seu dialeto de pepino, que tem condições e ciclos. Penso que a ideia de adicionar condições e ciclos ao pepino nasceu assim:
Alguns membros da comunidade OpenSource criticaram essa decisão, mas, para acreditar em gitter , eles concordaram com o seguinte - a "legibilidade humana" dos recursos não prejudica essa funcionalidade e todos decidem se devem usá-la ou não.
Sobre o turbo maxixe está planejado um artigo separado, fique atento.
"BDD em 1C" e um pouco de história
va , como vemos agora, foi visto de maneira diferente por seus criadores . Fazer o mesmo pepino + selênio a 1 ° C foi decidido somente depois que eles testaram as opções mais óbvias e de baixo custo. A certa altura, ficou claro que, se você usar pepino e selênio, essas ferramentas precisarão ser finalizadas para obter a funcionalidade necessária para testar as soluções de negócios de aplicativos 1C. Esse alinhamento, dentro da estrutura de código aberto e das realidades do mundo 1C, complicou e estendeu o desenvolvimento do projeto no tempo. Como resultado, decidiu-se fazer apenas com a plataforma 1C: Enterprise.
Por exemplo, com a venda de mercadorias, vimos como o va funciona, agora vamos ver como ele é implementado.
Verificação de etapa
O vídeo “Testing” mostra va , no qual um arquivo de recurso (a seguir denominado recurso ) já foi carregado e uma árvore de etapas foi formada. Ao clicar no botão "Executar scripts" , o processamento de cada etapa é iniciado, ou seja, chame o procedimento de verificação da etapa. Sobre onde este procedimento está localizado, explicarei pelo exemplo.
Suponha que haja um recurso com um script:
: "" 10 "" 300 "" 3000
Para implementar a verificação das etapas deste cenário, é necessário obter o processamento externo correspondente ao recurso. No va, isso é feito automaticamente, pelo botão correspondente.
Como resultado, o diretório step_definitions será criado no mesmo diretório que o recurso, e o processamento externo será criado nele, com o mesmo nome que o recurso.
..\.feature ..\step_definitions\.epf
Os procedimentos de verificação das etapas serão localizados no módulo do formulário de processamento.
Além disso, ao carregar um recurso, o va pesquisará e serializará processos externos para descobrir os procedimentos para verificar quais etapas neles (processos externos) são implementadas. O procedimento a seguir é responsável por isso:
A sequência de pesquisa para verificar as etapas é a seguinte:
1. , feature 2. , , 3. ,
No caso de um script ser adicionado / excluído / alterado, o processamento externo do recurso correspondente pode ser reabastecido pelo mesmo botão "Criar e atualizar modelos de processamento".
Tendo implementado a verificação de etapas uma vez, ela pode ser usada em outros recursos ( reutilização de etapas ). Na verdade, neste módulo de processamento externo, vemos dois procedimentos de verificação de script em três etapas.
Passos do ar e WYCIWYG
Um pouco sobre a funcionalidade Teste automatizado da plataforma 1C. Deixe-me lembrá-lo: o teste automatizado permite gravar, reproduzir e verificar as ações reproduzidas pelo usuário. Na verdade, é tudo o mesmo cliente e gerente de testes , somente no lado do cliente o registro do log de ações do usuário está ativado.
Como resultado, temos um arquivo xml com uma descrição das ações do usuário:
<?xml version="1.0" encoding="UTF-8"?> <uilog xmlns:d1p1="http://v8.1c.ru/8.3/uilog"> <ClientApplicationWindow isMain="true"> <CommandInterface> <CommandInterfaceGroup title=" "> <CommandInterfaceButton title=" "> <click/> </CommandInterfaceButton> </CommandInterfaceGroup> </CommandInterface> </ClientApplicationWindow> <ClientApplicationWindow caption=" "> <Form title=" "> <FormGroup name="" title=" "> <FormButton name="" title=""> <click/> </FormButton> </FormGroup> </Form> </ClientApplicationWindow> <ClientApplicationWindow caption=" ()"> <Form title=" ()"> <FormTable name="" title=""> <FormGroup name="" title=" "> <FormButton name="" title=""> <click/> </FormButton> </FormGroup> <FormField name="" title=""> <closeDropList/> <executeChoiceFromDropList presentation=""/> </FormField> </FormTable> </Form> </ClientApplicationWindow> <ClientApplicationWindow caption=""> <Form title=""> <FormTable name="" title=""> <gotoRow direction="down"> <Field title="" cellText="000000001"/> <Field title="" cellText=""/> </gotoRow> <choose/> </FormTable> </Form> </ClientApplicationWindow> <ClientApplicationWindow caption=" () *"> <Form title=" () *"> <FormTable name="" title=""> <endEditRow cancel="false"/> </FormTable> <FormGroup name="" title=" "> <FormButton name="" title=" "> <click/> </FormButton> </FormGroup> </Form> </ClientApplicationWindow> </uilog>
É difícil dizer se a idéia de criar a funcionalidade de converter o log de ações do usuário em etapas de script está na superfície, mas o primeiro a adivinhar e implementar essa ideia é Leonid Pautov ( pr-mex ). A quantidade de trabalho realizado pode ser estimada pelo conteúdo e tamanho da biblioteca , porque, além de converter o log de ações do usuário no maxixe, era necessário implementar procedimentos de execução e procedimentos para verificar as etapas.
Portanto, para obter um script pronto "do nada", basta ativar a gravação de ações do usuário no gerenciador de testes.
No cliente de teste, reproduza as ações do usuário, por exemplo, funcionalidade que precisa ser aprimorada ou erros que precisam ser corrigidos. Bem, conclua a gravação das ações do usuário. Isso implementa a abordagem de desenvolvimento de teste "WYCIWYG" (o que você clica é o que obtém).
Etapas, por exemplo, verificar o resultado de ações do usuário em um script podem ser adicionadas da biblioteca.
Detalhamento de etapas e cenários de exportação
Infelizmente, na realidade, o script consiste em várias etapas, mais do que na captura de tela a seguir.
Existem pelo menos duas opções para facilitar a percepção de tais cenários.
Primeiro, com a ajuda da tabulação, "mova" as etapas que precisam ser agrupadas e dê a elas um título mnemônico.
Segundo, torne o script conciso e versátil e exporte. Acho que não consigo descrever essa funcionalidade melhor do que Elena no vídeo "Usando a tag da árvore e as etapas do ar" e "Passando parâmetros para o script" .
Os dados de vídeo ( 1 , 2 ) também são criados a partir de scripts no Gherkin e o uso do mecanismo "AutoVideoInstructions" é convertido para o formato mp4 em um clique.
Sim, Vanessa pode criar vídeos sobre como Vanessa funciona)
AutoVideo
Instruções de vídeo automáticas são o tópico de um artigo separado ( aqui está ), só posso contar um pouco de fundo.
O momento da preparação da base de informações, reprodução das ações do usuário e verificação dessas ações, ou seja, execução de script
instruções bastante claras se você desacelerar as etapas.
Salvar usuários para assistir à execução do script (de onde vem esse humor policial?) Não é uma opção, mas o autor não parou de implementar a funcionalidade de criar um arquivo html com etapas e capturas de tela correspondentes. Ele não foi impedido pelo fato de que, ao reproduzir as ações do usuário, o cursor do mouse não é exibido e não há como selecionar uma área arbitrária no formulário; portanto, ele escreveu os utilitários correspondentes. Além disso, a pedido dos usuários, foi adicionada a dublagem ( Elena ), que com o trabalho principal sobre a formação do vídeo com legendas e o fundo musical original, resultou em uma quantidade decente de trabalho, mas as instruções do auto-vídeo estavam lá. No momento, as instruções de vídeo automático são significativamente otimizadas, em termos de sincronização de dublagem e ações no vídeo.
Algumas estatísticas chatas
va suporta:
- Versões da plataforma 1C: Enterprise a partir da 8.3.6 e superior (é recomendável usar a plataforma 8.3.10 e superior).
- Gerenciado e como formulários "normais" (a configuração testada pode estar no modo de compatibilidade 8.2 ou superior).
- Modo de chamada assíncrona.
Para funcionar corretamente em um "zoológico" , va teve que aprender a se testar. O relatório de autoteste é mais ou menos assim:
Os scripts para "auto-teste" estão no mesmo repositório .
Biblioteca de etapas
O pacote va inclui a biblioteca Gherkin de etapas padrão, que permite resolver tarefas diárias de autoteste, como trabalhar com a interface do aplicativo (botões, campos, tabelas, etc.), trabalhar com arquivos, SO, etc. No momento, são mais de 400 etapas.
Localização
A interface va está localizada em 20 idiomas:
RU, am, az, bg, et, fr, ka, de, en, hu, it, lv, lt, mn, pl, ro, sl, es, sv, tr, vi.
A localização va pode ser dividida em 3 componentes:
- Interface (o mecanismo padrão de sinônimos da plataforma 1C: Enterprise é usado).
- Mensagens para o usuário (em vez de chamadas para layouts de () com traduções de mensagens são usadas).
- Tradução das etapas Gherkin da biblioteca padrão va . I.e. em vez de implementar a etapa "E clico no botão 'NameKnopki'" em cada idioma, o "mapeamento" é usado novamente na etapa correspondente do Gherkin, que já está implementada em russo.
Em inglês, esta etapa será
And I click 'ButtonName' button
Portanto, agora os usuários que falam inglês podem escrever scripts em va em inglês. Todas as etapas da biblioteca padrão são traduzidas pelo homem. O resultado pode ser algo parecido com isto .
É lógico que, para oferecer suporte a essa localização, tivemos que implementar ferramentas adicionais para trabalhar com layouts (um layout é algo como uma tabela do Excel) para inserir / excluir valores, classificar linhas etc. diretamente na fonte (arquivos xml).
"TDD em 1C", teste de procedimentos e funções (testes unitários)
Com o va, você pode testar o "comportamento" de procedimentos e funções. Basta escrever um script semelhante:
Se os leitores tiverem interesse, esse tópico poderá ser revelado com mais detalhes em artigos futuros.
Opções de entrega
Inicialmente, o projeto era entregue apenas na forma de um conjunto de arquivos epf, que podiam ser montados a partir da fonte no github ou baixados de uma versão pronta. A partir da versão 1.2.009, o va também é fornecido como um arquivo epf, que inclui todas as bibliotecas, plugins, pacotes de localização, módulos de montagem de vídeo etc. Por assim dizer - tudo em um.
Essa versão da estrutura é chamada vanessa-automation-single . É adequado para usuários que não planejam modificar o va , mas o usarão apenas. Além disso, esta opção de entrega é adequada para inclusão em outras configurações ou extensões (o benefício da licença do projeto FreeBSD permite isso).
De cima para baixo e de baixo para cima
Apesar do fato de a ferramenta ter sido originalmente concebida para implementar a metodologia BDD (ou seja, quando os scripts são escritos de cima para baixo, ou seja, com base nos requisitos de nível superior do cliente), a prática de usar mostrou que os scripts também podem ser escritos de baixo para cima. Um caso típico é quando já existe uma configuração pronta e você só precisa cobri-la com testes sem se preocupar com metodologias.
Moral
Espero que o leitor tenha desenvolvido (a palavra-chave "formado") uma idéia de va como uma ferramenta de teste séria. Olhar para análogos estrangeiros no início, agora os ultrapassa, na minha humilde opinião. A extensão da funcionalidade de trabalhar com maxixe possibilitou (prometido, mas não implementado antes do turbo maxixe) envolver o analista, o desenvolvedor e o testador no processo de desenvolvimento. Vou explicar que o analista escreve um script de nível superior e transversal → o desenvolvedor detalha esse script também usando scripts de exportação e ele praticamente não escreve nada, exceto o código (todas as etapas necessárias da interface do usuário já estão na biblioteca) → o testador adiciona scripts para verificar por um "ângulo diferente" funcionalidade e tudo isso - em um arquivo de recursos , aplaude os camaradas!
PS
Sobre isso, deixe-me concluir este artigo de revisão.
Apoie o projeto com uma palavra gentil / like / criticism (o chat do projeto em Gitter está aqui ), os autores estão sempre satisfeitos.
Obrigado pela atenção!
Referências