AUTOMATIZAÇÃO DE TESTES DE INTERFACE EM LINGUAGEM ALTO NÍVEL MATEUS ADENIZ PEGORARO. Trabalho de Conclusão de Curso

Transcrição

1 SERVIÇO NACIONAL DE APRENDIZAGEM INDUSTRIAL FACULDADE DE TECNOLOGIA SENAI/SC FLORIANÓPOLIS CURSO SUPERIOR DE TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS AUTOMATIZAÇÃO DE TESTES DE INTERFACE EM LINGUAGEM ALTO NÍVEL MATEUS ADENIZ PEGORARO Trabalho de Conclusão de Curso Florianópolis/SC 2014

2 MATEUS ADENIZ PEGORARO AUTOMATIZAÇÃO DE TESTES DE INTERFACE EM LINGUAGEM ALTO NÍVEL Trabalho de Conclusão de Curso apresentado à Banca Examinadora do Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas da Faculdade de Tecnologia do SENAI Florianópolis como requisito parcial para obtenção do Grau de Tecnólogo em Análise e Desenvolvimento de Sistemas. Professor Orientador: João Carlos Testi Ferreira, esp.. Florianópolis/SC 2014

3 MATEUS ADENIZ PEGORARO AUTOMATIZAÇÃO DE TESTES DE INTERFACE EM LINGUAGEM ALTO NÍVEL Trabalho de Conclusão de Curso apresentado à Banca Examinadora do Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas da Faculdade de Tecnologia do SENAI Florianópolis como requisito parcial para obtenção do Grau de Tecnólogo em Análise e Desenvolvimento de Sistemas. APROVADA PELA COMISSÃO EXAMINADORA EM FLORIANÓPOLIS, 20 DE DEZEMBRO DE 2014 Prof. Luciana Shmitz, esp. (SENAI/SC) Coordenador do Curso Profa. Jaqueline Voltolini de Almeida, esp. (SENAI/SC) Coordenador de TCC Prof. João Carlos Testi Ferreira, esp.(senai/sc) Orientador Prof. Rodrigo Fortes Candido, esp. (SENAI/SC) Examinador

4 Dedico este trabalho à minha família que me deu forças e jamais deixou de acreditar em mim. Dedico também a cada um dos professores pelos quais tive a honra de ser instruído, cada um, de certa forma e a seu modo, foi responsável pela conclusão deste trabalho. E dedico principalmente ao meu orientador João Carlos Testi Ferreira, por todo o conhecimento, pela dedicação e por ter me aceitado como orientando.

5 AGRADECIMENTOS Agradeço ao meu orientador por todo o conhecimento e por me guiar neste trabalho em tempos difíceis. Agradeço ao projetista da minha equipe, Elton Andrade dos Santos por todo o auxílio, conhecimento, tempo e paciência dedicados a mim. Vocês foram fundamentais para a conclusão deste trabalho.

6 Que os vossos esforços desafiem as impossibilidades, lembrai-vos de que as grandes coisas do homem foram conquistadas do que parecia impossível (CHARLES CHAPLIN)

7 PEGORARO, Mateus. Automação de Testes de interface em Linguagem Alto Nível. Florianópolis, f. Trabalho de Conclusão de Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas - Curso Análise e Desenvolvimento de Sistemas. Faculdade de Tecnologia do SENAI, Florianópolis, RESUMO Este trabalho apresenta o desenvolvimento de uma ferramenta de testes de interface em uma metalinguagem amistosa e inteligível para usuários que não possuam conhecimento técnico em codificação. A vantagem é reduzir o tempo de manutenção e adequação dos testes automatizados de interface, além de torná-los mais flexíveis.

8 PEGORARO, Mateus. Automação de Testes de interface em Linguagem Alto Nível. Florianópolis, f. Trabalho de Conclusão de Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas - Curso Análise e Desenvolvimento de Sistemas. Faculdade de Tecnologia do SENAI, Florianópolis, ABSTRACT This work presents the development of a tool in a friendly and intelligible metalanguage for users without technical knowledge in coding. The advantage is to reduce maintenance time and suitability of automated interface tests, and make them more flexible.

9 LISTA DE ILUSTRAÇÕES Figura 1 Problemas na fase de criação de um projeto Figura 2 Relação entre exemplos, requisitos e testes Figura 3 Testes de software x Camadas no processo de software Figura 4 Exemplo de implementação do Gherkin Figura 5 Exemplo de implementação de um cenário de testes em Gherkin Figura 6 Exemplo de implementação de uma tabela com uso de Examples com Gherkin Figura 7 Investimento do tempo em automação (de setembro a novembro de 2013) 24 Figura 8 Exemplo de uso de um WebDriver com FireFox Figura 9 Arquitetura do Selenium RC com alguns navegadores de exemplo Figura 10 Selenium IDE - Exemplo de busca no google Figura 11 Exemplo de implementação de um Page Object Figura 12 Exemplo de implementação do JBehave em linguagem Java Figura 13 Exemplo de implementação textual de uma lista utilizando o padrão Gherkin Figura 14 Classe modelo para a lista especificada na feature da figura Figura 15 Exemplo de implementação do JBehave em linguagem Java Figura 16 Etapas de metodologia Figura 17 Exemplo de implementação de um Fluxo de Teste Figura 18 Exemplo de implementação de um Passo de Teste Figura 19 Exemplo de implementação de um Passo de Teste no XML Figura 20 Arquitetura atual Figura 21 Arquitetura proposta Figura 22 Implementação do DataProvider Figura 23 Implementação do RunnableScript Figura 24 Implementação do ScriptCommand Figura 25 Implementação da execução do Script utilizando o DataProvider Figura 26 Implementação do passo com o ScriptAction para definição das Keywords 44 Figura 27 Arquivo de script referente ao passo anterior

10 LISTA DE ABREVIATURAS E SIGLAS BDD HTML TDD URL HTTP XML Behavior Driven Development (Desenvolvimento Orientado a Comportamento). HyperText Markup Language (Linguagem de Marcação de Hipertexto). Test-Driven Development (Desenvolvimento Orientado a Testes). Uniform Resource Locator (localizador de recurso uniforme). HyperText Transport Protocol (Protocolo de transporte de hipertexto). Extensible Markup Language (Linguagem de marcação extensível).

