UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS ...siaibib01.univali.br/pdf/Ana Paula...
101
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO FERRAMENTA PARA AUTOMAÇÃO DE TESTES DE CAIXA PRETA Área de Engenharia de Software por Ana Paula Zimmermann Fabiane Barreto Vavassori Benitti, Dra Orientadora Itajaí (SC), julho de 2006
Transcript of UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS ...siaibib01.univali.br/pdf/Ana Paula...
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
FERRAMENTA PARA AUTOMAÇÃO DE TESTES DE CAIXA PRETA
Área de Engenharia de Software
por
Ana Paula Zimmermann
Fabiane Barreto Vavassori Benitti, Dra Orientadora
Itajaí (SC), julho de 2006
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
FERRAMENTA PARA AUTOMAÇÃO DE TESTES DE CAIXA PRETA
Área de Engenharia de Software
por
Ana Paula Zimmermann Relatório apresentado à Banca Examinadora do Trabalho de Conclusão do Curso de Ciência da Computação para análise e aprovação. Orientadora: Fabiane Barreto Vavassori Benitti, Dra.
Itajaí (SC), julho de 2006
ii
SUMÁRIO
LISTA DE ABREVIATURAS..................................................................iv
LISTA DE FIGURAS.................................................................................v
LISTA DE TABELAS...............................................................................vi RESUMO...................................................................................................vii ABSTRACT..............................................................................................viii 1 INTRODUÇÃO ......................................................................................1 1.1 PROBLEMATIZAÇÃO................................................................................... 4 1.1.1 Formulação do Problema .............................................................................. 4 1.1.2 Solução Proposta ............................................................................................ 4 1.2 OBJETIVOS ..................................................................................................... 5 1.2.1 Objetivo Geral................................................................................................ 5 1.2.2 Objetivos Específicos...................................................................................... 5 1.3 METODOLOGIA............................................................................................. 6 1.4 ESTRUTURA DO TRABALHO ..................................................................... 8
2 FUNDAMENTAÇÃO TEÓRICA ........................................................9 2.1 TESTE E QUALIDADE DE SOFTWARE..................................................... 9 2.1.1 Processo de Teste de Software..................................................................... 10 2.1.2 Fase dos Testes ............................................................................................. 11 2.1.3 Tipos de Teste............................................................................................... 14 2.1.4 Categorias de Teste de Software ................................................................. 26 2.2 FERRAMENTAS SIMILARES .................................................................... 28 2.2.1 TestComplete 3.11........................................................................................ 29 2.2.2 QuickTest Professional 8.2 .......................................................................... 30 2.2.3 J-Fut.............................................................................................................. 32 2.2.4 Análise Comparativa.................................................................................... 34 2.3 SOFTWARE ITLSYS .................................................................................... 36
3 PROJETO.............................................................................................42 3.1 REQUISITOS ................................................................................................. 42 3.1.1 Requisitos Funcionais .................................................................................. 42 3.1.2 Requisitos Não Funcionais........................................................................... 43 3.1.3 Regras de Negócio ........................................................................................ 43 3.2 CASOS DE USO............................................................................................. 44 3.2.1 UC 01 – Mantém Projeto ............................................................................. 45 3.2.2 UC 02 – Mantém Script ............................................................................... 45 3.2.3 UC 03 – Mantém Valores para Teste .......................................................... 46 3.2.4 UC 04 – Gera Casos de Teste....................................................................... 47 3.2.5 UC 05 – Executa Teste ................................................................................. 47
iii
3.2.6 UC 06 – Reproduz Teste .............................................................................. 48 3.3 DIAGRAMA DE CLASSES .......................................................................... 49 3.4 XML SCHEMA .............................................................................................. 50 3.5 ESTRUTURA DO SCRIPT ........................................................................... 51
4 DESENVOLVIMENTO ......................................................................54 4.1 RECONHECEDOR DO SCRIPT.................................................................. 54 4.2 ESTRUTURA DE DADOS DO SISTEMA ................................................... 55 4.3 IMPLEMENTAÇÃO DA FERRAMENTA.................................................. 56 4.4 FERRAMENTA TESTWARE ...................................................................... 57 4.4.1 TestWare no Processo de Teste de Software .............................................. 57 4.4.2 ItlSys - Estudo de Caso ................................................................................ 58 4.4.3 Demonstração............................................................................................... 58
5 CONCLUSÕES ....................................................................................71 5.1 DIFICULDADES ENCONTRADAS............................................................. 71 5.2 TRABALHOS FUTUROS ............................................................................. 72
REFERÊNCIAS BIBLIOGRÁFICAS ...................................................73
A XML SCHEMA....................................................................................76 A.1 XML SCHEMA DA FERRAMENTA........................................................... 76 A.2 XML SCHEMA CONFIGURAÇÕES DA TESTWARE............................. 77
B ESTUDO DE CASO ITLSYS .............................................................79 B.1 VALORES PARA TESTE ............................................................................. 79 B.2 CASOS DE TESTE ........................................................................................ 80
C ESTUDO DE CASO SAPRO..............................................................87
iv
LISTA DE ABREVIATURAS
API Application Programming Interfaces ASCII American Standard Code for Information Interchange CASE Computer Aided Software Engineering CNPJ Cadastro Nacional de Pessoa Jurídica CPF Cadastro Nacional de Pessoa Física DLL Dynamic Link Libraries ECF Emissor de Cupom Fiscal ERP Enterprise Resource Planning GALS Gerador de Analisadores Léxicos e Sintáticos HTML Hyper Text Markup Language IDE Integrated Development Environment ISO International Organization for Standardization POA Programação Orientada a Aspectos RF Requisito Funcional RN Regra de Negócio RNF Requisito Não Funcional SAPRO Sistema de Acompanhamento de Processos SPC Serviço Proteção ao Crédito TCC Trabalho de Conclusão de Curso TEF Transferência Eletrônica de Fundos UC Use Case UML Unified Modeling Language UNIVALI Universidade do Vale do Itajaí XML Extensible Markup Language
v
LISTA DE FIGURAS
Figura 1. Etapas da solução proposta ...............................................................................................5 Figura 2. Gráfico de causa-efeito ...................................................................................................20 Figura 3. Program P1 com múltiplas entradas e saídas ...................................................................23 Figura 4. Relacionamentos entre entrada e saída ............................................................................24 Figura 5. Interface TestComplete...................................................................................................30 Figura 6. Interface QuickTest ........................................................................................................32 Figura 7. Interface J-Fut – Cobertura de condições de entradas......................................................34 Figura 8. Organograma Software ItlSys .........................................................................................37 Figura 9. Tela Inicial do ItlSys.......................................................................................................38 Figura 10. Menu do ItlSys .............................................................................................................39 Figura 11. Interface do Caixa do ItlSys..........................................................................................40 Figura 12. Interface para finalizar a venda do ItlSys ......................................................................41 Figura 13. Modelo de Casos de Uso...............................................................................................44 Figura 14. Diagrama de Classes.....................................................................................................49 Figura 15. Visão geral do XML Schema ........................................................................................51 Figura 16. Exemplo de Script ........................................................................................................52 Figura 17. Definições Regulares, tokens e gramática do Script ......................................................55 Figura 18. Interface do XML Data Binding ...................................................................................56 Figura 19. Interface para configuração do projeto ..........................................................................59 Figura 20. Interface para cadastrar o script ....................................................................................60 Figura 21. Interface para cadastro de valores de teste por campo ...................................................61 Figura 22. Caso de teste com valores válidos para todos os campos ...............................................62 Figura 23. Caso gerado com campo inválido..................................................................................63 Figura 24. Caso de teste para teste de volume ................................................................................64 Figura 25. Interface com o resultado da execução..........................................................................65 Figura 26. Interface do Caixa com Erro .........................................................................................66 Figura 27. Interface do caixa após o teste de volume .....................................................................67 Figura 28. Interface para impressão / reprodução do caso de teste..................................................68 Figura 29. Relatório das execuções................................................................................................69 Figura 30. Interface do SAPRO .....................................................................................................70 Figura 31. XML Schema da TestWare...........................................................................................77 Figura 32. Xml Schema das configurações gerais da TestWare......................................................78 Figura 33. XML do projeto Sapro..................................................................................................92
vi
LISTA DE TABELAS
Tabela 1. Estágios do processo de aceite de um software ...............................................................13 Tabela 2. Exemplo de refinamento por particionamento de equivalência .......................................17 Tabela 3. Exemplo de refinamento por valores limites...................................................................19 Tabela 4. Identificação causas e efeitos..........................................................................................20 Tabela 5. Tabela de decisão causa-efeito .......................................................................................21 Tabela 6. Valores para teste do Program P1 ...................................................................................23 Tabela 7. Combinações para a saída W..........................................................................................24 Tabela 8. Combinações para a saída Z ...........................................................................................25 Tabela 9. União do conjunto de combinações para a saída W e Z...................................................25 Tabela 10. Conjunto mínimo de testes para o programa P1 ............................................................26 Tabela 11. Análise comparativa entre ferramentas similares ..........................................................35 Tabela 12. Instruções da gramática do script..................................................................................53 Tabela 13. Valores de teste para o campo produto .........................................................................79 Tabela 14. Valores de teste para o campo guia...............................................................................79 Tabela 15. Valores de teste para o campo cliente ...........................................................................79 Tabela 16. Valores de teste para o campo condicao_pagamento.....................................................80 Tabela 17. Valores de teste para o campo parcelamento.................................................................80 Tabela 18. Valores de teste para o campo cmc7 .............................................................................80 Tabela 19. Caso de teste 01 ...........................................................................................................81 Tabela 20. Caso de teste 02 ...........................................................................................................81 Tabela 21. Caso de teste 03 ...........................................................................................................82 Tabela 22. Caso de teste 04 ...........................................................................................................82 Tabela 23. Caso de teste 05 ...........................................................................................................82 Tabela 24. Caso de teste 06 ...........................................................................................................83 Tabela 25. Caso de teste 07 ...........................................................................................................83 Tabela 26. Caso de teste 08 ...........................................................................................................83 Tabela 27. Caso de teste 09 ...........................................................................................................84 Tabela 28. Caso de teste 10 ...........................................................................................................84 Tabela 29. Caso de teste 11 ...........................................................................................................84 Tabela 30. Caso de teste 12 ...........................................................................................................85 Tabela 31. Caso de teste 13 ...........................................................................................................85 Tabela 32. Caso de teste 14 ...........................................................................................................86
vii
RESUMO
ZIMMERMANN, Ana Paula. Ferramenta para automação de testes de caixa preta. Itajaí, 2006. 101 f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação)–Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, 2006. Teste de software é um dos processos do ciclo de desenvolvimento do software que possui o objetivo de exercitar um programa a fim de descobrir erros. Este processo contribui para a qualidade do produto final. Porém, deve ser realizado com planejamento e disciplina, devendo ser aplicado em paralelo com os demais processos do ciclo de desenvolvimento. Por ser um processo complexo deve-se destinar um bom tempo do projeto, assim, surgem no mercado ferramentas para automação de teste de software, permitindo reduzir o tempo gasto e conseqüentemente os custos para a organização que os incorpora. O intuito deste trabalho de conclusão de curso foi se aprofundar no processo de teste de software, e através do estudo realizado adquirir conhecimento suficiente, afim, de aplicá-lo na construção de uma ferramenta CASE (Computer Aided Software Engineering) para a automação de testes de caixa preta. Os testes de caixa preta garantem que os requisitos do sistema sejam plenamente atendidos pelo software e possibilitam localizar: erros de funções incorretas ou ausentes, erros de interface, nas estruturas de dados ou no acesso a banco de dados, dentre outros erros. O estudo de caso escolhido para a validação da ferramenta é o módulo de caixa do software ItlSys, pois, trata-se de um programa crítico para as empresas na área do comércio. Automatizando os testes desta aplicação foi possível localizar alguns erros funcionais, evidenciando a utilidade da ferramenta desenvolvida. Palavras-chave: Engenharia de Software. Teste de Software. Teste de Caixa Preta.
viii
ABSTRACT
Software Test is one of the processes on the cycle of software development; it has the objective to
exercise a program in order to find out errors. This process contributes for the quality of final
product. However, it must be performed with planning and discipline, being applied in parallel with
other development cycle processes. Once it is a complex task, a good time of the project must be
dedicated to it, thus, tools for software test automation appear in the market, allowing to reduce the
time spent and consequently the costs for the organization that uses them. The intention of this
Graduation Paper is to stress the software test process itsel, and based on the study made acquire
enough knowledge to apply it in the construction of a CASE (Computer Aided Software
Engineering) tool for the automation of black box tests. The black box tests guarantee that the
requirements of the system are fully covered by the software and make it possible to locate errors
such as incorrect or absent functions, errors of interface, errors in the structures of data or the
access the data base, just to name a few. The study of case chosen for the validation of the tool is
the module of box ItlSys software, because this is a critical program for companies in the direct
sales segment. Through the automation of the tests of this application it was possible to locate
functional errors, evidencing the utility of the tool developed.
Keywords: Software Engineering. Test of Software. Test of black box.
1 INTRODUÇÃO
Nas primeiras três décadas da era do computador, o principal desafio era desenvolver
hardware que reduzisse o custo de processamento e armazenagem de dados. Efetivado isto, o foco
voltou-se para o software, e o desafio tornou-se melhorar a qualidade e reduzir o custo de soluções
baseadas em computador. Para organizar, controlar e administrar o desenvolvimento destas
soluções surgiu a Engenharia de Software. Ela compreende um conjunto de etapas que envolvem
métodos, ferramentas e os procedimentos (seqüência em que os métodos serão aplicados)
(PRESSMAN, 1995).
Testes é uma das áreas da Engenharia de Software e tem como objetivo aprimorar a
produtividade e fornecer evidências da confiabilidade e da qualidade do software em complemento
a outras atividades de garantia de qualidade ao longo do processo de desenvolvimento de software.
Conforme Cândida Inthurn (2001), a atividade de teste é o processo de executar um programa com
a intenção de descobrir um erro e um teste bem sucedido é aquele que revela um erro ainda não
descoberto.
O processo de teste de software é uma das etapas do ciclo de desenvolvimento. É o último
passo a ser realizado antes de entregar o produto ao cliente, e pode ser feito em paralelo com outras
etapas do desenvolvimento. A atividade de teste não deve ser considerada como uma fase isolada
em um processo de desenvolvimento, ainda que dentro de um processo iterativo, devendo por isso
ser integrada a cada fase do desenvolvimento (INTHURN, 2001).
Com a realização de testes, que abrangem todo o sistema, obtém-se um produto com melhor
qualidade e confiabilidade, além do que, um teste sem planejamento, traz prejuízos a organização
que o desenvolve, prejuízos materiais e de reconhecimento. De acordo com Pressman (1995), esses
defeitos serão por fim descobertos pelos usuários e corrigidos pelo desenvolvedor durante a fase de
manutenção, quando o custo por correção pode ser de 60 a 100 vezes maior se fosse descoberto
durante a fase de desenvolvimento.
A concorrência entre organizações da área de desenvolvimento de software nos dias de hoje
é muito grande, portanto, um diferencial entre elas é a qualidade do produto comercializado. Em
muitas organizações a etapa de teste não é considerada um processo crítico, assim cada
programador realiza o teste de unidade do módulo que desenvolveu ou fez manutenção e libera a
2
atualização para o usuário final, que ao executar o programa se depara com diversos erros. "Para
serem eficazes, os testes devem ser cuidadosamente desenhados e planejados" (PAULA FILHO,
2001).
Com a complexidade envolvida em sistemas, para se testar adequadamente, uma
organização gasta 40% do esforço de projeto total em teste (PRESSMAN, 1995). Para diminuir o
tempo e custo do processo de teste de software muitas organizações optam por ferramentas que
automatizam as atividades de teste. Desta forma, desenvolveu-se uma ferramenta CASE para
auxílio no processo de testes do sistema ItlSys da empresa Intelidata. Esta ferramenta teve como
base o software ItlSys, ou seja, automatizar os testes deste sistema, preocupando-se com seus
detalhes e suas regras. No entanto, pode ser utilizada em vários outros sistemas que respeitem as
especificações impostas no projeto.
O sistema ItlSys é um sistema de informação ERP (Enterprise Resource Planning) voltado
para área comercial, que conforme Freitas (2004):
ERP é um sistema de informação que utiliza uma base de dados única, contendo diversos módulos que conversam entre si e trocam informações. Cada módulo é responsável por uma função específica do sistema, possibilitando à empresa acesso às informações de forma integrada, em uma única ferramenta e com um mesmo padrão de apresentação das informações.
O ItlSys é um sistema de grande porte desenvolvido de forma incremental, há necessidade
da criação de novos módulos e ao mesmo tempo da manutenção dos módulos já existentes, o
número de desenvolvedores é pequeno e a quantidade de serviços a ser realizado grande, assim o
tempo para o desenvolvimento e para a etapa de testes é curto, cada programador realiza o teste no
código criado ou modificado. Conseqüentemente algumas vezes o usuário final encontra erros que
poderiam ser descobertos com uma ferramenta automatizada, que é o objetivo geral deste trabalho.
Ou seja, o projeto está focado em automatizar testes funcionais (caixa preta) em um módulo do
software ItlSys, visando validar o comportamento do sistema referente a entrada de dados. No
entanto, isto não significa que não poderá ser utilizado em outros sistemas com características e
necessidades semelhantes ao ItlSys, mas deseja-se limitar o escopo da ferramenta e suprir as
necessidades de testes deste sistema específico.
Esta ferramenta será desenvolvida baseada nos conceitos do processo de teste de software,
se enquadrando no tipo de teste de caixa preta, que se refere a técnicas para garantir que os
requisitos do sistema sejam plenamente atendidos pelo software que foi construído. Não é seu
3
objetivo verificar como ocorrem internamente os processamentos no software, mas se o algoritmo
inserido no software produz os resultados esperados (BARTIÉ, 2002).
4
1.1 PROBLEMATIZAÇÃO
1.1.1 Formulação do Problema
Grandes empresas de desenvolvimento de softwares, ou departamentos de Tecnologia de
Informação integrados a organizações de outro ramo, possuem dificuldades na etapa de teste de
software, pois, muitas delas não possuem uma equipe especializada nesta área, assim, esta etapa é
realizada pelo próprio desenvolvedor ocasionando muitas vezes a não detecção de um erro. Para a
organização isto significa, como já foi dito, um custo muito elevado, podendo ser de 60 a 100 vezes
maior se fosse descoberto durante a fase de desenvolvimento.
Ainda para a realização de testes em sistemas complexos o tempo gasto é de 40% do esforço
do projeto total. Assim, nem sempre as organizações estão dispostas em destinar todo este
tempo/esforço para esta etapa.
Além disso, quando um produto é entregue com erros prejudica a imagem do
produto/organização, e com a concorrência acirrada dos dias de hoje a qualidade do software é
primordial para o crescimento e reconhecimento da organização.
1.1.2 Solução Proposta
Esta proposta pretende contribuir no processo de testes de software, visando minimizar o
tempo dedicado a esta atividade, bem como fornecer subsídios para incrementar a qualidade desta
etapa do processo de desenvolvimento. Para isto, propõe-se desenvolver uma ferramenta para
automatizar a execução dos testes de caixa preta, através da técnica de particionamento de
equivalência (detalhado no decorrer deste trabalho).
Sucintamente, pretende-se que a ferramenta automatize o processo observando as etapas
apresentadas na Figura 1, ou seja, na etapa 1 o testador deverá configurar a ferramenta fornecendo
um roteiro que indique a seqüência de uso da aplicação a ser testada. Na etapa 2, seguindo a técnica
de particionamento de equivalência, o testador deve informar os valores que a ferramenta deverá
utilizar para testar a aplicação. Na seqüência, etapa 3, a ferramenta gera os casos de teste
(observando os valores definidos anteriormente), na etapa 4 a ferramenta executa o caso de teste
automaticamente. E, por fim, na etapa 5, o testador informa o resultado do caso de teste executado
(os resultados possíveis estão detalhados na Seção 3.2.5 e a ferramenta habilita a reprodução do
mesmo.
5
Configuração da aplicação a ser testada
1 Definição dos valores de teste
2 Geração dos casos de teste 3 Execução
dos casos de teste
4 Resultado / re-execução 5
Figura 1. Etapas da solução proposta
1.2 OBJETIVOS
1.2.1 Objetivo Geral
O objetivo geral deste projeto é desenvolver uma ferramenta CASE para auxiliar na etapa de
teste do software ItlSys da empresa Intelidata Informática Ltda.
1.2.2 Objetivos Específicos
Os objetivos específicos deste projeto de pesquisa são:
• Estudar e descrever conceitos referentes ao processo de teste de software;
• Pesquisar e apresentar ferramentas voltadas a execução de testes automáticos de
software;
• Realizar a especificação da ferramenta CASE;
• Implementar uma ferramenta de testes, focada em testes de caixa preta, para o software
ItlSys;
• Validar a ferramenta automatizando os testes de um módulo do software ItlSys; e
• Documentar e divulgar os resultados do trabalho desenvolvido.
6
1.3 Metodologia
A metodologia utilizada no desenvolvimento deste projeto foi dividida em cinco grandes
etapas: (i) estudo; (ii) especificação; (iii) desenvolvimento, (iv) validação; e (v) documentação.
A etapa de estudo foi destinada a pesquisa e estudo dos conceitos que envolvem o processo
de teste de software, e as tecnologias similares existentes nesta área. Para a fundamentação teórica a
pesquisa realizou-se principalmente em livros na área de Engenharia de Software e também livros
específicos de Teste de Software, todos disponíveis na referência bibliográfica.
Ainda na etapa de estudo foi explanado o Software ItlSys, pois é a aplicação selecionada
como estudo de caso deste projeto. Foram descritas informações sobre a empresa proprietária, as
principais características do produto e algumas telas consideradas relevantes.
A etapa de especificação objetivou analisar e projetar as necessidades da ferramenta. Foi
especificada utilizando a notação UML (Unified Modeling Language) e a estrutura de
armazenamento dos dados escolhida, no caso, XML Schema. Nesta etapa foram realizadas as
tarefas:
• Especificação de Requisitos: durante esta tarefa foi definido o funcionamento da
ferramenta a ser implementada, especificando seus requisitos funcionais, requisitos não
funcionais e as regras de negócio;
• Casos de uso: para melhorar o entendimento dos requisitos da ferramenta e visualizar as
condições necessárias para a implementação foi construído o diagrama de casos de uso;
• Diagrama de classes: a partir dos casos de uso e protótipos foi elaborado o diagrama de
classes, identificando seus atributos;
• XML Schema: nesta tarefa foi criado o XML Schema, com o intuito de validar e
identificar como as informações serão armazenadas; e
• Estrutura do script: para a automação do teste de software é necessário descrever seu
roteiro, sendo assim esta tarefa detalhou a estrutura do script.
A etapa (iii) desenvolvimento por sua vez foi dividida em três módulos: implementação do
reconhecedor do script; implementação da estrutura de dados do sistema; e por fim a integração dos
7
dois módulos anteriores, somada a implementação da interface e outras funcionalidades necessárias
a fim de possibilitar a automação do processo de teste.
A etapa de validação foi dividida em três atividades: testes com o interpretador do script;
testes com a ferramenta; e validação através de um estudo de caso. As duas primeiras atividades
foram realizadas em paralelo com a etapa de desenvolvimento, aplicando inicialmente o teste de
unidade, com o objetivo de validar se cada parte da ferramenta estava funcionando de acordo com o
esperado e após realizado o teste de sistema, integrando toda a ferramenta com o intuito de validar o
sistema como um todo. E ao término da implementação, foi validada através do estudo de caso
aplicado no caixa do sistema ItlSys, onde ocorreu a automação dos testes deste módulo através da
ferramenta desenvolvida neste projeto. E concorrentemente com as etapas citadas, houve a etapa de
documentação, que contemplou a elaboração do texto final do TCC II.
8
1.4 Estrutura do trabalho
Este projeto está estruturado em cinco capítulos: (i)Introdução; (ii)Fundamentação
Teórica; (iii)Projeto; (iv) Desenvolvimento; e (v) Conclusões.
O Capítulo 1 (Introdução) destina-se a contextualizar o projeto sucintamente,
descreve o problema encontrado e qual a solução proposta, expõe os objetivos gerais e
específicos a serem atingidos com o trabalho e a metodologia utilizada para o
desenvolvimento do projeto.
O Capítulo 2 (Fundamentação Teórica) apresenta conceitos necessários e relevantes
para o entendimento do processo de teste de software, e como ele está integrado com a área
de Engenharia de Software. São apresentadas também ferramentas similares e abordadas
informações sobre o Software ItlSys que é o estudo de caso deste projeto.
O Capítulo 3 (Projeto) especifica detalhadamente a ferramenta proposta, definindo
seus requisitos, modelando os diagramas de caso de uso e de classes. Também apresenta o
XML Schema como base de armazenamento dos dados. E mostra a estrutura e sintaxe do
script que será utilizado como roteiro para a automação do teste.
O Capítulo 4 (Desenvolvimento) descreve quais foram as etapas necessárias para a
construção da ferramenta de automação de teste, como foram implementadas e quais as
tecnologias envolvidas. Além de contextualizar a ferramenta no processo de teste de
software e demonstrar a ferramenta através de um estudo de caso para automatizar os testes
do módulo caixa do software ItlSys.
E o Capítulo 5 (Conclusões) relaciona o projeto com os objetivos especificados, bem
como as dificuldades encontradas no seu desenvolvimento e expõe os resultados obtidos,
além de identificar melhorias a serem realizas na ferramenta com o intuito de dar
continuidade ao trabalho.
2 FUNDAMENTAÇÃO TEÓRICA
Neste capítulo são descritos os principais conceitos envolvidos na etapa de teste de software
e que estão relacionados com o objetivo geral deste trabalho de conclusão. A Seção 2.1 descreve,
referenciando diversos autores, o processo do teste, as fases, tipos de teste e técnicas, visando
demonstrar uma visão geral do processo de teste de software. Porém, a ênfase encontra-se no tipo
de teste de caixa preta que é aplicado na construção da ferramenta proposta. A Seção 2.2 apresenta
algumas ferramentas similares, além de realizar uma análise comparativa entre as ferramentas
existentes e a ferramenta proposta neste projeto. A Seção 2.3 destina-se a apresentação do Software
ItlSys, estudo de caso do presente projeto, abordando suas funcionalidades e características.
2.1 Teste e Qualidade de Software
Pode-se afirmar que a etapa de teste de software e a qualidade de produtos de software estão
relacionadas, pois, para obter um software com qualidade necessita-se que sejam realizadas várias
baterias de testes, antes de entregá-lo ao usuário final.
Segundo Inthurn (2001 p.36), a Organização Internacional de Padrões (ISO – International
Organization for Standardization), através da norma ISO/IEC 91261, define as seguintes
características que um software de qualidade deve possuir:
• Funcionalidade: um conjunto de funções que satisfazem a necessidade do cliente;
• Confiabilidade: a capacidade do software de manter seu nível de desempenho, sob
condições estabelecidas, por um determinado tempo;
• Usabilidade: refere-se ao esforço necessário para a utilização do software;
• Eficiência: relacionamento entre o nível de desempenho e a quantidade de recursos
utilizados;
• Manutenibilidade: esforço necessário para realizar modificações específicas; e
• Portabilidade: habilidade de o software ser transferido de um ambiente para outro.
1 Esta norma possui sua tradução para o Brasil publicada em agosto de 1996 como NBR 13596.
10
Nas próximas seções são abordadas a etapa de teste de software e suas técnicas, visando
garantir as características citadas anteriormente, a fim de produzir um software com qualidade.
A etapa de teste é o processo de simular a utilização do software pelo usuário, é o momento
de prever situações diferentes do planejado pelo programador. É verificar se o software atende a
todos os requisitos funcionais, não funcionais e regras de negócio estabelecidas na especificação.
Segundo Pressman (1995) “a atividade de teste não pode mostrar ausência de bugs; ela só pode
mostrar se defeitos estão presentes”.
O profissional responsável pela execução dos testes deverá possuir perfil de destruidor, não
poderá se intimidar com a equipe de desenvolvimento e nunca deverá ocultar erros. De acordo com
Inthurn (2001), “um teste bem sucedido é aquele que revela um erro ainda não descoberto. É uma
das atividades realizadas para garantir a qualidade do software”.
O objetivo principal desta atividade é encontrar erros no software antes que o mesmo esteja
em produção. É se antecipar a uma manutenção corretiva, e para uma organização isto significa
diminuir custos. Inthurn (2001) complementa, “teste de software tem como objetivo aprimorar a
produtividade e fornecer evidências de confiabilidade e da qualidade do software em complemento
a outras atividades de garantia de qualidade ao longo do processo de desenvolvimento do software”.
2.1.1 Processo de Teste de Software
Para Moreira Filho e Rios (2003, p. 9) “o processo de teste de software deve basear-se em
uma metodologia aderente ao processo de desenvolvimento, em pessoal técnico qualificado, em
ambiente e ferramentas adequadas”. As atividades que envolvem o ciclo de teste são diferenciadas
de um autor para outro, de forma geral pode-se identificar as seguintes etapas:
• Planejamento: Indica a abrangência, a abordagem, os recursos e a programação da
atividade de teste (PETERS E PEDRYCZ, 2001). É decidir antecipadamente o que deve
ser feito e quando deve ser feito (ROSA, 1997);
• Projeto: Identificam características específicas a serem testadas e definem os casos de
teste associados (PETERS E PEDRYCZ, 2001);
• Implementação: Nesta atividade o ambiente de teste é preparado, tornando disponíveis
todos os recursos necessários. Os itens a testar são instalados e configurados, assim
como as ferramentas e componentes de teste (PAULA FILHO, 2001); e
11
• Execução: Executam-se os testes e são produzidos os relatórios correspondentes
(PAULA FILHO, 2001).
2.1.2 Fase dos Testes
A atividade de testes está divida em fases: teste de unidade, teste de integração, teste de
sistema e teste de aceitação. Estas fases compreendem desde o teste da estrutura interna do sistema
até o exercício das funcionalidades e interfaces.
2.1.2.1 Teste de Unidade
O teste de unidade preocupa-se em exercitar a menor unidade de projeto de software, uma
função ou módulo, com o intuito de verificar se: (1) as informações que entram e saem são
consistentes; (2) as condições de limites garantem a execução correta da unidade; (3) todos os
caminhos básicos estão corretos; e (4) os caminhos de tratamento de erros sejam devidamente
tratados (INTHURN, 2001, p. 58).
“O teste de unidade tem por objetivo explorar a menor unidade do projeto, procurando
identificar erros de lógica e de implementação em cada módulo separadamente” (ROCHA,
MALDONADO e WEBER, 2001, p.75).
As categorias de teste aplicadas a esta fase são: estrutura interna, funcionalidade, usabilidade
e segurança, que aplicam técnicas de caixa branca e preta (abordadas na Seção 2.1.3 ), portanto o
engenheiro de testes deverá possuir conhecimento da estrutura interna do software (BARTIÉ, 2002
p. 139).
Através do teste de unidade, que empregam métodos de caixa branca, afirma Bartié (2002
p. 141), é possível examinar detalhadamente segmentos do código-fonte e simular o processamento
dos componentes, de modo a exercitar sua estrutura interna da forma mais variada possível, como:
• Exercitar todas as linhas existentes no código-fonte;
• Exercitar todos os desvios condicionais existentes no código-fonte; e
• Exercitar todos os fluxos alternativos de processamento.
Empregando métodos de caixa preta, o mesmo autor cita, que as validações são baseadas na
arquitetura da aplicação, sendo possível validar:
12
• Todos os requisitos funcionais relacionados ao componente;
• Todos os requisitos de usabilidade relacionados ao componente; e
• Todos os requisitos de sistema relacionados ao componente.
2.1.2.2 Teste de Integração
Possui o objetivo de integrar todas as unidades já testadas individualmente, a fim de validar
o sistema como um todo. As unidades podem ser integradas de forma não incremental ou
incremental.
Na integração não incremental as unidades são combinadas e o programa completo é
testado, na integração incremental, as unidades são gradativamente testadas e integradas, é uma
forma mais eficiente e apropriada, pois é mais fácil isolar a causa dos erros quando se testa partes
menores (INTHURN, 2001 p. 59).
Utilizando a integração incremental Pressman (2002 p.483) sugere a realização de testes de
regressão, pois cada vez que um novo módulo é adicionado o software se modifica, novos caminhos
de fluxo de dados são estabelecidos.
“O teste de regressão é a reexecução de algum subconjunto de testes que já foram
conduzidos para garantir que as modificações não propagaram efeitos colaterais indesejáveis”
(PRESSMAN, 2002).
2.1.2.3 Teste de Sistema
Após a integração do software aplica-se o teste de sistema, que se preocupa com a
incorporação do software com os outros elementos do sistema, hardware, pessoal e informação.
Têm o objetivo de descobrir implementações incorretas dos requisitos especificados, Inthurn (2001
p.62).
Esta fase utiliza estratégias de caixa preta, necessita de um ambiente muito próximo a
realidade da produção e utiliza as categorias de teste funcional, usabilidade e segurança (BARTIÉ,
2002). Pressman (2002) inclui também as categorias de teste de recuperação, estresse e
desempenho.
13
2.1.2.4 Teste de Aceitação
Também denominado teste de validação por alguns autores, é o último passo realizado para
a detecção de erros antes de disponibilizar o software para o ambiente de produção. “Nesta fase o
software é disponibilizado para clientes e usuários com o objetivo de estes validarem todas as
funcionalidades requisitadas no início do projeto” (BARTIÉ, 2002 p.157). Nas fases anteriores o
responsável pelo teste é um profissional da própria equipe de desenvolvimento, agora quem
executará os testes é o cliente ou o usuário final. Bartié (2002, p.158) divide esta fase em três
momentos distintos: o aceite formal, alpha teste e o beta teste, conforme ilustra a Tabela 1.
Tabela 1. Estágios do processo de aceite de um software
Homologação (Aceite da Solução) Aceite Formal Implantação Alpha Implantação Beta Clientes planejam e realizam os testes do software.
Clientes são convidados a operar o software no fornecedor.
Clientes selecionados recebem o software para operar em seu ambientes.
Fonte: Adaptado de Bartié (2002).
Inthurn (2001, p.59) conclui que a validação é bem sucedida quando o software funciona da
maneira esperada pelo cliente, ou conforme especificado na fase de projeto, e descreve o perfil que
o cliente selecionado para a execução dos testes deve possuir:
• Capacidade crítica no uso do software, testando situações pouco comuns ou de exceção;
• Bom relacionamento com a empresa desenvolvedora;
• Preferencialmente, ser leigo em informática, para evitar considerações que podem levar
à interpretações errôneas do caso observado; e
• Ser organizado e dispor de tempo para o teste, assim contribuindo para o
aperfeiçoamento do produto final.
14
2.1.3 Tipos de Teste
Nesta seção, são conceituados os tipos de testes de validação, os quais, segundo Bartié
(2002), “têm por objetivo identificar o maior número possível de erros tanto nos componentes
isolados quanto na solução tecnológica como um todo”. Os testes de validação possuem duas
abordagens, os testes de caixa branca e os testes de caixa preta. Porém, é dada ênfase no tipo de
teste de caixa preta que é o foco principal deste trabalho.
2.1.3.1 Teste de Caixa Branca
Também denominado teste estrutural, que conforme Bartié (2002), os testes de caixa branca
são conhecidos desta forma, pois são baseados na arquitetura interna do software. Eles empregam
técnicas que objetivam identificar defeitos nas estruturas internas dos programas através da
simulação de situações que exercitem, adequadamente, todas as estruturas utilizadas na codificação.
O testador deverá possuir conhecimento da arquitetura interna da solução, ter acessos aos
códigos-fonte e ao banco de dados. Segue algumas vantagens e desvantagens citadas por Bartié
(2002).
• Vantagens:
Alta eficiência na detecção de erros;
Podem ser modelados e estruturados pelo próprio desenvolvedor; e
Trata complexidade ciclomática das aplicações de modo a diminuí-la.
• Desvantagens:
São difíceis de ser implementado;
Traz uma carga adicional de trabalho ao desenvolvedor; e
Sem a contratação de uma equipe de testes, os resultados podem ser demorados e
pouco significativos.
Utilizando técnicas de caixa branca, de acordo com Pressman (2002, p 436), podem-se
derivar casos de teste que: (1) garantam que todos os caminhos do código tenham sido exercitados
ao menos uma vez; (2) exercitam todas as condições lógicas, verdadeiro e falso; (3) exercitam os
ciclos nos seus limites e dentro de seus intervalos operacionais; e (4) exercitam as estruturas de
15
dados internas para garantir sua validade. Os métodos mais conhecidos para a abordagem de caixa
branca são: Teste de Caminho Básico e Teste de Estrutura de Controle.
2.1.3.2 Teste de Caixa Preta
O teste funcional ou caixa preta concentra-se nos requisitos funcionais. Através dele torna-se
possível verificar as entradas e saídas de cada unidade. O teste de caixa preta é uma abordagem
complementar ao teste de caixa branca, que provavelmente irá descobrir erros diferentes dos
encontrados no teste de caixa branca (PRESSMAN, 2002 p. 450). Segundo Inthurn (2001), o teste
de caixa preta preocupa-se com “o quê” e não “como” a unidade está sendo executada, permitindo
descobrir:
• Funções incorretas ou ausentes;
• Erros de interface;
• Erros nas estruturas de dados ou no acesso a bancos de dados externos;
• Erros de desempenho; e
• Erros de iniciação e término.
Este tipo de teste não se preocupa em como o software foi implementado, como está
estruturado internamente, mas se atende aos requisitos especificados na fase de projetos.
Apresentam-se vantagens e desvantagens desta abordagem segundo Inthurn (2001):
• Vantagens:
Alta capacidade de detectar erros tanto de aplicação quanto do processo de negócio;
Os resultados são avaliados visualmente na aplicação;
Testes mais simples de serem implementados; e
Para a realização de testes não requer conhecimento da tecnologia empregada.
• Desvantagens:
Convencimento das áreas de homologação já existentes a seguir um procedimento
definido de testes; e
Requer maior manutenção dos artefatos de teste gerados.
16
O usuário que irá realizar os testes deverá ter conhecimento dos requisitos, suas
características e comportamentos esperados, para avaliar o software através dos resultados gerados
pela aplicação (INTHURN, 2001).
Existem quatro principais métodos utilizados para detectar casos de teste de caixa preta, que
procuram aumentar a cobertura dos testes, segundo Pressman (1995) são: particionamento por
equivalência, análise de valor limite, técnicas de grafo de causa efeito e testes de comparação. E são
modelados para responder as seguintes perguntas, citado por Pressman (2002, p. 451):
• Como a validade funcional é testada?
• Como o comportamento e o desempenho do sistema são testados?
• Que classes de entrada vão constituir bons casos de teste?
• O sistema é sensível a certos valores de entrada?
• Como são isolados os limites de uma classe de dados?
• Que taxas e volumes de dados o sistema pode tolerar? e
• Que efeito as combinações específicas de dados vão ter na operação do sistema?
Bartié (2002) apresenta também o método de refinamento por probabilidade de erro, onde
descrimina os erros mais comuns que a equipe de desenvolvimento costuma cometer, considerando
ser um método relevante para o desenvolvimento deste projeto é apresentado nas próximas
subseções.
Além destes métodos será descrito o método análise de entrada e saída, apresentado no
International Symposium on Software Testing and Analysis em Portland em 2000. Refere-se a uma
técnica que analisa o relacionamento entre entradas e saídas com o objetivo de diminuir o número
de combinações possíveis.
17
Particionamento por Equivalência
A técnica de particionamento por equivalência procura identificar classes de dados, que
contemple entradas de dados válidos e inválidos, tendo assim, um caso de teste reduzido mais
eficiente.
A partição de equivalência é um método que divide o domínio de entrada de dados em classes (grupos de valores). Cada classe representa um possível erro a ser identificado, permitindo que os casos de testes redundantes de cada classe identificada sejam eliminados sem que a cobertura dos cenários existentes seja prejudicada (BARTIÉ, 2002).
As classes de equivalência, que Pressman (2002, p. 455) define, “representa um conjunto de
dados válidos e inválidos pra condições de entrada”. Elas podem ser definidas de acordo com as
seguintes diretrizes:
1. Se uma condição de entrada especifica um intervalo, uma classe de equivalência válida e
duas inválidas são definidas;
2. Se uma condição de entrada exige um valor específico, uma classe de equivalência
válida e duas inválidas são definidas;
3. Se uma condição de entrada especifica um membro de um conjunto, uma classe de
equivalência válida e uma inválida são definidas; e
4. Se uma condição de entrada é booleana, uma classe de equivalência válida e uma
inválida são definidas.
Na Tabela 2, apresenta-se o exemplo de Bartié (2002). Em um sistema de gestão de
contratos, a idade válida dos clientes varia entre 18 e 120 anos.
Tabela 2. Exemplo de refinamento por particionamento de equivalência
Entrada Valores Permitidos
Classes Casos de Testes
18 a 120 Idade = 20 < 18 Idade = 10
Idade (esse valor é obtido através da digitação da data de aniversário)
Número entre 18 e 120
> 120 Idade = 150
Fonte: Bartié (2002).
18
Análise de valor limite
A análise de valor limite complementa o método de particionamento por equivalência,
porém foca os casos de testes nas fronteiras de cada classe, por exemplo, o software de digitação
das médias finais dos alunos de graduação, o campo nota permite a entrada de valores na seguinte
faixa “x >= 0 and x <=10”. Desta forma, este método sugere os casos de teste com o valor –1, 11, 0
e 10.
Este princípio foi criado, pois um grande número de erros é encontrado nas fronteiras do
domínio de entrada, mas os motivos da ocorrência destes erros não estão completamente claros
(PRESSMAN, 2002 p.456). O mesmo autor ainda confirma que além de focalizar somente as
condições de entrada, a análise de valor limite também deriva casos de teste para o domínio de
saída, apresentam-se diretrizes para a criação de casos de teste:
1. Se uma condição de entrada especifica um intervalo limitado pelos valores a e b, devem-
se criar casos de teste com valores imediatamente acima e abaixo de a e b;
2. Se uma condição de entrada especifica vários valores, casos de teste deverão ser
realizados para exercitar os números mínimos e máximos permitidos, também valores
imediatamente acima e abaixo do mínimo e máximo selecionado;
3. As diretrizes 1 e 2 também são aplicadas às condições de saída. Por exemplo, uma tabela
de temperatura versus pressão é esperada como saída de um programa de análise de
engenharia. Devem ser projetados casos de testes para criar um relatório de saída que
produza o número máximo e mínimo aceitável de entradas na tabela; e
4. Se o programa contém uma estrutura interna que existem limites prescritos, deve realizar
testes a fim de exercitar esta estrutura de dados no seu limite, por exemplo, um vetor de
100 entradas.
Segue os casos de teste do mesmo exemplo do método de particionamento por equivalência,
utilizando agora o método de análise de valor limite, de acordo com Bartié (2002, p.135).
19
Tabela 3. Exemplo de refinamento por valores limites
Entrada Valores Permitidos
Classes Casos de Testes
18 a 120 Idade = 18 Idade = 120
< 18 Idade = 17
> 120 Idade = 121
Idade (esse valor é obtido através da digitação da data de aniversário)
Número entre 18 e 120
Negativa Idade = -18 (data futura)
Fonte: Bartié (2002).
Neste exemplo percebe-se que o autor complementa com mais uma classe, a classe idade
negativa, justificando “essa classe foi identificada como uma eventual saída possível caso o
software venha erradamente aceitar idades negativas, como uma idade válida” (BARTIÉ, 2002).
Técnicas de grafo de causa efeito
A principal diferença entre este método e os dois vistos anteriormente, é que o método de
causa efeito preocupa-se também com as saídas dos dados e não somente com a entrada. A
definição, segundo Peters e Pedrycz (2001, p.390) diz: “os gráficos de causa-efeito capturam
relações entre combinações específicas de entradas (causas) e saídas (efeitos).” Complementando o
autor explica que as causas e os efeitos são representados como nós de um grafo de causa-efeito. O
grafo inclui nós intermediários que ligam causas e efeitos na formação de uma expressão lógica. O
objetivo deste método é ajudar a determinar os casos de testes correspondentes.
Para uma melhor compreensão deste método apresenta-se o exemplo de Peters e Pedrycz
(2001, p.391), um sistema de transação bancária de um caixa automático:
20
Tabela 4. Identificação causas e efeitos
Causas Efeitos
C1 Comando é crédito E1 Imprimir “comando inválido”
C2 Comando é débito E2 Imprimir “número de conta inválido”
C3 Número da conta é válido E3 Imprimir “valor de débito não é válido”
E4 Conta de débito C4 Valor da transação é válido
E5 Conta de crédito
Fonte: Adaptado de Peters e Pedrycz (2001).
A partir da descrição das “causas” e “efeitos” forma-se o grafo ilustrado na Figura 2:
Figura 2. Gráfico de causa-efeito
Fonte: Adaptado de Peters e Pedrycz (2001).
Em um grafo causa-efeito os nós de processamento possuem o significado: “e”, efeito ocorre
se todas as entradas forem verdadeiras (1), “ou”, efeito ocorre se pelo menos umas das entradas
forem verdadeiras, e negação “¬”, efeito ocorre se as entradas forem falsas (0)
ou ¬
C1
C2
C3
C4
E1
E2
E3
E4
E5
e
e
e
e
¬
¬
21
(PETERS e PEDRYCZ, 2001, p.392). Agora o grafo é convertido na tabela de decisão, e a partir
dela são derivados os casos de teste.
Tabela 5. Tabela de decisão causa-efeito
Causas C1 0 1 X X 1 C2 0 X 1 1 X C3 X 0 1 1 1 C4 X X 0 1 1 Efeitos E1 E2 E3 E4 E5
Fonte: Peters e Pedrycz (2001).
Na tabela de decisão os valores aplicados as causas possuem o seguinte significado: “0”,
aplicar valor falso a entrada, “1” aplicar valor verdadeiro, e “X” o valor da entrada não influencia
no efeito. Exemplificando, para produzir o efeito E1 (imprimir comando inválido) deve-se testar a
causa C1(comando é crédito) e C2 (comando é débito) com entradas falsas, ou seja, uma entrada em
que o comando não seja crédito e nem débito. Neste caso de teste as causas C3 (número da conta é
válido) e C4 (valor da transação é válido) não influenciam no efeito.
Teste de comparação
Este método é aplicado em sistemas onde a confiabilidade do software é absolutamente
crítica, por exemplo sistema de freio de automóveis. Nestas situações são desenvolvidos softwares e
hardwares redundantes, no caso do software são contratadas duas equipes diferentes para o
desenvolvimento do sistema utilizando a mesma especificação.
Após a solução pronta, cada versão é testada com os mesmos casos de teste para garantir que
fornecem saída idêntica. Depois as versões são executadas em paralelo com comparação em tempo
real dos resultados para garantir consistência.
Se a saída de cada versão for a mesma, é considerado que ambas as implementações estão
corretas, caso as saídas forem diferentes, cada versão é investigada a fim de descobrir o defeito
responsável pela diferença (PRESSMAN, 2002 p.457).
22
Refinamento por probabilidade de erro
Este método está baseado na intuição e experiência de testar condições que normalmente
provocam erros. Seguem os mais tradicionais erros que o grupo de desenvolvimento costuma
cometer na implementação do software, de acordo com Bartié (2002, p.136):
• Tabelas vazias ou nulas: registros nulos no modelo de dados, um exemplo é entrar em
uma tela de cadastramento sem que existam informações nesse cadastro, nessa situação,
software provoca um erro ao acessar a tela;
• Nenhuma ocorrência: quando alguma operação é executada porém não existem
informações a serem processadas. Exemplo, tela na qual são apresentados pedidos
pendentes e que podem ser visualizados através do comando “duplo clique”. Caso não
existam pedidos pendentes e seja realizada a visualização dos pedidos, o software pode
provocar erro de execução;
• Primeira execução: primeira execução de uma funcionalidade do sistema. Um exemplo é
o saldo da conta corrente, quando for executar a primeira operação para movimentar a
conta, a operação de soma ou subtração do saldo falha, pois este não foi iniciado com
“zero”, mas sim com o valor nulo;
• Valores brancos ou nulos: entrada de dados em branco ou nulo, ou durante a leitura
destes registros de uma tabela. Registros obrigatórios não estarem sendo validados
ocorrendo um erro de execução; e
• Valores inválidos e negativos: entrada de dados incorretos, provocados pelo
processamento equivocado de determinadas informações inconsistentes que
conseguiram ser digitadas pelo usuário.
Análise de entrada-saída
Programas com múltiplas entradas e saídas possuem um número de combinações possíveis
extremamente grandes, dificultando a realização dos testes. Este método identifica relacionamentos
entre as entradas e as saídas, tendo em vista que nem toda entrada do programa influencia cada
saída. Possui o objetivo de reduzir o número de combinações, sem diminuir a potencialidade na
detecção de falhas, assim, o conjunto de combinações identificadas exercita o software
adequadamente expondo a maioria dos seus defeitos (SCHROEDER e KOREL, 2000).
23
O autor explica o método através do seguinte exemplo: a Figura 3 mostra o programa P1 que
possui três entradas (A, B, e C) e duas saídas (W e Z).
Program 1
A B C
W Z
Figura 3. Program P1 com múltiplas entradas e saídas
Fonte: Schroeder e Korel (2000).
Na Tabela 6, apresentam-se os valores para cada entrada, estes conjuntos de valores já foram
reduzidos aplicando outros métodos de caixa preta como: particionamento por equivalência ou
análise de valor limite.
Tabela 6. Valores para teste do Program P1
Entrada Valores A 1.5, 3.6
B North, South, East, West
C TDC, BDM
Fonte: Schroeder e Korel (2000).
A aproximação mais completa deve testar cada combinação possível dos valores
selecionados dos dados de teste. Assim tem-se o produto cartesiano, T = D(A) × D(B) × D(C),
considerando T o número total de combinações, desta forma o programa P1 possui dezesseis
combinações.
24
Agora se identificam relacionamentos entre a entrada e as variáveis de saída para o
programa P1 como ilustra a Figura 4. Percebe-se que a saída W é uma função das entradas A e C, e
que a saída Z é uma função da entrada B.
A B C
W Z
Figura 4. Relacionamentos entre entrada e saída
Fonte: Schroeder e Korel (2000).
Tendo o relacionamento entre as entradas e as saídas, pode-se perceber que para a saída W
importa somente os valores da entrada A e C, a Tabela 7 apresenta os valores possíveis de entrada
para a saída W.
Tabela 7. Combinações para a saída W
Test ID Input A Input B Input C IO1 1.5 North TDC IO2 1.5 North BDM IO3 3.6 North TDC IO4 3.6 North BDM
Fonte: Schroeder e Korel (2000).
Para a saída Z leva-se em conta todos os valores possíveis da entrada B, conforme Tabela 8.
25
Tabela 8. Combinações para a saída Z
Test ID Input A Input B Input C IO5 1.5 North TDC IO6 1.5 South TDC IO7 1.5 East TDC IO8 1.5 West TDC
Fonte: Schroeder e Korel (2000).
Para criar um conjunto completo dos testes para o programa P1, deve-se unir as
combinações de entrada para a saída W com as combinações da saída Z. Neste momento já é visível
que as dezesseis combinações iniciais já diminuíram para 7 combinações.
Tabela 9. União do conjunto de combinações para a saída W e Z
Test ID Input A Input B Input C IO1 1.5 North TDC IO2 1.5 North BDM IO3 3.6 North TDC IO4 3.6 North BDM IO6 1.5 South TDC IO7 1.5 East TDC IO8 1.5 West TDC
Fonte: Schroeder e Korel (2000).
De acordo com os relacionamentos vistos na Figura 4 observa-se que o conjunto de
combinações apresentados na Tabela 9 ainda não é o mínimo possível, sendo assim a Tabela 10
apresenta o conjunto mínimo de combinações para o programa P1.
26
Tabela 10. Conjunto mínimo de testes para o programa P1
Test ID Input A Input B Input C MIN1 1.5 North TDC MIN2 1.5 South BDM MIN3 3.6 East TDC MIN4 3.6 West BDM
Fonte: Schroeder e Korel (2000).
Aplicando este método no exemplo do programa P1, foi possível reduzir 75% das
combinações. Conclui-se que realmente é um método considerável, mas que a localização do
conjunto mínimo de combinações não é uma tarefa trivial, sendo necessário o conhecimento de
todas as possíveis entradas e saídas do programa.
2.1.4 Categorias de Teste de Software
O processo de teste de software está classificado em várias categorias, que de acordo com
Bartié (2002, p.110), possibilita organizar melhor todo o planejamento dos testes, ampliando a
cobertura dos testes e aumentando a eficiência na detecção de defeitos:
• Teste de Funcionalidade: tem por objetivo simular todos os cenários de negócio e
garantir que todos os requisitos funcionais sejam implementados;
• Teste de Usabilidade: tem por objetivo simular as condições de utilização do software,
focalizam a facilidade de navegação entre as telas da aplicação, a clareza de textos e
mensagens que são apresentados ao usuário, a quantidade de interações para realizar
uma determinada função, padronização visual, dentre outros aspectos (BARTIÉ, 2002
p.114);
• Teste de Carga: simular condições anormais de utilização do software, realizando
aumento e reduções sucessivas de transações que superem os volumes máximos
previstos para o software e avaliando como o software e toda a infra-estrutura se
comportam. O objetivo é avaliar como todo o conjunto da solução se comporta com as
variações sucessivas de processamento;
• Teste de Volume: determina os limites de processamento e carga do software e de toda
infra-estrutura da solução, é exercitado através de incrementos sucessivos de volume das
27
operações realizadas com o software até atingir o limite máximo. O diferencial do teste
de carga, é que este não focaliza oscilações de processamento, mas o aumento contínuo
dos parâmetros de execução, a fim de conhecer os limites da solução;
• Teste de Configuração: executar o software sobre diversas configurações de software e
hardware, a fim de garantir que a solução rode nos ambientes previstos no levantamento
de requisitos;
• Teste de Compatibilidade: tem por objetivo executar o software interagindo com as
versões anteriores de outras aplicações ou dispositivos físicos, para garantir que as novas
versões suportam antigas interfaces;
• Teste de Segurança: avaliar o nível de segurança que toda a infra-estrutura oferece,
simulando situações que provocam quebra de protocolos de segurança, identificando
quais são os pontos de maior fragilidade e risco de ocorrerem ataques;
• Teste de Performance: definir se o desempenho nas situações previstas de pico máximo
de acesso e concorrência, está consistente com os requisitos definidos;
• Teste de Instalação: validar os procedimentos de instalação de uma aplicação, avaliar se
a instalação apresenta as várias alternativas previstas nos requisitos identificados;
• Teste de Confiabilidade e Disponibilidade: avaliar o nível de confiabilidade da
arquitetura da solução, confiabilidade está relacionada com a infra-estrutura e
disponibilidade com o tempo necessário para a resolução do problema;
• Teste de Recuperação: avaliar o comportamento do software após a ocorrência de erro
ou de determinadas condições anormais. Devem contemplar os procedimentos de
recuperação do estado inicial da transação interrompida, impedindo que determinados
processamentos sejam realizados pela metade; e
• Teste de Contingência: validar os procedimentos de contingência a serem aplicados à
determinada situação prevista no planejamento do software.
28
2.2 Ferramentas Similares
Em função do aumento das exigências dos usuários e a concorrência cada vez maior na área
de desenvolvimento de software, surge a necessidade de ferramentas que auxiliem os
desenvolvedores na produção de software de qualidade (PILLAT, FERREIRA e DIAS, 2004).
Moreira Filho e Rios (2003, p.152), citam alguns motivos que levaram ao surgimento de
ferramentas de automação de testes:
• Aumento do tempo requerido para os testes;
• Custo;
• Piora da qualidade dos sistemas produzidos; e
• Aumento das pressões sobre os projetos de desenvolvimento.
A automação de testes possui o objetivo de apoiar o processo de teste, reduzindo ou
eliminando as dificuldades existentes. Porém, o processo de automação vai muito além do que
simplesmente adquirir uma ferramenta. A organização que possuir interesse em automatizar esta
etapa do desenvolvimento deverá ter um processo formal de teste já consolidado e uma cultura
predisposta a aceitar regras que serão impostas pela utilização da ferramenta (MOREIRA FILHO e
RIOS, 2003). O mesmo autor classifica as ferramentas comerciais em três grupos:
• Ferramentas para o desenvolvimento dos testes: auxiliam no detalhamento dos planos de
testes, a geração dos dados e casos de testes;
• Ferramentas para execução dos testes: auxiliam na execução dos casos de testes e na
avaliação dos resultados. Geralmente utiliza “scripts”, que são programas escritos para
simular a operação do programa objeto de teste; e
• Ferramentas para acompanhamento e suporte dos testes: auxiliam no esforço geral dos
testes, não são ferramentas específicas de testes, normalmente fazem parte do processo
de controle de qualidade. Por exemplo: ferramentas de gerência de projetos, ferramentas
para rastreamento de defeitos, gerenciadores de banco de dados e processadores de
testes.
29
A ferramenta proposta neste TCC (Trabalho de Conclusão de Curso) irá conter componentes
de dois grupos, o de ferramentas para o desenvolvimento de testes e o de ferramentas para execução
dos testes. Encaixa-se no grupo de ferramentas para o desenvolvimento de testes, pois, permitirá ao
usuário o cadastro de casos de testes e a configuração da aplicação a ser testada. Classifica-se
também como ferramentas para execução dos testes, pois, após as configurações necessárias irá
executar os testes automaticamente.
Nas próximas seções são apresentadas as características de três ferramentas, e ao final
realizado uma análise comparativa entre elas.
2.2.1 TestComplete 3.11
A TestComplete é uma ferramenta de automação de testes, aplica testes de unidade,
funcional e de regressão. É desenvolvida pela empresa AutomatedQA Corporation, fundada em
1999 com matriz nos Estados Unidos (AUTOMATEDQA, 2005).
Segue algumas características e funcionalidades da ferramenta:
• Grava a interação do usuário com a interface do software, através dos eventos do mouse
e teclado, gerando scripts em delphi, visual basic e C;
• Permite criar ou alterar um script de teste;
• Reconhece variáveis e componentes da interface;
• Permitir realizar teste de carga e de escalabilidade de aplicações web;
• Permite gerar o resultado dos testes em arquivo com extensão HTML (Hyper Text
Markup Language) e XML (Extensible Markup Language), podendo assim incluir na
documentação do software;
• Permite depurar o script incluindo breakpoints; e
• Realiza testes em interfaces desktop e web.
O custo do TestComplete Enterprise V3.0 varia entre $ 779.99 até $2,437.49, dependendo
do número de licenças necessárias.
30
Foi aplicado testes com a ferramenta em aplicações desktop e web, a Figura 5 ilustra a
interface da ferramenta TestComplete, após a gravação do acesso ao portal do aluno da Univali
(Universidade do Vale do Itajaí).
Figura 5. Interface TestComplete
A TestComplete disponibiliza ao usuário a opção de gerar o script em três linguagens
diferentes, tornando esta funcionalidade uma vantagem e facilidade da ferramenta. A dificuldade
encontrada foi a localização de material e tutorial sobre a utilização da ferramenta.
2.2.2 QuickTest Professional 8.2
Esta ferramenta pertence a empresa Mercury Intercative Corporation, fundada em 1989
(MERCURY, 2005). A QuickTest é um módulo do suíte de testes, que segundo Moreira Filho e
Rios (2003, p. 161), “suíte é um conjunto de diferentes programas, geralmente integrados e
comercializados juntos”, o suíte de testes da QuickTest contém mais dois módulos:
31
• TestDirector: é o módulo gerenciador de testes e defeitos, controla o processo de testes
de “ponta-a-ponta”, garantindo que todos os requisitos dos usuários sejam cobertos pelos
casos de testes construídos; e
• LoadRunner: responsável pela automação de testes de desempenho, atendem aos testes
de carga e volume, a ferramenta permite a criação de um cenário para a execução dos
testes e monitora on-line os elementos envolvidos, como: servidores, banco de dados e
rede.
A QuickTest é uma ferramenta de automação de testes funcionais, ela grava a ação desejada
na aplicação, parametriza e em seguida executa o teste. Suas principais características e
funcionalidades são:
• Gera script da interação do usuário em VBScript;
• Permite incluir ou alterar o script;
• Realiza testes em interfaces web e desktop;
• Possibilita a depuração do script;
• Reconhece variáveis e componentes da interface;
• Após a execução apresenta um relatório com o resultado do teste;
• Permite cadastrar o executável ou browser a ser testado, desta forma o executa
automaticamente;
• Permite cadastrar parâmetros de entrada e saída; e
• Criptografa as senhas digitadas nas interfaces.
A Figura 6 apresenta a interface da aplicação, o quadrante superior é o script gerado após a
gravação de um acesso ao webmail da Univali, e o quadrante inferior corresponde a imagem da
linha selecionada no script.
32
Figura 6. Interface QuickTest
2.2.3 J-Fut
Esta é uma ferramenta acadêmica, apresentada no 19º Congresso Brasileiro de Engenharia
de Software. Realiza testes funcionais, é desenvolvida em Java e utiliza POA2 (Programação
Orientada a Aspectos). Não foi localizada versão disponível para demonstração. A J-Fut possui o
objetivo de apoiar o teste funcional de programas desenvolvidos em Java, possuindo as seguintes
características e funcionalidades:
• Oferece suporte as técnicas de particionamento de equivalência, análise de valor limite e
teste funcional sistemático3;
2 De acordo com Rocha et al. (2005), “ POA baseia-se no conceito de separação de interesses e busca identificar interesses que estão espalhados pelo código da aplicação e implementá-los como módulos separados (denominados aspectos).” 3 Segundo Rocha et al. (2005), o teste funcional sistemático é uma variação do método particionamento por equivalência que leva em consideração os domínios de entrada e saída, de acordo com um conjunto bem definido de regras.
33
• Permite que pré e pós condições do sistema sejam avaliadas;
• Permite efetivar as atividades básicas para a aplicação de critérios: instrumentação,
seleção, execução de casos de testes e análise de cobertura;
• Realiza teste funcional de unidade;
• Analisa o comportamento interno do programa identificando classes de equivalência de
uma operação;
• Não há acesso direto ao programa em teste e sua execução sempre é feita a partir dos
casos de teste implementados; e
• Os testes são feitos a partir de um projeto de teste, que armazena todos os dados
relativos ao teste, incluindo seu nome, classes e métodos em teste, bibliotecas
necessárias, requisitos de teste, condições de entrada e registro de execução.
A Figura 7 mostra o relatório de cobertura de condições de um caso de teste, nela é possível
observar as três condições de entrada e as seis classes de equivalência implementadas para o teste
da aplicação.
34
Figura 7. Interface J-Fut – Cobertura de condições de entradas
Fonte: Rocha et al. (2005).
2.2.4 Análise Comparativa
A Tabela 11 mostra uma análise comparativa entre as três ferramentas estudadas:
TestComplete, QuickTest e J-Fut, e a ferramenta desenvolvida neste projeto, a TestWare. Os
critérios de comparação relacionam-se com o conteúdo visto neste trabalho, ou seja, com as fases de
testes, técnicas, categorias, métodos, dentre outras características importantes que uma ferramenta
de automação de testes deve possuir.
35
Tabela 11. Análise comparativa entre ferramentas similares
Características TestComplete QuickTest J-Fut TestWare Realiza testes de quais fases (Unidade, Integração, Sistema e Aceitação)
- Teste de unidade - Teste de integração
- Teste de unidade - Teste de integração
- Teste de unidade
- Teste de integração
Tipos de Teste (Caixa Branca e Caixa Preta)
Caixa Preta Caixa Preta - Caixa Preta e Branca
- Caixa Preta
Método de caixa preta abordado
- nenhum - nenhum - Particiona- mento de equivalência - Teste funcional sistemático - Análise de valor limite
- Particiona-mento de equivalência - Análise de valor limite
Categorias de Testes - funcional - regressão - carga - escalabilidade
- funcional - volume - carga
- funcional - funcional - volume - regressão
Classificação da ferramenta
- execução dos testes
- execução dos testes
-desenvolvi-mento dos testes - execução dos testes
-desenvolvi-mento dos testes - execução dos testes
Tipo de aplicações testadas
-web - desktop
-web - desktop
- desktop escritas em Java
- desktop indepentente da linguagem
Formato de entrada dos casos de testes
- script - script - base de casos - base de casos - script
Resultado ao usuário - interface e gera arquivo de log em HTML e XML
- interface e gera arquivo de log
- interface - interface
A partir da comparação percebe-se que a TestComplete e a QuickTest apresentam
praticamente as mesmas características. As duas gravam a iteração do usuário com a interface em
script, após executa o teste, e apresenta relatórios de logs. Estas ferramentas são comerciais e
apresentam um custo elevado. Possuem versão trial para download, para a realização desta análise
comparativa foram aplicados diversos testes, com aplicações web e desktop.
Já a ferramenta acadêmica J-Fut implementa dois métodos de caixa preta, o método de
particionamento de equivalência e o método de análise de valor limite, através destes métodos gera
uma base de casos de testes e os executa. Uma grande desvantagem da J-Fut é testar somente
programas com interface desktop e aplicações implementadas na linguagem Java.
36
Com a pesquisa feita sobre ferramentas de automação de testes, conclui-se que existem
algumas opções já em comercialização ou em desenvolvimento através de projetos de pesquisa,
porém, não foi encontrado nenhuma que tenha as mesmas especificações da ferramenta que
construída, contudo, pode-se afirmar que auxiliaram no projeto, fornecendo novas idéias, a
organização do script, aplicação dos conceitos de teste utilizadas por elas, dentre outros. A
TestComplete ou a QuickTest poderiam ser utilizadas na automação dos testes do software ItlSys,
entretanto, possuem um custo elevado à organização e além do que não auxilia na construção de
casos de teste aplicando diretrizes de caixa preta, permitindo assim que sejam criados testes que não
abrangem as possibilidades mínimas para a detecção de erro, ou ainda, que sejam criados casos de
testes desnecessários, prejudicando a produtividade e prazo de entrega do produto.
2.3 Software ItlSys
Para o contexto do presente trabalho faz-se importante descrever informações sobre o
software em que a ferramenta irá atuar. Portanto, o principal foco de testes da ferramenta será o
software ItlSys. Este produto pertence a empresa Intelidata Informática Ltda, com sede em Brusque
– SC. A Intelidata é uma empresa de desenvolvimento de sistemas, está no ramo desde 1996 e conta
com 8 profissionais qualificados. Possui clientes no estado de Santa Catarina e também na região
norte e nordeste do Brasil (INTELIDATA, 2005).
O Itlsys é um sistema ERP voltado a empresas de comércio varejista e atacadista.
Disponibiliza atualmente 34 módulos, divididos em 7 gestões, conforme organograma da Figura 8:
37
Figura 8. Organograma Software ItlSys
O IltSys é desenvolvido com a ferramenta CASE Genexus, da empresa Uruguaia Artech, e é
gerado na linguagem Visual Basic Studio 6.0. Suporta os seguintes bancos de dados: IBM DB2
UDB, Informix, Microsoft SQL Server, Oracle, PostgreSQL e MySQL.
Para ter acesso ao ItlSys é necessário possuir um código de usuário e senha, devidamente
cadastrado no sistema, fornecendo assim segurança dos dados, cada usuário possui um perfil, onde
está configurado quais os programas e acessos aquele determinado usuário possui. A Figura 9
mostra a tela inicial do sistema, nela consta a versão do software, a conexão que deseja-se
autenticar, o código do usuário e a sua senha.
38
Figura 9. Tela Inicial do ItlSys
Após o usuário e a senha serem validados pelo sistema é aberto o menu, onde constam todos
os programas disponíveis para o usuário autenticado, conforme ilustra a Figura 10.
O menu é divido em módulos, cada módulo possui um sub-módulo que é a administração do
módulo selecionado. No lado direito da tela encontram-se os programas e relatórios disponíveis. A
hierarquia do menu é do tipo árvore.
39
Figura 10. Menu do ItlSys
Pelo fato do ItlSys ser um software voltado a área comercial, o ponto crítico deste sistema é
o módulo de caixa, pois, em uma empresa comercial o caixa jamais pode parar de funcionar, é o
coração do sistema. Tendo em vista a importância deste programa ele será utilizado como estudo de
caso neste trabalho de conclusão. Algumas características deste módulo são:
• Recebimento e pagamento do cartão fidelidade;
• Vendas de vales-presente;
• Suporta a maioria dos modelos de ECF (Emissor de Cupom Fiscal) do mercado;
• Suporta TEF (Transferência Eletrônica de Fundos) dedicado e TEF discado; e
• Integração com Serasa e SPC (Serviço Proteção ao Crédito).
Salienta-se que o estudo de caso será realizado apenas com vendas de mercadorias, não
serão exercitadas vendas de vale presente e pagamento do cartão fidelidade. As vendas serão
40
testadas sem a conexão com a impressora fiscal, tendo em vista, não possuir uma impressora fiscal
disponível para a apresentação do estudo de caso à banca avaliadora, assim, o TEF será avaliado
apenas de forma manual, considerando vendas com TEF discado.
Na Figura 11 e na Figura 12 apresenta-se uma operação de venda no módulo do caixa,
primeiramente o operador do caixa digita os itens e sua quantidade correspondente, o sistema
totaliza e apresenta o valor na tela.
Figura 11. Interface do Caixa do ItlSys
Após a digitação de todos os itens adquiridos é o momento de finalizar a venda, existem
diversos finalizadores, por exemplo: dinheiro, cheque, cartão de compras e cartão de crédito, de
acordo com as regras de negócio da empresa. A Figura 12 mostra um exemplo com a venda
finalizada em dinheiro.
41
Figura 12. Interface para finalizar a venda do ItlSys
No caixa existem inúmeros fluxos diferentes para a realização de uma venda, tornando os
testes complexos e cansativos quando realizados manualmente, sendo uma constante preocupação a
cada liberação de versão. Assim, o estudo de caso para a validação da ferramenta desenvolvida
neste projeto será aplicado neste módulo.
3 PROJETO
Este capítulo destina-se a especificação do projeto proposto, utilizando a notação UML. A
UML é uma linguagem destinada a visualizar, especificar, construir e documentar os artefatos de
sistemas de software (BOOCH, JACOBSON e RUMBAUGH, 1997 apud LARMAN, 2000).
Primeiramente é descrita a análise de requisitos, a fim de possibilitar uma visão geral da
ferramenta, após são especificados os diagramas de caso de uso e diagrama de classes. Além destes
diagramas da UML é apresentada a especificação da estrutura de armazenamento dos dados da
ferramenta através do XML Schema.
Concluída a modelagem do sistema, é detalhada a etapa de implementação, enfatizando as
técnicas e tecnologias utilitizadas em cada etapa. E para finalizar, o sistema é demonstrado passo a
passo através do estudo de caso do módulo caixa do software ItlSys.
3.1 Requisitos
Os requisitos são uma descrição das necessidades do sistema que se pretende construir, nesta
fase o objetivo é identificar e documentar o que é realmente necessário, com uma comunicação
clara que seja compreendida ao cliente e as pessoas envolvidas ao projeto (LARMAN, 2000, p.60).
3.1.1 Requisitos Funcionais
Os requisitos funcionais especificam todas as “coisas” que o sistema deve fazer, Paula Filho
(2001) cita que os requisitos funcionais descrevem as funções que o produto deverá realizar em
benefício dos clientes. Os requisitos funcionais da ferramenta proposta são:
• RF01: a ferramenta deverá possibilitar criar projetos para teste;
• RF02: permitir a definição e validação de um script, sendo este o roteiro de execução da
aplicação a se testar;
• RF03: a ferramenta deverá permitir a inclusão, alteração e exclusão de valores para teste;
• RF04: a ferramenta deverá executar o teste automaticamente;
• RF05: permitir ao usuário informar, para cada caso de teste executado, a ação /
comportamento do aplicativo testado; e
43
• RF06: possibilitar a reprodução do teste.
3.1.2 Requisitos Não Funcionais
Os requisitos não funcionais são restrições sobre como o sistema deve realizar seus
requisitos funcionais, eles são obrigatórios. Paula Filho (2001) complementa que os requisitos não
funcionais devem ser enunciados de forma precisa e quantitativa, mesmo sendo difícil formular
valores na primeira versão do software. Os requisitos não funcionais da ferramenta proposta são:
• RNF01: a ferramenta deverá utilizar classes geradas no GALS (Gerador de Analisadores
Léxicos e Sintáticos), com a implementação do analisador léxico e sintático para
possibilitar a interpretação dos scripts;
• RNF02: a ferramenta deverá utilizar estrutura de armazenamento de dados em XML
Schema;
• RNF03: o usuário que irá criar os projetos deverá possuir conhecimento de lógica de
programação; e
• RNF04: apresentar dicas ao usuário referente as diretrizes dos métodos de
particionamento por equivalência e análise de valor limite.
3.1.3 Regras de Negócio
Regras de negócio são declarações que definem ou restringem algum aspecto do negócio,
seu principal objetivo é estabelecer a estrutura controlando o comportamento do negócio (META et
al. 1999 apud KLINGER e KROTH, 2001). As regras de negócio da ferramenta proposta são:
• RN01: o aplicativo a ser testado deverá possuir todas as funcionalidades com acesso
através do teclado;
• RN02: os casos de testes 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, após serão exercitadas as opções inválidas de cada campo, sendo para os
demais campos utilizados valores válidos. A aplicação irá gerar casos de teste para todos
os valores cadastrados na aplicação, sempre exercitando um campo de cada vez e para os
demais aplicando valores válidos;
44
• RN03: a definição dos valores para teste se dará a partir dos campos de entrada definidos
no script; e
• RN04: nos aplicativos que possuam campos iterativos poderá ser aplicado o teste de
volume, para isto, será necessário estarem identificados com uma sintaxe específica no
script (detalhes na Seção 3.5) e também informado o valor máximo de iterações a ser
aplicado. Desta forma, será criado um caso de teste separadamente para testar esta
condição.
3.2 Casos de Uso
Os casos de uso melhoram a compreensão da análise de requisitos, são documentos
narrativos que descrevem a seqüência de eventos de um ator que usa um sistema para completar um
processo (JACOBSON et al. 1992 apud LARMAN, 2000). A Figura 13 apresenta o modelo de
casos de uso da ferramenta proposta.
ud Casos de Uso
UC 06 - Reproduz
Teste
Testador
UC 01 - Mantém
Projeto
UC 03 - Mantém
Valores para Teste
UC 02 - Mantém
Script
UC 05 - Executa
Teste
UC 04 - Gera
Casos de Teste
Figura 13. Modelo de Casos de Uso
O diagrama de caso de uso deste projeto contém seis casos de uso e um ator denominado
testador. O ator será responsável por configurar a ferramenta, interagindo com os casos de uso UC
01, UC 02, UC 03 e UC 04, somente com a conclusão destes quatros casos de uso será permitido
45
utilizar o UC 05 para a execução dos testes, após a execução será exibido o relatório de resultados
possibilitando então a reprodução do teste UC 06.
Nas seções subseqüentes são apresentados os casos de uso individualmente, com uma breve
descrição do caso de uso, o relacionando com os requisitos e regras de negócios, as pré e pós
condições .
3.2.1 UC 01 – Mantém Projeto
Este caso de uso é responsável por manter os projetos de teste, é o primeiro passo a ser
configurado pelo ator, nele serão cadastradas informações gerais sobre a aplicação que será testada.
Relações:
• RF01: a ferramenta deverá possibilitar criar projetos para teste; e
• RNF03: o usuário que irá criar os projetos deverá possuir conhecimento de lógica de
programação.
Condições:
• Pós Condição: um projeto foi criado.
3.2.2 UC 02 – Mantém Script
Caso de uso responsável pela edição e validação do script. O script é o roteiro de execução
da aplicação a se testar, nele constará a seqüência de execução, os campos de entradas, o comando
para navegação entre os campos, condições, laços dentre outros. O script terá uma sintaxe própria
que será ilustrado na Seção 3.5.
Após a edição do script o sistema deverá validá-lo, caso localize alguma inconsistência
deverá apresentar ao testador qual foi o erro encontrado e em qual linha se localiza, permitindo ao
testador alterá-lo e revalidá-lo. Somente será permitida a inclusão de valores para teste quando o
script estiver correto.
Relações:
• RF02: permitir a definição e validação de um script, sendo este o roteiro de execução da
aplicação a se testar; e
46
• RNF01: a ferramenta deverá utilizar classes geradas no Gals, com a implementação do
analisador léxico e sintático para possibilitar a interpretação dos scripts.
Condições:
• Pré Condição: um projeto já deve ter sido configurado; e
• Pós Condição: um script foi validado.
3.2.3 UC 03 – Mantém Valores para Teste
Quando o script estiver finalizado e validado a ferramenta irá solicitar que para cada campo
de entrada identificado sejam cadastrados os valores para teste. Neste caso de uso o testador irá
informar se o campo de entrada é do tipo intervalo, valor, conjunto ou booleano, e a partir desta
informação será sugerido ao usuário cadastrar valores de acordo com as diretrizes dos métodos de
particionamento por equivalência e análise de valor limite. Se através do script for identificado que
deve-se aplicar o teste de volume para determinado campo, a aplicação irá solicitar o cadastro da
quantidade máxima de iterações a ser aplicada no teste de volume.
Após as configurações gerais do campo deve-se cadastrar valores válidos e inválidos,
possibilitando a geração dos casos de testes, caso o valor do campo seja inválido a aplicação a ser
testada deverá exibir uma mensagem de aviso na tela.
Relações:
• RF03: a ferramenta deverá permitir a inclusão, alteração e exclusão de valores para
teste;
• RNF04: apresentar dicas ao usuário referente as diretrizes dos métodos de
particionamento por equivalência e análise de valor limite; e
• RN03: a definição dos valores para teste se dará a partir dos campos de entrada definidos
no script.
Condições:
• Pré Condição: um script ter sido criado e validado; e
• Pós Condição: valores para testes foram criados.
47
3.2.4 UC 04 – Gera Casos de Teste
A partir do script e dos valores cadastrados para cada campo, este caso de uso produz os
casos de teste. A quantidade de casos gerados está relacionado, com a quantidade de campos que a
aplicação em teste possui, com a quantidade de valores cadastrados para cada campo e também com
a existência ou não de campos que serão aplicados teste de volume.
Relações:
• RN02: os casos de testes 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, após serão exercitadas as opções inválidas de cada campo, sendo para os
demais campos utilizados valores válidos. A aplicação irá gerar casos de teste para todos
os valores cadastrados na aplicação, sempre exercitando um campo de cada vez e para os
demais aplicando valores válidos; e
• RN04: nos aplicativos que possuam campos iterativos poderá ser aplicado o teste de
volume, para isto, será necessário estarem identificados com uma sintaxe específica no
script (detalhes na Seção 3.5) e também informado o valor máximo de iterações a ser
aplicado. Desta forma, será criado um caso de teste separadamente para testar esta
condição; e
• RF05: permitir ao usuário informar, para cada caso de teste executado, a ação /
comportamento do aplicativo testado.
Condições:
• Pré Condição: valores para teste criados; e
• Pós Condição: casos de teste foram gerados.
3.2.5 UC 05 – Executa Teste
Caso de uso responsável por executar o teste. Antes da execução dos testes será validado se
todos os casos de uso anteriores foram definidos corretamente. Após a execução o testador deverá
informar qual foi o resultado do teste, poderá também fazer uma breve consideração sobre o caso
aplicado. Os resultados possíveis de um caso de teste são:
48
• Sucesso:
O caso de teste foi concluído com sucesso, considerando valores válidos parar todos
os campos de entrada; ou
O caso de teste não foi concluído, pois utilizou-se valores inválidos.
• Erro:
O caso de teste foi concluído, tendo utilizado valor inválido; ou
O caso de teste não concluiu, utilizando todos os valores válidos.
• Timeout:
A aplicação travou.
Relações:
• RF04: a ferramenta deverá executar o teste automaticamente.
Condições:
• Pré Condição: casos de teste gerados; e
• Pós Condição: aplicação testada.
3.2.6 UC 06 – Reproduz Teste
Após a execução dos testes, será exibido na interface da ferramenta o log dos casos de testes
aplicados, permitindo ao ator reproduzi-los.
Relações:
• RF06: possibilitar a reprodução do teste.
Condições:
• Pré Condição: o teste ter sido executado; e
• Pós Condição: resultados dos testes.
49
3.3 Diagrama de Classes
Segundo Furlan (1998), “o diagrama de classes trata-se de uma estrutura lógica estática em
uma superfície de duas dimensões mostrando uma coleção de elementos declarativos de modelo,
como classes, tipos e seus respectivos conteúdos e relações”. A Figura 14 apresenta o diagrama de
classes de domínio da ferramenta proposta.
cd Diagrama de Classes
Projeto
- nome: string
- aplic_testar: string
- obs: string
- script: texto
Valor_de_Teste
- campo: string
- tipo_dado: Tipo_Dado
- teste_volume: int
Execucao
- dat_ini: datetime
- dat_fim: datetime
«enumeration»
Status
- sucesso:
- timeout:
- erro:
Caso_de_Teste
- status: Status
- descrição: string
«enumeration»
Tipo_Dado
- intervalo:
- valor:
- conjunto:
- booleano:
Analisador_Script
+ UAnalysisError
+ UConstants
+ ULexicalError
+ ULexico
+ USemanticError
+ USemantico
+ USintatico
+ USyntactError
+ UToken
Configuracao
- tempo_app: integer
- tempo_campo: integer Valor_Campo
- valor: string
- situacao: boolean
Teclas
- nome: string
- comando: byte
1 1..*
1
0..*
1
11
1..*
1
1
1
1..*
1..* 0..*
Figura 14. Diagrama de Classes
O diagrama de classes da ferramenta possui sete classes relacionadas entre si, conforme
detalhamento:
• Projeto: é a classe principal da ferramenta, contém informações gerais referente ao
projeto;
50
• Valor de Teste: esta classe possui informação referente aos campos de entrada da
aplicação em teste;
• Valor_Campo: valores a serem testados para cada campo de entrada da aplicação;
• Execução: é a classe que possui dados sobre a execução do teste;
• Caso_de_Teste: esta classe contém o status e considerações referente a 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 para a
aplicação em teste carregar e intervalo de tempo para envio de dados de um campo para
outro;
• Teclas: classe com o código ASCII (American Standard Code for Information
Interchange) correspondente aos comandos utilizados no script, por exemplo: enter, F1,
F2, tab, etc.
Como já foi dito anteriormente, a ferramenta terá que interpretar um script (abordado na
Seção 3.5) ou linguagem própria, para que isto ocorra, será necessário utilizar as classes geradas
pela ferramenta GALS, que estão representadas no diagrama pelo pacote de classes
Analisador_script. Ele contém as classes responsáveis pela análise léxica, sintática e semântica do
script, o detalhamento e relacionamento das classes podem ser vistos em Seára (2005, p.44) .
O GALS foi desenvolvido por Carlos Eduardo Gesser em seu Trabalho de Conclusão de
Curso. De acordo com Gesser (2003) é uma ferramenta para geração automática de analisadores
léxicos e sintáticos.
No GALS serão descritos os tokens e a gramática da linguagem (informações na Seção 4.1)
depois de validado será gerado o código em Delphi, as classes geradas serão utilizadas pela
ferramenta para a realização da análise léxica e sintática. Destacando que a análise semântica será
implementada pela ferramenta deste projeto.
3.4 XML Schema
Para Maia (2005) um esquema XML descreve a estrutura de um documento XML, ele
possui o propósito de definir os blocos de construção permitidos em documentos XML. O
documento XML oferece uma forma padrão de codificar, cria estruturas de dados flexíveis,
51
utilizando metáfora de marcas de elementos para marcar conteúdo tendo como base um conjunto de
regras que o autor do documento criou (MOULTIS e KIRK, 2000).
A estrutura de armazenamento de dados deste projeto será através do XML Schema, para
fins de validação da estrutura e do conteúdo do documento XML. Para facilitar a compreensão, o
XML Schema será apresentado em forma de diagrama, a partir da notação utilizada pela ferramenta
XML Spy. Em Kokubo (2004, p.17) encontra-se uma explicação detalhada sobre cada um dos
estereótipos que compõem a notação. Além do diagrama, o Apêndice A apresenta o código fonte do
XML Schema da ferramenta proposta.
A Figura 15 mostra uma visão geral do XML Schema construído para validação do
documento XML. Neste diagrama é possível visualizar todos os elementos do documento e seus
relacionamentos.
Figura 15. Visão geral do XML Schema
3.5 Estrutura do Script
O script têm o objetivo de apresentar o roteiro de execução da ferramenta a se testar. Sua
gramática foi escrita e validada na ferramenta Gals, que gerou as classes ULexico e USintatico com
52
a implementação do analisador léxico e sintático respectivamente, que por sua vez foram
incorporadas a ferramenta.
A Figura 16 exibe um modelo de script para executar o programa caixa do software ItlSys,
abordado na Figura 11 e Figura 12 da Seção 2.3.
inicio_script
enquanto testevolume faca
inicio_enquanto
escreva produto
comando ENTER
fim_enquanto
comando F3
escreva guia
comando TAB
escrevaconst "D"
comando TAB
valor:= captura(311,134)
valor:= valor/2
escrevavar valor
comando TAB
comando ENTER
escrevaconst "Pre"
comando TAB
escreva cliente
comando TAB
escreva condicao_pgto
comando TAB
escreva parcelamento
comando TAB
comando TAB
comando ENTER
escreva cmc7
comando ENTER
comando ESC
comando ENTER
fim_script
Figura 16. Exemplo de Script
A sintaxe do script interpretado pela ferramenta consiste em um conjunto de instruções
simples, segue explicação dos comandos aceitos na Tabela 12.
53
Tabela 12. Instruções da gramática do script
Instrução Descrição inicio_script Primeira instrução do script e indica que ele foi inicializado, uma
instrução importante levando em consideração a implementação de diversos scripts no mesmo projeto.
enquanto testevolume faca
Esta instrução deve ser utilizada para campos iterativos, por exemplo, o campo código de produto, em um sistema de caixa, na validação do script serão identificados os campos de entrada que estiverem dentro deste laço e solicitado o cadastrado da quantidade máxima de iterações desejadas para a aplicação do teste de volume, e para os demais casos de teste será realizado um random de dez.
inicio_enquanto Identifica que o laço enquanto foi inicializado.
escreva Esta é uma das instruções mais utilizadas na sintaxe do script, pois, declara os campos de entrada existentes no aplicativo em teste.
comando Define a tecla utilizada para navegação entre os campos, por exemplo: “tab”, “enter”, “esc”, “alt+i”, dentre outras. Os códigos ASCII destas teclas devem estar devidamente cadastrados na ferramenta.
fim_enquanto Marca o final do laço enquanto.
escrevaconst Instrução utilizada para enviar a aplicação valores / texto exatos, no exemplo do caixa foi usado para selecionar o finalizar da venda, um campo do tipo combobox.
captura(x,y) Função que retorna uma string contendo o valor / texto de determinada posição da tela.
:= Atribui um valor inteiro a uma determinada variável.
escrevavar Envia a aplicação o valor de uma variável interna do script.
ALT#A Envia uma combinação de teclas para a aplicação.
fim_script Identifica o término do script.
54
4 DESENVOLVIMENTO
Esta fase dividiu-se, basicamente, em três etapas: implementar o reconhecedor da linguagem
do script; implementar a estrutura de dados da ferramenta; e por fim, unificar as etapas anteriores e
implementar a interface e funcionalidades necessárias a ferramenta de automação de teste de
software, denominada TestWare. As próximas seções detalham as etapas da implementação.
4.1 Reconhecedor do Script
Utilizando-se do gerador de analisadores léxicos e sintáticos – GALS, a construção da
gramática foi desenvolvida. A sintaxe foi formulada a partir do roteiro de execução dos programas
do sistema ItlSys e de um programa de cadastro de clientes4, desenvolvido em Delphi. Durante toda
a fase de implementação a gramática sofreu modificações, visto que, surgiam situações ainda não
previstas.
De forma geral, no GALS a criação do analisador dá-se através da definição das expressões
regulares, tokens e por final a formação da gramática, conforme demonstra a Figura 17.
4 Programa implementado apenas visando validar a ferramenta, com um software mais simples.
55
Definições Regulares
L:[a-z A-Z]
D:[0-9]
R : [0-9]+ \. [0-9]+
T : \" [^ \"]* \"
COMMENT : [";;"][";;"] [^ \n ]*
WS: [\ \n\t\r\s]
Tokens
id: {L}+ ({L} | {D} | "_" | "#")*
num: {D} | {R} //coordenadas da tela
texto :! {T}*
operlog: ">" | "<" | "=" | "<>" | ">=" |<="
"("
")"
":="
","
"+"
"-"
"*"
"/"
//Palavras reservadas
inicio_script=id: "inicio_script"
fim_script=id: "fim_script"
escreva=id: "escreva"
escrevaconst=id: "escrevaconst"
escrevavar=id: "escrevavar"
comando=id: "comando"
captura=id: "captura"
se=id: "se"
entao=id: "entao"
inicio_se=id: "inicio_se"
fim_se=id: "fim_se"
enquanto=id: "enquanto"
testevolume=id: "testevolume"
faca=id: "faca"
inicio_enquanto=id: "inicio_enquanto"
fim_enquanto=id: "fim_enquanto"
: {WS}+
coment :{COMMENT}
Gramática
<PROG> ::= inicio_script <BLOCO>
fim_script
;
<BLOCO> ::= <INSTR> | <BLOCO> <INSTR>
;
<INSTR> ::= <CMD> | <ATRIB> | <LACO>
;
<CMD> ::= escreva id#1 | comando id#2 |
escrevaconst texto | escrevavar id
;
<ATRIB> ::= id ":= " captura
"("num","num")" | id ":= " <EXPARIT>
;
<LACO> ::= se <EXP> entao inicio_se
<BLOCO> fim_se | enquanto <EXP> faca
inicio_enquanto <BLOCO> fim_enquanto#4
;
<EXP> ::= id operlog texto |
testevolume#3
;
<EXPARIT>::= <ADICAO> | <SUBTRACAO> |
<MULTI> | <DIV>
;
<ADICAO> ::= id "+" num | num "+" id | id
"+" id | num "+" num
;
<SUBTRACAO> ::= id "-" num | num "-" id |
id "-" id | num "-" num
;
<MULTI> ::= id "*" num | num "*" id | id
"*" id | num "*" num
;
<DIV> ::= id "/" num | num "/" id | id "/"
id | num "/" num
;
Figura 17. Definições Regulares, tokens e gramática do Script
A classe ULexico (apresentada no diagrama de classes, Seção 3.3) gerada pelo GALS foi
modificada, para possibilitar a apresentação do número da linha quando ocorrer um erro léxico,
sintático ou semântico. Enfatiza-se que a implementação da análise semântica foi de total
responsabilidade do projeto.
4.2 Estrutura de Dados do Sistema
O acesso e armazenamento dos dados originaram-se através de um recurso chamado XML
Data Binding, este recurso está integrado com o IDE (Integrated Development Environment)
Borland Delphi 7 e com base no XML Schema gera o código fonte para leitura e escrita no
documento XML, e com o auxílio do componente XmlDocument é possível realizar a integração da
ferramenta com o documento XML. A Figura 18 exibe a criação do código fonte a partir do XML
Schema deste projeto.
56
Figura 18. Interface do XML Data Binding
4.3 Implementação da Ferramenta
O desenvolvimento da ferramenta foi realizado com a IDE Borland Delphi 7. Em geral, a
implementação ficou dividida em três grandes atividades:
• A primeira e mais simples foi a criação da interface para a configuração da ferramenta;
• A segunda e mais árdua foi o estudo dirigido a API (Application Programming Interfaces)
do Windows, que segundo Richter (1995), é um conjunto de funções disponíveis para serem
utilizadas pelo seu código-fonte, objetivando o entendimento da comunicação entre as
aplicações com o sistema operacional, a fim de possibilitar a captura do resultado do teste
sem o auxílio do testador; e
• A última etapa foi a integração do script com os valores cadastrados para o teste resultando
na geração dos casos de teste, a execução dos casos gerados e após a reprodução dos
mesmos.
57
4.4 Ferramenta TestWare
A TestWare é uma ferramenta para automação de teste de caixa preta, destinada para
empresas ou setores na área de desenvolvimento de sistemas. Seu objetivo principal é a redução de
custo, tempo e conseqüentemente esforço na etapa de teste de software, e ainda, contribuir para a
qualidade do produto.
A TestWare foi desenvolvida fundamentada nos conceitos de teste de software, desta
maneira, inicialmente deve-se contextualizar a ferramenta dentro de um processo de teste de
software.
4.4.1 TestWare no Processo de Teste de Software
O processo de teste de software, conforme descrito na Seção 2.1.1 de forma geral possui
quatro etapas: (i) planejamento; (ii) projeto; (iii) implementação; e (iv) execução.
Na etapa inicial, Pfleeger (2004, p.299) salienta que “o planejamento cuidadoso ajuda a
projetar e organizar os testes, de forma a nos dar segurança de estarmos realizando os testes
adequadamente”, com esta afirmação conclui-se que o sucesso dos testes está diretamente
relacionado com esta etapa. Neste momento o testador deve fazer o cronograma do teste, verificar
pessoas, recursos de software e hardware envolvidos, desta forma, a TestWare não é utilizada, pois,
este ainda é o momento de planejar e documentar.
No projeto identifica-se características a serem testadas e os casos de teste associados, o
projeto pode ser iniciado antes mesmo do término da implementação do sistema, desde que, exista
documentação do sistema, por exemplo: definição de requisitos, casos de uso e protótipos de tela.
Nesta etapa a TestWare é de suma importância, é o momento de configurar a ferramenta,
cadastrando informações gerais do projeto, escrevendo o roteiro de execução e cadastrando os
valores para teste. Vale a pena enfatizar que os valores cadastrados para teste devem ser
cuidadosamente selecionados, para que validem diferentes aspectos, de modo que os casos de testes
cubram todas as situações possíveis (a Seção 2.1.3.2 expõe diretrizes para seleção de valores de
teste de caixa preta). Após a configuração da ferramenta os casos de teste são gerados
automaticamente.
A etapa de implementação é destinada a preparação do ambiente para a realização do teste.
Prepara-se tanto o ambiente de hardware quanto de software, disponibilizando os recursos,
58
instalando e configurando os itens necessários. A TestWare não está diretamente relacionada com
esta etapa, mas, deve-se preparar o ambiente, instalar e configurar a aplicação a testar, banco de
dados, dentre outros, para que a TestWare execute com sucesso.
E por fim, na etapa de execução, os testes são efetuados e os relatórios gerados, a TestWare
através dos casos de testes gerados os executa automaticamente, após a execução o testador cadastra
o resultado do teste aplicado e os relatórios ficam disponíveis para impressão e análise.
4.4.2 ItlSys - Estudo de Caso
Conforme já foi descrito anteriormente, a validação da ferramenta se realizará através do
módulo caixa do software ItlSys. O caixa é um sistema complexo, pois, possui diversas
ramificações. Neste projeto é testada uma venda, onde o cliente irá efetuar o pagamento em
dinheiro e cheque pré-datado.
Para englobar todos os caminhos possíveis deste módulo faz-se necessário a criação de
diversos scripts. Com a finalidade de demonstrar o funcionamento da TestWare a Seção 4.4.3 irá
apresentar a criação e configuração de um projeto que irá automatizar o teste do caixa.
4.4.3 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.
59
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
60
venda, como por exemplo: utilizar outros tipos de finalizadores5, 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
5 Finalizador é a forma de pagamento, como por exemplo: dinheiro; cheque; cartão de crédito; documento de devolução; dentre outras. Em uma venda é possível utilizar até 7 formas de pagamentos.
61
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
“Gerar”, e os casos de teste são gerados automaticamente, de acordo com as regras descritas nos
requisitos não funcionais 02 e 04. Neste estudo de caso, foram gerados 15 casos de teste (exibidos
62
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
execução clicando no ícone stop ou pause.
63
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.
64
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.
65
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
do caixa fechou deixando a operação da venda não concluída.
66
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.
67
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.
68
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.
69
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
cadastro de valores para teste; e as mensagens de erros ocorrem no momento da gravação do
cadastro e não após sair do campo como nos programas do ItlSys.
70
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.
71
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.
5.1 Dificuldades encontradas
Inicialmente desejava-se obter o resultado do teste automaticamente, para isto, foi realizado
o estudo da API do Windows, a idéia inicial era interceptar todas as mensagens que a aplicação em
teste passa para o Windows, através da API WndProc, porém, para interceptar estas mensagens faz-
se necessário a instalação de uma DLL (Dynamic Link Libraries) no espaço de endereçamento do
programa em teste, além desta dificuldade seria necessário analisar mensagem por mensagem a fim
de identificar quando a aplicação em teste comporta-se de uma maneira não esperada.
Ainda durante a pesquisa foi localizada a biblioteca ApiHook, que segundo Stuani (2006),
ela se instala nos outros processos, intercepta as funções que estes processos chamam e têm acesso
a todos os parâmetros passados para as funções, podendo ainda alterá-los. Com a utilização desta
API vou possível desviar a mensagem que seria encaminhada para a função MessageBoxA da
User32.dll para a DLL da TestWare, porém, desta forma, a TestWare não conseguiria diferenciar
um simples aviso de um erro, pois, nos dois casos a MessageBoxA é chamada e ainda as mensagens
do sistema ItlSys não eram interceptadas, pois, a linguagem em que ele é desenvolvida Visual Basic
não utiliza a API do Windows para exibir mensagens. Tendo em vista todas estas dificuldades e o
72
fato de que para identificar o resultado teria que impor muitas restrições na aplicação em teste, ou
ainda, desenvolver uma ferramenta muito específica para o ItlSys optou-se que o resultado do teste
seria informado pelo testador, assim, a TestWare torna-se uma ferramenta mais genérica podendo
ser útil para outros aplicativos.
5.2 Trabalhos Futuros
Pode-se dizer que este trabalho de conclusão de curso foi de extrema importância e o seu
resultado satisfatório, foi possível construir uma ferramenta para auxiliar na etapa de teste de
software, como foi evidenciado através da sua validação no estudo de caso. E a partir desta
ferramenta surgem diversas idéias para aperfeiçoá-la, conforme segue:
• Gravação de macro: além do roteiro de execução (script) permitir realizar a gravação
da execução, considera-se útil no caso de se testar um programa através do menu,
desta forma, a gravação do usuário, senha, navegação pelo menu, seria gravada pelo
macro e após o script seria executado;
• Sub-Projetos: permitir a criação de sub-projetos, por exemplo: criar um projeto pai
“módulo caixa” e dentro dele teria diversos sub-projetos de todos os programas que
pertencem ao módulo caixa; e
• Vários scripts: permitir a criação de diversos scripts por projeto. Como citado
anteriormente, para testar o programa caixa por completo seria necessário diversos
scripts, assim os valores de teste seriam reutilizáveis.
REFERÊNCIAS BIBLIOGRÁFICAS
AUTOMATEDQA. TestComplete. Disponível em: <http://www.automatedqa.com/products/testcomplete/>. Acesso em: 08 set. 2005.
BARTIÉ, Alexandre. Garantia da qualidade de software. Rio de Janeiro: Campus, 2002.
FOUR-M. Sapro: Sistema de acompanhamento de processos. Disponível em: <http://www.fourm.com.br>. Acesso em: 15 jun. 2006.
FREITAS, Henrique. Sistemas integrados de gestão. Porto Alegre, 2004. Disponível em: <http://professores.ea.ufrgs.br/hfreitas/revista/arquivos/slides/aula_8_erp_si_mgt.ppt>. Acesso em: 8 ago. 2005. (Notas de aula da disciplina Sistemas de Informação Gerencial).
FURLAN, José Davi. Modelagem de objetos através da UML. São Paulo: Makron Books, 1998.
GESSER, Carlos Eduardo. GALS: Gerador de analisadores léxicos e sintáticos. 2002. 150f. Trabalho de Conclusão de Curso (Bacharelado em Ciência da Computação)–Centro Tecnológico, Universidade Federal de Santa Catarina, Florianópolis, 2003.
INTELIDATA. Produtos. Disponível em: http://www.intelidata.inf.br. Acesso em: 16 out. 2005.
INTHURN, Cândida. Qualidade & teste de software. Florianópolis: Visual Books, 2001.
KLINGER, Daniel André, KROTH, Eduardo. Um software assistente para especificação de regras de negócio. Congresso Brasileiro de Computação. Itajaí, 2001. Disponível em: < http://cbcomp.univali.br/pdf/2001/eng006.pdf>. Acesso em: 8 jun. 2006.
KOKUBO, Eduardo. Sistema para importação de informações do currículo lattes. 2004, 94f. Trabalho de Conclusão de Curso (Bacharelado em Ciência da Computação)–Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, 2004.
LARMAN, Graig. Utilizando UML e padrões: Uma introdução à análise e ao projeto orientados a objetos. Porto Alegre: Bookman, 2000.
MAIA, Maurício M. Tutorial XML-Schema. Dicas-L, 2005. Disponível em: <http://www.dicas-l.com.br/dicas-l/20050326.php>. Acesso em: 04 nov. 2005.
MERCURY. QuickTest. Disponível em: <http://www.mercury.com/us/products/quality-center/functional-testing/quicktest-professional/>. Acesso em: 10 set. 2005.
MOREIRA FILHO, Trayahú R.; RIOS, Emerson. Projeto & engenharia de software: teste de software. Rio de Janeiro: Alta Books, 2003.
MOULTIS, Natanya Pitts; KIRK, Cheryl. XML Black Book. São Paulo: Makron Books, 2000.
PAULA FILHO, Wilson de Pádua. Engenharia de software: fundamentos, métodos e padrões. Rio de Janeiro: LTC, 2001.
PETERS, James F.; PEDRYCZ, Witold. Engenharia de software. Rio de Janeiro: Campus, 2001.
74
PFLEEGER, Shari Lawrence. Engenharia de software: teoria e prática. São Paulo: Prentice Hall, 2004.
PILLAT, Fábio Roberto; FERREIRA, Luciano; DIAS, Adriane Pedroso. Ferramentas para automação de testes. Revista do Centro de Ciências da Economia e Informática, Bagé, v.8, n 13, p. 50-57, 2004. Disponível em: <http://dinf.unicruz.edu.br/~pillatt/2004_urcamp.pdf>. Acesso em: 10 set. 2005.
PRESSMAN, Roger S. Engenharia de software. Rio de Janeiro: McGraw-Hill, 2002.
PRESSMAN, Roger S.. Engenharia de software. São Paulo: Makron Books, 1995.
RICHTER, Jeffrey. Windows avançado: guia de desenvolvimento para o API WIN 32, para Wndows NT Windows 95. São Paulo: Makron Books, 1995.
ROCHA, Ana Regina Cavalcanti da; MALDONADO, José Carlos; WEBER, Kival Chaves. Qualidade de Software: teoria e prática. São Paulo: Prentice Hall, 2001.
ROCHA, André Dantas; SIMÃO, Adenilso da Silva; MALDONADO, José Carlos; MASIERO, Paulo César. Uma ferramenta baseada em aspectos para o teste funcional de programas Java. Congresso Brasileiro de Engenharia de Software. Minas Gerais, 2005. Disponível em: < http://www.sbbd-sbes2005.ufu.br/arquivos/17-%209610.pdf>. Acesso em: 5 set. 2005.
ROSA, Edson. Software de apoio a etapa de testes, utilizando técnicas de caixa preta. 1997, 67f. Trabalho de Conclusão de Curso (Bacharelado em Ciência da Computação)–Centro de Ciências Tecnológicas, Universidade Regional de Blumenau, Blumenau, 1997.
SCHROEDER, Patrick J.; KOREL Bodgan. Black-box test reduction using input-output analysis. In: INTERNATIONAL SYMPOSIUM ON SOFTWARE TESTING AND ANALYSIS, Portland, 2000. Proceedings… New York: ACM Press, 2000.
SEÁRA, Ewerton Flávio Rufino. Incrementando o desenvolvimento de sistemas baseados em framework através de ferramenta RAD. 2005, 108f. Trabalho de Conclusão de Curso (Bacharelado em Ciência da Computação)–Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, 2005.
STUANI, Bruno Martins. O que é API Hooking. Disponível em: < http://www.projetobms.net/artigos.php?id=2>. Acesso em: 10 maio 2006.
APÊNDICES
A XML SCHEMA
Para o desenvolvimento da TestWare foi necessário criar dois XML Schemas. Conforme
mostra o Apêndice A.1 e A.2.
A.1 XML SCHEMA DA FERRAMENTA
O XML Schema ilustrado na Figura 31 contém a estrutura de armazenamento dos dados
relacionados ao projeto.
<?xml version="1.0" encoding="ISO-8859-1"?> <!-- edited with XMLSPY v5 rel. 4 U (http://www.xmlspy.com) by rth77 (rth77) --> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="Projeto" type="Projeto"/> <xs:complexType name="Projeto"> <xs:sequence> <xs:element name="Nome" type="xs:string"/> <xs:element name="App_Testar" type="xs:string"/> <xs:element name="Obs" type="xs:string" minOccurs="0"/> <xs:element name="Script" type="xs:string"/> <xs:element name="Vlr_Teste" maxOccurs="unbounded"> <xs:complexType> <xs:sequence> <xs:element name="Campo" type="xs:string"/> <xs:element name="Tipo_dado" type="Tipo_Dado"/> <xs:element name="Tst_volume" type="xs:integer"/> <xs:element name="Vlr_Campo" maxOccurs="unbounded"> <xs:complexType> <xs:sequence> <xs:element name="Valor" type="xs:string"/> <xs:element name="Situacao" type="xs:boolean"/> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Execucao" minOccurs="0" maxOccurs="unbounded"> <xs:complexType> <xs:sequence> <xs:element name="Data_ini" type="xs:string"/> <xs:element name="Data_fim" type="xs:string"/> <xs:element name="Casos_teste" maxOccurs="unbounded"> <xs:complexType> <xs:sequence> <xs:element name="Itens_testados" maxOccurs="unbounded"> <xs:complexType> <xs:sequence> <xs:element name="Campo" type="xs:string"/> <xs:element name="Valor" type="xs:string" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Status" type="Status"/> <xs:element name="Descrição" type="xs:string"/> </xs:sequence> </xs:complexType>
77
</xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> <xs:element name="Valores_de_Teste" type="Valores_de_Teste"/> <xs:complexType name="Valores_de_Teste"/> <xs:element name="Execução" type="Execução"/> <xs:complexType name="Execução"/> <xs:element name="Interpreta" type="Interpreta"/> <xs:complexType name="Interpreta"> <xs:sequence> <xs:element name="Interpreta.tokens" type="xs:token"/> </xs:sequence> </xs:complexType> <xs:simpleType name="Status"> <xs:restriction base="xs:string"> <xs:enumeration value="sucesso"/> <xs:enumeration value="timeout"/> <xs:enumeration value="erro"/> </xs:restriction> </xs:simpleType> <xs:element name="Caso_de_Teste" type="Caso_de_Teste"/> <xs:complexType name="Caso_de_Teste"/> <xs:simpleType name="Tipo_Dado"> <xs:restriction base="xs:string"> <xs:enumeration value="intervalo"/> <xs:enumeration value="valor"/> <xs:enumeration value="conjunto"/> <xs:enumeration value="booleano"/> </xs:restriction> </xs:simpleType> </xs:schema>
Figura 31. XML Schema da TestWare
A.2 XML SCHEMA CONFIGURAÇÕES DA TESTWARE
A Figura 32 apresenta o XML Schema que contém a estrutura de dados para armazenamento
das configurações gerais da ferramenta, como: o cadastro de teclas e seus devidos códigos ASCII; a
configuração do tempo de espera para a aplicação em teste carregar; e o intervalo entre o envio de
dados de um campo para outro.
78
<?xml version="1.0" encoding="UTF-8"?> <!-- edited with XMLSPY v5 rel. 4 U (http://www.xmlspy.com) by rth77 (rth77) --> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:element name="Configuracao"> <xs:annotation> <xs:documentation>Comment describing your root element</xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element name="Teclas" maxOccurs="unbounded"> <xs:complexType> <xs:sequence> <xs:element name="Nome" type="xs:string"/> <xs:element name="Valor" type="xs:integer"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="tempo_app" type="xs:integer"/> <xs:element name="tempo_campo" type="xs:integer"/> </xs:sequence> </xs:complexType> </xs:element> </xs:schema>
Figura 32. Xml Schema das configurações gerais da TestWare
79
B ESTUDO DE CASO ITLSYS
Este capítulo apresenta os valores configurados na TestWare para o estudo de caso do
aplicativo caixa, e também os casos de teste gerados.
B.1 VALORES PARA TESTE
Na seqüência estão exibidos os valores de teste configurados para cada campo de entrada.
Tabela 13. Valores de teste para o campo produto
Campo Tipo de Dado Valor Situação 1659 Válido 7891219013836 Válido 1660 Válido 0027084262087 Válido 7891612017837 Válido -1 Inválido ABC Inválido
Produto Valor
:~].,; Inválido
Tabela 14. Valores de teste para o campo guia
Campo Tipo de Dado Valor Situação 31107 Válido 90758 Inválido
Guia Valor
Guia Inválido
Tabela 15. Valores de teste para o campo cliente
Campo Tipo de Dado Valor Situação 02769695967 Válido 79379491000264 Válido 5555555 Inválido
Cliente Valor
JOSE Inválido
80
Tabela 16. Valores de teste para o campo condicao_pagamento
Campo Tipo de Dado Valor Situação 1 Válido 225-1 Inválido
Condicao_pagamento Valor
aaaaaaaaa Inválido
Tabela 17. Valores de teste para o campo parcelamento
Campo Tipo de Dado Valor Situação 30 Válido 02566985 Inválido
Parcelamento Valor
Abc Inválido
Tabela 18. Valores de teste para o campo cmc7
Campo Tipo de Dado Valor Situação 001040180168500275831000836150 Válido 1234 Inválido
Cmc7 Valor
000685 Inválido
B.2 CASOS DE TESTE
Os casos de teste aplicados no caixa estão ilustrados na seqüência. O caso de teste 15 que
aplicou o teste de volume não está exibido, por causa, do grande número de iterações. A Tabela 19
apresenta o primeiro caso de teste, nele foi aplicado para todos os campos valores válidos, o
resultado foi sucesso, pois, a venda concluiu.
81
Tabela 19. Caso de teste 01
Campo Valor Situação Produto 1659 Válido
7891219013836 Válido 1660 Válido 0027084262087 Válido
7891612017837 Válido Guia 31107 Válido Cliente 02769695967 Válido Condicao_pagamento 1 Válido Parcelamento 30 Válido Cmc7 001040180168500275831000836150 Válido
A Tabela 20 exibe o caso de teste 02, ele exercitou o campo “produto” com valor inválido,
obteve sucesso, pois, a aplicação exibiu a mensagem “Produto não cadastrado”.
Tabela 20. Caso de teste 02
Campo Valor Situação Produto -1 Inválido Guia 31107 Válido Cliente 79379491000264 Válido Condicao_pagamento 1 Válido Parcelamento 30 Válido Cmc7 001040180168500275831000836150 Válido
A Tabela 21 mostra o caso de teste 03, ele testou o campo “guia” com valor inválido, este
teste obteve resultado de erro, pois, a venda concluiu utilizando valor inválido no campo guia.
Como já foi mencionado anteriormente, quando o caixa é executado em OFF-LINE este campo não
é validado. Todos os casos de teste com status erro devem ser encaminhados para a equipe de
desenvolvimento para que as correções sejam realizadas.
82
Tabela 21. Caso de teste 03
Campo Valor Situação 1659 Válido Produto 7891219013836 Válido
Guia 90758 Inválido Cliente 02769695967 Válido Condicao_pagamento 1 Válido Parcelamento 30 Válido Cmc7 001040180168500275831000836150 Válido
O caso de teste 04, ilustrado na Tabela 22 exercitou o campo “parcelamento” com valor
inválido, obteve erro, pois, o caixa exibiu a mensagem “run-time error overflow”, fechando a
aplicação.
Tabela 22. Caso de teste 04
Campo Valor Situação 1660 Válido Produto 0027084262087 Válido
Guia 31107 Válido Cliente 02769695967 Válido Condicao_pagamento 1 Válido Parcelamento 02566985 Inválido Cmc7 001040180168500275831000836150 Válido
O caso de teste 05, conforme Tabela 23, testou o campo “condicao_pagamento” com valor
inválido, este caso obteve sucesso, pois, a aplicação exibiu a mensagem “Condição de pagamento
não cadastrada”.
Tabela 23. Caso de teste 05
Campo Valor Situação 7891612017837 Válido Produto 1659 Válido
Guia 31107 Válido Cliente 02769695967 Válido Condicao_pagamento 225-1 Inválido Parcelamento 30 Válido Cmc7 001040180168500275831000836150 Válido
A Tabela 24 exibe o caso de teste 06, nele foi aplicado um valor inválido para o campo
“cliente”, este teste obteve sucesso, pois, a aplicação exibiu o aviso “Digite o CPF ou CGC ou
cartão do cliente”.
83
Tabela 24. Caso de teste 06
Campo Valor Situação 7891219013836 Válido 1660 Válido
Produto
0027084262087 Válido Guia 31107 Válido Cliente 5555555 Inválido Condicao_pagamento 1 Válido Parcelamento 30 Válido Cmc7 001040180168500275831000836150 Válido
O caso de teste 07, Tabela 25, testou o campo “cmc7” com valor inválido, este caso teve o
resultado sucesso, pois, a aplicação exibiu a mensagem “CMC7 inválido”.
Tabela 25. Caso de teste 07
Campo Valor Situação 7891612017837 Válido Produto 1659 Válido
Guia 31107 Válido Cliente 02769695967 Válido Condicao_pagamento 1 Válido Parcelamento 30 Válido Cmc7 1234 Inválido
Os casos de teste apresentados na Tabela 26 e Tabela 27 exercitaram o campo produto com
valor inválido, obtiveram sucesso, pois, a aplicação exibiu a mensagem “Produto não cadastrado”.
Tabela 26. Caso de teste 08
Campo Valor Situação Produto ABC Inválido Guia 31107 Válido Cliente 02769695967 Válido Condicao_pagamento 1 Válido Parcelamento 30 Válido Cmc7 001040180168500275831000836150 Válido
84
Tabela 27. Caso de teste 09
Campo Valor Situação Produto :~].,; Inválido Guia 31107 Válido Cliente 02769695967 Válido Condicao_pagamento 1 Válido Parcelamento 30 Válido Cmc7 001040180168500275831000836150 Válido
O caso de teste mostrado na Tabela 28 exercitou o campo “guia” com valor inválido, obteve
erro, porque a venda foi concluída.
Tabela 28. Caso de teste 10
Campo Valor Situação 7891219013836 Válido 1660 Válido
Produto
0027084262087 Válido Guia Guia Inválido Cliente 02769695967 Válido Condicao_pagamento 1 Válido Parcelamento 30 Válido Cmc7 001040180168500275831000836150 Válido
O caso de teste 11, Tabela 29, testou o campo “parcelamento” com valor inválido, teve
resultado de erro, pois, a venda concluiu inserindo um valor inválido no campo parcelamento.
Tabela 29. Caso de teste 11
Campo Valor Situação 7891612017837 Válido 1659 Válido
Produto
7891219013836 Válido Guia 31107 Válido Cliente 02769695967 Válido Condicao_pagamento 1 Válido Parcelamento Abc Inválido Cmc7 001040180168500275831000836150 Válido
O caso de teste 12 exercitou o campo “condicao_pagamento” com valor inválido, obteve
sucesso, porque, a aplicação emitiu a mensagem “Condição de pagamento não cadastrada”.
85
Tabela 30. Caso de teste 12
Campo Valor Situação 1660 Válido 0027084262087 Válido
Produto
7891612017837 Válido Guia 31107 Válido Cliente 02769695967 Válido Condicao_pagamento Aaaaaaaaa Inválido Parcelamento 30 Válido Cmc7 001040180168500275831000836150 Válido
O caso de teste 13, exibido na Tabela 31 exercitou o campo cliente com valor inválido,
obteve sucesso, porém a aplicação exibiu a mensagem “Cliente não pode ficar em branco” e esta
mensagem não está de acordo. Neste caso, o testador deve solicitar a correção para a equipe de
desenvolvimento.
Tabela 31. Caso de teste 13
Campo Valor Situação 1659 Válido 7891219013836 Válido
Produto
1660 Válido Guia 31107 Válido Cliente JOSE Inválido Condicao_pagamento 1 Válido Parcelamento 30 Válido Cmc7 001040180168500275831000836150 Válido
A Tabela 32 ilustra o caso de teste 14 que exercitou o campo “cmc7” com valor inválido,
obteve sucesso, pois, a aplicação apresentou a mensagem “CMC7 inválido”,
86
Tabela 32. Caso de teste 14
Campo Valor Situação 0027084262087 Válido 7891612017837 Válido 1659 Válido 7891219013836 Válido 1660 Válido 0027084262087 Válido 7891612017837 Válido
Produto
1659 Válido Guia 31107 Válido Cliente 02769695967 Válido Condicao_pagamento 1 Válido Parcelamento 30 Válido Cmc7 000685 Inválido
E por fim, o caso de teste 15, exercitou o caixa aplicando o teste de volume, foi realizada
uma venda com 1000 itens, o teste durou 28 minutos e obteve sucesso.
87
C ESTUDO DE CASO SAPRO
A Figura 33 apresenta o arquivo xml referente ao projeto criado para testar o cadastro de
clientes do aplicativo SAPRO.
<?xml version="1.0" standalone="yes"?> <Projeto> <Nome>SAPRO - Cadastro de Cliente</Nome> <App_Testar>D:\Arquivos e Programas\Sapro.exe</App_Testar> <Obs/> <Script>inicio_script escrevaconst "SUPERVISOR" comando enter escrevaconst "MASTER" comando enter comando enter comando ALT#C escrevaconst "C" comando enter comando enter escreva cnpj comando enter escreva insest comando enter escreva dtcadastro comando enter escreva razao comando enter escreva nomefantasia comando enter comando ALT#S fim_script</Script> <Vlr_Teste> <Campo>nomefantasia</Campo> <Tipo_dado>Valor</Tipo_dado> <Tst_volume>0</Tst_volume> <Vlr_Campo> <Valor>TESTE</Valor> <Situacao>True</Situacao> </Vlr_Campo> <Vlr_Campo> <Valor>NULL</Valor> <Situacao>False</Situacao> </Vlr_Campo> </Vlr_Teste> <Vlr_Teste> <Campo>razao</Campo> <Tipo_dado>Valor</Tipo_dado> <Tst_volume>0</Tst_volume> <Vlr_Campo> <Valor>CLIENTE TESTE</Valor> <Situacao>True</Situacao> </Vlr_Campo> <Vlr_Campo> <Valor>NULL</Valor>
88
<Situacao>False</Situacao> </Vlr_Campo> </Vlr_Teste> <Vlr_Teste> <Campo>dtcadastro</Campo> <Tipo_dado>Valor</Tipo_dado> <Tst_volume>0</Tst_volume> <Vlr_Campo> <Valor>16072006</Valor> <Situacao>True</Situacao> </Vlr_Campo> <Vlr_Campo> <Valor>16072007</Valor> <Situacao>False</Situacao> </Vlr_Campo> <Vlr_Campo> <Valor>35062006</Valor> <Situacao>False</Situacao> </Vlr_Campo> </Vlr_Teste> <Vlr_Teste> <Campo>insest</Campo> <Tipo_dado>Valor</Tipo_dado> <Tst_volume>0</Tst_volume> <Vlr_Campo> <Valor>ISENTO</Valor> <Situacao>True</Situacao> </Vlr_Campo> </Vlr_Teste> <Vlr_Teste> <Campo>cnpj</Campo> <Tipo_dado>Valor</Tipo_dado> <Tst_volume>0</Tst_volume> <Vlr_Campo> <Valor>57485542000119</Valor> <Situacao>True</Situacao> </Vlr_Campo> <Vlr_Campo> <Valor>02769695967</Valor> <Situacao>False</Situacao> </Vlr_Campo> <Vlr_Campo> <Valor>11111111111111</Valor> <Situacao>False</Situacao> </Vlr_Campo> </Vlr_Teste> <Execucao> <Data_ini>16/7/2006 16:29:12</Data_ini> <Data_fim>16/7/2006 16:35:26</Data_fim> <Casos_teste> <Status>Sucesso</Status> <Descrição/> <Itens_testados> <Campo>cnpj</Campo>
89
<Valor>57485542000119</Valor> </Itens_testados> <Itens_testados> <Campo>insest</Campo> <Valor>ISENTO</Valor> </Itens_testados> <Itens_testados> <Campo>dtcadastro</Campo> <Valor>16072006</Valor> </Itens_testados> <Itens_testados> <Campo>razao</Campo> <Valor>CLIENTE TESTE</Valor> </Itens_testados> <Itens_testados> <Campo>nomefantasia</Campo> <Valor>TESTE</Valor> </Itens_testados> </Casos_teste> <Casos_teste> <Status>Sucesso</Status> <Descrição/> <Itens_testados> <Campo>cnpj</Campo> <Valor>57485542000119</Valor> </Itens_testados> <Itens_testados> <Campo>insest</Campo> <Valor>ISENTO</Valor> </Itens_testados> <Itens_testados> <Campo>dtcadastro</Campo> <Valor>16072006</Valor> </Itens_testados> <Itens_testados> <Campo>razao</Campo> <Valor>CLIENTE TESTE</Valor> </Itens_testados> <Itens_testados> <Campo>nomefantasia</Campo> <Valor>NULL</Valor> </Itens_testados> </Casos_teste> <Casos_teste> <Status>Sucesso</Status> <Descrição/> <Itens_testados> <Campo>cnpj</Campo> <Valor>57485542000119</Valor> </Itens_testados> <Itens_testados> <Campo>insest</Campo> <Valor>ISENTO</Valor> </Itens_testados> <Itens_testados>
90
<Campo>dtcadastro</Campo> <Valor>16072006</Valor> </Itens_testados> <Itens_testados> <Campo>razao</Campo> <Valor>NULL</Valor> </Itens_testados> <Itens_testados> <Campo>nomefantasia</Campo> <Valor>TESTE</Valor> </Itens_testados> </Casos_teste> <Casos_teste> <Status>Erro</Status> <Descrição>O cliente foi incluido tendo utilizado uma data de cadastro futura.</Descrição> <Itens_testados> <Campo>cnpj</Campo> <Valor>57485542000119</Valor> </Itens_testados> <Itens_testados> <Campo>insest</Campo> <Valor>ISENTO</Valor> </Itens_testados> <Itens_testados> <Campo>dtcadastro</Campo> <Valor>16072007</Valor> </Itens_testados> <Itens_testados> <Campo>razao</Campo> <Valor>CLIENTE TESTE</Valor> </Itens_testados> <Itens_testados> <Campo>nomefantasia</Campo> <Valor>TESTE</Valor> </Itens_testados> </Casos_teste> <Casos_teste> <Status>Sucesso</Status> <Descrição/> <Itens_testados> <Campo>cnpj</Campo> <Valor>02769695967</Valor> </Itens_testados> <Itens_testados> <Campo>insest</Campo> <Valor>ISENTO</Valor> </Itens_testados> <Itens_testados> <Campo>dtcadastro</Campo> <Valor>16072006</Valor> </Itens_testados> <Itens_testados> <Campo>razao</Campo> <Valor>CLIENTE TESTE</Valor>
91
</Itens_testados> <Itens_testados> <Campo>nomefantasia</Campo> <Valor>TESTE</Valor> </Itens_testados> </Casos_teste> <Casos_teste> <Status>Sucesso</Status> <Descrição/> <Itens_testados> <Campo>cnpj</Campo> <Valor>57485542000119</Valor> </Itens_testados> <Itens_testados> <Campo>insest</Campo> <Valor>ISENTO</Valor> </Itens_testados> <Itens_testados> <Campo>dtcadastro</Campo> <Valor>35062006</Valor> </Itens_testados> <Itens_testados> <Campo>razao</Campo> <Valor>CLIENTE TESTE</Valor> </Itens_testados> <Itens_testados> <Campo>nomefantasia</Campo> <Valor>TESTE</Valor> </Itens_testados> </Casos_teste> <Casos_teste> <Status>Sucesso</Status> <Descrição/> <Itens_testados> <Campo>cnpj</Campo> <Valor>11111111111111</Valor> </Itens_testados> <Itens_testados> <Campo>insest</Campo> <Valor>ISENTO</Valor> </Itens_testados> <Itens_testados> <Campo>dtcadastro</Campo> <Valor>16072006</Valor> </Itens_testados> <Itens_testados> <Campo>razao</Campo> <Valor>CLIENTE TESTE</Valor> </Itens_testados> <Itens_testados> <Campo>nomefantasia</Campo> <Valor>TESTE</Valor> </Itens_testados> </Casos_teste> </Execucao>
92
<Execucao> <Data_ini>18/7/2006 13:41:41</Data_ini> <Data_fim>18/7/2006 13:41:41</Data_fim> <Casos_teste> <Status/> <Descrição/> <Itens_testados> <Campo>cnpj</Campo> <Valor>57485542000119</Valor> </Itens_testados> <Itens_testados> <Campo>insest</Campo> <Valor>ISENTO</Valor> </Itens_testados> <Itens_testados> <Campo>dtcadastro</Campo> <Valor>16072006</Valor> </Itens_testados> <Itens_testados> <Campo>razao</Campo> <Valor>CLIENTE TESTE</Valor> </Itens_testados> <Itens_testados> <Campo>nomefantasia</Campo> <Valor>TESTE</Valor> </Itens_testados> </Casos_teste> </Execucao> </Projeto>
Figura 33. XML do projeto Sapro
