# Search-based testing in membrane computing

- 57 Downloads

## Abstract

Search-based testing is widely used for generating test sets. It is also applied in the case of model-based testing, especially for (extended) finite state machines. In this paper, we define such an approach for kernel P system models. We consider a specific kernel P system model and a define a search-based testing method. The test set generated consists of input sequences producing a given computation defined by the model. An example illustrates the use of the introduced method.

## Keywords

Membrane computing Kernel P systems Search-based testing Genetic algorithms Test data generation## 1 Introduction

Membrane computing represents a nature-inspired computing paradigm. Its models are called membrane systems or P systems [1]. This research was introduced by Gheorghe Păun in a seminal technical report [2] and then published as a journal paper [3]. The initial model was inspired by the structure and functioning of the living cells, but then other more complex biological structures have been considered and different phenomena utilised in defining new variants.

Another line of research is represented by the study of membrane systems of a more expressive power obtained by bringing together the features of different membrane models with the aim of providing a generic computing framework that allows to formally specify and analyse models derived from various systems and applications. One such membrane computing model is kernel P systems (kP systems, for short), introduced in [4, 5]. kP systems are widely used in various applications, ranging from systems and synthetic biology to engineering applications [6, 7, 8, 9, 10, 11, 12]. It allows models to be simulated and formally verified using third party model checkers using a software framework, called kPWorkbench [13]. This integrated software platform benefits from a specification language, called kP-Lingua allowing the simulation of the systems using either its own native simulator or the agent-based FLAME high-performance simulation environment [14, 15].

In parallel with these developments for kP systems, given the need to check that applications derived from such models are correct, some testing strategies have been considered. Conformance testing methods have been developed aiming to check that the implementation behaves in accordance with its specification, a kP system model, otherwise faults have to be identified and revealed. The testing approach has to consider difficulties posed by parallel and non-deterministic models.

So far, P system-based testing has been considered in the context of linking P system models with other computational models benefiting from testing approaches. Cell-like P system testing has been derived from testing methods based on finite state machines [16], stream X-machines [17], mutation testing [18], model checking-based testing [19] and testing identifiable kP systems using X-machines [20, 21].

Automated test data generation is one of the topics of great importance in software validation. The process of test data generation can be linked with the code or a model of it. Search-based testing [22], using evolutionary methods, is widely used for generating test data sets, but not yet considered in the case of membrane systems.

This paper presents a testing approach aimed at generating test data consisting of input data for models based on a special class of kP systems. The test sets are generated using genetic algorithms.

The rest of the paper is structured as follows: the basic kP systems concepts and search-based testing for extended finite state machines are introduced in Sect. 2. Section 3 introduces some constraints on kP systems used for testing, and describes the genetic algorithm used in this context and the experimental results obtained for a case study. Section 4 summarises the conclusions and presents our future work.

## 2 Preliminaries

In this section, the basic concepts and main definitions related to kP systems are introduced. The basic idea of search-based testing for extended finite state machine (EFSM, for short) models is presented.

### 2.1 Kernel P systems

The formal definition of kP systems [4] is introduced below. Before this, we need to introduce some preliminary concepts such as compartment type which is utilised for defining the compartments of a kP system.

### Definition 1

*T* is a set of compartment types, \(T=\{t_1, \ldots , t_s\},\) where \(t_i=(R_i, \sigma _i)\), \(1 \le i \le s\), consists of a set of rules, \(R_i\), and an execution strategy, \(\sigma _i\), defined over \(Lab(R_i)\), the labels of the rules of \(R_i\).

### Definition 2

*n*is a tuple \(k\varPi = (A, \mu , C_1, \ldots , C_n, i_0)\), where

*A*is a finite set of elements called objects;\(\mu\) defines the membrane structure, which is a graph, (

*V*,*E*), where*V*(vertices of the graph) represents the finite set of components (compartments) of the kP system, and*E*(edges of the graph) is the finite set of links between components;\(C_i = (t_i, w_{i,0})\), \(1 \le i \le n\), is a compartment of the system consisting of a compartment type, \(t_i\), from a set

*T*and an initial multiset, \(w_{i,0}\) over*A*;\(i_0\) is the output compartment where the result is obtained.

Rewriting and communication rules: \(x \rightarrow y \{g\}\), where \(x \in A^{+}\), \(y = (a_1, t_1) \ldots\)\((a_h, t_h)\), \(h \ge 0\), and for each \(1 \le j \le h\), \(a_j \in A\) and \(t_j\) indicates a compartment type from

*T*;*g*is a guard. The format of a guard will be presented below.Structure changing rules, such as membrane division, membrane dissolution, link creation and link destruction rules. These are presented in detail in [4] and will not be considered in this paper.

*w*over

*A*and an element \(a\in A\), we denote by \(|w|_a\) the number of objects

*a*occurring in

*w*. Let us denote \(\mathrm{Rel}=\{<, \le , =, \ne , \ge , >\}\), the set of relational operators, \(\gamma \in Rel\), a relational operator, and \(a^{n}\) a multiset, consisting of

*n*copies of

*a*. We first introduce an abstract relational expression.

### Definition 3

If *g* is the abstract relational expression denoting \(\gamma a^n\) and *w* a multiset, then the guard *g* applied to *w* denotes the relational expression \(|w|_a \gamma n\).

