A Review of Covering Arrays and Their Application to Software Testing

: Problem statement: As a complex logic system, software may suffer from different source of faults. Those faults can be avoided by applying different testing processes. It appears recently that the interaction among the system factors represents a common source of faults. Software function properly, all input factors and their interactions of the software need to be tested i.e., exhaustive testing. Random testing, in another hand, doesn’t guarantee the coverage of all factors interaction. Approach: Covering Arrays (CAs) are mathematical objects used as platform or structure to represent the interactions of factors for a given system. The uses of CAs become important to reduce the test cases by covering all t-interactions of the system factors at least one time. Results: This study focuses exclusively on the applications of the CAs in software interaction testing. We provide an overview of CAs notations, types and construction methods. Conclusion: We reviewed the recent applications of CAs to software testing and discuss the future possible directions of the research. The research in this area seems to be an active research direction for the coming years.


INTRODUCTION
Nowadays, our dependencies on software are straightforward and increasing, as many kinds of software have become a part of our daily lives. Unlike the old days, the development lifecycle of these software systems passes through several stages and comprehends different activities that need to harmonize carefully to meet the required user's specifications. Generally, those activities can be classified as two important activities, which are: activities to construct the software product and activities to check the quality of the produced software (Baresi and Pezze, 2006).
Although the construction of the product is important, however, checking the quality, which called the "quality process", represents the most important part of the software development lifecycle as it is spans through the whole cycle. The quality process gained importance because each development stage may suffer from different errors and faults, which must be detected as early as possible in order to prevent its propagation in the whole software and reduce the cost of verification. To regulate and show knowledge of the quality process, different levels of testing are used by the quality engineers during the software development lifecycle. This testing process helps to provide a realistic and practical way to analyze and understand the behavior of the produced software under test and to manage or mitigate the faults, risk and failure of the system (Agarwal et al., 2010). This can be tiresome, as when a computer game doesn't work properly, or it can be disastrous, resulting in the loss of life.
Unexpected Interactions among software system components represent a common source of software fault (Williams and Probert, 2001;Zamli and Isa, 2008). This risk is increasing when the numbers of software components are increased tremendously. To reduce this risk and ensure the quality of such software, the manufacture may need to test all the interaction among the components. For example, a complex software system with P components, each of which having two values, the manufacture needs 2 P test cases to test the software exhaustively. This in turn infeasible in practice due to different factors, including time, cost and resource constrains Williams and Probert, 2002). To this end, it is desirable to have a subset of all possible test interactions that have a high potential to uncover faults. Covering Arrays (CAs) recently appeared as an alternative to exhaustive testing by representing all the interactions of the components in a minimized array, which can be used as a test suite. In fact, by using this effective property of CAs, several applications in different areas of research have been introduced in the literature not only in software testing.
However, in this study, we address the use of CAs in software testing exclusively because it is the wider research area in this direction.
The rest of this study is organized as follows. We give the definitions and mathematical notation first. Then we discuss the methods used in literature to construct the CAs. In addition, we declare the recent use of CAs in different software testing applications. Finally, we discuss the possible future directions of the research then we present the conclusions of the study.
Definitions and Preliminaries: Consider a software system with P parameters (components or factors), where P = {P 1 , P 2 , ….. P j }. Each parameter P j can take one of the possible values of V , where V= {v 1 , v 2 , ….. , v i }. To test such a system, test cases could be constructed by assigning values to parameters then apply on the system. For example, the test case [v (1,1) , v (1,2) , v (2,3) ], considers three parameters of the system (P 1 , P 2 , P 3 ), by taking the first value v 1 of the first parameter, the first value v 1 for the second parameter and the second value v 2 for the third parameter.
An interaction "I" of the parameters is a set of values assigned to distinct parameters, considering the strength of interaction (t) among the parameters' values. We say that I=t-way if all the t-interactions of the parameters' values are taken. For example, if the system consists of three parameters P 1 , P 2 and P 3 , then the 2way interaction (or pairwise) of the parameters is the representative values of {(P 1 .P 2 ), (P 1 ,P 3 ), (P 2 ,P 3 )}. To represent these interactions systematically, Orthogonal Array is introduced in an early stage.
Definition 1: An Orthogonal Array, denoted by OA λ (N; t, p, v), is an array of size N and p components on v values and strength t, in which for every N×t subarray, the t-interaction elements occur exactly λ times, where λ=N/v t (Ronneseth and Colbourn, 2009;Cheng, 1980;Beizer, 1990).
OA is often too restrictive because it requires the parameters' values to be uniform. In other words, it is required the same number of v i for all the P j parameters, to occur in the OA exactly one time, which is difficult when the parameters are growing. In addition, most of the time in practice, the values of the parameters are not uniform. To overcome these limitations, the covering array is emerged.
Definition 2: A Covering Array, denoted by CA λ (N;t,p,v), represents an array of size N on v values, such that every N×t sub-array contains all ordered subsets from the v values of size t at least λ times and p is the number of components (Colbourn, 2008;Yilmaz et al., 2004a). Based on the CA construction, each column j (corresponding to a parameter P), contain all values of the corresponding parameters and every possible t-way interaction of the parameters' values is covered at least one time by a row. Hence, λ=1 and the notation becomes CA (N;t,k,v), because it is normally sufficient for each tinteraction to occur once in the CA. Figure 1a represents a CA with the notation CA (9; 3, 2 4 ) of size nine (i.e. nine rows) for a system with four parameters, each of which having two values.
Similar to the OA, in the CA all the parameters contain the same number of values, but the t-interactions in CA can occur more than one time. However, when the number of parameters' values varies, this can be handled by Mixed Covering Array (MCA), denoted by MCA (N;t,p,(v 1 ,v 2 ,…v p )) . The notation can also be represented by MCA (N;t,p,v k ). Figure 1b represents a MCA with the notation MCA (12; 3, 2 3 3 1 ) of size 12 for a four parameters system, with a combination of four parameters having three values and five parameters having four values, to cover the four-way interactions. Building from CA and MCA notations, the variable-strength Covering Array is emerged.
Definition 3: A Variable-strength Covering Array, denoted by VSCA (N; t,p, (v 1 , v 2 , …, v p ) , C) represents an N×p mixed level covering array of strength t containing C, a vector of covering arrays and a subset of the p columns each of strength >t (Yilmaz et al., 2004b;Cohen, 2004).
Throughout this study, we use the term "mainstrength" to describe the strength of VSCA and "substrength" to describe the strength of C. Here for example, VSCA (12; 2, 2 3 3 2 , {CA (3, 2 2 3 1 )}) represents a test suite of size 12 for a system of pair-wise interactions of five parameters in the main configuration with a combination of three parameters having two values and two parameters having three values. In addition, a strength three sub-configuration of three parameters is available, with a combination of one parameter having three values and two parameters having two values.
As noted, despite the existence of MCA and VSCA in different constructions from the CA, but both are based on the CA. Hence, throughout this study, we refer to them as "CAs", unless there is a need to mention about a specific type of them.
CAs construction methods: As the CAs are used in testing processes, the first point to be considered in any construction method is the size minimization. It is desirable for any construction method to construct CAs to cover all the required t-interactions with a minimum number of rows. However, mathematically, the construction of optimum CAs is an NP-complete problem. Hence, it is difficult to find a unified construction method to construct optimum CAs all the time (Lei and Tai, 1998). Therefore, it is normal to find a method that can achieve minimum CAs sizes for some interactions, parameters, or values, while it cannot achieve that for others. To this end, it has been appeared that it is desirable for a method to construct minimum sizes with reasonable time in most cases. This in turn leads to the developments of different methods for construction.
Generally, CAs are constructed computationally to ensure minimization in terms of size and time. Mostly, the construction methods are called strategies because they are combination of different algorithms. We can classify the developed strategies under two general categories: (a) one-parameter-at-a-time strategies and (b) one-row-at-a-time strategies (Grindal et al., 2005). In case of one-parameter-at-a-time, the strategy constructs the array by adding one parameter's value to the array and check for the coverage of t-interactions "greedily". The greedy algorithm chooses the parameters' values that can cover more t-interactions. In-Parameter-Order-General (IPOG) (Lei et al., 2007) and its improvements, IPO-s (Calvagna and Gargantini, 2009), IPOG-F and IPOG-D (Lei et al., 2008) are the most recent strategies that adopt this construction method. Recently, Klaib et al. (2010) also proposed a tree based strategy for oneparameter-at-a-time test generation method.
Whereas, in case of one-row-at-a-time, in addition of using the greedy algorithm the strategy constructs one row and check for its coverage. The rows that are cover more t-interactions are chosen to form the final array. The Automatic Efficient Test Generator (AETG) (Cohen et al., 1997), mAETG (Cohen, 2004), Pairwise Independent Combinatorial Testing (PICT) (Czerwonka, 2006), Deterministic Density Algorithm (DDA) (Bryce and Colbourn, 2007;, Classification-Tree Editor eXtended Logics (CTE-XL) (Lehmann and Wegener, 2000;Yu et al., 2003), Test Vector Generator (TVG) (Tung and Aldiwan, 2000) and Jenkins (2010) represent the most well-known strategies using this construction method.
Recently, the construction of CAs viewed as an optimization problem. As part of one-row-at-a-time construction method, meta-heuristics are used to achieve optimum number of rows. Different optimization methods are used in strategies for construction. From the published results, it has been appeared that these strategies can achieve better sizes in most cases but with longer construction time than other strategies (Afzal et al., 2009). So far, Simulated Annealing (SA) (Cohen, 2004;Stardom, 2001), Genetic Algorithm (GA) (Shiba et al., 2004), Ant Colony Algorithm (ACA) (Shiba et al., 2004) and Tabu Search (TS) (Nurmela, 2004), have been successfully implemented for small-scale interaction strength. We have also implemented Particle Swarm Optimization recently in a strategy named Particle Swarm Test Generator (PSTG) (Ahmed and Zamli, 2010).
Most of the strategies support the construction of CA and MCA. However, few strategies support the construction of VSCA. A number of the aforementioned strategies have started to support VSCA construction (e.g., PICT, IPOG, TVG, CTE-XL and SA). In addition to these strategies, a number of new strategies emerged to particularly construct VSCA using the published techniques. Wang et al. (2008) adopted the DDA algorithm for a strategy called Density to construct VSCA. Wang et al. (2008) also adopted the IPOG algorithm for a strategy called ParaOrder. Moreover, Chen et al. (2009) adopt the ACA algorithm for a strategy called Ant Colony System (ACS) to construct VSCA. Compared with CA and MCA, VSCA covers more t-interactions because of the sub-strength used in addition to the main-strength. Hence, the time of construction normally is more than CA and MCA in all the strategies. However, here also those strategies used meta-heuristics achieved better sizes most of the times (Afzal et al., 2009).

Applications:
CAs have been used recently in different areas of research. In addition to its use in software testing, it has been used in hardware testing (Borodai and Grunskii, 1992), gene expression regulation (Shasha et al., 2001), advance material testing (Cawse, 2003), performance evaluation of communication systems (Hoskins et al., 2005) and many other research areas. Each area contains different applications. Software testing represents the wider area of research for CAs application. The aim of using CAs in the form of interaction testing is to find faults in the application under test. Here, we review four main areas, which are: components interaction testing, GUI interaction testing, test case prioritization and regression testing as well as fault characterization.

Components interaction testing:
In the old days, the trend by the software industries was to produce small software to achieve a specific aim. Nowadays, this phenomenon has been changed. The trend now is to produce software systems, in which they consist of individual programs working on individual components and connect these components together to collaborate. This collaboration leads to achieve a unified software system to serve different needs by the users, for example communications systems, storage systems, or ecommerce systems. Testing the components and programs of these systems individually is desirable and may leads to find different faults. However, it has been appeared that a common source of fault in the whole system comes from the unexpected interaction among the individual components of the system itself (Williams and Probert, 2001). As an example, we consider a software system based on the Internet in Table 1.
The system in Table 1 contains four components or parameters. The system may use different payment server, web server, user browser and business database. In order to test the system, it is required to test all the combinations or interactions among the components, but the tester may need 2 4 test cases for test. For this system, this number of test cases seems to be reasonable. However, if we have similar system but with 8 components, each of which having 4 variables, the test may need to test 4 8 =65,536 test cases, which seems to be infeasible for testing, due to time, cost and resources limitations. Using CA with 2-way, 3-way or above interaction seems to be a compromise method to guarantee the coverage of all interactions possibilities with minimum number of test cases. For example, all the 2-way interactions of the components for the system in Table 1 can be represented by a CA with size six as in Table 2. In additions, the 2-way interaction for the example 4 8 can be covered by a CA with size 27.
Different research proposed this solution. Williams and Probert (2001) proposed this solution formally and studied the coverage of interactions for a particular interaction strength. In another research (Williams and Probert, 1996), they proposed this solution for testing network interface using 2-way interaction. Although these researches proposed this solution, it was not applied practically on a real software system.   Hoskins et al. (2005) applied CAs on a four categorical factors software system. The aim was to use CAs to measure the effect of type of database management system, platform, programmatic interface and type of indexing on the cache hit rate, number of page outs per second and number of physical reads per second. The results were compared with full factorial data and D-optimal designs construction. From the achieved results, CAs outperforms D-optimal designs and exhibit lower variance. The results support the contention that a CA whose strength is one less than the number of factors can be expected to outperform Doptimal designs. GUI interaction testing: Graphical User Interface (GUI) has become practically the means of user interaction with any software. GUI testing is a process of software testing to test the GUI of software to ensure that it meets the required user specification (Memon, 2002). Most of the techniques used for GUI testing are incomplete and used ad hoc or manual testing. However, to formalize these kind of testing, recently, there are three main directions of research, which are using finite state machines (Robinson and White, 2008), pre and post-conditions (Li et al., 2007) and directed graph models (Memon and Xie, 2005) techniques. CAs have been used with graph models to effectively test GUI.
Graph models used the Event-Flow Graph (EFG) to model all possible event sequences that may be executed on a GUI (Huang et al., 2010). In such a model, each event in the GUI is represented by a node N and the relationship among the events is represented by an edge. For example, the GUI in Fig. 2a has four events, which are: File, New, Open and Save; whereas, Fig. 2b is the representation of the GUI in node and edge form. For two nodes GUI n x and n y , the edge from n x to n y means that, along some execution path the event represented by n y may be performed immediately after the event represented by n x (Huang et al., 2010). This relationship is called follows. Hence the directed edges in the EFG are represented by a set E of ordered pairs (e x , e y ), where {e x , e y } ⊆ N and (e x , e y ) ∈ E if e y follows e x . To achieve more compact and efficient GUI model, Event-Interaction Graph (EIG) is emerged (Xie and Memon, 2008). In this model, the events to open or close menus, or open windows are not considered. Hence, menu-opening "File" event for the GUI in Fig.  2a is neglected. To generate the EIG model from the EFG model in Fig. 2b it is required first to delete the "File" event because it is a menu-open event, then for all remaining events, the even after "File" is replaced by the "File" in the edge. In other words, each edge (e x ,File) is replaced with the edge (e x , e y ) for each occurrence of edge (File, e y ) and for all e y , delete all edges (File, e y ). Figure 3 represents the EIG model for the GUI in Fig. 2a.
To derive test cases for the EIG model, a common technique is to derive a test case for each EIG edge, which is called "smoke test" (Memon and Xie, 2005;Yuan et al., 2010). For example, (Open,New), (Open,Save) and (New,Save) represent three smoke test cases with strength 2 for the EIG in Fig. 3. When the length of the sequence grows, the numbers of smoke test cases will grow exponentially exactly like components interaction testing. Here CAs come to face to reduce these smoke test cases systematically. For example, if we have five locations in the GUI each of them has three events; we need 3 5 or 243 test cases to test the GUI exhaustively. However, using the CAs properties, we can systematically sample those events. Using 2-way interaction, for example, we can test by only 11 test cases and the notation will be CA(11;2,5,3).
To derive the events in any GUI, normally GUI Ripper is used. The use of GUI ripper helps to traverse a GUI under test automatically and extracts the events (Huang et al., 2010). The problem with this ripping process is that some parts of the retrieved information may be incomplete or incorrect, which leads to introduce some constraints (Yuan et al., 2010). For example, some event needs another event to be executed before it is enabled or sometimes two events cannot be executed consecutively. As in the case of Fig. 4, we cannot run the "Save" event without running the "Save As…" event first.
Most of the research efforts concentrate on the generation of the test cases and how to solve the constraint problem. Yuan and Memon (2007) developed a new feedback-based technique for GUI testing. The technique depends on creating and executing an initial seed test suite for the software under test. The EIG model of the GUI is used to generate the seed test suite and then automatic test case re-player is used to execute it. A feedback is used to supplement the test suite when it is executing, by generating additional test cases. The relationship between pairs of events is identified to capture how the events are related to each other (Yuan and Memon, 2007). The empirical study reveals to the fact that although using this method, there are still infeasible test cases cannot be run in the test suite.
In another research Memon tried to solve this problem by repairing the unusable test cases (Memon, 2008). The study based on determining the usable and unusable test cases automatically from the test suite then determine the unusable test cases that can be repaired so that they can be executed. The repairing transformations are used to repair the test cases. Although useful and effective, from the results, it has been appeared that there are still many kinds of constraints that should be solved and dealt with. Huang et al. (2010) developed a method to automatically repair GUI test suites and generating new test cases that are feasible. The genetic algorithm is used in the research to evolve new test cases to increase the test suite's coverage. The algorithm produces effective results for different types of constraints. The research showed that the genetic algorithm outperforms the random algorithm and trying to achieve the same goal in almost all cases.
More recently Yuan et al. (2010) used the aforementioned researches to define new criteria for GUI testing grounded in CAs in more detail. The research incorporated "context" into the criteria in terms of event combinations, sequence length and by including all possible positions for each event. The criteria are based on both the efficiency (measured by the size of the test suite) and the effectiveness (the ability of the test suites to detect faults). The study conducts more empirical studies than before using eight applications. The results of those studies showed that increasing the interaction strength t and by controlling the relative positions of events, large number of faults can be detected compared with earlier techniques.

Test case prioritization and regression testing:
Regression testing is a type of software testing aims to find uncovered new errors after changes have been made to the software (Gu et al., 2010). This testing process is based on the fact that as the software is upgraded or developed, the occurrence of similar faults is frequent. This in turn leads to keep those test cases that detected faults in earlier version of the software to re-executing them after developing a new version of the same software. Using this method for testing helps to verify that the changes of specific software have not caused the software inadvertent side-effects and the software still meets its requirements (Rothermel and Harrold, 1996).
Test case prioritization techniques, in another hand, aimed to increase the effectiveness of test cases by scheduling them for execution to increase the rate of fault detection (Rothermel et al., 2001). This in turn gives the estimation of how quickly faults are detected in the testing process. Detecting the faults earlier during the testing process provide faster feedback for the tester and let him to begin correcting defects earlier than might otherwise be possible (Rothermel et al., 2001).
Most of the time, prioritization techniques are associated with regression testing as the information from previous execution of test cases can be used for the ordering and sequencing processes (Rothermel et al., 2001). Both of regression and prioritization are dependent on the test suite selected for the process, especially the initial test suite (Qu et al., 2007). CAs have been used with this kind of testing effectively because of optimized size. By using the generated CAs as test suites, first, an extensive prioritization has been applied to the test suite and then it is applied for the regression testing.
There are few researches introduced the prioritization with CAs. Bryce and Colbourn (2006) present an algorithm for prioritizing the test suites that based on CAs. Although the research showed impressive results for prioritization using interaction coverage; however, the algorithm is not applied on real software to illustrate its effectiveness. Qu et al. (2007) used multiple versions of two software subjects to examine the application and effectiveness of CAs for finding faults with regression testing. Before applying the test suites on the two subject software, the suites have been prioritized. Several different algorithms and methods used to control the prioritization. During the empirical study, the interactions used are between t =2 and 5. The results of the empirical study showed that the CAs are effective to reduce the test space and find the faults. Using prioritization with CAs improves the ability to detect faults early in certain subjects. The results showed also that for the first subject software, most of the faults are covered by t=3; however, for the second subject software, most of the faults covered when t=5.
Later on, Qu et al. (2008) applied the prioritization in regression testing with additional subjects. The research study several versions of an open source text editor. The results showed that using prioritization with CAs can impact the fault finding ability of regression test suites by as much as 70%.

Fault characterization:
Fault characterization (sometimes called failure diagnosis), is a mechanism or method used to find and locate faults in given software. With the increase of software complexity, some kinds of faults appeared that could not diagnose by the traditional methods. This is happened frequently when the system configuration spaces are large and resources are limited. For example, some systems like "Apache", can have hundreds of options that could not be tested extensively because of the large software configuration space and thus leads to the inability of characterizing some faults.
Fault characterization helps to identify the cause of a specific fault and save a great time by fixing the fault quickly. In other words, fault characterization process helps to determine which specific configuration or setting of the system causing a specific failure (Yilmaz et al., 2004a). Yilmaz et al. (2004b) developed a distributed continuous quality assurance process framework called "Skoll" (Memon et al., 2004). The process is supported by tools to leverage the widespread computing resources of worldwide users automatically. The aim was to incrementally, opportunistically and efficiently improve the quality of software. Skoll divided the quality assurance process into sub-tasks, then the tasks are distributed around the world to different client machines using the client-server communication. Each client downloads the software under test from a central code repository and uses a given configuration to test. To complete the overall quality process, the results are returned back to a central site that collects results and fused together (Yilmaz et al., 2004a).
One important implemented task in skoll is the fault characterization. This characterization process of faults is done by testing different configurations and features of the software under test and feed the result of the testing to a classification tree analysis. The output of this classification tree analysis would be a model to describe the options and setting that best forecast failure (Yilmaz et al., 2004b). Here, CAs used for generating the configurations' models for skoll. In this way, all the combinations of the options and are appearing in the provided configurations and will greatly reduce the cost of fault characterization, without compromising its accuracy. Yilmaz et al. (2004a) evaluated the uniform CA with interaction strength between 2 and 6. The results showed that even low strength CA can achieve reliable fault characterization compared with those achieved by exhaustive testing. By increasing the interaction strength of CA, the research reported more precise fault characterization, but with more test suite sizes. The research concludes that the fault characterization could be improved in term of accuracy with low cost if the low strength CA be used. Yilmaz et al. (2006) extend the above research to include more empirical studies. For the first time, the research reports the application of VSCA to tests the effects of using it practically. The use of VSCA allows testing stronger interactions for subspaces where they are needed (i.e., in high-risk subspaces) and keeping a lower strength of interaction across the entire space (Yilmaz et al., 2006). The research reports the same finding for the CA as in the case of the original research. In addition, the research reported that the use of VSCA reduces the cost of the fault characterization process without compromising its accuracy. Moreover, the research showed that use of VSCA improved that accuracy of the fault characterization process with the same cost of CA.

Future research directions:
There are many researches on CAs. Most of the researches are concentrating on the CAs construction methods, algorithms, or strategies. The researches for investigating the applications of CAs in software testing are still in the beginning. As we can see from the aforementioned applications, there are few researches dealing with the application of CAs. Although all the areas need further investigations and assessments, there are new directions that can be impressive for applications. Based on that, our recommendations to the future research focus could be in following two general directions mainly: • Further assessments to the existing researches: although the exiting researches are achieving good results, different areas need more assessments and improvements. One of those areas is the components' interaction testing. So far, the effectiveness of using CAs in this area is not clear. Although it is studied theoretically in many researches, there is little evidence showing its effectiveness. It seems to be encouraging area for empirical studies. An interesting direction, for example, is the use of CAs in e-commerce software systems. It seems to be interesting if a research study the effect of the component interactions on some performance criteria practically. In addition, the application of VSCA is an open research direction also. We can note from the study, the application of VSCA is not investigated clearly. So far, from the literature, there is only one research apply and investigate the effectiveness of the VSCA practically. This could be also applied with ecommence systems by taking stronger interaction strength among some special related components in the system, for example.
• Discovering new directions of software testing applications: CAs could be applied in a different way for software testing. There is a need to study and investigate new software testing directions using CAs. One important direction is to combine the CAs features with other software testing methods. As we mentioned previously, CAs have been used with regression testing and test case prioritization. It also could be useful if the CAs features are used with fault localization techniques.
Recently, fault localization has become an active research area. So far, the use of CAs not investigated with fault localization. Wong et al. (2010) investigate a new fault localization method using code coverage heuristic. In other recently researches, interaction testing using CAs have been effective for improving code coverage using some empirical studies (Zamli et al., 2011;Klaib et al., 2008). This in turn could be an important motivation for using CAs with code coverage heuristics to improve the fault localization as conducted by Wong et al. (2010).

CONCLUSION
The applications of CAs and interaction testing have been an active research area recently. In this study, we aimed to demonstrate the CAs and report their existing applications to software testing. To understand the CAs use in the applications, we first illustrate their types, notations and construction methods. Then, we reviewed several recent applications of CAs to software testing. We briefly mention some of those applications and the achieved results to illustrate the effectiveness of CAs in those applications. The research in this area seems to be an active research direction for the coming years. To this end, in this study we also give different research directions for the future and we also suggest some important ideas for the coming researches.