PIM V

Prévia do material em texto

0 
 
UNIP INTERATIVA 
 
Projeto Integrado Multidisciplinar 
Cursos Superiores de Tecnologia 
 
 
 
 
 
 
 
 
 
 
 
 
 
DESENVOLVIMENTO DE ROTEIRO DE TESTES 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
POLO POSSE/GO 
2018 
 
1 
 
UNIP INTERATIVA 
 
Projeto Integrado Multidisciplinar 
Cursos Superiores de Tecnologia 
 
 
 
 
 
 
 
 
 
 
 
 
 
DESENVOLVIMENTO DE ROTEIRO DE TESTES 
 
 
 
Aluno: Ericsojan Soares Alves 
RA: 1729752 
Curso: Análise e Desenvolvimento em 
Sistemas 
3º Semestre 
 
 
 
 
 
 
POLO POSSE/GO 
2018 
 
2 
 
RESUMO 
 
O trabalho a ser desenvolvido vem com o propósito de desenvolver e executar um 
roteiro de testes em um sistema de formatação de artigos acadêmicos e gerar os 
resultados obtidos com o teste e ainda realizar uma inspeção de usabilidade no 
sistema por meio da técnica de avaliação heurística, concluindo com um relatório 
com os resultados obtidos. O teste de software é um processo que compõe a 
construção de um software, o mesmo tem como objetivo central demostrar 
erros/falhas, afim de que possa ser corrigidos e alcançar os resultados esperados 
pelo usuário final. O estudo aqui proposto nesse projeto, prevê a utilização da 
técnica de teste funcional, também chamada caixa-preta, que verifica a saída dos 
dados usando vários dados como entrada. Essa denominação de caixa-preta faz a 
menção de que não se é necessário saber a estrutura interna (código) do software e, 
ou seja, os testes são executados a partir de um sistema já pronto. Nesse trabalho 
serão elaborados dez roteiros de testes já especificados no projeto de software para 
formatação de artigos acadêmicos e todas as observações e verificações devem ser 
documentadas. 
 
Palavras-chave: roteiro de testes, caixa-preta e software. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
3 
 
ABSTRACT 
 
The work to be developed comes with the purpose of developing and executing a 
test script in a system of formatting academic articles and generate the results 
obtained with the test and perform a usability inspection in the system by means of 
the heuristic evaluation technique, concluding with a report with the obtained results. 
The software test is a process that composes the construction of a software, the 
same one has the central objective to demonstrate errors / failures, in order that they 
can be corrected and reach the results expected by the end user. The study 
proposed here, foresees the use of the functional test technique, also called black 
box, that verifies the output of the data using several data as input. This 
denomination of black box makes mention that it is not necessary to know the 
internal structure (code) of the software and that is the tests are executed from a 
system already ready. In this work ten test scripts will be elaborated already specified 
in the software design for formatting academic articles and all observations and 
verifications should be documented. 
 
Keywords: test script, black box and software. 
 
 
4 
 
SUMÁRIO 
 
Introdução …………………………….................……………………...……...………….. 5 
Testes de software …………………………………………………................………….. 6 
Técnicas de teste de software .................................................................................... 6 
Planejamento............................................................................................................... 7 
Projeto......................................................................................................................... 7 
Implementação............................................................................................................ 8 
Execução dos casos de teste ..................................................................................... 9 
Relatório Final sobre os testes realizados no sistema ............................................. 33 
Relatório de Inspeção de Usabilidade ...................................................................... 34 
Falhas na usabilidade detectadas ............................................................................ 36 
Avaliação Global do Sistema Inspecionado ............................................................. 40 
Conclusão ................................................................................................................. 41 
Referências Bibliográficas ........................................................................................ 42 
 
 
 
 
 
 
 
5 
 
INTRODUÇÃO 
 
