Teaching Test - Ambiente de Apoio Ao Processo de Ensino-Aprendizagem de Conteúdos de Teste de Software

INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNLOGIA DO
AMAZONAS
Thais Elaizza da Rocha Colares
TEACHING-TEST: AMBIENTE DE APOIO AO PROCESSO DE ENSINO-

APRENDIZAGEM DE CONTEÚDOS DE TESTE DE SOFTWARE
Manaus, Amazonas – Brasil

2018
INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNLOGIA DO
AMAZONAS
Thais Elaizza da Rocha Colares
TEACHING-TEST: AMBIENTE DE APOIO AO PROCESSO DE ENSINO-

APRENDIZAGEM DE CONTEÚDOS DE TESTE DE SOFTWARE
Orientadora: Profa. Dra. Joyce Miranda dos Santos.
Trabalho de Conclusão de Curso

apresentado à banca examinadora do
Curso Superior de Tecnologia em
Desenvolvimento de Software do Instituto
Federal de Educação, Ciência e
Tecnologia do Amazonas – IFAM
Campus Manaus Centro, como requisito
para o cumprimento da disciplina TCC II
– Projeto de Software
Manaus, Amazonas – Brasil

2018
RESUMO
A realização de testes de software tem sido fundamental para garantir a

qualidade do produto que vai ser entregue ao usuário final. Muitas vezes, a
compreensão efetiva de conteúdos relativos à aplicação de testes de software não ocorre
de forma efetiva devido à falta da adoção de uma abordagem de ensino mais prática.
Com base nessa realidade, este trabalho propõe o desenvolvimento de um ambiente
computacional que apoie o ensino de teste de software de forma interativa e intuitiva,
abordando de forma específica conteúdos relacionados à aplicação das técnicas de
partição de equivalência e de análise do valor limite que são sugeridas para a criação de
casos de teste de qualidade.
LISTA DE FIGURAS
Figura 1 - Formulário para identificação de classes de equivalência................................7

Figura 2 - Exemplo utilizando intervalo...........................................................................8
Figura 3 - Exemplo utilizando valor específico................................................................8
Figura 4 - Exemplo utilizando conjunto de valores...........................................................9
Figura 5 - Exemplo utilizando condição lógica...............................................................10
Figura 6 - Exemplo da técnica de Análise de valor limite..............................................10
Figura 7 - Exemplo utilizando análise de valor limite....................................................11
Figura 8 - Ciclo do Scrum...............................................................................................13
Figura 9 - Diagrama de Caso de Uso do Aluno...............................................................24
Figura 10 - Diagrama de Caso de Uso do Tutor..............................................................25
Figura 11- Diagrama de classes.......................................................................................26
Figura 12 - Diagrama de Sequência................................................................................29
Figura 13 - Diagrama de Atividades...............................................................................30
Figura 14 - Modelo Entidade Relacionamento................................................................31
Figura 15 - Tela de perfil Fonte: Própria autora..............................................................33
Figura 16 -Tela de login Fonte: Própria autora...............................................................34
Figura 17 - Tela visualizar questão.................................................................................35
Figura 18 - Tela escolher tipo de variável.......................................................................35
Figura 19 - Tela Tipo condição de entrada......................................................................36
Figura 20 - Tela selecionar variável de entrada...............................................................36
Figura 21 - Tela selecionar variável de entrada - Variável selecionada..........................37
Figura 22 - Tela escolher condição de entrada................................................................38
Figura 23 - Tela identificar condição de entrada.............................................................38
Figura 24 - Tela para criação de classes de equivalência................................................39
Figura 25 - Tela criar classes de equivalência................................................................39
Figura 26 - Tela visualizar tabela de casos de teste.........................................................40
Figura 27 - Tela preencher casos de teste........................................................................41
Figura 28 - Tela preencher casos de teste........................................................................41
Figura 29 - Classe JUnit gerada......................................................................................42
Figura 30 - Tela Execução dos casos de teste................................................................43
Figura 31 - Visualizar respostas......................................................................................44
Figura 32 - Features da ferramenta..................................................................................55
Figura 33 – Estórias.........................................................................................................56
Figura 34 – Estória criar tela de login.............................................................................57
Figura 35- Estória criar tela visualizar questão...............................................................57
Figura 36- Estória criar tela escolher tipo de condição de entrada..................................58
Figura 37- Estória criar telas identificar condição de entrada e classes de equivalência 59
Figura 38- Estória criar tela visualizar tabela de casos de teste......................................59
Figura 39- Estória criar tela montar casos de teste..........................................................60
Figura 40- Estória ajustes e correções.............................................................................61
Figura 41- Estória revisão do projeto..............................................................................61
LISTA DE TABELAS
Tabela 1- Tabela comparativa.........................................................................................21

Tabela 2 - Requisitos funcionais.....................................................................................23
Tabela 3 - Requisitos não funcionais...............................................................................24
Tabela 4 - Dicionário de classes referente à função de cada classe................................27
Sumário
1 INTRODUÇÃO.........................................................................................................1
1.1 PROBLEMATIZAÇÃO.................................................................................3
1.2 JUSTIFICATIVA............................................................................................3
1.3 OBJETIVOS...................................................................................................3
1.3.1 Objetivo geral..............................................................................................3
1.3.2 Objetivos específicos...................................................................................3
1.4 ESTRUTURA DO TRABALHO....................................................................4
2 FUNDAMENTAÇÃO TEÓRICA.............................................................................5
2.1 TESTE DE SOFTWARE................................................................................5
2.1.1 CLASSIFICAÇÃO DOS TESTES DE SOFTWARE.................................5
2.2 TECNOLOGIAS E PADRÕES UTILIZADOS...........................................13
2.2.1 SCRUM.....................................................................................................13
2.2.2 UML - Unified Modeling Language........................................................14
2.2.3 Linguagem de Programação Java..............................................................15
2.2.4 JSF – Java Server Faces............................................................................15
2.2.5 PrimeFaces................................................................................................16
2.2.6 Hibernate/JPA............................................................................................16
2.2.7 MySQL......................................................................................................17
2.2.8 MVC – Model View Controller................................................................17
2.3 TRABALHOS RELACIONADOS...............................................................18
2.3.1 ProgTest.....................................................................................................18
2.3.2 BugHunt....................................................................................................19
2.3.3 Under Attack.............................................................................................19
3 PROPOSTA DO SISTEMA....................................................................................22
4 ANÁLISE E ESPECIFICAÇÃO DO SISTEMA....................................................23
4.1 REQUISITOS DO SISTEMA.......................................................................23
4.2 MODELAGEM DO SISTEMA....................................................................24
4.2.1 Diagrama de Casos de Uso........................................................................24
4.2.2 Diagrama de Classes..................................................................................25
4.2.3 Diagrama de Sequência.............................................................................28
4.2.4 Diagrama de Atividades............................................................................30
4.2.5 Modelo do Banco de Dados......................................................................31
5 IMPLEMENTAÇÃO...............................................................................................32
5.1 DETALHES DO DESENVOLVIMENTO DA FERRAMENTA................32
5.2 APRESENTAÇÃO DO SISTEMA..............................................................33
6 CONCLUSÕES E TRABALHOS FUTUROS........................................................45
6.1 CONCLUSÕES.............................................................................................45
6.2 TRABALHOS FUTUROS............................................................................45
APÊNDICE A – DESCRIÇÃO DOS CASOS DE USO.............................................49
APÊNDICE B – IMPLEMENTAÇÃO DA FERRAMENTA....................................55
1
1 INTRODUÇÃO
Utilizados em diversas atividades, os softwares estão cada vez mais integrados à

rotina das pessoas. Por esse motivo, a preocupação com a garantia da qualidade vem
ganhando mais destaque durante o processo de desenvolvimento desse tipo de produto.
A realização de testes de software tem sido fundamental para garantir a qualidade do
produto que vai ser entregue ao usuário final (BASTOS, 2012).
Segundo Pressman (2011), teste de software pode ser definido como um

conjunto de atividades que podem ser planejadas com antecedência e executadas
constantemente. Essas atividades são realizadas com o objetivo de controlar a qualidade
do produto, garantindo que o sistema atenda às funcionalidades prometidas e que estas
funcionalidades estejam funcionando conforme o esperado.
A elaboração de casos de teste é essencial para o sucesso das atividades de teste