The abstract relational expression *g* is true for the multiset *w*, if \(|w|_a \gamma n\) is true.

any abstract relational expression is an abstract Boolean expression;

if

*g*and*h*are abstract Boolean expressions then \(\lnot g\), \(g \wedge h\) and \(g\vee h\) are abstract Boolean expressions.

### Definition 4

If *g* is an abstract Boolean expression containing \(g_i,\)\(1\le i \le q,\) abstract relational expressions and *w* a multiset, then *g* applied to *w* means the Boolean expression is obtained from *g* by applying \(g_i\) to *w* for any \(i, 1\le i \le q\).

As in the case of an abstract relational expression, the guard *g* is true with respect to the multiset *w*, if the abstract Boolean expression *g* applied to *w* is true.

### 2.2 Search-based testing for EFSM models

Search-based testing is used for generating test data mainly starting from the code, but it is also applied to models for deriving these tests. In the sequel, we refer to a widely spread model used in testing, namely extended finite state machine.

### Definition 5

*S*, \(s_{0}, V,\)

*I*,

*O*,

*T*) [23] where

S is the finite set of states,

\(s_{0}\) is the initial state,

*V*is the finite set of context variables,*I*is the finite set of inputs,*O*is the finite set of outputs and*T*is the finite set of transitions. A transition is represented by a start state and an end state, an input that may have associated input parameters, a guard (logical expression) and a sequential operation (a method with assignments and output statements).

A transition from state \(S_1\) to \(S_2\), denoted \(S_1 \xrightarrow {f_1[g_1]} S_2\), consists of a method to be executed, \(f_1\), and a guard, \(g_1\).

### Definition 6

A path of an EFSM is a sequence of adjacent transitions, \(p = S_1 \xrightarrow {f_1[g_1]} S_2 \xrightarrow {f_2[g_2]} \dots S_m \xrightarrow {f_m[g_m]} S_{m+1}\). A path is called feasible, when there exist values for the input parameters to satisfy guards and to trigger all transitions for that path, and infeasible, otherwise.

For a given path *p*, one of the problems in testing based on EFSM is that of finding input values satisfying the guards along the path. The use of search-based testing has been investigated in [24] using search techniques such as simulated annealing, genetic algorithms and particle swarm optimisation. Kalaji et al. [23] proposed an integrated search-based test data generation instead. Lefticaru and Ipate [25] proposed an approach in two steps. In the first step, all the feasible paths to achieve some coverage criteria are identified. In the second step, for each path, the input values for parameters occurring in guards and triggering each transition of the path are obtained. [26] generates test data for EFSMs using a hybrid genetic algorithm, which is an improvement from the approach presented in [25]. In these approaches, the test data generation problem is converted to an optimisation problem.

Genetic algorithms (GAs) are metaheuristic search techniques, mainly applied in optimisation problems. They are inspired by evolutionary biology using a few concepts, such as populations of chromosomes—these are individuals, selection according to a fitness function, crossover to produce new offspring and random mutation of such offspring [27].

GAs start with an initial population consisting of random candidate solutions. The population will evolve until a solution is found. Each element of the population, the chromosome, is defined by some variables/parameters. These variables take values from a given set.

During the evolution process, certain operations are applied to the population of chromosomes with the aim of optimising a fitness function. The key operations used, crossover and mutation, are briefly presented below.

Crossover is applied to the randomly selected parent chromosomes, by exchanging information and generating children with newly obtained features. The most used chromosome crossover operations are: single-point crossover, multi-point crossover and uniform crossover.

Mutation is applied, with some probability, to each chromosome, by randomly changing the values of some genes. The main purpose of the mutation operation is to create diversity in the population and to prevent the evolution process from stopping too early.

- 1.
An initial population is randomly generated.

- 2.
The fitness function is evaluated for each chromosome in the population.

- 3.The following steps are repeated until a stopping condition is met or the maximum number of generations is obtained.
- (a)
Select a pair of parent individuals from the current population.

- (b)
Apply crossover to the current pair to form two offspring.

- (c)
Mutate the two offspring chromosomes, with a given probability, and place the resulting individuals in the new population.

- (a)
- 4.
Selection is applied on the current population along with the new population.

- 5.
Using the newly evolved population go to step 2.

*m*is the length of the path to be executed and

*p*is the number of nodes executed until the first unsatisfied guard on the path occurs. \(\mathrm{normalized\_branch\_level}\) is the mapping onto [0, 1) for \(\mathrm{branch\_level}\). \(\mathrm{branch\_level}\) computes, for the predicate that is not satisfied, how close the predicate was to being true, using the transformations from Table 1. The normalisation function is \(\mathrm{norm}: [0,101] \rightarrow [0,1], \mathrm{norm}(d) = 1 - 1.05^{-d}\).

Tracey’s objective functions for relational predicates and logical connectives

Element | Objective function value obj |
---|---|

Boolean | if TRUE then 0 else K |

\(a = b\) | if \(\mathrm{abs}(a - b) = 0\) then 0 else \(\mathrm{abs}(a - b) + K\) |

\(a \ne b\) | if \(\mathrm{abs}(a - b) \ne 0\) then 0 else |

