Você está na página 1de 20

1

Teste de Software
Introduo Teste de software o processo de execuo de um produto para determinar se ele atingiu suas especificaes e funcionou corretamente no ambiente para o qual foi projetado. O seu objetivo revelar falhas em um produto, para que as causas dessas falhas sejam identificadas e possam ser corrigidas pela equipe de desenvolvimento antes da entrega final. Por conta dessa caracterstica das atividades de teste, dizemos que sua natureza destrutiva, e no construtiva, pois visa ao aumento da confiana de um produto atravs da exposio de seus problemas, porm antes de sua entrega ao usurio final. O conceito de teste de software pode ser compreendido atravs de uma viso intuitiva ou mesmo de uma maneira formal. Existem atualmente vrias definies para esse conceito. De uma forma simples, testar um software significa verificar atravs de uma execuo controlada se o seu comportamento corre de acordo com o especificado. O objetivo principal desta tarefa revelar o nmero mximo de falhas dispondo do mnimo de esforo, ou seja, mostrar aos que desenvolvem se os resultados esto ou no de acordo com os padres estabelecidos. Ao longo deste trabalho, iremos discutir os principais conceitos relacionados s atividades de teste, as principais tcnicas e critrios de teste que podem ser utilizados para verificao ou validao de um produto, assim como exemplos prticos da aplicao de cada tipo de tcnica ou critrio de teste. Viso geral No se pode garantir que todo software funcione corretamente, sem a presena de erros, visto que os mesmos muitas vezes possuem um grande nmero de estados com frmulas, atividades e algoritmos. O tamanho do projeto a ser desenvolvido e a quantidade de pessoas envolvidas no processo aumentam ainda mais a complexidade. Idealmente, toda permutao possvel do software deveria ser testada. Entretanto, isso se torna impossvel para a ampla maioria dos casos devido quantidade impraticvel de possibilidades. A

2 qualidade do teste acaba se relacionando qualidade dos profissionais envolvidos em filtrar as permutaes relevantes. Falhas podem ser originadas por diversos motivos. Por exemplo, a especificao pode estar errada ou incompleta, ou pode conter requisitos impossveis de serem implementados, devido limitaes de hardware ou software. A implementao tambm pode estar errada ou incompleta, como um erro de um algortimo. Portanto, uma falha o resultado de um ou mais defeitos em algum aspecto do sistema. O teste de software pode ser visto como uma parcela do processo de qualidade de software. A qualidade da aplicao pode, normalmente, variar significativamente de sistema para sistema. Os atributos qualitativos previstos na norma ISO 9126 so funcionalidade, confiabilidade, usabilidade, eficincia, manutenibilidade e portabilidade. De forma geral, mensurar o bom

funcionamento de um software envolve compar-lo com elementos como especificaes, outros softwares da mesma linha, verses anteriores do mesmo produto, inferncias pessoais, expectativas do cliente, normas relevantes, leis aplicveis, entre outros. Enquanto a especificao do software diz respeito ao processo de verificao do software, a expectativa do cliente diz respeito ao processo de validao do software. Um desenvolvimento de software organizado tem como premissa metodologia de trabalho. Esta deve ter como base conceitos que visem a construo de um produto de software de forma eficaz. Dentro desta metodologia esto definidos os passos necessrios para chegar ao produto final esperado. Assim, quando se segue uma metodologia para o desenvolvimento de um produto de software, espera-se um produto final que melhor agrade tanto aos clientes quanto ao prprio fornecedor, ou seja, a empresa de desenvolvimento. Observando este aspecto, no faz sentido iniciar a construo de um produto de software sem ter uma metodologia de trabalho bem solidificada e que seja do conhecimento de todos os envolvidos no processo. Porm, alm de uma crescente demanda por softwares de qualidade, as empresas de desenvolvimento de software sofrem cada vez mais presso por parte dos clientes para que o produto seja entregue num curto

3 perodo de tempo. Este fato pode fazer com que uma slida metodologia de trabalho acabe por se desequilibrar. Independentemente da metodologia de trabalho empregada no

