Automação de testes com robot framework - básico [author] videos

A prática atual de testes funcionais automatizados é uma estratégia muito satisfatória para evitar alto orçamento para desenvolvimento de software e atrasos na entrega. No entanto, algumas limitações podem ser abordadas no uso de automação como o alto preço das licenças de software e o desconhecimento das boas práticas para estabelecer e organizar um projeto de testes automatizados. Neste ponto, a adoção bem-sucedida de abordagens para automação de testes funcionais depende de vários fatores, desde seguir boas práticas para concepção, modelo e codificação dos scripts de testes, até o execução das suites de testes e resultados de relatórios, considerando o conhecimento da equipe para aprender, corrigir e evoluir os artefatos do projeto de testes. Este artigo apresenta o Rudolfe's Test, uma proposta de framework de testes funcionais automatizados para aplicação web, que utiliza o método descritivo para reunir boas práticas e estabelecer um projeto de automação de testes: (i) reduzindo a complexidade para configuração e implementação de scripts de teste (automação baseada nas boas práticas de reutilização - com Selenium - e padrões de projeto); (ii) fornecendo mecanismo de execução capaz de capturar informações da execução; e, (iii) apresentando dados estatísticos e relatórios sintéticos para usuários após a execução, em todo um ambiente free/open-source. O uso da estrutura atual é exemplificado pelo sistema “Rudolfe's Test Web”.

1. Introdução

A utilização de software faz parte do nosso cotidiano, ainda que sem perceber esteja presente em televisores, geladeiras, automóveis, celulares, caixas eletrônicos, relógios, etc. Para qualquer um desses equipamentos, a expectativa é que irão funcionar da maneira esperada e qualquer divergência entre o resultado esperado e o resultado obtido pode ocasionar certos transtornos, em diferentes proporções de gravidade. Para evitar possíveis problemas é que submetemos as aplicações a um processo de teste de software, a fim de que se possam coletar informações sobre o software e assim verificar se este está se comportando de acordo com os requisitos solicitados. Havendo não-conformidades, deve-se proceder com os ajustes necessários para que seja obtido o seu correto funcionamento. Apesar de ser uma atividade inerente ao processo de desenvolvimento de software, os testes muitas vezes são menosprezados, não por serem menos importantes, mas sim por onerarem o custo final do produto. Estima-se que cerca de 40% do tempo planejado para um projeto venha ser utilizado na fase de testes, em contrapartida, um defeito descoberto tardiamente em um sistema provoca um acréscimo de 60% nos custos do projeto [Pressman 2010]. O fato é que, ao contrário do que muitos acreditam, os testes de software objetivam não somente elencar inconsistências, mas também evitar que o produto possa se tornar mais custoso, já que com pouca ou nenhuma atividade de testes, ele provavelmente resultará em uma aplicação de baixa qualidade, que implicará em retrabalho, diversas manutenções e, consequentemente, mais cara [Vidal 2011]. A automatização dos testes, em determinadas circunstâncias, tem se mostrado uma estratégia bastante satisfatória para melhoria do processo de testes como um todo, já que esta acaba proporcionando aumento na produtividade (menor tempo de execução), na melhoria da qualidade e precisão da execução (consistência de cenários) e na redução de custos (capital humano) [Lages 2010]. No entanto, dificuldades podem ser causadas simplesmente pelo desconhecimento de boas práticas de organização de um projeto com automação de testes [Bernardo 2011]. Desta forma, o sucesso da automação depende de uma série de fatores, que vão desde a forma de conceber este projeto, sua arquitetura base, estruturas, padrões e boas práticas aplicadas, até o nível de praticidade com a qual o projeto é executado, os utilitários são disponibilizados e os resultados das execução são apresentados aos demais colaboradores da equipe. Objetivo. Este trabalho irá apresentar o framework Rudolfe's Test como solução para o desenvolvimento de um projeto de automação de testes, com foco em aplicações Web, visando:

1. discutir, a partir de uma série de cenários comuns, algumas técnicas, padrões e boas práticas para a adoção do projeto de testes automáticos, free/open-source (gratuito e de código aberto);
2. abstrair as complexidades de configurações iniciais do projeto de testes automáticos, definindo uma estrutura para organização dos testes;
3. abstrair grande parte da complexidade de implementação de scripts de testes automáticos, oferecendo uma arquitetura base que propicie baixa curva de aprendizado, desenvolvimento ágil e manutenção facilitada dos testes;
4. oferecer um motor de execuções robusto, que capture as informações sobre as ações realizadas;
5. disponibilizar dados estatísticos/relatórios sobre as execuções automáticas de forma legível para um usuário comum.

Para atingir os objetivos desta pesquisa, utilizamos o método descritivo. Especificamente, nós realizamos as etapas de revisão bibliográfica para entender os avanços dos estudos recentes na área de automação de testes a nível funcional de software, analisando as ferramentas atuais existentes no mercado de TI, para no final obter as informações necessárias para elencar requisitos para uma ferramenta de automação de testes funcionais de software completa, assim montando o arcabouço desta ferramenta, e através deste realizar implementação para disponibiliza-la para usuário final para sua validação através de amostragem coletada desses.

Este artigo está organizado como segue: a seção 2 apresenta os principais trabalhos relacionados, com enfoque ao desenvolvimento de soluções free/open-source para testes automáticos. Na seção 3, são detalhadas as etapas de execução da pesquisa, desde o levantamento das técnicas, padrões e boas práticas para adoção do projeto de testes automáticos, passando pelas soluções existentes, até a concepção e desenvolvimento do framework open-source Rudolfe's Test. Na seção 4, nós detalhamos a arquitetura e o desenvolvimento do framework, os padrões seguidos e o propósito a que serve. Já na seção 5 nós exemplificamos o uso do framework através da implementação dos testes automatizados no sistema “Rudolfe's Test Framework” Web. Por fim, a seção 6 apresenta as nossas conclusões e propõe alguns trabalhos futuros.

2. Fundamentação Teórica

Recentemente, várias instituições estão buscando novas estratégias de melhoria para as atividades de teste, com o objetivo de construir softwares mais confiáveis e com menores custos de produção [Sogeti 2017, Steckham 2016, Symphony 2017, Nguyen 2017, Brian 2017].

Neste sentido, o relatório ‘Sogeti's World Quality Report’ [Sogeti 2017] apresenta as principais tendências que moldam a Garantia da Qualidade (QA) e os testes, destacando a automação de testes [Bernardo 2011, Chiavegatto et al. 2013, Pressman 2010, Vidal 2011, Sogeti 2017], as soluções bimodais [Sogeti 2017] e a automação de testes inteligentes [Sogeti 2017, Steckham 2016].

