PUC

ISSN 0103-9741

Monografias em Cincia da Computao
n MCC07/06

Teste de Software Baseado em Risco

Edson Andrade de Moraes




Departamento de Informtica


PONTIFCIA UNIVERSIDADE CATLICA DO RIO DE JANEIRO
RUA MARQUS DE SO VICENTE, 225 - CEP 22453-900
RIO DE JANEIRO - BRASIL





Monografias em Cincia da Computao, No. MCC07/06 ISSN: 0103-9741
Editor: Prof. Carlos Jos Pereira de Lucena Maro, 2006
Teste de Software baseado em Risco
Edson Andrade de Moraes
Abstract. This paper presents a bibliographical survey aimed at investigating software
testing methodologies based on risk, commonly known by the term risk-based testing.
This paper touches the fundamentals of these techniques, the advocated advantages of
these, the differences among them, as well as their limitations according to the authors
of the papers cited here.
Keywords: software testing, risk.
Resumo. Esta monografia apresenta uma pesquisa bibliogrfica realizada com o obje-
tivo de investigar os mtodos de testes de software baseados em risco, conhecidos pe-
lo termo em ingls risk- based testing. So abordados os fundamentos destas tcnicas,
as vantagens pretendidas pelas mesmas,as diferenas entre elas bem como suas limita-
es segundo os autores dos artigos aqui citados.
Palavras-chave: testes de software, risco.
ii

Responsvel por publicaes:
Rosane Teles Lins Castilho
Assessoria de Biblioteca, Documentao e Informao
PUC-Rio Departamento de Informtica
Rua Marqus de So Vicente, 225 - Gvea
22453-900 Rio de Janeiro RJ Brasil
Tel. +55 21 3114-1516 Fax: +55 21 3114-1530
E-mail: bib-di@inf.puc-rio.br
iii

Sumrio
1 Introduo 1
2 Riscos de software 1
3 Definies de Teste Baseado em Risco 1
4 Metodologias 5
4.1 Anlise de risco baseada em heurstica 5
4.2 Teste Baseado em Risco para Negcios Eletrnicos 8
4.3 Software Orientado a Objetos 12
4.4 Seleo de reas de teste 13
4.5 Estratgia de Seleo de Casos de Teste 16
5 Vantagens e Restries de Testes baseados em Risco 17
6 Concluso 17
7 Referncias Bibliogrficas 19

iv
Lista de Figuras
Figura 1 Opo para enviar a matria a outra pessoa 2
Figura 2 - Tela de opes para envio da matria a outra pessoa 3
Figura 3 - Modelo W 9

v
Lista de Tabelas
Tabela 1 - Testes que exploram os riscos analisados 5
Tabela 2 - Matriz Componente/Risco 7
Tabela 3 - Arcabouo de Processo de Teste 11
Tabela 4 - Mtricas e Valores Limites 13
Tabela 5 - Exemplo de Mtricas em um Projeto Java 13
Tabela 6- Clculo do grau de exposio ao risco 16


1 Introduo
Esta monografia apresenta o conjunto de propostas encontradas publicadas na literatu-
ra de teste de software que enfocam o teste de software baseado em risco. Seu principal
objetivo abordar diferentes metodologias propostas, enfocando os ganhos que so
defendidos por seus autores, a aplicabilidade e restries de uso. Esta uma pesquisa
bibliogrfica, feita a partir de artigos disponveis em meio eletrnico que foram publi-
cadas em revistas especializadas, conferncias e sites especializados. O termo risk-based
testing no possui uma traduo oficial ou aceita para o portugus, nesta monografia
ser utilizado o termo teste baseado em risco como traduo do termo em ingls.
Esta monografia inicia-se introduzindo o conceito de risco de software no captulo
2, e continua no captulo 3 mostrando o conceito de teste baseado em risco. No captulo
4 so apresentadas vrias tcnicas de teste baseada em risco coletadas em diversos ar-
tigos, de vrios autores. No captulo 5 mostrado um exemplo da aplicao de uma
das tcnicas do captulo 4 e, por fim, no captulo 6 esto as concluses da monografia.
2 Riscos de software
Antes que se possa abordar as metodologias de teste que se baseiam em risco, neces-
sria uma caracterizao do mesmo, que esteja adequada a estas. Dadas s vrias defi-
nies possveis que podem ser atribudas ao conceito, existe a restrio de que, para a
execuo de testes de software, nos interessam somente riscos que possam se materia-
lizar em falhas de software. No nos interessam riscos de natureza administrativa ou
que estejam ligados ao escopo de projeto, como por exemplo, falta de mo de obra a-
dequada ou entraves legislativos. Embora alguns dos artigos abordados utilizem defi-
nio de risco de projeto, como em Chen; Prober (2003).
Sero utilizadas duas definies de risco para que possam estar contempladas todas
as formas como este tratado nos artigos pesquisados. A primeira definio a mesma
utilizada no modelo CMM
1
, de que risco tcnico de software pode ser definido como
uma medida da probabilidade e severidade de efeitos adversos inerentes ao desenvol-
vimento do software que no se adequa aos requisitos funcionais e de performance
pretendidos (HIGUERA; RAIMES, 1996). Esta definio restringe de forma eficiente o
escopo do conceito de falha de software (no-adequao a requisitos funcionais e no
funcionais) e denota que o risco pode ser medido. A segundo definio mais infor-
mal, definimos risco como simplesmente algo que pode ocasionar uma falha no soft-
ware. Esta definio se faz necessria porque, como veremos adiante, nem todas as me-
todologias tratam o risco como uma medida.
3 Definies de Teste Baseado em Risco
Em Bach(1999) utilizada uma definio simplificada do que vem a ser um processo
de teste baseado em risco, a seguinte:
1. Faa uma lista de riscos por prioridade.

