AUTOMATIZAÇÃO DE TESTES DE INTERFACE , EM · PDF fileCURSO SUPERIOR DE TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE ... Exemplo de implementação de um Passo de Teste ... 2.2 Introdução

SERVIÇO NACIONAL DE APRENDIZAGEM INDUSTRIAL

FACULDADE DE TECNOLOGIA SENAI/SC FLORIANÓPOLIS

CURSO SUPERIOR DE TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DESISTEMAS

AUTOMATIZAÇÃO DE TESTES DE INTERFACEEM LINGUAGEM ALTO NÍVEL

MATEUS ADENIZ PEGORARO

Trabalho de Conclusão de Curso

Florianópolis/SC

2014



Trabalho de Conclusão de Curso apresentado àBanca Examinadora do Curso Superior de Tec-nologia em Análise e Desenvolvimento de Siste-mas da Faculdade de Tecnologia do SENAI Flo-rianópolis como requisito parcial para obtençãodo Grau de Tecnólogo em Análise e Desenvolvi-mento de Sistemas.Professor Orientador: João Carlos Testi Ferreira,esp..

Florianópolis/SC

2014



Trabalho de Conclusão de Curso apresentado à Banca Examinadora do Curso Superior deTecnologia 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 eDesenvolvimento 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

Dedico este trabalho à minha família que me deu forças e jamais deixou de acreditarem 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 dedicoprincipalmente ao meu orientador João Carlos Testi Ferreira, por todo o conhecimento, peladedicação e por ter me aceitado como orientando.

AGRADECIMENTOS

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

“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)

PEGORARO, Mateus. Automação de Testes de interface em Linguagem Alto Nível. Flori-anópolis, 2014. 47f. Trabalho de Conclusão de Curso Superior de Tecnologia em Análise eDesenvolvimento de Sistemas - Curso Análise e Desenvolvimento de Sistemas. Faculdade deTecnologia do SENAI, Florianópolis, 2014.

RESUMO

Este trabalho apresenta o desenvolvimento de uma ferramenta de testes de interface em umametalinguagem amistosa e inteligível para usuários que não possuam conhecimento técnico emcodificação. A vantagem é reduzir o tempo de manutenção e adequação dos testes automatizadosde interface, além de torná-los mais flexíveis.

PEGORARO, Mateus. Automação de Testes de interface em Linguagem Alto Nível. Flori-anópolis, 2014. 47f. Trabalho de Conclusão de Curso Superior de Tecnologia em Análise eDesenvolvimento de Sistemas - Curso Análise e Desenvolvimento de Sistemas. Faculdade deTecnologia do SENAI, Florianópolis, 2014.

ABSTRACT

This work presents the development of a tool in a friendly and intelligible metalanguage forusers without technical knowledge in coding. The advantage is to reduce maintenance time andsuitability of automated interface tests, and make them more flexible.

LISTA DE ILUSTRAÇÕES

Figura 1 – Problemas na fase de criação de um projeto . . . . . . . . . . . . . . . . 14Figura 2 – Relação entre exemplos, requisitos e testes . . . . . . . . . . . . . . . . 16Figura 3 – Testes de software x Camadas no processo de software . . . . . . . . . . 18Figura 4 – Exemplo de implementação do Gherkin . . . . . . . . . . . . . . . . . . 20Figura 5 – Exemplo de implementação de um cenário de testes em Gherkin . . . . 22Figura 6 – Exemplo de implementação de uma tabela com uso de Examples com

Gherkin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Figura 7 – Investimento do tempo em automação (de setembro a novembro de 2013) 24Figura 8 – Exemplo de uso de um WebDriver com FireFox . . . . . . . . . . . . . . 26Figura 9 – Arquitetura do Selenium RC com alguns navegadores de exemplo . . . 27Figura 10 – Selenium IDE - Exemplo de busca no google . . . . . . . . . . . . . . . 28Figura 11 – Exemplo de implementação de um Page Object . . . . . . . . . . . . . . 30Figura 12 – Exemplo de implementação do JBehave em linguagem Java . . . . . . . 31Figura 13 – Exemplo de implementação textual de uma lista utilizando o padrão

Gherkin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32Figura 14 – Classe modelo para a lista especificada na feature da figura 13 . . . . . 32Figura 15 – Exemplo de implementação do JBehave em linguagem Java . . . . . . . 32Figura 16 – Etapas de metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Figura 17 – Exemplo de implementação de um Fluxo de Teste . . . . . . . . . . . . 37Figura 18 – Exemplo de implementação de um Passo de Teste . . . . . . . . . . . . 38Figura 19 – Exemplo de implementação de um Passo de Teste no XML . . . . . . . 39Figura 20 – Arquitetura atual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Figura 21 – Arquitetura proposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41Figura 22 – Implementação do DataProvider . . . . . . . . . . . . . . . . . . . . . . 42Figura 23 – Implementação do RunnableScript . . . . . . . . . . . . . . . . . . . . 42Figura 24 – Implementação do ScriptCommand . . . . . . . . . . . . . . . . . . . . 43Figura 25 – Implementação da execução do Script utilizando o DataProvider . . . . 43Figura 26 – Implementação do passo com o ScriptAction para definição das Keywords 44Figura 27 – Arquivo de script referente ao passo anterior . . . . . . . . . . . . . . . 44

LISTA DE ABREVIATURAS E SIGLAS

BDD Behavior Driven Development (Desenvolvimento Orientado a Comporta-

mento).

HTML HyperText Markup Language (Linguagem de Marcação de Hipertexto).

TDD Test-Driven Development (Desenvolvimento Orientado a Testes).

URL Uniform Resource Locator (localizador de recurso uniforme).