Paralelamente, várias análises comparativas e estudos aprofundados estão sendo conduzidos com a finalidade de desenvolver e prover conhecimentos que auxiliem os profissionais a aprimorar seus processos de QA por meio da automação [Nguyen 2017, Steckham 2016, Brian 2017, Symphony 2017]. Ferramentas de automação de testes, como o Selenium [HQ 2018], Katalon Studio [Studio 2018], UFT [Focus 2018], Watir [Grant 2018], IBM Rational Function Tester [IBM 2018], TestComplete [Bear 2018], TestPlant eggPlant [eggplant 2018], Tricentis Tosca [Tricentis 2018], Ranorex [Ranorex 2018] e Robot framework [Framework 2018] já foram elencadas como as 10 melhores existentes no mercado atual de software, para o biênio 2017-2018 [Brian 2017, Nguyen 2017], avaliadas sob critérios como: presença de plataforma de desenvolvimento de teste; linguagem de script utilizada; habilidades de programação suportadas; curvas de aprendizado; facilidade de instalação e uso; tempo para a criação de scripts; armazenamento e manutenção de objetos; teste baseado em imagem; integrações contínuas; suporte ao produto; tipo de licença; e, custo. Este trabalho objetiva viabilizar a redução dos custos para processo de qualidade, este abordará apenas as principais ferramentas open-sources presentes na lista das 10 melhores do mercado, a saber: Selenium, Watir e Katalon Studio [Nguyen 2017, Brian 2017].

Nesta seção nós iremos apresentar apenas algumas ferramentas free/open source disponíveis no mercado para automação dos testes (já que estas se alinham ao objetivo de redução de custos defendido neste trabalho), relacionando alguns dos principais resultados dos estudos comparativos já existentes e salientando as contribuições que vieram fundamentar a concepção e implementação do framework ora proposto.

O Selenium é uma ferramenta robusta que possibilita a programação de estímulos no formato de ações em navegadores web, que tem como finalidade simular ações realizadas por humanos. Do ponto de vista dos testes automáticos, são elaborados roteiros no formato de procedimentos (passo a passo que deve ser aplicado ao software em análise), no qual o cumprimento dos passos é considerado um caso de sucesso e o contrário caracteriza uma não-conformidade [Bernardo 2011, Chiavegatto et al. 2013, Brian 2017, Nguyen 2017, Sogeti 2017, Gonc¸alves 2011]. O Selenium é solução de mercado de onde muitas outras derivam, a exemplo do Katalon Studio, Protractor, Watir Radonex, Robot Framework, entre outras. Sua versão IDE, no entanto, não supre requisitos básicos de um projeto orientado a objetos para automação, por exemplo: não proporciona a reutilização de código, permitindo apenas criação dos scripts em formato estruturado, dificultando a manutenibilidade; apresenta limitações na execução, pois só pode ser utilizado via Mozilla Firefox; impossibilita a personalização de entradas de dados dinâmicos, impedindo a aplicação de técnicas como a Análise do Valor Limite, Tabela de Decisão, Teste de transição de estados, como também a capacidade de gerenciar ambiente de execução, dentre outras séries de fatores [Bernardo 2011, Chiavegatto et al. 2013, Brian 2017, Nguyen 2017, Sogeti 2017, Gonc¸alves 2011].

Já na versão Webdriver, abre-se um leque de oportunidades, devido à possibilidade de personalização, execução em diversos navegadores web e livre implementação dos scripts. Todavia, esta versão não pode ser considerada uma ferramenta completa para automação de testes funcionais de software, mas sim uma solução que provê a simulação de ações no browser. Neste ponto, encontramos trabalhos que utilizaram esta versão em conjunto com outras ferramentas, como JUnit, DBUnit, Cucumber, Test NG, Jenkins, Ant, etc., de modo a criar um ecossistema para execução do projeto de automação de testes funcionais, que inclui complementar a forma de execução a partir da preparação dos dados para execução e da consolidação dos resultados obtidos, que estão intimamente ligados à estratégia empregada nos procedimentos de criação dos script de testes automatizados [Bernardo 2011, Gonçalves 2011].

Portanto, o Selenium não fornece um “projeto base” e há necessidade de se complementar o WebDriver através de outras ferramentas a fim de implementar estruturas e padrões que viabilizem a adoção de boas práticas de implementação e que facilitem a criação e a manutenção de scripts, que venham amenizar a curva de aprendizado de seus utilizadores.

O Watir é uma ferramenta similar ao Selenium Webdriver, que utiliza bibliotecas desta última como base e, assim, proporciona os mesmos recursos que esta: personalização, execução em diversos navegadores e livre implementação dos scripts de teste. Seu diferencial reside no encapsulamento do Selenium, de forma a abstrair boa parte da sua complexidade com relação às configurações necessárias para sua execução. Ela também dispõe de uma boa documentação de uso, assim como vídeos e tutoriais intuitivos [Grant 2018].

Assim como o Selenium WebDriver, esta ferramenta não tem como objetivo prover um ecossistema completo na perspectiva da automação, pouca abstração entre os elementos físicos manipulados no navegador (browser), os dados e os elementos de código-fonte que são necessários para implementar os testes, além de não realizar a apresentação dos resultados de testes funcionais de forma detalhada, sendo tais capacidades possíveis, apenas, com a integração com outras ferramentas.

O Katalon Studio é uma solução avançada, quando comparada ao Selenium e ao Watir. Ela possui uma IDE de desenvolvimento (semelhante ao Selenium IDE) que dá a possibilidade de realizar a execução de outros navegadores, além do Mozilla Firefox. Ela possibilita a automação de mobile app, criação de scripts com função “clica e arrasta” e define novas estruturas através de padrão de projeto Page Object [Martin 2013], que abstrai e centraliza a criação de scripts através de um único objeto, o que possibilita a execução, obtenção e divulgação dos resultados da execução de forma detalhada. A ferramenta possui um amplo tutorial. Desta forma, mostra-se uma ótima ferramenta no contexto de automação de testes funcionais [Studio 2018].

Apesar destas vantagens, podemos elencar alguns problemas:

1. indisponibilidade de recurso que promova a customização de entradas de dados dinâmicos: que possibilitam a aplicação de técnicas como Análise do Valor Limite, Tabela de Decisão, Teste de transição de estados, por exemplo;
2. tarefas de baixo nível: a ferramenta dispõe de vasto tutorial em sua documentação que expõe soluções para determinadas tarefas, porém, em algumas dessas soluções, são fornecidos ao usuário código de baixo nível, como a execução de um script SQL, no qual a solução ministra um trecho de código de baixo nível que realiza comunicação com banco de dados e executa script SQL, quando a ferramenta deveria disponibilizar ao usuário determinada ação de forma a abstrair a complexidade de sua utilização, assumindo a responsabilidade de tal tarefa.
3. configurações complexas: por exemplo, a forma na qual o usuário deve configurar a ferramenta para que esta submeta os resultados às partes interessadas.
4. conteúdo do relatório: trata apenas de dados básicos (listagem passou-falhou), sem histórico e métricas específicas de qualidade (que possibilite a comparação de resultados e a verificação da evolução da qualidade do produto).

2.1. Técnicas de testes funcionais