1 CMM Capability Maturity Model (HIGUERA; RAIMES, 1996)
2
2. Realize testes que exploram o risco.
3. A medida que os riscos evaporam e riscos novos aparecem, ajuste seu esforo de
teste para focar na tarefa atual.
Apesar de simples, esta definio contm a essncia da tcnica, ou seja, o foco do
teste baseado em risco na anlise do software e na criao de um plano teste baseado
nas reas que possuam a maior probabilidade de apresentarem problemas que teriam
o maior impacto sobre o mesmo (MCMAHOM,1998 apud ROSENBERG;STAPKO;
GALLO ,1999).
Para melhor ilustrar este conceito, aplicaremos uma das tcnica de teste baseado em
risco, com uma aplicao muito comum em sites de jornais disponveis na internet.
Em geral, nestes jornais eletrnicos encontramos ao final das matrias a opo de envi-
ar a matria para outra pessoa. Esta opo mostrada na figura 1 tendo como exemplo
um jornal brasileiro disponvel na internet.

Figura 1 Opo para enviar a matria a outra pessoa (JBONLINE.TERRA.COM.BR,
2006)
Utilizaremos para tal, uma das abordagens desenvolvidas por Bach(1999) , a qual
este chama de abordagem de dentro para fora. Nesta abordagem um produto estu-
dado utilizando-se as seguintes perguntas:
Vulnerabilidades: Quais fraquezas ou possveis falhas existem neste componen-
te?
Ameaas: Que entradas ou situaes poderiam existir que podem explorar uma
vulnerabilidade e disparar uma falha neste componente?
Vtimas: Quem ou o qu poderia ser impactado por uma possvel falha e quo
ruim isto seria?
3
A partir destas informaes ento geramos os casso de teste. interessante notar
que apesar do levantamento das vtimas no subsidiar a construo de casos de teste,
ela ajuda a compreender o severidade da falha, assim podemos concluir se devemos ou
no escrever um caso de teste para aquela situao. Segundo o autor, esta abordagem
requer substancial conhecimento tcnico do que est sendo desenvolvido. Portanto o
membro da equipe encarregado do teste pode no possuir esse conhecimento, assim
necessria a participao do desenvolvedor.
Complementando as informaes sobre a aplicao, vejamos que ao clicar sobre a
opo enviar matria, que retratada na figura acima, o leitor levado para uma outra
pgina onde ele encontra as opes retratadas na figura 2, para enviar a matria .
Figura 2 - Tela de opes para envio da matria a outra pessoa(
JBONLINE.TERRA.COM.BR, 2006)
Sendo que como o autor da monografia no possui acesso aos detalhes internos da
aplicao vamos supor aqui que ela conta com os seguintes componentes arquiteturais:
Uma pgina html que serve como interface para envio da matria.
Uma rotina no lado do servidor para enviar as mensagens de correio com a ma-
tria.
Rotinas de validao do lado servidor para averiguar a se o endereo de e-mail
est correto.
Rotinas que interceptam palavras de baixo calo.
Identifiquemos a seguir os itens de risco pertinentes as ameaas, vulnerabilidades e
vtimas. Quanto s vulnerabilidades:
1. O cdigo html pode no funcionar em todos os navegadores.
2. As fontes podem no ser desenhadas corretamente para o usurio, ou seja, fica-
rem pequenas demais ou grandes demais.
4
3. Determinado formato de imagem pode no aparecer.
4. Os links podem estar quebrados( no levam a pgina alguma).
5. O e-mail com a matria pode no ser enviado.
6. A rotina de validao do e-mail pode no funcionar adequadamente.
7. A pgina pode permitir o envio de e-mails annimos.
8. A pgina pode permitir o envio de e-mail com contedo ofensivo.
Quanto as ameaas so estas:
1. O usurio pode estar utilizando um navegador menos comum no mercado, uma
verso antiga de um navegador popular ou estar rodando o navegador em outra
plataforma tecnolgica que no seja muito comum ( esta ameaa dispara as situ-
aes 1, 2, 3 ).
2. O usurio pode estar com uma resoluo de vdeo muito alta ou muito baixa ( es-
ta ameaa dispara as situaes 2).
3. Uma falha de cdigo durante o desenvolvimento, resultando em nome errado do
endereo internet presente no link (esta ameaa dispara as situaes 4 ).
4. O mecanismo de envio de e-mail pode estar fora do ar momentaneamente(esta
ameaa dispara as situaes 5).
5. O usurio pode entrar com um e-mail incorreto ou que no exista (esta ameaa
dispara as situaes 5,6).
6. O usurio pode tentar enviar uma mensagem sem endereo do emissor(esta a-
meaa dispara a situao 7)
7. O usurio pode escrever contedo ofensivo(esta ameaa dispara a situao 8.)
Quanto as vtimas, so estas:
1. O usurio uma vez que este pode no obter o servio que ele espera( enviar um
mensagem com uma matria jornalstica em anexo).
2. O destinatrio da mensagem, que pode receber uma mensagem indesejada ou de
contedo ofensivo sem remetente.
3. A empresa de mdia dona do jornal. Uma vez que, este pode ser processado por
responsabilidade em permitir que um usurio envie uma mensagem de contedo
ofensivo sem remetente.
4. Os anunciantes do jornal, uma vez que a maioria dos anncios de publicidade
on-line so veiculados com imagens. Caso estas no carreguem ou seus links es-
tejam quebrados, haveria um dano material a um anunciante do jornal que
uma fonte importante de receita.
Tendo em vista as vulnerabilidades encontradas, vamos criar os casos de teste cor-
respondentes a cada uma das situaes acima. Na tabela seguir esto listados ento os
testes baseados nas vulnerabilidades e ameaas e vulnerabilidades encontradas. Para
efeito, consideramos todas a situaes como causadoras de danos significativos tendo
em vista as vtimas envolvidas.



5

