Centro de Tecnologia da Informao Renato Archer CTI/MCT

Centro de Tecnologia da Informao Renato Archer, CTI

Ministrio da Cincia e Tecnologia, MCT

Teste de Software: Motivao e Conceitos Bsicos

Autores: Adalberto Nobiato Crespo: Adalberto.crespo@cti.gov.br Mario Jino: Jino@dca.fee.unicamp.br Miguel Argollo: Miguel.argollo@cti.gov.br Paulo Bueno: Paulo.bueno@cti.gov.br Celso Penteado de Barros: Celso.barros@cti.gov

Outubro/2009
Teste de Software: Motivao e Conceitos Bsicos

Pgina 1

Centro de Tecnologia da Informao Renato Archer CTI/MCT

Teste de Software: Motivao e Conceitos Bsicos Apresentao Este documento apresenta uma introduo ao teste de software, um conjunto de atividades de extrema importncia para a obteno de produtos de software de qualidade. Como um texto inicial, buscou-se apresentar os conceitos fundamentais de teste de uma forma simples e breve. So descritos, dentre outros conceitos de teste: o objetivo; os procedimentos; o processo; os tipos; os nveis e as tcnicas aplicadas atividade de teste. O objetivo apontar prticas aceitas como eficazes por profissionais da rea e tambm padres recentes de teste de software, definidos por rgos como ISO/IEC e IEEE. importante notar que a adoo de qualquer tecnologia de teste por parte das organizaes ou profissionais envolvidos com o SPB deve ser calcada em uma anlise cuidadosa das reais necessidades de teste, tendo em vista o objetivo da organizao ou do profissional e a natureza do software produzido. Diferentes usurios podem se interessar prioritariamente por partes distintas deste documento. Embora a leitura integral seja recomendada, podem-se identificar duas reas de interesse: aspectos mais tcnicos do teste e aspectos mais voltados poltica e ao gerenciamento do teste. As Sees 1, 2, 3 e 11 abordam a motivao, alguns conceitos que so essenciais para todos os leitores assim como as concluses. As Sees 4, 5, 6 e 7 discutem conceitos como nveis, ciclos, tipos, tcnicas, critrios e ferramentas de teste; contedo importante para os desenvolvedores de software e os responsveis pelo teste (gerentes, projetistas e executores de teste). As Sees 8, 9, 10 apresentam os conceitos de processo, documentao, anlise de riscos, e consideraes polticas e estratgicas do teste, temas relacionados gerncia estratgica de TI, importantes para os responsveis pela rea de qualidade e de processos da organizao. Guias e tutoriais de teste esto sendo desenvolvidos para complementar este documento.

Teste de Software: Motivao e Conceitos Bsicos

Pgina 2

Centro de Tecnologia da Informao Renato Archer CTI/MCT

Contedo
1 2 3 4 5 6 Introduo: software pblico, qualidade e teste ............................................................. 4 Teste de software: objetivo, custos e benefcios ............................................................. 5 O sucesso no teste: provocar falhas que mostrem defeitos ............................................ 8 Nveis e ciclos do teste: quando testar .......................................................................... 11 Tipos de teste: o que testar ........................................................................................... 13 Tcnicas e critrios de teste: como testar ..................................................................... 15 6.1 Critrios da tcnica funcional ................................................................................... 17 6.2 Critrios da tcnica estrutural .................................................................................. 21 7 8 9 Ferramentas de apoio ao teste ...................................................................................... 24 Processo e documentao do teste: como organizar o trabalho .................................. 26 Anlise de riscos: priorizar aspectos para o teste .......................................................... 28

10 Poltica e processo de teste: o papel do teste na estratgia da organizao ................ 29 11 Concluso: transformando conceitos de teste em melhores produtos de software .... 31

Teste de Software: Motivao e Conceitos Bsicos

Pgina 3

Centro de Tecnologia da Informao Renato Archer CTI/MCT

Introduo: software pblico, qualidade e teste

O amadurecimento da indstria de software no Brasil traz consigo um aumento da competitividade entre as empresas brasileiras desenvolvedoras e tambm destas com empresas de outros pases. Neste contexto, a promoo da qualidade de produtos de software um fator crtico de sucesso. Tambm de suma importncia o aprimoramento dos processos de engenharia e de gesto no desenvolvimento de software, visando permitir projetos bem sucedidos, com menores custos e respeitando os limites de prazo. O Software Pblico Brasileiro (SPB) adota um modelo de desenvolvimento de software caracterizado pelo compartilhamento de produtos de software, assim como dos artefatos e servios a eles relacionados. A existncia de um alto nvel de qualidade do software, artefatos e servios compartilhados seguramente tem uma influncia positiva para o sucesso deste modelo. Deste modo, a adoo de prticas visando avaliar e aprimorar a qualidade deve ser estimulada no contexto do SPB. O desenvolvimento de software no uma tarefa fcil e, por ser fortemente baseada no trabalho humano, altamente sujeita a erros. Portanto, por mais que se adotem processos de software bem estabelecidos, e que estes sejam executados por pessoas capacitadas, usando tcnicas e ferramentas adequadas, erros durante o desenvolvimento acontecem e resultam em deficincias no software. A atividade de teste visa identificar estas deficincias, permitindo assim o aprimoramento dos produtos de software. O restante do documento est organizado do seguinte modo. A Seo 2 aborda a necessidade do teste e os impactos negativos de um teste inadequado; a Seo 3 define alguns conceitos fundamentais; a Seo 4 mostra como o esforo de teste pode ser realizado em etapas e ciclos; a Seo 5 apresenta alguns tipos de teste existentes; a Seo 6 descreve as principais tcnicas e critrios para seleo e avaliao de testes; a Seo 7 cita alguns tipos de ferramentas que podem apoiar esta atividade, enquanto a Seo 8 descreve as atividades principais e as informaes envolvidas em um processo de teste; a Seo 9 sumariza como a anlise de riscos pode ser considerada no teste; a Seo 10 aborda como situar estrategicamente o teste em relao aos objetivos da organizao. Finalmente, tem-se a concluso na Seo 11.

Teste de Software: Motivao e Conceitos Bsicos

Pgina 4

Centro de Tecnologia da Informao Renato Archer CTI/MCT

Teste de software: objetivo, custos e benefcios

Existem diversas definies de teste de software; por exemplo: Teste uma atividade direcionada para avaliar um atributo ou capacidade de um programa ou sistema e determinar se ele satisfaz os resultados requeridos1; Teste o processo de executar um programa com a inteno de encontrar defeitos2; Teste o processo pelo qual se explora e se entende o estado dos benefcios e riscos associados com a verso de um sistema de software3. Todas essas definies so vlidas e destacam algum aspecto importante da atividade de teste. De maneira simplificada podemos entender o teste de software como: a execuo do software de uma forma controlada com o objetivo de avaliar se o software se comporta ou no conforme especificado. Trata-se, portanto, de uma atividade fundamental para avaliar se o software produzido atende aos requisitos levantados com os usurios. No entanto, teste no exclui a realizao de outras atividades como as inspees efetuadas nos artefatos produzidos ao longo do processo de software. Uma questo essencial : por que existe a necessidade de se testar software? Uma resposta (provocativa) a esta pergunta tem a forma de outra questo: voc se sentiria confortvel em ser o passageiro de um vo em uma aeronave que nunca decolou antes? O processo de projeto e construo de aeronaves envolve uma srie de atividades de teste da aeronave como um todo e de seus componentes principais (asas, turbinas, sistemas eletrnicos, sistemas mecnicos). Essas atividades visam a confirmar as teorias consideradas no projeto, obter dados empricos e avaliar os aspectos no embasados por teorias, avaliar a conformidade com padres de segurana e de desempenho de vo, alm de vrios outros pontos. Os testes so aplicados em componentes, em subsistemas, e na aeronave inteira, incluindo o teste em condies reais de vo. Esta questo obviamente
1 2 3

