Baixe o app para aproveitar ainda mais
Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original
UNIP INTERATIVA Projeto Integrado Multidisciplinar Curso: Análise e desenvolvimento de sistemas PROJETO DE UM ROTEIRO DE TESTES CAIXA-PRETA PARA UM SISTEMA DE FORMATAÇÃO DE ARTIGOS ACADÊMICOS. Polo Unip - Paraisópolis (MG) 2019 UNIP INTERATIVA Projeto Integrado Multidisciplinar Curso: Análise e desenvolvimento de sistemas PROJETO DE UM ROTEIRO DE TESTES CAIXA-PRETA PARA UM SISTEMA DE FORMATAÇÃO DE ARTIGOS ACADÊMICOS. Edgar de Oliveira – RA 1822238 Fábio Luiz de Melo – RA 1816984 Gustavo Cristiano Ferreira – RA 1866828 Arthur Henrique B. C. Gerino – RA 1807504 Curso: Análise e desenvolvimento de sistemas Semestre: 3º Semestre Polo Unip - Paraisópolis (MG) 2019 RESUMO A Engenharia de software tem como objetivo definir as especificações, métodos para o desenvolvimento e manutenção do software. Dentre suas especificações estão os testes, neste trabalho iremos abordar o teste caixa preta. Iremos abordar o teste seguindo dez roteiros de teste previamente estabelecidos. Como objetivo iremos gerar os resultados com o teste e também, realizar uma inspeção de usabilidade no sistema por meio da técnica de avaliação heurística e apresentar um relatório com os resultados. Palavras-chave: engenharia de software, teste, validação, caixa preta. ABSTRACT Software Engineering aims to define the specifications, methods for software development and maintenance. Among its specifications are the tests, in this project we will address the black box test. We will approach the test following ten previously established test scripts. As an objective we will generate the results with the test and also, perform a usability inspection in the system through the heuristic evaluation technique and present a report with the results. Keywords: software engineering, testing, validation, black box. SUMÁRIO 1 INTRODUÇÃO .......................................................................................................... 6 2 PROJETO ................................................................................................................... 7 3 OBJETIVO ................................................................................................................. 7 4 TESTE CAIXA PRETA ............................................................................................ 7 4.1 DEFINIÇÃO ................................................................................................................... 7 4.2 CASOS DE TESTES ......................................................................................................... 7 4.3 EXECUÇÃO DOS TESTES ............................................................................................... 8 4.3.1 Caso de teste 01 ........................................................................................................... 8 4.3.2 Caso de teste 02 ........................................................................................................... 9 4.3.3 Caso de teste 03 ......................................................................................................... 10 4.3.4 Caso de teste 04 ......................................................................................................... 10 4.3.5 Caso de teste 05 ......................................................................................................... 11 4.3.6 Caso de teste 06 ......................................................................................................... 13 4.3.7 Caso de teste 07 ......................................................................................................... 13 4.3.8 Caso de teste 08 ......................................................................................................... 15 4.3.9 Caso de teste 09 ......................................................................................................... 15 4.3.10 Caso de teste 10 ......................................................................................................... 16 4.3.10.1 Especificações da interface ...................................................................................... 16 4.3.10.2 Especificações da mensagem a ser exibida ............................................................. 17 4.3.10.3 Testes funcionais da interface ................................................................................. 17 4.3.10.4 Avaliação heurística de usabilidade da interface .................................................. 18 4.3.10.5 Relatório de avaliação .............................................................................................. 20 5 CONCLUSÃO .......................................................................................................... 20 REFERÊNCIAS ....................................................................................................... 22 6 1 INTRODUÇÃO O teste de software não se trata de um assunto recente, contudo, no mercado atual de desenvolvimento de softwares, muitos fornecedores desenvolvem sistemas sem uma metodologia voltada à qualidade. Na maioria das vezes, o custo com o teste é uma das principais justificativas para não aplicar métodos visando obter um software com qualidade. Porém, isso é uma inverdade. O custo com a manutenção e o retrabalho será muito maior. Segundo Pressman, este custo pode chegar a 100 vezes mais nos projetos que não utilizaram metodologias de testes. Com a evolução no desenvolvimento de softwares, diversos métodos de testes surgiram. A primeira conhecida, foi no fim da década de 1970, desenvolvida por Jim McCall para o Departamento de Defesa, ela foi definida por um conjunto de características internas e externas de um software, sendo o primeiro modelo de qualidade a ser divulgado e utilizado. Iremos descrever, neste trabalho, um roteiro de testes caixa-preta para um sistema de formatação de artigos acadêmicos e gerar os resultados com o teste, conforme os casos de testes definidos no contexto do trabalho. Também, realizar uma inspeção de usabilidade no sistema por meio da técnica de avaliação heurística e apresentar um relatório com os resultados. No primeiro capítulo contêm a introdução do trabalho. No segundo e terceiro capítulo trazemos a descrição e objetivos deste trabalho. Depois, no quarto capítulo iremos abordar o teste caixa preta aplicado no sistema, para identificação de possíveis problemas na programação do sistema, assim como validar a interface do sistema seguindo as heurísticas apresentadas por Jakob Nielsen. Por fim teremos as considerações finais e referências bibliográficas utilizadas. 7 2 PROJETO O projeto consiste em criar um roteiro de testes caixa-preta para um sistema de formatação de artigos acadêmicos e realizar uma inspeção de usabilidade no sistema por meio da técnica de avaliação heurística. Os testes deverão ser aplicados no sistema, online, armazenado em http://sfaa.unipinterativa.edu.br/pdf/. 3 OBJETIVO O trabalho tem como objetivo obter os resultados com o teste do teste caixa preta para casa um dos casos de teste definidos, assim como apresentar um relatório com os resultados da inspeção de usabilidade seguindo os parâmetros pré- estabelecidos. 4 TESTE CAIXA PRETA 4.1 Definição Teste de caixa-preta é um teste de software para verificar a saída dos dados usando entradas de vários tipos sem a verificação da codificação feita pelo programador, daí vem o nome caixa preta. Tais entradas não são escolhidas conforme a estrutura do programa. Tem como base as especificações levantadas no início do projeto. 4.2 Casos de testes Os casos de testes são condições utilizadas no teste do software, visando garantir a qualidade, de acordo com as especificações de casos de uso e o protótipo de telas. Tem como objetivo identificar os cenários de sucesso, e insucessos que podem acontecer na utilização do software. Os casos de testes definidos neste projeto foram os seguintes: Quadro 1 – Casos de testes definidos para este trabalho Nº Descrição 01 Gerar um artigo completo com um autor cadastrado com sucesso (nenhum campo pode ser branco). 02 Gerar um artigo para submissão com um autor cadastrado com sucesso (nenhum campo pode ser branco). 8 03 Gerar um artigo completo com três autores cadastrados com sucesso (nenhum campo pode ser branco). 04 Gerar um artigo completo com três autores com e-mails inválidos (nenhum campo pode ser branco). 05 Gerar um artigo completo com três autores com os campos de autor em branco. 06 Gerar um artigo completo com um autor cadastrado com sucesso (nenhum campo pode ser branco) e limpar os dados sem gerar o artigo. 07 Gerar um artigo completo com um autor cadastrado com sucesso (nenhum campo pode ser branco), criando no campo “corpo de texto” um texto com trechos formatados em negrito, itálico, subscrito, sobrescrito e com texto justificado com sucesso. 08 Gerar um artigo completo com um autor cadastrado com sucesso (nenhum campo pode ser branco), anexando no campo “corpo de texto” uma imagem de um arquivo com sucesso. 09 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 formatado à esquerda e em negrito. 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. 4.3 Execução dos testes 4.3.1 Caso de teste 01 Quadro 2 - Resultado caso de teste 01 Caso de teste 01 Objetivo Gerar um artigo completo com um autor cadastrado com sucesso (Nenhum campo pode ser branco) Passos para o teste Preencher todos os campos, clicar no botão “Gerar” na sessão “Arquivo Completo” Resultado Com todos campos preenchidos o arquivo foi gerado com sucesso, conforme Figura 01. Evidências Figura 01 – Resultado do caso de teste 01 9 Fonte: Captura de tela do sistema testado 4.3.2 Caso de teste 02 Quadro 3 - Resultado caso de teste 02 Caso de teste 02 Objetivo Gerar um artigo para submissão com um autor cadastrado com sucesso (Nenhum campo pode ser branco) Passos para o teste Preencher todos os campos, clicar no botão “Gerar” na sessão “Arquivo para submissão (blind review)” Resultado Com todos campos preenchidos o arquivo foi gerado com sucesso, porém em nenhum local foi incluído os dados do autor, conforme Figura 02. Evidências Figura 02 – Resultado do caso de teste 02 Fonte: Captura de tela do sistema testado 10 4.3.3 Caso de teste 03 Quadro 4 - Resultado caso de teste 03 Caso de teste 03 Objetivo Gerar um artigo completo com três autores cadastrados com sucesso (Nenhum campo pode ser branco) Passos para o teste Preencher todos os campos, clicar no botão “Gerar” na sessão “Arquivo Completo” Resultado Com todos campos preenchidos o arquivo foi gerado com sucesso, com todos os dados informados para os três autores, conforme Figura 02. Evidências Figura 03 – Resultado do caso de teste 03 Fonte: Captura de tela do sistema testado 4.3.4 Caso de teste 04 Quadro 3 - Resultado caso de teste 04 Caso de teste 04 Objetivo Gerar um artigo completo com três autores com e-mails inválidos (Nenhum campo pode ser branco) Passos para o teste Preencher todos os campos, incluindo no e-mail um valor inválido para tal campo, por exemplo: “teste erro” e clicar no botão “Gerar” na sessão “Arquivo Completo” Resultado Ao preencher com o valor incorreto o e-mail foi exibido uma caixa de diálogo informando que o e-mail é inválido e mostrou um alerta visual, de cor vermelha, entorno do campo, conforme figuras 04 e 05. No entanto, esta validação só aconteceu para o primeiro autor, nos demais não houve validação. Conforme Figura 06. Evidências Figura 06 – Resultado 3 do caso de uso 04 11 Fonte: Captura de tela do sistema testado Figura 05 – Resultado 2 do caso de uso 04 Fonte: Captura de tela do sistema testado Figura 06 – Resultado 3 do caso de uso 04 Fonte: Captura de tela do sistema testado 4.3.5 Caso de teste 05 Quadro 6 - Resultado caso de teste 05 Caso de teste 05 Objetivo Gerar um artigo completo com três autores com os campos de autor em branco. Passos para o teste Preencher todos os campos, exceto os três campos “autor” e clicar no botão “Gerar” na sessão “Arquivo Completo” Resultado Ao os demais campos e clicar em gerar o sistema exibiu um diálogo informando que o campo autor deveria ser informado, confirme Figura 07, e mostrou um alerta visual, de cor vermelha, entorno do campo, conforme Figura 08. No entanto, esta validação só aconteceu para o primeiro autor, nos demais não houve validação. Conforme Figura 09. Evidências Figura 09 – Resultado 1 do caso de teste 05 12 Fonte: Captura de tela do sistema testado Figura 08 – Resultado 2 do caso de teste 05 Fonte: Captura de tela do sistema testado Figura 09 – Resultado 3 do caso de teste 05 Fonte: Captura de tela do sistema testado 13 4.3.6 Caso de teste 06 Quadro 7 - Resultado caso de teste 06 Caso de teste 06 Objetivo Gerar um artigo completo com um autor cadastrado com sucesso e limpar os dados sem gerar o artigo. (Nenhum campo pode ser branco) Passos para o teste Preencher todos os campos, com um autor e clicar no botão “Limpar”. Resultado Ao clicar em limpar, todos os campos foram limpos, com exceção dos campos: “Corpo do texto”, “Notas” e “Referências bibliográficas”. Evidências Figura 10 – Resultado caso de teste 06 Fonte: Captura de tela do sistema testado 4.3.7 Caso de teste 07 Quadro 8 - Resultado caso de teste 07 Caso de teste 07 Objetivo Gerar um artigo completo com um autor cadastrado com sucesso, criando no campo “corpo de texto” um texto com trechos formatados em negrito, itálico, subscrito, sobrescrito e com texto justificado com sucesso (Nenhum campo pode ser branco). Passos para o teste Preencher todos os campos e no campo “corpo de texto” incluir um texto com as formações solicitadas. Resultado No teste realizado todas as formatações foram mantidas com sucesso conforme podemos verificar nas Figuras 11 e 12. Evidências Figura11 – Preenchimento caso de teste 07 14 Fonte: Captura de tela do sistema testado Figura 12 – Resultado caso de teste 07 Fonte: Captura de tela do sistema testado 15 4.3.8 Caso de teste 08 Quadro 9 - Resultado caso de teste 08 Caso de teste 08 Objetivo Gerar um artigo completo com um autor cadastrado com sucesso, anexando no campo “corpo de texto” uma imagem de um arquivo com sucesso (Nenhum campo pode ser branco). Passos para o teste - Resultado Não há um botão para anexar arquivos no campo “corpo do texto” e não é possível colar uma imagem neste campo. Evidências Figura 13 – Resultado caso de teste 08 Fonte: Captura de tela do sistema testado 4.3.9 Caso de teste 09 Quadro 10 - Resultado caso de teste 09 Caso de teste 09 Objetivo Gerar um artigo completo com um autor cadastrado com sucesso, anexando no campo “Notas” uma URL de um arquivo com sucesso e criando um texto formatado à esquerda e em negrito (Nenhum campo pode ser branco). Passos para o teste Preencher todos os dados, incluindo uma URL no campo de Notas, com alinhamento a esquerda e negrito, depois clicar em “Gerar” Resultado No teste realizado a formatação de negrito foi mantida, porém o alinhamento passou a ser justificado, conforme podemos verificar nas Figuras 14 e 15. Evidências Figura14 – Preenchimento caso de teste 09 16 Fonte: Captura de tela do sistema testado Figura 15 – Resultado caso de teste 09 Fonte: Captura de tela do sistema testado 4.3.10 Caso de teste 10 Neste tópico iremos abordar os testes realizados na interface do sistema. Estes testes são importantes para garantir uma correta entrada de dados, fazendo que o sistema se torne mais robusto e confiável. 4.3.10.1 Especificações da interface Quadro 11 – Especificações da interface Elemento Descrição Tipo/tamanho Formato Validação Campo Título Alfa (livre) Alinhado à esquerda Deve ser preenchido Campo Título em inglês Alfa (livre) Alinhado à esquerda Deve ser preenchido Botão Autores Botão - Adiciona autor Campo Autor Alfa (livre) Alinhado à esquerda Deve ser preenchido Campo Titulação Alfa (livre) Alinhado à esquerda Deve ser preenchido 17 Campo Vínculo institucional Alfa (livre) Alinhado à esquerda Deve ser preenchido Campo E-mail de contato Alfa(livre) Alinhado à esquerda Deve ser preenchido, dever ser um e-mail válido Campo Resumo Alfa (1000) Alinhado à esquerda Deve ser preenchido, não pode ultrapassar 1000 caracteres Campo Palavras- Chave Alfa (livre) Alinhado à esquerda Deve ser preenchido Campo Abstract Alfa (1000) Alinhado à esquerda Deve ser preenchido, não pode ultrapassar 1000 caracteres Campo Keywords Alfa (livre) Alinhado à esquerda Deve ser preenchido Campo Corpo do texto Alfa (livre) Alinhado à esquerda Deve ser preenchido Campo Notas Alfa (livre) Alinhado à esquerda Deve ser preenchido Campo Referências bibliográficas Alfa (livre) Alinhado à esquerda Deve ser preenchido Botão Arquivo completo Botão - Gera arquivo completo Botão Arquivo para submissão (blind review) Botão - Gera arquivo para submissão Botão Limpar Botão - Limpa campos 4.3.10.2 Especificações da mensagem a ser exibida Quadro 12 - Especificações da mensagem a ser exibida Element o Descrição Situação Mensagem a ser exibida Botão Gerar Autor não preenchido Por favor, verifique o campo Autor Botão Gerar Titulação não preenchido Por favor, verifique o campo Titulação Botão Gerar Vínculo institucional não preenchido Por favor, verifique o campo Vínculo institucional Botão Gerar E-mail de contato não preenchido Por favor, verifique o campo E-mail 4.3.10.3 Testes funcionais da interface Quadro 13 – Testes funcionais da interface 18 Campo Título OK Livre OK Texto OK Não OK Aceita OK - - Campo Título em inglês OK Livre OK Texto OK Não OK Aceita OK - - Botão Autores OK - - - - - - OK Campo Autor OK Livre OK Texto OK Sim OK Aceita OK - - Campo Titulação OK Livre OK Texto OK Sim OK Aceita OK - - Campo Vínculo institucional OK Livre OK Texto OK Sim OK Aceita OK - - Campo E-mail de contato OK Livre OK E-mail OK Sim OK Aceita OK - - Campo Resumo OK 1000 OK Texto OK Não OK Aceita OK - - Campo Palavras- Chave OK Livre OK Texto OK Não OK Aceita OK - - Campo Abstract OK 1000 OK Texto OK Não OK Aceita OK - - Campo Keywords OK Livre OK Texto OK Não OK Aceita OK - - Campo Corpo do texto OK Livre OK Texto OK Não OK Aceita OK - - Campo Notas OK Livre OK Texto OK Não OK Aceita OK - - Campo Referências bibliográficas OK Livre OK Texto OK Não OK Aceita OK - - Botão Arquivo completo OK - - - - - - OK Botão Arquivo para submissão OK - - - - - - OK Botão Limpar OK - - - - - - Não limpa todos campos 4.3.10.4 Avaliação heurística de usabilidade da interface Segundo LIESENBERG (2005), a inspeção de usabilidade tem como objetivo remover todo e qualquer erro antes do teste com o usuário. Neste momento pode-se ter novas ideia que irão facilitar a utilização da interface. D es cr iç ão E le m en to O rt o g ra fi a O b ri g at ó ri o T am an h o d o s ca m p o s C ar ac te re s es p ec ia is V al o re s d e d o m ín io O rd em al fa b ét ic a N av eg aç ão F o rm at o 19 Na inspeção de usabilidade, avaliadores especialistas em desenvolvimento de interfaces utilizam-se de métodos específicos para avaliações. A avaliação heurística é uma destas avaliações realizadas. Nesta avaliação diversos avaliadores realizam testes seguindo heurísticas pré-estabelecidas. A seguir será realizada avaliação do sistema seguindo as heurísticas apresentadas por Jakob Nielsen. Jakob Nielsen é um cientista da computação com Ph.D. em interação homem-máquina Quadro 14 – Resultado da avaliação de usabilidade da interface Item avaliado Resultado Visibilidade do estado do sistema O sistema tem design bem definido e oportunamente mostra-se de fácil utilização. Não demostrou em nenhum momento da utilização que pudesse deixar o usuário “perdido”. Correlação entre o sistema e o mundo real Sistema possui palavras e frases que correlacionam com o mundo real. Botões e campos tem suas descrições bem claras e objetivas. Liberdade e controle do usuário O sistema não possui opção para que depois de clicar em gerar o arquivo, o usuário possa retornar e corrigir informações sem que seja necessário redigitar todo as informações novamente. Consistência e padrões Não foram encontradas controvérsias nas palavras e frases dos campos ou botões. Na verdade, os botões de gerar arquivos possuem exatamente a mesma descrição. Prevenção de erros Não foram encontrados erros não esperados. Os campos obrigatórios apresentam mensagem de validação (exceto para os autores adicionais). Nenhum erro ou BUG foi encontrado. Reconhecimento em vez de memorização Design claro e intuitivo, não é necessária nenhuma explicação para utilização do 20 sistema. O usuário em seu primeiro contato já consegue usar sem qualquer treinamento. Flexibilidade e eficiência de uso Não existe nenhum atalho ou ação personalizável para este sistema. Projeto estético e minimalista Os diálogos exibidos são claros e cordiais. Deixando claro o que o usuário deve fazer para corrigir o que não está válido. Suporte para o usuário no reconhecimento, no diagnóstico e na recuperação de erros Não foram encontrados erros que exibissem qualquer tipo de mensagem que não fosse de fácil compreensão. Apenas os alertas de validações foram exibidos. Ajuda e documentação Sistema claro, sem necessidade de estudo de documentações para utilização, sendo que esta não existe ou não nos foi apresentada. 4.3.10.5 Relatório de avaliação O sistema denominado “Editor de Texto”, disponível no sitio na internet com endereço http://sfaa.unipinterativa.edu.br/pdf/, foi testado por nossa equipe de testes, seguindo as dez heurísticas, apresentadas por Jakob Nielsen, e teve um resultado bastante satisfatório quanto a usabilidade de sua interface. De modo geral o sistema possui frases e palavras que não confundem os usuários em sua utilização. Assim como, as ações que precisam ser executadas através dos botões de ações apresentam total correlação com o mundo real. Igualmente satisfatório foram as mensagens de diálogo exibidas nas validações dos campos obrigatórios. Desta forma, definimos como APROVADO, no teste de USABILIDADE DA INTERFACE. 5 CONCLUSÃO Com os testes realizados foi possível constatar problemas nas validações dos campos de autores, sendo assim foi possível incluir dados em brancos ou inválidos de acordo com o tipo de dados. Também foram identificados problemas na rotina de “limpar”, onde alguns campos permaneceram com as informações digitadas. Vimos 21 que não existia uma ferramenta que atendesse as especificações do caso de teste 08. E finalmente, identificamos um problema com o campo notas, onde não se mantém o alinhamento desejado. Foram realizados testes de interface onde não foram encontradas anormalidades. Com isso podemos concluir que os testes são fundamentais durante e após o processo de desenvolvimento do software. Mesmo que isso gere um custo maior nesta fase, ao longo prazo terá grandes benefícios para a empresa que desenvolve o produto. Além de produzir um efeito muito positivo nos primeiros contatos do usuário/cliente com o software. Compreendemos, também, com a disciplina Engenharia de Software II, os benefícios, importância e obstáculos no controle de qualidade na produção do software. Porém, com os diversos processos e modelos existentes é altamente viável que toda e qualquer fornecedora de software aplique um SGQ (Sistemas de Gestão da Qualidade). Estudamos também o impacto do processo de manutenção de software e os conceitos para melhoria e aplicação de técnicas eficazes que visam facilitar este processo. Na disciplina de Projeto de Interface com o Usuário vimos a importância de uma interface bem definida e que facilite a utilização pelo usuário. Estudamos os processos que ajudam no processo de projeto da interface de um software. 22 REFERÊNCIAS Nascimento, André Luiz Sena. Técnicas de Caixa Preta de Teste de Software. DEVMEDIA. Disponível em: https://www.devmedia.com.br/tecnicas-de-caixa-preta- de-teste-de-software/8898. Acessado em 10 de abril de 2019. Sommerville, Ian. Engenharia de software, 8a edição. Pearson Addison - Wesley, 2007. Pfleeger, Shari Lawrence. Engenharia de software: teoria e prática. São Paulo: Prentice Hall, 2004. Souza, Luciano Soares de. Projeto de interface com o usuário. São Paulo: Editora Sol, 2015. Ribeiro, André Luiz. Engenharia de Software II. São Paulo: Editora Sol, 2015.
Compartilhar