Академический Документы
Профессиональный Документы
Культура Документы
Desenvolvedores : tm interesse de demonstrar que o programa isento de erros Os responsveis pelos testes : tm interesse em mostrar que o programa tem erros.
Para suprir o conflito de interesses existe o Grupo Independente de Testes (ITG). O ITG faz parte da equipe de projeto de desenvolvimento de software , no sentido de que est envolvido durante o processo de especificao e continua envolvido planejando e especificando procedimentos de teste ao longo de um grande projeto.
Se erros graves forem encontrados com regularidade => a qualidade e a confiabilidade de software so suspeitas Se erros facilmente corrigveis forem encontrados => a qualidade e a confiabilidade do software esto aceitveis ou os testes so inadequados para revelar erros graves Se no for encontrado erro => a configurao de teste no foi suficientemente elaborada e que erros esto escondidos no software
5
Tcnicas de Teste:
1- Testes Estruturais (Caixa Branca) Baseia-se num minucioso exame dos detalhes procedimentais. So testados os caminhos lgicos atravs do software, fornecendo-se casos de teste que pem prova conjuntos especficos de condies e/ou laos. 2 - Testes Funcionais (Caixa Preta) Refere-se aos testes que so realizados a partir das especificaes das interfaces (entradas e sadas) do programa. So usados para demonstrar que as funes dos softwares so operacionais, que a entrada adequadamente aceita e a sada corretamente produzida; que a integridade das informaes externas mantida. 2 - Testes Baseados em Erros Baseiam-se na incluso de erros propositais (artificiais) como forma de revelar erros existentes previamente (naturais). Fornecem indicadores para gerenciar o processo de teste (porcentagem de erros remanescentes, qualidade dos casos de testes)
Caminho Independente
Qualquer caminho atravs do programa que introduza pelo menos um novo conjunto de instrues de processamento ou uma nova condio. Grafo de Fluxo Conjunto Bsico para o Grafo de Fluxo Caminho 1: 1-11 Caminho 2: 1-2-3-4-5-10-1-11 Caminho 3: 1-2-3-6-8-9-10-111 Caminho 4: 1-2-3-6-7-9-10-111
Complexidade Ciclomtica
uma mtrica de software que proporciona uma medida quantitativa da complexidade lgica de um programa. Quando usado no contexto do mtodo de teste de caminho bsico, o valor computado da complexidade ciclomtica define o nmero de caminhos independentes do conjunto bsico de um programa e oferece um limite mximo para o nmero de testes que deve ser realizado para garantir que todas as instrues sejam executadas pelo menos uma vez. A complexidade ciclomtica computada numa das 3 formas seguintes: 1- O nmero de regies do grfico de fluxo. 2- V(G) = E-N+2 onde E o nmero de ramos do grafo e N o nmero de ns do grafo de fluxo G 3- V(G) = P+1 onde P o nmero de ns predicativos (ns que contm uma condio) contidos no grafo de fluxo G
Tcnicas e Estratgias de Teste de Software 10
O valor de V(G) oferece um limite mximo no nmero de testes que deve ser projetado e executado para garantir a cobertura de todas as instrues de programa.
Tcnicas e Estratgias de Teste de Software 11
12345678910 -
13
14
Caminhos Caminho 1: 1, 2, 3, 9, 10 A=(1,3) T=0 Resultado Esperado => Max=1 Caminho 2: 1, 2, 3, 4, 5, 6, 8, 3, 9, 10 A=(1,3) T=2 Resultado Esperado => Max=3 Caminho 3: 1, 2, 3, 4, 7, 8, 3, 9, 10 A=(3,1) T=2 Resultado Esperado => Max=3
15
12345678910 -
16
Particionamento de Equivalncia
um mtodo de teste que divide o domnio de entrada de um programa em classes de dados (equivalncia) a partir das quais os casos de teste podem ser derivados. 1- Se o domnio de entrada exigir um intervalo, so definidas uma classe de equivalncia vlida e duas classes de equivalncia invlidas. 2- Se o domnio de entrada exigir um valor especfico, so definidas uma classe de equivalncia vlida e duas classes de equivalncia invlidas. 3- Se o domnio de entrada especificar um membro de um conjunto, uma classe de equivalncia vlida e uma classe de equivalncia invlida so definidas. 4- Se o domnio de entrada for booleano, uma classe de equivalncia vlida e uma classe de equivalncia invlida so definidas. Os casos de teste so definidos para cada classe de equivalncia
Tcnicas e Estratgias de Teste de Software 17
18
19
20
22
23
Uma de Teste de
Estratgia Software
Teste de Unidade: concentra-se em cada unidade do software, de acordo com o que implementado no cdigo fonte. Utiliza as tcnicas de teste de caixa branca e caixa preta. Teste de Integrao: concentra-se no projeto e na construo da arquitetura de software. Utiliza principalmente as tcnicas de teste de caixa preta. Teste de Validao: os requisitos estabelecidos como parte da anlise de requisitos de software so validados em relao ao software que foi construdo. Alfa- e Beta-teste. Teste de Sistema: o software e outros elementos do sistema so testados como um todo.
25
26
Teste de Unidade
A interface com o mdulo testada para ter a garantia de que as informaes fluem para dentro e para fora da unidade de programa que se encontra sob teste. A estrutura de dados local examinada para ter a garantia de que dados armazenados temporariamente mantm sua integridade durante todos os passos de execuco. As condies de limite so testadas para ter a garantia de que o mdulo opera adequadamente nos limites estabelecidos para demarcarem ou restringirem o processamento. Todos os caminhos independentes atravs da estrutura de controle so exercitados para ter a garantia de que todas as instrues de um mdulo foram executadas pelo menos uma vez. Todos os caminhos de tratamento de erros so testados.
27
Um vez que o mdulo no um programa individual, um software driver e/ou stub deve ser desenvolvido para cada unidade de teste. Driver - na maioria das aplicaes um programa principal que aceita dados de caso de teste, passa tais dados para o mdulo a ser testado e imprime os dados relevantes. Stub ou programa simulado - servem para substituir mdulos que estejam subordinados (chamados pelo) ao mdulo a ser testado. Usa a interface do mdulo subordinado, pode fazer manipulao de dados mnima, imprime verificao de entrada e retorna.
Tcnicas e Estratgias de Teste de Software 28
Teste de Integrao
O objetivo , a partir dos mdulos testados ao nvel de unidade, construir a estrutura de programa que foi determinada pelo projeto.
Integrao Top-Down
Os mdulos so integrados movimentando-se de cima para baixo, atravs da hierarquia de controle, iniciando-se do mdulo de controle principal. Os mdulos subordinados ao mdulo de controle principal so incorporados estrutura de uma maneira depth-first (primeiro pela profundidade) ou breadth-first (primeiramente pela largura).
29
Teste de Integrao
- Integrao Top-Down
Passos do processo de integrao: 1- O mdulo de controle usado como um driver de teste e os stubs so substitudos para todos os mdulos diretamente subordinados ao mdulo de controle principal. 2- Dependendo da abordagem de integrao escolhida, os stubs subordinados so substitudos, um de cada vez por mdulos reais. 3- Testes so realizados medida que cada mdulo integrado. 4- Durante a concluso de cada conjunto de testes, outro stub substitudo pelo mdulo real. 5- Teste de regresso - (isto , a realizao de todos ou de alguns dos testes anteriores) pode ser realizado a fim de garantir que novos erros no tenham sido introduzidos. Tcnicas e Estratgias de Teste de Software 30
Teste de Validao
Ao trmino da atividade de teste de integrao, o software est completamente montado como um pacote, erros de interface foram descobertos e corrigidos e uma srie final de testes de software - os testes de validao - pode iniciar-se. A validao bem sucedida quando o software funciona de uma maneira razoavelmente esperada pelo cliente. A Especificao de Requisitos de Software contm os critrios de validao que formam a base para uma abordagem ao teste de validao. A validao do software demonstram a conformidade com os requisitos. O plano e o procedimento de teste so projetados para garantir que: todos os requisitos funcionais sejam satisfeitos todos os requisitos de desempenho sejam conseguidos a documentao esteja correta outros requisitos sejam cumpridos: portabilidade, compatibilidade, remoo de erros e manutenibilidade
Tcnicas e Estratgias de Teste de Software 31
Teste de Validao
- Reviso de Configurao
Um elemento importante do processo de validao a reviso de configurao ou auditoria. O propsito dessa reviso garantir que todos os elementos da configurao de software tenham sido adequadamente desenvolvidos, esto catalogados e tm os detalhes necessrios para apoiar a fase de manuteno do ciclo de vida do software.
32
Teste de Validao
virtualmente impossvel que se preveja como o cliente realmente usar um programa. As instrues de uso podem ser mal-interpretadas, combinaes estranhas de dados podem ser regularmente usadas, sadas que pareciam claras ao analista podem ser ininteligveis para um usurio em campo.
SOFTWARE CUSTOMIZADO PARA UM CLIENTE
so realizados testes de aceitao, realizados pelo usurio final para capacit-lo e para validar todos os requisitos. pode variar de um test drive informal a uma srie de testes planejados. Teste Alfa - levado a efeito por um cliente nas instalaes do desenvolvedor. O software usado num ambiente controlado com o desenvolvedor "olhando sobre os ombros" do usurio e registrando erros e problemas de uso. Teste Beta - realizado nas instalaes do cliente pelo usurio final do software. O desenvolvedor no est presente. O cliente registra os problemas (reais ou imaginrios) que so encontrados e relata-os ao desenvolvedor a intervalos regulares.
33
Teste de Sistema
O software apenas um elemento de um sistema baseado em computador mais amplo. O teste de sistema envolve uma srie de diferentes testes, cujo propsito primordial por completamente prova o sistema baseado em computador. Problema Clssico da atividade de teste de sistema: "apontar o dedo" - quando ocorre um erro, o desenvolvedor de um elemento do sistema culpa outro pelo problema. O engenheiro de software deve antecipar os problemas potenciais da interface: 1- projetar caminhos de tratamento de erros que testem todas as informaes que chegam de outros elementos do sistema. 2- realizar uma srie de testes que simulem dados ruins ou outros erros em potencial na interface do software. 3- registrar os resultados de teste para usar como "prova" se algum lhe apontar o dedo. 4- participar do planejamento e projeto dos testes do sistema para garantir que o software seja adequadamente testado.
34
Teste de Sistema
- Teste de Recuperao
Muitos sistemas baseados em computador precisam recuperar-se de falhas e retomar o processamento dentro de um tempo previamente especificado. Em certos casos, o sistema deve tolerar falhas, isto , o processamento de falhas no deve fazer com que uma funo global de sistema cesse. Em outros casos, uma falha do sistema deve ser corrigida dentro de um perodo previamente especificado; caso contrrio, graves prejuzos econmicos ocorrero. O teste de recuperao um teste de sistema que fora o software a falhar de diversas maneiras e verifica se a recuperao adequadamente executada.
35
Teste de Sistema
- Teste de Segurana
Qualquer sistema baseado em computador que gerencie informaes delicadas ou provoque aes que possam impropriamente prejudicar (ou beneficiar) pessoas constitui um alvo para o acesso imprprio ou ilegal. O teste de segurana tenta verificar se todos os mecanismos de proteo embutidos num sistema o protegero, de fato, de acessos indevidos. Durante o teste de segurana, o analista desempenha o papel de pessoa que deseja penetrar no sistema. Qualquer coisa vale! adquirir senhas mediante contatos externos atacar o sistema com software customizado projetado para derrubar quaisquer defesas que tenham sido construdas desarmar o sistema, negando servio a outros provocar erros intencionalmente, esperando acess-lo durante a recuperao "folhear" atravs de dados inseguros esperando descobrir a chave para a entrada no sistema. O papel do projetista do sistema fazer com que o acesso custe mais do que o valor da informao que ser obtida.
Tcnicas e Estratgias de Teste de Software 36
Ferramentas de Automatizao
Devido a complexidade dos softwares atuais, qualquer estratgia de teste sem suporte de ferramentas automatizadas tende a ser trabalhosa e propensa a enganos. Uma ferramenta de teste reduz a interveno humana nos resultados obtidos, aumentando a qualidade e a produtividade da atividade de teste. Influencia diretamente a confiabilidade do software testado. Ela deveria : 1. Produzir casos de teste que mostrassem o comportamento errado do programa; 2. Listar o erros revelados e a sua localizao; Exemplos Acadmicos: 1. PROTESTE (UFRGS) para programas em Pascal/Anlise de Fluxo de Dados 2. Mothra (UNICAMP) para programas em Fortran/Anlise de Mutantes 3. Proteum (Program Testing Using Mutants) (UNICAMP) para programas em C /Anlise de Mutantes
Tcnicas e Estratgias de Teste de Software 37
38