Com este artigo, continuamos uma série de publicações sobre como automatizamos o processo de teste manual (doravante denominado autoteste) de um grande sistema de informação (doravante referido como Sistemas) em um dos principais projetos LANIT e o que aconteceu.

Como organizar com eficiência uma hierarquia de classes? Como distribuir pacotes na árvore do projeto? Como se certificar de esquecer conflitos de mesclagem com uma equipe de 10 pessoas? Esses problemas estão sempre no início de um novo desenvolvimento e nunca têm tempo suficiente.

Fonte

Neste artigo, descrevemos a estrutura das classes e a organização do código, o que nos permitiu desenvolver com pouco esforço mais de um milhão e meio de testes de interface do usuário de ponta a ponta com base em Junit e Selenium para um grande sistema de significado federal. Além disso, oferecemos suporte e aperfeiçoamos constantemente os cenários existentes.

Aqui você pode encontrar uma descrição prática da estrutura hierárquica das classes base dos autotestes, o detalhamento do projeto de acordo com o modelo funcional java-packages e modelos de amostra de classes reais.

O artigo será útil para todos os desenvolvedores que desenvolvem autotestes baseados no Selenium.

Este artigo é parte de uma publicação geral na qual descrevemos como uma pequena equipe construiu o processo de automação de teste de interface do usuário e desenvolveu uma estrutura baseada em Junit e Selenium para isso.

Peças anteriores:

• Parte 1. Organizacional e gerencial. Por que precisamos de automação. Organização do processo de desenvolvimento e gerenciamento. Organização de uso
• Parte 2. Técnica. Arquitetura e pilha técnica. Detalhes de implementação e surpresas técnicas

Implementação de classe base para todos os testes e JUnit RuleChain

O conceito de desenvolvimento de autotestes, conforme mostrado em um artigo anterior ( Parte 2. Técnico. Arquitetura e pilha técnica. Detalhes da implementação e surpresas técnicas ), baseia-se na idéia de uma estrutura na qual um conjunto de funções do sistema é fornecido para todos os autotestes - eles são perfeitamente integrados e permitem que os desenvolvedores os autotestes se concentram em questões específicas da implementação comercial das classes de teste.

A estrutura inclui os seguintes blocos funcionais:

• Regras - inicialização e finalização dos componentes da infraestrutura de teste como inicialização do WebDriver e recebimento de um teste de vídeo. Descrito com mais detalhes abaixo;
• WebDriverHandlers - funções auxiliares para trabalhar com um driver da Web, como executar Java Script ou acessar logs do navegador. Implementado como um conjunto de métodos estáticos sem estado;
• WebElements é uma biblioteca de elementos típicos da Web ou de seus grupos, que contém a funcionalidade de função cruzada necessária e o comportamento típico. No nosso caso, essa funcionalidade inclui uma possível verificação da conclusão de operações assíncronas no lado do navegador da web. Implementado como extensões de elementos da Web das bibliotecas Selenium e Selenide.

Inicialização do ambiente de teste. Regras

A classe-chave para todas as classes de teste é BaseTest, da qual todas as classes de teste são herdadas. A classe BaseTest define o "corredor" de testes do Junit e o RuleChain usado, como mostrado abaixo. O acesso das classes de teste aplicadas às funções fornecidas pelas classes de regra é fornecido através dos métodos estáticos das classes de regra.

O código de exemplo BaseTest é apresentado na próxima caixa.

