Teste de Software

download Teste de Software

of 67

Transcript of Teste de Software

UNIVERSIDADE REGIONAL DE BLUMENAU CENTRO DE CINCIAS EXATAS E NATURAIS CURSO DE CINCIAS DA COMPUTAO (Bacharelado)

TESTES DE SOFTWARE A PARTIR DA FERRAMENTA VISUAL TEST

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

BLUMENAU, JUNHO/2001 2000/1-50

TESTES DE SOFTWARE A PARTIR DA FERRAMENTA VISUAL TEST

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

Prof. Dr. Paulo Csar Rodacki Gomes - Orientador

FURB

Prof. Jos Roque Voltolini da Silva Coordenador do TCC

BANCA EXAMINADORA

Prof. Dr. Paulo Csar Rodacki Gomes

Prof. Everaldo Artur Grahl

Prof. Dr. Oscar Dalfovo

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

AGRADECIMENTOSAo 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

SUMRIOLISTA 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

v

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

REFERNCIAS BIBLIOGRFICAS .............................................................................. 57

vi

LISTA DE QUADROSQuadro 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 FIGURASFigura 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

RESUMOO 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

ABSTRACTSoftware 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.

x

1

1. INTRODUOOs 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.

2

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.

3

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 OBJETIVOSO 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 ESTRUTURAO 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.

4

2. TESTE DE SOFTWAREEste 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.

2.1 ATIVIDADE DE TESTESA atividade de testes uma etapa crtica para o desenvolvimento de software. Freqentemente, a atividade de testes insere tantos erros em um produto quanto a prpria implementao. Por outro lado, o custo para correo de um erro na fase de manuteno de 60 a 100 vezes maior que o custo para corrig-lo durante o desenvolvimento. Embora as revises tcnicas sejam mais eficazes na deteco de defeitos, os testes so importantes para complementar as revises e aferir o nvel de qualidade conseguido. A realizao de testes , quase sempre, limitada por restries de cronograma e oramento. importante que os testes sejam bem planejados e desenhados, para se conseguir o melhor proveito possvel dos recursos alocados para eles. Um objetivo central de toda a metodologia dos testes maximizar a cobertura destes. Deseja-se conseguir detectar a maior quantidade possvel de defeitos que no foram apanhados pelas revises, dentro de dados limites de custo e prazos. Os testes no provam que um programa est correto, somente contribuem para aumentar a confiana de que o software desempenha as funes especificadas (Souza, 1996). Existem duas grandes razes para se testar software, fazer um julgamento sobre qualidade e descobrir problemas. Na verdade, testa-se porque sabe-se que as atividades

5

humanas so passveis de falha e, isso especialmente verdade no domnio de desenvolvimento de software.

2.2 OBJETIVOS E LIMITES DO TESTE DE SOFTWAREA atividade de teste o processo de executar um programa com a inteno de descobrir um erro, sendo assim, um bom caso de teste aquele que tem uma elevada probabilidade de revelar um erro ainda no descoberto. A atividade de teste no tem a capacidade de mostrar a ausncia de bugs(falhas e/ou erros encontrados em um programa de computador). Ela s pode mostrar se defeitos de software esto presentes. Tem-se como principal objetivo, projetar testes que descubram sistematicamente diferentes classes de erros e faam-no com uma quantidade de tempo e esforo mnimos. Se a atividade de teste for conduzida com sucesso, ela descobrir erros no software. Um plano de testes realista prev a soluo de uns poucos casos de teste a partir de milhares de casos possveis. No importando quo minuciosos forem os testes, nunca encontra-se o ltimo bug de um programa, ou se encontrado, no se sabe que tal ocorreu. Para Souza (2000), impossvel testar um programa completamente. Testar um programa completamente significa que no existe absolutamente mais nenhum bug a ser encontrado. Para garantir que um programa est completamente testado necessrio testar todas as combinaes de entradas vlidas (em um programa que soma dois dgitos so aproximadamente 39600 entradas vlidas) , todas as combinaes de entradas invlidas (testar todas as possveis combinaes do teclado que no sejam pares vlidos de 1 ou 2 dgitos). Deve-se testar tambm todas as possibilidades de edio (se o programa permite editar os valores digitados, preciso testar todos os recursos de edio e verificar se o resultado de uma edio ainda uma entrada vlida). Todas as possibilidades em relao ao tempo (por exemplo: se digitamos dois nmeros rpido demais, intercalados por e o programa no consegue capturar um dos valores) (Oliveira, 1997). Finalmente, para este autor, o mais complexo testar todas as entradas possveis em qualquer ponto que o programa permita entradas de dados, em todos os estados possveis que ele pode atingir nesses pontos. Esta tarefa praticamente impossvel. Como exemplos de situaes que normalmente no so testadas, pode-se citar:

