TRIBUNAL DE JUSTIÇA DE PERNAMBUCO DIRETORIA DE INFORMÁTICA Workshop de Testes Conceitos Básicos PROSOFT Setembro/ 2010 Daniel Leitão Juliana Xavier

TRIBUNAL DE JUSTIÇA DE PERNAMBUCOTRIBUNAL DE JUSTIÇA DE PERNAMBUCO

DIRETORIADIRETORIA DEDE INFORMÁTICAINFORMÁTICA

Workshop de TestesWorkshop de TestesConceitos BásicosConceitos Básicos

PROSOFTPROSOFT

Setembro/ 2010

Daniel LeitãoDaniel Leitão

Juliana XavierJuliana Xavier

TJPE.DINFO.GEDES.UTS

Workshop de TestesAgenda

HistóricoDefiniçõesDimensões do Teste

Estágios Técnicas Tipos

Casos de TesteTestes Exploratórios

2


Workshop de TestesHistóricoHistórico

Visão Histórica da Execução dos Testes Demonstração – Década de 70

• Garantir que o produto funciona;• Testes feitos pelos desenvolvedores.

Detecção – Década de 80/90• Garantir que o produto atende aos requisitos;• Testes feitos pelos desenvolvedores e usuários.

Prevenção – Década de 90/00• Garantir que o produto funciona, atende aos requisitos e não

tem defeitos;• Testes feitos pelos desenvolvedores, usuários e testadores.

3


Workshop de TestesDefiniçõesDefinições

“É um processo de exercitar um software ou componente sob condições específicas, observando ou gravando os resultados, e realizando uma avaliação sobre algum

aspecto”. (IEEE)

“Processo de executar um programa ou sistema com a intenção de encontrar defeitos”. (Glen Myers, 1979)

“Qualquer atividade que a partir da avaliação de um atributo ou capacidade de um programa ou sistema seja possível

determinar se ele alcança os resultados desejados” (Bill Hetzel, 1988)

4


Workshop de TestesImportância dos TestesImportância dos Testes

5

PMBOK, 2008


Workshop de TestesRegra 10 de MyersRegra 10 de Myers

6

12000

Regra 10 de Myers

6000

4000

2000

0

10000

8000

The Art of Software Testing – Glenford Myers


Workshop de TestesRegra 10 de MyersRegra 10 de Myers

7

The Art of Software Testing – Glenford Myers



Para quem ainda duvida veja o que Myers afirmou

Os testes unitários podem remover entre 30% e 50% dos defeitos dos programas

Os testes de sistemas podem remover entre 30% e 50% dos defeitos remanescentes

Dessa forma, os sistemas podem ir para produção ainda com aproximadamente 49% de defeitos

Por último, ele afirma que revisões de código podem ainda reduzir entre 20% e 30% desses defeitos

8



Por que os testes executados pelos desenvolvedores não atendem?

Desenvolvedores não são técnicos de teste, ou seja, não são testadores

Desenvolvedores são mais sujeitos a pressões de prazo e custo do que uma equipe apartada

Em geral, não possuem ferramentas, metodologia etc.

9



Quanto mais crítico for o software

Mais testes serão gastos para o controle da qualidade do produto

10

Logo, quem define a quantidade

de testes é a criticidade do negócio


Workshop de TestesPapel do TestadorPapel do Testador

11

É tudo na limpeza!


Workshop de Testes

Garantia de Qualidade x Controle de Qualidade

Garantia da Qualidade de Software Foco no processo Prevenção

Controle de Qualidade de Software Foco no produto Detecção

CMMI


Workshop de TestesControle de Qualidade

Está relacionado a um produto ou serviço específico

Verifica se um produto ou serviço específico tem um atributo específico

Identifica defeitos com o propósito principal de corrigi-los

A disciplina de testes está nesse âmbito


Workshop de TestesGarantia de Qualidade

Ajuda a estabelecer e avaliar processos Identifica fraquezas em processos e os

aperfeiçoaAvalia se o controle de qualidade está

funcionandoSEPG e Equipe de Qualidade estão nesse âmbito


Workshop de TestesDimensões do Teste (IEEE)Dimensões do Teste (IEEE)