Situao Teste
1 Testar nos trs navegadores mais usados no mercado em pelo menos duas
plataformas diferentes.
2 Testar a exibio da pgina em pelo menos cinco resolues diferentes e
testar em, monitores de raios catdicos e de cristal lquido.
3 Repetir o teste da situao observando as imagens.
4 Clicar em todos os links da pgina e ver se vo para o lugar correto( su-
pondo que existem poucos links).
5 Enviar 10 (dez) matrias por e-mail para diversas caixas de correio e verifi-
car se elas chegam. O teste deve ser repetido em horrios diferentes para
garantir que no h indisponibilidade momentnea durante certos mo-
mentos do dia.
6 Criar uma lista com e-mails que esto com endereo incorretos e submet-
los a rotina de validao de e-mail
7 Tentar enviar uma mensagem sem emissor e averiguar se a pgina aceita.
8 Entra no campo assunto e comentrios com palavras de baixo calo e ave-
riguar se a rotina de interceptao destas palavras est funcionando.
Tabela 1 - Testes que exploram os riscos analisados
4 Metodologias
Ao analisar as metodologias propostas podemos notar que trs fases bem definidas
compe todas elas:
Anlise dos riscos do software que ser alvo do teste.
Criao do plano de teste baseado nos riscos.
Execuo do plano de teste.
Os artigos analisados focam essencialmente na primeira fase, ou seja na anlise dos
riscos, com exceo de Bach(1999) que tambm descreve modos de organizao do
esforo de teste. Dentre os artigos analisado temos tambm a seleo de cenrios e
casos de teste, para teste de regresso, a partir do calculo de exposio ao risco
(CHEN; PROBER, 2003), utilizando um modelo desenvolvido em Amland(1999). Nos
prximos itens sero abordadas cada uma desta tcnicas, essencialmente quanto fase
de anlise de riscos para os fins de teste, com exceo do trabalho de Bach(1999) onde
tambm ser abordada a organizao do esforo de teste.
4.1 Anlise de risco baseada em heurstica
Bach (1999) defende a utilizao de duas abordagens distintas, baseadas em heursti-
cas, para identificao dos riscos a serem explorados pelo teste. A primeira j foi mos-
trada no captulo 3 desta monografia. A outra abordagem seria de fora para dentro,
que executada da seguinte forma: provido de um conjunto de riscos em potencial,
estes vo sendo relacionados aos detalhes da situao. Nesta abordagem, se consulta
uma lista pr-definida de riscos e se determina se estes riscos so aplicveis aqui e ago-
6
ra. Esta lista pode ser baseada em experincia prpria ou em listas j existentes. O au-
tor sugere a utilizao de trs tipos de listas: categorias de critrios de qualidade, listas
de riscos genricos e catlogos de riscos(BACH, 1999).
Nas listas de categorias de critrios de qualidade temos categorias desenvolvidas
para atenderem a diferentes tipos de requisitos. As listas abaixo foi desenvolvida a
partir dos critrios ISO 9126
2
a HP Furps
3
:
Capacitao
Confiabilidade
Usabilidade
Performance
Instalabilidade
Compatibilidade
Suportabilidade
Testabilidade
Manutenibilidade
Portabilidade
Localizabilidade(BACH, 1999)
Finalmente as listas genricas de riscos so aquelas que possuem riscos universais a
qualquer sistema:
Complexo: qualquer coisa desproporcionalmente grande, intrincado ou convo-
luto.
Novo: qualquer coisa que no possua histrico no produto.
Modificado: qualquer coisa que tenha sido modificada ou melhorada.
Dependncia em componente superior: qualquer coisa que cuja falha causaria
um efeito cascata de falhas no resto do sistema
Dependente de componente inferior: qualquer coisa que seja extremamente de-
pendente de falhas no resto do sistema.
Crtico: qualquer coisa cuja falha poderia causar um dano substancial.
Preciso: qualquer coisa que deva atender a requisitos exatos.
Popular: que ser muito usado.
Estratgico: qualquer coisa que tenha especial importncia para o seu negcio,
como uma caracterstica que lhe distingue da competio.
Terceirizado: qualquer coisa usada no seu produto, ms que foi desenvolvida fo-
ra do projeto.
Distribudo: qualquer coisa que esteja espalhada em relao a tempo ou espao, e
que seus elementos devam trabalhar juntos.

2 ISO 9126 Normas de Engenharia de Software; Qualidade do Produto (ISO.ORG, 2006).
3 FURPS(Functionality, Usability, Reliability, Performance, Supportability ) Sistema de classificao de
requisitos (EELES, 2005).
7
Defeituoso: qualquer coisa que conhecidamente tenha problemas
Falhou recentemente: qualquer coisa com uma histria recente de falha (BACH,
1999)
Os catlogos de risco so listas de riscos que pertencem a um domnio em particu-
lar. A seguir h uma verso resumida do que seria um catlogo de riscos para um ins-
talador:
Instalao dos arquivos errados.
Arquivos corrompidos.
Outras aplicaes corrompidas.
Hardware no foi configurado de forma apropriada.
O protetor de tela interfere no instalador.
No h deteco de aplicaes incompatveis.
O instalador silenciosamente substitui ou modifica arquivos crticos ou parme-
tros.
O processo de instalao muito lento.
O processo requer o constante monitoramento do usurio.
O processo de instalao confuso(Ibid, 1999).
Bach (1999) tambm sugere trs formas de organizao do esforo de teste em torno
de riscos. A Lista de observao de riscos a mais simples de todas. Uma lista de ob-
servao de riscos apenas um lista de riscos que voc periodicamente rev e pergunta
a si mesmo o que a sua atividade de teste revelou sobre os mesmos.
A Matriz Risco/Tarefa consiste de uma tabela com duas colunas. Na esquerda est
uma lista de riscos, na direita est uma lista de tarefas de mitigao associada a cada
risco. Ordene os riscos pela importncia com a os riscos mais importantes no topo (en-
tenda-se aqui por atividade, a criao e execuo dos testes associados aquele risco).
A Matriz Componente/Risco uma matriz com trs colunas como no exemplo a
seguir:

Componente Risco Heurstica
Impresso Normal Distribudo, Popular
Gerao de Relatrios Alto Novo, estratgico, terceiri-
zado,crtico
Instalao Baixo Popular, Usabilida-
de,Modificado
Biblioteca de imagens Baixo Complexo
Tabela 2 - Matriz Componente/Risco(BACH, 1999)
A coluna da esquerda indica o componente do sistema, a do centro o grau de seve-
ridade do risco, e a da direita a(s) heursticas que expem o risco. A vantagem desta
abordagem que medida que o projeto progride a ateno dispensada para os dife-
rentes componentes do sistema de acordo com os nveis de risco associados a este.
8
4.2 Teste Baseado em Risco para Negcios Eletrnicos
Gerrard (2005) desenvolve um arcabouo( termo em ingls framework) para criao de
uma estratgia de testes de sistemas de negcios eletrnicos ( conhecidos pela termo
em ingls E-Business) a partir dos cinco principais riscos em aplicaes dessa natureza.
So eles usabilidade, performance, segurana, disponibilidade e funcionalidade.
Seus argumentos para a utilizao de uma abordagem diferenciada de testes se ba-
seiam nas especificidades dos projetos de sistemas deste tipo. De forma resumida so
estas:
Mudanas tecnolgicas significativas a cada seis meses. Causando um eterno
grau de inexperincia nos desenvolvedores.
Em algumas organizaes tais projetos podem ser mantidos e gerenciados por
pessoas que no so possuem conhecimento tcnico em computao.
A prioridade se lanar ao mercado primeiro, sem que muitas vezes seja atingi-
do o nvel de qualidade necessrio.
Existem obstculos culturais, prticos, tcnicos e de cronograma implementa-
o de prticas mais robustas de controle de qualidade e teste.
Segundo o autor os principais desafios ao teste nestes ambientes so:
Identificar e enderear riscos rapidamente, e adquirir consenso sobre a estratgia
de teste como um todo.
Desenvolver e implementar estratgias flexveis de teste que sejam direcionados
aos riscos de maior preocupao.
Criar novas tcnicas de teste e mtodos que atendem as restries particulares da
rea de negcios eletrnicos.
Fazer o melhor uso possvel da automao de teste em cada rea da atividade de
teste
Prover evidencia de teste detalhada para ajudar aos colaboradores no projeto a
tomarem a deciso correta sobre o lanamento da verso.
Para Gerrard (2005) usar riscos para priorizar os testes, significa que os alocados ao
teste podem se concentrar na concepo de testes mais efetivos em encontrar falhas e
no se preocupar em ter realizado testes menos que o necessrio.
A metodologia desenvolvida por autor se difere segundo o prprio, pela execuo
de testes em todas as fases do projeto e no s ao final do projeto, quando da existncia
de um sistema executvel. Esta forma de trabalho fica representada pelo modelo W da
figura abaixo:
9

Figura 3 - Modelo W (GERRARD, 2000).
Esta tcnica a qual o autor batizou de Total Testing, um implementao da empre-
sa Evolutif para modelo W. O modelo W promove a idia de que para toda atividade
que gera um artefato que pode se entregue, cada um destes artefatos deve ter uma ati-
vidade teste associada (GERRARD, 2000).
O autor faz tambm algumas considerao em relao a formulao da estratgia de
teste:
Abordagem focada em automao: projete os testes para serem automatizados
desde o incio. No haver tempo suficiente para automatizar os testes manuais
depois.
Teste do desenvolvedor: considere a opo de amarrar os testes realizados no
cdigo do desenvolvedor aos procedimentos de check-in/check-out4. Em pri-
meiro lugar, isto ir garantir que eles realizaro alguma espcie de teste e em se-
gundo lugar, um conjunto confivel de testes de regresso ser mantido durante
o desenvolvimento.
Considere o uso de test drivers: estes so frequentemente programas simples que
aceitam dados de teste, constroem as chamadas ao cdigo que est no servidor,
executam as transaes e guardam os resultados para avaliao posterior.
Para atender os riscos de um projeto de negcios eletrnicos, foram identificados 20
tipos distintos de testes. Cada um est direcionada uma rea especfica de risco. Esta
arcabouo tem o propsito de auxiliar na construo de um processo de teste especfico
para o projeto que est sendo desenvolvido. Os tipos de teste esto agrupados em cin-
co categorias:
Teste esttico
Teste de navegao
Teste funcional
Teste no funcional
Integrao em larga escala

4 Termo usado para definir a colocao e extrao de cdigos fonte em softwares de controle de verso
de programas
10
Os testes ainda podem ser considerados estticos(no precisa ser executar o pro-
grama) ou dinmicos(precisa executar o programa), e devem ser priorizados segundo a
seguinte ordem de rea de risco:
Teste de fumaa( o sistema suporta pelo menos um sesso de uso sem apresentar
falha)
Usabilidade
Performance
Funcionalidade
Os testes tambm so classificados quanto ao estgio:
1. Teste no computador de desenvolvimento( em linhas gerais o que o navegador
internet executa)
2. Teste de infra-estrutura(o que roda no servidor)
3. Teste de sistema( do sistema completa em isolamento)
4. Alta escala de integrao( com outros sistemas)
5. Monitoramento aps entrada em produo( manter os testes de automao para
monitorar o site)
Acrescente-se finalmente o fato de que os testes podem ser automatizados(A) ou
manuais(M). A partir deste conjunto de classificaes utiliza-se uma tabela, na qual
partir da anlise dos riscos do projeto, se constri o processo de teste mais adequado
ao mesmo.
Suponhamos que atividade de testes de checagem do contedo , pertence aos ris-
cos relacionados usabilidade, deve ser testado de forma esttica, com uma parte
sendo feita via automao e outra sendo executada de forma manual, na fase de de-
senvolvimento na estao de trabalho. Estas informao esto expressas na primeira
linha da tabela 2 que mostra o exemplo de um processo de desenvolvimento, utilizan-
do o arcabouo. Tendo em vista as prioridades anteriormente citadas sabemos tambm
que devemos primeiro executar as atividades que esto marcadas como S na coluna
Fumaa, depois as da coluna Usabilidade, e assim por diante.
11