Automação de testes ao nível funcional de software não é uma tarefa fácil de ser executada, pois existem inúmeros fatores que permeiam a adoção desta estratégia. Podemos afirmar que um fator crítico para o seu sucesso é a base arquitetural do projeto, solução esta que deve ser pensada de modo a satisfazer o contexto global do projeto de automação, através de um modelo conceitual que preconize camadas que se comuniquem harmonicamente entre si (sem acoplamento). Este modelo deve contemplar necessidades que vão desde como criar, configurar e implementar, até a utilização de um arcabouço de ferramentas capazes de tornar produtiva a atividade de especificar e executar testes na prática [Bernardo 2008].

Neste sentido, analisaremos as boas práticas de testes funcionais automáticos, contextualizadas com base nas revisões bibliográficas realizadas.

As principais propriedades que toda ferramenta de teste automatizados deveria possuir são: automação, repetição, utilidade, unicidade, precisão, proficiência, legibilidade, simplicidade, independência, isolamento e rapidez [Bernardo 2011].

“Utilidade” e “unicidade” dizem respeito, respectivamente, à implementação dos casos de testes mais críticos e ao agrupamento (partição dos dados de entrada) dos comportamentos específicos do sistema, que diz respeito ao projeto de testes como um todo. Já a “legibilidade” enquadra-se com a clareza nos quais variáveis, métodos, classes, que se relacionam intimamente com a implementação dos scripts de casos de teste, na promoção de técnicas da orientação a objetos, refatoração, reflexão ou orientação a aspectos [Bernardo 2011, Vidal 2011, Martin 2013, Gonc¸alves 2011].

As demais propriedades podem ser encaradas enquanto atributos da automação, que mais se aproximam dos desejos subjetivos que ensejam as boas práticas de organização do projeto de automação, destacamos:

1. Repetição: As funcionalidades dos arcabouços devem garantir que os testes possam ser executados quantas vezes forem necessárias, de tal forma que sempre produzam os mesmos resultados. Essa característica pode ser difícil de ser assegurada, tanto em algoritmos que trabalham com datas e horários, quanto com relação aos dados persistidos no banco.
2. Simplicidade A criação e manutenção dos scripts de teste devem ser uma tarefa sem grandes dificuldades, na qual é fundamental o uso de arcabouços e ferramentas de testes adequadas para o que o teste se torne o mais simples possível.
3. Independência: Os scripts de teste devem ser independentes uns dos outros, onde a ordem de execução não deve interferir no resultado obtido.
4. Isolamento: Cada um dos scripts de teste deve verificar apenas um aspecto do sistema, para isso, quanto mais isolado estiverem dos outros módulos do sistema, mais fácil será sua escrita e manutenção.

Observando os itens acima listados percebemos que a principal necessidade entre esses atributos está relacionada à forma de como criar e manter scripts de testes, o modelo arquitetural do projeto de testes, às estruturas básicas que irão compor os scripts de teste e à forma que estas estruturas se relacionam. Portanto, a correta solução para este ponto está na adoção de boas práticas, padrões de projeto e nas técnicas de implementação que permitirão estes atributos serem alcançados com os scripts (cenários de testes) e os conjuntos de dados.

2.1.1. Script

Ou, ainda, cenário de teste, pode ser descrito de forma sucinta como um procedimento, no formato de passo a passo, o qual deverá ser executados ordenadamente, objetivando realizar a cobertura de um dado fluxo do software, alvo dos testes [Nannine and Almeida 2012].

A elaboração dos scripts de teste geralmente toma como base os requisitos funcionais de software, onde o analista de teste não tem o conhecimento do funcionamento interno do sistema, no qual é levado em consideração apenas a documentação do sistema ou cenários de testes previamente elaborados. Por isso, esta prática recebe o nome de teste funcional ou teste caixa-preta. O agrupamento destes scripts de teste também seguem a mesma prática, sendo realizado com base no mesmo requisito funcional de software, ao que se denomina suite de testes [Pfleeger 2004].

A técnica de implementação do script de teste consiste em representar em formato textual os procedimentos a serem aplicados no software. A boa prática consiste em representá-lo em um formato de instruções padronizadas, a fim de que o computador possa interpretá-los e executar estas instruções de forma automática. Neste sentido, o script de teste é composto por:

• Pré-condição: analisando de forma detalhada os conceitos básicos, pode-se observar que os testes em determinados cenários podem possuir ou não dependências de pré-condição para que o procedimento principal possa ser executado. Tal pré-condição pode ser dada pela necessidade do estado do banco de dados, devido à necessidade de informações estarem contidas ou não no banco de dados no momento de sua execução, ou devido à necessidade de um determinado estado no qual a aplicação deve se encontrar, onde neste último pode ser satisfeito executando procedimentos até que esta condição encontre-se em estado satisfatório para inicio da execução. Assim definimos que uma pré-condição pode ser de dois tipos: estado de banco ou estado de execução.
• Procedimento principal: é de fato o objetivo alvo do teste, é através do exercício deste procedimento que será coletada informações afim de avaliar a funcionalidade em questão.
• Pós-condição: esta é a verificação na qual é realizada no software após a execução do procedimento principal afim de constatar que o software encontra-se no devido estado, verificação esta que pode ocorrer tanto através de constatação realizada no banco de dados, como também ao nível de aplicação.
• Conjunto de dados: é a coleção de informações que serão dadas como entrada no software a serem inseridas durante a execução do script, essas informações devem ser condizentes com as informações contidas no banco de dados, tanto para sua existência ou ausência.

Uma outra abordagem que vem sendo bastante adotada é a utilização é a aplicação de testes exploratórios, que surtindo bons resultados aos testes devido a testes a esse tipo de abordagem na se limitar a execução de fluxos não pré-delimitados pelo requisito funcional, deixando o testador a vontade com sua expertise para buscar possíveis inconsistências [Itkonen and Rautiainen 2005].

2.1.2. Conjunto de Dados

São as informações que serão prestadas como entrada no software, que devem ser inseridas durante a execução do script, onde, em determinados casos, devem estar relacionadas com as informações contidas em uma massa de dados para teste. Para elencar estas informações, existem algumas técnicas como, por exemplo [Nannine and Almeida 2012]:

• Partição de Equivalência: essa técnica consiste em identificar as condições necessárias para entrada de dados e dividi-las em entrada para o programa em classes de equivalência válidas e inválidas. Após isto, é selecionado o menor número de possibilidades de casos de teste, e com base na hipótese é criada uma classe genérica que represaria todas as classes, onde para cada uma das classes inválidas deve ser gerado um caso de teste distinto. Esta técnica permite que sejam examinados todos os requisitos de forma sistemática, restringindo ao menor número possível à quantidade de casos de teste (cobertura mínima);
• Análise do Valor Limite: essa técnica é associada às condições de entrada de dados, onde, de forma mais rigorosa, os valores devem beirar o limite das entradas. Esta técnica, em muitos casos, é aplicada de forma complementar à técnica de particionamento em classes de equivalência;
• Tabela de Decisão: essa técnica consiste em elencar requisitos de teste com base nas possíveis combinações para as condições de entrada. Primeiramente, são levadas em consideração as condições de entrada e as suas respectivas possíveis saídas. Com base nessas informações é construído um grafo que relaciona as possíveis as causas e efeitos elencados anteriormente. Em seguida estas informações são transformadas em uma tabela de decisão, para a qual são derivados possíveis casos de teste.