Esse trabalho tem como principal objetivo desenvolver roteiro de testes, 
utilizando a os chamados testes funcionais que também são denominados testes 
caixa-preta, que segundo a proposta, serão necessários para auxiliar o 
Departamento de Extensão, Pesquisa e Pós-graduação (DEPP) de uma 
universidade. 
O DEPP solicita um sistema que possa formatar os trabalhos acadêmicos que 
serão submetidos, pelos autores, aos congressos e às revistas científicas da 
universidade. “O sistema terá a principal função de formatar os artigos acadêmicos 
que serão submetidos, pelos autores, aos congressos e às revistas científicas da 
universidade. Um artigo somente poderá ser submetido se estiver dentro das 
normas de formatação definidas pela DEPP, em formato PDF e se tiver até 42.000 
caracteres. Para ser submetido, o artigo deverá ter duas versões, uma com o nome 
dos autores e outra sem o nome dos autores (blind review). Essas duas versões 
deverão ser geradas pelo Sistema de Formatação de Artigos Acadêmicos”. 
Como o DEPP precisa avaliar e dar o aceite final no sistema, mas não tem 
domínio das técnicas a serem aplicadas para a avaliação, resolveram pedir o auxílio 
do Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas para 
realizar essas atividades. 
Para realizá-la a avaliação do sistema de formatação de trabalhos 
acadêmicos solicitada foram propostos 10 casos de testes em que será executado 
com a técnica caixa-preta e por fim serão apresentados os resultados dos testes. 
Esses testes estão inseridos nas etapas verificação e validação afim de que se 
possa chegar na qualidade do software exigido pelo usuário final. 
A atividade de testar software é essencial durante o processo de construção 
do software. É importante salientar que o processo de teste é totalmente diferente do 
processo de depuração de um programa. Os testes são realizados com o programa 
já finalizado, enquanto a depuração se realiza durante a construção do programa. 
Os testes de software são necessários e importantes devido um fator 
incentivador que é o custo. Segundo Myers (2004), quanto mais cedo for detectado 
e corrigido um defeito, menor será o custo para o projeto final. Como já foi citado 
nesse trabalho será usado o teste funcional que de acordo com as situações de 
6 
 
testes propostas, devem atestar que o software realiza fielmente o que foi solicitado 
pelo usuário, funcionando corretamente. 
 
Testes de Software 
 
Os testes de software estão incluídos nas etapas de verificação e validação 
como artifício para a garantia de qualidade do produto de software. 
Para executar as atividades de verificação e validação necessitamos definir 
uma técnica dependendo do contexto e do tempo para a elaboração do projeto. 
Os testes de software são técnicas dinâmicas usadas sobre o sistema já 
construído, podendo ser aplicadas de forma manual ou automática. 
Para entender testes de software faz-se necessário ter a clareza nos 
conceitos de testee depuração. A depuração acontece na fase de programação, 
antes dos testes através de ferramentas CASE. Os testes são realizados por 
pessoas especificas em cada etapa da concepção do produto de software, são as 
atividades de validação, uma equipe inteira é responsável. 
 
Técnicas de teste de software 
 
As técnicas de software estão divididas em duas linhas: a especificação 
funcional da aplicação e a qualidade do código. A especificação funcional da 
aplicação está direcionada aos testes de sistema e aceitação enquanto os testes de 
unidade e de integração relacionam-se com os testes de códigos. 
Este projeto utilizará a técnica de testes funcionais, especificamente o teste 
de caixa preta, que consiste em avaliar se o software final apresenta as 
necessidades propostas pelo usuário final. São necessários alguns elementos para 
se desenvolver testes elaborados e bem-sucedidos, entre os elementos tem se o 
levantamento de requisitos e pelo menos um protótipo visual de telas a serem 
testadas. 
Com esses elementos acessíveis a equipe de desenvolvedores podem iniciar 
as atividades de testes que se dividem em 5 etapas bem definidas: Planejamento, 
projeto, implementação, execução e verificação. Com isso tudo informado podemos 
começar os testes no sistema disponibilizado e solicitado pelo DEEP. 
 
7 
 
Planejamento 
 
O projeto será executado para que sirva de avaliação do PIM V referente ao 
curso superior tecnológico em Análise e desenvolvimento de Sistemas. 
A técnica que será utilizada para se avaliar se o sistema está de acordo como 
as conformidades previstas pelo Departamento de Extensão, Pesquisa e Pós-
graduação é a funcional caixa-preta. 
A universidade informou 10 casos de testes, por onde serão criados roteiros 
específicos para cada caso, executados e geradas as provas dos sucessos e 
insucessos observados. 
Ao final assim como requerido será gerado um relatório final apontando as 
possíveis falhas do sistema. 
 
Projeto 
 
 Nesta fase vamos identificar os casos de teste informados pelo DEEP e 
