Pos Testes Software 2010

8/8/2019 Pos Testes Software 2010

1/181

Ps-graduao em Anlise e Gerncia de Sistemas.

Testes de Software

Por: Guilherme Motta MSC / PMP / CTFL

[email protected]


2/181

Guilherme Motta 2

Boas Vindas

Qual o seu nome?

Qual a sua atividade profissional?

J trabalhou com Testes de Software?


3/181

Guilherme Motta

Aula Data Programao

1 27/02/2010

(manh)

1 - Fundamentos de Teste de Software:

2 - Verificao e Validao;

3 - Teste de Software e o Ciclo de Vida do Software;

2 06/03/2010

(manh)

4 - Tcnicas para Testes Estticos;

5 - Fundamentos do Processo de Testes de Software;

6 - Tcnicas de Modelagem de Testes de Software;3 06/03/2010

(tarde)

7 - Gerenciamento de Testes de Software;

8 - Ferramentas de Suporte aos Testes de Software;

9 - Desenvolvimento Baseado em Testes (TDD Test Driven Development);

4 13/03/2010

(manh)

10 - Central de Testes;

11 - Modelos de Maturidade em Testes de Software;12 Prova Final.

Programao do Curso


4/181

Guilherme Motta 4

1 Fundamentos de Testes de Software


5/181

Guilherme Motta 5

Qual o objetivo dos testes?

Executar o produto de software com o intuito de detectar a presenade falhas.

[Myers]

Mostrar a presena de falhas em um software, mas nunca a sua

ausncia.

[Dijkstra]

Executar um sistema ou componente sob condies especificas para

detectar diferenas entre os resultados obtidos e os esperados.

[IEEE]


6/181

Guilherme Motta 6

Quando comeam os testes?

As atividades de testes devem ser integradas s atividades dedesenvolvimento.

As atividades de teste devem ser iniciadas junto as atividades de

desenvolvimento.

Procedimentos de teste devem ser descritos desde a fase de

especificao.


7/181Guilherme Motta

Quando realizamos testes, como saber se j testamos o suficiente?

Respostas pragmticas:

Voc jamais ter completado a atividade de teste, a cargasimplesmente transfere-se do projetista para o cliente.

Quando estiver sem tempo ou sem dinheiro.

Respostas analticas:

Com planejamento, identificando as funes de maior impactopara o cliente e executando todo o ciclo de testes para essasfunes.

Avaliando e priorizando os riscos referentes aos Testes deSoftware.

Quando terminam os testes?

7


8/181Guilherme Motta

Quando terminam os testes?

8

Modelo Logartmico do Tempo de Execuo de Poisson.

A intensidade de erros real pode ser traada em relao a curva prevista.


9/181

Guilherme Motta 9

Motivao para realizao de Testes de Software

Existe grande possibilidade de injeo de falhas humanas no processode desenvolvimento de software;

O processo de testes faz parte da garantia de qualidade de software

(SQA);

Os custos associados s falhas de software justificam um processo de

testes cuidadoso e bem planejado;

Do ponto de vista psicolgico, o teste de software uma atividade com

um certo vis destrutivo, ao contrrio de outras atividades do processo

de software.


10/181

Guilherme Motta 10

Finalidade dos Testes de Software

Verificar se todos os requisitos do sistema foram corretamente implementados;

Assegurar, na medida do possvel, a qualidade do software produzido;

Reduzir custos de manuteno corretiva e retrabalho;

Assegurar a satisfao do cliente com o produto desenvolvido;

Produzir casos de teste que tenham elevada probabilidade de revelar um erro

ainda no descoberto com uma quantidade mnima de tempo e esforo;

Comparar o resultado dos testes com os resultados esperados a fim de

produzir uma indicao da qualidade e da confiabilidade do software;

Verificar a correta integrao entre todos os componentes do software.


11/181

Guilherme Motta 11

Princpios [Myers79]

Caso de teste = entrada (dados de teste) + sada esperada; Dados de teste devem ser definidos para dados vlidos, invlidos e

inoportunos;

Evite testar seus prprios programas, a menos que seja com auxlio

de uma ferramenta;

Determine se o software faz o que esperado, mas tambm se no

faz algo indesejvel;

Nunca planeje testes assumindo que falhas no sero encontradas.


12/181

Guilherme Motta 12

Princpios [Myers79]

Nunca jogue fora casos de teste, a no ser que esteja jogando osoftware fora tambm;

A probabilidade de detectar falhas em uma parte do software

proporcional ao n de falhas j detectadas;

Um bom caso de teste aquele que tem alta probabilidade de

detectar novas falhas;

Verifique cuidadosamente os resultados de cada caso de teste;

Testes devem ser planejados desde o incio do desenvolvimento.


13/181

Guilherme Motta

Perspectiva de Teste

Bons testadores necessitam de um conjunto especial de habilidades.

Um testador deve abordar um software com a atitude de questionar

tudo sobre ele (McGregor e Sykes, 2001).

A perspectiva de teste , um modo de olhar qualquer produto de

desenvolvimento e questionar a sua validade.

Habilidades requeridas na perspectiva de teste:

Querer prova de qualidade,

No fazer suposies,

No deixar passar reas importantes,

Procurar ser reproduzvel.

13


14/181

Guilherme Motta

Perspectiva de Teste

A perspectiva de teste requer que um fragmento de softwaredemonstre no apenas que ele executa de acordo com o

especificado, mas que executa apenas o especificado

(McGregor e Sykes, 2001).

O software faz o que deveria fazer e somente isso?

14


15/181

Guilherme Motta 15

Prtica 1 Fundamentos de Teste de Software

1 No contexto de Fundamentos de Teste de Software conceitue, ou responda, os itensabaixo relacionados:

Testes de Software;

Casos de Teste;

Resultado Esperado;

Falha e Defeito (Qual a diferena?);

Viso Construtiva e Viso Destrutiva (Qual a diferena?);

Dados de Teste: Vlidos; Invlidos;

Inoportunos.

Testes Positivos e Testes Negativos (Qual a diferena?);

Perspectiva de Teste.


16/181

Guilherme Motta 16

2 Verificao e Validao V&V


17/181

Guilherme Motta 17

Verificao & Validao

A atividade de teste de software um elemento de um tema mais amplo

chamado Verificao e Validao (V&V).

As atividades de Verificao e Validao (V&V) visam garantir,

respectivamente, que:

Verificao - o software est sendo desenvolvido corretamente,

Validao - o software que est sendo desenvolvido o software

correto.


18/181

Guilherme Motta

V&V: Esttica x Dinmica

As atividades de V&V costumam ser divididas em estticas e dinmicas:

As estticas no requerem a execuo ou mesmo a existncia de um programa

ou modelo executvel para serem realizadas.

As dinmicas se baseiam na execuo de um programa ou modelo (Delamaro et

al., 2007).

Inspees de software (V & V esttica):

Anlise da documentao e cdigo fonte do software;

Pode ser auxiliado por ferramentas de depurao.

Testes de software (V & V dinmica):

O programa ou um prottipo devem ser executados;

Casos de testes deve ser elaborados: dados de entrada e comportamento

esperado.

18


19/181

Guilherme Motta

V&V: Esttica x Dinmica

19


20/181

Guilherme Motta

Plano de V&V

20


21/181

Guilherme Motta 21

Prtica 2 Verificao e Validao

1 No contexto da Verificao e Validao conceitue, ou responda, os itens abaixo

relacionados:

Verificao;

Validao;

Atividade Dinmicas e Estticas;

Quando deve ocorrer a Verificao e a Validao?

O que deve ser Verificado e Validado?


22/181

Guilherme Motta 22

3 Teste de Software e o Ciclo de Vida do Software


23/181

Guilherme Motta

Modelo em V

23


24/181

Guilherme Motta 24

Os itens abaixo indicam as caractersticas para um bom teste para

qualquer modelo de ciclo de vida: Para todas as atividades do desenvolvimento h uma atividade deteste correspondente.

Cada nvel de teste tem um objetivo especfico daquele nvel. A anlise e modelagem do teste para um dado nvel de teste devem

comear durante a atividade de desenvolvimento correspondente. Testadores devem se envolver na reviso de documentos o mais

cedo possvel utilizando as primeiras verses disponveis ao longociclo de desenvolvimento.

Ciclo de Desenvolvimento e Ciclo de Testes de Software


25/181

Guilherme Motta 25

Ciclo de Desenvolvimento e Ciclo de Testes de Software


26/181

Guilherme Motta

Classificao dos Testes de Software

Podemos classificar os mtodos de teste de acordo com suas

caractersticas bsicas. Existem testes : Caixa Preta e Caixa Branca; Estticos e Dinmicos; Testes Estruturais e Funcionais;

Testes de Unidade e Integrao; Testes de Validao; Testes Alfa e Beta; Testes de Recuperao; Testes de Segurana; Testes de Regresso; Testes de Estresse e Testes de Desempenho.

26


27/181

Guilherme Motta

Descrio (1)

Pode-se descrever cada um destes testes de software da seguinte

forma:

27

Testes Caixa Branca (White Box) Visam avaliar o cdigo, a lgica interna do componente

codificado, as configuraes e outros elementos tcnicos.

Testes Caixa Preta (Black Box) Visam verificar a funcionalidade e a aderncia aos requisitos,

em uma tica externa ou do usurio, sem se basear emqualquer conhecimento do cdigo e da lgica do componentetestado.


28/181

Guilherme Motta

Descrio (2)