3. Metodologia

Neste artigo utilizamos o método descritivo, que consiste em exigir do investigador uma série de informações sobre o que se deseja pesquisar e descrever os fatos e fenômenos de determinada realidade, para que, a partir disto, possamos propor uma arquitetura base e contextualizada de testes funcionais automáticos [Trivinõs 1987]. Com relação às classificações de pesquisa, temos que se trata:

• natureza aplicada, já que nosso estudo aborda a problemática existente no âmbito empresarial de TI no que diz respeito à concepção de um projeto de testes funcionais automáticos e estratégias que podem ser adotadas para sua redução de custos e prazos no sistema “Rudolfe's Test Web”.
• caráter quantitativo, visto que aplicar-se-ão avaliações sobre critérios objetivos como: presença de plataforma de desenvolvimento de teste; linguagem de script utilizada; habilidades de programação suportadas; curvas de aprendizado; facilidade de instalação e uso; tempo para a criação de scripts; armazenamento e manutenção de objetos; teste baseado em imagem; integrações contínuas; suporte ao produto; tipo de licença; e, custo. Observa-se que tais critérios foram selecionados com base nos critérios que são utilizados na avaliação de ferramentas comumente utilizadas no mercado [Nguyen 2017, Steckham 2016, Brian 2017, Symphony 2017, HQ 2018, Studio 2018, Focus 2018, Grant 2018, IBM 2018, Bear 2018, eggplant 2018, Tricentis 2018, Framework 2018, Ranorex 2018].
• objetivos de cunho explicativo, dada a necessidade da contextualização de cenários de teste para exemplificação de problemas existentes na concepção de um projeto de automação de testes e a necessidade de serem aplicadas medidas para saná-los.
• procedimentos tecnológicos, foram utilizados: pesquisa bibliográfica sobre as tendências existentes no mercado atual de software, sobre os estudos realizados pelas empresas de software conduzidos no sentido de melhoria do processo de QA e sobre as melhores ferramentas de teste existentes no mercado.

Sendo assim, será adicionado para estudo de caso o sistema intitulado, por questão de sigilo, “Rudolfe's Test Web”, de onde iremos destacar cenários de testes que possuam situações de conflito ou dificuldade de automatização, utilizando o Rudolfe's Test Framework para superá-las.

Inicialmente foram abordados fatos sobre a concepção de um projeto de teste de software, descrevendo conteúdo pertinente à base arquitetural, padrões de projeto e boas práticas. Seguimos, agora, para a implementação de estruturas básicas de um projeto de teste e suas necessidades, onde será definida a modelagem e a relação entre as estruturas que compõem os testes, com a determinação de aspectos específicos dentro do contexto do teste funcional que irão direcionar a automação.

A partir daí, seguimos pelas seguintes etapas:

• Construção de arquitetura base para o projeto de testes automáticos, onde para este será pesquisada ferramentas gratuitas existentes atualmente no mercado, e também será elaborada uma modelagem para implementação, motor (engine) de execução, extração dos resultados de execução dos testes, configurações, classes utilitárias, entre outros;
• Apropriação de técnicas, boas práticas e especificação normativa de métricas para a construção do “Rudolfe's Test Framework”, através da sua ferramenta disponibilizada;
• Utilização do framework na implementação dos scripts de testes funcionais automatizados do sistema “Rudolfe's Test Web”;
• Demonstração de resultados obtidos através da utilização do framework;

Desta forma, será possível propor um guia que sintetizam as técnicas e boas práticas para a condução dos testes funcionais automáticos.

4. Rudolfe's Test Framework

Para o processo de automação dos testes de software, a operação que pode gerar maiores transtornos é a etapa de criação da base arquitetural do projeto, pois estabelecê-la dará os fundamentos às estratégias que serão executadas, bem como aos procedimentos que serão adotados. O “como” conceber um projeto de software é primordial, não só para projetos de automação, mas também para qualquer outro tipo de projeto, visto que é neste momento que devem ser compreendidas as suas necessidades, pois é com base nessas necessidades que serão tomadas as decisões para construção do arcabouço do projeto num todo. O projeto de automação deve ser visto como qualquer outro projeto de software, apesar de não apresentar complexidade isonômica aos demais projetos, visto que também sofrerá manutenção, versionamento, correções, dentre outros [Bernardo 2011, Pressman 2010, Sommerville 2011].

Nos casos de projetos de testes automatizados, é na base de criação do projeto de automação que serão definidos quais os procedimentos a serem tomados para implementação dos scripts de testes, como serão organizados, quais ferramentas serão adotadas, quando e quais padrões de projeto serão utilizados, criação de métodos utilitários que facilitem a implementação e outras séries de detalhes que deverão ser levados em consideração. Este projeto ainda deve ser um facilitador para quem o for utilizar, de forma que provoque agilidade no desenvolvimento e manutenção dos scripts, possa diminuir o esforço para o usuário. Desta forma, todos estes fatores dependerão da solução que for estruturada.

Antes que seja iniciada a arquitetura de um projeto, deve-se primeiramente entender a proposta do software a ser construído e verificar as suas necessidades. Tomando como base tais necessidades, serão primeiramente modeladas as estruturas mais básicas e posteriormente será definida a forma do como proceder para concepção de sua base arquitetural.

Com base nas características e conceitos explanados na seção 2.1 é que serão levantadas as principais estruturas básicas adotadas em torno das quais o “Rudolfe's Test Framework” se organiza e que darão origem ao principal artefato a ser desenvolvido no projeto de automação, onde com base no entendimento do contexto das estruturas mais básicas sobre teste de software e seus inter-relacionamentos, pode ser estabelecido um modelo que satisfaça as necessidades para um projeto deste tipo.

Nesta seção, apresentaremos o Rudolfe's Test Framework e sua ferramenta derivada para o suporte à automação de testes funcionais de software. A aplicação prática virá através do estudo de caso do projeto “Rudolfe's Test Web”.

4.1. Arquitetura do Framework

Um ponto crucial para construção do projeto de automação dos testes é no momento de sua concepção, já que este é o momento que é definido toda a base de arquitetura do projeto [Bernardo 2011]. Neste momento que será definido uma serie de critérios, como: o que deve ser feito, se existem ferramentas que satisfaçam as necessidades, se sim, quais ferramentas, se não, qual a alternativa a ser adotada para compor o projeto, como serão organizadas e separadas as estruturas (componentes) e a forma que estas se relacionam, como será executado, o que acontecerá em caso de sucesso, erro ou falha; como serão coletados e armazenados os resultados da execução, entre outros fatores que serão determinantes para o seu sucesso.

Esta estrutura não pode onerar o processo, e sim, deve ser uma ferramenta facilitadora, que auxilie o seu utilizador a uma fácil implementação, manutenção, execução e obtenção dos resultados [Pressman 2010, Sommerville 2011].