Hetzel, B. 1988, The Complete Guide to Software Testing (2nd Ed.). QED Information Sciences, Inc. Myers, G.J., 1979, The Art of Software Testing, Addison-Wesley, New York.

Cem Kaner, James Bach e Bret Pettichord, Lessons Learned in Software Testing: A Context-Driven Approach, Willey Computer Publishing, 2002.

Teste de Software: Motivao e Conceitos Bsicos

Pgina 5

Centro de Tecnologia da Informao Renato Archer CTI/MCT

um exagero proposital; uma aeronave no testada nunca seria liberada para um vo comercial. Analogamente, um software no deve ser liberado para uso sem que atividades adequadas de teste tenham sido realizadas. Por meio do teste diversas deficincias existentes no software, relacionadas a problemas de funcionalidade, desempenho, segurana, instalao e utilizao podem ser encontradas e removidas, antes que o software entre em vo, isto , seja implantado para o uso dos clientes. Enfim, testa-se software porque o desenvolvimento de sistemas envolve uma srie de atividades em que as possibilidades de ocorrncia de erros humanos so inmeras. Erros podem ocorrer logo no incio do processo de criao do software, quando objetivos definidos podem estar incorretos ou incompletos. Alm disso, erros podem ocorrer nas demais fases do desenvolvimento, como projeto, codificao e integrao do software. Essencialmente erros ocorrem pela dificuldade dos seres humanos de executar tarefas e se comunicar com perfeio. Esses so os mesmos motivos que justificam o teste rigoroso em aeronaves. O teste de software no uma atividade tecnicamente fcil nem barata. A atividade de teste representa um percentual significativo do custo total de desenvolvimento do software. Estudos mostram que, dependendo do tipo do software e do processo de desenvolvimento, o custo do teste tipicamente fica entre 50% e 80% do custo total 4. No entanto, fato reconhecido que a ausncia de uma atividade de teste bem realizada acarreta um custo total significativamente maior. O retrabalho devido manuteno corretiva de problemas de especificao, projeto e programao uma realidade amplamente conhecida. Estatsticas apresentadas mostram ainda que cada R$ 1,00 investido em preveno de defeitos diminui de R$ 3,00 a R$ 10,00 os custos de manuteno corretiva. E cada R$ 1,00 investido em remoo de defeitos diminui de R$ 2,00 a R$ 5,00 os custos de manuteno corretiva. Um estudo do NIST (Instituto Nacional de Padres e Tecnologia, rgo do Departamento de Comrcio dos Estados Unidos) aponta impactos negativos de
4

Boehm, B. W. 1981, Software Engineering Economics. 1st. Prentice Hall PTR

Teste de Software: Motivao e Conceitos Bsicos

Pgina 6

Centro de Tecnologia da Informao Renato Archer CTI/MCT

inadequaes nas atividades de teste5. Dentre os problemas acarretados pelo teste inadequado podem-se destacar: Crescimento do nmero de falhas em uso devido m qualidade do software, acarretando perdas na reputao da organizao e no potencial de negcios futuros; Aumento no custo de desenvolvimento de software, visto que o custo da correo de problemas no software cresce ao longo dos estgios do desenvolvimento, tendo seu maior valor quando necessrio corrigir problemas em um software j implantado no cliente; Atraso para disponibilizar o produto ao mercado devido ausncia de processos e tcnicas de teste padronizadas e a conseqente necessidade de criar s pressas uma infra-estrutura de teste. Esta lista de problemas mais extensa, e apresenta problemas potencialmente dramticos, no caso de software com altos requisitos de confiabilidade, tais como: software de controle de reatores nucleares; software aeroespacial e software de monitoramento de leitos em UTIs. O teste inadequado de softwares que manipulam informaes de alto valor, como dados estratgicos de empresas e informaes bancrias, tambm pode acarretar grandes danos financeiros e de imagem s organizaes. No contexto do SPB as deficincias no teste de um produto de software podem acarretar uma perda de reputao deste software entre os seus possveis usurios, limitando consequentemente os potenciais benefcios trazidos pelo software. Raymond define o modelo bazar de desenvolvimento no qual o cdigo fonte do software disponibilizado publicamente na internet e desenvolvido de forma colaborativa e compartilhada por milhares de desenvolvedores espalhados pelo mundo; o modelo utilizado para o desenvolvimento do Kernel do sistema operacional Linux 6. Segundo Raymond, ao se usar este modelo de desenvolvimento quanto mais largamente o cdigo fonte estiver disponvel para o teste, exame e experimentao, mais rapidamente os bugs

The National Institute of Standards and Technology (NIST) Strategic Planning and Economic Analysis Group, The Economic Impacts of Inadequate Infrastructure for Software Testing, Maio, 2002 Eric S. Raymond, The Cathedral & the Bazaar, Musings on Linux and Open Source by an Accidental Revolutionary, Fevereiro, 2001, OReilly & Associates, Inc. Teste de Software: Motivao e Conceitos Bsicos
6

Pgina 7

Centro de Tecnologia da Informao Renato Archer CTI/MCT

sero descobertos, chamada por ele de Lei Linus referindo-se a Linus Torvalds, idealizador do Linux given enough eyeballs, all bugs are shallow 7. Na medida em que o SPB caracteriza-se pelo compartilhamento de cdigo fonte e de outros artefatos de software, razovel esperar que as prticas de teste possam ser conduzidas de forma eficiente, aproveitando a caracterstica colaborativa do ambiente e o esprito engajado e investigativo de muitos membros de comunidades. A utilizao de boas prticas de teste neste contexto tem o potencial de aumentar a qualidade dos produtos de software e os benefcios do SPB sociedade.

O sucesso no teste: provocar falhas que mostrem defeitos

O teste de software pode tambm ser definido como a execuo de um software com o objetivo de encontrar defeitos. Neste caso, fica explcita a idia de que o teste deve exercitar o software de uma maneira tal que este falhe, permitindo assim a posterior identificao e remoo da causa desta falha. Deve-se ter em mente que um defeito (fault ou defect em ingls) uma anomalia no software que pode causar uma falha (exemplos: um comando imperfeito, incompleto, ausente ou extra no software). Uma falha (failure) a ocorrncia de uma discrepncia entre o resultado observado da execuo do software e o resultado prescrito pelos requisitos. Um erro (error) um estado incorreto, intermedirio ou final, de execuo do software que pode produzir um resultado incorreto, ou seja, pode levar a uma falha do software. Um defeito no software introduzido devido a algum engano (mistake) cometido em algum momento no desenvolvimento do software e no descoberto em atividades de inspeo. Por exemplo: o foguete Ariane V explodiu em 1996, cerca de 40 segundos aps ter decolado 8. O foguete saiu de sua rota programada e se desintegrou devido a foras aerodinmicas. Em uma anlise posterior do incidente, verificou-se que o software de controle do vo indicou uma direo errada ao foguete (esta foi a falha) devido a uma
7

