Universidade Federal do Rio Grande do Norte
Centro de Ciências Exatas e da Terra
Departamento de Informática e Matemática Aplicada
Bacharelado em Engenharia de Software
Especicação de Requisitos e Testes de um
Sistema de Chave de Identicação
Pablo Gabriel Rodrigues Neves Bedoya
Natal-RN
Novembro de 2017
Pablo Gabriel Rodrigues Neves Bedoya
Especicação de Requisitos e Testes de um Sistema de
Chave de Identicação
Monograa de Graduação apresentada ao
Departamento de Informática e Matemática
Aplicada do Centro de Ciências Exatas e da
Terra da Universidade Federal do Rio Grande
do Norte como requisito parcial para a ob-
tenção do grau de bacharel em Engenharia
de Software.
Orientador
Prof. Dr. Bruno Santana da Silva
Universidade Federal do Rio Grande do Norte  UFRN
Departamento de Informática e Matemática Aplicada  DIMAp
Natal-RN
Novembro de 2017
Universidade Federal do Rio Grande do Norte - UFRN
Sistema de Bibliotecas - SISBI
Catalogação de Publicação na Fonte. UFRN - Biblioteca Setorial Prof. Ronaldo Xavier de Arruda - CCET
Bedoya, Pablo Gabriel Rodrigues Neves.
   Especificação de requisitos e testes de um sistema de chave
de identificação / Pablo Gabriel Rodrigues Neves Bedoya. -
Natal, 2017.
   102f.: il.
   Monografia (graduação) - Universidade Federal do Rio Grande
do Norte. Centro de Ciências Exatas e da Terra. Departamento de
Informática e Matemática Aplicada. Bacharelado em Engenharia de
Software.
   Orientador: Bruno Santana da Silva.
   1. Engenharia de software - Monografia. 2. Identificação -