em um projeto de software. São eles que são responsáveis por identificar as pré-
condições para a execução dos testes, as entradas a serem informadas pelo testador (de
forma manual ou com apoio ferramental) e os resultados esperados a partir desta ação
(CRAIG; JASKIEL, 2002).
De uma forma geral, os testes de software podem ser aplicados utilizando dois
tipos de técnicas: a funcional e a estrutural. A técnica funcional, também conhecida
como técnica caixa preta, tem como foco a validação do comportamento externo da
funcionalidade que está sendo testada. O nome caixa preta vem do sentido de que nesse
tipo de teste, não é necessário saber a estrutura interna de como o código foi
implementado ou a tecnologia que foi utilizada. Nesse tipo de análise, essas questões
são transparentes para os analistas de teste. O objetivo dessa técnica é validar no
software implementado se os requisitos presentes na documentação foram devidamente
atendidos. A técnica estrutural, também conhecida como técnica caixa branca, foca no
comportamento interno do item que está sendo testado. Seu objetivo é testar o código-
fonte explorando todos os fluxos possíveis. O foco deste trabalho está no processo
ensino-aprendizagem da aplicação da técnica funcional.
2
Dentre as técnicas utilizadas para aprimorar e otimizar a aplicação dos testes

funcionais estão: a técnica de partição de equivalência e a técnica de análise do valor
limite. A técnica de partição de equivalência consiste em diminuir a quantidade de casos
de teste a serem criados, detectando conjuntos de entradas e os dividindo em classes, de
forma que o comportamento do sistema seja o mesmo para qualquer entrada em uma
mesma classe. Dessa forma, não é necessário testar todas as entradas possíveis, apenas
uma opção para cada classe. A técnica de análise do valor limite valida valores-limite de
um domínio e complementa a partição de equivalência selecionando valores das
extremidades das classes de equivalência. Esses critérios auxiliam na elaboração de
casos de teste para ajudar na validação do software (BASTOS, 2012).
Apesar da importância do teste de software, a compreensão desse tipo de

conteúdo por alunos dos cursos de computação muitas vezes não ocorre de forma
efetiva devido à falta da adoção de uma abordagem de ensino mais prática em sala de
aula (CARRIGTON, 1997). No caso de disciplinas específicas de programação, os
alunos possuem uma ampla variedade de ambientes como o URI Online Judge (TONIN;
BEZ, 2013) e ProgTest (DE SOUZA et al. 2011), que foram criados com o intuito de
aumentar a motivação e a prática dos estudantes em conteúdos específicos. A partir do
uso dessas ferramentas, os alunos têm a oportunidade de praticar o conteúdo que foi
ensinado, criando soluções para problemas solicitados pelo professor de uma forma
prática e didática. Certamente várias ferramentas já foram propostas para apoiar o
ensino de testes de software. Mas infelizmente, ainda é uma pequena parcela desses
softwares que vem sendo efetivamente sendo usada em sala de aula. Nesse sentido, é
preciso que os cursos acadêmicos da área de computação tratem de forma menos
superficial o ensino de teste de software, utilizando ferramentas que propiciem ao aluno
uma fixação maior dos conteúdos vistos em sala de aula e que o leve a uma prática mais
efetiva desses conteúdos.
Dentro do contexto apresentado, este trabalho tem como objetivo propor e

implementar uma ferramenta web que apoie o processo de ensino-aprendizagem nas
disciplinas de Teste de Software, explorando inicialmente de forma específica
conteúdos relativos à aplicação das técnicas de partição de equivalência e de análise do
valor limite para a criação de casos de teste de qualidade.
3
1.1 PROBLEMATIZAÇÃO
Como suprir no cenário acadêmico a necessidade de abordagens mais práticas a

serem aplicadas no processo de ensino-aprendizagem de conteúdos relacionados a
Testes de Software, de forma a promover a fixação desses conteúdos e o interesse por
parte dos alunos de forma mais efetiva?
1.2 JUSTIFICATIVA
A principal motivação para a realização deste trabalho está na possibilidade de

disponibilizar um ambiente que seja capaz de suprir parte das necessidades referentes ao
ensino de teste de software, apresentando uma ferramenta web dinâmica capaz de
abordar de uma forma prática, interativa e intuitiva conteúdos relativos ao ensino das
técnicas de partição de equivalência e de análise do valor limite que são sugeridas para a
criação de casos de teste de qualidade.
1.3 OBJETIVOS
1.3.1 Objetivo geral
Este trabalho tem como objetivo desenvolver uma ferramenta web que apoie o
processo de ensino-aprendizagem de conteúdos referentes ao ensino de Testes de
Software, explorando inicialmente de forma específica o ensino das técnicas de partição
de equivalência e de análise do valor limite de forma dinâmica, prática, interativa e
intuitiva, visando a construção de casos de teste de qualidade.
1.3.2 Objetivos específicos
 Disponibilizar um material de referência sobre os conceitos relacionados a teste

de software, mais especificamente sobre a aplicação das técnicas de partição de
equivalência e análise de valor limite;
4
 Realizar um levantamento sobre soluções existentes que ofereçam apoio ao

processo de ensino-aprendizagem de conteúdos relativos a teste de software a
fim de verificar pontos negativos e positivos em trabalhos similares;
 Definir e especificar requisitos da ferramenta proposta nesse trabalho;
1.4 ESTRUTURA DO TRABALHO
O presente trabalho está organizado da seguinte forma. No Capítulo 2 são

apresentados conceitos fundamentais que auxiliam o entendimento deste trabalho,
tecnologias e padrões que serão utilizados durante o seu desenvolvimento e uma breve
descrição sobre os trabalhos relacionados. O Capítulo 3 apresenta a proposta do
trabalho. No capítulo 4 são apresentados a análise e especificação da ferramenta. No
Capítulo 5 são apresentados detalhes sobre a implementação. Por fim, o Capítulo 6
apresenta as conclusões e os trabalhos futuros, que poderão ser desenvolvidos a partir
deste trabalho.
5
2 FUNDAMENTAÇÃO TEÓRICA
2.1 TESTE DE SOFTWARE
A realização de testes é uma atividade fundamental que deve ser realizada

durante o processo de desenvolvimento de um software com o objetivo de revelar e
identificar falhas para que estas possam ser corrigidas antes da entrega do produto final.
Segundo Myers (2004), processos de desenvolvimento de software que não
aplicam de forma efetiva à atividade de teste acabam extrapolando o orçamento e o
cronograma previstos. Um estudo mostra que de 30% a 50% dos defeitos dos programas
podem ser removidos com testes unitários e testes de sistema, além disso, as revisões de
código podem reduzir de 20% a 30% de defeitos.
O teste de produtos de software envolve basicamente quatro etapas:
planejamento de testes, projeto de casos de teste, execução e avaliação dos resultados
dos testes. Essas atividades devem ser desenvolvidas ao longo do próprio processo de
desenvolvimento de software. Defeitos encontrados nas fases iniciais do processo
tendem a tornar a correção do software menos complexa e custosa.
O projeto de casos de teste tem como objetivo criar uma série de testes que tenha
a mais alta probabilidade de descobrir erros no software. De forma geral, um caso de
teste identifica as pré-condições para a execução dos testes, as entradas a serem
informadas pelo testador e os resultados esperados a partir desta ação (CRAIG;
JASKIEL, 2002).
2.1.1 CLASSIFICAÇÃO DOS TESTES DE SOFTWARE
Segundo Bastos, et al., (2012), o nível do teste identifica a fase do

desenvolvimento na qual um determinado teste deve ser aplicado. Nesse sentido,
existem quatro tipos de teste: teste de unidade, teste de iteração, teste de sistema e teste
de aceitação.
6
 Teste de unidade: são testes na maioria das vezes feitos pelo programador. Tem
como objetivo testar a menor unidade do código (componente ou módulo do
software).
 Teste de integração: testa as interações entre os componentes construídos. É
realizado ao final de cada iteração com o objetivo de validar as funcionalidades
referentes aos casos de uso do sistema.
 Teste de sistema: executa o sistema inteiro incluindo interfaces. Serve para
validar as funcionalidades por meio de casos de teste elaborados por um analista
de teste em um ambiente de teste.
 Teste de aceitação: é um teste de responsabilidade do cliente, que ocorre antes
da implantação do software. Verifica se o software atende aos requisitos de
especificação. O objetivo desse teste é verificar se o sistema está pronto para ser
usado pelos usuários finais.
As técnicas de teste estão divididas entre os testes caixa-branca e testes caixa-

preta
 Teste caixa-branca: também conhecido como técnica estrutural. Focam no

comportamento interno do item que está sendo testado, com objetivo de verificar
o código-fonte explorando todos os fluxos possíveis. Utilizam teste de condição,
teste de fluxo de dados, teste de ciclos e teste de caminhos lógicos para avaliar
os aspectos internos do software.
 Teste caixa-preta: também conhecido como técnica funcional. Verifica se as
saídas do sistema estão de acordo com os resultados esperados. Foca a validação
de requisitos funcionais sem levar em consideração a estrutura interna de
implementação do código. Os principais critérios utilizados na técnica funcional
são: Partição de equivalência, Análise de valor limite, Tabela de decisão, Teste
de transição de estados e Teste de caso de uso.
Neste trabalho, serão explorados especificamente testes de unidade caixa-preta

