UNIP INTERATIVA

Projeto Integrado Multidisciplinar V

Cursos Superiores de Tecnologia

Teste de Software e modelo de dados.

Unip Interativa Piracicaba

2016
 UNIP INTERATIVA

Projeto Integrado Multidisciplinar V

Cursos Superiores de Tecnologia

Teste de Software e modelo de dados.

Joo Paulo Castro Tinelli Fernando Fonseca

1505231 - 1500492

Anlise e Desenvolvimento de Sistemas

1 Semestre

Unip Interativa Piracicaba

2016
 RESUMO

Este documento demonstra, detalhadamente, um projeto de teste e anlise para um

sistema de formatao de artigos acadmicos

A demonstrao dos testes ocorre atravs de 10 casos de teste j especificados.

Casos de teste relacionado uma situao que o sistema apresenta, e que dada
uma informao de entrada, gerado um resultado de sada esperado pelo usurio.

Alguns exemplos de casos de teste abordados nesse projeto so de gerar um artigo

completo com um autor cadastrado com sucesso, com trs autores, com formatao
de informaes (tipos de fontes, alinhamentos, listas), inserir e-mails invlidos, entre
outros.

E para cada caso de teste foi feito um roteiro de teste, que uma descrio
detalhada do passo a passo para execuo dos casos, e avaliao do resultado
obtido. Os roteiros de teste esto todos detalhados em tabelas, onde h um padro
para as colunas: ID que serve para sequenciar o roteiro, Passo para execuo
que a descrio da ao que o usurio deve realizar, Dado de entrada a
informao que ser imputada e Resultado esperado que como o sistema se
comportou diante da ao.

Com o roteiro j criado para cada caso, foram feitos os testes na prtica (gerando
prints de tela dos resultados para servirem de evidncia) e a partir deles foram
tiradas as concluses: se o sistema atendeu aquele caso, se no ocorreram erros,
se as validaes estavam corretas, criando um relatrio final especificando os
pontos negativos e positivos e sugerindo possveis melhorias.

A segunda parte do projeto consiste em apresentar um modelo de dados conceitual

para armazenamento das informaes que o sistema apresenta. Para isso foram
analisadas essas informaes, detalhando como seria as estruturas de tabelas e os
campos necessrios, as ligaes (chave primria e estrangeira) para identificar cada
registro e gerar interligao de dados (estrutura slida).

Aps esses estudos foram criados os modelos MER e DER, que contam com
imagens que detalham o fluxo de informao e suas regras, e tambm um dicionrio
de dados contendo as especificaes dos campos das tabelas, como tipo de dado,
tamanho, validao, e se obrigatrio ou no.

As metodologias utilizadas para elaborao foram as aulas de engenharia de

software 2 e a ferramenta Gliffy para criao da estrutura de banco de dados.
 ABSTRACT

This document shows, in detail, a test design and analysis for a formatting system of
academic articles.

The demonstration test occurs through 10 test cases already specified. Test cases
are related to a situation that the system displays, and given an entry of information,
it generates an output result expected by the user.

Some examples of test cases addressed in this project is to generate a complete

article with a successfully registered author with three authors, with formatting
information (types of fonts, alignment, lists), enter invalid emails, among others.
And for each test case was made a test script which is a detailed description of the
step by step execution of cases and review of the results obtained. test scripts The
are all detailed in tables where there is a pattern for the columns "ID" used to
sequence the script, "Step to run" which is the description of the action that the user
must perform, "input data" is the information that will be allocated and "expected
result" that is how the system behaved before the action.

With the script already set up for each case the tests were done in practice
(producing screen prints the results to be used as evidence) and from them the
conclusions were drawn: if the system met that case, if no errors have occurred, if
the validations were correct, creating a final report specifying the negative and
positive points and suggesting possible improvements.

The second part of the project is to present a conceptual data model to store the
information that the system displays. For this were analyzed this information,
detailing how would the tables structures and the required fields, the links (primary
and foreign key) to identify each record and generate data interconnection (solid
structure).

After these studies were created the MER models and RSP, which have images that
detail the flow of information and its rules, and also a data dictionary containing the
specifications of the fields of the tables, as data type, size, validation, and it is
mandatory or not.

The methodologies used in the preparation were the software engineering classes 2
and Gliffy tool for creating database structure.
 SUMRIO

1 INTRODUO

2 ROTEIRO DE TESTE 1
2.1 Print de Tela

3 ROTEIRO DE TESTE 2
3.1 Print de Tela

4 ROTEIRO DE TESTE 3
4.1 Print de Tela

5 ROTEIRO DE TESTE 4
5.1 Print de Tela

6 ROTEIRO DE TESTE 5
6.1 Print de Tela

7 ROTEIRO DE TESTE 6
7.1 Print de Tela

8 ROTEIRO DE TESTE 7
8.1 Print de Tela

9 ROTEIRO DE TESTE 8
9.1 Print de Tela

10 ROTEIRO DE TESTE 9
10.1 Print de Tela

11 ROTEIRO DE TESTE 10 (ESPECIFICAES DE INTERFACE)

11.1 Especificaes de mensagem a ser exibida

