V 1.0 Projeto DPES-FNDE 21/03/2007

Transcrição

1 V 1.0 Projeto DPES-FNDE 21/03/2007

2 Índice 1 HISTÓRICO DE ATUALIZAÇÃO APRESENTAÇÃO OBJETIVOS DO TESTE PRINCÍPIOS DO TESTE TESTABILIDADE MÉTODO DE TESTE TESTE CAIXA-PRETA FERRAMENTAS DE AUTOMATIZAÇÃO DE TESTES FUNÇÃO ESPECIALIZAÇÃO CATÁLOGO DE IDÉIAS DE TESTE CATÁLOGOS ADEQUADOS CRIAÇÃO E MANUTENÇÃO DE SEUS PRÓPRIOS CATÁLOGOS LISTA DE IDÉIAS DE TESTE O QUE SÃO IDÉIAS DE TESTE? MEDIÇÕES MEDIDAS DE COBERTURA COBERTURA DE TESTE BASEADA EM REQUISITOS PLANEJAR TESTES PLANO DE TESTE Finalidade REQUISITOS DE TESTE Teste de integridade de dados e BD Teste funcional Teste do ciclo de negócio Teste de Interface de Usuário Teste de Carga Teste de Stress Teste de Volume Teste de Segurança e Controle de Acesso Teste de Falha e Recuperação Teste de Configuração Teste de Instalação Teste de Contenção Teste de Estrutura PROJETAR TESTE CASOS DE TESTE Cenário de Teste Fluxos (Básico e Alternativos) Sugestões de Casos de Teste Massa de Teste PREPARAR AMBIENTE DE TESTE FINALIDADE OCORRÊNCIAS IMPLEMENTAR TESTES PROCEDIMENTO DE TESTE Finalidade

3 Condições EXECUTAR TESTES FINALIDADE TIPOS DE EXECUÇÃO RECUPERAR A PARTIR DE TESTES INTERROMPIDOS RESTAURAR O AMBIENTE DE TESTE AO ESTADO CONHECIDO REGISTRO DE ERROS DA RELEASE FINALIDADE OCORRÊNCIA AVALIAÇÃO DOS RESULTADOS DOS TESTES FINALIDADE DEFINIÇÃO DO CICLO DE TESTE PROCEDIMENTOS CONCLUSÃO ANEXO I - SUGESTÕES PARA FERRAMENTAS DE TESTE

4 1 Histórico de Atualização Data Atividade Autor Versão 12/03/2007 Criação do documento Pedro Garcia (Borland) /03/2007 Revisão do documento Pedro Garcia (Borland) /06/2007 Revisão do documento Pedro Garcia (Borland) 1.1 4

5 2 Apresentação A atividade de teste de software é um elemento crítico da garantia da qualidade de software e representa a última revisão de especificação, projeto e codificação. Deve-se testar o mais cedo possível e tantas vezes quanto necessário. A cultura do teste cria um ambiente favorável para detecção de erros e contribui para a sua rápida identificação pelos profissionais de teste. O desenvolvimento de sistemas de software envolve uma série de atividades de produção em que as oportunidades para injetar a falibilidade humana são enormes. Erros podem vir a ocorrer até no início do processo, onde os objetivos podem ser errônea ou imperfeitamente especificados, bem como em estágios posteriores de projeto e desenvolvimento por causa da inabilidade humana de realizar e de se comunicar com perfeição, o desenvolvimento é acompanhado por uma atividade de garantia de qualidade. 3 Objetivos do Teste Num excelente livro sobre teste de software, Glen Myers enumera algumas regras que podem servir bem como objetivos de teste: Teste é um processo de execução de um programa ou sistema com a finalidade de encontrar erros, falhas; Um bom caso de teste é aquele que tem alta probabilidade de encontrar um erro ainda não descoberto; Um teste bem-sucedido é aquele que descobre um erro ainda não descoberto. Se o teste for conduzido de maneira bem-sucedida, ele descobrirá inconsistências no software. Como benefício secundário, o teste demonstra que as funções do software parecem estar funcionando de acordo com o especificado e que os requisitos de comportamento e desempenho parecem estar satisfeitos. 4 Princípios do Teste Antes de aplicar métodos para projetar casos de teste efetivos, é necessário entender os princípios básicos que guiam o teste de software. Nos tópicos abaixo estão os principais: Todos os testes devem ser relacionados aos requisitos do Cliente: o objetivo do teste de software é descobrir erros. Segue-se que os defeitos mais indesejáveis são aqueles que levam o programa a deixar de satisfazer os requisitos do Cliente; Os testes devem ser planejados muito antes do início de sua execução: o planejamento de teste pode começar tão logo a especificação de requisitos seja completada. A definição detalhada dos casos de teste pode começar tão logo o modelo de projeto tenha sido consolidado. Assim sendo, todos os testes podem ser planejados e projetados antes que código tenha sido gerado; 5