se os olhos forem suficientes, todos os bugs sero vistos em uma traduo livre. Ou: ... dados grupos grandes o suficiente de testadores-beta e de desenvolvedores, quase todos os problemas sero identificados rapidamente e o conserto ser bvio para algum....
8

ARIANE 5 Flight 501 Failure Report by the Inquiry Board, Julho, 1996.

Teste de Software: Motivao e Conceitos Bsicos

Pgina 8

Centro de Tecnologia da Informao Renato Archer CTI/MCT

converso incorreta de uma varivel tipo real de 64 bits em um inteiro de 16 bits (este foi o defeito). Esta converso produziu um erro de overflow, isto , um valor errneo de uma varivel (este foi o erro), que ocasionou a resposta incorreta do software. O engano foi, provavelmente, cometido por um programador, indevido. Portanto, para um defei ser descoberto necessrio que o software seja executado efeito de uma forma tal que o defeito seja sensibilizado e provoque uma falha. Isto ocorre falha quando o comando defeituoso executado e cria um estado de erro (valores incorretos para as variveis internas, por exemplo) Para que a falha acontea, necessrio ainda que este ternas, exemplo). erro seja propagado, ao longo da execuo, do ponto onde foi criado (logo aps o comando defeituoso) para alguma sada do software, ocasionando uma resposta final incorreta (valores incorretos para alguma sada produzida, por exemplo). A Figura 1 ilustra a cadeia de eventos que se inicia com um engano e que pode resultar em uma falha do software. que inseriu no software um comando de atribuio

Figura 1: C Cadeia de Eventos Para a Falha do Software

Em uma viso simplificada, a realizao do teste envolve: a. Selecionar valores para as Variveis de Entrada a serem submetidos ao software em teste (chamados de Dad de Entrada ou de Dados de Teste); esta seleo feita a ados partir do conjunto de todos os possveis valores que podem ser usados para executar o software, chamado de Domnio de Entrada do software.

Teste de Software: Motivao e Conceitos Bsicos ftware:

Pgina 9

Centro de Tecnologia da Informao Renato Archer CTI/MCT

b. Executar o software com os dados de teste, ou seja, informar os valores para as teste, variveis de entrada e acionar alguma funo no software e software; c. Avaliar se a sada produzida corresponde sada esperada segundo a especificao do software, isto , se o comportamento e os valores produzidos como resultado da , execuo foram os corretos corretos. Um par dados de entrada e resultados esperados associados chamado de um Caso hamado de Teste. Uma coleo de vrios casos de teste referida como um Conjunto de Casos de onjunto Teste. Para a realizao do teste, presume se a existncia de algum meio ou dispositivo que presume-se permita avaliar se certo resultado - ou comportamento - produzido pelo software est de acordo com a especificao (ou seja, se o resultado esperado de um software correto). Esta avaliao feita por meio de um orculo. Normalmente o executor do teste assume o papel de orculo e realiza a comparao esperado versus obtido identificando se o obtido, identifica software falhou ou no. A Figura 2 apresenta uma viso simplificada do teste: a execuo do programa com dados de entrada e a avaliao da sada produzida pelo programa em relao aos resultados esperados.

Figura 2: Viso Simplificada do Teste

Uma limitao inerente atividade de teste sua impossibilidade de provar que um software est correto. O teste pode revelar a presena de defeitos no software, mas no a . ausncia desses defeitos. Portanto, por mais rigoroso que seja o teste, no possvel assegurar que no permaneceram no software defeitos escondidos no encontrados escondidos,

Teste de Software: Motivao e Conceitos Bsicos ftware:

Pgina 10

Centro de Tecnologia da Informao Renato Archer CTI/MCT

durante o teste. No entanto, o teste pode dar subsdios para que se avalie o quo confivel (ou no) o software.

Nveis e ciclos do teste: quando testar

O teste de software normalmente realizado em uma srie de fases, ou nveis: Teste de Unidade; Teste de Integrao; Teste de Sistema; e Teste de Aceitao. Aps o desenvolvimento de cada unidade do software (procedimento, funo, mtodo ou classe) realizado o teste de unidade (ou teste unitrio), que visa a identificar defeitos introduzidos nos algoritmos e estruturas de dados dessas unidades. Em geral, o teste de unidade feito pelo prprio desenvolvedor da unidade. As unidades so ento incrementalmente integradas e testadas (teste de integrao). Esta etapa realizada pelos desenvolvedores ou por elementos de uma equipe de teste e visa a identificar defeitos de interface entre as unidades. Depois de integrado, o software testado como um todo: o teste de sistema o nvel de teste cujos requisitos so derivados da especificao de requisitos funcionais e no funcionais, e aplicado para verificar se o software e o hardware executam corretamente ou no quando integrados ao ambiente de operao. O teste de aceitao ento conduzido para estabelecer se o sistema satisfaz ou no os critrios de aceitao definidos com o cliente. Deve-se notar que em cada um desses nveis (unidade, integrao, sistema e aceitao) diversos ciclos de teste podem ocorrer. Em cada ciclo de teste um procedimento de teste realizado, por meio do qual um ou mais casos de teste so executados. Falhas provocadas por casos de teste devem ser registradas para posterior depurao do software (localizao e remoo dos defeitos) pela equipe de desenvolvimento. No prximo ciclo, casos de teste devem ser re-executados para avaliar se os defeitos que ocasionaram as falhas foram realmente removidos e se as alteraes no software no introduziram inadvertidamente outros defeitos. Pode ocorrer tambm a necessidade de se retornar a um nvel de teste anterior. Por exemplo: durante o teste de integrao podem ser identificados
Teste de Software: Motivao e Conceitos Bsicos

Pgina 11

Centro de Tecnologia da Informao Renato Archer CTI/MCT

problemas que requeiram muitas alteraes em algum mdulo do software. Neste caso, as pode ser adequado, alm de re executar casos de teste de integrao, tambm realizar re-executar novamente o teste de unidade do mdulo alterado. O teste de um software j testado previamente e que sofreu mudanas chamado de Teste de Regresso. Este teste busca verificar se as modificaes efetuadas no . introduziram novos defeitos ou ativaram defeitos em partes inalteradas do cdigo; visa tambm avaliar se o software ainda satisfaz os seus requisitos. O teste de regresso requisitos. tipicamente realizado na fase de manuteno, aps a realizao de mudanas no software ou no seu ambiente. Conforme descrito no pargrafo anterior, este teste tambm pode ocorrer ao longo do desenvolvimento do software. A Figura 3 ilustra um processo em que os nveis de teste so executados sequencialmente: teste de unidade de integrao, de sistema e de aceitao. Em todos os quencialmente: unidade, nveis so mostrados os ciclos que envolvem alteraes do software (ou depurao) e a redepurao execuo de casos de teste. A figura mostra tambm o fluxo de retorno a nveis anteriores o de teste.

Figura 3: Nveis e Ciclos de Teste

Teste de Software: Motivao e Conceitos Bsicos ftware:

Pgina 12

Centro de Tecnologia da Informao Renato Archer CTI/MCT

