11 1 --teste_de_software_motivação_e_conceitos_basicos

Centro de Tecnologia da Informação Renato Archer – CTI/MCT

Teste de Software: Motivação e Conceitos Básicos Página 1

Centro de Tecnologia da Informação Renato Archer, CTI

Ministério da Ciência e Tecnologia, MCT

Teste de Software: Motivação

e Conceitos Básicos

Autores: Adalberto Nobiato Crespo: [email protected] Mario Jino: [email protected] Miguel Argollo: [email protected] Paulo Bueno: [email protected] Celso Penteado de Barros: [email protected]

Outubro/2009



Teste de Software: Motivação e Conceitos Básicos

Apresentação

Este documento apresenta uma introdução ao teste de software, um conjunto de atividades

de extrema importância para a obtenção de produtos de software de qualidade. Como um

texto inicial, buscou-se apresentar os conceitos fundamentais de teste de uma forma simples

e breve. São descritos, dentre outros conceitos de teste: o objetivo; os procedimentos; o

processo; os tipos; os níveis e as técnicas aplicadas à atividade de teste.

O objetivo é apontar práticas aceitas como eficazes por profissionais da área e

também padrões recentes de teste de software, definidos por órgãos como ISO/IEC e IEEE.

É importante notar que a adoção de qualquer tecnologia de teste por parte das organizações

ou profissionais envolvidos com o SPB deve ser calcada em uma análise cuidadosa das

reais necessidades de teste, tendo em vista o objetivo da organização ou do profissional e a

natureza do software produzido.

Diferentes usuários podem se interessar prioritariamente por partes distintas deste

documento. Embora a leitura integral seja recomendada, podem-se identificar duas áreas de

interesse: aspectos mais técnicos do teste e aspectos mais voltados à política e ao

gerenciamento do teste.

As Seções 1, 2, 3 e 11 abordam a motivação, alguns conceitos que são essenciais para

todos os leitores assim como as conclusões. As Seções 4, 5, 6 e 7 discutem conceitos como

níveis, ciclos, tipos, técnicas, critérios e ferramentas de teste; conteúdo importante para os

desenvolvedores de software e os responsáveis pelo teste (gerentes, projetistas e executores

de teste). As Seções 8, 9, 10 apresentam os conceitos de processo, documentação, análise

de riscos, e considerações políticas e estratégicas do teste, temas relacionados à gerência

estratégica de TI, importantes para os responsáveis pela área de qualidade e de processos da

organização.

Guias e tutoriais de teste estão sendo desenvolvidos para complementar este

documento.



Conteúdo

1 Introdução: software público, qualidade e teste ............................................................. 4

2 Teste de software: objetivo, custos e benefícios ............................................................. 5

3 O sucesso no teste: provocar falhas que mostrem defeitos ............................................ 8

4 Níveis e ciclos do teste: quando testar .......................................................................... 11

5 Tipos de teste: o que testar ........................................................................................... 13

6 Técnicas e critérios de teste: como testar ..................................................................... 15

6.1 Critérios da técnica funcional ................................................................................... 17

6.2 Critérios da técnica estrutural .................................................................................. 21

7 Ferramentas de apoio ao teste ...................................................................................... 24

8 Processo e documentação do teste: como organizar o trabalho .................................. 26

9 Análise de riscos: priorizar aspectos para o teste .......................................................... 28

10 Política e processo de teste: o papel do teste na estratégia da organização ................ 29

11 Conclusão: transformando conceitos de teste em melhores produtos de software .... 31



1 Introdução: software público, qualidade e teste

O amadurecimento da indústria de software no Brasil traz consigo um aumento da

competitividade entre as empresas brasileiras desenvolvedoras e também destas com

empresas de outros países. Neste contexto, a promoção da qualidade de produtos de

software é um fator crítico de sucesso. Também de suma importância é o aprimoramento

dos processos de engenharia e de gestão no desenvolvimento de software, visando permitir

projetos bem sucedidos, com menores custos e respeitando os limites de prazo.

O Software Público Brasileiro (SPB) adota um modelo de desenvolvimento de

software caracterizado pelo compartilhamento de produtos de software, assim como dos

artefatos e serviços a eles relacionados. A existência de um alto nível de qualidade do

software, artefatos e serviços compartilhados seguramente tem uma influência positiva para

o sucesso deste modelo. Deste modo, a adoção de práticas visando avaliar e aprimorar a

qualidade deve ser estimulada no contexto do SPB.

O desenvolvimento de software não é uma tarefa fácil 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 técnicas e ferramentas adequadas, erros durante o desenvolvimento

acontecem e resultam em deficiências no software. A atividade de teste visa identificar

estas deficiências, permitindo assim o aprimoramento dos produtos de software.

O restante do documento está organizado do seguinte modo. A Seção 2 aborda a

necessidade do teste e os impactos negativos de um teste inadequado; a Seção 3 define

alguns conceitos fundamentais; a Seção 4 mostra como o esforço de teste pode ser realizado

em etapas e ciclos; a Seção 5 apresenta alguns tipos de teste existentes; a Seção 6 descreve

as principais técnicas e critérios para seleção e avaliação de testes; a Seção 7 cita alguns

tipos de ferramentas que podem apoiar esta atividade, enquanto a Seção 8 descreve as

atividades principais e as informações envolvidas em um processo de teste; a Seção 9

sumariza como a análise de riscos pode ser considerada no teste; a Seção 10 aborda como

situar estrategicamente o teste em relação aos objetivos da organização. Finalmente, tem-se

a conclusão na Seção 11.



2 Teste de software: objetivo, custos e benefícios

Existem diversas definições 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 requeridos”1;

• “Teste é o processo de executar um programa com a intenção de encontrar

defeitos”2;

• “Teste é o processo pelo qual se explora e se entende o estado dos benefícios e

riscos associados com a versão de um sistema de software”3.

Todas essas definições são válidas e destacam algum aspecto importante da atividade

de teste. De maneira simplificada podemos entender o teste de software como: “a execução

do software de uma forma controlada com o objetivo de avaliar se o software se comporta

ou não conforme especificado”.

Trata-se, portanto, de uma atividade fundamental para avaliar se o software produzido

atende aos requisitos levantados com os usuários. No entanto, teste não exclui a realização

de outras atividades como as inspeções efetuadas nos artefatos produzidos ao longo do

processo de software.

