especi cação de requisitos e testes de um sistema de chave ... · agradeço à minha namorada,...

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 umSistema 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 aoDepartamento de Informática e MatemáticaAplicada do Centro de Ciências Exatas e daTerra da Universidade Federal do Rio Grandedo Norte como requisito parcial para a ob-tenção do grau de bacharel em Engenhariade 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

Bedoya, Pablo Gabriel Rodrigues Neves. Especificação de requisitos e testes de um sistema de chavede identificação / Pablo Gabriel Rodrigues Neves Bedoya. -Natal, 2017.

Monografia (graduação) - Universidade Federal do Rio Grandedo Norte. Centro de Ciências Exatas e da Terra. Departamento deInformática e Matemática Aplicada. Bacharelado em Engenharia deSoftware. 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

Universidade Federal do Rio Grande do Norte - UFRNSistema de Bibliotecas - SISBI

Catalogação de Publicação na Fonte. UFRN - Biblioteca Setorial Prof. Ronaldo Xavier de Arruda - CCET

102f.: il.

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 SilvaOrientador

Instituto Metrópole Digital � IMD


Profa. Dra. Isabel Dillmann NunesInstituto Metrópole Digital � IMD


Profa. Dra. Roberta de Souza CoelhoDepartamento de Informática e Matemática Aplicada � DIMAp


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 deChave 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 anIdenti�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.1 Fluxo Básico . . . . . . . . . . . . . . . . . . . . . . . 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.1 Fluxo Básico . . . . . . . . . . . . . . . . . . . . . . . p. 64




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.1 Fluxo Básico . . . . . . . . . . . . . . . . . . . . . . . p. 65




A.5 UC05 Criar Exemplar . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 66

A.5.1 Descrição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 66

A.5.2 Atores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 67


A.5.3.1 Fluxo Básico . . . . . . . . . . . . . . . . . . . . . . . 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.1 Fluxo Básico . . . . . . . . . . . . . . . . . . . . . . . p. 68




A.7 UC07 Atualizar Exemplar . . . . . . . . . . . . . . . . . . . . . . . . . p. 69

A.7.1 Descrição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 69

A.7.2 Atores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 69


A.7.3.1 Fluxo Básico . . . . . . . . . . . . . . . . . . . . . . . p. 69




A.8 UC08 Remover Exemplar . . . . . . . . . . . . . . . . . . . . . . . . . . p. 70

A.8.1 Descrição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 70

A.8.2 Atores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 70


A.8.3.1 Fluxo Básico . . . . . . . . . . . . . . . . . . . . . . . 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.1 Fluxo Básico . . . . . . . . . . . . . . . . . . . . . . . p. 72




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.1 Fluxo Básico . . . . . . . . . . . . . . . . . . . . . . . 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.1 Fluxo Básico . . . . . . . . . . . . . . . . . . . . . . . p. 75




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.1 Fluxo Básico . . . . . . . . . . . . . . . . . . . . . . . p. 76




A.13 UC13 Criar Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 77

A.13.1 Descrição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 77

A.13.2 Atores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 77


A.13.3.1 Fluxo Básico . . . . . . . . . . . . . . . . . . . . . . . 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.1 Fluxo Básico . . . . . . . . . . . . . . . . . . . . . . . p. 79




A.15 UC15 Atualizar Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . p. 80

A.15.1 Descrição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 80

A.15.2 Atores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 80


A.15.3.1 Fluxo Básico . . . . . . . . . . . . . . . . . . . . . . . p. 80




A.16 UC16 Remover Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 81

A.16.1 Descrição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 81

A.16.2 Atores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 81


A.16.3.1 Fluxo Básico . . . . . . . . . . . . . . . . . . . . . . . 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.1 Fluxo Básico . . . . . . . . . . . . . . . . . . . . . . . p. 83




A.18 UC18 Consultar Usuário . . . . . . . . . . . . . . . . . . . . . . . . . . p. 84

A.18.1 Descrição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 84

A.18.2 Atores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 84


A.18.3.1 Fluxo Básico . . . . . . . . . . . . . . . . . . . . . . . p. 84




A.19 UC19 Atualizar Usuário . . . . . . . . . . . . . . . . . . . . . . . . . . p. 85

A.19.1 Descrição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 85

A.19.2 Atores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 85


A.19.3.1 Fluxo Básico . . . . . . . . . . . . . . . . . . . . . . . p. 85




A.20 UC20 Remover Usuário . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 86

A.20.1 Descrição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 86

A.20.2 Atores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 86


A.20.3.1 Fluxo Básico . . . . . . . . . . . . . . . . . . . . . . . p. 86




A.21 UC21 Gerar Relatório . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 87

A.21.1 Descrição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 87

A.21.2 Atores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 88


A.21.3.1 Fluxo Básico . . . . . . . . . . . . . . . . . . . . . . . p. 88




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


terística A em branco . . . . . . . . . . . . . . . . . . . . . . . . p. 96


terística B > 1000 . . . . . . . . . . . . . . . . . . . . . . . . . p. 97


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, combase 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


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


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


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


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


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


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


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-

ves de identi�cação provendo as funcio-

nalidades de criação, consulta, remoção

e atualização das chaves de identi�ca-

ção

Essencial

RF02 O sistema deve fornecer ao usuário uma

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

Essencial

RF03 O sistema deve permitir o usuário aces-

sar o caminho percorrido (histórico) na

identi�cação de um táxon

Essencial RF02

RF04 O sistema deve permitir o usuário al-

terar uma veri�cação voltando a um

passo anterior no caminho percorrido

(histórico) na identi�cação

