3.4 Técnicas e critérios de teste para serviços
3.4.3 Monitoração
Segundo Canfora e Di Penta (2006), a falta de controle sobre os serviços que compõem uma aplicação é uma dificuldade encontrada pelos integradores de aplicações uma vez que os serviços podem ser alterados pelos seus fornecedores sem prévia notificação. As mudanças sofridas pelos serviços podem ser perfectivas, corretivas ou adaptativas, mas durante este processo é possível que a qualidade do serviço seja deteriorada, tanto em termos de requisitos funcionais quanto em termos de requisitos não funcionais e propriedades de contratos estabelecidas com os integradores. Dessa forma, os integradores precisam utilizar técnicas de monitoração para continuar verificando a qua- lidade dos serviços utilizados na aplicação ao invés de testá-los apenas durante o desenvolvimento da aplicação (Canfora e Penta, 2009).
A monitoração dos serviços de uma aplicação pode ser feita de forma passiva ou ativa (Britte- nham, 2003). A monitoração passiva consiste em interceptar as mensagens trocadas entre o serviço e a aplicação para verificar se as propriedades estabelecidas em contrato continuam sendo atendi- das. A monitoração ativa é baseada na execução de casos de teste com o objetivo de verificar a qualidade do serviço em tempo de execução. Uma forma popular de implementar uma estratégia de monitoração ativa é o uso de testes de regressão (Canfora e Penta, 2009). Classicamente, o teste de regressão é utilizado para verificar se um programa continua funcionando adequadamente após uma mudança conhecida. Em geral testa-se apenas a parte do software que foi modificada e as partes afetadas pela mudança. Nas estratégias de monitoração o teste de regressão tem sido
CAPÍTULO 3. TESTE DE SERVIÇOS 31 usado com o objetivo de descobrir as mudanças sofridas pelos serviços com base nos resultados dos casos de teste.
Um dos problemas de usar o teste de regressão para descobrir se o serviço mudou é que po- dem existir custos associados à execução dos casos de teste. Alguns serviços são cobrados por invocação ou possuem quota de invocação. A quota de invocação refere-se a uma quantidade de chamadas que pode ser feita para o serviço em um determinado período. Se a quota for ultrapassada é possível que seja lançada alguma exceção na interação com o serviço ou então o serviço deixa de atender às chamadas recebidas de quem excedeu a quota (Hou et al., 2008). Por este motivo é recomendável que sejam executados poucos casos de teste para esta atividade e não é recomendá- vel que eles sejam executados frequentemente (Canfora e Penta, 2006; Canfora e Di Penta, 2006; Hou et al., 2008).
Várias abordagens de monitoração foram encontradas na literatura. Na Tabela 3.3 são apresen- tados alguns trabalhos referentes à estratégia de monitoração ativa de propriedades funcionais dos serviços e que são baseados em teste de regressão. Na primeira coluna da tabela é identificado se a abordagem refere-se à estratégia ativa ou passiva. Algumas abordagens são classificadas como pas- siva e ativa, pois são abordagens que monitoram alguma propriedade para saber se houve alguma mudança antes de executar os casos de teste de regressão. A segunda coluna refere-se ao recurso utilizado pela abordagem para identificar as modificações. Na terceira coluna são apresentados os autores da abordagem.
Tabela 3.3: Abordagens de monitoração
Estratégia Recurso Autores
Ativa Resultados dos casos de teste Bruno et al. (2005a)
Passiva/Ativa Grafo Lin et al. (2006)
Passiva/Ativa Grafo Ruth et al. (2007)
Passiva/Ativa BPEL Liu et al. (2007)
Passiva/Ativa Resultados de casos de teste Denaro et al. (2007) Passiva Propriedades funcionais/não funcionais Baresi et al. (2007)
Passiva/Ativa BFG Wang et al. (2008)
Passiva/Ativa XBFG Li et al. (2010)
Passiva Log/invariantes Andrés et al. (2011)
Passiva/Ativa Outros Nguyen et al. (2011)
Bruno et al. (2005a) propuseram o uso de casos de teste como uma forma de estipular contratos entre provedores e consumidores de serviços. Essa forma de contrato permite que os consumido- res realizem testes de regressão para garantir que novas versões dos serviços utilizados continuam atendendo aos requisitos e contratos estipulados. Os casos de teste são publicados pelos fornece- dores dos serviços como parte de sua descrição. Os consumidores podem utilizar os casos de teste disponíveis e estendê-los. Os integradores devem executar periodicamente os casos de teste para descobrir se alguma mudança ocorreu na implementação do serviço..
CAPÍTULO 3. TESTE DE SERVIÇOS 32 Denaro et al. (2007) propuseram uma abordagem de composição de serviços autoadaptativas, baseada em mecanismos para a adaptação dinâmica das aplicações. A solução é apoiada por uma ferramenta que dispara um monitor quando algum serviço é invocado para verificar se a sua im- plementação mudou desde a última invocação. Se houve mudança, um mecanismo de diagnóstico é ativado para executar um conjunto de casos de teste para revelar possíveis problemas. Se ocorrer algum problema, existem mecanismos para tentar resolvê-los, seja pela notificação do fornecedor seja pela substituição do serviço defeituoso.
Baresi et al. (2004), Baresi e Guinea (2005), L. Baresi e Spoletini (2007) e Baresi et al. (2007) propuseram uma arquitetura simples que permite a criação de processos BPEL instrumentados por meio de anotações específicas. Os processos instrumentados interagem com um proxy específico para ativar as atividades de monitoração e permitir configurar dinamicamente o nível de monito- ração desejado. O ambiente projetado chama-se Dynamo e é utilizado para verificar se o sistema se comporta corretamente e se as propriedades funcionais e não funcionais são atingidas. Além disso, o Dynamo possui estratégias de reação e recuperação se algum erro ocorrer. Nesse ambiente, os integradores podem criar processos BPEL que tratam apenas dos requisitos funcionais sem se preocuparem em introduzir atividades de monitoração, pois é possível definir a regras de monito- ração externamente. As regras de monitoração definem o que os integradores querem controlar, como controlar e como reagir em situações em que restrições são violadas. Os integradores podem definir o local em que deve haver monitoração, prés- e pós-condições que devem ser atendidas e estratégias de reação. Essas regras podem ser especificadas por linguagens de asserção utilizadas no Dynamo.
Nguyen et al. (2011) propõem uma abordagem de seleção de casos de teste com base na obser- vação de documentos que contêm informações sobre as mudanças ocorridas nos serviços. Esses documentos são disponibilizados pelos próprios serviços e podem ser utilizados para rastrear quais casos de teste estão relacionados a quais partes do serviço. Sempre que o serviço é alterado esse documento também muda e é possível então selecionar os casos de teste adequados para exercitar as partes do serviço que precisam ser testadas porque foram afetadas pelas mudanças.
Rothermel e Harrold (1997) e Harrold et al. (2000) propuseram uma abordagem para selecio- nar e minimizar o número de casos de teste usados no teste de regressão de programas monolíticos e de componentes, respectivamente. O código do programa ou do componente é mapeado para um grafo de fluxo de controle que é usado para identificar em que partes do código ocorreu alguma mudança. As mudanças são identificadas em termos de nós e arestas do grafo que foram modifi- cados. Quando ocorre alguma mudança, são selecionados somente os casos de teste de regressão cujo caminho de execução inclui algum dos nós ou arestas afetados na mudança.
Os trabalhos de Rothermel e Harrold (1997) e Harrold et al. (2000) foram utilizados em abor- dagens cuja proposta é monitorar um serviço isolado (Lin et al., 2006; Ruth et al., 2007) ou uma aplicação baseada em serviços (Liu et al., 2007; Wang et al., 2008; Li et al., 2010; Chen et al., 2010). Entre as abordagens para monitorar um serviço isoladamente, Lin et al. (2006) propõem usar, além dos nós e arestas, um código hash de cada nó para identificar mudanças que não cau-
CAPÍTULO 3. TESTE DE SERVIÇOS 33 sam impacto na estrutura do grafo. Tanto nos trabalhos de Lin et al. (2006) quanto o de Ruth et al. (2007) os autores afirmam que a abordagem proposta não pode ser diretamente aplicada aos serviços porque o código fonte não está disponível. A solução encontrada por Lin et al. (2006) foi utilizar os esqueletos de código e simuladores gerados pelas tecnologias de invocação fornecidos pela plataforma Java para gerar um grafo de fluxo de controle que representa o serviço monitorado. Nas abordagens de monitoração de composições de serviços o grafo de fluxo de controle é construído a partir das interações entre os serviços e a aplicação, em que os serviços são os nós e as comunicações são as arestas. Alguns autores propuseram a adição de pesos para as arestas para priorizar a seleção dos casos de teste (Chen et al., 2010) e outros propuseram a geração de um grafo de fluxo específico para processos BPEL (BFG - BPEL Flow Graph) (Wang et al., 2008; Li et al., 2010).
As abordagens de monitoração baseadas na execução de casos de teste também são limitadas pela baixa testabilidade dos serviços. As abordagens baseadas no trabalho de Rothermel e Harrold (1997) e Harrold et al. (2000) sao adequadas para identificar mudanças nos serviços sem executar casos de teste. Após as mudanças serem identificadas, apenas um número reduzido de casos de teste são executados, o que é um grande benefício considerando os custos envolvidos na invocação das operações dos serviços monitorados (Hou et al., 2008). A limitação dessas abordagens é que elas não podem ser aplicadas a serviços porque o código deles não está disponível para que sejam gerados os grafos de fluxo de controle. Segundo Bozkurt et al. (2012), essas abordagens só podem ser usadas pela perspectiva dos desenvolvedores.
3.5
Considerações finais
O desenvolvimento baseado em serviços influenciou consideravelmente os conceitos de negó- cio da indústria de software, mas a adoção desse estilo de desenvolvimento pelos fabricantes de software ainda está em um ritmo mais lento (Bozkurt et al., 2012). Um dos impedimentos para a ampla adoção da arquitetura orientada a serviços é a falta de confiança nos serviços fornecidos por terceiros. O teste de software é uma das formas de ganhar confiança nos serviços utilizados. O teste de serviços envolve, segundo Canfora e Penta (2009), aplicar teste funcional (dos requisitos funcionais), teste não funcional, teste de integração e teste de regressão (monitoração).
Testar um serviço, entretanto, é uma tarefa desafiadora porque ele possui baixa testabilidade e alto dinamismo. A testabilidade dos serviços é influenciada por três fatores principais: a perspec- tiva de quem os usa, a forma de distribuição e o custo. Em geral o fator determinante para a baixa testabilidade é a forma de distribuição, pois serviços são tipicamente fornecidos como caixa-preta e seus clientes não têm possuem o código fonte ou o código objeto. Eles são invocados remo- tamente via operações públicas de uma interface. Essa limitação faz com que técnicas baseadas em implementação não possam ser combinadas com técnicas baseadas em especificação, o que é recomendável em uma atividade de teste (Myers, 1979).
CAPÍTULO 3. TESTE DE SERVIÇOS 34 As abordagens de teste das funcionalidades dos serviços propostas até agora baseiam-se princi- palmente em técnicas de teste baseadas em especificação e interface. A técnica de teste estrutural é utilizada somente quando se trata do teste das aplicações baseadas em serviços, pois os inte- gradores possuem o código fonte da aplicação, mas os serviços continuam sendo testados como caixa-preta. A única exceção é o trabalho de Bartolini et al. (2011a), cujo objetivo é aumentar a testabilidade dos serviços para apoiar o teste estrutural.
O mesmo ocorre com as abordagens de monitoração. As estratégias ativas em geral executam um conjunto de casos de teste de regressão para descobrir mudanças nos serviços. Algumas abor- dagens propõem a utilização de informaçõs estruturais para selecionar os casos de teste a serem executados, mas em geral essas abordagens não podem ser aplicadas por causa do encapsulamento dos serviços.
Segundo Bozkurt et al. (2012), apesar de haver crescido o número de abordagens criadas para o teste de serviços, algumas questões fundamentais permanecem sem solução definitiva. Ainda é necessária a criação de técnicas para descobrir quando o teste em tempo de execução é necessário e como minimizar o número de casos de teste executados (monitoração). Além disso, é preciso soluções para gerar dados realísticos para casos de teste, além dos casos de teste gerados automa- ticamente com base nas interfaces. Ainda, é necessário que surjam abordagens para aumentar a testabilidade dos serviços e facilitar as tarefas dos integradores e testadores.
De acordo com a revisão sistemática das abordagens de teste e monitoração realizado, percebeu- se que há oportunidades para contribuições na área. Nos próximos capítulos é apresentada a pro- posta desta tese para aumentar a testabilidade dos serviços com o objetivo de apoiar o teste estru- tural. Além disso, também é apresentada uma proposta de monitoração que usa informações do teste estrutural para decidir quando e como selecionar casos de teste de regressão para verificar mudanças nos serviços monitorados.