Patent Publication Number: US-11381464-B2

Title: Methods, systems, and computer readable media for implementing a generalized model for defining application state machines

Description:
PRIORITY CLAIM 
     This application claims the priority benefit of Romanian Patent Application Serial No. a 2019 00814, filed Nov. 28, 2019, the disclosure of which is incorporated herein by reference in its entirety. 
     TECHNICAL FIELD 
     The subject matter described herein relates to network equipment testing. More particularly, the subject matter described herein relates to methods, systems, and computer readable media for implementing a generalized model for defining application state machines. 
     BACKGROUND 
     While state machines have been utilized for the purpose conducting network traffic testing at a device under test, the use of these state machines has generally been confined to specific communication protocols that are directly incorporated into the application state machines. More specifically, the entirety of a specific communication protocol to be used for testing is typically embedded into a test engine in an attempt to minimize the consumption of resources. However, a test system that is tasked to simulate diverse network behaviors corresponding to a large number of emulated users is notably restricted when such testing is limited to the communications protocols integrated into the test engine. Namely, accurate testing necessitates a test system that can produce realistic and complex mixes of network traffic that is not constrained to a specific protocol. Other challenges associated with test systems restricted in this manner include extensive resource requirement costs as well as the significant time requirements that are associated with the provisioning and supporting of new testing scenarios. 
     Accordingly, there exists a need for methods, systems, and computer readable media for implementing a generalized model for defining application state machines. 
     SUMMARY 
     According to one aspect, the subject matter described herein includes a method for implementing a generalized model for defining application state machines that includes utilizing a user behavioral state machine construct layer of a generalized application emulation model (GAEM) system to emulate a plurality of high level user behaviors originating from a plurality of emulated network users and utilizing a business application logic state machine construct layer in the GAEM system to emulate access rules and policies of an application to be defined. The method further includes utilizing a message parsing state machine construct layer in the GAEM system to emulate input/output (IO) events and network messaging events originating from emulated network entities and utilizing at least one network traffic processing agent in the GAEM system that is configured to establish an execution environment for facilitating the interactions among the user behavioral state machine construct layer, business application logic state machine construct layer, and the message parsing state machine construct layer such that when executed in the execution environment, the interactions establish a definition for a state machine that is representative of the application. 
     In one example of the method, the high level user behaviors are represented as parallel tracks, wherein each of the parallel tracks is a sequence of operations that is exposed by one or more applications. 
     In one example of the method, two or more of the parallel tracks are synchronized together at synchronization points. 
     In one example of the method, an output of one or more of the construct layers is provided to the at least one network traffic processing agent for execution. 
     In one example of the method, emulated network packet traffic is generated by the at least one network traffic processing agent. 
     In one example of the method, the user behavioral state machine construct layer, the business application logic state machine construct layer, and the message parsing state machine construct layer are configured to communicate data via filing of events. 
     In one example of the method, service access rules associated with the business application logic state machine construct layer are defined by an operator of a network under test. 
     According to one aspect, the subject matter described herein includes a system for implementing a generalized model for defining application state machines that comprises a user behavioral state machine construct layer configured to emulate a plurality of high level user behaviors originating from a plurality of emulated network users and a business application logic state machine construct layer configured to emulate access rules and policies of an application to be defined. The system further includes a message parsing state machine construct layer configured to emulate input/output (IO) events and network messaging events originating from emulated network entities and at least one network traffic processing agent that is configured to establish an execution environment for facilitating the interactions among the user behavioral state machine construct layer, the business application logic state machine construct layer, and the message parsing state machine construct layer such that when executed in the execution environment, the interactions establish a definition for a state machine that is representative of the application. 
     In one example of the system, the high level user behaviors are represented as parallel tracks, wherein each of the parallel tracks is a sequence of operations that is exposed by one or more applications. 
     In one example of the system, two or more of the parallel tracks are synchronized together at synchronization points. 
     In one example of the system, an output of one or more of the construct layers is provided to the at least one network traffic processing agent for execution. 
     In one example of the system, emulated network packet traffic is generated by the at least one network traffic processing agent. 
     In one example of the system, the user behavioral state machine construct layer, the business application logic state machine construct layer, and the message parsing state machine construct layer are configured to communicate data via filing of events. 
     In one example of the system, service access rules associated with the business application logic state machine construct layer are defined by an operator of a network under test. 
     The subject matter described herein can be implemented in software in combination with hardware and/or firmware. For example, the subject matter described herein can be implemented in software executed by a processor. In one exemplary implementation, the subject matter described herein can be implemented using a non-transitory computer readable medium having stored thereon computer executable instructions that when executed by a processor of a computer control the computer to perform steps. Exemplary computer readable media suitable for implementing the subject matter described herein include non-transitory computer-readable media, such as disk memory devices, chip memory devices, programmable logic devices, and application specific integrated circuits. In addition, a computer readable medium that implements the subject matter described herein may be located on a single device or computing platform or may be distributed across multiple devices or computing platforms. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       Preferred embodiments of the subject matter described herein will now be explained with reference to the accompanying drawings, wherein like reference numerals represent like parts, of which: 
         FIG. 1  is a block diagram illustrating an exemplary generalized model for defining application state machines according to an embodiment of the subject matter described herein; 
         FIG. 2  is a block diagram illustrating the exemplary layers of an generalized application emulation model (GAEM) engine according to an embodiment of the subject matter described herein; 
         FIG. 3  illustrates a logical representation of an exemplary finite state machine configured to provide a search functionality for a server actor according to an embodiment of the subject matter described herein; 
         FIG. 4  illustrates a logical representation of an exemplary finite state machine configured to provide a search functionality for a client actor according to an embodiment of the subject matter described herein; 
         FIG. 5  illustrates a logical representation of an exemplary finite state machine configured to provide an upload functionality for a client actor according to an embodiment of the subject matter described herein; 
         FIG. 6  illustrates a logical representation of an exemplary finite state machine configured to provide an upload functionality for a server actor according to an embodiment of the subject matter described herein; and 
         FIG. 7  is a flow chart for utilizing a generalized model for defining application state machines according to an embodiment of the subject matter described herein. 
     
    
    
     DETAILED DESCRIPTION 
     In accordance with the subject matter disclosed herein, methods, systems, and computer readable media for generalized model for defining application state machines are provided. In some embodiments, the subject matter described herein relates to a network test system that generates highly realistic network user traffic associated with various protocols at large scale (e.g., a large number of simultaneous user emulations) for the purposes of testing a device under test (DUT) or system under test (SUT). In some embodiments, the disclosed subject matter may pertain to applications beyond network testing, such as network monitoring, network security, facilitating smart contracts, and the like. 
     In some embodiments, the disclosed subject matter may be implemented as an application security testing system  102 . As shown in  FIG. 1 , application security testing system  102  includes a user interface (UI) configuration engine  104 , a state machine (SM) model synthesizer  106 , a state machine library  108 , a test management controller  110 , a client agent  114 , and a server agent  116 . Notably, a DUT  122  (or SUT) can be communicatively connected (e.g., a wired connection or wireless connection) to system  102  via the client agent  114  and the server agent  116 . 
     As shown in  FIG. 1 , application security testing system  102  includes a UI configuration engine  104  that is configured to enable a test operator to specify a test case that can be used to test DUT  122 . For example, UI configuration engine  104  can be configured to define a test case that includes various emulated user network behaviors and an application business logic associated with an application being used by DUT  122 . Application security testing system  102  further includes a generalized SM model synthesizer  106  that is adapted to synthesize and/or generate a state machine traffic model that includes a plurality of state machine definitions and is based on the aforementioned specified user network behaviors and application business logic. 
     In some embodiments, SM model synthesizer  106  can be configured to synthesize the state machine definitions of the state machine traffic model using a high-level programming language (e.g., Python). Further, the state machine definitions can be synthesized using a high-level programming such that the state machine models can be segmented into state machine fragments. These state machine fragments can be programmed or logically interconnected by SM model synthesizer  106  to provide a desired testing functionality. Further, the state machine fragments can be stored by SM model synthesizer  106  in a local SM library  108  for subsequent access and use. More specifically, state machine definitions can be synthesized by synthesizer  106  using a reusable and extensible library of state machine fragments (SMFs) maintained in SM library  108 . Further, the SMFs may be written in Python or other suitable programming language. Different test operator objectives and/or goals may require the synthesis of various SM-based traffic definitions, which are constructed and dynamically implemented into a generalized application emulation model (GAEM) engine (e.g., GAEM engine  118  or  120 ). 
     In some embodiments, a GAEM engine is responsible for establishing and defining a plurality of state machines corresponding to the state machine definitions received from controller  110 . Notably, a GAEM engine can be a generic and/or protocol agnostic engine that can be implemented in software and run on a wide variety of test system-related hardware nodes. For example, the hosting hardware node can include an adjunct server, an appliance device, an internal processor, or the like. Other nodes can comprise an hardware component with an installed operating system. Alternatively, a node as used herein can be a virtual machine, cloud computing instance, or the like. In some embodiments, the GAEM engine is implemented in software that can be incorporated into and/or executed by an agent, such as client agent  114  or server agent  116  as shown in  FIG. 1 . Namely, the software implementation is not dependent on any test system hardware of any particular vendor. Software embodiments of GAEM engine  112  may run in many environments including, but not limited to, new network monitoring appliances, old network monitoring modules, off-the-shelf servers, virtual machines, cloud instances, and/or the like. Alternatively, the GAEM engine may be implemented as a dedicated hardware component. 
     Notably, the state machine definitions of a state machine traffic model may be provided by SM model synthesizer  106  to test management controller  110  for distribution to GAEM engines  118  and  120 . In some embodiments, test management controller  110  is primarily responsible for managing all of the agents (and their respective host nodes) in system  102 . For example, test management controller  110  can be configured to distribute the different state machine definitions (e.g., application definitions) and associated user inputs to the different agents (e.g., agents  114  and  116 ). Test management controller  110  can also be configured to assign different application profiles or roles to each of the agents based on the state machine definitions and associated user inputs (that the controller distributes among all the agents). 
     As indicated above, the application state machine definitions (along with user input data) can be delivered and provisioned in a GAEM engine, which provides a state machine execution environment. Notably, there is a GAEM engine residing in each agent of application security test system  102 , e.g., client agent  114  and server agent  116 . Once the state machine definitions are provisioned in the agents, each GAEM engine can use the definitions to execute the application state machines, which are configured to perform one or more test emulation functions, such as generating test network traffic. Specifically, the client and server agents are configured to generate network traffic test packets and packet flows in accordance with the definitions of the executed SM model. As shown in  FIG. 1 , client agent  114  and server agent  116  can bidirectionally communicate test packets and/or flows via DUT  122 . In some embodiments, the application state machine definitions provisioned on the agents define the agents as specific actors (e.g., a server actor or a client actor). Specifically, after receiving the application profile from test management controller  110 , the GAEM engine will begin emulating an element that complies with the defined application role (e.g., generate the test traffic profile of interest). For example, the client agent  114  may be defined by a provisioned state machine definition as a client actor (e.g., a client machine requesting a service or data from a server) while server agent  116  may be defined by a provisioned state machine definition as a server actor (e.g., an image storage server, a video server, a database server, a web server, and the like that is configured for receiving client requests). 
     In some embodiments, the GAEM engine is configured to use the synthesized SM definitions (e.g., application state machine definitions) to define and generate a respective application state machine that is executed within an agent. For example, each state machine can be defined by a set of states ( ), a set of events ( ), a set of actions ( ), an initial state ( ), and a map. For example, an exemplary state machine can be defined as follows:
 
 → i.e.,
 
     −   
 
     Notably, each action is defined as a sequence of well-known instructions. Each application state machine definition also includes a set of exposed operations ( ). In some embodiments, the operation includes a plurality of elements, where each element is a tuple comprising i) an initiating event, ii) a set of states indicating successful termination, and iii) a set of statistics indicating failed termination. 
     According to another aspect of the subject matter described herein, one application definition can inherit a definition from another application state machine definition. Since each application state machine definition is composed of transition tables and/or maps (represented by   in the examples above), emulated applications can be extended by referring to base transition tables and defining differences existing in the base transition tables in terms of i) adding new transitions to the base tables, ii) deleting transitions from the base tables, and/or iii) modifying transitions in the base tables. Notably, the application definition may define a plurality of actors (e.g., one or more server actors and client actors) that are involved with the execution of an application. 
     In some embodiments, client agent  114  and server agent  116  may each include traffic generation hardware modules (e.g., transmission hardware engines) that are implemented, at least in part, in programmable logic devices such as field programmable gate arrays (FPGAs) and/or multi-core central processing units (CPUs). These traffic generation hardware modules further include networking device ports that can be used to establish a connection with the device under test  122 . As shown in  FIG. 1 , agents  114 - 116  are configured to communicate test packets or flows in a bidirectional manner via DUT  122 . In some alternate embodiments, client agent  114  and server agent  116  can comprise software constructs that include software-based ports. As indicated above, client agent  114  and server agent  116  are designed to provide SM execution environments that are capable of loading and executing one or more application state machines. Notably, execution of the state machine drives the lower-layer transmission and receiving agents to communicate test packets and associated packet flows that are associated with emulated network users in a particular test case scenario. More specifically, agents  114 - 116  are designed to receive instructions provided by the output of the application state machines (of the GAEM engine), which provides instructions that define and control the generation of test packets and packet flows associated with highly realistic emulations of network end users. 
     Although not depicted in  FIG. 1 , test system  102  may include at least one processor and memory. In some embodiments, the processor includes a microprocessor, such as a central processing unit (CPU), or any other hardware-based processor unit that is configured to execute and/or utilize software and/or algorithms associated with test system  102  (e.g., GAEM engines  118 - 120 , test management controller  110 , agents  114 - 116 , and the like) and any platforms associated therewith. Further, memory included in test system  102  (e.g., a memory element or device) may include a random access memory (RAM), a read only memory (ROM), an optical read/write memory, a cache memory, a magnetic read/write memory, a flash memory, or any other non-transitory storage media. In some embodiment, the processor and memory may be used to execute and manage the operation of test system  102  and/or the GAEM engines. 
       FIG. 2  is a block diagram illustrating the exemplary construct layers of a GAEM engine that includes a number of generated application state machine according to an embodiment of the subject matter described herein. In one implementation, a GAEM engine provisioned on an agent used by test system  102  (shown in  FIG. 1 ) can be organized into three functional layers: i) Layer  1 —Behavioral, ii) Layer  2 —Business Logic, and iii) Layer  3 —On-The-Wire. As shown in  FIG. 2 , the first layer is represented by a user behavior state machine construct layer  202  that is intended to model the high-level behaviors of one or more emulated network users. For example, these behaviors can be modeled as the particular applications and services that are being used and/or accessed by emulated network users along with their respective timing and frequency of use. More specifically, user behavior state machine construct layer  202  may comprise a state machine that is configured to simulate a number of scenarios representative of emulated user actions. In some embodiments, the emulated user behaviors (or scenarios) generated by construct layer  202  can be represented as parallel tracks  206 - 208 . Notably, each of the parallel tracks  206 - 208  can be a sequence of operations exposed by one or more applications. Further, each of these operations can be adapted to invoke and/or trigger one or more of the application state machines. In addition, construct layer  202  can be configured to synchronize parallel tracks  206 - 208  with each other at different synchronization points  214 . Notably, synchronization points can be utilized by the constructs layer to ensure that certain operations emulating the different user behaviors are conducted at particular points in time and/or contemporaneously with each other. In some embodiments, the tracks can represent user behaviors such as listening to Internet radio, accessing data from different web browser tabs, conducting a banking transaction, sending an email, and/or the like. 
     Similarly, the second layer is represented in  FIG. 2  as a business logic state machine construct layer  204  that is configured to model and emulate application and service access rules and policies that are defined by the operator of the DUT or SUT. These defined rules and policies may be provided to test system  102  via the test user interface engine  104  as depicted in  FIG. 1 . In some embodiments, application business logic state machine construct layer  204  comprises a finite state machine that can be defined by application developers, such as system engineers or client operators. Notably, application business logic state machine construct layer  204  interacts or communicates with user behavior state machine construct layer  202  via the filing of events. For example, construct layer  202  can be configured to issue operation initiation events to file or issue operation initiation events to application business logic state machine construct layer  204 . In response, construct layer  204  can be configured to issue operation completion notifications to user behavior state machine construct layer  202  as a filed event(s). 
     Lastly, the on-the-wire SM construct layer is represented as a message parsing state machine construct layer  205  that is configured to model and emulate the messaging and associated messaging protocols used by an emulated network user. As shown in  FIG. 2 , message parsing state machine construct layer  205  comprises a finite state machine that is adapted to provide external network events. For example, message parsing state machine construct layer  205  is configured to issue timer expiration events to business logic state machine construct layer  204 . Likewise, message parsing state machine construct layer  205  is configured to receive timer schedule events that are filed by business logic state machine construct layer  204 . For example, a timer can be started and subsequently generated event after an expiration period. One example includes the application state machine being in a state where it sends a request and then initiate the timer. As such, a second event may occur depending on whether or not a response message is received in response to the request prior to the expiration of the timer. 
     Another source of events can be attributed to the input/output activity occurring in the lower layer of the application (e.g., lower layer I/O  218 ). In particular, input/output (I/O) events can be filed from message parsing state machine construct layer  205  to application business construct layer  204  as shown in  FIG. 2 . For example, a common source of evens are I/O packets that are received on-the-wire from the network and are indicative of events, such as the establishing of a connection or the disconnecting of a connection. The I/O packets may also comprise any type of message and/or protocol type. Examples of I/O packets include, but are not limited to, hypertext transfer protocol (HTTP) requests, HTTP responses, simple mail transfer protocol (SMTP) messages, Internet message access protocol (IMAP) messages and the like. 
     Furthermore, lower layer I/O  218  can also be configured to send packets to a message parsing logic state machine  220  hosted by message parsing state machine construct layer  205 . In some embodiments, the packets received by message parsing logic state machine  220  are received over the wire via a network interface port. Notably, message parsing logic state machine  220  is configured to receive the packets and forward them to application business construct layer  204  for processing. In some embodiments, application business construct layer  204  is configured to determine the initial state of the application state machine, inspect the bytes or signature contained in the received packets. Depending on the protocol or data indicated by the inspected bytes/signature in the packets, application business construct layer  204  is configured to utilize the determined data and the determined initial state to access a state transition table. Notably, the state transition table will indicate if the particular event associated with the initial state and the determined data has triggered a transition in the state machine. For example, message parsing state machine construct layer  205  can utilize this process to discern between whether certain expected attachments were received or alternatively, an error occurred. 
       FIG. 3  illustrates an exemplary finite state machine  300  that is configured to function as an application&#39;s message parsing logic provisioned on a server agent (e.g., server agent  116  shown in  FIG. 1 ) that is functioning as a ‘server actor’. In this exemplary embodiment, the application features a search functionality for images that are stored on the server agent (or server actor). As shown in  FIG. 3 , finite state machine  300  includes a plurality of parsing logic states  310 - 316  that may be traversed in response to transitions  321 - 330 . For example, state machine  300  may start at the initial state “P_S 0 ” and transition based on the occurrence of an event. For example, the server agent portion (e.g., acting as an image file storage server) of the application may be configured to trigger an event in response to receiving a search request from a client actor. Notably, the state machine may reference a state transition table that indicates that state machine  300  proceeds to state  311  in response to an HTTP GET search request message (see transition  321 ). In particular, a transition from state  310  to state  311  transpires and the state machine  300  is in “searching image received” state that is represented as P_S 1 . The state machine  300  can then utilize this state information to access a state transition table to determine that a “search response message” (e.g., see transition  322 ) should be sent. As shown in  FIG. 3 , the sending of the search response message triggers a transition back to P_S 0  state  310 .  FIG. 3  depicts other states and transitions that can be executed and or exposed based on the protocol (e.g., HTTP, SQL, Microsoft SCCM, McAfee, etc.) of the message received by the server agent portion of the application. 
       FIG. 4  illustrates an example finite state machine  400  that is configured to function as an application&#39;s message parsing logic provisioned on a client actor (e.g., transmission agent  114  shown in  FIG. 1 ). In this exemplary embodiment, the application features a client actor that is communicating with an image server agent/actor with respect to the image search requests described above and depicted in  FIG. 3 . As shown in  FIG. 4 , finite state machine  400  includes two parsing logic states  410 - 411  that may be traversed in response to transitions  321 - 330 . For example, the state machine  400  may start at the initial state “P_C 0 ” and experience a transition  421  based on the occurrence of an event. For example, the client agent portion (e.g., acting as the requesting entity for an image file stored on the server actor) of the application may be configured to trigger an event in response to receiving a response from the server actor. For example, the client agent portion of the application may be configured to trigger an event in response to receiving a search result response from the server actor. Notably, the state machine  400  may reference a state transition table that indicates that state machine  400  is to transition to state  411  (“P_C 1 ”) in response to receiving an HTTP response message. State machine  400  can then utilize this state information to access the state transition table to determine that a “Generic Response Message” (e.g., see transition  422 ) should be sent. As shown in  FIG. 4 , the sending of the response message triggers a transition back to P_C 0  state  410 . 
       FIG. 5  illustrates an example finite state machine  500  that is configured to function as an application&#39;s business logic that provisioned on a client actor (e.g., client agent  114  shown in  FIG. 1 ). In this exemplary embodiment, the application features a client actor that is attempting to store an image on the server actor. As shown in  FIG. 5 , finite state machine  500  includes two application business logic states  510 - 511  that may be transitioned in response to transition events  521 - 525 . For example, state machine  500  may start at initial state “P_A 0 ” (e.g., state  510 ) and can be configured to proceed to state A_C 1  (e.g., state  511 ) by way of transitions  521 - 524 . For example, state machine  500  can refer to a state transition table in response to an event transpiring. Events such as searching for an image, uploading an image, or receiving a system vulnerability alert, such as a message from a McAfee application or a Microsoft System Center Configuration Manager (SCCM) application. Notably, any of these events trigger a transition to state  511 . At this state, state machine  500  is configured to inspect the packets associated with the message and reference a state transition table using the originating state  510  and the packet data to determine if state machine  500  transitions to state  510 . For example, a response can be sent to the event originator, thereby triggering a return transition to A_C 0  (e.g., state  510 ), which represents that a generic response was received by the client actor. 
       FIG. 6  illustrates an example finite state machine  600  that is configured to function as an application&#39;s business logic provisioned on a server agent  116  as shown in  FIG. 1 . In this exemplary embodiment, the application features an upload functionality that allows a client agent to store an image on the server agent (or server actor). As shown in  FIG. 6 , finite state machine  600  includes a plurality of business logic states  610 - 614  that may be transitioned in response to transitions  621 - 628 . For example, state machine  600  may start at the initial state “S_S 0 ” and experience any number of transitions based on the occurrence of an associated event. For example, the server agent portion of the application may be configured to trigger a transition in response to receiving an upload request from a client actor. Notably, the state machine may reference a state transition table that indicates that state machine  600  proceeds to state  611  in response to a search response message  621 . In particular, a transition from state  610  to state  611  transpires and the state machine  600  is in “send images” state that is represented as A_S 1 . The state machine  600  can then utilize this state information to access a state transition table to determine that a “send complete message” (e.g., see transition  622 ) should be sent. As shown in  FIG. 6 , the sending of the send complete message triggers a transition back to A_S 0  state  610 .  FIG. 6  depicts other states and transitions that can be executed and or exposed based on the protocol (e.g., HTTP, SQL, Microsoft SCCM, McAfee, etc.) of the message received by the server agent portion of the application. 
       FIG. 7  is a flow chart illustrating an exemplary method  700  for implementing a generalized model for defining application state machines according to an embodiment of the subject matter described herein. In some embodiments, blocks  702 - 708  of method  700  may represent an algorithm that is stored in memory and executed by one or more processors of application security test system  102 . 
     In block  702 , method  700  includes utilizing a user behavioral state machine construct layer of a generalized application emulation model (GAEM) system to emulate a plurality of high level user behaviors originating from a plurality of emulated network users. In some embodiments, the high level user behaviors are represented as parallel tracks, wherein each of the parallel tracks is a sequence of operations that is exposed by one or more applications. 
     In block  704 , method  700  includes utilizing a business application logic state machine construct layer in the GAEM system to emulate access rules (e.g., service access rules) and policies of an application to be defined. 
     In block  704 , method  700  includes utilizing a message parsing state machine construct layer in the GAEM system to emulate input/output (IO) events and network messaging events originating from emulated network entities. 
     In block  706 , method  700  includes utilizing at least one network traffic processing agent in the GAEM system that is configured to establish an execution environment for facilitating the interactions among the user behavioral state machine construct layer, business application logic state machine construct layer, and the message parsing state machine construct layer such that when executed in the execution environment, the interactions establish a definition for a state machine that is representative of the application. 
     It should be noted that each of the GAEM engine and/or functionality described herein may constitute one or more special purpose computing devices constituting a practical application. Further, embodiments of the GAEM and/or functionality described herein can improve the technological field of network traffic testing environments by implementing a new test system that produces realistic and complex mixes of network traffic associated with a large number of users. For example, the use of a GAEM engine system enables a DUT/SUT test operator to describe network user behaviors at a high level as well as to specify application business logic rules that are to be applied in the DUT/SUT. As such, large scale testing scenarios (e.g., large number of simultaneous user emulations) may be conducted in a more efficient and realistic manner while also utilizing less computing resources than other network testing implementations. 
     It will be understood that various details of the subject matter described herein may be changed without departing from the scope of the subject matter described herein. Furthermore, the foregoing description is for the purpose of illustration only, and not for the purpose of limitation.