PIM V

Prévia do material em texto

UNIP INTERATIVA
 Projeto Integrado Multidisciplinar
 Cursos Superiores de Tecnologia- PIM V
DESENVOLVIMENTO DE UM ROTEIRO DE TESTES PARA UM SISTEMA
Unip Polo Paulista
 2018.
UNIP INTERATIVA
 Projeto Integrado Multidisciplinar
 Cursos Superiores de Tecnologia- PIM V
DESENVOLVIMENTO DE UM ROTEIRO DE TESTES PARA UM SISTEMA
Hendrel Yukimide de Oliveira
R.A- 1774005
Curso: Analise e Desenvolvimento de Sistemas
2º Semestre de 2018.
Unip Polo Paulista
 2018.
RESUMO
 
O projeto deve ser executado para que sirva de avaliação do PIM-V referente ao Curso superior Tecnológico em Analise e desenvolvimento de Sistemas, que será executado com base no aprendizado adquirido, conforme estudos das disciplinas de Engenharia de Software e Projeto de Interface com o usuário.
O trabalho será realizado um teste de caixa preta de um sistema de formatação de artigos acadêmicos, com objetivo de verificar sua correção em relação ao comportamento esperado e mediante as falhas e erros serão registrados e reportados no relatório final.
 
Palavras-chave: Engenharia de Software, teste caixa preta.
 
 
ABSTRACT
The project must be executed to serve as an evaluation of the PIM-V for the Technological Superior Course in Systems Analysis and Development, which will be executed based on the acquired learning, according to studies of the disciplines of Software Engineering and User Interface Design . The work will be carried out a black box test of a system of formatting of academic articles, with the objective of verifying its correction in relation to the expected behavior and through the failures and errors will be recorded and reported in the final report.
 
Keywords: Software Engineering, Black-box Testing.
SUMÁRIO
1- INTRODUÇÃO	6
2- TESTES DE SOFTWARE	7
2.1 Técnicas de Teste de Software	7
3-PLANEJAMENTO	8
4 - PROJETO	9
5- IMPLEMENTAÇÃO	10
6-EXECUÇÃO	11
Caso de teste 1:	11
Caso de teste 2:	12
Caso de teste 3:	13
Caso de teste 4:	14
Caso de teste 5:	15
Caso de teste 6:	16
Caso de teste 7:	17
Caso de teste 8:	18
Caso de teste 9:	19
Caso de teste 10:	20
Caso de teste 10.1:	21
RELATÓRIO FINAL	22
CONCLUSÃO	23
REFERÊNCIAS	24
	
	
	
1- 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. 
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 elaborei roteiros detestes de tipo caixa-preta, onde serão aplicados e gerados resultados dos testes.
	 
 
2- TESTES DE SOFTWARE
Os testes de software estão incluídos nas etapas de verificação e validação como artificio para a garantia de qualidade do produto de software. Técnica dependendo do contexto e do tempo para a elaboração do projeto. 
Software são técnicas dinâmicas usadas sobre o sistema já construído, podendo serem software a partir da década de 80 onde houveram 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 concepção do produto de software, são atividades de validação, uma equipe inteira é responsável.
2.1 Técnicas de Teste de Software
 As técnicas de testes de software estão divididas em dois objetivos:
 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 se relacionam 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 possam 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 concordância nas etapas definidas:
Planejamento: Consiste em determinar qual ponto do sistema será testado 
Projeto: Nesta fase são apresentados os casos de teste que nada mais e do que um requisito do utilizador com relação ao sistema. 
Implementação: Analisa cada caso de teste e elaboram os roteiros detestes em que 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: executam-se os roteiros e estrutura os resultados 
Verificação: Caso tenha não conformidades com os requisitos do usuário, que gera as evidencia dos testes através de prints das telas. Com essas informações podemos iniciar os testes no sistema disponível no endereço solicitado pelo DEEP. Cada parte está descrita e implantadas nas seções seguintes.
 
