Configuração

CAPÍTULO 6. UMA ABORDAGEM DE MONITORAÇÃO DE SERVIÇOS TESTÁVEIS 91

Serviço

Testável

Integrador

1: obter requisitos de teste

2: Executar casos de teste/obter requisitos cobertos 3: obter cobertura estrutural

MONITORAÇÃO * CONFIGURAÇÃO Marcadores Armazenar Referências Integrador

Serviço

Testável

1: Verificar mudanças estruturais

2: Verificar mudanças de comportamento** 3: Verificar código não testado**

* Executada periodicamente. A frequência é determinada pelo Integrador. ** Tarefas executadas apenas se a tarefa 1 encontrar alguma modificação estrutural. *** Executada apenas se for detectada alguma mudança no serviço testável.

Atualizar***

Figura 6.1: Ilustração de uma estratégia de monitoração de um serviço testável

1. Obter os requisitos de teste do serviço testável usando a operação getTestRequirements(). 2. Executar cada caso de teste do conjunto de regressão do serviço testável e identificar, usando

a operação getCoveredRequirements, quais requisitos de teste foram cobertos pelos casos de teste individualmente.

3. Obter a cobertura estrutural alcançada com a execução do conjunto de regressão.

Esta etapa é executada apenas uma vez e as informações obtidas são usadas como marcadores de referência (baseline) para comparar com as informações obtidas durante a atividade de monito- ração para detectar mudanças no serviço testável.

6.2.2

Monitoração

Esta etapa é responsável por detectar as mudanças nos serviços monitorados. Para isto as seguintes atividades devem ser executadas periodicamente:

1. Verificar mudanças estruturais: esta atividade tem o objetivo de verificar se a estrutura do serviço monitorado continua a mesma. Cada vez que esta atividade é realizada deve-se obter os requisitos de teste do serviço testável e compará-los aos requisitos obtidos na etapa de Configuração. O propósito da comparação é identificar as diferenças entre os requisitos de teste considerando os nós, as arestas e os usos das variáveis do serviço porque eles refletem

CAPÍTULO 6. UMA ABORDAGEM DE MONITORAÇÃO DE SERVIÇOS TESTÁVEIS 92 sua implementação. Com os requisitos de teste é possível criar um grafo de fluxo de controle da estrutura de cada operação do serviço testável. Independentemente das várias maneiras em que o código de um serviço pode ser alterado, as mudanças geralmente são as mesmas:

• Mudança no fluxo de controle: isto significa que instruções que desviam o controle do programa (while, if, switch) foram adicionadas ou removidas do código. Consequentemente, nós e arestas serão adicionados ou removidos da estrutura e dos requisitos de teste.

• Mudança no fluxo de dados: isto significa que variáveis passaram a ser usadas em diferentes nós ou arestas ou que variáveis não estão sendo mais usadas em nós e arestas onde estavam sendo usadas anteriormente. O critério todos-usos geralmente define um requisito de teste como um par definição-uso. A definição refere-se ao nó onde a variável é definida e o uso refere-se ao nó ou aresta onde a variável é usada. Esta abordagem de monitoração está preocupada apenas em identificar mudanças referentes ao uso das variáveis.

• Nenhuma mudança no fluxo de controle ou de dados: isto significa que instruções foram adicionadas ou alteradas sem afetar a estrutura do código considerando os nós, as arestas e os usos. Um exemplo deste tipo de modificação é quando um operador relacional ou matemático é trocado por outro. Esses tipos de mudanças não mudam os requisitos de teste. Uma das soluções para identificar este tipo de mudança é comparar o código hash dos blocos de instruções que compõem os nós do grafo de fluxo de controle Ruth et al. (2007).

O resultado desta atividade é uma lista de requisitos de teste (nós e arestas) que foram alte- rados porque a estrutura do serviço mudou.

2. Verificar mudanças de comportamento: esta atividade é usada para verificar se o com- portamento do serviço monitorado mudou com base na execução de casos de teste de um conjunto de regressão. Nesta abordagem, ao invés de executar todos os casos de teste do conjunto de regressão, são executados apenas os casos de teste que cobrem pelo menos um dos requisitos de teste da lista criada na atividade anterior. Esta estratégia permite que o teste de regressão seja usado da maneira tradicional em que casos de teste são executados após uma mudança conhecida.

Os resultados da execução dos casos de teste selecionados são comparados aos resultados da execução dos casos de teste na etapa de Configuração. Qualquer mudança nos resultados in- dicará que o comportamento do serviço está diferente, considerando serviços com resultados determinísticos.

