## 2 Background  
Assessing the certainty level about the quality of a software product is often needed to build confidence in the quality of the software product. Therefore, testing involves evaluating programs and applications to identify potential software bugs and faults at various levels of the software structure, including units, modules, subsystems, and system levels. Test engineers can use different testing techniques and types at different stages, ranging from white- to black-box testing. Moreover, re-executing and verifying test cases for various modules after a change (_i.e., bug fixing or introducing new features_) requires effort and time. To address this issue, researchers investigated different approaches to handle test-case prioritization and selection [12; 13]. Often, their goal is to order test cases based on various factors, optimize the testing process, and ensure its efficiency and effectiveness [14; 15]. In this paper, we utilize execution traces produced by a runtime monitoring framework [16] that captures source-code-level events. This monitoring framework can trace more than 120 different kinds of runtime events [17; 18; 19]. However, this project only utilizes a set of 70 kinds of events described in Table 1. Some events are triggered from variable references and expression evaluations, and others from various data structures such as lists and associated arrays (dictionaries). In contrast, other events capture syntax and control structures, such as the execution of functions, loops, and source-code line changes. This paper builds on this monitoring framework by introducing two new levels of character encoding. Instead of encoding each event in a structure with a field-encoding event type, as shown in Table 1, each event is further reduced down to one alphabetic character. This allows us to represent the execution of an entire test case as a (possibly long) string that constitutes an abstract view of the source-code coverage and runtime behavior of that test-case execution. Throughout this paper, we utilize the Greek symbol \(\sum\) to represent the set of alphabetic characters employed to encode each runtime event. A set of strings is created for each test suite, which is then analyzed to cluster, classify, and rank various related test cases based on their execution behavior. The analysis process yields further insights into the application's internal code structures and runtime behaviors of the software under test, and the relationship between test cases based on their code coverage. It should show how the used test cases cover the application's code and rank these test cases based on their similarities in the code structure covered during its validation process. Similarities between various execution traces will reflect the similarities between the test cases as well as the code that is covered by each of the test cases. Table 1 shows that variable behavior is captured using two events, one for _read_ (_E_Deref_), and the other for _write_ (_E_Assign_). Likewise, the behavior of user-defined procedures and built-in functions can be captured by five different events each. Expression evaluation uses five events as well. Additionally, operations on data structures such as lists or arrays, tables or dictionaries, and sets are represented by sets of seven, nine, and eight unique source-code events, respectively. Behavior pertaining to strings and string processing, including pattern matching (e.g., _regular expressions_), can be observed via eighteen events. The behavior of records and objects can be captured using four events. Additionally, line number change and source-code syntactic structures are depicted using two different events. Finally, a set of five events is used for miscellaneous source-code activities such as file handling and co-expression evaluation. This monitoring framework provides a dynamic filtering mechanism that allows the monitoring program to select a subset of the traced events.