1) Fundamentos dos Testes

1.1) Porque é necessário testar?

1. Contexto dos sistemas de software

Softwares que não funcionam corretamente levam a muitos problemas. Financeiro, Reputação etc..

2. Causas dos defeitos

Defeitos – Cometidos por seres humanos

Falhas – Conseqüência dos defeitos

Defeitos no software ou documentos resultam em falhas, mas nem todo defeito causa uma falha.

Porque os defeitos ocorrem:

 Ser humano passivo de falha

 Pressão no prazo

 Códigos complexos

 Complexidade na infra-estrutura

 Mudança da tecnologia

Falhas podem ocorrer por condições do ambiente:

 Radiação

 Magnetismo

 Poluição
 3. Função dos testes no desenvolvimento, manutenção e operação do software

Redução de riscos e ocorrências de problemas

Qualidade dos sistemas

Atender aos requisitos contratuais

4. Teste e Qualidade

Com ajuda dos testes é possível mediar à qualidade do software.

Projetos anteriores devem prover lições

Testes devem ser integrados, como uma atividade de garantia de qualidade

5. Quanto teste é suficiente?

Levar em consideração:

 Nível do risco

 Restrições de tempo

 Orçamento

O teste deve prover informações suficientes para tomadas de decisões sobre a distribuição do
software.
1.2) O que é teste?

Objetivos do teste:

 Encontrar defeitos

 Ganhar confiança sobre o nível de qualidade e prover informações

 Prevenir defeitos

Revisão de documentos ajuda a prevenir defeitos.

1.3) Princípios gerais do teste

 Teste demonstra a presença de defeitos

 Teste exaustivo é impossível

 Teste antecipado

 Agrupamento de defeitos

 Paradoxo do pesticida (Revisão dos casos de teste)

 Teste depende do contexto

 A ilusão de ausência de erros.

1.4) Fundamentos do processo de teste

O processo básico consiste nas seguintes atividades:

 Planejamento e controle

 Analise e modelagem

 Avaliação dos critérios de saída e relatórios

 Atividades de encerramento dos testes.

1.4.1) Planejamento e Controle

Consiste em verificar a missão dos testes, definindo seus objetivos e especificando as atividades.

1.4.2) Analise e modelagem dos testes

Principais atividades:

 Revisar a base de testes (Requisitos, Arquitetura, Modelagem e Interfaces)

 Avaliar a testabilidade dos requisitos

 Identificar condições de requisitos de teste

 Projetar e priorizar os casos de teste

1.4.3) Implementação e execução dos testes

Atividade onde os processos ou scripts de teste são especificados pela combinação dos casos de testes.

Atividades principais:

2) Teste durante o ciclo de vida de desenvolvimento do software

2.1) Modelos de Desenvolvimento de Software

 Validação [ISO9000]

 Validar que os requisitos de uso de aplicação especificada tencionada foram atendidos.

 Verificação [ISO9000]

 Verificar que os requisitos especificados foram implementados.

2.1.1) Modelo em “V”

Estrutura que descreve as atividades do ciclo de vida do desenvolvimento de software.

2.1.2) Modelos Iterativos de Desenvolvimento

Divide o projeto em uma serie de incremento cada um dos quais entrega uma porção da funcionalidade dos
requisitos gerais do projeto.

(DIVIDE O PROJETO EM PARTES)

2.1.3) Teste dentro de um ciclo de vida de desenvolvimento de software.

As características abaixo indicam um bom teste para todos e qualquer modelo de ciclo de vida de
desenvolvimento de software.

 Para todas as atividades do desenvolvimento há uma atividade de teste correspondente: EX:

 Cada nível de teste tem um objetivo especifico.

 A analise e modelagem dos testes para um nível de teste devem começar durante a respectiva
atividade de desenvolvimento.

 Testadores devem se envolver em revisões de documentos o mais cedo possível.

OBS: Níveis de testes podem ser combinados ou reorganizados dependendo da natureza do projeto ou
arquitetura do sistema.

2.2) Níveis de Teste