Testes Estticos ou Testes Humanos No so feitos atravs da execuo real do programa, mas sim

atravs da execuo conceitual do mesmo. Mtodos classificados como estticos so o de walkthrough,

inspees epeer rating.

So utilizados principalmente para validar as primeiras etapas doprojeto, como o de elicitao de requisitos, projeto preliminar e projeto

detalhado, podendo ser usados para validar o cdigo tambm.

Testes Dinmicos Requerem que o programa seja executado, e por isso seguem o

modelo tradicional de teste de programa, no qual o programa

executado com alguns casos de teste e os resultados da execuoso examinados para verificar se o programa operou de acordo com oesperado.

So usados principalmente na validao do cdigo em mdulos e naintegrao geral do sistema.

28


29/181

Guilherme Motta

Descrio (3)

Testes Funcionais Caractersticas do domnio do negcio so examinados, para que se tente

descobrir formas de derivar um conjunto de dados de teste representativo queconsiga exercitar completamente a estrutura do sistema.

Os dados de teste precisam ser derivados de uma anlise dos requisitosfuncionais e incluir elementos representativos de todas as variveis dodomnio.

Este conjunto deve incluir tanto dados de entrada vlidos quanto invlidos.

Testes Estruturais Diferentemente dos testes funcionais, que se preocupam com a funo que o

programa desempenha sem se preocupar com como a funo foiimplementada, o teste estrutural enfoca a implementao e a estrutura dafuno.

Embora geralmente usado durante a fase de codificao, testes estruturaisdevem ser usados em todas as fase do ciclo de vida do software nas quais osoftware representado formalmente. A inteno do teste estrutural encontrar dados de teste que tero cobertura suficiente de todas as estruturaspresentes na representao formal.

29


30/181

Guilherme Motta

Descrio (4)

Testes de Unidade O Teste de Unidade concentra-se no esforo de verificao da menor unidade de

projeto de software, o mdulo (Classe, Componente, Funo ...) Atravs do uso da descrio do projeto detalhado como guia, caminhos de

controle importantes so testados para descobrir erros dentro das fronteiras domdulo. Este teste baseia-se sempre em caixa branca, e esse passo pode serrealizado em paralelo para mltiplos mdulos. Nos testes de unidade soverificados:

1. A interface com o mdulo testada para ter a garantia de que as informaes fluem para dentro e parafora do mdulo que se encontra em teste;

2. A estrutura de dados local examinada para ter a garantia de que os dados armazenadostemporariamente mantm sua integridade durante todos os passos de execuo de um algoritmo;

3. As condies de limite so testadas para ter a garantia de que o mdulo opera adequadamente noslimites estabelecidos para demarcarem ou restringirem o processamento;

4. Todos os caminhos independentes atravs da estrutura de controle so exercitados para ter a garantiade que todas as instrues de um mdulo foram executadas pelo menos uma vez;

5. Todos os caminhos de tratamento de erros so testados.

6. O procedimento comumente utilizado para teste de unidade envolve o desenvolvimento de umsoftware driver e/ou stub para cada unidade de teste.

Driver um programa principal que aceita dados de caso de teste, passa tais dados para o mdulo a ser testado e imprime os dados relevantes.

Os stubs servem para substituir mdulos que estejam subordinados ao mdulo a ser testado. Um stub ou programa simulado, usa a interface domdulo subordinado, pode fazer manipulao de dados mnima, imprime verificao de entrada e retorna.

30


31/181

Guilherme Motta

Descrio (5)

Testes de Integrao O teste de integrao uma tcnica sistemtica para a construo da

estrutura de programa, que ao mesmo tempo procura descobrir errosrelacionados interface.

O objetivo , a partir dos mdulos testados no nvel de unidade, construira estrutura do programa que foi determinada pelo projeto.

A integrao pode ser incremental ou no-incremental:

A integrao no-incremental, executada atravs da abordagem do big-bang,combinando-se antecipadamente todos os mdulos no costuma ser eficaz,dada a amplitude de um teste do programa como um todo.

J a integrao incremental mais eficiente, podendo seguir a abordagemtop-down ou a bottom-up:

31


32/181

Guilherme Motta

Descrio (5)

Testes de Integrao Incremental

32


33/181


34/181

Guilherme Motta

Descrio (6)

Testes de Integrao Incremental Top Down

34


35/181

Guilherme Motta

Descrio (7)

Testes de Integrao J a integrao incremental mais eficiente, podendo seguir a

abordagem top-down ou a bottom-up:Bottom-up - inicia a construo e os testes com mdulos atmicos, ou seja,mdulos localizados nos nveis mais baixos da estrutura do programa.

Uma vez que os mdulos so integrados de baixo para cima, oprocessamento exigido para os mdulos subordinados em determinado nvel

est sempre disponvel, e a necessidade de stubs eliminada.Uma estratgia de integrao bottom-up pode ser implementada com osseguintes passos:

1) mdulos de baixo nvel so combinados em clusters (ou construes) que executam umasubfuno de software especfico;

2) Um driver (um programa de controle para teste) escrito para coordenar a entrada e a sadado caso de teste;

3) O cluster testado; 4) Os drivers so removidos e os clusters so combinados ao se dirigir para cima na estrutura de

programa.

A principal desvantagem da integrao bottom-up que o programa noexiste como entidade at que o ltimo mdulo seja adicionado.

35


36/181

Guilherme Motta

Descrio (7)

Testes de Integrao Incremental Botton-up

36


37/181

Guilherme Motta

Descrio (7)

Testes de Validao O teste de validao pode ser considerado bem sucedido quando

o software funciona da maneira esperada pelo cliente. Ou seja verifica-se se o produto certo foi construdo, seguindo a

especificao de requisitos do software.

A validao do software, na fase de testes, realizada por meio

de uma srie de testes de caixa preta que demonstram aconformidade com os requisitos.

Testes de validao podem e devem ser feitos na etapa deprojeto, podendo ser usada uma tcnica formal e esttica para asfases iniciais.

Um plano de teste esboa as classes de teste a serem realizadase um procedimento de teste define os casos de teste especficosque sero usados para demonstrar a conformidade com osrequisitos.

37


38/181

Guilherme Motta

Descrio (8)

Testes Alfa e Beta So os testes de aceitao, feitos pelo usurio, que dificilmente opera o

sistema da forma prevista, e visam descobrir erros cumulativos quepoderiam deteriorar o sistema no decorrer do tempo.

O teste alfa executado por um cliente nas instalaes dodesenvolvedor. Esse teste usado num ambiente natural com odesenvolvedor acompanhando e registrando erros e problemas de uso,

em ambiente controlado. J o teste beta realizado em uma ou mais instalaes do cliente pelo

usurio final do software.

Geralmente o desenvolvedor no est presente. Assim, o teste beta uma aplicao viva do software, num ambiente que no pode sercontrolado pelo desenvolvedor

Os problemas so registrados pelo usurio e repassados regularmenteao desenvolvedor, que corrige o software antes de lanar o produto paravenda.

38


39/181


40/181

Guilherme Motta

Descrio (10)

Testes de Estresse O teste de estresse feito para confrontar o sistema com situaes

anormais. O teste de estresse executa o sistema de forma que exigerecursos de infraestrutura em quantidade, freqncia ou volumeanormais.

Teste de Desempenho O teste de desempenho idealizado para testar o desempenho de run-

time do software dentro do contexto de um sistema integrado.

O teste de desempenho ocorre dentro do contexto de um sistemaintegrado e ao longo de todos os passos do processo de teste.

Algumas vezes os testes de desempenho so combinados com os de

estresse e freqentemente utiliza-se instrumentao de hardware e desoftware, para medio dos recursos com ciclo de processador, porexemplo.

40


41/181

Guilherme Motta

Fases de Teste

De uma forma geral, pode-se estabelecer como fases testes de

software (Delamaro et al., 2007):

Teste Esttico;

Teste Funcional;

Teste de Unidade;

Teste de Integrao;

Teste de Sistema;

Teste de Homologao (Aceitao).

41


42/181

Guilherme Motta

Quadro Resumo

42

Fases Tipos de Testes Caractersticas

Testes

deBaixo

Nvel

Teste Unitrio Estrutura Interna;

Funcionalidade;Usabilidade;

Segurana.

Caixa Branca e Caixa Preta;

Testa partes do software;

Requer conhecimento da estrutura interna;

Executada pelo desenvolvedor.

Teste Integrado Interfaces;

Dependncias entre componentes.

Caixa Branca e Caixa Preta;

Testa integraes entre partes do software;

Requer conhecimento da arquitetura interna do software;

Executada pelo desenvolvedor.

Testes

de AltoNvel

Teste Funcional Requisitos Funcionais;

Usabilidade.

Caixa Preta;

Os testes so aplicados em partes funcionais do software; No requer conhecimento da estrutura interna do software;

Requer ambiente prprio (ambiente de teste), semelhante ao de

produo;

Executada pelo Analista de Qualidade.

Teste de Sistema Requisitos Funcionais;

Requisitos No Funcionais:oCarga (estresse);oPerformance;oSegurana;o

Instalao;oetc.

Caixa Preta;

Os testes so aplicados no software como um todo;

No requer conhecimento da estrutura interna do software;

Requer ambiente muito semelhante ao da produo (Ambiente de

Homologao);

Executada pelo Analista de Teste e Responsveis Tcnicos do

projeto / manuteno.

Homologao Requisitos Funcionais;

Usabilidade;