desenvolvimento de um software, para que se obtenha um produto final com um certo nvel de qualidade imprescindvel a melhoria dos processos de engenharia de software. Uma maneira vivel para se assegurar a melhoria de tais processos seria tomar como base modelos sugeridos por entidades internacionais respeitadas no assunto. Dentro de uma gama de modelos, sejam eles para situaes e ambientes especficos ou para solues genricas, existem alguns que so mais utilizados e tidos como eficientes, como por exemplo os SWCMM, SE-CMM, ISO 15504 e o mais conhecido CMMI. Outro fator com grande influncia sobre a qualidade do software a ser produzido o que diz respeito aos testes que sero executados sobre tal produto. Todas as metodologias de desenvolvimento de software tm uma disciplina dedicada aos testes. Atualmente esta uma tarefa indispensvel, porm muitas vezes efetuada de maneira ineficiente, seja pelo subestimar dos que desenvolvem, pela falta de tempo ou mesmo pela falta de recursos humanos e financeiros. Princpios Para Myers (2004), h princpios vitais para o teste de software. O caso de teste deve definir a sada esperada, de forma a reduzir a interpretao do critrio de sucesso. A sada da execuo do teste deve ser exaustivamente analisada. Os casos de teste devem verificar no somente as condies invlidas de execuo, como tambm as condies vlidas. Outro conceito apresentado utilizar pessoas e organizaes diferentes para a

implementao e para a verificao. A entidade de teste possui uma viso destrutiva do sistema, em busca de erros, enquanto a entidade de programao possui uma viso construtiva, em busca da implementao de uma especificao. Mayer tambm aborda o esforo para se construir casos de teste. Devese evitar testes descartveis, pois a qualidade do teste piora gradualmente com as iteraes de desenvolvimento. Em contrapartida, h o teste de regresso,

4 que permite quantificar a evoluo da qualidade de software, mantendo e executando novamente testes realizados anteriormente. O mesmo autor afirma que, diferente do que se poderia considerar senso comum, a probabilidade de existncia de erros num certo trecho de cdigo proporcional quantidade de erros j encontradas anteriormente. Basicamente, erros aparecem em grupos. Trechos especficos de cdigo de um software qualquer esto mais propensos a ter erros que outros.

Conceitos bsicos associados a Teste de Software O teste do software a investigao do software a fim de fornecer informaes sobre sua qualidade em relao ao contexto em que ele deve operar. Isso inclui o processo de utilizar o produto para encontrar seus defeitos. O teste um processo realizado pelo testador de software, que permeia outros processos da engenharia de software, e que envolve aes que vo do levantamento de requisitos at a execuo do teste propriamente dito. Antes de iniciarmos uma discusso sobre teste de software precisamos esclarecer alguns conceitos relacionados a essa atividade. Inicialmente, precisamos conhecer a diferena entre Defeitos, Erros e Falhas. As definies que iremos usar aqui seguem a terminologia padro para Engenharia de Software do IEEE Institute of Electrical and Electronics Engineers (IEEE 610, 1990). Defeito um ato inconsistente cometido por um indivduo ao tentar entender uma determinada informao, resolver um problema ou utilizar um mtodo ou uma ferramenta. Por exemplo, uma instruo ou comando incorreto. Erro uma manifestao concreta de um defeito num artefato de software. Diferena entre o valor obtido e o valor esperado, ou seja, qualquer estado intermedirio incorreto ou resultado inesperado na execuo de um programa constitui um erro. Falha o comportamento operacional do software diferente do esperado pelo usurio. Uma falha pode ter sido causada por diversos erros e alguns erros podem nunca causar uma falha.

5 A Figura 1 expressa a diferena entre esses conceitos. Defeitos fazem parte do universo fsico (a aplicao propriamente dita) e so causados por pessoas, por exemplo, atravs do mal uso de uma tecnologia. Defeitos podem ocasionar a manifestao de erros em um produto, ou seja, a construo de um software de forma diferente ao que foi especificado (universo de informao). Por fim, os erros geram falhas, que so comportamentos inesperados em um software que afetam diretamente o usurio final da aplicao (universo do usurio) e pode inviabilizar a utilizao de um software.

Figura 1. Defeito x erro x falha

