Teste de Caixa-Preta

Prévia do material em texto

UNIVERSIDADE PAULISTA – UNIP 
 
 
 
 
 
 
 
JÚLIO BRAZÃO ASSUNÇÃO 
 
 
 
 
 
 
PIM V - PROJETO INTEGRADO MULTIDISCIPLINAR V 
 
 
 
 
MANAUS 
2018 
UNIVERSIDADE PAULISTA - UNIP 
 
 
 
 
 
 
 
TESTE DE CAIXA PRETA 
 
 
 
 
 Projeto dissertativo com finalidade de 
cumprimento de atividade e obtenção de nota 
na matéria de ‘Projeto Integrado 
Multidisciplinar IV’ do curso de Tecnologia em 
Análise e Desenvolvimento de Sistemas pela 
Universidade Paulista – UNIP no ano de 2017 
 
 
 
MANAUS 
2018 
ÍNDICE 
Resumo __________________________________________________________ 4 
Abstract __________________________________________________________ 5 
Introdução __________________________________________________________ 6 
Disciplinas __________________________________________________________ 7 
Fases __________________________________________________________ 8 
Roteiro __________________________________________________________ 9 
Casos 1-3 __________________________________________________________ 10 
Casos 4-5 __________________________________________________________ 11 
Casos 6-7 __________________________________________________________ 12 
Casos 8-9 __________________________________________________________ 13 
Caso 10 __________________________________________________________ 14 
O SFAA __________________________________________________________ 15 
Não 
conformidades 
__________________________________________________________ 17 
Conclusão __________________________________________________________ 18 
Anexo 1 __________________________________________________________ 19 
Anexo 2 __________________________________________________________ 20 
Anexo 3 __________________________________________________________ 21 
Anexo 4 __________________________________________________________ 22 
Anexo 5 __________________________________________________________ 23 
Anexo 6 __________________________________________________________ 24 
Anexo 7 __________________________________________________________ 25 
Anexo 8 __________________________________________________________ 26 
Anexo 9 __________________________________________________________ 27 
Anexo 10 __________________________________________________________ 28 
Referências 
Bibliográficas 
__________________________________________________________ 29 
 
RESUMO 
 
Teste de caixa-preta executado no sistema gerador de artigos cientificos da ‘UNIP Interativa’, o 
teste tem a finalidade de verificar e validar as funcionalidades propostas na documentação do 
sistema, bem como certificar de que o usuário final terá sucesso na execução de todos os 
comandos, utilização de funções e dados de resposta apresentados da forma que o software se 
propõe. 
O teste foi feito utilizando entradas fictícias que simulam os dados de entrada de um usuário 
convencional e a resposta obtida com cada tipo de dado inserido, bem como dados inválidos 
e/ou que não correspondem ao que foi pedido. Teste de verificação de restrição de tamanho de 
dados também foi executado na tentativa de identificar qualquer erro no momento da 
verificação e validação de dados por parte do sistema. 
Testes funcionais colocarão em prática fundamentos obtidos na matéria de “Engenharia de 
Software II” e os testes de usabilidade serão regidos pelo que foi ministrado no curso de “Projeto 
de Interface com o Usuário”. 
 
 
 
 
 
 
 
 
 
ABSTRACT 
 
Black-box test built on cientific article generator of ‘UNIP Interativa’, test must verify and validate 
all functions described on system documentation and verify the output received by user on 
system. 
Test was built using fake entries that simulate inputs of a common user and the outputs received 
on each field filled, this test also verifies cases where data was inserted incorrectly or on a format 
that system cannot recognize. 
Function test will be guided by statements learned on “Software Engineering II” course, and the 
usability test will be guided by statements learned on “User Interface Project” course. 
 
 
 
 
 
 
 
 
 
 
 
 
 
INTRODUÇÃO 
 