Requisitos No Funcionais:oCarga (estresse);oPerformance;oSegurana;oInstalao;oetc.

Caixa Preta;

Os testes so aplicados no software como um todo;

No requer conhecimento da estrutura interna do software;

Requer ambiente muito semelhante ao da produo (Ambiente de

Homologao);

Executada pelo Cliente e Analista de Negcio.

Prtica 3 Teste e o Ciclo de Vida do Software


43/181

Guilherme Motta 43

Prtica 3 Teste e o Ciclo de Vida do Software

1 Qual o principal objetivo da representao do Modelo em V?

2 Ciclo de Vida de Teste Alm de identificar defeitos e falhas, informe qual outro objetivopode ser atribudo ao Ciclo de Vida de Teste?

3 Qual a diferena entre Testes Caixa Preta e Caixa Branca? Cite exemplos.

4 Apresente um exemplo prtico, para cada um dos tipos de teste apresentados, que

comprove a real necessidade de execuo.

5 Cite as caractersticas principais dos Testes de Integrao Incremental.

6 Analise a situao abaixo e responda:


44/181

Guilherme Motta 44

4 Tcnicas para Testes Estticos


45/181

Guilherme Motta

Tcnicas de Teste Esttico

As tcnicas de teste esttico se diferem dos testes de software porno requerem a execuo do software que est sendo testado.

Este tipo de verificao representa a forma de testar (revisar)artefatos gerados ao longo do ciclo de vida do software (incluindo ocdigo) antes e/ou aps a execuo dos testes de software (testesdinmicos).

Defeitos detectados durante os testes estticos ocorrem normalmentenas etapas iniciais do processo de desenvolvimento, desta forma,requerem menor esforo de retrabalho.

Menor esforo de retrabalho significa correes a um custo beminferior, do que quando o defeito detectado e removido durante os

testes dinmicos.

45


46/181

Guilherme Motta

Tipos de Tcnicas Estticas

Diversos tipos de testes estticos so encontrados na literatura especializadae, na prtica, comum que o mesmo documento (artefato) seja objeto de maisde um tipo de verificao esttica.

Por exemplo, uma reviso informal pode ser conduzida antes de umareviso tcnica, ou uma inspeo pode ser executada em uma especificaode requisitos antes de um acompanhamento(walkthrough) com clientes.

46


47/181

Guilherme Motta

Tipo: Reviso Informal

No existe processo formal;

Discusso informal de um problema tcnico, o que muitas vezes efetivo;

Pode haver reviso em pares, onde um tcnico (ou um lder tcnico)revisa a modelagem e/ou o cdigo feito por outro tcnico;

A documentao opcional, no requer registros dos resultados dareviso; Principal propsito: uma forma de obter algum benefcio a um baixo

custo.

47


48/181

Guilherme Motta

Tipo: Acompanhamento - Walkthrough

Reunio conduzida pelo autor do artefato que est sendo revisado;

Cenrios, grupos de discusso e exerccios prticos, podem serutilizados para facilitar o entendimento por parte dos revisores (ex:clientes);

Opcionalmente h uma reunio preparatria com os revisores, comorientaes sobre a dinmica da reviso;

As sesses de Walkthrough devem contar com um redator diferentedo autor, nessas sesses devero ser produzidos: relatrios dereviso, lista de defeitos encontrados, alm do registro de todainformao til produzida;

Na prtica as sesses de Walkthrough podem variar de informal paramuito formal;

Principal propsito: aprendizagem, obter entendimento e encontrardefeitos.

48


49/181

Guilherme Motta

Tipo: Revises Tcnicas (Peer Review)

Deve ser documentado, processo de identificao de defeitos que incluitcnicos ou colegas especialistas, atuando em pares;

Pode ser feito por um colega, de mesmo perfil tcnico, com ou sem aparticipao da gerncia;

Idealmente so conduzidas por um moderador treinado (que no seja o autor); Dependendo do contexto, uma reunio preparatria pode ser necessria;

As revises tcnicas devem ser executadas com apoio de checklists; Como boa prtica deve-se gerar relatrio final da reviso, incluindo a lista de

defeitos e plano de ao para as correes. A participao do Gestor doProjeto (ou gerncia imediata) tambm visto como fator de sucesso;

Na prtica, as revises tcnicas podem variar de informal para muito formal;

Principais propsitos: discusso, tomada de decises, avaliar alternativas,encontrar defeitos, resolver problemas tcnicos e checar a conformidade dapadronizao das especificaes.

49


50/181

Guilherme Motta

Tipo: Inspees (Reviso Tcnica Formal)

Tcnica com maior grau de formalidade do que a Reviso Tcnica,tem como objetivo principal identificar e remover defeitos;

Conduzida por um tcnico moderador (que no seja o autor), ondetodos os participantes tem seus papis definidos;

Recomenda-se reunies de preparao antes das inspees;

Recomenda-se a utilizao de mtricas; Processo formal baseado em regras e utilizao de checklistcomcritrios de entrada e sada, alm da obrigatoriedade de gerarrelatrios de inspeo, lista dos defeitos encontrados e plano de aopara correo dos defeitos;

Principal propsito: controle de qualidade, ou seja, encontrardefeitos.

50


51/181

Guilherme Motta

Tipo: Anlise Esttica

O objetivo da anlise esttica encontrar defeitos no cdigo fonte do softwaree na modelagem.

Anlise esttica feita sem a execuo do software examinado pelaferramenta; j o teste dinmico executa o software.

Como as revises, a anlise esttica encontra defeitos ao invs de falhas. Ferramentas de anlise esttica analisam o cdigo do programa (ex: fluxo de

controle e fluxo de dados), gerando, como sada, arquivos do tipo HTML eXML, por exemplo.

Os benefcios da anlise esttica so: Deteco de defeitos antes da execuo do teste.

Conhecimento antecipado sobre aspectos suspeitos no cdigo ou programa atravsde mtricas, por exemplo, na obteno de uma medida da alta complexidade.

Identificao de defeitos dificilmente encontrados por testes dinmicos. Deteco de dependncias e inconsistncias em modelos de software, como links

perdidos.

Aprimoramento da manutenibilidade do cdigo e construo.

Preveno de defeitos, se as lies forem aprendidas pelo desenvolvimento.

51


52/181

Guilherme Motta

Tipo: Anlise Esttica Ferramentas

52

Prtica 4 Tcnicas para Testes Estticos


53/181

Guilherme Motta 53

Prtica 4 Tcnicas para Testes Estticos

1 Quais so as tcnicas para Teste Esttico? O que diferencia cada uma delas?

2 Qual a vantagem de utilizar checklists nos Testes Estticos?3 Para uma especificao de Casos de Uso, por exemplo, quais critrios (pelo menos 3

critrios) voc colocaria em um checklist?

4 Leia os artigos: Inspees_software_aplicadas_roteiros_teste_funcionais.pdf e

Ferramentas_para_Analise_Estatica_de_Codigos_Java.pdf. Faa suasconsideraes.

5 Comentar o diagrama abaixo:


54/181

Guilherme Motta 54

5 Fundamentos do Processo de Testes de Software

D fi i d P d T t


55/181

Guilherme Motta

Definio do Processo de Testes

O processo de teste pode ser definido como um processo separado,

mas intimamente ligado, ao processo de desenvolvimento. Issoporque eles tm metas e medidas de sucesso diferentes.

Por exemplo, quanto menor a taxa de defeitos (razo entre o no de

casos de teste que falham pelo total de casos de teste), mais bem

sucedido considerado o processo de desenvolvimento.

Por outro lado, quanto maior a taxa de defeitos, considera-se mais

bem sucedido o processo de teste (McGregor e Sykes, 2001).

55

Objetivos do Processo de Testes


56/181

Guilherme Motta 56

Objetivos do Processo de Testes

O objetivo da atividade de teste pode ser entendido da seguinte forma:

No incio de cada fase verificar se esta etapa do projeto reflete exatamente osrequisitos e definies da fase imediatamente anterior, para com isso garantirque o produto encomendado e o gerado pela atividade de desenvolvimento dosoftware ser o mesmo atravs dos diferentes nveis de refinamento doprojeto;

Verificar se no existem erros de lgica no projeto e cdigo, no fluxo de dados,no entendimento de requisitos, de codificao, tipogrficos ou de interface emtodas as fases do projeto;

Identificar e interferir na presena do erro, iniciando-se a depurao, sendo quequanto antes for descoberta a falha, menos custoso ser para adequ-la;

Ter em mente que, uma vez que errar humano e atividade dedesenvolvimento de software um exerccio bastante complexo, os errosexistem e devem ser descobertos, portanto o sucesso em um teste consisteem descobrir os erros e corrigi-los.

Et d P d T t


57/181

Guilherme Motta

Etapas do Processo de Testes

Independentemente da fase de teste, o processo de teste

inclui as seguintes etapas:

Planejamento;

Anlise de Requisitos de Teste;

Projeto de Casos de Teste;

Implementao de Casos de Teste;

Execuo ;

Anlise de Resultados e Defeitos.

57

Vi G l Ati id d d T t


58/181

Guilherme Motta

Viso Geral Atividades de Teste

58

A t ti d P d T t


59/181

Guilherme Motta

Automatizao do Processo de Teste

um ponto importante para o sucesso no teste de um software.

O processo de teste tende a ser extremamente dispendioso e muito

importante utilizar ferramentas de apoio ao teste para buscar

aumentar a produtividade.

H diversos tipos de ferramentas de teste. Ainda assim, muito