\(a < b\) | if \(a - b < 0\) then 0 else \((a - b) + K\) |

\(a \le b\) | if \(a - b \le 0\) then 0 else \((a - b) + K\) |

\(a > b\) | if \(b -a < 0\) then 0 else \((b - a) + K\) |

\(a \ge b\) | if \(b - a \le 0\) then 0 else \((b - a) + K\) |

\(a \wedge b\) | \(\mathrm{obj}(a) + \mathrm{obj}(b)\) |

\(a \vee b\) | \(\mathrm{min}(\mathrm{obj}(a), \mathrm{obj}(b))\) |

\(a \ xor \ b\) | \(obj((a \wedge \lnot b) \vee (\lnot a \wedge b))\) |

\(\lnot a\) | Negation is moved inwards and propagated over |

## 3 Search-based testing for kP systems

In this paper, we will introduce a variant of kP systems with states that will allow us to model systems in a way very close to EFSMs, but offering the flexibility of using other features of kP systems. This version of kP systems uses states in a manner similar to hyperdag P systems [28] or the more recently investigated cP systems [29].

In the sequel, we will consider only deterministic kP systems with states and two compartments.

In the main compartment, the rules will be of the form \(Aa \rightarrow Bb \{g\}\), where *A*, *B* are states as in [28, 29]; *a*, *b* are selected from an alphabet disjoint from states and denote input and output symbols, respectively; *g* is the guard of the rules. The compartment does not include any input symbol. These will be provided by the other compartment.

The other compartment acts as an environment providing inputs to the main compartment. The rules have the form \(C \rightarrow D(a,t_\mathrm{M})\), where *C*, *D* are states and *a* is the input sent to the main compartment of type \(t_\mathrm{M}\).

The execution strategy is sequential, which means at any moment in time only one rule is executed. In fact, an input symbol from the input compartment will be sent to the main compartment and this one will execute the rule corresponding to a state and matching the input received instead, given that the guard is true. This observation is important when the test set is built using inputs in accordance with the above-mentioned constraints.

Test data for kP systems will be generated using genetic algorithms and the kPWorkbench tool will simulate the evolution of the system by moving from one state to another and performing transitions similar to an EFSM.

### 3.1 kP systems definition

In this subsection, we will present the formal definition of kP systems.

### Definition 7

\(\mu = (V,E)\), where \(V ={\{{\rm cM}, {\rm cInp}\}}\), \(\mathrm{cM}\) is the main compartment and cInp is the input compartment, \(E = \{(\mathrm{cM, cInp})\}\);

*A*is the set of objects, defined as \(A=A_\mathrm{ST} \cup A_\mathrm{IO}\), where \(A_\mathrm{ST}\) and \(A_\mathrm{IO}\) are two disjoint sets, \(A_\mathrm{ST}\) denotes symbols corresponding to states in the two compartments. \(A_\mathrm{IO}\) denotes the set of input and output symbols; they may be used in guards;\(i_0\) denotes the label of the main compartment, cM.

\(t_\mathrm{M} = (R_\mathrm{M},\sigma _\mathrm{M})\) is the type of the main compartment and \(w_\mathrm{M0}\) is the initial multiset over

*A*. The main compartment type \(t_M=(R_\mathrm{M},\sigma _\mathrm{M})\) consists of a set of evolution rules, \(R_M\), of the form \(A a \rightarrow B b \{g\}\), where \(A, B \in A_\mathrm{ST}\) and \(a, b \in A_\mathrm{IO}\) and a sequential execution strategy, \(\sigma _M\).\(t_\mathrm{I} = (R_\mathrm{I},\sigma _\mathrm{I})\) is the type of the input compartment and \(w_{I0}\) is the initial multiset over

*A*. The input compartment type \(t_\mathrm{I} = (R_\mathrm{I},\sigma _\mathrm{I})\) consists of a set of rewriting and communication rules \(R_\mathrm{I}\) of the form \(C\rightarrow D (a,t_\mathrm{M})\), where \(C, D \in A_\mathrm{ST}\) and \(a\in A_\mathrm{IO}\), and a sequential execution strategy, \(\sigma _\mathrm{I}\).

### Example 1

A kP system with states that models a simple ATM is provided below.

A failing attempt to access the bank account is denoted by rule \(r_1\); two wrong attempts are allowed—*f* stands for the wrong attempt and output *a* counts the attempts. If a third wrong attempt appears then the system will stop in error state (*E*)—as described by rule \(r_2\). A successful attempt to access the bank account is denoted by rule \(r_3\), where *t* stands for right attempt; immediately afterwards, the system will move to state *B*.

From state *B*, there are two options, either withdrawing from or depositing a certain amount of money into a bank account. In the first case input *x* is processed (rule \(r_4\)), whereas for banking, input *d* is processed instead (\(r_5\)). For withdrawing an amount, this is provided as a multiplicity of *x* (rule \(r_6\) is applied until the entire amount is extracted from the bank account); the amount in the bank account is denoted by a multiplicity of *b*. Similarly, the depositing operation is captured by the rules \(r_5\) and \(r_7\).

Once any of these operations is completed, either \(r_8\) or \(r_9\) will stop the process—input *o* signals this. This model is described by compartment *cM* below. Compartment *cInp* is meant to provide suitable inputs to *cM*.

