capitulo 23 - teste de software

Upload: fernanda-caetano

Post on 19-Jul-2015

136 views

Category:

Documents


0 download

TRANSCRIPT

SOFTWARE TESTINGIan Sommerville, 8 edio Captulo 23Aula de Luiz Eduardo Guarino de Vasconcelos

A atividade de teste nunca termina. Apenas transferida do projetista para seu cliente. O engenheiro de software pode realizar testes mais completos e portanto descobrir e corrigir o maior nmero de erros possveis antes que os testes do cliente se iniciem.

ObjetivosEntender as tcnicas de testes que so utilizadas para descobrir defeitos em programas Introduzir diretrizes para o teste de interface Compreender abordagens especficas para o teste de sistemas orientados a objetos Compreender os princpios d operao de apoio C d i i da d i de ferramentas CASE para testes

Tpicos abordadosTestes de componentes e de integrao Testes de defeitos Testes orientados a objetos rea de trabalho de teste d t b lh d t t

O processo de TestesTestes de componentesTestes de componentes de programas individuais. Usualmente os programadores assumem a responsabilidade pelo U l d bld d l teste de seu cdigo (exceto em caso de sistemas crticos). Testes so derivados da experincia do desenvolvedor.

Testes de integraoTestes de grupos de componentes integrados para formar subsistemas ou sistemas completos. Uma equipe independente de teste faz o teste de integrao. Os testes so baseados em uma especificao do sistema.

Fases de Teste

Teste para deteco de defeitosO objetivo de testes para a deteco de defeitos revelar defeitos nos programas. Um teste bem sucedido aquele que revela a p presena de um defeito (faz com que o programa ( q p g se comporte de maneira anmala) Testes mostram a presena e no a ausncia de defeitos.

Prioridades de testeSomente o teste exaustivo pode mostrar que um programa livre de defeitos. Contudo, o teste exaustivo impossvel Testes devem executar as capacidades do sistema p em vez de seus componentes Testar capacidades antigas mais importante que testar novas capacidades Testar situaes tpicas mais i T i i i importante que situaes adversas (ex. casos de valor limite)

Dados de Teste e Casos de TesteDados de teste: Entradas que foram criadas para testar o sistema Casos de teste: Entradas para testar o sistema e as sadas esperadas caso o sistema opere de acordo p p com sua especificao

Processo de teste para deteco de defeitos

Teste de Caixa PretaUma abordagem de teste onde o programa considerado uma caixa preta Testes funcionais Os casos de teste so derivados da especificao do sistema Planejamento d t t deve comear no incio d Pl j t de testes d i i do processo de software

Teste de Caixa PretaValores de borda - Utiliza valores extremos vlidos (Ex: exorbitncia, vetores, null, etc) ll t ) Testes de Sintaxe T d S - Abrange as entradas invlidas do sistema, com o objetivo de observar seu comportamento quando esses valores forem usados (Ex: Uso de floats em campos inteiros) )

Teste de Caixa PretaTestes de transioEspecifica o comportamento de um componente em uma transio de estado ocorrida por uma entrada ou um evento. d (Ex: assentos de um vo, vo variveis)

Particionamento de equivalnciaDados de entrada e resultados de sada freqentemente se encontram em diferentes classes onde todos os membros de uma classe so relacionados Cada uma destas classes uma partio de equivalncia onde o programa se comporta de uma maneira equivalente para cada membro da classe Casos de teste devem ser escolhidos a partir de cada partio

Particionamento de equivalnciaParticionar as entradas e sadas em conjuntos equivalentesSe a entrada um nmero de 5 dgitos entre 10.000 e 99.999, as parties de equivalncia so 99.999

Escolher casos de teste nos limites destes conjuntos j00000, 09999, 10000, 99999, 100000

Particionamento de equivalncia

Diretrizes de Teste (Sequncia)Testar o software com seqncias que tenham somente um nico valor Utilizar seqncias, de diferentes tamanhos, em diferentes testes Derivar testes de forma que o primeiro, o mdio e o ltimo elemento da seqncia sejam acessados Testar seqncias de tamanho zero e NULO

