Baixe o app para aproveitar ainda mais
Prévia do material em texto
Unidade III – Testes de Validação 14 – Analisando cada Fase Unidade III Avaliação de Software Prof. Ulisses Sperle Graça Abr/2013 2 Em determinado momento do projeto, todos os levantamentos e decisões realizadas são materializados em produtos tecnológicos que foram construídos para atender às especificações definidas na etapa inicial do processo. Os testes de validação têm por objetivo avaliar a qualidade desse produto nas mais variadas dimensões possíveis. Ao contrário dos testes de verificação, que atuam em artefatos e procedimentos de trabalho, os testes de validação são aplicados diretamente no software que está sendo construído, tendo a árdua missão de identificar erros que foram introduzidos na solução no decorrer do projeto. Fazendo uma Reflexão 3 Estágios dos Testes de Software Teste de Unidade Teste de Aceitação Teste de Sistema Teste de Baixo Nível Teste de Alto Nível Estratégia Caixa-Branca; Testam partes do software; Requer conhecimento da estrutura interna; Executado pelo desenvolvedor ou profissional de teste. Estratégia de Caixa-Preta; Os testes são aplicados no software como um todo; Não requer conhecimento da estrutura interna do software; Requer ambiente muito semelhante ao da produção; Deve ser executado por um grupo de teste independente. Estrutura Interna; Funcionalidade; Usabilidade Segurança; Funcionais; Não Funcionais; o Performance; o Instalação; o Recuperação; o Carga; Funcional; Usabilidade; Segurança; Estratégia de Caixa-Preta; Os testes são aplicados no software como um todo; Não requer conhecimento da estrutura interna do software; Requer ambiente muito semelhante ao da produção; Deve ser executado pelos usuários finais. Interfaces; Dependências entre Componentes; Estratégia de Caixa-Branca; Testam integrações entre partes do software; Requer conhecimento da arquitetura interna do software; Executado pelo desenvolvedor ou profissional de teste. Teste de Integração Fase da Validação Categorias de Testes Aplicada Características da Fase de Validação 4 Os testes de baixo nível são caracterizados por exigir dos profissionais de testes um profundo conhecimento da estrutura interna do produto. Podem ser realizados pelo próprio desenvolvedor ou por um profissional dedicado a esta finalidade. Esta decisão depende da maturidade da organização, criticidade da aplicação, disponibilidade de recursos e das restrições orçamentárias do projeto. Estágios dos Testes de Software 5 Os testes de alto nível são caracterizados por não requererem conhecimento da estrutura interna do produto, possibilitando testes com maior “nível de abstração”. Estes testes são executados por uma equipe independente, sendo guiados pelas especificações de negócio e pela lista de requisitos do software. Estágios dos Testes de Software 6 É a primeira etapa do processo de validação que tem por objetivo testar os componentes individuais de uma aplicação. São orientados à estrutura interna, o que os caracteriza por testes de caixa branca. Mesmo um componente com uma estrutura interna validada adequadamente por um conjunto completo de testes caixa branca pode não estar contemplando adequadamente todos os requisitos, daí a necessidade de testes que os validem (caixa preta). Validação da Unidade Traduzir os modelos em estruturas internas dos códigos. Traduzir os requisitos de negócios, regras e comportamentos em código-fonte. Unidade Especificada ou Modificada Garantir máxima cobertura do código-fonte. Garantir o processamento de diferentes caminhos. Garantir que determinados requisitos estejam implementados. Validação da Unidade 5 7 Seguem alguns exemplos de pontos de validação que poderiam ser considerados críticos para avaliarmos a qualidade dos componentes: Testes que empregam métodos caixa branca: Exercitar todas as linhas de código; Exercitar todos os desvios condicionais; Exercitar todos os fluxos alternativos. Testes que empregam métodos Caixa Preta: Validar todos os requisitos funcionais; Validar todos os requisitos de usabilidade; Validar todos os requisitos de sistema. Validação da Unidade 8 Têm por objetivo examinar detalhadamente segmentos do código-fonte e simular o processamento dos componentes de modo a exercitar a estrutura interna. A grande desvantagem desta configuração de teste é o fato de exigir um profissional de grande experiência na linguagem de desenvolvimento usada e um alto grau de compreensão de toda a arquitetura interna do componente, bem como padrões utilizados, modelos de dados, ferramentas de desenvolvimento, o que exigiria do profissional total envolvimento no processo de criação do software. Validação de Unidades – Caixa Branca 9 Por esses motivos, é natural que essas atividades sejam transferidas para o próprio desenvolvedor, pois ele possui todas estas características. O grande problema é o conflito de interesses, pois ele está sempre sendo pressionado a construir softwares com rapidez, o que significa que testar é uma atividade secundária. Validação de Unidades – Caixa Branca 10 É aconselhável a utilização de um ou mais profissionais para integrar o processo de desenvolvimento, pois eliminaria os riscos de testes superficiais. A percepção de que isto seriam custos adicionais não se sustenta, pois o modelo que estamos trabalhando há anos se baseia na premissa que essas correções são características naturais e nada podemos fazer, pois nenhum levantamento de custos com correção é efetuado. Devemos lembrar que estes erros encarecem o software e reduzem a produtividade. Validação de Unidades – Caixa Branca 11 As validações serão baseadas na arquitetura da aplicação, sendo possível identificar quais requisitos são mais adequados aplicar durante os testes de cada unidade. Projetos orientados a objetos normalmente são separados em pacotes de especialização (packages) que facilitam a organização e representam melhor a arquitetura aplicada. Cada pacote existente agrupa um conjunto de componentes que têm as mesmas características e finalidades, possibilitando identificar um padrão único de abordagem dos testes: Validação de Unidades – Caixa Preta 12 User Packages: para pacotes de componentes que lidam especificamente com a interface do usuário – baseados em requisitos de usabilidade. Business Packages: para pacotes de componentes que lidam especificamente com as transações de negócios da aplicação – baseados nos requisitos funcionais (cenários básico, alternativos e de exceção). Data Packages: para pacotes de componentes que lidam especificamente com as transações de dados (tabelas, stored- procedures, transações de backup e recuperação de dados) – baseados em requisitos de armazenamento e recuperação. Validação de Unidades – Caixa Preta 13 Utilities-Packages: para pacotes de componentes utilitários que apoiam e reduzem os esforços de desenvolvimento de outros pacotes (controle de arquivos físicos, bibliotecas de criptografia, comunicação com sistemas office-automation) – baseados em requisitos de sistemas coletados durante o desenrolar do projeto. Esses requisitos são gerenciados corporativamente pela organização para que todos os outros projetos possam se beneficiar desses componentes utilitários. Validação de Unidades – Caixa Preta 14 As unidades são testadas de forma totalmente isoladas, eliminando a existência entre as outras unidades.Isto possibilita que os testes ocorram em qualquer sequência ou momento do projeto, uma vez que os componentes que são acionados por esta unidade não precisam estar prontos ou funcionando corretamente. Por outro lado, exige grande esforço de criação de simuladores (que não são simples de projetar e implementar) para cada componente que é acionado. Validação de Unidades – Abordagem Isolada 15 Validação de Unidades – Abordagem Isolada 16 Permitem uma condição perfeita para um ambiente de testes: Eliminam dependências já que não é necessária a existência física de outros componentes para o teste; Não existe sequencia de execução dos testes, permitindo a realização de testes paralelos de unidades (não preciso esperar a unidade xpto ficar pronta para testar tal componente). Como as chamadas realizadas a outros componentes são feitas de forma simulada, existe um risco real de que um determinado componente tenha modificado sua chamada (incluído um novo parâmetro), deixando incompatível a chamada para esse novo componente. Este teste não identificaria este problema. Validação de Unidades – Abordagem Isolada 17 Os testes unitários estão intimamente ligados à forma como eé conduzido o processo de desenvolvimento. Nos projetos estruturados, atendidos tipicamente por processos de análise estruturada ou análise essencial, as unidades são produzidas através de refinamentos sucessivos do projeto, ou seja, quando estamos criando uma unidade de software, os níveis superiores estão todos construídos e validados, enquanto que os níveis inferiores ainda não foram construídos. Dessa forma, quando uma determinada unidade será validada, todas as demais unidades que acionam seus serviços e que estão localizadas em níveis hierárquicos superiores estarão disponíveis para integrar os testes unitários como substituto natural dos controladores de teste. Validação de Unidades – Abordagem Top-down 18 Validação de Unidades – Abordagem Top-down Unidade E Simulador H Simulador I Simulador J Arquitetura Completa do Aplicativo Top-down Arquitetura do Teste da Unidade E Unidade A Unidade D Unidade E Unidade H Unidade G Unidade F Unidade I Unidade J Unidade B Unidade C Unidade B Unidade C 19 Já as unidades inferiores não terão sido criadas, necessitando da construção de simuladores para responder a eventuais chamadas acionadas pela unidade a ser testada. A vantagem dessa abordagem é o direcionamento explícito dos testes com relação aos requisitos de negócio. Como é natural que as unidades de maior nível suportem as telas de navegação do sistema, os testes poderão ser direcionados facilmente por estas estruturas, facilitando a análise de requisitos que não estão sendo atendidos. A desvantagem é o fato de ela estar fortemente apoiada na construção de simuladores, o que aumenta significativamente os esforços de construção de um ambiente de testes, e que aumenta ainda mais quando avançamos e atingimos níveis mais baixos de estruturação. Validação de Unidades – Abordagem Top-down 20 Nessa abordagem, os testes unitários acompanham a estratégia de desenvolvimento baseados em projetos orientados a objetos, onde não existe uma hierarquia de unidades . Os problemas são fragmentados em um conjunto de pequenas unidades especializadas de software que atenderão isoladamente a uma pequena fração do processo, que poderão ser empregadas em outros processos serem modelados de forma a maximizar a reutilização do código. Validação de Unidades – Abordagem Bottom-up 21 Unidade E Unidade H Unidade I Unidade J Arquitetura Completa do Aplicativo Bottom-Up Arquitetura do Teste da Unidade E Unidade A Unidade D Unidade E Unidade H Unidade G Unidade F Unidade I Unidade J Unidade B Unidade C Controlador Testes-E Validação de Unidades – Abordagem Bottom-up 22 Como característica do projetos orientados a objetos, uma única funcionalidade pode demandar a criação de um grande conjunto de unidades – chamadas classe. À medida que cada unidade é criada para atender a uma pequena fração da funcionalidade, esta deve ser testada isoladamente, avaliando se suas operações especializadas foram adequadamente implementadas. Após a validação isolada de cada unidade, torna-se necessário testar todas em conjunto, avaliando se a funcionalidade foi integralmente atendida. As unidades mais básicas serão codificadas antes das classes que utilizarão os serviços que serão disponibilizados, de forma que os testes exigirão controladores para simular as chamadas às rotinas especializadas das classes. Validação de Unidades – Abordagem Bottom-up 23 A vantagem dessa abordagem é a facilidade de realizar testes nas unidades mais básicas do projeto, o que potencializa os testes de classes. Os testes podem atingir a cobertura total da estrutura interna, possibilitando a simulação de todos os fluxos alternativos de processamento, além de exercitar os diversos desvios de condições existentes. A desvantagem é a crescente complexidade que os testes irão ganhando à medida que progredimos e subimos os níveis de interação com outras unidades, reduzindo o nível de cobertura estrutural alcançado pelos testes. Validação de Unidades – Abordagem Bottom-up 24 São uma natural continuação dos testes unitários, e podem ser entendidos como o segundo estágio do processo de validação. À medida que as unidades vão sendo construídas ou modificadas, estas devem manter a compatibilidade com outros componentes existentes. Esses testes são orientados pela própria arquitetura do projeto tecnológico, na qual são colocados diversos componentes para que sejam processados e tenham suas interfaces exercitadas e validadas. Validação da Integração Traduzir o modelo de arquitetura em componentes tecnológicos. Traduzir os requisitos de negócios, regras e comportamentos em código-fonte. Unidade Especificada ou Modificada Garantir a perfeita interface entre os diversos componentes existentes na arquitetura tecnológica Garantir perfeita colaboração entre os componentes. Garantir que determinados requisitos estejam implementados. Validação da Integração 6 25 Tem o objetivo de validar a compatibilidade entre componentes da mesma arquitetura, que é quebrada sempre que uma alteração ou exclusão de uma rotina ou propriedade pública de um componente. Quando isto ocorre, todos os outros componentes que empregam estas rotinas ou propriedades ficam automaticamente incompatí- veis com o componente modificado, gerando erros. Abaixo estão relatados alguns pontos de validação críticos: Exercitar todas as dependências entre componentes. Exercitar todas as interfaces do componente. Exercitar todas os parâmetros de interface do componente. Exercitar todas as propriedades públicas do componente. Validação da Integração 26 Provavelmente é o mais usado, onde os componentes são testados individualmente (teste de unidade) e depois integrados todos de uma única vez. É o que requer menos esforço, mas por outro lado é o que traz menos benefícios, já que diagnosticar um erro é bastante complexo, pois é difícil identificar qual dos componentes está produzindo o efeito. Resume-se na aplicação de testes de integração após a construção de todas as unidades, ou seja, de todas as unidades ao mesmo tempo, não havendo ciclos parciais de integração. Validação da Integração – Abordagem Big-bang 27 Seguem a filosofia dedesenvolvimento estrutural comumente conhecido como desenvolvimento top-down. As unidades de maior nível hierárquico são criadas inicialmente, sofrendo um processo de refinamento e decomposição sucessivos, até que seja alcançado o menor nível estrutural do projeto e todas as unidades tenham sido criadas. À medida que as unidades são construídas e alteradas, estes testes avaliam se as interfaces com outras unidades continuam compatíveis. Pode ser realizada em largura ou em profundidade. Quando em profundidade, simuladores serão substituídos ao longo do projeto. Quando em largura, os simuladores serão substituídos verticalmente Validação da Integração – Abordagem Top-down 28 Validação da Integração – Abordagem Top-down No exemplo acima temos: - através de profundidade: M1, M2, M5, M8, M6, M3, M7, M4. - através de largura: M1, M2, M3, M4, M5, M6, M7, M8. M 1 M 3M 2 M 4 M 7M 6M 5 M 8 29 Os componentes de níveis mais básicos da arquitetura do aplicativo são conjuntamente testados por controladores construídos para simular as interações dinâmicas e suas interfaces. À medida que evoluímos na integração, componentes reais substituem os controladores anteriores e novos controladores de testes são criados para simular as interfaces de um maior nível da arquitetura. Esses níveis de integração seguem até que não existam mais níveis a serem alcançados. Em cada nível de integração, existe um controlador criado exclusivamente para realizar os testes de interfaces entre os componentes do software. Validação da Integração – Abordagem Bottom-up 30 Validação da Integração – Abordagem Bottom-up Integração Nível 3 Integração Nível 2 Integração Nível 1 S T S T S T S T S T S T S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S T S T S S S S S S S S S S S S S S S S S T T S Componentes de Testware Componentes de Software 31 Representa uma combinação das abordagens Bottom-up e Top- down, visando à utilização do que existe de melhor nelas: Validação da Integração – Abordagem Mista Bottom-up Top-down Principais Características • Permite que as unidades básicas (e talvez mais críticas) sejam testadas mais cedo. • As unidades podem ser integradas em vários ciclos, de acordo com a necessidade. • Maior ênfase na funcionalidade e no desempenho dos módulos. • O módulo principal é testado primeiro. • Apenas uma unidade é integrada a cada ciclo • Maior ênfase nos protótipos visuais. Vantagens • Não há necessidade de simuladores. • Maior facilidade de adaptar os testes aos recursos humanos disponíveis para executá-los. • Maior cobertura das unidades mais básicas e que atendem a aspectos críticos de processamento. • Erros na arquitetura são detectados mais cedo • Não há necessidades de controladores. • Com o módulo principal e alguns módulos se obtém um protótipo nas fases iniciais. • Erros de interfaces são detectados mais cedo. • Facilita a orientação dos testes de funcionalidades da aplicação. 32 Representa uma combinação das abordagens Bottom-up e Top- down, visando à utilização do que existe de melhor nelas: (cont.) Validação da Integração – Abordagem Mista Bottom-up Top-down Desvantagens • Necessidade de controladores. • Muitas unidades devem ser integradas antes de se conseguir operacionalizar uma funcionalidade. • Erros nas interfaces visuais são detectados mais tarde. • Necessidade de simuladores. • Erros na arquitetura da solução são detectados tardiamente • Como s fases iniciais são muito prolongadas, torna-se difícil sincronizar o ritmo de desenvolvimento dos testes. Comentários • A produção do código avança mais rapidamente do que através da abordagem Top-down. • em geral esta abordagem é mais intuitiva. • Na prática, é muito difícil utilizar uma abordagem puramente Top- down. 33 É um estágio mal compreendido e de difícil operacionalização. Validam a solução como um todo e a maior parte dos erros de funcionalidade já deve ter sido detectadas nos testes anteriores. Como estes testes contam com uma infraestrutura mais complexa de hardware, estes testes deveriam concentrar-se mais nos aspectos de performance, segurança, disponibilidade, instalação, recuperação e etc. Validação do Sistema Atender os requisitos não funcionais da solução tecnológica. Modelar uma arquitetura que atenda a todos os requisitos da solução. Unidade Especificada ou Modificada Garantir os requisitos não funcionais. validar a infraestrutura a ser aplicada na solução. validar interfaces com sistemas e dispositivos físicos. Validação do Sistema 7 34 Teremos ainda os testes de integração com sistemas externos (sem simulação), testes com dispositivos físicos (hardware), utilitários externos e operacionalização do ambiente tecnológico. O planejamento destes testes não é tarefa fácil, pois exige o perfeito entendimento dos requisitos não funcionais do software, que muitas vezes não são claramente descritos ou representam cenários extremamente complexos. Ex.: Processar um extrato em, no máximo , 30 segundos, existindo uma concorrência de acesso de 500 usuários simultâneos e com volume de dados da ordem de 2 milhões de correntistas e 350 milhões de movimentações bancárias. Validação do Sistema 35 Nessa fase, a falta de um método único de como planejar e operacionalizar os testes de requisitos não funcionais (testar uma carga de 100.000 registros ou validar o procedimento de recuperação de um backup) exige grande dose de criatividade por parte da equipe de testes. Uma das formas encontradas para organizar os testes é relacioná-los em categorias, com objetivos bem definidos e distintos. Esta organização facilitará o planejamento e a execução dos testes, uma vez que os cenários que possuem características e comportamentos semelhantes estarão agrupados em uma mesma categoria. Revisar 12 – categorias de teste de Software – aula 5 slide 16 Validação do Sistema 36 Se nosso objetivo é validar os requisitos funcionais de toda uma aplicação, torna-se fundamental a execução de um conjunto de cenários de negócios que exigiria a interação de vários sistemas simultaneamente, o que inviabilizaria qualquer tentativa de realizar estes testes de forma integrada. Esta abordagem facilitaria a administração dos diversos cenários que estaremos simulando, evitando as dependências existentes. Cada sistema seria substituído por um simulador, que produziria as respostas necessárias para alimentar a execução do sistema que estamos testando, possibilitando a criação dos mais variados cenários, minimizando os esforços de planejamento e execução dos testes. Estes simuladores poderão ser aplicados nos testes unitário e de integração que também enfrentarão as mesmas dificuldades. Validação do Sistema – Abordagem isolada 37 Validação do Sistema – Abordagem Isolada Sistema Alvo Sistema D Sistema E << Batch >> << Batch >> << On-Line >> << On-Line >> Sistema F << Batch >> << Batch >> << On-Line >> << On-Line >> << Batch >> <Simulador> Sistema A <Simulador> Sistema B <Simulador> Sistema C Simuladores nos testes de sistema deixam o ambiente mais gerenciável 38 Cada sistema que incluímosno contexto traz uma gama de dificuldades adicionais: lidar com um número maior de profissionais, disponibilizar uma infraestrutura, instalar e parametrizar o sistema, além de esbarrarmos com as dependências do sistema com outros aplicativos, o que torna esta atividade complexa e inviável. Em algumas situações, necessitamos validar condições que necessitam da interação real com as aplicações para que as medições sejam obtidas nas condições mais próximas do ambiente em produção, onde os simuladores poderiam “esconder” gargalos de processamento. Neste caso uma abordagem integrada forneceria um cenário mais favorável para aplicar os testes. É fundamental avaliar quando é necessário este testes definir quais integrações são relevantes (nitidamente as operações on-line). Validação do Sistema – Abordagem Integrada 39 Validação do Sistema – Abordagem Isolada Sistema Alvo Sistema D Sistema E << Batch >> << Batch >> << On-Line >> << On-Line >> Sistema F << Batch >> << Batch >> << On-Line >> << On-Line >> << Batch >> Testes integrados identificam gargalos de processamento Sistema A Sistema B Sistema C 40 É o último processo formal de detecção de erros no sistema, antes da sua disponibilização no ambiente de produção. O software é disponibilizado para os usuários com o objetivo de estes validarem todas as funcionalidades requisitadas no início do projeto. Os usuários terão oportunidade de interagir com um sistema completo e exaustivamente testado pela equipe de testes. Validação do Aceite Disponibiliza a solução para os usuários validarem o software e suas funcionalidades. Estratégia de implantação gradativa da solução Disponibiliza a Solução Última etapa para detectar erros na solução. Permite aos usuários validarem o software (Alpha-teste). Permite realizar teste no ambiente do cliente (Beta-teste) Validação do Aceite 7 41 Se ao chegar nesta etapa e a solução ainda apresentar muitas falhas, é sinal de que os processos de detecção de erros não estão sendo efetivos, indicando falhas nos processos anteriores. Assim como nos testes de sistema, os procedimentos de aceite deverão ser realizados a cada ciclo de implementação da solução, permitindo correções antecipadas de determinados pontos que não foram adequadamente atendidos pelo software. Como esta é as última oportunidade efetiva de detectar falhas, podemos empregar o aceite como uma estratégia para reduzir riscos de uma implantação maciça, na qual um erro vital não detectado pode comprometer a imagem da solução toda. Dessa forma, podemos dividir o aceite em três momentos: o Aceite formal, Alpha-teste e o Beta-teste. Validação do Aceite 42 Validação do Aceite Estágios do processo de aceite de um software Aceite Formal Implantação Total Todos os clientes recebem o software devidamente testado. Implantação BETA Clientes selecionados recebem o software para operar em seu ambiente. Clientes planejam e realizam os testes do software. Aceite Formal ALPHA Teste BETA Teste Todos Clientes Clientes são convidados a operar o software no fornecedor. Implantação ALPHA Aceite da Solução Distribuição 43 O processo de aceite torna-se uma continuação natural do testes de sistema. Aproveitando-se toda a infraestrutura existente no ambiente de homologação (inclusive simuladores), o aceite formal segue rigoroso planejamento das atividades de testes, cabendo aos próprios usuários determinarem o que deverá ser testado e validar se os requisitos foram adequadamente atendidos. Na maior parte das vezes,restringe-se apenas às funcionalidade de negócio, deixando outros requisitos de fora. É muito empregado em projetos que são desenvolvidos para atender a um grupo de empresas, possibilitando a criação de um comitê que atestará a aderência do software às necessidades do grupo. Validação do Aceite – Aceite Formal 44 Os clientes são convidados a operar o software dentro de um ambiente simulado, localizado dentro da empresa criadora do software, porém fisicamente separada do ambiente de desenvolvimento. Os usuários poderão interagir diretamente com a aplicação, simulando operações e transações de todo os tipos. Cabe ao profissionais que estão gerenciando o processo de aceite garantir que todos os usuários convidados estão exercitando todos os pontos mais críticos da aplicação. Sua principal característica é a ausência de um formalismo no processo de validação, pois o objetivo é capturar a naturalidade dos próprios usuários e dar a eles a possibilidade de realizar seus próprios testes. Validação do Aceite – Alpha-teste 45 Os clientes são convidados a operar o software utilizando suas próprias instalações para que possa ser submetido às mesmas situações do dia-a-dia. Não se trata de uma implantação definitiva, mas sim uma implantação em paralelo e pode ocorrer até que o usuário sinta- se seguro em realizar mudança definitiva. Durante a sua execução, o cliente contará com o acompanhamento direto da empresa fornecedora para que corrija qualquer eventual falha. Os clientes que participarão desse estágio deverão ser aqueles que executam toda ou grande parte das funcionalidades. Pode ser planejado em vários ciclos que englobam um número cada vez maior de usuários até que aceite seja efetivo e o processo de implantação do software seja iniciado. Validação do Aceite – Beta-teste
Compartilhar