*Notation* In this example, we will use slightly different notations that are closer to kP-Lingua than to the formal kP system definition. A multiset \(a^5\ b^{10}\) will be written as \(5a\ 10b\). When the objects that appear on the right-hand side of a rule are sent to the same compartment type, a notation \((a_1,t) \ldots (a_p,t)\) is replaced by \((a_1 \ldots a_p, t)\). When an object appears several times, then the multiplicity factor will be used. For example, instead of \((a,t)\, (b,t)\, (a,t)\), either \((2a\, 1b, t)\) or \((2a\, b, t)\) is used.

*A*is the union of \(A_\mathrm{ST}=\{A,B,C,\)

*D*, \(E,F,A_1, \ldots ,A_6\}\) and \(A_{IO}=\{a,b,f,d,o,t,x\},\)

*cM*in state

*A*and have 100 units, i.e., 100

*b*in the bank account. The other compartment, cInp, will start in state \(A_1\).

The only applicable rule in the initial configuration is \(r_{10}\) from *cInp*. This rule will send the input *f* to *cM*. This input denotes a wrong attempt. In this case, we have the computation step \(M_0 \Longrightarrow ^{r_{10}} (100b \, A \, f, A_2) = M_1\).

In this configuration, \(M_1\), we can only apply the rule \(r_1\) from *cM* and \(r_{11}\) in cInp, i.e., the wrong attempt is processed in *cM* and another wrong attempt is generated by *cInp*, hence we have the computation step \(M_1 \Longrightarrow ^{r_1, r_{11}} (100b \, A \, a \, f, A_3) = M_2\).

The next step handles the wrong attempt in *cM* (rule \(r_1\)); at the same time a correct attempt (use of rule \(r_{12}\) in *cInp*) is signalled. These two sequential executions are given by \(M_2 \Longrightarrow ^{r_1, r_{12}} (100b \, A \, 2a \, t, A_4) = M_3\).

In configuration \(M_3\), the compartment cM processes the input signalling correct attempt, *t*, and *cInp* produces the request for withdrawing, *x*, hence \(M_3 \Longrightarrow ^{r_3, r_{13}} (100b \; B \; 3a \; x, A_5) = M_4\). Now, the input for withdrawing is processed in cM and the amount to be withdrawn is communicated from *cInp*, which is 3*x*. This step is illustrated by \(M_4 \Longrightarrow ^{r_4, r_{14}} (100b \, C \, 3a \, 3x, A_6) = M_5\).

Now, the amount from the bank account will be decreased by 3; in each step, a pair *x*, *b* will be removed from cM using \(r_6\), whereas a stop symbol, *o*, is generated in cInp, rule \(r_{15}\). So, we have the following steps:

\(M_5 \Longrightarrow ^{r_6, r_{15}} (99b \, C \, 3a \, 2x \, o, A_7) = M_6 \Longrightarrow ^{r_6} (98b \, C \, 3a \, x \, o, A_7) = M_7\)

\(\Longrightarrow ^{r_6} (97b \, C \, 3a \, o, A_7) = M_8.\)

In the last step, the only applicable rule is \(r_8\) which stops the process, i.e., \(M_8 \Longrightarrow ^{r_8} (97b \, F \, 3a, A_7) = M_9\).

Step 1: rule \(r_{10}\)

Step 2: rules \(r_1 r_{11}\)

Step 3: rules \(r_1 r_{12}\)

Step 4: rules \(r_3 r_{13}\)

Step 5: rules \(r_4 r_{14}\)

Step 6: rules \(r_6 r_{15}\)

Step 7: rule \(r_6\)

Step 8: rule \(r_6\)

Step 9: rule \(r_8\)

We now use kPWorkbench, an integrated software suite [13] that is able to model and analyse the behaviour of the kP system, as the one described in Example 1. The tool includes some simulation and verification components that refer to the model specified in kP-Lingua [30]. The kPWorkbench tool includes two simulators, a native one, which allows the execution of the entire system or a step-wise approach, and the Flame simulator [14], a general purpose large-scale agent-based simulation environment. The latter is meant to allow a kP system to be expressed as a set of communicating X-machines [31] and then executed on high-performance hardware platform [32].

The verification component of kPWorkbench [33] checks the correctness of kP system models. Verification, in particular model checking, has been widely applied to the analysis of various systems [34, 35, 36, 37]. The verification process works by exhaustively analysing all possible execution paths, the verification checks if system in question meets requirements, expressed in a formal logic [38, 39, 40].

kPWorkbench provides a property language specification, called kP-Queries, which comprises a list of property patterns written as natural language statements. This is very useful for non-experts as they do not need to know the syntax of such query languages, relying on existing pre-defined patterns. The properties expressed in *kP-Queries* are verified using the Spin [41] and NuSMV [42] model checkers after being translated into corresponding linear temporal logic (LTL) and computation tree logic (CTL) syntax.

We can check various properties of the ATM system to verify that the model satisfies the system requirements using the verification component of the kPWorkbench tool. For example, by looking at the verification results of some informal properties, e.g.,“whenever more than two attempts fail, the system will move to the Error state”, “the account holder will eventually withdraw some money”, “the account holder cannot withdraw money without the withdrawal request”, “the account holder cannot withdraw more than his/her balance”, etc., we can say whether there errors occur in the model or not. This will allow the user to verify the correctness of the model without generating execution traces to understand the evolution of the system, which is a cumbersome process for large systems.

