Baixe o app para aproveitar ainda mais
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/
Compartilhar