Processo de Desenvolvimento de Software RUP 5 Testes

  • Slides: 36
Download presentation
Processo de Desenvolvimento de Software – RUP 5. Testes Márcio Aurélio Ribeiro Moreira marcio.

Processo de Desenvolvimento de Software – RUP 5. Testes Márcio Aurélio Ribeiro Moreira marcio. moreira@pitagoras. com. br http: //si. lopesgazzani. com. br/docentes/marcio/

Conceitos de testes Ø Teste: l É a execução controlada do software visando revelar

Conceitos de testes Ø Teste: l É a execução controlada do software visando revelar falhas l Falha: Desvio de comportamento l Erro: Origem da falha (bug) Ø Teste de Regressão: l 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: l Testes não provam que o software está livre de falhas. Eles minimizam este risco, aumentam a confiança e agregam valor ao produto l São partes integrantes da qualidade Márcio Moreira 5. Testes – slide 2 Processo de Desenvolvimento de Software - RUP

Elementos de testes Ø De Planejamento: l Estratégia de Teste: l Plano de Testes:

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

Níveis de testes Sistema A Subsistema A 1 Ø Quanto às pessoas: l Desenvolvedores

Níveis de testes Sistema A Subsistema A 1 Ø Quanto às pessoas: l Desenvolvedores l Testes independentes: Cmp. A 11 Cmp. A 12 Sistema B Subsistema A 2 Cmp. A 21 Cmp. A 22 Cmp. A 23 Subsistema B 1 Cmp. B 12 Subsistema B 2 Cmp. B 21 Cmp. B 22 v Entidades verificadoras (certificadoras) ou Usuários chaves do cliente Ø Quanto a granularidade: l l l Testes de unidade Testes de integração Testes de sistema [Testes Integrados Testes de aceitação (desenvolvedores) (desenv. ) (subsistemas) (ambos) (outros sistemas) ausente no RUP] (cliente) (UAT: User Acceptance Test) Ø Quanto à forma: l Formal: Seguem os casos de testes l Informal: Não seguem roteiro (exploratórios, ad hoc ou aleatórios) Márcio Moreira 5. Testes – slide 4 Processo de Desenvolvimento de Software - RUP

Stubs Testes de Sistema Testes Integrados e UAT Sistema D Stub Sistema A Sistema

Stubs Testes de Sistema Testes Integrados e UAT Sistema D Stub Sistema A Sistema B Stub Sistema C Márcio Moreira Sistema C 5. Testes – slide 5 Processo de Desenvolvimento de Software - RUP

Visões de testes Ø Quanto à visão do sistema: l Caixa preta (fora do

Visões de testes Ø Quanto à visão do sistema: l Caixa preta (fora do sistema, sem visão interna) l Caixa branca (dentro do sistema) Ø Uso de testes nas dimensões da qualidade: Dimensão Funcionalidade Unidade Integração Interna Sistema Integração Externa Aceitação Usabilidade Confiabilidade Desempenho Suportabilidade Márcio Moreira 5. Testes – slide 6 Processo de Desenvolvimento de Software - RUP

Modelo V de testes Modelagem de Negócio Requisitos Ve Nível 2 Teste de Aceitação

Modelo V de testes Modelagem de Negócio Requisitos Ve Nível 2 Teste de Aceitação Nível 5 Teste de Sistema Teste de Integração Análise Teste Unitário Projeto Implementa ção Nível 6 Márcio Moreira Va o çã Nível 4 Arquitetura lid ica Nível 3 Teste Integrado aç rif ão Nível 1 5. Testes – slide 7 Processo de Desenvolvimento de Software - RUP

Tipos de testes Tamanho Real • Volume esperado Contenção • Volume extra Carga Estresse

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

Objetivos dos testes Ø Localizar e documentar defeitos na qualidade do software Ø Dar

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 Márcio Moreira 5. Testes – slide 9 Processo de Desenvolvimento de Software - RUP

Fluxo de trabalho de testes Márcio Moreira 5. Testes – slide 10 Processo de

Fluxo de trabalho de testes Márcio Moreira 5. Testes – slide 10 Processo de Desenvolvimento de Software - RUP

Objetivos das atividades Ø Definir missão de avaliação: l Identificar o foco apropriado do

Objetivos das atividades Ø Definir missão de avaliação: l 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: l 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: l 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: l 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? ): l Garantir a aceitação do produto através das avaliações dos testes Ø Aprimorar vantagens dos testes: l Manter e aprimorar os recursos de testes Márcio Moreira 5. Testes – slide 11 Processo de Desenvolvimento de Software - RUP