HTTP HyperText Transport Protocol (Protocolo de transporte de hipertexto).

XML Extensible Markup Language (Linguagem de marcação extensível).

SUMÁRIO

1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.1 JUSTIFICATIVA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.2 OBJETIVOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.2.1 Objetivo geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.2.2 Objetivos específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.3 ESTRUTURA DO TRABALHO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2 REVISÃO DA LITERATURA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.1 Behavior Driven Development (BDD) . . . . . . . . . . . . . . . . . . . . . . . . . 142.1.0.1 Ciclo de entrega . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.1.0.2 O que é uma Estória? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.1.0.3 O que é um Cenário? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.2 Introdução a Testes de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.2.1 Testes de caixa preta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.2.2 Testes de caixa branca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.3 Gherkin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.3.1 Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.3.1.1 Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.3.1.2 Given, When, Then e Asterísco (*) . . . . . . . . . . . . . . . . . . . . . . . . . 212.3.1.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.4 Testes Automatizados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.5 Testes funcionais de interface com Selenium . . . . . . . . . . . . . . . . . . . . . . 242.5.1 Selenium Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.5.1.1 Selenium 2 (Selenium WebDriver) . . . . . . . . . . . . . . . . . . . . . . . . . 252.5.1.2 Selenium RC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.5.1.3 Selenium IDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.5.1.4 Selenium Grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.5.2 TestNG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.5.3 Page Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.6 JBehave framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.6.1 Escrever uma estória . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.6.2 Mapear os passos para o Java . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.7 Cucumber framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3 PROCEDIMENTOS METODOLÓGICOS . . . . . . . . . . . . . . . . . . . . . 333.1 Levantamento bibliográfico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.2 Definição dos recursos a serem utilizados . . . . . . . . . . . . . . . . . . . . . . . 34

3.3 Análise dos resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4 RESULTADOS E DISCUSSÕES . . . . . . . . . . . . . . . . . . . . . . . . . . 364.1 Fluxo (Flow) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.2 Passo Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.3 Massa de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.4 Variações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.5 Proposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.5.1 Mapeamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.5.2 Execução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

12

1 INTRODUÇÃO

Em termos de qualidade de sofware, uma das vertentes essenciais é a parte de testes desoftware. Um componente fundamental para qualquer empresa que deseja obter certificações dequalidade e garantir a excelência de seus produtos e é nesta linha de pesquisa que este trabalhoestá baseado.

O foco principal é o uso de testes automatizados, a forma como eles podem ser imple-mentados e seus benefícios.

A ideia é estudar uma forma de aplicar BDD 1 em Testes Automatizados, e então, verificaros 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, garan-tindo uma confiança que a automação de testes nos fornece e que a aplicação de testes manuaisnão pode nos garantir.

A implementação de uma linguagem de alto nível onde o próprio analista de testes podedesenvolver os testes automatizados é uma inovação que acarreta em uma maior facilidade naimplementação dos testes e permite que qualquer pessoa, mesmo que não conheça programação,possa gerar estes artefatos.

1.2 OBJETIVOS

1.2.1 Objetivo geral

Compreender os requisitos necessários para desenvolver um ambiente de testes deinterface automatizados em linguagem de alto nível voltado para os testes de software daempresa X.

1.2.2 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ãoGherkin), 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 dadosreais.

Capítulo 1. INTRODUÇÃO 13

c) Desenvolver uma proposta, com base nesses estudos, de uma meta linguagem ondeo analista de testes seja capaz de implementar testes automatizados utilizando um padrão delinguagem 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.

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 sistemaainda 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 doprojeto, ainda na fase de planejamento.

O BDD trata da especificação de requisitos por comportamento, isto é, definimos osrequisitos 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 fatorealmente utilizados. A razão disto é que quem produz o software não é muito bom em dar aocliente o que ele realmente quer. Por conta dos defeitos nos processos de desenvolvimento osprogramas estão, atualmente, trabalhando contra quem os desenvolveu.

Nós acreditamos que a maioria dos problemas encarados pelas equipes dedesenvolvimento de software são problemas de comunicação. O BDD temcomo objetivo ajudar comunicação, simplificando a linguagem que utilizamos

Capítulo 2. REVISÃO DA LITERATURA 15

para descrever cenários em que o software será usado: Given (Dado) algumcontexto, When (Quando) algum evento ocorre, Then (Então) eu espero algumresultado. (CHELIMSKY et al., 2010, p. 24)

Apesar de o BDD ter surgido como uma simples reformulação do TDD 1, ele acabou setornando uma metodologia completa que segue suas próprias determinações.

Segundo Adzic (2011), para que se construa um software com sucesso, devemos noscertificar de que estamos trabalhando com os seguintes passos:

• Assegurar-se que as partes interessadas e a equipe de desenvolvimento tenham o mesmoentendimento do que deve ser entregue;

• Especificações claras, para que a equipe de desenvolvimento evite desperdício e retrabalhocausados 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 naestrutura da equipe.

Segundo (CHELIMSKY et al., 2010) o BDD trata-se do desenvolvimento de umaaplicaçã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 dosstakeholders, se a intenção for entregar algo utilizável. É preciso entender seu domínio, osdesafios e as oportunidades que eles enfrentam e até mesmo as palavras utilizadas para descrevero comportamento da aplicação.

Além disso, os stakeholders não devem ser vistos como uma única entidade, nãolimitando-se ao usuário final ou alguém que paga pelo produto. Eles são toda e qualquer parteinteressada no projeto.

Para chegar a um produto que tenha algum valor para o cliente, o autor descreve trêsprincípios do BDD. Sendo eles:

a) O suficiente já é o bastante: Não se deve desenvolver menos do que o necessáriopara 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ódigoque ainda não existe. Ao rodar, obviamente este teste irá falhar. O que deve ser feito na sequência é desenvolvero código necessário para que este teste passe.

2 Partes interessadas no projeto. Podendo se tratar do cliente, usuário, etc.


b) Entregar algo de valor aos stakeholders: Se o que está sendo feito não tem ou nãoaumenta 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 amesma forma de pensar e as mesmas construções linguisticas para descrever um determinadocomportamento em qualquer nível de granularidade do sistema.

Segundo Pufal e Vieira (2014), o BDD torna uma equipe muito mais eficaz no que dizrespeito a comunicação. Independente da sua função, cada membro da equipe pode contribuir naclareza 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 desenvolvi-mento de software. Nela é possível verificar que a partir dos exemplos é possivel elaborar osrequisitos, e estes mesmos exemplos podem se tornar testes que verificam estes requisitos.

2.1.0.1 Ciclo de entrega

O ciclo de entrega começa com um analista de negócios discutindo os requisitos funcio-nais do software com um stakeholder. Estes requisitos podem ser problemas que eles enfrentamou idéias que eles tiveram. O papel do analista é auxiliar o stakeholder a articular estas exigênciasem termos de domínio que façam sentido para para o stakeholder e para o analista, e que possamser quebrados em partes verificáveis que são chamadas de Estórias. (CHELIMSKY et al., 2010).


Em seguida o analista de negócios deve se reunir com o analista de testes para gerar asespecificações, ou cenários da aplicação.Enquanto o analista de negócios pensa em termos abstratos como "Deve ser possível retirardinheiro da conta corrente", o analista de testes pensa em termos mais concretos como: "Se eutiver 100,00 reais em uma conta e eu retirar 80,00 reais, o que acontece?" e "E se eu tentarretirar 120,00 reais?".

2.1.0.2 O que é uma Estória?

Ainda segundo Chelimsky et al. (2010) a anatomia de uma estória consiste em trêsetapas:

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çãodeve conter o stakeholder envolvido, uma descrição do recurso a ser entregue e o benefício espe-rado 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 deaceitação são descritos como cenários compostos por passos.

2.1.0.3 O que é um Cenário?

Cada cenário possui um título, como por exemplo: "Ao tentar sacar um valor maior queo permitido na conta corrente". Além disso, o cenário possui a estrutura Given (um estado comalgum dado conhecido), When (um comportamento a partir dos dados previstos) e Then (umresultado esperado).

Segundo Adzic (2011), uma vez que as especificações de testes estejam perfeitamenteclaras, 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 planejadase então executadas sistematicamente.

Ainda segundo o autor, as estratégias de testes de software devem contemplar tantotestes de baixo nível que podem verificar, por exemplo, se pequenos trechos de código foramimplementados corretamente, como testes de alto nível que verificam as principais funções dosistemas de acordo com os requisitos determinados pelo cliente.


"Não seja tolo e não considere o teste como uma "rede de segurança"quedetectará todos os erros ocorridos devido a práticas deficientes de engenhariade software. Isto não acontecerá. Enfatize a qualidade e a detecção de erro emtodo o processo de software."(PRESSMAN, 2011, p. 402)

Existe um tipo específico de teste para cada camada de processo de um sistema, conformeilustra 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ívelde código fonte sendo, por exemplo, um componente, uma classe, um objeto, etc. Este tipo deteste normalmente é considerado um auxiliar na etapa de codificação, podendo ser escrito antesdo código fonte ter sido gerado (TDD) ou depois. O teste de unidade foca em cada componentedo sistema individualmente. (PRESSMAN, 2011).

Teste de Integração

O foco fica na construção da arquitetura do sistema. Mesmo que os testes unitários funci-onem individualmente, o teste de integração se faz necessário pois ao integrar estes componentesproblemas poderão surgir. Um componente pode ter um efeito inesperado sobre o outro, e quandocombinados 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, osrequisitos estabelecidos são validados em relação ao software criado. Ele garante que o software


satisfaz a todos os requisitos, sejam eles funcionais, de desempenho ou comportamentais. Umadefinição simples deste tipo de teste é que ele é satisfatório quando o software funciona deuma maneira que pode ser razoavelmente esperada pelo cliente, de acordo com os critérios devalidação estabelecidos. (PRESSMAN, 2011).

Teste de Sistema

Nos testes de sistema, o software e outros elementos relacionados são testados comoum todo. Estes elementos relacionados podem ser outros sistemas, pessoas, hardware, base dedados, etc. Sua finalidade é exercitar o sistema como um todo com uma série de diferentes tiposde testes. (PRESSMAN, 2011).

Teste de Regressão

Esta é uma estratégia de testes que faz parte dos testes de integração mas que valeressaltar. Cada vez que um novo módulo do sistema é adicionado, o software muda. Podem havernovas entradas e saídas e alterações nas regras de controle. Isto pode acarretar problemas emfunções que antes funcionavam. Neste contexto, o teste de regressão é a reexecução do mesmosubconjunto de testes que já foram executados para garantir que o que foi feito e que fuincionavanão tenha sofrido efeitos colaterais indesejados. (PRESSMAN, 2011).

Os testes possuem uma visão interna e externa, que podem ser definidos como testes decaixa preta e testes de caixa branca.

2.2.1 Testes de caixa preta

São os testes realizados na interface do sistema. De acordo com Pressman (2011) o testede caixa preta não se preocupa com a estrutura lógica interna do software. Ele foca nos requisitosfuncionais do sistema e com este tipo de teste é possível identificar erros em várias categoriasdo sistema como na parte de interface, acesso a bases externas, erros de comportamento oudesempenho, e erros de inicialização e término. Segundo o autor, o teste de caixa preta não é umaalternativa ao de caixa branca, mas sim possibilita descobrir uma classe diferente de possíveiserros.

