UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE CENTRO DE CIÊNCIAS EXATAS E DA TERRA
DEPARTAMENTO DE INFORMÁTICA E MATEMÁTICA APLICADA PROGRAMA DE PÓS-GRADUAÇÃO EM SISTEMAS E COMPUTAÇÃO
HEITOR MARIANO DE AQUINO CÂMARA
UMA ABORDAGEM SISTEMÁTICA PARA IMPLEMENTAÇÃO,
GERENCIAMENTO E CUSTOMIZAÇÃO DE TESTES DE LINHAS DE PRODUTO DE SOFTWARE
HEITOR MARIANO DE AQUINO CÂMARA
UMA ABORDAGEM SISTEMÁTICA PARA IMPLEMENTAÇÃO,
GERENCIAMENTO E CUSTOMIZAÇÃO DE TESTES DE LINHAS DE PRODUTO DE SOFTWARE
Dissertação apresentada ao Programa de Pós-Graduação em Sistemas e Computação do Departamento de Informática e Matemática Aplicada da Universidade Federal do Rio Grande do Norte como requisito parcial para a obtenção do grau de Mestre em Sistemas e Computação.
Prof. Dr. Uirá Kulesza Orientador
Profª. Drª. Roberta de Souza Coelho Co-orientadora
Seção de Informação e Referência
Catalogação da Publicação na Fonte. UFRN / Biblioteca Central Zila Mamede
Câmara, Heitor Mariano de Aquino.
Uma abordagem sistemática para implementação, gerenciamento e customização de testes de linhas de produto de software. / Heitor Mariano de Aquino Câmara. – Natal, RN, 2011.
128f. ; il.
Orientador: Uirá Kulesza.
Co-orientador: Roberta de Souza Coelho.
Dissertação (Mestrado) – Universidade Federal do Rio Grande do Norte. Centro de Ciências Exatas e da Terra. Programa de Pós-Graduação em Sistemas e Computação.
1. Testes de software. – Dissertação. 2. Linhas de produtos de software.
– Dissertação. 3. Testes de linhas de produto de software. – Dissertação 4. Engenharia de software automatizada. – Dissertação. I. Kulesza, Uirá. II. Coelho, Roberta de Souza III. Universidade Federal do Rio Grande do Norte. IV. Título.
RN/UF/BCZM CDU 004.415.53
AGRADECIMENTOS
A Deus, por sempre me abençoar e concedido pelo seu infinito amor, misericórdia e graça a conclusão deste trabalho.
Aos meus pais, por todo amor, paciência, compreensão e apoio dedicados.
Aos meus irmãos, pelo incentivo constante.
A minha namorada, pelas palavras de confiança, conselhos, orações e por se fazer sempre presente mesmo nos momentos que não era possível estarmos juntos.
Ao meu orientador, por acreditar em mim e no desenvolvimento deste trabalho, assim como pela dedicação, ajuda constante e todo conhecimento adquirido.
Resumo
Com o uso da abordagem de linhas de produto de software (LPSs), vários benefícios
são alcançados quando comparados aos processos de desenvolvimento convencionais que se baseiam na criação de um único sistema por vez. O processo de desenvolvimento de uma LPS se diferencia da construção tradicional de software,
uma vez que apresenta duas etapas essenciais: a engenharia de domínio - quando elementos comuns e variáveis da LPS são definidos e implementados; e a engenharia de aplicação – quando uma ou mais aplicações (produtos específicos) são derivadas a partir do reuso dos artefatos criados na engenharia de domínio. Durante a elaboração da LPS, assim como no desenvolvimento convencional de sistemas, a atividade de teste é fundamental e tem como objetivo a detecção de defeitos nos artefatos produzidos. Contudo, as características de uma LPS trazem novos desafios a essa atividade e que precisam ser considerados. Diversas abordagens foram propostas para o processo de teste de linhas de produto, mas elas se mostram limitadas ou fornecem diretrizes muito gerais. Outro fator preocupante é a escassez de ferramentas que auxiliem na implementação, aplicação e acompanhamento dos testes, bem como na gerência e customização de tais artefatos. Com base nesse contexto relacionado ao processo de teste de LPSs, esta dissertação tem como objetivo propor uma abordagem sistemática para o teste de linhas de produto de software. A abordagem oferece: (i) estratégias de testes
automatizados para LPSs tanto na engenharia de domínio quanto de aplicação; (ii) diretrizes para a implementação e reuso de casos de teste automatizados nos níveis de unidade, integração e sistema tanto para a engenharia de domínio quanto de aplicação; e (iii) suporte ferramental para gerência e customização automática de casos de teste usando técnicas de derivação automática de software. A abordagem
é avaliada através da sua aplicação em uma linha de produto para sistemas web. Os resultados deste trabalho mostram que a abordagem proposta pode ajudar os desenvolvedores a lidar com os desafios impostos pelas características das LPSs durante o processo de testes.
Palavras-chave: Linhas de Produtos de Software; Testes de Software; Testes de
Abstract
Through the adoption of the software product line (SPL) approach, several benefits are achieved when compared to the conventional development processes that are based on creating a single software system at a time. The process of developing a SPL differs from traditional software construction, since it has two essential phases: the domain engineering - when common and variables elements of the SPL are defined and implemented; and the application engineering - when one or more applications (specific products) are derived from the reuse of artifacts created in the domain engineering. The test activity is also fundamental and aims to detect defects in the artifacts produced in SPL development. However, the characteristics of an SPL bring new challenges to this activity that must be considered. Several approaches have been recently proposed for the testing process of product lines, but they have been shown limited and have only provided general guidelines. In addition, there is also a lack of tools to support the variability management and customization of automated case tests for SPLs. In this context, this dissertation has the goal of proposing a systematic approach to software product line testing. The approach offers: (i) automated SPL test strategies to be applied in the domain and application engineering, (ii) explicit guidelines to support the implementation and reuse of automated test cases at the unit, integration and system levels in domain and application engineering; and (iii) tooling support for automating the variability management and customization of test cases. The approach is evaluated through its application in a software product line for web systems. The results of this work have shown that the proposed approach can help the developers to deal with the challenges imposed by the characteristics of SPLs during the testing process.
Sumário
1 Introdução ... 13
1.1 Problema ... 14
1.2 Limitações das Abordagens Atuais ... 15
1.3 Trabalho Proposto ... 15
1.4 Objetivos ... 16
1.5 Organização do Texto ... 17
2 Fundamentação Teórica ... 18
2.1 Linhas de Produto de Software ... 18
2.2 Desenvolvimento de Software Orientado a Aspectos ... 22
2.2.1 Programação Orientada a Aspectos ... 22
2.2.2 Orientação a Aspectos em LPS ... 23
2.3 Testes de Software ... 24
2.3.1 Abordagens de Teste ... 24
2.3.2 Estágios de Teste ... 25
2.3.3 Tipos de Teste de Sistema ... 26
2.4 Testes de Linhas de Produto de Software ... 27
2.5 Ferramentas de Derivação ... 29
2.5.1 Gears ... 29
2.5.2 pure::variants ... 30
2.5.3 Ferramenta GenArch ... 31
2.5.3.1 Visão Geral de Funcionamento ... 32
2.6 Sumário ... 34
3 Uma Abordagem para Implementação, Gerência e Customização de Testes de Linhas de Produto de Software ... 36
3.1 Visão Geral da Abordagem ... 36
3.1.1 Escolher Estratégias de Teste para a LPS ... 39
3.1.2 Diretrizes para Implementação dos Testes ... 43
3.1.2.1 Testes de Unidade do Núcleo ... 43
3.1.2.2 Testes de Integração do Núcleo ... 46
3.1.2.3 Testes de Sistema do Núcleo ... 47
3.1.2.5 Testes de Sistema de Produtos ... 50
3.1.3 Gerência Automática de Variabilidades em Artefatos de Teste ... 51
3.1.3.1 Anotar Artefatos de Teste ... 51
3.1.3.2 Configurar Templates de Teste ... 52
3.1.3.3 Gerenciamento e Derivação Automática de Testes ... 53
3.2 Sumário ... 54
4 Ferramenta para Derivação de Casos de Teste de LPS... 55
4.1 Adaptações na Ferramenta GenArch ... 55
4.2 Detalhamento das Adaptações ... 55
4.3 Projeto Detalhado ... 59
4.4 Algoritmo de Derivação ... 61
4.5 Sumário ... 63
5 Abordagem em Ação ... 64
5.1 Estudo de Caso: LPS E-Commerce ... 64
5.1.1 Características Comuns e Variáveis ... 65
5.1.2 Arquitetura da LPS ... 66
5.1.3 Implementação de Variações ... 67
5.2 Aplicação da abordagem de teste na LPS E-Commerce... 73
5.2.1 Passo 1: Escolha de Estratégias de Teste para a LPS ... 74
5.2.2 Passo 2: Implementação dos Testes ... 74
5.2.2.1 Testes de Unidade do Núcleo ... 75
5.2.2.2 Testes de Unidade do Núcleo com Mock Objects ... 80
5.2.2.3 Teste de Integração do Núcleo ... 85
5.2.2.4 Testes de Sistema do Núcleo ... 89
5.2.2.5 Testes de Unidade e Integração de Produtos ... 93
5.2.2.6 Testes de Sistema de Produtos ... 97
5.2.3 Passo 3: Anotar Artefatos de Teste ... 98
5.2.4 Passo 4: Geração dos Modelos do GenArch ... 100
5.2.5 Passo 5: Derivação de Produtos da LPS ... 104
5.3 Sumário ... 111
6 Trabalhos Relacionados ... 113
6.2 Estratégias Genéricas de Teste para LPS ... 114
6.3 Metodologia de Teste de LPS Baseada em Requisitos Expressos como Casos de Uso ... 116
6.4 Processo de Teste para LPS ... 117
7 Conclusão e Trabalhos Futuros ... 119
7.1 Contribuições ... 120
7.2 Trabalhos Futuros ... 121
Lista de Figuras
Figura 1 - Atividades principais de uma linha de produto. Adaptado de (SEI, 2010). 20 Figura 2 - Processo de derivação simplificado de uma LPS. Adaptado de (Krueger,
2006). ... 21
Figura 3 - Modelo V para testes de software. ... 25
Figura 4 - Funcionamento do GenArch. Adaptado de (Cirilo et al. 2007). ... 33
Figura 5 - Visão geral da abordagem. ... 37
Figura 6 - Testes de unidade sem mocks. ... 44
Figura 7 - Testes de Unidade com mock. ... 45
Figura 8 - Testes de integração do núcleo. ... 47
Figura 9 - Uso de Template de teste com código comum. ... 48
Figura 10 - Uso de template de teste com código comum e variável. ... 49
Figura 11 - Arquitetura do GenArch. Adaptado de (Cirilo, 2008). ... 57
Figura 12 - Meta-modelo do modelo de arquitetura. ... 58
Figura 13 - Meta-modelo do modelo de configuração. ... 59
Figura 14 - Classes principais na geração do modelo de Arquitetura. ... 60
Figura 15 - Classes principais na geração do modelo de Configuração. ... 61
Figura 16 - Modelo de Característica da LPS E-Commerce. ... 65
Figura 17 - Arquitetura MVC da LPS. ... 66
Figura 18 - Modelo de Configuração do GenArch. ... 69
Figura 19 - dynamicContent.jsp.xpt. ... 69
Figura 20 - Fragmento WelcomeMessageFragment. ... 70
Figura 21 - Característica Demographics. ... 70
Figura 22 - Classe Demografico.java. ... 70
Figura 23 - Arquivo DemograficoIdade.aj. ... 71
Figura 24 - Características de Catalog. ... 71
Figura 25 - Característica ContentApproval. ... 72
Figura 26 - Padrão Strategy na LPS. ... 73
Figura 27 - Aspecto AutorizacaoNecessariaAspect. ... 73
Figura 28 - Classes envolvidas nos testes de GenericDAOImpl. ... 75
Figura 29 - Classe GenericDAOImplTest. ... 76
Figura 30 - método setUp() de GenericDAOImplTest. ... 77
Figura 32 - método testFindByPrimaryKey(). ... 78
Figura 33 - método testFindAll_Class(). ... 78
Figura 34 - método testFindAllAtivos(). ... 78
Figura 35 - método testSave(). ... 79
Figura 36 - Classe DaoSuite. ... 80
Figura 37 - Classes envolvidas nos testes de ContextProdutoSBean. ... 81
Figura 38 - Classe ContextProdutoSBeanTest... 81
Figura 39 - setUp() e tearDown() de ContextProdutoBeanTest. ... 82
Figura 40 - método testCadastrar(). ... 83
Figura 41 - método testAutorizar(). ... 84
Figura 42 - método testCancelar(). ... 84
Figura 43 - Classe TestSuiteSBeans. ... 85
Figura 44 - Classes envolvidas nos testes de ProdutoMBean. ... 86
Figura 45 - Classe ProdutoMBeanTest. ... 87
Figura 46 - setUp() e tearDown() de ProdutoMBeanTest. ... 87
Figura 47 - método testFinalizarCadastroProduto(). ... 88
Figura 48 - Template TesteCadastroTipoProduto.xpt. ... 90
Figura 49 - Template TesteCadastroProduto.xpt. ... 92
Figura 50 - (a) Template ProdutoMBeanProductTest.java.xpt. ... 94
Figura 51 - (b) Template ProdutoMBeanProductTest.java.xpt. ... 95
Figura 52 - (c) Template ProdutoMBeanProductTest.java.xpt... 96
Figura 53 - Script de teste de sistema para um produto da LPS. ... 97
Figura 54 - GenericDAOImplTest anotada. ... 98
Figura 55 - ContextProdutoSBeanTest anotada. ... 99
Figura 56 - ProdutoMBeanTest anotada. ... 99
Figura 57 - Operação Create Models do GenArch. ... 101
Figura 58 - LPS E-Commerce com modelos do GenArch. ... 102
Figura 59 - Modelo de arquitetura e propriedades de classe de teste. ... 103
Figura 60 - Demonstração de relacionamento entre teste e característica. ... 104
Figura 61 - Operação Derivate Core Tests da extensão do GenArch. ... 105
Figura 62 - Assistente de derivação dos testes do núcleo. ... 106
Figura 63 - Testes de unidade em projeto de produto. ... 107
Figura 64 - Script de teste para o Selenium IDE. ... 108
Lista de Tabelas
Tabela 1 – Estratégias concretas de teste para Linhas de Produto. ... 40 Tabela 2 - Anotação @Test e seus atributos. ... 52
1 Introdução
Linhas de Produto de Software (LPS) (Clements e Northrop, 2001), (Weiss e
Lai, 1999), (Pohl et al., 2005), (Parnas, 1976) podem ser vistas como famílias de sistemas relacionados que compartilham um conjunto de características comuns como também suas especificidades, e que são voltadas para um mercado ou missão específica. A adoção de técnicas de linhas de produto no processo de desenvolvimento possibilita a criação de artefatos reutilizáveis como componentes, arquitetura, especificação de requisitos, casos de teste ou modelos, os quais são genéricos o suficiente para garantir a criação de sistemas que façam parte da família definida pela linha de produto. Dentro do contexto de abordagens de desenvolvimento de LPSs, além das características comuns, são também identificadas, modeladas e implementadas as características variáveis que podem existir entre os membros da linha, ou seja, as características que distinguem um produto do outro. Como conseqüência, uma série de benefícios podem ser obtidos, tais como: redução no tempo total de desenvolvimento e entrega de aplicações, maior controle de complexidade e aumento da qualidade dos produtos derivados da linha de produto.
Assim como pode ser observado no desenvolvimento de sistemas tradicionais, o uso de técnicas de teste de software numa linha de produto também
apresenta um papel fundamental, uma vez que busca melhorar a qualidade do
software produzido, através da busca de erros e detecção de inconsistências
(Kauppinen, 2003), (Pohl e Metzger, 2006), (Reuys et al., 2006). Com uma abordagem eficaz de testes pode-se reduzir os esforços, aumentar a qualidade do produto, alcançar os critérios de satisfação do cliente e diminuir os custos de manutenção (Juristo e Moreno, 2006).
No contexto de linhas de produto de software (Clements e Northrop, 2001),
considerados como, por exemplo: (i) a escolha adequada dos artefatos que devem ser testados na engenharia de domínio e os que precisam ser testados na engenharia de aplicação; (ii) a definição apropriada das estratégias de teste que serão utilizadas em cada fase da linha; e (iii) a melhor forma de lidar com as variabilidades nos artefatos de teste da LPS.
Esta dissertação se insere no contexto de testes de linhas de produto de
software, buscando trazer mais qualidade para os artefatos desenvolvidos para uma
LPS. Ela busca oferecer mais sistemática para a implementação de estratégias de teste tanto na engenharia de domínio como na de aplicação. As estratégias definem claramente quais artefatos da linha podem ser testados e como testá-los durante o processo de teste da LPS.
1.1 Problema
No processo de teste, muitos artefatos podem ser produzidos e requeridos nas etapas de planejamento, projeto, implementação, monitoramento e execução dos testes, tais como, cenários de teste, dados de teste e resultados de teste. O gerenciamento desses artefatos não é uma tarefa simples e se não for realizada de maneira adequada compromete os testes, deixando-os desatualizados ou mesmo incompletos e inapropriados (Pressman, 2002), (Sommerville, 2003). No contexto de testes de linhas de produto de software (Bertolino e Gnesi, 2003), (Kolb, 2003), (Pohl
e Metzger, 2006), (Pohl et al., 2005), (Tevanlinna et al., 2004), (Kolb e Muthig, 2006), (Kishi e Noda, 2006), recentemente diversas estratégias para implementar testes de
software foram propostas. Tais estratégias apresentam diretrizes gerais para a
realização de testes, tais como, motivar o teste do núcleo da arquitetura da LPS ou apenas dos produtos da LPS. Além disso, alguns trabalhos também ressaltam que parte dos testes elaborados durante a engenharia de domínio podem também ser reusados durante a engenharia de aplicação.
número de ferramentas que auxiliam em tal atividade, evidenciando a necessidade de mais trabalhos que explorem concretamente meios de ajudar o processo de teste de LPSs. No que se refere a ferramentas que ajudem na implementação e derivação de artefatos de código para produtos de uma LPS, existem, por exemplo, o Gears (Gears, 2010), pure::variants (pure::variants, 2010) e o GenArch (Cirilo, 2008). Contudo, essas ferramentas, apesar de serem muito úteis no desenvolvimento de linhas de produto, tais ferramentas não têm sido exploradas no contexto de suporte ao gerenciamento e customização de testes.
1.2 Limitações das Abordagens Atuais
Diversos trabalhos de pesquisa têm sido propostos nos últimos anos visando oferecer mais sistemática ao processo de teste de LPS. (Tevanlinna et al., 2004) propõem o uso de estratégias genéricas de teste que podem ser aplicadas a qualquer linha de produto, uma vez que independem do contexto específico de cada LPS. (Kolb e Muthig, 2006) ressaltam a necessidade de projetar arquiteturas de LPS visando testabilidade. (Bertolino e Gnesi, 2003) propõem uma metodologia para ajudar no planejamento e gerência do processo de teste de LPS baseada em requisitos expressos por casos de uso. (Kolb, 2003) propõe a melhoria das atividades relacionadas a testes de LPSs com base na identificação e priorização de riscos. (Kishi e Noda, 2006) apresentam um modelo de verificação que pode ser usado durante o projeto da linha de produto. Apesar da importância e do avanço proposto por tais trabalhos de pesquisa, existe uma forte carência na existência de trabalhos que oferecem diretrizes explícitas e concretas para implementação de estratégias de teste de LPS, assim como para o reuso, gerência e derivação de artefatos de teste automatizado produzidos durante a engenharia de domínio ou aplicação.
1.3 Trabalho Proposto
Este trabalho propõe uma abordagem para implementação, gerência e
derivação de testes automatizados para linhas de produto de software (Mariano et
dos testes automatizados na engenharia de domínio para os testes do núcleo da arquitetura e na engenharia de aplicação para testes dos produtos; e (iii) gerência e derivação automática de variabilidades em artefatos de teste através do uso de uma extensão de uma ferramenta de derivação de produtos que é usada também para permitir que testes dos elementos de implementação sejam organizados e automaticamente derivados, como também reaproveitar os testes aplicados no núcleo da LPS nos testes dos produtos específicos. É necessário destacar que os testes da LPS são implementados manualmente e que o processo de derivação automática se refere a possibilidade de selecionar e customizar pequenos trechos de tais testes por meio do suporte ferramental adotado no trabalho. No final desse processo, existe também o código referente aos produtos da linha. Portanto, a derivação no contexto da abordagem se caracteriza como a carga dos artefatos de implementação específicos da LPS, assim como das classes e scripts de teste
automatizados que, por sua vez, são implementados previamente.
1.4 Objetivos
A dissertação tem como objetivo principal propor uma abordagem sistemática para a implementação, gerência e derivação de testes automatizados de linhas de produto de software. Além disso, o trabalho apresenta os seguintes objetivos
específicos:
Investigar trabalhos na área de teste de linhas de produto de software;
Propor diretrizes concretas para a implementação de estratégias de teste para LPS tanto na engenharia de domínio quanto na engenharia de aplicação; Propor mecanismos para a gerência e derivação automática de testes de
software e implementar tais mecanismos em uma ferramenta de derivação de
produtos;
Aplicar e avaliar a abordagem proposta através da sua aplicação para uma LPS no domínio de sistemas web;
1.5 Organização do Texto
Além deste capitulo introdutório, a dissertação apresenta mais seis capítulos. O Capítulo 2 destaca: (i) conceitos da área de linhas de produto de software, os
benefícios da abordagem de LPS e suas respectivas etapas de desenvolvimento; (ii) desenvolvimento de software orientado a aspectos (DSOA), programação orientada
a aspectos (POA) e o uso de orientação a aspectos no contexto de LPS; (iii) conceitos básicos sobre testes de software; (iv) testes para linhas de produto de software; e (v) ferramentas de derivação de LPS. No Capítulo 3 é apresentado a
abordagem de implementação, gerência e derivação de artefatos de teste de uma LPS. No Capítulo 4 é detalhado as adaptações realizadas na ferramenta GenArch para auxiliar a abordagem de teste de LPS proposta no trabalho. No Capítulo 5 é detalhada a arquitetura, as características comuns e variáveis, e mecanismos de implementação de variabilidades que foram adotados numa LPS de sistemas web no domínio de Comércio Eletrônico (E-Commerce), assim como é ilustrada a aplicação
2 Fundamentação Teórica
Este capítulo apresenta uma visão geral da área de Linhas de Produto de
Software (LPS) que tem demonstrado ser uma estratégia de grande auxílio para
análise e gerência de características comuns e variáveis de famílias de sistemas, bem como permitir a geração de produtos por meio do reuso de artefatos de
software (Seção 2.1). Em seguida, são também introduzidos conceitos e técnicas de
Desenvolvimento de Software Orientado a Aspectos (Seção 2.2), testes de software
(Seção 2.3) e testes no contexto de linhas de produto (Seção 2.4). Finalmente, o capítulo é encerrado com a apresentação de ferramentas que lidam com o processo de derivação de produtos (instâncias de uma LPS), tais como, Gears, pure::variants e GenArch (Seção 2.5).
2.1 Linhas de Produto de
Software
Linhas de Produto de Software (LPS) (Clements e Northrop, 2001), (Weiss e
Lai, 1999), (Pohl et al., 2005), (Parnas, 1976) podem ser vistas como famílias de sistemas relacionados que compartilham um conjunto de características em comum, mas também suas especificidades, e que são voltadas para um mercado ou missão específica.
Com a adoção de linha de produto no processo de desenvolvimento é possível a criação de artefatos reutilizáveis como componentes, arquitetura, especificação de requisitos, casos de teste ou modelos, os quais são genéricos o suficiente para garantir a criação de sistemas que façam parte da família definida pela linha de produto. Além disso, é importante ressaltar que dentro do contexto de abordagens de desenvolvimento de LPSs não são apenas identificadas, modeladas e implementadas as características comuns, mas elas também permitem construir artefatos ligados a características variáveis que possam existir entre os membros da linha, ou seja, as características que distinguem um produto do outro.
Uma característica (feature) é uma propriedade ou funcionalidade relevante
de uma linha de produto de software (Czarnecki e Helsen, 2006) e que pode ser
características alternativas são funcionalidades mutuamente exclusivas, ou seja, existindo um grupo de características alternativas, apenas uma pode estar presente no produto final. Por fim, as características opcionais são as funcionalidades que podem ou não estar presentes num produto gerado a partir da LPS.
A abordagem de linhas de produto de software garante também alcançar
benefícios como (Pohl et al., 2005):
Redução nos custos envolvidos no desenvolvimento, pois existe a criação de artefatos reutilizáveis, os quais podem ser usados em vários tipos de produtos da LPS, ou seja, quando um produto necessita de uma funcionalidade e ela já se encontra implementada por um artefato reusável como um componente, basta apenas reaproveitá-lo, não precisando criar um novo componente. Melhoria na qualidade, uma vez que são utilizados artefatos de software que
foram revisados e testados em vários produtos criados anteriormente pela linha. Existe a preocupação de fazer a liberação desses artefatos para uso em novos produtos somente quando apresentam um nível de qualidade adequado, evitando que problemas sejam propagados para futuros produtos gerados pela LPS;
Redução no tempo de comercialização de um produto de software. No início o
tempo é alto, pois é necessário desenvolver a base de elementos comuns para a LPS a partir do zero. Contudo, depois que esses artefatos estão prontos é preciso simplesmente reusá-los para gerar os membros da linha de produto;
Redução no esforço de manutenção. Uma demonstração disso é vista quando ocorre a mudança de um artefato núcleo da arquitetura da linha para, por exemplo, corrigir problemas ou atender melhor os requisitos levantados na LPS. Essas alterações também são propagadas para os demais produtos que usam o mesmo artefato, facilitando a manutenção. Além disso, os procedimentos de teste que inevitavelmente são usados quando mudanças são aplicadas nos artefatos também podem ser reusados, sendo outra maneira para diminuir os esforços de manutenção.
Melhora o gerenciamento da complexidade. Com uma linha de produto bem projetada é possível saber com precisão quais artefatos poderão ser reusados pelos produtos da família, bem como o local exato que esses artefatos podem ser utilizados.
Com relação ao desenvolvimento de uma linha de produto de software,
normalmente existem três atividades principais (SEI, 2010), (Czarnecki, 1998): Engenharia de Domínio, Engenharia de Aplicação e Gerenciamento da LPS. A Figura 1 apresenta uma visão geral dessas atividades.
Figura 1 - Atividades principais de uma linha de produto. Adaptado de (SEI, 2010)
A engenharia de domínio, também conhecida como desenvolvimento da linha de produto ou desenvolvimento de ativos núcleo (core assets), se caracteriza como
um processo que visa promover o reuso, ou seja, tem como objetivo a criação de artefatos reusáveis para os produtos da linha como componentes, arquitetura, linguagens específica de domínio, casos de teste, modelos de projeto e análise, documentações, etc. Nessa fase, é encontrado o uso de atividades de análise, projeto (design) e implementação. Na análise de domínio, é realizado o trabalho de
projeto é definida uma estratégia de como os produtos finais podem ser montados a partir dos artefatos reusáveis. Por fim, a implementação de domínio, como o próprio nome sugere, tem a finalidade de implementar os artefatos reusáveis como componentes, arquitetura e casos de teste.
A engenharia de aplicação, também caracterizada como a fase de desenvolvimento do produto, tem o foco na construção dos sistemas da família com o reuso dos artefatos elaborados na engenharia de domínio. Durante a construção de um produto, também conhecido como derivação (Sybren et al., 2005), o engenheiro de aplicação é responsável por definir uma configuração base, ou seja, selecionar as características para um determinado produto tendo como referência os requisitos que esse produto precisará atender. A Figura 2 ilustra um processo de derivação simplificado de uma LPS.
Figura 2 - Processo de derivação simplificado de uma LPS. Adaptado de (Krueger, 2006).
Como pode ser observado na Figura 2, no processo de derivação existe a presença dos ativos núcleo, isto é, os artefatos reusáveis produzidos na LPS; a definição de configurações que refletem as características que cada produto deverá apresentar e, por fim, os produtos gerados, os quais são compostos pelos artefatos que implementam as características especificadas nas configurações.
unidades organizacionais. As atividades de nível técnico e as iterações durante o ciclo de elaboração dos artefatos núcleo e dos produtos derivados também são gerenciadas. No gerenciamento técnico, existe o trabalho de supervisionar o desenvolvimento das pessoas responsáveis pelos ativos núcleo e dos produtos específicos. Para isso, são coletadas informações que apontem se as atividades e processos definidos estão seguindo padrões técnicos apropriados.
2.2 Desenvolvimento de
Software
Orientado a Aspectos
O Desenvolvimento de Software Orientado a Aspectos (DSOA) (Filman et al.,
2005) (Kiczales, 1997) é uma abordagem de engenharia de software que aplica a
Orientação a Aspectos (OA) ao processo de desenvolvimento de sistemas de
software e oferece mecanismos para a separação clara das funcionalidades básicas,
as quais podem ser tratadas com as abordagens tradicionais não orientadas a aspectos, dos chamados conceitos ou interesses transversais (crosscutting
concerns). Os conceitos transversais se caracterizam por estarem espalhados e
entrelaçados no código da aplicação e que são difíceis de serem modularizados com o uso de técnicas normalmente empregadas no desenvolvimento de software (tais
como, a orientação a objetos) como, por exemplo, logging, integridade de
transações, autenticação, segurança, desempenho, distribuição, persistência e
profiling.
2.2.1 Programação Orientada a Aspectos
A Programação Orientada a Aspectos (POA) (Kiczales, 1997) tem como objetivo modularizar os programas através da separação dos conceitos relacionados na construção dos sistemas de software em dois tipos de abstrações diferentes: os
componentes e os aspectos. Os componentes são elementos que encapsulam os conceitos que podem ser perfeitamente modularizados em construções comuns de linguagens de programação como objetos, métodos e procedimentos. Os aspectos, por sua vez, são as entidades responsáveis por encapsular os conceitos transversais existentes numa aplicação. Além disso, um conceito essencial no contexto de POA é o de weaving que se refere ao processo de composição dos
Existem várias implementações dos conceitos da orientação a aspectos, assim como diversas terminologias e elementos associados a essa área. No presente trabalho, é adotada a terminologia empregada pelo AspectJ (Kiczales et al., 2001), por ser a linguagem que originou a POA e amplamente utilizada em soluções de software. No conjunto de terminologias dessa linguagem, existe a definição de
aspectos como elementos que encapsulam os conceitos transversais e definem join
points, advices e pointcuts. Os join points especificam os pontos da implementação
do sistema que o aspecto pode atuar como, por exemplo, chamadas de funções, leitura e escrita de variáveis, tratamento de exceções e entre outros. Os advices são
usados para indicar o comportamento (ação) que será introduzido quando os join points são atingidos. Em cada advice é possível definir se o comportamento será
executado depois (cláusula after) ou antes (cláusula before) ao momento que o join
point é alcançado, bem como se a ação irá ser executada no lugar do join point
(cláusula around). Por fim, os pointcuts são elementos-chaves que expressam um
conjunto de join points e certas informações do contexto desses join points, como
também são elementos presentes na construção dos advices.
2.2.2 Orientação a Aspectos em LPS
A orientação a aspectos (OA) pode ser aplicada tanto nas fases de implementação como nas etapas de arquitetura e projeto de um sistema, ou seja, OA busca apresentar um caminho completo que direcione as atividades de todo o ciclo de construção de um software. Nessa linha de uso de OA é possível apresentar
os seguintes exemplos: o trabalho de (Araújo et al., 2002) que demonstra a separação de interesses transversais em nível de requisitos e o trabalho de (Garcia et al., 2006) que mostra a aplicação das abstrações de aspectos como meio de capturar decisões arquiteturais e permitir o desenvolvimento de arquiteturas de
software com maior modularidade.
características transversais identificadas no domínio de uma linha de produto. Dessa forma, os aspectos servem para melhorar a separação e composição de características opcionais e de integração de uma arquitetura de LPS. Como resultado, os aspectos podem ser empregados para acoplar ou desacoplar essas características da arquitetura de referência da LPS, simplificando o desenvolvimento arquitetural da linha. Em outras palavras, a aplicação de aspectos em LPS pode ser empregada para modularizar as características transversais, bem como permitir a separação de um novo conjunto dessas características sem a necessidade de um projeto inicial extenso, garantindo que a linha de produto seja desenvolvida de forma incremental e a partir de ciclos iterativos, visando promover flexibilidade e adaptabilidade dos seus produtos.
2.3 Testes de
Software
No ano de 1972, Dijkstra afirmou que “os testes de programas podem ser usados para mostrar a presença de falhas, mas nunca a sua ausência“ (Dijkstra,
1972). Dessa forma, fica claro que os testadores precisam ter em mente o desenvolvimento de testes que evidenciem problemas associados à implementação de um software. Além disso, com uma abordagem eficaz de teste pode-se reduzir os
esforços, aumentar a qualidade do sistema, alcançar os critérios de satisfação do cliente e diminuição dos custos de manutenção (Juristo e Moreno, 2006).
Normalmente os testes são usados de duas formas para se alcançar os seus benefícios (Beizer, 1990). Na primeira os testes são empregados para ajudar a equipe de desenvolvimento a encontrar inconsistências nas aplicações durante a fase de construção. Com esses problemas descobertos, medidas reparadoras são implementadas e aplicadas no software. Na segunda, os testes são usados para
certificar se a aplicação realiza as suas funções de maneira adequada, ou seja, os testes são uma alternativa para mostrar se o sistema opera de acordo com os requisitos que deve atender.
2.3.1 Abordagens de Teste
contexto, existem duas abordagens de teste principais: caixa preta e caixa branca. Na primeira o sistema sob teste é visto como uma caixa preta. Os testes são construídos desconsiderando o comportamento interno e estrutura da aplicação. O objetivo dos testes está centrado em encontrar problemas relacionados ao comportamento definido nas especificações do programa. Para isso, são empregados dados de entrada e comparações entre os resultados alcançados nos testes e os resultados esperados. Na segunda, os testadores precisam conhecer a estrutura interna do programa, uma vez que são exercitados os caminhos lógicos da aplicação (Myers, 2004).
2.3.2 Estágios de Teste
Os testes de uma aplicação precisam de um planejamento cuidadoso e de um processo que determine com precisão as atividades necessárias para o desenvolvimento adequado dos testes (McGregor, 2001a). Tradicionalmente os testes de software são guiados através do modelo V de testes (Fewster e Graham,
1999), o qual é apresentado na Figura 3 a seguir.
Figura 3 - Modelo V para testes de software.
Nos testes de unidade é visto se componentes individuas como classes e métodos funcionam adequadamente. Nos testes de integração, os módulos do software são
reunidos e testados em grupo. Com o uso desses testes é possível encontrar problemas ligados as interfaces dos módulos da aplicação. Nos de sistema é avaliado o comportamento do software num ambiente semelhante ao de uso real,
verificando se a aplicação atende as características funcionais definidas na sua especificação. Por fim, no teste de aceitação o sistema é analisado pelos usuários finais, buscando saber se o software atende de maneira apropriada aos requisitos
apresentados por eles. A abordagem de teste de LPS proposta nesta dissertação focaliza os estágios de teste de unidade, integração e sistema, conforme será detalhado no Capítulo 3.
2.3.3 Tipos de Teste de Sistema
Como observado na Seção 2.3.2 anterior, os testes de sistema visam analisar se o comportamento da aplicação está de acordo com as suas especificações. Além desses testes com propósitos gerais, existem tipos de teste de sistema, os quais apresentam objetivos específicos para verificar e validar as características de um programa de software. No grupo dos tipos de teste, são destacados no presente
documento os testes de função, volume (conhecido também como teste de carga),
stress, usabilidade, segurança, desempenho e recuperação a falhas (Myers, 2004),
(Mcgregor e Sykes, 2001). A descrição dos tipos de teste é encontrada a seguir: Testes funcionais (ou de função): usado para saber se as funções gerais
(regras de negócio) da aplicação seguem o comportamento esperado. Durantes os testes, condições validadas e inválidas são empregadas para obter os resultados. Esta dissertação de mestrado foca exclusivamente nos testes funcionais por questão de escopo.
Teste de volume: nesse tipo de teste é analisado como a aplicação consegue lidar com grandes quantidades de dados.
Teste de stress: o programa é submetido a condições anormais de utilização.
Nesses testes, podem ser levados em consideração simulações em que o
software é submetido a trabalhos extremos, a memória disponível do sistema
Teste de usabilidade: os testes visam avaliar fatores como formas de navegação, o nível de facilidade de uso e aprendizado da aplicação, elementos de interface disponíveis e aderência a padrões de usabilidade. Teste de segurança: tipo de teste que busca saber se os mecanismos de
acesso ao sistema e aos seus dados estão funcionando adequadamente. Teste de desempenho: são verificados os critérios de desempenho e
eficiência do programa, tais como, tempo de resposta das operações e taxas de transferência em determinadas condições de carga de trabalho e configurações.
Teste de recuperação a falhas: os testes buscam saber a eficiência dos procedimentos de recuperação em casos de falha. Esses casos podem se manifestar quando existem, por exemplo, erros de programação, falhas de hardware e problemas nos dados.
2.4 Testes de Linhas de Produto de
Software
Assim como pode ser observado no desenvolvimento de sistemas tradicionais, os testes de linhas de produto de software apresentam o objetivo de
detectar defeitos nos artefatos produzidos (Pohl e Metzger, 2006). Além disso, técnicas e métodos de teste convencionais se mostram como alternativas válidas para ajudar no processo de teste de LPS (Tevanlinna et al., 2004). Contudo, devido às características peculiares inerentes a uma LPS, os testes de linhas de produto apresentam diferenças, como também problemas e desafios específicos para serem tratados.
de domínio, nessa fase também ocorre o desenvolvimento de artefatos de teste reusáveis como projetos de teste e dados de teste. Na engenharia de aplicação, por sua vez, são realizados testes adicionais visando encontrar problemas em configurações e garantir que as variações especificadas para um produto estão realmente presentes. Nessa fase também é empregado os artefatos de teste reusáveis que foram desenvolvidos na engenharia de domínio, reduzindo os esforços nos testes das aplicações que serão derivadas. Contudo, devido à presença de variabilidades e de arranjos específicos dessas variabilidades num produto, a forma como os testes podem ser reaproveitados se caracteriza como uma tarefa não trivial, pois para cada membro da LPS gerado, precisa existir a seleção de artefatos de testes específicos para serem aplicados (Pohl e Metzger, 2006). Por fim, os critérios de cobertura dos testes devem considerar tanto o reuso de elementos comuns e variáveis como as partes específicas de produtos recém criadas.
2.5 Ferramentas de Derivação
No processo de derivação (Sybren et al., 2005) é recomendado a aplicação de ferramentas que promovam a seleção, agregação e configuração de artefatos que compõem uma linha de produto. Gears (Gears, 2010) e pure::variants (pure::variants, 2010) são exemplos de ferramentas que se inserem nesse contexto. Essas ferramentas se apresentam como alternativas para promover a automatização da geração de produtos durante a engenharia de aplicação com base em configurações e artefatos produzidos durante a engenharia de domínio e que refletem as características associadas a cada membro da LPS. As subseções seguintes apresentam uma descrição geral das ferramentas mencionadas, bem como do GenArch (Cirilo, 2008), ferramenta também desenvolvida para auxiliar a construção de LPSs e derivação de produtos.
2.5.1 Gears
O Gears é uma ferramenta stand-alone formada por três elementos –
infra-estrutura, ambiente de desenvolvimento e configurador – os quais trabalhando em conjunto permitem a derivação de produtos de uma LPS. A infra-estrutura representa os arquivos e diretórios que foram adicionados aos artefatos de software (código
fonte, casos de teste, componentes) que tanto implementam a linha de produto como podem ser reusados pelos membros da LPS. O ambiente de desenvolvimento garante a elaboração, manutenção e organização dos artefatos que fazem parte da linha. O configurador é encarregado pela geração dos produtos. O processo de derivação implementada pela ferramenta é baseada em descrições de alto nível que apresentam as características configuradas para um determinado produto.
mixins e matrizes. Com os mixins é obtido o melhor gerenciamento de
características que se espalham em diversos módulos, uma vez que esse tipo de característica pode ser definida num lugar central e usada pelos módulos que dependem dela. As matrizes se apresentam como a alternativa que o Gears possui para garantir a agregação de módulos que fazem parte de uma LPS. Com as configurações, módulos, mixins e matrizes, o configurador da ferramenta é capaz de
derivar automaticamente os membros da linha de produto.
2.5.2 pure::variants
O pure::variants é uma ferramenta de derivação que usa modelos para descrever os conceitos, características e abstrações que estão ligados ao domínio da LPS em construção, elementos de implementação como arquitetura e componentes e os membros que formam a linha de produto. A ferramenta foi construída como um plug-in da plataforma Eclipse e apresenta também a
capacidade de prover o gerenciamento das características relacionadas à linha durante todo o ciclo de desenvolvimento da LPS.
No processo de derivação de produtos suportado pelo pure::variants são empregados dois tipos de modelos : modelo de características e modelo de família. O modelo de característica descreve as características identificadas na LPS, apresentando as propriedades, relacionamentos e restrições dessas características. O modelo de família representa a estrutura interna dos componentes e a relação de dependência deles com as características. Tal modelo é estruturado em diversos níveis. O nível mais alto é constituído por componentes, os quais representam uma ou mais características funcionais e compreende partes lógicas do software em
puderam ser revertidos. Além disso, o pure::variants fornece uma linguagem baseada em XML, denominada XMLTrans, para especificar as ações que devem ser executadas durante a derivação dos produtos da LPS.
2.5.3 Ferramenta GenArch
O GenArch - Generative Architectures (Cirilo, 2008) é uma ferramenta
baseada em modelos que permite a derivação de membros de uma linha de produto de software e que foi desenvolvida como um plug-in da plataforma Eclipse (Shavor
et al., 2003). Embora outras ferramentas de derivação de produtos como o Gears e o pure::variants apresentem um conjunto de funcionalidades úteis para auxiliar na construção e geração automática de linhas de produto de software, elas se mostram,
em geral, como ferramentas difíceis de serem empregadas pela comunidade tradicional de desenvolvedores que possuem pouca familiaridade com vários dos novos conceitos relacionados à área de LPS. Com base nesse contexto, o GenArch foi construído com o objetivo de simplificar o processo de preparação de LPSs, bem como ajudar na derivação de produtos de uma linha.
A ferramenta GenArch utiliza três modelos para representar os elementos que compõe uma linha de produto, os quais são: modelo de arquitetura, modelo de característica e modelo de configuração. O modelo de arquitetura permite a representação visual das entidades que implementam a LPS como classes, aspectos, templates ou arquivos de configuração. Com a sua criação é possível
relacionar os elementos de implementação da linha com as entidades do modelo de característica. O modelo de característica, como o próprio nome insinua, é empregado para representar as características obrigatórias, alternativas e opcionais da linha de produto. A ferramenta usa como base o modelo de características apresentado por (Czarnecki, 1998), o qual permite definir o relacionamento, restrições, dependência e atributos associados às características identificadas na LPS. Para implementar esse modelo no GenArch foi adotado o plug-in do Eclipse
chamado Feature Modelling Plugin (FMP) (Antkiewicz e Czarnecki, 2004). Por fim, o
poderá automaticamente carregar os elementos de implementação desse produto durante a derivação.
2.5.3.1 Visão Geral de Funcionamento
A ferramenta GenArch para suportar o processo de derivação de um produto necessita da definição dos seus modelos base, ou seja, o modelo de arquitetura, característica e configuração. Os modelos são produzidos através da varredura e identificação de anotações Java especificas (próprias do GenArch) nos elementos de implementação existentes no diretório de um projeto Java usado no desenvolvimento da linha de produto.
A Figura 4 apresenta o funcionamento geral do GenArch. No início é preciso anotar os elementos de implementação (passo 1). A ferramenta suporta dois tipos de anotações: @Feature e @Variability. A primeira é para determinar a relação entre os
elementos de implementação com as características da LPS. Essa anotação também permite especificar o nome da característica, o tipo (obrigatória, opcional ou alternativa) e seu respectivo pai, caso exista. A segunda é para indicar os pontos de extensão (hotspot) existentes. Em LPS, os pontos de extensão representam o que
Figura 4 - Funcionamento do GenArch. Adaptado de (Cirilo et al. 2007).
Em seguida, o módulo de importação do GenArch (passo 2) realiza uma varredura nos elementos de implementação e recupera as anotações do tipo
@Feature para gerar a versão inicial do modelo de arquitetura, característica e
configuração, bem como identifica as anotações do tipo @Variability para criar os templates, os quais são implementados através da linguagem XPand do plug-in
openArchitectureWare (oAW) que fornece uma completa infra-estrutura para o desenvolvimento orientado a modelos (openArchitectureWare, 2010). Os templates
no Genarch são usados tanto para especificar o código que será usado por todos os membros da LPS como código variável customizado de acordo com informações obtidas do modelo de características ou pelo uso de elementos conhecidos como fragmentos que encapsulam trechos de código ou texto, os quais são associados a características da LPS e gerenciados por meio do modelo de configuração. Em outras palavras, os templates auxiliam a determinar o conteúdo fixo e gerenciar a
características encontradas na configuração de dado produto da LPS criado após o processo de derivação.
Depois da criação preliminar dos modelos, eles precisam ser melhorados através de refinamentos e incrementos (passo 3). Nesse momento, existem trabalhos que visam, por exemplo, incluir novas características no modelo de característica, adição ou reestruturação dos elementos do modelo de arquitetura, novas relações entre os elementos de implementação e as características no modelo de configuração ou incremento dos templates com código que representem novas
possibilidades de variações concretas para um produto. Depois a ferramenta GenArch através do módulo de derivação (passo 4) permite a geração dos produtos da LPS. Para criar cada membro da linha, é preciso inicialmente definir uma configuração com base no modelo de característica, ou seja, selecionar um conjunto de característica que irá compor um produto específico. Com a configuração do modelo de característica e com os modelos de arquitetura e configuração, o GenArch é capaz de derivar os produtos. Por fim, para armazenar a implementação referente a cada produto é necessário apenas a construção de projetos Java na plataforma Eclipse (passo 5).
2.6 Sumário
Neste capítulo foi destacada a abordagem de linhas de produto de software
(LPS). Essa abordagem se diferencia do processo de desenvolvimento tradicional de
software, baseado na construção de um único sistema por vez. Ela apresenta duas
fases principais: (i) a engenharia de domínio - quando elementos comuns e variáveis são definidos, modelados e implementados; e (ii) engenharia de aplicação - quando uma ou mais aplicações são geradas a partir do reuso dos artefatos criados na engenharia de domínio.
O capítulo também apresentou conceitos do desenvolvimento de software
orientado a aspectos (DSOA), ressaltando a importância dessa abordagem para a modularização de interesses transversais (crosscutting concerns) de um dado
Outro assunto abordado é o de testes de software, assim como o de
abordagens de teste e estágios de teste (unidade, integração, sistema e aceitação). O processo de teste em linhas de produto foi também abordado. Os testes neste contexto se aplicam aos artefatos produzidos na engenharia de domínio e aos produtos específicos gerados na engenharia de aplicação, ou seja, os testes se manifestam nas duas fases de uma LPS.
3 Uma Abordagem para Implementação, Gerência e
Customização de Testes de Linhas de Produto de
Software
Este capítulo apresenta uma visão da abordagem proposta nesta dissertação, destacando: (i) estratégias para implementação de teste para linhas de produto de
software; (ii) diretrizes para a implementação de estratégias de teste e reutilização
de artefatos de teste durante a engenharia de domínio e aplicação; e (iii) mecanismos para garantir a gerência de variabilidades e customização de artefatos de teste tanto na engenharia de domínio como na engenharia de aplicação de uma LPS.
3.1 Visão Geral da Abordagem
A abordagem proposta nesta dissertação tem como objetivo principal oferecer mais sistematização para o processo de implementação, gerência e customização de testes automatizados para linhas de produto de software. No que se refere à
implementação, a abordagem oferece diretrizes para a implementação de estratégias de teste tanto na engenharia de domínio quanto de aplicação. Com base em tais diretrizes, é possível definir casos de teste automatizados para artefatos de implementação da LPS. Uma vez implementados casos de teste para o núcleo da linha e para as suas variabilidades, a abordagem oferece suporte para automaticamente customizar tais artefatos de teste para contextos específicos, tais como: (i) configurar o núcleo da LPS com seus respectivos casos de teste; ou (ii) derivar um produto da LPS com os seus casos de teste específicos.
A Figura 5 apresenta uma visão geral da abordagem que se baseia na extensão da ferramenta GenArch. A abordagem tem início durante a etapa de implementação de domínio da engenharia de domínio, com a escolha de estratégias de teste e implementação dos testes que consiste no desenvolvimento das classes de teste, assim como a criação e preparação dos templates. Em seguida, as classes
de teste implementadas são anotadas manualmente. Com os testes anotados e os
templates prontos, os modelos da extensão do GenArch podem ser gerados. Com
testes. As subseções seguintes detalham cada passo da abordagem de teste de LPS apresentada na Figura 5.
Figura 5 - Visão geral da abordagem.
(Bertolino e Gnesi, 2003), (Kolb, 2003), (Pohl e Metzger, 2006), (Pohl et al., 2005), (Tevanlinna et al., 2004). O presente trabalho tem o intuito de destacar de forma clara como os testes se manifestam nas fases de uma linha de produto. Para alcançar essa finalidade são propostas estratégias efetivas de teste, as quais são: (i) testes de unidade do núcleo, (ii) teste de integração do núcleo, (iii) teste de sistema
do núcleo, (iv) teste de unidade e integração de produtos e (v) teste de sistema de produtos.
Uma vez definida as estratégias de teste, o passo seguinte é implementar os testes da linha de produto. Nesse momento, os testes de unidade propostos para o núcleo são implementados com o apoio de frameworks, tais como, o JUnit. Mock Objects1 (Freeman et al., 2004), (Mackinnon et al., 2000) são empregados com o
objetivo de simular instâncias de objetos reais da LPS. Para a construção dos Mock
Objects é adotado o framework jMock (Freeman et al., 2004), (jMock, 2010). No
núcleo da LPS, testes de integração também são usados com o objetivo de avaliar a interação e integração entre objetos do núcleo. Na elaboração de tais testes tanto o JUnit como os Mock Objects são novamente usados. Para os testes de sistema do
núcleo são implementados templates, os quais servirão para criar scripts de teste de
sistema para uma ferramenta chamada Selenium IDE (Selenium, 2010). Para um
produto derivado, testes de unidade e integração aplicados ao núcleo são reusados, mas sem a presença de Mock Objects. Para os testes de integração, são usados
templates para tratar a entrada ou não de código de teste para as partes variáveis
dos produtos. Os testes de unidade, por sua vez, também podem ser criados, visando testar especificamente as classes referentes às variantes da LPS. Além disso, testes de sistema são empregados nos membros da LPS por meio de scripts
gerados com base nos templates.
Na nossa abordagem, conforme descrito anteriormente, são adotados
frameworks que permitem a automação de casos de teste, bem como a aplicação de templates para ajudar na definição de casos ou scripts de teste que poderão ser
customizados. Embora esses recursos auxiliem nos testes automatizados da LPS, é importante ressaltar que a atividade de implementação é realizada de forma manual, ou seja, requer a codificação de classes de teste e criação do código referente aos
templates.
Com os artefatos de teste implementados, o próximo passo é anotar os testes da LPS. No caso específico da nossa abordagem, é usada a ferramenta GenArch com tal propósito. A anotação @Feature da ferramenta é usada para relacionar
features a testes e como trabalho futuro usar @Variability para indicar classes e
interfaces que necessitam usar Mock Objects. Além dessas anotações existentes no
GenArch, é proposto o uso de uma nova anotação @Test para a ferramenta. Essa
anotação, por sua vez, indica se o artefato de teste é para o núcleo ou para um produto derivado, o tipo e o estágio de teste.
Em seguida, quando as classes de teste se encontram implementadas e devidamente anotadas, assim como os templates prontos, é iniciada a geração de
modelos da extensão do GenArch. Depois dessa geração, além das informações típicas dos modelos da ferramenta, os artefatos de teste são representados no modelo de arquitetura e no modelo de configuração. Por fim, é colocada em prática a derivação dos membros da LPS. Nessa etapa, os modelos são processados e os produtos, bem como seus testes automatizados são instanciados e customizados automaticamente. A extensão do GenArch proposta neste trabalho é responsável pela customização dos scripts e casos de teste automatizados. Essa extensão
também garante a possibilidade de escolha dos testes que serão derivados, ou seja, definir se serão configurados, por exemplo, apenas os testes de unidade para um produto ou se também os testes de integração e sistema serão carregados para esse membro da LPS.
3.1.1 Escolher Estratégias de Teste para a LPS
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
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.
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