11 SUMÁRIO 1 INTRODUÇÃO JUSTIFICATIVA OBJETIVOS Objetivo geral Objetivos específicos ESTRUTURA DO TRABALHO REVISÃO DA LITERATURA Behavior Driven Development (BDD) Ciclo de entrega O que é uma Estória? O que é um Cenário? Introdução a Testes de Software Testes de caixa preta Testes de caixa branca Gherkin Keywords Scenario Given, When, Then e Asterísco (*) Examples Testes Automatizados Testes funcionais de interface com Selenium Selenium Framework Selenium 2 (Selenium WebDriver) Selenium RC Selenium IDE Selenium Grid TestNG Page Object JBehave framework Escrever uma estória Mapear os passos para o Java Cucumber framework PROCEDIMENTOS METODOLÓGICOS Levantamento bibliográfico Definição dos recursos a serem utilizados

12 3.3 Análise dos resultados RESULTADOS E DISCUSSÕES Fluxo (Flow) Passo Step Massa de Dados Variações Proposta Mapeamento Execução CONCLUSÃO REFERÊNCIAS

13 12 1 INTRODUÇÃO Em termos de qualidade de sofware, uma das vertentes essenciais é a parte de testes de software. Um componente fundamental para qualquer empresa que deseja obter certificações de qualidade e garantir a excelência de seus produtos e é nesta linha de pesquisa que este trabalho está baseado. O foco principal é o uso de testes automatizados, a forma como eles podem ser implementados e seus benefícios. A ideia é estudar uma forma de aplicar BDD 1 em Testes Automatizados, e então, verificar os benefícios deste que sobrepõe os Testes Automatizados sem BDD e testes manuais. 1.1 JUSTIFICATIVA Esta solução nos permite uma maior cobertura de qualidade em nossos sistemas, garantindo uma confiança que a automação de testes nos fornece e que a aplicação de testes manuais não pode nos garantir. A implementação de uma linguagem de alto nível onde o próprio analista de testes pode desenvolver os testes automatizados é uma inovação que acarreta em uma maior facilidade na implementação dos testes e permite que qualquer pessoa, mesmo que não conheça programação, possa gerar estes artefatos. 1.2 OBJETIVOS Objetivo geral Compreender os requisitos necessários para desenvolver um ambiente de testes de interface automatizados em linguagem de alto nível voltado para os testes de software da empresa X Objetivos específicos a) Introdução ao BDD, seus benefícios e vantagens no processo de desenvolvimento. b) Estudo de ferramentas para BDD (como Cucumber, JBehave que utilizam o padrão Gherkin), visando evoluir a ferramenta SPW-Selenium. 1 Behavior Driven Development, ou Desenvolvimento Orientado a Comportamento. É o nome que se dá ao processo/metodologia de desenvolvimento de software que consiste em especificar requisitos utilizando dados reais.

14 Capítulo 1. INTRODUÇÃO 13 c) Desenvolver uma proposta, com base nesses estudos, de uma meta linguagem onde o analista de testes seja capaz de implementar testes automatizados utilizando um padrão de linguagem de fácil compreensão orientado ao BDD. 1.3 ESTRUTURA DO TRABALHO Este trabalho está estruturado da seguinte forma: Definição de justificativa do projeto, objetivo geral e objetivos específicos; Estudo com base na metodologia adotada acerca de ferramentas, padrões e demais ítens já existentes; Resultado e proposta da pesquisa com base nos estudos realizados; Conclusão obtida após a etapa de implementação.

15 14 2 REVISÃO DA LITERATURA 2.1 BEHAVIOR DRIVEN DEVELOPMENT (BDD) O BDD surgiu como forma de mitigar possíveis erros de especificação de um sistema ainda na fase de concepção. Figura 1 Problemas na fase de criação de um projeto Fonte: Blasko (2014) Conforme ilustra a figura 1, problemas de comunicação estão presentes desde o início do projeto, ainda na fase de planejamento. O BDD trata da especificação de requisitos por comportamento, isto é, definimos os requisitos de forma a prever possíveis erros de especificação antes da etapa de implementação. Segundo (CHELIMSKY et al., 2010), a maioria dos softwares escritos nunca são de fato realmente utilizados. A razão disto é que quem produz o software não é muito bom em dar ao cliente o que ele realmente quer. Por conta dos defeitos nos processos de desenvolvimento os programas estão, atualmente, trabalhando contra quem os desenvolveu. Nós acreditamos que a maioria dos problemas encarados pelas equipes de desenvolvimento de software são problemas de comunicação. O BDD tem como objetivo ajudar comunicação, simplificando a linguagem que utilizamos

16 Capítulo 2. REVISÃO DA LITERATURA 15 para descrever cenários em que o software será usado: Given (Dado) algum contexto, When (Quando) algum evento ocorre, Then (Então) eu espero algum resultado. (CHELIMSKY et al., 2010, p. 24) Apesar de o BDD ter surgido como uma simples reformulação do TDD 1, ele acabou se tornando uma metodologia completa que segue suas próprias determinações. Segundo Adzic (2011), para que se construa um software com sucesso, devemos nos certificar de que estamos trabalhando com os seguintes passos: Assegurar-se que as partes interessadas e a equipe de desenvolvimento tenham o mesmo entendimento do que deve ser entregue; Especificações claras, para que a equipe de desenvolvimento evite desperdício e retrabalho causados por ambiguidade e lacunas nas funcionalidades; Um objetivo significa medir quando uma parte do trabalho está completa; Documentação para facilitar mudanças, tanto em termos de recursos do software como na estrutura da equipe. Segundo (CHELIMSKY et al., 2010) o BDD trata-se do desenvolvimento de uma aplicação através de seu comportamento, a partir da perspetiva de seus stakeholders 2. Ainda segundo o autor o BDD implica em uma série de outras medidas. Primeiro ele sugere que é necessário entender o mundo de acordo com o ponto de vista dos stakeholders, se a intenção for entregar algo utilizável. É preciso entender seu domínio, os desafios e as oportunidades que eles enfrentam e até mesmo as palavras utilizadas para descrever o comportamento da aplicação. Além disso, os stakeholders não devem ser vistos como uma única entidade, não limitando-se ao usuário final ou alguém que paga pelo produto. Eles são toda e qualquer parte interessada no projeto. Para chegar a um produto que tenha algum valor para o cliente, o autor descreve três princípios do BDD. Sendo eles: a) O suficiente já é o bastante: Não se deve desenvolver menos do que o necessário para começar, mas desenvolver mais do que o que foi explicitado é um desperdício de esforço. Isto também serve para automação de processos. Não se deve automatizar tudo. 1 Test-Driven Development é uma prática de desenvolvimento que consiste em escrever o código de testes antes de escrever o código a ser testado. No início é escrito um pequeno trecho de código de testes para um código que ainda não existe. Ao rodar, obviamente este teste irá falhar. O que deve ser feito na sequência é desenvolver o código necessário para que este teste passe. 2 Partes interessadas no projeto. Podendo se tratar do cliente, usuário, etc.