### 3.2 Algorithm configuration

The algorithm uses a kP system similar to the one in Example 1. The input of the algorithm is a configuration file containing the description of the cM compartment, \(A_{IO}\) and the initial configuration. The compartment cInp will be generated by the algorithm for each potential solution. We need to know the number of rules from cInp, which will be added to the input configuration file (in the rest of the paper we will use the notation *size* for this value). The number of the rules from cInp will denote the size of the set that will be generated by the genetic algorithm. To the input configuration file we also add the scenario we want to test, denoted by a set of steps for which the genetic algorithm will find the input symbols.

The output of the algorithm will be a set of input symbols with the size equal to size. These values will be used to create the cInp compartment, by adding a rule for each input. By simulating the system using the newly created input compartment, we can obtain the resulting simulation steps.

create random initial population—length

*N*: this population contains*N*potential solutions (chromosomes, individuals) that will be evolved until we find a solution.evaluate the population using the fitness function: we need to evaluate each individual to find out how close it is to the solution. A solution is an individual with fitness function equal to 0.

- repeat the following steps until the stopping condition is met (the maximum number of evolution steps is reached or a solution is found):
offspring population \(\leftarrow\) mutation(reproduction(population));

evaluate offspring population;

population \(\leftarrow\) reinsertion+selection(population, offspring population).

*n*. A gene represents the input for the corresponding step and consists of a list of strings (input symbols) \(x_i = (k_1 s_1, \dots , k_n s_n)\), where \(s_i\) is a symbol from the alphabet, and \(k_i\) is the number of times the symbol appears in the input set.