Conceito: Para cada nível de teste podemos identificar os seguintes aspectos:

 Objetivos Genéricos

 Produtos de Trabalho Gerados

 Objetivos específicos dos testes

 Responsabilidades

2.2.1) Teste de Componente

Objetivo: Encontrar defeitos e verificar o funcionamento do software.

Testes de componentes podem incluir:

 Teste funcional

 Teste Estrutural

Teste de componentes consiste em preparar e automatizar os casos de testes antes de codificar.

(DESENVOLVIMENTO DIRIGIDO A TESTE)

2.2.2) Teste de Integração

Objetivo: Testar interfaces entre os componentes

Teste com características NÃO-FUNCIONAIS especifica (Performance) podem ser incluídos nos testes
de integração.

Se os testes de integração for planejado antes que os componentes do sistema estejam prontos eles podem
ser preparados visando um teste mais eficiente.

2.2.3) Teste de Sistema

Objetivo: O ambiente deve corresponder ao máximo possível ao objetivo final do software.

(AMBIENTE DE PRODUÇÃO)

O teste de sistema basea-se em:

 Especificação de Risco/Requisito

 Casos de uso

 Regras de Negocio

 Outras especificações de alto nível

2.2.4) Teste de Aceite

Objetivo: Estabelecer confiança no sistema, parte dele ou em alguma característica não especifica.

É de responsabilidade do cliente ou do usuário do sistema executar este tipo de testes.

Procurar defeitos não é seu principal objetivo.

Forma de testes de aceite:

 Teste de aceite usuário

 Teste operacional de aceite

 Backup/Restore

 Segurança

 Manutenção

 Etc...

 Teste de Contrato e Regulamento

 Testes Alfa e Beta

2.3 Tipos de Teste: o alvo do teste

2.3.1) Teste Funcional

Funções representam o que o sistema faz.

Teste funcional é baseado em funções descritas em documentos ou entendidas pelos testadores

Devem ser realizadas em todos os níveis de teste

Teste funcional considera comportamento externo do software (TESTE DE CAIXA-PRETA).

2.3.2) Teste Não-Funcional

 Teste de performance

 Teste de carga

 Teste de Estresse

 Teste de Usabilidade
 Teste de Interoperabilidade

 Teste de Manutenibilidade

 Teste de Confiabilidade

 Teste de Portabilidade

Teste Não-Funcional é o teste de “COMO” o sistema trabalha.

2.3.3) Teste Estrutural

TESTE DE (CAIXA-BRANCA)

Cobertura é a extensão expressa como uma porcentagem de itens é coberta.

Se a cobertura não atinge os 100%, mais testes devem ser realizados

Teste estrutural deve ser baseado na arquitetura do sistema.

2.3.2) Teste de Confirmação e Regressão

Teste de Confirmação > Confirmar que um defeito corrigido foi realmente removido

Teste de Regressão > Teste repetitivo em um programa para assegurar que partes do sistema que
funcionavam, não apresentam defeitos após correções.

È realizado quando o software ou seu ambiente é modificado.

A quantidade de teste de regressão é baseada no risco de não se encontrar defeito em algo que já
 funcionava.

2.4) Teste de Manutenção

Iniciado por:

 Modificações = Release

 Migrações = De uma plataforma para outra

 Retirada = Migração de dados ou arquivamento

3 Técnicas Estáticas

3.1) Revisão e Processo de Teste

Revisão = Maneira de testar o software, e pode ser realizada bem antes dos testes dinâmicos.

Defeitos encontrados durante as revisões são muitas vezes mais baratos quando encontrados em testes
dinâmicos.

Atividade Manual = Revisar e comentar o produto de trabalho.

Revisão pode encontrar omissões, por exemplo, nos requisitos.

Objetivo da Revisão = ENONTRAR DEFEITOS E NÃO FALHAS.

3.2) Processo de Revisão

3.2.1) Fases de Revisão Formal

 Planejamento = Selecionar Equipe, Alocações, Critérios de Entrada e Saída

 Kick Off = Distribuição dos Documentos, Reuniões, Explicação dos Objetivos

 Preparação Individual = Trabalho feito por cada um antes da reunião de revisão

 Reunião de Revisão

 Re-trabalho = Resolver defeitos encontrados

 Acompanhamento = Checar critérios de Saída