17 Capítulo 2. REVISÃO DA LITERATURA 16 b) Entregar algo de valor aos stakeholders: Se o que está sendo feito não tem ou não aumenta a capacidade de agregar valor, pare de fazer isso e faça outra coisa. c) É tudo comportamento: Seja a nível de código, documentação, etc. Podemos usar a mesma forma de pensar e as mesmas construções linguisticas para descrever um determinado comportamento em qualquer nível de granularidade do sistema. Segundo Pufal e Vieira (2014), o BDD torna uma equipe muito mais eficaz no que diz respeito a comunicação. Independente da sua função, cada membro da equipe pode contribuir na clareza com que uma funcionalidade é descrita. Figura 2 Relação entre exemplos, requisitos e testes Fonte: Pufal e Vieira (2014) A figura 2 mostra o quanto o uso de exemplos é importante no processo de desenvolvimento de software. Nela é possível verificar que a partir dos exemplos é possivel elaborar os requisitos, e estes mesmos exemplos podem se tornar testes que verificam estes requisitos Ciclo de entrega O ciclo de entrega começa com um analista de negócios discutindo os requisitos funcionais do software com um stakeholder. Estes requisitos podem ser problemas que eles enfrentam ou idéias que eles tiveram. O papel do analista é auxiliar o stakeholder a articular estas exigências em termos de domínio que façam sentido para para o stakeholder e para o analista, e que possam ser quebrados em partes verificáveis que são chamadas de Estórias. (CHELIMSKY et al., 2010).

18 Capítulo 2. REVISÃO DA LITERATURA 17 Em seguida o analista de negócios deve se reunir com o analista de testes para gerar as especificações, ou cenários da aplicação. Enquanto o analista de negócios pensa em termos abstratos como "Deve ser possível retirar dinheiro da conta corrente", o analista de testes pensa em termos mais concretos como: "Se eu tiver 100,00 reais em uma conta e eu retirar 80,00 reais, o que acontece?" e "E se eu tentar retirar 120,00 reais?" O que é uma Estória? Ainda segundo Chelimsky et al. (2010) a anatomia de uma estória consiste em três etapas: Um título: Para que se saiba de qual estória estamos falando. Uma narrativa: Descreve do que se trata a estória, isto é, qual seu objetivo. Esta seção deve conter o stakeholder envolvido, uma descrição do recurso a ser entregue e o benefício esperado por ele. Existem formatos comuns para isto, como o Connextra: "como [parte interessada], Eu quero [recurso], para que [benefício]". Critérios de aceitação: Para termos o conceito de "pronto". No BDD os critérios de aceitação são descritos como cenários compostos por passos O que é um Cenário? Cada cenário possui um título, como por exemplo: "Ao tentar sacar um valor maior que o permitido na conta corrente". Além disso, o cenário possui a estrutura Given (um estado com algum dado conhecido), When (um comportamento a partir dos dados previstos) e Then (um resultado esperado). Segundo Adzic (2011), uma vez que as especificações de testes estejam perfeitamente claras, não é necessário o uso de outro tipo de documentação para desenvolver um sistema. Este é um dos benefícios a longo prazo de especificar com o uso de exemplos. 2.2 INTRODUÇÃO A TESTES DE SOFTWARE Segundo Pressman (2011), testes são conjuntos de atividades que podem ser planejadas e então executadas sistematicamente. Ainda segundo o autor, as estratégias de testes de software devem contemplar tanto testes de baixo nível que podem verificar, por exemplo, se pequenos trechos de código foram implementados corretamente, como testes de alto nível que verificam as principais funções do sistemas de acordo com os requisitos determinados pelo cliente.

19 Capítulo 2. REVISÃO DA LITERATURA 18 "Não seja tolo e não considere o teste como uma "rede de segurança"que detectará todos os erros ocorridos devido a práticas deficientes de engenharia de software. Isto não acontecerá. Enfatize a qualidade e a detecção de erro em todo o processo de software."(pressman, 2011, p. 402) Existe um tipo específico de teste para cada camada de processo de um sistema, conforme ilustra a figura 3. Figura 3 Testes de software x Camadas no processo de software Fonte: Pressman (2011) De acordo com este modelo, temos os seguintes tipos de testes: Teste de Unidade Fica no centro da espiral e se concentra em cada unidade do sistema implementado a nível de código fonte sendo, por exemplo, um componente, uma classe, um objeto, etc. Este tipo de teste normalmente é considerado um auxiliar na etapa de codificação, podendo ser escrito antes do código fonte ter sido gerado (TDD) ou depois. O teste de unidade foca em cada componente do sistema individualmente. (PRESSMAN, 2011). Teste de Integração O foco fica na construção da arquitetura do sistema. Mesmo que os testes unitários funcionem individualmente, o teste de integração se faz necessário pois ao integrar estes componentes problemas poderão surgir. Um componente pode ter um efeito inesperado sobre o outro, e quando combinados podem não produzir uma função principal desejada. Quando um programa inteiro é testado como um todo, é normal que o resultado seja um caos. (PRESSMAN, 2011). Teste de Validação Este teste começa quando terminam os testes de integração. No teste de validação, os requisitos estabelecidos são validados em relação ao software criado. Ele garante que o software

20 Capítulo 2. REVISÃO DA LITERATURA 19 satisfaz a todos os requisitos, sejam eles funcionais, de desempenho ou comportamentais. Uma definição simples deste tipo de teste é que ele é satisfatório quando o software funciona de uma maneira que pode ser razoavelmente esperada pelo cliente, de acordo com os critérios de validação estabelecidos. (PRESSMAN, 2011). Teste de Sistema Nos testes de sistema, o software e outros elementos relacionados são testados como um todo. Estes elementos relacionados podem ser outros sistemas, pessoas, hardware, base de dados, etc. Sua finalidade é exercitar o sistema como um todo com uma série de diferentes tipos de testes. (PRESSMAN, 2011). Teste de Regressão Esta é uma estratégia de testes que faz parte dos testes de integração mas que vale ressaltar. Cada vez que um novo módulo do sistema é adicionado, o software muda. Podem haver novas entradas e saídas e alterações nas regras de controle. Isto pode acarretar problemas em funções que antes funcionavam. Neste contexto, o teste de regressão é a reexecução do mesmo subconjunto de testes que já foram executados para garantir que o que foi feito e que fuincionava não tenha sofrido efeitos colaterais indesejados. (PRESSMAN, 2011). Os testes possuem uma visão interna e externa, que podem ser definidos como testes de caixa preta e testes de caixa branca Testes de caixa preta São os testes realizados na interface do sistema. De acordo com Pressman (2011) o teste de caixa preta não se preocupa com a estrutura lógica interna do software. Ele foca nos requisitos funcionais do sistema e com este tipo de teste é possível identificar erros em várias categorias do sistema como na parte de interface, acesso a bases externas, erros de comportamento ou desempenho, e erros de inicialização e término. Segundo o autor, o teste de caixa preta não é uma alternativa ao de caixa branca, mas sim possibilita descobrir uma classe diferente de possíveis erros Testes de caixa branca Este tipo de teste abrange a aplicação a nível de componentes para gerar casos de teste. Testes de caixa branca garantem que os casos de testes exercitem todas as decisões lógicas nos estados de verdadeiro e falso nos componentes do sistema, por meio de suas estruturas de dados internas a nível de código.