A nível estrutural, compreende-se que os testes são organizados de acordo com a Figura 1:

Figura 1. Componentes básicos do Rudolfe’s Test Framework Fonte: Autor próprio

• Suite: Estrutura base que tem como objetivo organizar os testes através do agrupamento dos scripts pelo seu requisito funcional de software, porém pode seguir outro critério de agrupamento, ficando em aberto para estratégia adotada.
• Script: É a principal estrutura definida dentro deste contexto, é nesta que serão declaradas todos os requisitos necessários para execução do fluxo em avaliação.
• Procedure: Estrutura na qual será invocada os procedimentos a serem aplicadas ao software em análise.
• Dataset: Estrutura responsável por gerir os dados de entrada a serem utilizados na execução dos testes.
• SQL: Estrutura responsável pela execução dos arquivos SQL responsáveis por manter o estado de banco de dados da aplicação.

Da estrutura organizada, verifica-se que as execuções dos scripts devem acontecer de forma independente, já que serão avaliadas de forma isolada (sem que um dado script B dependa de que o script A tenha sido executado). Assim, devido a avaliação ser dada sobre as informações obtidas durante a execução de dado script, faz-se necessário a coleta do máximo de informações para que esta avaliação seja feita da forma mais adequada, precisa e completa.

Quanto aos procedimentos, o framework trata como uma estrutura genérica, mudando-se apenas os estímulos a serem aplicados durante a sua execução, estímulos estes que podem ser do tipo de estado de software} ou estado de banco de dados.

Com base no requisito funcional “Manter Projeto” da aplicação Rudolfe's Test Web, para exemplificação do contexto explanado no paragrafo anterior, que tem como uma das suas pré-condições “Usuário ter efetuado login”, para que possa ser dado inicio a execução do procedimento principal do script, mas a pré-condição “Usuário ter efetuado login” também é um procedimento baseado no requisito funcional “Efetuar Login”, mais especificamente no fluxo “Efetuar login com sucesso”, que é o procedimento que espera como resposta final após sua execução obter usuário devidamente autenticado na aplicação, fluxo este que por sua vez tem como pré-condição “Ter usuário cadastrado na aplicação”, condição esta no qual determina a existência de uma dada informação contida no banco de dados da aplicação. Note que este último tem como pré-condição, não a necessidade de encontrar o software em determinado estado de execução, mas sim uma dada informação que se deve fazer presente no banco de dados no momento antes da execução para que seja obtido sucesso para todo decorrer desta execução.

No exemplo citado acima, fica claro a abstração de todos os estímulos aplicados ao software como procedure, onde a sua função (se pré-condição, procedimento principal do teste ou pós-condição) é relativa ao script no qual este está sendo referido. Esse modelo leva o usuário implicitamente a aplicar a boa prática de reutilização de código, já que os procedures implementados no requisito funcional “Efetuar Login” podem reutilizar por todos os outros scripts que tenham este procedimento como pré-condição.

Já os Datasets são implementados por arquivos de extensão CSV, onde este deve seguir um padrão na sua construção: a sua primeira linha deve ser composta por chaves, que devem ser separadas por ponto e virgula. Será através destas chaves que serão acessados os dados de teste (valores) a serem utilizados como entrada na execução dos scripts. Os conjuntos de dados de entrada são, portanto, cada uma das linhas consecutivas a linha de chaves de acesso do arquivo CSV, valores estes que também deverão ser separados por ponto e virgula, fazendo referência a sequência da sua respectiva coluna de sua chave de acesso. Assim cada linha representará uma execução do script de testes.

Os valores declarados podem ser acessados no formato desejado, como String, float, Integer, Double, Array, dentre outros, através da interface do Dataset, objeto esse que é recebido como entrada pelo método abstrato “runSteps” a ser implementado da interface “Procedure”.

O Dataset foi concebido primeiramente como uma estrutura facilitadora para manter os dados de entrada para o teste através de componente que abstraia o gerenciamento das informações que serão utilizadas para execução dos scripts de teste, deixando os dados de entrada disponíveis para pronta utilização para o motor de execuções do Rudolfe's Test Framework. A solução utilizada para o dataset foi tomada como forma de externalizar os dados de entrada do seu respectivo código, onde o acesso a estes dados será realizado através da referência da sua respectiva chave de acesso, desta forma poderão ser criados vários conjuntos de dados para este arquivo dataset, possibilitando assim a aplicação de vários conjuntos de dados ao referido script de teste, possibilitando aplicação das técnicas de elaboração de dados de entradas (citadas na seção 2.1).

A implementação da interface Procedure deve ser feita utilizando o padrão Page Object [Martin 2013], cujo uso é encorajado por este framework, onde existe uma grande diversidade de possibilidades da utilização de recursos tanto do Selenium, como também de outras APIs de testes funcionais automáticos, abstraindo a utilização desses e, assim, futuras evoluções da ferramenta Rudolfe's Test não terão grande impacto nos scripts testes já implementados.

Em conjunto com a elaboração dos datasets para os testes foi vista a necessidade de considerar as informações contidas em banco de dados da aplicação afim de garantir que uma dada informação esteja presente no momento antes do inicio da execução dos testes, assim garantido a integridade da base de dados da aplicação com relação aos datasets, como também a independência da execução dos scripts de teste.

Para sanar esta dificuldade, o framework suporta componente de execução de scripts SQL, através de anotação “@SQL”, que recebe como parâmetro um ou vários caminhos o arquivos de extensão SQL a ser executado. Esta estrutura executa os arquivos SQL antes do inicio da execução do seu respectivo script de teste, aprontando uma massa de dados inicial dinamicamente.

Todos os componentes disponibilizados pelo framework são implementados por meio de anotações, desta forma fica a cargo da ferramenta validar a implementação de todas a estruturas, como também o gerenciamento da execução, controlando a instanciação dos objetos e os deixando prontos para utilização, garantindo assim melhor gerenciamento de memória da máquina na qual serão iniciados os testes.

O framework ainda dispõe de recurso que possibilitam a compatibilidade da execução em diversos browsers, o agendamento da execução, sendo possível informar horário para inicialização da execução dos testes, possibilitando a utilização da máquina como recurso de testes em um momento em que esta não esteja sendo utilizada por um recurso humano (ver Figura 2).

Figura 2. Classe Main.java para execução dos testes Fonte: Autor próprio

Nas próximas seções iremos detalhar as ferramentas de apoio ao Rudolfe's Test Framework: o agente local e a aplicação web. Um resumo de como as diversas partes do framework e suas ferramentas de apoio interagem pode ser visto na Figura 3.

4.2. Agente Local

Após executado os testes, os dados coletados durante a execução devem ser submetidos para aplicação Web, mas para que isso aconteça, criou-se um agente para ser executado na máquina local utilizada para execução dos testes, agente este que executa um servidor local, afim de garantir o envio de todos os dados coletados, fazendo o fracionamento do envio, se necessário.

Figura 3. Diagrama de comunicação entre aplicação alvo de testes, agente local e aplicação Web (Rudolfe’s Test) Fonte: Autor próprio