importante destacar que no obrigatrio que todos os nveis de teste ocorram para que se tenha um teste adequado. A necessidade ou no de realizar cada um desses nveis deve ser decidida a partir da anlise da situao especfica, conforme descrito nas sees sobre processos de teste (Sees 8 e 10).

Tipos de teste: o que testar

Diversos atributos de qualidade do software podem ser avaliados por meio de testes. Caractersticas de qualidade de software definidas em padres como a ISO/IEC 9126
9

podem servir como base para a definio de aspectos do software a serem avaliados por meio da realizao de testes. Portanto, existem diversos tipos de teste; cada tipo visa avaliao de um aspecto distinto do software e pode ser aplicado em um ou mais nveis de teste (unidade, integrao, etc.). O teste de funcionalidade busca avaliar se o software apresenta um conjunto de funes que satisfaa ou no s necessidades levantadas (associadas aos requisitos definidos). O teste de desempenho visa a avaliar se o software executa as funes previstas satisfazendo ou no os requisitos de desempenho definidos (e.g., velocidade de processamento, tempo de resposta, uso de memria). O teste de interoperabilidade avalia a capacidade do software em interagir com um ou mais componentes ou sistemas. O teste de segurana (security) visa a avaliar a habilidade do software de impedir o acesso no autorizado acidental ou deliberado ao software ou a dados. O teste de sanidade (smoke test) envolve a execuo de um subconjunto dos testes projetados que cobrem algumas funcionalidades principais; pode ser realizado

ISO/IEC 9126-1:2001 Software engineering -- Product Quality -- Part 1: Quality model

Teste de Software: Motivao e Conceitos Bsicos

Pgina 13

Centro de Tecnologia da Informao Renato Archer CTI/MCT

periodicamente, ou como uma atividade inicial para avaliar se o software est pronto para um esforo maior de teste. O teste de estresse simula condies atpicas de utilizao do software, provocando aumentos e redues sucessivas de transaes que superem os volumes mximos previstos para a capacidade de processamento dos componentes ou do sistema. O teste de usabilidade visa a determinar quo facilmente o produto de software compreendido, apreendido e usado, e quo agradvel ele ao usurio. O teste de portabilidade busca avaliar o nvel de facilidade de transferncia de um ambiente de hardware e software para outro ambiente. O teste de carga consiste em medir o comportamento de um componente ou sistema submetido a cargas de processamento crescentes para determinar qual nvel de carga o sistema pode tratar; por exemplo, nmero de usurios ou nmero de transaes. O teste de instalao busca avaliar se o software instalado e desinstalado com sucesso ou no em determinado ambiente operacional. O teste de recuperao determina a capacidade ou incapacidade de um produto de software de restabelecer condies normais de operao e de recuperar dados afetados, em caso de falha. A determinao de quais tipos de teste devem ser utilizados e em qual (quais) nvel (nveis) eles devem ser aplicados, ocorre durante a fase de planejamento do teste. Esta definio feita considerando-se as informaes disponveis sobre a natureza do software em teste e dos requisitos especficos dos mdulos que compem o software. Na maior parte das situaes adequado focar ateno no teste de funcionalidade para avaliar os se os requisitos funcionais do software so satisfeitos ou no. Este teste deve ser complementado por outros tipos de teste (carga, desempenho, etc) para avaliar se os requisitos no funcionais do software so satisfeitos ou no.
Teste de Software: Motivao e Conceitos Bsicos

Pgina 14

Centro de Tecnologia da Informao Renato Archer CTI/MCT

Tcnicas e critrios de teste: como testar

Esta seo apresenta algumas Tcnicas e Critrios de Teste teis para a seleo de bons casos de teste. importante ressalvar que existem outras tcnicas no relatadas aqui; procurou-se destacar as tcnicas mais usadas na prtica ou mais consolidadas na literatura. Como este documento apresenta apenas uma viso inicial sobre tcnicas e critrios, recomendada a consulta a tutoriais especficos e de literatura especializada para maiores informaes. Uma tarefa fundamental na atividade de teste a seleo dos casos de teste a serem utilizados. Esta seleo necessria porque o Teste Exaustivo, feito com todas as possveis combinaes de valores de entrada, quase sempre invivel. Por exemplo, considere um software que tenha como entrada 15 variveis, sendo que cada uma delas pode assumir 7 valores diferentes. Considere ainda que a execuo de cada caso de teste demore 1/100 de segundo (0,01 segundo). Para realizar o teste exaustivo deste software seriam necessrios 715/100 segundos, o que equivale a 1.505 anos e alguns meses de processamento. Tendo em vista o objetivo principal do teste de revelar defeitos e a restrio de que os cronogramas e oramentos sejam cumpridos, aconselhvel a utilizao de Tcnicas de Teste. Estas tcnicas estabelecem procedimentos para selecionar - ou criar - os casos de teste que resultem em um conjunto de teste eficaz e de tamanho moderado. As tcnicas de teste determinam a natureza da informao a ser utilizada para se fazer a seleo ou a avaliao de conjuntos de teste. Na tcnica de Teste Funcional os casos de teste so selecionados por meio da anlise da especificao do software, ou utilizando modelos criados na fase de anlise e projeto do software. Na tcnica de Teste Estrutural os casos de teste so selecionados por meio da anlise da estrutura interna do software. Na tcnica de teste Baseada em Defeitos, casos de teste so selecionados a partir de classes de defeitos que podem ser introduzidos ao longo do desenvolvimento do software. A Figura 4 ilustra as tcnicas funcional e estrutural de teste.

Teste de Software: Motivao e Conceitos Bsicos

Pgina 15

Centro de Tecnologia da Informao Renato Archer CTI/MCT

Figura 4: Tcnicas de Teste 10

As diversas tcnicas de teste no so excludentes; na verdade, a utilizao de vrias as tcnicas recomendada, pois os defeitos revelados pela aplicao de cada uma delas podem ada, ser diferentes. A utilizao de uma tcnica de teste ocorre por meio da aplicao de algum Critrio de Teste. Um critrio de teste determina um conjunto de Elementos Requeridos do software equeridos que devem ser exercitados pela realizao do teste. Por exemplo, o critrio todos os comandos - ou todos os ns - da tcnica estrutural de teste define como elementos requeridos os comandos do cdigo do software. Neste caso, cada comando do software o software. so deve ser executado (ou exercitado), pelo menos uma vez, por algum dado de teste. A Cobertura do Teste, com respeito a um critrio de teste especfico, mede o este, percentual de elementos requeridos exercitados por um conjunto de casos de teste executados. Por exemplo, o percentual de comandos executados durante o teste seria uma . medida de cobertura considerando se o critrio de teste do exemplo anterior. Deste modo, a considerando-se medida de cobertura quantifica, sob certa perspectiva, a qualidade do teste realizado. razovel supor, neste exemplo, que um conjunto de teste que executa 90% dos comandos de um software melhor do que outro conjunto de teste que executa apenas 50% dos

10

O teste caixa preta inclui outras tcnicas alm da tcnica funcional, nica que est sendo considerada neste documento. Teste de Software: Motivao e Conceitos Bsicos ftware:

Pgina 16

Centro de Tecnologia da Informao Renato Archer CTI/MCT

