padrão foi corretamente aplicado, os quatro casos de teste gerados pelo participante poderiam capturar os defeitos, totalizando em oito defeitos;
• Error Simulator: Conforme mostrado no Capítulo 5, este padrão detectaria defeitos de integração do tipo 2 (tratamento de erros/xceções incorreto). Como o padrão foi corretamente aplicado, os três casos de teste gerados pelo participante poderiam capturar o defeito, totalizando em três defeitos.
A Tabela D.3 apresenta os possíveis defeitos de integração que podem ser detectados pelos casos de teste gerados de acordo com a análise feita.
Tabela D.3: Tipos de defeitos de integração que poderiam ser detectados pelos casos de teste (participante 1).
Padrão de Teste Número de Defeitos por Tipo 1 2 3 4 5 6 7 8 9 Round-trip Scenario Test 9 9 9 9 9 9 - - Abstract Class Test 0 - 0 0 0 0 0 - - Error Simulator - 3 - - - - Test Case With Time Specification - - - 4 4 Total 9 3 9 9 9 9 9 4 4
D.2
Resultados do Segundo Participante
A Tabela D.4 mostra os dados coletados após a execução do estudo pelo segundo participante, para o cálculo das métricas com relação ao esforço e à corretude. Nesta tabela são apresentados o tempo gasto, em minutos, na aplicação da abordagem para a geração dos casos de teste, o número total de casos de teste gerados, o número total de casos de teste válidos e os padrões de teste aplicados, para cada caso de uso do sistema.
Analisando os dados da tabela D.4, tem-se que, o participante gerou um total de setenta e três casos de teste, em um tempo total de hum mil e quarenta e cinco minutos (dezessete horas e vinte e cinco minutos). Além disso, do total de casos de teste gerados, sessenta e dois casos de teste foram considerados válidos, sendo onze inválidos e descartados para
D.2 Resultados do Segundo Participante 145
Tabela D.4: Dados coletados na execução do estudo (participante 2).
Caso de Uso Tempo Gasto (min) CTs Gerados CTs Válidos Padrões
Validate PIN 259 min 11 5 RTST
Withdraw Funds 207 min 17 17 RTST, ACT Query Account 142 min 10 10 RTST, ACT Transfer Funds 158 min 16 16 RTST, ACT Deposit Funds 217 min 16 14 RTST, TCWTS
Exceptions 62 min 3 0 ES
a obtenção da métrica relacionada à eficácia. A Figura D.2 mostra um dos casos de teste gerados considerados inválidos. Este foi considerado inválido primeiramente pelo fato ser sintaticamente incorreto, de acordo com a modelagem/especificação do sistema (conforme pode ser visualizado em destaque na figura, indicado pelo número 3). Além disso, os seguintes defeitos também foram encontrados:
1. Anotação de classes com os estereótipos de integração: nos modelos de teste, as classes do sistema ainda estão anotadas com os estereótipos do perfil IOP, o que não devia acontecer, conforme a especificação da abordagem;
2. Falta de emuladores: as classes que não foram integradas, de acordo com o cenário de integração, não foram substituídas por seus respectivos emuladores, conforme a especificação da abordagem.
Para a medição da capacidade de detecção de defeitos dos casos de teste gerados pelo participante, no intuito de avaliar a eficácia da abordagem realizada no estudo, os casos de teste foram agrupados por cenário de integração especificado e por padrão de teste, conforme mostrado na Tabela D.5. Nesta tabela, em cada coluna é mostrado o número de casos de teste gerados com relação ao número mínimo de casos de teste que deveriam ter sido construídos (para garantir a cobertura).
É possível perceber, com esse dados, que o padrão Error Simulator não foi aplicado corretamente, por isso os casos de teste foram considerados inválidos. Além disso, para muitos dos cenários desenvolvidos não foram construídos todos os casos de teste necessários. No total, foram contabilizados trinta e oito casos de teste de acordo com o padrão Round-trip
D.2 Resultados do Segundo Participante 146
Figura D.2: Caso de teste inválido gerado pelo participante 2.
Scenario Test, vinte e quatro de acordo com o padrão Abstract Class Test e três de acordo com o padrão Test Case With Time Specification. Após esse agrupamento, os casos de teste foram analisados com respeito aos tipos de defeitos que poderiam detectar. A seguir, é apresentada a análise dos casos de teste de acordo com cada padrão de teste:
• Round-trip Scenario Test: Analisando os casos de teste gerados por cenário de integração constatou-se que foram gerados casos de teste que cobrem todos os caminhos para dez cenários. Para os demais cenários, alguns (ou todos) casos de teste gerados foram inválidos ou não foram construídos. Dessa forma, para esses cenários, embora os casos de teste que foram gerados possam capturar esses tipos de defeitos não é possível garantir que eles seriam capturados, uma vez que o conjunto de casos de teste não está completo. Logo, foi contabilizado pelo menos um defeito para cada um dos seis tipos identificados para esses dez cenários, totalizando em sessenta defeitos; • Abstract Class Test: Analisando os casos de teste gerados por cenário de integração
constatou-se que foram gerados casos de teste que cobrem todos os caminhos que envolvem classes abstratas para seis cenários. Logo, foi contabilizado pelo menos um
D.2 Resultados do Segundo Participante 147
Tabela D.5: Casos de teste válidos por cenário de acordo com os padrões de teste (participante 2).
Casos de Uso e Cenários RTST ACT TCWTS ES
Validate PIN Cenário 1 1 de 2 - - - Cenário 2 1 de 3 - - - Cenário 3 2 de 4 - - - Cenário 4 1 de 4 - - - Withdraw Funds Cenário 5 3 de 4 3 de 3 - - Cenário 6 1 de 1 - - - Cenário 7 3 de 4 2 de 3 - - Cenário 8 3 de 4 2 de 6 - - Query Account Cenário 9 2 de 2 1 de 1 - - Cenário 10 1 de 1 - - - Cenário 11 2 de 2 1 de 1 - - Cenário 12 2 de 2 1 de 2 - - Transfer Funds Cenário 13 3 de 3 2 de 2 - - Cenário 14 1 de 1 - - - Cenário 15 3 de 3 2 de 2 - - Cenário 16 3 de 3 2 de 4 - - Deposit Funds Cenário 17 1 de 6 1 de 3 - - Cenário 18 1 de 1 - - - Cenário 19 2 de 6 2 de 3 - - Cenário 20 2 de 6 2 de 6 - - Cenário 21 - - 3 de 4 - Exceptions Cenário 22 - - - 0 de 3
defeito para cada um dos seis tipos identificados para esses seis cenários, totalizando em trinta e seis defeitos;
• Test Case With Time Specification: Como este padrão foi corretamente aplicado, os três casos de teste gerados pelo participante poderiam capturar os defeitos relacionados ao conflito de componentes e o bloqueio de funções/tarefas (8 e 9), totalizando em seis