com a aplicação das técnicas de partição de equivalência e de análise do valor limite.
7
2.1.1.1 PARTIÇÃO DE EQUIVALÊNCIA
Segundo Pressman (2011), a técnica de Partição de Equivalência divide o

domínio de entrada de um programa em classes de equivalência, que identificam grupos
de dados que possuam comportamentos parecidos dentro do programa. Dessa forma, o
número de casos de teste é reduzido, porém mantendo um nível de cobertura razoável
(BASTOS et al., 2012).
Para Myers (2004), as classes de equivalência são identificadas por meio de
condições de entrada (sentenças ou frases na especificação do programa), e pela divisão
das condições de entrada em dois ou mais grupos. Depois de identificar as classes é
possível especificar os casos de teste.
A forma de identificação de classes de equivalência mostrada por Myers (2004)
pode ser observada na Figura 1.
Figura 1 - Formulário para identificação de classes de equivalência.
As classes são classificadas em dois tipos: classe válida que representa as

entradas válidas do programa e classe inválida que representa os valores de entrada
errados. (MYERS, 2004). Para Pressman (2011), classes de equivalência podem ser
definidas de acordo com a ajuda das seguintes regras:
8
1. Intervalo: se uma condição de entrada especifica um intervalo, são definidas

uma classe de equivalência válida e duas classes de equivalência inválidas.
Exemplo: Validar números referentes aos meses do ano.

Entrada válida: números entre 1 e 12.
Entradas inválidas: números menores que 1 e maiores que 12.
A resolução do exemplo está disponível na Figura 2.
Figura 2 - Exemplo utilizando intervalo.

Fonte: ByeBug – Aprendendo Teste de Software1
2. Valor Específico: se uma condição de entrada requer um valor específico, são

definidas uma classe de equivalência válida e duas classes inválidas.
Exemplo: Validar valor a pagar.

Entrada válida: valor maior que zero.
Entradas inválidas: valores iguais ou menores que zero, além de valores não
numéricos.
Figura 3 - Exemplo utilizando valor específico
1
Disponível em: <http://www.inf.ufsc.br/~fabiane.benitti/byebug/#> Acesso em ago. 2017.
9
3. Conjunto de Valores: se uma condição de entrada especifica um membro de

um conjunto, são definidas uma classe de equivalência válida e uma classe de
equivalência inválida.
Exemplo: Validar números positivos.

Entradas válidas: valores iguais ou maiores que zero.
Entradas inválidas: valores menores que zero.
Figura 4 - Exemplo utilizando conjunto de valores

4. Condição Lógica: se uma condição de entrada for booleana são definidas uma
classe válida e uma classe inválida.
Exemplo: Validar cliente ativo

Um caso de teste para validar se o cliente está ativo (verdadeiro).
Um caso de teste para validar se não está ativo (falso).
2
3
10
Figura 5 - Exemplo utilizando condição lógica

2.1.1.2 ANÁLISE DE VALOR LIMTE
Molinari (2003) conceitua a Análise de Valor Limite como uma técnica que tem
a atenção voltada para os limites de cada classe de equivalência. Essa técnica foi
desenvolvida levando em consideração que o limite de uma partição de equivalência é o
ponto com a maior probabilidade de apresentar falhas (PRESSMAN, 2011).
Na Figura 6 está sendo apresentado um exemplo de aplicação da técnica de
Análise de valor limite em um intervalo de valores.
Figura 6 - Exemplo da técnica de Análise de valor limite

Fonte: Própria autora
Segundo Pressman (2011), essa técnica possui as seguintes diretrizes:
1. Intervalo de valores: se uma condição de entrada especificar um intervalo

delimitado pelos valores a e b, os casos de teste devem ser elaborados com
valores a e b imediatamente acima e abaixo de a e b.
4
11
2. Série de valores: Se uma condição de entrada especificar uma série de valores,

os casos de testes deverão ser criados usando os valores máximo e mínimo.
Também serão testados os valores imediatamente acima e abaixo dos valores
máximo e mínimo.
3. Estrutura de dados: se estruturas internas de dados do programa prescreverem
fronteiras, deve-se elaborar casos de teste para exercitar a estrutura de dados na
fronteira.
4. Classes de saída: aplicar as diretrizes 1 e 2 às condições de saída.
Considere um exemplo utilizando o gerenciador de cores da ferramenta Paint,

(ferramenta presente no sistema operacional Windows), onde é usado como entrada o
modelo de cores RGB que permite a entrada de valores entre 0 e 255:
Figura 7 - Exemplo utilizando análise de valor limite
A Figura 7 ilustra a elaboração de casos de casos de teste utilizando a técnica de

Análise de valor limite, conforme as diretrizes citadas anteriormente.
Na coluna entrada foi informado o modelo de cores RGB e na coluna ao lado o

intervalo de valores aceitos para esse modelo. Neste caso a primeira diretriz foi
aplicada, logo valores imediatamente acima e abaixo dos limites devem ser validados.
Por esse motivo existe um caso de teste para validar os valores aceitos entre 0 e 255.
Um caso de teste para validar os valores abaixo de zero não permitidos e outro caso de
teste para validar os valores não permitidos acima de 255.
5
12
3.
13
2.2 TECNOLOGIAS E PADRÕES UTILIZADOS
Nessa seção, serão apresentadas as tecnologias e processos que serão utilizados

durante o desenvolvimento deste trabalho.
2.2.1 SCRUM
O Scrum é um processo iterativo e incremental usado para o desenvolvimento

ágil de software. É geralmente aplicado no gerenciamento de projetos que possuem
prazos apertados. Essa metodologia trabalha com Sprints, que são ciclos curtos de
desenvolvimento e entrega do software (PRESSMAN, 2011). A Figura 8 exemplifica o
funcionamento e o clico de uma Sprint.
Figura 8 - Ciclo do Scrum.
 Product Backlog: priorização das funcionalidades do produto desejadas pelo

cliente;
 Sprint Backlog: lista de tarefas que serão implementadas em uma Sprint;
 Sprint Review: é uma reunião informal feita ao final de cada Sprint com o
objetivo de avaliar o que foi feito e se há necessidade de realizar alterações no
backlog;
14
 Sprint Retrospective: realizado após o fechamento da Sprint a fim de analisar os

pontos positivos e negativos do que foi realizado;
 Product Planning: reunião onde são discutidos e planejados os trabalhos que
serão feitos na Sprint. Também são discutidos o tempo que será gasto para cada
trabalho;
 Daily Scrum: são reuniões diárias curtas, onde os integrantes falam o que
fizeram, o que estão fazendo e se há algum impedimento na execução do seu
trabalho;
Durante o processo de desenvolvimento deste trabalho será utilizado o artefato

Product Backlog para dar prioridade de desenvolvimento para as funcionalidades mais
importantes do sistema. Também será necessário definir todo o planejamento da Sprint,
e por esse motivo será usado o Sprint Backlog. As Sprints terão a duração de duas a
quatro semanas e a cada final de ciclo as funcionalidades definidas no Sprint Planning
deverão ser apresentadas.
Optou-se por não utilizar a Daily Scrum pelo fato de haver apenas uma pessoa
no processo de desenvolvimento. Logo, as reuniões diárias se tornarão reuniões
semanais para se adaptar as necessidades do projeto.
2.2.2 UML - Unified Modeling Language
A UML é uma linguagem usada para modelar sistemas orientados a objeto. É

voltada para a visualização, especificação, construção e documentação de artefatos
(BOOCH, et al., 2006). A importância de modelar um sistema antes do seu
desenvolvimento pode trazer benefícios como uma melhor comunicação entre os
envolvidos na implementação do projeto, uma melhor compreensão e análise do
sistema, torna a programação e a manutenção do código mais fácil, e diminui a
porcentagem de erros.
Foram utilizados no planejamento deste trabalho os seguintes diagramas da

UML: Diagrama de Caso de Uso, Diagrama de Classes, Diagrama de Sequência e
Diagrama de Atividade.
15
2.2.3 Linguagem de Programação Java
Java é uma linguagem de programação orientada a objeto criada pela Sun

Microsystems. Surgiu inicialmente com a finalidade de ser utilizada em sistemas de
dispositivos eletrônicos, como vídeo cassetes, TVs e aparelhos de TV a cabo. Porém,
com a chegada da Web (Word Wide Web) passou a ser utilizada na criação de páginas
Web por meio dos denominados applets (DEITEL, 2010).
Hoje em dia, Java é a linguagem mais utilizada no desenvolvimento de páginas