2.2.2 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 nosestados de verdadeiro e falso nos componentes do sistema, por meio de suas estruturas de dadosinternas a nível de código.


2.3 GHERKIN

Segundo o Wynne e Hellesoy (2014) o Gherkin trata-se de um padrão de linguagemBDD. 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. Elesserão capazes de entender e imaginar-se usando o sistema, o que garante um feedback maisrápido.

O Gherkin fornece uma estrutura para documentação baseada em exemplos comporta-mentais de um sistema que é exatamente o que os stakeholders procuram, por ser um padrão defácil entendimento.

Ainda segundo Wynne e Hellesoy (2014) apesar de em alguns casos ser chamado deuma linguagem de programação, o principal objetivo deste projeto é facilitar o entendimentoe a leitura humana. Ou seja, é possível escrever testes automatizados e que ao mesmo tempopodem ser usados como documentação. Abaixo (figura 4) temos um exemplo de uma estruturacomportamental de um sistema que utiliza-se do padrão Gherkin:

Figura 4 – Exemplo de implementação do Gherkin

Fonte: Wynne e Hellesoy (2014)

2.3.1 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


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:

2.3.1.1 Scenario

A palavra-chave Scenario trata-se do comportamento que se espera do sistema. Cadarecurso (feature) possui um conjunto de cenários (Scenario) e cada cenário é um exemplo con-creto de como o sistema deve se comportar em uma situação específica. (WYNNE; HELLESOY,2014).

2.3.1.2 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.


Figura 5 – Exemplo de implementação de um cenário de testes em Gherkin

Fonte: Wynne e Hellesoy (2014)

2.3.1.3 Examples

Às vezes é necessário rodar um cenário múltiplas vezes alternando parâmetros. Porexemplo: Um cenário onde é necessário validar uma lista de dados, um dado por vez. Destaforma é preciso executar o cenário mais de uma vez, apenas alterando os valores de validaçãopara cada vez que o cenário é rodado. A palavra-chave Examples funciona como um laço derepetiçã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 significa-tivamente o esforço necessário para a adequação de testes, bem como aumentar o número detestes que podem ser executados em um tempo limite. Testes que levam horas sendo executadosmanualmente podem levar uns poucos minutos para serem executados de forma automática.

Testes automatizados são repetitivos, eles usam exatamente os mesmo dados de entradasempre que executados (o que não pode ser garantido em testes manuais). Além disso elespermitem que mesmo as menores manutenções feitas sejam testadas exaustivamente com ummínimo de tempo e esforço.


Uma vez implementado, o teste automatizado é geralmente muito mais econômico. Ocusto de se rodar um teste automatizado é uma mera fração se comparado ao esforço de seexecutar o mesmo teste manualmente.

Ainda segundo os autores, mesmo assim o custo de se criar e de dar manutenção a testesautomatizados é maior em relação aos testes manuais.

Segundo Adzic (2011), é trivial que os testes automatizados precisem de atualizaçõesfrequentes, eles podem ser executados repetitivamente e os testes que falham, obviamente, nãomais estão em sincronia com o código subjacente. A menos que os testes em questão sejamprojetados de forma a serem de fácil modificação, alterá-los de acordo com as mudanças dosistema pode levar um bom tempo. Uma das armadilhas deste processo é que este efeito, porvezes, é negligenciado.

Ainda segundo o autor, as equipes que focam em desenvolver testes, por vezes, deixamde desenvolver testes de fácil manutenção. Com o tempo, os problemas que isto acarreta forçamestas equipes a procurar outras formas de especificar e automatizar testes que sejam fáceis deatualizar.

Conforme citado em Selenium.org (2014), a automação de testes possui vantagensespecíficas para melhorar a eficiência a longo prazo de processos de desenvolvimento e de testesde 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 inter-face tenha a tendência de mudar num futuro próximo, ou seja, aplicações com um constanteversionamento. Isto, no caso de testes automatizados, iria exigir revisão e adequação, tanto nadocumentação dos testes, quanto na codificação dos mesmos.

Em determinadas situações, devido ao fato de que conceber testes automatizados levaum tempo maior, o próprio prazo do projeto inviabiliza a automação. Para o curto prazo, o testemanual pode ser mais eficaz.


A figura 7 toma como exemplo um projeto da empresa X que já possui testes automatiza-dos, 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 testesautomatizados. Segundo Adzic (2011) em casos como este em que há alterações contínuas deversão do sistema e da base, o ideal é que se mantenha uma única pessoa encarregada de efetuarestas manutenções evolutivas. Ou seja, dividir a equipe entre quem irá efetuar a manutenção dosscripts já desenvolvidos para um único indivíduo e quem irá planejar/desenvolver para o futuroimediato.