21 Capítulo 2. REVISÃO DA LITERATURA GHERKIN Segundo o Wynne e Hellesoy (2014) o Gherkin trata-se de um padrão de linguagem BDD. Ele é uma técnica que permite o uso de exemplos concretos para a ilustrar o que o software deve fazer. Usando estes exemplos (dados) reais para descrever o comportamento do sistema, é possível alcançar uma linguagem e terminologia que faz sentido para todos os stakeholders. Eles serão capazes de entender e imaginar-se usando o sistema, o que garante um feedback mais rápido. O Gherkin fornece uma estrutura para documentação baseada em exemplos comportamentais de um sistema que é exatamente o que os stakeholders procuram, por ser um padrão de fácil entendimento. Ainda segundo Wynne e Hellesoy (2014) apesar de em alguns casos ser chamado de uma linguagem de programação, o principal objetivo deste projeto é facilitar o entendimento e a leitura humana. Ou seja, é possível escrever testes automatizados e que ao mesmo tempo podem ser usados como documentação. Abaixo (figura 4) temos um exemplo de uma estrutura comportamental de um sistema que utiliza-se do padrão Gherkin: Figura 4 Exemplo de implementação do Gherkin Fonte: Wynne e Hellesoy (2014) Keywords Um arquivo no padrão Gherkin possui uma série de palavras-chave (Keywords) reservadas. Existe um conjunto equivalente destas palavras-chave (Keywords) especiais para cada idioma

22 Capítulo 2. REVISÃO DA LITERATURA 21 suportado. (WYNNE; HELLESOY, 2014) Algumas delas no inglês são: Feature; Background; Scenario; Given; When; Then; And; But; *; Scenario Outline; Examples; Alguns dos mais relevantes serão citados a seguir: Scenario A palavra-chave Scenario trata-se do comportamento que se espera do sistema. Cada recurso (feature) possui um conjunto de cenários (Scenario) e cada cenário é um exemplo concreto de como o sistema deve se comportar em uma situação específica. (WYNNE; HELLESOY, 2014) Given, When, Then e Asterísco (*) Segundo Wynne e Hellesoy (2014), as palavras-chave (Keywords) Given, When e Then são três partes diferentes de um cenário de testes. O Asterísco serve para tornar o texto menos verboso. Sua utilização substitui Given, When e Then.

23 Capítulo 2. REVISÃO DA LITERATURA 22 Figura 5 Exemplo de implementação de um cenário de testes em Gherkin Fonte: Wynne e Hellesoy (2014) Examples Às vezes é necessário rodar um cenário múltiplas vezes alternando parâmetros. Por exemplo: Um cenário onde é necessário validar uma lista de dados, um dado por vez. Desta forma é preciso executar o cenário mais de uma vez, apenas alterando os valores de validação para cada vez que o cenário é rodado. A palavra-chave Examples funciona como um laço de repetição. (JBEHAVE.ORG., 2014). Figura 6 Exemplo de implementação de uma tabela com uso de Examples com Gherkin Fonte: JBehave.Org. (2014) 2.4 TESTES AUTOMATIZADOS De acordo com Fewster e Graham (1999), a automação de testes pode reduzir significativamente o esforço necessário para a adequação de testes, bem como aumentar o número de testes que podem ser executados em um tempo limite. Testes que levam horas sendo executados manualmente podem levar uns poucos minutos para serem executados de forma automática. Testes automatizados são repetitivos, eles usam exatamente os mesmo dados de entrada sempre que executados (o que não pode ser garantido em testes manuais). Além disso eles permitem que mesmo as menores manutenções feitas sejam testadas exaustivamente com um mínimo de tempo e esforço.

24 Capítulo 2. REVISÃO DA LITERATURA 23 Uma vez implementado, o teste automatizado é geralmente muito mais econômico. O custo de se rodar um teste automatizado é uma mera fração se comparado ao esforço de se executar o mesmo teste manualmente. Ainda segundo os autores, mesmo assim o custo de se criar e de dar manutenção a testes automatizados é maior em relação aos testes manuais. Segundo Adzic (2011), é trivial que os testes automatizados precisem de atualizações frequentes, eles podem ser executados repetitivamente e os testes que falham, obviamente, não mais estão em sincronia com o código subjacente. A menos que os testes em questão sejam projetados de forma a serem de fácil modificação, alterá-los de acordo com as mudanças do sistema pode levar um bom tempo. Uma das armadilhas deste processo é que este efeito, por vezes, é negligenciado. Ainda segundo o autor, as equipes que focam em desenvolver testes, por vezes, deixam de desenvolver testes de fácil manutenção. Com o tempo, os problemas que isto acarreta forçam estas equipes a procurar outras formas de especificar e automatizar testes que sejam fáceis de atualizar. Conforme citado em Selenium.org (2014), a automação de testes possui vantagens específicas para melhorar a eficiência a longo prazo de processos de desenvolvimento e de testes de uma equipe de software. Dentre algumas destas vantagens, pode-se levantar: Testes de regressão frequentes; Feedback rápido para os desenvolvedores; Iterações ilimitadas de execução de casos de teste; Suporte para metodologias ágeis (Agile); Documentação de casos de teste mais "disciplinada"; Relatórios de erros personalizados; Encontrar defeitos não detectados por testes manuais. Segundo Selenium.org (2014), não é sempre que devemos automatizar casos de teste. Por vezes, testes manuais são mais apropriados, como, por exemplo em sistemas onde a interface tenha a tendência de mudar num futuro próximo, ou seja, aplicações com um constante versionamento. Isto, no caso de testes automatizados, iria exigir revisão e adequação, tanto na documentação dos testes, quanto na codificação dos mesmos. Em determinadas situações, devido ao fato de que conceber testes automatizados leva um tempo maior, o próprio prazo do projeto inviabiliza a automação. Para o curto prazo, o teste manual pode ser mais eficaz.