Com o avanço da tecnologia e a necessidade de adaptação do nosso cotidiano a tarefas 
corriqueiras automatizadas, grande parte das atividades que realizamos em nossas casas, 
ambientes de trabalho e outros se fazem por meio de sistemas automatizados. Estes sistemas, 
por sua vez, antes de chegarem em nossas mãos, como usuários finais, devem e precisam passar 
por testes que verifiquem a capacidade do software de tratar todas as entradas de dados que 
podem ser inseridas afim de garantir a eficiencia e consistência no tratamento desses dados. 
 
Testes de caixa-preta são, basicamente, testes que irão verificar se o sistema em questão garante 
o recebimento de informações e a recusa de quaisquer tipos de dados que possam ameaçar a 
integridade do sistema como um todo. É através desse tipo de teste que também se cria o filtro 
que faz com que o sistema esteja imune a ataques mal intencionados e outras ameaças ao 
programa. Este documento trata dos casos de testes executados no sistema de geração de artigo 
científico da ‘UNIP Interativa’. 
 
 
 
 
 
 
 
 
 
DISCIPLINAS CONTEMPLADAS 
 
Engenharia de Software II: A disciplina em questão contempla fundamentos e procedimentos 
detalhados de planejamento estratégico que precedem o processo de desenvolvimento do 
software propriamente dito. O módulo em questão detalha a importancia do controle e 
documentação de todo o ciclo de vida do desenvolvimento, sobretudo aqueles que envolvem os 
mecanismos de interação do usuário final com o sistema desenvolvido. 
 
Projeto de Interface com o Usuário: Matéria que retrata a evolução histórica das interfaces ao 
longo do tempo e a forma com que nós, seres humanos, interagimos com elas. Também 
tomamos ciência da importancia do estudo aprofundado dos casos de experiência do usuário e 
como nós, desenvolvedores, podemos obter êxito no cumprimento de todos os requisitos do 
sistema levantados durante o processo de engenharia do software. 
 
 
 
 
 
 
 
 
 
 
 
FASES DO TESTE 
 
1. Roteiro de testes de caixa-preta 
Realização dos 09 casos de testes de inserção de dados para verificação de todas as 
nuances do sistema. 
 
2. Inspeção de usabilidade usando avaliação heurística 
Testes que verificam a resposta da interface gráfica do sistema, pontuando as respostas 
obtidas pelo usuário em casos de erro e sucesso. 
 
3. Resultados dos testes 
Estado final de todos os processos, resultados obtidos e conclusão geral acerca da 
utilização do sistema. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
ROTEIRO DE TESTE 
 
1. Do tipo de teste escolhido 
O sistema já conta com toda sua estrutura finalizada e necessita de todos os testes que 
certifiquem de que o mesmo retorna a resposta esperada pelo usuário, para testes de entrada e 
saída a opção mais indicada foi o teste de caixa preta. 
 