Esta atividade é executada apenas se alguma mudança estrutural foi identificada. Esta estra- tégia é uma vantagem porque as atividades de monitoração podem ser executadas periodica- mente e se nenhuma mudança for percebida nenhum caso de teste será executado. Mesmo

CAPÍTULO 6. UMA ABORDAGEM DE MONITORAÇÃO DE SERVIÇOS TESTÁVEIS 93 quando uma mudança estrutural é identificada, o número de casos de teste executados pela abordagem é reduzido, uma vez que somente são executados casos de teste criteriosamente selecionados.

3. Verificar código não testado: esta atividade é usada para verificar se existem partes do código do serviço monitorado que ainda não foram executadas. A cobertura estrutural obtida após a execução dos casos de teste na atividade anterior é comparada com a cobertura obtida com a execução dos casos de teste na etapa de Configuração. Diferenças entre as duas coberturas indicam que alguma coisa mudou dentro do código, mesmo quando nenhuma mudança foi identificada no comportamento do serviço.

Essa última situação pode ocorrer por diversos motivos:

• Novos trechos de código que não foram exercitados pelos casos de teste. • Trechos de código foram removidos do serviço.

• Os caminhos percorridos dentro do código pelos casos de teste mudaram porque houve alguma alteração nas instruções do serviço.

Os integradores podem utilizar as informações de cobertura para decidir se as mudanças de cobertura identificadas requerem alguma ação para evitar algum problema. Novos trechos de código que ainda não foram testados, por exemplo, podem esconder defeitos e por isso devem ser testados.

4. Reagir: As alterações sofridas por um serviço não são necessariamente ruins. Uma mudança ruim é quando defeitos são introduzidos no serviço ou quando o serviço para de apresentar o nível de qualidade esperado. Outro exemplo de mudança ruim é quando as regras de negócio de um serviço mudam e a aplicação no qual ele está integrado passa a ficar inconsistente. As boas mudanças de um serviço ocorrem quando as funcionalidades de um serviço são aprimoradas e ele passa a desempenhar sua função com maior qualidade.

Identificar qual tipo de alteração o serviço sofreu, e se é uma alteração boa ou ruim, é essen- cial para que alguma atitude seja tomada quando alguma mudança é detectada. Na Tabela 6.1 são apresentadas algumas possíveis mudanças sofridas pelos serviços combinando os elementos utilizados por esta abordagem para detectar tais mudanças. Em seguida são apre- sentadas reações possíveis para cada uma das alterações apresentadas.

Tabela 6.1: Tipos de mudanças sofridas por um serviço e as reações sugeridas Todos caso de teste passaram Pelo menos 1 caso de teste falhou

A cobertura não mudou 1 2

A cobertura está maior 1 2

CAPÍTULO 6. UMA ABORDAGEM DE MONITORAÇÃO DE SERVIÇOS TESTÁVEIS 94 • Mudança tipo 1: Esta é uma mudança boa, considerando os elementos observados para identificar as mudanças. Todos os casos de teste passaram e a cobertura é igual ou maior à cobertura obtida anteriormente. Significa que a mudança não alterou o comportamento e possivelmente existem menos trechos de código que ainda não foram testados. Nesta situação não se deve tomar nenhuma atitude para adequar a aplicação às mudanças sofridas pelo serviço.

• Mudança tipo 2: Esta á uma alteração ruim, pois foram encontradas falhas no serviço após ele ter sido modificado. Neste caso deve-se substituir o serviço defeituoso por um que desempenhe a mesma função. Na falta de um serviço substituto o provedor do serviço deve ser notificado. Se o serviço estiver falhando porque o serviço usado possui novas regras de negócio, deve-se adaptar a aplicação para ela se adequar ao serviço se este for o caso.

• Mudança tipo 3: Esta é uma mudança que pode ser considerada neutra porque não traz nenhum prejuízo imediato. O comportamento não mudou de acordo com os casos de teste executados, mas a cobertura está menor. É possível que haja mais trechos de código que não foram executados ainda e que podem vir a apresentar uma falha futuramente. Neste caso pode-se criar mais casos de teste para tentar cobrir as partes do código que ainda não foram cobertas e aumentar a confiança para a aplicação que usa o serviço.

Os tipos de mudanças e as ações que podem ser tomadas de acordo com cada uma delas são apenas exemplos do que pode ser feito quando mudanças são detectadas nos serviços moni- torados. Definir estratégias de reação não está nos objetivos da abordagem de monitoração de serviços testáveis apresentada.