3.2.2) Papeis e Responsabilidades

 Gerente = Toma decisões

  Moderador = Lidera as revisões dos documentos

 Revisores = Descrevem os defeitos encontrados

 Secretário

3.2.3) Tipos de Revisões

Acompanhamentos, revisões técnicas e inspeções podem ser realizados dentro do mesmo nível
organizacional. Chamado de “Peer review”.

Revisão Informal

 Não possui processo formal

Objetivo = Obter algum beneficio a baixo custo.

Acompanhamento

Objetivo = Aprendizagem, encontrar defeitos

Revisões Técnicas

 Documentado

 Conduzido pelo moderador TREINADO

Objetivo = Tomada de decisões, encontrar defeitos

Inspeção

 Processo formal

 Utilização de checklist

 Acompanhamento formal

Objetivo = Encontrar Defeitos

3.2.4) Fatores de Sucesso para as revisões

 Objetivo claro e bem definido

 Pessoas adequadas

 Defeitos expressados objetivamente

 Lidar com problemas pessoais e aspectos psicológicos

 Treinamento

 Ênfase em aprender, aprimorar o processo.

3.3) Analise Estática por Ferramentas

Analise estática pode encontrar defeitos que dificilmente são encontrados em testes dinâmicos.

Gera arquivos de saída do tipo HTML e XML.

Benefícios:

 Detecção dos defeitos antes dos testes dinâmicos

 Conhecimento antecipado de aspectos suspeitos

 Identificação de defeitos dificilmente encontrados nos testes dinâmicos

 Detecção de dependências e inconsistências como Links perdidos

  Aprimoramento da manutenibilidade do código

 Prevenção de defeitos

Defeitos Mais Comuns:

 Variáveis nunca usadas

 Código Morto

 Vulnerabilidade de segurança

 Violação de padrões de programação

4) Técnica de Modelagem em Testes

4.1)Identificando as condições de teste e projetando os casos de teste

    O nível de teste depende do contexto do teste, o que inclui:

 Organização

 Maturidade do processo de teste e desenvolvimento

 Restrições de Tempo

 Pessoas Envolvidas

    

    Um conjunto de Casos de teste consiste em:

 Valores de entrada

 Pré-condições de execução

 Resultados Esperados

 Pós-Condições de execução

 
    * RESULTADO ESPERADO DEVE SER DEFINIDO ANTES DA EXECUÇÃO DOS TESTE.

4.2) Categorias das técnicas de modelagem de teste

    O Syllabus considera:

 Técnicas baseadas em especificação ou experiência (CAIXA PRETA)

 Técnicas baseadas em estrutura (CAIXA BRANCA)

    Características comuns baseadas em especificação

 Modelos Formais ou Informais são utilizados para especificação de um problema

 Os casos de teste podem ser derivados deste modelo.

    Características comuns baseadas em estrutura

 Informações sobre como o software é construído e é utilizada para derivar os casos de teste

    Características comuns baseadas em experiência

 Conhecimento e experiência são utilizados para derivar os casos de teste

4.3) Técnicas baseadas em especificação ou Caixa Preta

    São considerados técnicas de baseadas em especificação:

 Partição de Equivalência

 Analise do Valor Limite

 Tabela Decisão

 Transição de Status

 Testes de Caso de Uso

4.3.1) Partição ou Equivalência

A técnica de participação de equivalência pode ser usada para atingir a cobertura dos valores de entrada e
saída. Usada em todos os níveis de teste

4.3.2) Analise do Valor Limite

Limites são áreas onde os testes estão mais propensos a indicar defeitos. Usado em todos os níveis de teste.

4.3.3) Tabela Decisão (Booleano)

Tabela decisão contem as condições que disparam ações, muitas vezes combinações verdadeiras e falsas para
todas as condições de entrada, e ações resultantes para cada combinação de condições.