mostra-los abaixo: 
Caso de teste 1: Gerar um artigo completo com um autor cadastrado com sucesso 
(nenhum campo pode ficar em branco); 
Caso de teste 2: Gerar um artigo para submissão com um autor cadastrado com 
sucesso (nenhum campo pode ficar em branco); 
Caso de teste 3: Gerar um artigo completo com três autores cadastrados com 
sucesso (nenhum campo pode ficar em branco); 
Caso de teste 4: Gerar um artigo completo com três autores com e-mails inválidos 
(nenhum campo pode ficar em branco); 
Caso de teste 5: Gerar um artigo completo com três autores com os campos de 
autor em branco; 
Caso de teste 6: Gerar um artigo completo com um autor cadastrado com sucesso 
(nenhum campo pode ficar em branco) e limpar os dados sem gerar o artigo; 
Caso de teste 7: Gerar um artigo completo com um autor cadastrado com sucesso 
(nenhum campo pode ficar em branco), criando no campo “corpo do texto” um texto 
com formatação em negrito, itálico, subscrito e sobescrito e o texto justificado com 
sucesso. 
8 
 
Caso de teste 8: Gerar um artigo completo com um autor cadastrado com sucesso 
(nenhum campo pode ficar em branco), anexando no campo “corpo do texto “uma 
imagem de um arquivo com sucesso; 
Caso de teste 9: Gerar um artigo completo com um autor cadastrado com sucesso 
(nenhum campo pode ficar em branco), anexando no campo “notas” uma URL de 
um arquivo com sucesso e criando um texto formato à esquerda e em negrito; 
Caso de teste 10: Testes de interface 
Além dos casos de testes relacionados às regras de negócio será necessário 
criar os testes relativos ao comportamento técnico da tela do sistema. 
Avalie a tela do sistema e crie, para todos os campos e os controles existentes, os 
testes de interface relacionados a: 
Domínio de todos os campos; 
Validação de cada campo; 
Ações em botões e links existentes; 
Mensagens exibidas pelo sistema. 
 
Implementação 
 
Elaborei um roteiro de testes com as exigências necessárias as execuções 
dos testes, comtemplando a condição inicial, os passos a serem executados, dados 
de entrada, resultado esperado, resultado real e a data de realização como podemos 
visualizar na tabela abaixo: 
 
Caso de teste: 
Responsável: 
Procedimento Inicial: 
 
 
 
 
 
 
 
 
9 
 
EXECUÇÃO DOS TESTES 
 
Abaixo estão inseridos os roteiros de testes dos casos de 1 a 10 com os 
dados utilizados na verificação bem como as evidências de sua execução no 
ambiente de sistema: 
 
Caso de teste 1 
 
 
 
 
 
 
 
 
 
10 
 
Evidências do caso de teste 1 
 
O sistema gera o artigo com o autor e todos os campos cadastrados com sucesso: 
 
 
 
 
11 
 
Caso de teste 2 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
12 
 
Evidências do caso de teste 2 
 
Sistema gera artigo para submissão com o autor e todos os campos 
cadastrados com sucesso: 
 
 
 
 
13 
 
Caso de teste 3 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
14 
 
Evidências do caso de teste 3 
 
Sistema gera artigo completo com três autores e campos cadastrados com sucesso: 
 
 
 
 
15 
 
Caso de teste 4 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
16 
 
Evidências do caso de teste 4 
 
Sistema gera artigo completo mesmo com e-mails inválidos informados: 
 
 
 
 
 
 
17 
 
Caso de teste 5 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
18 
 
Evidências do caso de teste 5 
 
Sistema não permite gerar artigo completo sem o cadastro do nome do autor: 
 
 
 
 
 
 
 
 
 
 
 
 
 
19 
 
Caso de teste 6 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
20 
 
Evidências do caso de teste 6 
 
Sistema gera um artigo completo com todos os campos preenchidos com sucesso: 
 
 
 
 
 
- 
 
 
 
 
 
21 
 
Sistema limpa os campos: Título, Título em inglês, Autor, Titulação, Vínculo 
Institucional, E-mail de contato, Resumo, Palavra-Chave, Abstract e KeyWords: 
 
 
 
 
 
 
22 
 
- Mas não limpa os campos: Corpo de texto, Notas e Referências Bibliográficas: 
 
 
 
 
23 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
24 
 
Caso de teste 7 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
25 
 
Evidências do caso de teste 7 
 
Sistema gera um artigo completo com todos os campos preenchidos com sucesso: 
 
- 
 
 
 
 
26 
 
Sistema formata o texto em Negrito, itálico, subscrito e sobescrito com texto 
justificado: 
 
 
 
Sistema gera o arquivo com formatação sugerida com sucesso: 
 
 
27 
 