web de conteúdo dinâmico e interativo. Por esse motivo, optou-se por utilizar essa
linguagem durante o processo de implementação deste trabalho.
2.2.4 JSF – Java Server Faces
É um framework de código aberto, de fácil usabilidade, que permite o

desenvolvimento de aplicações Java web. Está incorporado à especificação Java EE.
É composto por módulos como eventos, componentes, navegabilidade,

backbeans e validação e conversões. Possui características baseadas no padrão MVC, ou
seja, aplica a separação entre visualização e regras de negócio. No JSF a camada
controller fica sob a responsabilidade de um Faces Servlet que tem função de receber e
encaminhar requisições para a camada model e em seguida responder essas requisições.
A camada modelo é composta de classes e de regras de negócio, essa camada tem a
responsabilidade de receber informações da camada view e executar as regras de
negócio. E a camada view resume-se à visão do usuário, além de ser composta por uma
hierarquia de componentes organizados (SCHALK; BURNS; HOLMES, 2006.).
Esse framework foi escolhido para ser utilizado no desenvolvimento deste

trabalho pela facilidade de ser manuseado, por ter código aberto e por possuir
componentes visuais pré-estabelecidos que contribuem para uma implementação mais
rápida.
16
2.2.5 PrimeFaces
O PrimeFaces é um framework da Prime Teknoloji, possui código aberto e

oferece vários componentes para a criação de aplicações web mais eficientes. É
considerado a melhor biblioteca de componentes JSF disponível atualmente. A
biblioteca PrimeFaces não possui dependências, oferece componentes como Data Table,
Auto Complete, HTML Editor, componentes construídos com Ajax no padrão JSF 2.0,
que tem como objetivo facilitar as chamadas assíncronas ao servidor (REDDY, 2013).
Optou-se por usar o PrimeFaces pelo fato de possuir código aberto, por
disponibilizar uma boa documentação com exemplos de código, além de apresentar uma
boa usabilidade.
2.2.6 Hibernate/JPA
Hibernate é uma ferramenta open source de mapeamento objeto-relacional

(ORM) mais utilizada no mercado. É acessada por meio da especificação JPA (Java
Persistence API), que trabalha com mapeamentos, entidades, interfaces para o
gerenciamento de persistência e linguagem de consulta. Suas principais implementações
são Hibernate da JBoss, EclipseLink da Eclipse Foundation e o OpenJPA da Apache
(HIBERNATE,2016).
A ferramenta Hibernate gera o código SQL para qualquer banco de dados,

tornando possível a troca de banco de dados sem a necessidade de realizar qualquer
alteração no código Java (HIBERNATE,2016).
Neste trabalho será adotado o Hibernate acompanhado do JPA. Optou-se por

esse framework por este ser de open sourse, além de dar suporte à implementação de
conceitos do paradigma orientado a objetos, e ser um framework que provê alto
desempenho e confiança.
17
2.2.7 MySQL
MySQL é um sistema de gerenciamento de banco de dados (SGBD). É um dos

SGBD’s mais populares do mundo, sendo utilizado em grandes empresas como, NASA,
HP, Nokia, Sony, U.S. Federal Reserve Bank, Associated Press, Alcatel, Cisco Systems
e Google.
O MySQL possui uma lista de características que o fizeram se tornar um dos

SGBD’s mais utilizados em todo mundo. Algumas dessas características são:
portabilidade, compatibilidade, excelente desempenho e estabilidade, exige poucos
recursos de hardware, é um software livre, suporta triggers, cursors, stored procedures,
functions e possui interface gráfica (MYSQL, 2017).
Optou-se pela utilização do MySQL neste trabalho pelo fato de ser um SGBD
gratuito, além de possuir todas as outras características mencionadas no parágrafo
acima.
2.2.8 MVC – Model View Controller
O MVC é um padrão arquitetural de software que divide a aplicação em

camadas de Modelo, Visão e Controlador criando uma maior independência entre as
camadas e facilitando a manutenção da aplicação. A camada Modelo é responsável por
gerenciar dados e as operações associadas a esses dados, já a camada de Visão gerencia
como os dados serão mostrados para o usuário e a camada Controlador que faz a
comunicação entre as camadas Modelo e Visão através das interações do usuário no
sistema (SOMMERVILLE, 2011).
Neste trabalho o padrão MVC será utilizado pelo motivo de apresentar

vantagens e as características que serão necessárias para o desenvolvimento do projeto.
18
2.3 TRABALHOS RELACIONADOS
Os cursos de graduação na área de computação adotam como referência as

diretrizes propostas pela Sociedade Brasileira de Computação (SBC) e pela Comissão
de Especialistas de Ensino de Computação e Informática (CEEINF) (DA SILVA, 2015).
Apesar de serem adotados em grande parte das universidades, a falta de pessoas
qualificadas para atuar na área de testes ainda é bem perceptível (SILVA, et al., 2013).
Segundo Chen e Poon (2004), os conteúdos de teste nos cursos de computação
são abordados de maneira superficial e acabam contribuindo para a situação atual. Com
o objetivo de apoiar o ensino de teste tanto no meio acadêmico quanto no meio
empresarial, muitos trabalhos estão sendo propostos na literatura. Cada trabalho adota
uma abordagem diferenciada com focos específicos dentro do conteúdo de teste de
software. A seguir, são apresentados alguns desses trabalhos.
2.3.1 ProgTest
É um ambiente web desenvolvido por De Souza, et al., (2011), para submissão e

avaliação automática de trabalhos de programação. O Progtest aborda o ensino de teste
de software em disciplinas introdutórias, utiliza técnicas e critérios de teste para avaliar
os programas e conjuntos de teste elaborados pelos alunos.
O ambiente trabalha com as funcionalidades de submissão e feedback
automático do programa que foi submetido. Caso o feedback tenha resultado negativo
falhando em algum caso de teste, o aluno pode corrigir os erros encontrados na sua
resolução e criar novos testes para validar o que foi corrigido para então submeter
novamente. Dessa forma, o Progtest faz com que os alunos sempre sejam estimulados a
praticar o teste de software durante o processo de desenvolvimento do programa.
O Progtest e a proposta do ambiente TEACHING-TEST se assemelham quanto
às funcionalidades que auxiliam o aluno na resolução das questões utilizando técnicas e
critérios de teste. No primeiro ambiente, o teste de software é explorado durante a
prática da programação, levando o aluno a testar antes de submeter o seu programa. No
segundo ambiente é proposto a prática de resolução de questões utilizando técnicas de
testes, onde os alunos poderão contar com um tutorial que será exibido quando o aluno
19
iniciar a resolução da questão. Esse tutorial exibe dicas, regras e exemplos de acordo
com a interação do aluno.
2.3.2 BugHunt
Elbaum, et al., (2007), reuniu em seu trabalho alguns objetos de aprendizagem

de teste de software e algumas abordagens que apoiam o ensino de teste. O tutorial web
Bug Hunt, apoia o ensino de estudantes utilizando estratégias de teste de software. O
BugHunt é dividido em quatro lições. Na primeira questão são abordados os conceitos
básicos e terminologia em teste de software. Na segunda lição a técnica funcional (testes
de caixa-preta) é abordada. Nessa lição são disponibilizados para o aluno os
documentos de requisitos do programa. A técnica estrutural (testes de caixa-branca) é
explorada na lição três, onde o aluno inicia o contato com o código-fonte do programa.
E na quarta e última lição, a automatização de testes é proposta aos alunos. As questões
seguem o mesmo padrão e são compostas por três componentes (objetivos, exercícios e
resultados) e cinco subcomponentes (instruções, artefatos, feedbacks distintos, testes e
assistência).
Assim como no BugHunt, o TEACHING-TEST utilizará questões, porém elas
irão explorar o uso dos testes funcionais, mais especificamente as técnicas de partição
de equivalência e análise de valor limite. As questões serão disponibilizadas com
componentes que ajudarão na resolução do problema como: classe de referência e
tutorial com dicas e informações sobre as técnicas. O ambiente também irá
disponibilizar a automação dos casos de teste do aluno por meio de sua resposta durante
a resolução da questão.
2.3.3 Under Attack
O Under Attack desenvolvido por Da Silva (2015) é um jogo voltado para o

conteúdo de Teste de Software. O jogo se passa em um cenário que foi invadido por
inimigos que implantaram defeitos dentro de um software. O jogador deve encontrar e
remover os defeitos utilizando a técnica de partição de equivalência e elaborando casos
de teste automatizados usando a sintaxe do JUnit. O JUnit é um framework que possui o
20
código-fonte aberto. Ele possui anotações e asserções que ajudam a facilitar a

elaboração e execução de testes de unidade em Java (SOMMERVILLE, 2011).
A estrutura do Under Attack é dividida em duas fases. Na primeira fase o

