PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
SPLIT-TESGE - UM PROCESSO
PARA ADAPTAÇÃO DE
MÉTODOS DE GERAÇÃO DE
SEQUÊNCIAS DE TESTES
PARA LINHA DE PRODUTO
DE SOFTWARE
ALINE ZANIN
Dissertação apresentada como requisito parcial à obtenção do grau de Mestre em Ciência da Computação na Pontifícia Universidade Católica do Rio Grande do Sul.
Orientador: Prof. Avelino Francisco Zorzo
Dados Internacionais de Catalogação na Publicação (CIP)
Z31s Zanin, Aline
SPLiT-TeSGe : um processo para adaptação de métodos de geração de sequências de testes para linha de produto de software / Aline Zanin. – Porto Alegre, 2015.
103 p.
Diss (Mestrado) – Faculdade de Informática, PUCRS. Orientador: Prof. Dr. Avelino Francisco Zorzo.
1. Informática. 2. Engenharia de Software. 3. Software – Análise de Desempenho. 4. Testes de Software. I. Zorzo, Avelino Francisco. II. Título.
CDD 005.1
Ficha Catalográfica elaborada pelo
que precisa para enfrentar qualquer desafio que possa surgir, então, um passo por vez, um dia de cada vez, você verá com orgulho que a gente faz o impossível, um dia de cada vez.”
“Um sonho que se sonha só, é só um sonho, mas sonho que se sonha junto é realidade”. Diversos são os responsáveis pela conclusão deste curso de mestrado e concretização de um grande objetivo que ousei sonhar.
Gostaria de agradecer primeiramente ao meu orientador, professor Dr. Avelino Francisco Zorzo, por acreditar, incentivar e acompanhar meu trabalho, bem como pelos feedbacks negativos que impulsionaram meu desenvolvimento e pelas palavras amigas que propiciaram autoconfiança no decorrer do curso.
Aos colegas do Centro de Pesquisa em Engenharia de Software (CePEs): Flávio Moreira de Oliveira, Élder de Macedo Rodrigues, Maicon Bernardino, Edemar Mezacasa, Edio S. da Silva, Juliana Damásio, Marina Barros, Mauricio L. de Oliveira agradeço pelo companheirismo e trabalho. De forma especial ao amigo e colega Leandro Teodoro Costa, pela compreensão, paciência, pelo apoio, troca de conhecimento e palavras de incentivo recebidas.
Aos amigos Adelano, Diogo e Caroline que conviveram comigo dividindo apartamento agradeço pela paciência, pelo companheirismo e pelas madrugadas de estudo. De forma especial agradeço a Caroline pelas conversas, os conselhos os bons exemplos e a oportunidade de imersão cultural em um curso intensivo de “mineres”.
A Daniele que durante estes dois anos de mestrado tornou-se mais que uma amiga, uma companheira para todos os momentos. Aquela que sempre teve uma palavra de carinho e conforto nos piores dias, que esteve ao meu lado comemorando os momentos mais felizes e foi responsável pelos poucos momentos de vida social durante o curso.
As amigas Alessandra e Maria Luiza as quais eu poderia escrever uma dissertação toda apenas descrevendo os motivos para agradecê-las. Meu sincero muito obrigada por todos os mo-mentos vividos, pelo carinho, pelas conversas e principalmente pelo incentivo desde o primeiro dia em que ousei sonhar com o título de mestre. A Viviane, que embora não seja a melhor quando o assunto é motivação, sempre esteve disponível para sanar dúvidas, orientar e tornou-se um exemplo de sucesso conquistado com trabalho. A minha grande amiga Luciana, por sua vez, agradeço por torcer pelo meu sucesso, vibrar com as minhas conquistas, me dar um exemplo real de que amizade verdadeira a distância física não separa, e por ser um exemplo vivo de dedicação trabalho e batalha por sonhos.
À aqueles que sem dúvidas formam o mais forte dos pilares da minha vida, os meus familiares: Pai, Mãe e Angela, muito obrigado por perdoarem a ausência, entenderem a saudade, darem força, coragem e nunca desistirem de mim. Tadeu muito obrigado pelas conversas, conselhos, caronas e por ser meu espelho de trabalho e dedicação. Ao tio Hilário por todo apoio, carinho e pelas orações que certamente fizeste por mim. A minha “nona” Angelina “in memoriam” que eu tenho certeza que de onde estiver está sempre olhando por mim.
DE GERAÇÃO DE SEQUÊNCIAS DE TESTES PARA LINHA DE
PRODUTO DE SOFTWARE
RESUMO
O desenvolvimento de software em linha de produto tem ganhado notoriedade por ser um aliado a projetos que buscam aumentar a produtividade através do reuso de artefatos. Este reaproveitamento, já utilizado no processo de desenvolvimento, recentemente passou a ser adotado também no processo de testes de software, visto que, a etapa de testes é considerada uma das etapas mais onerosas do processo de desenvolvimento. Neste trabalho buscamos propor um processo para a adaptação de métodos de geração de sequências de testes, tradicionalmente utilizados em sistemas únicos, para a utilização em Linha de Produto de Software. Este processo chama-se Software Product Line Testing using Test Sequence Generation Method (SPLiT-TSGe). Com isso, visamos reutilizar os artefatos de teste produzidos na Engenharia de Domínio para os produtos derivados na Engenharia de Aplicação, permitindo assim, reduzir o número de casos de teste necessários para testar produtos derivados de uma Linha de Produto de Software.
SEQUENCE GENERATING METHODS FOR SOFTWARE PRODUCT
LINE
ABSTRACT
The Software Product Line development has gained notoriety for being an ally to projects that seek to increase productivity through reuse of artifacts. This reuse, already used in the de-velopment process, has recently started to be adopted during the software testing phase, which is considered one of the most costly phases of the development process. In this work, we propose a process to adapt methods for generating test sequences, traditionally used in single systems, to be used in Software Product Lines. This process is called Software Product Line Test using Test Sequence Generation Method (SPLiT-TeSGe). The main idea is that test artifacts produced in the Domain Engineering are reused for products derived in the Application Engineering allowing, thus, to reduce the number of test case to test a software derived from a Software Product Line.
1.1 Desenho de Pesquisa . . . 25
1.2 Etapas para Geração de Casos de Teste do Método SPLiT-MBt. . . 28
2.1 Erro, Defeito e Falha - Adaptado de [51] . . . 31
2.2 Atividades de Teste Baseado em Modelos [11] . . . 33
2.3 Representação de FSM com Diagrama de Transição de Estados [9]. . . 34
2.4 Exemplo de Modelo de Características de Linha de Produto de Software [49] . . . 45
2.5 Representação da Estrutura de uma SPL [26]. . . 46
2.6 Modelo de Características SPL AGM [29] . . . 47
3.1 Máquina de Estados Finitos com Ponto de Variação . . . 52
3.2 Máquina de Estados Finitos com Informações de Variabilidade . . . 57
4.1 Diagrama de Casos de Uso da AGM [29] . . . 74
4.2 FSM Play Selected Game . . . 75
4.3 FSM Play Selected Game - Processo SPLiT-TeSGE . . . 76
B.1 FSM Animation Loop . . . 97
B.2 FSM Initialization . . . 97
B.3 FSM Bowling Moves . . . 97
B.4 FSM Brickles Moves . . . 98
B.5 FSM Check Previous Best Score . . . 98
B.6 FSM Exit Game . . . 99
B.7 FSM Pong Moves . . . 99
B.8 FSM Install Game . . . 99
B.9 FSM Save Game . . . 100
2.1 Representação de FSM com Tabela de Transição de Estados. . . 35
2.2 Sequência UIO . . . 37
2.3 Sequência DS . . . 38
2.4 Tabela de Relação de Transitividade dos Pares de Estados da FSM[9]. . . 41
2.5 Identificadores Harmonizados dos Pares de Estados da FSM[9]. . . 42
3.1 HSI State Cover . . . 58
3.2 HSI Transition Cover . . . 59
3.3 HSI Transition Cover Final . . . 59
3.4 HSI Relação de Transitividade por Produto . . . 60
3.5 Identificadores Harmonizados . . . 61
3.6 Sequências de Teste Geradas . . . 61
3.7 Conjunto Wi por Par de Estados da FSM . . . 63
3.8 Conjunto Wi por Estado da FSM . . . 64
3.9 Conjunto W da FSM . . . 70
3.10 Conjuntos P, Q e R . . . 71
3.11 Concat. dos Conj. R e Wi . . . 71
3.12 Concat. Final dos Conj. R e Wi . . . 71
3.13 Sequências UIO por Estado . . . 71
4.1 AGM State Cover . . . 76
4.2 AGM Transition Cover . . . 77
4.3 Número de Sequências por Produto . . . 79
A.1 State Cover Por Produto 1 . . . 91
A.2 State Cover Por Produto 2 . . . 91
A.3 Transition Cover Por Produto 1 . . . 92
A.4 Transition Cover Por Produto 2 . . . 92
A.5 Sequências Wi dos Pares de Estados por Produto . . . 93
A.6 Sequências Wi dos Estados por Produto . . . 93
A.7 Sequências Wi dos Pares de Estados por Produto 2 . . . 94
A.8 Sequências Wi de Estados por Produto 2 . . . 94
A.9 Tabela de Apoio à Geração das Sequências Finais do Método UIO . . . 95
1 INTRODUÇÃO . . . 23
1.1 JUSTIFICATIVA . . . 24
1.2 OBJETIVOS . . . 24
1.3 DESENHO DE PESQUISA . . . 25
1.4 CONTEXTUALIZAÇÃO DO TRABALHO . . . 27
1.5 ORGANIZAÇÃO DO VOLUME . . . 28
2 REFERENCIAL TEÓRICO . . . 29
2.1 TESTES DE SOFTWARE . . . 29
2.2 TESTES BASEADOS EM MODELOS (MODEL BASED TESTING - MBT) . . . 32
2.3 MÁQUINA DE ESTADOS FINITOS . . . 34
2.4 MÉTODOS DE GERAÇÃO DE SEQUÊNCIA DE TESTES (MGST) . . . 36
2.4.1 SEQUÊNCIAS DE TESTE . . . 36
2.4.2 MÉTODO W . . . 39
2.4.3 MÉTODO WP . . . 39
2.4.4 MÉTODO HSI . . . 40
2.4.5 MÉTODO UIO E UIOV . . . 42
2.5 LINHA DE PRODUTO DE SOFTWARE . . . 43
2.5.1 EXEMPLOS DE LINHA DE PRODUTO DE SOFTWARE . . . 47
2.5.2 TESTES DE LINHA DE PRODUTO DE SOFTWARE . . . 48
3 ADAPTACÃO DE MÉTODOS DE GERAÇÃO DE SEQUÊNCIA DE TESTES PARA LINHA DE PRODUTO DE SOFTWARE . . . 51
3.1 O PROCESSO SPLIT-TESGE . . . 51
3.2 APLICAÇÃO DO PROCESSO SPLIT-TESGE . . . 56
3.2.1 APLICAÇÃO DO PROCESSO SPLIT-TESGE NO MÉTODO HSI . . . 57
3.3 APLICAÇÃO DO PROCESSO SPLIT-TESGE NOS MÉTODOS W, WP E UIO . . . 62
3.3.1 APLICAÇÃO DO PROCESSO SPLIT-TESGE NO MÉTODO W . . . 62
3.3.2 APLICAÇÃO DO PROCESSO SPLIT-TESGE NO MÉTODO WP . . . 65
3.3.3 APLICAÇÃO DO PROCESSO SPLIT-TESGE NO MÉTODO UIO . . . 66
A busca constante de acesso à informação e a necessidade de atualização e controle de dados, têm sido fatores determinantes para o aumento da demanda de sistemas computacionais. Entretanto, se por um lado a disseminação da tecnologia da informação provê benefícios aos usuários, por outro lado, ocasiona um aumento do número de falhas residuais que impactam a qualidade de software [1].
A fim de evitar que estas falhas afetem a utilização do sistema pelo usuário final, diversas estratégias de controle de qualidade de produto estão sendo adotadas pelas empresas fabricantes de software. Dentre estas estratégias destaca-se teste de software. Bastos [2] caracteriza teste de software como um conjunto de atividades utilizadas para validar os requisitos de um programa, determinando se os resultados esperados são atingidos. Na prática, a realização de testes busca garantir a confiabilidade do software, na medida em que esta confiabilidade é posta em prova, buscando-se defeitos.
Para que seja possível garantir a eficácia do processo de testes de software, viabilizando a realização completa de teste em uma funcionalidade com o menor esforço possível a técnica de Teste Baseado em Modelos (Model Based Testing - MBT) [17] tem sido empregada. Esta técnica faz uso de modelos de software (formais e comportamentais) para a geração de sequências de testes
i.e. conjunto de ações que podem ser executadas para testar uma funcionalidade. A fim de tornar possível a aplicação de MBT podem ser aplicadas algumas técnicas, dentre estas, a utilização de Métodos deGeração deSsequências deTeste (MGST). Estes métodos recebem como entrada uma Máquina de Estados Finitos (Finite State Machine - FSM) [30] que representa o comportamento
de um sistema e retornam como saída uma sequência de testes.
As sequências de testes geradas pelos MGST garantem que não seja necessário esforço excessivo para execução dos testes e ao mesmo tempo garantem a cobertura de todas as funcionali-dades modeladas na FSM. MGST são comumente utilizados para testes de sistemas únicos, e pouco explorados no segmento de Linha de Produto de Software (Software Product Line - SPL). Entre-tanto, o conceito de SPL, tem adquirido visibilidade em projetos de desenvolvimento que buscam o aumento da produtividade. Uma SPL é descrita como uma família de softwares similares desen-volvidos a partir de um conjunto de especificações comuns onde cada produto possui peculiaridades que o diferencia dos demais [26].
os produtos da SPL, sendo assim, um defeito presente em um artefato reutilizável pode refletir em todos os produtos derivados da linha.
Considerando a existência de software produzido a partir de SPLs, as vantagens da reuti-lização de artefatos e a importância do teste de software, apresentamos neste trabalho um processo para adaptação de Métodos de Geração de Sequência de Testes para Linha de Produto de Soft-ware, denominado SPLiT-TeSGe. Desta forma este estudo adota como questão de pesquisa: como adaptar métodos de geração de sequências de testes para o contexto de SPL?
1.1 Justificativa
Diversos autores têm efetuado pesquisas com o intuito de desenvolver metodologias [4], técnicas [5], métodos [44] e abordagens [35] para melhorar a eficácia da realização de testes de SPL. Entretanto, embora estes trabalhos apresentem relevantes contribuições, sendo capazes de adaptar técnicas de testes de sistemas únicos para o contexto de SPL, não foram encontrados trabalhos que façam uso de métodos de geração de sequência de testes, na Engenharia de Domínio de SPL.
O uso de MGST nesta etapa permite beneficiar-se do reaproveitamento de artefatos de testes. Desta forma são geradas sequências de teste contendo informações de variabilidade, que posteriormente podem ser utilizadas na Engenharia de Aplicação para derivar produtos específicos. Ainda, a utilização de MGST garante que quando produzidos artefatos de testes a partir das sequên-cias geradas, todas as funcionalidades modeladas na FSM serão testadas com o menor número de casos de testes possível. Desta forma, justifica-se a importância do processo apresentado neste trabalho, visto que com a utilização deste processo torna-se possível aliar as vantagens da utilização de linha de produto com as vantagens da utilização de métodos de geração de sequências de testes, provendo uma otimização do processo de testes de produtos derivados de uma SPL.
1.2 Objetivos
O objetivo geral deste trabalho de pesquisa é propor um processo genérico que possa ser utilizado para adaptação de MGST para SPL. A fim de complementar e atingir o objetivo geral, foram propostos os seguintes objetivos específicos:
• realizar um estudo dos trabalhos existentes na literatura que abordam a temática testes de SPL e de MGST;
• entender o funcionamento dos principais MGST a fim de estabelecer uma relação de caracte-rísticas similares entre eles;
• realizar testes do processo em diversos MGST;
• aplicar um exemplo de uso do processo em um MGST para o teste funcional de uma SPL real.
1.3 Desenho de Pesquisa
Nesta seção são apresentadas as etapas executadas para a concepção deste trabalho, de forma a obter: o conhecimento base para realização desta pesquisa (Etapa 1); a concepção e desenvolvimento do projeto (Etapa 2); a criação de um protótipo de ferramenta (Etapa 3); a execução de testes manuais (Etapa 4) e a validação do processo (Etapa 5). A Figura 1.1 representa cada uma das etapas desta pesquisa.
• Etapa 1: Análise de Referencial teórico e preparação da questão de pesquisa
Esta etapa foi dedicada a conhecer o estado da arte no que diz respeito a Métodos de Ge-ração de Sequências de Testes (MGST), Linha de Produto de Software e Testes de Linha de Produto de Software. Inicialmente focou-se em entender o funcionamento dos Métodos de Geração de Sequências de Testes. Este conhecimento foi adquirido através da discussão com outros pesquisadores do Centro de Pesquisa em Engenharia de Sistemas (CePES) que haviam trabalhado previamente com esta temática. A partir destas discussões e estudos, foi escrita uma monografia baseada em trabalhos de mestrado e doutorado, e artigos existentes nas principais bibliotecas digitais da Computação (ACM Digital library; IEEE Xplore; Sprin-gerLink; Scopus, etc.). Posteriormente buscou-se uma visão do estado da arte de Testes de Linha de Produto de Software. Assim, houve a cooperação com outro trabalho de pesquisa, em nível de doutorado, sendo realizado pelo grupo de pesquisa no qual a autora colabora. No contexto desta colaboração, analisou-se os trabalhos presentes em três revisões de literatura: [18] [10] [33] que proporcionaram um melhor entendimento dos conceitos de Testes de Linha de Produto de Software.
• Etapa 2: Realização dos testes iniciais para concepção do processo
A partir dos conhecimentos obtidos na Etapa 1, iniciou-se o trabalho de concepção do processo SPLiT-TeSGe. Nesta etapa, inicialmente, foi efetuada uma análise das características comuns a todos os MGST. Posteriormente foram realizados diversos testes exploratórios visando en-contrar o local (comum a maioria dos MGST) que seria capaz de obter os melhores resultados a partir da adaptação para inserção e manipulação de variabilidade. A definição do local ideal foi baseada na preservação da garantia de cobertura das sequências geradas pelos MGST. Esta garantia de cobertura foi verificada após a inserção e manipulação de variabilidade. Ainda, preocupou-se com a necessidade de que todos ou pelo menos a maioria dos MGST pudessem ser adaptados seguindo esta mesma estratégia.
• Etapa 3: Desenvolvimento e validação de um protótipo para testes
Para esta etapa utilizou-se uma implementação do MGST HSI que já havia sido gerada em projetos anteriores no CePES. A partir desta, foram realizadas correções de algumas falhas a fim de assegurar a geração correta das sequências HSI em seu formato tradicional. Após a realização de testes garantindo que o HSI estava corretamente implementado foi realizado o trabalho de concepção do algoritmo e codificação do programa para a adaptação do MGST para geração de sequências com variabilidade na Engenharia de Domínio.
• Etapa 4: Realização de testes manuais para validação do processo nos MGST que não foram automatizados
geração de sequências de testes para os métodos UIO, UIOv, W e Wp. As sequências geradas pelos MGST adaptados foram comparadas com as sequências geradas pelos MGST tradicionais a fim de garantir que a cobertura de testes dos MGST não foi afetada pela adaptação. Para isso verificamos se todas as sequências de testes geradas da forma tradicional estavam contidas nas sequências geradas pelos MGST adaptados.
• Etapa 5: Realização de exemplo de uso
Nesta etapa foi executado o protótipo de ferramenta criada e geradas sequências de testes para uma SPL real, a Arcade Game Maker (AGM) [26]. A AGM foi criada pelo Software Engineering Institute (SEI) com o objetivo de auxiliar o aprendizado dos conceitos de SPLs por meio de uma abordagem prática. As sequências de testes geradas tiveram sua variabilidade resolvida manualmente utilizando a metodologia descrita no método SPLiT-MBT [8].
1.4 Contextualização do trabalho
Este estudo, além de responder a questão de pesquisa proposta, busca contribuir com uma pesquisa de doutorado, cujo objetivo é desenvolver um método sistemático para gerar casos de teste e scripts para SPLs a partir de modelos UMLs. Este método é chamado Software Product Line Testing Method Based on System Models - SPLiT-MBt (Vide Figura 1.2) [8]. Fazem parte do método as seguintes etapas:
1. Geração de casos de testes na Engenharia de Domínio
• extrair informações de teste e variabilidade de diagramas de casos de uso e ativida-des. Sendo que, estes diagramas são previamente gerados com base na abordagem SMart [29] [20], a qual suporta a gerência de variabilidades em diversos modelos UML; • gerar FSMs com informações de teste e variabilidade a partir das informações anotadas
nos modelos;
• gerar sequências de teste por meio da aplicação de MGST adaptados/estendidos para SPLs sob as FSMs.
2. Geração de casos de testes na Engenharia de Aplicação:
• estender diagramas UML da Engenharia de Domínio para gerar casos de teste para produtos específicos;
• gerar FSMs a partir das informações anotadas nos modelos; • gerar sequências de teste aplicando o método HSI convencional;
Na Figura 1.2 é possível visualizar a etapa do projeto em que este trabalho de mestrado está inserido.
Figura 1.2: Etapas para Geração de Casos de Teste do Método SPLiT-MBt.
Conforme destacado na Figura 1.2 este trabalho faz parte da Engenharia de Domínio do método SPLiT-MBt, e apresenta como contribuição a adaptação de métodos de geração de sequência de testes a fim de gerar, na Engenharia de Domínio, sequências com variabilidade para serem utilizadas na Engenharia de Aplicação. Esta utilização se dá pela solução da variabilidade e por consequência, geração de produtos independentes com características peculiares.
1.5 Organização do Volume
2.
REFERENCIAL TEÓRICO
Neste capítulo será fornecido o conhecimento teórico básico para a compreensão do pro-cesso proposto neste trabalho e sua motivação. Na Seção 2.1 será apresentado o conceito de testes de software, destacada sua importância e apresentados alguns termos utilizados no processo de testes. Na Seção 2.2 será explanado sobre testes baseado em modelos. Na Seção 2.3, por sua vez, serão descritas as máquinas de estados finitos (Finite State Machine - FSM). Na Seção 2.4
é descrito o funcionamento dos Métodos de Geração de Sequências de Testes (MGST) estudados. A Seção 2.5 apresenta o conceito de SPL e as vantagens e desvantagens de sua utilização dando enfoque às formas de representação de variabilidade em SPL, bem como apresenta alguns exemplos de SPL e os conceitos de testes em SPL.
2.1 Testes de Software
O conceito de testes de software está intimamente ligado ao conceito genérico de testes. A palavra teste deriva do latimTestum, e faz alusão a uma panela de barro utilizada para realização de medidas de peso [25]. Atualmente testes são utilizados em diversos contextos e têm como função provar certo nível de qualidade de um produto.
No segmento de software, os testes buscam validar a qualidade do produto em relação à sua funcionalidade e conformidade com os requisitos. Desta forma, os testes se tornam um aliado para o ganho de confiabilidade, permitindo que as falhas existentes sejam corrigidas antes de se tornarem defeitos no ambiente do usuário.
Um dos fatores determinantes para o sucesso do processo de testes é analisar o nível de risco do projeto para então determinar qual estratégia de teste será utilizada. Os riscos são classificados em três grupos: risco técnico, aquele que diz respeito à possibilidade de cometer uma falha; risco de negócio, trata-se do impacto financeiro que pode ser ocasionado caso o programa apresente um defeito; e risco do projeto, refere-se aos impactos que um defeito pode ocasionar no projeto e.g. cronograma, recursos humanos, recursos materiais, etc. [28].
Embora a correta análise de riscos do projeto permita estruturar os testes para localizar a maior parte dos defeitos do software, se faz necessário enfatizar que software com ausência total de falhas não existe. Esta regra faz parte de um dos sete princípios do teste de software1, estabelecido pela International Software Testing Qualifications Board(ISTQB)[28]. A ISTQB ainda, define o processo de testes em cinco atividades, sendo elas:
• Planejamento e Controle: na atividade de planejamento são definidos os objetivos e es-pecificadas as atividades necessárias para atingi-los. Na atividade de controle, por sua vez, é feito um comparativo entre o processo planejado e o processo que está sendo executado, a fim de identificar possíveis desvios de projeto;
• Análise e Modelagem: atividades onde são criados os artefatos de teste para atender aos objetivos definidos no planejamento. Dentre as atividades previstas para esta etapa estão: avaliação das condições de teste do sistema, preparação do ambiente de testes, criação de casos de testes, priorização2 dos testes, identificação das necessidades de dados para o teste e criação de uma rastreabilidade entre os requisitos e casos de teste. Esta rastreabilidade é de grande importância pois permite, ao alterar um requisito do sistema, identificar os casos de testes que são impactados para serem atualizados evitando que se tornem obsoletos; • Implementação e Execução: na atividade de implementação o ambiente de teste é
prepa-rado e os casos de teste são agrupados conforme estratégia e prioridade, ficando disponíveis para a execução. Já na atividade de execução são realizados os casos de teste que foram planejados e elaborados os registros de defeitos localizados.
• Avaliação do Critério de Saída e Relatórios: nesta atividade é analisado se os objetivos definidos para o teste foram atingidos e averiguada a necessidade da realização de testes adicionais. Quando constatada a necessidade de realização de testes adicionais, podem ser executados novamente os casos de teste, ou feita uma execução de testes exploratórios, isto é, testes baseados na experiência do testador.
• Encerramento de teste: na atividade de encerramento de teste são coletados dados, fatos e números referentes as atividades anteriores, para registrar e consolidar a experiência adquirida na execução que encerra. Ainda faz parte desta etapa, armazenar todos os artefatos de testes utilizados para reuso futuro.
É importante enfatizar que apesar de serem apresentadas sequencialmente, durante o processo de testes pode ocorrer uma fusão, ou a execução paralela das etapas.
Para a organização e execução das atividades de testes, faz-se necessária a correta com-preensão de alguns termos que formalizam a atividade. Entre os termos mais utilizados estão: Falha (Fault), Erro (Error) e Defeito (Failure) sendo que, falhas estão associadas ao universo do usuário, erros ao universo da informação e defeitos ao universo físico. É importante citar que nem todos os defeitos e erros tornam-se falhas. Por exemplo, um defeito em um trecho de código que está condicionado a um comando de condição “if”, pode nunca gerar uma falha, caso esta condição nunca seja atendida e por consequência o trecho de código não executado. Os conceitos de falha (fault), erro (error) e defeito (failure) são baseados em [1]. A Figura 2.1, ilustra estes conceitos.
Ainda, outros termos formalizam o processo de análise e execução de testes, sendo os principais: caso de teste, cenário de teste, ambiente de teste e plano de teste.
Figura 2.1: Erro, Defeito e Falha - Adaptado de [51]
testador para testar os caminhos alternativos da funcionalidade em teste, ao contrário do que acontece em técnicas de teste baseadas na experiência, onde o testador executa apenas as funcionalidades conhecidas por ele;
• Cenário de Teste: documento que descreve uma funcionalidade de forma abrangente, i.e. sem detalhar as ações do usuário e as respostas do sistema em um ciclo de testes. Um exemplo de cenário de testes pode ser uma funcionalidade de login, esta que seria formada pelos casos
de teste “Efetuar login com sucesso” e “Efetuar tentativa de login inválido”;
• Ambiente de Teste: conjunto de hardware, software, simuladores, e outros elementos de suporte necessários à realização do teste;
• Plano de Teste: documento que descreve o escopo, abordagem, recursos e cronograma das atividades de teste. Este documento identifica os recursos a serem testados, as tarefas de teste, o responsável pela execução de cada tarefa, o grau de independência do testador, o ambiente de teste, as técnicas de projeto de teste e critérios de entrada e de saída a serem usados, as razões de sua escolha, e os eventuais riscos que exigem planos de contingência.
O processo de teste considera diversos níveis, sendo eles [43]: teste de unidade, teste de integração, teste de validação e teste de sistema. Cada nível de teste se adapta melhor a um estágio do processo de desenvolvimento de software e para cada nível, tipos diferentes de testes são utilizados, dentre estes, o mais comum é o teste funcional, que faz parte do nível de testes de sistema.
2.2 Testes Baseados em Modelos (Model Based Testing - MBT)
MBT é uma técnica que permite efetuar a criação de automática artefatos de teste com base em requisitos de software representados em modelos [12]. A partir destes modelos é possível derivar artefatos que refletem o comportamento do sistemae.g casos e scripts de Teste. A automa-tização deste processo é de grande valia uma vez que, teste é considerado uma das mais onerozas etapas do processo de desenvolvimento de software [38] [32]. Através da automatização da criação de casos e/ou scripts de teste é possível reduzir reduzir tempo e custo do processo de teste [50].
A otimização de tempo e economia de recurso proporcionada pela técnica de MBT é ainda mais evidente em sistemas que sofrem alterações frequentes nos requisitos, uma vez que, MBT possibilita que após cada alteração seja realizado uma nova geração automática dos casos de teste, evitando com isso o retrabalho. Esta vantagem é obtida devido a rastreabilidade criada entre modelo (requisito) e artefato de teste.
Os modelos utilizados pela técnica MBT podem ser criados no início do processo de desenvolvimento de software na ainda na etapa de análise de sistema. Isto permite que os testes sejam realizados de acordo com aquilo que foi solicitado pelo cliente (requisito de sistema) e não de acordo com o que foi compreendido e executado (software implementado). Desta forma, é considerado pelo testador apenas o que foi requisitado, enquanto que o teste manual, executado de forma exploratória, considera a visão do testador a respeito do negócio em comparação com o sistema desenvolvido.
O processo de MBT, considera as seguintes fases [17]: Construir o modelo, Gerar insumos esperados, Gerar resultados esperados, Executar os scripts de teste ou casos de teste, Analisar os resultados, Decidir novas ações e Parar o teste. Estas fases podem ser visualizadas na Figura 2.2 e serão especificadas a seguir:
• Construir o Modelo: construção de um modelo baseado na especificação dos requisitos do sistema. Este modelo deverá conter informações referente ao comportamento do sistema bem como informações de teste;
• Gerar Insumos Esperados: com base no modelo formal desenvolvido realizar a geração dos casos de teste ou scripts de teste, a fim de obter as entradas e saídas esperadas na execução
dos testes;
• Gerar Resultados Esperados: esta etapa consiste na geração de um Oráculo de Teste (Test Oracle) contendo os resultados esperados para cada ação do sistema. Desta forma, as saídas
geradas pela execução dos casos de teste escripts de teste (Saídas Reais) podem ser validadas de acordo com o estabelecido (Saídas Esperadas);
• Executar osScriptsde Teste ou Casos de Teste: nesta etapa acontece a execução dos artefatos
Figura 2.2: Atividades de Teste Baseado em Modelos [11]
• Analisar os Resultados: com base nos dados armazenados referente aos resultados da etapa de teste anterior, são criados nesta etapa relatórios e gráficos analíticos dos resultados obti-dos, estes dados são de grande importância para definição das ações futuras do processo de desenvolvimento de desenvolvimento de software;
• Decidir Novas Ações: a partir da análise dos resultados devem ser tomadas ações referente à modificação do modelo, a fim de corrigir deficiências encontradas nos modelos (suprindo a necessidade de gerações de mais testes); ações referentes à alteração de sistema, para correção de defeitos localizados, e ainda decidir quando encerrar as atividades de teste do sistema para implantar o produto no cliente e, estimar a qualidade do software;
• Parar o Teste: nesta etapa encerra-se o processo de testes e o sistema é disponibilizado para ser implantado no cliente.
Entre os modelos formais descritos os mais utilizados na técnica de MBT são as Máquinas de Estados Finitos [6]. Por este motivo e, por ser o modelo utilizado para aplicação de MGST, será brevemente descrito na próxima seção a estrutura das FSMs
2.3 Máquina de Estados Finitos
Máquina de Estados Finitos (Finite State Machine - FSM) são modelos utilizados para representar o comportamento de um sistema por meio de um número finito de estados e transi-ções [23]. Uma FSM pode ser representada formalmente por: (X, Z, S,S0 R
z, R
z) sendo [13]
• X (Input) é um conjunto finito não vazio de elementos de entrada; • Z (Output) é um conjunto finito de elementos de saída;
• S (State) é um conjunto finito não vazio de estados • S0 ∈S é o estado inicial
• R
z:(S × 1)→ 0 é a função de saída; • R
s: (S × 1)→ S é a função da transição de um estado para outro.
As FSMs, podem ser representadas fazendo uso de um grafo direcionado, denominado Diagrama de Transição de Estados, ou por tabelas denominadas Tabela de Transições de Estados. Diagramas de Transição de Estados, são a forma mais utilizada para representação de FSM, em que estados são representados por vértices e transições representadas por arestas direcionadas. Cada aresta possui um rótulo que indica entrada/saída e uma direção que leva a FSM ao próximo estado. A Figura 2.3 ilustra uma FSM representada em diagrama de transição de estados.
Figura 2.3: Representação de FSM com Diagrama de Transição de Estados [9].
o conjunto finito de saída “O” descreve as variáveis de saída do sistema. A FSM da Figura 2.3, possui o alfabeto de entrada I={x; y} e o alfabeto de saída O={0; 1}.
Já na representação de FSM por Tabela de Transições de Estados, linhas indicam estados e colunas representam entradas. A FSM da Figura 2.3, que conforme supra citado, tem como estados S={S0, S1, S2, S3}, como entrada I={x,y} e como saída O={0,1} é representada na Tabela 2.1.
Tabela 2.1: Representação de FSM com Tabela de Transição de Estados.
x y
S0 1/S2 0/S1
S1 1/S1 1/S3
S2 0/S1 0/S0
S3 1/S2 0/S0
Para exemplificar, pode ser visto na Tabela 2.1 que para o estado S0, quando aplicada a
entrada “x”, a FSM é direcionada ao estado S2 com saída “1”, enquanto que, quando aplicada a
entrada “y” ao mesmo estado S0, a FSM é direciona ao estado S1, com saída “0”.
As FSMs são classificadas em: Máquinas de Moore [37] e Máquinas de Mearly [36], sendo estas diferenciadas pela forma de representação das saídas. Nas Máquina de Mearly as saídas são representadas nas transições e nas Máquinas de Moore representadas nos estados.
Com o propósito de esclarecer a aplicabilidade de determinados Métodos de Geração de Sequências de Testes (MGST) 3 faz-se necessária a definição de algumas propriedades acerca de uma FSM [41], sendo estas descritas a seguir:
• Completamente especificada (ou completa): uma FSM é dita completa, quando todos os estados possuem transições definidas para todas as entradas do alfabeto de entradas. Quando a FSM não atente à esta condição ela é chamada de FSM Parcialmente Especificada ou Parcial. Formalmente, uma FSM é completa se:
(Dm = s.x), sendo Dm = Domínio, s = estados e x = entradas
Em alguns casos as transições não especificadas de uma FSM, podem ser completadas com “auto transições” para realização dos testes, neste caso, diz-se que a FSM assume uma suposição de completude [13];
• inicialmente conexa: quando todos os estados são alcançáveis a partir do estado inicial S0;
• fortemente conexa: se para cada par de estados Si, Sj ∈ S existe uma transição que leva a
FSM de Si a Sj;
• determinística: Quando para uma mesma entrada pertencente ao alfabeto de entradas, existe uma única transição de saída partindo de um mesmo estado. Quando esta condição não é atendida a FSM é ditaNão-determinística;
• minimal: uma FSM é minimal (ou reduzida) se na FSM não existem dois estados equivalentes, isto é, dois estados que possuem as mesmas entradas produzem as mesmas saídas;
2.4 Métodos de Geração de Sequência de Testes (MGST)
MGST são métodos que recebem como entrada uma FSM e retornam como saída um conjunto de entradas e um conjunto de saídas. Esses conjuntos de entradas que são gerados pelos MGST recebem o nome de sequências de testes. Estas sequências podem ser utilizadas para a criação de casos de teste e scripts de teste.
Estes artefatos de testes quando executados em uma aplicação, terão as saídas geradas confrontadas com as saídas definidas na FSM. Quando todas as saídas geradas são idênticas a aplicação (ou a funcionalidade que está sendo testada) é considerada correta, enquanto que, caso existam divergências entre as saídas específicas e as saídas geradas é caracterizado um defeito.
A aplicação é considerada correta quando as saídas geradas são idênticas às esperadas, quando elas diferem um erro é detectado. Os MGST buscam selecionar um subconjunto de sequên-cias de entradas que permita testar com o menor esforço a funcionalidade modelada na FSM por completo [16].
Os MGST baseiam-se em um conjunto de sequências básicas, sendo as principais [16],
State Cover (Q), Transition Cover (P),Characterization Set (W), Synchronization Sequence (SS),
Distinguishing Set (DS), Identifiers Harmonized Set (HI) e Sequência única de entrada e saída
(UIO). Estas sequências são utilizadas para obtenção de um resultado parcial importante na geração das sequências finais de testes. Cada MGST pode se basear em uma ou mais sequências básicas.
São conhecidos diversos MGST que fazem uso de FSM, em síntese, todos os métodos têm o mesmo objetivo, diferenciando-se pelas características das FSMs suportadas, bem como, pelo tamanho e cobertura das sequências que são geradas. Desta forma, é preciso analisar o custo benefício de cada um dos MGST na definição do MGST adequado para cada cenário.
2.4.1 Sequências de teste
Para que seja possível compreender os métodos de geração de sequência de testes, é preciso estar claro o funcionamento das principais sequências presentes na literatura [16].
• State Cover: também conhecido como Preâmbulo ou conjunto “Q”. O State Cover é
• Transition Cover: também chamado de conjunto “P”, o Transition Cover é um conjunto de entradas que cobre todas as transições da FSM. Em outras palavras, o conjunto “P” é formado pelo conjunto “Q” mais as entradas das transições de saída de cada estado FSM; • Characterization Set - W eIdentification Set - Wi: mais conhecido como conjunto “W”,
este conjunto é formado por um conjunto de entradas que quando executadas de qualquer estado de uma FSM diferenciam este estado dos demais. Isto é, quando executado o conjunto W de qualquer estado Si, a saída gerada será diferente de qualquer outro estado Sj [9].
• Sequência única de entrada e saída: também chamada de sequência UIO, é uma sequência de entradas/saídas que distingue cada estado dos demais estados da FSM. Este conceito se assemelha aos conceitos da sequência “W”, porém, na sequência “W” buscam-se sequências de entradas que distinguem um estado em um par de estados, enquanto que na sequência UIO, busca-se distinguir um estado de todos os demais estados da FSM [46]. A Tabela 2.2, demonstra o processo de geração das sequências UIO para a FSM da Figura 2.3.
Tabela 2.2: Sequência UIO ID Estado Entrada Saída
1 S0 X 1
2 S1 X 1
3 S2 X 0
4 S3 X 1
5 S0 Y 0
6 S1 Y 1
7 S3 Y 0
8 S0 yy 01
9 S3 yy 00
10 S3 yyy 000
Na Tabela 2.2 é possível notar que na linha 3 foi encontrado U IO2={x}, isto porque se
analisarmos os estados S0, S1 e S3 a saída gerada quando aplicada a entrada “x” é “1”
enquanto que para o estado S2, quando aplicada a mesma entrada “x” é gerada uma saída
“0”.
Na linha 6, localiza-se U IO1={y} devido a entrada “y” gerar para o estado S1 uma saída
diferente da gerada para os demais estados. Na linha 8, por sua vez, é gerado U IO0={yy}.
Nesta linha pode-se notar que a entrada “y”, foi aplicada duas vezes formando a sequência “yy” isto se faz necessário porque nenhuma das entradas do alfabeto de entradas (x e y), quando aplicada uma única vez é capaz de distinguir o estado dos demais.
Para o estado S3, oU IO3={yyy} é localizado na linha 10, nesta situação a entrada “y”, foi repetida três vezes pois a sequência “yy”, embora distinguisse o estadoS3dos demais, já havia
sido utilizada pra o estadoSO sendo então executado “y” mais uma vez, gerando a sequência
Uma das formas de localizar a sequência UIO é fazer uso de árvore. Nesta técnica, a raiz da árvore deve ser o estado que deseja-se distinguir. A partir deste estado são criados novos ramos para cada entrada aplicável ao estado raiz. Os ramos criados possuirão duas linhas: a primeira deverá conter os estados que se equivalem ao estado raiz, ou seja, os estados que para a entrada do ramo geram a mesma saída; na segunda linha deverão estar descritos os destinos dos estados colocados na linha 1 para a entrada deste ramo. O processo de repete, gerando novos ramos até que se encontre um conjunto vazio de estados destinos.
• Sequência de distinção: uma sequência de distinção (Distinguishing Set - DS) é um con-junto de entradas que quando executadas, retornam uma sequência de saídas diferentes para cada estado da FSM. Uma sequência de distinção pode ser obtida por meio da concatenação das sequências UIO. Para a FSM da Figura 2.3 considerando-se: U IO0={yy}, U IO1={y}, U IO2={x} eU IO3={yyy} concatenados temos DS={x, yyy}. Na Tabela 2.3 é exemplificada
a obtenção desta sequência DS.
Tabela 2.3: Sequência DS ID Estado Inicial Saída
1 S0 1001
2 S1 1100
3 S2 0100
4 S3 1001
Pode ser visualizado na Tabela 2.3 que executando-se a sequência {x, yyy} para cada um dos estados S0,S1,S2 e S3 cada execução produziu uma sequência de saídas distinta. Por tanto
{x, yyy}, pode ser considerada uma sequência de distinção para a FSM da Figura 2.3
• Sequência de sincronização: também chamada de sequência SS, esta sequência é determi-nada para cada estado da FSM, sendo que uma FSM pode não possuir sequência SS ou possuir mais de uma. Uma sequência SS é um conjunto de entradas que quando executadas a partir de qualquer estado da FSM, atinge um estado específico. As sequências de sincronização para a FSM da Figura 2.3 podem ser as seguintes: SS0 ={xyxy},SS1 ={xx}, SS2 ={xyx} eSS3
={xxy}
• Conjunto de identificadores harmonizados: também chamado de conjunto Hi é o conjunto união das sequências de separação, ou seja, o conjunto união das sequências que distinguem um estado side todos os outros estados da FSM) de Si para cada Sj da FSM, sendo i diferente
de j. Para a FSM representada na Figura 2.3 os identificadores harmonizados poderiam ser H0 = {x,yy}, H1 = {x,y}, H2 = {x}, e H3 = {x, yy}. O conjunto formado pela união dos
conjuntos Hi é chamado de conjunto HSI.
representa que a FSM deve ser reiniciada, ou seja, levada ao estado inicial a cada execução da sequência.
2.4.2 Método W
O método Automata Theoretic, popularizado como método W, é considerado um dos primeiros métodos de geração de sequência de testes, e por isso um dos mais difundidos. Foi proposto por Chow[6], sendo este aplicável somente a máquinas determinísticas, completas, inicialmente conexas e minimais. Segundo o Chow, o conjunto de teste gerado por esse método garante a cobertura de toda a FSM.
Este método consiste, em síntese, em concatenar os conjuntosP e W, para obter sequên-cias de entrada para o teste de determinada FSM. Para exemplificar, analisaremos a execução do método W para a FSM da Figura 2.3.
Inicialmente é necessário determinar o conjunto P e o conjunto W, tendo em vista que a determinação de P e W foi descrita na Seção 2.4.1 assumimos então:
P ={ǫ, y, x, yy, yx, xx, xy, yyx, yyy} e W ={x, yy}.
O segundo passo é concatenar os conjuntos P e W. A concatenação é feita colocando cada elemento de P, frente a cada elemento de W, com exceção do elemento ǫ que não deve ser
considerado. Após a execução desta etapa obtêm-se como resultado:
W = {x, yy, yx, yyy, xx, xyy, yyx, yyyy, yxx, yxyy, xxx, xxyy, xyx, xyyy, yyxx, yyxyy, yyx, yyyyy}.
Após a concatenação, devem ser eliminadas as sequências que são prefixos de outras sequências (sequências redundantes), resultando no conjunto W={x, yy, yx, yyy, xx, xyy, yyx, yyyy}.
A última etapa do método W, consiste em acrescentar a função “r”(reset) no início de cada sequência. Desta forma o conjunto final para a FSM da Figura 2.3 é W ={ryxx, ryxyy, rxxx, rxxyy, rxyx, rxyyy, ryyxx, ryyxyy, ryyyx, ryyyyy}.
2.4.3 Método Wp
O método Wp, proposto por Fujiwara(1991) [21], é uma adaptação ao método W, sendo que, seu nome deriva de W partial. O método Wp apresenta uma evolução do método W, que permite utilizar um subconjunto do conjuntoW, chamado Wi, para criação das sequências, obtendo
assim uma quantidade reduzida de sequências de teste. Assim como o método W, o método WP , é aplicável somente a máquinas determinísticas, completas, inicialmente conexas e minimais.
Para implementação do método Wp, segundo [21], deve-se inicialmente concatenar o conjunto State Cover (Q) e o conjunto W. Sabe-se que, para a FSM da Figura 2.3 temos W={x; yy} e Q = {ǫ, y, x, yy } desta forma, obtêm-se o conjunto {x, yy, yx, yyy, xx, xyy, yyx, yyyy}.
Para a segunda fase é preciso obter o conjuntoR, sendo R= (P-Q), sendo assim, obtêm-se o conjunto R = { yx, xx, xy, yyx, yyy}.
O próximo passo consiste em concatenar o conjunto R, com os conjuntos Wi de cada estado. Pode ser notado que o conjunto R é formado por cinco sequências e a FSM possui quatro estados. Para determinar com o Wi de qual estado deve-se concatenar cada sequência de R, executa-se a sequência de R e concatena-se R com o Wi do estado onde a execução terminou. Após esta etapa obtêm-se o conjunto Wp={yxy, xxy, xyyy, yyxx, yyyx, yyyyy}, por fim, eliminam-se as redundâncias (sequência prefixadas) e acrescenta-se a função “r” no início de cada sequência, obtêm-se então para este exemplo: Wp ={ryxy, rxxy, rxyyy, ryyxx,ryyyx, ryyyyy}.
2.4.4 Método HSI
O método Harmonized State Identification(HSI) é uma evolução do método W, sendo o primeiro dos métodos de geração de sequências de testes a permitir a utilização de FSMs completas, parciais e qualquer especificação de FSM reduzida [34].
O método HSI, assim como o método Wp, utiliza um subconjunto de W para geração das sequências de teste, e por este motivo obtêm uma redução no número de sequências geradas. Contudo, esta redução não interfere na cobertura dos testes, sendo o método HSI considerado um MGST que garante cobertura total dos estados e transições da FSM em teste.
Para se gerar sequências de testes, a partir do método HSI, faz-se necessário obter o con-juntoState Cover (Q), o conjuntoTransition Cover (P), o Conjunto de Identificadores Harmonizados (HI) e o conjunto Harmonized State Identification (HSI). Para a FSM da Figura 2.3 têm-se Q = {ǫ, y, x, yy } e P ={ǫ, y, x, yy, yx, xx, xy, yyx, yyy}
Para obter o conjunto HI, inicialmente deve ser criada uma lista com os pares de estados da FSM, a esta lista dá-se o nome de L0. Após é criada uma tabela, denominada de Tabela de Relação de Transitividade. Nesta tabela são apresentadas as colunas: “Par de Estados Origem”, “Par de Estados Destino”, “Entradas”, “Saídas” e “Resultados”. A partir desta tabela, o processo para obtenção dos Identificadores Harmonizados é o que segue:
• na coluna “Par de Estados Origem” são listados todos os pares de estado da FSM (L0);
• na coluna “Entradas” são colocas as entradas pertencentes ao alfabeto de entrada da FSM, sendo que estas entradas devem ser repetidas para cada par de estados;
• para cada par de estados Si,Sj, aplicam-se todas as entradas (percorrendo a FSM). Para Si
Estados Destino” formando um novo par S′
i e S′j. Caso a entrada não seja válida para alguns
dos estados do par, adiciona-se a coluna “Resultados” o status Desconsiderado;
• para cada par de estados Si,Sj, aplicam-se todas as entradas (percorrendo a FSM). Para Si e
Sj, adiciona-se na coluna “Saída” a saída da transição;
• para cada linha da tabela, é verificado se as saídas da coluna “Saída” são diferentes para os estados Si e Sj, neste caso adiciona-se a coluna “Resultados” o status Falho. No caso das
entradas serem idênticas, adiciona-se a coluna “Resultados” o status Válido.
E etapa de geração do conjunto de identificadores harmonizados, por meio da tabela de relação de transitividade, é a mais custosa das etapas do método HSI. A quantidade de linhas da tabela é representada por Spi, sendo Sp o número de pares de estados da FSM e i o número de
entradas da FSM. A Tabela 2.4 apresenta a Tabela de Relação de Transitividade para a FSM da Figura 2.3.
Tabela 2.4: Tabela de Relação de Transitividade dos Pares de Estados da FSM[9]. Par de Estados Origem Entrada Par de Estados Destino Saída Resultado
S0 -S1 X S2 - S1 11 Válido
S0 -S1 Y S1 - Sy 01 Falho
S0 -S2 X S2 - S1 10 Falho
S0 -S2 Y S1 - S0 00 Válido
S0 -S3 X S2 - S2 11 Válido
S0 -S3 Y S1 - S3 00 Válido
S1 -S2 X S1 - S1 10 Falho
S1 -S2 Y S3 - S0 10 Falho
S1 -S3 X S1 - S2 11 Válido
S1 -S3 Y S3 - S3 10 Falho
S2 -S3 X S1 - S2 01 Falho
S2 -S3 Y S0 - S3 00 Válido
Com base na Tabela 2.4 é possível localizar os Identificadores Harmonizados. Para isto deve-se percorrer a tabela buscando a menor sequência de entradas, que para cada par de estados, atinge o resultado falho4. Alguns pares da FSM podem não ter identificador harmonizado, por nenhuma sequência de entradas atingir um status “Falho” ou todas as entradas terem como resultado um par de estados inválido. Um exemplo desta aplicação, pode ser o par de estados S0, S3,
analisando a Tabela de Relação de Transitividade, tanto a entrada “x” quanto a entrada “y”, geram saídas idênticas, sendo necessário aplicar outra entrada para identificar o par, então, aplicando-se a entrada “y” o estado S0 irá para o estado S1 e o estado S3 irá para o estado S3 formando o par
destino S1,S3. Para este par, quando aplicada a entrada “y”, são geradas duas saídas diferentes
(Resultado falho), logo o HI do par S0,S3 será “yy”.
4A entrada que gerou um status diferente de falho é concatenada com a entrada que gerou um status falho
Como resultado desta etapa, podemos observar os seguintes pares com Identificador Harmonizado 2.5.
Tabela 2.5: Identificadores Harmonizados dos Pares de Estados da FSM[9]. Par de Estados (S0,S1) (S0,S2) (S0,S3) (S1,S2) (S1,S3) (S2,S3)
Identificador Harmonizado y x yy x y x
O próximo passo é encontrar o conjunto de identificadores harmonizados (HSI) da FSM a partir dos identificadores harmonizados dos pares de estados. Para chegar a este resultado é necessário, para cada estado, analisar os identificadores harmonizados dos pares que aquele estado pertence. Para exemplificar, o estadoS1 pertence ao par de estados, (S0,S1) que tem como HI “xx”,
par (S1,S2) que tem como HI “x” e par (S1,S3) que tem como HI “y”. Para obter o identificador
harmonizado do estado 1 exclui-se os identificadores que são prefixos de outro identificador, restando então HSI1 = {xx,y}. O mesmo processo é executado para os demais estados obtendo-se então:
HSIO = {x,yy}, HSI1 = {x,y}, HSI2 = {x} e HSI3 = {x,yy}
É importante enfatizar que quando a execução das entradas chega a um par de estados idênticoe.g. (S0,S0) caso o resultado corresponda a duas saídas iguais, (válido) então
desconsidera-se este identificador pois a partir deste ponto as entradas desconsidera-serão desconsidera-sempre iguais. Por outro lado, desconsidera-se o resultado for duas saídas diferentes (falho) o identificador é considerado.
Para se obter o conjunto de teste final, executa-se cada um dos conjuntosTransition Cover (P), verificando em qual estado a execução termina, então, concatena-se a este Transition Cover
o identificador harmonizado do estado atual. Para exemplificar, executando-se o Transition Cover “yx” a FSM é levada ao estado S1 que tem como Identificador Harmonizado “x,y“, formando as sequências “yxx” e “yxy”. Por fim, eliminam-se as redundâncias e acrescenta-se a função “r” no início de cada sequência. Obtendo-se o seguinte conjunto HSI final.
HSI = {ryxx, ryxy, rxxx, rxxy, rxyx, rxyyy, ryyxx, ryyyx, ryyyyy}.
2.4.5 Método UIO e UIOv
O métodoUnique Input-Output(UIO) proposto por Sabnani e Dahbura [46], também cha-mado de método U, recebeu este nome por utilizar o conjunto de sequências UIO em substituição ao conjunto W. Inicialmente este método foi considerado completo pelos autores, entretanto, Vu-ong [22] mostrou um contraexemplo provando que existiam situações em que defeitos não eram encontrados pelo método UIO. Por este motivo, o autor propôs uma evolução do método UIO chamado UIOv (UIO variation) ou Uv.
Para a obtenção das sequências por meio do métodoUIO é necessário, inicialmente, obter o conjunto P e o conjunto UIO. Para obtenção destes é preciso executar as sequências Transition Cover e UIO (Ver Seção 2.4.1). Portanto, para a FSM da Figura 2.3 adota-se:
P = {ǫ, y, x, yy, yx, xx, xy, yyx, yyy}
UIO0 = yy, UIO1 = y, UIO2 = x, e UIO3 = yyy.
Concatenando P com as sequências UIO correspondentes, obtêm-se as sequências [16]: {ǫ, UIO0, yUIO, xUIO2, yyUIO3, yxUIO1, xxUIO1, xyUIO0, yyxUIO2, yyyUIO3}, que após feitas as
devidas concatenações obtêm-se como resultado as sequências {yy, yy, xx, yyyyy, yxy, xxy, xyyy, yyxx, yyyyyy}.
O método UIOv, a fim de tomar-se um método completo, agrega ao método UIO uma verificação adicional. Desta forma, é aplicado a cada estado da FSM as sequências UIO pertencentes aos demais estados. Este procedimento é chamando ∼Uv. Com este procedimento garante-se que não existe uma mesma sequência UIO definida para dois ou mais estados. Desta forma, o que muda do método UIO para o método UIOv é a concatenação das sequências Q com as sequências UIO
de cada estado da FSM [16].
Para a FSM da Figura 2.3 são geradas as seguintes sequências:
ǫUIO0,ǫUIO1,ǫUIO2,ǫUIO3, yUIO0, yUIO1, yUIO2, yUIO3, xUIO0, xUIO1, xUIO2, xUIO3,yyUIO0,
yyUIO1, yyUIO2, yyUIO3. Quando realizas as substituições pelas sequências UIO correspondentes
obtêm-se as seguintes sequências: {yy, y, x, yyy, yyy, yy, yx, yyyy, xyy, xy, xx, xyyy, yyyy, yyy, yyx, yyyyy}. A segunda etapa do método UIOv é igual a executada no método UIO, portanto são obtidas as mesmas sequências.
Por fim, faz-se necessário eliminar as sequências que estão prefixadas em outras sequências e adicionar a função reset. Desta forma, obtém-se as sequências UIV={rxxy, ryxy, rxyyy, ryyxx, ryyyyyy}. Neste exemplo, os métodos UIO e UIOv obtiveram o mesmo conjunto final de sequências, isto acontece porque para este exemplo o método UIO havia gerado um conjunto completo de sequências de testes.
2.5 Linha de Produto de Software
Uma Linha de Produtos de Software(Software Product Line- SPL) é um grupo de software similares desenvolvidos a partir de um conjunto de especificações de software comuns a todos esses sistemas, tendo a mesma base e um alto grau de reaproveitamento [26]. Com a adoção de SPL é possível atingir otimização de tempo e recursos que se dá pela construção de um novo software a partir da gerência dos aspectos relativos à variabilidade entre os produtos e utilização das partes reutilizáveis de um software já existente.
De acordo com o Software Engineering Institute [26], as SPLs podem viabilizar a solução
• Aumento da produtividade em até 10x; • Aumento da qualidade em até 10x; • Diminuição de custo em 60%;
• Diminuição das necessidades de trabalho em até 87%;
• Diminuição do tempo de entrega do produto ao cliente em até 98%; • Capacidade de atingir novos mercados em meses, não em anos;
Uma das principais características de SPL é a possibilidade de desenvolver diversos produtos com características diferentes a partir de um núcleo comum. Isto é possível devido a representação de variabilidade em SPL. Afim de explorar a utilização desta variabilidade, é preciso estar claro o conceito dos dois principais termos utilizados i.e. Ponto de Variação e Variante
• Um Ponto de Variação:Um ponto de variação é um local específico de um artefato em que uma decisão de projeto ainda não foi resolvida [40]. Um ponto de variação responde a pergunta: O que varia em uma SPL? [42]
• Variantes: para cada ponto de variação, uma ou mais variantes podem estar associadas, sendo uma variante a uma alternativa de projeto para instanciar uma determinada variabilidade [40]. Uma variante responde a questão: Como uma variabilidade ou um ponto de variação varia em uma SPL [42]?
Estes pontos de variação e variantes são facilmente identificados em um modelo de ca-racterísticas. A Figura 2.4 representa um modelo de característica para um telefone celular. Um exemplo de ponto de variação pode ser visto na característica “Tela” onde a partir desta o telefone celular pode ter as características (variantes) “Básico”, “Colorido” ou “Alta Resolução”.
Nesta mesma Figura 2.4 é possível notar a presença de diferentes de características (Cha-madas, GPS, Tela, Mídia, Básico, Colorido, Alta Resolução, Câmera e MP3). Estas características que também são chamadas de variantes, podem ser dos tipos opcional (optional), obrigatória ( com-mon/mandatory) ou alternativa (alternatives/Xor ealternatives/Or). Sendo que, variantes do tipo
Obrigatória deverão estar presentes em todos os produtos derivados da SPL, enquanto que, varian-tes Opcional e Alternativa podem ou não estarem presentes em alguns dos produtos derivados da SPL. Ainda, faz-se necessário enfatizar que, variantes do tipo Alternativa estarão obrigatoriamente vinculadas a pontos de variação, enquanto que, variantes do tipo Opcional podem ou não atender a este critério [29].
As variantes do tipo Alternativa possuem uma característica peculiar i.e. se dividem em dois grupos: as alternative/Or e as alternative/Xor [29]. Variantes do tipo alternative/Or são
Figura 2.4: Exemplo de Modelo de Características de Linha de Produto de Software [49]
Figura 2.4). As variantes do tipo alternatives/Xor, por sua vez, quando pertencentes a um mesmo
ponto de variação só podem ser selecionadas individualmente (ver Básico, Colorido e Alta Definição na Figura 2.4).
As características também possuem relação entre si e algumas restrições são determinadas, tais como: relação de dependência (depends/requires) e relação de exclusão (mutex/excludes). Um exemplo de relação de dependência pode ser visto na Figura 2.4 entre as características Câmera e
Alta Resolução onde todo produto que possuir a característica Câmera necessariamente irá possuir a característica Alta Resolução. Ainda na Figura 2.4, um exemplo de relação de exclusão pode ser visto entre as características GPS e Básico, isto é, sempre que selecionada a característica Básico, não poderá ser selecionada a característica GPS
De acordo com a abordagem SMarty [29] [39], que foi utilizada como embasamento para representação de variabilidade neste trabalho, uma característica pode ser classificada como:
• Mandatory: representa uma variante obrigatória, ou seja, uma variante que está presente em
todos os produtos derivados de uma SPL;
• Optional: representa uma variante que pode ser selecionada para resolver um ponto de variação ou variabilidade;
• Alternative_OR: determina que a partir de um grupo de variantes ao menos uma variante deste grupo deve ser escolhida a fim de resolver um ponto de variação;
• Alternative_XOR: determina que a partir de um grupo de variantes somente uma variante deste grupo deve ser escolhida a fim de resolver um ponto de variação;
• requires: representa que quando uma variante, pertencente a um determinado ponto de
selecionada, obrigatoriamente a variante “Y” associada ao ponto de variação “B” deve ser selecionada.
• Mutex representa o conceito de restrição “Exclusão Mútua” entre variantes de diferentes pontos de variação. Isto é, uma variante, para ser selecionada, precisa que outra variante pertencente a um ponto de variação diferente, não seja selecionada. Por exemplo, para uma variante “X” associada ao ponto de variação “A” ser selecionada, obrigatoriamente a variante relacionada “Y” associada ao ponto de variação “B” não deve ser selecionada.
Outra característica de uma SPL que deve ser destacada é que as SPLs possuem três atividades principais em sua estrutura, sendo elas: Desenvolvimento do Núcleo de Artefatos, De-senvolvimento do Produto e Gerenciamento da Linha de Produto. Estas atividades serão descritas a seguir [26].
• Desenvolvimento do núcleo de artefatos: (Core Assets Development), também conhe-cida como Engenharia de Domínio (Domain Engineering) é a atividade que define o núcleo de artefatos que é comum a todos os produtos da SPL. Nesta etapa não são descritas par-ticularidades de produto, e sim, são criados os artefatos com variabilidade que estruturam a SPL permitindo a derivação de diferentes produtos a medida em que os pontos de variação são resolvidos;
• Desenvolvimento do Produto: (Product Development), também conhecido como Enge-nharia de Aplicação (Application Engineering) é a atividade onde são derivados os produtos, reutilizando os artefatos definidos e criados na Engenharia de Domínio e explorando as pecu-liaridades de cada produto, por meio da solução de variabilidades da SPL;
• Gerenciamento da Linha de Produto: (Management of Product Line), como sugere o nome esta etapa ocorre durante todo ciclo de vida da SPL e é responsável pela gestão da SPL;
A Figura 2.5 ilustra estas três atividades principais do desenvolvimento de uma SPL.
De acordo com [26], cada círculo representa uma das atividades, sendo estas ligadas entre si e com setas direcionais que demonstram que o processo entre as fases é altamente interativo.
2.5.1 Exemplos de Linha de Produto de Software
Diversas empresas e/ou instituições optam por adotar a técnica de Linha de Produto de Software, seja visando benefícios comerciais (e.g. reutilização de artefatos de software, qualidade e produtividade) ou acadêmicos (e.g. suporte ao ensino de SPL). Nesta seção serão descritos alguns exemplos de SPL.
AArcade Game Maker - AGMfoi criada peloSoftware Engineering Institute (SEI)[26] com o objetivo de auxiliar o aprendizado dos conceitos de SPL. Sendo esta uma SPL que com-preende três jogos: Bowling, Brickles e Pong. Estes jogos eletrônicos com dowload disponível gratuitamente a comunidade acadêmica. Esta Linha de Produto de Software tem sua variabilidade presente na seleção dos jogos, sendo possível derivar produtos que compreendam um, dois ou os três jogos eletrônicos. O modelo de característica que representa a SPL AGM pode ser visto na Figura 2.6 onde é possível identificar que as características que representam cada um dos jogos (brickes, pong e bowling) são alternativas. Ainda, são exemplos de as características obrigatórias desta SPL as funcionalidades jogar (play) e pausar o jogo (pause) e é exemplo de característica opcional a funcionalidade de salvar (save)
Figura 2.6: Modelo de Características SPL AGM [29]
Ainda [44] apresenta em seu trabalho um exemplo de SPL chamado Siemens Medical Solutions HS IM, esta que é uma linha de produto utilizada em workstations de clínicas de radiologia. Fazem parte do fluxo de trabalho de uma clínica de radiologia: o agendamento eletrônico de exame médico, a criação de imagens dos pacientes com a ajuda de equipamentos e o diagnóstico do paciente. O software desenvolvido suporta o cadastro e a manutenção de dados pacientes e de exames (imagens). Os dados são centralizados em um servidor e as imagens de exames processadas emworkstations pelos radiologistas no momento de realização do diagnóstico. A variabilidade desta Linha de Produto de Software está nas diferentes informações do sistema de radiologia (Radiology Information System - RIS) e nas diferenças entre as workstations, sendo todas estas desenvolvidas
com base nos mesmos requisitos, entretanto, possuindo características específicas de funcionalidades variadase.g. (diferentes possibilidades de edição de imagens).
Por fim, Figueiredo et. al [19] apresenta a SPL Mobile Media, uma SPL desenvolvida
com base na SPL chamada MobilePhoto [53] e foi criada para manipulação de mídias (fotos, músicas e vídeos) em dispositivos móveis. Para criação daMobile Media, utilizou-se o núcleo daMobilePhoto
e adicionou-se a este, novas características permitindo a derivação de diversos produtos a partir da exploração destas.
2.5.2 Testes de Linha de Produto de Software
Os conceitos de testes de software fundamentados na Seção 2.1 se aplicam também para Linha de Produtos de Software, uma vez que, tanto os testes de aplicações únicas quanto testes de Linha de Produtos de Software, possuem o mesmo objetivo principal, ou seja, agregar qualidade ao sistema em teste. O diferencial entre os testes de sistemas únicos e testes de linha de produto está justamente na quantidade e dimensão das aplicações. Em uma Linha de Produtos de Software um teste mal sucedido, isto é, que não identifique uma falha existente no software, pode permitir que o erro seja replicado em todos os produtos derivadas da linha, caso esta falha esteja localizada em um componente da Engenharia de Domínio comum entre todos os produtos derivadas.
Um dos principais conceitos em Linha de Produtos de Software é o reuso, onde os progra-mas são criados visando o reaproveitamento de artefatos. Quando se trata de testes de software, o reuso pode ser adotado para os artefatos de testes. Uma vez que, os produtos derivam de uma linha e possuem características comuns, podendo ser criado um único caso de teste para todas as aplicações que implementam a mesma característica.
Afim de explorar o reuso em testes se software, são apresentadas três estratégias para o teste de produtos derivados de SPLs [44]: testar cada produto individualmente, utilizar-se de reuso oportunístico e geração de casos de teste orientado ao reuso.
A segunda estratégia, utilizar-se de reuso oportunístico, aplica o recurso de reuso de arte-fatos de testes. Nesta estratégia os artearte-fatos gerados para o teste de uma aplicação são reutilizados para novas aplicações que derivarem da mesma linha. Sendo possível se beneficiar das vantagens do reuso, porém, se assume o risco de que caso a seleção dos casos de teste não seja bem realizada para a primeira aplicação, o problema irá se repetir nas novas aplicações, e possivelmente algumas funcionalidades não serão testadas.
Na terceira, e mais adequada estratégia [44], o processo de testes se assemelha ao pro-cesso de desenvolvimento de produtos em Linha de Produtos de Software, isto é, ocorre em duas atividades distintasi.e. Domain Testing, equivalente à Engenharia de Domínio eApplication Testing
