PIM V - Analise e desenvolvimento de sistemas

Prévia do material em texto

4
UNIP
PROJETO INTEGRADO MULTIDISCIPLINAR CURSOS SUPERIORES DE TECNOLOGIA
DESENVOLVIMENTO DE UM ROTEIRO DE TESTES PARA UM SISTEMA
Pólo Jabaquara
2017
UNIP
PROJETO INTEGRADO MULTIDISCIPLINAR CURSOS SUPERIORES DE TECNOLOGIA
DESENVOLVIMENTO DE UM ROTEIRO DE TESTES PARA UM SISTEMA
Aluno: 
Curso: Analise e Desenvolvimento de Sistemas 
Semestre: 2º 
Pólo Jabaquara
2017
Folha de Aprovação
DESENVOLVIMENTO DE UM ROTEIRO DE TESTES PARA UM SISTEMA
Projeto apresentado junto ao Curso de Analise e Desenvolvimento de Sistemas da
Universidade Paulista, como requisito parcial à obtenção da Graduação.
COMISSÃO EXAMINADORA: 
______________________________ 
______________________________ 
______________________________ 
São Paulo, 13 Abril de 2017.
RESUMO
Os testes de software sempre foram considerados como uma atividade desnecessária, implicando tanto no aumento do tempo para a entrega do produto como aumento de custo. 
Na década de 80 não havia metodologia para essa atividade e os testes serviam apenas para verificar se o sistema funcionava. Atualmente a engenharia de software dispõe de todo um arcabouço de ferramentas, técnicas e práticas destinadas a esta tarefa. 
Este estudo prevê a elaboração de dez roteiros de um tipo específico de teste, chamado caixa-preta, no qual é analisado um tipo de defeito denominado de funcionalidade, que é quando o software não faz o que o usuário espera que ele faça. O roteiro seguirá os casos de teste especificados no projeto de software para formatação de artigos acadêmicos e todas as observações e verificações devem ser devidamente documentadas. 
Palavras-chave: Roteiro, teste, caixa-preta, software, metodologia.
ABSTRACT
 Software testing has always been considered as an unnecessary activity, implying both increasing the time for product delivery as a cost increase.