Monografia. 3. Chave de identificação - Monografia. 4.
Requisitos - Monografia. 5. Teste de software - Monografia. I.
Silva, Bruno Santana da. II. Título.
RN/UF/CCET                                         CDU 004.41
Monograa de Graduação sob o título Especicação de Requisitos e Testes de um Sistema
de Chave de Identicação apresentada por Pablo Gabriel Rodrigues Neves Bedoya e aceita
pelo Departamento de Informática e Matemática Aplicada do Centro de Ciências Exatas
e da Terra da Universidade Federal do Rio Grande do Norte, sendo aprovada por todos
os membros da banca examinadora abaixo especicada:
Prof. Dr. Bruno Santana da Silva
Orientador
Instituto Metrópole Digital  IMD
Universidade Federal do Rio Grande do Norte  UFRN
Profa. Dra. Isabel Dillmann Nunes
Instituto Metrópole Digital  IMD
Universidade Federal do Rio Grande do Norte  UFRN
Profa. Dra. Roberta de Souza Coelho
Departamento de Informática e Matemática Aplicada  DIMAp
Universidade Federal do Rio Grande do Norte  UFRN
Natal-RN, 27 de novembro de 2017.
Ao meu pai, Jorge Arlindo Neves Bedoya (in memoriam), por ter sido o meu maior
incentivador e por sempre ter acreditado em mim mais que qualquer outra pessoa.
Obrigado por tudo!
Agradecimentos
Agradeço aos meus pais, Jorge Arlindo e Maria de Fátima, pelo amor, carinho e
esforço dedicados à minha formação durante toda minha vida, em especial nestes anos da
graduação.
Agradeço aos meus avós, tios e primos, especialmente àqueles que estiveram mais
próximos durante este período, João Henrique e Pablo Messias. Sem o apoio de vocês eu
não teria conseguido.
Agradeço à minha namorada, Juciene Almeida, pelo afeto de sempre e por me incen-
tivar a concluir este trabalho tornando os meus dias mais leves. Agradeço imensamente
por todo amor demonstrado por mim ao longo do tempo em que estamos juntos.
Agradeço ao meu amigo Ramon Gomes, que se fez presente nos momentos mais impor-
tantes apesar da distância. Muito obrigado! Agradeço também aos colegas de graduação,
pelos momentos de alegria e aprendizado.
Um agradecimento especial ao meu orientador, Bruno Santana da Silva, por ter me
guiado de forma clara e objetiva para alcançar os resultados esperados deste trabalho.
Obrigado por toda disponibilidade, paciência e suporte para a realização deste trabalho.
Agradeço às professoras Isabel Dillman Nunes e Roberta de Souza Coelho, por acei-
tarem o convite para participar da banca examinadora deste trabalho.
Por m, agradeço aos colegas de trabalho da equipe do SIGRH, pela descontração do
dia a dia, responsável por elevar meu humor em muitos momentos.
Olhe os seus olhos no espelho da alma, mas não perca a calma ao descobrir quem você é.
Pense  Espelho da Alma
Especicação de Requisitos e Testes de um Sistema de
Chave de Identicação
Autor: Pablo Gabriel Rodrigues Neves Bedoya
Orientador: Prof. Dr. Bruno Santana de Souza
Resumo
Na biologia, a identicação de seres vivos é uma atividade auxiliada por chaves de identi-
cação, normalmente registradas em papel, como nos livros. Uma chave de identicação
dene o passo a passo de vericações de características que o biólogo deve fazer para
identicar as classicações taxonômicas de um ser vivo. Com os avanços tecnológicos ao
longo dos últimos anos, foram desenvolvidas ferramentas computacionais para apoiar a
identicação de seres vivos, de modo que a navegação entre os passos de uma chave de
identicação fosse facilitada em contraposição ao método convencional em papel. A pro-
posta deste trabalho é apresentar o resultado das atividades de requisitos para a criação
de um sistema de chave de identicação, sendo desenvolvido num projeto de extensão do
Instituto Metrópole Digital e do Centro de Biociências da Universidade Federal do Rio
Grande do Norte. Além disso, este trabalho também apresenta a execução e os resultados
dos testes manuais e automatizados realizados após a conclusão do desenvolvimento do
sistema. Esses resultados acabaram por contribuir com a identicação de falhas presentes
no software, possibilitando uma melhoria da qualidade do produto desenvolvido.
Palavras-chave: Identicação, Chave de Identicação, Requisitos, Teste de Software.
Requirements Specication and Tests of an
Identication Key System
Author: Pablo Gabriel Rodrigues Neves Bedoya
Advisor: Prof. Dr. Bruno Santana da Silva
Abstract
In biology, the identication of living beings is an activity aided by identication keys,
usually recorded on paper, as in books. An identication key denes the step-by-step of
the features checks that the biologist must do to identify the taxonomic classications of a
living being. With the technological advances in the last years, computational tools have
been developed to support the identication of living beings, so that navigation between
the steps of an identication key would be facilitated against the conventional paper
method. The purpose of this work is to present the results of the requirements activities
for the creation of an identication key system, being developed in an extension project
of the Digital Metropolis Institute and of the Biosciences Center of Federal University of
Rio Grande do Norte. In addition, this work also presents the execution and results of
manual and automated tests performed after the completion of the system development.
These results eventually contribute to the identication of software bugs, allowing an
improvement in the quality of the product developed.
Keywords : Identication, Identication Key, Requirements, Software Testing.
Lista de Figuras
1 Processo de software do sistema de chave de identicação . . . . . . . . p. 24
2 Fragmento de chave de identicação das principais famílias da ordem
Diptera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 27
3 Processo da engenharia de requisitos . . . . . . . . . . . . . . . . . . . p. 28
4 Fluxo de TAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 30
5 Ciclo de atividades de TDD . . . . . . . . . . . . . . . . . . . . . . . . p. 30
6 Diagrama de casos de uso  versão 1 . . . . . . . . . . . . . . . . . . . p. 37
7 Diagrama de casos de uso  versão nal . . . . . . . . . . . . . . . . . . p. 38
8 Diagrama de classes  versão 1 . . . . . . . . . . . . . . . . . . . . . . . p. 39
9 Diagrama de classes  versão nal . . . . . . . . . . . . . . . . . . . . . p. 40
10 Diagrama de classes  versão nal MVC . . . . . . . . . . . . . . . . . p. 41
11 Sistema de chave de identicação  Identicação de Exemplar . . . . . p. 45
12 Gráco dos erros detectados pelos testes manuais . . . . . . . . . . . . p. 53
13 Diagrama de classes do projeto de automação de testes . . . . . . . . . p. 55
14 Classe de teste de chave de identicação . . . . . . . . . . . . . . . . . p. 56
15 Resultados da execução dos testes automatizados com TestNG . . . . . p. 57
16 Relatório de resultados da execução dos testes automatizados . . . . . . p. 58
Lista de Tabelas
1 Requisitos funcionais do sistema . . . . . . . . . . . . . . . . . . . . . . p. 42
2 Requisitos não funcionais do sistema . . . . . . . . . . . . . . . . . . . p. 44
3 Diretrizes dos testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 47
4 Marcos do projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 48
5 Produtos disponibilizados . . . . . . . . . . . . . . . . . . . . . . . . . p. 48
6 Casos de teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 49
Lista de Abreviaturas e Siglas
TAD  Test after development
TDD  Test-driven development
BDD  Behavior-driven development
MVC  Model-view-controller
API  Application programming interface
Sumário
1 Introdução p. 23
1.1 Objetivos do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 24
1.2 Organização do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . p. 25
2 Fundamentação Teórica p. 26
2.1 Chave de Identicação . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 26
2.2 Requisitos de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 27
2.3 Testes de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 28
2.3.1 Estratégias de Desenvolvimento de Testes . . . . . . . . . . . . p. 29
2.3.1.1 Test After Development (TAD) . . . . . . . . . . . . . p. 29
2.3.1.2 Test-Driven Development (TDD) . . . . . . . . . . . . p. 30
2.3.1.3 Behavior-Driven Development (BDD) . . . . . . . . . p. 31
2.3.2 Técnicas de Testes . . . . . . . . . . . . . . . . . . . . . . . . . p. 31
2.3.2.1 Teste Funcional . . . . . . . . . . . . . . . . . . . . . . p. 31
2.3.2.2 Teste Estrutural . . . . . . . . . . . . . . . . . . . . . p. 32
2.3.3 Fases de Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 32
2.3.3.1 Testes de Unidade . . . . . . . . . . . . . . . . . . . . p. 32
2.3.3.2 Testes de Integração . . . . . . . . . . . . . . . . . . . p. 33
2.3.3.3 Testes de Sistema . . . . . . . . . . . . . . . . . . . . . p. 33
2.3.3.4 Testes de Aceitação . . . . . . . . . . . . . . . . . . . . p. 33
2.3.4 Artefatos de Testes . . . . . . . . . . . . . . . . . . . . . . . . . p. 33
2.3.4.1 Plano de Teste . . . . . . . . . . . . . . . . . . . . . . p. 33
2.3.4.2 Caso de Teste . . . . . . . . . . . . . . . . . . . . . . . p. 34
2.3.5 Formas de Execução de Testes . . . . . . . . . . . . . . . . . . . p. 35
3 Requisitos do Sistema de Chave de Identicação p. 36
3.1 Análise dos Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 36
3.1.1 Diagrama de Casos de Uso . . . . . . . . . . . . . . . . . . . . . p. 36
3.1.2 Diagrama de Classes . . . . . . . . . . . . . . . . . . . . . . . . p. 38
3.2 Especicação dos Requisitos . . . . . . . . . . . . . . . . . . . . . . . . p. 41
4 Testes do Sistema de Chave de Identicação p. 46
4.1 Planejamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 46
4.1.1 Plano de Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 46
4.2 Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 48
4.2.1 Casos de Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 49
4.3 Testes Manuais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 51
4.3.1 Execução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 51
4.3.2 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 51
4.4 Testes Automatizados . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 53
4.4.1 Implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 53
4.4.2 Execução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 56
4.4.3 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 57
5 Considerações Finais p. 59
Referências p. 60
Apêndice A -- Casos de Uso do Sistema p. 61
A.1 UC01 Criar Identicação de Exemplar . . . . . . . . . . . . . . . . . . p. 61
A.1.1 Descrição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 61
A.1.2 Atores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 61
A.1.3 Fluxo de Eventos . . . . . . . . . . . . . . . . . . . . . . . . . . p. 61
A.1.3.1 Fluxo Básico . . . . . . . . . . . . . . . . . . . . . . . p. 61
A.1.3.2 Fluxos Alternativos . . . . . . . . . . . . . . . . . . . . p. 62
A.1.4 Condições Prévias . . . . . . . . . . . . . . . . . . . . . . . . . . p. 62
A.1.5 Condições Posteriores . . . . . . . . . . . . . . . . . . . . . . . . p. 62
A.2 UC02 Consultar Identicação de Exemplar . . . . . . . . . . . . . . . . p. 62
A.2.1 Descrição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 62
A.2.2 Atores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 63
A.2.3 Fluxo de Eventos . . . . . . . . . . . . . . . . . . . . . . . . . . p. 63
A.2.3.1 Fluxo Básico . . . . . . . . . . . . . . . . . . . . . . . p. 63
A.2.3.2 Fluxos Alternativos . . . . . . . . . . . . . . . . . . . . p. 63
A.2.4 Condições Prévias . . . . . . . . . . . . . . . . . . . . . . . . . . p. 63
A.2.5 Condições Posteriores . . . . . . . . . . . . . . . . . . . . . . . . p. 63
A.3 UC03 Atualizar Identicação de Exemplar . . . . . . . . . . . . . . . . p. 64
A.3.1 Descrição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 64
A.3.2 Atores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 64
A.3.3 Fluxo de Eventos . . . . . . . . . . . . . . . . . . . . . . . . . . p. 64
A.3.3.1 Fluxo Básico . . . . . . . . . . . . . . . . . . . . . . . p. 64
A.3.3.2 Fluxos Alternativos . . . . . . . . . . . . . . . . . . . . p. 65
A.3.4 Condições Prévias . . . . . . . . . . . . . . . . . . . . . . . . . . p. 65
A.3.5 Condições Posteriores . . . . . . . . . . . . . . . . . . . . . . . . p. 65
A.4 UC04 Remover Identicação de Exemplar . . . . . . . . . . . . . . . . p. 65
A.4.1 Descrição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 65
A.4.2 Atores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 65
A.4.3 Fluxo de Eventos . . . . . . . . . . . . . . . . . . . . . . . . . . p. 65
A.4.3.1 Fluxo Básico . . . . . . . . . . . . . . . . . . . . . . . p. 65
A.4.3.2 Fluxos Alternativos . . . . . . . . . . . . . . . . . . . . p. 66
A.4.4 Condições Prévias . . . . . . . . . . . . . . . . . . . . . . . . . . p. 66
A.4.5 Condições Posteriores . . . . . . . . . . . . . . . . . . . . . . . . p. 66
A.5 UC05 Criar Exemplar . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 66
A.5.1 Descrição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 66
A.5.2 Atores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 67
A.5.3 Fluxo de Eventos . . . . . . . . . . . . . . . . . . . . . . . . . . p. 67
A.5.3.1 Fluxo Básico . . . . . . . . . . . . . . . . . . . . . . . p. 67
A.5.3.2 Fluxos Alternativos . . . . . . . . . . . . . . . . . . . . p. 67
A.5.4 Condições Prévias . . . . . . . . . . . . . . . . . . . . . . . . . . p. 67
A.5.5 Condições Posteriores . . . . . . . . . . . . . . . . . . . . . . . . p. 67
A.6 UC06 Consultar Exemplar . . . . . . . . . . . . . . . . . . . . . . . . . p. 68
A.6.1 Descrição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 68
A.6.2 Atores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 68
A.6.3 Fluxo de Eventos . . . . . . . . . . . . . . . . . . . . . . . . . . p. 68
A.6.3.1 Fluxo Básico . . . . . . . . . . . . . . . . . . . . . . . p. 68
A.6.3.2 Fluxos Alternativos . . . . . . . . . . . . . . . . . . . . p. 68
A.6.4 Condições Prévias . . . . . . . . . . . . . . . . . . . . . . . . . . p. 69
A.6.5 Condições Posteriores . . . . . . . . . . . . . . . . . . . . . . . . p. 69
A.7 UC07 Atualizar Exemplar . . . . . . . . . . . . . . . . . . . . . . . . . p. 69
A.7.1 Descrição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 69
A.7.2 Atores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 69
A.7.3 Fluxo de Eventos . . . . . . . . . . . . . . . . . . . . . . . . . . p. 69
A.7.3.1 Fluxo Básico . . . . . . . . . . . . . . . . . . . . . . . p. 69
A.7.3.2 Fluxos Alternativos . . . . . . . . . . . . . . . . . . . . p. 70
A.7.4 Condições Prévias . . . . . . . . . . . . . . . . . . . . . . . . . . p. 70
A.7.5 Condições Posteriores . . . . . . . . . . . . . . . . . . . . . . . . p. 70
A.8 UC08 Remover Exemplar . . . . . . . . . . . . . . . . . . . . . . . . . . p. 70
A.8.1 Descrição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 70
A.8.2 Atores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 70
A.8.3 Fluxo de Eventos . . . . . . . . . . . . . . . . . . . . . . . . . . p. 71
A.8.3.1 Fluxo Básico . . . . . . . . . . . . . . . . . . . . . . . p. 71
A.8.3.2 Fluxos Alternativos . . . . . . . . . . . . . . . . . . . . p. 71
A.8.4 Condições Prévias . . . . . . . . . . . . . . . . . . . . . . . . . . p. 71
A.8.5 Condições Posteriores . . . . . . . . . . . . . . . . . . . . . . . . p. 71
A.9 UC09 Criar Chave de Identicação . . . . . . . . . . . . . . . . . . . . p. 72
A.9.1 Descrição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 72
A.9.2 Atores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 72
A.9.3 Fluxo de Eventos . . . . . . . . . . . . . . . . . . . . . . . . . . p. 72
A.9.3.1 Fluxo Básico . . . . . . . . . . . . . . . . . . . . . . . p. 72
A.9.3.2 Fluxos Alternativos . . . . . . . . . . . . . . . . . . . . p. 72
A.9.4 Condições Prévias . . . . . . . . . . . . . . . . . . . . . . . . . . p. 73
A.9.5 Condições Posteriores . . . . . . . . . . . . . . . . . . . . . . . . p. 73
A.10 UC10 Consultar Chave de Identicação . . . . . . . . . . . . . . . . . . p. 73
A.10.1 Descrição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 73
A.10.2 Atores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 73
A.10.3 Fluxo de Eventos . . . . . . . . . . . . . . . . . . . . . . . . . . p. 74
A.10.3.1 Fluxo Básico . . . . . . . . . . . . . . . . . . . . . . . p. 74
A.10.3.2 Fluxos Alternativos . . . . . . . . . . . . . . . . . . . . p. 74
A.10.4 Condições Prévias . . . . . . . . . . . . . . . . . . . . . . . . . . p. 74
A.10.5 Condições Posteriores . . . . . . . . . . . . . . . . . . . . . . . . p. 74
A.11 UC11 Atualizar Chave de Identicação . . . . . . . . . . . . . . . . . . p. 75
A.11.1 Descrição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 75
A.11.2 Atores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 75
A.11.3 Fluxo de Eventos . . . . . . . . . . . . . . . . . . . . . . . . . . p. 75
A.11.3.1 Fluxo Básico . . . . . . . . . . . . . . . . . . . . . . . p. 75
A.11.3.2 Fluxos Alternativos . . . . . . . . . . . . . . . . . . . . p. 76
A.11.4 Condições Prévias . . . . . . . . . . . . . . . . . . . . . . . . . . p. 76
A.11.5 Condições Posteriores . . . . . . . . . . . . . . . . . . . . . . . . p. 76
A.12 UC12 Remover Chave de Identicação . . . . . . . . . . . . . . . . . . p. 76
A.12.1 Descrição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 76
A.12.2 Atores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 76
A.12.3 Fluxo de Eventos . . . . . . . . . . . . . . . . . . . . . . . . . . p. 76
A.12.3.1 Fluxo Básico . . . . . . . . . . . . . . . . . . . . . . . p. 76
A.12.3.2 Fluxos Alternativos . . . . . . . . . . . . . . . . . . . . p. 77
A.12.4 Condições Prévias . . . . . . . . . . . . . . . . . . . . . . . . . . p. 77
A.12.5 Condições Posteriores . . . . . . . . . . . . . . . . . . . . . . . . p. 77
A.13 UC13 Criar Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 77
A.13.1 Descrição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 77
A.13.2 Atores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 77
A.13.3 Fluxo de Eventos . . . . . . . . . . . . . . . . . . . . . . . . . . p. 78
A.13.3.1 Fluxo Básico . . . . . . . . . . . . . . . . . . . . . . . p. 78
A.13.3.2 Fluxos Alternativos . . . . . . . . . . . . . . . . . . . . p. 78
A.13.4 Condições Prévias . . . . . . . . . . . . . . . . . . . . . . . . . . p. 78
A.13.5 Condições Posteriores . . . . . . . . . . . . . . . . . . . . . . . . p. 78
A.14 UC14 Consultar Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . p. 79
A.14.1 Descrição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 79
A.14.2 Atores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 79
A.14.3 Fluxo de Eventos . . . . . . . . . . . . . . . . . . . . . . . . . . p. 79
A.14.3.1 Fluxo Básico . . . . . . . . . . . . . . . . . . . . . . . p. 79
A.14.3.2 Fluxos Alternativos . . . . . . . . . . . . . . . . . . . . p. 79
A.14.4 Condições Prévias . . . . . . . . . . . . . . . . . . . . . . . . . . p. 80
A.14.5 Condições Posteriores . . . . . . . . . . . . . . . . . . . . . . . . p. 80
A.15 UC15 Atualizar Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . p. 80
A.15.1 Descrição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 80
A.15.2 Atores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 80
A.15.3 Fluxo de Eventos . . . . . . . . . . . . . . . . . . . . . . . . . . p. 80
A.15.3.1 Fluxo Básico . . . . . . . . . . . . . . . . . . . . . . . p. 80
A.15.3.2 Fluxos Alternativos . . . . . . . . . . . . . . . . . . . . p. 81
A.15.4 Condições Prévias . . . . . . . . . . . . . . . . . . . . . . . . . . p. 81
A.15.5 Condições Posteriores . . . . . . . . . . . . . . . . . . . . . . . . p. 81
A.16 UC16 Remover Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 81
A.16.1 Descrição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 81
A.16.2 Atores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 81
A.16.3 Fluxo de Eventos . . . . . . . . . . . . . . . . . . . . . . . . . . p. 82
A.16.3.1 Fluxo Básico . . . . . . . . . . . . . . . . . . . . . . . p. 82
A.16.3.2 Fluxos Alternativos . . . . . . . . . . . . . . . . . . . . p. 82
A.16.4 Condições Prévias . . . . . . . . . . . . . . . . . . . . . . . . . . p. 82
A.16.5 Condições Posteriores . . . . . . . . . . . . . . . . . . . . . . . . p. 82
A.17 UC17 Criar Usuário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 83
A.17.1 Descrição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 83
A.17.2 Atores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 83
A.17.3 Fluxo de Eventos . . . . . . . . . . . . . . . . . . . . . . . . . . p. 83
A.17.3.1 Fluxo Básico . . . . . . . . . . . . . . . . . . . . . . . p. 83
A.17.3.2 Fluxos Alternativos . . . . . . . . . . . . . . . . . . . . p. 83
A.17.4 Condições Prévias . . . . . . . . . . . . . . . . . . . . . . . . . . p. 84
A.17.5 Condições Posteriores . . . . . . . . . . . . . . . . . . . . . . . . p. 84
A.18 UC18 Consultar Usuário . . . . . . . . . . . . . . . . . . . . . . . . . . p. 84
A.18.1 Descrição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 84
A.18.2 Atores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 84
A.18.3 Fluxo de Eventos . . . . . . . . . . . . . . . . . . . . . . . . . . p. 84
A.18.3.1 Fluxo Básico . . . . . . . . . . . . . . . . . . . . . . . p. 84
A.18.3.2 Fluxos Alternativos . . . . . . . . . . . . . . . . . . . . p. 84
A.18.4 Condições Prévias . . . . . . . . . . . . . . . . . . . . . . . . . . p. 85
A.18.5 Condições Posteriores . . . . . . . . . . . . . . . . . . . . . . . . p. 85
A.19 UC19 Atualizar Usuário . . . . . . . . . . . . . . . . . . . . . . . . . . p. 85
A.19.1 Descrição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 85
A.19.2 Atores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 85
A.19.3 Fluxo de Eventos . . . . . . . . . . . . . . . . . . . . . . . . . . p. 85
A.19.3.1 Fluxo Básico . . . . . . . . . . . . . . . . . . . . . . . p. 85
A.19.3.2 Fluxos Alternativos . . . . . . . . . . . . . . . . . . . . p. 86
A.19.4 Condições Prévias . . . . . . . . . . . . . . . . . . . . . . . . . . p. 86
A.19.5 Condições Posteriores . . . . . . . . . . . . . . . . . . . . . . . . p. 86
A.20 UC20 Remover Usuário . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 86
A.20.1 Descrição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 86
A.20.2 Atores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 86
A.20.3 Fluxo de Eventos . . . . . . . . . . . . . . . . . . . . . . . . . . p. 86
A.20.3.1 Fluxo Básico . . . . . . . . . . . . . . . . . . . . . . . p. 86
A.20.3.2 Fluxos Alternativos . . . . . . . . . . . . . . . . . . . . p. 87
A.20.4 Condições Prévias . . . . . . . . . . . . . . . . . . . . . . . . . . p. 87
A.20.5 Condições Posteriores . . . . . . . . . . . . . . . . . . . . . . . . p. 87
A.21 UC21 Gerar Relatório . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 87
A.21.1 Descrição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 87
A.21.2 Atores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 88
A.21.3 Fluxo de Eventos . . . . . . . . . . . . . . . . . . . . . . . . . . p. 88
A.21.3.1 Fluxo Básico . . . . . . . . . . . . . . . . . . . . . . . p. 88
A.21.3.2 Fluxos Alternativos . . . . . . . . . . . . . . . . . . . . p. 88
A.21.4 Condições Prévias . . . . . . . . . . . . . . . . . . . . . . . . . . p. 88
A.21.5 Condições Posteriores . . . . . . . . . . . . . . . . . . . . . . . . p. 89
Apêndice B -- Relatório de Erros do Sistema p. 90
B.1 Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 90
B.1.1 TC01 Efetuar login com sucesso . . . . . . . . . . . . . . . . . . p. 90
B.1.2 TC02 Efetuar login com usuário inválido . . . . . . . . . . . . . p. 90
B.1.3 TC03 Efetuar login com usuário em branco . . . . . . . . . . . . p. 90
B.1.4 TC04 Efetuar login com senha inválida . . . . . . . . . . . . . . p. 90
B.1.5 TC05 Efetuar login com senha em branco . . . . . . . . . . . . p. 91
B.2 Identicação de exemplar . . . . . . . . . . . . . . . . . . . . . . . . . . p. 91
B.2.1 TC06 Identicar exemplar com sucesso . . . . . . . . . . . . . . p. 91
B.2.2 TC07 Identicar exemplar alternando entre características da chave
de identicação . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 91
B.2.3 TC08 Remover identicação de exemplar . . . . . . . . . . . . . p. 91
B.3 Exemplar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 92
B.3.1 TC09 Criar exemplar com sucesso . . . . . . . . . . . . . . . . . p. 92
B.3.2 TC10 Criar exemplar com Quantidade < 1 . . . . . . . . . . . . p. 92
B.3.3 TC11 Criar exemplar com Quantidade > 100 . . . . . . . . . . p. 92
B.3.4 TC12 Criar exemplar com Nome > 100 caracteres . . . . . . . . p. 92
B.3.5 TC13 Criar exemplar com Nome em branco . . . . . . . . . . . p. 93
B.3.6 TC14 Criar exemplar com Descrição > 1000 . . . . . . . . . . . p. 93
B.3.7 TC15 Criar exemplar com Data da coleta inválida . . . . . . . . p. 93
B.3.8 TC16 Remover exemplar . . . . . . . . . . . . . . . . . . . . . . p. 93
B.4 Chave de Identicação . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 94
B.4.1 TC17 Criar chave de identicação com sucesso . . . . . . . . . . p. 94
B.4.2 TC18 Criar chave de identicação com Nome > 100 caracteres . p. 95
B.4.3 TC19 Criar chave de identicação com Nome em branco . . . . p. 95
B.4.4 TC20 Criar chave de identicação com Descrição > 1000 caracteres p. 95
B.4.5 TC21 Criar chave de identicação com Autor > 100 caracteres . p. 96
B.4.6 TC22 Criar chave de identicação com Bibliograa > 1000 carac-
teres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 96
B.4.7 TC23 Criar chave de identicação adicionando passo com Carac-
terística A > 1000 . . . . . . . . . . . . . . . . . . . . . . . . . p. 96
B.4.8 TC24 Criar chave de identicação adicionando passo com Carac-
terística A em branco . . . . . . . . . . . . . . . . . . . . . . . . p. 96
B.4.9 TC25 Criar chave de identicação adicionando passo com Carac-
terística B > 1000 . . . . . . . . . . . . . . . . . . . . . . . . . p. 97
B.4.10 TC26 Criar chave de identicação adicionando passo com Carac-
terística B em branco . . . . . . . . . . . . . . . . . . . . . . . . p. 97
B.4.11 TC27 Remover chave de identicação . . . . . . . . . . . . . . . p. 97
B.5 Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 98
B.5.1 TC28 Criar projeto com sucesso . . . . . . . . . . . . . . . . . . p. 98
B.5.2 TC29 Criar projeto com Nome > 100 caracteres . . . . . . . . . p. 98
B.5.3 TC30 Criar projeto com Nome em branco . . . . . . . . . . . . p. 99
B.5.4 TC31 Remover projeto . . . . . . . . . . . . . . . . . . . . . . . p. 99
B.6 Usuário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 99
B.6.1 TC32 Criar usuário com sucesso . . . . . . . . . . . . . . . . . . p. 99
B.6.2 TC33 Criar usuário com Nome > 100 caracteres . . . . . . . . . p. 99
B.6.3 TC34 Criar usuário com Nome em branco . . . . . . . . . . . . p. 100
B.6.4 TC35 Criar usuário com Instituição > 100 caracteres . . . . . . p. 100
B.6.5 TC36 Criar usuário com Instituição em branco . . . . . . . . . . p. 100
B.6.6 TC37 Criar usuário com E-mail inválido . . . . . . . . . . . . . p. 100
B.6.7 TC38 Criar usuário com E-mail > 100 caracteres . . . . . . . . p. 100
B.6.8 TC39 Criar usuário com E-mail em branco . . . . . . . . . . . . p. 100
B.6.9 TC40 Criar usuário com Login > 100 caracteres . . . . . . . . . p. 101
B.6.10 TC41 Criar usuário com Login em branco . . . . . . . . . . . . p. 101
B.6.11 TC42 Criar usuário com Senha > 100 caracteres . . . . . . . . . p. 101
B.6.12 TC43 Criar usuário com Senha em branco . . . . . . . . . . . . p. 101
B.6.13 TC44 Remover usuário . . . . . . . . . . . . . . . . . . . . . . . p. 101
B.7 Relatório . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 102
B.7.1 TC45 Gerar relatório com sucesso . . . . . . . . . . . . . . . . . p. 102
23
1 Introdução
A identicação de seres vivos é uma atividade apoiada por chaves de identicação,
um recurso muito utilizado no ensino, pesquisa e até na prática prossional da biologia.
Através da vericação de uma série de características de um exemplar de ser vivo ana-
lisado, ela auxilia na sua identicação de acordo com uma taxonomia1, ou seja, na sua
classicação em táxon2 do tipo reino, lo, classe, ordem, família, gênero e espécie.
Como as chaves de identicação costumam ocupar várias páginas de papel, a iden-
ticação de um exemplar geralmente envolve navegar por várias páginas repetidas vezes
para vericação. Em geral, este é um processo ineciente e sujeito a erros.
Desde 2013, professores do Centro de Biociências e do Instituto Metrópole Digital da
Universidade Federal do Rio Grande do Norte vêm desenvolvendo sistemas computacionais
de apoio ao ensino e à prática prossional na área de Parasitologia e Entomologia. Um
dos projetos de extensão sendo executado teve por objetivo desenvolver uma ferramenta
computacional que apoie o processo sistemático, detalhista e algumas vezes longo de
identicação de exemplares de seres vivos. A equipe de desenvolvimento foi composta
pelo autor deste trabalhos e outros alunos de graduação orientados pelo professor Bruno
Santana.
O processo de desenvolvimento de software contempla a realização de um conjunto
de ações e tarefas para criar software de alta qualidade. O processo dene uma série
de atividades para guiar o desenvolvimento do software dentro do prazo estabelecido,
contando com o apoio de toda equipe, gerentes, analistas, projetistas, entre outros, além
dos próprios patrocinadores, para colaborar com a denição, construção e vericação do
software (PRESSMAN, 2011). As atividades do processo envolvem basicamente: requisitos,
projeto, implementação, teste, implantação e manutenção.
1Taxonomia é a ciência que dene a classicação de seres vivos, individualmente ou em grupo, com
base em características comuns.
2Táxon é a unidade taxonômica associada à classicação de seres vivos.
24
1.1 Objetivos do Trabalho
Dentre as atividades do processo de desenvolvimento de software, o autor deste traba-
lho contou com apenas a colaboração do seu orientador para realizar a análise e especica-
ção de requisitos e os testes funcionais (manuais e automatizados) do sistema de chave de
identicação, desenvolvido no âmbito do projeto de extensão (em cinza na Figura 1). As
demais atividades do processo de desenvolvimento foram de responsabilidade dos demais
participantes do projeto de extensão (em branco na Figura 1).
Um cuidado especial deste trabalho foi realizar a especicação de requisitos de forma
iterativa para aprimorar a compreensão do problema. Além disso, houve um cuidado no
planejamento e execução dos testes manuais e automatizados para que cobrissem partes
importantes do software e para que os testes automatizados pudessem ser mantidos ao
longo do tempo.
Como resultado deste trabalho, temos em requisitos a denição do diagrama e es-
pecicação textual dos casos de uso, o diagrama de classes e especicação de requisitos
funcionais e não funcionais. Já sobre os testes, temos o plano dos testes, denição dos
casos de teste derivados dos casos de uso, o código dos testes automatizados e o relatório
das falhas encontradas.
Figura 1: Processo de software do sistema de chave de identicação
Fonte: Elaboração própria
25
1.2 Organização do Trabalho
No Capítulo 2 é apresentada a fundamentação teórica deste trabalho, expondo os
conceitos essenciais para a sua compreensão, como: chave de identicação, requisitos de
software e testes de software. O Capítulo 3 apresenta um relato da realização das ati-
vidades de requisitos durante a fase inicial do desenvolvimento do sistema de chave de
identicação. No Capítulo 4 são descritas as atividades de planejamento e projeto relaci-
onadas ao testes do sistema, assim como a execução e os resultados dos testes manuais e
automatizados. O Capítulo 5 traz as considerações nais deste trabalho.
26
2 Fundamentação Teórica
Este capítulo traz conceitos fundamentais para a compreensão do trabalho. A seguir
serão feitas explanações a respeito do que se trata uma chave de identicação, além de
detalhar as atividades de requisitos e testes em um processo de software.
2.1 Chave de Identicação
Na biologia, uma chave de identicação dene etapas em que o biólogo verica ca-
racterísticas de um exemplar para determinar se ele pertence a um táxon, ou seja, se o
exemplar pertence a um grupo de seres vivos com características semelhantes. Tradicio-
nalmente as chaves de identicação assumem a forma dicotômica. Desta forma, em cada
etapa a chave apresenta duas descrições de características diferentes que o biólogo deve
vericar. Quando for vericado que o exemplar possui características conforme denido
numa etapa da chave, a chave pode indicar o próximo passo e/ou o táxon identicado.
Uma chave pode identicar um exemplar como sendo pertencente a diferentes níveis da
taxonomia (por exemplo, o gato doméstico pertence ao reino Animalia, lo Chordata,
classe Mammalia, ordem Carnivora, família Felidae, gênero Felis, espécie Felis catus).
OLIVEIRA-COSTA (2013) apresenta uma chave de identicação das principais famílias
da ordem Diptera com interesse forense. Esta chave assume que os exemplares que estão
sendo vericados são da ordem Diptera e permite ao biólogo identicar se eles pertencem às
famílias Stratiomyidae, Fanniidae, Muscidae, etc. Na Figura 2 é possível ver um fragmento
desta chave:
27
Figura 2: Fragmento de chave de identicação das principais famílias da ordem Diptera
Fonte: Elaboração própria
Numa situação hipotética de vericação, esta chave de identicação poderia ser utili-
zada da seguinte forma:
1◦ O biólogo vericou que o exemplar não possui as características descritas em 1a
(Corpo fortemente achatado dorsoventralmente).
2◦ O biólogo passa a vericar as características descritas em 1b (Corpo cilíndrico)
3◦ O biólogo conrmou que o exemplar possui as características descritas em 1b, a chave
de identicação ainda não indicou nenhum táxon identicado, e ela determina qual
o próximo passo de vericação e ser realizado (continua no passo 3).
4◦ O biólogo vericou que o exemplar possui as características descritas em 3a (Tu-
bérculos do segmento 12 ausentes). A chave de identicação indica que o exemplar
vericado pertence à família (táxon) Muscidae, encerrando os passos de identica-
ção.
Se o biólogo quiser identicar a quais níveis inferiores da família Muscidade (por
exemplo, gênero Musca e espécie Musca domestica) o exemplar pertence, ele deve utilizar
outra chave que tenha esta família como táxon inicial.
2.2 Requisitos de Software
A engenharia de requisitos estabelece uma base para a denição de requisitos de
software, idealmente denidos na fase inicial do seu desenvolvimento. O processo da enge-
28
nharia de requisitos (Figura 3) pode ser organizado em um conjunto de atividades básicas
(PRESSMAN, 2011):
Figura 3: Processo da engenharia de requisitos
Fonte: Elaboração própria
1. Elicitação: consiste em coletar informações sobre as necessidades e desejos dos inte-
ressados no sistema;
2. Análise: consiste em analisar esses dados para compreender as necessidades dos
interessados, e denir um conjunto de requisitos de um sistema computacional que
as atenda. Isso envolve compreender diferentes visões do sistema, negociar uma
solução razoável a todos os interessados, considerar a viabilidade de desenvolver tal
solução;
3. Especicação: consiste em documentar o que foi aprendido e especicar os requisitos
do sistema que será desenvolvido. Essa especicação deve evitar ambiguidades;
4. Validação: consiste em avaliar cuidadosamente se as necessidades dos envolvidos
foram compreendidas corretamente e se os requisitos identicados atendem a tais
necessidades. Além disso, é importante vericar a consistência e completude da
documentação produzida.
Com os requisitos especicados, é possível dar continuidade ao processo de desenvol-
vimento pela implementação e teste do sistema. À medida que se aprende mais sobre
as necessidades dos interessados e sobre a solução sendo desenvolvida, os requisitos do
sistema vão sofrendo modicações que precisam ser bem gerenciadas e documentadas.
2.3 Testes de Software
Segundo MYERS (2004), teste de software é um processo, ou uma série de processos,
denidos para garantir que um código faz o que ele foi projetado para fazer e que não faz
29
nada que não foi especicado para fazer.
Não existe nenhum método que garanta que um software está livre de erros. Dessa
forma, não e possível armar que existe um sistema livre de falhas.
A m de amenizar este problema o máximo possível, a garantia de qualidade é associ-
ada ao processo de desenvolvimento de software com a adoção de atividades de testes. As
atividades de testes envolvem estratégias, técnicas, fases, artefatos e formas de execução
como os discutidos a seguir.
2.3.1 Estratégias de Desenvolvimento de Testes
As estratégias de desenvolvimento de testes denem a integração de atividades de
testes no processo de desenvolvimento de software. Algumas das estratégias discutidas
na literatura são: Test After Development (TAD), Test-Driven Development (TDD) e
Behavior-Driven Development (BDD).
2.3.1.1 Test After Development (TAD)
TAD é a estratégia de implementar e executar os testes depois que um ou todos os
módulos de um sistema estão nalizados (BERNARDO, 2011). Nessa abordagem é comum
realizar testes de caixa preta, pois para realizar testes em tempo de execução é necessário
que o sistema ou parte dele esteja desenvolvido (Figura 4). Como os testes são realizados
após a implementação do sistema, TAD não tem o objetivo de impactar diretamente
a denição da arquitetura e a codicação do sistema durante seu desenvolvimento. O
objetivo é identicar falhas que quando forem corrigidas implicarão em mudanças no
código-fonte e, eventualmente, na arquitetura.
30
Figura 4: Fluxo de TAD
Fonte: BERNARDO (2011)
2.3.1.2 Test-Driven Development (TDD)
TDD é uma prática de desenvolver testes de software antes de escrever os códigos-
fonte de suas respectivas funcionalidades (BERNARDO, 2011). Deste modo é possível re-
alizar testes de caixa branca. Ao contrário de TAD, TDD tem como objetivo inuenciar
desde o início na denição da arquitetura e do código-fonte. A execução de TDD consiste
na repetição de um curto ciclo de atividades (Figura 5).
Figura 5: Ciclo de atividades de TDD
Fonte: BERNARDO (2011)
31
Este ciclo é denido pelas seguintes atividades:
1. Escrever um caso de teste;
2. Escrever um trecho de código suciente para o novo caso de teste ter sucesso de
modo que não quebre os testes previamente implementados;
3. Refatorar o código produzido para deixá-lo mais organizado.
2.3.1.3 Behavior-Driven Development (BDD)
É uma estratégia para ajudar as equipes a criar e entregar softwares de alta qualidade
mais rapidamente. BDD fornece uma linguagem comum baseada em frases simples e
estruturadas expressadas em inglês (ou na língua nativa das partes interessadas) que
facilitam a comunicação entre os membros da equipe do projeto e as partes interessadas
da empresa (SMART, 2014).
O objetivo da abordagem é retirar o foco dos detalhes técnicos do código e focar na
razão da sua criação, denindo, através de linguagem ubíqua entre cliente e equipe de de-
senvolvimento, comportamentos testáveis de acordo com as necessidades do usuário, antes
de iniciar a codicação para evitar defeitos baseados no descumprimento dos requisitos
do sistema.
2.3.2 Técnicas de Testes
As técnicas de testes orientam a denição de casos de teste. Dentre as técnicas exis-
tentes, serão abordadas a técnica funcional e a técnica estrutural.
2.3.2.1 Teste Funcional
Conhecido também como teste de caixa preta, o teste funcional é uma técnica usada
para projetar casos de teste na qual não é preciso ter acesso ao código fonte do software
para testá-lo (DELAMARO; MALDONADO; JINO, 2007). O testador fornece as entradas e
avalia as saídas para vericar a conformidade do software com a sua especicação.
Alguns exemplos de critérios de teste funcional são citados por DELAMARO; MALDO-
NADO; JINO (2007):
• Particionamento em classes de equivalência: este critério divide o domínio de en-
trada de dados em classes válidas e inválidas com base nas condições descritas na
32
especicação. Em seguida, o menor número de casos de teste é selecionado levando
em consideração a hipótese de que um elemento de uma classe pode representá-la
por completo.
• Análise do valor limite: este critério complementa o particionamento em classes de
equivalência associando os limites às condições de entrada. Dessa forma, os casos de
teste são selecionados nas fronteiras das classes, pois nesses pontos se concentra um
grande número de erros.
• Grafo de causa-efeito: este critério baseia-se nas possíveis combinações das condições
de entrada. Primeiramente, levanta-se as possíveis condições de entrada (causas) e
as possíveis ações (efeitos). Em seguida, constrói-se um grafo fazendo a relação das
causas e efeitos. Por m, transforma-se o grafo em uma tabela de decisão e a partir
dela os casos de teste são denidos.
2.3.2.2 Teste Estrutural
O teste estrutural, chamado também de teste de caixa branca, tem como objetivo
analisar o comportamento de um software internamente a partir de uma implementa-
ção. Esta técnica requer a execução de partes do software. Os caminhos lógicos do teste
são percorridos, fornecendo-se casos de teste que põe à prova tanto conjuntos especícos
de condições e/ou laços bem como pares de denições e usos de variáveis (DELAMARO;
MALDONADO; JINO, 2007).
2.3.3 Fases de Testes
As fases de testes estão relacionadas com o escopo do sistema analisado, tais como
Testes de Unidade, Testes de Integração, Testes de Sistema e Testes de Aceitação.
2.3.3.1 Testes de Unidade
Uma unidade é a parte mínima testável de um código-fonte. Sendo assim, o objetivo
nessa fase é testar cada unidade do projeto individualmente e garantir que o código escrito
esteja de acordo com sua especicação antes de integrá-lo com as outras unidades. Esse
teste ocorre durante a fase de implementação e o acesso ao código fonte é necessário
para realizá-lo. Com o teste de unidade é possível identicar defeitos na lógica e na
implementação de cada método do código fonte.
33
2.3.3.2 Testes de Integração
É a fase em que a combinação das unidades do sistema é testada a m de encontrar
possíveis falhas na interação entre elas. Existem diferentes abordagens para realizar um
teste de integração: big bang, top-down, bottom-up, sandwich, entre outros.
2.3.3.3 Testes de Sistema
No processo de testes, esta é a fase em que se testa o sistema como um todo sob
o ponto de vista de um usuário nal. Todas as funcionalidades do sistema são testadas
avaliando a conformidade dos requisitos funcionais e não funcionais. Para realizá-lo, o
ambiente e os dados de teste devem simular condições similares às de situações reais do
uso do sistema por seus usuários.
2.3.3.4 Testes de Aceitação
Nesta fase o objetivo é testar as funcionalidades do sistema de acordo com critérios
de aceitação denidos pelos usuários. Geralmente os testes de aceitação são realizados por
um grupo restrito de usuários nais do sistema.
2.3.4 Artefatos de Testes
A documentação dos testes propõe a criação de alguns artefatos para guiar o plane-
jamento e a execução dos testes, dentre os quais pode-se citar o Plano de Teste e o Caso
de Teste.
2.3.4.1 Plano de Teste
No desenvolvimento de software, uma das principais atividades a serem realizadas é
o planejamento. Um plano tem o objetivo de identicar informações e denir a execução
das tarefas de um projeto a m de alcançar a sua meta. Entre as atividades que estão
inseridas em um planejamento, três podem ser destacadas como principais:
1. Denir o cronograma de atividades;
2. Denir os recursos necessário;
3. Denir os marcos de projeto.
34
O plano de teste é um documento gerado durante o desenvolvimento de um sistema
que guia a execução e controle das atividades de testes (RIOS; MOREIRA, 2013). Nele
deve existir um conjunto de informações que permita o gerente de projeto coordenar as
atividades executadas e também monitorar o seu progresso, vericando se o que está sendo
feito está em conformidade com o que foi denido.
Itens de um plano de teste:
• Introdução: deve conter a denição do escopo do projeto e os objetivos do docu-
mento;
• Requisitos a serem vericados e validados: deve denir quais requisitos serão testa-
dos;
• Diretrizes/Recursos necessários para a realização dos testes: deve apresentar a des-
crição da equipe, quais tipos de testes serão realizados e quais ferramentas serão
utilizadas;
• Cronograma de atividades: deve descrever os marcos de projeto com a data de início
e m de cada atividade.
2.3.4.2 Caso de Teste
Um caso de teste é um documento no qual é denido um conjunto de entradas de
dados, condições de execução e resultados esperados para um objetivo especíco (MYERS,
2004). Como, por exemplo, testar o caminho de determinado programa ou vericar o
cumprimento de um requisito especíco. Para testes funcionais, os casos de teste são
criados a partir de um subconjunto dos requisitos, como casos de uso, características de
desempenho e os riscos relacionados ao projeto.
Como uma regra, as especicações de caso de teste são mais úteis onde a própria im-
plementação de teste será muito complexa para ser compreendida sozinha, sem o suporte
de uma explicação mais abstrata fornecida pelo caso de teste.
Itens de um caso de teste:
1. Descrição
2. Condição de execução
(a) Pré-condições
35
(b) Entradas
(c) Pontos de observação
(d) Pontos de controle
(e) Resultados esperados
(f) Pós-condições
2.3.5 Formas de Execução de Testes
Existem duas principais formas de execução de testes: testes manuais e testes au-
tomatizados. O teste manual de software é realizado por um ser humano navegando
cuidadosamente pelas telas da aplicação, tentando várias combinações de uso e entrada,
comparando os resultados com o comportamento esperado e registrando suas observações
(SMARTBEAR, 2017). Os testes manuais são repetidos frequentemente durante os ciclos de
desenvolvimento para alterações no código fonte e outras situações, como múltiplos ambi-
entes operacionais e congurações de hardware, tornando-se uma atividade dispendiosa,
demorada e sujeita a erro humano.
O teste automatizado consiste na criação de scripts ou programas de computa-
dor para realizar os testes. Apesar da implementação dos testes exigir esforço humano, a
execução automatizada dos testes pode ser realizada em bateria (grande conjunto), reque-
rendo apenas pequeno esforço humano para iniciá-la. Testes automatizados, nos quais os
times de garantia de qualidade usam ferramentas de software para executar testes repeti-
tivos automaticamente, ajudam os times a melhorar a qualidade do software e aproveitar
ao máximo seus recursos de teste (SELENIUM, 2017). Uma vez criados, os testes automa-
tizados podem ser facilmente repetidos e estendidos para executar tarefas inviáveis com o
teste manual. O teste automatizado de software pode reduzir de dias para horas o tempo
para executar testes repetitivos. Uma economia de tempo que se traduz diretamente em
economia de custos.
36
3 Requisitos do Sistema de Chave de
Identicação
Este capítulo apresenta as atividades de requisitos realizadas durante a fase inicial do
desenvolvimento do sistema de chave de identicação.
3.1 Análise dos Requisitos
No processo de engenharia de requisitos do sistema de chave de identicação, a ati-
vidade de elicitação de requisitos foi realizada por terceiros, integrantes do projeto de
extensão. Eles coletaram informações relevantes ao projeto através da realização de entre-
vistas, análise de documentações, observações em campo e brainstormings com professores
e alunos de Ciências Biológicas. Foram coletados documentos, explicações e exemplos que
detalhavam o passo a passo da execução do processo de identicação de espécies por meio
do uso de chave de identicação (OLIVEIRA-COSTA, 2013; LINARDI; GUIMARÃES, 2000).
O autor deste trabalho colaborou ativamente com a análise e especicação dos requi-
sitos deste sistema. Os materiais e informações coletadas foram interpretadas para uma
compreensão básica do que é uma chave de identicação, para a criação de casos de uso
e diagramas de classe (BOOCH; RUMBAUGH; JACOBSON, 2006) e para a especicação de
requisitos conforme discutido a seguir.
3.1.1 Diagrama de Casos de Uso
A primeira versão do diagrama continha dez casos de uso (Figura 6): Criar / Atualizar
/ Consultar / Remover Chave de Identicação, Identicar Espécie, Criar / Atualizar /
Consultar / Remover Projeto de Espécies e Gerar Relatório. Com isso, seria possível salvar
as informações de uma espécie, tais como características, taxa e imagens, através do caso
de uso Criar Chave de Identicação e posteriormente realizar a sua identicação por meio
37
do caso de uso Identicar Espécie. Foi denido ainda o conceito inicial de projeto com a
intenção de ter a possibilidade de registrar várias identicações de espécies em um único
arquivo.
Figura 6: Diagrama de casos de uso  versão 1
Fonte: Elaboração própria
Esta versão foi revisada após uma releitura do material coletado e das demais infor-
mações aprendidas com professores e alunos de Ciências Biológicas. Foi vericado se os
casos de uso estavam coerentes com as atividades realizadas em sala de aula e em campo,
para que eles estejam éis às reais necessidades dos usuários.
Na nova versão do diagrama foram adicionados mais oito casos de uso: Criar / Atua-
lizar / Consultar / Remover exemplar e Criar / Atualizar / Consultar / Remover usuário.
O termo espécie foi substituído por exemplar para referenciar exemplares (indivíduos
e/ou unidades) de seres vivos registrados no sistema e não sua classicação taxonômica
(Reino, Filo, Classe, Ordem, Família, Gênero e Espécie) resultante de uma identicação.
Sobre a identicação, percebeu-se que o caso de uso Identicar exemplar (equivalente
ao caso de uso Identicar espécie na versão anterior) deveria ser expandido para as quatro
38
operações básicas de um objeto, contemplando, além da criação, a alteração, a consulta
e a remoção de identicações de exemplares no sistema. Como resultado, tem-se vinte e
um casos de uso no sistema. A Figura 7 ilustra a versão nal do diagrama de casos de uso
com os novos casos destacados em um fundo cinza.
Figura 7: Diagrama de casos de uso  versão nal
Fonte: Elaboração própria
3.1.2 Diagrama de Classes
Dando continuidade à análise das informações coletadas, começou-se a modelar em
um diagrama de classes (BOOCH; RUMBAUGH; JACOBSON, 2006) os dados que o sistema
deve processar. Na primeira versão do diagrama de classes (Figura 8), o usuário avaliava
as características de um exemplar comparando-as com as características da chave disponi-
bilizadas pelo sistema; se elas fossem iguais, o atributo valor da classe Valor da Vericação
receberia o booleano true, caso contrário, receberia o booleano false e seguiria para o pró-
ximo passo da vericação. Quando o atributo próximo da classe Característica recebesse
o valor null, isso indicaria que o exemplar pertenceria ao táxon da chave vericado.
39
Figura 8: Diagrama de classes  versão 1
Fonte: Elaboração própria
Nesse modelo, o objetivo era que a identicação abrangesse as chaves de identicação
do tipo multi-access key1.
Inicialmente foi denido apenas o conceito de identicação para o diagrama de classes,
onde o usuário estava limitado a identicar um exemplar por vez sem a possibilidade de
agrupar um conjunto de identicações. Essa limitação se tornou motivação para denir
o conceito de projeto no diagrama de classes. Com isso seria possível um usuário reali-
zar várias identicações de exemplares, relacionadas ou não, e salvá-las para ter acesso
posteriormente.
Após uma revisão do modelo proposto até o momento, realizada durante uma iteração
da atividade de validação, notou-se que era preciso alterar a abordagem de identicação
multi-access key devido às necessidades de adequação ao conteúdo levantado durante
a análise de requisitos. Isso fez com que a chave de identicação mudasse para o tipo
single-access key2, obedecendo uma estrutura dicotômica comum na literatura de biologia
(WIKIBOOKS, 2014).
Como é possível ver, a versão nal do diagrama de classes (Figura 9) eliminou as
1Chave de identicação em que a sequência e estrutura de passos de identicação é livre.
2Chave de identicação em que a sequência e estrutura de passos de identicação é xada pelo autor.
40
classes Característica e Valor da Vericação existentes na primeira versão, para contemplar
a mudança do tipo da chave de identicação. Nessa reformulação, foram denidas as
classes Táxon e Passo, onde um passo de vericação é um conjunto de características que
devem ser vericadas no exemplar para o táxon poder ser identicado. Na versão nal do
diagrama também foi denida a classe Usuário para registrar o autor de uma chave em
sua criação.
Figura 9: Diagrama de classes  versão nal
Fonte: Elaboração própria
A m de tornar o design do projeto modular, adotou-se o padrão de arquitetura de
software model-view-controller (MVC) para o projeto (Figura 10):
• Model : representada na gura pelas classes de cor branca (Táxon, Identicação,
Chave de Identicação, Passo, Exemplar, Projeto e Usuário), essa camada possui as
classes que implementam as regras de negócio do sistema;
41
• View : representada na gura pelas classes de cor cinza claro, essa camada é respon-
sável por todo conjunto de dados exibidos através de uma interface de usuário;
• Controller : representada na gura pela classe de cor cinza escuro, essa camada lida
com todo o uxo de informação que passa pelo sistema com o auxílio das camadas
Model e View.
Figura 10: Diagrama de classes  versão nal MVC
Fonte: Elaboração própria
3.2 Especicação dos Requisitos
O documento de requisitos do sistema foi usado como base para escrever as especi-
cações dos requisitos funcionais do sistema, nas quais foram detalhados: a descrição do
caso de uso; os atores envolvidos; o uxo de eventos, tanto o básico como o alternativo; as
condições prévias e as condições posteriores. Os casos de uso foram detalhados conforme
as especicações no Apêndice A.
42
Na tabela a seguir são listados os requisitos funcionais:
Tabela 1: Requisitos funcionais do sistema
Identicador Descrição Prioridade Depende de
RF01 O sistema deve manter os dados de cha- Essencial
ves de identicação provendo as funcio-
nalidades de criação, consulta, remoção
e atualização das chaves de identica-
ção
RF02 O sistema deve fornecer ao usuário uma Essencial
forma de determinar a identidade de
um ou mais taxa por exemplar pela ve-
ricação das suas características, exe-
cutando o processo de chaves dicotô-
mica
RF03 O sistema deve permitir o usuário aces- Essencial RF02
sar o caminho percorrido (histórico) na
identicação de um táxon
RF04 O sistema deve permitir o usuário al- Essencial RF02, RF03
terar uma vericação voltando a um
passo anterior no caminho percorrido
(histórico) na identicação
RF05 O sistema deve, após o usuário realizar Importante RF02
a identicação de um táxon, apresentar
os taxa relacionados
RF06 O sistema deve permitir o usuário bus- Importante RF01
car um táxon por nome
RF07 O sistema deve noticar o usuário Importante RF02
quando uma identicação resultar em
um exemplar, tendo ela chegado ao seu
m
RF08 O sistema deve disponibilizar descri- Importante RF01, RF02
ções textuais em cada passo para auxi-
liar a vericação das características em
uma identicação
43
Tabela 1  continuação da página anterior
Identicador Descrição Prioridade Depende de
RF09 O sistema deve disponibilizar imagens Importante RF01, RF02
em cada passo para auxiliar a verica-
ção das características em uma identi-
cação
RF10 O sistema deve manter os dados de pro- Importante
jetos de chaves de identicação pro-
vendo as funcionalidades de criação,
consulta, remoção e atualização dos
projetos de chaves de identicação
RF11 O sistema deve permitir o usuário re- Importante RF02, RF10
alizar várias identicações e salvá-las,
nalizadas ou não, em um projeto de
chaves de identicação
RF12 O sistema deve manter os dados de Importante
usuários provendo as funcionalidades
de criação, consulta, remoção e atua-
lização dos usuários
RF13 O sistema deve disponibilizar uma Importante RF12
forma de autenticação dos usuários ca-
dastrados no por meio de username e
password
RF14 O sistema deve permitir o usuário ge- Importante RF11, RF12
rar relatórios de identicações realiza-
das em um projeto de chaves de iden-
ticação
44
Na tabela a seguir são listados os requisitos não funcionais:
Tabela 2: Requisitos não funcionais do sistema
Identicador Descrição Categoria Prioridade
RNF01 A persistência das informa- Manutenibilidade Essencial
ções de chaves de identica-
ção, projetos de chaves de
identicação e usuários de-
verá ser feita em um banco
de dados relacional
RNF02 O sistema deve ser fácil de Facilidade de Operação Importante
usar, tornando o seu processo
de identicação mais rápido
que o processo de identica-
ção manual
RNF03 O sistema deve ser adaptá- Usabilidade Desejável
vel a mudanças de contextos,
usuários e objetivos de di-
ferentes prossionais que fa-
zem identicação de táxon
(biólogos, biomédicos, médi-
cos, etc.)
A validação de requisitos, o design e a implementação do sistema foram realizadas
por terceiros. O sistema (Figura 11) encontra-se disponível em http://ihc.imd.ufrn.
br/bio/chave2.
45
Figura 11: Sistema de chave de identicação  Identicação de Exemplar
Fonte: Elaboração própria
46
4 Testes do Sistema de Chave de
Identicação
A estratégia de desenvolvimento de testes TAD foi adotada para processo de testes do
sistema de chave de identicação pois a implementação do sistema já havia sido concluída
quando se pensou na necessidade dos testes. Decidiu-se fazer uma avaliação funcional com
testes de sistema executados de forma manual e automatizada. Este capítulo apresenta o
planejamento, projeto e execução/resultados (RIOS; MOREIRA, 2013) dos testes realizados
com o objetivo de garantir a alta qualidade do produto nal.
4.1 Planejamento
O objetivo principal desta etapa foi detalhar o planejamento dos testes do sistema de
chave de identicação, denindo objetivos, diretrizes e outras informações essenciais na
estimativa do esforço de teste. Nesta etapa foi elaborado o Plano de Teste.
4.1.1 Plano de Teste
Objetivos
A seguir são listados os itens que foram identicados como alvos do teste. Esta lista
representa o que foi testado.
1. Vericar os casos de uso (criar, atualizar, consultar e remover) referente ao objeto
Identicação de Exemplar;
2. Vericar os casos de uso (criar, atualizar, consultar e remover) referente ao objeto
Exemplar;
3. Vericar os casos de uso (criar, atualizar, consultar e remover) referente ao objeto
Chave de Identicação;
47
4. Vericar os casos de uso (criar, atualizar, consultar e remover) referente ao objeto
Projeto de Identicação de Exemplares;
5. Vericar os casos de uso (criar, atualizar, consultar e remover) referente ao objeto
Usuário;
6. Vericar o caso de uso Gerar Relatório.
Diretrizes
Tabela 3: Diretrizes dos testes
Item Descrição
Objetivo do teste: Assegurar que as funcionalidades do sistema estão de acordo
com as especicações dos casos de uso do sistema.
Procedimentos: Executar testes manuais e automatizados sobre cada caso de
uso através de seu uxo principal e secundário, informando
dados válidos e inválidos, para vericar o seguinte:
• Os resultados esperados ocorrem quando são informados
dados válidos.
• As mensagens de erro ou aviso são exibidas quando dados
inválidos são informados.
• Cada regra de negócio é aplicada adequadamente.
Critério de conclusão:
• Todos os testes planejados foram executados.
• Todos os defeitos identicados foram tratados.
48
Marcos do Projeto
Tabela 4: Marcos do projeto
Bateria de Testes Manuais
Tarefa Esforço Data de Início Data de Término
Planejamento Alto 26/10/2015 22/11/2015
Projeto Alto 23/11/2015 29/11/2015
Implementação Baixo 30/11/2015 30/11/2015
Execução Alto 02/05/2016 22/05/2016
Resultados Médio 04/07/2016 10/07/2016
Bateria de Testes Automatizados
Tarefa Esforço Data de Início Data de Término
Planejamento Médio 07/08/2017 13/08/2017
Projeto Médio 07/08/2017 13/08/2017
Implementação Alto 14/08/2017 17/09/2017
Execução Médio 18/09/2017 24/09/2017
Resultados Médio 25/09/2017 01/10/2017
Produtos Disponibilizados
Os produtos das etapas do processo de testes denidos no plano de teste são listados
a seguir:
Tabela 5: Produtos disponibilizados
Produto Data de criação/atualização
Plano de teste 01/10/2017
Especicação de casos de teste 01/10/2017
Projeto de automação de testes 23/10/2017
Relatório de erros 23/10/2017
4.2 Projeto
Com base nas especicações de casos de uso do sistema, foi realizado o detalhamento
dos testes que seriam executados na etapa seguinte. Para cada caso de uso foram criados
49
um ou mais casos de teste contendo: cenário, condições, passos, entradas/saídas e resul-
tados esperados. O objetivo desta etapa era criar um documento para guiar a execução
dos testes.
4.2.1 Casos de Teste
Na tabela a seguir consta a listagem dos casos de teste elaborados para o sistema
de chave de identicação. A m de organizar o seu conteúdo, foi feito um agrupamento
na tabela dos casos de uso comuns a um objeto. Por exemplo, foi criado um grupo para
os casos de uso Criar Exemplar, Consultar Exemplar, Atualizar Exemplar e Remover
exemplar; outro grupo foi criado para os casos de uso referentes à Chave de Identicação
e assim sucessivamente.
Tabela 6: Casos de teste
Login
Caso de teste Descrição
TC01 Efetuar login com sucesso
TC02 Efetuar login com usuário inválido
TC03 Efetuar login com usuário em branco
TC04 Efetuar login com senha inválida
TC05 Efetuar login com senha em branco
Identicação de Exemplar
Caso de teste Descrição
TC06 Identicar exemplar com sucesso
TC07 Identicar exemplar alternando entre características da chave de iden-
ticação
TC08 Remover identicação de exemplar
Exemplar
Caso de teste Descrição
TC09 Criar exemplar com sucesso
TC10 Criar exemplar com Quantidade < 1
TC11 Criar exemplar com Quantidade > 100
TC12 Criar exemplar com Nome > 100 caracteres
TC13 Criar exemplar com Nome em branco
TC14 Criar exemplar com Descrição > 1000
50
Tabela 6  continuação da página anterior
TC15 Criar exemplar com Data da coleta inválida
TC16 Remover exemplar
Chave de Identicação
Caso de teste Descrição
TC17 Criar chave de identicação com sucesso
TC18 Criar chave de identicação com Nome > 100 caracteres
TC19 Criar chave de identicação com Nome em branco
TC20 Criar chave de identicação com Descrição > 1000 caracteres
TC21 Criar chave de identicação com Autor > 100 caracteres
TC22 Criar chave de identicação com Bibliograa > 1000 caracteres
TC23 Criar chave de identicação adicionando passo com Característica A
> 1000
TC24 Criar chave de identicação adicionando passo com Característica A
em branco
TC25 Criar chave de identicação adicionando passo com Característica B
> 1000
TC26 Criar chave de identicação adicionando passo com Característica B
em branco
TC27 Remover chave de identicação
Projeto
Caso de teste Descrição
TC28 Criar projeto com sucesso
TC29 Criar projeto com Nome > 100 caracteres
TC30 Criar projeto com Nome em branco
TC31 Remover projeto
Usuário
Caso de teste Descrição
TC32 Criar usuário com sucesso
TC33 Criar usuário com Nome > 100 caracteres
TC34 Criar usuário com Nome em branco
TC35 Criar usuário com Instituição > 100 caracteres
TC36 Criar usuário com Instituição em branco
TC37 Criar usuário com E-mail inválido
51
Tabela 6  continuação da página anterior
TC38 Criar usuário com E-mail > 100 caracteres
TC39 Criar usuário com E-mail em branco
TC40 Criar usuário com Login > 100 caracteres
TC41 Criar usuário com Login em branco
TC42 Criar usuário com Senha > 100 caracteres
TC43 Criar usuário com Senha em branco
TC44 Remover usuário
Relatório
Caso de teste Descrição
TC45 Gerar relatório com sucesso
4.3 Testes Manuais
4.3.1 Execução
Os testes manuais foram executados com base nos passos denidos no projeto de teste
e de acordo com a divisão de casos de uso comuns a um objeto, detalhada na especicação
de casos de teste.
Por meio da navegação dos casos de uso, cada um dos casos de teste foi executado
realizando um comparativo entre os resultados obtidos e os resultados esperados.
Durante a execução, foram registrados os resultados dos casos de teste e as ocorrências
de erros ou melhorias no sistema de chave de identicação.
Ao vericar a ocorrência de um erro, os passos que a ocasionou foram repetidos, a m
de reproduzi-la novamente e nalmente registrá-la.
Após nalizar os casos de teste, as ocorrências registradas foram revisadas, a m de
deixar claras as descrições dos erros encontrados.
4.3.2 Resultados
Dos 45 casos de teste, 27 foram executados com sucesso e 18 com falha, resultando em
um percentual de 60% de sucessos contra 40% de falhas, tendo sido reportados 43 erros.
A m de classicar os resultados obtidos pela execução dos casos de teste, o autor
52
deste trabalho deniu tipos e níveis de gravidade para os erros encontrados.
Tipos de erros:
• Execução: indica um comportamento anormal em uma operação, impedindo que a
ação principal do caso de uso testado não seja nalizada com sucesso.
• Navegação: descreve um uxo inesperado em uma operação, redirecionando o usuá-
rio para telas diferentes das que eram esperadas.
• Negócio: aponta um descumprimento de regras de negócio ou requisitos associados
ao caso de uso testado.
• Usabilidade: detalha uma experiência negativa de uso do sistema ao usuário.
• Visual: reporta um problema na disposição dos elementos nas telas do sistema, além
de eventuais erros de ortograa e de gramática.
Níveis de gravidade de erros (do mais grave ao menos grave):
• Crítico
• Alto
• Médio
• Baixo
Dos erros reportados, 5 foram de execução (11,62%), 7 de navegação (16,28%), 15 de
negócio (34,89%), 11 de usabilidade (25,59%) e 5 visuais (11,62%). Quanto aos níveis de
gravidade, 4 foram de nível crítico, 8 de nível alto, 7 de nível médio e 24 de nível baixo
(Figura 12). A descrição detalhada destes erros se encontra no Apêndice B.
53
Figura 12: Gráco dos erros detectados pelos testes manuais
Fonte: Elaboração própria
4.4 Testes Automatizados
O objetivo da execução de testes automatizados neste trabalho, é a criação de um
projeto de automação de testes para simular a navegação básica das funcionalidades mais
relevantes do sistema, com a possibilidade de ser executado de tempos em tempos (teste
de regressão) e gerar um relatório com dados da situação atual sobre o funcionamento dos
principais casos de uso do sistema.
4.4.1 Implementação
O projeto de automação foi implementado na linguagem de programação Java com
o apoio do ambiente de desenvolvimento integrado Eclipse1 e dos frameworks TestNG2 e
Selenium WebDriver3.
Os casos de teste listados a seguir foram selecionados para integrar a implementação
do projeto, considerando as operações mais relevantes do sistema para o usuário:
1https://www.eclipse.org
2http://testng.org
3http://www.seleniumhq.org
54
• Login
 TC01 Efetuar login com sucesso
