Demo Data from VLDB 2026 / reviewers in the wild / expert
Camille Constant
dblp:37/2571
· DBLP profile ↗
1ranked-venue papers
1as first author
0since 2021 · last 2007
—ORCID · none
Domains — the database's venue-derived domains; a paper can count in several
Software engineering, systems software and programming languages · 1 · 1 first-author
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 |
Program verification · 50% Software testing · 50% |
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
conformance testing |
0.1 | 1 | 2007 | Integrating formal verification and conformance testing for reactive systems · IEEE Trans. Software Eng. 2007 |
Program verification
model checking |
0.1 | 1 | 2007 | Integrating formal verification and conformance testing for reactive systems · IEEE Trans. Software Eng. 2007 |
Program verification
reactive system verification |
0.1 | 1 | 2007 | Integrating formal verification and conformance testing for reactive systems · IEEE Trans. Software Eng. 2007 |
Software testing › test generation
specification-based test generation |
0.1 | 1 | 2007 | Integrating formal verification and conformance testing for reactive systems · IEEE Trans. Software Eng. 2007 |
Methods — techniques the papers use, named apart from their topics
symbolic test generation · 0.1input-output automata · 0.1
| Year | Publication | Venue | Position |
|---|---|---|---|
| 2007 | Integrating formal verification and conformance testing for reactive systemsabstractIn this paper, we describe a methodology integrating verification and conformance testing. A specification of a system - an extended input-output automaton, which may be infinite-state - and a set of safety properties ("nothing bad ever happens") and possibility properties ("something good may happen") are assumed. The properties are first tentatively verified on the specification using automatic techniques based on approximated state-space exploration, which are sound, but, as a price to pay for automation, are not complete for the given class of properties. Because of this incompleteness and of state-space explosion, the verification may not succeed in proving or disproving the properties. However, even if verification did not succeed, the testing phase can proceed and provide useful information about the implementation. Test cases are automatically and symbolically generated from the specification and the properties and are executed on a black-box implementation of the system. The test execution may detect violations of conformance between implementation and specification; in addition, it may detect violation/satisfaction of the properties by the implementation and by the specification. In this sense, testing completes verification. The approach is illustrated on simple examples and on a bounded retransmission protocol. Camille Constant, Thierry Jéron, Hervé Marchand, Vlad Rusu |
IEEE Trans. Software Eng. | 1 |