Rotina de Busca Particionamento de Entrada

Testes de EstruturaAlgumas vezes chamado de teste de caixa branca Os casos de teste so derivados de acordo com a estrutura do programa. O conhecimento do p g programa utilizado para identificar casos de p teste adicionais. Objetivo exercitar todas as declaraes do programa (e no todas as combinaes de caminhos)

Testes de EstruturaFluxo de dados Pe prova a lgica do programa.

Teste de laos Faz procedimentos para exercitar laos de vrios graus de complexibilidade.

Testes de caminhoO objetivo do teste de caminho garantir que o conjunto de testes tal que cada caminho do programa executado pelo menos uma vez O ponto de partida para o teste de caminho um p p p grafo de fluxo do programa que mostra ns representando decises de programa e em arcos representando o fluxo de controle Declaraes condicionais so portanto ns no grafo de fluxo

Grafo de fluxo do programaDescreve o fluxo de controle do programa. Cada ramo em uma declarao condicional mostrado como um caminho independente e os loops so indicados por setas fazendo o loop de volta para o n de condio do loop Utilizado como uma base para o clculo da complexidade ciclomtica Complexidade ciclomtica = Numero de arestas Nmeros de ns + 2

Complexidade ciclomticaO nmero de testes de cada caminho independente (atravessa pelo menos um novo ramo) igual a complexidade ciclomtica l id d i l ti O nmero mnimo de casos de teste para testar todos os caminhos i d i h igual a complexidade l l id d ciclomtica til l se usado com cuidado. No implica suficincia d d d N l f de testes Embora todos os caminhos sejam executados, no so executadas todas as combinaes de caminhos

Grafo de fluxo para a busca binria

Caminhos independentes1, 2 3 8 9 2, 3, 8, 1, 2, 3, 4, 6, 7, 2 1, 2, 3, 4, 5, 7, 2 1, 2, 3, 4, 6, 7, 2, 8, 9 , , , , , , , , Casos de teste devem ser derivados de forma que todos estes caminhos sejam executados Um analisador dinmico de programa pode ser utilizado para verificar se todos os caminhos foram executados

Teste de IntegraoTesta sistemas completos ou subsistemas compostos de componentes integrados Testes de integrao devem ser caixa preta com testes derivados da especificao do sistema p Principal dificuldade a localizao de erros Testes d i t T t de integrao incremental reduz este i t l d t problema

Teste de Integrao Incremental

Abordagens para Teste de IntegraoTeste top-downInicia com componentes de alto nvel integrando de maneira top-down. Substitui componentes individuais por stubs quando apropriado

Teste Bottom-upIntegra componentes individuais em nveis at o sistema g p completo estar criado.

Na prtica, a maioria das integraes envolvem uma combinao destas estratgias

Abordagens de TesteValidao d arquitetura ld deTeste top-down melhor em descobrir erros na arquitetura do sistema

Demonstrao do sistemaTeste top down permite uma demonstrao limitada no top-down estgio inicial de desenvolvimento

Implementao de testeFreqentemente mais fcil com o teste bottom-up

Observao de testeProblemas com ambas abordagens. Cdigo extra pode ser necessrio para observar os testes

Teste de InterfaceOcorrem quando mdulos ou subsistemas so integrados para criar sistemas maiores Objetivo detectar defeitos devido a erros de interface ou suposies invlidas sobre as interfaces p Particularmente importante para o desenvolvimento orientado a objetos, j que os objetos so definidos objetos por suas interfaces

Teste de estresseExecutar o sistema alm da carga mxima projetada. Os testes de estresse freqentemente provocam a revelao d defeitos do sistema l de d f it d i t Durante os testes de estresse o sistema no deve falhar d f lh de maneira catastrfica. O sistema no deve i fi i d apresentar corrupo de dados ou a perda inesperada de servios Particularmente importante em sistemas distribudos que podem apresentar uma grande degradao d t d d d medida que a rede se torna sobrecarregada

