O teste de software é um dos processos do ciclo de desenvolvimento de software que visa exercitar um programa para descobrir erros. Para reduzir o tempo e o custo do processo de teste de software, muitas organizações optam por ferramentas que automatizam as atividades de teste.
PROBLEMATIZAÇÃO
Formulação do Problema
Solução Proposta
OBJETIVOS
Objetivo Geral
Objetivos Específicos
METODOLOGIA
As duas primeiras atividades foram realizadas paralelamente à fase de desenvolvimento, primeiro aplicando o teste unitário, com o objetivo de validar se cada parte da ferramenta estava funcionando conforme o esperado e após realizar o teste do sistema, integrando toda a ferramenta com o objetivo. validação do sistema como um todo. E paralelamente às etapas mencionadas, houve a fase de documentação, que incluiu a preparação do texto final do KKT II.
ESTRUTURA DO TRABALHO
Este capítulo descreve os principais conceitos envolvidos na fase de teste de software e relacionados ao objetivo geral deste trabalho de conclusão. Contudo, a ênfase está no tipo de teste de caixa preta que é aplicado na construção da ferramenta proposta.
TESTE E QUALIDADE DE SOFTWARE
- Processo de Teste de Software
- Fase dos Testes
- Tipos de Teste
- Categorias de Teste de Software
Contudo, a ênfase é colocada no tipo de teste de caixa preta que é o foco principal deste trabalho. Agora o gráfico é convertido na tabela de decisão e os casos de teste são derivados dele.
FERRAMENTAS SIMILARES
- TestComplete 3.11
- QuickTest Professional 8.2
- J-Fut
- Análise Comparativa
A ferramenta proposta neste TCC (Trabalho de Conclusão de Curso) conterá componentes de dois grupos, ferramentas de desenvolvimento de testes e ferramentas de execução de testes. Ele se enquadra no grupo de ferramentas de desenvolvimento de testes, pois permitirá ao usuário cadastrar casos de testes e configurar a aplicação a ser testada. LoadRunner: responsável por automatizar testes de desempenho, abrangendo testes de carga e volume, a ferramenta permite a criação de um cenário de execução de testes e monitora online os elementos envolvidos, como: servidores, banco de dados e rede.
QuickTest é uma ferramenta funcional de automação de testes, ele registra a ação desejada na aplicação, parametriza-a e depois executa o teste. Permite realizar atividades básicas para aplicação de critérios: instrumentação, seleção, execução de casos de teste e análise de cobertura; Os critérios de comparação estão relacionados ao conteúdo visto neste artigo, ou seja, fases de teste, técnicas, categorias, métodos, entre outras características importantes que uma ferramenta de automação de testes deve ter.
SOFTWARE ITLSYS
Após a autenticação do usuário e senha pelo sistema, abre-se o menu que contém todos os programas disponíveis ao usuário autenticado, conforme mostra a Figura 10. Dada a importância deste programa, ele será utilizado como estudo de caso neste final. . trabalhar. Portanto, o estudo de caso para validação da ferramenta desenvolvida neste projeto será aplicado neste módulo.
Primeiro, a análise de necessidades é descrita para fornecer uma visão geral da ferramenta, após a qual os diagramas de casos de uso e o diagrama de classes são especificados. Além desses diagramas UML, é apresentada a especificação da estrutura de armazenamento de dados da ferramenta utilizando XML Schema. E, finalmente, o sistema é demonstrado passo a passo usando o estudo de caso do módulo monetário do software ItlSys.
REQUISITOS
Requisitos Funcionais
Requisitos Não Funcionais
Regras de Negócio
RN03: Os valores para teste são definidos com base nos campos de entrada definidos no script; Isso é. RN04: Em aplicações que possuem campos iterativos, o teste de volume pode ser aplicado; para isso devem ser identificados com uma sintaxe específica no script (detalhes na seção 3.5) e também informados do número máximo de iterações a serem aplicadas.
CASOS DE USO
UC 01 – Mantém Projeto
Este caso de uso é responsável pela manutenção dos projetos de teste, é o primeiro passo a ser configurado pelo ator, conterá informações gerais sobre a aplicação que será testada.
UC 02 – Mantém Script
Com base no script e nos valores registrados para cada campo, este caso de uso produz os casos de teste. RN02: os casos de teste serão criados em tempo de execução e de acordo com a seguinte regra: no primeiro caso de teste em cada campo de entrada será inserido um valor válido, em seguida serão utilizadas as opções inválidas para cada campo, e para os demais campos valores válidos será usado. A aplicação irá gerar casos de teste para todos os valores cadastrados na aplicação, exercitando sempre um campo por vez e aplicando valores válidos aos demais; Isso é.
RF05: permite ao usuário informar, para cada caso de teste executado, a ação/comportamento da aplicação testada. O caso de teste foi concluído com sucesso, considerando valores válidos para todos os campos de entrada; ou. O caso de teste foi concluído após usar um valor inválido; ou O caso de teste não foi concluído, usando todos os valores válidos.
UC 06 – Reproduz Teste
DIAGRAMA DE CLASSES
Valor de teste: esta classe contém informações sobre os campos de entrada da aplicação que está sendo testada; Test_Case: esta classe contém o status e as considerações a respeito da execução do teste, bem como a referência aos valores testados no caso; Configuração: possui as configurações gerais da ferramenta, como: tempo de carregamento da aplicação em teste e intervalo de tempo para envio dos dados de um campo para outro;
Conforme mencionado anteriormente, a ferramenta precisará interpretar um script (discutido na seção 3.5) ou sua própria linguagem. Para que isso aconteça será necessário utilizar as classes geradas pela ferramenta GALS, que são representadas no diagrama pelo pacote de classes Analyzer_script. Contém as classes responsáveis pela análise lexical, sintática e semântica do roteiro. Os detalhes e a relação das classes podem ser vistos em Seára (2005, p.44). No GALS serão descritos os tokens e a gramática da linguagem (informações na seção 4.1) após a validação, o código será gerado em Delphi, as classes geradas serão utilizadas pela ferramenta para realizar análises lexicais e sintáticas.
XML SCHEMA
A estrutura de armazenamento de dados deste projeto será via XML Schema, com o objetivo de validar a estrutura e o conteúdo do documento XML. Para facilitar o entendimento, o esquema XML é apresentado em forma de diagrama, baseado na notação utilizada pela ferramenta XML Spy.
ESTRUTURA DO SCRIPT
A sintaxe do script interpretado pela ferramenta consiste em uma série de instruções simples, que seguem uma explicação dos comandos aceitos na Tabela 12. Esta instrução deve ser usada para campos iterativos, por exemplo o campo código do produto, em uma caixa registradora sistema. após a validação do script, os campos de entrada contidos neste loop são identificados e o número máximo de iterações desejadas para aplicação do teste é recuperado. Esta fase foi dividida basicamente em três etapas: implementação do reconhecedor de linguagem de script; implementar a estrutura de dados da ferramenta; e por fim, unificar as etapas anteriores e implementar a interface e funcionalidades necessárias à ferramenta de automação de testes de software, denominada TestWare.
RECONHECEDOR DO SCRIPT
ESTRUTURA DE DADOS DO SISTEMA
IMPLEMENTAÇÃO DA FERRAMENTA
FERRAMENTA TESTWARE
TestWare no Processo de Teste de Software
E por fim na fase de execução são executados os testes e os relatórios gerados, o TestWare, através dos casos de testes gerados, os executa automaticamente, após a execução, o testador registra o resultado do teste aplicado e os relatórios ficam disponíveis para impressão e análise .
ItlSys - Estudo de Caso
Demonstração
E por fim, de acordo com as dicas mostradas na interface, o testador determina os valores de teste para o campo. A Figura 22 mostra o primeiro caso de teste criado, ou seja, o caso que utiliza valores válidos para todos os campos da aplicação testada. O caso de teste mostrado na Figura 22 usará valores válidos para todos os campos, resultando em sucesso se a execução for concluída, em erro se a execução não for concluída ou em tempo limite se o aplicativo parar de responder.
A Figura 24 mostra um caso de teste de volume, de acordo com a etapa de configuração, o testador definiu o número de iterações igual a 1000, valores válidos são aplicados aos demais campos de entrada. A Figura 25 mostra a interface TestWare após a execução de todos os casos de teste aplicados no estudo de caso, nota-se que 11 deles obtiveram sucesso, incluindo o teste de volume (interface money após o teste de volume Figura 27) e erros ocorreram em 4 deles. É importante ressaltar que todos os testes aplicados na caixa registradora foram realizados sem impressora fiscal, tendo em vista que não possuímos impressora específica para testes.
DIFICULDADES ENCONTRADAS
Percebe-se que o campo dos testes de software está sendo cada vez mais explorado, levando em consideração os seguintes aspectos: os sistemas estão se tornando cada vez mais complexos; a concorrência entre empresas na área de desenvolvimento de software está aumentando; e os clientes estão se tornando mais exigentes. Numa empresa, o software deve ser concebido para suportar e automatizar processos, permitindo o crescimento da empresa. Se avaliarmos os objetivos específicos deste trabalho de conclusão de curso, podemos constatar que todos foram cumpridos, atingindo o objetivo geral.
TestWare é uma ferramenta CASE, sua validação foi realizada com um estudo de caso do módulo caixa de software ItlSys, auxiliando nos testes do software Intelidata Informática Ltda. Ao automatizar os testes neste módulo foi possível localizar erros, além de erros, foi possível localizar erros de sistema que podem ser melhorados, mas pode-se dizer que o TestWare contribui para a qualidade do software.
TRABALHOS FUTUROS
Sapro: Sistema de monitoramento de processos. lt;http://professores.ea.ufrgs.br/hfreitas/revista/arquivos/slides/aula_8_erp_si_mgt.ppt>. Trabalho de conclusão de curso (bacharelado em informática) – Centro Tecnológico, Universidade Federal de Santa Catarina, Florianópolis, 2003. Trabalho de conclusão de curso (bacharelado em informática) – Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí , 2004.
Disponível em:
XML SCHEMA DA FERRAMENTA
XML SCHEMA CONFIGURAÇÕES DA TESTWARE
VALORES PARA TESTE
Este capítulo apresenta os valores configurados no TestWare para o estudo de caso da aplicação cash, bem como os casos de testes gerados.
CASOS DE TESTE
A Tabela 20 mostra o caso de teste 02. Ele treinou o campo “produto” com valor inválido. Ele obteve sucesso porque o aplicativo exibiu a mensagem “Produto não cadastrado”. O caso de teste 04, ilustrado na Tabela 22, exerceu o campo “prazo” com valor inválido, resultando em uma mensagem de erro quando o caixa exibiu a mensagem “runtime error overflow”, que encerrou a aplicação. O caso de teste 05, conforme Tabela 23, testou o campo “condição de pagamento” com valor inválido. Este caso foi bem-sucedido porque a aplicação exibiu a mensagem “Prazo de pagamento não cadastrado”.
O caso de teste mostrado na Tabela 28 exercitou o campo “orientação” com valor nulo, recebendo erro porque a venda foi concluída. O caso de teste 12 exerceu o campo “prazo_pagamento” com valor inválido, obteve sucesso, pois a aplicação emitiu a mensagem “Prazo de pagamento não registrado”. A Tabela 32 ilustra o caso de teste 14 que exerceu o campo “cmc7” com valor inválido, o qual obteve sucesso, pois a aplicação retornou a mensagem “CMC7 inválido”.