In the 1980s there was no methodology for this activity and the tests were only used to check if the system worked. Currently software engineering has a whole set of tools, techniques and practices for this task.
This study foresees the preparation of ten scripts of a specific type of test, called a black box, in which a type of defect called functionality is analyzed, which is when the software does not do what the user expects it to do. The script will follow the test cases specified in the software design for formatting academic articles and all observations and verifications should be properly documented.
Keywords: Script, test, black box, software, methodology.
SUMÁRIO
INTRODUÇÃO	7
TÉCNICAS DE TESTES	8
PLANEJAMENTO	9
O PROJETO	9
IMPLEMENTAÇÃO	11
EXECUÇÃO DOS TESTES	11
CASO DE TESTES 1:	12
EVIDENCIAS DO CASO DE TESTES 1 Sistema gera o artigo com o autor e todos os campos cadastrado com sucesso:	12
CASO DE TESTES 2:	13
EVIDENCIAS DO CASO DE TESTES 2	15
CASO DE TESTES 3:	16
EVIDENCIAS DO CASO DE TESTES 3	17
CASO DE TESTES 4:	18
EVIDENCIAS DO CASO DE TESTES 4	19
CASO DE TESTES 5:	20
EVIDENCIAS DO CASO DE TESTES 5	21
CASO DE TESTES 6:	22
EVIDENCIAS DO CASO DE TESTES 6	23
CASO DE TESTES 7:	26
EVIDENCIAS DO CASO DE TESTES 7	26
CASO DE TESTES 8:	29
EVIDENCIAS DO CASO DE TESTES 8	29
CASO DE TESTES 9:	31
EVIDENCIAS DO CASO DE TESTES 9	32
CASO DE TESTES 10:	33
RELATÓRIO FINAL SOBRE OS TESTES	35
RELATÓRIO DE INSPEÇÃO DE USABILIDADE	36
Heurísticas:	36
Falhas de Usabilidade Detectadas:	37
AVALIAÇÃO GLOBAL DO SISTEMA INSPECIONADO	40
CONCLUSÃO	40
REFERÊNCIAS	41
 
 
INTRODUÇÃO
O objetivo deste projeto é criar e executar roteiros de testes com o a técnica caixa-preta para auxiliar um departamento de extensão, pesquisa e pós-graduação (DEPP) de uma universidade que comprou um sistema de formatação de trabalhos e precisa dar o aceite final para a aquisição do software.
O sistema terá a principal função de formatar os artigos acadêmicos que serão submetidos, pelos autores, aos congressos e 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 o domínio das técnicas a serem aplicadas para a avaliação, pediu o auxílio do Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas para realizar essas atividades.
Para a avaliação do sistema de formatação de artigos acadêmicos foram identificados 10 (dez) casos de testes a serem executados, assim a equipe elaborou roteiros de testes de tipo caixa-preta, onde serão aplicados e gerados resultados dos testes.
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.
Testar software é uma atividade introduzida no processo de desenvolvimento de software a partir da década de 80 onde houve a elaboração de métodos formais, tornando– se uma atividade essencial ao processo de construção do produto de software.
Para entender testes de software faz–se necessário ter a clareza nos conceitos de teste e 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 atividades de validação, uma equipe inteira é responsável.
TÉCNICAS DE TESTES
As técnicas de testes de software estão divididas em duas vertentes: a especificação funcional da aplicação e a qualidade do código. A especificação funcional da aplicação está voltada aos testes de sistema e de aceitação enquanto os testes de unidade e de integração relacionam – se com os testes de código
Este projeto utilizara a técnica funcional, mais especificamente o teste de caixa preta que consiste em avaliar se o software está de acordo com as necessidades dos usuários finais, são necessários alguns artefatos para que se possa criar testes bem elaborados. Entre estes artefatos temos o documento de requisitos e pelo menos um protótipo visual das telas a serem testadas.
Com esses documentos em mãos a equipe pode iniciar as atividades de teste que estão divididas em cinco etapas bem definidas:
•	Planejamento: Consiste em determinar qual parte do sistema será testado
•	Projeto: Nesta fase são identificados os casos de teste que nada mais e do que um requisito do usuário com relação ao sistema
•	Implementação: Analisa-se cada caso de teste e elabora-se os roteiros de testes onde encontramos as descrições detalhadas dos passos para a execução do sistema, a fim de identificar os casos de teste determinados na etapa de projeto
•	Execução: executa-se os roteiros e mapeia –se os resultados
•	Verificação: Caso haja não conformidades com os requisitos do usuário, gera-se as evidencias dos testes através de prints das telas.
PLANEJAMENTO
O projeto será executado para que sirva de avaliação do PIM V referente ao Curso superior Tecnológico em Analise e desenvolvimento de Sistemas.
A técnica utilizada para 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, que verifica situações de sucesso e insucesso na execução de determinadas funcionalidadesdenominadas casos de teste.
A universidade informou 10 casos de testes os quais serão criados roteiros específicos para cada caso, executados e geradas as evidencias dos sucessos ou insucessos observados.
Ao final será gerado um relatório final apontando as possíveis falhas do sistema, auxiliando a DEPP na aceitação do Sistema. 
O PROJETO
Nesta fase vamos identificar os casos de teste informados pela DEPP e elencá-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 sobrescrito e o texto justificado com sucesso.
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ão criados testes relativos ao comportamento técnico da tela do sistema. Então, avaliaremos a tela do sistema e criaremos, para todos os campos e controles existentes, testes relacionados a: 
Validação de cada campo;
Ações em botões e links existentes; 
Mensagens exibidas pelo sistema.
Definidos os casos de testes, iniciaremos a etapa de criação de um roteiro de teste modelo para auxiliar na execução dos testes.
IMPLEMENTAÇÃO
Elaboramos 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:
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 do sistema:
CASO DE TESTES 1:
EVIDENCIAS DO CASO DE TESTES 1
Sistema gera o artigo com o autor e todos os campos cadastrado com sucesso:
 CASO DE TESTES 2:
EVIDENCIAS DO CASO DE TESTES 2
Sistema gera artigo para submissão com autor e todos os campos cadastrados com sucesso:
CASO DE TESTES 3:
EVIDENCIAS DO CASO DE TESTES 3
Sistema gera artigo completo com três autores e campos cadastrados com sucesso:
CASO DE TESTES 4:
EVIDENCIAS DO CASO DE TESTES 4
Sistema gera artigo completo mesmo com os e-mails inválidos informados:
CASO DE TESTES 5:
EVIDENCIAS DO CASO DE TESTES 5
Sistema não permite gerar artigo completo sem o cadastro do nome do(s) autor(es):
CASO DE TESTES 6:
EVIDENCIAS DO CASO DE TESTES 6
Sistema gera um artigo completo com todos os campos preenchidos com sucesso:
 
Sistema limpa os campos: Título, Título em Inglês, Autor, Titulação, Vinculo Institucional, E-mail de Contato, Resumo, Palavra Chave, Abstract e KeyWords: 
Mas não limpa os campos: Corpo de Texto, Notas e Referências Bibliográficas:
CASO DE TESTES 7:
EVIDENCIAS DO CASO DE TESTES 7
Sistema gera um artigo completo com todos os campos preenchidos com sucesso:
Sistema formata o texto em Negrito, itálico, subscrito e sobrescrito com texto justificado:
Sistema gera o arquivo com a formatação sugerida com sucesso:
CASO DE TESTES 8:
EVIDENCIAS DO CASO DE TESTES 8
Sistema gera um artigo completo com todos os campos preenchidos com sucesso:
Sistema não permitiu inserção de imagem no corpo de texto mesmo em navegadores diferentes (Chrome e Explore):
CASO DE TESTES 9:
EVIDENCIAS DO CASO DE TESTES 9
Sistema gera um artigo completo com todos os campos preenchidos com sucesso:
Sistema aceita a formatação sugerida:
Sistema gera o arquivo com a formatação sugerida:
CASO DE TESTES 10:
Para o caso de testes 10, foi elaborado um roteiro próprio seguindo as especificações solicitadas no manual, conforme tabela abaixo: 
RELATÓRIO FINAL SOBRE OS TESTES
	Utilizando os conhecimentos adquiridos nas disciplinas Engenharia de Software II e Projeto Interface com o Usuário, foi desenvolvido roteiros de testes para os 9 casos de avaliação funcional e um roteiro específico para testar o caso de testes 10, referente a interface do sistema.
	Os testes realizados demonstraram que há erros considerados cruciais ao bom desempenho do sistema tornando-o falho em diversos aspectos, por exemplo a consistência dos dados informados. Dados incorretos são facilmente aceitos pelo sistema sem retornar qualquer mensagem de erro ou de validação.
	Através dos testes, vimos que a formatação realizada pelo sistema, atende em parte a necessidade do usuário, deixando a leitura do artigo um pouco confusa e, em alguns pontos, sem diferenciação de campos, como é o caso das seções de “Corpo do Texto”. “Notas” e “Referências”, que se misturam entre si.
	No geral, os testes mostraram que o sistema é de fácil assimilação, intuitivo e muito simples de utilizar, atendendo em partes, as necessidades do usuário.