25 Capítulo 2. REVISÃO DA LITERATURA 24 A figura 7 toma como exemplo um projeto da empresa X que já possui testes automatizados, mas que sofre constantes alterações: Figura 7 Investimento do tempo em automação (de setembro a novembro de 2013) Fonte: Próprio Autor Nela é possível perceber o tempo necessário para desenvolver e dar manutenção em testes automatizados. Segundo Adzic (2011) em casos como este em que há alterações contínuas de versão do sistema e da base, o ideal é que se mantenha uma única pessoa encarregada de efetuar estas manutenções evolutivas. Ou seja, dividir a equipe entre quem irá efetuar a manutenção dos scripts já desenvolvidos para um único indivíduo e quem irá planejar/desenvolver para o futuro imediato. Reescrever e automatizar testes funcionais usando uma ferramenta nova leva tempo. Enquanto novas validações do sistema surgem e crescem, quaisquer testes existentes devem ser mantidos e atualizados. Uma boa maneira de resolver este problema, é delegar este tipo de tarefa para uma única pessoa encarregada por manutenções evolutivas enquanto o restante da equipe planeja o futuro imediato. (ADZIC, 2011, p. 48) 2.5 TESTES FUNCIONAIS DE INTERFACE COM SELENIUM O teste funcional via interface faz parte dos testes de caixa preta. Ele interage com a interface do usuário, testando as funcionalidades do sistema. Este tipo de teste geralmente abrange os testes de sistema. Para automatizar este tipo de teste, existem algumas ferramentas de mercado que permitem interagir com a interface do usuário. Este trabalho irá focar na ferramenta Selenium.

26 Capítulo 2. REVISÃO DA LITERATURA Selenium Framework A maioria das aplicações desenvolvidas atualmente são voltadas para web. Por conseguinte elas dependem de um navegador de internet para rodarem. A forma de testar estas aplicações varia de acordo com cada empresa, e quanto mais for possível aplicar estes testes de forma ágil, melhor. (SELENIUM.ORG, 2014). Automação de testes tem, cada vez com mais freqüência, se tornado um requisito para o desenvolvimento de softwares. A ferramenta Selenium nos permite interagir com o browser por meio do web driver tornando possível a automação de processos. Conforme descreve a documentação em Selenium.org (2014), o selenium surgiu pela primeira vez em 2004, quando Jason Huggins estava testando um aplicativo interno na empresa ThoughWorks. Ele percebeu que havia um uso melhor do seu tempo do que enfrentar os mesmos passos para executar os mesmos testes manualmente para cada alteração feita. Ele começou desenvolvendo uma biblioteca em Javascript capaz de conduzir interações com a página, permitindo executar novamente testes com vários navegadores. Esta biblioteca tornou-se o Selenium Core, que posteriormente trouxe todas as funcionalidades do Selenium Remote Controle (RC) e do Selenium IDE. O Selenium RC foi inovador ao permitir o que nenhum outro produto fazia até então: controlar o navegador a partir de qualquer linguagem de sua escolha Selenium 2 (Selenium WebDriver) A maior mudança no Selenium recentemente tem sido a inclusão da API WebDriver. Controlar um navegador de forma nativa como um usuário faria localmente ou em um computador remoto (com o uso do Selenium Server) foi um salto a frente em termos de automação com o uso de browser. (SELENIUM.ORG, 2014). WebDriver é o nome como é chamada a interface onde os testes serão rodados em determinada linguagem. Alguns dos navegadores suportados pela ferramenta são: Android Web Driver; Chrome Web Driver; FireFox Web Driver; Internet Explorer Web Driver; A figura 8 mostra um exemplo de configuração de um WebDriver FireFox em Java:

27 Capítulo 2. REVISÃO DA LITERATURA 26 Figura 8 Exemplo de uso de um WebDriver com FireFox Fonte: Próprio Autor Conforme mostrado no código, na linha 8 é instanciado o WebDriver. Nisso, abrirá a janela do navegador aguardando a URL 3 de navegação. Na linha 9 é feita a navegação para a URL especificada. Então, nas demais linhas são mapeados os elementos na tela com que se deseja interagir. Neste caso um campo de pesquisa mapeado para um WebElement (uma abstração de um elemento html) e é preenchido com o texto "Selenium", e um botão para submeter (também mapeado em um WebElement) é clicado Selenium RC Selenium Remote Control é uma ferramenta de testes que permite desenvolver testes automatizados de interface do usuário em qualquer WebSite HTTP 4 com qualquer browser com suporte para JavaScript. (SELENIUM.ORG, 2014). O Selenium RC vem em duas partes: Um serviço que, automaticamente, inicia e "mata"browsers e funciona como um proxy HTTP para requisições web feitas a partir dele.; 3 Uniform Resource Locator: sequência de caracteres que engloba o protocolo, o nome do computador (o servidor), a(s) pasta(s) e o nome do ficheiro HTML, formando uma direção única na internet.(wiktionary.org, 2014) 4 HyperText Transport Protocol ou Protocolo para o transporte de hipertexto, é o protocolo usado nas transmissões dos ficheiros HTML usados na Web (WIKTIONARY.ORG, 2014)

28 Capítulo 2. REVISÃO DA LITERATURA 27 Bibliotecas que dão suporte para o desenvolvimento em várias linguagens. A figura 9 ilustra sua arquitetura de uma forma simplificada: Figura 9 Arquitetura do Selenium RC com alguns navegadores de exemplo Fonte: Selenium.org (2014) Para esclarecer melhor, ainda segundo Selenium.org (2014), o Selenium RC, basicamente, recebe comandos do Selenium a partir de um projeto de testes (desenvolvido em uma determinada linguagem que fica a critério do desenvolvedor), interpreta-os e reporta para o projeto os resultados desses testes. O servidor RC agrupa o Selenium Core e o "injeta"no browser. O Selenium Core é um conjunto de funções JavaScript que interpreta e executa comandos do Selenium no navegador. O Servidor RC recebe os comandos do Selenium do programa de testes utilizando uma simples requisição HTTP. Ou seja, é possível desenvolver estes testes automatizados via

29 Capítulo 2. REVISÃO DA LITERATURA 28 navegador em qualquer linguagem que tenha suporte para enviar solicitações via HTTP Selenium IDE Antes de mais nada, vale ressaltar que o Selenium IDE não faz parte do escopo deste projeto. Trata-se de uma ferramenta mais robusta do Selenium, que não envolve codificação. É um ambiente de desenvolvimento integrado para os Scripts do Selenium. Ele é implementado como uma extensão do Firefox, e permite gravar, editar e depurar testes. Esta ferramenta implementa o Selenium Core permitindo ao usuário gravar e reproduzir os testes em tempo real. (SELENIUM.ORG, 2014). Ainda assim, o Selenium IDE não é apenas uma ferramenta de gravação de testes, ele é uma IDE completa. O usuário pode escolher utilizar sua ferramenta de gravação ou pode, também, editar os scripts na mão. Esta IDE também possui o recurso de autocomplete. (SELENIUM.ORG, 2014) Figura 10 Selenium IDE - Exemplo de busca no google Fonte: Selenium.org (2014)