trabalho humano necessrio para criar os casos de teste

adequados ao critrio utilizado (Delamaro et al., 2007).

Uma anlise criteriosa deve ser feita para identificar o que deve e no

deve ser automatizado no Processo de Testes de Software.

59

E t t i d T t


60/181

Guilherme Motta

Estratgia de Testes (1)

60

Teste um conjunto de atividades que pode ser planejado

antecipadamente e realizado sistematicamente.

O planejamento e a realizao das atividades de teste definem a

estratgia de testes de software.

Define tcnicas de projeto de casos de teste e mtodos de testeespecficos para cada etapa do processo de engenharia de software.

Deve acomodar testes de baixo nvel e testes de alto nvel.

Oferecer orientao ao profissional, alm de um conjunto de marcosde referncia ao administrador.

Deve ser mensurvel.

Estratgia de Testes


61/181

Guilherme Motta 61

A atividade de teste inicia-se no nvel de mdulos e prossegue

"para fora", na direo da integrao de todo o sistema Diferentes tcnicas de teste so apropriadas a diferentes pontos de

tempo.

A atividade de teste deve ser realizada pela equipe dedesenvolvimento do software e por um grupo de teste

independente. As atividades de teste e de depurao so atividades diferentes,

mas a depurao deve ser acomodada em qualquer estratgia deteste.


Estratgia de Testes


62/181

Guilherme Motta 62

A formulao de uma estratgia de teste envolve a definio dos tipos

de teste que devero ser realizados, assim como, a identificao das

funcionalidades prioritrias para cada um dos tipos de teste definidos.

Isto no quer dizer que as funcionalidades no relacionadas no

devam ser testadas, mas apenas que elas no so prioritrias.


Processo de Teste Genrico (01)


63/181

Guilherme Motta

Processo de Teste Genrico(01)

PlanejarTestes

ProjetarTestes

ExecutarTestes

AnalisarResultados

Gerenciar

Defeitos

ImplementarTestes

Etapas do Processo de Teste Genrico (02)


64/181

Guilherme Motta

Etapas do Processo de Teste Genrico(02)

PlanejarTestes

ProjetarTestes

ExecutarTestes

AnalisarResultados

Gerenciar

Defeitos

ImplementarTestes

Planejar os testes adequados ao Projeto (Plano de Testes);

Identificar e mitigar os Riscos em relao aos Testes;

Cronograma dos Testes compatvel com o cronograma doProjeto;

Equipe de Teste (recursos).

PlanejarTestes



65/181

Guilherme Motta


PlanejarTestes

ProjetarTestes

ExecutarTestes

AnalisarResultados

Gerenciar

Defeitos

ImplementarTestes

ProjetarTestes

Elaborar Roteiros de Teste (Casos de Teste);

Definir Massa de Teste;

Fazer a modelagem dos Testes, identificando asvarveis, aes, resultados etc.



66/181

Guilherme Motta


PlanejarTestes

ProjetarTestes

ExecutarTestes

AnalisarResultados

Gerenciar

Defeitos

ImplementarTestes

Preparar ambientes de Teste;

Especificar a sequencia deaes para execuo dos TesteManuais;

Especificar a sequencia de

aes para os TestesAutomatizados;

Construir os scripts de teste.



67/181

Guilherme Motta


PlanejarTestes

ProjetarTestes

ExecutarTestes

AnalisarResultados

Gerenciar

Defeitos

ImplementarTestes

Executar Teste Unitrio / Integrado (RefernciaRoteiro de Teste);

Executar Teste Funcional (Referncia Roteiro deTeste);

Executar Testes de Sistema (Referncia Roteiro

de Teste);Executar Homologao;

Coletar Resultados de Teste (Medies).



68/181

Guilherme Motta


PlanejarTestes

ProjetarTestes

ExecutarTestes

AnalisarResultados

Gerenciar

Defeitos

ImplementarTestes

Definir ciclo de vida dos defeitos;

Priorizar os defeitos; Classificar os defeitos;

Analisar defeitos;

Gerar Relatrios de Defeitos.



69/181

Guilherme Motta


PlanejarTestes

ProjetarTestes

ExecutarTestes

AnalisarResultados

Gerenciar

Defeitos

ImplementarTestes

Gerar resultados dos Testes;

Indicar a Qualidade do Produto;

Avaliar a Produtividade do Processo; Realimentar Dados para Estimativa.

Prtica 5 Fundamentos do Processo de Testes de Software


70/181

Guilherme Motta 70

1 Quais so os objetivos do Processo de Testes de Software?

2 Quais so as etapas do Processo de Testes de Software? Qual a principal caracterstica

de cada etapa?

3 O que significa: Os testes devem ser mensurveis

4 - Leia o artigo: PBQP_Processo de Teste de Software Dataprev_2007.pdf. Faa suas

consideraes.

5 Considerando o Processo de Testes Genrico, informe qual (ou quais) artefato gerado

em cada uma das etapas?

Planejar

Testes

Projetar

Testes

Executar

Testes

Analisar

Resultados

GerenciarDefeitos

Implementar

Testes


71/181

Guilherme Motta 71

6 Tcnicas de Modelagem de Testes de Software

Categoria das Tcnicas de Modelagem de Testes (1)


72/181

Guilherme Motta 72

Tcnicas de Caixa_Preta ou baseada em especificao:

Forma de derivar e selecionar as condies e casos de testesbaseados na anlise da documentao seja funcional ou no-funcional, para um componente ou sistema sem levar emconsiderao a sua estrutura interna.

Caractersticas comuns das tcnicas baseadas em especificao:

Modelos, formais ou informais, so utilizados para especificaode um problema a ser resolvido, o software ou seu componente. Os casos de testes podem ser derivados sistematicamente

destes modelos.




73/181

Guilherme Motta 73

Tcnicas de Caixa-Branca (tambm chamadas de tcnicasestruturais ou baseadas em estrutura interna de um componente ou

sistema): Caractersticas comuns das tcnicas baseadas em estrutura:

Informaes sobre como o software construdo utilizada paraderivar os casos de testes. Por exemplo: cdigo e modelagem.

A extenso da cobertura de cdigo pode ser medida pelos casosde testes. Alm disto, os casos de testes podem ser derivados

sistematicamente para aumentar a cobertura.




74/181

Guilherme Motta 74

Tcnicas Baseadas em Experincia

Caractersticas comuns das tcnicas baseadas em experincia:

Conhecimento e experincia de pessoas so utilizados paraderivar os casos de testes.

Conhecimento de testadores, desenvolvedores, usurios, outrosinteressados (stakeholders) responsveis pelo software, seu uso

e ambiente. Conhecimento sobre defeitos provveis e sua distribuio.


Tcnicas Baseadas em Especificao (1)


75/181

Guilherme Motta 75

Partio de Equivalncia:

As entradas do software ou sistema so divididas em grupos que tenhamum comportamento similar, podendo ser tratados da mesma forma. Parties (ou classes) de equivalncia podem ser encontradas em dadosvlidos e invlidos (por exemplo, valores que deveriam ser rejeitados).

Parties podem tambm ser identificadas para valores de sadas, valoresinternos e valores relacionados a tempo, (antes e aps um evento) e para

parmetros de interface (durante teste de integrao). Testes podem ser elaborados para cobrir as parties. Partio de Equivalncia aplicvel a todos os nveis de testes. A tcnica de Partio de Equivalncia pode ser usada para atingir acobertura dos valores de entrada e sada.

Pode ser aplicada em uma entrada manual, interface entrada de sistema oucomo parmetro de interface num teste de integrao.




76/181

Guilherme Motta 76

Exemplo de Partio de Equivalncia

Funo:

Considere uma funo que aceita como entradas de 4 a 6 valores inteirosde 2 dgitos maiores do que 10.

Identificao das variveis de entrada e das condies que estas devemsatisfazer:

nro_entradas: pertence ao conjunto - [ 4, 6 ] Valor: pertence ao conjunto - [ 10, 99 ]




77/181

Guilherme Motta 77



Determinao das Parties (Classes) de Equivalncia

Varivel Classes Vlidas Classes invlidasnro_entradas C1: 4


78/181

Guilherme Motta 78



Casos de teste: Selecionar casos de testes cobrindo as classes vlidas das diferentes variveis.

nro_entradas C1 C2 C3 C4 C5 C6 CT nro_entradas valores

4 ... 6 X 1 5 11; 12; 45; 78; 95

< 4 2

> 6 3

valor

10 ... 99 X 4

< 10 5

> 99

Casos de testeClasses de EquivalnciaVariveis



79/181

Guilherme Motta 79



Casos de teste: Para cada classe invlida escolha um caso de teste que cubra 1 e somente 1 de cada vez.


4 ... 6 X 1 5 11; 12; 45; 78; 95

< 4 X 2 3 11; 12; 45

> 6 3

valor

10 ... 99 X 4

< 10 5

> 99




80/181

Guilherme Motta 80





4 ... 6 X 1 5 11; 12; 45; 78; 95

< 4 X 2 3 11; 12; 45

> 6 X 3 8 11, 12, 45, 78, 95,67, 77, 54

valor

10 ... 99 X 4 5 5, 11, 12, 45, 6

< 10 X 5 5 110, 45, 78, 340, 95

> 99 X




81/181

Guilherme Motta 81

Anlise do Valor Limite

O comportamento nos limites de uma partio de equivalncia onde existe

maior probabilidade de estar incorreto. Portanto, limites so reas onde testesesto mais propensos a indicar defeitos.