• Identicação de exemplar
 TC06 Identicar exemplar com sucesso
 TC08 Remover identicação de exemplar
• Exemplar
 TC09 Criar exemplar com sucesso
 TC16 Remover exemplar
• Chave de identicação
 TC17 Criar chave de identicação com sucesso
 TC27 Remover chave de identicação
• Projeto
 TC28 Criar projeto com sucesso
 TC31 Remover projeto
• Usuário
 TC32 Criar usuário com sucesso
 TC44 Remover usuário
Com a nalidade de modularizar o projeto, optou-se pela sua organização através do
uso do padrão Page Object (SELENIUM, 2015). Seu objetivo é tornar o código mais legível
através do encapsulamento da API do Selenium WebDriver em classes que representam
as páginas web (Figura 13).
55
Figura 13: Diagrama de classes do projeto de automação de testes
Fonte: Elaboração própria
Módulos do projeto de automação de testes:
• Page Objects : As classes contidas neste pacote representam as páginas web do sis-
tema de chave de identicação, isolando a referência aos elementos do sistema, tais
como campos de texto, links e botões, da implementação dos casos de teste.
• Tests : Cada classe deste pacote é responsável pela execução de um ou mais casos
de teste. Nelas são realizadas asserções onde compara-se o resultado esperado com
o resultado obtido pelo teste através do framework TestNG.
• Forms : Pacote composto pelas classes que detalham os atributos dos formulários
existentes no sistema.
• Results : Responsável pela geração do relatório de testes, detalhando os resultados
das execuções dos casos de teste.
56
Figura 14: Classe de teste de chave de identicação
Fonte: Elaboração própria
A Figura 14 ilustra a implementação da classe de teste de Chave de Identicação.
O método setUp() é invocado antes da execução dos casos de teste e é responsável por
criar uma instância dos objetos BasePage, que fornece o WebDriver usado para a exe-
cução dos testes, e KeyPage, que abre o navegador e em seguida acessa o link da chave
de identicação. O método tearDown(), por sua vez, é invocado depois da execução dos
casos de teste e se responsabiliza por fechar o navegador. Os métodos testCreateKey() e
testDeleteKey() são as respectivas implementações dos casos de teste TC17 e TC27, res-
ponsáveis por realizar interações com as páginas web da chave de identicação e asserções
dos resultados obtidos com os resultados esperados. O código dos testes automatizados
encontra-se em https://github.com/pablobedoya/identificationkey.
4.4.2 Execução
Depois de realizar a atividade de implementação dos casos de testes, iniciou-se a
execução do projeto de automação de testes.
O Google Chrome foi o navegador selecionado para a execução dos testes, com a pos-
sibilidade de substitui-lo apenas alterando o driver instanciado na classe de congurações
do projeto.
57
Além do Selenium WebDriver, a execução dos testes também foi apoiada pelo fra-
mework TestNG, integrado ao Eclipse como plugin, possibilitando o acompanhamento do
tempo de execução e resultado de cada caso de teste (sucesso ou falha). Quando um caso
de teste é bem sucedido, o TestNG apenas conrma o seu sucesso (Figura 15). No entanto,
quando uma falha ocorre, o Eclipse exibe uma exceção em seu console e é possível acessar
o log da falha através do TestNG, que ainda possibilita saber em qual classe e linha ela
foi originada.
Figura 15: Resultados da execução dos testes automatizados com TestNG
Fonte: Elaboração própria
4.4.3 Resultados
A análise dos resultados foi realizada com base no relatório gerado a partir da integra-
ção do projeto de automação com a API ExtentReport4. Foi criado um objeto gerenciador,
responsável por analisar o ciclo de vida da execução dos testes com o TestNG, documen-
tando logs e resultados de cada caso de teste executado. Conforme mostra a gura 16, o
relatório fornece um feedback geral dos casos de uso testados.
A partir dos resultados da execução dos casos de teste é possível noticar a necessidade
de ações corretivas ou preventivas para o sistema. No entanto, somente a visualização
desses resultados não fornece uma visão geral da sua qualidade. Dessa forma, no contexto
4http://extentreports.com
58
do sistema de chave de identicação, os testes automatizados foram desenvolvidos como
uma atividade complementar aos testes manuais.
Figura 16: Relatório de resultados da execução dos testes automatizados
Fonte: Elaboração própria
59
5 Considerações Finais
Este trabalho teve como objetivo realizar as atividades de análise e especicação,
dentro do âmbito da engenharia de requisitos, resultando em um modelo para apoiar o
desenvolvimento de um sistema de chave de identicação.
Depois que o sistema foi implementado, este trabalho buscou contribuir com a me-
lhoria da qualidade do produto através da execução manual e automatizada de testes
funcionais de sistema.
A execução dos testes automatizados mostrou-se menos custosa quando comparada
à execução dos testes manuais. Após a estruturação do projeto de automação usando o
padrão Page Object, a criação de um novo caso de teste automatizado se tornou mais
simples devido ao isolamento da API do Selenium WebDriver. Contudo, no contexto
deste trabalho, os testes manuais se mostraram indispensáveis, uma vez que o objetivo da
execução dos casos de teste automatizados era realizar apenas uma navegação básica nos
casos de uso.
O projeto de automação de testes pode ser apontado como principal contribuição deste
trabalho. Sua estrutura foi criada considerando pontos de extensão para a adaptação em
cima de sistemas relacionados ao domínio de chave de identicação.
60
Referências
BERNARDO, P. C. Mestrado em Ciência da Computação, Padrões de testes
automatizados. São Paulo: [s.n.], 2011.
BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML: guia do usuário. Rio de Janeiro:
Elsevier, 2006.
DELAMARO, M. E.; MALDONADO, J. C.; JINO, M. Introdução ao teste de software.
Rio de Janeiro: Elsevier, 2007.
LINARDI, P. M.; GUIMARÃES, L. R. Sifonápteros do Brasil. São Paulo: Museu de
Zoologia USP/FAPESP, 2000.
MYERS, G. J. The Art of Software Testing. 2. ed. Hoboken: John Wiley & Sons, 2004.
OLIVEIRA-COSTA, J. Insetos Peritos  A Entomologia Forense no Brasil. Campinas:
Millennium, 2013.
PRESSMAN, R. S. Software Engineering: A Practitioner's Approach. 7. ed. New York:
McGraw-Hill Higher Education, 2011.
RIOS, E.; MOREIRA, T. Teste de Software. 3. ed. Rio de Janeiro: Alta Books Editora,
2013.
SELENIUM. Page Objects. 2015. https://github.com/SeleniumHQ/selenium/wiki/
PageObjects. Acesso em: 14 ago. 2017.
SELENIUM. Test Automation for Web Applications. 2017. http://www.seleniumhq.
org/docs/01_introducing_selenium.html. Acesso em: 23 nov. 2017.
SMART, J. F. BDD in Action: Behavior-Driven Development for the Whole Software
Lifecycle. Shelter Island: Manning Publications, 2014.
SMARTBEAR. What is Automated Testing? 2017. https://smartbear.com/learn/
automated-testing/what-is-automated-testing/. Acesso em: 23 nov. 2017.
WIKIBOOKS. Dichotomous Key  Wikibooks, Open books for an open world. nov. 2014.
http://en.wikibooks.org/w/index.php?title=Dichotomous_Key&oldid=2721666.
Acesso em: 06 nov. 2014.
61
APÊNDICE A -- Casos de Uso do Sistema
A.1 UC01 Criar Identicação de Exemplar
A.1.1 Descrição
Este caso de uso descreve o processo realizado pelo usuário para identicar os taxa
a que um exemplar pertence, vericando suas características de acordo com os níveis da
taxonomia dos seres vivos. Essa vericação é feita usando o processo da biologia conhecido
por chave de identicação.
A.1.2 Atores
Administrador, Aluno, Monitor e Professor.
A.1.3 Fluxo de Eventos
A.1.3.1 Fluxo Básico
1. O usuário seleciona a opção de criar identicação de exemplar
2. O sistema exibe o formulário de identicação
3. O usuário informa o táxon inicial, que pode ser nulo
4. O sistema apresenta as chaves de identicação que partem (iniciam) com o táxon
informado
5. O usuário escolhe uma chave de identicação
6. O sistema exibe o primeiro conjunto de características a serem vericadas (Fluxo
Alternativo 1)
62
7. O usuário verica se o exemplar apresenta umas das características apresentadas,
respondendo sim ou talvez
8. Se a característica indicada pelo usuário for a última característica a ser vericada
em um táxon, o sistema registra que o usuário identicou aquele exemplar como
sendo deste táxon e retorna ao passo 2. Se não, o sistema apresenta as próximas
perguntas, voltando para o passo 4 (Fluxo Alternativo 2)
9. O caso de uso é nalizado.
A.1.3.2 Fluxos Alternativos
1. Alterar vericação de características anterior
(a) O usuário expande o histórico de vericações realizadas
(b) O usuário seleciona a qual vericação deseja voltar
(c) O sistema exibe a vericação selecionada pelo usuário
(d) O sistema volta ao passo 6 do Fluxo Básico.
2. Táxon/Exemplar não identicado em última característica vericada
(a) O sistema volta ao passo 6 do Fluxo Básico.
A.1.4 Condições Prévias
1. O usuário deve estar autenticado pelo sistema
2. Deve existir pelo menos uma chave de identicação cadastrada.
A.1.5 Condições Posteriores
1. Salvar temporariamente informações de identicação de exemplar.
A.2 UC02 Consultar Identicação de Exemplar
A.2.1 Descrição
Este caso de uso descreve a funcionalidade do sistema de consultar identicação de
exemplar. Essa consulta possibilita ao usuário a visualização das informações relacionadas
às identicações de exemplares já realizadas que ele possui acesso no sistema.
63
A.2.2 Atores
Administrador, Aluno, Monitor e Professor.
A.2.3 Fluxo de Eventos
A.2.3.1 Fluxo Básico
1. O usuário seleciona a opção de consultar identicação de exemplar
2. O sistema lista as identicações de exemplares concluídas e não concluídas
3. O usuário seleciona a identicação
4. O sistema exibe a identicação selecionada pelo usuário e disponibiliza as informa-
ções relacionadas
5. O caso de uso é nalizado.
A.2.3.2 Fluxos Alternativos
1. Cancelamento da Operação
(a) O usuário desiste da operação e seleciona a opção de cancelar
(b) O sistema volta para a tela inicial.
2. Não há identicações de exemplares disponíveis
(a) O sistema informa que não há identicações de exemplares cadastradas e
sugere a criação de uma nova identicação (UC01).
A.2.4 Condições Prévias
1. O usuário deverá estar autenticado pelo sistema
2. Deve existir pelo menos uma identicação cadastrada.
A.2.5 Condições Posteriores
Não se aplica.
64
A.3 UC03 Atualizar Identicação de Exemplar
A.3.1 Descrição
Este caso de uso descreve o processo de atualização da identicação de um exemplar
no sistema. Essa funcionalidade permite ao usuário tanto continuar uma identicação não
concluída como alterar uma identicação já realizada anteriormente.
A.3.2 Atores
Administrador, Aluno, Monitor e Professor.
A.3.3 Fluxo de Eventos
A.3.3.1 Fluxo Básico
1. O usuário faz uma consulta de identicação de exemplar (UC02)
2. O sistema lista as identicações de exemplares
3. O usuário escolhe a identicação que irá modicar e seleciona a opção de atualizar
identicação do exemplar
4. O sistema exibe a identicação escolhida pelo usuário
5. O usuário faz as modicações necessárias e seleciona a opção de salvar
6. O sistema exibe caixa de diálogo com a mensagem Tem certeza que deseja atualizar
esta identicação de exemplar?
7. O usuário conrma o desejo de atualização
8. O sistema executa a ação de atualização da identicação do exemplar
9. O sistema exibe a mensagem Identicação de Exemplar atualizada com sucesso!
e retorna para a listagem de identicações de exemplares
10. O caso de uso é nalizado.
65
A.3.3.2 Fluxos Alternativos
1. Cancelamento da operação
(a) O usuário desiste da operação e seleciona a opção de cancelar
(b) O sistema volta para a tela de listagem de identicações de exemplares.
A.3.4 Condições Prévias
1. O usuário deve estar autenticado pelo sistema
2. Deve existir pelo menos uma identicação cadastrada.
A.3.5 Condições Posteriores
1. Identicação de exemplar atualizada com sucesso.
A.4 UC04 Remover Identicação de Exemplar
A.4.1 Descrição
Este caso de uso descreve o processo de remoção de identicações de exemplares no
sistema. Essa operação é realizada no sistema e atualizada devidamente no banco de dados
de uma forma organizada e segura.
A.4.2 Atores
Administrador, Aluno, Monitor e Professor.
A.4.3 Fluxo de Eventos
A.4.3.1 Fluxo Básico
1. O usuário faz uma consulta de identicação de exemplar (UC02)
2. O sistema lista as identicações de exemplares
3. O usuário escolhe a identicação que irá remover e seleciona a opção de remover
identicação do exemplar
66
4. O sistema exibe caixa de diálogo com a mensagem Tem certeza que deseja remover
esta identicação de exemplar?
5. O usuário conrma o desejo de remoção
6. O sistema executa a ação de remoção da identicação do exemplar
7. O sistema exibe a mensagem Identicação de exemplar removida com sucesso! e
retorna para a listagem de identicações de exemplares
8. O caso de uso é nalizado.
A.4.3.2 Fluxos Alternativos
1. Cancelamento da operação
(a) O usuário desiste da operação e seleciona a opção de cancelar
(b) O sistema volta para a tela de listagem de identicações de exemplares.
A.4.4 Condições Prévias
1. O usuário deve estar autenticado pelo sistema
2. Deve existir pelo menos uma identicação cadastrada.
A.4.5 Condições Posteriores
1. Identicação de exemplar removida com sucesso.
A.5 UC05 Criar Exemplar
A.5.1 Descrição
Este caso de uso descreve o processo de criação de exemplares no sistema. Essa fun-
cionalidade permite ao usuário cadastrar exemplares de seres vivos no sistema. Após ser
criado, um exemplar estará apto a ser associado a chaves de identicação cadastradas no
sistema e ser identicado.
67
A.5.2 Atores
Administrador, Aluno, Monitor e Professor.
A.5.3 Fluxo de Eventos
A.5.3.1 Fluxo Básico
1. O usuário seleciona a opção de criar exemplar
2. O sistema exibe a tela de cadastro de exemplar
3. O usuário preenche os campos
4. O sistema valida os dados
5. O usuário conrma a criação do exemplar
6. O sistema executa a ação de criação do exemplar
7. O sistema salva os dados na base dados
8. O sistema exibe a mensagem Exemplar criado com sucesso! e retorna para a tela
de criação de exemplar
9. O caso de uso é nalizado.
A.5.3.2 Fluxos Alternativos
1. Cancelamento da operação
(a) O usuário desiste da operação e seleciona a opção de cancelar
(b) O sistema volta para a tela de criação de exemplar.
A.5.4 Condições Prévias
1. O usuário deve estar autenticado pelo sistema.
A.5.5 Condições Posteriores
1. Exemplar criado com sucesso.
68
A.6 UC06 Consultar Exemplar
A.6.1 Descrição
Este caso de uso descreve a funcionalidade do sistema de consultar exemplar. Essa
consulta permite ao usuário visualizar os exemplares existentes no sistema bem como as
informações e características detalhadas de cada um.
A.6.2 Atores
Administrador, Aluno, Monitor e Professor.
A.6.3 Fluxo de Eventos
A.6.3.1 Fluxo Básico
1. O usuário seleciona a opção de consultar exemplar
2. O sistema lista os exemplares
3. O usuário seleciona o exemplar
4. O sistema exibe o exemplar selecionado pelo usuário e disponibiliza as suas infor-
mações
5. O caso de uso é nalizado.
A.6.3.2 Fluxos Alternativos
1. Cancelamento da Operação
(a) O usuário desiste da operação e seleciona a opção de cancelar
(b) O sistema volta para a tela inicial.
2. Não há exemplares disponíveis
(a) O sistema informa que não existem exemplares disponíveis e sugere a criação
de um novo exemplar (UC05).
69
A.6.4 Condições Prévias
1. O usuário deverá estar autenticado pelo sistema
2. Deve existir pelo menos um exemplar cadastrado.
A.6.5 Condições Posteriores
Não se aplica.
A.7 UC07 Atualizar Exemplar
A.7.1 Descrição
Este caso de uso descreve o processo de atualização de um exemplar no sistema. Essa
funcionalidade possibilita ao usuário alterar as informações de um exemplar cadastrado
no sistema.
A.7.2 Atores
Administrador, Aluno, Monitor e Professor.
A.7.3 Fluxo de Eventos
A.7.3.1 Fluxo Básico
1. O usuário faz uma consulta de exemplar (UC06)
2. O sistema lista os exemplares
3. O usuário escolhe o exemplar que irá alterar e seleciona a opção de atualizar
exemplar
4. O sistema exibe o exemplar escolhido pelo usuário
5. O usuário faz as modicações necessárias e seleciona a opção de salvar
6. O sistema exibe caixa de diálogo com a mensagem Tem certeza que deseja atualizar
este exemplar?
70
7. O usuário conrma o desejo de atualização
8. O sistema executa a ação de atualização do exemplar
9. O sistema exibe a mensagem Exemplar atualizado com sucesso! e retorna para a
listagem de exemplares
10. O caso de uso é nalizado.
A.7.3.2 Fluxos Alternativos
1. Cancelamento da operação
(a) O usuário desiste da operação e seleciona a opção de cancelar
(b) O sistema volta para a tela de listagem de exemplares.
A.7.4 Condições Prévias
1. O usuário deve estar autenticado pelo sistema
2. Deve existir pelo menos um exemplar cadastrado.
A.7.5 Condições Posteriores
1. Exemplar atualizado com sucesso.
A.8 UC08 Remover Exemplar
A.8.1 Descrição
Este caso de uso descreve o processo de remoção de exemplares no sistema. Essa fun-
cionalidade é executada no sistema salvando informações de maneira segura e organizada
na base de dados.
A.8.2 Atores
Administrador, Aluno, Monitor e Professor.
71
A.8.3 Fluxo de Eventos
A.8.3.1 Fluxo Básico
1. O usuário seleciona faz uma consulta de exemplar (UC06)
2. O sistema lista os exemplares
3. O usuário escolhe o exemplar que irá remover e seleciona a opção de remover
exemplar
4. O sistema exibe caixa de diálogo com a mensagem Tem certeza que deseja remover
este exemplar?
5. O usuário conrma o desejo de remoção
6. O sistema executa a ação de remoção do exemplar
7. O sistema exibe a mensagem Exemplar removido com sucesso! e retorna para a
listagem de exemplares
8. O caso de uso é nalizado.
A.8.3.2 Fluxos Alternativos
1. Cancelamento da operação
(a) O usuário desiste da operação e seleciona a opção de cancelar
(b) O sistema volta para a tela de listagem de exemplares.
A.8.4 Condições Prévias
1. O usuário deve estar autenticado pelo sistema
2. Deve existir pelo menos um exemplar cadastrado.
A.8.5 Condições Posteriores
1. Exemplar removido com sucesso.
72
A.9 UC09 Criar Chave de Identicação
A.9.1 Descrição
Este caso de uso descreve o processo de criação de chaves de identicação no sistema.
Essa funcionalidade apoia a atividade de identicação de exemplar, denindo os passos
para a vericação dos taxa a que um exemplar pertence. Após a criação de uma chave
de identicação, o usuário poderá realizar a identicação de exemplares associados a esta
chave.
A.9.2 Atores
Administrador, Monitor e Professor.
A.9.3 Fluxo de Eventos
A.9.3.1 Fluxo Básico
1. O usuário seleciona a opção de criar chave de identicação
2. O sistema exibe a tela de cadastro de chave de identicação
3. O usuário preenche os campos (Fluxo Alternativo 1)
4. O sistema valida os dados
5. O usuário conrma a criação da chave de identicação
6. O sistema executa a ação de criação da chave de identicação
7. O sistema salva os dados na base dados
8. O sistema exibe a mensagem Chave de identicação criada com sucesso! e retorna
para a tela de criação de chave de identicação
9. O caso de uso é nalizado.
A.9.3.2 Fluxos Alternativos
1. Adicionar etapa de vericação
(a) O usuário seleciona a opção de adicionar nova etapa de vericação
73
(b) O sistema exibe a tela de cadastro da etapa de vericação
(c) O usuário preenche os campos referentes às características da vericação
(d) O sistema valida os dados informados
(e) O usuário conrma a adição da etapa de vericação
(f) O sistema executa a ação de adição da etapa de vericação
(g) O sistema salva a etapa de vericação na chave de identicação
(h) O sistema volta ao passo 3 do Fluxo Básico.
2. Cancelamento da operação
(a) O usuário desiste da operação e seleciona a opção de cancelar
(b) O sistema volta para a tela de criação de chave de identicação.
A.9.4 Condições Prévias
1. O usuário deverá estar autenticado pelo sistema.
A.9.5 Condições Posteriores
1. Chave de identicação criada com sucesso.
A.10 UC10 Consultar Chave de Identicação
A.10.1 Descrição
Este caso de uso descreve a funcionalidade do sistema de consultar chave de identi-
cação. Essa consulta possibilita ao usuário a visualização das informações relacionadas às
chaves de identicação cadastradas na base de dados.
A.10.2 Atores
Administrador, Aluno, Monitor e Professor.
74
A.10.3 Fluxo de Eventos
A.10.3.1 Fluxo Básico
1. O usuário seleciona a opção de consultar chave de identicação
2. O sistema lista as chaves de identicação
3. O usuário seleciona uma chave de identicação
4. O sistema exibe a chave de identicação selecionada pelo usuário e disponibiliza as
informações relacionadas
5. O caso de uso é nalizado.
A.10.3.2 Fluxos Alternativos
1. Cancelamento da operação
(a) O usuário desiste da operação e seleciona a opção de cancelar
(b) O sistema volta para a tela inicial.
2. Não há chaves de identicação disponíveis
(a) O sistema informa que não existem chaves de identicação disponíveis e sugere
a criação de uma nova chave de identicação (UC09).
A.10.4 Condições Prévias
1. O usuário deverá estar autenticado pelo sistema
2. Deve existir pelo menos uma chave de identicação cadastrada.
A.10.5 Condições Posteriores
Não se aplica.
75
A.11 UC11 Atualizar Chave de Identicação
A.11.1 Descrição
Este caso de uso descreve o processo de atualização de uma chave de identicação no
sistema. Essa funcionalidade possibilita ao usuário alterar as informações de uma chave
de identicação cadastrada no sistema.
A.11.2 Atores
Administrador, Monitor e Professor.
A.11.3 Fluxo de Eventos
A.11.3.1 Fluxo Básico
1. O usuário faz uma consulta de chave de identicação (UC10)
2. O sistema lista as chaves de identicação
3. O usuário escolhe a chave de identicação que irá modicar e seleciona a opção de
atualizar chave de identicação
4. O sistema exibe a chave de identicação escolhida pelo usuário
5. O usuário faz as modicações necessárias e seleciona a opção de salvar
6. O sistema exibe caixa de diálogo com a mensagem Tem certeza que deseja atualizar
esta chave de identicação?
7. O usuário conrma o desejo de atualização
8. O sistema executa a ação de atualização da chave de identicação
9. O sistema exibe a mensagem Chave de identicação atualizada com sucesso! e
retorna para a listagem de chaves de identicação
10. O caso de uso é nalizado.
76
A.11.3.2 Fluxos Alternativos
1. Cancelamento da operação
(a) O usuário desiste da operação e seleciona a opção de cancelar
(b) O sistema volta para a tela de listagem de chaves de identicação.
A.11.4 Condições Prévias
1. O usuário deverá estar autenticado pelo sistema
2. Deve existir pelo menos uma chave de identicação cadastrada.
A.11.5 Condições Posteriores
1. Chave de identicação de exemplar atualizada com sucesso.
A.12 UC12 Remover Chave de Identicação
A.12.1 Descrição
Este caso de uso descreve o processo de remoção de chaves de identicação no sistema.
Essa funcionalidade é executada no sistema e atualizada devidamente no banco de dados
de uma forma segura e organizada.
A.12.2 Atores
Administrador, Monitor e Professor.
A.12.3 Fluxo de Eventos
A.12.3.1 Fluxo Básico
1. O usuário faz uma consulta de chave de identicação (UC08)
2. O sistema lista as chaves de identicações
3. O usuário escolhe a chave de identicação que irá remover e seleciona a opção de
remover chave de identicação
77
4. O sistema exibe caixa de diálogo com a mensagem Tem certeza que deseja remover
esta chave de identicação?
5. O usuário conrma o desejo de remoção
6. O sistema executa a ação de remoção da chave de identicação
7. O sistema exibe a mensagem Chave de identicação removida com sucesso! e
retorna para a listagem de chaves de identicação
8. O caso de uso é nalizado.
A.12.3.2 Fluxos Alternativos
1. Cancelamento da operação
(a) O usuário desiste da operação e seleciona a opção de cancelar
(b) O sistema volta para a tela de listagem de chaves de identicação.
A.12.4 Condições Prévias
1. O usuário deverá estar autenticado pelo sistema
2. Deve existir pelo menos uma chave de identicação cadastrada.
A.12.5 Condições Posteriores
1. Chave de identicação removida com sucesso.
A.13 UC13 Criar Projeto
A.13.1 Descrição
Este caso de uso descreve o processo da criação de projeto de identicação de exem-
plares. Essa funcionalidade possibilita ao usuário organizar as suas identicações de exem-
plares dentro de um projeto no sistema.
A.13.2 Atores
Administrador, Aluno, Monitor e Professor.
78
A.13.3 Fluxo de Eventos
A.13.3.1 Fluxo Básico
1. O usuário seleciona a opção de criar projeto
2. O sistema solicita exemplares identicados para salvar no projeto
3. O usuário informa os exemplares identicados
4. O sistema salva os exemplares identicados no projeto
5. O usuário conrma a criação do projeto
6. O sistema executa a ação de criação de projeto
7. O sistema salva o projeto na base dados
8. O sistema exibe a mensagem Projeto criado com sucesso! e retorna para a tela
de criação de projeto
9. O caso de uso é nalizado.
A.13.3.2 Fluxos Alternativos
1. Cancelamento da operação
(a) O usuário desiste da operação e seleciona a opção de cancelar
(b) O sistema volta para a tela de criação de projeto.
A.13.4 Condições Prévias
1. O Usuário deve estar autenticado pelo sistema.
A.13.5 Condições Posteriores
1. Projeto criado com sucesso.
79
A.14 UC14 Consultar Projeto
A.14.1 Descrição
Este caso de uso descreve a funcionalidade do sistema de consultar projeto. Essa
consulta possibilita ao usuário a visualização dos projetos existentes em seu nome no
sistema.
A.14.2 Atores
Administrador, Aluno, Monitor e Professor.
A.14.3 Fluxo de Eventos
A.14.3.1 Fluxo Básico
1. O usuário seleciona a opção de consultar projeto
2. O sistema lista os projetos existentes do usuário
3. O usuário seleciona um projeto
4. O sistema exibe o projeto selecionado pelo usuário e disponibiliza as informações
das identicações de exemplares adicionadas nele
5. O caso de uso é nalizado.
A.14.3.2 Fluxos Alternativos
1. Cancelamento da operação
(a) O usuário desiste da operação e seleciona a opção de cancelar
(b) O sistema volta para a tela inicial.
2. Não há projetos disponíveis
(a) O sistema informa que não há projetos cadastrados pelo usuário e sugere a
criação de um novo projeto (UC13).
80
A.14.4 Condições Prévias
1. O usuário deverá estar autenticado pelo sistema
2. Deve existir pelo menos um projeto cadastrado.
A.14.5 Condições Posteriores
Não se aplica.
A.15 UC15 Atualizar Projeto
A.15.1 Descrição
Este caso de uso descreve o processo de atualização de um projeto. Essa funcionalidade
possibilita ao usuário alterar os dados de um projeto seu cadastrado no sistema.
A.15.2 Atores
Administrador, Aluno, Monitor e Professor.
A.15.3 Fluxo de Eventos
A.15.3.1 Fluxo Básico
1. O usuário faz uma consulta de projeto (UC14)
2. O sistema lista os projetos existentes
3. O usuário escolhe o projeto que irá modicar e seleciona a opção de atualizar
projeto
4. O sistema exibe o projeto escolhido pelo usuário
5. O usuário faz as modicações necessárias e seleciona a opção de salvar
6. O sistema exibe caixa de diálogo com a mensagem Tem certeza que deseja atualizar
este projeto?
7. O usuário conrma o desejo de atualização
81
8. O sistema executa a ação de atualização do projeto
9. O sistema exibe a mensagem Projeto atualizado com sucesso! e retorna para a
listagem de projetos
10. O caso de uso é nalizado.
A.15.3.2 Fluxos Alternativos
1. Cancelamento da operação
(a) O usuário desiste da operação e seleciona a opção de cancelar
(b) O sistema volta para a tela de listagem de projetos.
A.15.4 Condições Prévias
1. O usuário deve estar autenticado pelo sistema
2. Deve existir pelo menos um projeto cadastrado.
A.15.5 Condições Posteriores
1. Projeto atualizado com sucesso.
A.16 UC16 Remover Projeto
A.16.1 Descrição
Este caso de uso descreve o processo de remoção de projeto no sistema. Essa funci-
onalidade é executada no sistema salvando informações de maneira segura e organizada
na base de dados.
A.16.2 Atores
Administrador, Aluno, Monitor e Professor.
82
A.16.3 Fluxo de Eventos
A.16.3.1 Fluxo Básico
1. O usuário faz uma consulta de projeto (UC014)
2. O sistema lista os projetos existentes
3. O usuário escolhe o projeto que irá remover e seleciona a opção de remover projeto
4. O sistema exibe caixa de diálogo com a mensagem Tem certeza que deseja remover
este projeto?
5. O usuário conrma o desejo de remoção
6. O sistema executa a ação de remoção do projeto
7. O sistema exibe a mensagem Projeto removido com sucesso! e retorna para a
listagem de projetos
8. O caso de uso é nalizado.
A.16.3.2 Fluxos Alternativos
1. Cancelamento da operação
(a) O usuário desiste da operação e seleciona a opção de cancelar
(b) O sistema volta para a tela de listagem de projetos.
A.16.4 Condições Prévias
1. O usuário deve estar autenticado pelo sistema
2. Deve existir pelo menos um projeto cadastrado.
A.16.5 Condições Posteriores
1. Projeto removido com sucesso.
83
A.17 UC17 Criar Usuário
Este caso de uso descreve o processo de criação de usuário no sistema. Essa operação
possibilita ao usuário cadastrar novos usuários. Após criado, o usuário, dependendo do
seu perl, estará apto a usufruir das mais diversas funcionalidades do sistema.
A.17.1 Descrição
A.17.2 Atores
Administrador, Monitor e Professor.
A.17.3 Fluxo de Eventos
A.17.3.1 Fluxo Básico
1. O usuário seleciona a opção de criar usuário
2. O sistema exibe a tela de cadastro de usuário
3. O usuário preenche os campos
4. O sistema valida os dados
5. O usuário conrma a criação do novo usuário
6. O sistema executa a ação de criação de usuário
7. O sistema salva os dados na base de dados
8. O sistema exibe a mensagem Usuário criado com sucesso! e retorna para a tela
de criação de usuário
9. O caso de uso é nalizado.
A.17.3.2 Fluxos Alternativos
1. Cancelamento da operação
(a) O usuário desiste da operação e seleciona a opção de cancelar
(b) O sistema volta para a tela de criação de usuário.
84
A.17.4 Condições Prévias
1. O usuário deve estar autenticado pelo sistema.
A.17.5 Condições Posteriores
1. Usuário criado com sucesso.
A.18 UC18 Consultar Usuário
A.18.1 Descrição
Este caso de uso descreve a funcionalidade do sistema de consultar usuário. Essa
consulta permite ao usuário visualizar os usuários existentes no sistema bem como as
informações públicas do perl de cada um.
A.18.2 Atores
Administrador, Aluno, Monitor e Professor.
A.18.3 Fluxo de Eventos
A.18.3.1 Fluxo Básico
1. O usuário seleciona a opção de consultar usuário
2. O sistema lista os usuários
3. O usuário seleciona um usuário na listagem disponibilizada pelo sistema
4. O sistema exibe o usuário selecionado e as suas informações públicas do perl
5. O caso de uso é nalizado.
A.18.3.2 Fluxos Alternativos
1. Cancelamento da operação
(a) O usuário desiste da operação e seleciona a opção de cancelar
(b) O sistema volta para a tela inicial.
85
A.18.4 Condições Prévias
1. O usuário deverá estar autenticado pelo sistema.
A.18.5 Condições Posteriores
Não se aplica
A.19 UC19 Atualizar Usuário
A.19.1 Descrição
Este caso de uso descreve o processo de atualização de um usuário no sistema. Essa
funcionalidade possibilita ao usuário alterar os dados de registro do seu perl cadastrado
no sistema.
A.19.2 Atores
Administrador, Monitor e Professor.
A.19.3 Fluxo de Eventos
A.19.3.1 Fluxo Básico
1. O usuário seleciona a opção de atualizar cadastro
2. O sistema exibe a tela de alteração de informações do cadastro do perl do usuário
3. O usuário faz as modicações necessárias e seleciona a opção de salvar
4. O sistema exibe caixa de diálogo com a mensagem Tem certeza que deseja atualizar
seus dados?
5. O usuário conrma o desejo de atualização
6. O sistema executa a ação de atualização
7. O sistema exibe a mensagem Dados atualizados com sucesso! e retorna para a
tela inicial
8. O caso de uso é nalizado.
86
A.19.3.2 Fluxos Alternativos
1. Cancelamento da operação
(a) O usuário desiste da operação e seleciona a opção de cancelar
(b) O sistema volta para a tela inicial.
A.19.4 Condições Prévias
1. O usuário deve estar autenticado pelo sistema.
A.19.5 Condições Posteriores
1. Dados atualizados com sucesso.
A.20 UC20 Remover Usuário
A.20.1 Descrição
Este caso de uso descreve o processo de remoção de usuários no sistema. Após realizar
uma remoção, o usuário selecionado não deverá ser de fato removido da base de dados,
mas apenas inativado. Dessa forma, será possível manter as suas informações relacionadas
aos objetos existentes no sistema.
A.20.2 Atores
Administrador, Monitor e Professor.
A.20.3 Fluxo de Eventos
A.20.3.1 Fluxo Básico
1. O usuário seleciona a opção de remover usuário
2. O sistema exibe caixa de diálogo com a mensagem Tem certeza que deseja remover
o usuário selecionado?
3. O usuário conrma o desejo de remoção
87
4. O sistema executa a ação de remoção do usuário selecionado
5. O sistema exibe a mensagem Usuário removido com sucesso! e retorna para a tela
inicial
6. O caso de uso é nalizado.
A.20.3.2 Fluxos Alternativos
1. Cancelamento da operação
(a) O usuário desiste da operação e seleciona a opção de cancelar
(b) O sistema volta para a tela de listagem de usuários.
2. Remoção do próprio usuário
(a) O usuário seleciona seu próprio usuário para a remoção
(b) O sistema exibe a mensagem Não é possível remover o seu próprio usuário.
e retorna para a tela inicial.
A.20.4 Condições Prévias
1. O usuário deve estar autenticado pelo sistema
2. Deve existir pelo menos um usuário cadastrado além do próprio usuário.
A.20.5 Condições Posteriores
1. Usuário removido com sucesso.
A.21 UC21 Gerar Relatório
A.21.1 Descrição
Este caso de uso descreve o processo de geração de relatório no sistema. Após criar um
projeto e realizar identicações de exemplares nele, o usuário poderá gerar um relatório
de um projeto com todas as suas informações no formato PDF.
88
A.21.2 Atores
Administrador, Aluno, Monitor e Professor.
A.21.3 Fluxo de Eventos
A.21.3.1 Fluxo Básico
1. O usuário seleciona a opção de consultar projeto
2. O sistema lista os projetos existentes do usuário
3. O usuário seleciona um projeto
4. O sistema exibe o projeto selecionado pelo usuário disponibilizando as informações
das identicações de exemplares adicionadas nele e a opção de gerar relatório
5. O usuário seleciona a opção de gerar relatório
6. O sistema disponibiliza o relatório em formato PDF
7. O caso de uso é nalizado.
A.21.3.2 Fluxos Alternativos
1. Cancelamento da operação
(a) O usuário desiste da operação e seleciona a opção de cancelar
(b) O sistema volta para a tela inicial.
2. Não há identicações de exemplares disponíveis no projeto selecionado
(a) O sistema informa que não há identicações de exemplares cadastradas no
projeto selecionado para poder gerar o relatório e cancela a operação.
A.21.4 Condições Prévias
1. O usuário deve estar autenticado pelo sistema
2. Deve existir pelo menos um projeto cadastrado
3. No projeto deve existir pelo menos uma identicação de exemplar cadastrada.
89
A.21.5 Condições Posteriores
1. Relatório gerado com sucesso.
90
APÊNDICE B -- Relatório de Erros do Sistema
B.1 Login
B.1.1 TC01 Efetuar login com sucesso
1. Resultado: Sucesso.
B.1.2 TC02 Efetuar login com usuário inválido
1. Resultado: Sucesso.
2. Saída: A mensagem login e senha incorretos foi exibida.
3. Melhorias:
(a) [Visual] (Baixo) Alterar a mensagem para Seu usuário ou senha estão incor-
retos.
B.1.3 TC03 Efetuar login com usuário em branco
1. Resultado: Sucesso.
2. Saída: A mensagem Preencha este campo. foi exibida.
B.1.4 TC04 Efetuar login com senha inválida
1. Resultado: Sucesso.
2. Saída: A mensagem login e senha incorretos foi exibida.
91
B.1.5 TC05 Efetuar login com senha em branco
1. Resultado: Sucesso.
2. Saída: A mensagem Preencha este campo. foi exibida.
B.2 Identicação de exemplar
B.2.1 TC06 Identicar exemplar com sucesso
1. Resultado: Sucesso.
2. Melhorias:
(a) [Navegação] (Baixo) Após concluir uma identicação de exemplar, nenhuma
mensagem de sucesso foi exibida ao usuário.
(b) [Navegação] (Baixo) Após concluir uma identicação de exemplar, o usuário é
redirecionado à tela de início do projeto. Neste caso o ideal seria redirecioná-lo
para a tela de visualização de identicações daquele projeto.
(c) [Visual] (Baixo) Ao clicar em Identicar exemplar o nome do projeto não foi
exibido no cabeçalho da identicação. Por exemplo, ao clicar em Identicar
exemplar no exemplar de nome Exemplar 01 do projeto Projeto 01, o
cabeçalho exibiu as seguintes informações: Exemplar 01 exemplar coletado
em 2016-10-05 no projeto.
(d) [Navegação] (Baixo) Após seguir os passos de uma identicação de exemplar,
ao identicar um táxon e clicar na opção Visualizar no atlas, o link aberto
trouxe a mensagem Objeto não encontrado! (erro 404).
B.2.2 TC07 Identicar exemplar alternando entre características
da chave de identicação
1. Resultado: Sucesso.
B.2.3 TC08 Remover identicação de exemplar
1. Resultado: Falha.
2. Erros:
92
(a) [Negócio] (Crítico) Ao remover uma identicação qualquer de um exemplar
com várias outras identicações, todas as identicações foram removidas.
B.3 Exemplar
B.3.1 TC09 Criar exemplar com sucesso
1. Resultado: Sucesso.
2. Melhorias:
(a) [Navegação] (Baixo) Após concluir o cadastro de um exemplar, nenhuma men-
sagem de sucesso foi exibida ao usuário.
(b) [Visual] (Baixo) Após cadastrar um exemplar informando uma data válida, a
data da coleta foi exibida no formato aaaa-mm-dd.
B.3.2 TC10 Criar exemplar com Quantidade < 1
1. Resultado: Sucesso.
2. Saída: A mensagem O valor deve ser maior ou igual a 1. foi exibida.
B.3.3 TC11 Criar exemplar com Quantidade > 100
1. Resultado: Falha.
2. Erros:
(a) [Execução] (Médio) Após criar um exemplar para um projeto informando um
valor > 5000 para o campo quantidade, ao tentar acessar o projeto no qual
este exemplar foi criado, o tempo de requisição expirou e o sistema exibiu a
mensagem: Fatal error: Maximum execution time of 30 seconds exceeded in
C:\xampp\htdocs\bio\chave2\bd\bd.php on line 9.
B.3.4 TC12 Criar exemplar com Nome > 100 caracteres
1. Resultado: Falha.
2. Erros:
(a) [Negócio] (Alto) Foi possível cadastrar vários exemplares com o mesmo nome.
93
B.3.5 TC13 Criar exemplar com Nome em branco
1. Resultado: Sucesso.
2. Saída: A mensagem Preencha este campo. foi exibida.
B.3.6 TC14 Criar exemplar com Descrição > 1000
1. Resultado: Falha.
2. Erros:
(a) [Execução] (Médio) Ao tentar cadastrar um exemplar com a descrição > 3000
caracteres, foi inserido um exemplar com dados em branco e o sistema exibiu
a mensagem Notice: Undened oset: 0 in
C:\xampp\htdocs\bio\chave2\chave\exemplar.php on line 32.
B.3.7 TC15 Criar exemplar com Data da coleta inválida
1. Resultado: Sucesso.
2. Saída: A mensagem Insira um valor válido. O campo está incompleto ou tem uma
data inválida foi exibida.
3. Melhorias:
(a) [Usabilidade] (Baixo) Ao cadastrar um exemplar deixando o campo Data da
coleta em branco, o exemplar exibiu 0000-00-00 para a data da coleta.
B.3.8 TC16 Remover exemplar
1. Resultado: Sucesso.
2. Melhorias:
(a) [Navegação] (Baixo) Após conrmar a ação de remoção de um exemplar,
nenhuma mensagem de sucesso foi exibida ao usuário.
94
B.4 Chave de Identicação
B.4.1 TC17 Criar chave de identicação com sucesso
1. Resultado: Falha.
2. Erros:
(a) [Negócio] (Crítico) Foi vericado um erro de negócio ao tentar cadastrar a
seguinte chave com seus respectivos passos:
Chave 01 - inserção dos passos:
Foi inserido o Passo 1.
Foi inserido o Passo 2 a partir da Característica A do Passo 1.
Foi inserido o Passo 3 a partir da Característica B do Passo 1.
Foi inserido o Passo 4 a partir da Característica A do Passo 2.
Após a inserção do Passo 4 a chave deveria car da seguinte forma:
• Passo 1
 Característica A (leva ao Passo 2)
 Característica B (leva ao Passo 3)