Para que isto aconteça, o agente local solicita conexão com a aplicação alvo dos testes, sendo enviado um token para verificação de permissão ao projeto que deverá ser associado aos resultados da execução.

A Aplicação Web Rudolfe's Test, por fim, verificará se o agente está sendo executado durante as validações iniciais da execução dos testes e, caso este não esteja em execução, o iniciará. Através do uso do agente local, a execução ocorrerá em segundo plano como um processo da máquina local.

4.3 Aplicação Web

Uma vez submetidos os dados para a aplicação alvo dos testes através do agente local, a Aplicação Web encarregar-se-á de realizar o tratamento das informações recebidas pela execução dos testes, as organizará através dos devidos agrupamentos realizados por: suite, script, procedimento, passos executados, conjuntos de dados de entrada, tempo de execução do teste, browser utilizado para execução, classpath das classes, caminho para arquivo CVS, lista de caminhos para arquivos SQL, níveis relevância e criticidade, resultado do teste, tela de erro e motivo do erro, onde esses dois últimos serão capturados caso ocorra um erro durante a dada execução. Feita a organização, os dados devidamente tratados serão associados ao projeto em questão e serão persistidos no banco de dados da Aplicação Web.

Após realizada a organização das informações e persistência dessas, a aplicação Web realizará notificação de todos colaboradores do projeto em questão, notificando via e-mail, o qual será enviado informando que a nova execução foi realizada com sucesso e que está disponível para análise das partes interessadas.

O resultado final pode ser observado acessando a própria Aplicação Web, visualizando o projeto desejado, onde em tal visualização é possível observar listagem das últimas 10 execuções realizadas, com o detalhamento básico de cada execução, contendo horários de inicio e fim das execuções, tempo total de execução, quantidade total de execuções e percentual de sucesso, erro, falha e testes não executados (ver Figura 4).

Figura 4. Registros das execuções realizadas no projeto Rudolfe’s Test Web Fonte: Autor próprio

Pode-se visualizar qualquer das execuções acima relatadas de forma detalhada, através deste detalhamento é possível verificar maior quantidade de informações, de forma total, como também de forma individual a nível de suite, script e de cada uma das execuções.

5. Estudo de Caso

O estudo de caso realizado neste trabalho será feito através da aplicação do Rudolfe's Test Framework e suas ferramentas de apoio, com base no conhecimento prévio adquirido na seção 4, a partir da qual será implementada automação para alguns cenários de teste da aplicação “Rudolfe's Test Web”.

O primeiro passo a ser tomado para utilização o Rudolfe's Test Framework é a adoção de um IDE desenvolvimento para implementação de projeto de automação, a IDE pode ser qualquer um que suporte linguagem de programação Java 7 ou superior, e que preferencialmente dê suporte a criação de projeto Maven. A utilização do Maven deve ser feita para facilitar a configuração do projeto, porém não é um requisito obrigatório. Assim, o ambiente que será utilizado para implementação dos testes deve estar com o Java JDK instalado, e caso se opte pela utilização do Maven, esta ferramenta também deverá estar devidamente instalada.

Para iniciar um projeto de automação utilizando o Rudolfe's Test Framework, deve-se inicialmente criar um projeto Maven simples, após a criação de tal projeto, deve ser criado as estruturas de pacotes, pastas de resources e realizada a configuração do arquivo pom.xml do projeto, com dependência da API Rudolfe's Test Framework e dependência referente ao banco de dados da aplicação em avaliação (se houver). Também deve ser criado arquivo de propriedades (configuration.properties), e neste informar as propriedades de configuração para ferramenta, como informações de acesso ao banco de dados, informações de tempo de espera (timeout), tempo de demora (delay) entre ações, navegador padrão para execuções dos testes e seus respectivos server, dentre outras.

Como forma de demonstração do uso do framework e suas ferramentas de apoio, será realizada a implementação dos scripts de automação dos cenários de teste relacionados aos requisitos funcionais de software “RF02 - Efetuar Login” e “RF12 - Manter projeto”.

Baseando-se no conhecimento adquirido nas seções 2.1, os scripts de teste devem ser preferencialmente agrupados por uma suite, que propicia o agrupamento relacionado ao requisito funcional de software.

Figura 5. Classe suite, utilizando as anotações do framework Rudolfe’s Test Fonte: Autor próprio

Note que, na Figura 5, a representação da suite foi feita apenas criando a classe “UC12_ManterProjeto” e anotando-a com @Suite. Observe também que esta anotação tem atributos denominados “id” e “name”, que foram informados os valores “UC12” e “Manter projeto”, respectivamente. Também existem atributos declarados em seu corpo, atributos que representam os fluxos do sistema que deverão ser avaliados na execução da suite, e que cada atributo é do tipo da classe que representa o respectivo script. Cada um dos atributos deve ser anotado com @TestCase para ser reconhecido como um caso de teste da referida suite.

Na Figura 6 pode-se observar que a implementação da classe “UC12_TC01_CadastrarProjetoComSucesso” representa o cenário de teste “Cadastrar projeto com sucesso” da suite “Manter projeto”. Esta classe deve ser anotada com @Script, possuindo dois atributos obrigatório: “id” e “name”.

Figura 6. Classe Script, utilizando as anotações do Rudolfe’s Test Framework Fonte: Autor próprio

O cenário acima descrito é composto pelas pré-condições “Ter um usuário cadastrado” e “Ter efetuado login com sucesso”, procedimento principal do teste, pós-condição “Verificar mensagem sucesso” e ainda pelos dados de entrada para o teste.

No corpo da classe “UC12_TC01_CadastrarProjetoComSucesso” observa-se que foram declarados atributos do tipo Procedure, atributos que estão anotados com @PreCondition, para tipificá-lo como uma pré-condição, ou seja, para que este seja executado antes do procedimento principal, outro atributo com @Test para tipificá-lo como procedimento principal e o anotado com @PosCondition para tipificá-lo como pós-condição, ou seja, a verificação realizada após a execução do procedimento principal a fim de verificar se o objetivo da execução foi alcançado.

Esta composição informada acima permite que o seu utilizador subdivida todos os passos que serão aplicados no decorrer da execução do teste, desta forma este componente permite que os passos a serem aplicados possam ser implementados por de forma lógica e reutilizáveis, já que devido a esta divisão, é possível utilizar uma procedure que contenham os passos necessários para compor outro script de teste.

Um exemplo corriqueiro para várias aplicações é a situação de login, onde em muitos cenários de teste que possuam a execução deste requisito como pré-condição para sua avaliação, utilizando a estrutura mencionada acima fará com que a procedure implementada para a avaliação do próprio requisito da funcionalidade de login possa ser reutilizado para todos os demais cenários que tenham esta procedure como pré-condição. Outra situação que poderia ter esta execução subdividida seria quando o requisito funcional seja bastante extenso, como por exemplo um cadastro que possua muitos campos e abas. Outro benefício direto e implícito que esta estrutura traz é para manutenção dos scritps implementados, onde por exemplo fosse alterada a funcionalidade de login para que em vez de utilizar e-mail e senha para fazer a autenticação do usuário, fosse alterada para utilizar a autenticação de alguma rede social, uma fez realizada o ajustes necessário na procedure, este ajuste seria replicado para todos os demais scripts que utilizam esta procedure para o compor.