Os valores limites de uma partio so seu mximo e seu mnimo. Um valor limite para uma partio vlida um valor limite vlido. O limite de partio invlida um valor limite invlido.

Testes podem ser projetados para cobrir tanto valores invlidos como vlidos. Quando os casos de testes so projetados, um valor em cada limite escolhido.Anlise do valor limite pode ser aplicada em todos os nveis de teste. relativamente fcil aplic-la, sua capacidade de encontrar defeitos alta eespecificaes detalhadas podem ser teis em sua elaborao.

Esta tcnica muitas vezes considerada uma extenso da partio deequivalncia e pode ser aplicada para entradas manuais como, por exemplo, emescalas de tempo ou tabela de limites.

Valores limites podem tambm ser usados para selecionar dados de testes.




82/181

Guilherme Motta 82


Exemplo de Anlise do Valor LimiteCritrio de seleo que identifica valores nos limites das classes de equivalncia, exemplos:

Valor mnimo (mximo) igual ao mnimo (mximo) vlido; Uma unidade abaixo do mnimo; Uma unidade acima do mximo; Arquivo vazio Arquivo maior ou igual capacidade mxima de armazenamento; Clculo que pode levar a overflow (underflow);

Erro no primeiro (ltimo) registro

Mesma funo do exemplo anterior:

Considere uma funo que aceita como entradas de 4 a 6 valores inteiros de 2 dgitosmaiores do que 10.

Identificao das variveis de entrada e das condies que estas devem satisfazer: nro_entradas: pertence ao conjunto - [ 4, 6 ] Valor: pertence ao conjunto - [ 10, 99 ]



83/181

Guilherme Motta 83


Exemplo de Anlise do Valor Limite


4 ... 6 X 1 4 10, 11, 98, 99

< 4 X 2 6 10, 11, 50, 55, 98, 99

> 6 X 3 3 10, 11, 98

valor

10 ... 99 X 4 7 10, 11, 50, 55, 98, 99, 45

< 10 X 5 4 9, 10, 11, 99

> 99 X 6 4 10, 11, 100, 101



ValoresLimite



84/181

Guilherme Motta 84


Limitaes das tcnicas baseadas em Parties de Equivalncia eAnlise de Valores-Limite:

Consideram cada valor de entrada isoladamente;

Se existirem combinaes de valores que constituam situaesinteressantes a serem testadas?



85/181

Guilherme Motta 85

Tabela de Deciso

A tabela de deciso considerada uma boa alternativa para capturar requisitos de sistemasque contm condies lgicas e para documentar o comportamento interno do sistema.

Elas podem ser utilizadas para registrar regras de negcio complexas a seremimplementadas.

A especificao analisada e as condies e aes do sistema so identificadas. As condies de entrada e aes so declaradas de uma forma que possam serentendidas, como verdadeiras ou falsas (Booleano).

A tabela de deciso contm as condies que disparam as aes, muitas vezescombinaes verdadeiras e falsas para todas as condies de entrada, e aes resultantespara cada combinao de condies.

Cada coluna da tabela corresponde a uma regra de negcio que define uma nicacombinao de condies que resulta na execuo de aes associadas com aquela regra.

A cobertura padro comumente usada em uma tabela de deciso ter no mnimo um testepor coluna cobrindo todas as combinaes de condies apresentadas.

O grande ganho na utilizao da tabela de deciso que ela cria combinaes decondies que geralmente no foram exercitadas durante os testes.

Pode ser aplicada a todas as situaes quando a execuo do software depende de muitasdecises lgicas.

p ( )



86/181

Guilherme Motta 86

Tabela de Deciso

A tabela deciso pode ser utilizada para Anlise de Causa e Efeito, quando se

deseja testar combinaes de entrada. rvores de Deciso outra tcnica que tambm pode ser utilizada, quando sedeseja testar combinaes de entrada.

Definies: Causas = Condies (combinaes) de entrada (valor lgico); Efeitos = Aes realizadas em resposta s diferentes condies de entrada.

Exemplo: Causa: Preo 50 e 0 Quantidade 99;

Efeito: fornecer 5% de desconto.

p ( )



87/181

Guilherme Motta 87

rvore de Deciso

p ( )

Quantidade

Preo

Dar desconto

Cobrar preo normal

Emitir mensagem de erro

Pertence a [0, 99]

No pertence a [0, 99]

>= 50

< 50

Tabela de Deciso

Condio(Causa)

Preo >= 50 V F #

0


88/181

Guilherme Motta 88

Teste de Transio de Estados

Um sistema pode exibir respostas diferentes dependendo da sua condio atual ou deestado anterior. Neste caso, o comportamento do sistema pode ser representado como umdiagrama de transio de estados.

Permite ao testador visualizar o software em termos de estados, transies entre estados,as entradas ou eventos que disparam as mudanas de estado (transio) e as aes quepodem resultar daquelas transies.

Os estados do sistema, ou objetos sob teste, so isolados, identificveis e finitos.

Uma tabela de estado exibe a relao entre estados e entradas, e pode destacar possveistransies invlidas. Os testes podem ser construdos para cobrir uma seqncia tpica de status, cobrir todos osestados, exercitar todas as transies, exercitar uma seqncia especfica de transies outestar transies invlidas.

Teste de transio de status muito utilizada em softwares industriais embarcados eautomaes tcnicas em geral. No entanto, a tcnica tambm adequada para modelar um objeto de negcio tendo estadoespecfico ou para testar fluxos de telas de dilogos (exemplo: aplicao de internet ecenrios de negcios).

p



89/181

Guilherme Motta 89

Exemplo de Teste de Transio de Estados

Diagrama de Transio de Estados de um Livro (biblioteca)

p



90/181

Guilherme Motta 90

Exemplo de Teste de Transio de Estados

Tabela de Estados

p

Estados Entradas / Eventos / Aes

Emprestar Reservar Devolver Atualizar Retornar

E1Disponvel

E2

E2

Emprestado

E2 E4 E1; E3[ ]

E3Reservado

E2 E1

E4Atrasado

E1; E3[ ]

[ ] A transio entre estados depende do atendimento condio.



91/181

Guilherme Motta 91

Exemplo de Teste de Transio de EstadosA especificao do Software de Telecomando em mquina de estados (MEF) , composta por 6 estados,46 entradas e um total de 233 transies.



92/181

Guilherme Motta 92

Teste de Caso de Uso

Testes podem ser especificados a partir de casos de uso ou cenrios de negcios.

Um caso de uso descreve interaes entre os atores (usurios e o sistema) que produz umresultado relevante para um usurio do sistema. Cada caso de uso tem pr-condies, que precisam ser garantidas para que o caso de usofuncione com sucesso.

Cada caso de uso finalizado com uma ps-condio que representa os resultadosobservados e o estado final do sistema aps o trmino do caso de uso.

Um caso de uso normalmente tem um cenrio mais comum (mais provvel), e algumasvezes ramificaes.

Caso de uso descreve o fluxo de processo de um sistema baseado nas suas possibilidadesde utilizao.

Os casos de testes derivados de casos de uso so muito teis na descoberta de defeitos nofluxo do processo durante a utilizao do sistema no mundo real.

Casos de uso muitas vezes so tratados como cenrios, e teis para construir testes deaceite com a participao do usurio final.

Eles podem ajudar a descobrir defeitos de integrao causados pela interao einterferncia de diferentes componentes, que testes individuais de componentes podem noter detectado.



93/181

Guilherme Motta 93

Exemplo Teste de Caso de Uso



94/181

Guilherme Motta 94

Exemplo Teste de Caso de UsoNome: Registrar contrato

Ator: Vendedor

Evento: Vendedor fecha novo contratoDescrio: Este caso de uso responsvel pelo cadastramento denovos contratos no sistema.

Curso Normal:

1 - O vendedor informa o CNPJ do cliente;

2 - O sistema verifica que o cliente est cadastrado e apresenta seunome;

3 - O sistema apresenta os tipos de equipamentos cadastrados;

4 - O vendedor informa os equipamentos que faro parte do contrato(para cada equipamento, o vendedor seleciona um tipo deequipamento apresentado e informa seu nmero de srie e data defabricao);

5 - Vendedor informa dados bsicos do contrato (o vendedor deveinformar a data de incio, data de trmino e a quantidade de cotas

de pagamento);6 - O sistema registra o contrato (o sistema faz o registro docontrato, informando sua data de inicio e data de trmino, e gera umnmero seqencial nico independente do cliente);

7 - O sistema registra os equipamentos do contrato (cadaequipamento registrado no contrato recebe um nmero demanuteno gerado pelo sistema);

8- O sistema registra as cotas de pagamento docontrato (com base nas informaes fornecidas pelovendedor referentes a quantidade de cotas, data

base de pagamento e pesquisando o valor demanuteno de cada tipo de equipamento o sistemacalcula e registra o valor das cotas de pagamento docontrato);

Curso Alternativo Passo 2:

Evento: O cliente no est cadastrado.

O sistema gera um aviso de cliente no cadastrado;

ESTENDER Cadastrar Cliente;

O sistema apresenta o nome do cliente;

Retornar ao passo 3.



95/181

Guilherme Motta 95


Casos de Teste 1



96/181

Guilherme Motta 96


Casos de Teste 2



97/181

Guilherme Motta 97


Casos de Teste 3

Tcnicas Baseadas em Estrutura (1)


98/181

Guilherme Motta 98

Nveis:

Nvel de Componente:

A estrutura o prprio cdigo, ex: comandos, decises e desvios. Nvel de Integrao:

A estrutura pode ser uma rvore de chamadas (um diagrama em queum mdulo chama outros mdulos).

Nvel de Sistema: A estrutura pode ser uma estrutura de menu, processos de negciosou estruturas das pginas Web.



99/181

Guilherme Motta 99

Testes baseados em estrutura, no nvel componente, so baseados no cdigo e visamexercitar estruturas de controle (instrues) e de dados de um programa.

Esses testes, na verdade, exercitam o caminho (Testes de Caminho) com objetivo degarantir que o conjunto de casos de teste atenda aos caminhos realizados pelo programa,verificando se os caminhos so executados pelo menos uma vez.

Para o Teste de Caminho, elabora-se um Grafo de Fluxo de Programa, onde os ns,representam os blocos de comando do programa, e os arcos (arestas ou ramos) representamos fluxos de controle.



100/181

Guilherme Motta 100

Exemplo de Grafo de Fluxo de Controle



101/181

Guilherme Motta 101

Teste e Cobertura de Comandos

No teste de componente, cobertura de comando avaliado pela porcentagem de

comandos executveis que foram exercitados por um conjunto de casos de testes. No teste de comandos deriva-se os casos de teste para executar comandosespecficos, normalmente para se aumentar a cobertura.

Normalmente so utilizadas ferramentas para dar o suporte aos testes de estruturado cdigo.


102/181



103/181

Guilherme Motta 103

Teste e Cobertura de Deciso

Cobertura de deciso, tambm chamada de teste de ramificao, avaliada pela

porcentagem dos resultados da deciso (por exemplo, as opes Verdadeiro ouFalso de uma expresso condicional - IF) que foram exercitados em um conjuntode casos de teste.

No teste de deciso derivam-se os casos de testes para executar decisesespecficas, normalmente para se aumentar a cobertura.

Teste de deciso uma forma de teste de controle de fluxo, j que ele gera umfluxo especfico atravs dos pontos de decises.

A cobertura de deciso mais eficiente que a cobertura de comandos: 100% dacobertura de deciso garante 100% da cobertura de comandos, mas no vice-versa.

Normalmente so utilizadas ferramentas para dar o suporte aos testes de estruturado cdigo.



104/181

Guilherme Motta 104

Exemplo de Grafo de Fluxo para Testes e Cobertura de Deciso



105/181

Guilherme Motta 105

Complexidade Ciclomtica (McCabe)

O nmero de caminhos independentes no cdigo igual complexidadeciclomtica.

Clculo da Complexidade Ciclomtica:CC = Nmero de ramos - Nmero de ns + 2 (Nmero de Componentes Ligados)

Complexidade Ciclomtica determina o nmero de casos de teste mnimo paratestar adequadamente todos os caminhos independentes do programa.

Frmula Mgica (McCabe) de Complexidade Ciclomtica:CC = Quantidade de Decises + 1

OBS: Considerando a anlise de um programa que tenha apenas um ponto de entrada e um de sada.



106/181

Guilherme Motta 106

Exemplo de Clculo de Complexidade Ciclomtica (McCabe)

Clculo da Complexidade Ciclomtica:

CC = Nmero de ramos - Nmero de ns + 2 (Nmero de Componentes Ligados)

Clculo:

Nmero de Ramos = 12

Nmero de Ns = 10

Nmero de Componentes Ligados = 1 (nico componente)

CC = 12 10 + 2 = 4 Casos de Teste

Tcnicas Baseadas em Experincia (Teste Exploratrio)


107/181

Guilherme Motta 107

Possivelmente a tcnica mais amplamente aplicada a de supor (adivinhar) onde esto oserros.

Os testes derivam da intuio e conhecimento dos testadores com sua experincia emaplicaes e tecnologia similares. Quando usado para aumentar a tcnica sistemtica, testes intuitivos podem ser teis paraidentificar testes especficos que no so facilmente identificados pelas tcnicas formais.

Especialmente quando aplicado aps ter estabelecido o processo mais formal. No entanto,esta tcnica pode produzir amplas variedades e graus de eficincia, dependendo daexperincia do testador.

Uma abordagem estruturada da tcnica de deduo de erros enumerar uma lista depossveis erros e construir testes com objetivo de atacar/cobrir estes erros.

Estas listas de defeitos e falhas podem ser construdas com base na experincia, dados dedefeitos/falhas disponveis e do conhecimento comum de como o software falha.

Teste exploratrio ocorre simultaneamente modelagem, execuo e registro de teste, e

baseia-se nos objetivos de teste, onde realizado em um tempo predefinido. uma abordagem muito usual, em locais onde a especificao rara ou inadequada eexiste grande presso por conta de prazo, ou para aprimorar/complementar um teste maisformal.

Tcnicas Baseadas em Experincia (Teste Exploratrio)


108/181

Guilherme Motta 108

Exemplo Teste Exploratrio

Prtica 6 Tcnicas de Modelagem de Testes de Software


109/181

Guilherme Motta 109

1 Quais so as categorias das tcnicas de modelagemde testes? E qual o objetivo de fazer a modelagemde testes?

2 Escolha uma das tcnicas baseadas em especificaoe outra baseada em estrutura. Crie um exemplopara cada uma delas, diferentes dos apresentadosem sala, que comprove a utilidade dessas tcnicas.

3 Leia o artigo:Metodologia_Criacao_Massa_Testes_Rastreaveis.pdf. Faa suas consideraes.

4 - Para o Caso de Uso descrito ao lado, desenvolvaCasos de Teste que verifiquem:

A funcionalidade de Verificar a Validade da Conta Corrente item 4 do Fluxo Bsico;

A funcionalidade de Validar senha para autorizao detransferncia item 8 Fluxo Bsico.

A funcionalidade de Verificar Saldo de Conta item 7 doFluxo Bsico.


110/181

Guilherme Motta 110

7 Gerenciamento de Testes de Software

As Organizaes e o Teste de Software (1)


111/181

Guilherme Motta 111

A eficcia na procura por defeitos e falhas, em revises e testes, pode seraperfeioada em funo do grau de dependncia dos testadores e analistas deteste de uma organizao.

Os graus de dependncia so: Nenhum testador independente. Os desenvolvedores testam seu prpriocdigo.

Testadores independentes provenientes da prpria equipe dedesenvolvimento.

Equipe de teste independente ou grupo dentro da organizao, reportando aum gerente de projeto ou diretor executivo.

Testadores independentes da organizao do negcio, dos usurios e darea de TI.

Especialistas em teste independente para um objetivo especfico de teste,como testes de usabilidade, segurana ou certificao (que certifica se osoftware est em conformidade com as normas e padres).

Equipe de teste terceirizada ou independente da organizao.

As Organizaes e o Teste de Software (2)


112/181

Guilherme Motta 112

Para projetos longos, complexos e crticos, normalmente melhor ter vrios nveis deteste, com algum ou todos os nveis efetuados por equipes independentes de teste.

A equipe de desenvolvimento pode participar do teste, especialmente para os testes debaixo nvel, mas sua falta de objetividade muitas vezes limita a efetividade do teste.

Equipes independentes de teste devem ter a autoridade para requisitar e definir osprocessos de teste e suas regras, mas os testadores teriam que exercer estas funessomente sob um claro gerenciamento.

Os benefcios da independncia da equipe de testes so: Testadores independentes conseguem enxergar outros defeitos e so imparciais.

Um testador independente capaz de verificar concepes pessoais criadas durante aespecificao e implementao de um sistema.

As desvantagens incluem: Isolamento da equipe de desenvolvimento (se for tratado com independncia total).

Equipe pode se tornar um gargalo, considerando-se o ltimo ponto de controle.

Os desenvolvedores podem perder o senso da responsabilidade pela qualidade. A atividade do teste deve ser realizada por pessoas com uma funo especfica de teste.

Profissionais de Teste de Software (1)


113/181

Guilherme Motta 113

Para garantir que o Processo de Teste de Software seja adotado de forma Corporativa, necessrio que a atuao dos profissionais especializados em testes tenham focosdiferenciados, visando no somente a execuo dos projetos de testes, mas tambm na

evoluo do processo como um todo, seja na forma de otimizao dos trabalhos(automaes e simuladores) como na criao de novos controles e artefatos.

A diviso em grupos, com atuaes diferenciadas, proporcionaria empresa uma maioreficincia na conduo e melhoria dos projetos de testes de software, alm de estabelecerobjetivos e desafios a serem alcanados pelos profissionais, muito mais bem definidos esegregados.

G G i t d S i d T t



114/181

Guilherme Motta 114

Grupo: Gerenciamento dos Servios de Testes

Responsvel em atender as demandas de testes de software geradas pelas mudanas solicitadas pelosClientes.

Estas demandas devem ser priorizadas para que os esforos sejam direcionados de acordo com asexpectativas das reas Clientes (internas ou externas) e as estratgias da organizao (oportunidades ouameaas).

A limitao da equipe de testes e a produtividade do grupo estabelecem qual o nmero mximo deprojetos que a equipe poder suportar sem a necessidade de empregar a terceirizao do processo.

Nas terceirizaes, conduz e apia os projetos de testes nas negociaes com os fornecedores, sendoresponsvel pela elaborao dos contratos, estabelecendo os nveis de servios a serem contratados, osprodutos a serem entregues durante o projeto, bem como as premissas de padres de artefatos econtroles exigidos pelo modelo de testes da organizao.

