• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Testes Funcionais
 

Testes Funcionais

on

  • 16,091 views

Testes Funcionais

Testes Funcionais

Statistics

Views

Total Views
16,091
Views on SlideShare
16,053
Embed Views
38

Actions

Likes
15
Downloads
0
Comments
3

3 Embeds 38

http://www.slideshare.net 25
http://www.f2suporte.com 9
http://www.techgig.com 4

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

13 of 3 previous next Post a comment

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Quality Control : a série de inspeções, revisões, verificações, validações e testes utilizados em pontos específicos do ciclo de desenvolvimento de software com o objetivo de achar falhas . Software Quality Assurance : uma abordagem planejada e sistemática de controle da qualidade para avaliação da aderência à padrões dos processos, procedimentos e artefatos envolvidos na produção de um software com o objetivo de prevenir falhas . Quality by Design : uma abordagem integrada e otimizada de produção correta de software, o que garante evitar de falhas .
  • O papel de Gerente de Testes desempenha atividades responsáveis pelo sucesso dos esforços de teste como um todo. Essas atividades envolvem: Negociar os objetivos em andamento e utilização dos esforços de teste adequados para cada iteração. Garantir um planejamento e gerenciamento apropriado dos recursos de teste que irão induzir os testes durante a iteração. Avaliar se os esforços de teste estão progredindo de forma efetiva e promovendo a criação de software testável para dar suporte às necessidades dos esforços de teste. Promover também a utilização de técnicas e ferramentas de automação apropriadas. Estabelecer um nível apropriado de qualidade efetuando as mudanças para a resolução de defeitos que afetam seriamente o sistema. Avaliar a produtividade, efetividade e completude dos esforços de teste, ajustando estratégias e táticas para aprimorar o processo de teste.
  • O papel de Analista de Testes desempenha atividades responsáveis por identificar e definir os requisitos de teste.
  • Nessa macro-atividade, o principal objetivo é identificar o foco apropriado do esforço de testes para a iteração, e entrar em acordo com os stakeholders acerca dos objetivos dos testes. Definir os artefatos que serão utilizados e gerados Utilização dos recursos de teste Acordo com os stakeholders sobre os objetivos dos testes Técnicas e tipos de teste que serão empregados Itens de hardware e software necessários para os testes Forma como serão avaliados os esforços de teste Listar idéias para testes em potencial que podem ser aplicados Rastreabilidade mantendo documentos e gravações comprovando que foram feitos testes suficientes
  • Nessa macro-atividade o principal objetivo é demonstrar que as várias técnicas sugeridas no Enfoque do Testes irão facilitar os testes requeridos. Significa obter um entendimento dos obstáculos e limitações de cada técnica e buscar uma solução de implementação apropriada para cada técnica ou encontrar técnicas alternativas. Isto ajuda a minimizar o risco de descobertas tardias no ciclo de vida do projeto de que as recomendações de testes são impraticáveis. Estabelecer o ambiente necessário para suportar os testes Identificar os mecanismos necessários aos testes (Ex.: persistência, concorrência, distribuição, segurança, gerenciamento de transação, tratar e reportar erro, controle e sincronização de sincronização), bem como as ferramentas necesárias. Identificar os elementos físicos da infra-estrutura de implementação de teste necessários para permitir os testes sob cada configuração de ambiente de teste Analisar os itens da “Lista de Idéias” identificando as condições necessárias para aplicar determinada idéia de teste Reunir e organizar os testes a serem executados Implementar testes que forneçam a solicitada validação do produto Garantir a obtenção do produto de software a ser testado junto à equipe de desenvolvimento Reunir e organizar os testes a serem executados
  • Nessa macro-atividade o principal objetivo é validar se a construção está estável o suficiente para o início da execução de testes detalhados e avaliação. Este trabalho é também conhecido como “ smoke test”, “build verification test”, “build regression test”, “sanity check” ou “acceptance into testing” . Este trabalho ajuda a prevenir que recursos de teste sejam perdidos em esforços de teste desnecessários e infrutíferos. Executar as coleções de testes necessárias para validar a qualidade do produto, capturando resultados de teste que facilitam a avaliação do produto Analisar as falhas que ocorreram durante a implementação e execução dos testes, corrigindo as falhas que resultaram dos procedimentos de teste. Fazer um resumo de avaliação de resultados de software, propondo ações corretivas para resolver as falhas de qualidade Identificar e requerer a resolução dos defeitos que causam impactos sérios na qualidade do software
  • Nessa macro-atividade, o principal objetivo é alcançar a largura e profundidade do esforço de testes para possibilitar uma avaliação suficiente dos itens de teste—onde uma suficiente avaliação é governada pelas motivações dos testes e Missão da Avaliação. Tipicamente executado um por ciclo de teste, este trabalho envolve executar o trabalho principal do esforço dos testes e avaliação de resultados: especialmente a implementação, execução e avaliação de testes específicos e o correspondente registro das ocorrências. Definir os artefatos que serão utilizados e gerados. Estruturar as suítes de teste necessárias, atribuindo responsabilidades para cada área de implementação de suítes de teste. Identificar os elementos físicos da infra-estrutura de implementação de teste necessários para permitir os testes sob cada configuração de ambiente de teste Verificar as requisições de mudança feitas e as construções (“builds”) liberadas para re-teste. Avaliar se os esforços de teste estão sendo produtivos, efetivos e completos, realizando, se necessário, ajustes táticos e estratégicos para que os esforços de teste se tornem mais efetivos.
  • Nessa macro-atividade, o principal objetivo é entregar uma avaliação útil dos resultados de testes aos stakeholders – onde uma avaliação útil é definida em termos da Missão de Avaliação. É o momento em que é feita uma avaliação dos esforços de teste em geral para verificar se os objetivos definidos na Missão de Avaliação da primeira macro-atividade estão sendo atingidos na iteração.
  • Nessa macro-atividade, o principal objetivo é manter e melhorar as necessidades dos testes. Isto é importante especialmente se a intenção é reutilizar os recursos desenvolvidos no ciclo corrente nos ciclos subseqüentes. A partir da avaliação feita na macro-atividade “Atingir Missão Aceitável”, o final de um ciclo de teste geralmente possui esse trabalho de aprimoramento das propriedades do teste que foi executado no ciclo.
  • Testes de regressão são as várias re-execuções de um teste após uma correção de bugs, mudanças ou manutenções evolutivas. É importante para manter a consistência entre as mudanças, pois muitas vezes algumas correções influenciam no comportamento de outras funcionalidades.
  • Estrutura utilizada pela gerência de requisitos. O primeiro passo é entender o problema sem pensar na solução. Buscar o acordo sobre esse entendimento. Descobrir as principais causas, segundo Pareto, se atacarmos 20% das principais causas solucionamos 80% dos problemas. Em seguida entendemos as necessidades do cliente. Ao mesmo tempo, vamos definindo as fronteiras do sistema, descobrindo os atores do sistema. O próximo passo é pensar em soluções para cada necessidade apresentada. O sistema deverá ter características (features) para atender às necessidades. Notamos que a partir das necessidades derivamos as características do sistema (rastreabilidade). Então analisamos o que cada ator espera usar do sistema (requisitos de software) e fazemos o mapeamento com as características do sistema (rastreabilidade).
  • _______________________________________________________ _______________________________________________________ _______________________________________________________ _______________________________________________________ _______________________________________________________ _______________________________________________________ _______________________________________________________ _______________________________________________________ _______________________________________________________ _______________________________________________________ _______________________________________________________ _______________________________________________________
  • _______________________________________________________ _______________________________________________________ _______________________________________________________ _______________________________________________________ _______________________________________________________ _______________________________________________________ _______________________________________________________ _______________________________________________________ _______________________________________________________ _______________________________________________________ _______________________________________________________ _______________________________________________________
  • _______________________________________________________ _______________________________________________________ _______________________________________________________ _______________________________________________________ _______________________________________________________ _______________________________________________________ _______________________________________________________ _______________________________________________________ _______________________________________________________ _______________________________________________________ _______________________________________________________ _______________________________________________________
  • Existem várias técnicas que permitem a execução de uma série de cenários ou exemplos diretamente na aplicação. Nessa situação o testador assume o papel do usuário, testando o software da maneira como ele será utilizado. Os bugs encontrados durante os testes dinâmicos são aqueles introduzidos pelos requisitos, projeto e codificação. Inclusive problemas gerados por interação com sistemas legados. Nos próximos slides serão detalhadas as técnicas de Derivação de Especificação, Particionamento de Equivalência e Análise de Valores Limite.
  • Para derivar casos de teste a partir de casos de uso, devem ser encontrados todos os cenários possíveis para o caso de uso. Cada cenário de caso de uso dá origem a um ou mais casos de teste. Quanto mais complexa for uma funcionalidade, mais cenários existirão. Casos de uso típicos têm entre 3 e 15 páginas, sendo que 70% a 90% são cenários de fluxos alternativos.
  • Pense em Quality by Design como qualidade por “objetivo”. Quality By Design é uma aproximação pró-ativa de desenvolvimento e teste de software que abrange boas práticas, processo e ferramentas que o ajudam a entregar aplicativos com maior qualidade e mais rápido.
  • _______________________________________________________ _______________________________________________________ _______________________________________________________ _______________________________________________________ _______________________________________________________ _______________________________________________________ _______________________________________________________ _______________________________________________________ _______________________________________________________ _______________________________________________________ _______________________________________________________ _______________________________________________________
  • A ferramenta Rational Administrator é responsável por armazenar as informações de um projeto de teste.
  • Para criar um projeto novo: Clique File > New Project. Entre com o nome e diretório Não selecione ClearCase/UCM Management Se quiser, coloque uma senha Cheque “Configure Project Now”
  • Utilize o botão Create para criar os artefatos de teste
  • O usuário pode adicionar Computadores para a realização de testes distribuídos.
  • O usuário pode implementar um Plano de Testes no nível de granularidade que quiser.
  • Profundidade: quantidade de dados usado nos testes. Muito poucos dados podem não refletir numa situação real. Amplitude: variações nos valores dos dados. Escopo: relevância dos dados de teste. O ideal é abranger todas as partições de equivalencia. Arquitetura: mecanismos que poderão ser utilizados para a execução dos testes. Ex.: persistencia, concorrencia, etc. Gerenciamento
  • .
  • Para acessar quando não estiver gravando: View > Toolbars > GUI Insert Toolbar