3-PLANEJAMENTO
O projeto deve 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 e a funcional caixa-preta que verifica situações de sucesso e insucesso na execução de determinadas funcionalidades denominadas casos de teste. A universidade informou 10 casos de testes os quais serão criados roteiros específica para cada caso, executados e geradas as evidencias com sucessos ou insucesso observados. Será gerado um relatório final apontando as possíveis falhas do sistema, auxiliando a DEPP na aceitação do Sistema.
4 - PROJETO
Nesta fase iremos identificar os casos de teste informados pela DEPP como mostra 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 comsucesso (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
 
5- IMPLEMENTAÇÃO
Iniciei através de um roteiro de testes, com as exigências necessárias, as execuções dos testes, contemplando a condição inicial, os passos a serem realizados, dados de entrada, resultado previsto, resultado real e a data de realização como podemos visualizar na tabela abaixo:
6-EXECUÇÃO
Abaixo estão inseridos os roteiros de testes dos casos de 1 a 10 com os dados utilizados na verificação:
Caso de teste 1:
Ao clicar no botão Gerar, o arquivo é exibido na própria janela do navegador, na mesma aba do sistema, verificando-se a ausência de um botão ou link para download do arquivo. Sugere se que o arquivo seja gerado me aberto em aba separada, permitindo ao usuário visualizá-lo no próprio browser, mas mantendo a tela do sistema aberta, podendo também optar por salvá-lo em sua máquina, no formato PDF.
http://sfaa.unipinterativa.edu.br/pdf/
Caso de teste 2:
O arquivo foi gerado com sucesso. Reitera-se aqui a sugestão de melhoria feita no caso anterior.
http://sfaa.unipinterativa.edu.br/pdf/
Caso de teste 3:
O arquivo foi gerado com sucesso, apresentando a identificação dos três autores cadastrados. Reitera-se aqui a sugestão de melhoria feita nos casos de teste 1 e 2. 
http://sfaa.unipinterativa.edu.br/pdf/
Caso de teste 4:
 O sistema exibe mensagem de alerta no caso do não preenchimento ou do preenchimento incorreto (endereço inválido) do campo de e-mail, destacando-o em vermelho. Observa-se, no entanto, que o sistema considera inválido o endereço de e-mail somente se este não contiver o caractere @ (arroba), ou seja, qualquer endereço inserido, ainda que com formato incorreto, é considerado válido pelo sistema, desde que o sinal @ (arroba) esteja presente. Outra observação a ser feita é que, o exposto acima somente aplica-se ao campo de e-mail referente ao primeiro autor cadastrado, ou seja, somente este é de preenchimento obrigatório. O não preenchimento dos e-mails dos demais autores ou seu preenchimento com a inserção de dados incorretos não gera nenhuma mensagem de erro tampouco impede que o sistema de prossiga com o processo de geração do arquivo. Sugere-se a implementação de mais critérios que permitam ao sistema identificar um endereço de e-mail inválido, não permitindo a continuidade do processo enquanto não for inserido um dado no formato correto, sendo também necessário que este comportamento ocorra para os demais autores cadastrados.
http://sfaa.unipinterativa.edu.br/pdf/
Caso de teste 5:
Observou-se que as regras de validação dos campos referentes ao primeiro autor não se aplicam aos demais autores adicionados. Sugere-se a aplicação das mesmas regras de validação para todos os autores cadastrados.
http://sfaa.unipinterativa.edu.br/pdf/
Caso de teste 6:
O sistema não limpou todos os campos do formulário. Os campos “Corpo do texto”, “Notas” e “Referências Bibliográficas” não são apagados.
http://sfaa.unipinterativa.edu.br/pdf/
 
Caso de teste 7:
O sistema funcionou satisfatoriamente, gerando o artigo com a formatação previamente configurada.
http://sfaa.unipinterativa.edu.br/pdf/
Caso de teste 8:
O sistema não dispõe de ferramenta para inserção de imagens previamente salvas no computador do usuário. Ao tentar inserir uma imagem disponível na web, apresenta falha, não exibindo a imagem, mas tão somente sua URL. Sugere-se a implementação de um botão na barra de ferramentas do campo “Corpo do texto” que permita inserir arquivos de imagens online ou a partir da máquina utilizada pelo usuário, da forma similar aos processadores de textos como o Word ou Write. Outra forma seria possibilitar o acesso direto do sistema à área de transferência do computador, proporcionando mais agilidade no processo ao permitir que o usuário realize a ação por meio dos comandos de copiar e colar ou simplesmente arrastando e soltando o objeto.
http://sfaa.unipinterativa.edu.br/pdf/
Caso de teste 9:
Ao gerar o artigo completo, o sistema exibe no campo “Notas” o texto formatado conforme pedido e o endereço do arquivo externo em PDF, porém este não se encontra formatado como um link, ou seja, para ter acesso ao seu conteúdo, faz-se necessário copiar a URL e colar na barra de endereços do navegador, em uma aba à parte. Sugere-se a correção do problema fazendo com que, no arquivo gerado, o endereço inserido esteja sensível ao mouse e que, ao clicar sobre ele, o documento seja aberto em aba separada, permitindo ao usuário mais praticidade para realizar a consulta.
Caso de teste 10:
Caso de teste 10.1:
Observou-se que o sistema não oferece proteção contra entrada de dados não previstos, os quais, tratados de maneira inadequada, causam problemas nas etapas seguintes do processamento. Sugere-se a devida correção das instabilidades relativas ao comportamento da interface, realizando uma verificação das regras de validação de cada campo, de maneira a não permitir a entrada de dados fora do formato especificado, com quantidade de caracteres além do limite estabelecido, bem como verificar se os campos com indicação de obrigatoriedade estão sendo bloqueados.
RELATÓRIO FINAL 
Este projeto teve o propósito de elaborar e executar um roteiro de testes para um sistema de formatação de artigos acadêmicos, desenvolvido por uma empresa contratada para este fim, para o DEPP (Departamento de Extensão Pesquisa e Pós-Graduação) da Universidade Paulista. 
A partir da aplicação da técnica de testes funcionais ou “caixa-preta”, foi realizada a análise das respostas do sistema frente às entradas de dados propostos nos roteiros e casos de testes, assim como das funcionalidades, da interface e de sua interatividade como o usuário. 
Ao longo do ciclo de testes, em função dos problemas identificados, a equipe aponta as diversas melhorias a serem implementadas, a fim de garantir que todos os requisitos solicitados estejam presentes no produto final e que este atenda, na sua totalidade, as funções que lhe foram atribuídas.
CONCLUSÃO 
Conclui-se, do presente trabalho, que o processo de desenvolvimento de software demanda muito mais do que o simples conhecimento de uma linguagem de programação, abrangendo um conjunto de atividades a serem executadas de forma planejada a partir da utilização de teorias, métodos, técnicas e ferramentas adequadas que visam a criação de um produto que contenha as características que lhe confiram a capacidade de atender as necessidades dos usuários finais. Os conhecimentos adquiridos por meio da disciplina proposta para a elaboração deste projeto possibilitou uma visão abrangente do conceito de qualidade de software e da importância da aplicação dos seus requisitos, objetivando a melhoria dos processos de desenvolvimento, minimizando custos e retrabalho e possibilitando a obtenção de resultados positivos e cada vez mais alinhados com as expectativas e com a satisfação da equipe e do cliente. A elaboração e aplicação de um roteiro de testes do tipo “caixa-preta” para realizar a verificação e validação de um sistema, possibilitou conhecer na prática a importância do trabalho desenvolvido por controle daquilo que é produzido, e, ao mesmo tempo, uma conscientização sobre a necessidade da qualidade, mediante a exposição das vantagens proporcionadas pela aplicação de metodologias de desenvolvimento de softwares fundamentadas em parâmetros qualitativos.
REFERÊNCIAS
 Figuras 1 a 10: Imagens de tela do sistema, disponível em: http://sfaa.unipinterativa.edu.br/pdf/. (acessado entre os dias 29 e 31de março de 2018).
 Textuais: 
SOMMERVILLE, I. Engenharia de software. São Paulo: Pearson, 2011. PRESSMAN, R. S. Engenharia de software: uma abordagem profissional. São Paulo: McGraw-Hill, 2011. RIBEIRO, A. L. Engenharia de software II. São Paulo: Editora Sol, 2017.