Núcleo de Excelência em Testes de Sistemas Fundamentos de Teste de Software Módulo 1- Visão Geral de Testes de Software Aula 2 Estrutura para o Teste de Software
SUMÁRIO 1. Introdução... 3 2. Vertentes do Teste de Software... 3 3. Ciclo de Vida... 3 4. Estágio ou Níveis de Teste de Software... 6 5. Tipos de Testes de Software... 10 ii
1. Introdução Esta segunda parte do módulo apresenta os fundamentos estruturais e conceituais para compreender e adaptar a disciplina de teste de software. 2. Vertentes do Teste de Software No contexto do teste de software, é necessário ter a correta compreensão dos três pilares que dão sustentação a todo processo (Ver Figura 1). Eles são a base para o entendimento conceitual, adaptação prática e elaboração efetiva do planejamento do teste em um projeto. Nesse âmbito, os estágios ou níveis de teste abrangem o escopo de quando o teste será realizado. Já a vertente de tipos de teste compreende categorias de teste associadas a partir de um objetivo comum. Por sua vez, as técnicas de teste tratam formas para realizar um projeto de casos de teste. Figura 1 - pilares do processo de teste 3. Ciclo de Vida CASCATA É um ciclo de vida de desenvolvimento de software onde as atividades são sequenciais, no qual o desenvolvimento se dá através das fases de definição de requisitos, projeto de sistemas e software, implementação, testes, integração, operação e manutenção de software (Ver Figura 2). O primeiro modelo teve sua origem através de um artigo publicado referente 3
aos processos mais gerais de engenharia de software no ano de 1970 por Royce. Inicialmente, Royce buscava uma abordagem iterativa para o desenvolvimento de software e não usou em nenhum momento. Figura 2 - Modelo Cascata Os processos de teste podem ser adaptados de acordo com o ciclo de vida adequado ao contexto da organização. O ciclo de vida cascata é também conhecido como linear ou sequencial, onde os produtos de trabalho relacionados a cada fase devem ser completamente desenvolvidos antes de passarem para a fase seguinte. Os passos são executados em sequência e todos os requisitos do cliente são progressivamente refinados até o ponto onde a codificação se inicia. O teste é uma fase que só acontece após a implementação de todo código e pode ser visto como uma forma de auditoria da qualidade do produto podendo, portanto, ser aceito ou rejeitado. Esta etapa no modelo cascata serve para assegurar que todos os requisitos do software sejam atendidos. Um aspecto negativo desse ciclo de vida é que as mudanças no escopo, observadas ao longo do ciclo de vida, não são absorvidas pelo processo. Nesse caso, o produto pode estar obsoleto, mesmo antes de sua finalização. MODELO-V Antes de discutir o modelo V, é interessante compará-lo com o modelo que antecedeuse a ele. O modelo cascata foi um dos primeiros modelos a serem projetados. Tem uma linha de tempo natural, onde as tarefas são executadas sequencialmente. Neste modelo os testes acontecem no final do ciclo de vida do projeto, o que não traz benefício ao projeto. O modelo V, por sua vez, define níveis de teste correspondente a cada nível de desenvolvimento 4
de software (Ver Figura 3). O lado esquerdo do modelo foca as atividades de desenvolvimento de software. A parte central do modelo mostra que o planejamento das atividades de teste deve ser iniciado a partir de cada fase do desenvolvimento do software. Figura 3 - Modelo V O lado direito foca as atividades de teste, apresentando quando elas serão realizadas. Os artefatos produzidos no processo de desenvolvimento são a referência para o processo do teste. Por exemplo, no mesmo momento em que os requisitos estão sendo refinados em um projeto, o planejamento da aceitação já pode ser realizado. ITERATIVO Nem todos os ciclos de vida são sequenciais. Há também os ciclos de vida iterativo (Ver Figura 4), onde, em vez de ter um desenvolvimento sequenciado do começo ao fim, o mesmo percorre uma série de pequenos ciclos para o mesmo projeto, tal como acontece com o modelo V. O modelo de ciclo de vida iterativo foi concebido como uma resposta às lacunas ou problemas que existem no modelo cascata. Essa abordagem divide o desenvolvimento de um produto de software em ciclos ou iterações. Em cada ciclo de desenvolvimento podem ser identificadas as fases de elicitação ou definição dos requisitos, projeto de sistemas, implementação, testes, integração. Essa característica contrasta com a abordagem cascata ou clássica, na qual as fases são realizadas uma única vez. 5
Figura 4 - Modelo Iterativo Os requisitos de um sistema sempre mudam e evoluem ao longo de seu ciclo de vida, ou seja, durante o seu desenvolvimento. No ciclo de vida iterativo, o software é construído por partes e gradativamente incorporado ao que foi desenvolvido anteriormente. Iterações podem ser aplicadas a qualquer modelo do ciclo de vida de software, mesmo no modelo cascata que estudamos anteriormente. Utilizando a mesma abordagem, o processo de teste também é realizado iterativamente, onde o objetivo e esforço do teste devem estar de acordo com objetivo de cada iteração. O escopo do teste irá aumentar a cada iteração, haja vista que o software é construído também de maneira gradativa. Dessa forma, deve-se considerar a possibilidade de automação do processo de teste para trabalharmos de maneira mais efetiva, conforme o processo de desenvolvimento do produto. 4. Estágio ou Níveis de Teste de Software Os estágios de teste fornecem a indicação sobre o foco do teste e os tipos de problemas a serem encontrados, dependendo do nível em que o teste será realizado. O teste pode ser dividido em: unitário, sistema, integração e, por fim, aceitação. O conceito níveis de teste está relacionado com o modelo V, que representa quando as atividades de teste acontecem em decorrência do ciclo de vida do software. No entanto, o conceito de estágios de teste também pode ser aplicado ao desenvolvimento iterativo. Quando o teste é realizado no momento da codificação e desenvolvimento do sistema, 6
consideramos o nível de teste unitário (Ver Figura 5). Já, quando o teste é realizado no momento da integração de componentes previamente desenvolvidos, estamos falando do teste de integração. Após o desenvolvimento do sistema, no momento em que os analistas de teste validam o produto com base nos requisitos, podemos considerar que estamos tratando de teste de sistema. Já no ambiente de produção, considera-se teste de aceitação aquele que é realizado pelo usuário da aplicação ou por terceiros designados, cujo objetivo é de aprovar ou não o software. UNITÁRIO Figura 5 - Níveis de Teste O teste unitário tem o objetivo de garantir que o código escrito esteja de acordo com sua especificação antes de integrá-lo com outras unidades ( Ver Figura 6). Figura 6 - Teste Unitário 7
O mesmo também é importante para garantir que todo o código escrito para a unidade possa ser executado. Nesse nível de teste, é imprescindível o acesso ao código fonte e isso acontece durante a fase de implementação. Nesse momento o desenvolvedor é o responsável pela execução do teste unitário e nesse âmbito há menor necessidade de formalismos. Os problemas são identificados e corrigidos ainda nessa fase. INTEGRAÇÃO O teste de integração tem por definição a busca por defeitos na interface entre componentes e ocorre em paralelo à atividade de integração do sistema (Ver Figura 7). Pode acontecer de várias formas, de acordo com a estratégia de integração adotada. Figura 7 - Teste de Integração Os testes de integração são feitos em sistemas completos ou subsistemas, compostos de componentes integrados, onde unidades de software e hardware são testadas juntas para avaliar a integração entre eles, permitindo exposição dos problemas nas interfaces das unidades. Pode haver mais de um nível de teste de integração, a serem utilizados em objetos de teste de tamanho variado. Por exemplo: 8
Teste de integração de componente testa interações entre componentes de software e é realizado após o teste de componente. Teste de integração de sistemas testa interação entre diferentes sistemas e pode ser realizado após o teste de sistema. Quanto maior o escopo para a realização da integração, maior será a dificuldade para isolar as falhas para componentes, algo que pode vir a representar um aumento no risco. Estratégias sistemáticas de integração podem ser baseadas na arquitetura do sistema (top-down e bottom-up), funções entre outros aspectos do sistema ou componente. Visando diminuir ou minimizar o risco de encontrar, tardiamente, defeitos, a integração deve, preferencialmente, ser incremental. SISTEMA Teste de sistema se refere ao comportamento de todo o sistema, ou seja, produto definido pelo escopo de um projeto ou programa de desenvolvimento (Ver Figura 8). Figura 8 - Teste de Sistema No teste de sistema, o ambiente de teste deve corresponder ao ambiente de produção em que o sistema irá funcionar. O teste de sistema refere-se ao comportamento do sistema como 9
um todo, com foco na análise da conformidade com os requisitos. Para ciclos de vida iterativos, o teste de sistema é antecipado e realizado por subconjuntos do sistema. Nesse contexto, recomenda-se o envolvimento de uma equipe independente para sua realização. ACEITAÇÃO O teste de aceitação é aquele realizado para assegurar o usuário de que o sistema irá funcionar de acordo com as expectativas definidas no início do projeto (Ver Figura 9). Figura 9 - Teste de Aceitação Este teste inclui a avaliação dos critérios objetivos para aceitação dos requisitos do software. Nesse caso, é necessário definir procedimentos de aceitação esclarecendo como o teste será conduzido e, com base nos acordos estabelecidos previamente, verificar se o produto satisfaz os requisitos. Todos os resultados do teste de aceitação devem ser documentados e, se necessário, um plano de ação deve ser traçado para os produtos rejeitados. 5. Tipos de Testes de Software Os tipos de teste são definidos de acordo com o nível em que o teste será realizado e também com base nos objetivos de cada um dos níveis de teste. Eles estão organizados em 10
categorias e, dependo do pesquisador e escola que é seguida, podem variar quanto a sua classificação. Nesse contexto iremos abordar três tipos de teste: (i) funcional, (ii) não funcional e (iii) estrutural, conforme descritos a seguir: FUNCIONAL O teste funcional é utilizado quando o objetivo é verificar se as especificações foram atendidas, ou seja, o foco do teste funcional são os requisitos funcionais do sistema. Portanto, o teste funcional olha para as funcionalidades do sistema e também é chamado de teste baseado em especificação, ou teste caixa preta (Ver Figura 10). Figura 10 - Teste Funcional Como exemplos de teste funcional, podemos citar o teste de segurança (ex.: um firewall ), investiga as funções relacionados à detecção de ameaça de vírus ou de ações mal intencionadas. Além disso, podemos citar também como teste funcional o cálculo de pagamento de um funcionário, em um sistema de folha de pagamento. NÃO FUNCIONAL Testes não funcionais incluem, mas não se limitam a: teste de performance; teste de carga; teste de estresse; teste de usabilidade; teste de interoperabilidade; teste de 11
manutenibilidade; teste de confiabilidade e teste de portabilidade. É o teste de como o sistema trabalha (Ver Figura 11). Figura 11 - Teste Não-Funcional Testes não funcionais podem ser realizados em todos os níveis de teste. O termo teste não funcional descreve que o teste é executado para medir as características que podem ser quantificadas em uma escala variável, como o tempo de resposta em um teste de performance. O teste não funcional busca analisar os aspectos comportamentais do sistema. Como exemplos de teste não funcional, podemos citar o teste de usabilidade. ESTRUTURAL A técnica de teste estrutural é mais conhecida como teste caixa branca. O teste estrutural tem como base o conhecimento da estrutura interna da codificação. Portanto, o teste estrutural é baseado no código escrito para implementar um componente ou sistema ( Ver Figura 12). Figura 12 - Teste Estrutural 12
O teste caixa branca é usado para garantir que elementos de uma estrutura foram corretamente definidos. Por exemplo, as técnicas de teste estruturado podem ser usadas para garantir que declarações do código de um determinado sistema são executadas uma única vez. Nesse caso, os testes estruturais podem acontecer em qualquer nível de teste. 13