UNIVERSIDADE FEDERAL DE MATO GROSSO

COORDENAÇÃO DE ENSINO DE GRADUAÇÃO EM

SISTEMAS DE INFORMAÇÃO

RELATÓRIO DE ESTÁGIO SUPERVISIONADO

TESTES AUTOMATIZADOS DE UM SISTEMA WEB

USANDO PROTRACTOR EM AMBIENTE ÁGIL COM

SCRUM

PAULO VINÍCIUS DE OLIVEIRA TÁRCIO

CUIABÁ – MT

2016

UNIVERSIDADE FEDERAL DE MATO GROSSO

COORDENAÇÃO DE ENSINO DE GRADUAÇÃO EM

SISTEMAS DE INFORMAÇÃO

RELÁTORIO DE ESTÁGIO SUPERVISIONADO

TESTES AUTOMATIZADOS DE UM SISTEMA WEB

USANDO PROTRACTOR EM AMBIENTE ÁGIL COM

SCRUM

PAULO VINÍCIUS DE OLIVEIRA TÁRCIO

Relatório apresentado Instituto de

Computação da Universidade Federal de

Mato Grosso, para obtenção do título de

Bacharel em Sistemas de Informação.

CUIABÁ – MT

2016

UNIVERSIDADE FEDERAL DE MATO GROSSO

COORDENAÇÃO DE ENSINO DE GRADUAÇÃO EM

SISTEMAS DE INFORMAÇÃO

PAULO VINÍCIUS DE OLIVEIRA TÁRCIO

Relatório de Estágio Supervisionado apresentado à Coordenação do Curso de

Sistemas de Informação como uma das exigências para obtenção do título de

Bacharel em Sistemas de Informação da Universidade Federal de Mato Grosso

Aprovado por:

Prof.

Instituto de Computação

(Coordenador de Estágios)

Prof. Dr. ou MSc.

Instituto de Computação

(ORIENTADOR)

Prof. Dr. ou MSc. ou Esp.

(SUPERVISOR)

DEDICATÓRIA

À minha família que nunca deixou de me incentivar.

AGRADECIMENTOS

AGRADEÇO AO MEU ORIENTADOR, DANIEL VECCHIATO, QUE DISPONIBILIZOU

PARTE DO SEU TEMPO PARA ME ORIENTAR NO DESENVOLVIMENTO DESSE TRABALHO,

ME DANDO DICAS VALIOSAS. E AGRADEÇO AOS COLEGAS DE TRABALHO QUE, JUNTO A

SUAS EXPERIÊNCIAS, ME AUXILIARAM E CONTINUAM ME AUXILIANDO NA MINHA

CARREIRA PROFISSIONAL.

6

Sumário

LISTA DE FIGURAS .......................................................................................................................... 7

LISTA DE TABELAS .......................................................................................................................... 8

LISTA DE SIGLAS E ABREVIATURAS ......................................................................................... 9

RESUMO ............................................................................................................................................ 10

1. REVISÃO DE LITERATURA ................................................................................................ 13

1.1. TESTE DE SOFTWARE .................................................................................................... 13

1.1.1. TESTES ESTRUTURAIS ................................................................................................... 14

1.1.2. TESTES FUNCIONAIS ...................................................................................................... 14

1.1.3. CASOS DE TESTES............................................................................................................ 15

1.2. AUTOMAÇÃO DE TESTES .............................................................................................. 16

1.2.1. TÉCNICAS DE AUTOMAÇÃO DE TESTES .................................................................. 16

1.3. SISTEMA A SER TESTADO ............................................................................................. 17

1.4. MANIFESTO DE DESENVOLVIMENTO ÁGIL ........................................................... 19

1.4.1. FRAMEWORK SCRUM .................................................................................................... 20

2. MATERIAS, TÉCNICAS E MÉTODOS ............................................................................... 21

2.1. METODOLOGIA DE DESENVOLVIMENTO ............................................................... 21

2.2. FRAMEWORK PROTRACTOR ...................................................................................... 23

2.3. SELENIUM .......................................................................................................................... 24

2.3.1. PROCESSO DE COMUNICAÇÃO ................................................................................... 26

2.4. CONFIGURAÇÃO DO PROTRACTOR .......................................................................... 26

2.5. FRAMEWORK JASMINE ................................................................................................. 27

2.6. MICROSOFT TEAM FOUNDATION SERVER (TFS) .................................................. 28

3. RESULTADOS ......................................................................................................................... 29

3.1. PLANEJAMENTO DE TESTES ....................................................................................... 29

3.2. CONFIGURAÇÃO PARA INÍCIO DOS TESTES .......................................................... 30

3.3. FUNCIONALIDADES TESTADAS .................................................................................. 31

3.4. CRIAÇÃO DE CASOS DE TESTES ................................................................................. 35

4. DIFICULDADES ENCONTRADAS ...................................................................................... 39

5. CONCLUSÕES ......................................................................................................................... 41

6. REFERÊNCIAS BIBLIOGRÁFICAS .................................................................................... 42

APÊNDICES ....................................................................................................................................... 44

7

LISTA DE FIGURAS

FIGURA 1 - DEFEITO X ERRO X FALHA ................................................................................................. 13 FIGURA 2 - CASO DE USO DO SGPWEB ................................................................................................ 18 FIGURA 3 - MÉTODO DO DESENVOLVIMENTO (ADAPTADO DE QUICKSCRUM) ....................................... 22 FIGURA 4 – SINTAXE DE LOCALIZADORES( ADAPTADO DO SITE OFICIAL DO PROTRACTOR).................. 23 FIGURA 5 – AÇÕES DO PROTRACTOR (ADAPTADO DO SITE OFICIAL DO PROTRACTOR). ........................ 24 FIGURA 6 – INFRAESTRUTURA PROVIDA PELO SELENIUM E PROTRACTOR (PROTRACTOR, HOW IT WORKS)