Pode ser aplicada em todas as situações quando a execução do software depende de muitas decisões lógicas.

4.3.4) Teste de transição de status

Teste de transição de status é muito utilizada em software industriais embarcados.

4.3.5) Teste de caso de uso

Casos de uso descrevem interações entre usuários e sistemas.

Casos de uso possuem:

 Cenário
  Pré condições

 Pós condições

 Estado final

Casos de testes derivados de casos de uso são muito úteis na descoberta de defeitos no fluxo de processos
durante a utilização do sistema no mundo real.

CASOS DE USO MUITAS VEZES SÃO TRATADOS COMO CENÁRIOS, E UTEIS PARA CONSTRUIR
TESTES DE ACEITE COM A PARTICIPAÇÃO DO USUÁRIO FINAL.

4.4) Técnicas baseada em estrutura ou Caixa Branca.

 Teste de cobertura de comandos

 Cobertura de decisão

 Condições de cobertura e múltiplas condições

Conceito:

 Nível de componente: A estrutura é o próprio código (Comandos, Decisões e Desvios)

 Nível de integração: A estrutura pode ser uma arvore de chamadas (Diagramas, onde módulos
chamam outros módulos)

 Nível de sistema: Estrutura de menus, processos de negocio ou estruturas de páginas web.

4.4.1) Cobertura e comandos

No teste de comandos deriva-se os casos de testes para executar comandos específicos, normalmente
para se aumentar a cobertura.
 4.4.2) Teste de cobertura de Decisão

É avaliada pela porcentagem dos resultados de decisão que foram executados em um conjunto de
casos de teste. (ex: opções de Verdadeiro e Falso em uma condição de execução IF).

4.4.3) Outras técnicas basedas na estrutura

Cobertura de condições e cobertura de múltiplas condições.

4.5) Técnicas baseada na experiência.

4.6) Escolhendo as técnicas de teste

A escolha da técnica depende de uma série de fatores:

 Tipo de sistema

 Padrões

 Cliente

 Requisitos contratuais

 Riscos

 Objetivos dos testes

 Documentações

 Conhecimento dos testadores

 Tempo

 Dinheiro

 Ciclo de desenvolvimento
5) Gerenciamento de testes

5.1) Organização do teste

5.1.1) Organização e o teste independente

Opções para a independência nos testes

 Nenhum testador independente: Os desenvolvedores testam seus próprios códigos.

 Testadores provenientes da equipe de desenvolvimento

 Equipe de testes independentes ou grupo dentro das organizações reportam do a um gerente de

projetos.

 Testadores totalmente independentes.

 Especialistas em teste independentes para um objetivos especifico

Benefícios de se ter uma equipe independente de teste:

 Testadores enxergam defeitos e são imparciais

 Capazes de verificar concepções pessoais criadas durante a especificação

Desvantagens em não ter uma equipe independente de testes:

 Isolamento da equipe de desenvolvimento

 Equipe pode se tornar gargalo

 Desenvolvimento perdem o senso de qualidade

5.1.2) Tarefas dos Lideres de teste e dos testadores

Líder de teste: Responsável pelo planejamento, monitoração e controle das atividades e tarefas da
equipe de testes

Tarefas Líder:

 Coordenar a estratégia de teste

 Escrever e revisar a estratégia de teste

 Contribuir com a perspectiva dos testes para outras atividades

 Planejar os testes

 Iniciar especificações, preparação, implementação e execução dos testes

Tarefas Testadores:

 Revisar e contribuir no planejamento

 Criar especificações de teste

 Configurar ambiente de teste

 Executar testes.

5.2) Organização do teste

5.2.1) Planejamento dos testes

Planejamento é uma atividade continua e realizada durante todo processo de ciclo de vida do software.

5.2.2) Atividades de planejamento dos testes

Atividades no planejamento podem incluir:

 Definição do escopo e risco

 Definição completa da abordagem do teste. Critérios de entrada e saída

 Designar recursos

 Escolher métricas para monitorar, controlar a execução dos testes

5.2.3) Critérios de Saída

Objetivo de critério de saída é definir quando para de testar.