A: Definir missão de avaliação 1 Márcio Moreira 5. Testes – slide 12 Processo

A: Definir missão de avaliação 1 Márcio Moreira 5. Testes – slide 12 Processo de Desenvolvimento de Software - RUP

A: Definir missão de avaliação 2 Márcio Moreira 5. Testes – slide 13 Processo

A: Definir missão de avaliação 2 Márcio Moreira 5. Testes – slide 13 Processo de Desenvolvimento de Software - RUP

A: Validar abordagem do teste 1 Márcio Moreira 5. Testes – slide 14 Processo

A: Validar abordagem do teste 1 Márcio Moreira 5. Testes – slide 14 Processo de Desenvolvimento de Software - RUP

A: Validar abordagem do teste 2 Márcio Moreira 5. Testes – slide 15 Processo

A: Validar abordagem do teste 2 Márcio Moreira 5. Testes – slide 15 Processo de Desenvolvimento de Software - RUP

A: Validar a estabilidade da construção 1 Márcio Moreira 5. Testes – slide 16

A: Validar a estabilidade da construção 1 Márcio Moreira 5. Testes – slide 16 Processo de Desenvolvimento de Software - RUP

A: Validar a estabilidade da construção 2 Márcio Moreira 5. Testes – slide 17

A: Validar a estabilidade da construção 2 Márcio Moreira 5. Testes – slide 17 Processo de Desenvolvimento de Software - RUP

A: Testar e avaliar 1 Márcio Moreira 5. Testes – slide 18 Processo de

A: Testar e avaliar 1 Márcio Moreira 5. Testes – slide 18 Processo de Desenvolvimento de Software - RUP

A: Testar e avaliar 2 Márcio Moreira 5. Testes – slide 19 Processo de

A: Testar e avaliar 2 Márcio Moreira 5. Testes – slide 19 Processo de Desenvolvimento de Software - RUP

A: Testar e avaliar 3 Márcio Moreira 5. Testes – slide 20 Processo de

A: Testar e avaliar 3 Márcio Moreira 5. Testes – slide 20 Processo de Desenvolvimento de Software - RUP

A: Realizar a missão aceitável Márcio Moreira 5. Testes – slide 21 Processo de

A: Realizar a missão aceitável Márcio Moreira 5. Testes – slide 21 Processo de Desenvolvimento de Software - RUP

A: Aprimorar vantagens dos testes 1 Márcio Moreira 5. Testes – slide 22 Processo

A: Aprimorar vantagens dos testes 1 Márcio Moreira 5. Testes – slide 22 Processo de Desenvolvimento de Software - RUP

A: Aprimorar vantagens dos testes 2 Márcio Moreira 5. Testes – slide 23 Processo

A: Aprimorar vantagens dos testes 2 Márcio Moreira 5. Testes – slide 23 Processo de Desenvolvimento de Software - RUP

Essência dos testes Planejamento: • Estratégia, Plano e Idéias de Testes • Arquitetura de

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 Márcio Moreira 5. Testes – slide 24 Processo de Desenvolvimento de Software - RUP

P: Estratégia de testes Ø Seções típicas do documento: l Contexto: v Missão de

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

P: Plano de testes Ø 2. Requisitos de Testes: l Quais tipos de testes

P: Plano de testes Ø 2. Requisitos de Testes: l Quais tipos de testes serão utilizados v. . . v 2. 6. Teste de carga v. . . 2. 7. Teste de estresse 2. 8. Teste de volume Ø 3. Estratégia de testes: l 3. 1. Descrever para cada tipo de teste: objetivo, técnica, critérios e detalhes v. . . v 2. 6. Teste de carga: § Objetivo: § Técnica: real de dados § Critérios: § Detalhes: Verificar o tempo de resposta do sistema para alguns casos de negócio Utilizar Casos de Testes prontos, com variações que simulem o volume Metas de transações e acessos concorrentes atingidos Para medição exata, utilizar máquina dedicada por um tempo dedicado l 3. 2. Ferramentas utilizadas Ø Outros: funções x recursos x responsabilidades, marcos, datas, etc. Márcio Moreira 5. Testes – slide 26 Processo de Desenvolvimento de Software - RUP

P: Idéias de teste Ø Exemplo 1: Item Build Objeto Descrição Esperado 1 1

