The Impact of Resource Availability and the Operating System on
Test Flakiness
Engenharia de software, teste de software, confiabilidade de testes, recursos computacionais.
Test flakiness refere-se a falhas não determinísticas em testes de software, nas quais um mesmo teste pode ora falhar, ora passar, sem que haja qualquer modificação no código. Esse fenômeno compromete a confiança nos testes e representa um problema prevalente e sério na engenharia de software. A tese deste trabalho é que as características do ambiente de execução, como disponibilidade de CPU, memória, disco, plataforma e sistema operacional, aumentam significativamente a incidência de test flakiness, afetando a confiabilidade e a reprodutibilidade dos testes.
A pesquisa está organizada em dois eixos principais: (i) a análise do impacto de recursos computacionais, como CPU, memória e disco, na ocorrência de test flakiness; e (ii) a análise de problemas de portabilidade, examinando como diferenças entre plataformas, sistemas operacionais causam tests flakiness. Em conjunto, esses eixos buscam oferecer uma visão integrada da interação entre infraestrutura, plataforma e código, contribuindo com métodos e ferramentas para aumentar a robustez dos testes automatizados.
Em síntese, no eixo (i) os resultados indicam que o flakiness é sensível a recursos: no corpus de 52 projetos, 46.5% (283/608) dos testes flakies apresentam taxas de falha estatisticamente diferentes sob restrição. A influência mais forte recai sobre CPU (e, em menor grau, memória), enquanto disco e rede têm impacto limitado; a maioria dos casos é apenas levemente afetada (aumento inferior a 25x), embora existam casos extremos acima de 200x em poucos projetos. Os efeitos raramente dependem de uma única configuração, sugerindo que poucas configurações e mais repetições já podem revelar o fenômeno. Em termos práticos, configurações mais restritas aumentam a detecção de falhas, mas a prevenção exige balancear custo e confiabilidade, com o melhor perfil variando por projeto e, frequentemente, favorecendo configurações intermediárias (por exemplo, CPU 0.5/RAM 2GiB e CPU 2/RAM 4GiB).
No eixo (ii), observamos que problemas de portabilidade são frequentes e afetam testes: na reexecução cross-OS, 11.2% dos 500 projetos exibiram diferenças, e a mineração de issues confirmou casos em 95 projetos; no total, 151 projetos apresentaram problemas. A taxonomia contém 7 categorias e 24 subcategorias, com predominância de FILE, PROC e LIB; 62.5% das subcategorias geram assinaturas de erro únicas, enquanto 37.5% exigem inspeção contextual. Identificamos quatro padrões de correção, com maior uso de environment handling (35.7%) e defensive checks (32.2%). Na avaliação de ferramentas, analisadores estáticos tiveram alcance limitado; LLMs alcançaram 40–79% de acurácia na detecção e 27–43% no reparo com prompt genérico, mas subiram para 50–77% com prompts guiados. A validação com PRs confirma alta aceitação (51.5%, sem rejeições), indicando correções localizadas e reconhecidas pelos mantenedores.