Os critérios de encerramento podem ser:

 Métricas de cobertura código, riscos de funcionamento

 Estimativas

 Custos

 Cronograma

5.2.4) Estimativa dos testes

 Estimativa dos esforços de teste baseado em métricas de projetos anteriores ou similares

 Estimativa das tarefas pelo próprio executor.

Esforços de teste podem depender de fatores que incluem:

 Características do produto: Tamanho, complexidade, Requisitos de segurança.

 Características do processo de desenvolvimento: Estabilidade da organização, ferramentas,

processos, experiência pessoal

 As saídas de teste: Numero de defeitos, quantidade de re-trabalho necessário

5.2.5) Estratégia dos testes (abordagem dos teste)

Estratégia preventiva = Os testes são construídos o mais cedo possível.

Estratégia Reativa = Os testes são construídos após o termino da construção do software.

Estratégias ou abordagens típicas incluem;

 Analítica = Os testes são direcionados para áreas onde apresentam maior risco.

 Baseada em Modelos = Os testes baseados em dados informais e estatísticas sobre as taxas de erros.

 Abordagem Metódica = Baseada em checklist, qualidade, documentos

 Compatível com processos e padrões = Metodologias ágeis

 Dinâmica Heurística = Testes exploratórios, onde atividade de testar é mais reativa que planejada.

 Baseada em conselhos = Testes dirigidos por conselhos de especialistas fora do time de testes

 Regressão = Re-uso do material de teste.

5.3) Monitoração e controle do processo de teste

5.3.1) A monitoração do progresso do teste

Permite uma visibilidade sobre as atividades do teste.

Utilizadas para medir critérios de saída.

Métricas podem ser usadas para avaliar o progresso dos testes em relação ao cronograma e orçamentos.

Métricas mais comuns incluem;

 Porcentagem dos casos de testes planejados

  Porcentagem de trabalho na preparação do ambiente de teste

 Porcentagem das falhas encontradas (Ok e Não OK)

 Informação sobre os defeitos

 Custo dos testes

5.3.2) Relatórios dos testes

Informações resumidas sobre os esforços do teste, incluindo:

 O que aconteceu durante o período de testes, e qual o melhor momento de parar.

 Informações métricas para dar suporte ao líder de testes nas tomadas de decisões

Métricas podem ser coletadas durante ou ao final dos testes

 Adequação dos objetivos com o nível dos testes

 Adequação da abordagem do teste

 Eficiência dos testes em respeito aos objetivos

5.3.3) Controle dos testes

Exemplo de controles;

 Tomar decisões baseadas em informações adquiridas na monitoração dos teste

 Re-priorizar testes quando riscos são identificados

 Mudar cronograma de acordo com a disponibilidade do ambiente de teste

 Definir critérios de entrada para re-testes.

5.4) Gerenciamento de configuração

Estabelecer e manter a integridade dos produtos de trabalho do software, durante todo o ciclo de vida do
software. (documentos, dados, componentes).

Gerenciamento pode garantir que:

 Todos os itens são identificados, controladas as mudanças, seus relacionamentos, facilitando a

rastreabilidade e a manutenção dos defeitos

 Todos os produtos de trabalho do software são referenciados sem ambigüidade na documentação do

teste.

Para os testadores, ajuda na identificação e reprodução dos itens testados, documentados, e na execução de
scripts de teste

Durante o planejamento deve ser definido, configurado e implementado as ferramentas e configurações de

controle.

5.5) Riscos e testes

Riscos = Uma chance de um evento indesejável acontecer, causando um dano em potencial

Os riscos podem ser determinados pela POSSIBILIDADE de ocorrerem X os DANOS que podem causar.

5.5.1) Risco no projeto

São aqueles que comprometem a capacidade do projeto em não atender seus objetivos

Fatores organizacionais:

 Falta e conhecimento da equipe

  Reciclagem e treinamento do pessoal

 Políticos

 Problemas com os testadores na obtenção dos resultados dos testes

 Dificuldades na comunicação

Fatores técnicos

 Problemas na definição correta dos requisitos

 Requisitos X Restrições

 Qualidade na modelagem do código de teste