6

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.

2.3 METODOLOGIAS DE TESTE DE SOFTWARESegundo o IEEE (1994), para serem eficazes, os testes devem ser cuidadosamente desenhados e planejados. Os testes irreproduzives e improvisados devem ser evitados. Durante e aps a realizao dos testes, os resultados de cada teste devem ser minuciosamente inspecionados, comparando-se resultados previstos e obtidos. Os desenvolvedores no so as pessoas mais adequadas para testar seus prprios produtos. Assim como nas revises, os autores tm maior dificuldade em enxergar problemas, comparados com pessoas que no participaram do desenho e da implementao. O trabalho de testadores independentes particularmente importante no caso dos testes de aceitao. Possivelmente, os mesmos testadores independentes se encarregaro tambm dos testes de integrao. Testes de aceitao e integrao, sero vistos em seguida em uma maior profundidade. O planejamento e o desenho dos testes devem ser feitos por pessoas experientes, que conheam adequadamente a metodologia de testes usada. Por outro lado, a realizao dos testes baseados em planos e especificaes de testes bem definidos pode ser feita por pessoas

7

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.

2.4 BATERIAS DE TESTESA seguir esto descritos brevemente os tipos de baterias de testes, ou conjuntos de testes de software de determinada categoria, conforme proposto pela IEEE segundo Poston (1996). a) Testes de Unidade, que geralmente so de caixa branca, tm por objetivo verificar um elemento que possa ser localmente tratado como uma unidade de implementao; por exemplo, uma sub-rotina ou um mdulo. Em produtos implementados com tecnologia orientada a objetos, uma unidade tipicamente uma classe. Em alguns casos, pode ser conveniente tratar como unidade um grupo de classes correlatas; b) Testes de Integrao tm por objetivo verificar as interfaces entre as partes de uma arquitetura de produto. Esses testes tm por objetivo verificar se as unidades que compem cada liberao funcionam corretamente, em conjunto com as unidades j integradas, implementando corretamente os casos de uso cobertos por essa liberao executvel;

8

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.

2.5 ATIVIDADES DE TESTE DE SOFTWAREO processo de testes tem dois grandes grupos de atividades para cada bateria de testes: preparao e realizao dos testes. Durante a preparao, elaborado o plano da bateria e so desenhadas as especificaes de cada teste. Durante a realizao, os testes so executados, os defeitos encontrados so, se possvel, corrigidos, e os relatrios de teste so redigidos. Normalmente, a preparao se inicia pelos testes de mais alto nvel, ou seja, os testes de aceitao, baseados principalmente na Especificao de Requisitos do Software. Desses testes e do desenho das liberaes, elaborado no fluxo de desenho e contido na descrio do desenho do software, so derivados os testes de integrao. O desenho detalhado das unidades, realizado durante cada liberao, serve de base para o desenho dos testes de unidade (Ramirez, 1999). O Quadro 1 mostra as entradas necessrias para cada tipo de teste e seu respectivo desenho.

9

Quadro 1- ENTRADAS PARA O DESENHO DE TESTESENTRADAS

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 aceitaoFonte: Ramirez (1990).

2.5.1 PLANEJAMENTO DOS TESTESO planejamento dos testes de produtos no triviais complexo, envolvendo muitos aspectos tcnicos e gerenciais. Para facilitar a descrio, a atividade de planejamento foi dividida em trs tarefas separadas, o plano de testes, o planejamento inicial e identificao dos itens a testar. A seguir temos uma descrio mais detalhada destas trs tarefas.