Reescrever e automatizar testes funcionais usando uma ferramenta nova levatempo. Enquanto novas validações do sistema surgem e crescem, quaisquertestes existentes devem ser mantidos e atualizados. Uma boa maneira de resolvereste problema, é delegar este tipo de tarefa para uma única pessoa encarregadapor manutenções evolutivas enquanto o restante da equipe planeja o futuroimediato. (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 coma interface do usuário, testando as funcionalidades do sistema. Este tipo de teste geralmenteabrange os testes de sistema.

Para automatizar este tipo de teste, existem algumas ferramentas de mercado que permi-tem interagir com a interface do usuário. Este trabalho irá focar na ferramenta Selenium.


2.5.1 Selenium Framework

A maioria das aplicações desenvolvidas atualmente são voltadas para web. Por con-seguinte elas dependem de um navegador de internet para rodarem. A forma de testar estasaplicações varia de acordo com cada empresa, e quanto mais for possível aplicar estes testes deforma ágil, melhor. (SELENIUM.ORG, 2014).

Automação de testes tem, cada vez com mais freqüência, se tornado um requisito para odesenvolvimento de softwares. A ferramenta Selenium nos permite interagir com o browser pormeio do web driver tornando possível a automação de processos.

Conforme descreve a documentação em Selenium.org (2014), o selenium surgiu pelaprimeira vez em 2004, quando Jason Huggins estava testando um aplicativo interno na empresaThoughWorks. Ele percebeu que havia um uso melhor do seu tempo do que enfrentar os mesmospassos para executar os mesmos testes manualmente para cada alteração feita.

Ele começou desenvolvendo uma biblioteca em Javascript capaz de conduzir interaçõescom a página, permitindo executar novamente testes com vários navegadores.

Esta biblioteca tornou-se o Selenium Core, que posteriormente trouxe todas as funciona-lidades do Selenium Remote Controle (RC) e do Selenium IDE. O Selenium RC foi inovador aopermitir o que nenhum outro produto fazia até então: controlar o navegador a partir de qualquerlinguagem de sua escolha.

2.5.1.1 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 computadorremoto (com o uso do Selenium Server) foi um salto a frente em termos de automação com ouso de browser. (SELENIUM.ORG, 2014).

WebDriver é o nome como é chamada a interface onde os testes serão rodados emdeterminada 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:


Figura 8 – Exemplo de uso de um WebDriver com FireFox


Conforme mostrado no código, na linha 8 é instanciado o WebDriver. Nisso, abrirá ajanela do navegador aguardando a URL3 de navegação.Na linha 9 é feita a navegação para a URL especificada. Então, nas demais linhas são mapeadosos elementos na tela com que se deseja interagir. Neste caso um campo de pesquisa mapeado paraum WebElement (uma abstração de um elemento html) e é preenchido com o texto "Selenium", eum botão para submeter (também mapeado em um WebElement) é clicado.

2.5.1.2 Selenium RC

Selenium Remote Control é uma ferramenta de testes que permite desenvolver testesautomatizados de interface do usuário em qualquer WebSite HTTP4 com qualquer browser comsuporte 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 proxyHTTP 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õesdos ficheiros HTML usados na Web (WIKTIONARY.ORG, 2014)


• 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, basica-mente, recebe comandos do Selenium a partir de um projeto de testes (desenvolvido em umadeterminada linguagem que fica a critério do desenvolvedor), interpreta-os e reporta para oprojeto os resultados desses testes.

O servidor RC agrupa o Selenium Core e o "injeta"no browser. O Selenium Core é umconjunto 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 utilizandouma simples requisição HTTP. Ou seja, é possível desenvolver estes testes automatizados via


navegador em qualquer linguagem que tenha suporte para enviar solicitações via HTTP.

2.5.1.3 Selenium IDE

Antes de mais nada, vale ressaltar que o Selenium IDE não faz parte do escopo desteprojeto.

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 é implementadocomo uma extensão do Firefox, e permite gravar, editar e depurar testes. Esta ferramentaimplementa 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)


2.5.1.4 Selenium Grid

Segundo o Selenium.org (2014), o Selenium Grid permite ao usuário executar os testesem diversas máquinas diferentes em diferentes navegadores em paralelo.

Ou seja, uma máquina funciona como Hub5 (que recebe um sinal do Selenium Server) eenvia para suas máquinas Nodos6 (nós na máquina Hub que irão executar estes testes). Destaforma é possível os testes rodarem em threads (paralelamente). Isto permite que os testes sejamrodados em um ambiente distribuído (várias máquinas simulando vários usuários).

2.5.2 TestNG

Segundo a documentação do TestNG.org (2014), o TestNG é um framework de testesprojetado para simplificar uma ampla gama de necessidades de testes e pode ser aplicado emtestes unitários e até mesmo em testes de integração.

Basicamente, os testes são desenvolvidos em linguagem de programação contendoas anotações do TestNG. Logo após, estes testes são informados em um arquivo XML7 (otestng.xml), e então, eles são rodados. Após os testes serem executados, o TestNG gera umrelatório em html contendo o resultado destas execuções.

2.5.3 Page Object

Segundo Selenium.org (2014) o Page Object é um padrão de projeto muito popular naautomação de testes. Seu intuito é o de simplificar a manutenção dos testes e reduzir ao máximoa replicação de código.

Um Page Object é uma classe que segue os princípios da orientação a objetos e servecomo uma interface que irá mapear uma página html. Os passos dos testes interagem com esseobjeto 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 seradequado à 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 depá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, Win-dows, Linux, etc), onde o teste deve ser executado. Ele "sabe"a configuração de cada nó que foi "registrado"parao 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


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 dapágina, conforme pode ser visto no exemplo a seguir:

Figura 11 – Exemplo de implementação de um Page Object


2.6 JBEHAVE FRAMEWORK

Jbehave é um framework para BDD, ele torna possível trabalhar com scripts BDD emnível de código, com o auxilio de anotações. Segundo Zeferino (2010), a ideia principal doBDD é 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 importantesetapas:

2.6.1 Escrever uma estória

O BDD encoraja o desenvolvedor a definir estórias via cenários que expressam o com-portamento 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 exem-plos do comportamento de um dado incremento de funcionalidade do sistema.(JBEHAVE.ORG., 2014)

2.6.2 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


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 textosimples e funcionais no formato de testes automatizados. (CUCUMBER.ORG, 2014).