Ainda com relação a estrutura de procedure, note que está para ser utilizada em um script de teste faz-se necessário uma das anotações @PreCondition, @Test ou @PosCondition, desta forma a API pode destingir qual o papel de cada uma das procedures declaradas no corpo do script, assim pode ser avaliado somente o trecho da execução que de fato é o objetivo do teste.

Um exemplo desta situação seria que em um eventual script que tenha como pré-condição o login, e que durante a execução desta pré-condição tenha ocorrido alguma não conformidade que não permitiu a execução do trecho que avalia o procedimento principal objetivo do teste, desta forma a API compreende que de fato o ocorreu um erro durante a execução do dado teste, e que também que como o erro não ocorreu durante a execução do trecho objetivo da avaliação, esta compreende que devido a um erro durante a pré-condição não possibilitou que o objetivo principal possa ter sido avaliado, e desta forma na sua avaliação coloca status desta execução como “Não avaliado”.

Note ainda, que a classe “UC12_TC01_CadastrarProjetoComSucesso” foi anotada com @Dataset, anotação que possui atributo “pathCSV”, que representa o caminho para o arquivo de dados de entrada a ser utilizado pelo teste durante a sua execução.

Para os dados de entrada deve ser criado arquivo de extensão CSV, que deve ter a primeira linha do arquivo informado as chaves de acesso separados por ponto e virgula. Será através das referências dessas chaves de acesso que serão acessados os seus respectivos valores.

Figura 7. Arquivo CSV, utilizado para entrada de dados no Rudolfe’s Test Framework

As demais linhas, após a linha de chaves de acesso, representam os conjuntos de dados a serem utilizados no script pelos procedimentos, cada uma das linhas informadas representará uma execução do script de teste o qual pertence. O componente de dataset permite que seja declarado dados de várias tipos e formatos, como String, Long, Integer, Float, Double, Array, etc.

Desta forma é possível criar testes mais elaborados, utilizando técnicas de seleção de dados de entrada que objetivem testar maior número de entradas possíveis. Por exemplo, na aplicação “Rudolfe's Test Web” foi criado grande carga de dados com diversas combinações para o requisito funcional “Efetuar Login”, desta forma foi possível constatar que a declaração de uma senha composta apenas por zeros gera uma não conformidade na aplicação, que acaba impossibilitando a execução do fluxo de login.

As técnicas de identificação de dados de teste podem ser aplicadas em diversos cenários, como a verificação de limite entre períodos, limites entre valores mínimo e máximo, quantidade máxima de caracteres, entre outra infinidades de possibilidades que podem ser aplicadas aos testes, a fim de realizar maior cobertura das funcionalidades da aplicação e avaliação.

Agora observando as figuras 5 e 6 podemos observar que ambas as classes estão anotadas com @Script. Esta estrutura permite que em cada execução da aplicação sejam executados arquivos SQL com a finalidade de garantir que uma dada informação esteja contida ou ausente na base de dados da aplicação no momento antes da execução.

A anotação @Script pode ser declarada aos níveis de suite, script e procedure, onde o componente executará os arquivos SQL neste informados no momento antes da execução da estrutura em que foi declarada, assim, sempre será executado suite, script e posteriormente os procedures na ordem em que foram informados.

Os testes implementados para aplicação “Rudolfe's Test Web” utilizam o componente @Script de forma que ao nível de suite seja executado arquivo SQL que deleta schema, cria schema, povoa os dados básicos no schema e que, aos níveis de script e procedure sejam executadas as inserções dos dados pertinentes ao cenário de teste.

Como exemplo, o cenário de “Efetuar login com sucesso” tem como pré-condição “Ter um usuário cadastrado na aplicação”, pré-condição que consiste nos dados de um usuário específico estarem contidos na base de dados da aplicação no momento antes da execução deste cenário. Note que desta forma a execução do arquivo SQL pode ser feita de forma independente dos demais scripts, pois este, por si só, torna-se auto suficiente, visto que quando for executado, todos os seus pré-requisitos estarão conforme o esperado. Note que esta pré-condição será aplicada para todos os demais cenários de teste que passem pelo fluxo de efetuar login com sucesso, assim é possível reutilizar estes arquivos SQL em diversos outros scripts.

De forma análoga a situação acima citada, o procedure “Efetuar login” pode ser reaproveitado em todos os outros scripts de teste que o tenham como pré-condição, desta forma, além de possibilitar grande agilidade na implementação dos scripts de teste, devido a possibilidade de reutilização dos procedimentos já implementados para compor um script, também possibilita grande agilidade com relação a manutenibilidade dos mesmos, já que qualquer ajuste realizado em um procedure terá impacto replicado para todos os scripts que utilizem este mesmo procedure (Ver Figura 8).

Figura 8. Classe Procedure, utilizando as anotações do Rudolfe’s Test Framework Fonte: Autor próprio

A implementação de procedures deve ser feita no método “runSteps”, método que recebe como entrada um objeto Dataset com os valores referentes à linha correspondente do arquivo CSV que está sendo fornecido.

Para implementação do método “runSteps”, primeiramente é necessária a criação de classes que seguem o padrão Page Object (Classes que conterão o mapeamento das ações das páginas), onde esta deve ser declarada como atributo da classe procedure, atributo este que deve ser anotado com @Page. Feito isso apenas devem ser invocadas as ações das classes do page object na sequência da qual estas ações devam ser executas (ver Figura 9).

Figura 9. Classe Page Object, utilizando as anotações do Rudolfe’s Test Framework Fonte: Autor próprio

Para implementação de classes Page Object é necessário apenas criar classe que estenda da classe abstrata “PageObject”, e no corpo desta classe devem ser implementados métodos que representem as possíveis ações de cada página, estes métodos ainda devem ser anotados com @Action, anotação possui atributo obrigatório denominado “description”.

Figura 10. Etapas da execução da API Rudolfe’s Test Framework Fonte: Autor próprio

Para que seja realizada execução do projeto deve ser criada uma classe com um método main, e no corpo deste projeto deve ser invocada a classe “RudolfesTest” e o seu respectivo método “executar”, no qual seguirá as etapas de acordo como mostrado na figura 10.

Figura 11. Registo de execução no Rudolfe’s Test Web

Após realizada a execução dos testes na ferramenta “Rudolfe's Test Web”, as informações coletadas são submetida para Aplicação Web, que é encarregada por notificar os colaboradores sobre a nova execução e que a mesma está disponível para visualização. Essas informações são exibidas de forma tratada como exibida na Figura 12.

Figura 12. Detalhes da execução no Rudolfe’s Test Web

