## 3 Model-Based Mutation Testing
### Test Case Prioritization  
Consider software \(S\); the test suite used to test \(S\) is \(T\). Term any source code modification in \(S\)\(S^{\prime}\), and the test suite used to retest the changed software \(T^{\prime}\). During regression testing, the test suite \(T\) for \(S\) must achieve certain objectives. In particular, when the software change \(S\to S^{\prime}\) occurs, \(T\) should be used to examine whether the test cases meet the changed customer requirements. Some test cases in \(T\) can be retained without change, but a new test case must be added to \(T^{\prime}\). However, as software becomes more complex and test suite size increases with each regression cycle, it may not be possible to perform all tests in \(T^{\prime}\) if resources are limited. Optimization techniques can be used to construct a new test suite \(T^{\prime}\). Coverage is a test exit criterion and an important factor as a metric for monitoring how much testing has been performed. Coverage includes structural coverage of a model or a source code, and fault coverage; both are used as measures of testing. For example, if a certain software must meet 10 requirements, all must be verified. On the other hand, to confirm efficient source code implementation, structural coverage confirms that all necessary tests meet certain conditions or decision-making criteria. Finally, fault coverage should reveal all faults. If the test suite meeting these criteria is optimized early, the resources required during each regression are low. APFD is used to measure how early the test suite reveals faults. For example, for 10 faults, suppose that the first test case reveals both faults 1 and 2. That test case is executed first because it is efficient. The APFD is calculated using the test case execution order for 10 faults:  
\[APFD=1-\frac{TF_{1}+TF_{2}+\ldots+TF_{n}}{n\ \times\ m}+\frac{1}{2n} \tag{1}\]  
\(TF_{1}\) : test case revealing the first fault.  
\(TF_{2}\) : test case revealing the second fault.  
\(\cdots\)  
\(TF_{i}\) : test case revealing the \(i\)th fault.  
\(n\) : number of test cases  
\(m\) : number of faults  
However, APFD assumes that all faults are equally severe and that all tests cost the same. The test order is not prioritized. APFDc prioritizes tests by fault severity and considers costs. To this end, an additional term is needed to reflect the severity and weigh the costs of Equation (1), as follows [21]:  
\[APFDc=1-\frac{\sum_{j=1}^{m}(f_{j}\times(\sum_{i=1}^{n}t_{i}-\frac{1}{2}t_{TF _{i}}))}{\sum_{i=1}^{n}t_{i}\times\sum_{j=1}^{m}f_{j}} \tag{2}\]  
\(t_{i}\) : cost of the \(i\)th test case  
\(f_{j}\) : severity of the \(j\)th fault  
\(TF_{i}\) : test case order of test suite \(T\) revealing the \(i\)th fault  
The cost shown above should reflect the time required for test case execution, but fault severities can be difficult to measure precisely. If all fault severities are assumed to be identical, the APFDc becomes more concise [23]:  
\[APFDc=1-\frac{\sum_{j=1}^{m}(\sum_{i=TF_{i}}^{n}t_{i}-\frac{1}{2}t_{TF_{i}})} {\sum_{i=1}^{n}t_{i}\times m} \tag{3}\]  
When we simulated real-world test case execution times on a PC, they did not differ markedly. Of course, test times in a black box and the real world may differ in terms of variables. However, in a white box, real execution times can be reduced. Thus, the APFD serves as an objective function.  
Model-based mutation testing has attracted much attention. Usually, mutants are generated by a software model based on UML or Matlab, as are the test cases [16; 17]. Mutation operators are required in model-based environments, but not for code mutation. [PERSON] et al. studied model-based mutation testing using mutation operators of a UML-based model [5].