Frastøting

A atividade de escolha das estratégias de teste para a linha de produto tem como principal objetivo selecionar estratégias efetivas para a realização dos testes da linha de produto (passo 1 da Figura 5). Na abordagem proposta, a escolha das estratégias considera o documento de requisitos da LPS, informações dos modelos preliminares do GenArch que possam ter sido criados antes do processo de teste e as implementações (código) da linha de produto, bem como envolve: (i) decisões de que estratégias gerais serão utilizadas, tais como, teste apenas do núcleo da LPS, teste apenas dos produtos, ou teste de ambos; assim como (ii) a seleção de que tipos e estágios (níveis) de teste podem ser aplicados dada uma estratégia de teste de LPS escolhida. Diversos fatores podem influenciar nessa escolha, tais como: (i) a

tecnologia de implementação das variabilidades; (ii) o tipo e domínio do software envolvido na LPS; (iii) o grau de amadurecimento da equipe com automação de testes; (iv) os custos para sua implementação, etc. A escolha da estratégia de teste é essencial, uma vez que determina que casos de teste deverão ser, de fato, elaborados e possivelmente automatizados para garantir a qualidade da linha de produto de software.

Nossa abordagem explicita e detalha estratégias concretas de teste de linhas de produto, ressaltando as vantagens de cada uma delas. O foco principal do trabalho é nos testes relacionados às funcionalidades da linha de produto, testes não-funcionais serão alvos de trabalhos futuros. A escolha dos testes do tipo funcional foi, sobretudo, devido a sua importância no contexto de teste de sistemas e por serem fundamentais na garantia de qualidade do funcionamento de aplicações. A Tabela 1 apresenta diferentes tipos e estágios de teste que podem ser aplicados as estratégias gerais de teste escolhidas.

Tabela 1 - Estratégias concretas de teste para Linhas de Produto.

Estratégia Objetivo Consequências

Teste de Unidade do Núcleo Exercitar e avaliar a

funcionalidade implementada por classes do núcleo da LPS, de forma a verificar o seu funcionamento.

Problemas ligados a classes do núcleo são identificados e não são transferidos para os membros da LPS.

Teste de Unidade do Núcleo com Mocks

Verificar o funcionamento adequado de classes do núcleo com outras classes do núcleo que apresentam um comportamento complexo ou

são difíceis de serem

inicializados.

As classes do núcleo (difíceis de serem usadas nos testes), as quais interagem com outras classes do núcleo, mas que representam elementos que estarão sob teste, podem ser simuladas por Mock Objects. Dessa forma, as classes do núcleo podem ser testadas sem a necessidade de usar instâncias reais das outras classes do núcleo que possam depender.

Teste de Integração do Núcleo Verificar o funcionamento e colaboração adequada de classes do núcleo. A viabilidade de integração dos componentes é comprovada. Componentes

envolvidos nos testes e de qualidade atestada podem ser usados para um produto derivado.

Teste de Sistema do Núcleo Verificar que os componentes

comuns existentes na

arquitetura da LPS estão funcionando adequadamente.

Casos de testes são aplicados exclusivamente para artefatos do núcleo da arquitetura da LPS, permitindo saber se

classes anteriormente

testadas continuam

funcionando da forma

esperada, bem como podem verificar o comportamento da

aplicação com os

componentes do núcleo.

Teste de Unidade e

Integração de um Produto

Analisar se unidades como classes da parte comum e variável de um produto

funcionam de forma

adequada, como também saber se a colaboração entre essas classes também está de acordo com o esperado.

Componentes do núcleo e

variações são retestados

quando presentes em um produto derivado. Além disso, testes são usados para verificar novamente que a

colaboração entre os elementos de implementação está adequada. Teste de Sistema de um Produto Verificar se os componentes comuns e variáveis de um produto funcionam corretamente. A qualidade do comportamento funcional do produto é comprovada.

As estratégias apresentadas na Tabela 1 concretizam duas abordagens gerais de teste de LPS encontradas na literatura que são: (i) divisão de responsabilidades (Tevanlinna et al., 2004) que motiva a aplicação de teste tanto na engenharia de domínio como na engenharia de aplicação; e (ii) reuso de artefatos de teste (Pohl e Metzger, 2006), (McGregor, 2001b), (Tevanlinna et al., 2004) que

destaca a elaboração de testes durante a engenharia de domínio de forma a promover o reuso de tais artefatos durante a engenharia de aplicação.

A primeira abordagem geral – divisão de responsabilidades – é concretizada pela definição explícita de estratégias que se manifestam na engenharia de domínio e aplicação de uma LPS. O trabalho apresenta diretrizes de como testes de unidade, integração e sistema são aplicados para os artefatos que implementam o núcleo da LPS como para os diversos produtos (configurações) gerados.

A segunda abordagem geral – reuso de artefatos de teste – por sua vez, é implementada neste trabalho através da reutilização de testes de unidade e integração na engenharia de aplicação e que foram definidos para o teste do núcleo durante a engenharia de domínio, assim como pela definição de templates de geração de código de teste. Os templates são implementados para os seguintes cenários: (i) geração de testes de sistema para o núcleo; (ii) geração de testes de integração para os produtos; e (iii) geração de testes de sistema para os membros (produtos) da LPS. No primeiro cenário, os templates são implementados ainda na fase de domínio e possuem código de teste para páginas comuns a todos os produtos da linha. Em outras palavras, são voltados para páginas mandatórias e que apresentam código fixo. Os testes para tais páginas (gerados a partir dos templates) estarão sempre presentes, pois foram projetados para testar páginas que serão carregadas em todos os membros da LPS. A técnica de template é usada neste cenário apenas para customizar informações específicas do projeto da LPS ou mesmo diferentes dados de teste. Dessa forma, a medida que novos produtos são derivados, os testes podem ser reaproveitados. No segundo cenário de uso dos

templates, o código de teste desses artefatos são criados com base nos testes de

integração do núcleo. Os templates apresentam uma parte comum e outra variável que é gerada de acordo com a presença de variabilidades para determinado produto. O código comum é sempre reutilizado e a parte variável é passível de reuso, uma vez que pode existir um subconjunto entre todos os produtos da LPS que compartilhem uma mesma variabilidade. Dessa forma, o trecho de teste usado para testá-la estará presente no arquivo de teste de integração de cada membro do subconjunto. Por fim, no terceiro cenário, os templates são usados para permitir a geração de código de teste de sistema que possa exercitar páginas que apresentam conteúdo fixo e variável que depende da escolha de variabilidade para ser inserido. Os templates são implementados, de forma que possam testar a parte comum e

garantir também que trechos de código de teste para a parte variável também sejam gerados caso certa variabilidade seja selecionada. Assim como observado no uso dos templates para teste de integração, o reuso é alcançados devido a existência de trechos comuns nos casos de testes criados. Os trechos variáveis também podem ser reaproveitados, pois pode existir um grupo de produtos que apresentam a mesma variabilidade.

As seções seguintes apresentam as diretrizes para implementar cada estratégia concreta de teste proposta neste trabalho, permitindo compreender melhor como tais estratégias implementam as abordagens gerais de teste de LPS destacadas anteriormente. Além disso, é encontrada a forma como é usada a ferramenta de derivação GenArch para gerenciar e customizar os artefatos de teste automatizado elaborados durante a aplicação das estratégias.