Metodologia de Desenvolvimento de Software – RUP 5. Testes

Apresentação em tema: "Metodologia de Desenvolvimento de Software – RUP 5. Testes"— Transcrição da apresentação:

1 Metodologia de Desenvolvimento de Software – RUP 5. Testes
Márcio Aurélio Ribeiro Moreira

2 Conceitos de testes Teste: Teste de Regressão: Importância:
É a execução controlada do software visando revelar falhas Falha: Desvio de comportamento Erro: Origem da falha (bug) Teste de Regressão: Execução repetida dos Casos de Testes que falharam, bem como dos Casos de Testes impactados por eles, após a correção dos erros (bugs) que causaram as falhas Importância: Testes não provam que o software está livre de falhas. Eles minimizam este risco, aumentam a confiança e agregam valor ao produto São partes integrantes da qualidade

3 Elementos de testes De Planejamento: De Desenvolvimento: De Execução:
Estratégia de Teste: Define como o esforço de teste será conduzido Plano de Testes: Define objetivos, metas, abordagem e recursos testes de cada iteração Idéias de Teste: Lista de idéias a serem utilizadas nos testes De Desenvolvimento: Casos de Testes: Entradas, passos e saídas esperadas de cada teste Scripts de Testes: Códigos executados durante (preparação, execução, passos e geração de resultados) os Casos de Teste Dados de Teste: Massa de dados usada para realização dos testes Cenários de Teste: Variações que um mesmo Caso de Teste pode ter De Execução: Registro de Testes: Saída bruta da execução dos testes Resultados de Testes: Avaliação dos resultados dos registros de testes

4 Níveis de testes Quanto às pessoas: Quanto a granularidade:
Sistema A Subsistema A1 CmpA11 CmpA12 Subsistema A2 CmpA21 CmpA22 CmpA23 Sistema B Subsistema B1 CmpB11 CmpB12 Subsistema B2 CmpB21 CmpB22 Quanto às pessoas: Desenvolvedores Testes independentes: Entidades verificadoras (certificadoras) ou Usuários chaves do cliente Quanto a granularidade: Testes de unidade (desenvolvedores) Testes de integração (desenv.) (subsistemas) Testes de sistema (ambos) [Testes Integrados (ambos) (outros sistemas) ausente no RUP] Testes de aceitação (cliente) (UAT: User Acceptance Test) Quanto à forma: Formal: Seguem os casos de testes Informal: Não seguem roteiro (exploratórios, ad hoc ou aleatórios)

5 Stubs Testes de Sistema Testes Integrados e UAT Sistema D Sistema A
Sistema B Sistema C Sistema D Stub Sistema A Sistema B Sistema C

6 Visões de testes Quanto à visão do sistema:
Caixa preta (fora do sistema, sem visão interna) Caixa branca (dentro do sistema) Uso de testes nas dimensões da qualidade: Dimensão Unidade Integração Interna Sistema Integração Externa Aceitação Funcionalidade  Usabilidade Confiabilidade Desempenho Suportabilidade

7 Modelo V de testes Verificação Validação Nível 1 Nível 2 Nível 3
Implementação Projeto Modelagem de Negócio Requisitos Análise Arquitetura Teste Unitário Teste de Aceitação Teste Integrado Teste de Integração Teste de Sistema

8 Tipos de testes Funcionalidade: Utilidade: Confiabilidade: Desempenho:
Tamanho Real Volume esperado Contenção Volume extra Carga Até onde vai? Estresse Condições extremas Tipos de testes Funcionalidade: Função: A parte testável funciona como foi projetada? Segurança: Somente usuários autorizados têm acesso à funcionalidade? Volume: A funcionalidade suporta o volume de dados especificado? Utilidade: Usabilidade: O software tem a usabilidade que é esperada dele? Confiabilidade: Integridade: O software tem a robustez (resistência a defeitos) esperada? Estrutura: Os links, botões e opções de navegação funcionam corretamente? Estresse: Como o software lidas com muitos dados, pouca memória, etc.? Desempenho: Tamanho real: O software tem o desempenho esperado quando com volume real? Contenção: Como o software lida com solicitação excessiva de um recurso? Carga: Aumentando o volume de transações, até onde o software suporta? Perfil de desempenho: O software possui gargalos ou processos ineficientes? Suportabilidade: Configuração: Nosso software funciona em diferentes configurações (hw/sw)? Instalação: O processo de instalação funciona em diferentes configurações?