Problemas do fornecedor

 Problemas com terceiros

 Problemas contratuais

OBS: DOCUMENTAÇÃO IEEE 829, DECLARA QUE RISCOS E CONTIGENCIA DEVEM SER
DECLARDOS.

5.5.2) Risco do produto

Áreas de potencial falhas no software são consideradas com risco de produto, pois são consideradas risco
para a qualidade final do software.

Exemplos:

 Software instável

 Software com características pobres (usabilidade, funcionalidade, segurança, confiabilidade...)

 Software que não cumpre os objetivos

Risco é usado para decidir quando começar e onde focar mais os testes.
 Riscos identificados podem ser utilizados para:

 Determinar técnicas de testes a serem empregadas

 Nível de detalhamento dos testes

 Priorizar os testes

5.6) Gerenciamento do incidente

Registro das discrepâncias entre o resultado obtido e o resultado esperado.

Os relatórios de incidente tem os seguintes objetivos:

 Prover aos desenvolvedores e aos interessados, informações sobre o problema, para identificar, isolar
e corrigir se necessário.

 Prover aos lideres de teste um meio para se rastrear a qualidade do sistema sob os progressos dos
testes

 Prover idéias para melhorar o processo de teste

Um relatório de incidentes pode incluir:

 Data, autor, status e organização

 Resultados esperados e atuais

 Item de configuração

 Processo do ciclo de vida do software

 Descrição do incidente

 Grau de impacto

 Severidade

 Urgência

 Comentários gerais
  Histórico

 Referencias

6) Ferramentas de suporte a teste

6.1) Tipos de ferramentas de teste

Ferramentas são classificadas de acordo com a atividade de teste que suporta.

Ferramentas de teste podem melhorar a eficiência do teste automatizando tarefas repetitivas.

Ferramentas de teste intrusivas podem afetar os resultados dos testes

Ferramentas auxiliam desenvolvedores durante os testes de componentes e integração dos componentes.

6.1) Ferramentas para o gerenciamento dos testes

As características das ferramentas de gerenciamento:

 Dar suporte ao gerenciamento dos testes

 Fazer a interface entre as ferramentas de gerenciamento de defeitos X gerenciamento de requisitos

 Controle de versão independente

 Dar suporte a rastreabilidade, resultados e incidentes dos testes aos documentos de origem

 Registrar os resultados e gerar relatórios de progresso

 Métricas relacionadas aos testes

6.1.2) FERRAMENTAS DE GERENCIAMENTO DE REQUISITOS

 Armazenam, consistem, verificam ausência e priorizam os requisitos

[Link]) FERRAMENTAS DE GERENCIAMENTO DE INCIDENTES

Defeitos, falhas, problemas, anomalias…

 Facilidade na priorização das correções

 Facilidade na distribuição das tarefas

 Atribuição de status

Estas ferramentas permitem a monitoração do progresso do projeto

[Link]) FERRAMENTAS DE GERENCIAMENTO DE CONFIGURAÇÃO

Manter o controle das versões;

As ferramentas:

 Armazenam todas as informações de versões e dos testwares

 Permite a rastreabilidade entre testaware X software

6.1.3) Ferramentas para testes estáticos

[Link]) FERRAMENTAS PARA SUPORTE AO PROCESSO DE REVISÃO

Armazenam informações sobre as revisões dos processos, comentários, relatos dos

defeitos e esforços.

Mantém controle da rastreabilidade entre documentos e o código fonte.

 Muito comum quando equipes estão distantes.

[Link]) FERRAMENTAS DE ANÁLISE ESTÁTICA

Ajudam os desenvolvedores, testadores com a qualidade de encontrar defeitos antes

dos testes dinâmicos.

Principais objetivos;

 Esforço na padronização do código

 Analise da estrutura

 Ajuda na compreensão do código

Estas ferramentas podem contribuir com informações valiosas para o planejamento ou

analise dos riscos.

[Link]) FERRAMENTAS DE MODELAGEM