2.5.1.1

PLANOS DE TESTESEle 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 planoObjetivos, 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 INICIALO 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.

Fonte: Ramirez (1990).

2.5.1.3

IDENTIFICAO DOS ITENS A TESTARA terceira tarefa do planejamento dos testes, compreende a identificao dos itens

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.

2.5.2 DESENHO DE TESTESNesse atividade, conforme o Quadro 4, feito o desenho da bateria de testes, estes desenhos vm a ser a especificao completa desta atividade, ou seja, como e de que maneira cada parte integrante do software testado deve ser submetido ao teste. Esta especificao deve conter todas informaes necessrias para as entradas suas respectivas sadas e a maneira com que o software deve se comportar ao ser submetido ao referido teste. So completadas as especificaes dos testes da bateria, desenhando-se os procedimentos e casos de teste. Em seguida so selecionados para reutilizao artefatos de teste de outros projetos que possam ser reaproveitados, enfim, definida a ordem de execuo dos casos de teste. (Ramirez, 1999) Em certos casos, principalmente nos testes de unidade, pode ser necessrio solicitar o redesenho de mdulos, para melhorar a testabilidade destes. Ainda seguindo a idia do autor, pode-se ver no Quadro 4 a seguir o que deve conter um desenho de bateria de testes: Quadro 4 - DESENHO DA BATERIA DE TESTES Descrio Desenho da Bateria de testes Especificao dos requisitos do software (testes de aceitao). Descrio do desenho do software desenho arquitetnico e plano das liberaes dos executveis(teste de integrao).Descrio do desenho do software desenho detalhado da unidade (testes de unidade).

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

ESPECIFICAES DOS TESTESAs especificaes de testes contm os detalhes dos testes a serem realizados. A

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

DESENHO DE PROCEDIMENTOS DE TESTEOs procedimentos de teste devem descrever a seqncia de passos necessria para

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

DESENHO DE CASO DE TESTECada teste consta da execuo de um ou mais procedimentos de teste, que so

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

REVISO DO DESENHO DE TESTEUm bom desenho de testes gera grande quantidade de informao. Para cada caso

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.

2.5.3 IMPLEMENTAO DOS TESTESNessa atividade, descrita no Quadro 6, realizada a implementao dos testes. O ambiente de teste completamente preparado, tornando-se disponveis todos os recursos necessrios.

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.

Fonte: Ramirez (1990).

2.5.4 EXECUO DOS TESTESEssa atividade, executa os testes da bateria, produzindo os relatrios correspondentes. Podem resultar, dos problemas encontrados neste passo, solicitaes de correo dos itens sob teste, assim como alteraes nos planos e especificaes dos prprios testes (Ramirez, 1999).

2.5.5 VERIFICAO DO TRMINO DOS TESTESSegundo Ramirez (1999), essa atividade, determina se esto satisfeitas as condies para completeza e sucesso dos testes. Caso necessrio para garantir a cobertura desejada, testes suplementares podem ser desenhados, retornando-se ao passo de execuo.

2.5.6 BALANO FINALEssa atividade, realiza o balano final dos testes da bateria. So registradas as lies aprendidas, completando-se o relatrio de resumo dos testes. Se possvel, so identificados artefatos reutilizveis em outros testes, inclusive procedimentos, casos e componentes de teste (Ramirez, 1999).

16

2.6 TCNICAS DE TESTE DE SOFTWARENesta parte so descritas tcnicas especficas de cada bateria de testes. Os testes de integrao so classificados de acordo com a abordagem escolhida para a integrao. J testes de aceitao so divididos em testes funcionais e no funcionais. E em seguida, so tratados os testes de regresso. O tratamento dos testes de unidade deixado para o fluxo de implementao. Esses testes geralmente so desenhados e realizados pelos prprios desenvolvedores, e no por uma equipe independente de testes, por este motivo no ser visto neste texto.