.................................................................................................................................................... 25 FIGURA 7 – PROCESSO DE COMUNICAÇÃO ENTRE O BROWSER, TESTE E SELENIUM ((PROTRACTOR, HOW IT

WORKS) ....................................................................................................................................... 26 FIGURA 8 PROCESSO DE AUTOMAÇÃO UTILIZADO NO ESTÁGIO ............................................................. 30 FIGURA 9 - AUTOMAÇÃO DO LOGIN DO SISTEMA .................................................................................. 30 FIGURA 10 - TELA DE PESQUISA DE NORMAS ........................................................................................ 31 FIGURA 11 - APRESENTAÇÃO DA FUNCIONALIDADE DE CADASTRO DE NORMA ................................... 32 FIGURA 12 - PARTE DO TESTE DE VALIDAÇÃO DE CAMPO DA FUNCIONALIDADE CADASTRO DE NORMA35 FIGURA 13 - RESULTADO DO TESTE DE VERIFICAÇÃO DE CAMPOS OBRIGATÓRIOS ................................ 35 FIGURA 14 - PARTE DO TESTE DE VALIDAÇÃO DE VIGÊNCIA DE NORMA. .............................................. 36 FIGURA 15 - RESULTADO DOS TESTES DE VERIFICAÇÃO DE VIGÊNCIA. .................................................. 37 FIGURA 16 - AUTOMAÇÃO DE CADASTRO DE NORMA ........................................................................... 38 FIGURA 17 - RESULTADO DO TESTE DE CADASTRO DE NORMA. ............................................................. 39

8

LISTA DE TABELAS

TABELA 1 – TABELA DE STATUS DE VIGÊNCIA ...................................................................................... 36

9

LISTA DE SIGLAS E ABREVIATURAS

SGP Sistema de Gestão de Pessoas

IEEE Institute of Eletrecial and Eletronics Engineers

TFS Team Foundation Server

DOM Document Object Model

JSON JavaScript Objection Notation

BDD Behavior Driven Development

API Application Programming Interface

ISTQB International Software Testing Qualifications Board

BSTQB Brazilian software testing Qualification Board

10

RESUMO

Este documento apresenta, em detalhes, o trabalho desenvolvido durante o estágio

supervisionado no departamento de desenvolvimento do Tribunal de Justiça do Mato

Grosso como etapa para a conclusão do curso de Sistema de Informação da

Universidade Federal do Mato Grosso. O principal resultado do estágio é a

implementação de testes automatizados em um ambiente que segue uma metodologia

ágil de gestão e planejamentos de projetos de software. O ambiente ágil de

desenvolvimento foi guiado pelo framework Scrum. As tecnologias usadas para a

realização dos testes foram: o framework de automação de testes, Protractor; o

framework de desenvolvimento de testes, o Jasmine; e para o registro de falhas

encontradas no produto foi utilizado a ferramenta da Microsolf, o Team Foundation

Server. Pode-se concluir que os testes automatizados facilitam e agilizam o trabalho

de um testador, contudo, a implementação da automação de testes em um ambiente

requer muito cuidado e principalmente planejamento e análise para ser possibilitar a

geração de um produto de qualidade.

11

INTRODUÇÃO

Sistemas computacionais têm se tornado um dos pilares mais importante no

suporte de processos e projetos de instituições ou companhias. Elas - instituições e

companhias - tendem a necessitar cada vez mais de automatização de tarefas e para

isso os softwares suportes estão se tornando gradativamente mais complexos. As

chamadas fábricas de softwares, empresas que utilizam processos para criar

ferramentas que diminuem a presença do fator humano, estão pouco a pouco se

tornando bastante preocupadas na entrega de seus produtos com qualidade e a

execução de testes de software está fortemente relacionada com a qualidade final do

produto desenvolvido.

Embora importante, a atividade de testes pode se tornar muitas vezes

repetitiva e custosa, principalmente em projetos que estão em fase de

desenvolvimento, em que os testes necessários aumentam gradualmente com a vida

útil dos projetos.

O presente relatório tem como objetivo relatar as principais atividades

desenvolvidas em um estágio supervisionado dentro do ambiente de

desenvolvimento de softwares do tribunal de justiça de Mato Grosso, no qual junto a

um time de desenvolvimento composto por desenvolvedores, analista de sistema,

analista de qualidade, controlador de projetos, entre outros, foram implementados

testes automatizados em um projeto de desenvolvimento de software de gestão de

pessoas.

A necessidade da automação dos testes se deu por uma tentativa de

aumentar a agilidade de processos e cumprimentos de prazos, diminuindo e até

evitando erros humanos, entregando produtos com maior qualidade ao usuário final.

A organização desse documento está disposta da seguinte forma: a seção 1

apresenta a revisão de literatura, na qual serão abordados aspectos de fundamentação,

teórica e prática, básica, necessários para dar continuidade no entendimento desse

documento; A seção 2 apresenta detalhamento de atividades realizadas e tecnologias

usadas no processo do estágio; A seção 3 apresenta os resultados obtidos nesse

período de estágio supervisionado; A seção 4 apresenta as dificuldades e como elas

foram resolvidas pelo estudante; A seção de número 5 apresenta a conclusão do

12

trabalho e a última seção, de número 6, apresenta as referências bibliográficas que

serviram de suporte para a realização do documento.

13

1. REVISÃO DE LITERATURA

1.1. TESTE DE SOFTWARE

Sistemas de software tornam-se gradativamente parte do nosso dia-a-dia,

desde aplicações comerciais (ex: bancos) até produtos de consumo (ex: carros).

Softwares que não funcionam corretamente podem levar a muitos problemas,

incluindo financeiros, tempo e reputação das empresas. Podendo, inclusive, chegar a

influenciar na integridade das pessoas (BSTQB, 2011).

Teste de software envolve executar uma implementação de software com

dados de testes. Após isso, examina-se as saídas dos dados do software e seu

comportamento operacional para verificar se seu desempenho está conforme

necessário. (SOMMERVILLE, 2007).

Alguns conceitos básicos sobre os testes de software são bastante

relevantes, como, por exemplo, os diferentes conceitos de Defeitos, Erros e Falhas.

Erro, ou engano, são cometidos por seres humanos e gera um defeito (ou

bug, em inglês), no código do software, sistema ou documento. Se esse defeito de

código for executado, o sistema apresenta uma falha ao usuário. Defeitos geram

falhas, mas nem todos os defeitos causam falhas. (Certified Tester Foundation Level

Syllabus, versão 2011, ISTQB).

Figura 1 - Defeito x Erro x Falha

Erro

Defeito

Falha

14

Bastos (BASTOS et al., 2012) explica que os testes de software podem ser

classificados em testes funcionais (também chamados de caixa preta) ou estruturais

(também chamados de caixa branca).

1.1.1. TESTES ESTRUTURAIS

Testes estruturais garantem que os softwares e os programas sejam

estruturalmente sólidos e que funcionem no contexto técnico instalado. Esse tipo de

teste busca determinar se a tecnologia usada funciona de forma correta. Esses testes

não garantem a funcionalidade correta do sistema, mas sim que o sistema esteja

estruturalmente robusto (BASTOS et al., 2012).

Alguns tipos de testes estruturais são: Testes de estresse, teste de execução,

testes unitários, entre outros.

Testes estruturais tem como objetivo avaliar o comportamento do software

sob condições críticas como, por exemplo, pouca memória, objetivando simular

ambientes de produção que há restrições (BASTOS et al., 2012).

Testes de execução são aqueles que verificam o tempo resposta do sistema,

se esse não está demorando para retornar um resultado ou de processar operações

(BASTOS et al., 2012).

Testes unitários são os testes realizados na parte mais baixa da escala de

testes, normalmente realizados pelos próprios desenvolvedores, são aplicados em

pequenos componentes de código criado, visando garantir os componentes atendam

características da funcionalidade (BASTOS et al., 2012).

1.1.2. TESTES FUNCIONAIS

Testes funcionais garantem que os requisitos do usuário, ou seja, requisitos

do sistema perante a sua funcionalidade, estejam corretamente codificado e se o

sistema está se comportando de forma correta como o usuário espera (BASTOS et

al., 2012). Alguns exemplos desse tipo de testes são: Teste de sistema, teste de

regressão e teste fumaça.

15

Os testes de sistema (também chamados de ponta-a-ponta) verificam se o

software está realizando o que foi descrito nos requisitos. Esse tipo de teste costuma

envolver mais de um programa ou um conjunto lógico de casos de testes, que muitas

vezes estão ligados a um determinado caso de uso (BASTOS et al., 2012)

Os testes de regressão voltam a testar segmentos já testados após a mudança

em outra parte do software. Ou seja, testar novamente os mesmos testes realizados

anteriormente para garantir que os resultados não tenham sido afetados pelas

mudanças realizadas não só na parte alterada, como também em outras partes do

sistema (BASTOS et al., 2012).

Teste fumaça ou smoke test é: Um subconjunto de todos os casos de testes

definido ou planejados que cobrem as principais funcionalidades de um componente

ou sistema, preocupando com detalhes mais superficiais do que superficiais (ISTQB,

Glossário Padrão de Termos Utilizados em Testes de softwares, 2014).

1.1.3. CASOS DE TESTES

Um caso de teste pode ser entendido como um conjunto de valores de

entrada, precondições de execução, resultados esperados e condições posteriores a

execução, desenvolvida para um objetivo particular ou condição de teste. (ISTQB,

versão 3.1, 2016). A definição de casos de testes é importante para que possa ser

determinado o que será testado, objetivando um maior número de cenários e

variações a serem testadas.

Um bom caso de testes deve conter basicamente (BASTOS et al., 2012).

Pré-condições;

Pós-condições;

Critério de Aceitação;

Identificação dos casos de testes (o que testar);

Detalhamento da massa de entrada e de saída;

Critérios especiais, quando houver;

Especificação especiais das configurações do ambiente de teste;

Definição se o teste será manual ou automático;

16

Para (BASTOS et al., 2012) um caso de teste deve seguir algumas

características para que seja válido, ou seja, para que garanta que o software esteja

fazendo a coisa certa de acordo com os requisitos. Essas características são: O caso

de teste tem que ser efetivo, ou seja, testar o que se planejou testar; tem que ser

econômico, não possuir passos desnecessários; tem que ser reutilizável, que possa ser

repetido; rastreável, que possa identificar o requisito a ser testado e tem que ser

autoexplicativo, que possa ser testado por qualquer outra pessoa.

1.2. AUTOMAÇÃO DE TESTES

Automação de testes significa fazer o uso de software que controlem a

execução dos casos de teste. O uso desta prática pode reduzir significativamente o

esforço necessário para os testes em um projeto de software, ou seja, executar

maiores quantidades de testes em tempo reduzido testes manuais que levariam horas

para serem totalmente executados poderiam levar minutos caso fossem

automatizados. (TUSCHLING, 2008).

1.2.1. TÉCNICAS DE AUTOMAÇÃO DE TESTES

Existe algumas técnicas de automação de testes, a mais conhecidas delas são

a record & playback e a programação de script. A técnica record & playback

consiste em utilizar uma ferramenta de automação de testes e gravar as ações

executadas por um usuário sobre a interface de uma aplicação. Após a gravação, o

teste é transformado em script de testes que podem ser executados várias vezes. Toda

vez que o script já gravado é executado, as ações gravadas são realizadas novamente.

A vantagem da técnica de record & playback é que ela é bastante simples e prática,

sendo uma boa abordagem para testes executados poucas vezes. Porém há várias

desvantagens como: custo e dificuldade de manutenção, baixa taxa de reutilização,

curto tempo de vida e alta sensibilidade (FANTINATO, et al, 2005).

A técnica de programação de script de teste é uma extensão da técnica record

& playback. Por meio da programação, os scripts de testes são gravados e alterados

17

para que desempenhem um comportamento diferente dos scripts originais da sua

execução (FANTINATO, et al, 2005).

Segundo (FANTINATO, et al, 2005) “a programação de script de teste é uma

técnica de automação que permite, em comparação com a record & playback, maior

taxa de reutilização, maior tempo de vida, melhor manutenção e maior robustez dos

scripts de teste”.

1.3. SISTEMA A SER TESTADO

Nesse estágio, o sistema a ser testado encontra-se em fase de

desenvolvimento e se chamará SGPWeb - Sistema de Gestão de Pessoas Web. O seu

primeiro marco de entrega está para o final do ano de 2016.

O SGPWeb é um projeto de substituição de um sistema legado, o SGP -

Sistema de Gestão de Pessoas, que tem como objetivo controlar as informações de

recursos humanos do Poder Judiciário de Mato Grosso, assim como: férias, ponto

eletrônico, nomeação, exoneração, desligamento, cadastro de feriados, relatórios,

entre outros.

A primeira versão do sistema SGP foi implementada em 2004 e começou

com uma plataforma web, porém, por causa mudanças constantes para atender as

demandas dos usuários, o sistema passou gradativamente para a plataforma atual

(Windows Forms). Após mais de dez anos de uso do SGP, o mesmo retornará a

plataforma web.

A permuta de um sistema legado para um novo sistema demanda um

esforço muito grande, tanto financeiro, quanto temporal. E a mudança do SGP para o

SGPWEB não podia ser diferente, por isso, em seu primeiro planejamento, o

SGPWEB não possuirá todas as funcionalidades do Sistema de Gestão de Pessoas

(Windows Forms).

O SGPWEB contará nessa primeira fase de implementação apenas as

funcionalidades referentes a cadastro de pessoas, convites de candidatos,

movimentação de pessoas, nomeação, exoneração, cadastro de localidade, normas e

cargos. Na Figura 2, foi desenvolvido um diagrama de casos de uso para melhor

visualização do que constará no novo sistema SGP.

18

Figura 2 - Caso de Uso do SGPWEB

Conforme ilustrado na Figura 2, existem 4 pacotes: Localidade, Pessoa,

Convite e Movimentação. O pacote Localidade representa os cadastros de local de

trabalho dos servidores do poder judiciário do tribunal de justiça. Para se cadastrar

um local é necessário primeiro o cadastro de uma norma, que são documentos (leis,

súmulas, portarias...) que regem regras dentro do poder judiciário. Ainda nesse

pacote são regidos a criação e vinculação de cargos, seus requisitos e as quantidades

disponibilizada para cada local de trabalho. O pacote de Pessoa, representa um

cadastro de uma pessoa que fará ou já faz parte integrante da organização. Esse

cadastro poderá ser preenchido manualmente, contudo, esse não é o objetivo

principal dessa funcionalidade. Essa funcionalidade será automaticamente

preenchida após a nomeação do candidato após um convite. O pacote Convite,

representa a configuração dos envios de e-mail e requisitos para os candidatos à vaga

de cargos. Esse pacote compreende também a aprovação desse convite, por meio de

um checklist; o último pacote, movimentação, é responsável pelas funcionalidades de

nomeação, exoneração ou demissão de pessoas que integram o serviço do poder

judiciário.

Existe uma grande necessidade de desenvolver testes automatizados para o

SGPWEB, pois o sistema está em fase de desenvolvimento e é um projeto

completamente novo, sendo assim, são necessários bastantes testes para garantir a

qualidade do produto, principalmente os testes de regressão. Outro motivo bastante

19

importante é iniciar a cultura do desenvolvimento de automação dos testes no

departamento de desenvolvimento, que ainda não é adepto a prática, sendo assim, o

projeto servirá como um caso pioneiro para a introdução da técnica em um

departamento que utiliza os princípios do manifesto de desenvolvimento ágil como

pilar da rotina de trabalho.

1.4. MANIFESTO DE DESENVOLVIMENTO ÁGIL

O Agile Alliance, organização sem fim lucrativo, dita que o desenvolvimento

ágil de software se baseia nos métodos e princípios do manifesto ágil. Esse manifesto

surgiu em 2001, e são um grupo de pessoas que estão descobrindo maneiras

melhores de desenvolver softwares, valorizando os seguintes pontos (Manifest for

Agile Software Development. Agile Alliance, 2001):

Indivíduos e interação entre eles ao invés de processos e ferramentas;

Software em funcionamento mais que documentação;

Colaboração com cliente mais que a negociação de contratos;

Responder as mudanças mais que seguir um plano.

O manifesto ágil possui 12 princípios e eles são listado abaixo (12 Principles

Behind the Agile Manifesto, Agile Alliance, 2015):

1. Maior prioridade em satisfazer o cliente, entregando o software de forma

continua e adiantada.

2. Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento.

Processos ágeis se adequam a mudança.

3. Entregar software funcionando com frequência, na escala de semanas até

meses, com preferência aos períodos mais curtos;

4. Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em

conjunto e diariamente;

5. Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente

e suporte necessário, e confiar que farão seu trabalho;

20

6. O método mais eficiente e eficaz de transmitir informações é por conversação

cara-a-cara;

7. Software funcional é a medida primária de progresso;

8. Processos ágeis promovem um ambiente sustentável. Os patrocinadores,

desenvolvedores e usuários, devem ser capazes de manter indefinidamente

passos constantes;

9. Contínua atenção à excelência técnica e bom design;

10. Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou

ser feito;

11. Times auto organizáveis possuem melhores arquiteturas, requisitos e design;

12. Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se

ajustam e otimizam seu comportamento de acordo.

1.4.1. FRAMEWORK SCRUM

Scrum é um framework dentro do qual pessoas podem tratar e resolver

problemas complexos e adaptativos, enquanto produtiva e criativamente entregam

produtos com o mais alto valor possível (Guia do Scrum, Scrum.Org, 2013). O

Scrum.org completa dizendo que o framework consiste nos times do Scrum

associadas a papéis, eventos, artefatos e regras. Cada componente dentro do

framework serve a um propósito especifico e é essencial para o uso e sucesso do

Scrum (Guia do Scrum, Scrum.org, 2013).

O time de trabalho Scrum é composto pelo Product Owner, o time de

desenvolvimento e o Scrum Master, cada entidade dessas com suas devidas

atribuições.

O Scrum.org apresenta a Sprint, como o núcleo do framework, definindo

como “é um time-boxed de um mês ou menos, durante o qual um “pronto”, versão

incremental potencialmente utilizável do produto, é criado. ” (Guia do Scrum,

Scrum.org, 2013) As Sprints são compostas por uma reunião de planejamento da

Sprint, reuniões diárias, o trabalho de desenvolvimento, uma revisão da Sprint e a

retrospectiva da Sprint”.

21

2. MATERIAS, TÉCNICAS E MÉTODOS

Durante o período de estágio, as atividades foram realizadas com o auxílio

de várias tecnologias e utilizando alguns métodos. Essa seção mostrará

detalhadamente como se deu o processo de realização das atividades, suas

tecnologias e métodos.

2.1. METODOLOGIA DE DESENVOLVIMENTO

O departamento de desenvolvimento do Tribunal de Justiça conta em sua

maioria com profissionais terceirizados que utilizam de métodos ágeis para entrega

de seus produtos. O projeto SGPWeb, em seu estágio de desenvolvimento, utilizou

de conceitos da metodologia Scrum para o cronograma do projeto.

Nesse estágio, as Sprints foram determinadas em um tempo de uma

semana, ou seja, cinco dias úteis, iniciando todas as segundas feiras e terminando as

sextas.

É dentro da Sprint que o time de desenvolvimento realiza suas tarefas,

como análise, prototipação, desenvolvimento, testes, deploys e reuniões, resultando

em uma parte do produto, chamado de produto incremental. As reuniões diárias

desse projeto foram estimadas em 15 minutos, já as de planejamento e retrospectivas

foram estimadas 3 horas e 30 minutos, respectivamente, toda as segundas-feiras.

A Figura 3 exemplifica como método é usado:

22

Figura 3 - Método do desenvolvimento (Adaptado de QuickScrum)

O time de desenvolvimento foi composto por um controlador de projeto,

responsável por gerenciar o time e o projeto; um analista de sistemas, responsável

por analisar, documentar e criar protótipos da aplicação; cinco desenvolvedores,

responsáveis pela codificação da aplicação; dois arquitetos de software, responsável

por decisões de tecnologias e auxílios destas ; um estagiário, que auxilia no

desenvolvimento e um técnico de qualidade, o autor desse documento, responsável

por testes, automatização de testes, documentos de apoios e treinamentos.

Inicialmente foi tentado realizar os testes automatizados junto com o

desenvolvimento, contudo, essa ação foi logo modificada, pois o projeto está em fase

de desenvolvimento e os requisitos ou layout eram frequentemente modificados.

Sendo assim, a automação passou a ser realizada sempre que uma funcionalidade

atingisse o nível de maturidade para tal.

Os testes manuais eram realizados em todas as sprints com o objetivo de

encontrar defeitos que poderiam passar despercebidos pelos testes automatizados.

23

2.2. FRAMEWORK PROTRACTOR

Segundo o site oficial da tecnologia, protractortest.org, Protractor é um

framework de teste ponta-a-ponta para aplicações desenvolvidas em AngularJS.

Protractor executa testes em cima de aplicações que estão sendo executadas em

navegadores reais, interagindo como se fosse um usuário final.

A parte principal de um teste ponta-a-ponta de páginas webs é procurar um

elemento DOM, interagir com eles, e obter informação sobre o atual estado da

aplicação.

Protractor exporta uma função chamada “element”, que recebe uma

localização e retorna um ElementFinder, que por sua vez retorna um único elemento.

Para múltiplos elementos pode-se usar a função “element.all”. (Protractor, Using

Locators).

O ElementFinder possui algumas ações, como “click()”, “getText()” e

“sendKeys”. Esses são alguns jeitos de interagir com elementos e obter informações

deles.

As Figuras 4 e 5, ilustradas abaixo, mostram alguns exemplos.

Figura 4 – Sintaxe de localizadores( Adaptado do site oficial do Protractor)

24

Figura 5 – Ações do Protractor (Adaptado do site oficial do Protractor).

Protractor é um programa Node.Js. Para executar Protractor, é necessário

primeiro ter o Node.Js instalado na máquina.

NodeJS, segundo o site nodebr.com, é uma plataforma construída sobre o

motor JavaScript dos navegadores para facilmente construir aplicações de redes

rápidas e escaláveis. Node.Js usa um modelo de I/O direcionada a evento que não

bloqueante que o torna leve e eficiente, ideal par aplicações em tempo real com troca

intensa de dados através de dispositivos distribuídos.

2.3. SELENIUM

Selenium é um conjunto de diferentes ferramentas com diferentes objetivos

que suportam teste automatizados de aplicações web. Selenium pode ser executado

em vários navegadores e sistema operacionais, e também pode ser controlado por

várias linguagens de programação e por vários frameworks. Esta ferramenta tem

suporte para as maiores empresas de navegadores de internet que já estão

trabalhando para deixar que Selenium seja uma parte nativa do próprio navegador

(Selenium, 2016).

Protractor trabalha junto com o Selenium para prover uma infraestrutura de

teste que pode simular a ação dos usuários (Figura 6). (Protractor, How it Works).

Para isso:

1. Protractor empacota WebDriverJS, que são ligações JavaScript

para o API do SeleniumWebDriver;

25

2. Comandos Webdriver são assíncronos, ou seja, eles são

programados no fluxo de controle e retornam um resultado

prometido, e não valores primitivos;

3. Os scripts de testes são enviados para o Selenium Server, que se

comunica com o driver dos navegadores.

Figura 6 – Infraestrutura provida pelo Selenium e Protractor (Protractor, How it Works)

26

2.3.1. PROCESSO DE COMUNICAÇÃO

Um teste utilizando Selenium Webdriver envolve três processos - o script

de teste, o servidor e o navegador. A comunicação entre esses três processos é

mostrada na Figura 7, logo abaixo:

Figura 7 – Processo de comunicação entre o browser, teste e Selenium ((Protractor, How it

Works)

O Selenium Server se responsabiliza para interpretar os comandos dos testes

e transmitir para um ou mais navegadores. A comunicação entre o servidor e os

navegadores utiliza o WebDriver Wire Protocol, um protocolo JSON. O Comando é

interpretado pelo driver do browser (Protactor, How it Works, 2016).

2.4. CONFIGURAÇÃO DO PROTRACTOR

Protractor necessita de dois arquivos para poder ser executado, o arquivo

de configuração, que diz ao Protractor como configurar o servidor do Selenium, qual

27

teste executar, qual browser executar e quais frameworks utilizar; e o arquivo de

especificação de testes, ou seja, aonde os testes serão escritos.

2.5. FRAMEWORK JASMINE

Jasmine é um framework independente, e de sintaxe de fácil compreensão

para o desenvolvimento de testes em código JavaScript. Jasmine não precisa de

DOM e encontra-se atualmente, na data desse relatório, na versão 2.4.1(Jasmine,

Introduction, 2016).

Jasmine possui uma sintaxe simples que conta com os seguintes itens:

Describe:

Início do suíte de testes que possui dois parâmetros, uma string

e uma função. A string representa o nome ou título para um suíte de

teste; a função é um bloco de código que implementa o suíte.

(Jasmine, Introduction,2016).

Its:

São blocos de funções, eles podem conter qualquer código

executável que seja necessário para programar testes. Regras do

JavaScript podem ser aplicadas aqui (Jasmine, Introduction, 2016).

Expectation:

Expectativas são criadas com a função “expect” que recebe um

valor. É encadeado a função “matcher”, que recebe o retorno de um

valor (Jasmine, Introduction, 2016).

Matcher:

Cada “matcher” programa uma comparação booleana entre o

atual valor e um valor esperado. Isso é responsável de dizer ao

Jasmine se a expectativa é falsa ou verdade (Jasmine, Introduction,

2016).

28

2.6. MICROSOFT TEAM FOUNDATION SERVER

(TFS)

O Team Foundation Server oferece um conjunto de ferramentas que

funcionam com qualquer IDE proporcionando a equipe uma forma de trabalhar

efetiva em projetos de todos os tamanhos ou formatos.

O TFS proporciona ferramentas como lista de pendências, kanban, e toda

uma estrutura para time que utilizam o Scrum como metodologia. (O que é o Team

Foundation Server, Microsoft, 2016.)

29

3. RESULTADOS

Nessa seção serão apresentados os resultados no período de estágio o qual o

aluno foi submetido. Em um primeiro momento, houve a necessidade de estudos

sobre os conceitos básicos de testes de software e suas especializações. Feito isso,

como o projeto já se encontrava em desenvolvimento, foi necessário também os

estudos sobre o ambiente ágil, seus artefatos e métodos e a ferramenta Team

Foudation Server. Esses conhecimentos foram necessários para que o aluno, em suas

atribuições de técnico de qualidade, pudesse manusear e reportar os defeitos

encontrados de forma manual no sistema a ser testado.

Feito esse estudo, houve a necessidade de compreender o funcionamento

das ferramentas para dar continuidade ao processo de trabalho, estudando então

Protactor, Jasmine e a linguagem de programação, JavaScript.

As subseções mostrarão como as seções após a fase de estudo foram

desenvolvidas.

3.1. PLANEJAMENTO DE TESTES

O primeiro passo para a implantação da automação dos testes foi a

elaboração de um processo que fosse viável para o ambiente de trabalho. Esse

processo inicia-se com o estudo, junto ao time de desenvolvimento, do cenário que

eram descritos pelo analista do sistema em forma de User Storys. Em um segundo

passo, se deu a especificação das tarefas de testes, descrevendo “o que” e “como” e

por quê?” será testado tal cenário. O terceiro passo contempla a execução manual dos

testes e o último passo, após verificar que a funcionalidade estava testável, a

automação. O processo pode ser visualizado na Figura 8, logo abaixo:

30

Figura 8 Processo de automação utilizado no estágio

3.2. CONFIGURAÇÃO PARA INÍCIO DOS TESTES

A configuração do Protactor é simples, sendo necessário apenas a

instalação do NodeJs e do Protractor que já possui o Jasmine como framework

padrão de escrita de código.

A automação do login foi realizada no arquivo de configuração em uma

função chamada “onPrepare”, que realiza tarefas antes mesmo do início dos testes.

Na figura abaixo é demonstrado a automação do login.

Figura 9 - Automação do Login do sistema

O código completo usado para a configuração do Protractor usado está

disponibilizado nos anexos desse relatório juntos com os demais códigos de testes.

Todos os testes foram realizados em um ambiente de teste com as seguintes

configurações: Sistema Operacional cliente Windows 10 Pro, 64 bits, Browser

Google Chrome, RAM 16GB, IntelCore i5-4460.

Estudo de Cenário

Descrição de Tarefa

Testes Manuais

Automação

31

3.3. FUNCIONALIDADES TESTADAS

Foram desenvolvidos testes automatizados para as seguintes

funcionalidades: Gerenciamento de norma, cargo e de local, cada uma com cadastro,

edição e exclusão.

Para demonstrar a criação dos testes, foi selecionado uma funcionalidade

simples, porém de grande valor para o sistema: O gerenciamento de norma. O

gerenciamento de norma é o primeiro passo para o pacote de Localização do sistema.

Essa funcionalidade é de bastante importância, pois as outras funcionalidades do

sistema estão vinculadas a alguma Norma. As Figuras 10 e 11, logo abaixo,

apresentam a tela de cadastro de Norma:

Figura 10 - Tela de Pesquisa de Normas

32

Figura 11 - Apresentação da Funcionalidade de Cadastro de Norma

Objetivando demonstrar o comportamento do sistema na funcionalidade de

cadastro de norma, a especificação desse caso de uso – Cadastrar Norma – pode ser

verificada abaixo:

Atores

Usuário do RH

Pré-Condições

O usuário deve estar autenticado no sistema.

Pós-Condições

Ter os registros alterados ou alterar os status de ativos para inativos no banco

de dados.

Fluxo Principal

Passo Descrição

1. O fluxo principal inicia-se quando o usuário realiza login no sistema e

clica na opção Principal - >Norma

2. O sistema apresenta uma tela de consulta de normas aonde apenas as

normas ativas são apresentadas.

3. O usuário possui as seguintes opções:

Cadastro de Nova Norma

Editar Norma

Desativação de Norma

Pesquisa Especifica de Norma

Pesquisa Avançada de Norma

Fluxo Alternativos

33

(A 01) Alterar Registro de Norma

Passo Descrição

1. Ao clicar em “Editar norma” encontramos os campos já preenchidos e

podendo ser alterados:

Tag (não obrigatório)

Norma (obrigatório)

Ano (obrigatório)

Data de Publicação (obrigatório)

Início Vigência (obrigatório)

Fim Vigência (não obrigatório)

Descrição/Ementa (obrigatório)

Referência (obrigatório)

2. Fim do Fluxo Alternativo A 01

(A 02) Desativar registro de Norma

Passo Descrição

1 Ao clicar na última coluna da listagem de registros, o sistema deve

apresentar o botão de desativação de norma.

2. Caso o botão seja selecionado, o sistema deve abrir a tela de motivo para

exclusão de dados.

3. Ao preencher o motivo e clicar em sim, o sistema deve alterar o status da

norma para “inativo” e retirar da lista de normas ativas.

4. Ao preencher e clicar em não, o sistema não modifica o status da norma e

retorna a tela de pesquisa.

(A 03) Pesquisa Especifica de Norma

Passo Descrição

1 Ao digitar qualquer item que esteja na listagem de normas ativas, ou seja,

Tipo de Norma, Número, Ano, Descrição, Status, Data de Publicação ou

Situação; o sistema deve apresentar os registros referentes à pesquisa

feita.

2 Caso não encontre resultado, o sistema deve apresentar a lista de

registros com um único registro indicando que não houve resultado

encontrado.

(A 04) Pesquisa Avançada de Norma

Passo Descrição

1 Ao clicar em “Mais Opções” o sistema habilita a pesquisa avançada para

o usuário com os seguintes campos: Norma, Descrição, Data de

Publicação, Inicio vigência, Fim Vigência, Status, Tags.

2 Ao preencher um ou mais campos da pesquisa, o sistema deve apresentar

os resultados de acordo com as junções de filtros.

3 Caso não encontre resultado, o sistema deve apresentar a lista de

registros com um único registro indicando que não houve resultado

encontrado.

Fluxos de Exceções

34

(E 01) Norma já cadastrada

Passo Descrição

1. Caso o usuário tente adicionar uma Norma com o mesmo número,

mesmo ano e mesma vigência, o sistema deve apresentar a mensagem de

validação de normas iguais.

(E 02) Campos obrigatórios não preenchidos.

Passo Descrição

1. Todos os campos da tela são obrigatórios. Caso algum campo não seja

preenchido, o sistema deve exibir a mensagem de validação de

obrigatoriedade de campo.

35

3.4. CRIAÇÃO DE CASOS DE TESTES

O primeiro conjunto de testes consta com os casos de testes referentes ao

preenchimento obrigatório dos campos. O teste se baseia em adicionar valores de

forma sequencial aos campos da tela de cadastro de norma, e clicar no botão de

“salvar e fechar”. A cada inserção de dado e click botão salvar, o teste verificava se a

mensagem de validação dos outros campos não preenchidos está sendo apresentada.

Quase todos os campos da tela de Cadastro de Norma são obrigatórios,

salvo os campos “tag” e “Fim vigência”. Parte do código e o resultado do teste

automatizado podem ser verificados abaixo:

Figura 12 - Parte do teste de validação de campo da funcionalidade Cadastro de Norma

Figura 13 - Resultado do teste de verificação de campos obrigatórios

O segundo suíte consta com os casos de testes de verificação do status da

vigência de acordo com a data informada nos campos “Inicio Vigência” e “Fim

36

Vigência” preenchidos no cadastro de norma. A tabela abaixo demonstra os valores

possíveis para vigência de normas.

Datas Vigência

Ao abrir a tela Sem vigência

Fim vigência > Data

Atual

Vigente

Início Vigência > Fim

Vigência

Vigência invalida

Início e Fim Vigência <

Data Atual

Vigente

Fim Vigência = nulo Vigente

Fim Vigência = Data

Atual

Vigente

Fim Vigência < Data

Atual

Revogada

Tabela 1 – Tabela de status de Vigência

Parte da automação do teste e o resultado estão apresentados abaixo:

Figura 14 - Parte do teste de validação de vigência de Norma.

37

Figura 15 - Resultado dos testes de verificação de vigência.

O último suíte de teste consta com os casos de testes referentes ao cadastro de

norma ativa, verificando, se após o cadastro, o sistema apresenta um registro a mais

na lista de normas ativas. Para isso, foi automatizada a contagem de registros ao abrir

a tela de pesquisa de norma e a paginação, a inserção de dados do cadastro de norma

e contagem após o click de no botão de “salvar e fechar”. O fator de aceitação é que

o sistema não deve duplicar registros e ao fazer a segunda contagem, apenas um

registro a mais deve ser identificado. Abaixo é possível visualizar parte do código

que está sendo automatizado o cadastro de norma e o resultado do teste.

38

Figura 16 - Automação de cadastro de Norma

Nessa parte do código, após a contagem dos registros em uma lista, foi

clicado no botão “Novo” que apresenta a tela de cadastro de norma (Figura 11), após

esperar um pouco para que todos os elementos sejam apresentados, o teste realiza a

inserção de dez tags na norma com um intervalo de um segundo entre elas pois

Protractor insere os dados muitos rápidos e algumas vezes acaba “comendo” dados

que deveriam ser inseridos. Posteriormente a inserção de tags, os elementos foram

selecionados pelos seus ids, inseridos no front-end. Para a inserção de dados de

dropdown list, número, ou data, usou-se de funções que gerassem valores

aleatoriamente para que nenhum teste ficasse igual ao outro. Perceba que os valores

do campo de “fim vigência” não foi inserido pois não é um campo obrigatório e o

teste de vigência de norma foi realizado em outro grupo de testes.

Após a inserção de datas e dropdown list, a automação se deu nos campos

textuais da funcionalidade, seguido do botão salvar, finalizando a parte de cadastro

39

de norma mostrado na figura. Como resultado do teste, o sistema então faz a

contagem novamente de registros e verifica se só um único registro foi adicional a

lista de resultados.

Figura 17 - Resultado do teste de cadastro de norma.

Após os resultados dos testes, caso alguma falha fosse apresentada, o

defeito era cadastrado em forma de artefato de Bug na ferramenta Team Foudation

Server, descrevendo os passos para a reprodução, perfil de acesso e outras

informações importantes; também era realizada a classificação perante prioridade e

gravidade do artefato. Na reunião de planejamento de Sprint, esse artefato bug era

discutido com o time de desenvolvimento, que tomava a decisão de quando tal

inconsciência iria ser corrigida.

4. DIFICULDADES ENCONTRADAS

Durante o período de estágio, o autor desse documento se deparou com

várias dificuldades. A primeira dela foi o desconhecimento prévio das tecnologias

40

usadas para a realização do trabalho. Necessitando então de tempo para estudo

prévio.

O Protractor, tecnologia usada para automatizar os testes, é uma tecnologia

relativamente nova no mercado (março de 2014) e que possui pouca documentação e

alguns bugs em suas versões. A documentação, em sua grande maioria, é encontrada

apenas no idioma americano, o que não impediu os estudos do estagiário, porém

demandou uma maior quantidade de tempo e concentração. A soma desses fatores

concretiza a segunda dificuldade.

A terceira dificuldade encontrada foi em relação às constantes mudanças do

projeto, característica comum em projetos em desenvolvimento. Quase sempre que

havia mudança de escopo ou de layout, os testes automatizados apresentavam

alguma irregularidade e precisavam passar por manutenção.

A quarta dificuldade a ser citada é o não conhecimento da linguagem de

teste, JavaScript, que não foi lecionada durante o período escolar do estagiário. Essa

dificuldade foi sanada com estudos da tecnologia, uso de redes sociais de

programação e auxilio dos desenvolvedores, colegas de trabalho.

Como dificuldade pode-se citar também que o projeto estava passando por

uma experiência de tecnologia nova para os desenvolvedores, o Angular 2. Os

desenvolvedores também precisaram de tempo para estudo de tecnologia e muitas

vezes, no meio do projeto, era necessário refatorar alguma funcionalidade,

consequentemente a dificuldade de testes automatizados, pois algumas

funcionalidades demoraram a ser finalizadas, estourando o planejamento geral do

projeto, e também a manutenção dos testes que eram realizadas constantemente e que

muitas vezes foi preferível a execução de testes manuais.

41

5. CONCLUSÕES

A atividade de teste torna-se cada vez mais bem vista no mercado de

software, isso porque as empresas estão preocupadas na entrega não só da

funcionalidade do produto, mas também na qualidade do produto.

Assim como um projeto de desenvolvimento, a atividade de teste deve ser

tratada como um projeto, sendo necessário planejamento, análise e execução

(BASTOS et al, 2012), deixando claro que é uma ação que demanda tempo e mão de

obra.

A automação de testes é uma técnica que visa agilizar e deixar menos

onerosa os testes de software. Para a realização dessa técnica é necessário bastantes

estudos e dedicação.

Nesse estágio, a grande falha do estagiário foi a tentar automatizar tudo,

esquecendo-se da fase de planejamento. Essa falha não impediu a realização do

trabalho, contudo dificultou a realização das atividades que já passavam por

bastantes desafios no caminho.

Como trabalho futuros, o aluno se dedicará a prestar mais atenção no

planejamento das atividades para amadurecer o processo já implantado e estenderá os

testes automatizados as outras funcionalidades do sistema, sabendo agora que nem

tudo deve ser automatizado. Dedicará também aos estudos as boas práticas de escrita

de testes como, por exemplo, o padrão de projeto Page Object, e ao processo da

implementação dos testes nas builds de versões do sistema.

42

6. REFERÊNCIAS BIBLIOGRÁFICAS

Agile Alliance, 12 Principles Behind the Agile Manifesto, disponível em

https://www.agilealliance.org/agile101/12-principles-behind-the-agile-manifesto

(acessado em 05/09/2016)

Agile Alliance, Manifesto for Agile Software Development, disponível em

https://www.agilealliance.org/agile101/the-agile-manifesto/ acessado em

(05/09/2016)

BASTOS, Aderson; RIOS, Emerson; CRISTALLI, Ricardo, MORREIRA,

Trayahú; 2012. Base de conhecimento em teste de software. 3. ed. São Paulo :

Martins

Certified Tester Foundation Level Syllabus, BSTQB, disponível em

http://www.bstqb.org.br/uploads/docs/syllabus_ctfl_2011br.pdf (acessado em 10 de

agosto de 2016).

FANTINATO, Marcelo; 2005. AutoTest - Um framework reutilizável para

automação de teste funcional de software. Campinas

Glossário padrão de termos utilizados em Testes de Software versão 2.4br, ITSQB, r

disponível em

http://www.bstqb.org.br/uploads/docs/glossario_istqb_2.4br.pdf(acessado em

02/10/2016)