Estas ferramentas auxiliam na criação de casos de teste com base na modelagem

O maior beneficio das ferramentas de analise estática, é encontrar defeitos antes dos
testes dinâmicos, ou no inicio do processo de desenvolvimento.

Contribui para:

 Desenvolvimento acelerado

 Diminuição do re-trabalho

6.1.4) Ferramentas de suporte para especificação de teste

 [Link]) FERRAMENTAS DE MODELAGEM DOS TESTES

Geram entradas de testes ou testes a partir dos requisitos, de uma interface, diagramas
de modelagem

Ajudam na criação de templates estruturados chamados de test frames, que geram

testes ou simuladores de testes.

[Link]) FERRAMENTAS PARA PREPARAÇÃO DE DADOS DE TESTE

Ferramentas que manipulam a base de dados

Beneficio é assegurar a integridade dos dados na transferência para um ambiente de

teste.

6.1.5) Ferramentas de suporte para execução e registro

[Link]) FERRAMENTAS DE EXECUÇÃO DOS TESTES

Permite que os testes sejam executados automaticamente, ou semi automaticamente,

usando dados de entrada e resultados esperados através de um script.

Ferramentas de capturas de entradas e saídas são utilizadas para gravar os testes.

[Link]) FERRAMENTAS DE TESTE DE UNIDADE

Facilita o teste de componente, pois simula o ambiente em que o sistema será testado.
Utilizada quando o foco dos testes está no nível do teste de componente.

[Link]) COMPARADORES

Determinam a diferença entre arquivos banco de dados ou resultados dos testes.

[Link]) FERRAMENTAS DE MEDIÇÃO DE COBERTURA

Medem a porcentagem de estruturas de código que são exercitadas. (comando,

decisões, ramos).

Estas ferramentas demonstram o quanto foi coberta a estrutura por um dado.

------------------------------------------

[Link]) FERRAMENTAS DE SEGURANÇA

Verificam a vulnerabilidade do computador a infecções por vírus e a ataques.

6.1.6) Ferramentas de performance e monitoração

[Link]) FERRAMENTAS DE ANALISE DINÂMICA

Só encontra defeitos quando o software está em execução

São normalmente utilizados testes de componentes, teste de integração dos

componentes.
[Link]) FERRAMENTAS DE TESTE DE PERFORMANCE, CARGA E STRESS

Monitora e relata como um sistema se comporta sob uma variedade de condições

simuladas.

[Link]) FERRAMENTAS DE MONITORAÇÃO

Analisa, continuamente, verifica e reporta a utilização de recursos específicos do

sistema.

6.1.7) Ferramentas de suporte para aplicações

6.1.8) Ferramentas de suporte utilizando outras ferramentas

 Planilhas

 SQL

 Ferramentas de depuração

6.2) Uso efetivo das ferramentas: Riscos e benefícios em potenciais.

6.2.1) Potenciais benefícios e riscos de ferramentas de suporte ao teste

Benefícios em potenciais incluem:

 Reduzir trabalhos repetitivos

 Avaliação clara dos objetivos

 Facilidade no acesso as informações sobre os testes

Riscos no uso das ferramentas:

  Falsas expectativas

 Subestimação do tempo, custo e esforços iniciais

 Subestimação do esforço para manter os artefatos gerados pela ferramenta

 Confiança excessiva na ferramenta

6.3) Implementando uma ferramenta na organização

PRINCIPIOS:

 Avaliação da maturidades das organizações

 Avaliar frente aos requisitos claros e objetivos

 Avaliar se a ferramenta atende aos objetivos

PROJETO PILOTO TEM OS SEGUINTE OBJETIVOS:

 Aprende mais detalhes sobre a ferramenta

 Ver como a ferramenta poderá se adequar aos processos

 Decidir as formas e padrões de uso

 Estimativa dos benefícios a um custo razoável

FATORES DE SUCESSO PARA A PERMANECIA DE UMA FERRAMENTA

 Revezamento na utilização da ferramenta

 Aprimorar os processos

 Treinamento a novos usuários

 Guia de usuários

 Monitoração do uso da ferramentas