30 Capítulo 2. REVISÃO DA LITERATURA Selenium Grid Segundo o Selenium.org (2014), o Selenium Grid permite ao usuário executar os testes em diversas máquinas diferentes em diferentes navegadores em paralelo. Ou seja, uma máquina funciona como Hub 5 (que recebe um sinal do Selenium Server) e envia para suas máquinas Nodos 6 (nós na máquina Hub que irão executar estes testes). Desta forma é possível os testes rodarem em threads (paralelamente). Isto permite que os testes sejam rodados em um ambiente distribuído (várias máquinas simulando vários usuários) TestNG Segundo a documentação do TestNG.org (2014), o TestNG é um framework de testes projetado para simplificar uma ampla gama de necessidades de testes e pode ser aplicado em testes unitários e até mesmo em testes de integração. Basicamente, os testes são desenvolvidos em linguagem de programação contendo as anotações do TestNG. Logo após, estes testes são informados em um arquivo XML 7 (o testng.xml), e então, eles são rodados. Após os testes serem executados, o TestNG gera um relatório em html contendo o resultado destas execuções Page Object Segundo Selenium.org (2014) o Page Object é um padrão de projeto muito popular na automação de testes. Seu intuito é o de simplificar a manutenção dos testes e reduzir ao máximo a replicação de código. Um Page Object é uma classe que segue os princípios da orientação a objetos e serve como uma interface que irá mapear uma página html. Os passos dos testes interagem com esse objeto sempre que for necessário acessar os atributos daquela determinada página html. A vantagem de se trabalhar com Page Objects é que o domínio da regra de negócio é separado da página em si. Ou seja, sempre que uma tela sofrer alterações, o que deve ser adequado à estas mudanças são os Page Objects e não os códigos de testes. O padrão de projeto Page Object oferece as seguintes vantagens: 1 - Há uma separação clara entre o código de testes e o código específico de páginas, como localizadores e layout. 2 - Há um repositório único para os serviços e operações fornecidos por cada 5 O hub recebe um teste a ser executado junto com a informação de qual navegador e "plataforma"(ou seja, Windows, Linux, etc), onde o teste deve ser executado. Ele "sabe"a configuração de cada nó que foi "registrado"para o hub. Usando essa informação ele seleciona um nó disponível para rodar o teste no navegador solicitado. (SELENIUM.ORG, 2014) 6 O nodo dispara o browser e executa os comandos selenium.(selenium.org, 2014) 7 Extensible Markup Language

31 Capítulo 2. REVISÃO DA LITERATURA 30 página, evitando que estas regras fiquei espalhadas pelo código de testes. (SELENIUM.ORG, 2014) No java, o selenium fornece Annotations que facilitam o mapeamento dos dados da página, conforme pode ser visto no exemplo a seguir: Figura 11 Exemplo de implementação de um Page Object Fonte: Próprio Autor 2.6 JBEHAVE FRAMEWORK Jbehave é um framework para BDD, ele torna possível trabalhar com scripts BDD em nível de código, com o auxilio de anotações. Segundo Zeferino (2010), a ideia principal do BDD é trazer a facilidade na comunicação acerca dos requisitos entre responsáveis pelo negócio (analistas de negócio, patrocinadores, etc.) e o time de desenvolvimento. Segundo a JBehave.Org. (2014), pode-se dividir a implementação em duas importantes etapas: Escrever uma estória O BDD encoraja o desenvolvedor a definir estórias via cenários que expressam o comportamento desejado em um formato textual. Um exemplo pode ser visto nas figuras 4 e 5. Uma estória é uma coleção de cenários, cada uma detalhando diferentes exemplos do comportamento de um dado incremento de funcionalidade do sistema. (JBEHAVE.ORG., 2014) Mapear os passos para o Java Nesta etapa o desenvolvedor só precisa implementar os métodos fornecendo as keywords via anotação. Estas anotações devem corresponder aos padrões de expressão regular dos passos

32 Capítulo 2. REVISÃO DA LITERATURA 31 textuais. (JBEHAVE.ORG., 2014). Abaixo, segue um exemplo de implementação dos passos em linguagem Java: Figura 12 Exemplo de implementação do JBehave em linguagem Java Fonte: JBehave.Org. (2014) 2.7 CUCUMBER FRAMEWORK O cucumber, assim como o JBehave, é uma ferramenta para execução de Scripts de texto simples e funcionais no formato de testes automatizados. (CUCUMBER.ORG, 2014). Ainda segundo Cucumber.Org (2014), apesar de o Cucumber ser visto como uma ferramenta de testes, sua intenção é a de dar suporte ao BDD. Isto significa que os "testes"são escritos antes do código ser desenvolvido e são verificados por analistas de negócios, analistas de requisitos e outras partes interessadas que não tenham ou não precisem de conhecimento técnico de implementação. O código de produção então, é escrito de fora para dentro, de forma a fazer com que as estórias passem sem erros. Abaixo (figura 13) segue um exemplo de implementação do Cucumber:

33 Capítulo 2. REVISÃO DA LITERATURA 32 Figura 13 Exemplo de implementação textual de uma lista utilizando o padrão Gherkin Fonte: Cucumber.Org (2014) No passo acima foram especificados os dados que devem preencher uma lista de vegetais. Figura 14 Classe modelo para a lista especificada na feature da figura 13 Fonte: Cucumber.Org (2014) Na classe java acima foram especificados os atributos que definem o que foi especificado na feature. Estes atributos são um conjunto que faz parte de um objeto Vegetal. Figura 15 Exemplo de implementação do JBehave em linguagem Java Fonte: Cucumber.Org (2014) Acima é mostrada a implementação para a feature, nela é especificada a que corresponde ao elemento textual da feature. O método em questão espera uma lista de Vegetais como parâmetro. Na feature esta lista é definida com o uso de uma barra vertical onde a primeira linha equivale aos atributos da classe Vegetable e as demais linhas equivalem às variações da lista de Vegetais.