jogador deve destruir os Gambisters (responsáveis pelo surgimento defeitos no sistema)
construindo uma poção mágica. O jogador irá conseguindo o item da poção conforme
for enfrentando os desafios do jogo. Além disso, o aluno deve encontrar defeitos (bug
zumbis) utilizando a técnica de partição de equivalência.
Na segunda fase o jogador deve despertar os desenvolvedores através de uma

melodia produzida por uma máquina que só irá funcionar com testes automatizados.
Logo, para o aluno concluir a fase deverá elaborar testes automatizados.
O ponto de semelhança entre o Under Attack e o TEACHING-TEST é o foco em

testes utilizando a técnica de partição de equivalência e a elaboração de testes
automatizados. Porém, no Under Attack o jogador deverá criar testes automatizados
tendo como base a fase anterior do jogo. No TEACHING-TEST a criação dos testes
automatizados será feita à medida que o aluno for resolvendo a questão. Cada questão
terá uma classe de referência com nome e métodos pré-estabelecidos, além de uma
classe de teste JUnit que será complementada com as respostas dadas pelo aluno
durante a resolução da questão. No final desse processo será disponibilizado uma classe
com casos de teste automatizados.
A Tabela 1 apresenta uma comparação entre as ferramentas produzidas nos

trabalhos relacionados descritos anteriormente destacando as principais vantagens e
limitações de cada uma.
21
Tabela 1- Tabela comparativa
ProgTest BugHunt Under Attack TEACHING-TEST

Trabalha estimulando o Ferramenta voltada Trabalha com a Propõe trabalhar com
aluno na prática tanto da apenas para o busca de defeitos. a prática de técnicas
programação, quanto do ensino de teste de Utiliza a utilização de teste de software,
teste de software. software. da técnica de elaboração de casos
Vantagens
Apresenta a Aborda conceitos partição de de teste e automação

funcionalidade de básicos, técnicas de equivalência. de teste.
validação e correção da teste funcionais, Oferece ao aluno a Propõe que aluno
resolução submetida estruturais e elaboração de casos aprenda as técnica de
retornando um feedback automação de teste. de teste testes durante a
para o aluno. automatizados. resolução das
questões.
O aluno testa o A inclusão de um Não oferece apoio Trabalha apenas com
programa que irá novo exercício na didático à criação o ensino de duas
submeter utilizando base de dados só é das classes JUnit técnicas de teste de
alguns testes elaborados permitida pelo durante a software
por ele, podendo ou não administrador. O elaboração dos Não valida questões e
aplicar técnicas de teste. instrutor deve ter a casos de teste retorna um feedback
Deve-se ter aprovação do automatizados. de correção para o
Limitações
conhecimento prévio administrador do aluno

das técnicas para sistema.
elaborar o casos de
teste.
22
3 PROPOSTA DO SISTEMA
A proposta principal deste trabalho é implementar o ambiente TEACHING-

TEST que será responsável por apoiar o processo de ensino-aprendizagem de conteúdos
da disciplina de Teste de Software. Este ambiente deverá ser utilizado com o intuito de
auxiliar de forma simples e dinâmica a aprendizagem dos alunos sobre o uso de algumas
técnicas que os tornam mais eficazes na elaboração de casos de teste de qualidade.
Para que o objetivo proposto seja alcançado, o aluno responderá às questões com
a ajuda de um tutorial que será exibido nas telas do ambiente, mostrando para ele dicas
de preenchimento e quais passos devem ser seguidas para resolver a questão. Ao final
do processo de resolução da questão, o aluno poderá automatizar os casos de teste
criados a partir do sistema por meio de uma funcionalidade que utilizará como base o
framework JUnit.
O sistema contará com um módulo para tutores, que inicialmente poderá

visualizar as respostas do aluno para as questões propostas.
23
4 ANÁLISE E ESPECIFICAÇÃO DO SISTEMA
5.
4.1 REQUISITOS DO SISTEMA
As Tabelas 2 e 3 apresentam respectivamente os requisitos funcionais e não

funcionais levantados para o ambiente proposto.
Tabela 2 - Requisitos funcionais
Código Descrição
Acesso ao sistema. Após um usuário válido efetuar
RF01 Controle de acesso login terá acesso às questões disponibilizadas pelo
ambiente.
O usuário terá a visualização das questões
RF02 Acesso às questões disponíveis. O usuário terá a opção de iniciar
resolução de uma questão por vez.
O sistema deverá disponibilizar um passo a passo
Apresentação de
RF03 e dicas para ajudar os estudantes durante a
tutorial de resolução
resolução das questões.
O tutor terá a visualização das respostas dos
RF04 Acessar respostas alunos. Ele terá a opção de acompanhar o
progresso de cada aluno.
Após a resolução das questões com o auxílio do
Gerar tabela com tutorial, o sistema deverá gerar uma tabela com os
RF05
casos de teste casos de teste que foram criados através do
ambiente.
Gerar casos de teste automatizados. O usuário
Gerar casos de teste poderá automatizar os casos de teste criados no
RF06
automatizados ambiente por meio de uma funcionalidade do
sistema que fará uso do framework JUnit.
Tabela 3 - Requisitos não funcionais

24
Códig
o Descrição
RNF01 O sistema deverá utilizar tecnologias open source e multiplataforma.
RNF02 O sistema deverá usar tecnologia web.
4.2 MODELAGEM DO SISTEMA
Esta seção irá apresentar os diagramas de casos de uso e o diagrama de classes

que foram confeccionados durante a fase de modelagem do ambiente proposto.
4.2.1 Diagrama de Casos de Uso
As Figuras 9 e 10 apresentam os diagramas de casos de uso criados para o

sistema proposto nesse trabalho. O sistema possui como atores principais o Aluno e o
Tutor, que são os responsáveis pelas ações feitas dentro do ambiente. As descrições dos
principais casos de uso são apresentadas no APÊNDICE A.
Figura 9 - Diagrama de Caso de Uso do Aluno

25
Figura 10 - Diagrama de Caso de Uso do Tutor
4.2.2 Diagrama de Classes
Nesta seção será apresentado o diagrama de classes, construído para um melhor

entendimento do relacionamento das classes no sistema, conforme é mostrado na Figura 11.
26
Figura 11- Diagrama de classes

27
Na Tabela 4 estão descritas as funções de cada entidade apresentada no

diagrama de classes mostrado anteriormente.
Tabela 4 - Dicionário de classes referente à função de cada classe
Dicionário de classes
Classe Função
Classe responsável por manter
informações dos professores que
Tutor utilizarão o ambiente. O tutor é a pessoa
responsável por manter as questões
disponíveis no TEACHING-TEST
A classe turma contém a lista de alunos
Turma que compõem aquela turma, além de ter
um vínculo com o tutor
Os alunos poderão fazer parte de uma
Aluno turma ou utilizar o ambiente como aluno
avulso, caso queira estudar sozinho.
Classe responsável pelo banco de
Questao questões compostas por enunciado e
classe de referência
A classe resposta é a responsável por
Resposta comparar as respostas do aluno com as
respostas do professor
Responsável por exibir o dicas úteis para
PassosTutorial
a resolução da questão
A resolução da questão se inicia nessa
classe. Os tipos de condição de entradas
TipoCondicaoEntrada serão exibidos para o aluno com regras e
exemplos para ajudar no processo de
resolução.
Classe responsável por guardar as
condições de entrada presente na questão
CondicaoEntrada
e que informadas pelo aluno durante a
elaboração da sua resposta.
Classe responsável por guardar as classes
ClasseEquivalencia de equivalência informadas pelo aluno
durante a elaboração da sua resposta.
Essa classe é usada para preencher os
casos de teste com os valores fornecidos
ValoresCasosTeste
pelo aluno assim que ele estiver
finalizando a resolução da questão
28
4.2.3 Diagrama de Sequência
O diagrama de sequência tem como propósito ilustrar o comportamento dos

métodos a cada ação do ator. O diagrama de sequência pode ser visualizado na Figura
12.
29
Figura 12 - Diagrama de Sequência

30
4.2.4 Diagrama de Atividades
O diagrama de atividades mostrado na Figura 13 ilustra o fluxo das atividades do

sistema.
Figura 13 - Diagrama de Atividades

31
4.2.5 Modelo do Banco de Dados
A Figura 14mostra uma visão geral do banco de dados do sistema, foi utilizado o
modelo ER para o mapeamento das entidades e seus relacionamentos.
Figura 14 - Modelo Entidade Relacionamento

32
5 IMPLEMENTAÇÃO
Este capítulo tem como objetivo apresentar com detalhes o desenvolvimento da

ferramenta TEACHING TEST.
5.1 DETALHES DO DESENVOLVIMENTO DA FERRAMENTA
O desenvolvimento da ferramenta voltou-se para as funcionalidades que fazem

