VLDB 2026 Research / reviewers in the wild / expert
Nikolas Havrikov
dblp:153/5426
· DBLP profile ↗
5ranked-venue papers
2as first author
1since 2021 · last 2022
0000-0003-1524-7666ORCID · verified
Domains — the database's venue-derived domains; a paper can count in several
Software engineering, systems software and programming languages · 5 · 2 first-author · 1 since 2021
Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.
| Software engineering, system software, and programming languages
5 papers |
Software testing · 75% Debugging and program repair · 17% Program synthesis and code generation · 8% |
Topics — the 9 heaviest of 9, each with the papers that count most for it
| Topic | Weight | Papers | Last | Evidence papers |
|---|---|---|---|---|
Software testing
test input generation |
1.0 | 2 | 2022 | Inputs From Hell · IEEE Trans. Software Eng. 2022 When does my program do this? learning circumstances of software behavior · ESEC/SIGSOFT FSE 2020 |
Software testing › test generation
grammar-based test generation |
1.0 | 2 | 2022 | Inputs From Hell · IEEE Trans. Software Eng. 2022 Systematically Covering Input Structure · ASE 2019 |
Debugging and program repair
fault localization |
0.9 | 2 | 2020 | When does my program do this? learning circumstances of software behavior · ESEC/SIGSOFT FSE 2020 Abstracting failure-inducing inputs · ISSTA 2020 |
Software testing
test generation |
0.6 | 2 | 2020 | Abstracting failure-inducing inputs · ISSTA 2020 XMLMate: evolutionary XML test generation · SIGSOFT FSE 2014 |
Software testing › test input generation
failure-inducing input generation |
0.6 | 1 | 2022 | Inputs From Hell · IEEE Trans. Software Eng. 2022 |
Software testing › test generation
failure-inducing test generation |
0.4 | 1 | 2020 | Abstracting failure-inducing inputs · ISSTA 2020 |
Program synthesis and code generation
grammar-constrained generation |
0.4 | 1 | 2020 | When does my program do this? learning circumstances of software behavior · ESEC/SIGSOFT FSE 2020 |
Software testing › test generation
search-based test generation |
0.2 | 1 | 2014 | XMLMate: evolutionary XML test generation · SIGSOFT FSE 2014 |
Software testing › test generation
constraint-based test generation |
0.1 | 1 | 2014 | XMLMate: evolutionary XML test generation · SIGSOFT FSE 2014 |
Methods — techniques the papers use, named apart from their topics
probability inversion · 0.6probabilistic grammar learning · 0.6systematic testing · 0.4input grammar · 0.4grammar-based parsing · 0.4decision tree learning · 0.4k-path algorithm · 0.4recombination · 0.2mutation · 0.2evolutionary search · 0.2
| Year | Publication | Venue | Position |
|---|---|---|---|
| 2022 | Inputs From HellabstractGrammarscan serve asproducersfor structured test inputs that are syntactically correct by construction. A probabilistic grammar assigns probabilities to individual productions, thus controlling the distribution of input elements. Using the grammars as input parsers, we show how tolearn input distributions from input samples,allowing to create inputs that aresimilarto the sample; byinvertingthe probabilities, we can create inputs that aredissimilarto the sample. This allows for threetest generation strategies: 1) “Common inputs”–by learning from common inputs, we can create inputs that aresimilarto the sample; this is useful for regression testing. 2) “Uncommon inputs”–learning from common inputs and inverting probabilities yields inputs that arestrongly dissimilarto the sample; this is useful for completing a test suite with “inputs from hell” that test uncommon features, yet are syntactically valid. 3) “Failure-inducing inputs”–learning from inputs that caused failures in the past gives us inputs that share similar features and thus also have ahigh chance of triggering bugs; this is useful for testing the completeness of fixes. Our evaluation on three common input formats (JSON, JavaScript, CSS) shows the effectiveness of these approaches. Results show that “common inputs” reproduced 96 percent of the methods induced by the samples. In contrast, for almost all subjects (95 percent), the “uncommon inputs” covered significantly different methods from the samples. Learning from failure-inducing samples reproduced all exceptions (100 percent) triggered by the failure-inducing samples and discovered new exceptions not found in any of the samples learned from. Ezekiel O. Soremekun, Esteban Pavese, Nikolas Havrikov, Lars Grunske, Andreas Zeller |
IEEE Trans. Software Eng. | 3 |
| 2020 | Abstracting failure-inducing inputsabstractA program fails. Under which circumstances does the failure occur? Starting with a single failure-inducing input ("The input ((4)) fails") and an input grammar, the DDSET algorithm uses systematic tests to automatically generalize the input to an abstract failure-inducing input that contains both (concrete) terminal symbols and (abstract) nonterminal symbols from the grammar—for instance, "(( ))", which represents any expression in double parentheses. Such an abstract failure-inducing input can be used (1) as a debugging diagnostic, characterizing the circumstances under which a failure occurs ("The error occurs whenever an expression is enclosed in double parentheses"); (2) as a producer of additional failure-inducing tests to help design and validate fixes and repair candidates ("The inputs ((1)), ((3 * 4)), and many more also fail"). In its evaluation on real-world bugs in JavaScript, Clojure, Lua, and UNIX command line utilities, DDSET’s abstract failure-inducing inputs provided to-the-point diagnostics, and precise producers for further failure inducing inputs. Rahul Gopinath, Alexander Kampmann, Nikolas Havrikov, Ezekiel O. Soremekun, Andreas Zeller |
ISSTA | 3 |
| 2020 | When does my program do this? learning circumstances of software behaviorabstractA program fails. Under which circumstances does the failure occur? Our Alhazenapproach starts with a run that exhibits a particular behavior and automatically determines input features associated with the behavior in question: (1) We use a grammar to parse the input into individual elements. (2) We use a decision tree learner to observe and learn which input elements are associated with the behavior in question. (3) We use the grammar to generate additional inputs to further strengthen or refute hypotheses as learned associations. (4) By repeating steps 2 and 3, we obtain a theory that explains and predicts the given behavior. In our evaluation using inputs for find, grep, NetHack, and a JavaScript transpiler, the theories produced by Alhazen predict and produce failures with high accuracy and allow developers to focus on a small set of input features: “grep fails whenever the --fixed-strings option is used in conjunction with an empty search string.” Alexander Kampmann, Nikolas Havrikov, Ezekiel O. Soremekun, Andreas Zeller |
ESEC/SIGSOFT FSE | 2 |
| 2019 | Systematically Covering Input StructureabstractGrammar-based testing uses a given grammar to produce syntactically valid inputs. To cover program features, it is necessary to also cover input features-say, all URL variants for a URL parser. Our k-path algorithm for grammar production systematically covers syntactic elements as well as their combinations. In our evaluation, we show that this results in a significantly higher code coverage than state of the art. Nikolas Havrikov, Andreas Zeller |
ASE | 1 |
| 2014 | XMLMate: evolutionary XML test generationabstractGenerating system inputs satisfying complex constraints is still a challenge for modern test generators. We present XMLMATE, a search-based test generator specially aimed at XML-based systems. XMLMATE leverages program structure, existing XML schemas, and XML inputs to generate, mutate, recombine, and evolve valid XML inputs. Over a set of seven XML-based systems, XMLMATE detected 31 new unique failures in production code, all triggered by system inputs and thus true alarms. Nikolas Havrikov, Matthias Höschele, Juan P. Galeotti, Andreas Zeller |
SIGSOFT FSE | 1 |