6 O princípio de Pareto se aplica ao teste de software: colocado simplesmente, o princípio de Pareto implica que 80% de todos os erros descobertos durante o teste serão provavelmente relacionados a 20% de todos os componentes do programa. O problema, sem dúvida, é isolar os componentes suspeitos e testá-los rigorosamente; O teste deve começar no varejo e progredir até o teste no atacado : os primeiros testes planejados e executados geralmente concentram-se nos componentes individuais. À medida que o teste progride, o foco se desloca numa tentativa de encontrar erros em conjuntos integrados de componentes e finalmente em todo o sistema; Teste completo não é possível: a quantidade de permutações de caminhos, mesmo para um programa de tamanho moderado, é excepcionalmente grande. Por essa razão, é impossível executar todas as combinações de caminhos durante o teste. É possível, no entanto, cobrir adequadamente a lógica do programa e garantir que todas as condições no projeto, em nível de componente, tenham sido exercitadas; Para ser mais efetivo, o teste deveria ser conduzido por terceiros : o desenvolvedor que escreveu o programa não é a pessoa mais adequada para conduzir os testes do software. 4.1 Testabilidade A testabilidade de software é simplesmente a facilidade com que um programa de computador pode ser testado a fim de garantir que ele execute sua função pretendida. Como o teste é profundamente difícil, vale a pena saber o que pode ser feito para facilitá-lo. Algumas vezes, a testabilidade é usada para dizer quão adequadamente um conjunto particular de testes vai cobrir o produto. É percebida pela menor ocorrência de erros e maior confiabilidade. Abaixo segue um conjunto de características que levam a um software testável : Operabilidade : Quanto melhor funciona, mais eficientemente pode ser testado. O sistema tem poucos defeitos; Nenhum defeito bloqueia a execução dos testes; O produto evolui em estágios funcionais, isto é permite desenvolvimento e testes simultâneos. Observabilidade : O que você vê é o que você testa Saída distinta é gerada para cada entrada; Estados e variáveis do sistema são visíveis ou consultáveis durante a execução; Os estados e variáveis anteriores do sistema são visíveis ou consultáveis, por exemplo, registro de transações; Todos os fatores que afetam a saída são visíveis; Saída incorreta é facilmente identificada; Erros internos são automaticamente detectados por meio de mecanismos de autoteste ; Erros internos são automaticamente relatados; O código-fonte é acessível. 6

7 Controlabilidade : Quanto mais você pode controlar o software, mais o teste pode ser automatizado e otimizado. Todas as saídas possíveis podem ser geradas por alguma combinação de entradas; Todo código é executável através de alguma combinação de entradas; Estados e variáveis do software e do hardware podem ser controlados diretamente pelo engenheiro de teste ; Formatos de entrada e saída são consistentes e estruturados; Testes podem ser especificados, automatizados e reproduzidos convenientemente. Decomponibilidade : Controlando o escopo do teste, podemos isolar problemas mais rapidamente e realizar novos testes mais racionalmente. O sistema de software é construído a partir de módulos independentes; Módulos de software podem ser testados independentemente. Simplicidade : Quanto menos há a testar, mais rapidamente podemos testá-lo. Simplicidade funcional, por exemplo, o conjunto de características é o mínimo necessário para satisfazer os requisitos; Simplicidade estrutural, por exemplo, a arquitetura é modularizada para limitar a propagação de defeitos; Simplicidade do código, por exemplo, um padrão de código é adotado para facilitar a inspeção e a manutenção. Estabilidade : Quanto menos modificações, menos interrupções no teste Modificações no software não são freqüentes; Modificações no software são controladas; Modificações no software não invalidam os testes existentes; O software se recupera bem das falhas. Compreensibilidade : Quanto mais informações disponíveis mais racionalmente vamos testar o software. O projeto é bem compreendido; As dependências entre componentes internos, externos e compartilhados são bem compreendidas; Modificações no projeto são informadas; A documentação técnica é acessível instantaneamente; A documentação técnica é bem organizada; A documentação técnica é específica e detalhada; A documentação técnica é precisa. 7

8 5 Método de Teste 5.1 Teste Caixa-Preta Também chamado de teste comportamental, focaliza os requisitos funcionais do software para garantir que estão plenamente satisfeitos. Isto é, o teste de caixapreta permite ao analista de teste derivar conjuntos de condições de entrada que vão exercitar plenamente todos os requisitos funcionais de um programa. O teste de caixa-preta não é uma alternativa às técnicas caixa-branca. É uma abordagem complementar que provavelmente descobrirá uma classe diferente de erros do que os métodos caixa-branca. Não é objetivo dos testes de caixa preta verificar como ocorrem os processamentos, mas sim, se estes produzem os resultados esperados. O método de caixa preta não requer conhecimento interno do sistema, mas somente o conhecimento dos requisitos de negócio Tenta encontrar erros das seguintes categorias: funções incorretas ou omitidas, erros de interface, erros de estrutura de dados ou de acesso a base de dados externa, erros de comportamento ou desempenho e erros de iniciação e término. Diferente do teste caixa-branca, que é realizado no início do processo de teste, o teste caixa-preta tende a ser aplicado durante os últimos estágios da execução dos testes. Como o teste caixa-preta despreza, propositalmente, a estrutura de controle, a atenção é focalizada no domínio da informação. Os testes são projetados para responder as seguintes questões: Como a validade funcional é testada? Como o comportamento e o desempenho do sistema são testados? Que classes de entrada vão constituir bons casos de teste? O sistema é particularmente sensível a certos valores de entrada? Como são isolados os limites de uma classe de dados? Que taxas e volumes de dados o sistema pode tolerar? Que efeito as combinações específicas de dados vão ter na operação do sistema? 6 Ferramentas de Automatização de Testes Existem várias ferramentas de automatização, e é improvável que uma única ferramenta seja capaz de automatizar todas as atividades de teste. Geralmente, as ferramentas de teste são avaliadas com base nas seguintes categorias: Função; Caixa branca versus Caixa preta; Especialização. 6.1 Função As ferramentas de teste podem ser caracterizadas pela função que executam. Estas são as designações de funções comuns para ferramentas: Ferramentas de aquisição de dados que adquirem os dados a serem usados nas atividades de teste. É possível adquirir dados através da 8