comandos. Se um conjunto de casos de teste exercita todos os elementos requeridos pelo critrio, diz-se que tal conjunto satisfaz o critrio. Em geral, os critrios de teste podem ser utilizados para: criar um conjunto de casos de teste; avaliar um conjunto de casos de teste j criado; ou ainda, servir como uma condio para a finalizao do teste. A seguir feita uma breve descrio de alguns critrios de teste da tcnica funcional e da tcnica estrutural, as mais usadas na prtica.
6.1 Critrios da tcnica funcional

Os critrios da tcnica de teste funcional caracterizam-se por utilizar informaes originadas da especificao do software como base para a seleo de casos de teste. Artefatos criados na fase de anlise de requisitos e de projeto do software, tais como o documento de requisitos do software ou modelos como diagramas UML, so utilizados para criar os casos de teste. A idia essencial da tcnica funcional selecionar dados de teste representativos o suficiente para avaliar se as funcionalidades definidas na especificao do software foram implementadas corretamente ou no. Para tanto, operaes associadas s funcionalidades so identificadas e dados de teste que as exercitem so definidos e executados. O critrio Particionamento de Equivalncia divide o domnio de entrada do software em classes de equivalncia e requer que pelo menos um dado de teste de cada classe seja selecionado e executado. Essas classes so definidas pressupondo que todo dado de entrada pertencente a uma classe tratado do mesmo modo, de acordo com a especificao do software. Portanto, cada dado de teste selecionado representa os demais dados de testes da sua classe de equivalncia. Por exemplo, se a especificao define que um software recebe como entrada uma varivel idade, tipo inteiro, que pode variar de 0 a 120 anos (incluindo os extremos), poderiam ser identificadas as seguintes classes de equivalncia: Classe 1: idade menor que zero referida como classe de valores invlidos; Classe 2: idade entre 0 e 120 classe de valores vlidos; e, Classe 3: idade maior que 120 outra classe de valores invlidos. Pgina 17

Teste de Software: Motivao e Conceitos Bsicos

Centro de Tecnologia da Informao Renato Archer CTI/MCT

Ao se executar o software com dados de teste que pertenam s Classes 1 e 3 espera-se que os valores fornecidos sejam identificados como no aceitveis e sejam emitidas mensagens apropriadas. Ao se executar o software com um dado de teste que pertena Classe 2 o valor fornecido deve ser aceito e uma sada apropriada deve ser produzida. A Figura 5 ilustra as classes de equivalncia do exemplo e os dados de teste selecionados para exercitar cada classe.
Classe 1 (valores invlidos) Classe 2 (valores vlidos) Classe 3 (valores invlidos)

-39

45

120

135

Figura 5: Classes de Equivalncia e Dados de Teste

Dependendo da especificao, se existirem diferentes tipos de tratamento dentro de alguma dessas classes, ela deve ser subdividida. Por exemplo, a Classe 2 pode ser subdividida em sub-classes: 2.1 idade entre 0 e 17; 2.2 idade entre 18 e 20; e 2.3 idade entre 21 e 120. Esta diviso faz sentido e deve ser feita se a especificao do software definir tratamentos distintos para estas diferentes faixas de valores. Neste caso a Classe 2 no homognea e, portanto, a execuo de apenas um caso de tese da classe seria insuficiente. Deve-se notar que o modo como as classes de equivalncia so definidas influencia fortemente a eficcia do critrio. Esta definio deve ser feita de forma cuidadosa, analisando-se a natureza de cada varivel de entrada do programa e a especificao do software em teste. O critrio Anlise de Valores Limite complementa o critrio Particionamento de Equivalncia. Freqentemente as situaes de transio de comportamento do software de uma classe para outra classe, as situaes limite, so implementadas de forma incorreta. Estas situaes costumam ser inerentemente complexas e acabam induzindo a erros de anlise, projeto ou codificao. Para descobrir defeitos associados a estas situaes recomendada a seleo de dados de teste situados nos limites das classes. No exemplo anterior (varivel idade, tipo inteiro,
Teste de Software: Motivao e Conceitos Bsicos

Pgina 18

Centro de Tecnologia da Informao Renato Archer CTI/MCT

que pode variar de 0 a 120 anos, incluindo os extremos) os valores limite seriam: 1, 0 e -1, referentes ao limite entre as Classes 1 e 2; e 119, 120, 121, referentes ao limite entre as Classes 2 e 3, conforme ilustrado na Figura 6. Notar que so selecionados valores exatamente no limite, valores imediatamente inferiores e imediatamente superiores ao limite. A definio dos valores limite tambm deve ser feita cuidadosamente, analisando-se a natureza de cada varivel de entrada do programa e a especificao do software em teste.
Classe 1 (valores invlidos) Classe 2 (valores vlidos) Classe 3 (valores invlidos)

-1

0 1

119

120 121

Figura 6: Valores Limite e Dados de Teste

Teste baseado em modelos Alguns critrios caracterizam-se por utilizar modelos do software (representaes intermedirias do software) como base para a seleo de dados de teste. Esses critrios so freqentemente chamados de Teste Baseado em Modelos (Model Based Testing). Modelos como Mquinas de Estados Finitas (FSM), ou modelos definidos em linguagens como UML (Unified Modelling Language) ou SDL (Specification and Description Language) podem ser utilizados para este propsito. O Teste Baseado em Casos de Uso utiliza os modelos de Casos de Uso (representao definida na UML), criados na fase de anlise de requisitos e de projeto do software, para a seleo de casos de teste. Casos de Uso so muito usados para especificar o comportamento esperado do sistema do ponto de vista dos atores que interagem com o sistema. Como so elaborados normalmente em etapas iniciais do processo de desenvolvimento, esses modelos so teis para o projeto antecipado de casos de teste, principalmente os que sero aplicados nos testes de sistema e de aceitao do software.

A aplicao do critrio de teste feita nos seguintes passos:

Teste de Software: Motivao e Conceitos Bsicos

Pgina 19

Centro de Tecnologia da Informao Renato Archer CTI/MCT

a. Descrever os fluxos de eventos para o caso de uso. Devem ser descritos tanto o fluxo de eventos bsico como os fluxos alternativos e de exceo. b. Definir o conjunto de cenrios que sero usados nos testes. Cada cenrio pode ser formado a partir dos fluxos de eventos identificados bem como das combinaes desses fluxos. c. Definir casos de teste para cada um dos cenrios, ou seja, para cada cenrio definir valores de entrada, aes no software que provoquem a execuo do cenrio e as sadas esperadas. d. Executar o software com os dados de teste, avaliar se os resultados produzidos correspondem aos esperados, registrar os resultados e os incidentes observados. Notar que os passos a, b e c podem ser realizados logo que a especificao dos casos de uso esteja pronta e revisada; no necessrio esperar a concluso da implementao dos casos de uso para realiz-los. O passo d pode ser realizado em momentos distintos, dependendo do nvel do teste realizado: quando os mdulos que implementam as funes especificadas nos casos de uso estiverem disponveis (no caso do teste de partes do sistema); quando o sistema como um todo estiver integrado e disponvel (no caso do teste de sistema); ou ainda, quando o sistema for utilizado no processo de aceitao pelo cliente (no caso do teste de aceitao). Naturalmente, outros modelos (da UML ou de outras linguagens) podem ser utilizados de forma semelhante para a seleo de casos de teste. Por exemplo, Diagramas de Estados (com os Statecharts) podem servir como base para a seleo de casos de teste que exercitem transies de estado que podem ocorrer em um objeto. Critrios de teste baseados em modelos de estados so teis para aplicaes nas quais muitas transies complexas de estado dos objetos so possveis, tais como sistemas de controle de processos e sistemas de telefonia. Diagramas de Colaborao, que descrevem a interao entre objetos para especificar um comportamento, tambm podem ser utilizados para seleo de casos de teste. Critrios de teste baseados em Diagramas de Colaborao permitem avaliar interaes especficas entre objetos, formadas por seqncias de comunicaes. Os casos de teste visam a