Ainda segundo Cucumber.Org (2014), apesar de o Cucumber ser visto como uma fer-ramenta de testes, sua intenção é a de dar suporte ao BDD. Isto significa que os "testes"sãoescritos antes do código ser desenvolvido e são verificados por analistas de negócios, analistas derequisitos e outras partes interessadas que não tenham ou não precisem de conhecimento técnicode implementação. O código de produção então, é escrito de fora para dentro, de forma a fazercom que as estórias passem sem erros.

Abaixo (figura 13) segue um exemplo de implementação do Cucumber:


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


Na classe java acima foram especificados os atributos que definem o que foi especificadona 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


Acima é mostrada a implementação para a feature, nela é especificada a Annotation

@Given que corresponde ao elemento textual da feature. O método em questão espera uma listade Vegetais como parâmetro. Na feature esta lista é definida com o uso de uma barra verticalonde a primeira linha equivale aos atributos da classe Vegetable e as demais linhas equivalem àsvariações da lista de Vegetais.

33

3 PROCEDIMENTOS METODOLÓGICOS

Este trabalho foi baseado em três fases:

Figura 16 – Etapas de metodologia


3.1 LEVANTAMENTO BIBLIOGRÁFICO

Nesta etapa serão levantados os estudos com base em ferramentas já existentes e emmateriais 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 qualquerpesquisa científica.Uma pesquisa bibliográfica procura explicar e discutir um assunto, tema ou

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. Buscaconhecer, analisar e explicar contribuições sobre determinado assunto, tema ouproblema. (MARTINS; THEOPHILO, 2009, p. 54)

Este estudo visa conciliar conceitos sobe o Behavior Driven Development (BDD) comautomação de testes funcionais e de interface. Para tanto é necessário estudar conceitos e padrõesde 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, nestaetapa serão utilizados os dados coletados na pesquisa bibliográfica e será desenvolvido um estudoacerca do que foi abordado.

O objetivo disto é avaliar, dentre as ferramentas possíveis, quais e como serão utilizadaspara o desenvolvimento deste trabalho. É necessário fazer esta mineração uma vez que trata-seda evolução de uma ferramenta já existente, e que pode estar "engessada"em determinadosaspectos que impossibilitam o uso de outras ferramentas que possam afetar sua arquiteturaoriginal. Segundo (MARTINS; THEOPHILO, 2009, p. 54), quando à pesquisa de Estudo deCaso, temos:

O sucesso de um Estudo de Caso, em muito, depende da perseverança, cria-tividade e raciocínio crítico do investigador para construir descrições, inter-pretações, enfim, explicações originais que possibilitem a extração cuidadosade conclusões e recomendações. Neste sentido, o pesquisador deve apresentarencadeamentos de evidências e testes de triangulação de dados que orientam abusca 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 amaioria dos problemas surgem. O desafio consiste em definir bem a arquitetura e as ferramentasa serem utilizadas.

3.3 ANÁLISE DOS RESULTADOS

A maioria destes frameworks utiliza-se do padrão Gherkin, trabalhando com conceitos deestórias, cenários de testes e passos. O framework utilizado atualmente trabalha com o conceito

Capítulo 3. PROCEDIMENTOS METODOLÓGICOS 35

de Fluxos e Passos, o que torna complicado o uso de uma ferramenta de mercado que utilizeGherkin 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 dasferramentas encontradas, mas sem o uso do Gherkin. A idéia é trabalhar com os arquivos textuaisde scripts (também chamados de features), e com as Annotations para fazer a ligação dessesscripts contendo as Keywords com os passos codificados.

Com isso é possível fazer uma amarração simples da nova proposta com o sistema atualsem mudar radicalmente a arquitetura do mesmo. Assim, os fluxos e os arquivos de massade dados podem ser gerados programaticamente. Isto será melhor entendido em Resultados eDiscussões.

36

4 RESULTADOS E DISCUSSÕES

Ao decorrer de todo este tempo de pesquisa, foram feitas algumas reuniões na empresa afim de colher informações e levantar discussões com o intuito de definir a forma como isto deveser 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 dereduzir 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 demandaum certo tempo (ver figura 7). Com base nisso, pode-se dizer que testes automatizados deinterface são mais adequados a sistemas legados. Ou seja, desenvolver testes automatizados deinterface para sistemas que sofrem constante versionamento e correções de bugs pode ser umproblema no que diz respeito à manutenção dos testes, uma vez que estes testes levam um bomtempo para serem implementados.

O framework SPW-Selenium, inicialmente, utiliza-se de uma estrutura que obedece aseguinte 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 serchamadas de passos. Desta forma, surge a seguinte estrutura:

• Fluxo A;

– Passo1;

– Passo2;

• Fluxo B;

– Passo1;

– Passo2;

Capítulo 4. RESULTADOS E DISCUSSÕES 37

Abaixo (na figura 17) segue um exemplo no código de como ficaria a implementação deum fluxo:

Figura 17 – Exemplo de implementação de um Fluxo de Teste


O fluxo deve ser definido com a anotação @Flow e, por fazer o login no portal da empresaX, 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 funcionalidademaior (no caso o Fluxo). Um passo pode fazer parte de mais de um fluxo, sendo assim desa-coplado, de forma que ele seja reutilizável em fluxos de teste que tenham funcionalidades emcomum.

O passo faz parte do fluxo, e deve ser instanciado no mesmo, conforme pode ser visto nafigura 17. Pode-se observar a definição de uma classe que implementa um passo na figura 18.


Figura 18 – Exemplo de implementação de um Passo de Teste


Observa-se que o passo implementa três métodos distintos. São eles: checkPreConditi-

ons(), checkResults() e doExecute().