IEEE Standard Glossary of Software Engineering Terminology. IEEE Std 610.12-

1990, p. 1– 84, dez. 1990.

Jasmine Introduction, disponível em http://jasmine.github.io/edge/introduction.html

(acessado em 10/07/2016)

Ken Schwaber e Jeff Sutherland. Guia do Scrum. Disponível em

http://scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-Portuguese-

Brazilian.pdf (acessado em 28/07/2016)

43

Manifesto Ágil, disponível em http://www.manifestoagil.com.br/ (acessado em

11/08/2016).

Manifesto for Agile Software Development, disponível em

http://www.agilemanifesto.org/ (acessado em 27/07/2016).

NODEJS, disponível em https://nodejs.org/en/ (acessado em 11/08/2016).

Protractor, disponível em http://www.protractortest.org/#/(acessado em 10/07/2016).

Protractor, How It Works, disponível em

http://www.protractortest.org/#/infrastructure (acessado em 05/09/2016)

Revista Engenharia de Software, edição especial Qualidade de Software, disponível

em http://www.devmedia.com.br/revista-engenharia-de-software/8028

Revista Engenharia de Software, edição especial, disponível em

http://www.devmedia.com.br/revista-engenharia-de-software/8028 (acesso em 10 de

agosto de 2016).