parte da elipse responder questão, do caso de uso mostrado na Figura 9.
A tela “Visualizar questão” foi a primeira tela a ser implementada juntamente com suas
funcionalidades, que eram basicamente exibir nome do aluno logado, exibir listas de
questões disponíveis para o aluno, mostrar enunciado da questão selecionada e
visualizar classe de referência da questão.
Após a finalização desta tarefa, iniciou-se a implementação das telas que usam o
tutorial dinâmico: Selecionar tipo de condição de entrada, Identificar condição de
entrada e Criar classes de equivalência.
A próxima tarefa implementada foi a tela “Visualizar tabela de casos de teste”.

Devido ter que mostrar todos os dados que o aluno informou até o passo criar classes de
equivalência, foi necessário desenvolver métodos que guardassem esses dados em listas,
para em seguida passar para uma tabela e posteriormente exibir na tela.
Para completar a resposta do aluno foi implementada a tela “Montar casos de

teste”. Ela tem como base a tela “Visualizar tabela de casos de teste”, porém foram
adicionados campos para o aluno informar valores de entrada e saída tanto para as
classes de equivalência válidas, quanto para as classes de equivalência inválidas. A tela
utiliza a funcionalidade gerar classe JUnit, onde as entradas e saídas informadas serão
utilizadas dentro da classe de teste que é gerada no pacote de teste do NetBeans.
Após concluir a implementação da funcionalidade gerar classe JUnit, foi

possível iniciar o desenvolvimento da tarefa executar classe JUnit. Para o processo de
execução da classe de teste é necessário que uma classe JUnit exista, após essa
verificação a classe é compilada juntamente com a classe de referência da questão. A
classe de referência é de extrema importância durante esse processo, pois é por meio
33
dela que os métodos da classe de teste serão executados. Cada questão deve possuir a
sua própria classe de equivalência.
O resultado da execução é lido e passado para a tela onde deve ser exibido. O
resultado exibe dados como: tempo de execução, quantidade de testes passando,
quantidade de testes falhando e log das falhas.
5.2 APRESENTAÇÃO DO SISTEMA
A Figura 15 mostra a tela inicial da ferramenta, onde o usuário deve selecionar a

opção Tutor ou Aluno antes de realizar o login.
Figura 15 - Tela de perfil

34
Na Figura 16 é apresentada a tela de login do ambiente. O aluno deve estar

devidamente cadastrado para poder acessar o conteúdo da ferramenta.
Figura 16 -Tela de login

35
A tela do ambiente onde o aluno irá ter acesso às questões é mostrada na Figura
17, essa tela exibe ao usuário uma lista de questões disponíveis para resolução. Além
disso, exibe o enunciado de cada questão selecionada na lista e disponibiliza a opção de
visualizar a Classe de Referência usada como base para a criação os casos de teste
automatizados. Cada questão deve possuir uma classe de referência composta por
atributos e métodos. É com base nessa classe que será possível criar uma classe de teste
JUnit para validar os casos de teste criados pelos alunos. A classe JUnit será
complementada à medida em que o aluno informar os dados necessários para concluir a
questão.
Figura 17 - Tela visualizar questão

36
Nas telas mostradas na Figura 18 e Figura 19, um tutorial composto por passos,
dicas, e regras é exibido ao aluno para auxiliá-lo durante o processo de resolução da
questão.
Figura 18 - Tela escolher tipo de variável

Figura 19 - Tela Tipo condição de entrada

37
No primeiro passo do tutorial, o ambiente direciona o usuário para selecionar o

tipo de condição de entrada. Na tela são exibidas algumas informações sobre condição
de entrada e as opções de tipo de condição de entrada, conforme mostra a Figura 20.
Figura 20 - Tela selecionar variável de entrada

Após analisar a questão e selecionar o tipo de condição de entrada, a tela

referente à Figura 21 irá exibir para o usuário, um exemplo de aplicação do tipo de
condição entrada.
38
Figura 21 - Tela selecionar variável de entrada - Variável selecionada

A Figura 22 mostra a tela referente ao próximo passo para resolver a questão.

Essa tela informa ao usuário que ele deve indicar a condição ou condições de entrada
presentes no enunciado da questão selecionada para resolução.
Figura 22 - Tela escolher condição de entrada

Na tela mostrada na Figura 23 são exibidas dicas e exemplos para ajudar o

usuário a identificar as condições de entrada presente na questão.
39
Figura 23 - Tela identificar condição de entrada

Após identificar as condições de entrada, o tutorial exibe na tela mostrada na

Figura 24 que o próximo passo deve ser criar as classes de equivalência.
40
Figura 24 - Tela para criação de classes de equivalência

Na Figura 25 é mostrada a tela onde o usuário deve informar os valores que

serão usados em cada classe de equivalência válida e inválida.
41
Figura 25 - Tela criar classes de equivalência

A próxima tela, representada pela Figura 26, exibe uma tabela com tudo o que
foi informado pelo usuário até o momento tipo de condição de entrada, condição de
entrada, classe válida e classe inválida. A tela também exibe as opções de adicionar um
novo tipo de condição de entrada, adicionar uma nova condição de entras e preencher os
casos de teste.
Figura 26 - Tela visualizar tabela de casos de teste
A próxima tela, representada pela Figura 27, exibe uma tabela baseada na Figura
26, porém exibe alguns campos para que o usuário possa informar o valor que deseja
usar nas classes válidas e inválidas. Os valores informados serão usados na classe JUnit,
serão adicionados nos métodos padrões existentes na classe. Após informar esses
valores o usuário poderá gerar os casos de teste.
42
Figura 27 - Tela preencher casos de teste
A tela também possui a opção de visualizar a classe de referência, para auxiliar o

aluno caso tenha alguma dúvida sobre a questão, conforme a Figura 28 abaixo.
Figura 28 - Tela preencher casos de teste

43
Na Figura 29 é mostrada a classe JUnit gerada após o aluno finalizar a resolução

da questão.
Figura 29 - Classe JUnit gerada

44
A tela exibida na Figura 30, mostra para o aluno a classe de teste JUnit gerada a
partir das respostas fornecidas por ele durante a resolução da questão.
Figura 30 - Tela Execução dos casos de teste

45
Na tela “Visualizar questões respondidas” o aluno também tem a opção de

acompanhar as respostas elaboradas para cada questão respondida, como pode ser visto
detalhadamente na Figura 31.
Figura 31 - Visualizar respostas

46
6 CONCLUSÕES E TRABALHOS FUTUROS
Neste capítulo, são apresentadas as considerações finais sobre o

desenvolvimento de uma ferramenta de apoio ao processo de ensino-aprendizagem de
Teste de software.
6.1 CONCLUSÕES
Este trabalho foi desenvolvido com o objetivo de implementar e disponibilizar

um ambiente de apoio ao ensino de Teste de Software, a fim de auxiliar alunos no
aprendizado de técnicas de testes para a elaboração de casos de teste mais eficientes.
Pretende-se com o trabalho explorar a aplicação das técnicas de Partição de
Equivalência e Análise do Valor Limite (critérios de testes utilizados em testes de caixa
preta) para resolver as questões disponíveis no ambiente. Além disso, o ambiente
propõe como estratégia de ensino e fixação do conteúdo estudado, o auxílio de um
tutorial para tornar o processo de resolução das questões mais dinâmico para o aluno.
6.2 TRABALHOS FUTUROS
A ferramenta encontra-se na versão inicial e está apta para ser expandida. Como
melhorias e trabalhos futuros são propostas as seguintes ideias.
 Implementar a aplicação de outras técnicas de teste para a elaboração de

casos de teste como: Diagrama de Transição de Estado e Tabela de Decisão;
 Desenvolver o módulo de Cadastro de questão, possibilitando que o tutor
interfaces adequadas para que o mesmo consiga elaborar questões utilizando
a ferramenta TEACHING TEST;
 Ampliar o módulo Tutor tornando possível além do acompanhamento do
progresso do aluno o cadastro de turmas e alunos.
 Implementação para tradução da saída do JUnit após execução da classe de
teste;
47
 Implementar validação de expressões informadas nas classes de

equivalência;
 Implementar botões de retorno para cada etapa da ferramenta;
 Adicionar dicas para o preenchimento dos campos: condição de entrada,
classes válidas e inválidas, entrada válida e inválida (regra do separador para
questões que exigem mais de um valor como entrada);
 Criar mini manual de usuários sobre os botões usados na ferramenta;
 Implementar feedback de passos com o objetivo de informar ao aluno o
passo atual e o total de passos para a conclusão da questão.
Realizar a troca dos links presentes na tela de perfil por figuras. .
Mostrar a classe de referência apenas quando o aluno finalizar a questão;
 Realizar testes da ferramenta em um ambiente acadêmico;