Caso de teste 8 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
28 
 
Evidências do caso de teste 8 
 
Sistema gera um artigo completo com todos os campos preenchidos com sucesso: 
 
 
 
 
 
 
 
 
 
 
 
 
29 
 
Sistema não permitiu a inserção de imagem no corpo de texto: 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
30 
 
Caso de teste 9 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
31 
 
Evidências do caso de teste 9 
 
- Sistema gera um artigo completo com todos os campos preenchidoscom sucesso: 
 
 
Sistema aceita a formatação sugerida: 
 
 
 
32 
 
Caso de teste 10 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
33 
 
RELATÓRIO FINAL SOBRE OS TESTES REALIZADOS NO SISTEMA 
 
Usando dos conhecimentos adquiridos nas disciplinas que envolvem esse 
projeto proposto (Projeto Interface com o Usuário e Engenharia de Software II), 
foram realizados os testes funcionais para os 10 casos de testes elencados pela 
universidade. 
Sobre os testes realizados ficou demonstrado e observado que existem 
erros/falhas considerados graves para o bom desempenho do sistema, fazendo com 
que o mesmo se torne falho em diversos aspectos, um desses pontos observados 
foi à consistência dos dados informados. O sistema aceita dados incorreto 
facilmente sem retornar qualquer mensagem de erro ou validação. 
Os testes mostraram que a formatação feita pelo sistema, satisfaz em parte a 
necessidade o usuário, a leitura do usuário acaba ficando confusa e, em alguns 
pontos, sem diferenciação de campos, como é o caso dos campos “Notas, Corpo do 
Texto e Referências Bibliográficas”, que acabam se misturando, causando certa 
confusão de informação. 
Enfim, no geral os testes deixaram a mostra que o sistema é de fácil 
assimilação, intuitivo e muito simples de utilizar, atendendo em partes, as 
necessidades do usuário. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
34 
 
RELATÓRIO DE INSPEÇÃO DE USABILIDADE 
 
Responsável: Ericsojan Soares Alves 
Sistema avaliado: http://sfaa.u nipinterativa.edu.br/pdf/ 
Avaliação Heurística 
 
1 – Visibilidade do estado do sistema 
 O SFAA da UNIP tem uma interface semelhante a sistemas de preencher 
formulários, ele faz a validação dos campos que tem no grupo “autor”, porém 
ao inserir um E-mail inválido o sistema acusa no mesmo momento, mas ao 
clicar em gerar, o sistema mesmo assim gera o artigo com E-mail inválido. 
 Se o usuário esquecer-se de colocar alguma parte do trabalho como 
referência ou título, o sistema não faz nenhuma menção de quais informações 
estão em falta. 
 
2 – Correlações entre o sistema e o mundo real 
Ao adicionar autores, o nome “autor”, fica com um X em frente, dando a 
impressão que o não consta nome do autor, mas é para excluir o autor cadastrado, 
poderia ser o sinal de subtração. 
 
3 – Liberdade e controle do usuário 
 O sistema coloca como obrigação ao usuário fazer o cadastro de E-mail do 
autor, poderia não ser uma obrigação e sim opcional, até porque o sistema 
aceita E-mail inválido. 
 Após gerar o artigo o sistema não possui um botão com a função de voltar a 
página inicial do sistema, com isso é preciso usar os recursos do browser 
para realizar essa tarefa. 
 
4 – Consistências e padrões 
Nos campos do grupo do autor, quando não se insere algum campo e clica-se 
para gerar, o sistema exibe um pop-up com a mensagem de que o mesmo não foi 
informado e fica destacado, mas quando é inserido obrigatoriamente fica marcado e 
continua como se ainda persististe o erro. 
 
35 
 
5 – Prevenção de erros 
 Quando digita-se um E-mail inválido o sistema avisa o E-mail é inválido, mas 
se deixar o campo com o E-mail inválido mesmo assim clicando em gerar o 
sistema aceita e gera o artigo com sucesso. 
 Mesmo clicando no botão limpar, nota-se que nem todos os campos são 
limpos. 
 
6 – Reconhecimento em vez de memorização 
É um sistema fácil de se usar, mas poderia haver inclusão de alguns ícones, 
como exemplo de imprimir, além de melhorar a um pouco mais a interface. 
 
7 – Flexibilidade e eficiência de uso 
Poderia ter a possibilidade de formatar o título. 
 