9 conversão, extração, transformação ou captura dos dados existentes, ou através da geração a partir de casos de uso ou especificações suplementares. Ferramentas de medição estática que analisam as informações contidas nos modelos de design, no código-fonte ou em outras fontes fixas. A análise produz informações sobre o fluxo lógico, o fluxo de dados ou as métricas de qualidade, como complexidade, capacidade de manutenção ou linhas de código. Ferramentas de medição dinâmicas que executam uma análise durante a execução do código. As medições incluem a operação do código em tempo de execução, como desempenho e detecção de erros na memória. Simuladores ou Geradores que executam atividades que não estão ou não podem estar disponíveis para fins de teste, por questão de tempo, custo ou segurança. Ferramentas de gerenciamento de teste que auxiliam no planejamento, design, implementação, execução, avaliação e gerenciamento dos artefatos ou atividades de teste. 6.2 Especialização Além das amplas classificações de ferramentas apresentadas acima, elas também podem ser classificadas por especialização: Ferramentas de registro/reprodução combinam a aquisição de dados com a medição dinâmica. Os dados de teste são adquiridos durante o registro de eventos (na implementação do teste). Mais tarde, durante a execução do teste, os dados são usados para "reproduzir" o script de teste usado para avaliar a execução do objetivo do teste; Ferramentas de medição de qualidade são ferramentas de medição estáticas que executam uma análise estática dos modelos de design ou do código-fonte para estabelecer um conjunto de parâmetros que descreva a qualidade do objetivo do teste. Os parâmetros podem indicar confiabilidade, complexidade, capacidade de manutenção ou outras medidas de qualidade; Ferramentas de monitoramento de cobertura indicam a abrangência do teste, identificando quanto do objetivo do teste foi coberto, em alguma dimensão, durante o teste. As classes comuns de cobertura incluem casos de uso baseados em requisitos, ramificações ou nós lógicos (baseados em código), estado dos dados e pontos de função; Geradores de caso de teste automatizam a geração dos dados de teste. Eles usam uma especificação formal das entradas de dados do objetivo do teste ou os modelos de design/código-fonte para produzir dados de teste que testem as entradas nominais, entradas de erro e casos de limite e fronteira; Ferramentas de comparação comparam os resultados do teste com os resultados de referência e identificam as diferenças. Os comparadores diferem quanto à especificidade para determinados formatos de dados. Por exemplo, os comparadores podem ser baseados em pixels (para comparar imagens de bitmap) ou em objetos (para comparar propriedades ou dados do objeto); Extratores de dados fornecem entradas para casos de teste provenientes de fontes existentes. As fontes incluem bancos de dados, streams de dados 9

10 em um sistema de comunicação, relatórios ou modelos de design/códigofonte. 7 Catálogo de Idéias de Teste A maior parte da programação dos testes consiste em aproveitar os itens que têm sido usados ao longo do tempo, utilizando-os mais uma vez em um contexto distinto. Esses itens podem abranger estruturas de dados (como listas vinculadas, tabelas de hashing, bancos de dados relacionais, etc.) ou operações (como pesquisa, classificação, criação de arquivos temporários ou exibição da janela de um navegador). Um desenvolvedor que exibe a janela de um navegador pode cometer um desses erros reincidentes: Criar uma nova janela quando outra já aberta deveria ser reutilizada; Não tornar visível a janela de um navegador que esteja oculta ou minimizada; Usar o Internet Explorer quando o usuário escolheu outro navegador padrão; Não verificar se o Javascript está ativado. 7.1 Catálogos Adequados O que torna um catálogo adequado? Ele contém um pequeno conjunto de idéias de teste que pode localizar um conjunto muito maior de falhas básicas. Ele pode ser examinado superficialmente com facilidade. Você deve ser capaz de ignorar as idéias de teste que não sejam relevantes para a sua situação. Não deve conter idéias de teste que nunca serão utilizadas. Por exemplo, alguém que nunca lida com navegadores da WEB não deve usar idéias de teste referentes a programas que usam navegadores da WEB. Alguém que trabalha com softwares de jogos precisa de um catálogo menor que alguém que trabalha com softwares nos quais a segurança é vital. A pessoa que lida com jogos pode se concentrar apenas nas idéias de teste com maior chance de localizar falhas. Considerando essas regras, é melhor existir mais de um catálogo. Como alguns dados e operações são comuns, as respectivas idéias de teste podem ser incluídas em um catálogo genérico para que todos os Analistas de Teste e Testadores possam usá-las. Outras são específicas de um determinado domínio; por isso, as idéias de teste correspondentes podem ser incluídas em um catálogo de idéias de teste específico do domínio. 7.2 Criação e Manutenção de Seus Próprios Catálogos Como mencionado anteriormente, o catálogo genérico não conterá todas as idéias de teste necessárias. Para que se possa manter um catálogo específico, terá de se criá-lo. Eis algumas sugestões: Deve-se evitar a tentação de preencher um catálogo com especulações sobre quais seriam as idéias apropriadas para a localização de falhas. Cada idéia de teste incluída no catálogo custa tempo e dinheiro: o tempo gasto 10