2.6.1 TESTES DE INTEGRAOO teste de integrao sistematiza a atividade de integrao dos mdulos j submetidos ao teste de unidade, ao mesmo tempo em que as interfaces entre esses mdulos so testadas. Estes testes diferem-se conforme a ordem em que so montadas as configuraes de integrao, ou construes, tambm conhecidas como builds. Em alguns casos, testes constantes da bateria de aceitao podem ser usados como testes de integrao.

2.6.2 TESTES DE ACEITAOOs testes de aceitao so testes de alto nvel que devem ser realizados na fase inicial dos testes de software. Eles so divididos em dois itens principais, os testes funcionais e os testes no funcionais, estes dois itens sero vistos a seguir.

2.6.2.1

TESTES FUNCIONAISPara 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 FUNCIONAISOs 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 requisitosDesempenho

Tipos de testeNmero 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

Outros atributos de qualidade

Fonte: Ramirez (1990).

19

2.6.3 TESTES DE REGRESSOAs alteraes feitas durante a correo dos erros detectados podem introduzir problemas em segmentos do cdigo previamente testados. Os testes de regresso verificam novamente esses segmentos, para checar se eles continuam funcionando de maneira apropriada aps a alterao de outras partes da aplicao. Testes de regresso so particularmente importantes durante a manuteno, pois nesta fase mais freqente que as alteraes realizadas afetem outras pores do cdigo. So usados tambm durante a integrao, para confirmar a estabilidade dos mdulos j integrados anteriormente. Essa tcnica inclui a definio de uma bateria de testes de regresso, ou seja, um conjunto selecionado de testes de boa cobertura, que executado periodicamente. Essa bateria geralmente baseada nos testes de aceitao. Caso essa bateria seja muito grande, pode-se utilizar uma bateria menor com testes selecionados, para uso mais freqente, testando-se a bateria completa em intervalos maiores. (Ramirez, 1999) Os seguintes aspectos tambm devem ser verificados durante os testes de regresso: a) se a documentao do sistema est consistente com o comportamento atual do sistema (por exemplo, se os documentos relevantes foram atualizados aps as alteraes realizadas); b) se os dados e as condies de teste continuam vlidos (por exemplo, mudanas em uma interface podem requerer alterao de procedimentos e casos de teste).

2.7 CASOS DE TESTECasos de teste so um conjunto especfico de dados de teste juntamente com os resultados esperados seguindo um determinado objetivo, que pode ser a avaliao de um recurso de programa ou a verificao do atendimento de uma necessidade especfica (Hetzel, 1987). O mesmo ainda cita que, cada teste constante de uma bateria procura verificar uma caracterstica dos itens sob teste. Tratando-se de uma bateria de testes de aceitao, cada teste geralmente verificar a implementao de um caso de uso do produto.

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).

2.7.1 IDENTIFICAO DE CASOS DE TESTEAinda seguindo a idia do autor, as tcnicas e metodologias de teste de software vistas at agora neste trabalho, objetivam a criao de casos de teste que nos permitem e identificar possveis "bugs" dos sistemas testados. Neste contexto casos de teste so descritos por dois elementos, um conjunto de aes ou valores de entrada e um conjunto de aes ou resultados esperados.

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).

2.7.2 MODELO PARA CRIAO DE UM CASO DE TESTEA partir das caractersticas de um "teste" possvel definir diferentes modelos para sua descrio. Visando uniformizar o trabalho proposto um modelo de referncia a ser seguido em todos os casos de teste. Este modelo tem seus itens proposto por Oliveira (1997) e pode ser visto no Quadro 9 adaptado para o Radar como forma de exemplificao.

22