RELATÓRIO DE INSPEÇÃO DE USABILIDADE
Responsável: Vinicius Costa
Sistema avaliado: http://sfaa.unipinterativa.edu.br/pdf/
Avaliação Heurística
Heurísticas:
1. Visibilidade do estado do sistema 
A- O SFAA tem uma interface similar a sistemas de preencher formulários, ele valida os campos que tem no grupo “autor” mas ao passar um e-mail inválido o sistema avisa na hora , mas ao clicar em gerar, o sistema gerar o artigo mesmo com e-mail inválido.
B- Caso o usuário esqueça de colocar alguma parte do trabalho como referencia ou titulo, o sistema não alerta o usuário de que tais informações estão faltando.
2. Correlação entre o sistema e o mundo real 
A. Ao adicionar autores, o nome “Autor fica com um X em frente, da a impressão que o autor está sem nome, mas é para excluir o autor cadastrado, poderia ser o sinal de subtração.
3. Liberdade e controle do usuário.
A- O sistema obriga o usuário a cadastrar o e-mail de um autor, deveria somente alertar e não obrigar, tanto que o sistema aceita e-mail inválido.
B- Após gerar o artigo o sistema não tem um botão voltar para a página inicial do sistema é necessário usar o recurso do browser para fazer esse serviço.
4. Consistência e padrões
Nos campos do grupo autores quando não é inserido algum campo e clicamos em gerar, o sistema exibe um pop-up com a mensagem de que o campo não foi informado e fica em destaque, mas quando inserimos a informação obriga tória a marcação continua como se ainda estivesse com erro.
5. Prevenção de erros
A- Quando digitamos um e-mail inválido o sistema avisa que o e-mail é inválido, mas se deixarmos o e-mail inválido e clicar em gerar o sistema aceita e gera o artigo com sucesso.
B- Ao clicar no botão limpar, nem todos os campos são limpos.
6. Reconhecimento em vez de memorização
É um sistema simples de usar, mas poderia melhorar um pouco mais a interface, colocar alguns ícones, poderia ter botão para imprimir.
 7. Flexibilidade e eficiência de uso