Detalhando a execução através da aplicação Rudolfe's Tes Web é possível observar diversos dados da execução, como id e nome, classes cliente, caminho de arquivos SQL e CSV, passos executados subdivididos por pré-condição, procedimento principal e pós-condição, lista de dados de entrada, tempos e métricas de avaliação de acordo como exibido nas imagens 11 e 12.

6. Resultados e Trabalhos Futuros

Construir ferramentas de apoio ao processo de testes é um desafio que a cada dia pode ser visto como mais necessário para a indústria, tendo em vista o contínuo crescimento das organizações, do número de clientes e dos requisitos por elas administrados e utilizados em suas aplicações. Neste sentido, a automação de testes funcionais em aplicações Web ganha um grande destaque, tendo em vista boa parte dos sistemas estarem migrando para este tipo de plataforma.

Embora existam várias APIs para o desenvolvimento de scripts de testes funcionais automatizados, este trabalho propôs criar um ecossistema para a automação de testes, que incluísse não apenas uma API para desenvolvimento de testes funcionais automatizados, mas também ferramentas auxiliares que tornassem mais dinâmica a execução e apresentação dos resultados dos testes.

Desta forma, ficou demonstrado pelo estudo de caso na seção 5 que o Rudolfe's Test Framework e suas ferramentas auxiliares (agente local e aplicação web) mostraram-se capazes de implementar casos de teste funcionais automatizados, sendo uma opção a ser considerada quanto à organização do projeto de testes, devido ao modo com que a arquitetura apresentada atende a este fim, uma vez que não se preocupa apenas em disponibilizar uma API (que é o foco de muitos produtos de mercado, tal como o Selenium), mas também por permitir:

• a organização do código-fonte: por fornecer uma API simples, baseadas no recurso de “anotações” de código-fonte JAVA com um padrão de comunicação entre camadas não-acopladas;
• encorajamento ao uso de padrões e boas práticas: na implementação do projeto de testes automáticos, dos quais a própria API foi baseada, enquanto à subdivisão em suites, scripts, procedures, datasets, SQL e a utilização de Page Objects.
• possibilidade de utilização de massa de dados estática e/ou dinâmica: pela execução de arquivos SQL e manipulação de dados em arquivos CSV.
• preocupação com a facilidade de execução e mostra de resultados: para disponibilização das ferramentas Agente Local e Aplicação Web, responsáveis, respectivamente, por gerenciar a execução das suites de testes funcionais automatizados e mostrar e armazenar o resultado das execuções (histórico).

Durante a utilização das ferramentas do Rudolfe's Test Framework também foram identificados alguns conjuntos de situações ainda não tratadas. Desta forma, em trabalhos futuros, deve ser realizado uma série de melhorias, as quais destacam-se:

• Execução em múltiplos navegadores: Dar a opção de configurar para que o teste seja executado em vários navegador por bateria de execução.
• Acesso a múltiplos bancos de dados: Possibilitar que possa ser gerenciado mais de um banco de dados.
• Execução em concorrência: Possibilitar execuções em paralelas de duas instâncias distintas como forma de verificar a simultaneidade da execução de determinada funcionalidade/browser.
• Melhoria de execução em SQL: Realizar correção de bugs, otimização de execução de script SQL e possibilitar verificação pós-execução.
• Banco NoSQL: Possibilitar o gerenciamento banco NoSQL.
• Modo demonstração: Possibilitar a execução de determinada funcionalidade para fins de homologação ou de caráter demonstrativo, de forma que os passos executado sejam notória para seu observador.
• Implementar recurso 'Matriz de rastreabilidade entre requisitos': Implementar funcionalidade que gere a matriz de rastreabilidade entre os requisitos de software.
• Melhorias no agente local: Implementar novas funcionalidades e ajustes de performance no agente localhost.
• Plugin Eclipse: Implementar plugin do Eclipse para execução dos testes.
• Integração continua: Implementar integração para continuous delivery (Docker, jenkins, etc).
• Integração com outras ferramentas: Implementar integração com outras ferramentas CASE (Testlink, Mantis, etc).
• Definir serviço baseados em REST: Complementar arquitetura com serviços baseados em REST para permitir integrar com outras ferramentas.
• Analise comparativa entre Rudolfe' Test Framework vs Outros framework: Realizar analise comparativa entre a proposta de framework Rudolfe's Test Framework com outros frameworks de maior aceitação de mercado de software.

7. Referências

Bear, S. (2018). TestComplete.

Bernardo, P. C. (2008). Devmidia - Engenharia de Software Magazine.

Bernardo, P. C. (2011). Padrões de testes automatizados. Dissertação de mestrado, Universidade de São Paulo.

Brian (2017). Best Automation Testing Tools for 2018. Medium.

Chiavegatto, R. B., Silva, L. V., Vieira, A., and Malvezzi, W. R. (2013). Desenvolvimento Orientado a Comportamento com Testes Automatizados utilizando JBehave e Selenium.

eggplant (2018). Test Plant.

Focus, M. (2018). Unified Functional Testing (UTF).

Framework, R. (2018). Robot Framework.

Gonçalves, H. N. (2011). Geração de testes automatizados utilizando o Selenium. PhD thesis, Universidade de Pernambuco.

Grant, J. (2018). Watir.

HQ, S. (2018). Selenium HQ.

IBM (2018). Rational Functional Tester.

Itkonen, J. and Rautiainen, K. (2005). Exploratory testing: A multiple case study. Proceedingsofthe4thInternationalSymposiumonEmpiricalSoftwareEngineering(ISESE 2005).

Lages, D. S. (2010). Automação dos Testes: um lobo na pele de cordeiro? Revista Engenharia de Software Magazine – Automação de testes, 29a edition.

Martin, F. (2013). Page Object. Martin Fowler.

Nannine,P.H.andAlmeida,R.(2012). Syllabus-AnalistadeTestesCertificado. IBQTS, São Paulo.

Nguyen, V. (2017). A Comparison of Automated Testing Tools. DZone.

Pfleeger, S. L. (2004). Engenharia de Software: Teoria e Prática. Pearson Prentice Hall Brasil, São Paulo, 2a edition.

Pressman, R. S. (2010). Engenharia de Software. AMGH, Porto Alegre, 7a edition.

Ranorex (2018). Ranorex.

Sogeti (2017). WORLD QUALITY REPORT 2017-18 - 9TH EDITION. Sogeti.

Sommerville, I. (2011). Engenharia de Software. Pearson, São Paulo.

Steckham, M. (2016). The Forrester WaveTM: Modern Application Functional Test Automation Tools, Q4 2016. IBM.

Studio, K. (2018). Katalon Studio.

Symphony, Q. (2017). 100+ Best Software Testing Tools. Q.A. Symphony.

Tricentis (2018). Tricentis Tosca.

Trivinõs, A. N. S. (1987). Introdução à pesquisa em Ciências Sociais: a pesquisa qualitativa em educação. Atlas, São Paulo.

Vidal, A. R. (2011). Teste Funcional Sistemático Estendido: Uma Contribuição na Aplicação de Critérios de Testes Caixa-Preta. Dissertação de mestrado, Universidade Federal de Goiás.