Testes orientado a objetosOs componentes a serem testados so classes instanciadas como objetos Como objetos tm uma granularidade maior que funes individuais, os testes de caixa branca , devem ser estendidos No h um nvel superior bvio para o sistema para a integrao e teste top-down

Nveis de TesteTestar operaes individuais associadas com objetos Testar classes de objetos individuais Testar agrupamentos de objetos relacionados Testar o sistema orientado a objetos

Testes de Classes de ObjetosCobertura completa de testes de uma classe C envolve Testar todas as operaes associadas com um objeto Estabelecimento e interrogao de todos os atributos do objeto Exerccio do objeto em todos os estados possveis A herana torna mais difcil projetar testes de p j classes de objetos j que a informao a ser testada no localizada

Interface do objeto Estao Meteorolgica

So necessrios casos de teste para todas as operaes Utilizar um modelo de estado para identificar seqncias de transies de estado para teste Exemplos de seqncias a serem testadas Desativado Aguardando Aguardando Aguardando Calibrando Coletando Desativado Testando Aguardando Transmitindo Resumindo Aguardando Transmitindo Aguardando

Outros TestesTeste Alpha Teste Beta Teste de Regresso Garante funcionamento pleno Teste de Aceitao Grupo restrito de usurios finais simulando rotinas

Profisso: Testador uma certificao relativamente nova na rea de TI Em outros pases j bem difundida Na ndia so 10 mil testadores Compradores, especialmente estrangeiros, exigem que a soluo desenvolvida seja certificada Salrio Mdio Entre R$ 1.900,00 e R$ 5.000,00

Certificao em Testes de Software Existem vrias entidades que emitem a certificao em testes de software: E i i id d i ifi d f QAI - Quality Assurance Institute A prova est dividida em 4 partes sendo duas de mltipla escolha e duas partes Dissertativas. Seu custo de 350 dlares. CMST - Certified Manager of Software Testing A prova requer conhecimento prtico. E di idid em 4 partes e as respostas h i i Est dividida tem de ser construdas. Seu custo de 600 dlares. ISTQB (International Software Testing Qualifications Board) Com durao de uma hora, a prova contm 40 questes de mltipla escolha. Para ser aprovado, necessita-se de no mnimo 65 % de acertos. Tem custo de 350 reais. CTM C tifi d Test Manager Certified T t M A prova tem custo de 120 dlares + um treinamento obrigatrio. O nmero de questes e o tempo de durao variam. Requer mnimo de 80 % de acertos para aprovao

Certificao em Testes de Software Existem vrias entidades que emitem a certificao em testes de software:

ALATS (Associao Latino-Americana de Teste de Software) A prova contm 100 questes de mltipla escolha e tem durao de 3 horas. O preo de 300 reais e requer no mnimo 75 % de acertos http://www.alats.org.br.

IBQTS (Instituto Brasileiro de Qualidade em Testes de Software) Contm 50 questes de mltipla escolha e 3 horas de durao.. Seu preo de 300 reais e requer no mnimo 70% de acertos http://www.ibqts.com.br.

A atividade de teste nunca termina. Apenas transferida do projetista para seu cliente. O engenheiro de software pode realizar testes mais completos e portanto descobrir e corrigir o maior nmero de erros possveis antes que os testes do cliente se iniciem.

Pontos chave Pontos-chave mais importante testar as partes do sistema mais d comumente utilizadas do que as partes que so exercitadas raramente raramente. Partio de equivalncia uma maneira de derivar casos de teste. Parties so conjuntos de dados onde o teste programa deve se comportar de maneira equivalente. Teste de caixa preta baseado na especificao do sistema. No precisa analisar o cdigo fonte. Teste estrutural baseia-se na anlise do programa baseia se para determinar os caminhos a serem executados e a seleo de casos de teste.

Pontos chave Pontos-chaveOs testes de integrao testes de integrao se concentram no teste das interaes entre os componentes. Para testar as classes de objetos testar as classes j de objetos, deve-se testar todas as operaes, atributos e estados.