11 para manter o catálogo, o tempo de outros testadores para pensar sobre a idéia de teste e para implementá-lo. Adicionar apenas as idéias que tenham um registro de controle demonstrado e que é capaz de apontar pelo menos uma falha real. O ideal é que essas falhas não tenham sido identificadas por outros testes (ou seja, uma falha relatada pelo campo). Uma boa maneira de criar catálogos consiste em percorrer o banco de dados de erros e perguntar como cada falha poderia ter sido detectada anteriormente; A criação e a manutenção de um Catálogo de Idéias de Teste são tarefas que devem ter tempo alocado, como para qualquer outra atividade. 7.3 Lista de Idéias de Teste As informações usadas no design de testes são provenientes de vários locais: modelos de design, interfaces de classificador, diagrama de estados e o próprio código. Em determinado ponto, as informações do documento de origem devem ser transformadas em testes executáveis: Entradas específicas feitas no software em teste; Em determinada configuração de hardware e software; Inicializadas em um estado conhecido; Com resultados específicos esperados. É possível passar diretamente das informações do documento de origem para os testes executáveis. Mas normalmente é útil adicionar uma etapa intermediária. Nela, as idéias de teste são incluídas em uma Lista de Idéias de Teste. A lista é usada para criar testes executáveis. 7.4 O que são Idéias de Teste? Uma idéia de teste (ou requisito de teste) é uma declaração resumida sobre um teste que poderia ser realizado. Como exemplo, vamos utilizar uma função que calcula uma raiz quadrada. Eis uma lista de idéias de teste: Fornecer como entrada um número menor que zero; Fornecer zero como entrada; Testar um número que tenha uma raiz quadrada perfeita, como 4 ou 16 (o resultado é exatamente 2 ou 4?). Cada uma dessas situações poderia ser facilmente convertida em um teste executável com descrições exatas de entradas e resultados esperados. Todos os exemplos de raiz quadrada descrevem entradas, mas as idéias de teste podem descrever qualquer elemento de um teste executável. Por exemplo, "imprimir em uma HP LaserJet" descreve a configuração do teste, enquanto "testar com o banco de dados cheio" descreve a configuração e inicialização do sistema. Essas últimas idéias de teste são em si incompletas. Imprimir o que na impressora? Fazer o que com esse banco de dados cheio? Contudo, elas garantem que idéias importantes não sejam esquecidas, idéias que surgirão posteriormente no design de teste. As idéias de teste geralmente baseiam-se em modelos de falha, noções sobre quais falhas são plausíveis no software e sobre qual a melhor forma de descobri-las. Por exemplo, considere fronteiras. É seguro supor que a função de raiz 11