2. Do conteúdo de entrada 
Com a finalidade de ter uma base fixa de texto para testes de entrada e saída de dados, foi criado 
um texto fictício (Anexo 1) com padrão informal de formatação para ser tratado pelo sistema e 
devolvido ao usuário no padrão estipulado pela proposta principal do sistema. Nomes e títulos 
são fictícios e corpo do texto foi gerado via Lorem Ipsum (http://lipsum.com). 
 
3. Do conteúdo de saída 
O teste servirá para validação do sistema e estudo aprofundado de erros que podem ocorrer com 
quaisquerentradas que não respondam os requisitos exigidos no descritivo de cada campo. Este 
teste validará a consistencia do sistema e sua capacidade de identificar saídas inadequadas ou 
que não atendam corretamente os padrões estabelecidos e exigidos. 
 
4. Status do teste 
O status de cada caso de teste será definido por “IN” (dentro do estabelecido previamente) e 
“OUT” (fora do estabelecido”. O status “IN” será definido quando todas as condições do teste 
forem satisfeitas pela descrição dos seus campos e funções. O status “OUT” será definido quando 
qualquer função não for satisfeita integralmente ou não. 
 
CASOS DE TESTE 
 
Caso 1 
Descrição: Gerar um arquivo completo com um autor cadastrado com sucesso, sendo que, todos 
os campos devem estar preenchidos. 
Entrada inserida Resultado esperado Resultado obtido Status 
Anexo 1 Formatação do texto com sucesso Formatação do texto com 
sucesso (Anexo 2) 
IN 
 
 
Caso 2 
Descrição: Gerar um artigo para submissão com um autor cadastrado com sucesso (nenhum 
campo pode ser branco). 
Entrada inserida Resultado esperado Resultado obtido Status 
Anexo 1 Submissão realizada com sucesso. 
 
Submissão realizada com 
sucesso. (Anexo 3) 
IN 
 
 
Caso 3 
Descrição: Gerar um artigo completo com três autores cadastrados com sucesso (nenhum campo 
pode ser branco). 
Entrada inserida Resultado esperado Resultado obtido Status 
Anexo 1 Geração realizada com sucesso. Geração realizada com 
sucesso. (Anexo 4) 
IN 
 
Caso 4 
Descrição: Gerar um artigo completo com três autores com e-mails inválidos (nenhum campo 
pode ser branco). 
Entrada inserida Resultado esperado Resultado obtido Status 
Anexo 1 Sistema deverá detectar emails 
inválidos e pedir que usuário 
reescreva-os inserindo entradas 
válidas. 
Dois autores tiveram emails 
inválidos inseridos e sistema 
não detectou, nem acusou 
erro. Sistema deveria ser 
capaz de detectar entrada 
inválida. (Anexo 5) 
OUT 
 
 
Caso 5: Gerar um artigo completo com três autores com os campos de autor em branco. 
Entrada inserida Resultado esperado Resultado obtido Status 
Anexo 1 Sistema deve acusar falta de 
informação essencial e pedir que 
usuário insira um nome válido no 
campo do autor. 
Sistema acusou campo em 
branco e pediu que usuário 
verificasse o campo do 
“autor”. (Anexo 6) 
IN 
 
 
 
 
 
 
Caso 6 
Descrição: Gerar um artigo completo com um autor cadastrado com sucesso (nenhum campo 
pode ser branco) e limpar os dados sem gerar o artigo. 
Entrada inserida Resultado esperado Resultado obtido Status 
Anexo 1 Sistema deve limpar todos os 
campos do sistema para que 
usuário retome preenchimento do 
inicio do processo. 
Sistema não limpou os 
campos: “Corpo do texto”, 
“Notas” e “Referencias 
bibliográficas”. (Anexo 7) 
OUT 
 
 
Caso 7 
Descrição: Gerar um artigo completo com um autor cadastrado com sucesso (nenhum campo 
pode ser branco), criando no campo “corpo do texto” um texto com formatação em negrito, 
itálico, subscrito e sobrescrito com texto justificado com sucesso. 
Entrada inserida Resultado esperado Resultado obtido Status 
Anexo 1 Sistema deve manter formatações 
no texto gerado. 
Manteve formatação 
conforme definido no 
“campo de texto”. (Anexo 8) 
IN 
 
 
 
 
 
 
 
Caso 8 
Descrição: 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. 
Entrada inserida Resultado esperado Resultado obtido Status 
Anexo 1 Sistema deve permitir e exibir 
imagem inserida no campo “corpo 
do texto”. 
Sistema não possui função 
de inserir imagem ou URL de 
imagem já hospedada em 
algum servidor externo. Foi 
tentada inclusão da imagem 
utilizando a tag <img> no 
modo “Source” porém não 
foi obtido qualquer 
resultado com sucesso. 
(Anexo 9) 
OUT 
 
 
Caso 9 
Descrição: 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. 
Entrada inserida Resultado esperado Resultado obtido Status 
Anexo 1 Na geração final do arquivo deve 
ser mantida formatação em 
negrito como foi configurado no 
software e URL deve permanecer. 
Software manteve texto em 
negrito e manteve URL 
anexada, a mesma só não se 
tornou clicável. (Anexo 10) 
IN 
 
Caso 10 - Testes de Interface 
 
Testes de interface são métricas criadas para quantificar e validar o nível de experiência de 
usuário de uma determinada interface. Através desses testes podemos ter uma base a respeito 
do que pode e precisa ser melhorado, seja num software, interface gráfica para web (sites, blogs, 
sistemas intranet e afins) ou qualquer outro tipo de tecnologia que parta do principio da 
interação entre um ser humano e uma máquina. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
O “SFAA – UNIP Interativa” 
O sistema conta com 16 (dezesseis) elementos de “input”, e são eles: 
ITEM NOME DESCRIÇÃO TIPO STATUS 
1 Título Título do artigo a ser gerado. FIELD OK 
2 Title Tradução do título do artigo para a 
língua inglesa. 
FIELD OK 
3 Autores Objeto com múltiplos campos que 
formam um objeto “Autor”. 
OBJECT OK 
3.1 Autor Campo “autor” do objeto “Autores”. FIELD OK 
3.2 Titulação Titulação do autor do artigo gerado 
pelo sistema. Campo “titulação” do 
objeto “Autores”. 
FIELD OK 
3.3 Vínculo 
Institucional 
Vínculo institucional do autor com a 
instituição mantenedora do sistema de 
geração de artigos. Campo “vínculo 
institucional” do objeto “Autores”. 
FIELD OK 
3.4 Email Email para contato do autor do artigo 
científico gerado pelo sistema. Campo 
“email” do objeto “Autores”. 
FIELD Não 
Conforme 
4 Resumo Breve resumo a respeito do artigo 
gerado pelo sistema. 
FIELD OK 
5 Palavras-chave Palavras-chave que dizem a respeito do 
artigo gerado pelo sistema. 
FIELD OK 
6 Abstract Breve resumo, em inglês, do artigo 
gerado pelo sistema. 
FIELD OK 
7 Keywords Palavras-chave, em inglês, que dizem a 
respeito do artigo gerado pelo sistema. 
FIELD OK 
8 Corpo do 
Texto 
Campo com o desenvolvimento do 
texto, com ferramentas de formatação 
através de “markdown” para 
organização do texto. 
TEXTAREA OK 
9 Notas Campo de notas do texto, com 
ferramentas de formatação através de 
“markdown” para organização do texto. 
TEXTAREA OK 
10 Referências 
Bibliográficas 
Campo de referências bibliográficas do 
texto, com ferramentas de formatação 
através de “markdown” para 
organização do texto. 
TEXTAREA OK 
11 Arquivo 
Completo 
Botão que gera arquivo. BUTTON OK 
12 Arquivo Para 
Submissão 
Botão que gera arquivo proto para 
submissão. 
BUTTON OK 
13 Limpar Botão que limpa todos os campos 
preenchidos no documento gerado pelo 
sistema. 
BUTTON Não 
conforme 
 
 
 
 
 
 
 
 
NÃO CONFORMIDADES 
 
Durante o teste foram identificados 2 (dois) campos com não-conformidades com relação ao seu 
funcionamento segundo a sua função definida. Do total de 17 (dezessete) elementos 
identificados e descritos na interface, 2 (dois) deles não apresentaram pleno funcionamento e/ou 
apresentam funcionamento parcial que pode prejudicar parte da experiência de usuário. 
 
Quantificando os dados levantados temos uma representação de 8,5% de mal funcionamento 
apresentado que serão detalhados a seguir:Elemento Problema (Issue) Gravidade 
 
 
Email (3.4) 
Campo não verifica com exatidão a validade do 
dado inserido. Se houver a entrada de um tipo de 
dado do tipo “email@.com”, por exemplo, o 
sistema não acusa o dado inválido e procede a 
geração do arquivo com o dado errado. 
 
 
Leve 
 
 
 
Limpar (13) 
 
O botão não limpa todos os campos do 
formulário, deixando campos importantes como 
“Corpo do Texto”, “Notas” e “Referências 
Bibliográficas” ainda preenchidos, causando 
provavel irritação no usuário que teria que 
apagar tudo manualmente. 
 
 
 
Leve 
 
 
 
 
 
CONCLUSÃO 
 
O sistema “SFAA – UNIP Interativa” oferece uma ferramenta simples e descomplicada na hora 
de formatar um texto não-normatizado para o formato padrão de artigos científicos. A 
ferramenta apresenta erros de validação de dados em alguns campos mas que, no final, não 
prejudicam o arquivo final e depende muito mais da forma que o usuário dispõe os dados, 
configurando portanto os problemas da interface como problemas leves que podem ser 
contornados mesmo sem a correção do sistema por parte do desenvolvedor. 
No contexto geral este trabalho apresentou com caráter de introdução a ferramenta de teste 
de software por meio de testes de caixa-preta que ajudam no desenvolvimento do software de 
maneira que se diminuam cada vez mais os erros de consistência de dados a cada ciclo de 
desenvolvimento e teste. 
 
 
 
 
 
 
 
 
 
 
 
 
ANEXO 01 
 
A Grande Muralha da China (The Great Wall of China) 
Author: John Doe – CEO – MSc. Business Intelligence 
Business Ipsum, 2003. 
 
 
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nunc euismod orci a iaculis 
euismod. Proin sit amet aliquam leo. Curabitur venenatis purus id placerat malesuada. 
Sed volutpat lobortis nulla eu maximus. Proin lacinia congue odio ut ultrices. Curabitur 
pretium molestie nunc, consectetur mattis lacus suscipit sollicitudin. Nulla vitae augue 
eros. 
Pellentesque eu felis lorem. Suspendisse ullamcorper eleifend lorem ut aliquet. Duis diam 
ex, tempus ut consequat ut, tristique quis nunc. Curabitur ut risus mauris. Aliquam 
dignissim vulputate aliquam. Donec mattis nibh ipsum, congue commodo sapien mollis 
eget. Maecenas eget fermentum arcu, et euismod nibh. Integer suscipit elit fermentum, 
tristique enim non, tempor lectus. 
Phasellus quis turpis vel orci consectetur commodo id eu turpis. Pellentesque habitant 
morbi tristique senectus et netus et malesuada fames ac turpis egestas. Curabitur finibus 
convallis purus, in rutrum tortor ultrices eu. Fusce eget viverra nibh, ac egestas odio. 
Fusce vel euismod est. Curabitur finibus ipsum vitae dignissim euismod. Nunc volutpat in 
libero at dapibus. Maecenas at massa sed purus venenatis sodales. Praesent porta ligula 
dui, quis condimentum libero consequat quis. Suspendisse sollicitudin arcu pharetra 
placerat rhoncus. Pellentesque eget tempus risus. Morbi et porta ligula. Pellentesque 
egestas sapien a turpis malesuada, vitae hendrerit libero venenatis. Praesent 
condimentum sem at condimentum faucibus. Donec bibendum interdum elit, a dictum nisi 
consectetur quis. Fusce quis neque eget eros pulvinar pharetra quis ac arcu. 
 
ANEXO 02 
 
 
 
 
 
 
 
 
 
ANEXO 3 
 
 
 
 
 
 
 
 
ANEXO 4 
 
 
 
 
 
 
 
 
 
 
 
ANEXO 5 
 
 
 
 
 
 
 
 
 
 
 
ANEXO 6 
 
 
 
 
 
 
 
 
 
 
 
ANEXO 7 
 
 
 
 
 
 
 
 
 
 
 
ANEXO 8 
 
 
 
 
 
 
 
 
 
 
ANEXO 9 
 
 
 
 
 
 
 
 
 
 
 
 
 
ANEXO 10 
 
 
 
 
 
 
 
 
 
 
 
 
REFERÊNCIA BIBLIOGRÁFICA 
 
RIBEIRO, André Luiz. Livro-texto “Engenharia de Software II”. São Paulo. 2015 
SOUZA, Luciano Soares de. Livro-texto “Projeto de Interface com o Usuário”. São Paulo. 2015.