34 33 3 PROCEDIMENTOS METODOLÓGICOS Este trabalho foi baseado em três fases: Figura 16 Etapas de metodologia Fonte: Próprio Autor 3.1 LEVANTAMENTO BIBLIOGRÁFICO Nesta etapa serão levantados os estudos com base em ferramentas já existentes e em materiais bibliográficos relacionados ao BDD. Segundo Martins e Theophilo (2009), quanto à pesquisa bibliográfica, temos como definição: Trata-se de estratégia de pesquisa necessária para a condução de qualquer pesquisa científica. Uma pesquisa bibliográfica procura explicar e discutir um assunto, tema ou

35 Capítulo 3. PROCEDIMENTOS METODOLÓGICOS 34 problema com base em referências publicadas em livros, periódicos, revistas, enciclopédias, dicionários, jornais, sites, CDs, anais de congressos etc. Busca conhecer, analisar e explicar contribuições sobre determinado assunto, tema ou problema. (MARTINS; THEOPHILO, 2009, p. 54) Este estudo visa conciliar conceitos sobe o Behavior Driven Development (BDD) com automação de testes funcionais e de interface. Para tanto é necessário estudar conceitos e padrões de desenvolvimento orientados a comportamento e como adequá-los a testes funcionais. Também serão abordadas as demais ferramentas utilizadas no projeto, tais como: TestNG; Selenium; 3.2 DEFINIÇÃO DOS RECURSOS A SEREM UTILIZADOS Através de uma abordagem de pesquisa qualitativa com base em Estudo de Caso, nesta etapa serão utilizados os dados coletados na pesquisa bibliográfica e será desenvolvido um estudo acerca do que foi abordado. O objetivo disto é avaliar, dentre as ferramentas possíveis, quais e como serão utilizadas para o desenvolvimento deste trabalho. É necessário fazer esta mineração uma vez que trata-se da evolução de uma ferramenta já existente, e que pode estar "engessada"em determinados aspectos que impossibilitam o uso de outras ferramentas que possam afetar sua arquitetura original. Segundo (MARTINS; THEOPHILO, 2009, p. 54), quando à pesquisa de Estudo de Caso, temos: O sucesso de um Estudo de Caso, em muito, depende da perseverança, criatividade e raciocínio crítico do investigador para construir descrições, interpretações, enfim, explicações originais que possibilitem a extração cuidadosa de conclusões e recomendações. Neste sentido, o pesquisador deve apresentar encadeamentos de evidências e testes de triangulação de dados que orientam a busca dos resultados alcançados. (MARTINS; THEOPHILO, 2009, p. 63) É nesta fase onde inicia-se a etapa de implementação da proposta e é nela em que a maioria dos problemas surgem. O desafio consiste em definir bem a arquitetura e as ferramentas a serem utilizadas. 3.3 ANÁLISE DOS RESULTADOS A maioria destes frameworks utiliza-se do padrão Gherkin, trabalhando com conceitos de estórias, cenários de testes e passos. O framework utilizado atualmente trabalha com o conceito

36 Capítulo 3. PROCEDIMENTOS METODOLÓGICOS 35 de Fluxos e Passos, o que torna complicado o uso de uma ferramenta de mercado que utilize Gherkin e que não vá impactar na arquitetura atual do sistema. Com base nessas conclusões, será feito o uso da mesma idéia de implementação das ferramentas encontradas, mas sem o uso do Gherkin. A idéia é trabalhar com os arquivos textuais de scripts (também chamados de features), e com as Annotations para fazer a ligação desses scripts contendo as Keywords com os passos codificados. Com isso é possível fazer uma amarração simples da nova proposta com o sistema atual sem mudar radicalmente a arquitetura do mesmo. Assim, os fluxos e os arquivos de massa de dados podem ser gerados programaticamente. Isto será melhor entendido em Resultados e Discussões.

37 36 4 RESULTADOS E DISCUSSÕES Ao decorrer de todo este tempo de pesquisa, foram feitas algumas reuniões na empresa a fim de colher informações e levantar discussões com o intuito de definir a forma como isto deve ser concebido e entender os riscos que o projeto pode vir a correr. O principal risco seria que o projeto não chegasse ao seu objetivo real que seria o de reduzir a manutenção dos testes e o tempo de implementação destes. Conforme visto na etapa de Revisão da Literatura, manutenção de testes automatizados demanda um certo tempo (ver figura 7). Com base nisso, pode-se dizer que testes automatizados de interface são mais adequados a sistemas legados. Ou seja, desenvolver testes automatizados de interface para sistemas que sofrem constante versionamento e correções de bugs pode ser um problema no que diz respeito à manutenção dos testes, uma vez que estes testes levam um bom tempo para serem implementados. O framework SPW-Selenium, inicialmente, utiliza-se de uma estrutura que obedece a seguinte arquitetura: Fluxo; Passo; Massa de Dados; Variações. 4.1 FLUXO (FLOW) O fluxo é um conjunto de execuções que um teste deve fazer. Estas execuções podem ser chamadas de passos. Desta forma, surge a seguinte estrutura: Fluxo A; Passo1; Passo2; Fluxo B; Passo1; Passo2;

38 Capítulo 4. RESULTADOS E DISCUSSÕES 37 um fluxo: Abaixo (na figura 17) segue um exemplo no código de como ficaria a implementação de Figura 17 Exemplo de implementação de um Fluxo de Teste Fonte: Próprio Autor O fluxo deve ser definido com a e, por fazer o login no portal da empresa X, deve conter o endereço da aplicação, um usuário e uma senha, bem como uma referência à massa de dados, onde são armazenados os dados do teste e suas variações. 4.2 PASSO STEP O passo executa ações (pequenas, médias ou grandes) que compõem uma funcionalidade maior (no caso o Fluxo). Um passo pode fazer parte de mais de um fluxo, sendo assim desacoplado, de forma que ele seja reutilizável em fluxos de teste que tenham funcionalidades em comum. O passo faz parte do fluxo, e deve ser instanciado no mesmo, conforme pode ser visto na figura 17. Pode-se observar a definição de uma classe que implementa um passo na figura 18.

39 Capítulo 4. RESULTADOS E DISCUSSÕES 38 Figura 18 Exemplo de implementação de um Passo de Teste Fonte: Próprio Autor Observa-se que o passo implementa três métodos distintos. São eles: checkpreconditions(), checkresults() e doexecute(). Estes métodos fazem parte da seguinte abstração: 1 - Verificar as pré-condições para que aquele caso de teste possa ser executado (checkpreconditions()); 2 - Executar o caso de teste (doexecute()); 3 - Verificar os resultados do teste executado (checkresults()); É no passo onde as regras de negócio previstas no caso de teste deverão ser validadas e é nele em que o objeto Page (vide Page Object) deverá ser manipulado, separando assim, a regra de negócio da aplicação em si. 4.3 MASSA DE DADOS Uma especificação de caso de teste da empresa X contém os dados necessários para preenchimento dos campos da tela e os dados de validação da tela. Desta forma foi criada uma abstração para a massa de dados. Esta abstração nada mais é do que um arquivo XML que contém atributos conhecidos do Fluxo e do Passo, estes atributos, por sua vez, contém seus valores, que é o que interessa ao passo. A figura 19 ilustra a forma como um arquivo XML para a Massa de Dados deve ser implementado.

