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 Editor: Prof. Carlos Jos Pereira de Lucena

ISSN: 0103-9741 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 objetivo de investigar os mtodos de testes de software baseados em risco, conhecidos pelo termo em ingls risk- based testing. So abordados os fundamentos destas tcnicas, as vantagens pretendidas pelas mesmas,as diferenas entre elas bem como suas limitaes segundo os autores dos artigos aqui citados. Palavras-chave: testes de software, risco.

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

ii

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

iii

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

iv

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

1 Introduo
Esta monografia apresenta o conjunto de propostas encontradas publicadas na literatura 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 publicadas 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 artigos, 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, necessria uma caracterizao do mesmo, que esteja adequada a estas. Dadas s vrias definies 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 materializar 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 adequada ou entraves legislativos. Embora alguns dos artigos abordados utilizem definio 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 CMM1, de que risco tcnico de software pode ser definido como uma medida da probabilidade e severidade de efeitos adversos inerentes ao desenvolvimento 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 informal, definimos risco como simplesmente algo que pode ocasionar uma falha no software. Esta definio se faz necessria porque, como veremos adiante, nem todas as metodologias 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. 3.

Realize testes que exploram o risco. 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 enviar 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 estudado utilizando-se as seguintes perguntas: Vulnerabilidades: Quais fraquezas ou possveis falhas existem neste componente? 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?

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 matria. 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. 2. O cdigo html pode no funcionar em todos os navegadores. As fontes podem no ser desenhadas corretamente para o usurio, ou seja, ficarem pequenas demais ou grandes demais.

3. 4. 5. 6. 7. 8.

Determinado formato de imagem pode no aparecer. Os links podem estar quebrados( no levam a pgina alguma). O e-mail com a matria pode no ser enviado. A rotina de validao do e-mail pode no funcionar adequadamente. A pgina pode permitir o envio de e-mails annimos. 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 situaes 1, 2, 3 ). O usurio pode estar com uma resoluo de vdeo muito alta ou muito baixa ( esta ameaa dispara as situaes 2). Uma falha de cdigo durante o desenvolvimento, resultando em nome errado do endereo internet presente no link (esta ameaa dispara as situaes 4 ). O mecanismo de envio de e-mail pode estar fora do ar momentaneamente(esta ameaa dispara as situaes 5). O usurio pode entrar com um e-mail incorreto ou que no exista (esta ameaa dispara as situaes 5,6). O usurio pode tentar enviar uma mensagem sem endereo do emissor(esta ameaa dispara a situao 7) O usurio pode escrever contedo ofensivo(esta ameaa dispara a situao 8.)

2. 3. 4. 5. 6. 7.

Quanto as vtimas, so estas: 1. 2. 3. O usurio uma vez que este pode no obter o servio que ele espera( enviar um mensagem com uma matria jornalstica em anexo). O destinatrio da mensagem, que pode receber uma mensagem indesejada ou de contedo ofensivo sem remetente. 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. 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 estejam quebrados, haveria um dano material a um anunciante do jornal que uma fonte importante de receita.

4.

Tendo em vista as vulnerabilidades encontradas, vamos criar os casos de teste correspondentes 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.

Situao 1 2 3 4 5

Teste Testar nos trs navegadores mais usados no mercado em pelo menos duas plataformas diferentes. Testar a exibio da pgina em pelo menos cinco resolues diferentes e testar em, monitores de raios catdicos e de cristal lquido. Repetir o teste da situao observando as imagens. Clicar em todos os links da pgina e ver se vo para o lugar correto( supondo que existem poucos links). Enviar 10 (dez) matrias por e-mail para diversas caixas de correio e verificar se elas chegam. O teste deve ser repetido em horrios diferentes para garantir que no h indisponibilidade momentnea durante certos momentos do dia. Criar uma lista com e-mails que esto com endereo incorretos e submetlos a rotina de validao de e-mail Tentar enviar uma mensagem sem emissor e averiguar se a pgina aceita. Entra no campo assunto e comentrios com palavras de baixo calo e averiguar se a rotina de interceptao destas palavras est funcionando.
Tabela 1 - Testes que exploram os riscos analisados