9 Objetivos dos testes Localizar e documentar defeitos na qualidade do software Dar sugestões sobre a qualidade do software Validar e provar as suposições feitas nas especificações de projeto e requisitos através de demonstração concreta Validar se o software funciona conforme o projeto Validar se os requisitos estão implementados adequadamente

10 Fluxo de trabalho de testes

11 Objetivos das atividades
Definir missão de avaliação: Identificar o foco apropriado do esforço de teste para a iteração e estabelecer consenso com os envolvidos sobre as metas que conduzirão o esforço de teste Validar abordagem do teste: Verificar por meio da demonstração que a abordagem de testes funcionará, produz resultados precisos e é apropriada para os recursos disponíveis Validar a estabilidade da construção: Validar que a construção esteja estável o suficiente, para que sejam iniciados o teste detalhado e o esforço de avaliação Testar e avaliar: Executar os testes e verificar se eles tem a amplitude e o detalhamento necessários para garantir que os testes atinjam seus propósitos Realizar a missão aceitável (atingimos a missão de aceitação?): Garantir a aceitação do produto através das avaliações dos testes Aprimorar vantagens dos testes: Manter e aprimorar os recursos de testes

12 A: Definir missão de avaliação 1

13 A: Definir missão de avaliação 2

14 A: Validar abordagem do teste 1

15 A: Validar abordagem do teste 2

16 A: Validar a estabilidade da construção 1

17 A: Validar a estabilidade da construção 2

18 A: Testar e avaliar 1

19 A: Testar e avaliar 2

20 A: Testar e avaliar 3

21 A: Realizar a missão aceitável

22 A: Aprimorar vantagens dos testes 1

23 A: Aprimorar vantagens dos testes 2

24 Essência dos testes Planejamento: Estratégia, Plano e Idéias de Testes
Arquitetura de Testes Ambiente de Testes Desenvolvimento : Casos de Testes Scripts, Dados e Cenários de Testes Projeto e Interfaces de Testes Execução: Log de Testes Mudanças (bugs ou ajustes a serem feitos) Resultados e Avaliação dos Testes

25 P: Estratégia de testes
Seções típicas do documento: Contexto: Missão de Avaliação (foco dos testes) e Motivadores de Testes (razões de existir dos testes) Abordagem: Extensão: Cobertura que será utilizada Medição: Como serão medidos os testes Técnicas: Quais técnicas serão utilizadas Ambiente: Hardware: Hardwares necessários aos testes Software: Softwares necessários aos testes Ferramentas: Utilizadas na medição e avaliação Configuração: Configuração final do ambiente Responsabilidades: Funções: Papéis necessários aos testes Pessoal: Pessoas necessárias para realizar os testes Responsabilidades: Que pessoa é responsável por qual papel Outros: Riscos, dependências, premissas, restrições, processo e procedimento de gestão dos testes

26 P: Plano de testes 2. Requisitos de Testes: 3. Estratégia de testes:
Quais tipos de testes serão utilizados ... 2.6. Teste de carga 2.7. Teste de estresse 2.8. Teste de volume 3. Estratégia de testes: 3.1. Descrever para cada tipo de teste: objetivo, técnica, critérios e detalhes 2.6. Teste de carga: Objetivo: Verificar o tempo de resposta do sistema para alguns casos de negócio Técnica: Utilizar Casos de Testes prontos, com variações que simulem o volume real de dados Critérios: Metas de transações e acessos concorrentes atingidos Detalhes: Para medição exata, utilizar máquina dedicada por um tempo dedicado 3.2. Ferramentas utilizadas Outros: funções x recursos x responsabilidades, marcos, datas, etc.

