Planejamento do Segundo Estudo de Caso

Objetivo do Estudo

O objetivo do estudo de caso apresentado nessa seção pode ser descrito da seguinte forma:

Analisar diferentes técnicas para espera (atrasos explícitos, abordagem corrente uti-

lizada no sistema OurBackup e abordagem Thread Control for Tests) em testes assín- cronos do sistema OurBackup com o propósito de avaliar o uso de controle e moni- toração de threads por meio do arcabouço ThreadControl com respeito a conseguir evitar a ocorrência de falhas em testes devidas a asserções feitas cedo ou tarde de- mais do ponto de vista de quem executa testes automáticos e no contexto de testes que exercitam operações assíncronas.

Hipóteses

As hipóteses consideradas nesse estudo são semelhantes a do estudo anterior, podendo ser descritas da seguinte forma:

H01Não há diferença em termos de quantidade de falhas incorretas em testes por asser-

ções feitas em momentos inadequados entre testes usando monitoração e controle de threads através do ThreadControl e testes utilizando atrasos explícitos e a abordagem corrente de espera utilizada nos testes do sistema OurBackup.

H11 É menor (e preferencialmente nula) a quantidade de falhas incorretas em testes

6.2 Estudo 2: Casos de Teste com Testes Reais do OurBackup 94

que em testes que usam como abordagem os atrasos explícitos ou a versão corrente de espera utilizada nos testes do sistema OurBackup.

Variáveis

Para o segundo estudo de caso aqui apresentado, será utilizada a seguinte variável de res-

posta:

Número de testes que falham para um certo número de re-execuções de testes.

Os tratamentos utilizados serão os seguintes:

Uso da abordagem Thread Control for Tests através do arcabouço de testes Thread-

Control;

Uso da abordagem atualmente utilizada nos testes do OurBackup (status quo, chamada

de CurrentVersion) e que mescla espera ocupada e atrasos explícitos em cada caso de teste;

Uso de atrasos explícitos (Explicit Delays ou ED) com diferentes valores fixos para os

intervalos de espera.

Para os tratamentos baseados em atrasos explícitos serão implementadas 3 versões, cujos intervalos de espera corresponderão a 80%, 100% e 120% dos tempos médios de espera utilizados pela versão com ThreadControl. Isso foi feito apenas para tornar mais justa a comparação do número de falhas entre as versões já que o uso de um tempo muito inferior ocasionaria uma frequência maior de falhas nessa versão. Para a versão CurrentVersion, que também se utiliza de espera ocupada em alguns de seus testes, foram utilizados os mesmos tempos de espera escolhidos pelos desenvolvedores.

Sujeitos

Os sujeitos de um experimento de software são os indivíduos que utilizam um certo método ou ferramenta [55].

No caso desse segundo estudo de caso, os sujeitos principais são Ayla Dantas e Matheus Gaudêncio (aluno de graduação na época), que trabalharam na produção de cada uma das

6.2 Estudo 2: Casos de Teste com Testes Reais do OurBackup 95

diferentes versões dos testes correspondentes aos tratamentos do estudo de caso referente ao uso da ferramenta ThreadControl e também os correspondentes a variações de uma versão utilizando atrasos explícitos. Uma característica importante desses sujeitos é que eles não participaram do desenvolvimento do sistema OurBackup. No entanto, membros do time de desenvolvimento foram consultores destes na definição de estados de espera desejáveis para os testes em termos das threads do sistema, sendo portanto também sujeitos do estudo de caso. É importante destacar que estes membros foram os responsáveis pela versão de testes já existente (CurrentVersion) (o status quo).

Objetos

No caso do estudo de caso 2, os objetos utilizados foram 12 dos testes existentes no Our-

Backup. Estes testes foram selecionados através de entrevistas com desenvolvedores sobre

as principais classes de testes com assincronia que apresentavam problemas de falhas por asserções feitas em momentos não apropriados.

Instrumentação

A instrumentação do estudo de caso para colher os valores das variáveis de resposta foi feita através de scripts que varriam os relatórios de teste gerados pelo JUnit observando o sucesso ou falha na execução de cada teste.

Procedimento de coleta dos dados

Para cada um dos diferentes tratamentos (diferentes versões dos testes), os 12 testes deverão ser executados mais de 10.000 vezes observando-se a ocorrência de falhas e os tipos de falhas encontradas, classificando-as entre falhas de fato causadas por problemas de tempo (asserções antecipadas e tardias) e falhas devidas ao problema já conhecido (known bug) em uma biblioteca utilizada pelo OurBackup. Essa classificação foi automática baseando-se nas mensagens de erro dos logs de testes, como detalhado a seguir.

6.2 Estudo 2: Casos de Teste com Testes Reais do OurBackup 96 Procedimento de análise

Na análise será avaliada a hipótese nula referente ao número de falhas em testes. Consi- derando tal hipótese, foi feita uma comparação entre o valor encontrado para o número de falhas, para a mesma quantidade de execuções em cada variação dos testes. Porém, como em um estudo piloto anterior foi encontrada na versão de teste utilizando o ThreadControl um teste que falhou e identificou-se que tal falha era devida a um problema conhecido em uma das bibliotecas utilizadas pelo sistema, nesse novo estudo de caso as falhas foram classifica- das através das mensagens de erro dos logs de execuções de testes para identificar quais fa- lhas em testes estavam mais provavelmente ligadas a asserções antecipadas e tardias (falhas

por asserção antecipada ou tardia) e quais estavam relacionados ao known bug (falhas por defeitos da aplicação já conhecidos). Como eram muito variadas as mensagens de erro

e como não se conhecia todos os possíveis defeitos da aplicação que é relativamente com- plexa, houve casos em que não se pôde classificar as falhas nesses dois grupos e estas foram classificadas no grupo de outras falhas.

A análise feita buscou identificar dentre as falhas encontradas nos testes, quantas esta- vam em cada grupo. O objetivo principal era identificar se com a versão de testes usando

ThreadControlhavia alguma falha por asserção antecipada ou tardia e comparar tal nú- mero com a quantidade de falhas de tal tipo nas execuções utilizando as outras versões de testes.

Avaliação da Validade

Para aumentar a confiabilidade das medidas feitas, a máquina em que são executados os testes é a mesma para cada um dos diferentes tratamentos. Além disso, essa máquina ficou inacessível pela rede enquanto estava dedicada ao estudo de caso.

Configurações do Ambiente

A Tabela 6.3 mostra as configurações de hardware e software da máquina sendo utilizada no estudo de caso.

6.2 Estudo 2: Casos de Teste com Testes Reais do OurBackup 97

Tabela 6.3: Configuração do Ambiente para execução do estudo de caso

Versão do OurBackup Versão corrente do repositório OurBackup em 4/4/2008

Versão de Java Java 1.6.0 06

Sistema Operacional Linux 2.6.24-1-686 (Apr 19) libc6-i686 (2.7-10) Debian Lenny (5.0)

Modelo da máquina HP Compaq dc5100 SFF(ED514LA)

Processador Intel(R) Pentium(R) 4 CPU 3.00GHz (XU1) L2 1MiB

Memória 1.5 GiB de RAM (1548220 kB) (512 MiB e 1 GiB)

HD SAMSUNG HD080HJ/P (80 GB) SATA