Prioridades
de teste
Tipo de Teste Mapeados para Est-
gios de Teste
Tipo de Teste
F
u
m
a

a

U
s
a
b
i
l
i
d
a
d
e

p
e
r
f
o
r
m
a
n
c
e

F
u
n
c
i
o
n
a
l
i
d
a
d
e

E
s
t

t
i
c
o
/
D
i
n

m
i
c
o

D
e
s
e
n
v
o
l
v
i
m
e
n
t
o

n
a

E
s
t
a

o

d
e

T
r
a
b
a
l
h
o

T
e
s
t
e

d
e

i
n
f
r
a
-
e
s
t
r
u
t
u
r
a

T
e
s
t
e

d
e

S
i
s
t
e
m
a

T
e
s
t
e

d
e

i
n
t
e
g
r
a

o

M
o
n
i
t
o
r
a
m
e
n
t
o

e
m

P
r
o
d
u

o

Teste esttico

Checagem de Contedo S E A/M
Teste de HTML S E A/M
Compabilidade com a Sintaxe do
Navegador Internet S E A
Validao Visual no Navegador S D M M M
Teste de Navegao

Checagem dos Links S D A A
Tempo de Carga de Objetos S S D A A
Verificao de Transao S E A/M A/M
Teste Funcional

Teste de Navegao da Pgina S D A/M
Teste de Componentes de CGI S D A/M
Teste de Transao S D A/M
Teste de Aplicaes de Sistema S D A/M
Internacionalizao S D A/M A/M
Teste No-funcional

Teste de Configurao S D M A/M M
Teste de Performance S D A A A
Teste de Resistncia/ confiabili-
dade S D A A A A
Disponibilidade D A
Usabilidade S E/D M
Segurana S D A/M A/M A/M A
Integrao em Larga Escala

Links externos/ integrao com
sistemas legados S D A/M
Funcionalidade Ponta--ponta S D A/M A/M A
Tabela 3 - Arcabouo de Processo de Teste (GERRARD, 2000)
12
4.3 Software Orientado a Objetos
Em Rosenberg; Stapko; Gallo (2002), proposta a utilizao de uma metodologia para
identificao de classes que estejam mais propensas a erro(ou seja, representam maior
risco de falha ) e eventualmente a aplicao de testes nas mesmas. Segundo os autores
foi comprovado anteriormente que o cdigo que mais complexo tem uma maior in-
cidncia de erros ou problemas(PFLEEGER, 1990 apud ROSENBERG; STAPKO;
GALLO ,2002). Sendo assim atravs de mtricas de complexidade de software orienta-
do a objetos pode se chegar as classes que tem maior probabilidade de falha.
Os autores defendem a utilizao de seis mtricas de medio de projetos orientadas a
objeto, identificadas e aplicadas pelo Software Assurance Technology Center (SATC) do
NASA Goddard Space Flight Center. So estas:
Nmero de Mtodos (Number of Methods NOM ): uma simples contagem dos
diferentes mtodos existentes em uma classe.
Nmero Ponderado de Mtodos Por Classe(The Weighted Methods per Class
WMC ): uma soma ponderada dos mtodos em uma classe(CHIDAMBER, 1991
apud ROSENBERG; STAPKO; GALLO,2002). Se os pesos so iguais, equivalem
mtrica anterior. A Complexidade Ciclomtica (MCCABE, 1976 apud
ROSENBERG; STAPKO; GALLO, 2002) utilizada para avaliar. Adicionar pesos
aos mtodos com sua respectiva complexidade cria uma mtrica mais informati-
va sobre a classe
Acoplamento entre objetos (Coupling Between Objects CBO): uma contagem do
nmero de outras classes para a qual uma classe est acoplada, medida pela
contagem do nmero de hierarquias de classe distintas, excluindo-se herana, re-
lacionadas das quais uma classe depende (CHIDAMBER, 1991 apud
ROSENBERG; STAPKO; GALLO,2002) . Classes acopladas devem ser distribu-
das junto com a classe a qual se acoplam ou modificadas se elas precisam ser reu-
tilizadas
A resposta uma classe (The Response for a Class - RFC) a cardinalidade do con-
junto de todos os mtodos que podem ser invocados em resposta uma mensa-
gem para um objeto da classe ou por algum mtodo que pode ser invocado em
resposta uma mensagem para um objeto da classe ou por algum mtodo da
classe (CHIDAMBER, 1991 apud ROSENBERG; STAPKO; GALLO,2002)
Profundidade na rvore (Depth in Tree DIT ) A profundidade de uma classe de
acordo coma hierarquia de herana o nmero de saltos saindo de uma classe
at a raiz da hierarquia de classes e medida pelo nmero de ancestrais na clas-
se. Quando existe herana mltipla utilize o maior DIT.
Nmero de filhos (Number of Children NOC ): O nmero de filhos o nmero
de subclasses que herdam diretamente da classe na hierarquia.
Por mais de trs anos, o SATC tem coletado e analisado cdigo orientado a objetos
escritos tanto em C++ e em Java. Mais de 20.000 classes foram analisadas, de mais de
15 programas. Os seguintes valores limites para as mtricas individuais foram deriva-
dos do estudo da distribuio das mtricas coletadas.



