O principal objetivo dos experimentos foi verificar a capacidade dos benchmarks em gerar uma demanda controlada e qualificada sobre modelos, critérios e ferramentas de teste, de modo a viabilizar a correta avaliação destes. Por demanda controlada e qualificada entende-se o uso de benchmarks conhecidos e com características bem definidas.
A condução dos experimentos considerou os 30 benchmarks desenvolvidos, a execução dos mesmos com um ou mais dados de teste (em seções de teste) e a geração automática de
diferentes pares de sincronização. Posteriormente foram considerados também os benchmarks com defeitos inseridos.
Anteriormente à execução dos experimentos, foi necessário gerar um conjunto de dados de teste manualmente, a fim de cobrir o critério todos os nós, para cada benchmark. A elaboração de tais conjuntos levou em consideração tanto a funcionalidade quanto o código fonte dos programas. A ValiPar foi utilizada nessa fase como ferramenta de apoio para guiar a escolha de novos dados de teste através da análise da cobertura e do arquivo de elementos requeridos para o critério todos os nós.
Os experimentos foram realizados sobre um cluster de computadores gerenciado por um sistema operacional GNU/Linux. Este cluster, composto por treze nós, está localizado no Laboratório de Sistemas Distribuídos e Programação Concorrente do ICMC/USP e suas características de hardware e software podem ser vistas na Tabela7.
Tabela 7 – Características de hardware e software do cluster onde foram realizados os experimentos. Fator Valor
Processador host físico Intel(R) Core(TM) i7-4790 3.60GHz Memória host físico 32 GB RAM
Processador host virtual 4 Núcleos Memória host virtual 8 GB RAM
Virtualizador KVM
Sistema Operacional Ubuntu 14.04.1 LTS (GNU/Linux 3.13.0-44-generic x86 64) Rede Gigabit Ethernet
Java Runtime Edition build 1.7.0 71b14
Java Virtual Machine Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode)
A ferramenta ValiPar para Java foi então instalada e configurada no cluster. Os bench- marks, juntamente com seus conjuntos de dados de teste, e os scripts utilizados para automatiza- ção dos experimentos, foram transferidos para o ambiente de teste.
A execução de um único experimento foi composta por cinco fases distintas:
A primeira delas foi a execução do módulo ValiInst tendo como entrada o benchmark a ser testado. Nesse módulo o programa foi analisado estaticamente, extraindo-se informações sobre seu fluxo de controle, de dados e de sincronização, sendo gerado, também, o código instrumentado.
A segunda foi composta pela execução do módulo ValiElem com base nas informações extraídas pela análise estática. Nessa fase o objetivo foi obter os elementos requeridos para os critérios de teste.
Na terceira o benchmark passou pela execução livre e determinística no módulo ValiExec. Nessa fase o módulo utiliza o programa instrumentado gerado pela ValiInst e os dados de teste fornecidos pelo testador (neste caso o próprio mestrando).
6.2. Metodologia dos Experimentos 67
sequências de sincronização (ou variantes). O objetivo foi forçar a execução de novas sincroniza- ções, diferentes daquelas realizadas pela execução livre no módulo ValiExec, aumentando, se possível, a cobertura das arestas de sincronização.
Nessa fase optou-se por utilizar a política de geração de variantes em que a escolha dos novos transmissores é feita independentemente da cobertura das arestas de sincronização. Entretanto, devido ao alto custo desta abordagem, foi utilizada como heurística de parada, a estabilização da taxa de cobertura das arestas de sincronização por três níveis consecutivos na árvore de geração de variantes. As arestas de sincronização não cobertas pela geração de variantes foram então consideradas não executáveis.
O módulo ValiEval foi executado ao final de cada nível na árvore de geração de variantes. Ele é responsável pela avaliação da cobertura obtida nas execuções para os elementos requeridos gerados, compreendendo assim a quinta, e última, fase de um experimento.
Foi definida a realização de 10 replicações do experimento para cada benchmark livre de defeito conhecido. O número de 10 replicações foi escolhido para se obter uma maior confiança dos resultados e uma média da quantidade de variantes geradas.
Uma nova execução livre foi feita (novo v0) em cada experimento, para permitir novas sincronizações diferentes daquelas obtidas em outros experimentos. O algoritmo de geração de variantes baseia-se no v0 obtido para um determinado experimento. Desta maneira, a depender da execução inicial e do progresso das demais execuções, a quantidade de variantes geradas pode ser diferente de um experimento para o outro.
Para se avaliar a eficácia de critérios foi necessário inserir defeitos em alguns benchmarks. Para cada defeito inserido foi gerada uma nova versão do programa. Os defeitos inseridos não foram detectados na compilação dos programas, ou seja, não adicionando defeitos sintáticos nos mesmos. Novos experimentos foram então realizados e os dados coletados.
A apresentação dos resultados foi dividida em dois grandes grupos: benchmarks sem defeitos conhecidos e com defeitos inseridos. Os experimentos realizados com os benchmarks sem defeitos tiveram como objetivo validar os modelos de teste e os diferentes módulos da ferramenta ValiPar. O segundo grupo, com benchmarks com defeitos inseridos, teve como foco a validação do critério all-sync-edges.
Os resultados são apresentados em tabelas, estas acompanhadas de uma discussão crítica sobre os mesmos.
Para os benchmarks livres de defeitos conhecidos três tabelas foram preenchidas. A primeira apresenta informações sobre a execução livre, determinística, geração de rastro e variantes. A segunda com informações de cobertura para alguns critérios. A terceira tabela tem informações sobre as quantidades totais, factíveis e não executáveis de arestas de sincronização, e quantidade média de variantes geradas.
Para os benchmarks com defeitos inseridos uma tabela foi preenchida. Nela constam informações sobre a capacidade da ferramenta em revelar defeitos, quantidade de casos de teste, de cada benchmark, que revelou o defeito; se foi necessário o suporte da geração de variantes para revelar o defeito, e em caso afirmativo, a quantidade de variantes geradas até revelar. Por fim, se foi possível revelar o defeito observando a cobertura do critério all-sync-edges.
As duas próximas seções apresentam os resultados obtidos para os benchmarks livres de defeitos conhecidos e com defeitos inseridos.