Demonstração

Esta seção possui o objetivo de demonstrar as funcionalidades da ferramenta desenvolvida neste projeto, assim, é apresentada através do estudo de caso caixa do software ItlSys (citado na Seção 4.4.2 ). Pode-se dizer que para a automação do teste de software, retomando a Figura 1 (Seção 1.1.2 ), são necessárias cinco etapas: (i) configuração da aplicação a se testar; (ii) definição dos valores de teste, (iii) geração dos casos de teste; (iv) execução dos casos de teste; e (v) resultado e re-execução. A realização de cada etapa é demonstrada na seqüência através da interface da TestWare.

Na configuração da ferramenta, Figura 19, o testador deverá definir um nome ao projeto, informar o caminho do executável a ser testado e, opcionalmente, pode descrever algumas observações referente ao projeto em questão.

Figura 19. Interface para configuração do projeto

Após o cadastro das informações pertinentes ao projeto, o testador deve descrever o roteiro da aplicação em teste, ou seja, o script de execução, ilustrado na Figura 20 (cuja sintaxe está apresentada na Tabela 12). Finalizada a edição do script o testador deve clicar no botão “validar”, a TestWare exibirá os erros léxicos, sintáticos e semânticos no espaço reservado às mensagens, apresentando também a linha onde encontra-se o erro. Caso o script contenha erros, o testador deverá realizar as correções e validar o script novamente. A TestWare só irá liberar a próxima etapa quando o script estiver validado.

Destaca-se que este script está testando apenas algumas condições do caixa e como este é um sistema complexo necessita-se de diversos scripts, a fim de testar outras situações de uma

venda, como por exemplo: utilizar outros tipos de finalizadores⁵, pois, cada finalizador possui um caminho diferente a seguir; utilizar produtos com unidades de medidas diferentes; produtos que estão em promoção; dentre outras.

Figura 20. Interface para cadastrar o script

Estando a ferramenta configurada a etapa definição de valores de teste deve ser iniciada. A partir da sintaxe do script o campo “Nome”, da aba valores para teste é carregado, e é também através do script que o campo “Teste de volume” é habilitado. Para cada campo de entrada o testador deve informar o tipo de dado: valor, conjunto, booleano ou intervalo, e é através desta informação que a ferramenta exibe dicas de valores a serem cadastrados. Para campos iterativos o

testador informa a quantidade máxima de iterações que deseja que a aplicação exercite. E por fim, de acordo com as dicas exibidas na interface o testador define os valores de teste para o campo.

A Figura 21 exibe o cadastro de valores de teste para o campo “produto”, este campo é do tipo valor, assim, no canto direito da tela é apresentado as diretrizes para este tipo de dado. Nesse exemplo o testador informou a quantidade de 1000 itens para a aplicação do teste de volume. Para os valores a testar, foram cadastrados cinco válidos e três inválidos. O apêndice B.1 apresenta os valores cadastrados para teste de cada campo de entrada.

Figura 21. Interface para cadastro de valores de teste por campo

Com o término do cadastro de valores para todos os campos de entrada a TestWare está totalmente configurada, assim, inicia a etapa geração dos casos de teste. O testador deve clicar em

no apêndice B.2), existem três situações de casos de teste gerados: todos os campos válidos; teste com campo inválido; e teste de volume, conforme mostra Figura 22, Figura 23 e Figura 24.

A Figura 22 mostra o primeiro caso de teste gerado, este é o caso que aplica valores válidos para todos os campos da aplicação em teste. No caso do campo produto, que é um campo iterativo, a TestWare faz um random de até dez para os casos de teste que não sejam de volume.

Após a geração dos casos o testador deve clicar em “Executar”, neste momento deve se ater a observar a execução do aplicativo. O caso de teste exibido na Figura 22 irá aplicar valores válidos para todos os campos, terá resultado sucesso, se a execução for concluída, erro, se a execução não concluir, ou timeout, se a aplicação parar de responder.

Figura 22. Caso de teste com valores válidos para todos os campos

O caso de teste 3 ilustrado na Figura 23 está exercitando o campo “parcelamento” com valor inválido. Para execuções com valores inválidos o status dos resultados se dará da seguinte forma:

sucesso, o caso de teste não foi concluído; erro: o caso de teste concluiu; ou timeout, a aplicação parou de responder. É importante ressaltar que o testador poderá interromper a qualquer momento a

Figura 23. Caso gerado com campo inválido

A Figura 24 exibe um caso de teste de volume, de acordo com a etapa de configuração o testador definiu a quantidade de iterações igual a 1000, para os demais campos de entrada são aplicados valores válidos. Os status possíveis para o teste de volume são: sucesso, se a execução for concluída; erro: se a execução não concluir; ou timeout, se a aplicação parar de responder.

O testador deverá informar para cada caso de teste executado o resultado do teste, também é possível informar uma descrição, neste espaço o testador pode informar alguma observação em relação à execução do teste.

Figura 24. Caso de teste para teste de volume

A Figura 25 mostra a interface da TestWare após a execução de todos os casos de teste aplicados no estudo de caso, nota-se que 11 deles foram de sucesso, inclusive o teste de volume (interface do caixa após teste de volume Figura 27) e em 4 deles ocorreram erros.