12 quadrada seja implementada de maneira semelhante a esta: double sqrt(double x) { if (x < 0) // erro de sinal... É plausível que < seja digitado incorretamente como <=. As pessoas sempre cometem esse tipo de erro; portanto, convém verificar. Não será possível detectar a falha se X tiver o valor 2, pois a expressão incorreta (x<=0) e a expressão correta (x<0) seguirão a mesma ramificação da instrução if. Da mesma forma, se X tiver o valor -5, não será possível encontrar a falha. A única maneira é atribuir a X o valor 0, o que justifica a segunda idéia de teste. Nesse caso, o modelo de falha é explícito. Em outros casos, é implícito. Por exemplo, sempre que um programa manipula uma estrutura vinculada, convém testá-la com uma circular. É possível ocorrer falhas que levem a uma estrutura circular difícil de ser tratada. Para fins de teste, elas não precisam ser enumeradas - basta saber que uma falha é provável o suficiente para justificar a execução do teste. É possível aplicar esses modelos de falha a vários artefatos diferentes. Por exemplo, o primeiro descreve o que fazer com uma expressão booleana. Elas podem ser encontradas no código, em condições de guarda em diagramas de estados e de seqüência, e em descrições de idioma nacional dos comportamentos de método (como pode ser encontrado em uma API publicada). Observe que uma Lista de Idéias de Teste específica pode conter idéias de teste provenientes de vários modelos de falha. Também pode conter idéias de teste derivadas de mais de um artefato. 8 Medições As principais medidas de um teste incluem a cobertura e a qualidade. A cobertura é a medida da abrangência do teste e é expressa pela cobertura dos requisitos e casos de teste ou pela cobertura do código executado. A qualidade é uma medida de confiabilidade, de estabilidade e de desempenho do objetivo do teste (sistema ou aplicativo em teste). Ela se baseia na avaliação dos resultados do teste e na análise das solicitações de mudança (defeitos) identificadas durante o teste. 8.1 Medidas de Cobertura As medidas de cobertura fornecem respostas à pergunta "Qual é a abrangência do teste?". As medidas de cobertura usadas com mais freqüência são a cobertura de teste baseada em requisitos e em códigos. Em resumo, a cobertura de teste é qualquer medida de abrangência relacionada a um requisito (baseada em requisitos) ou a um critério de design/implementação do código (baseada em códigos), como a verificação de casos de uso (baseada em requisitos) ou a execução de todas as linhas de código (baseada em códigos). Qualquer atividade sistemática de teste baseia-se em, pelo menos, uma estratégia de cobertura. Essa estratégia orienta o design de casos de teste declarando a finalidade geral do teste. A declaração da estratégia de cobertura pode ser tão simples quanto verificar todo o desempenho. Se os requisitos estiverem completamente catalogados, uma estratégia de cobertura baseada em requisitos poderá ser suficiente para produzir uma medida quantificável para testar a abrangência. Por exemplo, se todos os requisitos do teste de desempenho foram identificados, é possível fazer referência aos resultados 12

13 do teste para obter medidas, como 75% dos requisitos do teste de desempenho foram verificados. Se a cobertura baseada em códigos for aplicada, as estratégias de teste serão formuladas em termos da quantidade do código-fonte que foi executada pelos testes. Esse tipo de estratégia de cobertura de teste é muito importante para sistemas de segurança crítica. 8.2 Cobertura de Teste Baseada em Requisitos A cobertura de teste baseada em requisitos é medida diversas vezes durante o ciclo de vida do teste e fornece a identificação da cobertura do teste em um marco desse ciclo (como a cobertura de testes planejados, implementados, executados e bem-sucedidos). A cobertura de teste é calculada pela seguinte equação: Cobertura de Teste = T / RfT onde: T é o número de Testes (planejados, implementados, executados ou bemsucedidos) expressos como procedimentos ou casos de teste. RfT é o número total de Requisitos do Teste. Na atividade Planejar Teste, a cobertura de teste é calculada para determinar a cobertura dos testes planejados e o cálculo é efetuado da seguinte maneira: Cobertura dos Testes (planejados) = T p / RfT onde: T p é o número de Testes planejados expressos como procedimentos ou casos de teste. RfT é o número total de Requisitos do Teste. Na atividade Implementar Teste, à medida que os procedimentos de teste são implementados (como procedimentos de teste), a cobertura de teste é calculada usando a seguinte equação: Cobertura dos Testes (implementados) = T i / RfT onde: T i é o número de Testes implementados conforme expresso pela quantidade de procedimentos ou casos de teste para os quais existem scripts correspondentes. RfT é o número total de Requisitos do Teste. Na atividade Executar Teste, são usadas duas medidas de cobertura. Uma delas identifica a cobertura obtida com a execução dos testes. A outra identifica a cobertura dos testes bem-sucedidos (aqueles que foram executados sem falhas, como defeitos ou resultados inesperados). Essas medidas de cobertura são calculadas pelas seguintes equações: Cobertura dos Testes (executados) = Tx / Rft onde: Tx é o número de Testes executados expressos como procedimentos ou casos de teste. RfT é o número total de Requisitos do Teste. 13

14 Cobertura dos testes bem-sucedidos (executados) = T s / RfT onde: T s é o número de Testes executados expressos como procedimentos ou casos de teste que foram concluídos com êxito e sem defeitos. RfT é o número total de Requisitos do Teste. A transformação das relações anteriores em porcentagens permite a seguinte declaração sobre a cobertura de teste baseada em requisitos: x% dos casos de teste (T(p,i,x,s) nas equações anteriores) obtiveram uma taxa de êxito de y% Essa é uma declaração importante de cobertura de teste que pode ser comparada a critérios de êxito definidos. Se os critérios não forem atingidos, a declaração fornecerá uma base para prever a quantidade de esforço de teste restante. 9 Planejar Testes 9.1 Plano de Teste Este é o primeiro documento e o de mais alto nível gerado pelo processo de testes de software e deve ser elaborado de acordo com o objetivo de formalizar o processo de testes a ser iniciado, envolvendo os usuários, clientes e desenvolvedores. Um plano de testes refere-se a diversos projetos de avaliação, um para cada etapa do desenvolvimento ou versão intermediária do software. O Plano de testes deve prever, para cada versão intermediária do sistema, qual o tipo de teste apropriado à determinada etapa, quais suas condições (casos e requisitos de testes), os resultados obtidos e qual desses resultados serão admitidos. Para facilitar a elaboração desses documentos é possível utilizar o CaliberRM para criação de cada caso de teste utilizando o mesmo formato utilizado com os requisitos e facilitando a rastreabilidade de cada caso de teste com seu respectivo caso de uso. 14

15 9.1.1 Finalidade A finalidade do Plano de Teste é: Definir as metas e os objetivos dos testes no escopo da iteração (ou projeto), os itens-alvo, a abordagem adotada, os recursos necessários e os produtos que serão liberados. Comunicar a intenção do esforço de teste em determinada programação. Ganhar a aceitação e aprovação dos envolvidos no esforço de teste. Direcionar, orientar e restringir o esforço de teste, priorizando os produtos liberados úteis e necessários. Deve estabelecer uma visão clara de como será operacionalizado o processo, estabelecendo um escopo bem definido de trabalho e nivelando expectativas em relação aos testes. Devem-se evitar informações que não serão compreendidas ou que serão consideradas irrelevantes pelos envolvidos. 9.2 Requisitos de Teste O teste de software consiste em mais do que simplesmente avaliar as funções, a interface e as características de tempo de resposta de um objetivo do teste. Os testes adicionais devem se concentrar em características / atributos. Para conseguir isso, diferentes tipos de testes são implementados e executados, cada um com um objetivo e uma técnica de suporte específico. O foco 15

16 de cada técnica está em testar uma ou mais características ou atributos do objetivo do teste. Alguns destes tipos estão listados a seguir: Teste de integridade de dados e BD Objetivo: Os bancos de dados e os processos de banco de dados deverão ser testados como um subsistema independente. Esse teste deve testar os subsistemas sem que a Interface do Usuário faça interface com os dados. É necessário efetuar pesquisas adicionais referentes ao Sistema de Gerenciamento de Banco de Dados (DBMS) a fim de assegurar que os dados foram distribuídos conforme o planejado e que todos os eventos de banco de dados ocorreram de forma adequada. Revisar os dados retornados para assegurar que os dados corretos foram recuperados pelas razões corretas. Experimentar processos e métodos de acesso a banco de dados para que se possa observar e registrar comportamentos-alvo incorretos ou a existência de dados corrompidos. Condições para execução: poderão necessitar de drivers ou de um ambiente de desenvolvimento DBMS para inserir ou modificar dados diretamente no banco de dados. Os processos deverão ser disparados manualmente. Deverão ser usados bancos de dados pequenos ou de tamanho mínimo (com um número limitado de registros) para aumentar a visibilidade de quaisquer eventos não aceitáveis Teste funcional Objetivo: detectar erros entre as especificações funcionais do software, e seu atual comportamento. Quando um erro for identificado, tanto a especificação quanto o comportamento poderão estar errados. Condições para execução: Produto deve ser testado com todos os softwares e hardwares especificados nos requisitos Teste do ciclo de negócio Objetivo: emular as atividades executadas no projeto ao longo do tempo. Deverá ser identificado um período, e deverão ser executadas as transações e atividades que ocorreriam durante esse período. Isso incluirá todos os ciclos diários, semanais e mensais, assim como os eventos que mudam com as datas. Condições para execução: Produto deve ser testado com todos os softwares e hardwares especificados nos requisitos Teste de Interface de Usuário Objetivo: é responsável pela interação antecipada do usuário com o software em desenvolvimento onde poderá, antecipadamente, detectar problemas na utilização do produto, como dificuldades de navegação, falta de clareza nas informações disponíveis, termos não adequados ao negócio suportado pelo software, entre outros. Condições para execução: Através da utilização de desenhos, protótipos ou mesmo produtos semi-acabados. 16

17 9.2.5 Teste de Carga Objetivo: Verifica a aceitabilidade do comportamento de desempenho do objetivo do teste em condições operacionais variáveis (como número de usuários, número de transações, etc.), enquanto a configuração permanece constante. Condições para execução: elevação momentânea de parâmetros chave do software, como taxa de erros, volume de transações, número de usuários simultâneos, e combinações destes Teste de Stress Objetivo: Consisti em testar o software em situações limites, como cadastrar valores ou determinadas informações que contenham uma grande carga de dados possíveis até que alguma falha ocorra. O teste de stress exige do sistema alguns recursos de qualidade, volume e freqüências anormais, como exemplo, pesquisas longas e exaustivas em disco, testes limites de memória, entre outros. Condições para execução: elevação momentânea de parâmetros chave do software, como taxa de erros, volume de transações, número de usuários simultâneos, e combinações destes Teste de Volume Objetivo: destinado a verificar a capacidade do objetivo do teste de lidar com um grande volume de dados, como entrada e saída ou residente no banco de dados. O teste de volume abrange, como, por exemplo, a entrada de dados do volume máximo de dados em cada campo ou a criação de consultas que retornem todo o conteúdo do banco de dados ou que tenham tantas restrições que nenhum dado seja retornado. Condições para execução: ao contrário do teste de carga e stress, esse tipo de teste não focaliza situações de pico, mas o aumento contínuo das condições de carga Teste de Segurança e Controle de Acesso Objetivo: demonstrar que todas as funcionalidades de segurança operam da maneira como foram especificadas e testar a resistência do sistema às ameaças existentes no ambiente, visando detectar formas de quebra de segurança do software. Condições para execução: geralmente são obtidos durante a execução de outros testes de Sistema Teste de Falha e Recuperação Objetivo: forçar o software a falhar, e verificar se a combinação do software com outros programas são realizados com sucesso. Tais testes são executados conforme as necessidades de cada testador. Essas falhas podem ocorrer devido a quedas na rede dos computadores ou na energia elétrica, além da execução de alguma funcionalidade do software que dependa de outros programas, entre outros. Quando ocorrer essas falhas, será verificado se a recuperação está sendo adequadamente realizada. 17

18 Condições para execução: geralmente são obtidos durante a execução de outros testes de Sistema Teste de Configuração Objetivo: determinar configurações de software e hardware, previstas na especificação de requisitos, em que o software não opera de forma adequada. Condições para execução: Produto deve ser testado com todos os softwares e hardwares especificados nos requisitos Teste de Instalação Objetivo: destinado a garantir que o objetivo do teste seja instalado conforme o esperado em diferentes configurações de hardware e/ou software e sob diferentes condições (como no caso de espaço insuficiente em disco ou interrupção de energia). Esse teste é implementado e executado em aplicativos e sistemas. Condições para execução: devem-se executar as instruções de instalação em ambientes simulados ou reais, verificando se estas estão claras e completas, observando os resultados produzidos Teste de Contenção Objetivo: destinados a verificar se os objetivos do teste podem lidar de forma aceitável com as demandas de vários atores no mesmo recurso (registros de dados, memória, etc.). Condições para execução: geralmente são obtidos durante a execução de outros testes de Sistema Teste de Estrutura Objetivo: preocupar com a função que o programa desempenha sem preocupar-se de como a função foi implementada, o teste estrutural enfoca a implementação e a estrutura da função. A intenção do teste estrutural é encontrar dados de teste que terão cobertura suficiente de todas as estruturas presentes na representação formal. Condições para execução: Embora geralmente usado durante a fase de codificação, testes estruturais devem ser usados em todas as fases do ciclo de vida do software nas quais o software é representado formalmente. 10 Projetar Teste 10.1 Casos de Teste Contém informações sobre os Objetivos, os Cenários e os respectivos Casos de Testes a serem abordados e planejados para realização dos testes funcionais. Defini os cenários a serem cobertos pelos casos de testes, com base nas especificações de caso de uso. A execução dos casos de testes visa verificar e validar as funcionalidades do sistema, e o seu correto funcionamento. Abrangendo seus fluxos principais e alternativos. 18

19 Cenário de Teste Objetivo: iniciar o processo de detalhamento dos testes de validação. Identificar o maior número de variações possíveis sobre um determinado requisito a ser testado. Cada cenário será validado por um conjunto de procedimentos que deverão ser levantados Fluxos (Básico e Alternativos) Detalha todos os procedimentos a serem realizados durante a execução dos testes. Cada cenário produz um conjunto diferenciado de procedimentos a serem seguidos, denominado fluxos. Os procedimentos definem o que e em que ordem, determinadas atividades deverão ser desempenhadas, visando a qualidade final dos testes Sugestões de Casos de Teste Detalha todas as informações a serem empregadas nos procedimentos definidos para cada cenário existente. Estas informações são referentes tanto às entradas de dados quanto às saídas esperadas para cada processamento. As primeiras sugestões de Casos de Teste podem ser identificadas logo na Fase de Levantamento de Requisitos, sendo identificadas subseqüentemente em cada iteração durante o restante do ciclo de vida do projeto. Os seguintes itens devem ser abordados: Identificação dos Casos de Testes; Definição de cada Caso de Teste; Detalhamento da Massa de Entrada (Entrada); Detalhamento da Massa Resultante (Saída); Critérios Especiais para Geração da Massa Ativa; Responsáveis; Definir Agenda de Levantamentos. Bons casos de teste são aqueles que encontram falhas no sistema até então não descobertas; Bons casos de teste são projetados levando em conta os requisitos do projeto Massa de Teste A definição de um conjunto de valores de entrada de teste que são usados durante a execução de um teste, e os resultados esperados mencionados para fins de comparação durante a execução de um teste. Normalmente, se começa a reunir sugestões de Massa de Teste logo na Fase de Levantamento de Requisitos, sendo esta tarefa desempenhada pelos analistas de requisitos em conjunto com a equipe de teste. 19

20 11 Preparar Ambiente de Teste 11.1 Finalidade Este ambiente deve fornecer toda a infra-estrutura necessária de hardware e software para a realização dos testes de software em condições conhecidas e controladas. Toda infra-estrutura deve estar disponível à equipe de testes e deve contemplar um ambiente semelhante ao de produção. Com isto será possível realizar um maior número de testes, principalmente os relativos a sistema, onde seja possível que requisitos como desempenho, volume e carga sejam medidos e estimados ao ambiente de produção. Neste ambiente deverão ocorre todos os processos de validação do software (os testes de usabilidade, funcionalidades e sistemas). Os testes são realizados com as técnicas de caixa preta, onde não se requer um conhecimento interno do software. Os testes são gerados com a finalidade de provocar situações específicas de negócio e verificar como estas foram tratadas. Através da análise deste comportamento o teste é dado como bem sucedido ou não. Podem ser empregadas técnicas de criptografia, impossibilitando que os dados, muitas vezes migrados de um ambiente real de produção, tornem-se de conhecimento dos profissionais do ambiente de teste Ocorrências Identificar as necessidades de ambiente, específicos para cada técnica de teste. Usando o Plano de Teste, identificar cada técnica que fará parte da abordagem de teste. Para cada técnica, listar os requisitos de ambiente específicos que precisarão ser satisfeitos para permitir a execução do teste. Definindo um inventário de itens básicos de hardware e software. Usando os requisitos identificados, agrupando em uma lista os itens de hardware e software necessários para a condução do teste. Definir um inventário detalhado de itens de hardware e software para suportar o processo de teste. Reunir os detalhes para cada configuração. Solicitar ajuda do suporte técnico ou dos recursos de administração do sistema, caso seja necessário. Descobrir os "extremos" mínimos e máximos para os possíveis ambientes. Em geral, esses extremos são suficientes para fornecer uma visão geral da experiência de ambiente. Definir os requisitos do processo de gerenciamento do Ambiente de Teste. Elaborar procedimento de gerenciamento para configurar, manter e gerenciar o ambiente de teste funcionando apropriadamente. 20

21 12 Implementar Testes 12.1 Procedimento de Teste Finalidade Registrar os procedimentos de um determinado teste, normalmente um conjunto de instruções detalhadas para a configuração e a execução passo a passo, de um ou mais casos de teste elaborados para verificação e validação do caso de uso foco do teste Condições Cada cenário produz um conjunto diferenciado de procedimentos a serem seguidos, denominado como Procedimento de Testes. Os procedimentos definem o que e em que ordem, determinadas atividades deverão ser desempenhadas, visando a qualidade final dos testes. Os procedimentos de teste podem começar a serem identificados na fase de Iniciação Alguns Itens devem ser Observados Os Procedimentos de Teste devem considerar alguns aspectos: Compatibilidade e relevância do teste individual a ser executado pelo procedimento de teste, especialmente nos termos do objetivo do teste e seu escopo; Ponto do qual o procedimento de teste pode ser recuperado ou reiniciado se a sua execução falhar; Configuração de hardware e software para execução do procedimento de teste, por exemplo, resolução de vídeo, alocação de recursos, variáveis de ambiente, caso sejam necessários; Disponibilizar requisitos pré-existentes de consumo do procedimento de teste, tais como povoamento da base de dados, instalação de impressoras. 13 Executar Testes Devem ser aplicadas todas as atividades planejadas no Plano de Teste pertinente à fase executada, ou seja, preparar o ambiente e executar todo o conjunto de testes elaborados na fase de planejamento Finalidade Executar os conjuntos de testes apropriados necessários para validar a qualidade do produto. Capturar resultados de teste que facilitem a avaliação do produto Conduzir os testes incluídos no Conjunto de Testes, monitorando e suportando sua conclusão Tipos de Execução A execução dos Conjuntos de Testes e dos Scripts de Testes varia de acordo com o tipo de teste, ou seja, automatizado ou manual: 21

22 Teste automatizado: Os scripts de teste criados durante a atividade Implementar Teste são executados. Execução manual: Os Scripts de Teste estruturados e desenvolvidos durante a atividade Projetar Teste são usados para executar manualmente o teste Recuperar a partir de testes interrompidos Determinar a ação corretiva apropriada para a recuperação a partir da execução de um Conjunto de Testes interrompido e, se necessário, corrigir o problema, recuperando e executando novamente o Conjunto de Testes Restaurar o ambiente de teste ao estado conhecido Garantir que tenha sido feita uma limpeza apropriada do ambiente após a execução do Script de Teste. Restaurar o ambiente novamente ao seu estado original: Redefinição do ambiente básico (arquivo do Registro e outros arquivos de configuração); Restauração dos bancos de dados básicos ao estado conhecido; Além de outras tarefas necessárias a sua restauração. 14 Registro de Erros da Release 14.1 Finalidade Registrar todos os procedimentos e ocorrências (suspeitas e identificações de erros) realizados durante a execução de um ciclo de testes, bem como apontar as eventuais interrupções e re-processamentos ocorridos. O Registro de Erros da Release é uma prova de que os testes foram processados. Fornecer um registro detalhado usado para verificar se ocorreu a execução de um conjunto de testes, e fornecer informações relacionadas ao sucesso desses testes. Em geral, o foco está voltado para o provimento de uma faixa de auditoria precisa, permitindo a realização de um diagnóstico de falhas posterior a uma execução. Esses dados serão analisados subseqüentemente para ajudar a determinar os resultados de algum aspecto do esforço de teste Ocorrência Devem ser criados sempre que os Conjuntos de Testes forem executados. Deve ser composto de uma série de entradas que apresentem uma faixa de auditoria para diversos aspectos da execução de testes. 15 Avaliação dos Resultados dos Testes 15.1 Finalidade É produzido com o objetivo de sumarizar todos os sucessos e insucessos alcançados, após o término de todas as etapas do processo de validação. 22

23 Verificar se a atividade foi concluída de forma apropriada e se os artefatos resultantes são aceitáveis. Determinar se o Conjunto de Testes foi executado até o fim ou interrompido de forma anormal e avaliar se há necessidade de ação corretiva. A execução do teste é concluída ou finalizada em uma destas duas condições: Normal: todos os Scripts de Teste são executados até a conclusão conforme planejado. Anormal ou prematura: os Scripts de Teste não são executados completamente conforme planejado. A causa do término anormal precisa ser identificada e, se necessário, o erro deve ser corrigido e os testes devem ser novamente executados. Também é um excelente momento de propor melhorias no processo como um todo. 16 Definição do Ciclo de Teste A atividade de definição do Ciclo de Teste é um complemento à elaboração de Estratégia de Teste, e tem como objetivo principal registrar como será a simulação da execução dos processos de negócio que envolve o sistema em um período menor e controlado, o qual denominamos de Ciclo de Teste. Esta fase é de extrema importância, pois ela possibilita ao Arquiteto de Teste visualizar quais serão as dependências e seqüência de execução dos testes, antes de se iniciar a elaboração dos Planos de Teste, fato que facilita a atividade de Elaborar Planos de Teste e agiliza a atividade de Planejar Execução de Teste Procedimentos 1) Identificar, inicialmente, qual será o escopo do teste, através da Estratégia de Teste, entendendo qual será a integração e dependência entre Requisitos de Escopo (processos de negócio) do sistema alvo de teste. 2) Estabelecer através da Estratégia de Teste de quantos dias é o Ciclo de Teste para demanda em questão. Exemplo: 15 dias úteis. Esta quantidade de dias poderá ser alterada ao longo da elaboração do documento de Ciclo de Teste conforme a necessidade. 3) Registrar os Requisitos de Escopo na planilha de Ciclo de Teste de acordo com o especificado na Estratégia de Teste no tópico Casos de Uso Alvo de Teste, por exemplo. 4) Através dos Requisitos Funcionais e, eventualmente, mediante reuniões com a Unidade de Requisitos, identificar qual é a seqüência de cada execução dos Casos de Uso englobados no Requisito de Escopo, dentro do Ciclo de Negócio do Sistema alvo de teste. 5) Em alguns casos poderá se registrar diferentes cenários de execução de teste para o mesmo Requisito de Escopo, e isto deverá ser tratado dentro do documento. 6) O Analista de Teste, responsável pela elaboração do documento de Ciclo de Teste, deverá distribuir a seqüência de cada Caso de Uso nas datas de 23