• Passo 2
 Característica A (leva ao Passo 4)
 Característica B
• Passo 3
• Passo 4
No entanto, a chave tomou a seguinte forma:
• Passo 1
 Característica A (leva ao Passo 2)
 Característica B (leva ao Passo 4)
• Passo 2
 Característica A (leva ao Passo 3)
 Característica B
• Passo 3
• Passo 4
Ocorreu uma inversão entre a Característica B do Passo 1 e a Característica A
do Passo 2.
95
3. Melhorias:
(a) [Navegação] (Baixo) Após concluir o cadastro de uma chave de identicação,
nenhuma mensagem de sucesso foi exibida ao usuário.
(b) [Usabilidade] (Baixo) Ao acessar uma chave de identicação, o menu princi-
pal deixa de ser exibido, causando uma experiência negativa de navegação no
sistema ao usuário.
B.4.2 TC18 Criar chave de identicação com Nome > 100 carac-
teres
1. Resultado: Sucesso.
2. Melhorias:
(a) [Usabilidade] (Baixo) Ao cadastrar uma chave de identicação com o nome
> 50 caracteres, o sistema reduziu o nome informado para os 50 caracteres
iniciais.
B.4.3 TC19 Criar chave de identicação com Nome em branco
1. Resultado: Falha.
2. Erros:
(a) [Negócio] (Alto) Ao tentar cadastrar uma chave de identicação com o nome
em branco, o sistema não exibiu nenhuma mensagem de validação e permitiu
o cadastro com um campo obrigatório não preenchido.
B.4.4 TC20 Criar chave de identicação com Descrição > 1000
caracteres
1. Resultado: Falha.
2. Erros:
(a) [Negócio] (Médio) Ao tentar cadastrar uma chave de identicação com a des-
crição > 1000 caracteres, o sistema concluiu a ação sem cadastrar a chave de
identicação.
96
B.4.5 TC21 Criar chave de identicação com Autor > 100 carac-
teres
1. Resultado: Sucesso.
2. Melhorias:
(a) [Usabilidade] (Baixo) Ao cadastrar uma chave de identicação com o nome
> 50 caracteres, o sistema reduziu o nome informado para os 50 caracteres
iniciais.
B.4.6 TC22 Criar chave de identicação com Bibliograa > 1000
caracteres
1. Resultado: Falha.
2. Erros:
(a) [Negócio] (Médio) Ao tentar cadastrar uma chave de identicação com a bi-
bliograa > 1000 caracteres, o sistema concluiu a ação sem cadastrar a chave
de identicação.
B.4.7 TC23 Criar chave de identicação adicionando passo com
Característica A > 1000
1. Resultado: Falha.
2. Erros:
(a) [Execução] (Médio) Ao cadastrar uma chave de identicação adicionando um
passo com a característica A > 1000 caracteres, a ação foi concluída normal-
mente. No entanto, ao acessar a chave, o sistema exibiu a mensagem Notice:
Undened oset: 0 in
C:\xampp\htdocs\bio\chave2\chave\passo.php on line 37 e o passo adicio-
nado com a característica A superior a 1000 caracteres foi exibido em branco.
B.4.8 TC24 Criar chave de identicação adicionando passo com
Característica A em branco
1. Resultado: Falha.
97
2. Erros:
(a) [Negócio] (Alto) Ao tentar cadastrar uma chave de identicação adicionando
um passo com a característica A em branco, o sistema não exibiu nenhuma
mensagem de validação e permitiu o cadastro com um campo obrigatório não
preenchido.
B.4.9 TC25 Criar chave de identicação adicionando passo com
Característica B > 1000
1. Resultado: Falha.
2. Erros:
(a) [Execução] (Médio) Ao cadastrar uma chave de identicação adicionando um
passo com a característica B > 1000 caracteres, a ação foi concluída normal-
mente. No entanto, ao acessar a chave, o sistema exibiu a mensagem Notice:
Undened oset: 0 in
C:\xampp\htdocs\bio\chave2\chave\passo.php on line 37 e o passo adicio-
nado com a característica B superior a 1000 caracteres foi exibido em branco.
B.4.10 TC26 Criar chave de identicação adicionando passo com
Característica B em branco
1. Resultado: Falha.
2. Erros:
(a) [Negócio] (Alto) Ao tentar cadastrar uma chave de identicação adicionando
um passo com a característica B em branco, o sistema não exibiu nenhuma
mensagem de validação e permitiu o cadastro com um campo obrigatório não
preenchido.
B.4.11 TC27 Remover chave de identicação
1. Resultado: Falha.
2. Erros:
98
(a) [Negócio] (Crítico) Foi possível excluir uma chave de identicação relacionada
a uma identicação de exemplar, o que acarretou em inconsistências ao acessar
o projeto associado à chave de identicação excluída.
B.5 Projeto
B.5.1 TC28 Criar projeto com sucesso
1. Resultado: Sucesso.
2. Melhorias:
(a) [Navegação] (Baixo) Após concluir o cadastro de um projeto, nenhuma men-
sagem de sucesso foi exibida ao usuário.
(b) [Usabilidade] (Baixo) Ao acessar um projeto, o menu principal deixa de ser
exibido, causando uma experiência negativa de navegação no sistema ao usuá-
rio.
(c) [Execução] (Baixo) Após abrir um projeto, selecionar a opção Adicionar novo
participante e em seguida clicar no botão Adicionar, sem marcar nenhum dos
checkboxes com os participantes disponíveis, ocorreu um erro de execução e o
sistema exibiu as mensagens Notice: Undened index: usuario in
C:\xampp\htdocs\bio\chave2\chave\controle.php on line 50 e Warning: In-
valid argument supplied for foreach() in
C:\xampp\htdocs\bio\chave2\chave\controle.php on line 51.
B.5.2 TC29 Criar projeto com Nome > 100 caracteres
1. Resultado: Falha.
2. Erros:
(a) [Negócio] (Alto) Foi possível cadastrar vários projetos com o mesmo nome.
3. Melhorias:
(a) [Usabilidade] (Baixo) Ao cadastrar um projeto com o nome > 50 caracteres,
o sistema reduziu o nome informado para os 50 caracteres iniciais.
99
B.5.3 TC30 Criar projeto com Nome em branco
1. Resultado: Falha.
2. Erros:
(a) [Negócio] (Alto) Ao tentar cadastrar um projeto com o nome em branco, o
sistema não exibiu nenhuma mensagem de validação e permitiu o cadastro com
um campo obrigatório não preenchido.
B.5.4 TC31 Remover projeto
1. Resultado: Sucesso.
2. Melhorias:
(a) [Usabilidade] (Baixo) Para remover um projeto é necessário antes abri-lo.
Nesse caso, o ideal é que a opção Remover projeto fosse exibida ao lado da
opção Abrir projeto.
B.6 Usuário
B.6.1 TC32 Criar usuário com sucesso
1. Resultado: Falha.
2. Erros:
(a) [Negócio] (Alto) Foi possível cadastrar vários usuários com o mesmo login.
B.6.2 TC33 Criar usuário com Nome > 100 caracteres
1. Resultado: Sucesso.
2. Melhorias:
(a) [Usabilidade] (Baixo) Ao cadastrar um usuário com o nome > 50 caracteres,
o sistema reduziu o nome informado para os 50 caracteres iniciais.
100
B.6.3 TC34 Criar usuário com Nome em branco
1. Resultado: Sucesso.
2. Saída: A mensagem Preencha este campo. foi exibida.
B.6.4 TC35 Criar usuário com Instituição > 100 caracteres
1. Resultado: Sucesso.
2. Melhorias:
(a) [Usabilidade] (Baixo) Ao cadastrar um usuário com a instituição > 50 carac-
teres, o sistema reduziu a instituição informada para os 50 caracteres iniciais.
B.6.5 TC36 Criar usuário com Instituição em branco
1. Resultado: Sucesso.
2. Saída: A mensagem Preencha este campo. foi exibida.
B.6.6 TC37 Criar usuário com E-mail inválido
1. Resultado: Sucesso.
2. Saída: A mensagem Inclua um @ no endereço de e-mail. teste está com um @
faltando. foi exibida.
B.6.7 TC38 Criar usuário com E-mail > 100 caracteres
1. Resultado: Sucesso.
2. Melhorias:
(a) [Usabilidade] (Baixo) Ao cadastrar um usuário com o e-mail > 35 caracteres,
o sistema reduziu o e-mail informado para os 35 caracteres iniciais.
B.6.8 TC39 Criar usuário com E-mail em branco
1. Resultado: Sucesso.
2. Saída: A mensagem Preencha este campo. foi exibida.
101
B.6.9 TC40 Criar usuário com Login > 100 caracteres
1. Resultado: Sucesso.
2. Melhorias:
(a) [Usabilidade] (Baixo) Ao cadastrar um usuário com o login > 30 caracteres,
o sistema reduziu o login informado para os 30 caracteres iniciais.
B.6.10 TC41 Criar usuário com Login em branco
1. Resultado: Sucesso.
2. Saída: A mensagem Preencha este campo. foi exibida.
B.6.11 TC42 Criar usuário com Senha > 100 caracteres
1. Resultado: Falha.
2. Erros:
(a) [Negócio] (Médio) Após cadastrar um usuário com a senha > 100 caracteres,
ao fazer logout e tentar fazer login com o usuário criado, a mensagem login e
senha incorretos foi exibida.
B.6.12 TC43 Criar usuário com Senha em branco
1. Resultado: Sucesso.
2. Saída: A mensagem Preencha este campo. foi exibida.
B.6.13 TC44 Remover usuário
1. Resultado: Falha.
2. Erros:
(a) [Negócio] (Crítico) Foi possível excluir um usuário relacionado a uma identi-
cação de exemplar, o que acarretou em inconsistências ao acessar o projeto
associado ao usuário excluído.
(b) [Negócio] (Alto) Foi possível excluir o próprio usuário logado no sistema.
102
B.7 Relatório
B.7.1 TC45 Gerar relatório com sucesso
1. Resultado: Sucesso.
2. Melhorias:
(a) [Visual] (Baixo) Ao abrir um projeto e exportar os dados dos exemplares adici-
onados, o título do arquivo .csv gerado não foi o mesmo do projeto selecionado.
(b) [Visual] (Baixo) O título da opção para exportar dados de um projeto possui
um erro de graa: Exportar dados sobre explares do projeto.