Uma questão essencial é: “por que existe a necessidade de se testar software?” Uma

resposta (provocativa) a esta pergunta tem a forma de outra questão: “você se sentiria

confortável em ser o passageiro de um vôo em uma aeronave que nunca decolou antes?”

O processo de projeto e construção de aeronaves envolve uma série de atividades de

teste da aeronave como um todo e de seus componentes principais (asas, turbinas, sistemas

eletrônicos, sistemas mecânicos). Essas atividades visam a confirmar as teorias

consideradas no projeto, obter dados empíricos e avaliar os aspectos não embasados por

teorias, avaliar a conformidade com padrões de segurança e de desempenho de vôo, além

de vários outros pontos. Os testes são aplicados em componentes, em subsistemas, e na

aeronave inteira, incluindo o teste em condições reais de vôo. Esta questão é obviamente 1 Hetzel, B. 1988, “The Complete Guide to Software Testing (2nd Ed.)”. QED Information Sciences, Inc.

2 Myers, G.J., 1979, “The Art of Software Testing”, Addison-Wesley, New York. 3 Cem Kaner, James Bach e Bret Pettichord, “Lessons Learned in Software Testing: A Context-Driven

Approach”, Willey Computer Publishing, 2002.



um exagero proposital; uma aeronave não testada nunca seria liberada para um vôo

comercial.

Analogamente, um software não deve ser liberado para uso sem que atividades

adequadas de teste tenham sido realizadas. Por meio do teste diversas deficiências

existentes no software, relacionadas a problemas de funcionalidade, desempenho,

segurança, instalação e utilização podem ser encontradas e removidas, antes que o software

“entre em vôo”, isto é, seja implantado para o uso dos clientes.

Enfim, testa-se software porque o desenvolvimento de sistemas envolve uma série de

atividades em que as possibilidades de ocorrência de erros humanos são inúmeras. Erros

podem ocorrer logo no início do processo de criação do software, quando objetivos

definidos podem estar incorretos ou incompletos. Além disso, erros podem ocorrer nas

demais fases do desenvolvimento, como projeto, codificação e integração do software.

Essencialmente erros ocorrem pela dificuldade dos seres humanos de executar tarefas e se

comunicar com perfeição. Esses são os mesmos motivos que justificam o teste rigoroso em

aeronaves.

O teste de software não é uma atividade tecnicamente fácil 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 ausência de uma atividade de teste bem

realizada acarreta um custo total significativamente maior.

O retrabalho devido à manutenção corretiva de problemas de especificação, projeto e

programação é uma realidade amplamente conhecida. Estatísticas apresentadas mostram

ainda que cada R$ 1,00 investido em prevenção de defeitos diminui de R$ 3,00 a R$ 10,00

os custos de manutenção corretiva. E cada R$ 1,00 investido em remoção de defeitos

diminui de R$ 2,00 a R$ 5,00 os custos de manutenção corretiva.

Um estudo do NIST (Instituto Nacional de Padrões e Tecnologia, órgão do

Departamento de Comércio dos Estados Unidos) aponta impactos negativos de

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



inadequações nas atividades de teste5. Dentre os problemas acarretados pelo teste

inadequado podem-se destacar:

• Crescimento do número de falhas em uso devido à má qualidade do software,

acarretando perdas na reputação da organização e no potencial de negócios futuros;

• Aumento no custo de desenvolvimento de software, visto que o custo da correção de

problemas no software cresce ao longo dos estágios do desenvolvimento, tendo seu

maior valor quando é necessário corrigir problemas em um software já implantado

no cliente;

• Atraso para disponibilizar o produto ao mercado devido à ausência de processos e

técnicas de teste padronizadas e a conseqüente necessidade de criar às pressas uma

infra-estrutura de teste.

Esta lista de problemas é mais extensa, e apresenta problemas potencialmente

dramáticos, 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 informações de alto valor,

como dados estratégicos de empresas e informações bancárias, também pode acarretar

grandes danos financeiros e de imagem às organizações.

No contexto do SPB as deficiências no teste de um produto de software podem

acarretar uma perda de reputação deste software entre os seus possíveis usuários, limitando

consequentemente os potenciais benefícios trazidos pelo software.

Raymond define o “modelo bazar” de desenvolvimento no qual o código 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 código

fonte estiver disponível para o teste, exame e experimentação, mais rapidamente os “bugs”

5 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 6 Eric S. Raymond, “The Cathedral & the Bazaar, Musings on Linux and Open Source by an Accidental

Revolutionary,” Fevereiro, 2001, O´Reilly & Associates, Inc.



serão 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 código fonte e de outros artefatos de

software, é razoável esperar que as práticas de teste possam ser conduzidas de forma

eficiente, aproveitando a característica colaborativa do ambiente e o espírito engajado e

investigativo de muitos membros de comunidades. A utilização de boas práticas de teste

neste contexto tem o potencial de aumentar a qualidade dos produtos de software e os

benefícios do SPB à sociedade.

3 O sucesso no teste: provocar falhas que mostrem defeitos

O teste de software pode também ser definido como “a execução de

um software com o objetivo de encontrar defeitos”. Neste caso, fica

explícita a idéia de que o teste deve exercitar o software de uma

maneira tal que este falhe, permitindo assim a posterior identificação

e remoção da causa desta falha.

Deve-se ter em mente que um defeito (fault ou defect em inglês) é uma anomalia no

software que pode causar uma falha (exemplos: um comando imperfeito, incompleto,

ausente ou extra no software). Uma falha (failure) é a ocorrência de uma discrepância entre

o resultado observado da execução do software e o resultado prescrito pelos requisitos. Um

erro (error) é um estado incorreto, intermediário ou final, de execução 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 não descoberto em atividades de inspeção.

Por exemplo: o foguete Ariane V explodiu em 1996, cerca de 40 segundos após ter

decolado 8. O foguete saiu de sua rota programada e se desintegrou devido a forças

aerodinâmicas. Em uma análise posterior do incidente, verificou-se que o software de

controle do vôo indicou uma direção errada ao foguete (esta foi a falha) devido a uma

7 “se os olhos forem suficientes, todos os bugs serão vistos” em uma tradução livre. Ou: “... dados grupos grandes o suficiente de testadores-beta e de desenvolvedores, quase todos os problemas serão identificados rapidamente e o conserto será óbvio para alguém...”. 8 ARIANE 5 Flight 501 Failure Report by the Inquiry Board, Julho, 1996.