Quadro 9 EXEMPLO DE UM MODELO DE CASO DE TESTEProduto: Radar Contbil Numero do teste: 01 Dependncias: Objetivo: verificar se o sistema grava corretamente o Plano de Contas Contbil. Ambiente: Hardware: micro PC compatvel com pelo menos 25Mb livres em HD Software: Passos: 1. executar o Radar Contbil 2. Selecionar a Empresa WKDemo 3. observar o resultado esperado 2 4. selecionar o menu, Cadastro/Plano Empresarial/Contbil 5. observar o resultado esperado 4 6. selecionar o menu Editar/Incluir 7. Preencher o campo Classificao conforme a primeira linha do relatrio de Plano de Contas a ser includo. 8.Preencher o campo Descrio conforme a primeira linha do relatrio de Plano de Contas a ser includo. 9. Selecionar o(s) CheckBox referentes caracterstica da conta conforme a primeira linha do relatrio de Plano de Contas a ser includo. 10. Pressiona o Boto OK 11. Observar os resultados esperados 7, 8 e 9 Resultados esperados: 1. O Plano de Contas deve ter sido gravado exatamente como foi digitado. win95 ou superior Radar Contbil instalado no diretrio c:\wkradar\

Fonte: Oliveira (1997).

2.8 NORMA BRASILEIRA ABNT NBR 12207Conforme a ABNT (1998), software uma parte fundamental da tecnologia de informao e de sistemas convencionais, tais como sistemas de transporte, militares, da rea mdica e financeiros. Tem havido uma proliferao de normas, procedimentos, mtodos, ferramentas e ambientes de desenvolvimento e de gerncia de software. Esta proliferao tem criado dificuldades na gerncia e engenharia de software, principalmente na integrao de produtos e servios. A disciplina de software necessita migrar desta proliferao para uma estrutura comum que possa ser usada por profissionais de software para criar um padro na criao e gerncia de software. Esta Norma prov tal estrutura comum. A estrutura cobre o ciclo de vida de software desde a concepo de idias at a descontinuao do software, e consiste dos processos de aquisio e fornecimento de produtos e servios de software. Adicionalmente, a estrutura prov o controle e a melhoria destes processos.

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.

2.8.1 PROCESSO DE DESENVOLVIMENTOO processo de desenvolvimento contm as atividades e tarefas do desenvolvedor. O processo contm as atividades para anlise de requisitos, projeto, codificao, integrao, testes, e instalao e aceitao relacionada aos produtos de software. Pode conter atividades relacionadas ao sistema, se estipulado no contrato. O desenvolvedor executa ou apoia as atividades neste processo, de acordo com o contrato. Este processo consiste em diversas atividade, dentre as quais pode-se destacar trs que so pertinentes atividade de teste de software: a) codificao e testes do software; b) integrao do software; c) teste de qualificao do software. A codificao e testes do software uma atividade que 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:

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 OPERAOO 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

PROCESSOS DE APOIO DE CICLO DE VIDAEste captulo da norma, define os seguintes de apoio de ciclo de vida. As

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.

2.9 A FERRAMENTA RATIONAL VISUAL TEST 6.5O Rational Visual Test, uma ferramenta de automatizao de testes onde o programador de testes dispe de diversos recursos ferramentas que o permitem criar os mais diversos tipos de caso de teste possvel. Este captulo mostrar quais so essas ferramentas, para que servem e os principais recursos do Visual Test, bem como consideraes sobre automao dos testes de software e outras ilustraes rpidas sobre a ferramenta Visual Test.

28

