Abstract. Model-based testing has mainly focused on models where currency is interpreted as interleaving (like the ioco theory for labeled transition systems), which may be too coarse when one wants concurrency to be preserved in the implementation. In order to test such concurrent systems, we choose to use Petri nets as specifications and define a concurrent conformance relation named coioco. We propose a test generation algorithm based on Petri net unfolding able to build a complete test suite w.r.t our co-ioco conformance relation. In addition we propose a coverage criterion based on a dedicated notion of complete prefixes that selects a manageable test suite.Model-based Testing. The aim of testing is to execute a software system, the implementation, on a set of input data selected so as to find discrepancies between actual behavior and intended behavior described by the specification. The testing process is usually decomposed into three phases: selection of relevant input data, called a test suite, among the possible inputs of the system; submission of this test suite to the implementation, its execution; and decision of the success or the failure of the test suite submission, known as the oracle problem. We focus here on the selection phase, crucial for relevance and efficiency of testing.Model-based testing requires a behavioral description of the system under test. One of the most popular formalisms studied in conformance testing is that of input output labeled transition systems (IOLTS). In this framework, the correctness (or conformance) relation the system under test (SUT) and its specification must verify is formalized by the ioco relation [1]. This relation has become a standard, and is used as a basis in several testing theories for extended state-based models: restrictive transition systems [2,3], symbolic transition systems [4,5], timed automata [6], multi-port finite state machines [7].Model-based Testing of Concurrent Systems. Systems composed of concurrent components are naturally modeled as a network of finite automata, a formal class of models that can be captured equivalently by safe Petri nets. Concurrency in a specification can arise for different reasons. First, two events may be physically localized on different components, and thus be "naturally" independent of one another; this distribution is then part of the system construction. Second, the specification may not care about the order in which two actions are performed on the same component, and thus leave the