Responde pelo acompanhamento e visibilidade dos projetos de testes para toda a organizao e seusClientes, mantendo todos informados sobre os riscos do projeto, etapas finalizadas e em realizao,indicadores de produtividade e qualidade alcanados pelo projeto. Alm de garantir que os projetos detestes empreguem o padro corporativo estabelecido.

Seguem os principais servios sob sua responsabilidade: Gerenciamento de Projetos e Recursos de Testes de Software;

Gerenciamento de Mtricas de Qualidade e Produtividade;

Gerenciamento de Estimativas de Testes.

G E d S i d T t



115/181

Guilherme Motta 115

Grupo: Execuo dos Servios de Testes

Responde diretamente pela execuo dos projetos de testes, pois direcionam seus esforosexclusivamente na aplicao dos casos de testes e simulaes que avaliaro o comportamento

esperado dos diversos sistemas modificados para suportar todos os requisitos estabelecidos pelosClientes.

Exercita continuamente o Processo de Teste de Software, estabelecendo um nvel de Garantia deQualidade diferenciado para cada sistema, respeitando os acordos de qualidade estabelecidos peloscritrios de importncia e risco que uma falha de implementao poder provocar nas operaes.

Profissionais com alta especializao nos processos de negcios e produtos gerenciados pela empresa,de forma a garantir que os aplicativos construdos comportam-se adequadamente com as regras de

negcios exigidas pelos Clientes. Combinam conhecimento especfico com o de negcio, complementado pelo uso de ferramentas etcnicas de testes, proporcionando reduzir esforos em cobrir um maior volume de testes num menorespao de tempo possvel.

Principais servios:

Conduo da Fbrica de Testes e Homologaes de Sistemas;

Montagem e Monitorao de Ambientes de Testes e Homologao; Gerenciamento de Reviso de Artefatos;

Gerenciamento de Preveno de Defeitos de Software.

G I d S i d T t



116/181

Guilherme Motta 116

Grupo: Inovao dos Servios de Testes

Direciona integralmente seus esforos na contnua Evoluo do Processo de Testes de forma apossibilitar que os servios de testes tenham maior controle e desempenho, proporcionando testes em

maior velocidade, volume e preciso nos resultados, refletindo na reduo de prazos, custos e noaumento da qualidade do processo.

Exercita a Melhoria Contnua do Processo de Teste de Software, estabelecendo novos controles,artefatos, indicadores, possibilitando uma evoluo na forma e conduo dos projetos de testes.

Responder pela Melhoria Contnua das Arquiteturas de Testes, mantendo a evoluo das automaese ferramentas empregadas nos servios de testes, buscando agregar novas funcionalidades e facilidadesoperacionais, reduzindo esforos e retrabalhos nos projetos de testes.

Principais servios: Consultoria em Fbrica de Testes, Homologao e Qualidade de Software;

Automao de Testes e Arquiteturas Automatizadas;

Treinamento e Certificao de Profissionais e Empresas;

Vendas e Suporte de Ferramentas de Testes e Qualidade.

Planejamento de Teste de Software (1)


117/181

Guilherme Motta 117

O planejamento pode ser documentado em um plano de teste mestre ou deprojeto separado em vrios planos de testes para diferentes nveis, assim comoteste de aceite ou teste de sistemas.

A essncia dos documentos de planejamento de teste coberta pelo Padro deDocumentao de Teste de Software (IEEE 829).

O planejamento influenciado pela poltica de teste da organizao, o escopo,objetivo, riscos, obstculos, crticas e disponibilidade de recursos.

Quanto maior for o projeto e o progresso do planejamento do testes, mais

informaes estaro disponveis e mais detalhes podem ser includos no plano.

Planejamento do teste uma atividade contnua realizada durante todo oprocesso do ciclo de vida do software.

O retorno (feedback) da atividade do teste utilizado para identificar riscos demudanas, para que ajustes no planejamento sejam efetuados.



118/181

Guilherme Motta 118

As atividades no planejamento dos testes podem incluir:

Determinao do escopo e risco, identificando os objetivos do teste.

Definio completa da abordagem do teste (estratgia de teste), incluindo a definio donvel de testes, dos critrios de entrada e sada. Integrao e coordenao da atividade de teste no ciclo de vida do software (aquisio,fornecimento, desenvolvimento, operao e manuteno).

Tomar a deciso sobre o que testar, quais as funes executaro as atividades de teste,quando e como as atividades podem ser realizadas, como o resultados dos testes sero

avaliados e quando parar o teste (critrio de sada). Programar as atividades de anlise e planejamento dos testes. Programar a implementao, execuo e validade dos testes. Designar recursos para as diferentes tarefas definidas. Definir o nvel de detalhe, estrutura e modelos para a documentao dos testes.

Escolher mtricas para monitorar, controlar a preparao e execuo do teste, resolverefeitos e apontar os riscos.

Configurar o nvel de detalhe para os procedimentos de teste de forma a proverinformaes suficientes para que o suporte possa reproduzir o incidente.



119/181

Guilherme Motta 119

Critrio de Sada

O objetivo do critrio de sada definir quando parar de testar.

Por exemplo: ao final de um nvel de teste ou quando um conjunto de testes tem um alvoespecfico.

Os critrios de encerramento podem ser constitudos de:

Mtricas como a cobertura de cdigo, riscos ou funcionalidades.

Estimativa da densidade de defeitos ou segurana nas medies. Custos. Riscos residuais, como defeitos no solucionados ou falta de cobertura de teste emalgumas reas.

Cronograma, como os baseados na data de entrega do produto.



120/181

Guilherme Motta 120

Estimativa dos Testes

Algumas abordagens:

Estimativa do esforo do teste baseado em mtricas de projetos anteriores ousimilares, ou baseado em valores tpicos. Estimativas das tarefas pelo prprio executor ou por especialistas. Estimativa de durao de testes utilizando a tcnica TPA (Test Point Analysis).

Uma vez que a estimativa do esforo do teste efetuada, recursos podem ser alocados eum cronograma pode ser elaborado.

O esforo do teste pode depender de inmeros fatores que incluem: Caractersticas do produto: a qualidade da especificao ou outra informao usadapor projetos de teste, o tamanho do produto, a complexidade do problema, os requisitospara segurana e os requisitos para documentao.

Caractersticas do processo de desenvolvimento: A estabilidade da organizao,

ferramentas usadas, processos de teste, experincia das pessoas envolvidas e pressono prazo.

As sadas do teste: o nmero de defeitos e a quantidade de re-trabalho necessria.



121/181

Guilherme Motta 121

Abordagens dos Testes

Uma maneira de classificar a abordagem do teste ou estratgia baseando-se no ponto emque comea aparecer o volume de trabalho da modelagem de teste, a saber:

Abordagem Peventiva, na qual os testes so construdos o mais cedo possvel. Abordagem Reativa, nas quais os testes so construdos aps o software e /ou

sistemas estarem prontos.

Estratgias ou abordagens tpicas incluem:

Analtica: nas quais os testes so direcionados nas reas do software ou sistema ondeapresentem maiores riscos.

Baseada em modelos: nas quais os testes so baseados em dados informaisestatsticos sobre taxa de erros (tais como erros operacionais e de segurana).

Abordagem metdica: como a baseada em falhas (incluindo deduo de erros e injeode falhas), baseadas em check-list, e baseadas em caracterstica de qualidade.

Compatvel com processos ou padres: como algumas especificadas por padres daindstria ou as vrias metodologias geis. Dinmica e heurstica: tais como os testes exploratrios onde a atividade de testar

mais reativa do que pr-planejada e onde a execuo e avaliao so tarefasconcorrentes.

Ab d d T



122/181

Guilherme Motta 122

Abordagens dos Testes

Baseada em conselhos: como os testes em que a cobertura dirigida por conselhosde especialistas em tecnologia ou negcio fora do time de teste.

Regresso: como aqueles em que h o reuso do material de teste, automaoextensiva dos testes funcionais de regresso, e um conjunto de testes padro.

Diferentes abordagens para montar uma estratgia podem ser utilizadas como, por exemplo,abordagem baseada em risco.

A escolha da estratgia do teste dever considerar o contexto, incluindo:

Risco de falha do projeto, perigo do produto em caso de falhas do software a afetar aspessoas, ambiente e a empresa.

Experincia das pessoas nas tcnicas propostas, ferramentas e mtodos. Os objetivos do teste, esforo e a misso da equipe de teste. Aspectos regulamentares, tais como alteraes internas e externas no processo de

desenvolvimento. A natureza do produto e do negcio.

O it d it d d t t iti i ibilid d b

Monitoramento e Controle dos Teste de Software (1)


123/181

Guilherme Motta 123

O propsito da monitorao do progresso do teste permitir uma visibilidade sobre asatividades do teste. As informaes a serem monitoradas podem ser coletadas manualmenteou automaticamente e serem utilizadas para medir os critrios de sada, como cobertura.

Mtricas podem ser usadas para avaliar o progresso em relao ao oramento ecronogramas planejados. As mtricas mais comuns incluem:

Porcentagem de trabalho na preparao do caso de teste (ou porcentagem de casosde testes devidamente planejados).

Porcentagem de trabalho na preparao do ambiente.

Execuo dos testes (nmeros de teste executados, testes com resultados ok e nook).

Informaes dos defeitos (densidade do defeito, defeitos encontrados e resolvidos,taxas de falha e resultado da re-execuo).

Cobertura de requisitos, riscos ou cdigo.

Confiana subjetiva do testador sob o produto

Datas dos pontos de controle.