48
REFERÊNCIAS
BASTOS, A. et. al. Base de conhecimento em teste de software. 3. ed. Rio de Janeiro:
Martins, 2012. 263p.
BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML: guia do usuário.

Elsevier Brasil, 2006.
Boston, 2002.
BYEBUG – Aprendendo Teste de Software., 2014 Disponível em: <
http://www.inf.ufsc.br/~fabiane.benitti/byebug/#> Acesso em: 11/09/2017.
CARRIGTON, D. Teaching Software testing. Proceeding of the 2nd Australian

conference on Computer science education. Australia, 1997. p. 59-64.
CHEN, T. Y.; POON, P. L. Experience with teaching black-box testing in a computer

science/software engineering curriculum. IEEE Transactions on Education, v. 47, n. 01,
p. 42-50, 2004.
CRAIG, R.D., JASKIEL, S. P., “Systematic Software Testing”, Artech House

Publishers, 2002.
DA SILVA, E. S. UNDER ATTACK: Um sistema web gamificado para apoio ao ensino

de teste de software. 2015. 92 f. Trabalho de conclusão de curso (Monografia) – Curso
de Tecnologia em Análise e Desenvolvimento de Sistemas, Instituto Federal de
Educação, Ciência e Tecnologia do Amazonas – IFAM, Amazonas, 2015.
DE SOUZA, D. M., MALDONADO, J. C., and BARBOSA, E. F. (2011). Progtest: Na

environment for the submission and evaluation of programming assignments based on
testing activities. In Software Engineering Education and Training (CSEE&T), 2011
24th IEEE-CS Conference on, pages 1–10. IEEE.
DEITEL, P. J.; Java : como programar / Paul Deitel e Harvey Deitel ; tradução Edson
Furmankiewicz ; revisão técnica Fábio Luis Picelli Lucchini. -- 8. ed. -- São Paulo :
Pearson Prentice Hall, 2010.
ELBAUM, S., PERSON, S., DOKULIL, J., and JORDE, M. (2007). Bug hunt: Making
early software testing lessons engaging and affordable. In Proceedings of the 29th
international conference on Software Engineering, pages 688–697. IEEE Computer
Society.
HIBERNATE. Hibernate ORM, 2016. Disponivel em: <http://hibernate.org/orm/>.

Acesso em: 26/11/2017.
49
MOLINARI, L. Testes de Software: Produzindo Sistemas melhores e mais confiáveis.

1ª Edição. ed. São Paulo: Érica, 2003.
MYERS, G. J. The Art of Software Testing. Hoboken: John Wiley & Sons, Inc, 2004.
MYSQL. Documentação MySQL – Manuais de Referência, 2017. Disponivel em:

<http://dev.mysql.com/doc/>. Acesso em: 26/11/2017.
PRESSMAN, R. S. Engenharia de Software. 5ª Edição São Paulo: Pearson Addison,

2011.
REDDY, K. SIVA PRASAD. PrimeFaces Beginner's Guide. Birmingham, UK: Packt
Pub., 2013.
SCHALK, Chris; BURNS, Ed; HOLMES, James. JavaServer Faces: The complete
reference. 1.ed. McGraw-Hill Osborne. 2006.
SILVA, P.H. ; BENITTI, F.B.V.; ALBANO, E.L. Objetos de aprendizagem para apoio

ao ensino de teste de software. In: Computer on the Beach, 2013, Florianópolis. IV
Computer on the Beach, 2013
SOMMERVILLE, I. Software Engineering. 9ª. ed. [S.l.]: Pearson, 2011.
TONIN, N. A. and BEZ, J. L. (2013). Uri online judge: A new interactive learning
approach. Computer Technology and Application, 4(1).
.
50
APÊNDICE A – DESCRIÇÃO DOS CASOS DE USO
Nome do Caso de uso Criar questão

Sumário Realizar a criação de questão no sistema
Atores Tutor
Pré-Condição Usuário deve estar logado no sistema
como professor
Fluxo Principal 1 - Esse caso de uso inicia quando o

professor acessa o sistema e clica na
opção “Criar questão”.
2 - O sistema exibe uma “Criar questão”

com os campos necessários para a criação
da questão.
3 - O tutor preenche os campos e clica no

botão ”Concluir”.
4 - O sistema exibe uma mensagem

informando que a questão foi criada.
Fluxos Alternativos Caso o professor não preencha algum

campo obrigatório para a criação da
questão o sistema mostra a mensagem
“Todos os campos obrigatórios devem ser
preenchidos.”
51
Nome do Caso de uso Editar questão

Sumário Realizar a edição da questão no sistema
Atores Tutor
Pré-Condição 1 - Usuário autenticado no sistema
2 - Ter questão criada

professor seleciona uma questão e clica
no botão “Editar”
2 - O sistema habilita os campos para a

edição
3 - O professor edita a questão e clica no

botão “Concluir”
4 - O sistema exibe a mensagem “Edição

concluída”
Fluxos Alternativos Caso o aluno clique no botão “Cancelar”,

o sistema exibe a mensagem “Edição
cancelada”.
Nome do Caso de uso Visualizar questão

Sumário Realizar a visualização da questão no
sistema
Atores Tutor
Pré-Condição 1 - Usuário autenticado no sistema
2 - Ter questão criada

no botão “Visualizar”
2 - O sistema exibe uma tela de

visualização mostrando a questão com
informações detalhadas
52
Fluxos Alternativos Caso o aluno clique no botão “Cancelar”,

o sistema retorna para a tela principal.
Nome do Caso de uso Excluir questão

Sumário Realizar a exclusão da questão no
sistema
Atores
Pré-Condição 1-Usuário autenticado no sistema
2-Ter questão criada

no botão “Exluir”
2 - O sistema exibe a mensagem “Deseja

excluir a questão selecionada?”
3 - O professor clica no botão “Sim”
4 - O sistema exibe a mensagem “A

questão foi excluída”
Fluxos Alternativos Caso o professor não queira excluir a

questão e clique no botão “Não”, o
sistema retorna para a tela principal.
Nome do Caso de uso Acessar questão

Sumário Realizar o acesso a questões no sistema
Atores Aluno
Pré-Condição O usuário deve estar logado no sistema
como aluno

aluno acessa o sistema e visualiza as
questões disponibilizadas pelo professor.
2 - O aluno seleciona uma questão e clica

no botão “Visualizar questão”
3 - O sistema exibe uma tela com a

descrição da questão
53
Fluxos Alternativos Caso o aluno clique no botão “Visualizar

questão” sem selecionar uma questão o
sistema mostra a mensagem “Selecione
uma questão.”
Nome do Caso de uso Responder questão - Criar caso de teste

Sumário Realizar a criação de casos de teste no
sistema
Atores Aluno
Pré-Condição Ter acessado questão
aluno clica no botão “Iniciar resolução”
2 - O sistema direciona o aluno para a

tela “Escolher tipo de variável” com
primeiro passo do tutorial “Para
solucionar a questão o 1º passo deve ser
escolher o tipo de condição”
3 - O aluno clica no botão “Escolher tipo

de condição de entrada”.
4 - O sistema exibe a tela “Selecionar

condição de entrada”
5 - O aluno seleciona um tipo de

condição de entrada
6 - O sistema exibe um exemplo do tipo

de condição selecionado pelo aluno
7 - O aluno clica no botão “Próximo

passo”
8 – O sistema exibe a tela “Identificar

condições de entrada” com o segundo
passo do tutorial “Você está muito bem!
Agora para o 2º passo você precisa
identificar as condições de entrada”
9 - O aluno clica no botão “Identificar

condições de entrada”
10 - O sistema exibe a tela “Identificar

condições de entrada” com um campo
54
para inserção da condição
11 - O aluno informa a condição de

entrada e clica no botão “Próximo passo”
12 - O sistema exibe a tela “Criar

classes” com o terceiro passo do tutorial
13 - O aluno clica no botão “Criar classes

de equivalência”
14 - O sistema exibe a tela “Determinar
classe” com os campos “Classe válida” e
“Classe inválida”
15 - O aluno informa os valores

desejados para cada classe e clica no
botão “Salvar”.
16 - O sistema exibe a tela “Casos de

teste” com uma tabela mostrando todos
os dados informados nos passos
anteriores e com as opções “+ tipo de
condição”,
“+ condição de entrada” e “Preencher
casos de teste”
17 - O aluno clica no botão “Preencher

casos de teste”
18 - O sistema exibe uma nova tabela,

porém dessa vez com campos para
inserção de valores para cada classe.
19 - O aluno preenche os campos e clica

no botão “Gerar classe de teste”
20 - O sistema exibe a tela “Gerar classe

de teste JUnit” com informações da
classe de referência e os casos de teste
selecionados para serem usados na classe.
21 - O sistema informa os casos de teste