P: Idéias de teste Ø Exemplo 1: Item Build Objeto Descrição Esperado 1 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 1 Conta 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. 1 Conta 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 Deve salvar apenas o data referente ao tipo de Conta (PF ou PJ) que para Pessoa Fisica, observe que o campo Data de esta sendo informado. Nascimento continuará preenchido com o valor anterior. Verificar o que será salvo. 3 Ø Exemplo 2: Alvo Nome Tipo Descrição Justificativa Filtros R 001 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 R 003 Funcional 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 R 003 Márcio Moreira Executar um relatório com dados que contemplem todos os componentes visuais Usabilidade de apresentação do relatório (ex. : labels, campos, linhas, sombreamentos, gráficos, imagens e etc. . ) 5. Testes – slide 27 Garantir que a apresentação do relatório está de forma adequada Processo de Desenvolvimento de Software - RUP

P: Caso de teste Ø Ø Fase: Ciclo: Nome TC: Passos: GL 1 Catálogo

P: Caso de teste Ø Ø Fase: Ciclo: Nome TC: Passos: GL 1 Catálogo de Produtos Criação de Produtos Simples Step Action Build: ID do TC: Prioridade: Inputs 1 149 Baixa Expected Results 0 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 1 Ir para a Tela de Administração - Produto- Visualização Produtos; n/a produtos exibidos 2 Criar um novo registro; n/a 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; n/a 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 n/a registro salvo 5 Liberar o produto; n/a Produto liberado com sucesso Márcio Moreira 5. Testes – slide 28 Processo de Desenvolvimento de Software - RUP

P: Resultados de testes 1 Test. Set. Name Test. ID Test. Suite. Name Test.

P: Resultados de testes 1 Test. Set. Name Test. ID Test. Suite. Name Test. Status Comments Val End 6422 [Full-Val. End] 19) Validação de campos - Applet Account Address Mvg Applet Val End 6423 [Full-Val. End] 20) Validação de campos - Applet selecionar Passed endereço para correção e ver a origem do endereço Adq Dados 6605 [Full-Adq. Dad. Cli] 05 - tela de cadastro de novas contas de cliente pessoa física e contas de serviço e faturamento Passed Ade Dados 6606 [Full-Adq. Dad. Cli] 04 - campos genéricos que serao utilizados na localização e criação de contas Passed Adq Dados 6608 [Full-Adq. Dad. Cli] 02 - tela de cadastro de novos contatos e na manutenção dos principais dados cadastrais dos Passed mesmos Adq Dados 6609 [Full-Adq. Dad. Cli] 01 - tela de localização e criação de contatos na base do Siebel. Passed Adq Dados 6615 [Full-Adq. Dad. Cli] 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. Adq Dados 6631 [Full-Adq. Dad. Cli] 24) Validação de dados no sistema AUDICON por processo batch - Pessoa Jurídica Canceled não temos como fazer essa validação nessa fase de teste, pois não a integração apenas a sua simulação. Val Cred 6185 [Full-Valid. Credit] 02) Validação de Crédito Prévia (FA 1) - validação Botao Not Completed Val Cred 6186 [Full-Valid. Credit] 03) Validação de Crédito Prévia (FA 2) - Falha na conexão com SOA Passed Márcio Moreira 5. Testes – slide 29 Passed Teste executado com sucesso. Testes efetuados, OK. . Processo de Desenvolvimento de Software - RUP

P: Resultados de testes 2 Build. Name Test. Set. Name Passed Failed Not Completed

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

P: Avaliação dos testes 1 Resultado Estratégia X % de Sucesso 100% 90% 80%

P: Avaliação dos testes 1 Resultado Estratégia X % de Sucesso 100% 90% 80% 70% 60% Densidades 180% 160% 140% 120% 100% 50% 80% 40% % Exec CT % Suc CT Legenda: Exec = Execução CT = Caso de Teste Márcio Moreira % Exec PT % Suc PT Suc = Sucesso PT = Passos de CT 5. Testes – slide 31 Dens. Falhas 07/01 24/12 10/12 26/11 12/11 29/10 15/10 17/09 07/01 24/12 10/12 26/11 0% 12/11 0% 29/10 20% 15/10 10% 01/10 40% 17/09 20% 01/10 60% 30% Dens. Bugs Falhas / C. T. Executado Bugs / C. T. Executado Processo de Desenvolvimento de Software - RUP

P: Avaliação dos testes 2 Severidade final Severidade Média 100% 127, 10% Bloqueador 90%