6 7 8

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 heursticas, para identificao dos riscos a serem explorados pelo teste. A primeira j foi mostrada 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 ago5

ra. Esta lista pode ser baseada em experincia prpria ou em listas j existentes. O autor 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 convoluto. 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 dependente 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 fora 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).

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 particular. A seguir h uma verso resumida do que seria um catlogo de riscos para um instalador: 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 parmetros. 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 observao 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 (entenda-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 Impresso Gerao de Relatrios Instalao Biblioteca de imagens Risco Normal Alto Baixo Baixo Heurstica Distribudo, Popular Novo, estratgico, terceirizado,crtico Popular, Usabilidade,Modificado Complexo

Tabela 2 - Matriz Componente/Risco(BACH, 1999)

A coluna da esquerda indica o componente do sistema, a do centro o grau de severidade 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 diferentes componentes do sistema de acordo com os nveis de risco associados a este.

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 baseiam 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 atingido o nvel de qualidade necessrio. Existem obstculos culturais, prticos, tcnicos e de cronograma implementao 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:

Figura 3 - Modelo W (GERRARD, 2000).

Esta tcnica a qual o autor batizou de Total Testing, um implementao da empresa 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 atividade 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 primeiro lugar, isto ir garantir que eles realizaro alguma espcie de teste e em segundo 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 cinco 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

Os testes ainda podem ser considerados estticos(no precisa ser executar o programa) ou dinmicos(precisa executar o programa), e devem ser priorizados segundo a seguinte ordem de rea de risco: 1. 2. 3. 4. 5. 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: Teste no computador de desenvolvimento( em linhas gerais o que o navegador internet executa) Teste de infra-estrutura(o que roda no servidor) Teste de sistema( do sistema completa em isolamento) Alta escala de integrao( com outros sistemas) 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 riscos 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 desenvolvimento na estao de trabalho. Estas informao esto expressas na primeira linha da tabela 2 que mostra o exemplo de um processo de desenvolvimento, utilizando 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.

10

Prioridades de teste Usabilidade Funcionalidade Fumaa performance Esttico/Dinmico Tipo de Teste

Tipo de Teste Mapeados para Estgios de Teste Desenvolvimento na Estao de Trabalho infraTeste de integrao M A A A M A/M A/M A/M A A/M A/M A/M A em Teste de Sistema M A A A/M A/M A/M A/M A/M A/M A/M A A A A A Monitoramento Produo M A A

Teste esttico Checagem de Contedo Teste de HTML S Compabilidade com a Sintaxe do Navegador Internet S Validao Visual no Navegador Teste de Navegao Checagem dos Links Tempo de Carga de Objetos Verificao de Transao Teste Funcional Teste de Navegao da Pgina Teste de Componentes de CGI Teste de Transao Teste de Aplicaes de Sistema Internacionalizao Teste No-funcional Teste de Configurao Teste de Performance Teste de Resistncia/ confiabilidade S Disponibilidade Usabilidade Segurana Integrao em Larga Escala Links externos/ integrao com sistemas legados Funcionalidade Ponta--ponta S S S S S S S S S S S S E E E D A/M A/M A M

D D E

S S S S

D D D D D

A/M A/M

D D D D E/D D

D D

Tabela 3 - Arcabouo de Processo de Teste (GERRARD, 2000)

11

Teste de estrutura

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 incidncia de erros ou problemas(PFLEEGER, 1990 apud ROSENBERG; STAPKO; GALLO ,2002). Sendo assim atravs de mtricas de complexidade de software orientado 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 informativa 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, relacionadas das quais uma classe depende (CHIDAMBER, 1991 apud ROSENBERG; STAPKO; GALLO,2002) . Classes acopladas devem ser distribudas junto com a classe a qual se acoplam ou modificadas se elas precisam ser reutilizadas A resposta uma classe (The Response for a Class - RFC) a cardinalidade do conjunto de todos os mtodos que podem ser invocados em resposta uma mensagem 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 classe. 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 derivados do estudo da distribuio das mtricas coletadas.

12

Mtrica Nmero de Mtodos: Nmero Ponderado de Mtodos Por Classe Acoplamento entre objetos A resposta uma classe Profundidade na rvore Nmero de filhos

Observao Preferencialmente menor que 20 e aceitvel at 40 Preferencialmente menor que 25 e aceitvel at 40 Aceitvel at 5 Aceitvel at 50 Aceitvel at 5 No h um nmero de consenso. Ms quanto maior, 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 cdigo, 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 classes 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

13

um estudo de caso de uma aplicao em uma instituio financeira. Este foi desenvolvido 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 monografia 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 provedor 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, programador 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 posicionamento no mercado, no cumprimento de regulamentaes governamentais, etc, por causa de falhas. Esta conseqncia representa o custo para o consumidor 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 manuteno de software, etc. , devido a uma funo com falhas. Estas conseqncias representam um custo para o vendedor C(v) (AMLAND, 1999).

A suposio era de que o custo para o consumidor igualmente importante na anlise do risco em relao ao custo do vendedor, e exposio de risco seria dada pela funo:

Re( f ) = P( f ) *

C ( c ) + C (v ) 2

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 poderia 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 novas 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 utilizadas par anlise de risco: Clculo de juros

14

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 custo 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 custo mnimo no caso de uma falha nesta funo. Os elementos a serem considerados 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 governamentais. 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 falhas 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 probabilidade 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 particular dividida pela maior mdia ponderada de todas as funes, dando uma probabilidade na faixa [0,1].

15

Custo
Funo C(v) C(c) Mdia C

Probabilidade
Nova Quali- Tama- Com- Mdia Proba Exponho plexi- Ponsi-ao Fun- dade (5) (1) dade debilida ao o (5) (3) rada -de risco P(f) Re(f) 2 2 2 3 7,75 0,74 1,48

Fechar Conta

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 pretendido e que as partes do software que no foram modificadas no foram adversamente 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 rastreabilidade (Ibid, 2003). Os principais objetivos do teste de regresso so garantir a estabilidade e a confiabilidade de sistemas. A abordagem baseada em risco de Chen; Prober (2003) foca em casos de teste que testam as reas que possuem maior risco. Como conseqecia, esta pode nos auxiliar a atingir um nvel de confiabilidade adequado na qualidade do software. 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) apresentado anteriormente. A fase de seleo de casos de teste envolve as seguintes atividades: 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 causar. Derive a severidade para cada caso de teste Calcule o grau de exposio de risco para cada caso de teste Selecione os casos de teste que tem os maiores valores de exposio ao Risco como Casos Seguros (casos de segurana checam que falhas graves no ocorrem).

2. 3. 4.

Quanto Seleo de cenrios de teste baseados em risco, desde que cenrios pontaa-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

16

2.

Garanta que os cenrios cubram tantos casos de teste quanto possvel

A seleo de casos de teste tem os seguintes passos: 1. 2. 3. 4. Calcule a exposio de riscos para cada cenrio Selecione os cenrios com maior exposio ao risco Atualize a matriz de rastreabilidade ( remova os cenrios selecionados e os testes j cobertos e recalcule a exposio ao risco) 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 baseado 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, inviabilizando processos formais de qualidade. Amland(1999) foca suas metodologia na utilizao de riscos para fins de teste, explicitamente 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 executado, 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 funcionalidades 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.

17

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 domnio 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 seriam 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, mode-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 tradicionais. Dentre as tcnicas pesquisadas, Chen; Prober(2003) merecem um certo destaque. pois as dvidas colocadas acima no se aplicam to fortemente em relao a abordagem 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 avaliar seus riscos no constitui uma tarefa to complexa que poderia aumentar o esforo ao invs de reduzir.

18

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, Systems, 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

19