Академический Документы
Профессиональный Документы
Культура Документы
TRABALHO DE CONCLUSO DE CURSO SUBMETIDO UNIVERSIDADE REGIONAL DE BLUMENAU PARA A OBTENO DOS CRDITOS NA DISCIPLINA COM NOME EQUIVALENTE NO CURSO DE CINCIAS DA COMPUTAO BACHARELADO
MARCIO TOMELIN
MARCIO TOMELIN
ESTE TRABALHO DE CONCLUSO DE CURSO, FOI JULGADO ADEQUADO PARA OBTENO DOS CRDITOS NA DISCIPLINA DE TRABALHO DE CONCLUSO DE CURSO OBRIGATRIA PARA OBTENO DO TTULO DE: BACHAREL EM CINCIAS DA COMPUTAO
FURB
BANCA EXAMINADORA
ii
DEDICATRIA
Dedico este trabalho, aos meus familiares e amigos e principalmente a meus pais Ivo e Zulmira, pelo apoio dado durante a elaborao deste trabalho.
iii
AGRADECIMENTOS
Ao Professor Paulo Csar Rodacki Gomes, pela pacincia e pelo interesse com o qual orientou este trabalho. Ao Professor Jos Roque Voltolini da Silva, coordenador do Trabalho de Concluso de Curso. A todos os professores e funcionrios do Departamento de Sistemas e Computao que auxiliaram para que este trabalho pudesse ser realizado. WK Sistemas, pelo apoio recebido e pela contribuio com o ensinamento da ferramenta Visual Test. Aos colegas, tanto aqueles que ficaram no decorrer do curso, como aos que conseguiram junto comigo chegar ao fim de mais uma etapa de nossas vidas. E a todos que de alguma forma contriburam para a realizao deste trabalho.
iv
SUMRIO
LISTA DE QUADROS .....................................................................................................vii LISTA DE FIGURAS ......................................................................................................viii 1. 1.1 1.2 2. 2.1 2.2 2.3 2.4 2.5 2.5.1 2.5.1.1 2.5.1.2 2.5.1.3 2.5.2 2.5.2.1 2.5.2.2 2.5.2.3 2.5.2.4 2.5.3 2.5.4 2.5.5 2.5.6 2.6 2.6.1 2.6.2 2.6.2.1 2.6.2.2 INTRODUO ......................................................................................................... 1 OBJETIVOS .............................................................................................................. 3 ESTRUTURA............................................................................................................ 3 TESTE DE SOFTWARE........................................................................................... 4 ATIVIDADE DE TESTES ........................................................................................ 4 OBJETIVOS E LIMITES DO TESTE DE SOFTWARE ......................................... 5 METODOLOGIAS DE TESTE DE SOFTWARE ................................................... 6 BATERIAS DE TESTES .......................................................................................... 7 ATIVIDADES DE TESTE DE SOFTWARE ........................................................... 8 PLANEJAMENTO DOS TESTES ........................................................................ 9 PLANOS DE TESTES........................................................................................ 9 PLANEJAMENTO INICIAL ........................................................................... 11 IDENTIFICAO DOS ITENS A TESTAR................................................... 11 DESENHO DE TESTES ...................................................................................... 12 ESPECIFICAES DOS TESTES .................................................................. 13 DESENHO DE PROCEDIMENTOS DE TESTE ............................................ 14 DESENHO DE CASO DE TESTE................................................................... 14 REVISO DO DESENHO DE TESTE............................................................ 14 IMPLEMENTAO DOS TESTES ................................................................... 14 EXECUO DOS TESTES ................................................................................ 15 VERIFICAO DO TRMINO DOS TESTES ................................................. 15 BALANO FINAL .............................................................................................. 15 TCNICAS DE TESTE DE SOFTWARE.............................................................. 16 TESTES DE INTEGRAO............................................................................... 16 TESTES DE ACEITAO.................................................................................. 16 TESTES FUNCIONAIS ................................................................................... 16 TESTES NO FUNCIONAIS.......................................................................... 18
2.6.3 2.7 2.7.1 2.7.2 2.8 2.8.1 2.8.1.1 2.8.1.2 2.9 2.9.1 2.9.2 2.9.3 2.9.4 2.9.5 3. 3.1 3.2 3.2.1 3.2.2 3.3 4. 4.1 4.2
TESTES DE REGRESSO ................................................................................. 19 CASOS DE TESTE ................................................................................................. 19 IDENTIFICAO DE CASOS DE TESTE........................................................ 20 MODELO PARA CRIAO DE UM CASO DE TESTE.................................. 21 NORMA BRASILEIRA ABNT NBR 12207 .......................................................... 22 PROCESSO DE DESENVOLVIMENTO ........................................................... 23 PROCESSO DE OPERAO.......................................................................... 25 PROCESSOS DE APOIO DE CICLO DE VIDA ............................................ 25
A FERRAMENTA RATIONAL VISUAL TEST 6.5............................................. 27 AUTOMAO DO TESTE DE SOFTWARE.................................................... 28 INTERFACE DO VISUAL TEST ......................................................................... 29 LINGUAGEM DO VISUAL TEST....................................................................... 30 UTILITRIOS DO VISUAL TEST ...................................................................... 31 EXECUO DOS SCRIPTS ............................................................................... 31 DESENVOLVIMENTO .......................................................................................... 33 ESPECIFICAO................................................................................................... 36 IMPLEMENTAO............................................................................................... 39 TCNICAS E FERRAMENTAS UTILIZADAS ................................................ 51 OPERACIONALIDADE DA IMPLEMENTAO ........................................... 51 RESULTADOS E DISCUSSO............................................................................. 52 CONCLUSES ....................................................................................................... 55 LIMITAES ......................................................................................................... 56 EXTENSES........................................................................................................... 56
vi
LISTA DE QUADROS
Quadro 1- ENTRADAS PARA O DESENHO DE TESTES..................................................... 9 Quadro 2 - ESTRUTURA DE PLANDO DE TESTES ........................................................... 10 Quadro 3 - PLANEJAMENTO INICIAL DOS TESTES ........................................................ 11 Quadro 4 - DESENHO DA BATERIA DE TESTES .............................................................. 12 Quadro 5 - ESTRUTURA DE UMA ESPECIFICAA DE TESTES .................................. 13 Quadro 6 - IMPLEMENTAO DOS TESTES ..................................................................... 15 Quadro 7 - DESENHO DE CASO DE TESTE DE ANLISE DO VALOR LIMITE ........... 17 Quadro 8 - TIPOS DE TESTES DE SISTEMA....................................................................... 18 Quadro 9 EXEMPLO DE UM MODELO DE CASO DE TESTE ....................................... 22 Quadro 10 CODIFICAO PARA O TESTE DE ACEITAO..........................................i Quadro 11 PLANO DE TESTES .......................................................................................... 42 Quadro 12 RESTAURAO E BACKUP DA BASE DE DADOS.................................... 45 Quadro 13 ANLISE DO VALOR LIMITE ........................................................................ 47 Quadro 14 TESTE DE DESEMPENHO ............................................................................... 48 Quadro 15 RESTRIES DE INTEGRIDADE................................................................... 49 Quadro 16 FUNO DE GERAO DO RELATRIO.................................................... 50 Quadro 17 EXECUO DE TESTES MANUAIS X TESTES AUTOMATIZADOS ....... 53
vii
LISTA DE FIGURAS
Figura 1 INTERFACE DO VISUAL TEST.......................................................................... 29 Figura 2 ETAPA DE DESENVOLVIMENTO DE SOFTWARE ........................................ 34 Figura 3 DIAGRAMA USE-CASE DO PROTTIPO......................................................... 37 Figura 4 MODELO DE RELATRIO DE RESULTADOS DOS TESTES ...........................i Figura 5 ESTRUTURAO LGICA DOS SCRIPTS DE TESTE ................................... 44
viii
RESUMO
O teste de software uma das fases do ciclo de vida de um software que mais contribuem para a garantia da qualidade do software. Vrias ferramentas tm sido construdas com o objetivo de apoiar esta fase. Entre elas est o Visual Test. Esta ferramenta simula de forma automatizada a entrada de dados informadas pelo usurio final de forma a alimentar o sistema com cadastros, movimentaes, relatrios e outros. Com o desenvolvimento deste trabalho pretendeu-se montar um projeto de software automatizado que agilize e d qualidade a este tipo de atividade. Este projeto baseou-se em tcnicas de testes sugeridas por normas de qualidade.
ix
ABSTRACT
Software Testing represents an important process in a softwares life-cycle regarding its software quality. Several tools for helping such process have been designed. Rationals Visual Test is one of them. Such tool automates the simulation of final users data input. The present work proposes an automated software project for Software Testing, providing better performance and quality to this kind of activity, which is currently left aside by most software houses. This project is based mainly on quality software testing standards.
1. INTRODUO
Os testes de software so vistos como uma tarefa contnua de avaliar e mensurar a qualidade do trabalho desenvolvido em cada etapa do processo de desenvolvimento de sistemas, desde a anlise de requisitos at a fase de manuteno do software. Aproximadamente 50% do tempo e mais 50% do custo total de um sistema so gastos no teste de programas ou sistemas em desenvolvimento. Testar sistemas uma atividade que a maioria das pessoas j faz por fora ou por obrigao, uma atividade na qual investe-se muito tempo e dinheiro. Ainda assim, no definida com clareza. Na maioria das empresas, os testes so mal estruturados e feitos de maneira fortemente individualizada, quase aleatoriamente (Martimiano, 1995). A noo teste de programas surgiu quase que simultaneamente ao aparecimento dos primeiros programas. Os programas executados nos primrdios da computao tambm tinham que ser testados. A realizao de testes era uma atividade rotineira associada a processos de engenharia e produo industrial e a sua extenso ao desenvolvimento de software pode ser encarada como um desdobramento natural. Segundo se pensava, os programas eram escritos e depois testados e depurados. Os testes eram considerados uma atividade secundria, englobando os esforos para a deteco de erros e tambm a sua correo e eliminao. Vrios dos primeiros estudos publicados sobre teste de software, abordavam aa depurao. A dificuldade da correo e eliminao de erros foi vista durante muito tempo como um problema mais interessante. O tema vem crescendo em importncia com a necessidade de todos os setores da informtica no sentido de criar mtodos prticos que assegurem a qualidade de seus produtos finais. No entanto o autor acredita que a maturidade ainda est longe de ser alcanada. Os ambientes de engenharia de software orientados a processo visam apoiar as fases do processo de software, permitindo a definio de tarefas e a comunicao e o compartilhamento de dados entre as ferramentas que compem o ambiente. fundamental em todos os ramos da engenharia de software garantir a produo de software de alta qualidade a fim de proporcionar aos usurios uma maior confiana e segurana na utilizao do mesmo.
Com a necessidade de no apenas dar suporte aos objetos gerados durante o desenvolvimento de software, mas tambm de se definir e controlar o processo de desenvolvimento e manuteno de software, considerando dessa forma, o processo como parmetro do ambiente (Gimenes, 1994) surgiram ento, os ambientes de engenharia de software orientados a processos (PSEE). Os PSEEs caracterizam-se por prover suporte a descrio e execuo de processos de modo a auxiliar e controlar todas as atividades do ciclo de vida de um software. Dentre estas atividades, tem-se a fase de teste de software, na qual se concentrar este texto. Testes eficientes so essenciais para o controle de qualquer projeto de desenvolvimento de software. uma forma de verificar se o sistema que est sendo desenvolvido est sendo feito de maneira correta e conforme os requisitos especificados pelo usurio. O teste de software envolve: planejamento de testes, projeto de casos de testes, execuo e avaliao dos resultados obtidos. Segundo Hetzel (1987), teste qualquer atividade que vise avaliar uma caracterstica ou recurso de um programa ou sistema. Teste uma forma de medir a qualidade do software. Um teste de software examina o comportamento do software atravs de sua execuo em um conjunto de dados pertencentes a um domnio de teste definido pela tcnica de teste a ser usada (Martimiano, 1995). O teste de software pode ser realizado durante todas as fases do processo de desenvolvimento do software, portanto trata-se de uma das atividades mais importantes no desenvolvimento de um software. Em muitos casos os programas so testados isoladamente medida que os mdulos vo sendo concludos, a fim de confirmar que o mdulo foi codificado corretamente. Depois, grupos de programas so testados num "teste de sistema" onde feito um teste de integrao para testar as interfaces e assegurar que os mdulos esto se comunicando da maneira esperada. Em seguida, o software explorado como forma de detectar suas limitaes e medir suas potencialidades. Em um terceiro nvel, sistemas completos so, por fim, submetidos a um "teste de aceitao" para verificar a possibilidade de implantao e uso, geralmente feita pelo cliente ou usurio final. Enfim, os testes de software podem ser baseados na norma brasileira NBR-12207 (ABNT, 1998) ou em diversas normas internacionais tais como, IEEE, CMM, ISO, etc. Os trabalhos de Ramirez (1999), Souza (2000) apresentam compilaes da norma IEEE94.
Atravs do estudo destas normas e da ferramenta de automatizao de testes Visual Test, foi implementada uma de teste automatizada. O software submetido ao teste foi o Radar Contbil desenvolvido pela software house WK WK Sistemas de Computao Ltda.
1.1 OBJETIVOS
O objetivo principal deste trabalho implementar uma soluo automatizada para os testes de software utilizando a ferramenta de testes Visual Test. Os objetivos especficos so: a) observar a atividade de teste na WK Sistemas, e a partir desta observao, identificar se a empresa est praticando as atividades de teste conforme as tcnicas estudadas neste trabalho; b) realizar um estudo sobre as recomendaes para teste de software previstas em algumas normas de qualidade.
1.2 ESTRUTURA
O primeiro captulo fornece uma introduo ao trabalho desenvolvido, demonstrando qual o objetivo do trabalho e apresentando os principais tpicos. O segundo captulo demonstra o que Teste de Software suas metodologias, tipos, como e porque execut-los. Mostra tambm para que servem e como devem ser criados os casos de teste, oque algumas normas falam a respeito de teste de software e faz um breve comentrio sobre uma ferramenta de automatizao de testes, o Visual Test. O terceiro trata da especificao do prottipo e demonstra sua implementao por meio de um diagrama de fluxo de dados. Fornece tambm outras informaes sobre a implementao, tais como operacionalidade da mesma e, as tcnicas e ferramentas utilizadas. Por fim, o quarto captulo faz uma anlise conclusiva indicando as dificuldades encontradas e apresenta sugestes para futuras extenses do trabalho que podero ser realizadas.
2. TESTE DE SOFTWARE
Este captulo apresenta um conjunto de princpios, mtodos e tcnicas relativos atividade de teste de software. Esta atividade por sua vez parte integrante de um dos processos ciclo de vida de um software, conforme tratado pela engenharia de software. A engenharia de software uma disciplina tecnolgica e gerencial preocupada com a produo sistemtica de produtos de software, que so desenvolvidos e/ou modificados dentro do tempo e custo estimados, tendo como principal objetivo, a produo de software de alta qualidade e baixo custo (Souza, 2000). Ainda seguindo a idia do autor, defini-se teste de software como sendo um processo de executar um programa com o objetivo de revelar a presena de defeitos; ou, falhando nesse objetivo, aumentar a confiana sobre o programa.
a) um certo gerenciador de banco de dados falha quando certas tabelas tem exatamente 512 bytes de tamanho; b) um certo editor de textos falha se o texto for muito longo (mais de 100.000 caracteres), desde que o texto estija muito fragmentado no disco (espalhado em setores no contguos). O objetivo de um testador de software, neste caso um testador profissional e no uma ferramenta de teste, no pode ser ele querer mostrar que o software est livre de bugs, porque ele jamais conseguir provar isso. De alguma forma ou maneira ele provavelmente deixar escapar muitos bugs (Oliveira, 1997). O principal objetivo de um testador de software deve ser: encontrar problemas no sistema. E, quando encontrado, encaminh-lo para o conserto. Sendo assim: um teste falha quando no acha nenhum bug. Os bugs esto l, cabe ao testador encontr-los.
menos experientes, ou at parcialmente automatizada. Os testes so indicadores da qualidade do produto, mais do que meios de deteco e correo de erros. Por fim, quanto maior o nmero de defeitos detectados em um software provavelmente maior tambm o nmero de defeitos no detectados. A ocorrncia de um nmero anormal de defeitos em uma bateria de testes indica uma provvel necessidade de redesenho dos itens testados. Existem basicamente duas maneiras de se construrem testes (Poston, 1996) : a) mtodo da caixa branca, que tem por objetivo determinar defeitos na estrutura interna do produto, atravs do desenho de testes que exercitem suficientemente os possveis caminhos de execuo; b) mtodo da caixa preta, que tem por objetivo determinar se os requisitos foram total ou parcialmente satisfeitos pelo produto. Os testes de caixa preta no verificam como ocorre o processamento, mas apenas os resultados produzidos. Os testes de aceitao e de regresso normalmente so de caixa preta. Os testes de integrao geralmente misturam testes de caixa preta e de caixa branca.
c) Testes de Aceitao tm por objetivo validar o produto, ou seja, verificar se este atende aos requisitos especificados. Eles so executados em ambiente o mais semelhante possvel ao ambiente real de execuo. Os testes de aceitao podem ser divididos em testes funcionais e no funcionais; d) Testes de Regresso, que executam novamente um subconjunto de testes previamente executados. Seu objetivo assegurar que alteraes em partes do produto no afetem as partes j testadas. As alteraes realizadas, especialmente durante a manuteno, podem introduzir erros nas partes previamente testadas. A maior utilidade dos testes de regresso aparece durante o processamento de solicitaes de manuteno. Entretanto, testes de regresso podem ser executados em qualquer passo do desenvolvimento. Por exemplo, para cada liberao, deve ser feita uma regresso com os testes de integrao das liberaes anteriores.
Especificao dos requisitos Plano de desenvolvimento Plano da qualidade Testes de integrao Descrio do Projeto (projeto de alto nvel) Descrio dos Testes (testes de aceitao) Testes de unidade Descrio do Projeto (projeto detalhado) Descrio dos Testes (testes de integrao) Cdigo Fonte da Unidade Testes de aceitao
Fonte: Ramirez (1990).
2.5.1.1
PLANOS DE TESTES
Ele ser normalmente preenchido durante a iterao de projeto inicial. Sua base
a especificao de requisitos do software; geralmente, cada caso de uso gera uma especificao de teste funcional. Os planos de testes de integrao so preenchidos no inicio de cada liberao. Os testes escolhidos para cada liberao partem normalmente de um subconjunto dos testes de aceitao, correspondente aos casos de uso implementados nessa liberao. Testes adicionais de caixa branca so usados para verificar se as interfaces dos componentes implementados nessa liberao esto funcionando corretamente (entre si e com os componentes herdados das liberaes anteriores). Estes testes adicionais podem ser derivados das realizaes dos casos de uso de desenho, onde as interfaces so exercitadas atravs das colaboraes entre componentes.
10
Cada plano de testes de unidade preenchido durante a respectiva implementao. Os testes de unidade geralmente requerem a construo de componentes de teste. Normalmente, s so desenhados, registrados e guardados os testes das unidades crticas, para uso futuro em manuteno. Tipicamente, uma organizao comearia por planejar e desenhar os testes de aceitao. Na medida em que a cultura da organizao absorvesse esses testes, passaria a planejar e a desenhar tambm os testes de integrao, e finalmente os testes de unidades crticas. O padro adotado para planos de testes prev a estrutura mostrado no Quadro 2. Quadro 2 - ESTRUTURA DE PLANDO DE TESTES Item Identificar o plano de testes Introduo Itens a testar Aspectos a testar Aspectos que no sero testados Abordagem Critrios de completeza e sucesso Critrio de suspenso e retomada Resultado do teste Descrio Identificador nico para o plano
Objetivos, histrico, escopo, referncias a documentos
Conjuntos dos itens cobertos pelo plano Contedos dos testes que sero feitos Aspectos significativos que no sero testados Opes metodolgicas que so aplicveis ao conjunto de testes Condies que devem ser satisfeitas e estados que devem ser atingidos para que o conjunto de testes seja considerado bem sucedido Problemas graves que podem provocar interrupo dos testes
Artefatos que sero produzidos durante a realizao da bateria de testes Tarefas de teste Lista detalhada das tarefas que sero cobertas por este plano Ambiente Hardware e software utilizados para o conjunto dos testes Responsabilidades Responsabilidades de cada um dos participantes da equipe de testes Agenda Data de inicio e de fim de cada tarefa do plano Riscos e contingncias Riscos e contingncias aplicveis aos testes deste plano Aprovao Nome assinatura dos responsveis pela criao do plano Fonte: Ramirez (1990).
11
2.5.1.2
PLANEJAMENTO INICIAL
O Quadro 3 a seguir, mostra em detalhes o planejamento inicial dos testes. Os
insumos so documentos de planejamento, como o plano de desenvolvimento de software, no caso de testes de aceitao, e a seo de plano das liberaes executveis da descrio do projeto do software, no caso de testes de integrao. Quadro 3 - PLANEJAMENTO INICIAL DOS TESTES Descrio Insumos Planejamento inicial dos testes Plano de desenvolvimento do software (testes de aceitao) Descrio do desenho do software Plano de liberaes (teste de integrao) Escolher abordagens para os testes, identificando: reas de risco que devem ser testadas; Restries existentes aos testes; Fontes existentes aos casos de testes; Mtodos de validao dos casos de testes; Tcnicas para registro, coleta, reduo e validao das sada; Necessidades de estruturas provisrias.
Especificar condies de completeza dos testes:
Atividades
Itens a serem testados; Grau de cobertura por itens. Especificar condies de trmino de testes: Condies para trmino normal;
Condies de trmino anormal e procedimentos a adotar nestes casos.
Resultados
Determinar requisitos de recursos: Pessoas; Hardware; Software de sistema; Ferramentas de teste; Formulrios; Suprimentos; Especificar agenda dos testes. Informao geral de planejamento dos testes. Requisies de recursos para testes.
2.5.1.3
a testar. Os insumos so a especificao de requisitos do software, no caso dos testes de aceitao, e as partes apropriadas da descrio do desenho do software, no caso dos demais testes. So identificados os requisitos a testar, determinado o status dos itens sob teste (por
12
exemplo, itens novos ou modificados) e so caracterizados os dados para os casos de teste. produzida a lista dos itens e aspectos a testar.
Insumos
Plano de testes. Especificaes de testes anteriores. Desenhar bateria de testes, estabelecendo: Objetivos dos testes; Reutilizao de especificao de testes existentes; Atividades Ordenamento dos casos de testes. Especificar os procedimentos de testes. Especificar os casos de teste. Especificaes dos testes. Resultados Solicitaes de melhoria do desenho para testabilidade, quando necessrio. Fonte: Ramirez (1990).
13
2.5.2.1
separao entre planos e especificaes permite o reaproveitamento das especificaes em diversos planos. Os procedimentos de teste devem conter uma seqncia de aes que devem ser executadas para realizar um grupo de testes semelhantes. Geralmente, cada procedimento de teste corresponde a um roteiro importante de um caso de uso. Um procedimento pode ser executado de forma manual, ou, automtica. Neste ltimo caso, deve ser codificado em linguagem de script da ferramenta de automao de testes. Para os casos de teste indispensvel que se contenha valores de entradas e sadas esperados para cada instncia de teste. Esses valores so escolhidos de acordo com critrios que maximizam a cobertura da especificaro de teste. Outro fator que no pode ser esquecido, a especificao da ordem de execuo, pois a execuo correta de um caso pode depender de um estado de uma base de dados, que produzido por um caso anterior. O padro aqui adotado para especificaes de testes prev a estrutura mostrada no Quadro 5. Quadro 5 - ESTRUTURA DE UMA ESPECIFICAA DE TESTES Item Identificador da especificao de teste Aspecto a serem testados Detalhes da abordagem Procedimentos de Identificao teste dos testes Casos de teste Critrios de completeza e sucesso Procedimentos de teste Casos de teste Fonte: Ramirez (1990). Descrio Identificador nico para teste. Aspectos a testar combinado neste teste. Detalhes da abordagem especficos deste. Procedimentos associados a este teste. Casos de teste associados a este teste. Critrios de completeza e sucesso especficos deste teste. Descrio de cada um dos procedimentos de teste listados anteriormente. Descrio de cada um dos casos de teste listados anteriormente.
14
2.5.2.2
executar uma variao de teste. Nos testes funcionais, cada variao tipicamente baseada em um roteiro do respectivo caso de uso. conveniente prever procedimentos de teste para execuo de seqncias erradas mas possveis. O fluxo do procedimento representa os passos que devem ser executados por um testador humano ou automatizado, em termos das telas, campos e comandos envolvidos. Os valores efetivos dos campos sero determinados por cada caso de teste.
2.5.2.3
aplicveis a vrios conjuntos de entradas, chamados de casos de teste. Cada caso de teste, por sua vez, tem um ou mais procedimentos de teste associados. O que , e como identificar um caso de teste, ser visto com maiores detalhes no captulo 2.7 deste trabalho.
2.5.2.4
de uso, as respectivas especificaes de testes geralmente ocupam vrias pginas. V-se que, mesmo em sistemas relativamente simples, com poucas dezenas de casos de uso, a Descrio dos testes pode chegar a dezenas ou centenas de pginas. Neste volume de informao, os desenhistas de testes facilmente introduzem defeitos. Por isso, recomendvel que os planos e especificaes dos testes sejam submetidos a uma reviso tcnica formal, pelo menos no caso dos testes de aceitao.
15
Os itens a testar so instalados e configurados, conforme necessrio, assim como as ferramentas e componentes de teste. Os componentes podem ser reaproveitados de testes anteriores, ou desenvolvidos especialmente para os testes em questo (Ramirez, 1999). Quadro 6 - IMPLEMENTAO DOS TESTES Descrio Insumos Implementao dos testes Plano de testes. Especificaes dos testes.
Recursos para os testes.
Atividades
Resultados
Itens a testar. Ferramentas de teste. Dados de atividades anteriores de teste, se houver. Estruturas provisrias de testes anteriores, se houver. Configurar ambientes de teste. Disponibilizar todos os recursos necessrios. Instalar itens a testar, ferramentas e estruturas provisrias. Itens a testar, instalados e configurados. Ferramentas e estruturas provisrias instaladas e configuradas.
16
2.6.2.1
TESTES FUNCIONAIS
Para Ramirez (1999), os testes funcionais so desenhados para verificar a
consistncia entre o produto implementado e os respectivos requisitos funcionais. A completeza e a preciso da especificao dos requisitos do software so fundamentais para assegurar a qualidade desses testes. Os testes funcionais tm como suas principais caractersticas o anlise do valor limite, testes de comparao e testes de tempo real. A anlise do valor limite uma tcnica para a seleo de casos de teste que exercitam os limites. O emprego dessa tcnica deve ser complementar ao emprego da partio de equivalncia. Assim, em vez de se selecionar um elemento aleatrio de cada classe de
17
equivalncia, selecionam-se os casos de teste nas extremidades de cada classe. Veja no Quadro 7 um exemplo de desenho de caso de teste de anlise do valor limite. Quadro 7 - DESENHO DE CASO DE TESTE DE ANLISE DO VALOR LIMITE Entradas vlidas Intervalo delimitado pelos valores a e b Srie de valores Casos de teste Valores imediatamente abaixo de a e imediatamente acima de b
Valor imediatamente abaixo do mnimo, para o mnimo, para o mximo, imediatamente e acima do mximo. Intervalo ou srie de valores Sadas mxima e mnimas definidas. Estruturas de dados Caso que exercite a estrutura em suas fronteiras. Fonte: Ramirez (1990). Existem situaes em que necessrio comparar as sadas de diferentes verses de um sistema quando submetidas s mesmas entradas, estas situaes so denominadas de testes de comparao. Esses testes se aplicam a situaes como: a) uso de sistemas redundantes para aplicaes crticas como controle de aeronaves; b) comparao de resultados de produtos em evoluo. Quando produtos so substitudos por verses mais novas que incluem mais funcionalidade, devem-se comparar os resultados das caractersticas que fazem parte de ambas as verses (no introduzem nova funcionalidade). Essas caractersticas j foram testadas pelos usurios com dados reais e tendem a estar mais estabilizadas. A comparao das sadas pode ser feita com o auxlio de uma ferramenta automatizada. Nessa situao, casos de teste desenhados por meio de tcnicas de caixa preta so usados para testar cada uma das verses existentes. Se as sadas forem consistentes, presumese que todas as verses estejam corretas. Caso contrrio, deve-se investigar em qual ou quais das verses se encontra o defeito. O desenho de testes para sistemas de tempo real no pode considerar apenas casos de teste de caixa preta e branca, mas tambm a temporizao dos dados e o paralelismo das tarefas que os manipulam. Os testes de tempo real podem ser executados atravs dos seguintes passos:
18
a) teste de tarefas isoladas, casos de testes de caixa preta e branca so desenhados para testar cada tarefa independentemente. Nessa etapa, no possvel detectar erros decorrentes de problemas de temporizao. Apenas erros de lgica e funcionalidade so apontados; b) teste comportamental, atravs de modelos executveis por ferramentas de simulao possvel simular o comportamento de sistemas de tempo real e verificar como eles respondem a eventos externos. Cada um desses eventos identificados testado individualmente, e o comportamento do sistema real comparado ao comportamento apontado pelo modelo; c) testes de interao entre tarefas, a fim de detectar erros de sincronizao entre as tarefas, aquelas que se comunicam so testadas com diferentes taxas de dados e cargas de processamento. Devem ser desenhados casos de teste para avaliar situaes de travamento, inanio e tamanho insuficiente de filas de mensagem.
2.6.2.2
TESTES NO FUNCIONAIS
Os testes no funcionais procuram detectar se o comportamento do software ou
sistema est consistente com a respectiva especificao dos requisitos quanto aos aspectos no funcionais. Esses testes cobrem por exemplo, desempenho, dados persistentes e outros atributos, como pode ser visto no Quadro 8 com mais detalhes. Quadro 8 - TIPOS DE TESTES DE SISTEMA Tipos de requisitos
Desempenho
Tipos de teste
Nmero de terminais suportados Nmero de usurios simultneos Volume de informao que deve ser tratado Freqncia de uso Restries de acesso Restries de integridade Requisitos de guarda e reteno dados Funcionalidade Confiabilidade Usabilidade Manutebilidade Portabilidade
Dados persistentes
19
20
Um bom caso de teste tem por objetivo detectar defeitos ainda no descobertos, ao invs de apenas demonstrar que o programa funciona corretamente. Ele deve obrigatoriamente incluir uma descrio das sadas esperadas, que ser usada para comparao com as sadas reais obtidas em cada execuo do caso de teste. Devem existir casos de teste que cubram tanto entradas vlidas quanto invlidas. Os casos de teste devem cobrir as combinaes de entrada relevantes para dar ao teste uma cobertura adequada. Alm disso, conveniente prever casos de teste para execuo de procedimentos errados mas possveis. Cada caso de teste deve corresponder a um conjunto de entradas e sadas esperadas. (Ramirez, 1999) conveniente classificar os casos de teste em categorias bem definidas. Uma classificao importante baseia-se na origem dos dados de teste (Hetzel, 1987). Os tipos principais, dentro dessa classificao incluem: a) casos funcionais (derivados das especificaes ou do entendimento do que o programa deve realizar); b) casos estruturais (derivados da estrutura lgica da codificao e das instrues do programa); c) casos de dados (derivados do entendimento e da definio dos elementos de dados e dos arquivos usados no programa); d) casos aleatrios (derivados de uma tcnica de aleatorizao ou amostragem, como os produzidos por geradores paramtricos de casos de teste); e) casos extrados (aproveitados de outros sistemas ou arquivos de produo); f) casos anormais ou extremos (selecionados numa tentativa deliberada de vencer o sistema, incluindo elementos como condies limtrofes e situaes extremas).
21
Esse conjunto de informaes, porm, no suficiente para a aplicao do caso de teste. preciso considerar que, a pessoa que determina o caso de teste no , obrigatoriamente, a mesma que efetivamente ir aplicar os casos de teste na busca por "bugs" no sistema. Outro fator importante que deve ser considerado, que pode se passar um intervalo de tempo razovel (dias, semanas, meses) entre o desenvolvimento dos casos de teste e sua efetiva aplicao. fundamental que um caso de teste seja repetvel, ou seja, se pessoas distintas em momentos e lugares distintos aplicarem o mesmo caso de teste sobre a mesma verso de um produto, imprescindvel que os resultados encontrados sejam rigorosamente os mesmos. Isso fundamental, principalmente, para que a equipe de desenvolvimento possa reproduzir os "bugs" relatados pela equipe de testes. Face a isso, razovel exigir uma documentao mais completa para cada caso de teste alm da simples determinao de um conjunto de valores de entrada e de seus respectivos resultados esperados. Normalmente as expresses "teste" e "caso de teste" so usadas indistintamente como sinnimos. Neste contexto iremos us-las com significados distintos. Ao usar "casos de teste" estaremos nos referindo ao resultado das tcnicas vistas at agora, ou seja composto por um conjunto de entradas e os respectivos resultados esperados. Ao usar a expresso teste, porm, estaremos nos referindo a descrio documentada de um teste, composta por todas as informaes necessrias para que o mesmo possa ser executado e repetido sem problemas (note que por repetido entende-se chegar sempre ao mesmo resultado esperado).
22
23
Os processos desta Norma formam um conjunto abrangente. Uma organizao, dependendo de seu objetivo, pode selecionar um subconjunto apropriado para satisfaz-lo. Esta norma , portanto, projetada para ser adaptada para uma organizao, projeto ou aplicao especficos. Tambm projetada para ser utilizada quando o software uma entidade independente ou embutida ou integrada a um sistema. Esta norma estabelece uma estrutura comum para os processos de ciclo de vida de software, com terminologia bem definida, que pode ser referenciada pela indstria de software. A estrutura contm processos, atividades e tarefas que servem para ser aplicadas durante a aquisio de um sistema que contm software, de um produto de software independente ou de um servio de software, e durante o fornecimento, desenvolvimento, operao e manuteno de produtos de software. Esta norma tambm prov um processo que pode ser utilizado para definir, controlar e melhorar os processos no ciclo de vida de software. Porm neste trabalho ser dado enfoque apenas s partes que dizem respeito teste de software, o processo de desenvolvimento, processo de operao e processo de apoio ao ciclo de vida.
24
a) deve desenvolver e documentar, cada unidade de software e base de dados e os procedimentos de teste e dados para testar cada uma dessas unidades e bases de dados; b) deve testar cada unidade de software e base de dados, garantindo que sejam atendidos seus requisitos. Os resultados dos testes devem ser documentados; c) deve atualizar a documentao do usurio, quando necessrio; d) deve atualizar os requisitos de teste e o cronograma, para integrao do software; e) deve avaliar o cdigo do software e os resultados dos testes. Os resultados das avaliaes devem ser documentados. A atividade de integrao do software, por sua vez deve ser realizada para cada item de software (ou item de configurao de software, se identificado) e consiste nas seguintes tarefas para o desenvolvedor de software: a) deve desenvolver um plano de integrao para integrar as unidades de software e componentes de software no item de software. O plano deve incluir requisitos de teste, procedimentos, dados, responsabilidades e cronograma e tudo deve ser documentado; b) deve integrar as unidades e componentes de software e testar essas agregaes medida que forem sendo integradas, de acordo com o plano de integrao. Deve ser garantido que cada agregao atenda os requisitos do item de software e que o item de software esteja integrado na concluso da atividade de integrao. Os resultados da integrao e dos testes devem ser documentados; c) deve atualizar a documentao do usurio, quando necessrio; d) deve desenvolver e documentar, para cada requisito de qualificao do item de software, um conjunto de testes, casos de teste (entradas, sadas e critrios de teste), e procedimentos de teste, para conduzir o teste de qualificao do software. O desenvolvedor deve garantir que o item de software integrado est pronto para o teste de qualificao do software; e) deve avaliar o plano de integrao, projeto, cdigo, testes, resultados dos testes e a documentao do usurio. Os resultados das avaliaes devem ser documentados.
25
A atividade de teste de qualificao do software deve ser realizada para cada item de software (ou item de configurao de software, se identificado) e consiste nas seguintes tarefas para o desenvolvedor de software: a) deve conduzir o teste de qualificao de acordo com os requisitos de qualificao para o item de software. Deve ser garantido que a implementao de cada requisito do software seja testada para conformidade. Os resultados do teste de qualificao devem ser documentados; b) deve atualizar a documentao do usurio, quando necessrio; c) deve avaliar o projeto, cdigo, testes, resultados dos testes e a documentao do usurio. Os resultados das avaliaes devem ser documentados; d) deve apoiar auditorias. Os resultados das auditorias devem ser documentados. Se ambos, hardware e software, esto sendo desenvolvidos e integrados, as auditorias podem ser adiadas at o teste de qualificao do sistema.
2.8.1.1
PROCESSO DE OPERAO
O processo de operao contm as atividades e as tarefas do operador. O processo
cobre a operao do produto de software e o suporte operacional aos usurios. Como a operao do produto de software est integrada operao do sistema, as atividades e tarefas deste processo se referem ao sistema. Este processo tem como atividade pertinente ao de teste de software, o teste operacional. Para cada liberao do produto de software, o operador deve executar o teste operacional e satisfazendo os critrios especificados, liberar o produto de software para uso operacional. O operador deve garantir que o cdigo de software e as bases de dados sejam iniciados, executados e finalizados, como descrito no plano.
2.8.1.2
atividades e tarefas num processo de apoio so de responsabilidade da organizao que o executa. Essa organizao garante que o processo existe e funcional. O processo de validao um processo para determinar se os requisitos e o produto final, sistema ou produto de software construdo, atendem ao uso especfico
26
pretendido. A validao pode ser conduzida nos estgios iniciais. Este processo pode ser conduzido como parte da atividade apoio aceitao do software. Este processo pode ser executado com variados graus de independncia. O grau de independncia pode variar da mesma pessoa ou outra pessoa da organizao, para uma pessoa de outra organizao. No caso em que o processo executado por uma organizao independente do fornecedor, desenvolvedor, operador ou mantenedor, chamado de Processo de Validao Independente. Este processo est dividido nas seguintes atividades, implementao do processo e a validao propriamente dita. A implementao do processo consiste nas seguintes tarefas: a) deve ser determinado se o projeto justifica um esforo de validao e o grau de independncia organizacional. Os requisitos do projeto devem ser analisados em funo dos fatores crticos. Estes fatores podem ser aferidos nos seguintes termos: O potencial de que um erro no detectado em um requisito do sistema ou software possa causar morte ou dano pessoal, no alcance de objetivos, perda ou dano financeiro ou de equipamento; A maturidade e riscos associados com a tecnologia de software a ser utilizada; A disponibilidade financeira e de recursos. b) Se o projeto justifica um esforo de validao, um processo de validao deve ser estabelecido para validar o sistema ou o produto de software. As tarefas de validao definidas a seguir, incluindo mtodos, tcnicas e ferramentas associados para executar as tarefas, devem ser selecionadas; c) Se o projeto justifica um esforo de validao independente, deve ser selecionada uma organizao qualificada responsvel para conduzi-la. O condutor deve ter assegurada a independncia e autoridade para executar as tarefas de validao; d) Um plano de validao deve ser desenvolvido e documentado. O plano deve incluir, mas no estar limitado ao seguinte:
27
itens sujeitos validao; tarefas de validao a serem executadas; recursos, responsabilidades e cronograma para validao; procedimentos para encaminhar relatrios de validao ao adquirente e outras partes envolvidas. O plano de validao deve ser implementado. Problemas e no-conformidades detectados pelo esforo de validao devem ser includos no processo de resoluo de problemas. Todos os problemas e no-conformidades devem ser resolvidos. Os resultados das atividades de validao devem ser disponibilizados para o adquirente e outras organizaes envolvidas. O processo de validao consiste nas seguintes tarefas: b) preparar os requisitos de teste, casos de teste e especificaes de teste selecionados para anlise dos resultados dos testes; c) assegurar que estes requisitos de teste, casos de teste e especificaes de teste reflitam os requisitos particulares para o uso especfico pretendido; d) conduzir os testes nos dois itens anteriores, incluindo: teste de estresse, limites e entradas especficas; teste do produto de software para verificar sua habilidade em isolar e minimizar efeitos de erros; isto , degradao suave em caso de falha, pedido de assistncia do operador em caso de estresse, de exceder limites e de condies especficas; teste para que usurios representativos possam executar, com sucesso, suas tarefas pretendidas usando o produto de software. e) Validar um produto de software, significa garantir que ele satisfaa seu uso pretendido. Testar o produto de software, quando apropriado, nas reas selecionadas do ambiente alvo.
28
29
30
31
pode ser utilizado em forma de constante ou ento diretamente o nmero em segundos representado o tempo desejado.
32
que diz respeito ao comportamento do software testado em diversas configuraes de mquinas e sistemas operacionais possveis.
33
3. DESENVOLVIMENTO
Para o desenvolvimento deste projeto, tomou-se como ponto de partida os mtodos utilizados pela WK WK Sistemas na atividade de teste de software. Permitindo com isto, verificar as deficincias em relao as normas e/ou tcnicas estudadas neste trabalho de concluso de curso, conforme apresentado no captulo 2. A WK WK Sistemas uma software house com sede em Blumenau e existe desde 1985. Projetou-se no mercado nacional ganhando prmios com sistemas contbeis. Hoje, a empresa produz softwares de gesto empresarial que utilizam das ltimas tecnologias disponveis no mercado. A empresa conta com o trabalho de mais de 50 funcionrios que contribuem na produo dos mais de 13 produtos de software desenvolvidos pela mesma. A partir disso, iniciou-se ento um estudo de normas e tcnicas que possam uniformizar e melhorar esta atividade to importante no ciclo de vida do software, que hoje no vista como muito importante pelas software houses. Na figura 2, demonstrado o funcionamento da atividade de teste de software hoje empregado pela WK Sistemas. Este fluxograma demonstra simplificadamente as etapas de desenvolvimento do de software dando mais nfase atividade de teste.
34
Incio
TE S TE S
Ve rifica o do s res ultad os da exe cu o dos testes . R elatrio gera do apon ta erro s?
S
G era o de ord em d e s erv io p ara repa ro n o s ist ema
N
Libe ra a v ers o
F IM
35
O fluxograma mostrado pela Figura 2 pode ser interpretado mais facilmente atravs do texto a seguir: Para iniciar um projeto de software necessrio cumprir-se vrias etapas. A primeira delas o levantamento das informaes. Esta etapa consiste em especificar detalhadamente todos os requisitos bsicos e necessidades do sistema, ou seja, funcionalidades, operaes atendimento s exigncias legislativas quando necessrio, entradas e sadas de dados. A partir da ento, parte-se para a especificao e redao do relatrio de levantamento. Nesta especificao, ser descrito como se dar a criao dos arquivos de dados de entrada do sistema a ser testado bem como em que momento acontece a integrao entre os mdulos do sistema testado. O relatrio de levantamento ter como contedo as informaes obtidas na etapa de especificao e traz uma descrio formal da funcionalidade do sistema de forma que o programador possa implement-lo de acordo com a especificao de cada etapa. Com a especificao pronta, equipes de programadores iniciam a
implementao de cada mdulo do sistema. Assim que liberada pelos programadores, a implementao compilada e so gerados os programas executveis, estes so encaminhados equipe de teste juntamente com os relatrios de levantamento para as devidas conferncias. a ento que inicia-se uma das etapas mais importantes do desenvolvimento de sistemas, a etapa de testes. A etapa de testes conta tambm com tecnologia de ponta. Uma ferramenta chamada Visual Test utilizada para a implementao de Scripts que simulam a entrada de dados de um usurio qualquer (Arnold, 1999). Por fim, implementa-se tambm rotinas que verificam valores calculados, dados gravados e toda e qualquer sada de resultados que o sistema em questo pode gerar. Para implementar este Scripts, deve-se fazer um estudo prvio do sistema atravs dos relatrios de levantamento para se poder saber como, onde, e de que maneira os dados digitados pelo usurio devem ser gravadas e ou calculadas. Utiliza-se tambm os casos de uso como fonte de informaes para implementar um roteiro de testes. Os casos de uso so descritos pelos gerentes de produto e ou analistas e retratam a realidade do sistema de forma que contenha as informaes que devem ser utilizadas para cada cadastro simulando a utilizao do sistema por parte de um usurio final/cliente. indispensvel tambm que os casos de uso contenham
36
todas as informaes sobre integraes, clculos, tamanhos e tipos de cada campo de entrada e/ou armazenamento de dados, arquivos que so criados no decorrer dos cadastros e movimentaes, resultados finais em relatrios e seqncia da implantao dos dados. Com todas essas informaes bem detalhadas possvel implementar um roteiro de testes eficiente. Uma vez implementados, os scripts de teste so executados. Eles geram um arquivo de relatrio com os resultados da execuo. Por exemplo, se algum procedimento especificado no teste no foi feito corretamente pelo software testado, este relatrio de resultado apontar qual a falha, seja ela de gravao incorreta de algum dado ou de algum processo gerado incorretamente pelo sistema como clculos e ou integraes. Estes resultados so analisados e, se nenhum erro for encontrado no sistema, este pode ser liberado para o mercado, caso contrrio, o sistema volta para a programao com o resultado dos testes apontando os erros encontrados. Estes erros so corrigidos e o sistema retorna mais uma vez para os testes. Visto que os Scripts j esto prontos, basta execut-los novamente. recomendvel que os scripts sejam executados novamente do incio ao fim e no apenas a partir da parte corrigida pelo programador, pois uma alterao no sistema, por menor que seja, pode afetar todo o programa bem como seu desempenho e funcionalidade. Eis a uma imensa vantagem em se automatizar os testes de software. O teste de software geralmente trabalhoso na sua implementao, entretanto quando pronto, pode ser repetido tantas vezes quantas forem necessrias sem qualquer trabalho adicional de implementao e com muita rapidez e agilidade. Nos prximos captulos, sero apresentados de que maneira chegou-se a uma soluo automatizada de teste de software baseando-se em normas e tcnicas especficas este tipo de atividade. Estas normas e tcnicas foram estudadas ao longo do desenvolvimento deste trabalho e tomadas como referncia para a implementao do prottipo.
3.1 ESPECIFICAO
Apresenta-se na especificao, um diagrama que esquematiza a realizao dos testes de software de uma forma automatizada. Este diagrama, representado pela Figura 3, demonstra a funcionalidade do prottipo.
37
Program dor de T es te
Gerente de Produto
Programador de teste: responsvel pelo desenvolvimento dos scripts de teste, bem como sua execuo. Construir Script: esta ao resume-se pela codificao dos scripts de teste. Esta codificao feita pelo programador de teste utilizando-se a ferramenta Visual Test. Executar Script: esta ao representa a execuo dos scripts de teste codificados na etapa anterior sobre o software submetido ao teste. Neste caso, o Radar Contbil. Gerar Relatrio de Erros: esta ao responsvel pela gerao de um relatrio em formato de arquivo texto, com os resultados obtidos no teste. Este relatrio contm todos os erros encontrados durante a execuo do teste no referido software testado. Gerente de Produto: Ator responsvel pela anlise e avaliao dos resultados obtidos com a execuo do teste.
38
Partindo da funcionalidade deste diagrama, deve-se implementar uma soluo automatizada de teste de software seguindo a especificao a seguir. O software a ser submetido ao teste o Radar Contbil da empresa WK Sistemas. Deve-se implementar um conjunto de scripts de teste que o alimentem a partir de uma base vazia com informaes necessrias a fazer movimentaes contbeis. Em cada caso de teste, cada um correspondendo a um Script implementado, deve ser includa a restaurao da base de dados gerada pelo caso de teste anterior, no incio de sua execuo. Ao seu final, deve-se efetuar o backup do estado atual da base de dados para que possa ser utilizado no caso de teste seguinte. Depois de todos os cadastros terem sido implementados, deve-se partir para a movimentao contbil propriamente dita, ou seja, lanamentos contbeis de recebimentos, pagamentos, transferncia entre outros. Como ltima etapa, tem-se as verificaes. Esta a etapa mais importante, nela devero ser analisados todos os campo de cada cadastro. Se algum dado tiver sido gravado incorretamente, o sistema automatizado de teste deve informar em um relatrio de erros qual o campo e de que cadastro no houve sucesso na gravao Para as movimentaes, o sistema de automatizao de teste deve fazer as movimentaes propriamente ditas, verificar as gravaes dos registros das mesmas atravs dos saldos contbeis, executar a excluso de um registro verificar novamente o saldo. Se encontrado algum erro durante em alguma destas operaes, o sistema de testes deve registrar a descrio do mesmo no relatrio de erros. Este relatrio de erros, um arquivo de formato texto, seu modelo pode ser visto atravs da Figura 4.
39
O prottipo ainda deve conter uma soluo automatizada para os testes de aceitao, regresso e integrao conforme especificado pela norma estudada neste trabalho. Alm disso os testes de anlise do valor limite, testes de desempenho e restries de integridade, todos estudados neste trabalho, devem ser implementado no prottipo.
3.2 IMPLEMENTAO
Conforme o proposto pelo trabalho, a implementao do prottipo baseou-se nas normas e tcnicas de teste de software estudadas neste trabalho de concluso de curso. Seguindo esta idia, este captulo apresentar de que maneira o software implementado para automatizao de teste atende s normas e tcnicas estudadas. Conforme apresentado no captulo 2.2, o objetivo central de um teste de software descobrir erros, e partindo deste princpio que esta implementao foi iniciada. Os testes
40
foram implementados para encontrar erros no sistema, porm o sistema submetido ao teste, o Radar Contbil, no apresentou defeitos. Mas, como Souza (2000) afirma, impossvel testar um software completamente, portanto a no descoberta de defeitos no Radar Contbil, no significa que este esteja livre de bugs. Segundo as metodologias de teste de software propostas pela IEEE (1994), devese fazer um comparativo dos resultados previstos com os obtidos na execuo do teste. Neste projeto o comparativo foi feito na prpria implementao do teste automatizado, onde o valor esperado para o saldo de uma determinada conta contbil, comparado com o obtido na execuo do teste. Se este valor no for idntico ao esperado, um log sobre o erro gravado no arquivo texto que contm o resultado completo do teste. Ainda seguindo as metodologias de teste de software, tem-se basicamente duas maneiras de se construir testes, os testes de caixa branca e os de caixa preta. Os testes de caixa branca, que agregam os testes de unidade, como j foi visto anteriormente tm por objetivo testar a estrutura interna do sistema, ou seja, o cdigo fonte, por este motivo no foi implementado, pois a ferramenta de automatizao de testes utilizada, o Visual Test, no permite tal implementao. Este teste deve ser feito pelo programador, assim como os testes de unidade que so parte integrante da metodologia de teste de caixa branca. J os teste de caixa preta, agregam os testes de aceitao e regresso cuja forma de implementao no prottipo ser vista adiante. As bateias de testes estudadas so os testes de unidade, testes de integrao, testes de aceitao e regresso. Os testes de unidade, como vimos anteriormente no foram executados, pelo motivo de ser teste que exige a disponibilidade do cdigo fonte do produto, na qual no teve-se acesso parta este projeto, e pelo fato de a ferramenta de automatizao de testes utilizada neste projeto, no permitir este tipo de teste. As demais baterias de teste podem ser vista a seguir. O teste de regresso o mais indicado para a ser automatizado, pois seu objetivo testar o sistema por completo partido de uma base de dados vazia. Sendo assim, o prottipo implementado atende perfeitamente a este teste. Por ser um teste completo do sistema, no tem-se uma parte especfica do prottipo que implementa este teste, a execuo completa do projeto de teste, ou seja, todos os scripts, implementam a soluo para este teste.
41
Para o teste de aceitao pode-se apontar uma parte do prottipo como sendo fundamental para este teste. Como o sistema submetido ao teste um sistema contbil, para implementar o teste de aceitao, tomou-se como base os saldos contbeis, estes indicam se a finalidade do sistema que de contabilizar valores, est de acordo com o que previsto pela legislao. A codificao referida a este teste pode ser vista a seguir no Quadro 10. Os testes de integrao esto implicitamente inseridos ao longo de todo o prottipo. Como j visto anteriormente, eles tm como objetivo verificar se as unidades que compem cada liberao funcionam corretamente em conjunto com as unidades j liberadas. Contudo, este teste executado implicitamente ao se executar um teste completo do sistema. Quadro 10 CODIFICAO PARA O TESTE DE ACEITAO
Scenario "Verifica Saldo" 'VERIFICA SALDO DO ATIVO WEditSetText("#1211","17") 'Conta sleep 1 Play "{TAB}" WEditSetText("#1212","01/01/99") 'Data Inicial sleep 1 Play "{TAB}" WEditSetText("#1213","31/12/01") 'Data Final Sleep 1 Play "{TAB}" WButtonClick("OK") Sleep 1 IF ((StaticText("#1060") = "95.028,00") and (StaticText("#1061") = "107.724,00")) and (StaticText("#1062") = "237.304,00") then certo1 = 1 else LogErros(Cabecalho,"O SALDO DO ATIVO NO CONFERE, algum lanamento no foi efetuado com sucesso.", Cabecalho) end if 'VERIFICA SALDO DO PASSIVO WEditSetText("#1211","939") 'Conta sleep 1 Play "{TAB}" WEditSetText("#1212","01/01/99") 'Data Inicial sleep 1 Play "{TAB}" WEditSetText("#1213","31/12/01") 'Data Final Sleep 1 Play "{TAB}" WButtonClick("OK") Sleep 1 IF ((StaticText("#1060") = "8.400,00") and (StaticText("#1061") = "340,00")) and (StaticText("#1062") = "241.940,00") then certo2 = 1 else LogErros(Cabecalho,"O SALDO DO PASSIVO NO CONFERE, algum lanamento no foi efetuado com sucesso.",Cabecalho) end if Sleep 1 tudocerto = (certo1 + certo2) IF tudocerto = 2 then LogErros(cabecalho,"No foram encontrados erros",Cabecalho) MSGBOX "TUDO CERTO, os LANAMENTOS foram efetivados com Sucesso!!!",MB_ICONINFORMATION,"Teste de Ltos Normais" else VisualizaArquivo() End IF WButtonClick("Cancelar") WMenuSelect("&Arquivo\&Sair") Maximiza() End Scenario
42
O captulo 2.5 mostrou que as atividades de teste de software esto divididas em dois grandes grupos: preparao e realizao dos testes. Para etapa de preparao dos testes para este trabalho de concluso de curso, foi utilizado o material desenvolvido pela WK WK Sistemas na qual no pode ser retirado da empresa. Por este motivo no est exposto neste trabalho. No captulo 2.5.1 foi mostrado como devem ser tratados o planejamento dos testes. Este planejamento est dividido em 3 tarefas separadas: planos de testes, planejamento inicial e identificao dos itens a testar. Para este trabalho de concluso de curso foi utilizado o seguinte plano de teste demonstrado no Quadro 11. Quadro 11 PLANO DE TESTES Item
Identificar o plano de testes Introduo Itens a testar
Descrio
Teste do Radar Contbil Implementao de testes automatizado afim de encontrar erros ainda no descobertos. Implantao da Base de dados. Cadastros de: Usurios, Estado e Municpios, Propriedades, Empresas/Filiais, Plano Empresarial, Relacionamentos, Histricos, Mensagens, ECFs, Documentos, Naturezas de Operao, Vendedores, Tipos de Cobrana, Tipos de Vencimento, Forma de Pagamento, Produtos, Servios, Tipos de Perodo, Condies de Pagamento e Percentual de Rateio. Movimentaes: Saldo Anterior, Lanamentos Normais e Lanamentos em Lote. Gravao e conferncia dos registros. Utilizao do sistema em modo multi-usurio. No definido. Verificar se o dado inserido na gravao, realmente o que foi gravado. Verificar valores contbeis conforme especificao da WK WK Sistemas. (Esta especificao no liberada pela empresa) Se a base de dados for danificada em qualquer ponto do teste, o mesmo deve ser reiniciado com uma base vazia. Os resultados do teste devem ser registrados em um arquivo texto pela prpria automatizao do teste. No definido. Windows 98. No definido, pois para este trabalho no utilizou-se uma equipe de teste. No definido por se tratar de um trabalho de concluso de curso. No definido. Nome assinatura dos responsveis pela criao do plano no possvel por se tratar de um trabalho de concluso de curso.
Aspectos a testar Aspectos que no sero testados Abordagem Critrios de completeza e sucesso Critrio de suspenso e retomada Resultado do teste Tarefas de teste Ambiente Responsabilidades Agenda Riscos e contingncias Aprovao
43
O planejamento inicial dos testes no foi executado pois seria necessrio ter acesso aos documentos sobre a especificao do software na qual o acesso restrito ao uso interno da empresa WK WK Sistemas. A identificao do itens a testar no foi especificada pois foi utilizado o item itens a testar do Quadro 11 visto anteriormente. O captulo 2.5.2 apresentou como deve ser construdo um desenho de caso de teste. Conforme exposto neste mesmo captulo, seriam necessrios documentos como a especificao dos requisitos do software submetido ao teste entre outros insumos para a execuo deste item. Por se tratar de um trabalho de concluso de curso, o acesso a esses documentos no foi possvel, eles so de uso restrito da empresa e por este motivo este item no foi executado neste projeto. Conforme visto no item 2.5.2.1, que trata sobre especificaes de teste, os testes de software devem seguir uma ordem lgica de execuo porque geralmente cada procedimento de teste corresponde a um resultado de teste anterior, o que gera uma dependncia com a execuo anterior e sua respectiva base de dados gerada. Esta dependncia e ordem lgica de execuo pode ser percebida na implementao pela disposio dos arquivos de caso de teste que so criados prevendo-se esta dependncia como pode ser visto na Figura 5. O captulo 2.5.2.2 traz uma denotao sobre desenho de procedimento de teste, onde seu principal insumo descrever a seqncia de passos necessria para executar uma variao de teste. Neste projeto esta seqncia est aplicada na prpria estrutura hierrquica dos arquivo de scripts de teste como pode ser visto na figura 5 a seguir.
44
A dependncia da base de dados gerada por uma caso de teste anterior tambm implementada no prottipo e seu cdigo fonte pode ser visto no Quadro 12. Este quadro apresenta a codificao de restaurao de dados de um caso de teste anterior e o seu respectivo backup para o caso de teste seguinte.
45
Scenario "BKP dos Dados" if carinha = 2 or carinha = 3 then run "deltree /y d:\TCC\BKP\ECFS" run "xcopy c:\wkradar\dados\TESTE\*.* d:\TCC\BKP\ECFS /s /i" end if End Scenario
Na seqncia, o captulo 2.5.2.3 tratou sobre desenho de caso de teste e que pde ser visto tambm com mais detalhes no captulo 2.7. Estes desenhos so um conjunto especfico de dados de teste juntamente com os resultados esperados. Estas informaes devem ser descritas pelo gerente do produto submetido ao teste. Para este trabalho de concluso de curso o desenho de caso de teste no foi realizado pela falta de informaes e documentos necessrios para a completeza deste item, pois os materiais descritos pelo gerente de produto do software submetido ao teste, pertencem a empresa WK WK Sistemas no podem ser retirados da mesma, por conseqncia disto, o captulo 2.5.2.4 que trata sobre a reviso do desenho de teste no pde ser realizada. O prximo captulo estudado foi o 2.5.3, implementao dos testes, que a etapa onde o ambiente de teste preparado. Para aplicao deste item neste trabalho, a preparao do ambiente foi realizada instalando-se o software submetido ao teste, o Radar Contbil, e a ferramenta de automatizao teste, o Visual Test. Dando seqncia a esta etapa, tem-se a execuo dos testes, vista no item 2.5.4. Esta etapa cumprida quando a execuo propriamente dita dos scripts realizada e os relatrios referentes aos resultados dos testes so gerados. A verificao do trmino dos testes descrita no captulo 2.5.5 realizada atravs de observao direta da execuo dos testes automatizados verificando-se, se o seu trmino efetivou-se de uma maneira normal.
46
O balano final exposto pelo captulo 2.5.6, no foi realizado. Pois, a realizao deste item est voltada para testes que possam ter continuidade em outros softwares. Este trabalho no se enquadra a este item pelo fato de submeter um nico sistema aos testes. O item 2.6.2.1 fala sobre testes funcionais. Este tipo de teste est subdividido em anlise do valor limite, testes de comparao e testes de tempo real. O prottipo de automatizao de teste implementado neste trabalho, atende em parte o teste funcional. A anlise de valor limite est implementada no prottipo e pode ser vista atravs do Quadro 12. O teste de comparao proposto, no foi implementado explicitamente mas se tomarmos duas verses do Radar Contbil, software submetido ao teste, e submeter estas duas verses execuo dos testes implementados no prottipo deste trabalho comparando os resultados das duas verses, teremos o teste de comparao efetuado. J a automatizao dos testes de tempo real no vivel por serem testes minuciosos e variados. Alm disso, o software em questo submetido ao teste, no um tipo de sistema que possa ser submetido a este tipo de teste.
47
WMenuSelect ("&Editar\&Incluir") WEditSetText("#1001","005") play "{TAB}" if EditText("#1003") = "Banco Internacionali" then resultado% = 1 else LogErros(Cabecalho,"O Campo FANTASIA no foi gravado corretamente",Cabecalho) end if if EditText("#1004") = "Banco Internacional S/A Pan-Americano do Desenvolv" then resultado% = resultado% + 1 else LogErros(Cabecalho,"O Campo DENOMINAO SOCIAL no foi gravado corretamente",Cabecalho) end if if resultado% = 2 then LogErros(cabecalho,"No foram encontrados erros",Cabecalho) MsgBox "Todos os dados foram gravados corretamente!",MB_ICONINFORMATION,"Verificao" Else VisualizaArquivo() End If SLEEP 1 WButtonClick("Cancelar") WMenuSelect("&Arquivo\&Sair") End Scenario
O item 2.6.2.2 trata sobre testes no funcionais, esses testes cobrem por exemplo, desempenho, dados persistentes e outros atributos de qualidade. Dois desses itens, desempenho e dados persistentes, esto implementados no prottipo. Quanto ao desempenho, foi implementado um teste na qual feito um looping definido pelo programador de teste, com os lanamentos contbeis. Parte de um exemplo de script para esse tipo de teste pode ser visto no Quadro 13.
48
dias$ = GeraDia() WEditSetText("#1002","1") ' FILIAL Sleep ENTRE Play"{TAB}" WEditSetFocus("#1003") 'DATA Play (dias$) 'DIA Play (mes$) 'MES Play (ano$) 'ANO Sleep ENTRE Play"{TAB}" WEditSetText("#1018","46") 'CTA DBITO Sleep ENTRE Play"{TAB}" WEditSetText("#1019","81") 'CTA CRDITO Sleep ENTRE Play"{TAB}" WEditSetText("#1080","1000") 'VALOR Sleep ENTRE Play"{TAB}" WEditSetText("#1033","07.04") 'HISTRICO Play "{TAB}" Sleep ENTRE WButtonClick("OK") Sleep INCLUI TelaGerencial() 'VERIFICA SE TEM GERENCIAL
Ainda continuando com os testes no funcionais tem-se o teste de restries de integridade atravs de dados persistentes. Este teste tambm implementado pelo prottipo e pode ser visto no Quadro 14. Esta implementao d-se atravs da tentativa de incluir um registro em um determinado cadastro com sua chave duplicada, o resultado registrado no relatrio de resultados do teste.
49
Cabecalho = ("RESTRIES DE INTEGRIDADE") LogErros(Cabecalho,"","2") WmenuSelect("&Editar\&Incluir") WEditSetText("#1001","1") 'Cdigo play "{TAB}" Cabecalho = ("CADASTRO DE TIPOS DE COBRANA") LogErros(Cabecalho,"","2") if EditText("#1003") = "Cobrana Simples" then 'Descrio LogErros(cabecalho,"No foram encontrados erros",Cabecalho) MsgBox "Todos os dados foram gravados corretamente!",MB_ICONINFORMATION,"Verificao" else LogErros(Cabecalho,"O Campo DESCRIO no foi gravado corretamente",Cabecalho) VisualizaArquivo() end if Sleep 1 WButtonClick("Cancelar") Sleep .5 WMenuSelect("&Arquivo\&Sair") End Scenario
No item 2.5.4, execuo dos testes, sugerido por Ramirez (2001) que os testes devem resultar em um relatrio que contenha os problemas encontrados. O prottipo de automatizao de teste implementado neste trabalho, possui uma funo que pode ser vista no Quadro 13, que implementa a criao de um relatrio com o resultado completo dos testes conforme proposto pela IEEE segundo Ramirez (2001). Este relatrio gerado automaticamente pelo prottipo com a descrio de cada erro encontrado em um arquivo texto gerado em um diretrio especificado previamente pelo programador de teste.
50
O item 2.8 trata sobre a norma brasileira ABNT NBR 12207 e suas sugestes e recomendaes quanto aos testes de software. Dos trs captulos abordados pela norma, processo de desenvolvimento, processo de operao e processo de apoio ao ciclo de vida, apenas os dois ltimos esto implementados no prottipo. O processo de desenvolvimento,
51
trata de uma forma terica como deve ser estruturado o processo de desenvolvimento de software sendo utilizada apenas como uma fase introdutria s demais. Por este motivo , no vivel e nem possvel a sua implementao. Quanto ao processo de operao, como j foi visto anteriormente este efetuado pelo operador e a execuo dos testes propriamente ditos, ou seja, executando todos os scripts de atende-se a este item da norma ABNT NBR 12207. O processo de apoio de ciclo de vida tem como enfoque ao teste de software o teste de validao, este serve para determinar se os requisitos do sistema submetido ao teste atendem sua especificao. Este teste tambm est implicitamente implementado no prottipo de automatizao de teste, pois se, aps executado por completo, no forem encontrados erros, significa que o sistema atende aos seus requisitos especificados. Deve-se levar em considerao que o teste automatizado deve estar implementado corretamente de forma com que os valores e dados utilizados no teste possa validar corretamente o produto. Enfim, todas as tcnicas e normas estudadas neste trabalho que foram possveis de ser implementadas, esto inseridas no prottipo, algumas de forma implcita e outras explicitamente conforme proposto pelas normas avaliadas no presente trabalho.
52
pressionado a tecla F5 ou o cone prprio para esta tarefa. Ou ento, tem-se ainda a opo de executar o programa de teste gerado em formato executvel correspondente ao referido caso de teste escolhido. Uma vez executado o teste, aguarda-se o fim do mesmo e verifica-se o arquivo de resultados gerado pelo mesmo, este conter a descrio dos erros se eles existirem.
53
no que sugerido pela norma. Porm os testes de unidade, que conforme a norma sugere, deve ser realizado na fase de desenvolvimento pelo prprio programador, testando as funes, classes, procedimentos internos do sistema, ou seja, o cdigo fonte, no praticado pela empresa conforme a norma sugere. importante salientar que a empresa possui uma equipe de testes capacitada para esta atividade. Esta equipe faz uso de ferramentas que auxiliam na produo dos testes de uma forma eficiente e rpida. Os resultados dos testes so analisados e encaminhados equipe de desenvolvimento quando necessrio. A utilizao de testes automatizados pela empresa, mostra no Quadro 16, que a velocidade dos testes manuais em relao automatizao de um mesmo item de teste, aumenta espantosamente. Estes itens de testes esto relacionados ao teste do Radar Contbil, software submetido ao teste utilizado ao longo deste projeto. Quadro 17 Velocidade de execuo de Testes Manuais x Testes Automatizados
Item submetido ao teste Cadastro de um plano de contas completo Cadastro de empresas filiais Movimentaes contbeis referentes a um ano de exerccio. Tempo em minutos do teste manual 480 90 260 Tempo em minutos do teste automatizado 3 0.7 2
Enfim, a empresa, mesmo sem ter tomado como referncia as propostas destas normas, est praticando o sugerido pelas mesmas, mas com uma certa limitao. Esta limitao caracteriza-se pelo fato de que apenas alguns tipos e tcnicas de testes de software sugeridos pelas normas so utilizados pela WK, porm outros que no so utilizados mas considerados importantes para o autor, no esto sendo empregados. Como o caso dos desenhos de casos de teste e testes de caixa preta na qual introduzem os testes de unidade, que so os testes na estrutura internas dos sistemas. Se este teste fosse adotados, certos erros bsicos de codificao (por exemplo, erros de anlise de valor limite em relao ao tamanho e/ou tipo de dados de entrada) poderiam ser detectados j na fase de desenvolvimento pelos prprios programadores do sistema. Para aprimorar ainda mais sua atividade de teste, o autor sugere que a WK Sistemas comece a criar seus casos de teste para cada um de seus sistemas, bem como executar os teste de caixa preta. O autor acredita que, com a implementao destes dois itens,
54
pode-se dizer que a WK Sistemas torna-se uma empresa que possui um processo de testes de seus softwares que atende s sugestes das normas, estudadas neste trabalho. Estas recomendaes estendem-se a todas as empresas de desenvolvimento de software, no sentido de melhorarem a qualidade de seu processo de desenvolvimento, e, conseqentemente, de seus produtos.
55
4. CONCLUSES
O presente trabalho apresenta os resultados da elaborao de um estudo de algumas normas de qualidade e as atividades de teste de software empregadas pela WK Sistemas, empresa usada como objeto de estudo deste trabalho. Alm disso, este trabalho sugere melhorias e aperfeioamentos no processo de teste de software nesta empresa, que podem ser estendidos a outras empresas com atividade de desenvolvimento de software. O trabalho tambm implementa um prottipo para a automatizao dos testes que contm diversos tipos de testes sugeridos pelas normas estudadas. Os tipos de testes implementados pelo prottipo so: testes de aceitao incluindo os funcionais e no funcionais, testes de regresso, aceitao e integrao, alm de a prpria estruturao dos arquivos de teste(Scripts) estarem dispostos de forma organizada seguindo a ordem lgica de execuo conforme a norma recomenda. Contudo, o prottipo permite dar qualidade, rapidez e eficincia aos testes de software aumentando cerca de 140 vezes a velocidade de execuo de um teste manual para um automatizado. Este nmero diz respeito ao teste automatizado criado para este trabalho de concluso de curso destinado ao Radar Contbil que foi o software submetido ao teste. O prottipo implementado no decorrer deste trabalho de pesquisa realiza de maneira automatizada diversos tipos de teste, tais como testes de regresso, testes funcionais e testes no funcionais. Alm de tambm gerar relatrios com a descrio de erros encontrados no sistema testado. Tais relatrios so de extrema utilidade para a posterior avaliao dos problemas existentes no produto testado. Portanto, conclui-se que a criao do prottipo foi bem sucedida. Alm disso, o teste de software criado para o Radar Contbil neste trabalho, baseou-se nas normas de qualidade estudadas no decorrer captulo 2, e pode ser visto pelo captulo 3.2 de que maneira estas tcnicas e normas de teste de software foram aplicadas. Contudo, concluiu-se que, nem todas as metodologias, tcnicas e/ou normas de qualidade aqui estudadas, puderam ser aplicadas neste trabalho. Pois algumas delas dependem de documentos entre outros insumos que no foram disponibilizados. Outra observao conclusiva refere-se ao fato de que a anlise das normas estudadas indica que mesmo sendo impossvel testar um sistema por inteiro, a qualidade final
56
dos softwares testados tende a melhorar significativamente se as suas sugestes forem seguidas. Um dos grandes motivos que levaram ao desenvolvimento desta pesquisa foi a percepo por parte do autor em relao grande deficincia no processo de desenvolvimento de software hoje, evidenciada pela falta de uma estratgia bem definida para a realizao de testes, devido principalmente ao desconhecimento das normas e tcnicas utilizadas para este tipo de atividade.
4.1 LIMITAES
O prottipo atende apenas ao teste do sistema para qual ele foi implementado, se for desejado testar algum outro sistema, deve-se implementar novos scripts de teste. A ferramenta utilizada para a gerao dos Scripts, voltada para sistemas desenvolvidos em Visual C++, mas isso no significa que seja limitado somente a esta linguagem, porm funciona com mais eficincia nela.
4.2 EXTENSES
Como extenses deste trabalho, sugere-se, a realizao de avaliaes de outras ferramentas para automatizao de testes de software, pois possvel que determinadas ferramentas sejam mais adequadas a determinados tipos de testes ou determinados tipos de sistemas, e isto foge ao escopo do presente trabalho. Como caso tpico, pode-se imaginar ferramentas que sejam mais adequadas ao teste de softwares no convencionais tais como sistemas que realizem processamento vetorial ou softwares que implementem algoritmos paralelos. Alm disso, uma possvel extenso seria a aplicao dos testes propostos neste trabalho em empresas que no desenvolvem atividades de teste de uma forma organizada e metdica. Assim, possvel fazer um levantamento do grau de melhoria de qualidade que os testes de software, nos padres das recomendaes da ABNT, podem trazer ao processo de desenvolvimento de software dessas empresas e, principalmente, a qualidade de seus produtos finais.
57
REFERNCIAS BIBLIOGRFICAS
ARNOLD , Thomas R. Visual test 6 bible. Chicago: IDG Books World Wide, 1999. ASSOCIAO BRASILEIRA DE NORMAS TCNICAS. NBRISO/IEC12207: tecnologia de informao processos de ciclo de vida de software. Rio de Janeiro, 1998. GIMENES, I. M. S. Ferramentas CASE. Maring: Makrow, 1994. HETZEL, W., Guia completo ao teste de software. Rio de Janeiro: Campus, 1987. IEEE. IEEE Standard Collection. Software Engineering. IEEE, New York, 1994. MARTIMIANO, L. A. F., Integrao da ferramenta de teste de software Poke-Tool em PCTE. 1995. Trabalho de Graduao, DIN/UEM, Maring. OLIVEIRA, Flvio Moreira de. Teste de software, Porto Alegre, dez. [1997]. Disponvel em: <http://www.inf.pucrs.br/~flavio/teste/>. Acesso em: 27 abr. 2001. POSTON, R.M. Automating specification-based software testing. IEEE computer society. Chicago: Books, 1996. RAMIREZ, Jaime Arturo. Teste de software, Belo Horizonte, dez. [1990]. Disponvel em: <http://ead1.eee.ufmg.br/~renato/engsoft/Teste_Soft.pdf>. Acesso em: 13 fev. 2001. ROBERT, MaryAnn; MARYANSKI, Fred J. Automated test plan generator for database application systems. California: Transctions of ACM, 1991. SOUZA, Simoni do Rocio Senger. Introduo ao teste de software, Paran, out. 2000. Disponvel em: <www.pbnet.com.br/openline/cefet/horario_sbes_englihs.htm>. Acesso em: 18 abr. 2001.