@RunWith(FilterTestRunner.class) public class BaseTest { private TemporaryFolder downloadDirRule                                                                  = new TemporaryFolder(getSomething().getWorkingDir());      @Rule     public RuleChain rules = RuleChain             .outerRule(new Timeout(TimeoutEnum.GLOBAL_TEST_TIMEOUT.value(),                                                                       TimeUnit.SECONDS))             .around(new TestLogger())             .around(new StandStateChecker())             .around(new WaitForAngularCreator())             .around(downloadDirRule)             .around(new DownloaderCreator(downloadDirRule))             .around(new EnvironmentSaver())             .around(new SessionVideoHandler())             .around(new DriverCreator(downloadDirRule))             .around(new BrowserLogCatcher(downloadDirRule))             .around(new ScreenShooter())             .around(new AttachmentFileSaver())             .around(new FailClassifier())             .around(new PendingRequestsCatcher());     //            final protected SomeObject getSomething() {         return Something.getData();    }    … } 

FilterTestRunner.class - uma extensão do BlockJUnit4ClassRunner, fornece filtragem da composição de testes executáveis ​​com base em expressões regulares pelo valor da anotação especial do Filtro (valor = "some_string_and_tag"). A implementação é dada abaixo.

org.junit.rules.Timeout - usado para limitar a continuação máxima de testes. Ele deve ser instalado primeiro, pois inicia o teste em uma nova ramificação.

TestLogger é uma classe que permite que o teste registre eventos no formato json para uso na análise ELK. Enriquece eventos com dados de teste de org.junit.runner.Description. Além disso, também gera automaticamente eventos para o ELK no formato json para iniciar o teste com sua duração e resultado

StandStateChecker é uma classe que verifica a disponibilidade da interface da web do stand de destino ANTES de inicializar o driver da web. Fornece uma verificação rápida de que o suporte está disponível em princípio.

WaitForAngularCreator - uma classe que inicializa o manipulador de driver da web para controlar a conclusão de operações angulares assíncronas. É usado para personalizar testes "especiais" com chamadas síncronas longas.

org.junit.rules.TemporaryFolder - usado para definir uma pasta temporária exclusiva para armazenar arquivos para operações de upload e download de arquivos por meio de um navegador da web.

DownloaderCreator é uma classe que fornece suporte para operações de upload em um diretório temporário de arquivos baixados pelo navegador e gravados através da função de vídeo Selenoid.

EnvironmentSaver - uma classe que adiciona informações gerais sobre o ambiente de teste ao relatório Allure.  

SessionVideoHandler - uma classe que carrega um arquivo de teste de vídeo, se houver, e aplica Allure ao relatório.

DriverCreator é uma classe que inicializa o WebDriver (a classe mais importante para testes), dependendo dos parâmetros definidos - local, solenóide ou ggr-selenóide. Além disso, a classe executa o conjunto de scripts Java necessário para nossos testes. Todas as regras que acessam o driver da web devem ser inicializadas após esta classe.

BrowserLogCatcher - uma classe que lê mensagens graves do log do navegador, as registra no ELK (TestLogger) e as aplica ao relatório Allure.

ScreenShooter - uma classe que, para testes sem êxito, tira uma captura de tela da tela do navegador e a aplica ao relatório como WebDriverRunner.getWebDriver (). GetScreenshotAs (OutputType.BYTES)

AttachmentFileSaver - uma classe que permite anexar ao relatório Allure um conjunto de arquivos arbitrários exigidos pela lógica comercial dos testes. Usado para anexar arquivos carregados ou baixados ao sistema.

FailClassifier é uma classe especial que, no caso de uma falha de teste, tenta determinar se esta falha foi causada por problemas de infraestrutura. Verifica a presença na tela (após uma queda) de janelas modais especiais do tipo “Ocorreu um erro do sistema nºXXXXXXXXXX”, bem como mensagens do sistema do tipo 404 e similares. Permite dividir os testes reprovados em falhas nos negócios (conforme o cenário) ou problemas no sistema. Funciona através da extensão org.junit.rules.TestWatcher. # Método com falha.

PendingRequestsCatcher é outra classe especial que tenta classificar ainda mais se a falha foi causada por serviços de descanso incompletos, interrompidos ou muito longos entre o front-end angular e a web. Além dos testes funcionais, é possível identificar serviços de descanso problemáticos e congelantes sob cargas pesadas, bem como a estabilidade geral da versão. Para fazer isso, a classe registra no ELK todos os eventos com solicitações de descanso congeladas que recebe, iniciando js especiais no navegador por meio de um driver da web aberto.

Modelo de Implementação de Classe de Teste