Custo do teste, incluindo o custo comparado ao benefcio de encontrar o prximo erroou de executar o prximo teste.

R l t i d T t



124/181

Guilherme Motta 124

Relatrio do Teste

O relatrio do teste constitudo de informaes resumidas sobre o esforo do teste,incluindo:

O que aconteceu durante a o perodo do teste, e qual o melhor momento de parar. Informaes e mtricas para dar suporte na tomada de deciso e recomendaes

sobre futuras aes, tais como avaliao dos defeitos persistentes, vantagemeconmica da continuao dos testes e dos riscos considerveis apontados alm donvel de confiana no software testado.

A essncia de um relatrio de teste tratada no Padro de Documentao de Teste deSoftware (IEEE 829).As mtricas podem ser coletadas durante ou ao final do teste:

A adequao dos objetivos do teste com o nvel do teste. A adequao da abordagem/estratgia do teste.

A eficincia dos testes em respeito a seus objetivos.

C t l d T t



125/181

Guilherme Motta 125

Controle do Teste

O controle do teste descreve uma orientao ou ao corretiva tomada como um

resultado de informaes e mtricas obtidas e relatadas.Aes podem cobrir qualquer atividade do teste e qualquer atividade em um ciclode vida de um software.

Exemplos de controle de teste: Tomar decises baseadas em informaes adquiridas na monitorao dos

testes. Re-priorizar os teste quando riscos so identificados. Mudar o cronograma de acordo com disponibilidade do ambiente de teste. Definir um critrio de entrada para se iniciar o re-teste de bugs resolvidos

pelo desenvolvedor antes de aceit-lo em uma build.

O it d i t d fi t b l t i t id d d

Gerenciamento de Configurao


126/181

Guilherme Motta 126

O propsito do gerenciamento de configurao estabelecer e manter a integridade dosprodutos (componentes, dados e documentao) do software ou sistema durante todo oprojeto ou ciclo de vida do produto.

Para o teste, o gerenciamento de configurao pode garantir que: Todos os itens do software so identificados, controladas as mudanas, seus

relacionamentos, facilitando manuteno e a rastreabilidade durante todo o processode teste.

Todos os documentos e itens do software so referenciados sem ambigidade nadocumentao do teste.

Para o testador, o gerenciamento de configurao ajuda na identificao nica (e areproduo) do item testado, documentos de testes, aos testes e aos scripts de execuo detestes.

Durante o planejamento do teste a ferramenta e processos de gerenciamento deconfigurao devem ser escolhidos, documentados e implementados.

Ri d S ft

Riscos em Testes de Software (1)


127/181

Guilherme Motta 127

Risco de Software

Risco a possibilidade de sofrer perdas (impacto na qualidade do produto final,

no atraso do cronograma,no aumento de custos ou mesmo na falha doprojeto). (SEI - Software Engineering Institute)

Gerncia de Riscos

De acordo com o SEI, Gerenciamento de Risco (Risk Management) uma prticacom processos, mtodos, e ferramentas para gerenciar riscos em um projeto.

Ele fornece um ambiente disciplinado para a tomada de deciso a fim de:

Avaliar continuamente o que poderia dar errado (riscos).

Determinar quais riscos so importantes de tratar. Implementar estratgias para tratar aqueles riscos.

Classificao



128/181

Guilherme Motta 128

Classificao

Riscos de Projeto:

Engloba os eventos que comprometem ou impedem a realizao de umdado projeto. Exemplo: Problemas com oramento, cronograma, pessoal, recursos,

cliente e requisitos.

Riscos de Produto (ou Tcnicos):

Afetam a qualidade ou desempenho do software que desenvolvido. Exemplo: Problemas com implementao, interface, ambigidade de

especificao.

Os riscos tcnicos podem ser mitigados atravs de testes de software!!!!

Riscos de Negcios:

Afetam a organizao que est desenvolvendo ou adquirindo o produto. Exemplo: Problemas com o mercado, com as estratgias da empresa, com

a gerncia e com oramentos.

Teste Baseado em Riscos



129/181

Guilherme Motta 129


O teste baseado em risco (risk-based testing) consiste em um conjunto de

atividades que favorecem a identificao de fatores de riscos associados aosrequisitos do produto de software.

Uma vez identificados, os riscos so priorizados e casos de testes gerados combase nas estratgias para tratamento e acompanhamento dos fatores de riscosidentificados.

Focar em testes baseados em risco significa fazer julgamento sobre: Cobertura de teste; O nmero de testes a ser conduzido; Escolhas dos tipos de testes e de revises; Uso e balanceamento entre testes, revises e inspees, dentre outros

problemas; Priorizao dos testes (planejamento e execuo).




130/181

Guilherme Motta 130


Etapas / Atividades




131/181

Guilherme Motta131


Dificuldades:

Anlise de risco algo abstrato e necessita de conhecimento/treinamentopara sua aplicao. Engenheiros de teste no possuem formao em gerenciamento de riscos. No existe processo formal com atividades, papis e artefatos definidos

que guie os engenheiros de testes.

No foram encontradas ferramentas especficas para a abordagem, o que,provavelmente, dificulta sua aplicao e disseminao.

Modelo de Processo de Teste Baseado em Riscos



132/181

Guilherme Motta132

Modelo de Processo de Teste Baseado em Riscos

Levando em considerao que um dos objetivos do teste encontrar defeitos as

Gerenciamento de Incidentes (1)


133/181

Guilherme Motta133

Levando em considerao que um dos objetivos do teste encontrar defeitos, asdiscrepncias entre o resultado atual e o esperado precisam ser registradas como incidentes.

Incidente deve ser rastrevel desde a descoberta, classificao at correo econfirmao da resoluo.Para gerenciar os incidentes, a empresa deve estabelecer processos e regras paraclassific-los.

Incidentes podem ser descobertos durante o desenvolvimento, o teste e a utilizao dosoftware.

Eles podem se revelar por problemas no cdigo, por funes do sistema, documentao dedesenvolvimento, documentao de teste, manual de instalao ou manual do usurio.O Relatrio de Incidentes tem os seguintes objetivos:

Prover aos desenvolvedores e outros envolvidos um retorno sobre o problema parapermitir a identificao, isolamento e correo se necessrio.

Prover aos lderes de teste um meio para se rastrear a qualidade do sistema sobteste e o progresso do teste.

Prover idias para aprimorar o processo de testes.

Os detalhes de um relatrio de incidente podem incluir:

Gerenciamento de Incidentes (2)


134/181

Guilherme Motta134

Os detalhes de um relatrio de incidente podem incluir:

Data da emisso, autor, status e organizao.

Resultados esperados e resultados atuais.Identificao ou item de configurao do software ou sistema.Processo do ciclo de vida do sistema ou software em que o incidente foi descoberto.Descrio da anomalia para permitir a resoluo.Grau de impacto para os interessados (stakeholder) e severidade do impacto no sistema.

Urgncia / Prioridade na correo.Estado (status) do incidente (aberto, aceito, duplicado, aguardando resoluo, aguardandoreteste ou fechado).

Comentrios gerais, tais como outras reas que podem ser afetadas por uma mudanaresultante de um incidente.

Mudana no histrico, como a seqncia de aes tomadas pela equipe envolvida no projetocom respeito ao isolamento do incidente, reparo e confirmao da resoluo.

Referncias, incluindo a identificao da especificao do caso de teste que revelou oproblema.

A estrutura de um relatrio de incidente pode ser encontrada no Padro de Documentao de Teste deSoftware) IEEE 829, conhecido como relatrio de irregularidades (anomaly report).

Prtica 7 Gerenciamento de Testes de Software


135/181

Guilherme Motta135

1 Ler os artigos: Analise_das_Tecnicas_Estimativas_de_Esforco.pdf;

Documentation_Testing_In_Document_We_Trust.pdf;Modelo_Processo_Teste_Software_Baseado_Riscos.pdf;

QTest_Metodologia_Teste_Qualidade_Processo_Software.pdf. Faa seus

comentrios.

2 Monte um exemplo de Plano de Teste.

3 Faa avaliao de risco do estudo de caso Marketing.

4 Analise a planilha de estimativa TPA. Faa seus comentrios.

5 Analise o Relatrio de Cobertura de Testes. Faa seus comentrios.


136/181

Guilherme Motta136

8 Ferramentas de Suporte aos Testes de Software

Classificao das Ferramentas de Suporte aos Testes

Ferramentas de Suporte aos Testes de Software (1)


137/181

Guilherme Motta137

Classificao das Ferramentas de Suporte aos Testes

Ferramentas para Gerenciamento de Testes:

As ferramentas de gerncia aplicam-se a todas as atividades do teste sobre o ciclo devida do software;As caractersticas das ferramentas de Gerenciamento de Testes so:

Dar suporte ao gerenciamento de testes e a suas atividades. Fazer a interface entre as ferramentas de execuo, ferramentas de gerenciamento de

defeitos e ferramentas de gerenciamento de requisitos.

Controle de verso independente ou uma interface com o gerenciador de configurao. Dar suporte a rastreabilidade do teste, resultados, e incidentes aos documentos de

origem, como especificao de requisitos.

Registrar os resultados e gerar o relatrio de progresso do teste. Anlise quantitativa (mtricas), relacionadas aos testes (ex: testes executados e testes

que passaram) e aos objetos de teste (ex: incidentes levantados), visando fornecerinformaes sobre o objeto de teste e para controlar e melhorar o

Pos Testes Software 2010

Documents