Teste de Software: Motivao e Conceitos Bsicos

Pgina 20

Centro de Tecnologia da Informao Renato Archer CTI/MCT

exercitar e avaliar se as trocas de mensagens, que caracterizam a colaborao de um conjunto de objetos, permitem atingir os propsitos definidos na especificao do sistema.
6.2 Critrios da tcnica estrutural

Na tcnica de Teste Estrutural os dados de teste so selecionados por meio da anlise da estrutura interna do software. Portanto, o cdigo fonte do software deve estar disponvel, pois ele utilizado para a seleo dos dados de teste. A motivao para o uso desses critrios muitas vezes feita com questionamentos do tipo: voc confiaria em um software se fosse informado que algumas instrues deste software nunca foram executadas antes? Esta pergunta enfatiza que defeitos em trechos no exercitados do cdigo fonte do software certamente no sero descobertos. Na Tcnica Estrutural uma unidade de software (funo, procedimento ou mtodo) considerada como o conjunto de seus componentes estruturais. Estes componentes estruturais podem ser comandos de desvio (como os comandos: if-then; switch; while e repeat) ou outros comandos (instrues como: x = y + 2; read(a,b); x = func(a,b) ). O software pode ser representado por um Grafo de Fluxo de Controle (GFC) composto de ns correspondem a blocos de comandos que so sempre executados conjuntamente -, e ramos, que correspondem a possveis desvios no fluxo de execuo. O GFC possui um nico n de entrada, um nico n de sada, e define um conjunto de caminhos que podem ser executados do n de entrada ao n de sada, passando por certos comandos e desvios ao longo da execuo. Quando se executa o software com um dado de teste, algum caminho especfico ser executado no programa (isto s no ocorre caso o software entre em um lao infinito). A Figura 7 mostra um cdigo fonte em C (identifier.c) e o respectivo GFC 11. Notar que o cdigo fonte apresenta no lado esquerdo como comentrios o nmero do n do GFC ao qual o comando pertence. possvel identificar conjuntos de comandos executados sempre conjuntamente, por exemplo, os comandos precedidos por /* 01 */ que pertencem ao n 1 do GFC. Pode-se tambm observar o efeito de comandos de desvio no fluxo de

Cdigo fonte e GFC presentes em: Barbosa E., Maldonado, J., Vincenzi, A., Delamaro, M., Souza, S., Jino, M. Introduo ao Teste de Software, XIV Simpsio Brasileiro de Engenharia de Software, 2000.
11

Teste de Software: Motivao e Conceitos Bsicos

Pgina 21

Centro de Tecnologia da Informao Renato Archer CTI/MCT

controle, por exemplo, o comando while presente no n 4 do grafo, ou o comando if-thenelse iniciado no n 8.
/* 01 */ { /* 01 */ char achar; /* 01 */ int length, valid_id; /* 01 */ length = 0; /* 01 */ printf (Digite um possvel identificador\n); /* 01 */ printf (seguido por <ENTER>: ); /* 01 */ achar = fgetc (stdin); /* 01 */ valid_id = valid_starter (achar); /* 01 */ if (valid_id) /* 02 */ length = 1; /* 03 */ achar = fgetc (stdin); /* 04 */ while (achar != \n) /* 05 */ { /* 05 */ if (!(valid_follower (achar))) /* 06 */ valid_id = 0; /* 07 */ length++; /* 07 */ achar = fgetc (stdin); /* 07 */ } /* 08 */ if (valid_id && (length >= 1) && (length < 6) ) /* 09 */ printf (Valido\n); /* 10 */ else /* 10 */ printf (Invalido\n); /* 11 */ }

Figura 7: Cdigo Fonte e Respectivo Grafo de Fluxo de Controle

Critrios de teste estrutural estabelecem componentes internos do software como elementos requeridos. O critrio de teste Todos os Comandos (ou Todos os Ns) requer que cada comando do software seja exercitado pelo menos uma vez durante o teste. A determinao de dados de teste que exercitem um comando especfico requer a anlise do cdigo fonte do software e a escolha de valores para as variveis de entrada que provoquem a execuo do comando. Por exemplo, a Figura 8 mostra um trecho de programa no qual h um comando de deciso if-then-else e o respectivo GFC. Para que os comandos representados por B sejam executados necessria a seleo de valores de entrada tais que a condio lgica do comando if seja satisfeita; por exemplo, valores de entrada que faam com que x tenha valor 100 e y tenha valor 30 imediatamente antes do comando if (notar que x e y podem ser variveis de entrada, mas tambm podem ser computadas internamente, a partir de outras variveis). Outros dados de teste sero necessrios para exercitar os comandos

Teste de Software: Motivao e Conceitos Bsicos

Pgina 22

Centro de Tecnologia da Informao Renato Archer CTI/MCT

representados por C; por exemplo, dados que resultem nos valores x = 20 e y = 15 antes do comando if.
A A B C C D ; if (x > y * 2) {} else {} ; A B D C

Figura 8: Comando if-then-else e Respectivo Grafo de Fluxo de Controle

A A A B C ; If (x > y * 2) {} ; C Figura 9: Comando if-then e Respectivo Grafo de Fluxo de Controle B

O critrio Todos os Ramos requer que cada possvel transferncia de controle seja exercitada pelo menos uma vez. A Figura 9 mostra um trecho de programa com um comando condicional if-then. Os dados de teste que satisfazem a condio do if, exercitam os comandos representados em B e tambm os em C. Este critrio, no entanto (ao contrrio do anterior), requer a execuo de dados de teste adicionais, que provoquem a transferncia de controle (ou ramo) do comando if diretamente para os comandos em C (sem passar por B). O critrio Todos os Caminhos requer que cada diferente caminho no GFC seja executado pelo menos uma vez. Este critrio geralmente considerado excessivamente exigente visto que, em programas reais, a sua aplicao tende a gerar conjuntos muito grandes de elementos requeridos. Considere a Figura 10 que mostra um trecho de cdigo com dois comandos if-then-else em sequncia e o respectivo GFC; note que o segundo comando if pertence ao n D no grafo. A execuo de apenas dois casos de teste suficiente para exercitar todos os ns e tambm todos os arcos do GFC; por exemplo, utilizando um caso de teste que exercite a seqncia ABDEG e outro que exercite a
Teste de Software: Motivao e Conceitos Bsicos

Pgina 23

Centro de Tecnologia da Informao Renato Archer CTI/MCT

seqncia ACDFG. No entanto, para satisfazer o critrio todos os caminhos so necessrios quatro casos de teste, cada um exercitando um caminho do GFC: ABDEG, ABDFG, ACDEG e ACDFG.
A A B C C D E F F G ; if (x > y * 2) {} else {} if (z > w) {} else {} ; A B D E G F C

Figura 10: Comandos if-then em Sequncia e Respectivo Grafo de Fluxo de Controle