27 P: Idéias de teste Exemplo 1: Exemplo 2: Item Build Objeto Descrição
Esperado 1 Conta Criar uma conta do Tipo Cliente (PF ou PJ) e colocar acentuação no nome Não deve deixar salvar o registro com acento, mas deve deixar alterar o registro retirando o acento. 2 Adcionar uma conta a partir da tela principal (Account Home Public and Private View Link List Applet) Abrir a tela de cadastro de contas para informar os demais dados. 3 Começar a criar o conta como Pessoa Fisica (PF), preencher dados como data de nascimento, e alterar o tipo para PJ preencher a data de fundação, e mudar novamente para Pessoa Fisica, observe que o campo Data de Nascimento continuará preenchido com o valor anterior. Verificar o que será salvo. Deve salvar apenas o data referente ao tipo de Conta (PF ou PJ) que esta sendo informado. Alvo Nome Tipo Descrição Justificativa Filtros R001 Funcional Executar um relatório com dados que atendem os critérios dos filtros Garantir que os critérios dos filtros estão funcionando adequadamente Fórmulas R003 Verificar a corretude de todas as fórmulas utilizadas no relatório Garantir que as fórmulas utilizadas no relatório estão efetuando os cálculos de forma correta Visualização Usabilidade Executar um relatório com dados que contemplem todos os componentes visuais de apresentação do relatório (ex.: labels, campos, linhas, sombreamentos, gráficos, imagens e etc..) Garantir que a apresentação do relatório está de forma adequada

28 P: Caso de teste Fase: GL1 Build: 1
Ciclo: Catálogo de Produtos ID do TC: 149 Nome TC: Criação de Produtos Simples Prioridade: Baixa Passos: Step Action Inputs Expected Results Pre-requisitos Administrador ja procurou o produto e o produto nao foi encontrado Para os Produtos Simples, o Administrador deve escolher o Tipo de Estrutura como Nenhum  n/a n/a 1 Ir para a Tela de Administração - Produto- Visualização Produtos; produtos exibidos 2 Criar um novo registro; registro criado 3 Preencher os campos obrigatórios e requisitos opcionais a.Nome do Produto; b.Tipo de Preço; c.Unidade de Medida; d.Início e Término da Vigência e.Tipo de Estrutura = 'Nenhum'; f.Tipo de Serviço = Multimídia, Data Center; fornece a facilidade para adicionar os detalhes relevantes: - o tipo de preco: Recorrente, Uma vez e Por uso - definir a unidade de medida para o produto. Ex: Mensal, bimestral para produtos recorrentes. Data de Vigência Atual e Data de vigência Final no registro do produto definindo a disponibilidade do produto para o cliente alvo 4 Salvar o registro registro salvo 5 Liberar o produto; Produto liberado com sucesso

29 P: Resultados de testes 1
TestSetName TestID TestSuiteName TestStatus Comments Val End 6422 [Full-ValEnd] 19) Validação de campos - Applet Account Address Mvg Applet Passed 6423 [Full-ValEnd] 20) Validação de campos - Applet selecionar endereço para correção e ver a origem do endereço Teste executado com sucesso. Adq Dados 6605 [Full-AdqDadCli] 05 - tela de cadastro de novas contas de cliente pessoa física e contas de serviço e faturamento Ade Dados 6606 [Full-AdqDadCli] 04 - campos genéricos que serao utilizados na localização e criação de contas 6608 [Full-AdqDadCli] 02 - tela de cadastro de novos contatos e na manutenção dos principais dados cadastrais dos mesmos Testes efetuados, OK .. 6609 [Full-AdqDadCli] 01 - tela de localização e criação de contatos na base do Siebel. 6615 [Full-AdqDadCli] 23) Validação de dados no sistema AUDICON por processo batch - Pessoa Física Canceled não temos como fazer essa validação nessa fase de teste, pois não a integração apenas a sua simulação. 6631 [Full-AdqDadCli] 24) Validação de dados no sistema AUDICON por processo batch - Pessoa Jurídica Val Cred 6185 [Full-ValidCredit] 02) Validação de Crédito Prévia (FA1) - validação Botao Not Completed 6186 [Full-ValidCredit] 03) Validação de Crédito Prévia (FA2) - Falha na conexão com SOA