Estes métodos fazem parte da seguinte abstração: 1 - Verificar as pré-condições para queaquele 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 regrade 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 parapreenchimento dos campos da tela e os dados de validação da tela. Desta forma foi criada umaabstração para a massa de dados.

Esta abstração nada mais é do que um arquivo XML que contém atributos conhecidosdo Fluxo e do Passo, estes atributos, por sua vez, contém seus valores, que é o que interessa aopasso.A figura 19 ilustra a forma como um arquivo XML para a Massa de Dados deve ser implemen-tado.


Figura 19 – Exemplo de implementação de um Passo de Teste no XML


Este XML faz referência à classe Passo1, ao instanciar o passo no fluxo (ver figura 17), oXML é recuperado via reflection. Basicamente o nome definido para a classe passo deve ser omesmo 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 nasespecificações de casos de testes, onde um caso de teste que deve validar uma determinadafuncionalidade possui variações nos valores inseridos. Desta forma, são alterados os dados, masnão a estrutura do caso de testes em si. A implementação de uma variação de caso de teste ficano mesmo arquivo XML do caso de teste base. Para isto só é necessário alterar o id do caso deteste e seus dados.

4.5 PROPOSTA

Com o uso do BDD para a implementação dos testes, a classe fluxo foi "substituída"peloScript de testes que, por sua vez, irá fazer a chamada para os passos que corresponderem às suaskeywords.

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 usandofluxos e passos.

O modelo atual, conforme já foi abordado, obedece a seguinte arquitetura:


Figura 20 – Arquitetura atual


Conforme ilustra a figura 20, na arquitetura atual existe uma grande dependência entrefluxo, 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 dedados. Somente é necessário codificar o passo que contenha as regras do teste, e a Page Objectque fará o mapeamento da interface do usuário. Tanto o fluxo como a massa de dados são geradosprogramaticamente.

A vantagem disso é que fica mais simples de criar novos testes que façam uso de passosjá existentes, bem como o tempo de manutenção é bem menor, já que boa parte da codificaçãonão é mais necessária. O Script de testes substitui a criação do fluxo e do arquivo XML quecontém a massa de dados. A figura 21 demonstra como ficaria o processo.


Figura 21 – Arquitetura proposta


A arquitetura ficou disposta em duas principais vertentes:

4.5.1 Mapeamento

A primeira etapa será o mapeamento dos artefatos necessários para a execução. Estemapeamento é feito por meio de um DataProvider com a anotação @DataProvider.

Como pode ser visto em TestNG.org (2014), o DataProvider funciona como um objetode contexto, ou seja, ele é parte das pré-condições de um teste, e, portanto, ele irá ser executadoantes do teste.

O DataProvider irá retornar uma lista de Objects que poderão ser utilizados no contextodos 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.


A figura 22 mostra a implementação do DataProvider em questão.

Figura 22 – Implementação do DataProvider


4.5.2 Execução

É na etapa de execução que a lista de RunnableScrips deverá ser utilizada. Primeiramenteserá mostrado o que é um RunnableScript e os dados contidos nele.

Figura 23 – Implementação do RunnableScript


O RunnableScript possui quatro atributos distintos. Um id, que será a identificação docaso de teste contida no script textual (Exemplo: CT01), também contém um objetivo, umcaminho de arquivo e os comandos. O objetivo é o objetivo do caso de teste, que é uma descriçãodele. O caminho de arquivo referencía o Script textual com as Keywords. e os comandos são umalista de ScriptCommand. O ScriptCommand será esclarecido a na figura 24.


Figura 24 – Implementação do ScriptCommand


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 correspon-dente a keyword está definida no atributo stepClass. Também é definido o caminho e o nome doarquivo da massa de dados, que ficam no atributo stepDataXmlPath. O atributo variables trata-sede 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 umteste de aceitação. Ou seja, se existirem três arquivos de script, o DataProvider irá mapeá-los eo método de teste que fizer uso destes insumos obtidos pelo DataProvider será executado trêsvezes, 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


É 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 especifica-dos e implementados, estes artefatos são gerados programaticamente com base nos dados doRunnableScript.


No passo, as keywords são definidas utilizando-se da annotation @ScriptAction. Esta an-notation possui três atributos distintos. O primeiro é a Keyword de identificação do passo (Stringkeyword). O segundo é uma descrição do passo (String description). O terceiro é o caminhopara criação do arquivo XML de massa de dados (String stepDataMassXML). A imagem abaixomostra a definição do passo com o @ScriptAction:

Figura 26 – Implementação do passo com o ScriptAction para definição das Keywords


Abaixo segue o arquivo de scripts referente ao passo mostrado anteriormente:

Figura 27 – Arquivo de script referente ao passo anterior


Em seguida os fluxos serão rodados e seus resultados serão reportados pelo testNG.

45

5 CONCLUSÃO

A automação de testes de interface tem como objetivo trazer eficácia e eficiência nostestes de software de uma empresa.

Eficácia por que trata o que deve ser feito para garantir que a qualidade do produto sejagarantida, um produto submetido a testes é um produto com menos erros e falhas do que oconcorrente que não possui o mesmo processo de desenvolvimento.

Eficiência por que trata do como e qual a melhor forma de testar o produto. A automaçãopermite que os testes sejam rodados em períodos curtos e sem alterações externas, algo comumem testes manuais.

A automação permite, por exemplo, ser executada ao realizar um commit no versiona-mento de um sistema.

Ainda assim existe o problema de se desenvolver testes automatizados de interface paraprodutos que ainda estejam em processo de desenvolvimento ou correção/manutenção contínua.Estes produtos sofrem constantes alterações seja no modelo de negócio, seja na própria interfacedo usuário.