15

Técnica de Teste (como testar)

Estágios ou Níveis de Teste (quando testar)

Tipos de Teste (o que testar)


Workshop de TestesEstágios de TesteEstágios de Teste

16


Workshop de TestesTeste UnitárioTeste Unitário

17

Estágio mais baixo da escala de testes

Verifica o funcionamento de um pedaço do software que possa ser testado isoladamente


Workshop de TestesTeste UnitárioTeste Unitário

18

Sempre que possível, deve ser automatizado

Normalmente feito pelo programador na etapa de implementação


Workshop de TestesTeste de IntegraçãoTeste de Integração

19

Verifica se os componentes funcionam corretamente juntos, conforme as especificações

É alimentado pelos módulos previamente testados individualmente pelo teste de unidade


Workshop de TestesTeste de IntegraçãoTeste de Integração

20

Em geral, é feito ao término de cada iteração, dentro de um ambiente operacional controlado

Normalmente feito pelo Analista de Sistemas para um módulo ou conjunto de programas


Workshop de TestesTeste de SistemaTeste de Sistema

Visa a execução do sistema como um todo ou um subsistema (parte do sistema), dentro de um ambiente operacional controlado

21


Workshop de TestesTeste de SistemaTeste de Sistema

Valida a exatidão e perfeição na execução das funções

São realizados pela Equipe de Testes

22


Workshop de TestesTeste de AceitaçãoTeste de Aceitação

Verifica se a solução atende aos objetivos do negócio e a seus requisitos, no que diz respeito à funcionalidade e usabilidade, antes da utilização no ambiente de produção

23


Workshop de TestesTeste de AceitaçãoTeste de Aceitação

24

São os testes finais da execução do sistema, realizados pelos usuários

Executado no ambiente de homologação


Workshop de TestesModelo em VModelo em V

25

Figura 3. Modelo V descrevendo o paralelismo entre as atividades de desenvolvimento e teste de software (CRAIG e JASKIEL, 2002)

CRAIG e JASKIEL, 2002


Workshop de TestesTécnicas de TesteTécnicas de Teste

26


Workshop de TestesTestes Caixa PretaTestes Caixa Preta

Visam verificar a funcionalidade e a aderência aos requisitos em uma ótica externa ou do usuário

Não se baseiam em qualquer conhecimento do código ou da lógica interna do componente testado

27


Workshop de TestesTestes Caixa BrancaTestes Caixa Branca

Visam avaliar as cláusulas de código, a lógica interna do componente codificado, as configurações e outros elementos técnicos

Também conhecidos como Testes de Caixa de Vidro

28


Workshop de TestesTipos de TesteTipos de Teste

29

RUP


Workshop de TestesFuncionalidade

Teste FuncionalTeste de RegressãoTeste de VolumeTeste de Segurança



Teste Funcional Teste destinado a validar as funções do sistema conforme o

esperado Fornece as entradas e compara as saídas da execução do

teste com o resultado esperado Pode ser implementado e executado em diferentes estágios

de teste, como unidade, integração e sistema



Teste de Regressão Visam garantir que mudanças realizadas não geraram

impactos negativos no sistema Existem vários níveis de regressão

• Regressão Total• Regressão Básica• Regressão Seletiva

Em geral, sempre que possível devem ser automatizados



Teste de Volume Tem como objetivo verificar a capacidade do sistema de lidar

com um grande volume de dados Abrange estratégias de teste, como a entrada de dados no

volume máximo de cada campo ou a criação de consultas que retornem um grande volume de dados

Exemplos:• Relatórios com o período máximo permitido (1 ano, 2 anos etc)• Inserção de arquivos no BD com o tamanho máximo permitido

(500 MB, 1 GB etc)



Teste de Segurança Testes destinados a garantir que as funcionalidades e os

dados possam ser acessados apenas por determinados atores

Devem validar os requisitos de segurança definidos para o sistema

Objetivos• Detectar vulnerabilidades• Verificar robustez do sistema frente a determinados tipos de

ataques


Workshop de TestesUsabilidade

Testes de Usabilidade Enfatizam:

• Interface com o usuário• Acessibilidade• Estética• Ajuda on-line e contextual• Adequação a padrões

Não esquecer de utilizar o padrão de interface visual do TJPE !!!


Workshop de TestesConfiabilidade

Teste de IntegridadeTeste de EstruturaTeste de EstresseTeste de Fumaça (Smoke Test)



Teste de Integridade Testes destinados a avaliar a robustez do sistema

(resistência a falhas) Pode ser implementado e executado em vários níveis

(unidade, integração, sistema)Teste de Estrutura

Em geral, é executado em aplicativos Web Verifica se todos os links estão conectados, que o conteúdo

esperado é exibido e que não há link órfão



Teste de Estresse Destinado a avaliar como o sistema responde em condições

anormais de uso O estresse no sistema pode abranger carga de trabalho

extrema, memória insuficiente, hardware e serviços indisponíveis ou recursos compartilhados limitados

Teste de Fumaça (Smoke Test) Executam testes básicos para verificar a estabilidade da

versão Podem ser executados pela equipe de testes ou por outra

equipe


Workshop de TestesDesempenho

Teste de Carga Tipo de teste de desempenho usado para validar a

aceitabilidade dos limites operacionais de um sistema de acordo com cargas de trabalho variáveis, enquanto a configuração permanece constante

Durante os testes de carga, vários atributos do sistema são medidos

• Tempo de resposta de cada requisição, uso da CPU, uso da memória, tráfego de rede, etc


Workshop de TestesSuportabilidade

Teste de Configuração Teste destinado a garantir que o sistema funcione conforme o

esperado em diferentes configurações de hardware e/ou software

Exemplos: Navegadores, Servidores de Aplicação, Banco de Dados, etc

Teste de Instalação Teste destinado a garantir que o sistema seja instalado

conforme o esperado em diferentes configurações de hardware e/ou software


Workshop de TestesCasos de Teste

É um conjunto de entradas de teste, condições de execução e resultados esperados desenvolvidos para um objetivo específico

Os casos de testes funcionais devem conter: Identificação Única (Ex: CT001) Objetivo Pré-condições Passos (Ação e Resultado Esperado) Pós-condições



Em geral, estão associados a um requisitoPodem ser:

Positivos: têm como objetivo demonstrar que o requisito foi atendido

Negativos: refletem uma condição ou dados inaceitáveis, anormais ou inesperados para demonstrar que o sistema responde da forma esperada


Workshop de TestesDerivação de Casos de Teste

Os casos de teste funcionais são derivados a partir dos cenários dos casos de uso


Workshop de TestesDerivação de Casos de Teste

Passos para derivação dos casos de teste (Heumann) : Para cada caso de uso, gerar uma lista de cenários Para cada cenário, identificar, ao menos, um caso de teste e

a condição que o farão ser executado Para cada caso de teste, identificar os dados que serão

utilizados



Exemplo:


Workshop de TestesTestes Exploratórios

O que são testes exploratórios?

“Testes em que o testador controla ativamente o design dos testes durante a execução e utiliza informações adquiridas para projetar novos e melhores testes”

James Bach, “Exploratory Testing Explained”



Simultaneamente Aprender sobre o produto Aprender caminhos em que o produto falha Aprender os pontos fracos do produto Aprender como testar o produto Testar o produto Reportar problemas Desenvolver novos testes com o que foi aprendido até o momento



Todo testador pratica exploração em algum nível Desde os testes com roteiro aos testes ad-hoc

Em que nível o seu teste é exploratório?



Como funciona Durante um período de tempo (sessão), o testador interage

com o produto para executar uma “missão de teste” e reportar os resultados

Sessão

Tempo

Testador

Produto

Missão

Relatório



Sessão O testador recebe uma cartilha (fornecida pelo líder de

testes) que contém a missão e, possivelmente, táticas a serem usadas

• Em algumas organizações, casos de testes e procedimentos podem ser usados como cartilhas

Não deve ser muito longa• Depende do objetivo da sessão, mas uma sessão típica dura

em torno de 90 minutos



Sessão É uma unidade básica de teste Deve ser ininterrupta