12 RELATRIO FINAL ROTEIRO DE TESTE

13 MODELO DE DADOS
13.1 Relacionamentos (Mer/Der)
13.2 Dicionrio de Dados
14 CONCLUSO

15 REFERNCIAS
 6

1 INTRODUO

O objetivo para realizao desse trabalho desenvolver, para um sistema de

formatao de artigos acadmicos, um roteiro de teste, baseando-se nos
princpios de caixa-preta. Foram identificados 10 casos de testes, sendo que para
cada um, ser desenvolvido um roteiro de teste, e a partir deles sero gerados
resultados. Tambm ser demonstrado um modelo para armazenamento dos
dados desse sistema.

A metodologia utilizada com base em testes funcionais de caixa-preta que

envolve duas atividades: especificao de casos de testes ou cenrios de testes
(por exemplo, incluir um cliente com sucesso) e a descrio detalhada do passo a
passo para essa execuo. Para o modelo de dados, foi adotado as prticas de
definio de tabelas (chaves primrias e estrangeiras), de campos (tamanho,
tipo, validao), relacionamentos (Mer x Der), todos de acordo com as
informaes do sistema.

O sistema conta com o cadastro de informaes essenciais para gerao de

artigo, como ttulo, autor, resumo, palavras-chave, contedo, referncias, etc. Os
roteiros de teste em unio com as especificaes de dados geram uma viso
mais abrangente dos objetivos do sistema.

2 ROTEIRO DE TESTE 1
 7

Caso de Teste: Gerar um artigo completo com um autor cadastrado com

sucesso (nenhum campo pode ser em branco).

2.1 Print de Tela

 8

3 ROTEIRO DE TESTE 2

Caso de Teste: Gerar um artigo para submisso com um autor cadastrado

com sucesso (nenhum campo pode ser em branco).
 9

3.1 Print de Tela

 10

4 ROTEIRO DE TESTE 3

Caso de Teste: Gerar um artigo completo com trs autores cadastrados com
sucesso (nenhum campo pode ser em branco).
 11

4.1 Print de Tela

 12

5 ROTEIRO DE TESTE 4
 13

Caso de Teste: Gerar um artigo completo com trs autores com e-mails
invlidos (nenhum campo pode ser em branco).

5.1 Print de Tela

 14

6 ROTEIRO DE TESTE 5

Gerar um artigo completo com trs autores com os campos de autor em

branco.
 15

6.1 Print de Tela

 16

7 ROTEIRO DE TESTE 6
 17

Gerar um artigo completo com um autor cadastrado com sucesso (nenhum

campo pode ser em branco) e limpar os dados sem gerar o artigo.

7.1 Print de Tela

 18

8 ROTEIRO DE TESTE 7

Caso de Teste: Gerar um artigo completo com um autor cadastrado com

sucesso (nenhum campo pode ser branco), criando no campo corpo do
 19

texto um texto com formatao em negrito, itlico, subscrito e sobrescrito

com texto justificado com sucesso.

8.1 Print de Tela

 20

9 ROTEIRO DE TESTE 8
 21

Gerar um artigo completo com um autor cadastrado com sucesso (nenhum

campo pode ser branco), anexando no campo corpo do texto uma imagem
de um arquivo com sucesso.

9.1 Print de Tela

 22

10 ROTEIRO DE TESTE 9
 23

Gerar um artigo completo com um autor cadastrado com sucesso (nenhum

campo pode ser branco), anexando no campo Notas uma URL de um
arquivo com sucesso e criando um texto formato esquerda e em negrito.

10.1 Print de Tela

 24

11 ROTEIRO DE TESTE 10 (ESPECIFICAES DE INTERFACE)

 25

11.1 Especificaes de mensagem a ser exibida

 26

12 RELATRIO FINAL ROTEIRO DE TESTE

 27

Aps a realizao dos roteiros de teste, podemos identificar alguns casos de

possveis erros e sugerimos solues:

- Ao inserir um e-mail invlido, quando se tira o foco do campo

demonstrado a mensagem de invalidao, porm ao clicar no boto de gerar
artigo completo essa validao ocorre apenas uma vez (no submete o
formulrio), na segunda o e-mail invlido submetido outra pgina. A
soluo seria validar novamente ao clicar no boto e no submeter os dados
do formulrio.

- Para os campos Resumo e Abstract o limite de caracteres 1000, mas

possvel exceder essa capacidade. preciso garantir que para esses campos
o limite mximo de caracteres 1000 e no deixar inserir a mais.

- Ao colar uma imagem no campo Corpo do Texto essa imagem no

anexada. A soluo seria criar uma interface para que o editor acesse os
dados da rea de transferncia diretamente.

- Ao adicionar um cadastro de um novo autor, as regras de validaes dos

campos do primeiro autor no acontecem para o autor novo, o correto seria
atribuir as mesmas validaes aos campos novos.

Em geral, o sistema atendeu abertamente aos requisitos para a criao de

um artigo, onde nele so cadastradas as informaes bsicas (ttulo, resumo,
abstract, etc). A possibilidade de formatao (fontes, alinhamento, listas) do
contedo, das notas e das referncias bibliogrficas so um diferencial que
facilitam o trabalho e garantem a livre escolha de formatao. A insero de
mais de um autor e a rapidez para gerar o artigo tambm so destaques.