Figura 25. Interface com o resultado da execução

Nos testes 3 e 10 foram aplicados valores inválidos para o campo de entrada “guia” e nos dois casos a venda finalizou. Os testes foram realizados com o status do caixa em “OFF-LINE”, nesta situação o banco de dados que o sistema utiliza é o local, por isto existem algumas limitações, levando em conta que somente os dados essenciais são atualizados na base local. A tabela de entidades (clientes, fornecedores, guias, etc) não é copiada para esta base, assim este campo não é validado. Sugere-se que exista algum outro tipo de validação para este campo, como por exemplo:

através do CPF (Cadastro de Pessoa Física) ou CNPJ (Cadastro Nacional de Pessoa Jurídica) do guia; ou permitir somente caracteres numéricos neste campo.

Nos testes 4 e 11 foram inseridos valores inválidos para o campo “parcelamento”, porém, cada um obteve um erro diferente. No primeiro, foi enviado a aplicação o valor “02566985”, o caixa exibiu o seguinte erro “Run-time error 6 Overflow”, ilustrado na Figura 26. Este erro significa que o valor inserido contém mais caracteres do que foi definido no banco. Após o erro o aplicativo

No teste de número 11 foi enviado ao campo “parcelamento” o valor “abc”, e a aplicação aceitou normalmente, finalizando a venda como cheque a vista.

Figura 26. Interface do Caixa com Erro

O último teste efetuado foi o teste de volume, Figura 27, foi realizado uma venda com 1000 itens, este caso durou 28 minutos para ser concluído e obteve sucesso. É importante citar que todos os casos de teste aplicados ao caixa foram realizados sem impressora fiscal, tendo em vista, não possuir uma impressora específica para testes.

Figura 27. Interface do caixa após o teste de volume

Na etapa (v) o testador pode reproduzir o teste e imprimir o relatório com as execuções, através da interface exibida na Figura 28, a funcionalidade da reprodução do caso de teste simplesmente remonta o caso de teste e o executa não permitindo ao testador alterar o resultado ou descrição da execução.

Figura 28. Interface para impressão / reprodução do caso de teste

Após finalizada a execução de todos os casos de teste o testador deve imprimir o relatório com o resultado das execuções, Figura 29, encaminhar para a equipe de desenvolvimento e após as correções serem concluídas, aplicar todos os casos de teste novamente (teste de regressão), com o objetivo de validar se os erros foram corrigidos, e também validar se a alteração feita no programa não provocou outros erros diferentes.

Figura 29. Relatório das execuções

A TestWare também foi validada através do aplicativo SAPRO (Sistema de Acompanhamento de Processos), desenvolvido pela empresa Four-M Comercial e Serviços de Informática Ltda, este sistema possui o objetivo de facilitar o dia a dia dos escritórios de advocacia gerenciando e controlando os processos de forma simples e dinâmica (FOUR-M, 2006).

O SAPRO possui as seguintes características: rotinas de andamentos, custas, agenda, árvore de processos por cliente / processo, alerta de agenda pendentes (apresentadas logo que se inicia o sistema), atualização de valores (parcial), etiquetas por parte contrária e cliente, auditoria no cadastro de processos, além de relatórios com diversas opções de filtros e quebras.

O programa selecionado para a aplicação do teste foi o cadastro de clientes, ilustrado na Figura 30. Destacam-se algumas particularidades deste aplicativo que diferem do estudo de caso apresentado, como: foi necessário utilizar envio de teclas simultâneas; diversos campos do SAPRO são validados para não permitir que fiquem em branco, assim, criou-se a sintaxe “NULL” no

Figura 30. Interface do SAPRO

Através da realização dos testes na aplicação foi possível detectar um erro, no campo data de cadastro foi inserido o valor “16072007”, assim, o cliente foi incluído com sucesso tendo utilizado uma data de cadastro futura. O arquivo XML do projeto SAPRO encontra-se no apêndice C para uma compreensão melhor do projeto de teste.

5 CONCLUSÕES

Percebe-se que a área de teste de software vem sendo explorada cada vez mais, tendo em vista os seguintes aspectos: os sistemas tornam-se cada vez mais complexos; a concorrência entre empresas da área de desenvolvimento de software é cada vez maior; e os clientes tornam-se mais exigentes. Em uma empresa o software deve destinar-se a auxiliar e automatizar os processos, ajudando no crescimento da empresa. Assim, este trabalho de conclusão contribui para a qualidade dos processos e softwares desenvolvidos.

Avaliando os objetivos específicos deste trabalho de conclusão de curso, pode-se perceber que todos foram cumpridos, atingindo, desta forma, o objetivo geral. A TestWare é uma ferramenta CASE, sua validação fez-se através do estudo de caso do módulo caixa do software ItlSys, sendo assim, auxiliando a etapa de teste de software da empresa Intelidata Informática Ltda. Através da automação do teste neste módulo foi possível localizar erros, além dos erros foi possível localizar falhas no sistema que podem ser melhoradas, contudo, pode-se afirmar que a TestWare está contribuindo para a qualidade do software.