13

Mtrica Observao
Nmero de Mtodos: Preferencialmente menor que 20 e aceitvel at 40
Nmero Ponderado de M-
todos Por Classe
Preferencialmente menor que 25 e aceitvel at 40
Acoplamento entre objetos Aceitvel at 5
A resposta uma classe Aceitvel at 50
Profundidade na rvore Aceitvel at 5
Nmero de filhos No h um nmero de consenso. Ms quanto mai-
or, maior a probabilidade de erro.
Tabela 4 - Mtricas e Valores Limites(ROSENBERG; STAPKO; GALLO, 2002)
Uma nica mtrica nunca deveria ser utilizada sozinha para avaliar os riscos do c-
digo, necessria pelo menos duas ou trs mtricas para dar uma indicao clara de
problemas em potencial. Portanto, para cada projeto, o SATC cria uma tabela de clas-
ses que possuem alto risco. Alto risco identificado com uma classe que tem ao menos
duas mtricas que excedem os limites recomendados (ROSENBERG; STAPKO;
GALLO,2002) . A tabela a seguir um exemplo de informao que poderia ser obtida a
partir de um projeto. As classes excedem os limites esto sombreadas. Esta informao
foi obtida a partir das classes de um projeto em Java.

Tabela 5 - Exemplo de Mtricas em um Projeto Java (ROSENBERG; STAPKO;
GALLO, 2002)
4.4 Seleo de reas de teste
Em Amland (1999), o autor desenvolve um conjunto de mtricas para a anlise de risco
com o objetivo de subsidiar um processo de teste. Estas mtricas foram aplicadas em
14
um estudo de caso de uma aplicao em uma instituio financeira. Este foi desenvol-
vido pelo autor e relatado no artigo. A anlise do risco foi desenvolvida antes do incio
dos testes no sistema, ms foi continuamente atualizada durante a sua execuo. Como
a aplicao possua dois mdulos um on-line e outro que processava em lote (batch),
anlises separadas foram executadas para cada um deles. Para os fins desta monogra-
fia darei nfase ao modelo de anlise utilizado no mdulo em lote , descrito a seguir.
A empresa financeira, referida como provedora do servio e vendedor, desenvolveu
um modelo para o clculo da exposio ao risco baseado em:
A probabilidade de um erro
O custo (conseqncia) de um erro na funo correspondente, tanto para o pro-
vedor do servio como para o cliente.
Na sua metodologia existem trs principais fontes de anlise de risco:
Qualidade da funo (rea) a ser testado. Entenda-se por funo o mdulo ou
programa. Isto foi utilizado como indicao da probabilidade de uma falha-P(f).
A presuno de que um funo sofre de um projeto de m qualidade, programa-
dor inexperiente, funcionalidade complexa, etc, est mais exposta a falhas que
funes baseadas em um projeto de melhor qualidade, que foram feitas por um
programador mais experiente, etc.
As conseqncias de uma falha em uma funo do ponto de vista de um cliente
em uma situao de produo, isto , probabilidade de ameaa legal, perder po-
sicionamento no mercado, no cumprimento de regulamentaes governamen-
tais, etc, por causa de falhas. Esta conseqncia representa o custo para o consu-
midor C( c).
As conseqncias de uma falha em uma funo do ponto de vista do vendedor
do servio, isto a probabilidade de: publicidade negativa , altos custos de ma-
nuteno de software, etc. , devido a uma funo com falhas. Estas conseqn-
cias representam um custo para o vendedor C(v) (AMLAND, 1999).
A suposio era de que o custo para o consumidor igualmente importante na an-
lise do risco em relao ao custo do vendedor, e exposio de risco seria dada pela fun-
o:
2
) ( ) (
* ) ( ) Re(
v C c C
f P f
+
=
Um exemplo de reas com diferentes perfis de risco seriam s reas de clculo de
juros e rea de impresso de relatrios internos. Um falha no clculo de juros pode-
ria facilmente ocasionar um ameaa legal ao banco que utilizasse o software, enquanto
uma falha na impresso de relatrios internos no chegaria nem ao conhecimento do
pblico (Ibid, 1999).
Tendo em vista os graus de exposio ao risco, as reas com risco mais alto tem a
maior prioridade no teste. E, durante o teste a medida que falhas vo ocorrendo e no-
vas prioridades podem ser adicionadas ao projeto, os graus de exposio ao risco vo
sendo atualizados, a prioridade de teste pode ser modificada.
As reas de processamento em lote da aplicao foram dividas em sub-reas( ou
funes ) como parte de um estgio de projeto lgico. Estas funes foram ento utili-
zadas par anlise de risco:
Clculo de juros
15
Calculo de multas
Anlise de lucratividade
Excluso de dados
Gerao de relatrios
Capitalizao
O grande desafio segundo Amland(1999) foi a identificao dos indicadores de cus-
to de falha e de qualidade. Foi utilizada uma abordagem simples ms segundo o autor
satisfatria:
Custo de falha: foi indicada por um numero de 1 3 com 1 representando o cus-
to mnimo no caso de uma falha nesta funo. Os elementos a serem considera-
dos eram:
Recurso de manuteno a serem alocados no caso de uma falha( dado que
o vendedor proveria o servio 24 h por dia).
Conseqncias legais no caso do vendedor no cumprir com requisitos go-
vernamentais.
Conseqncias de uma m reputao.
A probabilidade de uma falha foi indicado dando a 4 indicadores um nmero que
varia de 1 3, onde 1 era bom com probabilidade de falha baixa. Os indicadores eram:
Funo que foi modificada ou uma nova funcionalidade.
Qualidade do projeto da funo. Este item era medido pelo nmero de pedidos
de mudana no projeto da funo.
Tamanho. Foi assumido que o nmero de sub-funes afetaria o nmero de fa-
lhas introduzidas pelo programador.
Complexidade. A habilidade do programador em compreender as funes que
ele estava programando iro sempre ter um efeito sobre o nmero de falhas.
Para o custo relacionado a cada funo em lote foi calculada a mdia entre o custo
par o cliente e o custo para o vendedor. Os indicadores utilizados para calcular a pro-
babilidade de falha de uma funo em particular foram ponderados isto , o peso iria
variar de 1 at 5, sendo a nota 5 indicando a maior probabilidade de falha.
Os pesos utilizados pelo vendedor foram
Funo que foi modificada ou nova funcionalidade: 5
Qualidade do projeto: 5
Tamanho: 1
Complexidade: 3
Um exemplo do grau de exposio ao risco calculado para a funo Fechar contas
mostrado na tabela abaixo. O grau de exposio ao risco foi calculado para todas as
funes e a lista foi ordenada para identificar quais reas deveriam ser focadas durante
o teste. A probabilidade calculada como a Media Ponderada de uma funo em par-
ticular dividida pela maior mdia ponderada de todas as funes, dando uma probabi-
lidade na faixa [0,1].

16

Custo

Probabilidade


Funo C(v) C(c) Mdia
C
Nova
Fun-
o
(5)
Quali-
dade
(5)
Tama-
nho
(1)
Com-
plexi-
dade
(3)
Mdia
Pon-
de-
rada
Proba
-
bilida
-de
P(f)
Expo-
si-ao
ao
risco
Re(f)

Fechar
Conta
1 3 2 2 2 2 3 7,75 0,74 1,48

Tabela 6- Clculo do grau de exposio ao risco (AMLAND, 1999).
4.5 Estratgia de Seleo de Casos de Teste
Em Chen; Prober (2003) encontramos a utilizao de mtricas de riscos para seleo de
sutes de teste a serem aplicadas. Os testes de regresso so essenciais para a garantia
da qualidade do software. Ele o processo de validao do software modificado para
prover confiana as partes que foram mudadas do software se comportam como pre-
tendido e que as partes do software que no foram modificadas no foram adversa-
mente afetadas pelas modificaes (HARROLD ET AL.,2001 apud CHEN; PROBER,
2003). Seleo de teste de regresso baseados em cdigo boa para teste de unidade
ms tem problemas de escalabilidade. medida que o tamanho do sistema sob teste
cresce, se torna mais difcil gerenciar a informao do teste e criar matrizes de rastrea-
bilidade (Ibid, 2003).
Os principais objetivos do teste de regresso so garantir a estabilidade e a confiabi-
lidade de sistemas. A abordagem baseada em risco de Chen; Prober (2003) foca em ca-
sos de teste que testam as reas que possuem maior risco. Como conseqecia, esta po-
de nos auxiliar a atingir um nvel de confiabilidade adequado na qualidade do softwa-
re. A metodologia proposta por Chen; Prober (2003) consiste de duas etapas, seleo
dos casos de teste e seleo dos cenrios de teste ponta-a-ponta.
Esta metodologia utiliza o modelo de risco desenvolvido por Amland(1999) apre-
sentado anteriormente. A fase de seleo de casos de teste envolve as seguintes ativi-
dades:
1. Estimar o custo de cada caso de teste. Entenda-se por custo no o custo laboral de
executar o teste e sim o custo que uma falha que ocorra naquela rea possa cau-
sar.
2. Derive a severidade para cada caso de teste
3. Calcule o grau de exposio de risco para cada caso de teste
4. Selecione os casos de teste que tem os maiores valores de exposio ao Risco co-
mo Casos Seguros (casos de segurana checam que falhas graves no ocorrem).
Quanto Seleo de cenrios de teste baseados em risco, desde que cenrios ponta-
a-ponta envolvem muitos componentes do sistema trabalhando juntos, ele so muito
efetivos em encontrar falhas de regresso.A seleo de cenrios deve obedecer duas
regras:
1. Selecione os cenrios para cobrir os casos de teste mais crticos
17
2. Garanta que os cenrios cubram tantos casos de teste quanto possvel
A seleo de casos de teste tem os seguintes passos:
1. Calcule a exposio de riscos para cada cenrio
2. Selecione os cenrios com maior exposio ao risco
3. Atualize a matriz de rastreabilidade ( remova os cenrios selecionados e os testes
j cobertos e recalcule a exposio ao risco)
4. Repita os passos 1 e 2 o quanto desejar
5 Vantagens e Restries de Testes baseados em Risco
As principais vantagens de utilizao destas tcnica esto relacionadas a questes de
custo, prazos e cultura organizacional. Bach(1999) recomenda a utilizao de teste ba-
seado em risco quando outras formas de organizao do esforo de teste demandam
mais tempo ou recursos que voc tenha disponvel. Outra vantagem que o autor cita
que uma vez que o foco deste tipo de teste em reas de maior risco para o software,
este acaba por justificar o esforo de teste em relao a misso da atividade de teste,
encontrar falhas. O que pode ser til em culturas organizacionais avessas ao teste.
Realidade esta, a qual relatada por Gerrard(2005) quando se refere ao ambiente
de negcios eletrnicos. Onde o ciclo de vida das verses muito pequeno, inviabili-
zando processos formais de qualidade.
Amland(1999) foca suas metodologia na utilizao de riscos para fins de teste, ex-
plicitamente com o objetivo de reduo do custo da fase de teste do projeto e a reduo
de futuros custo de produo em potencial pela otimizao do processo de teste.
Para Chen; Prober(2003), o crescimento contnuo das sutes de teste em tamanho e
volume a medida que um sistema de software evolui em funcionalidades pode tornar
invivel, ou extremamente custosa a execuo de um teste de regresso completo. Por
isso uma abordagem baseada em riscos reduz o volume de teste de regresso a ser exe-
cutado, possibilitando que as reas mais crticas sejam testadas.
Tendo em vista que as tcnicas apresentadas focam na reduo do esforo de teste
utilizando risco, conclui-se obviamente que, as mesmas no devem ser utilizadas em
ambientes de alta criticidade em que uma falha pode causar perda de vida humana ou
grande perda financeira. Como exemplo podemos citar sistemas de apoio vida. Para
estes casos necessrio a utilizao de abordagens mais formais.
6 Concluso
Esta monografia analisou algumas das propostas de testes de software baseados em
risco. Estas tcnicas focam o esforo de teste em reas do software que possuam maior
risco de falha, em comparao com outras tcnicas que buscam cobrir todas as funcio-
nalidades do software. Assim obtendo uma atividade de teste menos custosa e mais
rpida.
necessrio portanto fazer algumas consideraes a respeito. Como citada na seo
anterior esta tcnica possui limitaes. Principalmente em se tratando de sistemas de
alta criticidade, nos quais o custo da falha muito alto.
18
Nota-se tambm uma certa semelhana destas tcnica, principalmente a proposta de
Bach(1999), com uso de listas de condies de contorno. Em que apresentado um
conjunto de condies que podem ocorrer durante a execuo do programa, e ento
averiguamos como este se comporta nestas condies. Ou seja podemos dize que h
uma semelhana com testes baseados em checklist de forma geral.
Tambm necessrio levar em considerao que a identificao e a avaliao dos
riscos tcnicos de um software pode no ser uma tarefa simples, dependendo do do-
mnio da aplicao, tamanho da mesma, publico alvo, tecnologia utilizada, etc. Estes
fatores podem complicar o processo de anlise de risco. Neste casos, no h nenhum
indicativo claro que abordagens de teste funcional caixa-preta, por exemplo, no seri-
am mais baratas ou at mesmo mais rpidas que o uso tcnicas baseadas em risco.
Torna-se esta ento uma das maiores questes em aberto nos artigos. No existe
uma indicao clara de em quanto realmente reduzido o esforo( custo, tempo, mo-
de-obra, etc.) de teste. No h uma comparao numrica de volume de atividades de
teste usando teste baseado em risco e outras abordagens consideradas mais tradicio-
nais.
Dentre as tcnicas pesquisadas, Chen; Prober(2003) merecem um certo destaque.
pois as dvidas colocadas acima no se aplicam to fortemente em relao a aborda-
gem dos autores. Eles utilizam a anlise de risco par selecionar testes de regresso. Ou
seja estamos falando de uma aplicao que conhecida dos desenvolvedores, logo ava-
liar seus riscos no constitui uma tarefa to complexa que poderia aumentar o esforo
ao invs de reduzir.

19
7 Referncias Bibliogrficas
AMLAND, Stle; Risk based Testing and Metrics; EuroSTAR '99, November 8 - 12,
1999, Barcelona, Spain. Traduo livre do autor desta Monografia. Disponvel tambm
em:
http://www.amland.no/WordDocuments/EuroSTAR99Paper.doc
BACH, James; James Bach on Risk-Based Testing: How to conduct heuristic risk
analysis; Software Testing & Quality Engineering Magazine; p. 23-28, nov. de 1999.
Traduo livre do autor desta Monografia.
CHEN, Yanping; PROBER, Rbert L.; Risk-Based Regression Test Selection Strategy;
14th. IEEE International Symposium on Software Reliability Engineering ISSRE 2003.
Disponvel em:
http://www.chillarege.com/fastabstracts/issre2003/161-FA-2003.pdf
CHIDAMBER S.R. & Kemerer, C.F., Towards a Metrics Suite for Object Oriented
Design Proc. OOPSLA, 1991.
EELES, Peter; Capturing Architectural Requirements. Disponvel em:
http://www-128.ibm.com/developerworks/rational/library/4706.html
GERRARD, Paul; Risk-Based E-Business Testing-Part 1, Risk and Test Estrategy.
Disponvel em:
http://www.software-engineer.org acessado em 26 de out. de 2005.
HARROLD, Mary Jean; JONES,James A.; LI, Tongyu; LIANG Donglin; Regression
Test Selection for Java Software, Proc. of the ACM Conf. on OO Programming, Sys-
tems, Languages, and Applications (OOPSLA 01), 2001, p. 312 326.
HIGUERA, Ronald P.; RAIMES, Yacov, Y.; Software Risk Management-Technical
Report CMU-SEI-96-TR-012; Jun. de 1996. Traduo livre do autor desta Monografia.
Disponvel em:
http://www.sei.cmu.edu/pub/documents/96.reports/pdf/tr012.96.pdf
ISO.ORG ; ISO 9126 : Software Engineering -- Product Quality part1: Quality
Model. Disponvel em:
http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=227
49&ICS1=35&ICS2=80&ICS3. Acessado em 14 de fev. de 2006.
JBONLINE.TERRA.COM.BR; JB Online; Disponvel em:
http://jbonline.terra.com.br . Acessado em 12 de fev. de 2005.
MCMAHON, Keith; Risk Based Testing, ST Labs, WA, 1998 apud ROSENBERG,Linda
H.; STAPKO, Ruth; GALLO, Albert ;Risk-based Object Oriented Testing; NASA
SEW24 - Twenty-Fourth Annual Software Engineering Workshop. Traduo livre do
autor desta Monografia.
PFLEEGER, S.L. and Palmer, J.D.; Software Estimation for Object Oriented Systems;
Intl. Function Point Users Group Fall conference, San Antonio TX, 1990
ROSENBERG,Linda H.; STAPKO, Ruth; GALLO, Albert ;Risk-based Object Oriented
Testing; NASA SEW24 - Twenty-Fourth Annual Software Engineering Workshop.
Disponvel em:
http://sel.gsfc.nasa.gov/website/sew/1999/topics/rosenberg_SEW99paper.pdf