30 P: Resultados de testes 2
BuildName TestSetName Passed Failed Not Completed Not Run Pending Canceled Review Grand Total Fase 1 Adm. de Dados 77% 0% 23% 100% Catalogo de Produtos 73% 9% 18% Ger. de Contato 78% 22% Master Docs 61% 4% 34% Master Docs NOVO 71% 29% Perfil - Positions Perfil - Respons. 70% Perfil de Acesso Requisitos Gerais 68% 19% 3% 10% Testes Alterados 28% Fase 1 Total 51% 7% 1% 40% Steps Qtd % Passed 2918 35% Failed 372 5% Not Run 2908 Canceled 2030 25% Total 8228 100% Bug Status Qtd % Closed 1032 78% Closed/canceled 199 15% Open 92 7% Grand Total 1323 100% Bug Severity Qtd % Show Stopper 18 1% Critical 109 8% Severe 378 29% Moderate 704 53% Cosmetic 110 Grand Total 1323 100%

31 P: Avaliação dos testes 1
Resultado Estratégia X % de Sucesso Densidades Legenda: Exec = Execução Suc = Sucesso CT = Caso de Teste PT = Passos de CT Falhas / C.T.Executado Bugs / C.T.Executado

32 P: Avaliação dos testes 2
Severidade final Severidade Média Bloqueador Severo Moderado Cosmético Severidade

33 P: Avaliação dos testes 3
100% em 7/7/2010

34 Exercício 3: Contexto Considerando o mesmo projeto dos exercícios 1 e 2, e além disto: A empresa de consultoria tem fábricas de software em: São Paulo no Brasil: que fará a interface com o cliente A língua utilizada para fazer modelagem, análise e projeto é o português 2 cidades na Índia: que farão a maior parte do desenvolvimento A língua oficial da consultoria na Índia é o inglês A empresa de consultoria é parceira da Oracle e participou das validações das customizações propostas feita com a Oracle A empresa de consultoria utilizará uma unidade deles especializada em testes, que fica em Brasília As responsabilidades de testes ficaram combinadas da seguinte forma: Testes Unitários e Testes de Integração (internos): Responsabilidade da consultoria Testes de Sistema e Testes Integrados (externo, ou seja, com outros sistemas): A consultoria: Desenvolve os Casos de Teste A empresa: Valida os Casos de Teste A consultoria: Executa os Casos de Teste e fornece evidências da execução A empresa: Verifica as evidências e registra as rejeições A consultoria: Corrige as rejeições e fornece novamente para a empresa Teste de Aceitação: Responsabilidade integral da empresa

35 Exercício 3: Questões Que Atividades e Tarefas de Implementação & Testes do RUP vocês recomendam que sejam utilizadas neste caso? Justifique porque vocês incluíram ou excluíram cada Atividade e Tarefa. Vocês recomendam alguma tarefa adicional para as Atividades selecionadas? Quais e por que? A Construção está prevista para 4 meses e a consultoria tomou algumas decisões não muito assertivas nas etapas anteriores. O que você pode fazer para: Ter maior assertividade na entrega da Construção? Ter mais confiança no software nos Testes de Sistema?

36 Referências Sigla Referência BEI90
BEIZER, Boris. Software testing techniques. Scottdale: Coriolis Group, 1990, 2 ed. JAC98 Ivar Jacobson, Grady Booch, and James Rumbaugh. The Unified Software Development Process Addison Wesley Longman. KAN01 Cem Kaner, James Bach e Bret Pettichord Lessons Learned in Software Testing. John Wiley & Sons, Inc. KRO03 Per Kroll e Philippe Kruchten The Rational Unified Process Made Easy, A Practitioners Guide to the RUP. Addison Wesley Longman. KRU98 P. Kruchten; The Rational Unified Process: An Introduction, Object Technology Series, Addison-Wesley, 1998. MAR05 Márcio Moreira. Resumo do livro Unified Process. Márcio. Uberlândia (MG) MAR06 Márcio Moreira. Engenharia de Software - RUP . Uniube - Universidade de Uberaba - Uberlândia (MG) MEY79 MYERS, Glenford J. The art of software testing. New York: John Wiley & Sons, 1979. PRE95 PRESSMAN, R. S. Engenharia de software. São Paulo: Makron Books RUP08 IBM Rational. RUP – Rational Unified Process – 7.5 – For Large and Small Projects IBM Rational. SUM07 Sommerville, Ian. Engenharia de Software. 8ª Ed. Pearson / Prentice Hall