## 6 Case Studies
### Case Study #1: Runtime Behavior and Event Classification
#### Behavior Classification  
Classifying the execution behavior of the running program (during a test case) is achieved using the captured execution trace. A statistical model is used to classify each test case, classify a set of test cases (_test suite_), and eventually classify the complete system or software. The four major classes are:  
1. _Resources and Allocations_: In this category, the program is spending a considerable amount of work preparing and allocating resources to the system. These resources are not limited to the dynamic memory allocations frequently needed for processing various requirements. It can be expanded to include all the resources needed to execute the test case or the set of test cases. It may consist of other resources besides the dynamic memory allocations, such as files, network connections, threads, etc. However, the developer can often optimize these resources, which may lead to better software. However, sometimes, most of these resources can be allocated to serve the various dynamic data structures needed to complete the processing of some requirements, leading to the second category. 2. _Data-Structure Operations_ is the category where programs spend considerable time processing various dynamic data structures. It differs from the category in _Class 1_ above, in that it is not concerned with the allocation itself but with the various data structures used and how frequently they are used. It is more about referencing and managing these data structures that have already been allocated. This major category helps test engineers figure out and focus their testing efforts and resources on the test cases that use more of these data structures. For example, in stress testing, engineers may try to generate test cases that abuse the more expensive structures and measure various nonfunctional requirements in extraordinary situations. 3. _String Processing and Operations_ is the text- and string-processing category. It is one of the common techniques used by programmers and software developers to achieve their goals of functional and non-functional requirements. Therefore, this category is designed specifically to address this particular domain. It will help developers and testers identify the test cases and, maybe, eventually, the systems that can be identified as text- and string-processing cases or applications. However, it is very common for various reasons that the developer may need to search for a specific text or sub-string inside another one or, even more so, identify general or specific patterns inside a given text. Therefore, it can be helpful for software testers to identify these cases and evaluate whether their test suite is focused enough on this particular issue needed by the application or system. 4. _General Evaluation_ is the category that incorporates all of the program's activities, a specific test case, or a set of test cases. Suppose we exclude the allocation of resources, the processing of various data structures, and the frequently needed test processing and evaluation. In that case, we end up with the remainingoperation that can be identified as the general evaluation and processing required to accomplish some task or satisfy functional and non-functional requirements. This category deals with variables, expression evaluations, and calls at the low level and utilizes various user-defined and built-in functions and procedures, libraries, and operators. Identifying the program or the set of test cases in this category would help the test engineer design better test cases and maybe direct resources and efforts into the most-needed places based on time, budgets, and available resources. This execution trace shows three levels of execution trace to explore. At the top level, there are four major classes with a total of 17 different source-code-level events represented in each sub-class. See Figure 5, in which the distribution of events is somehow uniform between the subclasses.