O botão para dar zoom no texto poderiaser como do Word em que o usuário insere o tamanho da fonte, poderia ter formatação no titulo também.
8. Projeto estético e minimalista
Os pop-ups de aviso são diretos e de fácil entendimento, porem somente quando se trata do grupo dos autores, o sistema devia alertar o usuário, quando ele não coloca o titulo e os outros campos quando os mesmos ficam vazios.
9. Suporte para o usuário no reconhecimento, no diagnóstico e na recuperação de erros.
O sistema apresenta mensagens diretas e de fácil entendimento.
10. Ajuda e documentação
O sistema falha no quesito material de apoio e help, pois o mesmo não tem nenhum tipo de ajuda, mesmo o sistema sendo simples poderia ter um help com algumas informações referente ao sistema.
Falhas de Usabilidade Detectadas:
Número da falha de usabilidade: 1
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 um titulo e outras partes do trabalho.
Número da heurística violada: 8
Grau de severidade estimado: 2 (O usuário pode esquecer de colocar o titulo tanto em inglês como em português que o sistema não irá avisá-lo, tendo que o mesmo voltar refazer o processo.
Número da falha de usabilidade: 2
Localização da falha de usabilidade: Tela com arquivo gerado
Caracterização da falha de usabilidade: O sistema não tem um botão de voltar para a tela inicial.
Número da heurística violada: 3
Grau de severidade estimado: 1 (O usuário não tem o controle de voltar para a tela inicial via sistema, somente forçando a voltar via browser).
Número da falha de usabilidade: 3
Localização da falha de usabilidade: Tela com arquivo gerado
Caracterização da falha de usabilidade: O sistema não tem nenhuma opção de imprimir e nem salvar em pdf.
Número da heurística violada: 3
Grau de severidade estimado: 3 (O usuário gera o arquivo mas não tem opção para imprimir e nem salvar em um formato especifico).
Número da falha de usabilidade: 4
Localização da falha de usabilidade: Tela com arquivo gerado
Caracterização da falha de usabilidade: O sistema gera o arquivo mesmo depois de ter informado que o e-mail está invalido.
Número da heurística violada: 5
Grau de severidade estimado: 3 (O sistema gera o arquivo mesmo com o e-mail inválido, como não sabemos para que p sistema usa o e-mail, pode causar inconsistências.).
AVALIAÇÃO GLOBAL DO SISTEMA INSPECIONADO
O sistema inspecionado é, em sua forma geral, muito simples. Apresenta características básicas de funcionalidades, e, num aspecto mais amplo, é bastante intuitivo.
É voltado para estudantes, tem um visual simples e é fácil de usar, mas pode ser melhorado em aspectos de usabilidade e se faz necessário corrigir algumas falhas.
Poderia ser mais inclusivo se oferecesse uma interface para aumentar o tamanho da fonte, colocasse alguns ícones para facilitar mais o uso, colocar opções para impressão e salvar em um formato especifico.
Um ponto positivo é as opções de formatação que são bem parecidas com o word.
No geral, o site está bom. Existem pontos de melhoria, mas o site ainda assim é adequado para os seus fins, e o usuário é capaz navegar e utilizar o site com certa facilidade e usabilidade.
CONCLUSÃO
O software é todo o processo que envolve sua concepção: desenvolvimento, testes e a entrega do sistema para o cliente que, provavelmente, irá demandar cada vez mais recursos ou funcionalidades mediante novas necessidades. Com base nisso e focado em testes de caixa preta padronizados pelos alunos, foi possível mapear entradas e saídas esperadas do software, de modo a obter parâmetros que propusessem resolver problemas que surgiram após analise da versão corrente, tornando assim a curva de desenvolvimento do sistema menos acentuada com a diminuição de inconsistências que poderiam passar despercebidos pela equipe de desenvolvedores, uma vez que tais testes permitem simular com maior precisão o a linha de pensamento do usuário final, com a diferença de que todo o processo é sistematizado e documentado para uma maior absorção por parte dos analistas e programadores que poderão propor novas soluções para futuras versões do sistema.
REFERÊNCIAS
ASSOCIACAO BRASILEIRA DE NORMAS TECNICAS (ABNT). NBR ISO 9000: Sistemas de gestão da qualidade – Fundamentos e vocabulário. Rio de Janeiro, 2000a.
- Site: www.abnt.org.br - Acesso em 08/ 04/ 2017
- RIBEIRO, A. L. São Paulo: Livro texto Engenharia de Software II. UNIP INTERATIVA, São Paulo, 2016.
- Prof. LUCIANO SOARES DE – Livro texto Projeto de Interface com o Usuário – UNIP INTERATIVA. 
ISO/IEC. ISO/IEC 12207 - Software Life Cycle Processes. [S.l.], 2004
- GUERRA A. C.; COLOMBO, R. M. T. Tecnologia da informacao: qualidade de produto de software.
- KOSCIANSKI, A.; SOARES, M. S. Qualidade de software. Rio de Janeiro: Novatec, 2010 (pdf). 
- LIMA, Allyn Grey de Almeida. Padrão SQL e sua evolução. 2008 (pdf).
-PAULA FILHO, W. Engenharia de software: fundamentos, metodos e padroes. Rio de Janeiro: LTC, 2011.
-PFLEEGER, S. L. Engenharia de software: teoria e pratica. 2. ed. Sao Paulo: Prentice Hall
-PRESSMAN, R. S. Engenharia de software. Sao Paulo: McGraw Hill, 2006.
-RIOS, E.; MOREIRA, T. Testes de software. 3. ed. Sao Paulo: Alta Books, 2013.
-SOMMERVILLE, I. Engenharia de software. Sao Paulo: Pearson, 2013.
-VILAS BOAS, A. L. C. Qualidade e avaliacao de produto de software. Lavras: Ufla/Faepe. 2004
Sites 
www.iso.org - Acesso em 08/ 04/ 2017
http://www.pcs.usp.br/~pcs0409/pdfs/Teste.PDF - Acesso em 08/ 04/ 2017