- exchange only the value for a gene from a random selected point$$\begin{aligned} {\left\{ \begin{array}{ll} (x_1, x_2, \ldots , x_n) \\ (y_1, y_2, \ldots ,y_n) \end{array}\right. } \rightarrow {\left\{ \begin{array}{ll} (x_1, x_2, \dots , y_i, \ldots , x_n) \\ (y_1, y_2, \ldots , x_i, \ldots ,y_n) \end{array}\right. } \end{aligned}$$
- exchange only a part of the gene for a random pointwhere \(x_i = (r_1 s_1, \ldots , r_m s_m) , y_i = (t_1 s_1, \ldots , t_m s_m),\)\(x'_i = (r_1 s_1, \ldots , t_i s_i, \ldots , t_m s_m) , y'_i = (t_1 s_1, \dots ,r_i s_i, \ldots , r_m s_m)\)$$\begin{aligned} {\left\{ \begin{array}{ll} (x_1, x_2, \dots , x_i, \ldots , x_n) \\ (y_1, y_2, \ldots , y_i, \dots ,y_n) \end{array}\right. } \rightarrow {\left\{ \begin{array}{ll} (x_1, x_2, \dots , x'_i, \dots , x_n) \\ (y_1, y_2, \dots , y'_i, \ldots ,y_n) \end{array}\right. } \end{aligned}$$

completely change a gene (an input value)

remove gene part—for an input value choose randomly a symbol that will not be used (\(k_i = 0\))

for a random gene—replace random symbol number (\(k_i\))

exchange materials between two genes

the new population := the offspring population [25];

the new population := the offspring population and the fittest individual is kept in the next generation [26];

apply the selection operator and select

*N*chromosomes from the offspring population along with the old population, using different selectors: best chromosome selection, binary tournament selection.

\(P = \{x_1,y_1, x_2, y_2, \ldots , x_{25}, y_{25}\}\), where \(x_1, x_2, \ldots , x_{25} \in{{\rm Old}_{\rm Population}}\) and \(y_1,y_2,\ldots,y_{25} \in {{\rm Offspring}_{\rm Population}}.\)

To evaluate an individual, we need to compute the objective function. To verify if a chromosome is the solution, we need to simulate the system with the corresponding input values and compare the simulation traces with the given steps. The fitness function, as it appears in Eq. 1, is based on the approach level and the branch distance. It checks if the input steps are exactly the needed ones (representing a solution) or how far is the chromosome from the solution. The approach level records how many steps were not executed by a particular input. The fewer steps executed, the further away the input is from executing the steps. The branch distance is computed using the conditions of the guards of the rule at which the evolution diverted away from the current target step. To compute the fitness function, we need to perform a simulation of the system, using kPWorkbench.

### 3.3 Experiments

In our experiments, we have used the kP system presented in Example 1 (except for the input compartment that will be generated for each chromosome). In these experiments, we aim to execute a different sequence of steps and in each case the inputs are calculated with the method described above.

Experiment 1 consists of generating input symbols that can simulate the following scenario: the account holder will introduce at first, a wrong pin. Then, at the second attempt, the correct pin is introduced and withdrawing a certain amount of money (five units) is selected. Finally, the transaction process will stop. For this simple scenario, we can guess the inputs very easy, but for a more complex example, it might be harder just to guess them. Also, this problem might not have an unique solution.

This experiment consists in generating test data. i.e., input sequence, for the following evolution steps:

\(\mathrm{Steps}= \{r_{10}, (r_1,r_{11}), (r_3,r_{12}), (r_5,r_{13}), (r_7,r_{14}),r_7, r_7, r_7, r_7, r_8 \}.\)

This means that we want to search for the input values associated with *cInp* that will generate the given *Steps*. The size of the input set is 5. In this example, we have ten steps, but only the first six will receive inputs. The other steps will consume the inputs until the system reaches the final configuration. An example solution found by the algorithm is the set:

\(\mathrm{Inputs} = \langle 1f\, 2x, 1t, 1d, 1f\, 3x\, 3d, 2x\, 2d\, 1o \rangle\)

This experiment was carried out to find the suitable configuration for the algorithm, including the reinsertion method. As described in Sect. 3.2, the initial configurations failed. After running the algorithm 100 times for each configuration, we could not find a solution. Only for the new reinsertion method, the algorithm has been successful with a success rate of \(75\%\). The average number of evolutions needed to find a solution is 37.

Example of solutions for Experiment 1

Evolutions | Input1 | Input 2 | Input 3 | Input 4 | Input 5 |
---|---|---|---|---|---|

45 | \(1f\, 2x\) | 1 | 1 | \(1f\, 3x\, 3d\) | \(2x\, 2d\, 1o\) |

41 | \(1f\, 2x\) | \(1t\, 1d\) | \(2x\, 2d\) | \(1f\, 6x\, 3d\, 1o\) | |

33 | 1 | \(1f\, 1t\, 5x\) | \(1d\, 1o\) | 5 | 4 |

32 | \(1f\, 1t\) | 1 | 1 | \(1f\, 4x\, 5d\, 1o\) | 1 |

28 | \(1f\, 1t\, 1d\) | 1 | 2 | \(3x\, 1d\) | \(1f\, 1x\, 4d\) |

27 | \(1f\, 1t\) | \(1d\, 1o\) | \(1t\, 2d\) | \(1f\, 3d\) | |

43 | \(1f\, 1t\, 1x\) | 3 | 1 | \(2x\, 1d\, 1o\) | \(1f\, 4x\, 4d\) |

Experiment 2 consists of generating the test data for other examples of evolution steps, using the configuration established in Experiment 1. One of the following evolution steps we have used is:

\(\mathrm{Steps}= \{r_{10}, (r_1,r_{11}), (r_3,r_{12}), (r_4,r_{13}), (r_6,r{14}),r_6, r_6, r_6, r_6,r_8 \}\)

The scenario associated with these steps is the following: the account holder will introduce at first a wrong pin. At the second attempt, the correct pin is introduced. Then, the user will select to withdraw a certain amount of money (five units), and will stop the transaction process.

The size of the input set is 5. In this example, we have ten steps, but only the first six will receive inputs. The other steps will consume the inputs until the system reaches the final configuration. The maximum number of evolution steps is set to 50. After running the algorithm 100 times, the success rate for this example was \(62\%\) and the average number of evolutions needed to find a solution was 36.

Using these experiments, we have established the configuration of the genetic algorithm.

## 4 Conclusions

In conclusion, we have used genetic algorithms as part of search-based testing to generate test data for kP systems. The algorithm input is represented by a kP system model and a set of computation steps; the output is the set of input sets needed to create the given input scenario. The algorithm uses kP systems with states that behave similar to EFSMs. Here, we have applied some genetic algorithms defined for EFSMs directly, but it was not successful. We have overcome this problem by changing the population reinsertion method. With this configuration, the algorithm was successful.

As future work, we will extend this algorithm to other kP systems where the execution strategy is not only sequential. We will apply the testing strategy derived from this approach to other examples and case studies. It will be of interest to look at other search-based testing problems, such as the identification of the computation that takes place in certain circumstances, i.e., linking two states or multisets.

## Notes

### Acknowledgements

The work of AT, FI and MG is supported by a grant of the Romanian National Authority for Scientific Research, CNCS-UEFISCDI, project number PN-III-P4-ID-PCE-2016-0210. The work of SK is supported by EPSRC (EP/R043787/1). The authors are indebted to the anonymous reviewers for their comments made on a previous version of the paper which have contributed to significant improvement of the current work.

## References

- 1.The P systems website. http://ppage.psystems.eu. Accessed 12 May 2018.
- 2.Păun, Gh. (1998).
*Computing with membranes*. Tech. rep., Turku Centre for Computer Science.Google Scholar - 3.Păun, Gh. (2000). Computing with membranes.
*Journal of Computer and System Sciences*,*61*(1), 108–143. https://doi.org/10.1006/jcss.1999.1693.MathSciNetCrossRefzbMATHGoogle Scholar - 4.Gheorghe, M., Ipate, F., Dragomir, C., Mierlă, L., Valencia-Cabrera, L., García-Quismondo, M., & Pérez-Jiménez, M.J. (2013). Kernel P Systems - Version I. Eleventh Brainstorming Week on Membrane Computing (11BWMC), pp. 97–124.Google Scholar
- 5.Gheorghe, M., Ceterchi, R., Ipate, F., Konur, S., & Lefticaru, R. (2018). Kernel P systems: from modelling to verification and testing. Theoretical Computer Science
*724*, 45–60. http://hdl.handle.net/10454/11720. - 6.Blakes, J., Twycross, J., Konur, S., Romero-Campero, F.J., Krasnogor, N., & Gheorghe, M. (2014). Infobiotics workbench: A P systems based tool for systems and synthetic biology. In Applications of membrane computing in systems and synthetic biology, emergence, complexity and computation, vol. 7, pp. 1–41. Springer International Publishing.Google Scholar
- 7.Sanassy, D., Fellermann, H., Krasnogor, N., Konur, S., Mierlă, L., Gheorghe, M., Ladroue, C., & Kalvala, S. (2014). Modelling and stochastic simulation of synthetic biological boolean gates. In 2014 IEEE International Conference on High Performance Computing and Communications, HPCC 2014, Paris, France, pp. 404–408.Google Scholar
- 8.Konur, S., Gheorghe, M., Dragomir, C., Mierlă, L., Ipate, F., & Krasnogor, N. (2015). Qualitative and quantitative analysis of systems and synthetic biology constructs using P systems.
*ACS Synthetic Biology*,*4*(1), 83–92.CrossRefGoogle Scholar - 9.Konur, S., Gheorghe, M., Dragomir, C., Ipate, F., & Krasnogor, N. (2014). Conventional verification for unconventional computing: a genetic XOR gate example.
*Fundamenta Informaticae*,*134*(1–2), 97–110.MathSciNetCrossRefGoogle Scholar - 10.Konur, S., Kiran, M., Gheorghe, M., Burkitt, M., & Ipate, F. (2015). Agent-based high-performance simulation of biological systems on the GPU. In 17th IEEE International Conference on High Performance Computing and Communications, HPCC 2015, pp. 84–89.Google Scholar
- 11.Gheorghe, M., Konur, S., & Ipate, F. (2017). Kernel P systems and stochastic P systems for modelling and formal verification of genetic logic gates, pp. 661–675. Springer International Publishing, Cham.Google Scholar
- 12.Lefticaru, R., Konur, S., Yildirim, U., Uddin, A., Campean, F., & Gheorghe, M. (2017). Towards an integrated approach to verification and model-based testing in system engineering. In The International Workshop on Engineering Data- & Model-driven Applications (EDMA-2017) within the IEEE International Conference on Cyber, Physical and Social Computing (CPSCom), pp. 131–138. http://hdl.handle.net/10454/12322
- 13.Dragomir, C., Ipate, F., Konur, S., Lefticaru, R., & Mierlă, L. (2014). Model checking kernel P systems. In A. Alhazov, S. Cojocaru, M. Gheorghe, Y. Rogozhin, G. Rozenberg, & A. Salomaa (Eds.), Membrane computing (Vol. 8340, pp. 151–172), Lecture Notes in Computer Science Berlin Heidelberg: Springer.Google Scholar
- 14.Coakley, S., Gheorghe, M., Holcombe, M., Chin, S., Worth, D., & Greenough, C. (2012). Exploitation of high performance computing in the FLAME agent-based simulation framework. In 14th IEEE International Conference on High Performance Computing and Communication, HPCC 2012, pp. 538–545.Google Scholar
- 15.Kiran, M., Konur, S., Gheorghe, M., Burkitt, M., & Ipate, F. (2015). Agent-based high-performance simulation of biological systems on the GPU. In 2015 IEEE 17th International Conference on High Performance Computing and Communications. pp. 84–89.Google Scholar
- 16.Ipate, F., & Gheorghe, M. (2009). Finite state based testing of P systems.
*Natural Computing*,*8*(4), 833–846. https://doi.org/10.1007/s11047-008-9099-3.MathSciNetCrossRefzbMATHGoogle Scholar - 17.Ipate, F., & Gheorghe, M. (2009). Testing non-deterministic stream X-machine models and P systems.
*Electronic Notes in Theoretical Computer Science*,*227*, 113–126. https://doi.org/10.1016/j.entcs.2008.12.107.CrossRefzbMATHGoogle Scholar - 18.Lefticaru, R., Gheorghe, M., & Ipate, F. (2011). An empirical evaluation of P system testing techniques.
*Natural Computing*,*10*(1), 151–165. https://doi.org/10.1007/s11047-010-9188-y.MathSciNetCrossRefzbMATHGoogle Scholar - 19.Ipate, F., Gheorghe, M., & Lefticaru, R. (2010). Test generation from P systems using model checking.
*Journal of Logic and Algebraic Programming*,*79*(6), 350–362. https://doi.org/10.1016/j.jlap.2010.03.007.MathSciNetCrossRefzbMATHGoogle Scholar - 20.Gheorghe, M., Ipate, F., & Konur, S. (2016). Testing based on identifiable P systems using cover automata and X-machines. Information Sciences
*372*, 565–578. https://doi.org/10.1016/j.ins.2016.08.028.CrossRefGoogle Scholar - 21.Gheorghe, M., Ipate, F., Lefticaru, R., & Ţurlea, A. (2018). Testing identifiable kernel P systems using an X-machine approach. In International Conference on Membrane Computing, pp. 142–159, Springer.Google Scholar
- 22.Harman, M., & McMinn, P. (2010). A theoretical and empirical study of search-based testing: Local, global, and hybrid search.
*IEEE Transactions on Software Engineering*,*36*(2), 226–247.CrossRefGoogle Scholar - 23.Kalaji, A. S., Hierons, R. M., & Swift, S. (2011). An integrated search-based approach for automatic testing from extended finite state machine (EFSM) models.
*Information & Software Technology*,*53*(12), 1297–1318.CrossRefGoogle Scholar - 24.Lefticaru, R., & Ipate, F. (2008). Functional Search-based Testing from State Machines. In First International Conference on Software Testing, Verification, and Validation, ICST 2008, Lillehammer, Norway, pp. 525–528.Google Scholar
- 25.Lefticaru, R., & Ipate, F. (2007). Automatic state-based test generation using genetic algorithms. In Proc. SYNASC’07, pp. 188–195. IEEE Computer Society.Google Scholar
- 26.Ţurlea, A., Ipate, F., & Lefticaru, R. (2016). A hybrid test generation approach based on extended finite state machines. In 18th International Symposium on Symbolic and Numeric Algorithms for Scientific Computing, SYNASC 2016, Timişoara, Romania, pp. 173–180. https://doi.org/10.1109/SYNASC.2016.037.
- 27.Mitchell, M. (1998).
*An Introduction to Genetic Algorithms*. Cambridge: MIT Press.zbMATHGoogle Scholar - 28.Nicolescu, R., Dinneen, M.J., & Kim, Y.B. (2009). Structure modelling with hyperdag p systems: Part B. Tech. rep., Centre for Discrete Mathematics and Theoretical Computer Science, CDMTCS-373.Google Scholar
- 29.Henderson, A., & Nicolescu, R. (2019). Actor-like cP systems. In T. Hinze, G. Rozenberg, A. Salomaa, & C. Zandron (Eds.),
*Membrane Computing*(Vol. 11399, pp. 160–187), Lecture Notes in Computer Science Berlin Heidelberg: Springer.Google Scholar - 30.Bakir, M.E., Ipate, F., Konur, S., Mierlă, L., & Niculescu, I. (2014). Extended simulation and verification platform for kernel P systems. In Membrane Computing—15th International Conference, CMC 2014, pp. 158–178.Google Scholar
- 31.Holcombe, M. (1988). X-machines as a basis for dynamic system specification.
*Software Engineering Journal*,*3*(2), 69–76.CrossRefGoogle Scholar - 32.Bakir, M.E., Konur, S., Gheorghe, M., Niculescu, I., & Ipate, F. (2014). High performance simulations of kernel P systems. In 2014 IEEE international conference on high performance computing and communications, HPCC 2014, pp. 409–412.Google Scholar
- 33.Gheorghe, M., Konur, S., Ipate, F., Mierlă, L., Bakir, M.E., & Stannett, M. (2015). An integrated model checking toolset for kernel P systems. In Membrane Computing - 16th International Conference, CMC 2015, pp. 153–170Google Scholar
- 34.Arapinis, M., Calder, M., Denis, L., Fisher, M., Gray, P., Konur, S., et al. (2009). Towards the verification of pervasive systems.
*Electronic Communications of the EASST*,*2009*, 22.Google Scholar - 35.Konur, S., Fisher, M., Dobson, S., & Knox, S. (2014). Formal verification of a pervasive messaging system.
*Formal Aspects of Computing*,*26*(4), 677–694.CrossRefGoogle Scholar - 36.Konur, S., & Gheorghe, M. (2015). A property-driven methodology for formal analysis of synthetic biology systems.
*IEEE/ACM Transactions on Computational Biology and Bioinformatics.*,*12*, 360–371.CrossRefGoogle Scholar - 37.Bakir, M. E., Konur, S., Gheorghe, M., Krasnogor, N., & Stannett, M. (2018). Automatic selection of verification tools for efficient analysis of biochemical models.
*Bioinformatics*,*34*(18), 3187–3195.CrossRefGoogle Scholar - 38.Konur, S. (2010). Real-time and probabilistic temporal logics: An overview. CoRR arXiv:1005.3200.
- 39.Konur, S. (2013). A survey on temporal logics for specifying and verifying real-time systems.
*Frontiers of Computer Science*,*7*(3), 370–403.MathSciNetCrossRefGoogle Scholar - 40.Konur, S. (2014). Specifying safety-critical systems with a decidable duration logic.
*Science of Computer Programming*,*80*, 264–287.CrossRefGoogle Scholar - 41.Holzmann, G. J. (1997). The model checker SPIN.
*IEEE Transactions on Software Engineering*,*23*(5), 275–295.CrossRefGoogle Scholar - 42.Cimatti, A., Clarke, E.M., Giunchiglia, E., Giunchiglia, F., Pistore, M., Roveri, M., Sebastiani, R., & Tacchella, A. (2002). NuSMV 2: An open source tool for symbolic model checking. In Computer Aided Verification, 14th International Conference, CAV 2002, Proceedings, pp. 359–364.Google Scholar
- 43.Harman, M., & McMinn, P.: A theoretical & empirical analysis of evolutionary testing and hill climbing for structural test data generation. In Proceedings of the 2007 international symposium on Software testing and analysis. pp. 73–83. ACM (2007).Google Scholar