24 referência estabelecidas na planilha. Isto demonstrará em qual posição, no tempo, deverá ser executado um determinado Caso de Uso para se validar o processo de negócio ao qual ela faz parte. 7) Deve-se identificar qual a característica de execução de Caso de Uso, identificando-o como on-line ou batch. 8) Deve-se identificar a existência de dependência de algum conjunto de dados, que deve ser pré-existente no ambiente-alvo (banco de dados ou arquivos) para a execução do teste de um determinado Requisito de Escopo. 9) Após a elaboração do documento, o Analista de Teste poderá promover uma reunião de revisão do documento produzido, com alguns representantes da Unidade de Requisitos, Análise e Projeto e da própria Unidade de Teste para validação. 10) Após finalizado, este documento será de extrema importância para o Líder da Unidade de Teste durante a atividade de planejamento. 17 Conclusão A atividade de teste serve para mostrar o quão é importante, pois não sendo utilizada causa impacto como não se testar suficientemente um software, gerando erros e manutenções que poderiam ser evitadas. Muitas vezes, a correção de um erro num software pode custar muito mais caro do que se tivesse sido gasto um tempo maior para executar os testes necessários. À medida que gestores, equipes, empresas, passam a adequar o trabalho no intuito de se produzir um software de qualidade o que não se restringe ao aspecto de Testes todas as partes envolvidas irão colher os frutos. Desde o usuário, que muito provavelmente ficará satisfeito com o produto logo na primeira entrega, quanto os próprios desenvolvedores, que começarão a abandonar a imagem de sempre atrasam na entrega ou de não era isso que eu queria. 24