2.9.1 AUTOMAO DO TESTE DE SOFTWAREDurante os ltimos anos, testar software se tornou uma tarefa complexa. A linha de sistemas operacionais Windows necessita de uma programao complexa, fazendo com que os sistemas se tornem mais vulnerveis a Bugs. Para que se possa encontrar rapidamente e com eficcia esses Bugs e para que se possa abordar os possveis problemas de desempenho do sistema, preciso, em um mercado de desenvolvimento de software competitivo como os de hoje, automatizar o processo de teste de software. Para isso, disponibiliza-se ferramentas adequadas este tipo de atividade (Arnold, 1999). Porm, nenhuma ferramenta de automatizao do processo de teste de software perfeita, automatizao leva tempo, esforo e compromisso ali envolvido, inclusive uma compreenso sobre o que realmente uma automatizao pode e no pode fazer. Geralmente acredita-se que automatizao de teste significa substituir o papel humano de teste. Testes automatizados so uma ajuda na execuo dos testes somente, porm eles no substituem o testador humano, que tem que cri-los, e conferi-los para verificar se funcionam satisfatoriamente, e pensar em outros itens que precisam ser testados para assegurar a qualidade do software. A automatizao um ponto forte na re-execuo com rapidez dos testes inmeras vezes da mesma forma. Desta maneira, os Bugs so encontrados mais cedo permitindo que o software seja produzido com mais qualidade. Testar, pode levar 80% do tempo da produo do software. Enfim, automatizao de testes, emula aes de um usurio, digitao, entrada de dados, cliques em botes etc. Automatizar, gera velocidade e agilidade essas tarefas tediosas e repetitivas e tambm assegura que essas tarefas seja repetidas inmeras vezes na mesma ordem dando mais qualidade e consistncia ao teste. Destaca-se algumas razes chaves de porque deve-se automatizar os testes de software e utilizar uma boa ferramenta para esta atividade. Segundo Arnold (1999), a realizao de testes de regresso; fcil repetio da reproduo dos passos de um teste; testes de compatibilidade e reuso de scripts em diversos teste, plataformas e casos diferentes.

29

2.9.2 INTERFACE DO VISUAL TESTEspecificamente o Visual Test da Rational, oferece benefcios considerveis sobre esses assuntos mencionados anteriormente. O Visual Test est inserido em uma plataforma semelhante do Developer Studio Visual C++, que no s usado pelo Visual Test como tambm o editor principal do Microsoft Visual Studio, um agrupamento das ferramentas de desenvolvimento da Microsoft. Devido a este fato, ele se adapta melhor a programas desenvolvido em Visual C++. A interface do Visual Test, que pode ser vista na Figura 1 que est divida em trs parte principais: Workspace, Output, Source File. A primeira, Worspace ou rea de Trabalho, mostra uma representao clara da hierarquia de arquivos do projeto. Isso faz com que seja mais fcil organizar os arquivos relacionados a um determinado projeto de teste. Output a parte onde so mostradas as informaes sobre erros encontrados durante a compilao e/ou execuo de uma caso de teste. Por fim, a parte onde se trata do Source File, corresponde janela utilizada para a digitao do cdigo fonte propriamente dito, os scripts. Figura 1 INTERFACE DO VISUAL TEST

30

2.9.3 LINGUAGEM DO VISUAL TESTA linguagem utilizada pelo Visual Test uma verso robusta do Basic e oferece bastante flexibilidade para escrever scripts complexos que satisfaam as necessidades de teste. Porm, pode-se destacar alguns comandos essenciais e indispensveis para a implementao de testes: a) WEditSetText comando utilizado para inserir um dado qualquer em um campo editvel do tipo Edit. Tem como sua sintaxe, WeditSetText(#ID, Dado) onde o ID o nmero de identificao do campo e o Dado, o dado propriamente dito a ser inserido no campo; b) WComboItemClk comando utilizado para um item qualquer em um combo box. Tem como sua sintaxe, WComboItemClk(#ID, Item) onde o ID o nmero de identificao do combo box e o Item, o item propriamente dito a ser selecionado no combo; c) WCheckCheck comando utilizado para marcar um check box. Tem como sintaxe, WcheckCheck(#ID) onde o ID o nmero de indentificao do check box. Temos tambm o WcheckUnCheck para desmarcar um check box utilizando a mesma sintaxe do anterior; d) WoptionSelect comando utilizado para selecionar uma opo nica em um radio button. Tem como sintaxe WoptionSelect(#ID), onde o ID o nmero de identificao do campo; e) WbuttonClick comando utilizado para clicar em um boto qualquer, tem como sintaxe, WbuttonClick(nome_boto ou #ID) onde o nome_boto o nome do boto propriamente dito ou ainda pode-se utilizar o ID, que o nmero de identificao do mesmo; f) WMenuSelect - comando utilizado para acessar menus, tem como sintaxe, WmenuSelect (caminho_do_menu) onde o caminho_do_menu representa exatamente os nomes dos menus a serem acessados. Ex:. WMenuSelect (&Arquivo/Sa&ir), onde o & representa o atalho para o mesmo. g) Sleep comando utilizado para parar a execuo do teste por um tempo determinado, tem-se a seguinte sintaxe, Sleep X, onde X representa em segundos o tempo em que a execuo ficar parada, o parmetro de tempo

31

pode ser utilizado em forma de constante ou ento diretamente o nmero em segundos representado o tempo desejado.

2.9.4 UTILITRIOS DO VISUAL TESTA ferramenta Visual Test conta com o apoio de alguns utilitrios que facilitam a implementao dos Scripts. Os trs principais utilitrios so: a) gravador de cenrio(Scenario Record) quando ativado, este utilitrio, trabalha como um gravador de todas as aes do usurio a partir daquele momento. Ele localiza todas as aes e as transforma em linguagem de teste para o prprio Visual Test. Uma vez terminada esta gravao, o script j est gerado e pode ser executado, e todas as aes executadas anteriormente pelo usurio e gravadas, sero repetidas pela execuo do script no Visual Test. b) utilitrio de informaes de janela (Window Information Utility). Este, por sua vez, traz informaes detalhadas de uma determinada janela. Aps sua execuo, aberta uma janela onde, atravs de um cursor, possvel identificar nomes de campos das janelas do sistema testado, bem como seus IDs (nmeros de identificao gerados para cada campo do sistema), a que mdulo pertence, entre outras informaes. c) Suite Manager, este funciona como um gerenciador de execuo dos diversos casos de teste gerados em um projeto. Atravs de seu uso, possvel executar em uma seqncia qualquer desejada pelo programador de teste, os seus diversos arquivos de caso de teste, sem que os mesmos sejam executados um por um separadamente.

