Centro Universidade de Belo Horizonte Disciplina: Engenharia de Software Professor: Eduardo Habib Perodo Letivo: 2010/2

Lista final - Data de entrega: 11/12/2010 Enviar para o email: eduardo.maia@prof.unibh.br

1. Sobre os mtodos Statment Coverage, Branch Coverage e PathCoverage, descreva: a. Objetivo; b. Critrio de completeza dos testes.
STATMENT COVERAGE Cobrir um conjunto ou a totalidade de sentenas (comandos/condio). Ou seja, o objetivo principal aqui cobrir todos os ns do grfico. BRANCH COVERAGE Executar todas as decises (true e false). Ou seja, necessrio cobrir todas as arestas do grfico. PATH COVERAGE Executar todos os diferentes caminhos do objeto testado

Objetivo

2. Para o fluxo de controle abaixo, indique os casos de testes para que se tenha uma cobertura 100% das tcnicas: I)Statment Coverage; a,b,d,e,f,g ii) Branch Coverage; a,b,d,e,f,g a,c,e,h iii) PathCoverage; a,b,d,e,f,g a, b, d, e, h a,c,e,h a,c,e,f,g

3.

O que um teste de unidade?

Teste realizado com os componentes individuais de um software. Os componentes so testados individualmente e isoladamente de qualquer outro sistema. Se ocorrer uma falha j sabe onde est o defeito. muitas vezes confundido com debugging. um tipo de tes te caixa branca.
4. Quando o custo de um bug maior? No incio ou no fim do projeto? Explique porque. No fim do projeto o custo do defeito maior, pois aps o defeito ser descoberto, tudo que j foi feito tem que ser modificado, e isso inclui no apenas o cdigo fonte como tambm toda a documentao do sistema. 5. Qual a diferena entre verificao e validao?

Na Verificao verifica-se se o produto est sendo construdo corretamente, conforme especificado. Enquanto isso, na validao verificado se o produto atende o esperado, ou seja, se ele cumpre o propsito para o qual foi desenvolvido.
6. Explique os 7 princpios que se tornaram regras gerais de teste.

1. Os testes mostram a presena de defeitos, e no a ausncia. Quando os testes so realizados em um software e nenhum defeito encontrado, no significa que o software no possui defeito. No d para provar que o software no possui defeitos. Os testadores podem, simplesmente, no terem realizados os passos que levaro reproduo do defei o. t 2. O teste exaustivo no possvel.

Exceto em aplicaes extremamente simples, o nmero de combinaes possveis de dados proibitivamente alta. Assim, impossvel realizar todas as combinaes dos possveis testes. 3. As atividades de testes devem comear o mais cedo possvel. Um produto (incluindo documentos, tais como a especificao do produto) pode ser testado logo que foi criado, a fim de corrigir erros o mais rapidamente possvel, pois, quanto mais tarde um defeito for detectado maior ser o custo de corrigi-lo. 4. Os defeitos tendem a estar agrupados. Geralmente, a maioria dos defeitos so encontrados em poucas partes do objeto testado. Isso porque os defeitos no so distribudos de forma homognea. Eles esto agrupados. Se muitos defeitos so encontrados em um determinado mdulo do sistema provvel que existam mais defeitos. Possveis causas dos defeitos estarem agrupados so: complexidade, momento (stress, desateno), inexperincia, falta de clareza no entendimento, etc.. 5. O Paradoxo do Pesticida. Um conjunto de testes que usada vrias vezes no mesmo produto de software ir diminuir a eficcia. Usando uma variedade de testes e tcnicas iro expor uma srie de defeitos em diferentes reas do produto. 6. Os testes dependem do contexto da aplicao. Os mesmos testes no devem ser aplicados de forma generalizada. Produtos de software diferentes tm necessidades diferentes, necessitando, portanto, de testes diferentes. 7. Crena de que um sistema sem falhas til ao usurio.
O sistema pode possuir qualidade, mas no fazer nada que o usurio necessite ( devido a falha na especificao, falta de participao do usurio, etc..).