Existem outros critrios estruturais que no sero abordados neste documento. Mais informaes sobre os critrios apresentados e sobre como utiliz-los encontram-se em tutoriais especficos e em literatura especializada.

Ferramentas de apoio ao teste

As empresas de software so cada vez mais pressionadas a produzir produtos de qualidade em curto espao de tempo. Esta situao coloca uma forte presso em suas equipes de teste, que so levadas a tentar aumentar a cobertura dos testes realizados sem comprometer os prazos de entrega do projeto. O emprego de ferramentas de apoio pode reduzir o esforo e aprimorar a qualidade do teste. Estas ferramentas no so suficientes para automatizar completamente o teste, mas podem auxiliar o testador na realizao de diversas atividades. So exemplos de atividades de teste para as quais se encontram ferramentas de apoio: Definio dos elementos requeridos para o teste: para as diversas tcnicas so determinados elementos requeridos que podem servir de base para a criao de casos de teste;

Teste de Software: Motivao e Conceitos Bsicos

Pgina 24

Centro de Tecnologia da Informao Renato Archer CTI/MCT

Avaliao de cobertura atingida no teste e a identificao de elementos requeridos no exercitados: para as diversas tcnicas so avaliados o nvel de cobertura atingido (percentual de elementos requeridos exercitados) e os elementos requeridos ainda no exercitados. As ferramentas permitem quantificar a qualidade do teste; Captura de eventos e de respostas do software: gravao e reproduo de informaes do teste, tais como: dados de entrada, eventos de entrada, interfaces e informaes mostradas; Execuo do teste: execuo do software com um conjunto de casos de teste e a avaliao do resultado produzido. Ferramentas podem ser aplicadas tanto para o teste de unidade como para o teste de sistema; Armazenamento e gerenciamento de informaes de teste: manuteno de informaes de teste planos, projetos, scritps e casos de teste. Ferramentas permitem tambm o rastreamento de informaes associando casos de teste aos requisitos do software a serem validados; Armazenamento e gerenciamento de incidentes: registro de informaes sobre incidentes ocorridos e acompanhamento da resoluo; Definio e gerenciamento do processo de teste: definio de aspectos do processo de teste como recursos, medidas, atividades e tarefas, e tambm o gerenciamento da execuo do processo de teste. A adoo de um processo de teste para a organizao (veja prximas sees) pode

incluir a avaliao de quais tipos de ferramentas so adequadas aos objetivos estabelecidos para o teste.

Teste de Software: Motivao e Conceitos Bsicos

Pgina 25

Centro de Tecnologia da Informao Renato Archer CTI/MCT

Processo e documentao do teste: como organizar o trabalho A adoo de um processo bem estabelecido para realizar as diversas atividades da

engenharia de software contribui positivamente para que se alcance o objetivo pretendido. Um processo um conjunto de passos parcialmente ordenados, constitudos por atividades, mtodos, prticas e transformaes, usado para atingir uma meta. A atividade de teste de software tambm deve ser conduzida por meio de um processo bem estabelecido. Um processo de teste de software um conjunto de passos parcialmente ordenados constitudos por atividades, mtodos e prticas, usadas para testar um produto de software. Um exemplo de modelo de processo de teste o ArtProTest (Artifact Oriented Process Model for Testing) 12,13. Este modelo baseado em artefatos de teste determinados na Norma IEEE Std 829-1998
14

e formado por subprocessos, definidos e ordenados de

forma a permitir que o teste seja eficiente e eficaz. No subprocesso Planejar criado o Plano de Teste de Software, que contm, dentre outras informaes: extenso e abordagem do teste; recursos necessrios, equipe e treinamento, cronograma de atividades; ambiente operacional; itens a serem testados, o nvel e abordagem de teste para cada item, atividades, tarefas e respectivos responsveis, alm de riscos e planos de contingncia no teste. O subprocesso Projetar envolve: refinar a abordagem de teste, definir e especificar os casos de teste; estabelecer o ambiente e procedimentos de teste. O subprocesso Executar envolve: executar, registrar, suspender, retomar, parar, encerrar e tratar as contingncias no teste. O subprocesso Registrar visa relatar a execuo dos testes e os incidentes observados (defeito no software ou anomalia de funcionamento do ambiente). Tambm so sumarizados os resultados do teste e as avaliaes baseadas nesses resultados.
12

Crespo, A. N.; Silva, O. J. ; Borges, C. A.; Salviano, C. F.; Argollo Junior, M. T. E.; Jino, M. Uma Metodologia para Teste de Software no Contexto da Melhoria de Processo. III Simpsio Brasileiro de Qualidade de Software, 2004. v. 3. p. 271-285.
13

Bueno, P.M.S., Crespo A.N., Jino, M., Analysis of an Artifact Oriented Test Process Model and of Testing Aspects of CMMI. In: 7th International Conference on Product Focused Software Process Improvement, Amsterdam., Lecturer Notes in Computer Science. Berlin: Springer-Verlag, 2006. v. 4034. p. 263-277.
14

IEEE Std 829 (1998), IEEE Standard for Software Test Documentation, IEEE, New York.

Teste de Software: Motivao e Conceitos Bsicos

Pgina 26

Centro de Tecnologia da Informao Renato Archer CTI/MCT

importante destacar que existem diversas atividades associadas a cada subprocesso descrito anteriormente, que criam ou utilizam os artefatos que documentam o teste (plano de teste, projetos de teste, etc). A definio de como esta informao de teste deve ser estruturada em artefatos (isto , a definio de templates de teste) uma etapa importante da implantao de um processo de teste em uma organizao. O processo de teste deve ser alinhado com o processo de desenvolvimento como um todo. Uma alternativa organizar os subprocessos de teste considerando as principais fases do processo de desenvolvimento e associando a cada fase o nvel de teste de software correspondente unidades, integrao, sistema e aceitao (Modelo V). As atividades de teste podem ser iniciadas junto com as atividades de desenvolvimento, logo que as informaes necessrias estejam disponveis. Neste caso, o planejamento do teste deve ser realizado junto com o planejamento do desenvolvimento, enquanto que o projeto do teste de aceitao pode ser iniciado logo que os requisitos do software tenham sido definidos. A execuo de atividades de teste o mais cedo possvel diminui as chances de que esta atividade seja feita de forma apressada no final do projeto, devido necessidade de entregar o produto ao cliente. Alguns modelos de processo de desenvolvimento de software, como o Espiral ou o RUP, definem iteraes (ou ciclos) para o desenvolvimento do software. Ao invs da realizao seqencial das atividades de desenvolvimento do software, como no tradicional modelo cascata
15

, so definidas iteraes para o desenvolvimento e incrementos (ou

releases) so associados a cada iterao. Cada incremento envolve a realizao das atividades para: definio de requisitos, projeto, implementao, integrao e testes. Nestes casos, as atividades de teste devem ser associadas s atividades de desenvolvimento em cada iterao, de modo que haja o adequado replanejamento, projeto, execuo e registro dos testes. Recomenda-se realizar um planejamento global do teste junto com o planejamento do desenvolvimento. O teste final do sistema e o teste de aceitao so executados aps o trmino da ltima iterao do processo de desenvolvimento.

15