2.9.5 EXECUO DOS SCRIPTSComo j foi visto anteriormente, os scripts de teste so executados no prprio Visual Test, mas isso no quer dizer que necessariamente precisa-se desta ferramenta para executar um determinado caso de teste. O Visual Test conta com um recurso de criao de executveis dos Scripts que podem ser executados independentemente de se ter ou no o Visual Test instalado na mquina. Isto faz com que os testes criados para um computador possam ser carregados para outras mquinas e executados nelas, aumentando assim a rea de cobertura dos testes no

32

que diz respeito ao comportamento do software testado em diversas configuraes de mquinas e sistemas operacionais possveis.

33

3. DESENVOLVIMENTOPara 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

Figura 2 ETAPA DE DESENVOLVIMENTO DE SOFTWARE

Incio

Relatrio de le va nta m ento

Im pleme nta o do S oftware

C omp ila o e gera o d os pro gram as

TE S TE S

Implem enta o d os Sc ripts c on form e re l. d e lev an tam e nto

Exe cu o do s tes tes a uto m atiz ado s (Sc ripts )

Ve rifica o do s res ultad os da exe cu o dos testes . R elatrio gera do apon ta erro s?

SG era o de ord em d e s erv io p ara repa ro n o s ist ema

NLibe 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 ESPECIFICAOApresenta-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

Figura 3 DIAGRAMA USE-CASE DO PROTTIPO

Program dor de T es te

C ons tr uir Scri pt

Exe cutar Script

Gerente de Produto

Gerar R elatrio de Erros

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

Figura 4 MODELO DE RELATRIO DE RESULTADOS DOS TESTES

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 IMPLEMENTAOConforme 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 ACEITAOScenario "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 ItemIdentificar o plano de testes Introduo Itens a testar

DescrioTeste 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

Figura 5 ESTRUTURAO LGICA DOS SCRIPTS DE TESTE

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

Quadro 12 RESTAURAO E BACKUP DA BASE DE DADOSScenario "Restaura Dados" if carinha = 1 or carinha = 3 then run "deltree /y c:\wkradar\dados\TESTE" run "xcopy d:\TCC\BKP\MENSG\*.* c:\wkradar\dados\TESTE /s /i" end if End Scenario

Scenario "BKP dos Dados" if carinha = 2 or carinha = 3 then run "deltree /y d:\TCC\BKP\ECFS" run "xcopy c:\wkradar\dados\TESTE\*.