P: Avaliação dos testes 2 Severidade final Severidade Média 100% 127, 10% Bloqueador 90% 80% 697, 53% 60% Severo 375, 29% 70% 50% 30% 20% 10% Bloqueador Márcio Moreira Severo Moderado 24/12 10/12 26/11 12/11 29/10 15/10 01/10 17/09 0% 07/01 Severidade 40% Cosmético Moderado 110, 8% Cosmético 5. Testes – slide 32 Processo de Desenvolvimento de Software - RUP

P: Avaliação dos testes 3 100% 90% 100% em 7/7/2010 80% 70% 60% 50%

P: Avaliação dos testes 3 100% 90% 100% em 7/7/2010 80% 70% 60% 50% 40% 30% 20% 10% % Execução Márcio Moreira % Sucesso 5. Testes – slide 33 %Suc. Linear 14/01 07/01 31/12 24/12 17/12 10/12 03/12 26/11 19/11 12/11 05/11 29/10 22/10 15/10 08/10 01/10 24/09 17/09 0% Necessário Processo de Desenvolvimento de Software - RUP

Exercício 3: Contexto Ø Considerando o mesmo projeto dos exercícios 1 e 2, e

Exercício 3: Contexto Ø Considerando o mesmo projeto dos exercícios 1 e 2, e além disto: l A empresa de consultoria tem fábricas de software em: v 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 v 2 cidades na Índia: que farão a maior parte do desenvolvimento § A língua oficial da consultoria na Índia é o inglês l A empresa de consultoria é parceira da Oracle e participou das validações das customizações propostas feita com a Oracle l A empresa de consultoria utilizará uma unidade deles especializada em testes, que fica em Brasília l As responsabilidades de testes ficaram combinadas da seguinte forma: v Testes Unitários e Testes de Integração (internos): Responsabilidade da consultoria v Testes de Sistema e Testes Integrados (externo, ou seja, com outros sistemas): § § § A consultoria: A empresa: A consultoria: Desenvolve os Casos de Teste Valida os Casos de Teste Executa os Casos de Teste e fornece evidências da execução Verifica as evidências e registra as rejeições Corrige as rejeições e fornece novamente para a empresa v Teste de Aceitação: Responsabilidade integral da empresa Márcio Moreira 5. Testes – slide 34 Processo de Desenvolvimento de Software - RUP

Exercício 3: Questões 1. Que Atividades e Tarefas de Implementação & Testes do RUP

Exercício 3: Questões 1. Que Atividades e Tarefas de Implementação & Testes do RUP vocês recomendam que sejam utilizadas neste caso? 2. Justifique porque vocês incluíram ou excluíram cada Atividade e Tarefa. 3. Vocês recomendam alguma tarefa adicional para as Atividades selecionadas? Quais e por que? 4. 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: a. b. Márcio Moreira Ter maior assertividade na entrega da Construção? Ter mais confiança no software nos Testes de Sistema? 5. Testes – slide 35 Processo de Desenvolvimento de Software - RUP

Referências Sigla Referência BEI 90 BEIZER, Boris. Software testing techniques. Scottdale: Coriolis Group, 1990,

Referências Sigla Referência BEI 90 BEIZER, Boris. Software testing techniques. Scottdale: Coriolis Group, 1990, 2 ed. JAC 98 Ivar Jacobson, Grady Booch, and James Rumbaugh. The Unified Software Development Process. 1998. Addison Wesley Longman. KAN 01 Cem Kaner, James Bach e Bret Pettichord 2001. Lessons Learned in Software Testing. John Wiley & Sons, Inc. KRO 03 Per Kroll e Philippe Kruchten 2003. The Rational Unified Process Made Easy, A Practitioners Guide to the RUP. Addison Wesley Longman. KRU 98 P. Kruchten; The Rational Unified Process: An Introduction, Object Technology Series, Addison-Wesley, 1998. MAR 05 Márcio Moreira. Resumo do livro Unified Process. Márcio. Uberlândia (MG). 2005. MAR 06 Márcio Moreira. Engenharia de Software - RUP. Uniube - Universidade de Uberaba - Uberlândia (MG). 2006. MEY 79 MYERS, Glenford J. The art of software testing. New York: John Wiley & Sons, 1979. PRE 95 PRESSMAN, R. S. Engenharia de software. São Paulo: Makron Books. 1995. RUP 08 IBM Rational. RUP – Rational Unified Process – 7. 5 – For Large and Small Projects. 2008. IBM Rational. SUM 07 Sommerville, Ian. Engenharia de Software. 8ª Ed. Pearson / Prentice Hall. 2007. Márcio Moreira 5. Testes – slide 36 Processo de Desenvolvimento de Software - RUP