25 Anexo I - Sugestões para ferramentas de teste E para melhor realizar a atividade de testes existem diversas ferramentas que permitem a otimização dos testes a serem realizados, uma dessas ferramentas é a suíte de testes Silk da Borland e o Borland Gauntlet responsável por estar realizando a integração continua do código fonte. Abaixo segue uma breve descrição das ferramentas. Borland SilkCentral Test Manager : Disponibiliza eficiência e visibilidade a equipe de teste em uma única ferramenta de gerencia de teste que suporta todos os passos cruciais do ciclo de vida da garantia de qualidade do software; Borland Gauntlet : Permite de forma pro ativa implementar e testar o código fonte a medida que ele entra no repositório de controle de versão, isolando defeitos e reportando métricas de desenvolvimento com a integração continua e a ferramenta de cobertura de código, melhorando assim a visibilidade, a qualidade do software e a produtividade dos desenvolvedores; Borland SilkTest : Aumentar a produtividade e reduzir custos com regressão automatizada e teste funcional do software que incluem funcionalidades como gravação de informações da interface gráfica do sistema e execução dessas informações, alem de uma linguagem de teste simples e de fácil aprendizado; Borland SilkPerformer : Permite testar a performance do sistema de forma automatizada para otimizar o tempo de resposta, a escalabilidade e a confiança da aplicação. Para maiores informações consulte o site: 25