Centro de Tecnologia da Informação Renato Archer


conversão incorreta de uma variável

defeito).

Esta conversão produziu um

erro de overflow, isto é, um valor

errôneo de uma variável (este foi o

erro), que ocasionou a resposta

incorreta do software. O engano foi,

provavelmente, cometido por um

programador, que inseriu no

software um comando de atribuição

indevido.

Portanto, para um defei

de uma forma tal que o defeito seja “sensibilizado”

quando o comando defeituoso é executado e cria um

as variáveis internas, por exemplo)

erro seja propagado, ao longo da execução, do ponto onde foi criado

defeituoso) para alguma saída do software, ocasionando uma resposta final incorreta

(valores incorretos para alguma saída 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.

Figura 1: C

Em uma visão simplificada, a realização do teste

a. Selecionar valores para as

teste (chamados de Dad

partir do conjunto de todos os possíveis valores que podem ser usados para executar

o software, chamado de


ftware: Motivação e Conceitos Básicos

variável tipo real de 64 bits em um inteiro de 16 bits

produziu um

um valor

(este foi o

resposta

O engano foi,

provavelmente, cometido por um

programador, que inseriu no

software um comando de atribuição

efeito ser descoberto é necessário que o software seja executado

de uma forma tal que o defeito seja “sensibilizado” e provoque uma falha

quando o comando defeituoso é executado e cria um estado de erro (valores incorretos para

ternas, por exemplo). Para que a falha aconteça, é necessário

ao longo da execução, do ponto onde foi criado (logo após o comando

para alguma saída do software, ocasionando uma resposta final incorreta

(valores incorretos para alguma saída produzida, por exemplo).


resultar em uma falha do software.

Figura 1: Cadeia de Eventos Para a Falha do Software

Em uma visão simplificada, a realização do teste envolve:

valores para as Variáveis de Entrada a serem submetidos ao software em

ados de Entrada ou de Dados de Teste); esta seleção é feita a


o software, chamado de Domínio de Entrada do software.

Página 9

tipo real de 64 bits em um inteiro de 16 bits (este foi o

seja executado

e provoque uma falha. Isto ocorre

estado de erro (valores incorretos para

é necessário ainda que este

(logo após o comando

para alguma saída do software, ocasionando uma resposta final incorreta


a serem submetidos ao software em

esta seleção é feita a




b. Executar o software com os dados de teste

variáveis de entrada e acionar alguma função no software

c. Avaliar se a saída produzida corresponde à

do software, isto é, se o comportamento e os valores produzidos como resultado da

execução foram os corretos

Um par dados de entrada

de Teste. Uma coleção de vários

Teste.

Para a realização do teste, presume

permita avaliar se certo resultado

acordo com a especificação (ou

Esta avaliação é feita por meio de um

papel de oráculo e realiza a comparação “esperado versus obtido”

software falhou ou não.

A Figura 2 apresenta uma visão simplificada do teste:

de entrada e a avaliação da saída produzida pelo programa

esperados.

Uma limitação inerente à atividade de teste é

software está correto. O teste pode revelar a

ausência desses defeitos. Portanto, por mais rigoroso que seja o teste, não é possível

assegurar que não permaneceram no software defeitos “escondidos”



com os dados de teste, ou seja, informar os valores para

entrada e acionar alguma função no software; e

se a saída produzida corresponde à saída esperada segundo a especificação

, isto é, se o comportamento e os valores produzidos como resultado da

corretos.

entrada e resultados esperados associados é chamado de um

de vários casos de teste é referida como um Conjunto

Para a realização do teste, presume-se a existência de algum meio ou dispositivo que

resultado - ou comportamento - produzido pelo software está de

acordo com a especificação (ou seja, se é o resultado esperado de um software correto).

é feita por meio de um oráculo. Normalmente o executor do teste assume o

realiza a comparação “esperado versus obtido”, identifica

apresenta uma visão simplificada do teste: a execução do programa com dados

de entrada e a avaliação da saída produzida pelo programa em relação aos resultados

Figura 2: Visão Simplificada do Teste

inerente à atividade de teste é sua impossibilidade de provar que um

. O teste pode revelar a presença de defeitos no software, mas não a

Portanto, por mais rigoroso que seja o teste, não é possível

que não permaneceram no software defeitos “escondidos”, não encontrados

Página 10

, ou seja, informar os valores para as

esperada segundo a especificação

, isto é, se o comportamento e os valores produzidos como resultado da

hamado de um Caso

onjunto de Casos de

se a existência de algum meio ou dispositivo que

produzido pelo software está de

o resultado esperado de um software correto).

Normalmente o executor do teste assume o

identificando se o

a execução do programa com dados

em relação aos resultados

provar que um

no software, mas não a

Portanto, por mais rigoroso que seja o teste, não é possível

não encontrados



durante o teste. No entanto, o teste pode dar subsídios para que se avalie o quão confiável

(ou não) é o software.

4 Níveis e ciclos do teste: quando testar

O teste de software é normalmente realizado em uma série de fases, ou níveis:

• Teste de Unidade;

• Teste de Integração;

• Teste de Sistema; e

• Teste de Aceitação.

Após o desenvolvimento de cada unidade do software (procedimento, função, método

ou classe) é realizado o teste de unidade (ou teste unitário), que visa a identificar defeitos

introduzidos nos algoritmos e estruturas de dados dessas unidades. Em geral, o teste de

unidade é feito pelo próprio desenvolvedor da unidade. As unidades são então

incrementalmente integradas e testadas (teste de integração). 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 nível de teste cujos requisitos são derivados da especificação de

requisitos funcionais e não funcionais, e é aplicado para verificar se o software e o

hardware executam corretamente ou não quando integrados ao ambiente de operação. O

teste de aceitação é então conduzido para estabelecer se o sistema satisfaz ou não os

critérios de aceitação definidos com o cliente.

Deve-se notar que em cada um desses níveis (unidade, integração, sistema e

aceitação) 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 são executados. Falhas

provocadas por casos de teste devem ser registradas para posterior depuração do software

(localização e remoção dos defeitos) pela equipe de desenvolvimento. No próximo ciclo,

casos de teste devem ser re-executados para avaliar se os defeitos que ocasionaram as

falhas foram realmente removidos e se as alterações no software não introduziram

inadvertidamente outros defeitos. Pode ocorrer também a necessidade de se retornar a um

nível de teste anterior. Por exemplo: durante o teste de integração podem ser identificados



problemas que requeiram muitas alterações em

pode ser adequado, além de re

novamente o teste de unidade

O teste de um software já testado previamente

Teste de Regressão. Este teste busca verificar se as modificações efetuadas não

introduziram novos defeitos ou ativaram defeitos em partes inalteradas do código; visa

também avaliar se o software ainda satisfaz os seus r

tipicamente realizado na fase de manutenção, após a realização de mudanças no software

ou no seu ambiente. Conforme descrito no parágrafo anterior, este teste também pode

ocorrer ao longo do desenvolvimento do software.

A Figura 3 ilustra um processo

sequencialmente: teste de unidade

níveis são mostrados os ciclos

execução de casos de teste. A figura mostra

de teste.



as que requeiram muitas alterações em algum módulo do software. Neste caso,

pode ser adequado, além de re-executar casos de teste de integração, também realizar

novamente o teste de unidade do módulo alterado.

O teste de um software já testado previamente e que sofreu mudanças é chamado de

. Este teste busca verificar se as modificações efetuadas não


também avaliar se o software ainda satisfaz os seus requisitos. O teste de regressão é



ocorrer ao longo do desenvolvimento do software.

A Figura 3 ilustra um processo em que os níveis de teste são executados

quencialmente: teste de unidade, de integração, de sistema e de aceitação.

níveis são mostrados os ciclos que envolvem alterações do software (ou depuração

ão de casos de teste. A figura mostra também o fluxo de retorno a níveis anteriores

Figura 3: Níveis e Ciclos de Teste

Página 12

do software. Neste caso,

executar casos de teste de integração, também realizar

e que sofreu mudanças é chamado de

. Este teste busca verificar se as modificações efetuadas não


equisitos. O teste de regressão é



os níveis de teste são executados

de sistema e de aceitação. Em todos os

depuração) e a re-

também o fluxo de retorno a níveis anteriores



É importante destacar que não é obrigatório que todos os níveis de teste ocorram para

que se tenha um teste adequado. A necessidade ou não de realizar cada um desses níveis

deve ser decidida a partir da análise da situação específica, conforme descrito nas seções

sobre processos de teste (Seções 8 e 10).

5 Tipos de teste: o que testar

Diversos atributos de qualidade do software podem ser avaliados por meio de testes.

Características de qualidade de software definidas em padrões como a ISO/IEC 9126 9

podem servir como base para a definição de aspectos do software a serem avaliados por

meio da realização de testes. Portanto, existem diversos tipos de teste; cada tipo visa à

avaliação de um aspecto distinto do software e pode ser aplicado em um ou mais níveis de

teste (unidade, integração, etc.).

O teste de funcionalidade busca avaliar se o software apresenta um conjunto de funções

que satisfaça ou não às necessidades levantadas (associadas aos requisitos definidos).

O teste de desempenho visa a avaliar se o

software executa as funções previstas satisfazendo ou

não os requisitos de desempenho definidos (e.g.,

velocidade de processamento, tempo de resposta, uso

de memória).

O teste de interoperabilidade avalia a capacidade do

software em interagir com um ou mais componentes ou

sistemas.

O teste de segurança (security) visa a avaliar a habilidade

do software de impedir o acesso não autorizado – acidental ou

deliberado – ao software ou a dados.

O teste de sanidade (smoke test) envolve a execução de um subconjunto dos testes

projetados que cobrem algumas funcionalidades principais; pode ser realizado

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



periodicamente, ou como uma atividade inicial para avaliar se o software está pronto para

um esforço maior de teste.

O teste de estresse simula condições atípicas de utilização do software, provocando

aumentos e reduções sucessivas de transações que superem os volumes máximos previstos

para a capacidade de processamento dos componentes ou do sistema.

O teste de usabilidade visa a determinar quão

facilmente o produto de software é compreendido,

apreendido e usado, e quão agradável ele é ao usuário.

O teste de portabilidade busca avaliar o nível de

facilidade de transferência 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 nível de

carga o sistema pode tratar; por exemplo, número de

usuários ou número de transações.

O teste de instalação busca avaliar se o software é instalado e desinstalado com sucesso

ou não em determinado ambiente operacional.

O teste de recuperação determina a capacidade ou incapacidade de um produto de

software de restabelecer condições normais de operação e de recuperar dados afetados, em

caso de falha.

A determinação de quais tipos de teste devem ser utilizados e em qual (quais) nível

(níveis) eles devem ser aplicados, ocorre durante a fase de planejamento do teste. Esta

definição é feita considerando-se as informações disponíveis sobre a natureza do software

em teste e dos requisitos específicos dos módulos que compõem o software.

Na maior parte das situações é adequado focar atenção no teste de funcionalidade para

avaliar os se os requisitos funcionais do software são satisfeitos ou não. Este teste deve ser

complementado por outros tipos de teste (carga, desempenho, etc) para avaliar se os

requisitos não funcionais do software são satisfeitos ou não.



6 Técnicas e critérios de teste: como testar

Esta seção apresenta algumas Técnicas e Critérios de Teste úteis para a seleção de bons

casos de teste. É importante ressalvar que existem outras técnicas não relatadas aqui;

procurou-se destacar as técnicas mais usadas na prática ou mais consolidadas na literatura.

Como este documento apresenta apenas uma visão inicial sobre técnicas e critérios, é

recomendada a consulta a tutoriais específicos e de literatura especializada para maiores

informações.

Uma tarefa fundamental na atividade de teste é a seleção dos casos de teste a serem

utilizados. Esta seleção é necessária porque o Teste Exaustivo, feito com todas as possíveis

combinações de valores de entrada, é quase sempre inviável. Por exemplo, considere um

software que tenha como entrada 15 variáveis, sendo que cada uma delas pode assumir 7

valores diferentes. Considere ainda que a execução de cada caso de teste demore 1/100 de

segundo (0,01 segundo). Para realizar o teste exaustivo deste software seriam necessários

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 restrição de que os

cronogramas e orçamentos sejam cumpridos, é aconselhável a utilização de Técnicas de

Teste. Estas técnicas estabelecem procedimentos para selecionar - ou criar - os casos de

teste que resultem em um conjunto de teste eficaz e de tamanho moderado. As técnicas de

teste determinam a natureza da informação a ser utilizada para se fazer a seleção ou a

avaliação de conjuntos de teste. Na técnica de Teste Funcional os casos de teste são

selecionados por meio da análise da especificação do software, ou utilizando modelos

criados na fase de análise e projeto do software. Na técnica de Teste Estrutural os casos de

teste são selecionados por meio da análise da estrutura interna do software. Na técnica de

teste Baseada em Defeitos, casos de teste são selecionados a partir de classes de defeitos

que podem ser introduzidos ao longo do desenvolvimento do software. A Figura 4 ilustra

as técnicas funcional e estrutural de teste.



As diversas técnicas de teste não são excludentes;

técnicas é recomendada, pois os defeitos revelados pela aplicação de

ser diferentes.

A utilização de uma técnica de teste ocorre por meio da aplicação

de Teste. Um critério de teste determina um conjunto de

que devem ser exercitados pela realização do teste.

comandos - ou todos os nós

requeridos os comandos do código do software

deve ser executado (ou exercitado), pelo menos uma vez, por algum dado de teste.

A Cobertura do Teste,

percentual de elementos requeridos exercitados por um conjunto de casos

executados. Por exemplo, o percentual de comandos executados durante o teste seria uma

medida de cobertura considerando

medida de cobertura quantifica, sob certa perspectiva, a qualidade do teste realizado.

razoável supor, neste exemplo, que um conjunto de teste que executa 90% dos comandos de

um software é melhor do que outro conjunto de teste

10 O teste caixa preta inclui outras técnicas além da técnica funcional, única que está sendo considerada neste documento.



Figura 4: Técnicas de Teste 10

as de teste não são excludentes; na verdade, a utilização de várias

ada, pois os defeitos revelados pela aplicação de cada uma delas podem

A utilização de uma técnica de teste ocorre por meio da aplicação de algum

Um critério de teste determina um conjunto de Elementos Requeridos

que devem ser exercitados pela realização do teste. Por exemplo, o critério

ou todos os nós - da técnica estrutural de teste define como elementos

o código do software. Neste caso, cada comando do so


este, com respeito a um critério de teste específico, mede

percentual de elementos requeridos exercitados por um conjunto de casos

. Por exemplo, o percentual de comandos executados durante o teste seria uma

medida de cobertura considerando-se o critério de teste do exemplo anterior. Deste modo, a

medida de cobertura quantifica, sob certa perspectiva, a qualidade do teste realizado.


do que outro conjunto de teste que executa apenas 50% dos

O teste caixa preta inclui outras técnicas além da técnica funcional, única que está sendo considerada neste

Página 16

a utilização de várias

cada uma delas podem

algum Critério

equeridos do software

critério todos os

de teste define como elementos

. Neste caso, cada comando do software


com respeito a um critério de teste específico, mede o

percentual de elementos requeridos exercitados por um conjunto de casos de teste

. Por exemplo, o percentual de comandos executados durante o teste seria uma

se o critério de teste do exemplo anterior. Deste modo, a

medida de cobertura quantifica, sob certa perspectiva, a qualidade do teste realizado. É


que executa apenas 50% dos

O teste caixa preta inclui outras técnicas além da técnica funcional, única que está sendo considerada neste



comandos. Se um conjunto de casos de teste exercita todos os elementos requeridos pelo

critério, diz-se que tal conjunto satisfaz o critério.

Em geral, os critérios 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

condição para a finalização do teste.

A seguir é feita uma breve descrição de alguns critérios de teste da técnica funcional e

da técnica estrutural, as mais usadas na prática.

6.1 Critérios da técnica funcional

Os critérios da técnica de teste funcional caracterizam-se por utilizar informações

originadas da especificação do software como base para a seleção de casos de teste.

Artefatos criados na fase de análise de requisitos e de projeto do software, tais como o

documento de requisitos do software ou modelos como diagramas UML, são utilizados

para criar os casos de teste.

A idéia essencial da técnica funcional é selecionar dados de teste representativos o

suficiente para avaliar se as funcionalidades definidas na especificação do software foram

implementadas corretamente ou não. Para tanto, operações associadas às funcionalidades

são identificadas e dados de teste que as exercitem são definidos e executados.

O critério Particionamento de Equivalência divide o domínio de entrada do software

em classes de equivalência e requer que pelo menos um dado de teste de cada classe seja

selecionado e executado. Essas classes são definidas pressupondo que todo dado de entrada

pertencente a uma classe é tratado do mesmo modo, de acordo com a especificação do

software. Portanto, cada dado de teste selecionado representa os demais dados de testes da

sua classe de equivalência.

Por exemplo, se a especificação define que um software recebe como entrada uma

variável idade, tipo inteiro, que pode variar de 0 a 120 anos (incluindo os extremos),

poderiam ser identificadas as seguintes classes de equivalência:

• Classe 1: idade menor que zero – referida como classe de valores inválidos;

• Classe 2: idade entre 0 e 120 – classe de valores válidos; e,

• Classe 3: idade maior que 120 – outra classe de valores inválidos.



Ao se executar o software com dados de teste que pertençam às Classes 1 e 3 espera-se que

os valores fornecidos sejam identificados como não aceitáveis e sejam emitidas mensagens

apropriadas. Ao se executar o software com um dado de teste que pertença à Classe 2 o

valor fornecido deve ser aceito e uma saída apropriada deve ser produzida.

A Figura 5 ilustra as classes de equivalência do exemplo e os dados de teste selecionados

para exercitar cada classe.

Figura 5: Classes de Equivalência e Dados de Teste

Dependendo da especificação, 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 divisão faz sentido e deve ser feita se a especificação do software

definir tratamentos distintos para estas diferentes faixas de valores. Neste caso a Classe 2

não é homogênea e, portanto, a execução de apenas um caso de tese da classe seria

insuficiente.

Deve-se notar que o modo como as classes de equivalência são definidas influencia

fortemente a eficácia do critério. Esta definição deve ser feita de forma cuidadosa,

analisando-se a natureza de cada variável de entrada do programa e a especificação do

software em teste.

O critério Análise de Valores Limite complementa o critério Particionamento de

Equivalência. Freqüentemente as situações de transição de comportamento do software de

uma classe para outra classe, as situações limite, são implementadas de forma incorreta.

Estas situações costumam ser inerentemente complexas e acabam induzindo a erros de

análise, projeto ou codificação.

Para descobrir defeitos associados a estas situações é recomendada a seleção de dados

de teste situados nos limites das classes. No exemplo anterior (variável idade, tipo inteiro,

Classe 2 (valores válidos)

Classe 3 (valores inválidos)


-39 0 45 120 135



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 são selecionados valores

exatamente no limite, valores imediatamente inferiores e imediatamente superiores ao

limite. A definição dos valores limite também deve ser feita cuidadosamente, analisando-se

a natureza de cada variável de entrada do programa e a especificação do software em teste.

Figura 6: Valores Limite e Dados de Teste

Teste baseado em modelos

Alguns critérios caracterizam-se por utilizar modelos do software (representações

intermediárias do software) como base para a seleção de dados de teste. Esses critérios são

freqüentemente chamados de Teste Baseado em Modelos (Model Based Testing). Modelos

como Máquinas 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 propósito.

O Teste Baseado em Casos de Uso utiliza os modelos de Casos de Uso (representação

definida na UML), criados na fase de análise de requisitos e de projeto do software, para a

seleção de casos de teste. Casos de Uso são muito usados para especificar o comportamento

esperado do sistema do ponto de vista dos atores que interagem com o sistema. Como são

elaborados normalmente em etapas iniciais do processo de desenvolvimento, esses modelos

são úteis para o projeto antecipado de casos de teste, principalmente os que serão aplicados

nos testes de sistema e de aceitação do software.

A aplicação do critério de teste é feita nos seguintes passos:


Classe 2 (valores válidos)


-1 0 1 119 120 121



a. Descrever os fluxos de eventos para o caso de uso. Devem ser descritos tanto o

fluxo de eventos básico como os fluxos alternativos e de exceção.

b. Definir o conjunto de cenários que serão usados nos testes. Cada cenário pode ser

formado a partir dos fluxos de eventos identificados bem como das combinações

desses fluxos.

c. Definir casos de teste para cada um dos cenários, ou seja, para cada cenário definir

valores de entrada, ações no software que provoquem a execução do cenário e as

saídas 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 especificação dos casos

de uso esteja pronta e revisada; não é necessário esperar a conclusão da implementação dos

casos de uso para realizá-los. O passo d pode ser realizado em momentos distintos,

dependendo do nível do teste realizado: quando os módulos que implementam as funções

especificadas nos casos de uso estiverem disponíveis (no caso do teste de “partes” do

sistema); quando o sistema como um todo estiver integrado e disponível (no caso do teste

de sistema); ou ainda, quando o sistema for utilizado no processo de aceitação pelo cliente

(no caso do teste de aceitação).

Naturalmente, outros modelos (da UML ou de outras linguagens) podem ser

utilizados de forma semelhante para a seleção de casos de teste. Por exemplo, Diagramas

de Estados (com os Statecharts) podem servir como base para a seleção de casos de teste

que exercitem transições de estado que podem ocorrer em um objeto. Critérios de teste

baseados em modelos de estados são úteis para aplicações nas quais muitas transições

complexas de estado dos objetos são possíveis, tais como sistemas de controle de processos

e sistemas de telefonia.

Diagramas de Colaboração, que descrevem a interação entre objetos para especificar

um comportamento, também podem ser utilizados para seleção de casos de teste. Critérios

de teste baseados em Diagramas de Colaboração permitem avaliar interações específicas

entre objetos, formadas por seqüências de comunicações. Os casos de teste visam a



exercitar e avaliar se as trocas de mensagens, que caracterizam a colaboração de um

conjunto de objetos, permitem atingir os propósitos definidos na especificação do sistema.

6.2 Critérios da técnica estrutural

Na técnica de Teste Estrutural os dados de teste são selecionados por meio da análise da

estrutura interna do software. Portanto, o código fonte do software deve estar disponível,

pois ele é utilizado para a seleção dos dados de teste. A motivação para o uso desses

critérios muitas vezes é feita com questionamentos do tipo: “você confiaria em um software

se fosse informado que algumas instruções deste software nunca foram executadas antes?”

Esta pergunta enfatiza que defeitos em trechos não exercitados do código fonte do software

certamente não serão descobertos.

Na Técnica Estrutural uma unidade de software (função, procedimento ou método) é

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 (instruções 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 nós

– correspondem a blocos de comandos que são sempre executados conjuntamente -, e

ramos, que correspondem a possíveis desvios no fluxo de execução. O GFC possui um

único nó de entrada, um único nó de saída, e define um conjunto de caminhos que podem

ser executados do nó de entrada ao nó de saída, passando por certos comandos e desvios ao

longo da execução. Quando se executa o software com um dado de teste, algum caminho

específico será executado no programa (isto só não ocorre caso o software entre em um

laço infinito).

A Figura 7 mostra um código fonte em C (identifier.c) e o respectivo GFC 11. Notar

que o código fonte apresenta no lado esquerdo como comentários o número do nó do GFC

ao qual o comando pertence. É possível identificar conjuntos de comandos executados

sempre conjuntamente, por exemplo, os comandos precedidos por /* 01 */ que pertencem

ao nó 1 do GFC. Pode-se também observar o efeito de comandos de desvio no fluxo de

11 Código fonte e GFC presentes em: Barbosa E., Maldonado, J., Vincenzi, A., Delamaro, M., Souza, S., Jino, M. “Introdução ao Teste de Software”, XIV Simpósio Brasileiro de Engenharia de Software”, 2000.



controle, por exemplo, o comando while presente no nó 4 do grafo, ou o comando if-then-

else iniciado no nó 8.

Figura 7: Código Fonte e Respectivo Grafo de Fluxo de Controle

Critérios de teste estrutural estabelecem componentes internos do software como

elementos requeridos. O critério de teste Todos os Comandos (ou Todos os Nós) requer que

cada comando do software seja exercitado pelo menos uma vez durante o teste. A

determinação de dados de teste que exercitem um comando específico requer a análise do

código fonte do software e a escolha de valores para as variáveis de entrada que provoquem

a execução do comando.

Por exemplo, a Figura 8 mostra um trecho de programa no qual há um comando de

decisão if-then-else e o respectivo GFC. Para que os comandos representados por B sejam

executados é necessária a seleção de valores de entrada tais que a condição lógica do

comando if seja satisfeita; por exemplo, valores de entrada que façam com que x tenha

valor 100 e y tenha valor 30 imediatamente antes do comando if (notar que x e y podem ser

variáveis de entrada, mas também podem ser computadas internamente, a partir de outras

variáveis). Outros dados de teste serão necessários para exercitar os comandos

/* 01 */ { /* 01 */ char achar; /* 01 */ int length, valid_id; /* 01 */ length = 0; /* 01 */ printf (“Digite um possível 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 */ }



representados por C; por exemplo, dados que resultem nos valores x = 20 e y = 15 antes do

comando if.

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

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

O critério Todos os Ramos requer que cada possível transferência 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 condição do if, exercitam

os comandos representados em B e também os em C. Este critério, no entanto (ao contrário

do anterior), requer a execução de dados de teste adicionais, que provoquem a transferência

de controle (ou ramo) do comando if diretamente para os comandos em C (sem passar por

B).

O critério Todos os Caminhos requer que cada diferente caminho no GFC seja

executado pelo menos uma vez. Este critério é geralmente considerado excessivamente

exigente visto que, em programas reais, a sua aplicação tende a gerar conjuntos muito

grandes de elementos requeridos. Considere a Figura 10 que mostra um trecho de código

com dois comandos if-then-else em sequência e o respectivo GFC; note que o segundo

comando if pertence ao nó D no grafo. A execução de apenas dois casos de teste é

suficiente para exercitar todos os nós e também todos os arcos do GFC; por exemplo,

utilizando um caso de teste que exercite a seqüência ABDEG e outro que exercite a

A …;

A if (x > y * 2)

B { … }

C else

C { … }

D …;

A

B C

D

A …;

A If (x > y * 2)

B { … }

C …;

A

B

C



seqüência ACDFG. No entanto, para satisfazer o critério todos os caminhos são necessários

quatro casos de teste, cada um exercitando um caminho do GFC: ABDEG, ABDFG,

ACDEG e ACDFG.

Figura 10: Comandos if-then em Sequência e Respectivo Grafo de Fluxo de Controle

Existem outros critérios estruturais que não serão abordados neste documento. Mais

informações sobre os critérios apresentados e sobre como utilizá-los encontram-se em

tutoriais específicos e em literatura especializada.

7 Ferramentas de apoio ao teste

As empresas de software são cada vez mais pressionadas a produzir produtos de qualidade

em curto espaço de tempo. Esta situação coloca uma forte pressão em suas equipes de teste,

que são 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 esforço e aprimorar a qualidade

do teste. Estas ferramentas não são suficientes para automatizar completamente o teste, mas

podem auxiliar o testador na realização de diversas atividades.

São exemplos de atividades de teste para as quais se encontram ferramentas de apoio:

• Definição dos elementos requeridos para o teste: para as diversas técnicas são

determinados elementos requeridos que podem servir de base para a criação de

casos de teste;

A …;

A if (x > y * 2)

B { … }

C else

C { … }

D if (z > w)

E { … }

F else

F { … }

G …;

A

B C

D

E F

G



• Avaliação de cobertura atingida no teste e a identificação de elementos requeridos

não exercitados: para as diversas técnicas são avaliados o nível de cobertura

atingido (percentual de elementos requeridos exercitados) e os elementos requeridos

ainda não exercitados. As ferramentas permitem quantificar a qualidade do teste;

• Captura de eventos e de respostas do

software: gravação e reprodução de

informações do teste, tais como: dados de

entrada, eventos de entrada, interfaces e

informações mostradas;

• Execução do teste: execução do software

com um conjunto de casos de teste e a

avaliação do resultado produzido.

Ferramentas podem ser aplicadas tanto para

o teste de unidade como para o teste de

sistema;

• Armazenamento e gerenciamento de informações de teste: manutenção de

informações de teste – planos, projetos, scritps e casos de teste. Ferramentas

permitem também o rastreamento de informações associando casos de teste aos

requisitos do software a serem validados;

• Armazenamento e gerenciamento de incidentes: registro de informações sobre

incidentes ocorridos e acompanhamento da resolução;

• Definição e gerenciamento do processo de teste: definição de aspectos do processo

de teste como recursos, medidas, atividades e tarefas, e também o gerenciamento da

execução do processo de teste.

A adoção de um processo de teste para a organização (veja próximas seções) pode

incluir a avaliação de quais tipos de ferramentas são adequadas aos objetivos estabelecidos

para o teste.



8 Processo e documentação do teste: como organizar o trabalho

A adoção 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, constituídos por atividades,

métodos, práticas e transformações, usado para atingir uma meta. A atividade de teste de

software também deve ser conduzida por meio de um processo bem estabelecido. Um

processo de teste de software é um conjunto de passos parcialmente ordenados constituídos

por atividades, métodos e práticas, 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 contém, dentre

outras informações: extensão e abordagem do teste; recursos necessários, equipe e

treinamento, cronograma de atividades; ambiente operacional; itens a serem testados, o

nível e abordagem de teste para cada item, atividades, tarefas e respectivos responsáveis,

além de riscos e planos de contingência 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 contingências no teste.

O subprocesso Registrar visa relatar a execução dos testes e os incidentes observados

(defeito no software ou anomalia de funcionamento do ambiente). Também são

sumarizados os resultados do teste e as avaliações 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 Simpósio 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.



É 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 definição de como esta informação de teste deve ser

estruturada em artefatos (isto é, a definição de “templates” de teste) é uma etapa importante

da implantação de um processo de teste em uma organização.

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 nível de teste de software

correspondente – unidades, integração, sistema e aceitação (Modelo V). As atividades de

teste podem ser iniciadas junto com as atividades de desenvolvimento, logo que as

informações necessárias estejam disponíveis. Neste caso, o planejamento do teste deve ser

realizado junto com o planejamento do desenvolvimento, enquanto que o projeto do teste

de aceitação pode ser iniciado logo que os requisitos do software tenham sido definidos. A

execução de atividades de teste o mais cedo possível 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 iterações (ou ciclos) para o desenvolvimento do software. Ao invés da

realização seqüencial das atividades de desenvolvimento do software, como no tradicional

modelo “cascata” 15, são definidas iterações para o desenvolvimento e incrementos (ou

releases) são associados a cada iteração. Cada incremento envolve a realização das

atividades para: definição de requisitos, projeto, implementação, integração e testes. Nestes

casos, as atividades de teste devem ser associadas às atividades de desenvolvimento em

cada iteração, de modo que haja o adequado replanejamento, projeto, execução 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 aceitação são

executados após o término da última iteração do processo de desenvolvimento.

15 Tipicamente, as atividades realizadas no modelo cascata são: análise de requisitos; projeto do software; implementação e teste de unidades; integração e teste de integração; teste de sistema; implantação e teste de aceitação.



Alguns modelos mais recentes enfatizam o projeto de testes e sua execução como um

elemento central do desenvolvimento do software. A abordagem Desenvolvimento Baseado

em Testes (ou TDD, sigla em inglês) é frequentemente adotada em métodos ágeis, como a

Programação Extrema (XP). No TDD os casos de teste são criados pelos desenvolvedores

antes mesmo que o código fonte seja criado.

9 Análise de riscos: priorizar aspectos para o teste

Em muitos casos o software em teste possui algumas partes (ou funcionalidades) nas quais

a ocorrência de uma falha pode acarretar graves conseqüências a seus usuários, podendo

impactar negativamente seus negócios e eventualmente até mesmo colocar a integridade de

vidas humanas em risco. Por outro lado, o mesmo software pode possuir partes nas quais a

ocorrência de falhas, embora não desejável, não seja crítica em termos dos negócios de seus

usuários, impactando-os somente de forma marginal.

Neste contexto, uma preocupação fundamental do

teste é avaliar as funcionalidades do software que sejam

mais importantes para o negócio de seus futuros

usuários 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 análise de riscos deve ocorrer no planejamento do teste e deve dar subsídios para a

definição de tipos e técnicas de teste a serem utilizadas em cada parte do software, assim

como o quão rigoroso deve ser o teste daquela parte do software. Em última análise, a

consideração dos riscos envolvidos permite alocar os recursos de teste de uma maneira

prudente, dosando o rigor e o esforço do teste de cada parte do software ao nível requerido

de confiabilidade.



10 Política e processo de teste: o papel do teste na estratégia da organização

A definição de uma Política de Teste é fundamental para qualquer organização que

pretende definir ou aprimorar as suas atividades de teste. Trata-se, portanto, de um primeiro

passo importante que servirá de base para definição do processo de teste da organização.

A política de teste define, de maneira geral, os objetivos e a visão estratégica em

relação ao teste. Portanto, deve estar alinhada com a política de qualidade e com os

objetivos de negócios da organização. Ao se estabelecer uma visão comum sobre o teste

para todos os envolvidos com esta atividade, obtém-se um alinhamento das iniciativas para

a utilização ou melhoria do processo de teste, tanto no desenvolvimento como na

manutenção de software. Recomenda-se, portanto, que a política de teste seja documentada,

divulgada e tenha um responsável definido.

A definição de indicadores associados aos objetivos do teste permite a avaliação e a

melhoria contínua do processo de teste na organização. Tipicamente uma política de teste

aborda: objetivos e importância do teste; níveis de qualidade a serem atingidos; nível de

independência da equipe de teste; principais responsabilidades; definição em alto nível do

processo de teste; e separação entre teste e depuração.

A partir do momento em que se estabelece “o quê” as atividades de teste devem

atingir na organização – a Política de Teste – pode-se trabalhar para definir “como” os

objetivos serão atingidos. A definição do “como” dá-se pelo estabelecimento de um

processo de teste. Modelos de processos genéricos de teste e modelos de maturidade de

teste podem servir como inspiração nesta tarefa.

Um modelo de processo genérico de teste, como é o descrito na Seção 8, pode ser

adaptado às necessidades específicas de cada organização. Tal tipo de modelo define um

conteúdo amplo em teste (formado por atividades, métodos, artefatos, etc.) que serve como

base para o estabelecimento de processos customizados, fundamentados nas necessidades

de teste específicas de cada organização. O termo Estratégia de Teste também é utilizado

na literatura com significado semelhante, ou seja, atividades, métodos, artefatos de teste

adotados por uma organização.



Modelos de maturidade de testes, tais como o Test Process Improvement (TPI) 16 ou

o Test Maturity Model Integration (TMMi) 17, também podem ser utilizados para definir

um processo de teste bem como para guiar a sua avaliação 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

estágios do CMMI, o TMMi usa o conceito de níveis de maturidade para a avaliação e

melhoria do processo de teste.

A adoção de um processo de teste, feita por meio da customização de um modelo de

processo genérico de teste, é referida como uma implantação ou configuração de um

processo de teste na organização. Os modelos de processos genéricos de teste ou os

modelos de maturidade do teste podem ser utilizados também para aprimorar, de forma

controlada e gradual, um processo de teste já existente na organização.

A implantação de um processo de teste deve ser feita de forma cuidadosa, por meio

da análise das reais necessidades de teste e das possibilidades da organização. Fatores como

tipo de software desenvolvido, requisitos de confiabilidade e segurança, bem como a

disponibilidade de recursos humanos e financeiros da organização, devem ser levados em

conta nesta implantação. Em geral, requisitos rigorosos de confiabilidade e segurança do

software determinam a definição de processos de teste mais completos, contemplando

vários níveis, tipos e técnicas de teste. Por outro lado, em muitos casos um processo “leve”

– com poucos níveis e utilizando técnicas simples e documentando apenas o essencial –

pode ser o suficiente.

Processos de teste mais completos demandam um maior esforço por parte da

organização, mas tendem a propiciar melhores produtos de software, além de evidências

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.



11 Conclusão: transformando conceitos de teste em melhores produtos de software

Este documento apresentou um corpo de conhecimentos fundamentais em Teste de

Software. O conteúdo foi abordado mais em extensão do que em profundidade, isto é,

espera-se que o leitor tenha adquirido um conhecimento amplo dos vários aspectos das

atividades de teste; entretanto, é necessário o aprofundamento nos assuntos específicos

conforme o interesse e os objetivos específicos.

Os guias e os tutoriais de teste (em elaboração) irão prover o aprofundamento em

alguns aspectos tratados de forma rápida neste documento. A literatura específica de teste

também pode ser útil para este intento.

Espera-se que com a aplicação do conteúdo apresentado, os diversos atores

envolvidos com as questões de qualidade e teste das mais diversas organizações possam

definir ou aprimorar as suas práticas de teste. Em especial, espera-se que todos os

participantes que compõem o ecossistema do SPB possam se beneficiar da aplicação deste

conteúdo e também possam contribuir para o aprimoramento do conhecimento público de

teste de software do SPB.

Environment

11 1 --teste_de_software_motivação_e_conceitos_basicos