Mudanças entre as edições de "Framework de testes automatizados"

Edição das 13h21min de 28 de abril de 2015

INTRODUÇÃO

O teste funcional automatizado consiste basicamente em executar um mesmo algoritmo com diferentes massas de dados. Para cenários diferentes temos dados diferentes com resultados esperados diferentes, e inserir estes dados e resultados diretamente no código implica em replicar (tantas vezes quantos cenários diferentes existirem) código para poder atender a diferentes situações.

O objetivo de se desenvolver um framework para automação dos testes é permitir que seja criada uma camada de dados independente da camada de algoritmos que executam a automação. Esta é a tradicional divisão de software em duas camadas. Esta divisão (algoritmo versus dados) é válida tanto para testes automatizados funcionais como para testes unitários.

Este arquivo descreve a documentação técnica para manutenção do framework de testes automatizados a ser utilizado para testes unitários e testes funcionais. O documento está organizado em seções que descrevem separadamente as características de cada parte da arquitetura do framework.

VISÃO ARQUITETURAL POR SERVIÇO PRESTADO

A arquitetura do framework de testes desenvolvido pode ser vista sob o ponto de vista da funcionalidade fornecida para os desenvolvedores. A Figura abaixo ilustra a divisão por funcionalidade da arquitetura proposta.

Núcleo genérico

O núcleo genérico do framework tem a função de carregar os dados dos cenários (provenientes de arquivos XML), carregar os cenários e executá-los, independentemente se esta execução se trata de um teste funcional com Selenium ou de um teste unitário. Trata-se de um conjunto de classes, em sua maioria abstratas, que definem um conjunto de comportamentos esperados da funcionalidade de testes automatizados.

Núcleo Selenium

O núcleo Selenium é uma camada sobre o núcleo genérico, que usa os serviços deste (por herança e composição) para a execução de testes funcionais em páginas web. É um conjunto de classes em sua maioria também abstratas que, além de estender as classes do núcleo genérico, camada faz uso do Selenium WebDriver para acessar o navegador, preencher os campos de formulário e conferir os valores dos elementos HTML.

É importante observar que esta camada é independente do sistema web que será testado. Ou seja, qualquer sistema web baseado com páginas HTML pode ter seus testes funcionais automatizados com base no framework desenvolvido.

Testes do PJe

Nesta camada estão as classes que implementam de fato a automação dos casos de teste do Pje. Elas são desenvolvidas segundo o padrão Page Object e, na hierarquia do framework, estendem funcionalidades de FluentPage.

São um conjunto de classes concretas responsáveis por armazenar os dados e definir o algoritmo concreto para execução. Cada caso de teste requer uma classe específica para armazenamento dos dados e outra para a execução do teste. A classe de armazenamento de dados é responsável por realizar a leitura do arquvo XML e armazenamento dos dados para execução.

VISÃO ARQUITETURAL POR CAMADAS

Sob outro ponto de vista o framework pode ser analisado de acordo com as camadas tradicionais da arquitetura em camadas, com divisão de dados e lógica de negócio. A Figura a seguir exibe a arquitetura dividida em camadas.

Arquivo xml cenários Este arquivo é responsável por armazenar os dados para execução dos cenários. Para cada caso de teste é necessário criar um arquivo xml com os dados para sua execução. Em um arquivo podem ser definidos vários cenários para execução, com valores diferentes entre eles.

Arquivo xml indexador Este arquivo funciona como um conjunto de links para os cenários que serão executados, cenários estes cujos dados de execução são definidos no arquivo xml descrito na seção anterior.

De acordo com a relação entre o arquivo indexador e o arquivo de cenários ilustrada na Figura acima, um arquivo indexador fornece links para vários arquivos de cenários. Tanto arquivos xml indexadores quando arquivos de cenário devem ser criados dentro do diretório xml/ da aplicação.

Em geral deve haver poucos arquivos de indexação de cenários, pois cada um deles referencia inúmeros arquivos de cenários.

Classes de indexação de cenários

Classes de indexação são as classes chamadas pelo Junit como ponto de partida para a automação. No framework existe apenas uma classe, abstrata, chamada TesteBase, e que utiliza apenas a anotação @Test do Junit.

Para cada arquivo xml indexador descrito na seção anterior deve existir uma classe criada pelo desenvolvedor. Esta classe deve estender TesteBase, somente; nenhuma outra implementação é necessária.

O nome da classe também deve guardar relação com o nome do arquivo xml indexador. Por exemplo, se o nome do arquivo indexador for Cenarios1G.xml, o nome da classe deverá ser Cenarios1GTest. Ou seja, o nome da classe deve possuir o sufixo Test. No padrão de desenvolvimento do framework esta classe deve ser criada abaixo da estrutura src/test/java, conforme ilustrado pela Figura 3.

REFERÊNCIAS

Frameworks: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.29.6157&rep=rep1&type=pdf

Selenium Webdriver: http://www.seleniumhq.org/projects/webdriver

Fluentlenium: https://github.com/FluentLenium/FluentLenium

Design Pattern Page Object: https://code.google.com/p/selenium/wiki/PageObjects

Design Pattern Decorator: http://www.dofactory.com/net/decorator-design-pattern

Design Pattern Template Method: http://www.dofactory.com/net/template-method-design-pattern

Design Patterm Singleton: http://www.dofactory.com/net/singleton-design-pattern