Logo des Repositoriums

Auflistung nach Autor:in "Niedermayr, Rainer"

1 - 3 von 3
  • Konferenzbeitrag
    Better Feedback Times Using Test Case Prioritization? Mining Data of Past Build Failures in an Automated Benchmark
    (Softwaretechnik-Trends Band 40, Heft 2, 2020) Rott, Jakob; Niedermayr, Rainer; Jürgens, Elmar
    In software projects with growing functionality, the number of tests increases fast which results in long execution times for the whole test suite. As a consequence, it is not possible to always execute the whole test suite after each commit so that feedback time to developers increases. With long test feedback times, the effort for an early fix rises and developers can be hindered in productive work. One solution to reduce feedback times is test case prioritization. Although test prioritization strategies have been extensively studied, they are rarely used in practice and their benefits are widely unknown. In this paper, we present a benchmark framework to evaluate the benefits of different test prioritization algorithms on open source projects and primarily use the time until the first failure (TUFF) as relevant metric. We conducted an empirical study with 31 open-source projects hosted on GitHub, using data of 437 builds that failed on the CI server. In 75% of the builds, the first test will fail within the first 18% of the total test suite’s duration.
  • Konferenzbeitrag
    Kann statische Analyse unnützen Code erkennen?
    (Software Engineering 2022, 2022) Haas, Roman; Niedermayr, Rainer; Roehm, Tobias; Apel, Sven
    Dieser Beitrag fasst einen im ACM Journal Transactions on Software Engineering and Methodology veröffentlichten Artikel von Haas et al. [Ha20] zusammen. Darin geht es um die Identifikation von unnützem Code, also Code, der nicht mehr benötigt wird. In den meisten gewachsenen Softwaresystemen sind Teile des Codes im Laufe der Zeit unnütz geworden. Unnützer Code ist problematisch, weil dadurch Ressourcen bei der Entwicklung und Wartung verschwendet werden, beispielsweise bei der Vorbereitung für eine bevorstehende Migration oder Zertifizierung. Zwar kann mithilfe eines Profilers nicht mehr produktiv verwendeter Code aufgedeckt werden, aber oft ist es zu zeitaufwendig bis repräsentative Daten erhoben wurden. Im oben genannten Beitrag wird ein auf Codestabilität und -zentralität basierender statischer Analyseansatz vorgeschlagen, um unnützen Code zu identifizieren. Um die Nützlichkeit des Ansatzes zu untersuchen, wurde eine Studie mit 14 Open-Source-und Closed-Source Software-Systemen durchgeführt. Da es kein perfektes Orakel für unnützen Code gibt, wurden die Empfehlungen für unnützen Code auf Basis von Löschungen in der Codehistorie, Laufzeitnutzungsdaten und dem Feedback von 25 Entwicklern aus fünf Software-Projekten evaluiert. Die Studie zeigt, dass aus Stabilitäts-und Zentralitätsinformationen generierte Empfehlungen auf unnützen Code hinweisen. Insgesamt deuten die Ergebnisse darauf hin, dass die statische Analyse schnelles Feedback zu unnützem Code liefern kann und in der Praxis nützlich ist.
  • Konferenzbeitrag
    Too trivial to test? An inverse view on defect prediction to identify methods with low fault risk
    (Software Engineering 2020, 2020) Niedermayr, Rainer; Röhm, Tobias; Wagner, Stefan
    To cope with the scarce resources for testing, teams can apply defect prediction to identify fault-prone code regions. However, defect prediction tends to low precision in cross-project prediction scenarios. We take an inverse view on defect prediction and aim to identify methods that can be deferred when testing because they contain hardly any faults due to their code being \"trivial\". We compute code metrics and apply association rule mining to create rules for identifying methods with low fault risk (LFR) and assess our approach with six Java open-source projects containing precise fault data at the method level. Our results show that inverse defect prediction can identify approx. 32-44% of the methods of a project to have a LFR; on average, they are about six times less likely to contain a fault than other methods. Our approach identifies methods that can be treated with less priority in testing activities and is well applicable in cross-project prediction scenarios.