Essencial RF02, RF03

RF05 O sistema deve, após o usuário realizar

a identi�cação de um táxon, apresentar

os taxa relacionados

Importante RF02

RF06 O sistema deve permitir o usuário bus-

car um táxon por nome

Importante RF01

RF07 O sistema deve noti�car o usuário

quando uma identi�cação resultar em

um exemplar, tendo ela chegado ao seu

�m

Importante RF02

RF08 O sistema deve disponibilizar descri-

ções textuais em cada passo para auxi-

liar a veri�cação das características em

uma identi�cação

Importante RF01, RF02

43

Tabela 1 � continuação da página anterior

Identi�cador Descrição Prioridade Depende de

RF09 O sistema deve disponibilizar imagens

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-

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

Importante

RF11 O sistema deve permitir o usuário re-

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

usuários provendo as funcionalidades

de criação, consulta, remoção e atua-

lização dos usuários

Importante

RF13 O sistema deve disponibilizar uma

forma de autenticação dos usuários ca-

dastrados no por meio de username e

password

Importante RF12

RF14 O sistema deve permitir o usuário ge-

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-

çõ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

Manutenibilidade Essencial

RNF02 O sistema deve ser fácil de

usar, tornando o seu processo

de identi�cação mais rápido

que o processo de identi�ca-

ção manual

Facilidade de Operação Importante

RNF03 O sistema deve ser adaptá-

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

Usabilidade Desejável

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


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;


Exemplar;


Chave de Identi�cação;

47


Projeto de Identi�cação de Exemplares;


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


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


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


TC15 Criar exemplar com Data da coleta inválida

TC16 Remover exemplar

Chave de Identi�caçã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


TC28 Criar projeto com sucesso

TC29 Criar projeto com Nome > 100 caracteres

TC30 Criar projeto com Nome em branco

TC31 Remover projeto

Usuário


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


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


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


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.org2http://testng.org3http://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


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


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


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


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 testesautomatizados. 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 deZoologia 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 SoftwareLifecycle. 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




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



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


1. O usuário deverá estar autenticado pelo sistema

2. Deve existir pelo menos uma identi�cação cadastrada.


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




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


65


1. Cancelamento da operação


(b) O sistema volta para a tela de listagem de identi�cações de exemplares.





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




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





(b) O sistema volta para a tela de listagem de identi�cações de exemplares.





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




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





(b) O sistema volta para a tela de criação de exemplar.


1. O usuário deve estar autenticado pelo sistema.


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




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



1. Cancelamento da Operação



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



2. Deve existir pelo menos um exemplar cadastrado.


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




1. O usuário faz uma consulta de exemplar (UC06)


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



este exemplar?�

70


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





(b) O sistema volta para a tela de listagem de exemplares.





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


71



1. O usuário seleciona faz uma consulta de exemplar (UC06)


3. O usuário escolhe o exemplar que irá remover e seleciona a opção de remover

exemplar


este exemplar?�


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





(b) O sistema volta para a tela de listagem de exemplares.





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.



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)


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



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.



(b) O sistema volta para a tela de criação de chave de identi�cação.


1. O usuário deverá estar autenticado pelo sistema.


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


74



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






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





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




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



esta chave de identi�caçã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


76




(b) O sistema volta para a tela de listagem de chaves de identi�cação.





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




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


esta chave de identi�caçã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





(b) O sistema volta para a tela de listagem de chaves de identi�cação.





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


78



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





(b) O sistema volta para a tela de criação de projeto.


1. O Usuário deve estar autenticado pelo sistema.


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




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






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



2. Deve existir pelo menos um projeto cadastrado.


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




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



este projeto?�


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





(b) O sistema volta para a tela de listagem de projetos.





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


82



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


este projeto?�


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





(b) O sistema volta para a tela de listagem de projetos.





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




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


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





(b) O sistema volta para a tela de criação de usuário.

84




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




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






85


1. O usuário deverá estar autenticado pelo sistema.


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




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



seus dados?�


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


86








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




1. O usuário seleciona a opção de remover usuário


o usuário selecionado?�


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





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



2. Deve existir pelo menos um usuário cadastrado além do próprio usuário.


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




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






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.



2. Deve existir pelo menos um projeto cadastrado

3. No projeto deve existir pelo menos uma identi�cação de exemplar cadastrada.

89


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


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


2. Saída: A mensagem �Preencha este campo.� foi exibida.

B.1.4 TC04 Efetuar login com senha inválida


2. Saída: A mensagem �login e senha incorretos� foi exibida.

91

B.1.5 TC05 Efetuar login com senha em branco



B.2 Identi�cação de exemplar

B.2.1 TC06 Identi�car exemplar com 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


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


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


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


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


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



B.3.6 TC14 Criar exemplar com Descrição > 1000


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


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


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


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 B

• Passo 3

• Passo 4

No entanto, a chave tomou a seguinte forma:

• Passo 1


� Característica B (leva ao Passo 4)

• Passo 2


� 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


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


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


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


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


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


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.


Característica A em branco


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.


Característica B > 1000


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.


Característica B em branco


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


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


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


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


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


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


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


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



B.6.4 TC35 Criar usuário com Instituição > 100 caracteres


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



B.6.6 TC37 Criar usuário com E-mail inválido


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


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



101

B.6.9 TC40 Criar usuário com Login > 100 caracteres


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



B.6.11 TC42 Criar usuário com Senha > 100 caracteres


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



B.6.13 TC44 Remover usuário


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


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

especi cação de requisitos e testes de um sistema de chave ... · agradeço à minha namorada,...

Documents