• E-mails, telefonemas, conversas devem ser evitados Revisável

• Para isso, o relatório deve estar em um formato possível de ser entendido por terceiros (o gerente do projeto, por exemplo)



Exemplo de cartilha Teste todos os campos de entrada da tela “Inserir Produto”.

Lembre-se de testar limites e dados inválidos. A primeira frase estabelece a missão A segunda, táticas a serem usadas



Possível formato para relatório de sessão

Cartilha

Testador

Data/Hora

Observações

Bugs

Questionamentos



Habilidades Projetista de testes

• Todo testador exploratório é, em primeira instância, um projetista / arquiteto de testes Observador

• Testadores experientes diferem de novatos por perceberem mais facilmente comportamentos “não usuais” Crítico

• Um bom testador deve ser capaz de revisar e explicar sua lógica de achar um bug



Habilidades Crítico

• Testadores experientes tendem a usar mais heurísticas para produzir novas e melhores idéias Explorador de recursos

• Um bom testador deve estar munido de ferramentas, informações e ter contato com pessoas que possam ajudar


Workshop de Testes

Testes Exploratórios X Testes com Testes Exploratórios X Testes com RoteiroRoteiro

Conhecimento do domínio Com roteiros

• Falta de conhecimento pode ser minimizado durante a fase de projeto de testes

Com exploração• Não é possível prosseguir quando o conhecimento do

domínio é insuficiente• Treinamentos podem ser utilizados, mas introduzem

overhead

56


Workshop de Testes

Complexidade do Sistema Com roteiros

• Possibilita um projeto de testes cuidadoso que se preocupa com as dependências entre os testes

Com exploração• Reside na experiência do testador para gerenciar as

dependências entre os testes

57

Testes Exploratórios X Testes Testes Exploratórios X Testes com Roteirocom Roteiro


Workshop de Testes

Nível de documentação Com roteiros

• Requer vasta e boa documentação Com exploração

• Não requer documentação (assumindo grande conhecimento do domínio)

58



Workshop de Testes

Prazos Com roteiros

• Requer tempo para preparação Com exploração

• Não requer grande tempo inicial para preparação

59



Workshop de Testes

Recursos Disponíveis Com roteiros

• Requer maior consumo de recursos (mais pessoas) Com exploração

• Ideal quando há limitação grande de recursos

60



Workshop de Testes

Habilidades Necessárias Com roteiros

• Requer grande habilidade dos envolvidos na análise e projeto dos testes; na execução, pode usar testadores com poucas habilidades

Com exploração• Requer testadores habilidosos na arte da exploração

61



Workshop de Testes

Cobertura Com roteiros

• Há rastreabilidade entre os testes e os requisitos / especificações que os originaram. Dessa maneira, pode-se calcular a cobertura

Com exploração• Não há como calcular a cobertura de maneira precisa

62



Workshop de Testes

Verificação Com roteiros

• Verifica formalmente se o sistema está de acordo com a sua especificação

Com exploração• O sistema é comparado apenas com as expectativas e o

entendimento do testador sobre o que a aplicação deveria fazer

63



Workshop de Testes

Facilidade de reprodução Com roteiros

• Pode ser facilmente reproduzido Com exploração

• Apenas defeitos podem ser reproduzidos, os testes não.

64



Workshop de TestesDúvidas | Sugestões

65

SEPG: [email protected]

Mantis: “Processo de Software”

UTS: [email protected]

Telefone: 3419.3701

TRIBUNAL DE JUSTIÇA DE PERNAMBUCOTRIBUNAL DE JUSTIÇA DE PERNAMBUCO

DIRETORIADIRETORIA DEDE INFORMÁTICAINFORMÁTICA

Workshop de TestesWorkshop de TestesConceitos BásicosConceitos Básicos

PROSOFTPROSOFT

Setembro/ 2010

Daniel LeitãoDaniel Leitão

Juliana XavierJuliana Xavier

Documents

TRIBUNAL DE JUSTIÇA DE PERNAMBUCO DIRETORIA DE INFORMÁTICA Workshop de Testes Conceitos Básicos PROSOFT Setembro/ 2010 Daniel Leitão Juliana Xavier