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

ROTEIRO DE TESTE 1

2.1

Print de Tela

ROTEIRO DE TESTE 2

3.1

Print de Tela

ROTEIRO DE TESTE 3

4.1

Print de Tela

ROTEIRO DE TESTE 4

5.1

Print de Tela

ROTEIRO DE TESTE 5

6.1

Print de Tela

ROTEIRO DE TESTE 6

7.1

Print de Tela

ROTEIRO DE TESTE 7

8.1

Print de Tela

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

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.

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

ROTEIRO DE TESTE 2
Caso de Teste: Gerar um artigo para submisso com um autor cadastrado
com sucesso (nenhum campo pode ser em branco).

3.1

Print de Tela

10

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

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

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

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

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

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

Nome Lgico
P
K Id artigo
Reviso artigo
Data criao
artigo
Data envio
artigo
Documento
envio

Nome Lgico
P
K Id dados
F
K Id artigo
titulo artigo
Titulo ingles artigo
resumo artigo
Palavras chave
artigo
abstract artigo
keywords artigo
Corpo artigo
notas artigo
Ref Bibliogrficas
artigo

Nome Fsico

ARTIGO
Taman
Tipo
ho

art_id

Inteiro

Obrigatrio
(S/N)

10

Regra
Validao
<> vazio E
inteiro
<> vazio E
inteiro

art_revisao
Inteiro
art_data_criaca data/hor
o
a
data/hor
art_data_envio a

19

Data

19

Data

art_documento Caracter

40

<> vazio

ARTI_DADOS
Taman Obrigatrio
Nome Fsico
Tipo
ho
(S/N)
atd_id

Regra
Validao
<> vazio E
inteiro
<> vazio E
inteiro

Inteiro

10

Inteiro
Caract
atd_titulo
er
Caract
atd_titulo_inlges er
Caract
atd_resumo
er
atd_palavras_cha Caract
ve
er
Caract
atd_abstract
er
Caract
atd_keywords
er
Caract
atd_corpo_texto er
Caract
atd_notas
er
atd_ref_bibliogra Caract
fica
er

10

20000

<> vazio

20000

<> vazio

1000

<> vazio

10000

<> vazio

1000

<> vazio

10000

<> vazio

30000

<> vazio

30000

<> vazio

20000

<> vazio

art_id

ARTI_AUTO
Nome Lgico
P
K Id autor
F
K Id artigo

Taman Obrigatrio
ho
(S/N)

Regra
Validao
<> vazio E
inteiro
<> vazio E
inteiro

Nome Fsico

Tipo

ata_id

Inteiro

10

art_id

Inteiro
Caract
er
Caract
er

10

3000

<> vazio

3000

<> vazio

Autor artigo

ata_autor

titulao autor

ata_titulacao

31
vinculo institucional
autor
email de contado do
autor

Nome Lgico
P
K Id revisor
F
K Id artigo
Revisor artigo
Data reviso
artigo
Observao
reviso

ata_vinculo_instituci
onal
ata_email_contato

Caract
er
Caract
er

500

<> vazio

500

<> vazio

Nome Fsico

ARTI_REVISOR
Tamanh Obrigatrio
Tipo
o
(S/N)

atr_id

Inteiro

10

art_id

Inteiro
Caract
er
Caract
er
Caract
er

10

200

<> vazio

19

<> vazio

500

<> vazio

atr_revisor
atr_data_revisa
o
atr_observacao

Regra
Validao
<> vazio E
inteiro
<> vazio e
inteiro

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-ateste-de-software/8035
https://www.gliffy.com/
Conhecimentos sobre Banco de Dados obtidos em outras instituies e
experincias profissionais.

33