Tipicamente, as atividades realizadas no modelo cascata so: anlise de requisitos; projeto do software; implementao e teste de unidades; integrao e teste de integrao; teste de sistema; implantao e teste de aceitao. Teste de Software: Motivao e Conceitos Bsicos

Pgina 27

Centro de Tecnologia da Informao Renato Archer CTI/MCT

Alguns modelos mais recentes enfatizam o projeto de testes e sua execuo como um elemento central do desenvolvimento do software. A abordagem Desenvolvimento Baseado em Testes (ou TDD, sigla em ingls) frequentemente adotada em mtodos geis, como a Programao Extrema (XP). No TDD os casos de teste so criados pelos desenvolvedores antes mesmo que o cdigo fonte seja criado.

Anlise de riscos: priorizar aspectos para o teste

Em muitos casos o software em teste possui algumas partes (ou funcionalidades) nas quais a ocorrncia de uma falha pode acarretar graves conseqncias a seus usurios, podendo impactar negativamente seus negcios e eventualmente at mesmo colocar a integridade de vidas humanas em risco. Por outro lado, o mesmo software pode possuir partes nas quais a ocorrncia de falhas, embora no desejvel, no seja crtica em termos dos negcios de seus usurios, impactando-os somente de forma marginal. Neste contexto, uma preocupao fundamental do teste avaliar as funcionalidades do software que sejam mais importantes para o negcio de seus futuros usurios e propor e desenvolver atividades de teste que abordem com o devido cuidado essas reas. Pensar nos testes com a perspectiva dos riscos que as falhas possam provocar um aspecto importante para o sucesso do teste. A anlise de riscos deve ocorrer no planejamento do teste e deve dar subsdios para a definio de tipos e tcnicas de teste a serem utilizadas em cada parte do software, assim como o quo rigoroso deve ser o teste daquela parte do software. Em ltima anlise, a considerao dos riscos envolvidos permite alocar os recursos de teste de uma maneira prudente, dosando o rigor e o esforo do teste de cada parte do software ao nvel requerido de confiabilidade.

Teste de Software: Motivao e Conceitos Bsicos

Pgina 28

Centro de Tecnologia da Informao Renato Archer CTI/MCT

10 Poltica e processo de teste: o papel do teste na estratgia da organizao A definio de uma Poltica de Teste fundamental para qualquer organizao que pretende definir ou aprimorar as suas atividades de teste. Trata-se, portanto, de um primeiro passo importante que servir de base para definio do processo de teste da organizao. A poltica de teste define, de maneira geral, os objetivos e a viso estratgica em relao ao teste. Portanto, deve estar alinhada com a poltica de qualidade e com os objetivos de negcios da organizao. Ao se estabelecer uma viso comum sobre o teste para todos os envolvidos com esta atividade, obtm-se um alinhamento das iniciativas para a utilizao ou melhoria do processo de teste, tanto no desenvolvimento como na manuteno de software. Recomenda-se, portanto, que a poltica de teste seja documentada, divulgada e tenha um responsvel definido. A definio de indicadores associados aos objetivos do teste permite a avaliao e a melhoria contnua do processo de teste na organizao. Tipicamente uma poltica de teste aborda: objetivos e importncia do teste; nveis de qualidade a serem atingidos; nvel de independncia da equipe de teste; principais responsabilidades; definio em alto nvel do processo de teste; e separao entre teste e depurao. A partir do momento em que se estabelece o qu as atividades de teste devem atingir na organizao a Poltica de Teste pode-se trabalhar para definir como os objetivos sero atingidos. A definio do como d-se pelo estabelecimento de um processo de teste. Modelos de processos genricos de teste e modelos de maturidade de teste podem servir como inspirao nesta tarefa. Um modelo de processo genrico de teste, como o descrito na Seo 8, pode ser adaptado s necessidades especficas de cada organizao. Tal tipo de modelo define um contedo amplo em teste (formado por atividades, mtodos, artefatos, etc.) que serve como base para o estabelecimento de processos customizados, fundamentados nas necessidades de teste especficas de cada organizao. O termo Estratgia de Teste tambm utilizado na literatura com significado semelhante, ou seja, atividades, mtodos, artefatos de teste adotados por uma organizao.

Teste de Software: Motivao e Conceitos Bsicos

Pgina 29

Centro de Tecnologia da Informao Renato Archer CTI/MCT

Modelos de maturidade de testes, tais como o Test Process Improvement (TPI) o Test Maturity Model Integration (TMMi)
17

16

ou

, tambm podem ser utilizados para definir

um processo de teste bem como para guiar a sua avaliao e melhoria. O TMMi complementar ao modelo CMMI e aborda aspectos importantes para os gerentes e analistas de testes e demais profissionais de qualidade de software. Assim como o modelo em estgios do CMMI, o TMMi usa o conceito de nveis de maturidade para a avaliao e melhoria do processo de teste. A adoo de um processo de teste, feita por meio da customizao de um modelo de processo genrico de teste, referida como uma implantao ou configurao de um processo de teste na organizao. Os modelos de processos genricos de teste ou os modelos de maturidade do teste podem ser utilizados tambm para aprimorar, de forma controlada e gradual, um processo de teste j existente na organizao. A implantao de um processo de teste deve ser feita de forma cuidadosa, por meio da anlise das reais necessidades de teste e das possibilidades da organizao. Fatores como tipo de software desenvolvido, requisitos de confiabilidade e segurana, bem como a disponibilidade de recursos humanos e financeiros da organizao, devem ser levados em conta nesta implantao. Em geral, requisitos rigorosos de confiabilidade e segurana do software determinam a definio de processos de teste mais completos, contemplando vrios nveis, tipos e tcnicas de teste. Por outro lado, em muitos casos um processo leve com poucos nveis e utilizando tcnicas simples e documentando apenas o essencial pode ser o suficiente. Processos de teste mais completos demandam um maior esforo por parte da organizao, mas tendem a propiciar melhores produtos de software, alm de evidncias mais claras da qualidade do teste.

16

Koomen, T. and Pol M., (1999), Test Process Improvement: A practical step-by step guide to structured testing. ACM Press, London, England.
17

TMMi Foundation, Test Maturity Model Integration (TMMi) Version 2.0, 2009.

Teste de Software: Motivao e Conceitos Bsicos

Pgina 30

Centro de Tecnologia da Informao Renato Archer CTI/MCT

11 Concluso: transformando conceitos de teste em melhores produtos de software Este documento apresentou um corpo de conhecimentos fundamentais em Teste de Software. O contedo foi abordado mais em extenso do que em profundidade, isto , espera-se que o leitor tenha adquirido um conhecimento amplo dos vrios aspectos das atividades de teste; entretanto, necessrio o aprofundamento nos assuntos especficos conforme o interesse e os objetivos especficos. Os guias e os tutoriais de teste (em elaborao) iro prover o aprofundamento em alguns aspectos tratados de forma rpida neste documento. A literatura especfica de teste tambm pode ser til para este intento. Espera-se que com a aplicao do contedo apresentado, os diversos atores envolvidos com as questes de qualidade e teste das mais diversas organizaes possam definir ou aprimorar as suas prticas de teste. Em especial, espera-se que todos os participantes que compem o ecossistema do SPB possam se beneficiar da aplicao deste contedo e tambm possam contribuir para o aprimoramento do conhecimento pblico de teste de software do SPB.

Teste de Software: Motivao e Conceitos Bsicos

Pgina 31