 package autotest.test.<sub-system>; @Feature("     TMS") @Story("    TMS") @Owner("       ") @TmsLink("    .   ") public class <   >_Test extends BaseTest { /** *           **/    Login orgTest; /**         **/    Login loginStep1;    ...    Login loginStepN;    /** *   -      -   * ...         **/      /** *    *              *    Utils.allure.message("     -", business_object) *     null,             . *             preconditions  actions    *  Utils.allure.message("      ", documentNumber) **/ @Step("  ") private void init(Login login) {    some_business_object = //         login        Utils.allure.message("     -", some_business_object)                           // ...             /**     */        loginStep1 = LoginFactory.get(_Some_Login_);    ...    loginStepN = LoginFactory.get(_Some_Login_); }    /** *       **/    @Test    @Filter("       JUnit")    @DisplayName("    TMS")    public void <   >_<>_<__>_Test() {  //            orgTest = LoginFactory.get(_Some_Login_);                //               init(orgTest);           //    -.                preconditions();               //             actions(orgTest); }    /** *        **/ @Step(" ") protected void preconditions() {    loginStep1.login();    new SomeAction().apply(someTestObject1, ..., someTestObjectN);        Utils.allure.message("   -      -", someTestObjectN)        ...    }    /** *        */ @Step(" ") protected void actions(Login testLogin) {    testLogin.reLogin();               //                new SomeAction().apply(someTestObject1, ..., someTestObjectN); } } 

Modelo de Implementação de Classe de Script de Teste

 package autotest.business.actions.some_subsystem; public class SomeAction {            //   PageClassA pageA = new PageClassA(); PageClassB pageB = new PageClassB();    @Step("     TMS")    @Description("     TMS")    public void apply(someTestObject1, ..., someTestObjectN) {    //   TMS        step_1(...);        step_2(...);        ...        step_N(...);    }    @Step("  1    TMS")    private void step_1(...) {       pageA.createSomething(someTestObject1);// just as an example create }    @Step("  2    TMS")    private void step_2(...) {   pageA.checkSomething(someTestObject1);// just as an example }                       ... } 

Implementando a classe de filtragem de teste FilterTestRunner

Aqui está uma implementação da extensão BlockJUnit4ClassRunner para filtrar testes com base em conjuntos de tags arbitrários.

 /** * Custom runner for JUnit4 tests. * Provide capability to do additional filtering executed test methods * accordingly information that could be provided by {@link FrameworkMethod} */ public class FilterTestRunner extends BlockJUnit4ClassRunner { private static final Logger LOGGER = Logger.getLogger(FilterTestRunner.class.getName()); public FilterTestRunner(Class<?> klass) throws InitializationError {    super(klass); } /** * This method should be used if you want to hide filtered tests completely from output **/ @Override protected List<FrameworkMethod> getChildren() {    //  ,        @Filter       TestFilter filter = TestFilterFactory.get();    List<FrameworkMethod> allMethods = super.getChildren();    List<FrameworkMethod> filteredMethod = new ArrayList<>();    for (FrameworkMethod method: allMethods) {        if (filter.test(method)) {            LOGGER.config("method [" + method.getName() +"] passed by filter [" + filter.toString() + "]" );            filteredMethod.add(method);        } else {            LOGGER.config("method [" + method.getName() +"] blocked by filter [" + filter.toString() + "]" );        }    }    return Collections.unmodifiableList(filteredMethod); } /** * This method should be used if you want to skip filtered tests but no hide them @Override protected boolean isIgnored(FrameworkMethod method) {    …    if (filter.test(method)) {        return super.isIgnored(method);    } else {     return true;  }} */ } 

Na próxima parte, falarei sobre como implementamos o processo de upload de um arquivo do contêiner com o navegador para a estrutura de teste e resolvemos o problema de encontrar o nome do arquivo baixado pelo navegador.

A propósito, teremos o maior prazer em reabastecer nossa equipe. As vagas atuais estão aqui .