Demo Data from EDBT 2026 / reviewers in the wild / expert
Jérôme Vassy
dblp:43/2791
· DBLP profile ↗
2ranked-venue papers
0as first author
0since 2021 · last 2003
—ORCID · none
Domains — the database's venue-derived domains; a paper can count in several
Software engineering, systems software and programming languages · 2
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
1 paper |
Software testing · 100% |
Topics — the 4 heaviest of 4, each with the papers that count most for it
| Topic | Weight | Papers | Last | Evidence papers |
|---|---|---|---|---|
Software testing
specification-based testing |
0.0 | 1 | 2001 | Strategies for Automated Specification-Based Testing of Synchronous Software · ASE 2001 |
Software testing
test input generation |
0.0 | 1 | 2001 | Strategies for Automated Specification-Based Testing of Synchronous Software · ASE 2001 |
Software testing › software reliability
operational profile |
0.0 | 1 | 2001 | Strategies for Automated Specification-Based Testing of Synchronous Software · ASE 2001 |
Software testing
test generation |
0.0 | 1 | 2001 | Strategies for Automated Specification-Based Testing of Synchronous Software · ASE 2001 |
Methods — techniques the papers use, named apart from their topics
constraint solving · 0.0
| Year | Publication | Venue | Position |
|---|---|---|---|
| 2003 | Thoroughness of Specification-Based Testing of Synchronous ProgramsabstractAdequacy criteria for structural testing techniques are defined in terms of coverage (e.g. of statements or branches). For black-box testing, such criteria, making testers able to decide when to stop testing, are more difficult to define. In this paper, we propose such a definition for the particular case of specification-based testing techniques for synchronous software supplied by the Lutess testing environment. Lutess provides a framework for automatically building generators interacting with the software under test and feeding it with test input sequences. It requires a Lustre specification of both the software environment and the software safety properties. This specification is translated into an input-output automaton. A critical situation occurs when a safety property can be violated unless the software reacts adequately. Such situations correspond to particular states of the specification automaton, called suspect states. Suspect states definition can be used in two complementary ways: First, to design testing techniques able to reach several such states during testing. Second, to assess the thoroughness of a test input sequence in terms of covered suspect states. The above techniques are illustrated on a telephony software specification developed for the first Feature Interaction Detection Contest and involving 12 different telephone features. The thoroughness of the Lutess testing strategies is assessed as their ability to lead the software into suspect states. Ioannis Parissis, Jérôme Vassy |
ISSRE | 2 |
| 2001 | Strategies for Automated Specification-Based Testing of Synchronous SoftwareabstractThe paper presents new techniques for specification based-testing of synchronous software with the Lutess tool. Lutess provides a framework consisting of automatically building generators which interact with the software under test and feed it with test input sequences. In the past few years, it has been established that operational profiles as well as scenarios are powerful tools, allowing for a better fault detection ability. As opposed to this last technique which relies on the ability of the human tester to specify scenarios, we propose an approach based solely on software specification to automatically generate input sequences which may correspond to fault revealing scenarios. Ioannis Parissis, Jérôme Vassy |
ASE | 2 |