TU München - Fakultät für Informatik
Software- and Systems Engineering Research Group

  Home  |  Forschung/Kompetenz  |  Lehre  |  Personen  |  Publikationen  |  Abschlussarbeiten  |  Sonstiges  |  Kontakt  | 

Agenda

Es sprechen Studenten über ihre abgeschlossenen Diplomarbeiten und Systementwicklungsprojekte.

Am Mittwoch, 20.03.19, ab 14:00 Uhr, im Raum Alonzo Church, 01.09.014:

Ownership Calculation in branched Source Code History

Code Ownership is a fundamental aspect of software development. If a developer has a question about a certain software component or discovers a bug in it, he/she wants to address this matter to an experienced developer. But who is that? Code ownership analysis determines developers with a lot of contributions and experience of the software component. It can also be used to detect head monopolies. However, existing code ownership analyses examine the source code history linearly. With the popularity of distributed version control systems such as Git, the existing code ownership analysis can deliver unexpected results because all the commits outside of the release branch are not taken into account. For example, in some teams only a small number of developers have the authorization to execute merges into the release branch. Other developers write code and make changes in feature branches but they do not merge them into the release branch. Thus, the linear code ownership analysis does not recognize their contributions which leads to an incorrect result. In this thesis, a code ownership analysis approach for branched source code histories is presented. The implemented algorithm is tested on an industry project called Teamscale. Teamscale comprises 6,988 files, has 531 active branches and 100,000 commits in the span of 6.5 years. For 21 source files the ownership is determined. The developers of Teamscale answered a survey in order to establish the real owners of these files. Further research questions of this thesis investigate the effect of merge commits on the code ownership detection and if weighting commits according to the date they were created improve the code ownership detection. The results indicate that with a 95% probability our code ownership analysis determines an experienced developer, who is correctly picked as owner. Regarding the study object of this thesis, the code ownership detection performs better when merge commits are excluded. Weighting commits according to the date they were created does not yield the expected success.

Detection of Flaky Tests Based on Static and Dynamic Software Analysis

Regression testing is important for software maintained over a longer period of time to make sure already existing functionality is not broken by newly introduced features and adjustments. However, the designed test suites to avoid bugs do not always indicate errors in the code when a test case fails. This is due to poor design or implementation choices made by the programmers implementing the tests, which as a consequence yields non-deterministic outcomes for those tests. These commonly called flaky tests hinder the process of software development as developers might debug tests that did not point out bugs in the code. This thesis presents an approach to detect flaky tests without the need of rerunning a failed test which is currently the widespread procedure to identify flaky tests. Therefore it collects the tests coverage and compares if the tests intersect with the changes made in the code. Based on that, tests that had a change in their result and did not cover any changed code are identified to be flaky and will be presented to the developer. I evaluate the approach on the software analysis tool Teamscale using an implemented prototype. The results of the case study show that the approach successfully detects flaky tests in a software system and does not identify tests to be flaky even they are not.

Empirische Untersuchung der Effektivität von Testpriorisierungsverfahren in der Praxis

Automatisierte Tests sind ein zentrales und unverzichtbares Qualitätssicherungsinstrument bei der kontinuierlichen Weiterentwicklung von langlebiger Software. Die Tests werden im Rahmen der Continuous Integration idealerweise bei jedem Push (oder Commit) ausgeführt und helfen somit, Fehler frühzeitig aufzudecken. Bei wachsender Systemfunktionalität und damit einer zunehmenden Anzahl an automatisierten Testfällen steigt jedoch die Ausführdauer der gesamten Test-Suite. Bei großen Systemen erreicht die Ausführdauer oft die Größenordnung von Tagen oder gar Wochen. Somit ist es für diese Systeme selbst unter dem Einsatz von Parallelisierung nicht mehr möglich, alle Testfälle bei jedem Push auszuführen. Als Folge ist Continuous Integration nicht mehr möglich und die Zeit zwischen dem unbeabsichtigten Einbau eines Fehlers durch eine Code-Änderung und dessen Erkennung steigt. Eine mögliche Lösung ist es, die regelmäßige Ausführung der Tests auf eine Teilmenge zu beschränken, die pro Testlauf in Abhängigkeit von den durchgeführten Code-Änderungen neu gewählt wird. Um die Teilmenge für jeden Testlauf neu zu bilden, kommen Testselektionstechniken zum Einsatz. Auszuführende Test können zudem durch eine Priorisierung in ihrer Ausführungsreihenfolge so umsortiert werden, dass ein gewünschtes Ziel möglichst schnell erreicht wird. Dies kann zum Beispiel die zeiteffiziente Abdeckung verschiedener Systemteile sein. Bisherige Studien wurden mit unterschiedlichen Evaluierungstechniken (echte Fehlschläge historischer Testausführungen vs. durch Mutationen verursachte Fehlschläge) und für verschiedene Studienobjekte durchgeführt, sodass eine Generalisierbarkeit dieser Studien nicht gewährleistet ist. Hierbei wurde die Zeit bis zum ersten Testfehlschlag (Time to Failure) als ausschlaggebende Metrik betrachtet. In dieser Arbeit wurden Testpriorisierungsalgorithmen sowohl auf in der Vergangenheit fehlgeschlagene Builds angewendet, als auch in einem Benchmark, der mit Daten aus Mutationsanalysen arbeitet. Eine Teilmenge der Studienobjekte konnte durch beide Methoden untersucht werden. In beiden Analysen zeigten sich durch den Einsatz der an der Forschungsgruppe entwickelten Strategie die niedrigsten Time to Failure Werte. Bei zwei von drei Projekten, von denen die Ergebnisse aus beiden Analysen verglichen wurden, zeigten sich keine auffälligen Unterschiede in der Strategieperformanz. Anhand eines Projektes wurde untersucht, ob sich ältere Testausführungsinformationen für die Nutzung im Selektions- und Priorisierungsverfahren eignen. Dabei wurde der fehlgeschlagene Test in fünf von 15 Fällen nicht mehr ausgeführt, die Time to Failure blieb allerdings niedrig. Weiterhin wurde die Berechnung der Testmenge und -reihenfolge um Optionen erweitert, die die vorgeschlagene Testausführung an Beschränkungen eines testausführenden Systems ausrichtet. Die Auswirkungen unterschiedlicher Konfigurationen wurden an einem Algorithmus gemessen, wobei mit erhöhter Restriktion die Time to Failure Werte leicht anstiegen.