8 – Projeto estético e minimalista 
O sistema deveria avisar o usuário quando não é colocado o título e os 
outros campos quando estão vazios, mas os pop-ups de aviso são de fácil 
entendimento. 
 
9 – Suporte para o usuário no reconhecimento, no diagnostico e na recuperação de 
erros 
O sistema gera mensagens diretas e de fácil entendimento. 
 
10 – Ajuda e documentação 
Nesse quesito o sistema falha, não existe nenhum tipo de ajuda, apesar de 
ser um sistema simples, deveria haver um help do mesmo para algumas situações 
do sistema. 
 
 
 
 
 
 
 
36 
 
FALHAS NA USABILIDADE DETECTADAS 
 
1ª Falha de usabilidade 
Localização da falha de usabilidade: Tela inicial 
Caracterização da falha de usabilidade: O sistema não avisa ao usuário que ele 
não informou o título e outros campos. 
Número da Heurística violada: 8 
Grau de severidade estimado: 2 (O usuário esquecendo de colocar o título em 
português ou inglês o sistema não avisa, fazendo com que o usuário tenha que 
refazer o processo). 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
37 
 
2º Falha de usabilidade 
Localização: Tela com arquivo gerado 
Caracterização da falha: O sistema não tem um botão de voltar para a tela inicial. 
Número da heurística violada: 3 
Grau de severidade: 1 (O usuário não possui o controle de voltar para a tela inicial 
pelo sistema, somente se usar o comando do browser ). 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
38 
 
3ª falha de usabilidade 
Localização: Tela com arquivo gerado 
Caracterização da usabilidade: O sistema não possui nenhuma opção para 
imprimir e nem salvar o pdf. 
Número da heurística violada: 3 
Grau de severidade estimado: 3 (O usuário gera o artigo porém não tem a 
possibilidade de imprimir e nem de salvar o pdf gerado). 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
39 
 
4ª falha de usabilidade 
Localização: Tela com arquivo gerado 
Caracterização da usabilidade: Mesmo o sistema informando que o e-mail inserido 
é inválido, acaba gerando o arquivo normalmente. 
Número da heurística violada: 5 
Grau de severidade estimado: 3 (O sistema gera arquivo com e-mail inválido, 
podendo gerar inconsistências dependendo do que for usado no sistema 
 
 
 
 
 
 
 
 
 
40 
 
AVALIAÇÃO GLOBAL DO SISTEMA INSPECIONADO 
 
O sistema trabalho e verificado, é de forma geral, em simples, com 
características e funções básicas. É voltado para um público alvo de estudantes, 
possui um visual simples e com funcionalidade fácil, porém se há a necessidade de 
melhorias na usabilidade e se fazer a correção de algumas falhas encontradas. 
Necessita basicamente de inclusão de alguns ícones para facilitar o uso, 
como exemplo pode se citar, pode haver a colocação de opções de impressão e 
salvar em um formato de pdf ou outro específico. 
No geral o sistema ou site é bom, como foi relatado há a necessidade sim de 
melhorias, mas para o que se propõe o site é adequado para sua finalidade, 
proporcionando ao usuário uma navegação e utilização com relativa facilidade e 
usabilidade. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
41 
 
CONCLUSÃO 
 
O desenvolvimento de um software envolve muitas etapas e uma delas é a 
fase de testes, com base nisso e focado em testes funcionais também chamados de 
testes caixa-preta, foi possível fazer um mapeamento de entrada e saída de dados e 
informações. Com isso foi possível obter parâmetros que possibilitassem resolver 
problemas que durante o desenvolvimento do projeto, a fim de se diminuir ao 
máximo as inconsistências que poderiam passar despercebidas pela equipe de 
desenvolvedores. Esses testes feitos no roteiro proposto permitem simular com 
maior precisão a linha de pensamento do usuário final, coma diferença de que todo 
o processo é documentado e sistematizado para uma maior absorção por parte dos 
analistas e programadores que poderão propor novas soluções para futuras versões 
do sistema desenvolvido. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
42 
 
REFERÊNCIAS 
 
RIOS, E.; MOREIRA, T. Testes de software. 3. ed. São Paulo: Alta Books, 2013 
 
SOMMERVILLE, I. Engenharia de software. Sao Paulo: Pearson, 2013. 
 
https://www.portalgsti.com.br/testes-de-software/sobre/ 
 
https://pt.wikipedia.org/wiki/Teste_de_caixa-preta 
 
http://app.crowdtest.me/entenda-teste-caixa-preta-garante-qualidade-software/