Testes Funcionais Testes Funcionais Presentation Transcript

  • Planejamento e Execução de Testes Funcionais Apresentação Instrutor: Juliana Maria Lopes / Leonardo Grilli Torres
  • Objetivos
    • Apresentar os conceitos de testes funcionais implementados no Framework de Desenvolvimento de Sistemas
    • Detalhar a suíte de testes funcionais IBM Rational Functional Test
    • Detalhar técnicas de apoio ao projeto de casos de testes funcionais
    • Detalhar os recursos de criação de scripts manuais e automatizados de testes funcionais na ferramenta
    • Detalhar os recursos de execução e geração de relatórios de testes funcionais
  • Agenda
    • Dia 1
      • Fundamentos de Testes
      • O processo de Testes
      • Derivação Casos de Uso em Casos de Teste
        • Lab: Exemplo de Derivação
    • Dia 2
      • Introdução à Suíte de Testes
        • Labs: Projeto Rational, Gerenciando Plano de Testes, Criando scripts manuais.
    • Dia 3
      • Suítes de Execução de Testes.
        • Labs: Criando scripts automáticos, geração de relatórios
  • Módulo 1: Fundamentos de Testes de Software Juliana Maria Lopes
  • Agenda
    • Motivações
    • Introdução conceitual de Testes de Software
    • Testes Funcionais e Casos de Uso
  • Por que testar?
    • Motivação:
    • Financeira
      • Perdas financeiras devido a erros
      • Custo da qualidade (CoSQ)
    • Técnica
      • Baixa eficácia
    • Profissional
      • Carência de profissionais qualificados
    • Normativa
      • Institucionalização de normas técnicas
  • Motivação financeira: perdas devido a erros US$ 1 milhão por minuto Charles Schwab (maior corretora on-line do mundo ) US$ 167 mil por minuto American Express US$ 50 mil por minuto Boeing Quedas do Sistema Queda de 26% no valor das ações Perdas de US$ 3,5 milhões Site fora do ar por 22 horas eBay (Online Marketplace) US$ 1,1 milhão por dia Problemas no sistema de controle de bagagem US$ 50 milhões Erro no sistema mostrando que todos os vôos estavam lotados US$ 20 mil por minuto Sistema SABRE fora do ar por 12 horas American Airlines
  • Motivação financeira: custo da qualidade Fe Fi Encontrar o maior número de erros com o menor retrabalho possível com os testes de regressão 92,9% 7,1% 0% 50% 100% Falhas Externas Falhas Internas
  • Vantagem: menor custo da correção de erros “ O Custo para encontrar e determinar um erro, aumenta exponencialmente com a fase do projeto.” Barry Boehm, criador do Software Economics
  • Motivação técnica
    • Tempo do Projeto aplicado em Testes
    • (aceitação + homologação) 15-40% (Média 23%)
    • Maturidade do Processo de Testes (TPI/TMM) 1.3 [escala 1-5]
    • Índice de Retrabalho 25-70% [média 32%]
    • Proporção de falhas especificação/programação 1,6:1 [62%]
    • Eficácia dos Testes 18-75% [média 35%]
    • Custo dos Testes
    • (% custo dos projetos gastos em Testes, prevenção e correção) 45%-60% [média 52%]
  • Motivação técnica
    • 74% dos projetos de software falham em prazo e custo
      • Custos de retrabalho não gerenciados
    • Falta de ambientes estruturados para a execução dos testes
      • Processo Informal de testes
      • Muitos erros detectados na fase de implantação
      • Muitos problemas em produção, pela liberação de novos sistemas ou versões instáveis
    • Cobertura de testes insuficientes em relação aos requisitos
      • Alto índice de requisitos não-atendidos
      • Testes com cobertura insuficiente sobre os requisitos
    • Necessidade de abordagens de teste diferenciadas para novas tecnologias
  • Motivação profissional
    • Certificações
    • QAI – Quality Assurance Institute
      • Software Quality Analyst (CSQA)
      • Software Test Engineer (CSTE)
      • Software Project Manager (CSPM)
      • Software Quality Engineer (CSQE)
    • ASQ – American Society For Quality
    • Iniciativa nacional: ALATS (http://www.alats.org.br)
    • Carência de profissionais especializados
      • Baixo grau de especialização das equipes de testes;
      • Baixa relevância atribuída ao processo de testes;
      • Baixa produtividade das equipes devido ao re-trabalho
  • Motivações normativas Motivações
    • Documentação mínima, normas internas
    • Resolução do Banco Central
    • Lei Sarbanes-Oxley, apelidada de “SOX”
      • Seu conjunto busca garantir a criação de mecanismos de auditoria e segurança confiáveis nas empresas, incluindo ainda regras para a criação de comitês e comissões encarregados de supervisionar suas atividades e operações de modo a mitigar riscos aos negócios, evitar a ocorrência de fraudes ou ter meios de identificar quando elas ocorrem, garantindo a transparencia na gestão das empresas.
  • Motivações normativas: evidências ok Robustez (escalabilidade / performance) ok Integração ok Funcionalidade ok Segurança de Dados ok Autorização ok Autenticação Validação e Testes Requisitos de Conformidade em Tecnologia de Informação
  • Introdução conceitual
  • Histórico: o 1 º Bug http://www. history . navy . mil/photos/images/h96000/h96566kc . htm O primeiro "Bug" de Computador Uma traça foi encontrada enroscada próxima ao Relay #70, Painel F, da Máquina Calculadora Mark II Aiken enquanto ela estava sendo testada na Universidade de Harvard, em 9 de Setembro de 1945. Os operadores afixaram a traça no diário de operação, com a frase: "O primeiro caso real de um bug encontrado". Eles descreveram o processo como tendo "debugado" a máquina, o que introduziu o termo "debugar um programa de computador". Desde 1988, o diário, com a traça colada, está no Museu do Computador do Centro de Guerra Naval em Dahlgren, Virgina, USA.
  • Evolução histórica das atividades de teste de software DEMONSTRAÇÃO Mostrar que funciona 1960s DETECÇÃO Procurar defeitos meados 1970s PREVENÇÃO Gerenciar a qualidade 1990s
    • Revisar e esclarecer as especificações do sistema
    • Fornecer informações que previnem ou reduzem a probabilidade de criação de erros
    • Detectar erros o mais cedo possível no processo de desenvolvimento de software
    • Identificar riscos e problemas no desenvolvimento e estudar maneiras de previní-los
    • Descobrir defeitos, erros e deficiências do sistema
    • Definir as capacidades e limitações do sistema
    • Fornecer informações sobre a qualidade de componentes, sistemas e artefatos
    • Conquistar a confiança de que o sistema pode ser utilizado com riscos aceitáveis
    • Submeter as features e funcionalidades do sistema ao funcionamento em situações e condições não usuais
    • Certificar que um componente de software está completo e pronto para uso ou integração
  • O que é Teste? Uma investigação técnica executada para revelar informações relacionadas à “ qualidade” do produto Sob teste O Teste Funcional tem Por meta a verificação e Aceitação dos dados, do Processamento, da resposta A este processamento e a implementação Apropriada das regras De negócio
  • Definição
    • Investigação
      • È uma procura meticulosa e organizada por informações
      • É um processo ativo de questionamento, no qual fazemos questões críticas (através de casos de testes ) e olhamos cuidadosamente para os resultados
    • Técnica
      • Método no qual utilizamos meios, incluindo experimentos, lógica, matemática e estatística, modelos, ferramentas de testes e de monitoramento
    • Definições aplicadas sobre o produto em teste.
  • Informações relativas a qualidade do produto em teste
    • Encontrar bugs importantes e resolvê-los
    • Validar a interoperabilidade entre produtos
    • Auxiliar os gerentes tomar decisões
    • Evitar publicação de versões prematuras de produtos
    • Minimizar custos de suporte técnico
    • Avaliar a conformidade com a especificação
    • Avaliar a conformidade com normas
    • Minimizar riscos legais
    • Determinar cenários seguros de uso do produto
    Objetivos diferentes requerem estratégias de testes diferentes, o que implica em diferentes tipos de testes, diferentes documentos e diferentes resultados
  • Princípios básicos
    • Testes são
      • caros e demorados
      • pouco eficientes porém identificam falhas
        • encontram poucas falhas a cada execução
        • estatísticas mostram que encontram somente cerca de 65% de todos os problemas identificados
      • devem ser projetados cuidadosamente
        • visando aumentar eficiência e eficácia
  • Princípios básicos
    • Teste é um experimento controlado visando a identificação de problemas.
      • como conduzir os experimentos?
      • como selecionar os dados?
      • como identificar os resultados esperados?
      • como confrontar resultados esperados com os resultados observados?
      • como replicar os experimentos?
  • Princípios básicos
    • O objetivo do teste é encontrar problemas relevantes
      • um teste que encontrou um problema, valeu o investimento
        • depois de eliminar o problema temos que retestar o artefato e esperamos não encontrar outros problemas relacionados ou decorrentes do que foi eliminado
      • um teste que não encontrou um problema foi uma ação bem sucedida
    • Atitude destrutiva ao testar
    • O objetivo de encontrar problemas é poder removê-los de forma completa
      • é a remoção da falta que gerou o problema que constitui a melhoria da qualidade
  • Os focos da disciplina de testes Quality Control encontrar falhas Quality Assurance prevenir falhas Quality by Design evitar falhas
  • Quality Control (QC) Especificação de Requisitos Análise do projeto Desenho do projeto codificação Testes de unidade Testes de integração Testes de Sistema Teste de Aceitação Validação Validação Validação Quality Control encontrar falhas
  • Quality Control Testes de unidade Testes de integração Testes de sistema Testes formais conduzidos para determinar se um sistema satisfaz ou não os critérios de aceitação e que possibilita ao cliente/usuário determinar se aceita ou não o sistema Testes de aceitação do usuário Explora a menor unidade do projeto, procurando identificar erros de lógica e de implementação em cada módulo separadamente Descobrir erros associados às interfaces entre os módulos quando esses são integrados para construir a estrutura do software que foi estabelecida na fase de projeto Identificar erros de função e características de desempenho que não estejam de acordo com a especificação
  • Técnicas de testes Técnicas de testes Visão Fontes de informação Métodos entradas saídas Caixa preta Caixa branca Domínio do problema Requisitos Especificações de projeto Dados de análise de defeitos Diagramas de projeto Detalhes de projeto Código fonte Grafos de fluxo de controle Complexidade ciclomática Particionamento de classe de equivalência Análise de valores limites Diagrama de estados Grafos de causa e efeito Statement testing Branch testing Path testing Data flow testing Mutation testing Loop testing Testes Funcionais no Processo de Software
  • Dimensões de qualidade de software
    • O que testar ?
      • Um produto de software é validado e testado de acordo com suas dimensões de qualidade.
    Funcionalidade Teste do funcionamento adequado de cada cenário de uso Facilidade de uso Teste da aplicação da perspectiva da conveniência do usuário final Confiabilidade Testa se a aplicação se comporta como o esperado Performance Teste de tempo de resposta sobre picos e médias de carga Suportabilidade Teste da habilidade de manter e dar suporte à aplicação em produção FURPS
  • Tipos de teste
    • Teste de unidade
      • Teste independente de uma unidade (módulo, classe, função?)
      • Foco: exame minucioso do código e da interface disponibilizada pela unidade (componente?)
      • Exemplos de unidades
        • classes
        • widgets
        • agentes
        • páginas Web
        • módulos
        • componentes
        • applets
        • servlets
        • programas
          • no caso de programas compostos
  • Tipos de teste
    • Teste de integração
      • Testa a composição de unidades previamente testadas.
      • Foco: exame minucioso do uso das interfaces entre componentes
        • parâmetros
        • variáveis globais
        • mensagens
        • estados
        • rotinas
        • sincronização
        • protocolos
        • recuperação ( roll back )
  • Tipos de teste
      • teste da corretude procura encontrar diferenças entre o especificado e o implementado
      • teste da interface verifica se a interface do componente ou módulo permite a construção de programas que utilizem estes artefatos sem requerer quaisquer alterações, adaptações ou interfaces de conversão ( wrappers )
      • teste da adequação verifica se o construto resolve os problemas que o usuário espera ver resolvidos
      • teste da utilizabilidade verifica se o construto é fácil de usar e de aprender a utilizar
      • teste da robustez verifica se o construto resiste a agressões intencionais ou fortuitas
      • teste da segurança procura encontrar brechas de segurança que permitam pessoas azaradas ou mal intencionadas a causar danos
  • Tipos de teste
      • teste da instalação verifica se o programa de instalação está operando corretamente
      • teste da implantação verifica se o construto pode ser colocado em correto funcionamento nas plataformas do usuário.
      • teste da capacidade verifica se o construto é capaz de atender à demanda esperada
      • teste de volume procura determinar os limites de capacidade a partir dos quais o programa entra em colapso por excesso de demanda
      • teste de exaustão verifica o comportamento quando recursos exaurirem (ex. falta memória, ultrapassa o volume)
      • teste de longa vida verifica se o construto pode ser utilizado intensivamente por longos períodos (ex. 24 x 7) sem se deteriorar
  • Relato de falhas
      • O objetivo de um teste é achar erros .
      • Relatório de erros são o objetivo principal desta disciplina.
        • Este será valorizado por outros atores do processo.
      • O melhor teste não é aquele que acha mais erros, ou embaraça o maior número de programadores. O melhor teste é aquele que consegue auxiliar na correção de um maior número de erros.
      • Programadores estão sujeitos a restrições e prioridades concorrentes.
      • Um relatório de erros é uma ferramenta que deve vender ao programador a idéia de que é útil investir o seu tempo e energia para corrigir o erro.
  • Módulo 2: O processo de Testes de Software Juliana Maria Lopes
  • A disciplina de Validação e Testes Framework de Desenvolvimento de Sistemas
  • Papéis, Atividades e Artefatos de Teste Gerente de Testes Plano de Testes Responsável Por Aceitar Missão de Avaliação Identificar Motivadores de Teste Obter comprometimento de Testabilidade Avaliar e defender a Qualidade Avaliar e aprimorar os esforços de Teste Resumo de Avaliação de Testes
  • Papéis, Atividades e Artefatos de Teste Analista de Testes Lista de Idéias de Teste Responsável Por Identificar os Objetivos do Teste Identificar Idéias para os Testes Definir os Detalhes do Teste Definir Avaliação e Rastreamento de Necessidades Determinar Resultados de Teste Casos de Teste Verificar Mudanças na Construção Modelo de Análise de Carga de Trabalho Dados de Teste Resultados de Teste
  • Papéis, Atividades e Artefatos de Teste Projetista de Testes Arquitetura de Automação de Teste Responsável Por Definir a Abordagem do Teste Definir as Configurações do Ambiente de Testes Identificar Mecanismos de Testes Estruturar a Implementação dos Testes Definir Elementos de Testes Especificação de Interface de Teste Desenvolver Diretrizes de Teste Configuração de Ambiente de Teste Suíte de Teste Diretrizes de Teste
  • Papéis, Atividades e Artefatos de Teste Testador Scripts de Teste Responsável Por Implementar Testes Implementar Suíte de Testes Executar Suíte de Testes Analisar Falhas do Teste Log de Teste
  • Workflow da Disciplina de Testes Definir Missão de Avaliação Verificar Enfoque do Teste Validar Estabilidade da Construção [Outra Técnica] Testar e Avaliar Avaliar Missão de Aceitação Aprimorar Ativos de Testes [Outro Ciclo de Teste]
  • Definir Missão de Avaliação
    • Para cada iteração:
    • Identificar os objetivos e produtos dos esforços de teste
    • Identificar uma boa estratégia de utilização dos recursos de teste
    • Definir o escopo/fronteiras para os esforços de teste
    • Esboçar o framework que será adotado
    • Definir como o progresso será monitorado e estimado
    Definir Missão de Avaliação
  • Verificar Enfoque do Teste
    • Para cada técnica utilizada:
    • Identificação prévia de que o enfoque dos testes irá funcionar e gerar um resultado de valor
    • Estabelecer a infra-estrutura básica para suportar o enfoque dos testes
    • Obter o comprometimento da equipe de desenvolvimento para o fornecimento de produto passível de teste
    • Identificar o escopo, limitações e dificuldades de cada técnica
    Verificar Enfoque do Teste
  • Validar Estabilidade da Construção ( Build )
    • Para cada ciclo de teste:
    • Avaliar a estabilidade e testabilidade da Construção ( Build )
    • Adquirir um conhecimento inicial ou confirmar o que já era esperado sobre o que foi desenvolvido na construção.
    • Decidir entre utilizar a construção em testes futuros ou testá-lo contra uma construção prévia.
    Validar Estabilidade da Construção
  • Testar e Avaliar
    • Para cada ciclo de teste:
    • Prover avaliação progressiva dos itens alvos do teste.
    • Gravar as informações necessárias para diagnosticar e resolver qualquer caso identificado
    • Atingir a cobertura adequada nos testes e avaliação
    • Prover feedback sobre as áreas mais prováveis de potenciais riscos de qualidade
    Testar e Avaliar
  • Atingir Missão de Aceitação
    • Para cada ciclo de teste:
    • Priorizar o conjunto mínimo de testes necessários para atingir a Missão de Avaliação.
    • Resolução das questões mais importantes.
    • Defender a qualidade apropriada.
    • Identificar redução de qualidade entre um ciclo de teste e outro.
    • Revisar a Missão de Avaliação conforme necessário.
    Atingir Missão de Aceitação
  • Aprimorar Propriedades dos Testes
    • Para cada ciclo de teste:
    • Adicionar testes apropriados para a próxima “Validação de Estabilidade da Construção ( Build )”.
    • Incluir novos scripts de teste à suíte.
    • Remover propriedades improdutivas ou não econômicas.
    • Cuidar as configurações de ambiente de teste e dados de teste.
    • Documentar lições aprendidas durante o ciclo de teste que foi executado.
    Aprimorar Propriedades dos Testes
  • A equipe de testes
    • Precisa ter experiência e conhecimento de como um software é especificado, projetado e desenvolvido
    • Precisa ter um bom conhecimento sobre o domínio do problema
    • Deve conhecer as ferramentas de automação de testes, acompanhar sua evolução e ter “programadores de teste”
    • Deve trabalhar em conjunto e cooperação com analistas de requisitos, arquitetos e projetistas, e programadores, e quando conveniente com os usuários e clientes
    • Os testadores têm de deter o conhecimento sobre técnicas de testes e serem críticos na sua utilização
    • Os testadores têm perfil destrutivo; programadores têm perfil construtivo.
  • Revisão
    • Quais os papéis de testes?
    • Qual a importância de um plano de testes?
  • Testes Funcionais
  • Testes Funcionais: Definição Uma maneira de avaliar o comportamento de um produto de software sem que o funcionamento interno do que está sendo testado seja conhecido pelo testador. Entrada Saída Programa Casos de Testes Resultados esperados
  • Testes Funcionais de Regressão
    • Rexecução de um ou mais testes em versões
    • subseqüentes do sistema para garantir que a qualidade
    • anteriormente obtida não foi perdida.
      • Verificam a consistência entre as versões
      • Verificam que as alterações e correções não introduziram novos problemas
      • Garantem testes mais completos e precisos
  • Estratégia de Testes Funcionais
  • Estratégia de Testes Funcionais Código Testes Funcionais X Testes Funcionais no Processo de Software Casos de Uso
  • Técnicas de Testes no Framework
  • Escopo Atual do Framework Requisitos Gerência de Configuração (SCM) Análise & Desenho Construção Validação & Testes Implantação Documentação Gerência de Projetos Disciplinas Principais Disciplinas de Apoio Abordagem por Caso de Uso MSVisual Studio/ WSAD/TSO/ISPF Java 4GL(VAGen) COBOL Plataforma Distribuída Mainframe Plataforma Distribuída Mainframe Análise Estruturada Análise OO
  • Estratégia de Testes Requisitos A/D Construção Testes Implantação Testes Estruturais Repositório Requisitos Casos de Testes Funcionais Código
  • Cobertura de Requisitos X Cobertura de Código
    • Cobrir 100% do código não indica que todos os requisitos estão testados
    • Cobrir todos os requisitos não garante que 100% do código foi executado sem erros
    • Parâmetros de avaliação mútuos
    Testes Funcionais no Processo de Software
  • Estratégia de Testes Requisitos A/D Construção Testes Implantação Construção codificação Tunning Testes Unidade Debug e Testes Estruturais Testes Estruturais Testes Estruturais Analista Programador
  • Estratégia de Testes Requisitos A/D Construção Testes Implantação Teste Testes Internos Correção Testes Aceitação Registro de Defeitos Testes Estruturais Testes Funcionais Testes de Carga Analista de Sistemas
  • Derivação de Especificação Caos de Uso Código Testes Funcionais Próximos Passos x Casos de Testes
  • Sistema de Rastreamento de Defeitos Instrumento de gerência de projetos Registra Líder de Projeto Equipe de Testes Gerencia Desenvolvedor Fixa Cancelado Em Solução Resolvido Fechado Adiado Aberto Ciclo de vida de Defeitos Base de defeitos
  • Técnicas de Projeto de Testes
    • Derivação de Especificação
    • Particionamento de Equivalência
    • Análise de Valores Limite
  • Derivação de Especificação Cenário 1 Cenário 2 Cenário N Derivação de Casos de Uso em Casos de Testes Caso de Uso
  • Particionamento de Equivalência
    • Divide o domínio de entrada de um software (ou programa) em classes de dados a partir as quais os casos de teste podem ser derivados;
    • Classe de equivalência representa um conjunto de estados válidos ou inválidos para condições de entrada;
    • Uma condição de entrada pode ser:
      • Valores numéricos;
      • Intervalo de valores;
      • Intervalo de data;
      • Valor alfabético.
    entradas válidas entradas inválidas Saídas software Técnicas de Testes Funcionais
  • Classes de Equivalência
      • Se a condição de entrada especifica um intervalo ,ou requer um valor específico então é definida uma classe de equivalência válida e duas inválidas;
    Técnicas de Testes Funcionais 4 7 Classe Válida Classe Inválida Classe Inválida 4 Classe Válida Classe Inválida Classe Inválida
      • Se a condição de entrada especifica um membro de um conjunto , então é definida uma classe de equivalência válida e uma inválida;
    Classe válida Classe dos elementos inválidos Conjunto
  • Análise de Valores Limites Técnicas de Testes Funcionais 4 Classe Válida Classe Inválida 3 5 7 Classe Válida Classe Inválida 6 8 4 7 Classe Válida Classe Inválida Classe Inválida
  • Análise de Valores Limites
      • Definidas as partições de equivalência, os valores limites destas particições indicam os casos de testes necessários.
    Técnicas de Testes Funcionais
      • Situações de análise
      • Intevalos de valores financeiros
      • Intervalos de Datas
      • Grupo de códigos de produtos
    8 >7 3 < 4 Inválidas 4, 5, 6, 7 >= 4 <= 7 Válidas Valores Limites Partições (de entrada ou saída)
  • Derivando Casos de Uso em Casos de Testes
  • Existem inúmeros tipos de requisitos
    • FURPS
      • Funcionalidade
      • Facilidade de uso
      • Confiabilidade
      • Performance
      • Suportabilidade
    • Conformidade legal ou regulatória
      • Comissões Federais ou Internacionais
      • Bancos Centrais
      • Departmento de defesa
    • Restrições de projeto
      • Sistemas operacionais
      • Ambientes
      • Compatibilidade
      • Padrões de aplicação
    • Casos de uso descrevem requisitos funcionais
    • A meta dos casos de uso é de especificar TODOS os requisitos funcionais
  • Casos de uso são parte da UML 1967 Foundations of OO (Nygaard, Goldberg, Meyer, Stroustrup, Harel, Wirfs-Brock, Reenskaug,…) UML 1.1 (OMG Standard) UML 1.3 ( extensibility ) UML 1.4 ( action semantics ) UML 1.5 1996 1997 1998 2001 1Q-2003 3Q-2003 UML 2.0 (MDA) Evolução da UML Origem dos casos de uso Jacobson Booch Rumbaugh
  • O que é um caso de uso?
    • São descritos textualmente
      • Contam a história da interação entre os atores e o sistema
      • A UML não especifica exatamente COMO escrevê-los
    Saque de dinheiro Cliente do Banco
    • Diagramas de caso de uso são parte da UML
      • Um caso de uso descreve uma seqüência de ações que o sistema executa e que produz um resultado observável de valor para um ator particular
  • Especificação Textual de casos de uso
    • A UML não especifica como o texto do caso de uso deve ser estruturado, organizado ou escrito
    • A maneira de descrever os casos de uso têm grande impacto na facilidade de como serão testados
      • Um caso de uso descreve uma seqüência de ações que o sistema executa e que produz um resultado observável de valor para um ator particular
  • Conteúdos de um caso de uso
    • Um fluxo básico
      • Cenário básico
    • Muitos fluxos alternativos
      • Variações regulares
      • Fluxos de Exceção (erro)
    Sem conjugação no futuro
  • Exemplo de estilo de descrição de fluxo básico Estruture os fluxos em passos Numere o título de cada passo Descreva os passos (1-3 sentenças) Não referencie fluxos alternativos no fluxo principal
  • Exemplo de descrição de fluxo alternativo Informe o passo onde o fluxo alternativo inicia Caso de Uso: Registro em cursos Informe o que causa o início do fluxo Informe o que acontece Informe onde o fluxo termina Fluxos alternativos devem tratar apenas uma condição
  • Casos de Uso e Casos de Teste
    • É uma maneira objetiva de produzir casos de testes baseados em casos de uso (requisitos)
    • Benefícios:
      • Permite que testadores escrevam os casos de testes antes do código ser escrito
      • Fornece um método claro de teste
      • Dá aos testadores um ponto de partida para enteder o que a aplicação supostamente faz
  • O que é um caso de teste?
    • Um “artefato intermediário&quot;
    • Ajuda a organizar e desenvolver scripts de testes e drivers, tanto manuais quanto automáticos
    • Um caso de testes deve responder a seguinte questão: “O que é necessário testar?
    Um conjunto de entradas, condições de execução, e resultados esperados (saídas) desenvolvido...para verificar a conformidade da aplicação com os requisitos definidos Caso de Teste
  • Cenário 1 Cenário 2 Cenário N Casos de Teste são derivados a partir de casos de uso (relembrando...) Caso de Uso
  • Derivação de caso de uso em caso de teste Ação do Ator Passo Caso de Uso Caso de Teste Resposta do Sistema Ponto de Verificação
  • Derivando Casos de Testes de Casos de Uso
    • Passo um
      • Identificar todos os caminhos do caso de uso - cenários
    • Passo dois
      • Para cada cenário, crie um caso de teste e identifique as condições nas quais cada caso de teste executará
    • Passo três
      • Revise e reconsidere cada um
      • Adicione valores de dados para cada condição de teste
  • Cenários – Caminhos do caso de uso
    • Cenários
      • Descrevem o que o ator pode fazer
      • Cobre o fluxo básico e o fluxo alternativo
      • Inicia e termina dentro do caso de uso
    • Não se pode testar fluxos alternativos sem o fluxo básico
  • Encontrando cenários
    • Cada combinação possível do fluxo básico e alternativo identifica o conjunto completo de cenários
    • O número mínimo de cenários será igual ao número de fluxos alternativos + o fluxo básico
    • Muito frequentemente há mais cenários que o número mínimo graças a
      • Combinação de cenários
      • Múltiplas “condições” de um fluxo alternativo (este tipo de fluxo não é “atômico”)
    • Ao encontrar cenários é útil desenhar os fluxos
      • Diagrama de atividade da UML
      • Uma figura como esta
  • Matriz de Cenários – Registro de Cursos
    • Use uma matriz de cenários para manter a rastreabilidade
  • Derivando casos de testes de casos de uso
    • Passo um
      • Identificar todos os caminhos do caso de uso - cenários
    • Passo dois
      • Para cada cenário, crie um caso de teste e identifique as condições nas quais cada caso de teste executará
    • Passo três
      • Revise e reconsidere cada um
      • Adicione valores de dados para cada condição de teste
  • De cenários a casos de testes
    • Crie uma matriz de casos de testes
    • Para cada cenário
      • Adicione uma linha na matriz de caso de teste
    • Para cada condição de teste
      • Adicione uma coluna na matriz de casos de teste
      • Para identificar as condições de teste
        • Analise os fluxos de eventos dos casos de uso
        • Procure pelos passos dos usuários (ex: saída)
        • Procure pelos dados de entrada dos usuários (ex: passwd)
        • Procure por dados fornecidos pelo sistema (ex: cursos)
    • Para cada caso de teste
      • Identifique o resultado esperado do cenário em questão
  • Encontrando condições e resultados esperados
  • Examplo de matriz de casos de teste – Registro em curso Cada linha é um caso de teste Nota: V = Valido I = Inválido
  • Matriz de caso de teste – Observações
    • Nenhum valor real foi apontado para as condições
    • Facilita a visualização das condições a serem testadas
    • Facilita a determinação da cobertura de teste suficiente
      • Avalie os V's e I's
      • No mínimo um I para cada valor
    • Testes abrangentes devem incluir casos de testes positivos e negativos
      • O exemplo RC1 é um caso de teste positivo
      • Os exemplos RC2 a RC9 são casos de testes negativos
  • Derivando casos de testes de casos de uso
    • Passo um
      • Identificar todos os caminhos do caso de uso - cenários
    • Passo dois
      • Para cada cenário, crie um caso de teste e identifique as condições nas quais cada caso de teste executará
    • Passo três
      • Revise e reconsidere cada um
      • Adicione valores de dados para cada condição de teste
  • Casos de Testes – O que falta?
    • Revisar e validar os casos de testes
      • Garantir acurácia, relevância, eficácia
      • Eliminar redundâncias ou casos de testes equivalentes
    • Uma vez aprovados os casos de testes:
      • Os valores de dados reais podem ser identificados (minerados) e inseridos na matriz para a construção da massa de dados de teste
  • Exemplo de Matriz com valores
  • Revisão
    • Cada caso de uso pode ser entendido como uma fonte de um conjunto de casos de testes
      • Um caso de uso tem múltiplos cenários
      • Cada cenário tem vários casos de testes
    • Testar basedado em casos de uso fornece uma cobertura primária para os testes funcionais
      • É uma forma de testes de caixa-preta
      • Uma boa estratégia de testes requer tanto testes de caixa-preta quanto de caixa-branca
        • Testar os casos de uso não é suficiente
        • Realizações de caso de uso ajudam nos testes de caixa-branca
    • Testes baseados em casos de uso
      • Permite aos testadores escreverem casos de testes antes do código ser escrito
      • Fornece um método claroe eficaz
      • Dá aos testadores um ponto de partida para entender o que a aplicação supostamente faz
  • Lab: Construindo matrizes de casos de testes
    • Examine os casos de uso do projeto
    • Liste os cenários de testes
    • Liste os casos de testes
    • Valide a matriz de casos de testes para valores válidos, inválidos
    • Preencha a matriz de casos de testes com dados minerados da base de dados da aplicação
    • Revise a matriz, agrupe os casos de testes por equivalência e analise os valores limites
  • Módulo 3: Suíte de Testes Funcionais IBM Rational Functional Test Luís Felipe Cipriani
  • Objetivos do módulo
    • Explicar o conteúdo e função do Rational Project
    • Explicar as funções do Rational Administrator
    • Uso do Rational Administrator para registrar um projeto existente, criar usuários e grupos, e atribuir permissões para grupos
  • Objetivos de teste
    • Avaliar a qualidade do produto de software por meio de:
    • Procura e documentação de defeitos de software
    • Avisar ao envolvidos e defender a percepção de qualidade evidenciada
    • Fornecer a validação das hipóteses assumidas em projeto e especificação de requisitos através de uma demonstração concreta
    • Validar se as funções do software estão em conformidade com o projetado
    • Validar que os requisitos que foram acordados com o cliente foram efetivamente implementados
  • Principais problemas nos testes de software
    • Testar software é uma atividade de muita dificuldade
    • Testes são, geralmente, feitos sem um método claro e eficaz
    • Testes são feitos sem o uso de ferramentas adequadas
    NASA reports loss of Mars Climate Orbiter - 1999 Investigation of failure reveals software used combination of miles and meters for measurement ... NASDAQ Index Update Error - 1998 Net asset values were reported incorrectly to investors for several hundred mutual funds ...
  • Abordagem do Framework Software de Qualidade Ferramentas Processo B O A S P R Á T I C A s
  • Ferramentas de apoio a testes funcionais
    • Rational TestManager
      • Gerencia, rastreia e relata esforços de testes
    • Rational Robot
      • Grava, edita e reproduz scripts de testes funcionais
    • Rational ClearQuest
      • Gerencia, rastreia e relata defeitos encontrados
  • Integração das ferramentas Rational Testes Estruturais Repositório: Projeto Rational Course.dll People.dll Course User Register.exe Billing.exe Billing System
  • O que é um projeto Rational?
    • Uma integração lógica de banco de dados e datastore que associa os dados necessários para uso integrado das ferramentas Rational
    • Inclui
      • Rational Test datastore
      • Rational RequisitePro project
      • Rational ClearQuest database
      • Rational Rose models
  • Test Datastore
    • Armazena informações sobre o teste da aplicação, incluindo:
      • Scripts de Teste
      • Suítes de Test
      • Planos de Teste
      • Logs de Test
      • Datapools
      • Informações de resultados (Build)
      • Relatórios
  • Rational Administrator
    • Centraliza o gerenciamento de um Projeto Rational
      • Cria, deleta e conecta projetos Rational
      • Cria e gerencia usuários e grupos em um Test Datastore
      • Gerencia privilérios de segurança em um Test Datastore
      • Criar e gerencia projetos Rational integrando
      • documentos do RequisitePro, modelos Rose e informações do ClearQuest
      • Sincroniza dados entre as várias ferramentas
      • Permite upgrade da versão dos ativos dos projetos
  • Criando um novo projeto 1 2 3
  • Configurando o projeto
  • Administrando privilérios para usuários e grupos
    • Test Analysts
    • Planejamento
    • Análise de resultados
    Testadores
    • Planejamento
    • Implementação
    • Execução
    • Análise de resultados
    Gerentes de Testes
    • Implementação
    • Execução
    • Privilérios disponíveis:
    • Planejamento de testes
    • Implementação de testes
    • Execução de testes
    • Análise de resultados
  • Gerenciando usuários e grupos de testes Para adicionar grupos: Insert > New User > New Group Para modificar grupos existentes: Right-click > Properties
  • Revisão
    • O que é um Projeto Rational?
    • O que é gravado em um Test datastore?
    • Quais as principais funções do Rational Administrator?
    • Porque deve-se gerenciar usuários e grupos?
    • Quais os privilégios que são atribuídos a usuários que não fazem parte de nenhum grupo?
  • Lab 3.1: Entendendo Projetos Rational
    • Registrar um projeto
    • Importar um arquivo de perfil do ClearQuest
    • Conectar com um projeto
    • Adicionar grupos e usuários
    • Atribuir permissão para grupos
  • Gerenciando Planos de Testes no IBM Rational TestManager
  • Objetivos do módulo
    • Definir os artefatos (ativos) e informações envolvidos no plano e projeto de testes
    • Gerenciar planos e projetos de testes no TestManager:
      • Definir iterações, configurações e computadores
      • Definir entradas de testes e registrar fontes de entrada
      • Definir, configurar e projetar casos de testes
      • Estabelecer links de rastreabilidade entre entradas de testes e casos de testes
      • Gerar relatórios de planejamento de testes
  • Entradas e atividades do planejamento e projeto de testes Test Case Definir Missão Identificar Motivadores Identificar Alvos Definir avaliação e rastreabilidades Definir abordagem de teste Identificar opiniões Definir Detalhes Definir ambiente e configurações Obter compromisso com a testabilidade Especificações de sistema Requisitos Pedidos de alteração Lista de riscos Plano de Iteração Especificações de Projeto Modelos de casos de uso Test Plan Test-Ideas List Test Automation Architecture
  • O plano de Testes
      • Um ou mais documento que :
      • Defina as metas e objetivos dos testes que devem ser gerenciados na iteração ou projeto
      • Identificar software e hardware alvos de testes
      • Delinear os testes que serão executados
      • Identificar abordagem que será adotada (estratégia)
      • Estimar os recursos necessários
      • Definir um calendário e marcos de projeto
      • Identificar produtos do trabalho chaves
    Plano de Teste
  • Os desafios da gerência de testes
    • Como é avaliada a qualidade atual do sistema em desenvolvimento?
    • Como são definidas, medidas e rastreadas as metas de qualidade atuais?
    • Como são coordenados os esforços dos envolvidos no esforço de testes?
    • Como são rastreadas as dependências e relacionamentos entre os ativos?
    • Como são controlados o planejamento, execução e avaliação de testes iterativos?
  • TestManager: Plataforma central para gerência de testes Gerência de Resultados Pass Fail Relatórios integrados Scripts GUI e VU Scripts Java ou Basic Scripts para outros S.O. Projeto Iterações de teste Configurações Planos Casos Teste Entradas de Testes Rational TestManager Adapters Input Execution Adapters
  • Planejamento orientado à Casos de Testes Caso de Teste O que motiva os testes? Entradas de Testes Implementações Configurações Onde será testado? Quando será testado? Iterações Como será conduzido? 
  • Planejamento Visual Casos de Testes Pastas de Testes Plano de Teste Configurações
  • Passos para gerenciar Planos e Projetos de Testes
    • Conecte a um Projeto
    • Defina informações de planejamento
      • Consulte/adicione entradas de testes
      • Planeje iterações, configurações, e computadores
    • Construa o(s) plano(s) de testes
    • Crie casos de testes
    • Configure casos de testes
    • Defina casos de testes
    • Executar relatórios de planejamento de testes
  • Entradas de Testes
    • Pode ser qualquer coisa que o testador utiliza para ajudar a determinar o que será testado em cada iteração
    • Tipos de entrada nativos do TestManager
      • Requisitos do Rational RequisitePro
      • Elementos de modelo do Rational Rose
      • Valores em planilhas Microsoft Excel
    • Tipos customizados de entrada de testes
      • Arquivos include C++, documentos Microsoft Word, pedidos de alterações do Rational ClearQuest
      • Implementações DLL
  • Visão de Entrada de Testes View > Test Inputs
  • Definindo Iterações, Configurações e Computadores Define computadores que serão executados os testes Define iterações de para o plano de testes Define configurações das aplicações de teste Define atributos de configuração
  • Adicionando Configurações e atributos Tools > Manage > Configurations > New
  • Adicionando Computadores Tools > Manage > Computers > New
  • Lab 3.2: Gerenciando Planos de Testes
    • Conecte ao Projeto Rational
    • Navegue na janela principal do TestManager
    • Registre uma planilha Excel como fonte de entrada de teste
    • Gerencie as configurações e atributos
  • Construindo um plano de testes no TestManager File > New Test Plan Nome do plano de teste Descrição (opcional) proprietário (opcional)
  • Associando documentos externos a Planos de Testes Associa um documento externo
  • Criando pasta de casos de testes Selecione Insert Test Case Folder Selecione o plano de teste na janela Test Plan, e clique com o botão direito do mouse
  • Criando Casos de Teste Selecione a pasta de caso de teste, e clique com o botão direito Selecione Insert Test Case
  • Duas visões de Casos de Testes
  • Associando entradas, iterações, e configurações
  • Casos de Testes configurados
  • Casos de Testes Suspeitos Entrada 1 Entrada 2 Entrada 1 Entrada 2 Alteração significante Marcado como suspeito Associação Associação Caso de Teste A  Caso de Teste B  Caso de Teste C  Caso de Teste A  Caso de Teste B  Caso de Teste C 
  • Visualizando o status de Casos de Teste Casos de Testes suspeitos
  • Alterando status de Suspeita Altera o status suspeito
  • Lab 3.3: Construindo um plano de teste
    • Inicie o Rational TestManager e conecte ao projeto
    • Adicione um plano de teste
    • Associe um documento externo ao plano de teste
    • Adicione uma pasta de casos de testes ao plano de teste
    • Crie e configure casos de testes
  • Lab 3.4 Identifique casos de testes suspeitos
    • Visualize os casos de testes suspeitos
    • Elimine a suspeita dos casos de testes
  • Considerações sobre projeto de casos de teste
    • Dados
    • Seqüência
    • Modularidade
    • Ações de navegação
    • Ações adicionais
    • Pontos de verificação
    • Automação
  • Identificação de dados de casos de testes
    • Configuração de Testes
      • Fonte de dados da aplicação
        • Dedicado ao esforço de testes
        • Deve ter um conjunto de dados pequeno, estático e controlado
        • Deve poder ser reinicializada para a condição inicial
      • Configurações de Hardware e software
        • Configuração do Cliente
        • Configuração do Servidor
        • Suporte de Impressão
        • Conexões de rede
        • Versão de software de terceiros
  • Identificação dos dados de casos de testes (cont.)
    • Características de dados de teste
      • Profundidade
      • Amplitude
      • Escopo
      • Arquitetura
      • Gerenciamento
    • Retorno ao estado inicial dos dados
      • Refresh
      • Reinicialização
      • Reset
      • Roll forward
  • Seqüência
    • Faça os testes corretos para uma ordem determinada
      • Primeiro os testes que carregam dados
      • Depois testes que deletam dados
      • Um teste pode tratar os dados para o seguinte
    • Atributos de seqüência podem afetar o projeto e a implementação dos testes
      • Considere o impacto na atribuição da tarefa e no plano de iteração
  • Modularidade
    • Como regra geral, foque o script de teste em um casos de testes independentes
    • Projete os scripts para facilitar
      • Reusabilidade
      • Manutenção
      • Longevidade
      • Eficiência
    • Todos os scripts de testes iniciar e terminam no mesmo ponto da aplicação em teste
    • Pode seguir a dependência de dados
    Modularidade: Estratégia Roundtrip Test Script 1 Test Script 2 Test Script 3 Test Script 4 Funcionalidade 1 Funcionalidade 2 Funcionalidade 3 Funcionalidade 4
  • Modularidade: Estratégia de segmentação
    • Cada script de teste inicia onde o anterior terminou
    • Cada script de teste segue uma dependência de aplicação
    Test Script 1 Test Script 2 Test Script 3 Test Script 4 Funcionalidade 1 Funcionalidade 2 Funcionalidade 3 Funcionalidade 4
  • Navegação e ações adicionais
    • Ação de Navegação:
      • Transição de um ponto a outro na aplicação em teste
      • Hot keys vs . opções de menu
      • Pode ou não incluir pontos de verificação
    • Ações adicionais podem ser necessárias para suportar o processode teste:
      • Iniciar a aplicação
      • Reinicializar o banco de dados
      • Parar a aplicação
      • Capturar detalhes de saídas de testes
  • Pontos de Verificação
    • Como dizer que a aplicação funciona como esperado?
      • Somas, totais, balanços
      • Exibição de dados
      • Mensagens de erro
      • Movimento de cursores
      • Manipulação de janelas
      • Queries
  • Automação
    • Determine quais casos de testes são bons candidatos para automação
      • Principais candidatos:
        • Testes complexos e que consomem muito tempo manualmente
        • Testes que requerem uma grande precisão
        • Testes que envolvem muitos passos simples e repetitivos
        • Testes que envolvem muitas combinações de dados
      • Candidatos com baixa prioridade:
        • Testes executados uma única vez
        • Processos batch
        • Testes que envolvem dispositivos periféricos
        • Testes de avaliação subjetiva ( ex: look & feel)
  • Detalhando casos de testes no TestManager Impressão Clique para mudar para passos ou ponto de verificação Em iterações iniciais, detalhe o caso de teste em alto-nível
  • Detalhando casos de testes no TestManager (cont.)
  • Associando documentos externos a casos de testes
  • Relatório de distribuição de casos de testes
    • Relatório de distribuição de casos de testes exibe
      • O número de casos de testes planejados
      • O número de casos de testes implementados com scripts
      • O número de casos de testes que não tem implementação
      • O número de casos de testes implementados com scripts manuais ou automáticos
    • Distribuição de casos de testes para avaliar a cobertura dos testes
      • Cobertura de planejamento de testes
      • Cobertura de desenvolvimento dos testes
      • Cobertura de execução dos testes
  • Relatórios de Listagem
    • Os relatórios sobre os ativos do projeto incluem
      •  Builds  Usuários
      •  Configurações  Lista de computadores
      •  Computadores  Iterarações
      •  Suítes  Planos de testes
      •  Scripts de teste  Logs de testes
      •  Sessões
  • Criando um relatório de distribuição de casos de teste Reports > New Selecione um item sobre o qual será a distribuição Selecione o formato da exibição
  • Revisão
    • Nomeie os artefatos que fornecem as seguintes informações:
      • Esforço de planejamento de testes?
      • Esforço de detalhamento de testes?
    • No TestManager, o que é um test input? O que são entradas pré-definidas de testes?
    • No TestManager, o que é um caso de teste configurado?
    • No TestManager, o que significa um caso de teste estar marcado como suspeito?
  • Revisão (cont.)
    • Quais os principais fatores que devem ser considerados no detalhamentos de casos de testes?
    • Qual a diferença entre as estratégias de modularidade: roundtrip e de segmentação?
    • Que tipo de informação que o relatório de distribuição de casos de testes que TestManager pode dar?
  • Lab 3.5: Detalhando um caso de teste no TestManager
    • Use o TestManager para detalhar casos de testes:
      • Descreva os passos e pontos de verificação no editor de detalhes de casos de testes (Design)
      • Especifique as pré-condições, pós-condições e critérios de aceitação
  • Lab 3.6: Criando relatórios de planejamento de testes
    • Crie e execute um relatório de distribuição de casos de testes
    • Crie e execute um relatório de cobertura de testes
    • Crie e execute um relatório de listagem
    • Crie um relatório customizado
  • Módulo 4: Desenvolvimento de Scripts de Testes IBM Rational Robot Luís Felipe Cipriani
  • Objetivos do módulo
    • Descrever a evolução do processo de teste
    • Criar scripts manuais
    • Associar scripts manuais ou implementados à casos de testes
    • Descrever o fluxo básico de gravação, execução e verificação de um script do Rational Robot
    • Gravar e executar um script GUI
    • Definir shell scripts e avaliar seus benefícios
    • Criar shell scripts e analisar os resultados
  • Scripts de Testes
    • Instruções passo-a-passo que realizam um teste, e/ou permitem sua execução
    • Podem ser manuais, instruções textuais a serem seguidas e executadas manualmente, ou intruções de computadores executáveis automaticamente
  • A evolução de um teste Identificar Motivaçõesdo teste Identificar os alvos do teste Identificar idéias de teste Caso de Teste Detalhar o s testes Scripts Automáticos Test Suite Implementar Teste Scripts Manuais
  • Scripts Manuais
    • Criados dentro do TestManager utilizando o Rational ManualTest
    • Consistem de passos e pontos de verificação
    • Executados manualmente pelo testador
    • Podem estar associados com casos de testes e são executados no TestManager. Seus resultados são utilizados na geração dos relatórios
  • Criando Scripts Manuais no Rational ManualTest File > New Test Script > Manual
  • Associando uma implementação manual à um caso de teste Clique para escolher um script já existente como implementação
  • Gerando scripts manuais à partir de casos de testes
  • Ícones de implementação Caso de Testes sem implementação associada Casos de testes com implementação manual Casos de testes configurados com scripts automáticos e herdados de um caso de teste pai
  • Lab 4.1 Criando um script de teste manual
    • Criar um script manual no TestManager utilizando o Rational ManualTest
    • Associar uma implementação manual com um caso de testes no TestManager
    • Gerar um script manual à partir de um caso de teste detalhado
  • Preparação para automatizar testes
    • Relacione os padrões de projeto para:
      • Organizar artefatos de projetos de testes
      • Convenção de nomes de scripts de teste
      • Compartilhamento de artefatos de teste
      • Compartilhamento de dados de teste
    • Determine o melhor método para automatizar os pontos de verificação da aplicação em teste
  • Considerações sobre estrutura de automação de testes
    • Maximize o reuso dos scripts de teste
    • Minimize a necessidade de manutenção dos scripts
    • Os scripts de testes podem ser executados na seqüência da navegação ou em outras ordens
    • Dependências
      • Lógica contida nos scripts
      • Estado da base de dados
      • Estado da aplicação em teste
  • Influências sobre a automação
    • Ferramentas de automação
    • Técnicas de gravação
    • Ambiente de teste
      • Aplicação em teste
      • Configuração de Hardware/Software
      • Dados de testes ( hard-coded ou variáveis)
    • Scripts já existentes
  • Rational Robot Permite a gravação e execução de scripts de testes automáticos que navegam pela aplicação e testa o estado dos objetos por meio dos pontos de verificação
  • Modos de gravação de scripts
    • Orientado a objetos
    • É o método padrão de gravação
    • Grava ações na camada de objetos visuais do Windows
    • Gera scripts extensíveis e editáveis
    • Linguagem SQABasic e Java
    • Baixo-nível
    • Grava os movimentos do mouse como coordenadas de tela
    • Executa em tempo-real o movimento gravado
    • Grava eventos de objetos extras como desenhos e CAD
    • Cria um arquivo binário que não pode ser editado
  • Gravação orientada a objetos visuais Objetos Buttons Menu Edit box Tree view Window region Window Label ComboBox
    • Reconhece objetos por identificadores internos, não por coordenadas de tela
    Gravação orientada a objetos visuais (cont.) OK OK Versão 1 Versão 2
    • Permite avaliar o estado, propriedades e dados de objetos visuais da aplicação
    Gravação orientada a objetos visuais (cont)
    • Permite o teste de objetos visíveis ou não na tela .
    Gravação orientada a objetos visuais (cont.) Visualização da lista de objetos visíveis ou não da aplicação
  • Fluxo de gravação e execução de scripts Configure o ambiente de teste Insira Pontos de Verificação Configure opções de gravação Inicie a gravação Execute ações dos usuários Reconfigure o ambiente Create verification points Configure opções de execução Execute o script de teste Insira pontos de controle Finalize a gravação Visualize e analise os resultados
  • Configuração do ambiente de testes
    • O contexto é fundamental
      • Ambiente de testes
        • Configuração de Hardware
        • Base de dados de testes
        • Configurações de rede e segurança
      • Estado da aplicação
      • Seqüência das ações
    • Contexto inconsistente = falha no script de teste
  • Opções de gravação do Robot Tools > GUI Record Options
  • Iniciando a gravação de scripts GUI Nome do script Opções de gravação Record GUI Test Script button on toolbar or File > Record GUI
  • Execução das ações do usuário Pausa na gravação GUI Record toolbar Grava suas ações de interação com a aplicação
  • Criando pontos de verificação
    • Pontos do script nos quais devem ser confirmados os estados da aplicações ao longo das versões
    Exibição da GUI Insert Toolbar Pontos de Verificação
  • Finalizando a gravação Termina a gravação Gera o script SQABasic
  • Lab 4.2: Gravando um script GUI
    • Gravando um script básico no Rational Robot
    • Visualizando e executando scripts de teste
    • Visualizando os resultados da execução
  • Fluxo de gravação e execução de scripts Configure o ambiente de teste Insira Pontos de Verificação Configure opções de gravação Inicie a gravação Execute ações dos usuários Reconfigure o ambiente Create verification points Configure opções de execução Execute o script de teste Insira pontos de controle Finalize a gravação Visualize e analise os resultados
  • Pontos de verificação do Rational Robot Imagem de janela Alfanuméricos Clipboard Scan no site Web Propriedade de objetos Comparação de arquivos Existência de arquivos Existência de módulos Existência de janela Menu Objeto de dados Região de imagem Comparação de site web
  • Selecionando o ponto de verificação apropriado
    • Objetive o elemento essencial
    • Considere as dimensões de qualidade
    • Guie-se pelos casos de testes
    • Considere eficiência de custo e tempo
  • GUI Insert Toolbar: Pontos de Verificação Propriedades de objetos Alfanumérico Objeto de dados Menu Clipboard Região de imagem Imagem de janela Existência de janela Scan de site web Comparação de site web Display GUI Insert Toolbar
  • Selecionando o objeto de teste Arraste o Object Finder sobre o objeto e libere o botão no mouse ou Clique em Browse para selecionar o objeto à partir de uma lista de todos os objetos no desktop
  • Exemplo de Ponto de Verificação: Existência de Janela
    • Verifica a existência de uma janela específica
    • Verifica se uma janela não existe
    • Identifica janela por um método de reconhecimento
    • Testa o estado da janela
  • Exemplo de Ponto de Verificação: Menu Seleção das células de teste Método de identificação Descrição de seleções Método de Verificação
  • Lab 4.3: Inserindo Pontos de Verificação
    • Usar o Rational Robot para gravar scripts reusável de logon, logoff e da tela inicial da aplicação Classics Online
    • Inserir um ponto de verificação de existência de janela
    • Inserir um ponto de verificação de menu
  • Fluxo de gravação e execução de scripts Configure o ambiente de teste Insira Pontos de Verificação Configure opções de gravação Inicie a gravação Execute ações dos usuários Reconfigure o ambiente Create verification points Configure opções de execução Execute o script de teste Insira pontos de controle Finalize a gravação Visualize e analise os resultados
  • Restauro do ambiente para execução
    • Restaurar o ambiente de teste para o estado inicial
    • Restaurar o ambiente Windows
    • Restaurar a aplicação para o estado inicial
      • Base de Dados (restaurar a base)
      • Ambiente da aplicação (restaurar janelas)
    • Desabilitar mecanismo de mensagens de rede
    • Desabilitar utilitários
  • Opções de execução GUI
    • Recuperação de erros
    • Log
    • Execução
    • Janelas ativas inesperadas
  • Antes de executar o teste propriamente dito
    • Execute o script de teste para verificar que ele funciona como esperado
      • A aplicação se comporta como planejado
      • Os pontos de verificação capturam os dados corretos
    • Debugue os scripts para resolver possíveis problemas
    • Edite o script de teste para torná-lo mais confiável, de fácil manutenção e reutilizável
    • Configure o script de teste para utilizar dados externos ou um datapool
  • Fluxo de gravação e execução de scripts Configure o ambiente de teste Insira Pontos de Verificação Configure opções de gravação Inicie a gravação Execute ações dos usuários Reconfigure o ambiente Create verification points Configure opções de execução Execute o script de teste Insira pontos de controle Finalize a gravação Visualize e analise os resultados
  • Visualização e análise dos resultados
    • Visualização dos resultados na janela Test Log
      • Nenhuma falha de pontos de verificação?
      • Nenhum erros de comando?
      • Nenhuma mensagem de warning?
    • Avaliando falhas com os comparadores
      • Comparador de texto
      • Comparadores de imagem
      • Comparador de propriedades de objetos
      • Comparador de Grid
  • O Log de teste
      • Pontos de verificação
    Resultados pass/fail
      • Comandos do Script
  • Quando os pontos de verificação falham
    • Uma falha revela uma diferença entre um resultado esperado e o resultado obtido
    • Investigue todas as falhas
    • Use os comparadores para determinar as diferenças
    • Atualize os dados de baseline se for necessário
      • Melhora no produto
      • Mudanças na interface
    • Relate os defeitos se necessário
  • Lab 4.4: Executar um script e visualizar resultados
    • Revisar e configurar o Robot para recuperação de erros, log e opções de execução
    • Execute o script gravado para avaliar sua correção
    • Revise o script, reexecute e avalie os resultados
  • Shell Scripts Execução Test Script 1 Test Script 2 Test Script 3 Test Script 4 Shell Script Test Script 1 Test Script 2 Test Script 3 Test Script 4
  • Benefícios dos Shell Scripts
    • Habilitam a execução de scripts não relacionados a casos de teste
    • Simplifica a organização de scripts de testes
    • Centraliza os resultados no log
    • Facilita os testes de regressão
    • Ajuda a garantir um teste mais completo
  • Creating Shell Scripts
    • File > New > GUI Shell Script
    Nome do shell script Lista de scripts GUI disponíveis Adiciona scripts GUI script ao shell
  • O comando CallScript Os s hell scripts adicionam comandos CallScript ou Adicione manualmente o comando CallScript Insert > Call Script
  • Lab 4.5: Criando um Shell Script
    • Crie um shell script
    • Execute o shell script
    • Analise os resultados da execução
  • Revisão
    • Como é o ciclo de desenvolvimento de testes?
    • Que tipos de scripts podem ser associados como implementação nos casos de testes do TestManager?
    • Quais os passos do fluxo de desenvolvimento de scripts?
    • Quais são os passos críticos que ocorrem antes da gravação e antes da execução?
    • Quais é o conceito de baseline e qual seu valor para os testes?
    • Que funcionalidades permitem que você analise os resultados de testes?
    • Quais os benefícios de utilizar shell scripts?
  • Módulo 5: Desenvolvimento de Scripts Automatizados: Pontos de Verificação, Datapools IBM Rational Robot Luís Felipe Cipriani
  • Objetivos do módulo
    • Detalhar os pontos de verificação e descrever seu uso adequado
    • Explicar o uso apropriado de estados de espera (wait state)
    • Explicar como os comparadores ajudam na análise dos resultados de testes
    • Revisar e editar dados de baseline
    • Adicionar pontos de verificação a scripts Robot
  • Pontos de verificação Clique para expandir a GUI Insert toolbar Object Properties Alphanumeric Object Data Menu Clipboard Region Image Window Image Window Existence Web Site Scan Web Site Compare
  • Estado de espera e resultados esperados Nome do ponto de verificação Configuração do estados de espera Insert > Verification Point > Verification Point Type Especificação do resultado esperado
  • Selecionando o objeto de teste Arraste a ferramenta Object Finder sobre objeto e libere o botão do mouse ou Clique browse para selecionar o objeto na lista de todos os objetos visuais no desktop
  • A lista de objetos Duplo clique para expandir o objeto Duplo-clique para retrair o objeto Retorna ao método de seleção Object Finder A cor do objeto selecionado será invertida na aplicação Exibe os objetos escondidos no desktop
  • Ponto de verificação alfanumérico
    • Verifica dados alfanuméricos nos objetos padrão Windows
    • Testa edit boxes , pushbuttons, labels, e text fields
    • Avalia:
      • Caps do texto
      • Equivalência numérica ou continência em invervalos
      • Campos em branco
      • Comparação .dll definidas pelo usuários
      • Subconjunto de textos (manipulação de strings)
    &quot; Program &quot; 75 or &quot;75&quot;
  • Ponto de Verificação: propriedades de objetos
    • Testa os atributos de um objeto
    • Testa objetos individuais ou coleção de objetos dentro de uma janela
  • Objetos “filhos”
  • Seleção do que será verificado
    • Escolha um item de dados que reflita a operação feita na aplicação
  • Selecionando itens de um Edit List
    • Utilize a função Edit List para selecionar as propriedades que deseja validar
  • Resultados da Edit List
  • Lab 5.1: propriedades de objetos e VPs alfanuméricos
    • Grave um novo script Robot
    • Insira um ponto de verificação do tipo Object Properties
    • Insira um ponto de verificação Alfanumérico
    • Execute e verifique os resultados do script
  • Ponto de verificação Object Data
    • Testa o conteúdo de dados dos seguintes objetos:
      • PowerBuilder DataWindows, DataStores, Java, HTML, etc.
      • Controles ActiveX
      • Windows 32-bit common controls
      • Objetos tipo Lista
      • Menus
    • Reconhece os objetos automaticamente
  • Verificando dados em Grids
  • O ponto de verificação Data Grid Grid de dados para seleção das células que serão testadas Método de identificação Descrição da seleção Método de verificação
  • Selecionando os dados
    • Intervalo
    • Colunas inteiras
    • Linhas inteiras
    • Células adjacentes
    • Células dispersas
    • Todas as células
  • Método de verificação
    • Case-sensitive
    • Case-insensitive
    • Equivalência numérica
    • Intervalo numérico
    • Valores definidos pelo usuário
    • Subconjunto de strings
  • Métodos de identificação
  • Selecionando conjunto de dados
  • Valores chaves
  • Dados de objetos vs. propriedades de objetos
      • Captura somente conteúdo de dados
      • Ignora as propriedades de objetos
      • Exibe dados tabulados de maneira complexa em um grid de dados
      • Captura os atributos de objetos
      • Captura objetos individualmente ou coleção de objetos dentro de uma janela
    Ponto de verificação Dados de objeto Ponto de verificação propriedade de objeto
  • Outros pontos de verificação
    • Clipboard
    • Imagem de janela (Window Image)
    • Região de imagem (Region Image)
    • Arquivos
      • Existência de arquivos
      • Comparação de arquivos
    • Existência de módulos
  • Lab 5.2: Propriedades de objetos e dados de objetos
    • Insira um ponto de verificação de propriedades de objetos no script
    • Edite a lista de propriedades do objeto
    • Insira o ponto de verificação no script
    • Faça a distinção entre os pontos de verificação de propriedade de objetos e dados de objeto
    • Execute e verifique o script
  • Comparadores
    • propriedade de objetos
    • Imagem
    • Texto
    • Grid
    Grave scripts com os pontos de verificação Baseline Execute o script contra a aplicação Obtido COMPARE
  • Comparador de propriedades de objetos Lista de diferenças Propriedades do objeto comparado Hierarquia de objetos
  • Comparador de imagens
  • Criando máscaras de comparação
    • Edit > New Mask
    • Utilize o cursor para destacar a área a ser mascarada
    • Salve o baseline
  • Comparações em Grid Lista de diferenças Comparador de menu Grid de valores do menu
  • Comparador de texto
  • Atualização da Baseline
    • Durante a gravação pela edição de propriedades
    • Depois da gravação com os comparadores
  • Lab 5.3: Usando o comparador de textos
    • Edite os dados da baseline no ponto de verificação utilizando o comparador de texto
    • Reexecute o script utilizando a nova baseline
  • Testando com datapools
    • Execução de scripts múltiplas vezes com dados diferentes
      • Variação nos dados de teste
      • Testes de regressão
      • Teste de volume de dados
    • Usa arquivos de dados existentes, ou
    • Datapools
      • Utiliza a função datapool
      • Utiliza arquivos como fontes externas
  • Datapools
    • Criado e gerenciado no TestManager
    • Gera altos volumes de dados únicos automaticamente
    • Permite importar dados de outras fontes
  • Datapool: primeiros conceitos
    • Os valores são gravados em arquivos .csv
    • As colunas são gravadas em arquivos .spc
    • Pode suportar até 2 bilhões de registros de dados
    • O script deve ser modificado manualmente para utilizar dados do datapool
  • Tipos de dados Tipos de dados padrão e tipos de dados customizados
  • Passo 1: Planejando o Datapool
    • Quais colunas serão necessárias no datapool?
    • Que tipo de dados devem ser atribuídos a cada coluna?
    • Será necessária a criação de tipos de dados?
  • Passo 2: Modificando o código
    • Referência ao arquivo header SQAUTIL.SBH
    • Substituição de valores literais fornecidos pela gravação por variáveis
    • Adicionar comandos de acesso ao datapool manualmente
    Fecha o datapool SQADatapoolClose Recupera valores individuais do registro capturado SQADatapoolValue Captura um registro de dados do datapool SQADatapoolFetch Abre o datapool especificado SQADatapoolOpen
  • Passo 3: Criação e população do Datapool
    • Definir colunas do datapool
    • Geração de dados
  • Gerenciando Datapools Tools > Manage > Datapools
  • Lab 5.4: Testando com dados externos
    • Visualizar e modificando um arquivo simples de dados
    • Gravar e modificar um script para ler um arquivo de dados
    • Executar o script atualizar a baseline
  • Lab 5.5: Criando e utilizando Datapools
    • Criar um datapool
    • Editar um script para incluir comandos de datapool
    • Executar um script que utiliza dados de um datapool
  • Revisão
    • Quais tipos de variáveis gravadas podem ser controladas com o Robot?
    • Como selecionar objetos escondidos para verificar?
    • Como lida com objetos que não são reconhecidos? Como você pode contralar isso?
    • Quando utilizar pontos de verificação Dados de Objeto ou Propriedades de Objeto?
    • Quando utilizar ponto de verificação de região de imagem ao invés de Imagem de Janela?
    • O que é uma máscara e quando você pode aplicá-la?
    • Como os comparadores ajudam na avaliação de resultados de pontos de verificação?
    • Utilização de Datapools para a variação dos dados do teste.
  • Módulo 6: Executando e avaliando os testes IBM Rational Robot
  • Objetivos do módulo
    • Executar os scripts no Rational Robot
    • Executar os testes no Rational TestManager
    • Avaliar a execução de teste
    • Analisar os resultados de teste utilizando os logs e comparadores
    • Executar um teste de regressão da aplicação exemplo
  • Maneiras de executar um script de teste
    • Rational Robot
      • Scripts GUI
      • Scripts Shell
    • Rational TestManager
      • Vários tipos de scripts
      • Casos de testes
      • Suítes
    Flexibilidade Rastreabilidade Relatórios
  • Requisitos de execução de teste
    • Uma versão funcional e estável da aplicação em teste
    • Um conjunto de scripts corretos e confiáveis
    • Um ambiente de execução de teste estabelecido
  • Ambiente de configuração de teste
    • Configuração de ambiente de teste e do sistema
      • Hardware
      • Software (inclusive as ferramentas de automação)
    • Ambiente de inicialização
      • Aplicação em teste
      • Base de dados
      • Procedimentos de configuração do ambiente ou scripts utilitários
      • Ordem estabelecida dos scripts de teste
  • Passos para o testes de regressão Configurar Ambiente Criação Testes/ Suites Executar os Testes Recuperar os testes interrompidos Verificar os resultados esperados Investigar os resultados esperados Defeitos logados
  • Lab 7.1: Executando no Rational Robot
    • Modifique um shell script existente
    • Modifique um script existente
    • Configure as opções do Robot para os testes de regressão
    • Execute e verifique o shell script contra uma nova versão da aplicação
  • Avaliação de execução de teste
    • Determinar se um teste foi executado ou interrompido
    • Determinar se uma ação corretiva é requerida
  • Avalia o término de testes
    • Término normal
      • Todos os testes executados como planejado
      • Todos os resultados obtidos são válidos
    • Término anormal
      • Erros fatais (falhas de sistema)
      • Erros de script (terminados prematuramente)
  • Verificando os resultados de teste
    • Determinar se os resultados são confiáveis
    • Identificar as ações corretivas apropriadas
    • Identificar falhas nos esforços de teste ou artefatos
  • Falhas comuns
    • Falha na verificação
      • Modificações na aplicação
      • Modificação de dados
    • Janelas inesperadas
      • Problemas de sincronização
      • Scripts que não correspondem à navegação na aplicação
    • Janelas ausentes
      • Scripts que não correspondem à navegação na aplicação
      • Configurações na ferramenta de automação
  • Recuperação de testes interrompidos
    • Determinação das ações corretivas apropriadas para recuperar os testes interrompidos
    • Correção do problema, recuperação e re-execução dos testes
  • Recuperação de erros fatais
    • Causas possíveis
      • Problemas de rede
      • Interrupções elétricas
      • Falhas de software
    • Recuperação
      • Reconfiguração do ambiente de testes/sistema (se necessário)
      • Reinicialização do ambiente
      • Re-execução do script de teste
  • Recuperação de erros nos scripts
    • Causas possíveis
      • Scripts de testes e aplicação não coincidem
        • Falha de comandos nos scripts
        • Método de verificação de falhas
      • Sincronização entre os scripts e a aplicação
    • Recuperação
      • Investigar as diferenças entre o script e a aplicação
      • Modificar os scripts de teste e/ou os pontos de verificação
  • Executandos os scripts no TestManager File > Run Test Script > Type of Script Computadores onde os scripts executarão Clique para alterar o computador Onde os resultados serão gravados Clique para alterar onde os resultados serão gravados
  • Janela de scripts
    • Gravar um script de teste
    • Abrir um script de teste
    • Executar um script de teste
    • Editar as propriedades do script de teste
    • Implementar um caso de teste
    Nesta janela, você pode:
  • Propriedades de um script de teste Visualizar uma baseline capturado pelo ponto de verificação
  • Running Test Cases from TestManager File > Run Test Case ou Botão-direito
  • Executando um caso de testes no TestManager (cont.) Casos de testes que serão executados Adicione casos de teste na lista Ignora as configurações de sistema – executa os casos de testes nos computadores disponíveis Computador onde o caso de testes será executado Clique Change para alterar o computador Onde os resultados serão gravados Clique para alterar onde os resultados serão gravados
  • Executando uma implementação manual Executa os passos no Rational ManualTest, e grava os resultados dos passos e pontos de verificação
  • Visualizando os resultados de casos de teste Log de resultados de casos de teste
  • Visualizando os resultados de casos de testes Detalhe dos logs de resultados dos casos de testes
  • Dos logs de testes, você pode:
    • Usar comparadores para analisar os resultados
      • Comparador de propriedades de objetos
      • Comparador de imagens
      • Comparador de grids
      • Comparador de textos
    • Submete um defeitos ao Rational ClearQuest
  • Lab 6.1: Executando um caso de teste
    • Associar uma implementação automatizada com um caso de teste
    • Executar um caso de teste
    • Revisar e avaliar os resultados de uma execução na log do TestManager
  • Lab 6.2: Analisando detalhes de log
    • Examinar os resultados no TestManager
    • Analizar os pontos de verificação no comparador de grid e atualizar o arquivo baseline
    • Analizar o ponto de verificação no comparador de propriedades de objeto
    • Visualizar uma janela ativa inesperada no comparador de grid