13 MODELO DE DADOS

Para armazenar as informaes dos artigos, foram analisadas as seguintes

tabelas:
 28

Artigo: Para armazenar identificador, reviso, datas e numero documento do

artigo.

Arti_dados: Para armazenar todos os dados do artigo.

Arti_autor: Para armazenar informaes de todos os autores do artigo.

Arti_revisor: Para armazenar informao dos revisores do artigo.

Cada tabela possui sua chave primria e as tabelas arti_dados, arti_autor e

arti_revisor possuem chave estrangeira para interligarem com a tabela artigo.

13.1 Relacionamentos (Mer/Der)

 29

13.2 Dicionrio de Dados

 30

ARTIGO
Taman Obrigatrio Regra
Nome Lgico Nome Fsico Tipo ho (S/N) Validao
P <> vazio E
K Id artigo art_id Inteiro 10 S inteiro
<> vazio E
Reviso artigo art_revisao Inteiro 3 S inteiro
Data criao art_data_criaca data/hor
artigo o a 19 S Data
Data envio data/hor
artigo art_data_envio a 19 N Data
Documento
envio art_documento Caracter 40 N <> vazio

ARTI_DADOS
Taman Obrigatrio Regra
Nome Lgico Nome Fsico Tipo ho (S/N) Validao
P <> vazio E
K Id dados atd_id Inteiro 10 S inteiro
F <> vazio E
K Id artigo art_id Inteiro 10 S inteiro
Caract
titulo artigo atd_titulo er 20000 S <> vazio
Caract
Titulo ingles artigo atd_titulo_inlges er 20000 S <> vazio
Caract
resumo artigo atd_resumo er 1000 S <> vazio
Palavras chave atd_palavras_cha Caract
artigo ve er 10000 S <> vazio
Caract
abstract artigo atd_abstract er 1000 S <> vazio
Caract
keywords artigo atd_keywords er 10000 S <> vazio
Caract
Corpo artigo atd_corpo_texto er 30000 S <> vazio
Caract
notas artigo atd_notas er 30000 S <> vazio
Ref Bibliogrficas atd_ref_bibliogra Caract
artigo fica er 20000 S <> vazio

ARTI_AUTO
Taman Obrigatrio Regra
Nome Lgico Nome Fsico Tipo ho (S/N) Validao
P <> vazio E
K Id autor ata_id Inteiro 10 S inteiro
F <> vazio E
K Id artigo art_id Inteiro 10 S inteiro
Caract
Autor artigo ata_autor er 3000 S <> vazio
Caract
titulao autor ata_titulacao er 3000 S <> vazio
 31

vinculo institucional ata_vinculo_instituci Caract

autor onal er 500 S <> vazio
email de contado do Caract
autor ata_email_contato er 500 S <> vazio

ARTI_REVISOR
Tamanh Obrigatrio Regra
Nome Lgico Nome Fsico Tipo o (S/N) Validao
P <> vazio E
K Id revisor atr_id Inteiro 10 S inteiro
F <> vazio e
K Id artigo art_id Inteiro 10 S inteiro
Caract
Revisor artigo atr_revisor er 200 S <> vazio
Data reviso atr_data_revisa Caract
artigo o er 19 S <> vazio
Observao Caract
reviso atr_observacao er 500 N <> vazio

14 CONCLUSO

A elaborao do contedo do projeto, proporcionou uma viso bastante

abrangente de como um software acontece. Podemos destacar os estudos
para criao de estruturas de tabelas, de tipos de dados, dos
relacionamentos, de lgicas, sendo esses os primeiros passos para o
surgimento.

Logo aps o desenvolvimento em cdigo-fonte, necessrio a realizao de

testes, as interfaces j esto prontas, ento preciso criar acontecimentos
para testa-lo, permitindo que essa fase entre nos conceitos de engenharia de
software (testes caixa preta no caso desse projeto).

Os testes caixa-preta nos mostraram um novo caminho para testar os

softwares, sendo que podemos atribui-lo em nosso trabalho do dia a dia, pois
uma tarefa que facilita a qualidade do produto, podendo fazer correes,
validaes, visualizar possveis melhorias e o roteiro de teste pode servir de
documentao para outros profissionais que forem utilizar o sistema.

A partir dos estudos visto em Engenharia de Software 2 e com a ferramenta

Gliffy para gerao dos modelos de dados, foi possvel desenvolver um
projeto com bastante eficincia, onde apontamos ao software os seus
possveis erros, mas tambm suas correes e melhorias, no deixando de
destacar suas qualidades e diferenciais.
 32

15 REFERNCIAS

Unidades 1, 2, 3 e 4 da matria Engenharia de Software || da Unip

Interativa, professor Andr Luiz.

http://www.devmedia.com.br/artigo-engenharia-de-software-introducao-a-
teste-de-software/8035

https://www.gliffy.com/

Conhecimentos sobre Banco de Dados obtidos em outras instituies e

experincias profissionais.
33