Isto resulta em constantes e dispendiosas manutenções. Por vezes, é necessário delegartarefas de adequação e manutenção em geral dos testes para uma pessoa que poderia estarexercendo outras funções.

Agora ao implementar o BDD no desenvolvimento dos testes automatizados, estasmanutenções são reduzidas pois são feitas em tempo de especificação. Isto é, o próprio analistade testes ou responsável pelo modelo de negócio poderá fazer as alterações necessárias e quepodem tornar-se documentação, conforme descrevem os objetivos deste trabalho.

Ainda há um porém: a interface do usuário. Esta exige manutenção por uma pessoa maistécnica do que o analista. O mapeamento das telas do sistema, no momento, exige codificação, eportanto, seu processo de adequação e manutenção para novas versões não será diferente.

Este ponto, no cenário atual, ainda não há como ser abstraído do desenvolvimento.Todavia, com o conceito de PageObjects, a parte referente ao modelo do negócio (requisitos erestrições do sistema) não deverão sofrer alterações pois ficam em uma camada a parte.

Uma boa prática seria, futuramente, desacoplar esta nova implementação do projetoantigo, tornando-o uma dependência. A vantagem disto é a de não correr o risco de corrompera arquitetura desenvolvida até então e poder sobreescrever o que for necessário para que sepossa fazer uso de ferramentas de mercado o que é bom pois facilita a manutenção e o uso dedocumentações já existentes.

46

REFERÊNCIAS

ADZIC, G. Specification By Example. 1. ed. Shelter Island, NY 11964: Manning PublicationsCo., 2011. Acesso em: 24 out. 2011. Citado 4 vezes nas páginas 15, 17, 23 e 24.

BLASKO, B. What does the customer really want? They don’t always know... - Agile BusinessManagement Software. 2014. O que um cliente realmente quer? Disponível em: <http://www.kapta.com/blog/technology/what-does-the-customer-really-want-they-dont-always-know>.Acesso em: 05-11-2014. Citado na página 14.

CHELIMSKY, D. et al. The RSpec Book, Behaviour-Driven Development with RSpec, Cucumber,and Friends. 1. ed. Crawfordsville, Indiana: The Pragmatic Bookshelf, 2010. Acesso em: 07 jan.2015. Citado 4 vezes nas páginas 14, 15, 16 e 17.

CUCUMBER.ORG. Cucumber - Step Definitions. 2014. Site oficial do Cucumber. Disponívelem: <http://cukes.info/step-definitions.html>. Acesso em: 05-11-2014. Citado 2 vezes naspáginas 31 e 32.

FEWSTER, M.; GRAHAM, D. Software Test Automation, Effective use of test execution tools. 1.ed. New York, NY: Addison-Wesley, 1999. Acesso em: 24 out. 2011. Citado na página 22.

JBEHAVE.ORG. JBehave Org. - Documentação. 2014. Documentação do framework JBehave.Disponível em: <http://jbehave.org/reference/stable/index.html>. Acesso em: 05-11-2014.Citado 3 vezes nas páginas 22, 30 e 31.

MARTINS, G. de A.; THEOPHILO, C. R. Metodologia da investigação científica para ciênciassociais aplicadas. 2. ed. Shelter Island, NY 11964: Editora Atlas, 2009. Acesso em: 24 out.2011. Citado 2 vezes nas páginas 33 e 34.

PRESSMAN, R. S. Engenharia de Software, Uma abordagem profissional. 7. ed. New York,NY: McGraw-Hill Companies, 2011. Acesso em: 07 jan. 2015. Citado 3 vezes nas páginas 17,18 e 19.

Pufal, N. P.; VIEIRA, V. Desmistificando o bdd. Mundo J, v. 11, n. 64, p. 5–14, 2014. Citado napágina 16.

SELENIUM.ORG. Selenium Documentation. 2014. Documentação do framework Selenium.Disponível em: <http://www.seleniumhq.org/docs/>. Acesso em: 05-11-2014. Citado 7 vezesnas páginas 23, 25, 26, 27, 28, 29 e 30.

TESTNG.ORG. TestNG Documentation. 2014. Documentação do framework TestNG.Disponível em: <http://testng.org/doc/documentation-main.html>. Acesso em: 05-11-2014.Citado 2 vezes nas páginas 29 e 41.

WIKTIONARY.ORG. Wikcionário, o dicionário livre. 2014. Dicionário da Wikipédia.Disponível em: <http://pt.wiktionary.org/wiki/>. Acesso em: 05-11-2014. Citado na página 26.

WYNNE, M.; HELLESOY, A. The cocumber book, behavior-driven development for testers anddevelopers. Mundo J, v. 11, n. 64, p. 5–14, 2014. Citado 3 vezes nas páginas 20, 21 e 22.

http://www.kapta.com/blog/technology/what-does-the-customer-really-want-they-dont-always-know

http://www.kapta.com/blog/technology/what-does-the-customer-really-want-they-dont-always-know

http://cukes.info/step-definitions.html

http://jbehave.org/reference/stable/index.html

http://www.seleniumhq.org/docs/

http://testng.org/doc/documentation-main.html

http://pt.wiktionary.org/wiki/

REFERÊNCIAS 47

ZEFERINO, M. Behaviour-driven development em java na prática, com jbehave: criandoespecificações executáveis utilizando bdd, em nossa língua! Mundo J, v. 8, n. 44, p. 30–39, 2010.Citado na página 30.

Documents

AUTOMATIZAÇÃO DE TESTES DE INTERFACE , EM · PDF fileCURSO SUPERIOR DE TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE ... Exemplo de implementação de um Passo de Teste ... 2.2 Introdução