Dessa forma, ressaltamos que teste de software revela simplesmente falhas em um produto. Aps a execuo dos testes necessria a execuo de um processo de depurao para a identificao e correo dos defeitos que originaram essa falha, ou seja, Depurar no Testar! A atividade de teste composta por alguns elementos essenciais que auxiliam na formalizao desta atividade. Esses elementos so os seguintes: Caso de Teste: descreve uma condio particular a ser testada e composto por valores de entrada, restries para a sua execuo e um resultado ou comportamento esperado (CRAIG e JASKIEL, 2002).

6 Procedimento de Teste: uma descrio dos passos necessrios para executar um caso (ou um grupo de casos) de teste (CRAIG e JASKIEL, 2002). Critrio de Teste: serve para selecionar e avaliar casos de teste de forma a aumentar as possibilidades de provocar falhas ou, quando isso no ocorre, estabelecer um nvel elevado de confiana na correo do produto (ROCHA et al., 2001). Os critrios de teste podem ser utilizados como: Critrio de Cobertura dos Testes: permitem a identificao de partes do programa que devem ser executadas para garantir a qualidade do software e indicar quando o mesmo foi suficientemente testado (RAPPS e WEYUKER, 1982). Ou seja, determinar o percentual de elementos necessrios por um critrio de teste que foram executados pelo conjunto de casos de teste. Critrio de Adequao de Casos de Teste: Quando, a partir de um conjunto de casos de teste T qualquer, ele utilizado para verificar se T satisfaz os requisitos de teste estabelecidos pelo critrio. Ou seja, este critrio avalia se os casos de teste definidos so suficientes ou no para avaliao de um produto ou uma funo (ROCHA et al., 2001). Critrio de Gerao de Casos de Teste: quando o critrio utilizado para gerar um conjunto de casos de teste T adequado para um produto ou funo, ou seja, este critrio define as regras e diretrizes para gerao dos casos de teste de um produto que esteja de acordo com o critrio de adequao definido anteriormente (ROCHA et al., 2001). Definidos os elementos bsicos associados aos testes de software, iremos a seguir discutir a origem dos defeitos em um software.

7 Defeitos no desenvolvimento de software No processo de desenvolvimento de software, todos os defeitos so humanos e, apesar do uso dos melhores mtodos de desenvolvimento, ferramentas ou profissionais, permanecem presentes nos produtos, o que torna a atividade de teste fundamental durante o desenvolvimento de um software. J vimos que esta atividade corresponde ao ltimo recurso para avaliao do produto antes da sua entrega ao usurio final. O tamanho do projeto a ser desenvolvido e a quantidade de pessoas envolvidas no processo so dois possveis fatores que aumentam a complexidade dessa tarefa, e consequentemente aumentam a probabilidade de defeitos. Assim, a ocorrncia de falhas inevitvel. Mas o que significa dizer que um programa falhou? Basicamente significa que o funcionamento do programa no est de acordo com o esperado pelo usurio. Por exemplo, quando um usurio da linha de produo efetua consultas no sistema das quais s a gerncia deveria ter acesso. Esse tipo de falha pode ser originado por diversos motivos: A especificao pode estar errada ou incompleta; A especificao pode conter requisitos impossveis de serem implementados devido a limitaes de hardware ou software; A base de dados pode estar organizada de forma que no seja permitido distinguir os tipos de usurio; Pode ser que haja um defeito no algoritmo de controle dos usurios. Os defeitos normalmente so introduzidos na transformao de informaes entre as diferentes fases do ciclo de desenvolvimento de um software. Vamos seguir um exemplo simples de ciclo de vida de desenvolvimento de software: os requisitos expressos pelo cliente so relatados textualmente em um documento de especificao de requisitos. Esse documento ento transformado em casos de uso, que por sua vez foi o artefato de entrada para o projeto do software e definio de sua arquitetura utilizando diagramas de classes da UML. Em seguida, esses modelos de projetos foram usados para a construo do software em uma linguagem que

8 no segue o paradigma orientado a objetos. Observe que durante esse perodo uma srie de transformaes foi realizada at chegarmos ao produto final. Nesse meio tempo, defeitos podem ter sido inseridos. A Figura 2 expressa exatamente a metfora discutida nesse pargrafo.

