Pontifícia Universidade Católica do Rio Grande do Sul Faculdade de Informática Pós-Graduação em Ciência da Computação Análise de Casos de Teste Estatisticamente Relevantes Através da Descrição Formal de Programas Cristiano Bertolini Dissertação apresentada como requisito parcial à obtenção do grau de mestre em Ciência da Computação Orientador: Prof. Dr. Paulo Henrique Lemelle Fernandes Porto Alegre, janeiro de 2006
"Not Everything that counts can be counted, and not everything that can be counted counts." Albert Einstein
iii Resumo Este trabalho aborda a qualidade da geração estatística de casos de teste no teste estatístico através da descrição formal de programas. A principal contribuição consiste na proposta de uma métrica para o cálculo de índice de cobertura baseado em trajetórias; ou seja, é formalizada uma métrica que verifica a relevância de conjuntos de casos de teste. São utilizadas Cadeias de Markov (MC) e Redes de Autômatos Estocásticos (SAN) como métodos formais de descrição de modelos de uso, no sentido de verificar vantagens e desvantagens no processo de teste estatístico utilizado. No decorrer do trabalho, discute-se uma análise quantitativa da geração de casos de teste, bem como sua eficiência para os formalismos MC e SAN. Como resultado, são apresentadas uma análise quantitativa da geração de casos de teste e a evolução de resultados numéricos para a métrica proposta. Verificou-se com a análise quantitativa que a implementação em SAN apresentou uma pequena vantagem na geração de casos de teste. Com a métrica proposta pode-se avaliar tanto para SAN quanto para MC o índice de cobertura de uma determinada amostra de casos de teste.
iv Abstract This work focus on the quality of test case generation through the formal program description. The main contribution of this dissertation is a new metric to compute coverage test case index based on model trajectories. The proposed metric verifies the statistical relevance of a given set of test cases. Markov Chains (MC) and Stochastic Automata Network (SAN) are used as formal methods to describe usage models in order to investigate the benefits in the applied statistical testing process. It is discussed a quantitative analysis of the test cases generation and its efficiency to MC and SAN formalisms. As results of this work, it is presented a quantitative analysis of test case generation and a numerical evaluation to the metric coverage test case index.
Sumário RESUMO ABSTRACT LISTA DE TABELAS LISTA DE FIGURAS LISTA DE SÍMBOLOS E ABREVIATURAS iii iv viii ix x Capítulo 1: Introdução 1 Capítulo 2: Teste Estatístico 4 2.1 Teste de Software............................ 4 2.2 Técnicas e Processos de Testes..................... 5 2.3 Modelos de Uso............................. 6 2.3.1 Benefícios e Limitações dos Modelos de Uso no Teste Estatístico de Software...................... 8 2.4 Especificação Baseada em Modelos Formais.............. 8 2.4.1 Cadeias de Markov - MC.................... 9 2.4.1.1 Definição Formal................... 10 2.4.1.2 Definição Informal.................. 10 2.4.2 Redes de Autômatos Estocásticos - SAN........... 11 2.4.2.1 Definição Formal................... 11 2.4.2.2 Definição Informal.................. 13 Capítulo 3: Estudos de Caso 17 3.1 Exemplo: Sistema de Login....................... 17 3.2 Estudo de Caso 1: Simple Counter Navigation............ 20 v
SUMÁRIO vi 3.2.1 Descrição da Aplicação..................... 20 3.2.2 Modelo de Cadeia de Markov................. 21 3.2.3 Modelo SAN........................... 21 3.3 Estudo de Caso 2: Calendar Manager................. 24 3.3.1 Descrição da Aplicação..................... 24 3.3.2 Modelo de Cadeia de Markov................. 25 3.3.3 Modelo SAN........................... 26 3.4 Estudo de Caso 3: Docs Editor.................... 30 Capítulo 4: Geração Estatística de Casos de Teste 32 4.1 Ferramentas de Geração Estatística.................. 34 4.1.1 STAGE-Model......................... 35 4.1.2 STAGE-Test........................... 36 Capítulo 5: Análise Quantitativa 39 5.1 Diversidade de Geração......................... 39 5.2 Tempo de Geração........................... 41 Capítulo 6: Métricas de Qualidade 44 6.1 Qualidade de Test Suites........................ 44 6.1.1 Comparação Baseada em Transições.............. 45 6.1.2 Comparação Baseada em Eventos............... 46 6.2 Índice de Cobertura Baseado em Trajetórias............. 46 6.2.1 Probabilidade dos Casos de Teste............... 46 6.3 Exemplo: Sistema de Login....................... 49 6.4 Resultados................................ 53 Capítulo 7: Conclusões 57 7.1 Construção dos Modelos de Uso.................... 57 7.2 Geração dos Casos de Teste...................... 58 7.3 Métricas de Qualidade......................... 58 7.4 Trabalhos Futuros............................ 60 REFERÊNCIAS BIBLIOGRÁFICAS 62 Apêndice A: Probabilidades 67 A.1 Probabilidades Condicionais...................... 67
SUMÁRIO vii Apêndice B: Sistema de Login 69 B.1 Modelo PEPS.............................. 69 Apêndice C: Simple Counter Navigation 70 C.1 Modelo PEPS.............................. 70 Apêndice D: Calendar Manager 72 D.1 Modelo PEPS.............................. 72 Apêndice E: Docs Editor 75 E.1 Modelo PEPS.............................. 75 ÍNDICE REMISSIVO 78
Lista de Tabelas 3.1 Correspondência dos estados da MC: Sistema de Login........ 20 3.2 Correspondência dos estados da MC: Simple Counter Navigation.. 24 3.3 Correspondência dos estados da MC: Calendar Manager....... 29 6.1 Probabilidade dos estados atingíveis: Sistema de Login........ 50 6.2 Probabilidade dos casos de teste: Sistema de Login.......... 52 6.3 Valores - Simple Counter Navigation.................. 54 6.4 Valores - Calendar Manager....................... 55 6.5 Valores - Docs Editor.......................... 56 viii
Lista de Figuras 2.1 Exemplo de MC............................. 11 2.2 Exemplo SAN com dois autômatos independentes........... 13 2.3 Exemplo SAN de um evento sincronizante............... 14 2.4 Exemplo SAN utilizando taxa funcional................ 16 3.1 Sistema de Login............................. 18 3.2 Modelo MC: Sistema de Login...................... 18 3.3 Modelo SAN: Sistema de Login..................... 19 3.4 Modelo MC: Simple Counter Navigation................ 21 3.5 Modelo SAN: Simple Counter Navigation............... 23 3.6 Modelo MC: Calendar Manager..................... 26 3.7 Modelo SAN: Calendar Manager.................... 28 3.8 Modelo SAN: Docs Editor........................ 31 4.1 STAGE Framework............................ 34 4.2 STAGE-Model.............................. 35 4.3 STAGE-Test............................... 36 5.1 Análise de diversidade: Calendar Manager............... 40 5.2 Análise de diversidade: Docs Editor.................. 41 5.3 Análise de eficiência: Simple Counter Navigation........... 42 5.4 Análise de eficiência: Calendar Manager................ 42 5.5 Análise de eficiência: Docs Editor.................... 43 6.1 Índice de cobertura: Sistema de Login................. 53 6.2 Índice de cobertura: Simple Counter Navigation............ 54 6.3 Índice de cobertura: Calendar Manager................ 55 6.4 Índice de cobertura: Docs Editor.................... 56 ix
Lista de Símbolos e Abreviaturas MC Markov Chains 2 SAN Stochastic Automata Networks 2 UML Unified Modeling language. 9 FSM Finite State Machine 9 CTMC Continuous Time Markov Chain 10 HTML HyperText Markup Language. 20 JSP Java Server Pages 24 CPTS Centro de Pesquisa em Teste de Software. 32 STAGE State Based Test Generator 33 XML Extensible Markup Language 33 EMC Embedded Markov Chains 60 DTMC Discrete Time Markov Chains 60 x
Capítulo 1 Introdução Com a crescente demanda por sistemas de computação mais robustos, estes tornamse cada vez mais complexos e requerem um maior grau de precisão, por exemplo, sistemas web onde performance e confiabilidade são requisitos necessários para o sucesso desses sistemas e satisfação dos usuários [29]. Há uma crescente necessidade de software com alta confiabilidade e qualidade, como aplicações críticas, Web, médicas e outros sistemas de controle. Neste sentido, muitas formas de melhoria dos processos de desenvolvimento de software são utilizadas e diversos artefatos e ferramentas buscam melhorar o desenvolvimento, como a utilização de métodos formais para descrever requerimentos, especificações, designs e testes [1]. As inovações e melhorias dos processos de desenvolvimento de software ajudam a ter software com alta qualidade e de alta confiabilidade, mas continua a necessidade deles serem testados, o que significa que os métodos utilizados para testes devem ser eficientes para que problemas possam ser detectados e corrigidos antes de chegaram ao usuário final. Assim, métodos formais tornam-se uma boa abordagem a ser utilizada, podendo ser utilizados desde a fase de requisitos até a fase de teste [1,11]. Muitos sistemas atuais são expostos a uma quantidade exaustiva de testes na tentativa de minimizar possíveis falhas e, mesmo assim, a confiabilidade não é garantida na maioria dos casos. No entanto, nem sempre é possível realizar testes de forma exaustiva devido ao alto custo e tempo gasto; assim, necessitamos de técnicas que tornem a prática de testar viável e com bons resultados [48]. Muitas técnicas, conceitos e estilos de teste são descritos na literatura devido à popularização da orientação a objetos e modelos em engenharia de software. Assim, tem sido grande a utilização de teste de software baseado em modelos (model-based testing) [13], que possui como base um modelo formal da aplicação onde torna-se possível a geração de casos de teste. Considerando sistemas complexos, sistemas que necessitam de confiabilidade, ou sistemas que necessitam de uma quantidade de testes mais apurados, então 1
CAPÍTULO 1. INTRODUÇÃO 2 existe a necessidade de uma geração de casos de teste automática. Entre os benefícios da geração automática de testes pode-se citar a economia de tempo e recursos (pessoas). Adicionalmente, através da geração estatística de casos de teste, pode-se estimar a confiabilidade de um determinado sistema. Apoiado em técnicas tradicionais de teste de software, como o teste funcional e o teste estrutural, o teste estatístico compreende a aplicação da ciência estatística para a solução de problemas de teste de software [42]. A utilização de teste estatístico usualmente requer a utilização de procedimentos randômicos como procedimentos de amostragem, algoritmos randômicos ou construções randômicas [10]. Neste contexto, a utilização do teste estatístico deve-se apoiar em ferramentas que suportem todo este processo de teste. Outro fator importante na automatização do processo de teste estatístico é a forma como a aplicação é representada. Desta forma, são construídos modelos que buscam expressar a realidade de um sistema. Estes modelos além de representarem características do sistema podem ser utilizados na geração de casos de teste. Os formalismos para a construção de modelos adotados neste trabalho são as Cadeias de Markov (MC) [43], pela grande utilização na construção de modelos de uso, e as Redes de Autômatos Estocásticos (SAN) [36] que representam um formalismo mais sofisticado, onde os modelos são representados de forma modular e com isso torna-se mais fácil e viável a construção de modelos maiores. Tais formalismos utilizam a noção de "estado do sistema"e as transições levam a um novo estado do sistema. Em [14] é apresentada a primeira utilização das SAN no teste estatístico, assim, essa dissertação busca dar continuação a este trabalho focando em questões como métricas de qualidade no teste estatístico, visto que o trabalho, anteriormente realizado, apenas introduzia a utilização de SAN no contexto de teste estatístico. Para a consolidação do referencial teórico sobre os modelos de uso utilizando métodos formais (MC e SAN), três estudos de caso foram realizados. Nos estudos de caso buscou-se explorar a sua equivalência com as Cadeias de Markov através da construção da Cadeia de Markov correspondente a SAN, e a sua verificação através da ferramenta PEPS [6]. O intuito foi avaliar quantitativamente os casos de teste e verificar através de experimentos a eficiência da geração automática. A avaliação mostrou a eficiência na geração através da análise de tempo dos algoritmos de geração e a qualidade na geração através da diversidade de casos de teste gerados, ou seja, a cada novo conjunto de casos de teste gerados, casos de teste únicos eram gerados. Um dos pontos de investigação deste trabalho compreende a análise de métricas para o teste estatístico. Algumas métricas são propostas na literatura como técnicas de comparação de vetores para MC. No entanto, como essas técnicas correspondem a comparação das freqüências das transições dos modelos em MC, para SAN elas não se aplicam da mesma forma devido à semântica dada às transições
CAPÍTULO 1. INTRODUÇÃO 3 através dos eventos. Desta forma, também é proposta uma métrica de cálculo do índice de cobertura baseado em trajetórias, que é aplicada tanto para MC quanto para SAN. Os objetivos gerais desse trabalho são de consolidar a utilização de SAN para a construção de modelos de uso e propor uma métrica de análise de cobertura da geração de casos de teste baseada nas probabilidades dos estados do modelo. Os objetivos específicos correspondem a análise dos casos de teste gerados, traçando um comparativo entre MC e SAN; descrição do processo de teste utilizado na geração de casos de teste; e cálculo do índice de cobertura de cada caso de teste. Cabe ressaltar que o comparativo realizado teve como base uma ferramenta de geração estatística chamada STAGE que será apresentada no decorrer do trabalho. Este trabalho está estruturado da seguinte forma. O Capítulo 2 apresenta o referencial teórico sobre teste estatístico de software utilizando modelos de uso, bem como alguns formalismos existentes e utilizados no decorrer do trabalho. O Capítulo 3 apresenta os estudos de caso realizados. No Capítulo 4 é apresentado o processo de teste estatístico utilizado e as ferramentas de automação. No Capítulo 5 são apresentados os resultados numéricos para a análise quantitativa da geração de casos de teste. O Capítulo 6 apresenta a métrica de cálculo do índice de cobertura dos casos de teste. Por fim, são apresentados as conclusões e o referencial bibliográfico utilizado.
Capítulo 2 Teste Estatístico Este capítulo apresenta um embasamento teórico e um panorama histórico do uso de teste de software, enfocando no teste estatístico de software com a utilização de modelos de uso. Para tanto, divide-se em uma abordagem sobre teste de software em geral partindo para a definição de teste estatístico apoiado em modelos de uso. Logo após, são descritos alguns formalismos utilizados no teste estatístico de software para a geração de casos de teste. 2.1 Teste de Software Em um processo de desenvolvimento de sistemas, o ciclo de testes é responsável por garantir que o produto tenha sido construído com qualidade e para que sejam corrigidos erros de execução e especificação. A alta qualidade gerada é uma das principais motivações para se ter processos de teste de software bem definidos e eficientes. Alguns importantes conceitos que estão presentes nesta seção são confiabilidade e falhas. Confiabilidade em software pode ser definida como a probabilidade que o software não irá falhar durante o uso operacional [48]. Em [24] são apresentados definições diferentes para erro, falha e defeito: Falha (Fault): Corresponde a uma condição anômala, causada por erros de projeto, problemas de fabricação ou distúrbios externos. Uma falha em um sistema ocorre quando o comportamento deste sistema foge de sua normalidade, a qual é especificada na fase de projeto. Erro (Error): Corresponde à manifestação de uma falha no sistema, causando disparidade nas respostas apresentadas, que diferem do valor previsto. Defeito (Defect): Corresponde à incapacidade de algum componente em realizar a função para o qual foi projetado. 4
CAPÍTULO 2. TESTE ESTATÍSTICO 5 No entanto para fins de entendimento deste trabalho e por conveniência, assumese que erro, falha e defeito são sinônimos e ocorrem quando o software não é executado de acordo com sua especificação. Assim, segundo Myers [33] teste é o processo de executar um programa com a intenção de encontrar erros, isto é, aplicar processos de validação e verificação através da análise do software, buscando encontrar falhas de execução e funcionalidade. As atividades de testes podem compreender um esforço grande no desenvolvimento de um software, e muitas vezes não contemplam todas as funcionalidades e rotinas de execução. Várias estratégias podem ser empregadas para assegurar a correta execução do software. Em [40] são apresentadas três fases de teste: Teste de unidade (Unit testing): Nesta fase cada unidade que compõe o sistema é testada separadamente, desde que as unidades sejam pequenas (e possam ser testadas separadamente), buscando encontrar erros de especificação e implementação em cada unidade [25]. Teste de integração (Integration testing): Nesta fase as unidades são agrupadas formando subsistemas, por exemplo, interfaces. Os módulos são testados adicionando as unidades de forma incremental ao subsistema. Assim a unidade responsável por uma falha é mais facilmente identificada [25]. Teste de sistema (System testing): Nesta fase o objetivo é identificar erros de funções e características de desempenho que não estejam de acordo com a especificação [38]. Além dessas fases, em [30] duas outras fases são apresentadas, o teste de aceitação e o teste de regressão. O teste de aceitação tem por objetivo avaliar a confiabilidade e performance do sistema em um comportamento operacional, requer então uma coleção de informações sobre como o usuário gostaria de usar o sistema, o que é chamado de alfa teste, e muitas vezes seguido pelo beta teste que envolve a utilização do software pelos usuários. O teste de regressão é feito em uma nova versão para assegurar que não houve perda de confiabilidade, quando importantes adições ou modificações são feitas para uma versão existente. 2.2 Técnicas e Processos de Testes As técnicas de teste são classificadas de acordo com a origem da informação que é utilizada para estabelecer os requisitos de testes [40], e têm por objetivo encontrar falhas no software. As principais técnicas de teste são o teste funcional, o teste estrutural e o teste estatístico.
CAPÍTULO 2. TESTE ESTATÍSTICO 6 O teste funcional, conhecido também como caixa-preta (black-box), enxerga o sistema como uma caixa fechada onde não se tem conhecimento sobre sua implementação ou seu comportamento interno. No teste funcional os testes são gerados somente considerando os valores de entrada e saída do sistema utilizando como base a sua especificação [30]. O teste estrutural, também conhecido como caixa branca (white-box), estabelece os requisitos do software baseados na sua implementação. Sendo assim, a geração dos testes leva em conta as estruturas lógicas e funcionais implementadas, verificando se as funcionalidades e resultados gerados estão de acordo com a especificação [33]. Estas duas primeiras técnicas de teste são usualmente as mais utilizadas. Os testes funcionais são aplicados geralmente em testes de unidades, enquanto os testes estruturais são aplicados geralmente em testes de integração e testes de sistema [2]. O teste estatístico é visto como um excelente complemento para as técnicas de teste existentes podendo ser utilizado não como uma diferente técnica de testes, mas como uma técnica que visa somar confiabilidade às demais técnicas [20]. Portanto, o teste estatístico pode ser definido como a aplicação da ciência estatística para a solução de problemas de teste de software [42] e é desenvolvido para caracterizar a população que utiliza o software. 2.3 Modelos de Uso Os modelos de uso caracterizam-se pelo uso operacional do software e são baseados em especificações funcionais e no uso das especificações para o desenvolvimento do software. Assim todas as informações necessárias para desenvolver o modelo devem ser disponíveis antes do começo da implementação, o que torna os modelos de uso artefatos importantes para o desenvolvimento, por exemplo, de funções em termos de probabilidade de uso [48]. Também é apresentada uma metodologia para a criação de modelos de uso dividida em oito etapas [48], como segue: 1. Revisar a especificação do software: Nesta etapa a especificação do software é revisada e compreendida, para que o modelo de uso possa refletir o uso do software partindo de uma especificação funcional completa. 2. Identificar o uso do software, usuário e ambiente de uso: Nesta etapa é definido o ambiente operacional o qual o software vai ser aplicado [48]: Usuário: Compreende a entidade que interage com o software, e pode ser uma pessoa, um periférico ou outro sistema.
CAPÍTULO 2. TESTE ESTATÍSTICO 7 Uso: Compreende a maneira como o software é processado, e pode ser uma seção de trabalho, transações ou qualquer outra unidade de serviço. Ambiente: Compreende os fatores externos ao software que podem interferir no seu funcionamento, e pode ser interações com outros sistemas (banco de dados, dispositivos de E / S), plataforma, integridade de dados, necessidade de acessos simultâneos, etc. 3. Definir parâmetros de ambiente: Existe uma grande quantidade de combinações de valores para os parâmetros utilizados por um software, incluindo múltiplos estímulos aplicados simultaneamente. Nesta etapa são definidos os parâmetros que serão suficientes e que satisfaçam o sistema e contribuem para o desenvolvimento de modelos de uso de forma que estes se tornem simples e eficazes. 4. Determinar o nível de granularidade: A granularidade dos modelos de uso tendem a aumentar com seu custo de desenvolvimento e manutenção. Nesta etapa, para determinar os níveis de granularidade deve-se periodicamente analisar o custo de desenvolvimento e manutenção do modelo e os benefícios de se ter um teste de melhor qualidade. 5. Desenvolver a estrutura do modelo de uso: Os modelos de uso são compostos por eventos e transições entre os eventos, sendo que os eventos partem de um estado para outro. Nesta etapa o modelo de uso pode ser representado por um grafo, gramática formal, MC ou SAN. 6. Verificar se a estrutura do modelo de uso está de acordo com a especificação: Nesta etapa todos os parâmetros que afetam a estrutura dos modelos devem ser verificados, como classes de usuários e funções críticas do sistema, entre outros. 7. Desenvolver a distribuição da probabilidade para o modelo: Nesta etapa, para cada transição é definida uma probabilidade, e um conjunto de transições que definem a distribuição da probabilidade. Essa distribuição é a base para que o teste estatístico de software possa ser executado. 8. Verificar a distribuição da probabilidade: Nesta etapa é feita uma verificação da distribuição da probabilidade na tentativa de minimizar erros. Estas etapas incluem todos os passos necessários para a construção de um modelo de uso. No entanto, cabe ressaltar que um modelo de uso define apenas aspectos funcionais de um software, não considerando aspectos não funcionais ou estruturais do software modelado.
CAPÍTULO 2. TESTE ESTATÍSTICO 8 2.3.1 Benefícios e Limitações dos Modelos de Uso no Teste Estatístico de Software É notório que o teste estatístico baseado nos modelos de uso possui muitos benefícios, mas por outro lado, também possui algumas limitações. Como a modelagem é feita baseada em estados surge o problema da explosão dos estados, ou seja, modelos muito complexos que necessitam de uma modelagem com muitos estados pode tornar a sua construção impraticável. Este problema pode ser contornado adicionando uma maior abstração ao modelo, no entanto outro problema é gerado: A perda de informações [26]. Uma alternativa é a utilização de redes de autômatos estocásticos (SAN) que será discutida adiante. Há muitos benefícios no teste estatístico de software com modelos de uso; alguns podem ser vistos em [37], como: Fonte para estimativas de planejamento: Os resultados obtidos podem ser utilizados para estimar custo e tempo no desenvolvimento de novos software. Geração de testes automática: A utilização de modelos de uso torna-se ideal para a geração automática de testes, por exemplo, utilizando cadeias de Markov para a execução de testes estatísticos de software. Testes eficientes: Os testes tornam-se bem estruturados e contribuem para a obtenção de resultados mais eficientes. Gerenciamento quantitativo dos testes: Os resultados quantitativos dos testes acabam ajudando no gerenciamento e tomadas de decisão. Verificação de confiabilidade: Com a utilização dos modelos de uso as métricas de confiabilidade têm melhorado e, portanto, tornado as aplicações mais confiáveis. Cabe ressaltar que a utilização dos modelos de uso não garante todos os benefícios; algumas vezes alguns são mais enfatizados ou priorizados. Neste sentido, nesta dissertação os benefícios dos modelos de uso que buscou-se explorar foram a geração de testes automática, gerenciamento quantitativo dos casos de teste e verificação de confiabilidade. 2.4 Especificação Baseada em Modelos Formais Modelos são usados para compreender, especificar e desenvolver sistemas em muitas áreas [4]. No desenvolvimento de casos de teste e análise de confiabilidade estes modelos tornam-se muito interessantes, principalmente em sistemas complexos e
CAPÍTULO 2. TESTE ESTATÍSTICO 9 difíceis de serem testados exaustivamente [5]. O teste baseado em modelos significa representar as informações de um determinado sistema em um modelo. Há uma grande quantidade de modelos atualmente e cada um descreve diferentes aspectos do comportamento do software, como: Controle de fluxo, fluxo de dados, grafos, máquinas de estado, entre outros [13]. Atualmente os formalismos mais populares para a geração de casos de teste são baseados em estados, ou seja, os modelos utilizam-se de um conjunto de estados para a representação de um comportamento do sistema. Dentre os formalismos utilizados, é crescente a utilização dos modelos da UML, que substituem a simples representação de estilo gráfico por uma poderosa estrutura de linguagem. Portanto, UML é uma linguagem para construção de modelos de software dos mais simples até os mais complexos e vem sendo utilizada com muitos fins. Além da UML ser utilizada em diversas fases do desenvolvimento de sistemas, também podemos encontrar diversos trabalhos sobre teste baseado em UML, como, por exemplo, em [39] onde é proposto uma geração estatística de casos de teste baseada na utilização do diagrama de estados da UML. Como este trabalho representa uma continuação ao trabalho desenvolvido em [14], os modelos formais utilizados são as Cadeias de Markov (MC) e Redes de Autômatos Estocásticos (SAN). As MC são muito utilizadas na construção de modelos de uso para o teste estatístico, e as SAN possuem o mesmo poder de representação das MC, no entanto, de forma modular. Com isso, este trabalho não visa discutir outras formas de representação formal dos modelos de uso, mas busca explorar as MC e SAN no sentido de avaliar métricas e resultados na geração de casos de teste. A seguir, é apresentada uma descrição formal e informal dos modelos utilizados nesta dissertação, ou seja, as Cadeias de Markov e as Redes de Autômatos Estocásticos. 2.4.1 Cadeias de Markov - MC Uma máquina de estados finita (FSM) é representada por arcos que correspondem a transições que interligam estados. Cada transição contém o estado origem, um evento de entrada, saída ou uma ação e o próximo estado [5, 19]. Máquina de estados finitos também são conhecidas como autômatos finitos e são aplicadas para qualquer modelo que possa ser descrito com precisão por um número finito de estados e geralmente pequeno [13]. As FSM também são empregadas no teste de software como visto em [28]. Grafos são equivalentes a máquinas de estados finitos e modelam sistemas complexos e de tempo-real. Grafos fornecem um framework para especificar máquinas de estados em uma hierarquia, ou seja, um simples estado pode ser expandido em
CAPÍTULO 2. TESTE ESTATÍSTICO 10 outra máquina de estados e eles também agregam características especiais para máquinas de estados concorrentes [13]. As Cadeias de Markov (MC) são por sua vez uma extensão das máquinas de estados e grafos onde as transições possuem taxas ou probabilidades. 2.4.1.1 Definição Formal Considera-se a formalização de um modelo em Cadeias de Markov a Escala de Tempo Contínuo 1 (CTMC - Continuous Time Markov Chain) compreendendo um conjunto finito de estados e transições. Dado um conjunto finito E de estados, uma MC é definida como: Onde: (E,T x,y ) E = E 1,E 2,...,E n representa um conjunto de estados, onde n é um número inteiro, positivo e finito. T x,y representa uma taxa (não nula) de ocorrência de uma transição do estado E x para o estado E y. Outra definição formal das MC pode ser encontrada em [49]. 2.4.1.2 Definição Informal Um processo estocástico é definido como um conjunto de variáveis randômicas definidas em um espaço de probabilidade e indexadas por um parâmetro t, onde t representa um intervalo de tempo que pode variar de (, + ). Os valores assumidos pelo conjunto de variáveis randômicas são chamados de estados. O processo estocástico é discreto quando o intervalo de tempo é discreto e, portanto chamado de processo estocástico discreto, (ex. T = (0, 1, 2,...)). O processo estocástico é contínuo quando o intervalo de tempo é contínuo, e chamado de processo estocástico contínuo (ex. T = (0 t + )) [43]. O processo estocástico é definido como estacionário quando independe de mudanças do tempo inicial. Portanto, processo Markoviano é um processo estocástico quando é caracterizado por não possuir memória em relação ao passado do sistema, isto é, somente o estado atual do sistema pode influenciar no próximo estado [34]. Os estados em um processo Markoviano representam o estado do software. As ações executadas pelos usuários do sistema são definidas como transições entre 1 Nos modelos em CTMC as transições entre os estados podem ocorrer em qualquer instante de tempo [43].
CAPÍTULO 2. TESTE ESTATÍSTICO 11 os estados (representadas por arcos). Assim, as MC são definidas como modelos matemáticos para a resolução de fenômenos randômicos em um tempo. Esse tempo é considerado discreto e possui um número de estados finitos e enumeráveis. As MC no contexto de modelos de uso podem ser descritas em duas fases de construção: A fase estrutural onde os estados e arcos da cadeia são definidos, e a fase estatística onde são atribuídas as probabilidades de transições. Como visto na Figura 2.1, o modelo pode ser descrito em um alto nível de abstração. Por exemplo, em uma aplicação o modelo possui um estado inicial (Invocation) e um estado final (Termination). O estado de uso (Usage) representa um conjunto de estados que determina as ações executadas no software em questão [50]. Invocation Usage Termination Figura 2.1: Exemplo de MC. A utilização das MC como um modelo para a geração de casos de teste é bastante difundida na literatura, podendo ser encontrados diversos trabalhos [3, 45 47,51]. 2.4.2 Redes de Autômatos Estocásticos - SAN As SAN foram propostas por Plateau [36] e consistem em um conjunto de subsistemas representados por autômatos estocásticos e a interação entre os subsistemas é feita através de regras estabelecidas entre os estados internos de cada autômato. As SAN são muito apropriadas para a modelagem de sistemas paralelos e distribuídos que podem, muitas vezes, ser vistos como coleções de componentes que atuam de forma independente, requerendo somente eventuais interações como ações sincronizadas [36]. 2.4.2.1 Definição Formal A descrição formal aqui apresentada é dada de forma diferente da descrição formal apresentada nos trabalhos de Fernandes e Plateau [16,17,35,36]. Dados n conjuntos S i de estados (estados locais), uma SAN é definido a partir de A = {A 1,A 2,...A n } sendo um conjunto de autômatos, onde cada autômato A i é composto por estados de S i. Uma SAN é uma estrutura: (G,E,R,P,I)
CAPÍTULO 2. TESTE ESTATÍSTICO 12 Onde: G = {G 1,G 2,...G m } é um conjunto de estados globais, tal que cada G i é um elemento de A 1 A2 A n. Em outras palavras, cada estado global é uma combinação de estados locais de um autômato. E = {E 1,E 2,...E k } é um conjunto de eventos. Cada evento é uma função E i : G P(G). Ou seja, cada evento mapeia estados locais em conjuntos de estados globais. Quando um evento é disparado, a SAN pode ir para qualquer elemento do conjunto especificado por uma função, dependendo das probabilidades associadas ao evento. Assumindo que um estado global é uma lista de estados locais, a função descreve para cada autômato A i em uma rede, o que acontece no autômato quando o evento é disparado. Eventos podem ser classificados como locais e sincronizantes. Um evento local muda o estado de somente um autômato e um evento sincronizante muda o estado de dois ou mais autômatos. R = {R 1,R 2,...R k } é um conjunto de taxas funcionais, uma para cada evento. Cada função R i : G R + descreve a taxa de ocorrência do evento de cada estado global. P = {P 1,P 2,...P k } é um conjunto de funções de probabilidade de transição (possivelmente vazio), um para cada tupla (evento, estado global). Como definido acima, para um evento i, quando a SAN está em um estado global G i e o evento é disparado, a SAN vai para o estado G j o qual deve ser um elemento de E i (G i ). A função de probabilidade de transição descreve a probabilidade de diferentes elementos de E i (G i ) estarem selecionados. Usualmente, E i (G i ) tem somente um estado, então a definição dessa probabilidade é opcional. I G é um conjunto (possivelmente vazio) de estados iniciais. Na definição original SAN não possui um estado inicial, mas um conjunto de estados atingíveis. A definição de estados iniciais é útil em modelos de uso, e não muda o formalismo SAN. Qualquer SAN pode ser convertida em uma MC correspondente [16]. Os estados da MC correspondem aos estados globais da SAN. As SAN têm demonstrado um grande número de vantagens para a modelagem de sistemas complexos em comparação com as MC [18, 41]. Para o teste estatístico baseado em modelos de uso as vantagens também são evidentes e os modelos SAN são construídos sem perda de informações. Modelos de uso descritos com SAN têm algumas características interessantes [15]:
CAPÍTULO 2. TESTE ESTATÍSTICO 13 requisitos do ambiente podem ser explicitamente modelados, por exemplo, servidores, comunicação entre ambientes diferentes, etc; a representação é modular, melhorando a manutenção e leitura do modelo; um uso individual é uma seqüência de estados globais em uma SAN, assim, sua descrição é mais detalhada, o que torna simples o mapeamento de uso em casos de teste. 2.4.2.2 Definição Informal Como mencionado, no formalismo SAN os estados globais são definidos como a combinação de estados de cada autômato, chamados estados locais. Na Figura 2.2 pode ser visto um exemplo de um modelo SAN com dois autômatos completamente independentes. A (1) A (2) x (1) u (2) e 3 e 1 z (1) y (1) e 5 e 4 e 2 w (2) Tipo Evento Taxa Tipo Evento Taxa Loc e 1 τ 1 Loc e 4 τ 4 Loc e 2 τ 2 Loc e 5 τ 5 Loc e 3 τ 3 Figura 2.2: Exemplo SAN com dois autômatos independentes. O autômato A (1) possui três estados locais (x (1), y (1), z (1) ). O autômato A (2) possui dois estados locais (u (2), w (2) ). Os eventos nesse exemplo são considerados locais, pois cada evento altera apenas o estado de um autômato. Por exemplo, caso o autômato A (1) encontre-se no estado x (1) e o autômato A (2) encontre-se no estado u (2), o autômato A (1) pode passar do estado x (1) para y (1), conforme o evento e1, independente em que estado o autômato A (2) se encontre. O estado local de um autômato em um tempo t é justamente o estado em que ele ocupa no tempo t, e o estado global em um tempo t é dado pelo estado local em cada um dos autômatos da SAN ocupa neste mesmo tempo t. Seguindo o exemplo
CAPÍTULO 2. TESTE ESTATÍSTICO 14 da Figura 2.2 alguns estados globais são x (1) u (2), y (1) u (2), y (1) w (2), z (1) w (2), y (1) u (2). Há basicamente duas formas que as SAN interagem [44]: A taxa em que uma transição pode ocorrer em um autômato pode ser uma função de um estado de outro autômato. Assim transições são chamadas de taxas funcionais. Transições que não são funcionais são chamadas de constantes. Uma transição em um autômato pode forçar a ocorrência de uma transição em um ou mais autômatos. Este tipo de transição é dita como transições sincronizantes. Uma transição sincronizante também pode ser representada por uma taxa funcional ou constante. Em uma rede de autômatos estocásticos os estados dos autômatos podem sofrer mudanças. Quando um evento local muda de estado sem interferir no estado dos demais autômatos, o evento é chamado de evento local. Quando um evento muda não somente o seu estado, mas também o estado de outros autômatos simultaneamente, então é chamado de evento sincronizante. Na Figura 2.3 observamos o evento sincronizante s que representa transições disparadas simultaneamente nos autômatos A (1) e A (2), onde uma alteração no estado global do modelo ocorre através de uma alteração nos estados locais de ambos os autômatos. Também podemos observar no exemplo os eventos locais e1, e2, e3 do autômato A (1), e e4 do autômato A (2) que representam as transições que ocorrem no seu autômato através da alteração no estado local do autômato. A (1) A (2) x (1) u (2) sπ 1 e 1 e 3 sπ 2 s e 4 z (1) y (1) e 2 w (2) Tipo Evento Taxa Tipo Evento Taxa Loc e 1 τ 1 Loc e 4 τ 4 Loc e 2 τ 2 Syn s τ 5 Loc e 3 τ 3 Figura 2.3: Exemplo SAN de um evento sincronizante. Um evento sincronizante é associado a um conjunto de no mínimo duas transições. As transições sincronizantes possuem estruturas chamadas tripla de sin-
CAPÍTULO 2. TESTE ESTATÍSTICO 15 cronização que é definida por um identificador do evento sincronizante, uma taxa de disparo e uma probabilidade de ocorrência [17]: Nome do evento sincronizante: É o identificador do evento, onde cada evento sincronizante possui um nome único identificando que a transição ocorre simultaneamente. Taxa de disparo: É a taxa em que o evento ocorre. A taxa é apresentada apenas em um autômato, sendo omitida dos demais (π 1 e π 2 na Figura 2.3). Probabilidade de ocorrência: Cada transição que sai de um mesmo estado local recebe uma probabilidade de ocorrência, sendo que essas transições não ocorrem simultaneamente e a soma das probabilidades é igual a um. Considerando os tipos de eventos, locais e sincronizantes, podemos ter taxas constantes apresentadas como números reais não negativos, e taxas funcionais representadas por uma função para um único número real não negativo. As taxas funcionais e os eventos sincronizantes representam as duas formas de interação entre autômatos em uma SAN [44]. Os estados da SAN indicam qual é a taxa utilizada no momento da transição. No exemplo da Figura 2.4, o autômato A (2) apresenta, além do evento local l4, a taxa funcional f, definida como: λ1 se A (1) estiver no estado x (1) f = 0 se A (1) estiver no estado y (1) (2.1) λ2 se A (1) estiver no estado z (1) Assim, a transição do estado u (2) para o estado w (2) irá ocorrer com a taxa de λ 1 se o autômato A (1) estiver no estado x (1). Se o se o autômato A (1) estiver em z (1) a taxa de transição será de λ2. Caso o autômato A (1) esteja no estado y (1), a transição u (2) para w (2) não irá ocorrer, portanto com taxa igual a zero. Neste exemplo, a taxa funcional está sendo utilizada com um evento local, porém ela não está limitada a apenas eventos locais, podendo ser utilizada com eventos sincronizantes. As SAN representam uma importante ferramenta de modelagem que se torna muito útil principalmente para sistemas paralelos e distribuídos. Estes sistemas podem dispor de muitos estados e, portanto, a sua representação utilizando MC pode resultar no problema de explosão de estados. Além disso, tais sistemas freqüentemente podem ser vistos como módulos ou coleções de componentes e, portanto, o aspecto modular que as SAN agregam acaba sendo uma importante vantagem frente às MC [44].
CAPÍTULO 2. TESTE ESTATÍSTICO 16 A (1) A (2) x (1) u (2) e 1 sπ 1 e 3 sπ s 2 e 4 z (1) y (1) e 2 w (2) Tipo Evento Taxa Tipo Evento Taxa Loc e 1 τ 1 Loc e 4 f Loc e 2 τ 2 Syn s τ 5 Loc e 3 τ 3 Figura 2.4: Exemplo SAN utilizando taxa funcional.
Capítulo 3 Estudos de Caso Este capítulo descreve os estudos de caso realizados com a finalidade de evoluir alguns resultados numéricos na geração estatística de casos de teste. Um pequeno exemplo de um sistema de login é apresentado por completo, demonstrando todo o processo de construção de um modelo de uso. O primeiro estudo de caso referese à aplicação Simple Counter Navigation, que corresponde a uma aplicação de navegação entre páginas Web. Para o segundo estudo de caso utilizou-se a aplicação Calendar Manager, que se caracteriza por um sistema de gerenciamento do calendário acadêmico, com funcionalidades de edição de calendários e seus respectivos eventos. No terceiro estudo de caso, modelou-se a aplicação Docs Editor que consiste em um editor de planos de teste. 3.1 Exemplo: Sistema de Login Considere um simples sistema de login com dois diálogos: O primeiro é o diálogo de login (Figura 3.1a), onde o usuário entra com seu nome e senha; se o nome e senha estiverem incorretos, a aplicação apresenta uma mensagem de erro (Figura 3.1b); o segundo diálogo apresenta um menu onde o usuário pode simplesmente sair da aplicação (Figura 3.1c). Na Figura 3.2, a Cadeia de Markov (MC) equivalente descreve a aplicação com 4 estados e 7 transições. Cada estado corresponde a: Estado Start: Representa o estado inicial da aplicação. Quando a transição com taxa τ 1 é executada a aplicação é iniciada. Estado Password: Representa a tela de validação do nome e senha (Figura 3.1a). Estando neste estado a aplicação pode passar para o estado PNotOK com uma taxa de transição τ 5 ou para o estado menu executando a taxa de 17
CAPÍTULO 3. ESTUDOS DE CASO 18 Invalid Username/Password Valid Username/Password (b) (a) (c) Figura 3.1: Sistema de Login. τ 3. Se a transição com taxa τ 2 é executada a aplicação é finalizada voltando para o estado inicial. Estado PNotOK: Representa a mensagem de erro (Figura 3.1b). Executando a transição com taxa τ 4 a aplicação volta para o estado Password. Se a transição com taxa τ 2 é executada a aplicação é finalizada voltando para o estado inicial. Estado Menu: Representa o menu da aplicação (Figura 3.1c). Quando a transição com taxa τ 2 é executada a aplicação é finalizada voltando para o estado inicial. Start τ 2 τ 2 τ 2 τ 1 Menu τ 3 Password τ 5 τ 4 PNotOK Figura 3.2: Modelo MC: Sistema de Login. Na Figura 3.3 esta mesma aplicação é descrita por uma SAN com dois autômatos representando em que tela estamos e qual o status da tela. Neste modelo temos cinco eventos possíveis: Evento ST: Representa o início da execução, ou seja, a alteração do estado inicial [Start, Waiting] para o estado global [Password, Waiting].
CAPÍTULO 3. ESTUDOS DE CASO 19 Evento QT: Representa o fim da execução por interrupção ou término normal, ou seja, a alteração do estado [Password, Waiting] para [Start, Waiting] ou estado [Menu, Waiting] para [Start, Waiting] ou estado [Menu, POK] para [Start, Waiting]. Evento S: Representa a entrada de um usuário no sistema, ou seja, a alteração do estado [Password, Waiting] para [POK, Menu]. Evento l 1 : Representa um usuário inválido, ou seja, a alteração do estado [Password, Waiting] para [Password, PNotOk]. Evento l 2 : Representa a saída da mensagem de erro e retorno para a tela de login, ou seja, a alteração do estado [Password, PNotOk] para [Password, Waiting]. QT W indows Start Menu QT S ST Password Tipo Evento Taxa PNotOK Status l 1 l 2 ST QT S Waiting Tipo Evento Taxa QT Sync ST 2.0 Sync S 1.5 Sync QT 0.1 Loc l 2 1.0 Loc l 1 f f = [st Windows == Password] 0.5 POK Figura 3.3: Modelo SAN: Sistema de Login. ST, QT e S são eventos sincronizantes, enquanto l 1 e l2 são locais. O evento local l 1 tem uma taxa funcional f. Segundo a definição de f, este evento só poderá ocorrer quando o autômato Windows estiver no estado Password. Observa-se que o modelo SAN possui nove estados globais onde apenas quatro são atingíveis (Tabela 3.1). Neste sentido, o modelo SAN acaba não se tornando mais compacto que seu modelo equivalente MC. Mesmo assim, o objetivo em apresentar esse modelo é o entendimento de como as aplicações são modeladas. As taxas reais para os modelos de uso são obtidas por logs de usuários, ou seja, a aplicação é monitorada por um determinado período de tempo e os logs gerados são convertidos em taxas. Desta forma, a aplicação é utilizada por um tempo arbitrário e então logs contendo informações de uso (links visitados, formulários preenchidos, etc) são gerados. O percentual de ocorrência de transições (MC) ou eventos (SAN) é interpretado como taxa de ocorrência. Por exemplo, se o evento
CAPÍTULO 3. ESTUDOS DE CASO 20 Tabela 3.1: Correspondência dos estados da MC: Sistema de Login. SAN - Estado global MC - Estado (Start, Waiting) Start (Start, PNokOK) (Start, POK) (Password, Wainting) Password (Password, PNokOK) PNotOK (Password, POK) (Menu, Waiting) (Menu, PNokOK) (Menu, POK) Menu S ocorre dez vezes em um total de vinte vezes, logo, sua taxa é igual à 0.5. Um exemplo desse processo pode ser visto em [29]. 3.2 Estudo de Caso 1: Simple Counter Navigation Para o primeiro estudo de caso utilizou-se uma aplicação chamada Simple Counter Navigation a qual foi desenvolvida pelo CPTS. Primeiramente é apresentada uma descrição da aplicação, e logo após seu modelo MC seguido pelo modelo SAN equivalente. 3.2.1 Descrição da Aplicação A aplicação consiste em páginas HTML e JavaScript. A aplicação é apresentada da seguinte forma: Tela Inicial (estado Start): Apresenta o início da aplicação e possui dois links: link NEXT1 que vai para a próxima janela e link CLOSE que fecha a aplicação. Janela 1 (estado main): Apresenta uma única opção disponível e o link NEXT2 para a janela 2. Janela 2 (estado win01): Apresenta dois links para caminhos diferentes. No link CAMINHO1 a aplicação retorna a tela inicial, e no link CAMINHO2 a aplicação passa para a janela 3.
CAPÍTULO 3. ESTUDOS DE CASO 21 Janela 3 (estados win03 0 1, win01 0 1, win03 0 2, win04 0 2, win03 0 3): Apresenta um contador com valor inicial igual a 0 e cada vez que o link NEXT5 é acionado, a aplicação passa para a janela 4, onde o contador é incrementado. Quando o contador tiver o valor 2 a próxima vez em que o link NEXT5 for acionado a aplicação retorna a tela inicial. Janela 4 (estado win02): Apresenta a última tela da aplicação onde é possível voltar para a tela inicial através do link NEXT7 ou retornar a tela anterior através do link BACK. 3.2.2 Modelo de Cadeia de Markov O modelo MC para a aplicação Simple Counter Navigation possui nove estados conforme apresentado na Figura 3.4. ST main LV L2 win02 start QT L1 win01 T S L3 win03_01 win04_01 L4 V win03_02 T L5 V L6 win04_02 T win03_03 Figura 3.4: Modelo MC: Simple Counter Navigation. 3.2.3 Modelo SAN O modelo de uso da aplicação considera os seguintes elementos: A aplicação ativa e não ativa. A navegabilidade da aplicação, ou seja, as telas e as opções (links) de navegação disponíveis ao usuário. O contador existente na janela 3.
CAPÍTULO 3. ESTUDOS DE CASO 22 Sendo assim, foram definidos três autômatos para a aplicação: Autômato Application: Representa o início da aplicação (estado run) e o fechamento da aplicação, fazendo a aplicação voltar a um estado inicial start. Autômato Navigation: Representa as possibilidades de navegação entre as telas da aplicação. Autômato Count: Representa o contador da aplicação. O modelo SAN apresentado na Figura 3.5 possui cinco eventos sincronizantes e sete eventos locais, possuindo um total de 60 estados, sendo que apenas 9 são atingíveis. Na situação inicial da aplicação (tela inicial), ela encontra-se no estado run do autômato Aplication, estado main do autômato N avigation e no estado start do autômato Cont. Os eventos sincronizantes são: Evento ST: Ocorre quando a aplicação é iniciada passando do estado start, start, start para o estado run,main,start. Evento QT: Ocorre quando a aplicação é encerrada, ou seja quando o usuário acionar o link CLOSE na tela inicial. Evento S: Ocorre quando a aplicação passa para a tela onde possui o contador (Janela 3). Evento V e T: Ocorrem quando o usuário volta para a tela inicial. Os eventos locais são: Evento L 1 : Ocorre quando a aplicação passa do estado main para o estado win01 do autômato Navigation. Evento L 2 : Ocorre quando a aplicação passa do estado win01 para o estado win02 do autômato Navigation. Evento L 3 : Ocorre quando a aplicação passa do estado win03_01 para o estado win04_01 do autômato Cont. Evento L 4 : Ocorre quando a aplicação passa do estado win04_01 para o estado win03_02 do autômato Cont. Evento L 5 : Ocorre quando a aplicação passa do estado win03_02 para o estado win04_02 do autômato Cont.
CAPÍTULO 3. ESTUDOS DE CASO 23 Aut Aplication (AA) ST start QT run Aut Navigation (AN) main ST LV L2 win02 start QT L1 win01 V T S win03 Aut Cont (AC) T T ST S f win03_01 win04_01 win04_02 start T L3 L4 L5 L6 win03_02 win03_03 V V Figura 3.5: Modelo SAN: Simple Counter Navigation. Evento L 6 : Ocorre quando a aplicação passa do estado win04_02 para o estado win03_03 do autômato Cont. Evento LV : Ocorre quando a aplicação passa do estado win02 para o estado main do autômato Navigation. Logo após, foi gerada a descrição textual do modelo SAN conforme apresentada no Apêndice C. Tal descrição é utilizada para a obtenção das probabilidades dos estados que serão utilizadas para o cálculo da métrica. O modelo SAN corresponde a MC apresentada na Tabela 3.2, onde observa-se a equivalência dos estados da MC para o formalismo SAN.