Scrum Framework and Sprint, disponível em

https://dmquickscrum.wordpress.com/2014/11/07/in-scrum-can-a-sprint-be-

cancelled-if-so-when/ (acessado em 27/07/2016).

Selenium Documentation, disponível em http://www.seleniumhq.org/docs/, (acesso

em 07/09/2016)

SOMMERVILLE, IAN; 2007, Engenharia de Software 8. Ed. São Paulo. Pearson

Education.

Standard Glossary of Terms used in Software Testing Version 3.1, ISTQB,

disponível em http://www.istqb.org/downloads/send/20-istqb-glossary/186-glossary-

all-terms.html (acessado em 09 de agosto de 2016).

Team Foundation Server, disponível em https://www.visualstudio.com/pt-

br/products/tfs-overview-vs.aspx (acesso em 07/09/2016)

TUSCHLING, Oliver, 2008, disponível em

https://www.agileconnection.com/sites/default/files/article/file/2013/XDD14908fileli

stfilename1_0.pdf (acesso em 10/08/2016)

44

APÊNDICES

APÊNDICE 1

const config = { baseUrl: 'http://localhost:5555/', // Url de acesso padrão. Toda chamada feita para um browser será para essa url specs: [ // Array de arquivos de testes './testes/ValidacaoDeNormas.js' ], framework: 'jasmine', //Identificando o framework escolhido para escrita de testes. jasmineNodeOpts: { // opções passada para o Jasmine - Node showColors: true, //Utiliza colores na linha de comando para reportar defaultTimeoutInterval: 400000 //Tempo de espera antes do sistema apontar TimeOut }, directConnect: true, capabilities: { // Capacidades passada para o instância do webdriver browserName: 'chrome' // Qual o browser deverá ser utilizado }, onPrepare: function() { //função antes da realizaçãos arquivos de teste browser.ignoreSynchronization = true; //A página de login não é desenvolvida em angular, então é necessário para a sicronização para o protracotr não ficar procurando as tags do Angular browser.get('http://localhost:5555/#'); var EC = protractor.ExpectedConditions; browser.wait(EC.presenceOf(element(by.id('Username'))));//espera até o elemento de login aparecer para poder continuar var login = browser.driver.findElement(by.id('Username')); // localiza input com ID de Login var senha = browser.driver.findElement(by.id('Password')); // Localizando input de ID Password var btnEntrar = element(by.buttonText('ENTRAR')); // localização botão com texto de Entrar login.sendKeys('27331'); // login de acesso senha.sendKeys('sgpweb69'); // senha do sistema btnEntrar.click().then(function(){ browser.wait(EC.presenceOf(element(by.css('h1')))); // espera o h1 da outra página aparecer}, useAllAngular2AppRoots: true //Para o protractor indentifcar os comandos do Angular 2

45

}; if (process.env.TRAVIS) { // Configuração de Build config.capabilities = { browserName: 'firefox' }; } exports.config = config;

APÊNDICE 2

describe('Teste de Validação de Campos obrigatórios na tela de Normas', function(){ //função para retornar a data anual no formato dd/mm/aaaa function RetornaDataAtual(){ var hoje = new Date(); var dd = hoje.getDate(); var mm = hoje.getMonth()+1; var yyyy = hoje.getFullYear(); if(dd<10){ dd='0'+dd } if(mm<10){ mm='0'+mm } var hoje = dd+'/'+mm+'/'+yyyy; return hoje; }; it('Deve clicar no botão ', function(){ browser.get('http://localhost:5555/#/normas/cadastro'); browser.actions().click().perform(); browser.actions().click().perform(); var btnSalvar =element(by.partialButtonText('Salvar & Fechar')); btnSalvar.click().then(function(){ expect(element(by.css('.ui-growl-message p')).getText()).toBe('Selecione um tipo de norma. Número é obrigatório. Selecione o ano. Data de publicação é obrigatório. Inicio Vigência é obrigatório. Descrição / Ementa é obrigatório. Referência para local de publicação da norma é obrigatório.'); }); }); it('Deve inserir norma e validar Campos', function(){ //Localiza elemento com Id Tipo Norma e seleciona o item da terceira option. Após isso, clicar. var tipoDeNorma = element(by.id('tipoNorma')).all(by.tagName('option')).get(3); tipoDeNorma.click();

46

//Localiza elemento botão com texto de Salvar e Fechar e clica var btnSalvar =element(by.partialButtonText('Salvar & Fechar')); btnSalvar.click().then(function(){ //Espera que um tostar com class ui-gorwl-message apareça com o texto de validação expect(element(by.css('.ui-growl-message p')).getText()).toBe('Número é obrigatório. Selecione o ano. Data de publicação é obrigatório. Inicio Vigência é obrigatório. Descrição / Ementa é obrigatório. Referência para local de publicação da norma é obrigatório.'); }); }); it('Deve inserir um número de norma e não validar o campo de norma e não validar o campo de número', function(){ var numero = element(by.id('numero')); var aux2 = Math.floor(Math.random() * 9999); numero.sendKeys(aux2); //Localiza elemento botão com texto de Salvar e Fechar e clica var btnSalvar =element(by.partialButtonText('Salvar & Fechar')); btnSalvar.click().then(function(){ //Espera que um tostar com class ui-gorwl-message apareça com o texto de validação expect(element(by.css('.ui-growl-message p')).getText()).toBe('Selecione o ano. Data de publicação é obrigatório. Inicio Vigência é obrigatório. Descrição / Ementa é obrigatório. Referência para local de publicação da norma é obrigatório.'); }); }); it('Deve inserir uma data e validar os campos que não foram preenchidos', function(){ var ano = element(by.id('anoSelect')).all(by.tagName('option')).get(3); ano.click(); //Localiza elemento botão com texto de Salvar e Fechar e clica var btnSalvar =element(by.partialButtonText('Salvar & Fechar')); btnSalvar.click().then(function(){ //Espera que um tostar com class ui-gorwl-message apareça com o texto de validação expect(element(by.css('.ui-growl-message p')).getText()).toBe('Data de publicação é obrigatório. Inicio Vigência é obrigatório. Descrição / Ementa é obrigatório. Referência para local de publicação da norma é obrigatório.'); }); }); it('Deve inserir data de publicação e validar os outros campos não preenchidos', function(){ var dataPublicacao = element(by.id('dataPublicacaoInput')); dataPublicacao.sendKeys(RetornaDataAtual()); //Localiza elemento botão com texto de Salvar e Fechar e clica var btnSalvar =element(by.partialButtonText('Salvar & Fechar')); btnSalvar.click().then(function(){

47

expect(element(by.css('.ui-growl-message p')).getText()).toBe('Inicio Vigência é obrigatório. Descrição / Ementa é obrigatório. Referência para local de publicação da norma é obrigatório.'); }); }); it('Deve inserir data de Inicio de Vigência e validar outros campos não preenchidos', function(){ var dataInicio = element(by.id('dataVigenciaInicioInput')); dataInicio.sendKeys(RetornaDataAtual()); //Localiza elemento botão com texto de Salvar e Fechar e clica var btnSalvar =element(by.partialButtonText('Salvar & Fechar')); btnSalvar.click().then(function(){ //Espera que um tostar com class ui-gorwl-message apareça com o texto de validação expect(element(by.css('.ui-growl-message p')).getText()).toBe('Descrição / Ementa é obrigatório. Referência para local de publicação da norma é obrigatório.'); }); }); it('Deve inserir descrição e validar os outros registros ainda não preenchidos', function(){ element(by.id('descricaoEmenta')).sendKeys('TESTE AUTOMATIZADO DE VALIDAÇÃO'); //Localiza elemento botão com texto de Salvar e Fechar e clica var btnSalvar =element(by.partialButtonText('Salvar & Fechar')); btnSalvar.click().then(function(){ //Espera que um tostar com class ui-gorwl-message apareça com o texto de validação expect(element(by.css('.ui-growl-message p')).getText()).toBe('Referência para local de publicação da norma é obrigatório.'); }); }); });

APÊNDICE 3

describe('Teste de Verificação de Vigência --', function(){ //Função para gerar Dia Mes e Ano aleatorios function RetornaDataAleatoria(){ return (Math.floor(Math.random() * 31) +1) + '/' + (Math.floor(Math.random() * 12) +1 ) + '/' + (Math.floor(Math.random() * (2016-1990) + 1990)); } //função para gerar a Data atual function dataAtualFormatada(){ var data = new Date();

48

var dia = data.getDate(); if (dia.toString().length == 1) dia = "0"+dia; var mes = data.getMonth()+1; if (mes.toString().length == 1) mes = "0"+mes; var ano = data.getFullYear(); return dia+"/"+mes+"/"+ano; } //Função para gerar Data de ontem function ontemFormatada(){ var data = new Date(); var ontem = data.getDate() -1 ; if (ontem.toString().length == 1) ontem = "0"+ ontem; var mes = data.getMonth()+1; if (mes.toString().length == 1) mes = "0"+mes; var ano = data.getFullYear(); return ontem +"/"+mes+"/"+ano; } //Função executada antes de cada caso de teste, ou seja, cada 'It' beforeEach(function(){ browser.get('http://localhost:5555/#/normas/cadastro');//Antes do teste o sistema deve abrir a página de cadastro browser.sleep(3000);//Espera o carregamento da página browser.actions().click().perform(); }); it('Deve verificar o status default da pagina seja Sem vigência e os campos data em branco', function(){ //Verifica se o texto da vigência ao abrir a tela é Sem Vigência expect(element(by.partialButtonText("Sem vigência")).isPresent()).toBe(true); }); it('Deve Verificar Vigência Inválida - Data Fim maior que Data Inicio', function(){ //Seta a data no campo de Inicio Vigência var dataInicio = element(by.id('dataVigenciaInicioInput')); dataInicio.sendKeys('04/08/2060'); // Seta data no campo Fim Vigência var fimVigencia = element(by.id('dataVigenciaFimInput')); fimVigencia.sendKeys('01/08/2000'); // Verifica o texto do botão que indicia a vigência

49

expect(element(by.partialButtonText(" Vigência invalida")).isPresent()).toBe(true); });

it('Deve verificar Vigência Revogada', function(){ //Seta a data no campo de Inicio Vigência var dataInicio = element(by.id('dataVigenciaInicioInput')); dataInicio.sendKeys('07/08/2015'); // Seta data no campo Fim Vigência var fimVigencia = element(by.id('dataVigenciaFimInput')); fimVigencia.sendKeys('01/07/2016'); // Verifica o texto do botão que representa a Vigência expect(element(by.partialButtonText("Revogada")).isPresent()).toBe(true); });

it('Deve verificar vigência Valida - Cadastrada corretamente', function(){ //Seta a data no campo de Inicio Vigência var dataInicio = element(by.id('dataVigenciaInicioInput')); dataInicio.sendKeys('01/08/2000'); // Seta data no campo Fim Vigência var fimVigencia = element(by.id('dataVigenciaFimInput')); fimVigencia.sendKeys('02/08/3000'); // Verifica o texto do botão que representa a Vigência expect(element(by.partialButtonText("Vigente")).isPresent()).toBe(true); });

it('Deve verificar data fim em branco e vigência Valida', function(){ //Seta a data no campo de Inicio Vigência var dataInicio = element(by.id('dataVigenciaInicioInput')); dataInicio.sendKeys('01/08/2015'); // Verifica o texto do botão que representa a Vigência expect(element(by.partialButtonText("Vigente")).isPresent()).toBe(true); }); it('Deve verificar vigência Valida para data fim igual a data Atual', function(){ //Seta a data no campo de Inicio Vigência var dataInicio = element(by.id('dataVigenciaInicioInput')); dataInicio.sendKeys('01/08/1990'); // Seta data atual no campo Fim Vigência var fimVigencia = element(by.id('dataVigenciaFimInput')); fimVigencia.sendKeys(dataAtualFormatada()); // Verifica o texto do botão que representa a Vigência expect(element(by.partialButtonText("Vigente")).isPresent()).toBe(true); }); it('Deve verificar se a vigência esta revogada com uma data anterior que a data atual', function(){ //Seta a data no campo de Inicio Vigência

50

var dataInicio = element(by.id('dataVigenciaInicioInput')); dataInicio.sendKeys('01/08/1999'); // Seta data atual no campo Fim Vigência var fimVigencia = element(by.id('dataVigenciaFimInput')); fimVigencia.sendKeys(ontemFormatada()); // Verifica o texto do botão que representa a Vigência expect(element(by.partialButtonText("Revogada")).isPresent()).toBe(true); }); });

APÊNDICE 4

describe('Cadastro de Normas --', function(){ function RetornaDataAleatoria(){ return (Math.floor(Math.random() * 31) +1) + '/' + (Math.floor(Math.random() * 12) +1 ) + '/' + (Math.floor(Math.random() * (2016-1990) + 1990)); } var contadorInicial = 0; var contadorFinal = 0;

it('Abrir tela de grid', function(){ browser.get('http://localhost:5555/#/normas'); browser.sleep(5000); browser.actions().click().perform(); browser.actions().click().perform(); });

it('contabiliza registros', function(){ function getPrimeiraCedula() { var registros = element(by.className('ui-datatable-data ui-widget-content')).all(by.tagName('tr')); var primeiralinha = registros.first(); var coluna = primeiralinha.all(by.tagName('td')).first(); var primeiroTexto = coluna.getText(); return primeiroTexto; }; var promiseWhile = function(condition, action) { return new Promise(function(resolve, reject) { var inner = function(condition, action) { condition().then(function(result) { if (result) {

51

action().then(inner.bind(null, condition, action)); } else { resolve(); } }); }; inner(condition, action); }); }; promiseWhile( function() { return new Promise( function(resolve, reject) { getPrimeiraCedula().then(function(conteudo) { var areNotEquals = (conteudo !== 'No records found'); resolve(areNotEquals); browser.sleep(1000); }); }); }, function() { return new Promise(function(resolve, reject) { var registros = element(by.className('ui-datatable-data ui-widget-content')).all(by.tagName('tr')); var prom = registros.count().then(function(resultado){ contadorInicial += resultado; element(by.className('zmdi zmdi-caret-right')).click().then(function() { resolve(); return; }); }); }); }).then(function() { }); }); it('Cadastrando norma Vigente', function(){ element(by.linkText('Novo')).click(); browser.sleep(8000); browser.actions().click().perform(); browser.actions().click().perform(); //Gera loop para incluri 10 tags no cadastro de nroma for (var i = 0; i < 11; i++) { element(by.id('tagInput')).sendKeys('tag ' + i); browser.sleep(100);

52

element(by.id('tagInput')).sendKeys(protractor.Key.TAB); } browser.sleep(100); //localiza o droplist com id TipoNorma e verifica todos os options var tipoDeNorma = element(by.id('tipoNorma')).all(by.tagName('option')); //Seleciona uma norma aleatoria do droplist tipoDeNorma.count().then(function (opcao){ return Math.floor(Math.random() * opcao); }).then(function (escolhaopcao){ tipoDeNorma.get(escolhaopcao).click(); }); //Localiza elemento com Id numero e seta valor inteiro aleatorio até 9999 var numero = element(by.id('numero')); var aux2 = Math.floor(Math.random() * 9999); numero.sendKeys(aux2); //localiza element com id AnoSelect e seleciona todos os options, seleciona randomicamente valor de array de 218 e clica var aux3 = Math.floor(Math.random() * 218); var ano =element(by.id('anoSelect')).all(by.tagName('option')).get(aux3); ano.click(); browser.sleep(200); //localiza elemento com id data publicação e seta data Aleatoria var dataPublicacao = element(by.id('dataPublicacaoInput')); dataPublicacao.sendKeys(RetornaDataAleatoria()); browser.sleep(200) //localiza elemento com id data inicio e seta data Aleatoria var dataInicio = element(by.id('dataVigenciaInicioInput')); dataInicio.sendKeys(RetornaDataAleatoria()); browser.sleep(300); expect(dataInicio).not.toBe(null); //localiza elemento com id Descrição e seta valor de teste automatização element(by.id('descricaoEmenta')).sendKeys('TESTE AUTOMATIZADO'); //localiza elemento botao com text de Referência e clica, seleciona opção DOE. element(by.buttonText('Referência')).click(); element(by.linkText('DOE')).click(); var doe = element(by.tagName('link-externo')).element(by.tagName('input')); doe.sendKeys('http://wikicti.tjmt.jus.br/index.php?title=P%C3%A1gina_principal'); element(by.partialButtonText('Salvar')).click();

53

}); it('Deve contabilizar os registros novamente após adicionar e verificar se foi adicionado um único registros na grid', function(){ browser.sleep(10000); function getPrimeiraCedula() { var registros = element(by.className('ui-datatable-data ui-widget-content')).all(by.tagName('tr')); var primeiralinha = registros.first(); var coluna = primeiralinha.all(by.tagName('td')).first(); var primeiroTexto = coluna.getText(); return primeiroTexto; } var promiseWhile = function(condition, action) { return new Promise(function(resolve, reject) { var inner = function(condition, action) { condition().then(function(result) { if (result) { action().then(inner.bind(null, condition, action)); } else { resolve(); } }); }; inner(condition, action); }); }; promiseWhile( function() { return new Promise( function(resolve, reject) { getPrimeiraCedula().then(function(conteudo) { var areNotEquals = (conteudo !== 'No records found'); resolve(areNotEquals); browser.sleep(1000); }); }); }, function() { return new Promise(function(resolve, reject) { var registros = element(by.className('ui-datatable-data ui-widget-content')).all(by.tagName('tr')); var prom = registros.count().then(function(resultado){ contadorFinal += resultado;

54

element(by.className('zmdi zmdi-caret-right')).click().then(function() { resolve(); return; }); }); }); }).then(function() { expect(contadorFinal).toBe(contadorInicial+1); }); }); });