## 4 Data Representation: Runtime Events and Dataset  
This paper uses execution traces as a representation of test cases. These traces capture aspects of the runtime behavior of test cases. An execution trace provides a comprehensive record of the sequence of source-code-level operations performed by a program during its execution. This trace encompasses function calls, variable accesses (both read and write operations), line number transitions, dynamic memory allocations, and control-flow changes. By analyzing the sequence of runtime execution events, each test case can be uniquely identified. Therefore, the analysis of these traces reveals parts of the test cases' runtime behavior, code structure, and code coverage. The traced execution events are comprehensive enough to represent various code structures, data-structure allocations and operations, source-code evaluations, and built-in operations and functions. This allows a trace to be sensitive to small changes from one test case to another and to depict the similarity in test cases based on their runtime execution behavior and code coverage. Experimentation shows that identical or redundant test cases execute the same code structure in the same order; similar but not identical test cases will share part of the code structure in the same order of execution. Similar runtime characteristics of source-code-level behaviors appear as common substrings in the string representations of the execution traces, which are captured from the sequence of runtime events. For instance, method calls and returns can become integral parts of a program's execution behavior or test cases. To gain insights into the distribution of these embedded events--specifically, how they are distributed within each test case--we needed to explore whether any execution trace exhibits similar functionalities. Traces with common substrings represent test cases with comparable execution patterns, runtime events, or programs with similar logic or internal design structures. Furthermore, if functions, programs, or test cases significantly deviate from the norm, we can identify this deviation using distinct metrics by utilizing various similarity algorithms and measurement metrics. Execution traces capture not just the code's similarity but also its order, just like a time series. The captured events in the execution trace can be encoded in three levels of runtime events. These events are triggered by the program under test, obtained, and collected by AbstractTrace based on different aspects of the program under test, such as memory allocations for various resources (_i.e., data-structure allocations such as lists and arrays, tables and dictionaries; sets, etc._), data-structure utilization, string processing, and the use of various built-in functions and operators, user-defined procedures, and the read and write functions of various program variables. This diversity of runtime events allows for good differentiation between various test cases based on their actual source code and executed statements covered during the test-case validation. \[\sum_{1}=\{A,D,S,E\} \tag{1}\]  
_where_ _A: Resources and Allocations; D: Data-Structure Operations;_  
_S: String Processing and Operations; E: General Evaluation_  
The approach introduced in this paper employs program execution traces at three levels; each level captures a defined level of information. For example, level one or \(L_{1}\) (\(\sum_{L_{1}}=\{A,D,S,E\}\)) divides the runtime behavior into four classes: (1) '\(A\)': for allocations, (2) '\(D\)': for data-structure usage, (3) '\(S\)': for string-processing activities, and (4) '\(E\)': for general evaluations. See Equation (1), where the Greek symbol \(\sum\) is used to represent the set of alphabetic characters. However, if these four major categories are insufficient, the second level, or \(L_{2}\), can be used. \(L_{2}\) divides the runtime behavior into sixteen sub-classes, each encoded with a letter in the alphabet (\(\sum_{L_{2}}=\{H,U,Z,X,Y,M,L,T,C,O,N,J,G,V,P,F\}\)).