foram criados.
Fluxos Alternativos 1 - Casos o aluno clique no botão

“Concluir” sem ter criado algum caso de
teste, o sistema mostra a mensagem: “É
necessário criar os casos de teste antes de
gerá-los.”
55
2 – Caso o aluno clique no botão “+ tipo

de condição” durante a resolução da
questão, será direcionado para a tela
“Selecionar Tipo de Condição de
Entrada”, que permitirá que o aluno
adicione mais um tipo de condição à sua
resolução.
3 – Caso o aluno clique no botão “+

condição de entrada” durante a resolução
da questão, será direcionado para a tela
“Identificar Condição de entrada”, que
permitirá que o aluno adicione mais
condições de entrada para o mesmo tipo
de condição.
56
APÊNDICE B – IMPLEMENTAÇÃO DA FERRAMENTA
Para o processo de desenvolvimento desta ferramenta foi adotada a metodologia

ágil Scrum. Essa metodologia trabalha com Sprints, que são ciclos curtos de
desenvolvimento e entrega do software. Além de organizar o projeto utilizando
funcionalidades, estórias e tarefas.
Na Figura 32, temos a visão do projeto dividido em duas funcionalidades, a

primeira denominada Desenvolvimento e a segunda denominada Escrita TCCII.
Figura 32 - Features da ferramenta

Fonte: Plataforma IceScrum do projeto da própria autora.
Dentro da funcionalidade Desenvolvimento foram criadas as seguintes estórias:
1. Criar tela de login;

2. Criar tela visualizar questões;
3. Criar tela escolher tipo de condição de entrada;
57
4. Criar tela identificar condição de entrada;

5. Criar tela visualizar tabela de casos de teste;
6. Criar tela montar casos de teste;
7. Ajustes e correções;
8. Revisão do projeto;
A Figura 33 mostra detalhadamente como ficou a estrutura das estórias.
Figura 33 – Estórias
Dentro de cada estória foram criadas tarefas específicas para as funcionalidades.

Para uma melhor visualização as figuras referentes à cada estória serão listadas abaixo.
A Figura 34 mostra as tarefas implementação da autenticação do aluno e criar

sessão do usuário logado referente à estória “Criar tela login”.
58
Figura 34 – Estória criar tela de login

Fonte: Plataforma IceScrum do projeto da própria autora
Na figura 35, são mostradas as tarefas da estória “Criar tela visualizar questão”,
sendo elas Listar questões cadastradas no banco, exibir enunciado da questão
selecionada e exibir classe de referência da questão.
Figura 35- Estória criar tela visualizar questão

59
A Figura 36 mostra que para a estória “Criar tela escolher tipo de condição de
entrada”, as tarefas criadas foram exibir passos do tutorial, exibir dicas do tutorial, listar
tipos de condição de entrada e exibir exemplos do tipo de condição de entrada.
Figura 36- Estória criar tela escolher tipo de condição de entrada

Na estória “Criar tela identificar condição de entrada e criar classes de

equivalência” foram criadas as tarefas implementar funcionalidade do campo condição
de entrada e exibir os campos das classes dinamicamente. A Figura 37 mostra de forma
mais detalhada.
60
Figura 37- Estória criar telas identificar condição de entrada e classes de equivalência
A Figura 38 exibe as tarefas implementar botão adicionar condição de entrada,

montar tabela parcial de teste e implementar botão preencher casos de teste, referentes à
estória “Criar tela visualizar tabela de casos de teste”.
Figura 38- Estória criar tela visualizar tabela de casos de teste

61
A estória “Criar tela montar casos de teste” é mostrada na Figura 39, juntamente
com as tarefas montar tabela de casos de teste adicionando campos de entrada e saída,
criar classe JUnit, executar classe JUnit, exibir classe JUnit gerada e exibir resultado da
execução da classe JUnit.
Figura 39- Estória criar tela montar casos de teste

A Figura 40 mostra uma estória criada apenas para ajustes e correções, dentro
dessa estória foi criada a tarefa correção e atualização da ferramenta após avaliação do
orientador.
62
Figura 40- Estória ajustes e correções

Para a feature Escrita TCCII foi criada apenas a estória Revisão do projeto,
contendo como tarefas, revisar documento TCCII, revisar diagramas e fazer correção
após avaliação do orientador. A Figura 41 mostra uma melhor organização das tarefas.
Figura 41- Estória revisão do projeto


Teaching Test - Ambiente de Apoio Ao Processo de Ensino-Aprendizagem de Conteúdos de Teste de Software

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Teaching Test - Ambiente de Apoio Ao Processo de Ensino-Aprendizagem de Conteúdos de Teste de Software

Enviado por

Direitos autorais:

Formatos disponíveis

INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNLOGIA DO

Thais Elaizza da Rocha Colares

TEACHING-TEST: AMBIENTE DE APOIO AO PROCESSO DE ENSINO-

Manaus, Amazonas – Brasil

Thais Elaizza da Rocha Colares

TEACHING-TEST: AMBIENTE DE APOIO AO PROCESSO DE ENSINO-

Orientadora: Profa. Dra. Joyce Miranda dos Santos.

Trabalho de Conclusão de Curso

Manaus, Amazonas – Brasil

A realização de testes de software tem sido fundamental para garantir a

Figura 1 - Formulário para identificação de classes de equivalência................................7

Tabela 1- Tabela comparativa.........................................................................................21

Utilizados em diversas atividades, os softwares estão cada vez mais integrados à

Segundo Pressman (2011), teste de software pode ser definido como um

A elaboração de casos de teste é essencial para o sucesso das atividades de teste

Dentre as técnicas utilizadas para aprimorar e otimizar a aplicação dos testes

Apesar da importância do teste de software, a compreensão desse tipo de

Dentro do contexto apresentado, este trabalho tem como objetivo propor e

Como suprir no cenário acadêmico a necessidade de abordagens mais práticas a

A principal motivação para a realização deste trabalho está na possibilidade de

1.3.1 Objetivo geral

1.3.2 Objetivos específicos

 Disponibilizar um material de referência sobre os conceitos relacionados a teste

 Realizar um levantamento sobre soluções existentes que ofereçam apoio ao

1.4 ESTRUTURA DO TRABALHO

O presente trabalho está organizado da seguinte forma. No Capítulo 2 são

2.1 TESTE DE SOFTWARE

A realização de testes é uma atividade fundamental que deve ser realizada

2.1.1 CLASSIFICAÇÃO DOS TESTES DE SOFTWARE

Segundo Bastos, et al., (2012), o nível do teste identifica a fase do

As técnicas de teste estão divididas entre os testes caixa-branca e testes caixa-

 Teste caixa-branca: também conhecido como técnica estrutural. Focam no

Neste trabalho, serão explorados especificamente testes de unidade caixa-preta

2.1.1.1 PARTIÇÃO DE EQUIVALÊNCIA

Segundo Pressman (2011), a técnica de Partição de Equivalência divide o

Figura 1 - Formulário para identificação de classes de equivalência.

As classes são classificadas em dois tipos: classe válida que representa as

1. Intervalo: se uma condição de entrada especifica um intervalo, são definidas

Exemplo: Validar números referentes aos meses do ano.

Figura 2 - Exemplo utilizando intervalo.

2. Valor Específico: se uma condição de entrada requer um valor específico, são

Exemplo: Validar valor a pagar.

Figura 3 - Exemplo utilizando valor específico

Fonte: ByeBug – Aprendendo Teste de Software2

3. Conjunto de Valores: se uma condição de entrada especifica um membro de

Exemplo: Validar números positivos.

Figura 4 - Exemplo utilizando conjunto de valores

Exemplo: Validar cliente ativo

Figura 5 - Exemplo utilizando condição lógica

2.1.1.2 ANÁLISE DE VALOR LIMTE

Figura 6 - Exemplo da técnica de Análise de valor limite

Segundo Pressman (2011), essa técnica possui as seguintes diretrizes:

1. Intervalo de valores: se uma condição de entrada especificar um intervalo

2. Série de valores: Se uma condição de entrada especificar uma série de valores,

Considere um exemplo utilizando o gerenciador de cores da ferramenta Paint,

Figura 7 - Exemplo utilizando análise de valor limite

Fonte: ByeBug – Aprendendo Teste de Software5

A Figura 7 ilustra a elaboração de casos de casos de teste utilizando a técnica de

Na coluna entrada foi informado o modelo de cores RGB e na coluna ao lado o

2.2 TECNOLOGIAS E PADRÕES UTILIZADOS

Nessa seção, serão apresentadas as tecnologias e processos que serão utilizados

O Scrum é um processo iterativo e incremental usado para o desenvolvimento

Figura 8 - Ciclo do Scrum.