Figura 2. Diferentes Interpretaes ao longo do ciclo de desenvolvimento de um software (Uma verso similar pode ser obtida em http://www.projectcartoon.com/cartoon/611)

Essa srie de transformaes resultou na necessidade de realizar testes em diferentes nveis, visando avaliar o software em diferentes perspectivas de acordo com o produto gerado em cada fase do ciclo de vida de desenvolvimento de um software. Esse ser o foco da seo seguinte.

Nveis de teste de software O planejamento dos testes deve ocorrer em diferentes nveis e em paralelo ao desenvolvimento do software (Figura 3). Buscando informao no Livro Qualidade de Software Teoria e Prtica (ROCHA et al., 2001), definimos que os principais nveis de teste de software so: Teste de Unidade: tambm conhecido como testes unitrios. Tem por objetivo explorar a menor unidade do projeto, procurando provocar falhas ocasionadas por defeitos de lgica e de implementao em cada

9 mdulo, separadamente. O universo alvo desse tipo de teste so os mtodos dos objetos ou mesmo pequenos trechos de cdigo. Teste de Integrao: visa provocar falhas associadas s interfaces entre os mdulos quando esses so integrados para construir a estrutura do software que foi estabelecida na fase de projeto. Teste de Sistema: avalia o software em busca de falhas por meio da utilizao do mesmo, como se fosse um usurio final. Dessa maneira, os testes so executados nos mesmos ambientes, com as mesmas condies e com os mesmos dados de entrada que um usurio utilizaria no seu dia-a-dia de manipulao do software. Verifica se o produto satisfaz seus requisitos. Teste de Aceitao: so realizados geralmente por um restrito grupo de usurios finais do sistema. Esses simulam operaes de rotina do sistema de modo a verificar se seu comportamento est de acordo com o solicitado. Teste de Regresso: Teste de regresso no corresponde a um nvel de teste, mas uma estratgia importante para reduo de efeitos colaterais. Consiste em se aplicar, a cada nova verso do software ou a cada ciclo, todos os testes que j foram aplicados nas verses ou ciclos de teste anteriores do sistema. Pode ser aplicado em qualquer nvel de teste. Dessa forma, seguindo a Figura 3, o planejamento e projeto dos testes devem ocorrer de cima para baixo, ou seja: 1. Inicialmente planejado o teste de aceitao a partir do

documento de requisitos; 2. Aps isso planejado o teste de sistema a partir do projeto de alto

nvel do software; 3. Em seguida ocorre o planejamento dos testes de integrao a

partir o projeto detalhado; 4. E por fim, o planejamento dos testes a partir da codificao.

10

J a execuo ocorre no sentido inverso. Conhecidos os diferentes nveis de teste, a partir da prxima seo descreveremos as principais tcnicas de teste de software existentes que podemos aplicar nos diferentes nveis abordados.

Figura 3. Modelo V descrevendo o paralelismo entre as atividades de desenvolvimento e teste de software (CRAIG e JASKIEL, 2002)

Tcnicas de teste de software

Atualmente existem muitas maneiras de se testar um software. Mesmo assim, existem as tcnicas que sempre foram muito utilizadas em sistemas desenvolvidos sobre linguagens estruturadas que ainda hoje tem grande valia para os sistemas orientados a objeto. Apesar de os paradigmas de desenvolvimento ser diferentes, o objetivo principal destas tcnicas continua a ser o mesmo: encontrar falhas no software. As tcnicas de teste so classificadas de acordo com a origem das informaes utilizadas para estabelecer os requisitos de teste. Elas

11 contemplam diferentes perspectivas do software e impe-se a necessidade de se estabelecer uma estratgia de teste que contemple as vantagens e os aspectos complementares dessas tcnicas. As tcnicas existentes so: tcnica funcional e estrutural. A seguir conheceremos um pouco mais sobre cada tcnica, mas iremos enfatizar alguns critrios especficos para a tcnica funcional.

Tcnica Estrutural (ou teste caixa-branca) Tcnica de teste que avalia o comportamento interno do componente de software (Figura 4). Essa tcnica trabalha diretamente sobre o cdigo fonte do componente de software para avaliar aspectos tais como: teste de condio, teste de fluxo de dados, teste de ciclos e teste de caminhos lgicos (PRESSMAN, 2005)

Figura 4. Tcnica de Teste Estrutural.

Os aspectos avaliados nesta tcnica de teste dependero da complexidade e da tecnologia que determinarem a construo do componente de software, cabendo, portanto, avaliao de outros aspectos alm dos citados anteriormente. O testador tem acesso ao cdigo fonte da aplicao e pode construir cdigos para efetuar a ligao de bibliotecas e componentes. Este tipo de teste desenvolvido analisando-se o cdigo fonte e elaborando-se casos de teste que cubram todas as possibilidades do componente de software. Dessa maneira, todas as variaes originadas por estruturas de condies so testadas. A Listagem 1 apresenta um cdigo fonte, extrado de (BARBOSA et al., 2000) que descreve um programa de exemplo que deve

12 validar um identificador digitado como parmetro, e a Figura 5 apresenta o grafo de programa extrado a partir desse cdigo, tambm extrado de (BARBOSA et al., 2000). A partir do grafo deve ser escolhido algum critrio baseado em algum algoritmo de busca em grafo (exemplo: visitar todos os ns, arcos ou caminhos) para gerao dos casos de teste estruturais para o programa (PFLEEGER, 2004). Listagem 1. Cdigo fonte do programa identifier.c (BARBOSA et al., 2000) /* 01 */ { /* 01 */ /* 01 */ /* 01 */ /* 01 */ /* 01 */ /* 01 */ /* 01 */ /* 01 */ /* 02 */ /* 03 */ /* 04 */ /* 05 */ /* 05 */ /* 06 */ char achar; int length, valid_id; length = 0; printf ("Digite um possvel identificador\n"); printf ("seguido por <ENTER>: "); achar = fgetc (stdin); valid_id = valid_starter (achar); if (valid_id) length = 1; achar = fgetc (stdin); while (achar != '\n') { if (!(valid_follower (achar))) valid_id = 0;

13 /* 07 */ /* 07 */ /* 07 */ /* 08 */ /* 09 */ /* 10 */ /* 10 */ /* 11 */ } else printf ("Invalido\n"); } if (valid_id && (length >= 1) && (length < 6) ) printf ("Valido\n"); length++; achar = fgetc (stdin);

Figura 5. Grafo de Programa (Identifier.c) (BARBOSA et al., 2000).

Um exemplo bem prtico desta tcnica de teste o uso da ferramenta livre JUnit para desenvolvimento de casos de teste para avaliar classes ou mtodos desenvolvidos na linguagem Java. A tcnica de teste de Estrutural recomendada para os nveis de Teste da Unidade e Teste da Integrao, cuja responsabilidade principal fica a cargo dos desenvolvedores do software, que so profissionais que conhecem bem o cdigo-fonte desenvolvido e dessa forma conseguem planejar os casos de teste com maior facilidade. Dessa forma, podemos auxiliar na reduo dos problemas existentes nas pequenas funes ou unidades que compem um software.

14 Teste Funcional (ou teste caixa-preta) Tcnica de teste em que o componente de software a ser testado abordado como se fosse uma caixa-preta, ou seja, no se considera o comportamento interno do mesmo (Figura 6). Dados de entrada so fornecidos, o teste executado e o resultado obtido comparado a um resultado esperado previamente conhecido. Haver sucesso no teste se o resultado obtido for igual ao resultado esperado. O componente de software a ser testado pode ser um mtodo, uma funo interna, um programa, um componente, um conjunto de programas e/ou componentes ou mesmo uma funcionalidade. A tcnica de teste funcional aplicvel a todos os nveis de teste (PRESSMAN, 2005).

Figura 6. Tcnica de Teste Funcional.

Um conjunto de critrios de teste pode ser aplicado aos testes funcionais. A seguir conheceremos alguns deles. Particionamento em classes de equivalncia Esse critrio divide o domnio de entrada de um programa em classes de equivalncia, a partir das quais os casos de teste so derivados. Ele tem por objetivo minimizar o nmero de casos de teste, selecionando apenas um caso de teste de cada classe, pois em princpio todos os elementos de uma classe devem se comportar de maneira equivalente. Eventualmente, pode-se tambm considerar o domnio de sada para a definio das classes de equivalncia (ROCHA et al., 2001). Uma classe de equivalncia representa um conjunto de estados vlidos e invlidos para uma condio de entrada. Tipicamente uma condio de entrada pode ser um valor numrico especfico, uma faixa de valores, um

15 conjunto de valores relacionados, ou uma condio lgica. As seguintes diretrizes podem ser aplicadas: Se uma condio de entrada especifica uma faixa de valores ou requer um valor especfico, uma classe de equivalncia vlida (dentro do limite) e duas invlidas (acima e abaixo dos limites) so definidas. Se uma condio de entrada especifica um membro de um conjunto ou lgica, uma classe de equivalncia vlida e uma invlida so definidas. Devemos seguir tais passos para gerao dos testes usando este critrio: 1. Identificar classes de equivalncia ( um processo heurstico) o o 2. condio de entrada vlidas e invlidas

Definir os casos de teste o o o enumeram-se as classes de equivalncia casos de teste para as classes vlidas casos de teste para as classes invlidas

Em (BARBOSA et al., 2000) apresentado a aplicao do critrio de particionamento por equivalncia para o programa identifier.c. Iremos apresent-lo como exemplo do uso deste critrio de teste. Relembrando, o programa deve determinar se um identificador vlido ou no. Um identificador vlido deve comear com uma letra e conter apenas letras ou dgitos. Alm disso, deve ter no mnimo 1 caractere e no mximo 6 caracteres de comprimento. Exemplo: abc12 (vlido), cont*1 (invlido), 1soma (invlido) e a123456 (invlido).

16 O primeiro passo a identificao das classes de equivalncia. Isso est descrito na Tabela 1.
Tabela 1. Classes de Equivalncia do programa identifier.c.

Condies de Entrada Tamanho t do identificador Primeiro caractere c uma letra S contm caracteres vlidos

Classes (1) 1 ??t???6 (3) Sim (5) Sim

Classes (2) t > 6 (4) No (6) No

A partir disso, conseguimos especificar quais sero os casos de teste necessrios. Para ser vlido, um identificador deve atender s condies (1), (3) e (5), logo necessrio um caso de teste vlido que cubra todas essas condies. Alem disso, ser necessrio um caso de teste para cada classe invlida: (2), (4) e (6). Assim, o conjunto mnimo composto por quatro casos de teste, sendo uma das opes: T0 = {(a1,Vlido), (2B3, Invlido), (Z-12, Invlido), (A1b2C3d, Invlido)}. Anlise do valor limite Por razes no completamente identificadas, um grande nmero de erros tende a ocorrer nos limites do domnio de entrada invs de no centro. Esse critrio de teste explora os limites dos valores de cada classe de equivalncia para preparar os casos de teste (Pressman, 2005). Se uma condio de entrada especifica uma faixa de valores limitada em a e b, casos de teste devem ser projetados com valores a e b e imediatamente acima e abaixo de a e b. Exemplo: Intervalo = {1..10}; Casos de Teste {1, 10, 0,11}. Como exemplo, extrado de (BARBOSA et al., 2000), iremos considerar a seguinte situao: "... o clculo do desconto por dependente feito da seguinte forma: a entrada a idade do dependente que deve estar restrita ao intervalo [0..24]. Para dependentes at 12 anos (inclusive) o desconto de 15%. Entre 13 e 18 (inclusive) o desconto de 12%. Dos 19 aos 21 (inclusive) o desconto de 5% e dos 22 aos 24 de 3%..."

17 Aplicando o teste de valor limite convencional sero obtidos casos de teste semelhantes a este: {-1,0,12,13,18,19,21,22,24,25}. Grafo de causa-efeito

Esse critrio de teste verifica o efeito combinado de dados de entrada. As causas (condies de entrada) e os efeitos (aes) so identificados e combinados em um grafo a partir do qual montada uma tabela de deciso, e a partir desta, so derivados os casos de teste e as sadas (ROCHA et al., 2001). Esse critrio baseado em quatro passos, que exemplificaremos utilizando o exemplo, tambm extrado de (BARBOSA et al., 2000): Em um programa de compras pela Internet, a cobrana ou no do frete definida seguindo tal regra: Se o valor da compra for maior que R$ 60,00 e foram comprados menos que 3 produtos, o frete gratuito. Caso contrrio, o frete dever ser cobrado. 1. Para cada mdulo, Causas (condies de entrada) e efeitos

(aes realizadas s diferentes condies de entrada) so relacionados, atribuindo-se um identificador para cada um. Causa: valor da compra > 60 e #produtos < 3 Efeito: frete grtis 2. Em seguida, um grafo de causa-efeito (rvore de deciso)

desenhado (Figura 7).

Figura 7. rvore de Deciso Grafo de Causa-Efeito.

18 1. Neste ponto, transforma-se o grafo numa tabela de deciso (Tabela 2).

Tabela 2. Tabela de deciso para o programa de compra pela Internet.

Causa

Valor da compra > 60 > 60 <= 60 #Produtos Cobrar frete Frete grtis V <3 >= 3 -V V

Efeito

2. teste.

As regras da tabela de deciso so, ento, convertidas em casos de

Para a elaborao dos casos de teste, devemos seguir todas as regras extradas da tabela. Esse critrio deve ser combinado com os dois outros j apresentados neste artigo para a criao de casos de teste vlidos (extrados das regras) e invlidos (valores foras da faixa definida). Os casos de teste definidos a seguir refletem somente as regras extradas da tabela de deciso. Fica como exerccio pensar nos casos de teste invlidos para este problema. Casos de Teste (valor, qtd produtos, resultado esperado) = {(61,2,frete grtis); (61,3,cobrar frete); (60, qualquer quantidade,cobrar frete)} Outras tcnicas Outras tcnicas de teste podem e devem ser utilizadas de acordo com necessidades de negcio ou restries tecnolgicas. Destacam-se as seguintes tcnicas: teste de desempenho, teste de usabilidade, teste de carga, teste de stress, teste de confiabilidade , teste de recuperao, teste de regresso, teste de unidade, teste de integrao, teste de sistema, teste de aceitao, teste de operao, teste alfa e beta e outros.

Concluses O teste de software uma das atividades mais custosas do processo de desenvolvimento de software, pois pode envolver uma quantidade significativa

19 dos recursos de um projeto. O rigor e o custo associado a esta atividade dependem principalmente da criticalidade da aplicao a ser desenvolvida. Diferentes categorias de aplicaes requerem uma preocupao diferenciada com as atividades de teste. Um ponto bastante importante para a viabilizao da aplicao de teste de software a utilizao de uma infra-estrutura adequada. Realizar testes no consiste simplesmente na gerao e execuo de casos de teste, mas envolvem tambm questes de planejamento, gerenciamento e anlise de resultados. Apoio ferramental para qualquer atividade do processo de teste importante como mecanismo para reduo de esforo associado tarefa em questo, seja ela planejamento, projeto ou execuo dos testes. Aps ter sua estratgia de teste definida, tente buscar por ferramentas que se encaixem na sua estratgia. Isso pode reduzir significantemente o esforo de tal tarefa. Alm disso, importante ressaltar que diferentes tipos de aplicaes possuem diferentes tcnicas de teste a serem aplicadas, ou seja, testar uma aplicao web envolve passos diferenciados em comparao aos testes de um sistema embarcado. Cada tipo de aplicao possui caractersticas especificas que devem ser consideradas no momento da realizao dos testes. O conjunto de tcnicas apresentado neste artigo cobre diversas caractersticas comuns a muitas categorias de software, mas no completo.

Referncias BARBOSA, E.; MALDONADO, J.C.; VINCENZI, A.M.R.; DELAMARO, M.E; SOUZA, S.R.S. e JINO, M.. Introduo ao Teste de Software. XIV Simpsio Brasileiro de Engenharia de Software, 2000. CRAIG, R.D., JASKIEL, S. P., Systematic Software Testing, Artech House Publishers, Boston, 2002. IEEE Standard 610-1990: IEEE Standard Glossary of Software Engineering Terminology, IEEE Press.

20 PFLEEGER, S. L., Engenharia de Software: Teoria e Prtica, Prentice HallCap. 08, 2004. PRESSMAN, R. S., Software Engineering: A Practitioners Approach, McGraw-Hill, 6th ed, Nova York, NY, 2005. RAPPS, S., WEYUKER, E.J., Data Flow analysis techniques for test data selection, In: International Conference on Software Engineering, p. 272-278, Tokio, Sep. 1982. ROCHA, A. R. C., MALDONADO, J. C., WEBER, K. C. et al., Qualidade de software Teoria e prtica, Prentice Hall, So Paulo, 2001.