40 Capítulo 4. RESULTADOS E DISCUSSÕES 39 Figura 19 Exemplo de implementação de um Passo de Teste no XML Fonte: Próprio Autor Este XML faz referência à classe Passo1, ao instanciar o passo no fluxo (ver figura 17), o XML é recuperado via reflection. Basicamente o nome definido para a classe passo deve ser o mesmo definido no id da tag step no XML, neste caso, "Passo1". 4.4 VARIAÇÕES As variações fazem parte da massa de dados. Esta é uma abstração feita com base nas especificações de casos de testes, onde um caso de teste que deve validar uma determinada funcionalidade possui variações nos valores inseridos. Desta forma, são alterados os dados, mas não a estrutura do caso de testes em si. A implementação de uma variação de caso de teste fica no mesmo arquivo XML do caso de teste base. Para isto só é necessário alterar o id do caso de teste e seus dados. 4.5 PROPOSTA Com o uso do BDD para a implementação dos testes, a classe fluxo foi "substituída"pelo Script de testes que, por sua vez, irá fazer a chamada para os passos que corresponderem às suas keywords. Como a estrutura atual trabalha com o conceito de fluxos e passos e cenários (ou suítes), ficou inviável implementar o padrão Gherkin, que trabalha com cenários de teste, não usando fluxos e passos. O modelo atual, conforme já foi abordado, obedece a seguinte arquitetura:

41 Capítulo 4. RESULTADOS E DISCUSSÕES 40 Figura 20 Arquitetura atual Fonte: Próprio Autor Conforme ilustra a figura 20, na arquitetura atual existe uma grande dependência entre fluxo, passo, massa de dados e Page Object. Sempre que necessária a reutilização de um passo (que contém a regra de negócio do teste), é preciso codificar o fluxo e montar a massa de dados. Na arquitetura proposta, é desfeito o alto acoplamento entre fluxo, passo e massa de dados. Somente é necessário codificar o passo que contenha as regras do teste, e a Page Object que fará o mapeamento da interface do usuário. Tanto o fluxo como a massa de dados são gerados programaticamente. A vantagem disso é que fica mais simples de criar novos testes que façam uso de passos já existentes, bem como o tempo de manutenção é bem menor, já que boa parte da codificação não é mais necessária. O Script de testes substitui a criação do fluxo e do arquivo XML que contém a massa de dados. A figura 21 demonstra como ficaria o processo.

42 Capítulo 4. RESULTADOS E DISCUSSÕES 41 Figura 21 Arquitetura proposta Fonte: Próprio Autor A arquitetura ficou disposta em duas principais vertentes: Mapeamento A primeira etapa será o mapeamento dos artefatos necessários para a execução. Este mapeamento é feito por meio de um DataProvider com a Como pode ser visto em TestNG.org (2014), o DataProvider funciona como um objeto de contexto, ou seja, ele é parte das pré-condições de um teste, e, portanto, ele irá ser executado antes do teste. O DataProvider irá retornar uma lista de Objects que poderão ser utilizados no contexto dos testes rodados. Neste contexto, o método DataProvider deverá: Escanear as Keywords definidas no projeto com base nas Annotations; Escanear os Scripts de linguagem textual contidos no projeto; Montar um objeto RunnableScript com base nas Keywords e nos scripts; Retornar uma lista de RunnableScripts que serão consumidos pelo teste.

43 Capítulo 4. RESULTADOS E DISCUSSÕES 42 A figura 22 mostra a implementação do DataProvider em questão. Figura 22 Implementação do DataProvider Fonte: Próprio Autor Execução É na etapa de execução que a lista de RunnableScrips deverá ser utilizada. Primeiramente será mostrado o que é um RunnableScript e os dados contidos nele. Figura 23 Implementação do RunnableScript Fonte: Próprio Autor O RunnableScript possui quatro atributos distintos. Um id, que será a identificação do caso de teste contida no script textual (Exemplo: CT01), também contém um objetivo, um caminho de arquivo e os comandos. O objetivo é o objetivo do caso de teste, que é uma descrição dele. O caminho de arquivo referencía o Script textual com as Keywords. e os comandos são uma lista de ScriptCommand. O ScriptCommand será esclarecido a na figura 24.

44 Capítulo 4. RESULTADOS E DISCUSSÕES 43 Figura 24 Implementação do ScriptCommand Fonte: Próprio Autor No ScriptCommand, estão também implementadados quatro atributos. São eles a keyword, a stepclass, o stepdataxmlpath e as variables. A keyword contém as palavras-chave (Keywords) para acionar o passo. A classe Passo correspondente a keyword está definida no atributo stepclass. Também é definido o caminho e o nome do arquivo da massa de dados, que ficam no atributo stepdataxmlpath. O atributo variables trata-se de um Map que contém as variáveis contidas no arquivo de script textual, a partir delas será montado o arquivo de massa de dados. Para cada elemento RunnableScript recuperado pelo DataProvider será executado um teste de aceitação. Ou seja, se existirem três arquivos de script, o DataProvider irá mapeá-los e o método de teste que fizer uso destes insumos obtidos pelo DataProvider será executado três vezes, uma para cada script. O método em questão, que fará uso destes dados do DataProvider encontra-se a seguir: Figura 25 Implementação da execução do Script utilizando o DataProvider Fonte: Próprio Autor É feita então uma amarração simples com a infraestrutura já utilizada até então. Como não há classes fluxo e nem arquivos XML de massa de dados previamente especificados e implementados, estes artefatos são gerados programaticamente com base nos dados do RunnableScript.

45 Capítulo 4. RESULTADOS E DISCUSSÕES 44 No passo, as keywords são definidas utilizando-se da Esta annotation possui três atributos distintos. O primeiro é a Keyword de identificação do passo (String keyword). O segundo é uma descrição do passo (String description). O terceiro é o caminho para criação do arquivo XML de massa de dados (String stepdatamassxml). A imagem abaixo mostra a definição do passo com Figura 26 Implementação do passo com o ScriptAction para definição das Keywords Fonte: Próprio Autor Abaixo segue o arquivo de scripts referente ao passo mostrado anteriormente: Figura 27 Arquivo de script referente ao passo anterior Fonte: Próprio Autor Em seguida os fluxos serão rodados e seus resultados serão reportados pelo testng.