Computer implementation methods, computer programs, and computer systems (test case factorization optimization)

Abstract

Existing software testing methodologies are inefficient for various reasons. [Solution] One embodiment decomposes each test case from a set of multiple test cases into a set of multiple test case units. This embodiment constructs a graph data structure based on the set of multiple test case units, where each path in the graph data structure corresponds to one test case from the set of multiple test cases. This embodiment detects a first test case scenario, where the first test case scenario corresponds to the first part of the set of multiple test cases. When the first test case scenario is detected, this embodiment scans the first part of the multiple paths in the graph data structure, where scanning the paths of the first part of the multiple paths triggers the assembly of the test cases of the first part of the multiple test cases. This embodiment executes each test case assembled as a result of scanning each path of the first part of the multiple paths in the graph data structure.

Description

Technical Field

[0001] The present invention generally relates to software testing. More specifically, the present invention relates to a method, system, and computer program for test case factorization optimization.

Background Art

[0002] Software testing is a process of systematically evaluating a software application to ensure that a particular application or component meets specified requirements, functions as intended, and / or is free of defects. Software testing typically involves running the software in a controlled environment to identify errors, gaps, or missing functionality against expected outcomes. Software testing can involve various methodologies including, but not limited to, manual testing, automated testing, functional testing, performance testing, and the like.

[0003] In the context of software testing, a test case is a specific predefined condition or series of steps designed to verify whether a software application or component behaves as expected under specific inputs, environments, and / or scenarios. A test case typically includes test input, execution conditions, and expected results. Thus, test input can include data or actions applied to the system, execution conditions can include preconditions or system states required for the test, and expected results can include the outcomes expected if the system, application, or component functions correctly. Test cases can be used to identify bugs or behavioral discrepancies, ensuring that the software meets requirements and functions as intended.

[0004] In the context of computer data structures, a graph is a data structure that includes nodes (or vertices) representing data points and edges representing connections or relationships between nodes. Graphs are a highly efficient way to break down and store similar data by leveraging their ability to represent those relationships and shared connections. When data share common attributes or relationships, graphs can eliminate redundancy by storing these shared elements only once and linking them appropriately. [Overview of the project] [Problems that the invention aims to solve]

[0005] Existing software testing methodologies are inefficient for various reasons. For example, software testing involves memorizing a vast amount of data corresponding to test cases. Furthermore, this data may include many redundant and / or duplicate software tests stored in the system or organization's test case database. [Means for solving the problem]

[0006] Exemplary embodiments provide test case factorization optimization. One embodiment comprises the step of decomposing each test case from a set of multiple test cases into a set of multiple test case units. The embodiment also comprises the step of constructing a graph data structure based on the set of multiple test case units, wherein each path in the graph data structure corresponds to one test case from the set of multiple test cases. The embodiment also comprises the step of detecting a first test case scenario, wherein the first test case scenario corresponds to a first portion of the set of multiple test cases. The embodiment also comprises the step of traversing a first portion of the paths in the graph data structure when the first test case scenario is detected, wherein the step of traversing the paths of the first portion of the paths causes the assembly of the test cases of the first portion of the multiple test cases. The embodiment also comprises the step of executing each test case assembled as a result of traversing each path of the first portion of the paths in the graph data structure.

[0007] One embodiment comprises a computer-readable program product. The computer-readable program product has a computer-readable storage medium and program instructions stored on the storage medium.

[0008] One embodiment comprises a computer system, the computer system having a processor, computer-readable memory, and a computer-readable storage medium, and program instructions stored on the storage medium for execution by the processor via the memory. [Brief explanation of the drawing]

[0009] Novel features considered to be characteristic of the present invention are described in the appended claims. However, the present invention itself, as well as preferred modes of use, further purposes, and their advantages, will be best understood by referring to the following detailed description of exemplary embodiments, when read in conjunction with the appended drawings.

[0010] [Figure 1] A block diagram of an example computing environment according to an exemplary embodiment is shown.

[0011] [Figure 2] A block diagram of an example computing environment according to an exemplary embodiment is shown.

[0012] [Figure 3] A block diagram of an example of a test case factorization optimization software module according to an exemplary embodiment is shown.

[0013] [Figure 4] A block diagram of an example system architecture according to an exemplary embodiment is shown.

[0014] [Figure 5] A graphical diagram of an example of the process for optimizing test case factorization according to an exemplary embodiment is shown; and

[0015] [Figure 6] A flowchart of the process for optimizing test case factorization according to an exemplary embodiment is shown. [Modes for carrying out the invention]

[0016] Existing software testing methodologies are inefficient for various reasons. For example, software testing involves memorizing a vast amount of data corresponding to test cases. Furthermore, this data may include many redundant and / or duplicate software tests stored in the system or organization's test case database.

[0017] The inefficiencies of current software testing methods stem from a variety of factors. For example, testers and developers waste time on redundant test execution, reducing the time available for other critical activities such as creating new tests or fixing defects. Furthermore, especially in cloud-based or large-scale systems, automated test suites that run redundant tests consume more computing resources, leading to extended execution times and increased costs.

[0018] Furthermore, redundant testing can prolong the overall testing process, delaying feedback to developers, slowing down the development cycle, and increasing the time required to identify and fix problems. Moreover, redundant testing can create a false sense of comprehensive testing, as the team or automated system may mistakenly believe that the system has been thoroughly tested, even when the redundant tests do not actually provide any additional value.

[0019] Furthermore, maintaining duplicate tests increases development effort and complexity. As the codebase evolves, additional effort is required to keep redundant tests up-to-date, making test maintenance more difficult and error-prone. Thus, a bloated test suite containing duplicates becomes increasingly difficult to scale, especially as the codebase and test suite continue to grow. Additionally, when duplicate tests fail, they can produce redundant failure reports, which introduce unnecessary noise into the test results. Overall, the time and resources spent on duplication could be better utilized to create new, high-value tests to verify untested areas of the application, improving overall test coverage and software quality.

[0020] Therefore, these inefficiencies described above can be at least partially addressed through the development of more advanced techniques that leverage the factorization and refactoring of test cases through an iterative optimization process. By overcoming the inefficiencies of existing methods, systems and organizations can achieve more efficient and cost-effective computer resource management for software test execution. The following disclosure addresses the deficiencies described above and includes iterative refactoring techniques for storing and executing software tests.

[0021] Thus, the present disclosure addresses the deficiencies described above by providing a process (as well as a system, method, machine-readable medium, etc.) for developing a system for test case factorization optimization. In one embodiment, the process employs software modules designed to optimize software test case factorization and test case deployment across a computer network environment. Inputs to the test case factorization module may include various types of software tests that can be executed across a computer environment to test the functionality of various applications and / or components of the system. By analyzing these inputs, the process generates and outputs a graph-based data structure that efficiently stores the software tests. The output graph of the process provides an efficient data storage scheme for software tests that reduces and / or eliminates the presence of unnecessary, redundant, and / or duplicate code associated with the software tests stored on the graph structure.

[0022] Currently, there are no existing systems or methods that consider test case factorization, graph-based storage, and iterative weighted automated software testing. In some embodiments, the software test execution described herein can be optimized for maximum coverage of the associated software tests. However, the use of this example is for illustrative purposes only, and the optimization goals can include other types of specified optimization goals such as, for example, minimization of computer resources and / or power consumption related to the deployment and execution of software tests, prioritization of important or critical software tests when limited execution resources are provided, and the like. In some embodiments, the specified optimization goals can include any optimization goals specified by a user having sufficient privileges.

[0023] In one embodiment, the system may include a test case factorization module configured to factorize multiple test cases into multiple test case units. Furthermore, in one embodiment, the test case factorization module may be configured to construct a graph data structure from the multiple test case units. Furthermore, in one embodiment, the test case factorization module may be configured to automatically execute test cases by traversing multiple paths of the graph data structure. In one embodiment, the test case factorization module includes a monitoring module, an analysis module, a decomposition module, a mapping module, a graph module, an assembly module, and an optimization module.

[0024] The following description provides examples of embodiments of the present disclosure, which may be modified and substituted in other embodiments. Herein, several examples are provided to further clarify the various aspects of the present disclosure.

[0025] Example 1: A computer implementation method comprising the step of decomposing each test case from a set of multiple test cases into a set of multiple test case units. The method further comprises the step of constructing a graph data structure based on the set of multiple test case units, wherein each path in the graph data structure corresponds to one test case from the set of multiple test cases. The method further comprises the step of detecting a first test case scenario, wherein the first test case scenario corresponds to a first part of the set of multiple test cases. The method further comprises the step of scanning a first part of the multiple paths of the graph data structure when the first test case scenario is detected, wherein scanning the paths of the first part of the multiple paths causes the assembly of test cases for the first part of the multiple test cases. The method further comprises the step of executing each test case assembled as a result of scanning each path of the first part of the multiple paths of the graph data structure.

[0026] The above limitations allow for advantageous efficient storage and execution of test cases. Therefore, by factorizing multiple test cases into multiple test case units and storing them as a sequence of test case units along a graph data structure, the amount of data storage resources required to store the same number of test cases using conventional methods is significantly reduced. Furthermore, by factorizing multiple test cases into multiple test case units and storing them as a sequence of test case units, it is prevented that the test case database storing test cases will be filled with duplicate and / or redundant test case inclusions. Moreover, efficient test case execution is provided by leveraging the graph data structure to execute test cases in response to the detection of test case scenarios, and as a result, efficiency is maximized according to a user-specified graph traversal algorithm.

[0027] Example 2: A limitation of Example 1, further comprising assigning weight values ​​to each node in the graph data structure based on the number of connections to other nodes.

[0028] The above limitations allow for the advantageous prioritization of critical functions, scenarios, or test cases based on their importance, complexity, and / or execution frequency. This prioritization enables a more efficient allocation of test resources, focusing on high-impact areas of the software system. Furthermore, weight values ​​provide a quantitative measure of the importance of each node, guiding the test strategy and optimizing the test sequence.

[0029] Example 3: The number of connections to other nodes corresponds to the limit in Example 2, which is the number of connections to child nodes.

[0030] The above limitations favorably allow for prioritizing nodes that have a significant impact on the overall system behavior or test coverage. This approach enables the test framework to limit tests to test cases that have a higher impact on the system's functionality. By assigning weights based on connections to child nodes, the test process becomes more focused, efficient, and effective in identifying and addressing the most relevant areas of the software system.

[0031] Example 4: The number of connections to other nodes corresponds to the limit in Example 2, which is the number of connections to the parent node.

[0032] The above limitations allow for advantageous prioritization of nodes with multiple dependencies. Therefore, nodes with multiple connections to a parent node may represent core components or critical functions that affect various parts of the software system. By assigning weights based on connections to the parent node, the testing process considers the hierarchical structure and dependencies within the software system, facilitating targeted testing, efficient resource allocation, and comprehensive verification of key components.

[0033] Example 5: The number of connections to other nodes is limited to the same number as in Example 2, corresponding to the combination of child and parent nodes connected to a node.

[0034] The above limitations favor a comprehensive assessment of the importance and impact of each node within the graph data structure. Nodes with a large number of connections to both parent and child nodes are likely to represent critical decision points in the software system. By assigning weights based on this combined metric, nuanced prioritization of nodes that significantly impact the overall system behavior and test coverage becomes possible. By assigning weight values ​​based on the combination of parent and child node connections, the test process considers a holistic perspective on the interdependencies within the software system.

[0035] Example 6: The constraint of Example 2, where each path of the first part of multiple paths in a graph data structure is performed in an order at least partially based on the cumulative weight values ​​corresponding to the execution of each path.

[0036] The above limitations allow for advantageous prioritization of test case execution. Prioritizing test case execution is particularly important for efficient resource consumption when running software tests. Therefore, paths with higher cumulative weights may be executed before paths with relatively lower cumulative weights. By prioritizing test case execution by scanning paths with higher cumulative weights, more important tests may be executed before less important tests, based on user specifications. For example, more comprehensive tests, such as those with greater coverage, may be executed before less comprehensive tests, such as niche tests that may have less impact on a particular software system or component.

[0037] An exemplary embodiment provides test case factorization optimization. Where used throughout this disclosure, the term “test case” refers to a set of specific conditions, inputs, and / or expected outcomes designed to evaluate whether a particular feature or function of a software application behaves as intended. In one embodiment, a test case includes a test case identifier corresponding to a unique name and / or number for identifying, tracking, and / or referencing a particular test case, a test objective description including a description of what the test is intended to verify, and / or a set of prerequisites and / or requirements or setups required before the test is performed. Furthermore, a test case may include test data that may include a set of test phases, or the sequence of actions or inputs to be performed, and specific inputs to be used in the test. Additionally, a test case may include expected outcomes, which may include the results or behaviors expected when the software is functioning correctly, as well as post-conditions including the state of the system, application, or component after the test has been performed.

[0038] Where used throughout this disclosure, unless otherwise defined by context, the term “Application” refers to any type of software application that may run whole or in part across units of computing resources. The terms “System,” “Application,” “Component,” and / or “Software” are understood to be used interchangeably and / or interchangeably with each other, depending on the context.

[0039] As used throughout this disclosure, the term “atomic test unit” refers to the smallest, indivisible unit of a test case that represents a single, distinct function or behavior under test within a software system. In some embodiments, an atomic test unit may be independent and self-contained, and may be configured to test a particular aspect or feature of the system in isolation. Thus, atomic test units serve as a fundamental building block for constructing more complex test cases without being further subdivided into smaller test case units. Furthermore, atomic test units can be used for fine-grained testing, enabling precise verification of individual functions and facilitating targeted debugging and analysis during the testing process.

[0040] In one embodiment, a test case can be assembled by traversing a graph data structure and sequentially combining atomic test units along a specific path or sequence, starting from a chain of atomic test units stored on the graph data structure. In some embodiments, the graph data structure hierarchically organizes the atomic test units, each unit representing a specific function or behavior under test. To assemble a test case, one embodiment of the disclosed process starts from the root of the graph and follows a path that connects a series of atomic test units in a logical order. As the traversal progresses downward, each atomic test unit along the path is added to the test case chain, forming a sequence of test stages that collectively verify a specific scenario or function within the software system.

[0041] By storing atomic test units on a graph data structure such as a tree or a directed acyclic graph (DAG), the organization and relationships between different test units are clearly defined, enabling the systematic construction of test cases based on desired test criteria and / or test case scenarios. This approach allows for efficient storage, construction, and execution of test cases, ensuring comprehensive coverage of different functionalities and promoting the reuse of atomic test units across multiple test cases within the test framework.

[0042] When used throughout this disclosure, the term "Coverage Weight" (or simply "C") is used. weight The term "coverage weight" in the context of software testing refers to a quantitative measure assigned to nodes in a graph data structure. In some embodiments, coverage weights represent the importance and contribution of each node to achieving comprehensive test coverage. In some embodiments, coverage weights may be calculated based on factors such as the number of associated test cases, the criticality of the function represented by the node, and the frequency of node traversal during testing. Therefore, assigning coverage weights can be useful for optimizing test coverage by prioritizing test work, effectively allocating resources, and ensuring that nodes with higher weights receive more attention during the testing process.

[0043] In one embodiment, the process of assigning weights to tree nodes to establish coverage weights for each node involves a systematic method for determining the importance and coverage contribution of individual nodes in the graph structure. In one embodiment, this process begins with a coverage analysis, where factors such as the number of associated test cases, the criticality of the function represented by each node, and the frequency of node traversal during testing are considered to assess their impact on coverage. Subsequently, based on the coverage analysis results, C for each node is determined. weightWeight calculations may be performed to determine the weights, ensuring that the assigned weights accurately reflect the importance of each node in achieving comprehensive test coverage.

[0044] In one embodiment, the C of node weight The values ​​are fine-tuned based on their relationships with other nodes, shared functionality, and test dependencies, with nodes that are shared across multiple test cases or have a greater impact on coverage receiving higher C ratings. weight It may receive values. In addition, hierarchical weighting may be applied to take into account the hierarchical structure of the graph data structure, and appropriate C to align with the test priority and critical path in the graph. weight Ensure that values ​​are assigned to parent and child nodes. In this manner, C is assigned to the node. weight By assigning C to nodes, the test process can effectively prioritize relevant functions, optimize test coverage, and efficiently allocate resources to improve the overall quality and reliability of the software system. In some embodiments, the C of nodes weight The values ​​are fine-tuned through an iterative adjustment process, which is described in more detail herein.

[0045] In one embodiment, weighted automated testing is performed in part by calculating the weight of the test unit within each node of a graph structure. As discussed, this calculation may involve, firstly, assigning weights to individual test units based on specific criteria such as coverage importance, criticality, or importance in achieving comprehensive test coverage. Subsequently, in the automated testing phase, all test cases may be automated based on either a coverage-first or importance-first principle, depending on the user's specific requirements. In a coverage-first approach, automated testing prioritizes test cases that cover a wider range of functions and scenarios to ensure comprehensive test coverage across the software system. On the other hand, in an importance-first approach, the focus is on automating test cases that address critical functions or high-priority areas of the system to reduce risk and ensure the reliability of critical functions. By automating test cases according to either a coverage-first or importance-first principle, weighted automated testing optimizes test efficiency, prioritizes critical test areas, and aligns the test work with the user's specific needs and priorities.

[0046] For the sake of clarity in the description and without implying any limitation thereof, exemplary embodiments are described using several exemplary configurations. From this disclosure, those skilled in the art can devise many changes, adaptations, and modifications of the described configurations to achieve the described objectives, these of which are intended to be within the scope of the exemplary embodiments.

[0047] Furthermore, a simplified diagram of the data processing environment is used in the drawings and exemplary embodiments. In actual computing environments, additional structures or components not illustrated or described herein, or structures or components for similar functions to those described herein but different from those shown, may exist without departing from the scope of the exemplary embodiments.

[0048] Furthermore, the exemplary embodiments are described merely as examples with respect to specific actual or hypothetical components. Any particular embodiment of these and other similar artifacts is not intended to limit the invention. Any preferred embodiment of these and other similar artifacts may be selected within the scope of the exemplary embodiments.

[0049] The examples in this disclosure are for illustrative purposes only and do not limit the scope of exemplary embodiments. Any advantages listed herein are merely examples and are not intended to limit the exemplary embodiments. Additional or different advantages may be realized by specific exemplary embodiments. Furthermore, specific exemplary embodiments may include some or all of the advantages listed above, or none of them.

[0050] Furthermore, exemplary embodiments may be implemented with respect to any type of data, data source, or access to a data source via a data network. Any type of data storage device may, within the scope of the invention, provide data to one embodiment of the invention, either locally in a data processing system or via a data network. If one embodiment is described using a mobile device, any type of data storage device suitable for use with a mobile device may, within the scope of the exemplary embodiment, provide data to such embodiment, either locally in the mobile device or via a data network.

[0051] Exemplary embodiments are described using specific code, computer-readable storage media, high-level functions, designs, architectures, protocols, layouts, schematics, and tools only as examples, and do not limit the exemplary embodiments. Furthermore, for the sake of clarity, exemplary embodiments are described in some cases using specific software, tools, and data processing environments. Exemplary embodiments may be used in conjunction with other equivalents or structures, systems, applications, or architectures for similar purposes. For example, other equivalent mobile devices, structures, systems, applications, or architectures may be used in conjunction with such embodiments of the present invention within the scope of the present invention. Exemplary embodiments may be implemented in hardware, software, or a combination thereof.

[0052] The examples in this disclosure are for illustrative purposes only and do not limit the exemplary embodiments. Additional data, behaviors, actions, tasks, activities, and operations can be conceived from this disclosure and are intended to be within the scope of the exemplary embodiments.

[0053] Various aspects of this disclosure are described by explanatory text, flowcharts, block diagrams of computer systems, and / or block diagrams of machine logic included in embodiments of computer program products (CPPs). With respect to any flowchart, depending on the technology involved, operations may be performed in a different order than those shown in a given flowchart. For example, again, depending on the technology involved, two operations shown in consecutive blocks of a flowchart may be performed in reverse order, as a single integrated stage, simultaneously, or with at least partial time overlap.

[0054] Embodiments of a computer program product ("CPP Embodiment" or "CPP") are terms used in this disclosure to describe any set of one or more storage media (also called "mediums") that collectively comprise a set of one or more storage devices that collectively contain machine-readable code corresponding to instructions and / or data for performing computer operations specified in a given CPP claim. "Storage device" is any tangible device capable of holding and storing instructions for use by a computer processor. Computer-readable storage media may, but are not limited to, electronic storage media, magnetic storage media, optical storage media, electromagnetic storage media, semiconductor storage media, mechanical storage media, or any preferred combination thereof. Some known types of storage devices, including these media, include diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), compact disc read-only memory (CD-ROM), digital versatile disk (DVD), memory stick, floppy disk, mechanically encoded devices (such as pits / lands formed on the main surface of a punch card or disk), or any suitable combination of those described above. When the term "computer-readable storage medium" is used in this disclosure, it shall not be interpreted as storage in the form of a transient signal itself, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides, optical pulses passing through optical fiber cables, electrical signals communicated through wires, and / or other transmission media.As will be understood by those skilled in the art, data is normally moved at several intermittent points during the normal operation of a storage device, such as during access, defragmentation, or garbage collection; however, since data is not transient while it is stored, this does not mean that the storage device is transient.

[0055] Referring to Figure 1, this figure shows a block diagram of the computing environment 100. The computing environment 100 includes, for example, an example of an environment for executing at least some of the computer code involved in performing the method of the present invention, such as a test case factorization module 200, which may be configured to factorize a set of multiple test cases into a set of multiple test case units and partially and automatically execute some or all of the set of multiple test cases by traversing one or more paths of a graph data structure in which the test case units corresponding to the set of multiple test cases are stored. In addition to block 200, the computing environment 100 includes, for example, a computer 101, a wide area network (WAN) 102, an end user device (EUD) 103, a remote server 104, a public cloud 105, and a private cloud 106. In this embodiment, the computer 101 includes a processor set 110 (including processing circuits 120 and a cache 121), a communication fabric 111, volatile memory 112, persistent storage 113 (including an operating system 122 and blocks 200 as specified above), a peripheral device set 114 (including a user interface (UI) device set 123, storage 124, and an Internet of Things (IoT) sensor set 125), and a network module 115. The remote server 104 includes a remote database 130. The public cloud 105 includes a gateway 140, a cloud orchestration module 141, a host physical machine set 142, a virtual machine set 143, and a container set 144.

[0056] Computer 101 may take the form of a desktop computer, laptop computer, tablet computer, smartphone, smartwatch, or other wearable computer, mainframe computer, quantum computer, or any other form of computer or mobile device, currently known or to be developed in the future, that can run programs, access networks, or query databases such as remote database 130. As is well understood in the field of computer technology, and depending on the technology, the execution of a computer implementation method may be distributed among multiple computers and / or multiple locations. On the other hand, in this presentation of computing environment 100, in order to keep the presentation as simple as possible, the detailed discussion focuses on a single computer, specifically computer 101. Although computer 101 is not shown in the cloud in Figure 1, it may be located in the cloud. On the other hand, computer 101 is not required to be located in the cloud, except to any extent that can be definitively shown.

[0057] The processor set 110 includes one or more computer processors of any type currently known or to be developed in the future. The processing circuitry 120 may be distributed across multiple packages, for example, multiple coordinated integrated circuit chips. The processing circuitry 120 may implement multiple processor threads and / or multiple processor cores. The cache 121 is memory located within the processor chip package and is typically used for data or code that should be available for high-speed access by threads or cores running on the processor set 110. The cache memory is typically organized into multiple levels depending on its relative proximity to the processing circuitry. Alternatively, some or all of the cache for the processor set may be located "off-chip". In some computing environments, the processor set 110 may operate with qubits and be designed to perform quantum computing.

[0058] Computer-readable program instructions are typically loaded onto computer 101, causing the processor set 110 of computer 101 to execute a series of operational steps, thereby enabling the computer implementation method. As a result, the instructions thus executed instantiate the method specified in the flowcharts and / or descriptions of the computer implementation method contained herein (collectively referred to as the "Method of the Invention"). These computer-readable program instructions are stored in various types of computer-readable storage media, such as cache 121 and other storage media discussed below. The program instructions and associated data are accessed by the processor set 110 to control and direct the execution of the Method of the Invention. In computing environment 100, at least some of the instructions for executing the Method of the Invention may be stored in block 200 in persistent storage 113.

[0059] The communication fabric 111 is a signal conduction path that enables various components of the computer 101 to communicate with one another. Typically, this fabric is made up of switches and conductive paths, such as buses, bridges, physical input / output ports, and similar components. Other types of signal communication paths may be used, such as fiber optic communication paths and / or wireless communication paths.

[0060] Volatile memory 112 is any type of volatile memory currently known or to be developed in the future. Examples include dynamic random access memory (RAM) or static RAM. Typically, volatile memory 112 is characterized by random access, but this is not required unless explicitly stated. In computer 101, volatile memory 112 is located in a single package and resides inside computer 101, but alternatively or additionally, volatile memory may be distributed across multiple packages and / or located externally to computer 101.

[0061] The persistent storage 113 is any form of non-volatile storage for a computer, currently known or to be developed in the future. The non-volatility of this storage means that the stored data is maintained regardless of whether power is supplied to the computer 101 and / or directly to the persistent storage 113. The persistent storage 113 may be read-only memory (ROM), but typically at least a portion of the persistent storage allows for writing, deleting, and rewriting of data. Some well-known forms of persistent storage include magnetic disks and solid-state storage devices. The operating system 122 can take multiple forms, such as various known proprietary operating systems or open-source portable operating system interface type operating systems employing a kernel. The code contained in block 200 typically includes at least a portion of computer code involved in performing the method of the present invention.

[0062] The peripheral device set 114 includes a set of peripheral devices for the computer 101. Data communication connections between the computer 101's peripheral devices and other components can be implemented in various ways, including Bluetooth® connections, Near-Field Communication (NFC) connections, connections made by cables (such as Universal Serial Bus (USB) type cables), insert-type connections (e.g., Secure Digital (SD) cards), connections made through local area communication networks, and even connections made through wide area networks such as the Internet. In various embodiments, the UI device set 123 may include components such as a display screen, speaker, microphone, wearable devices (such as goggles and smartwatches), keyboard, mouse, printer, touchpad, game controller, and haptic devices. Storage 124 is external storage such as an external hard drive, or insertable storage such as an SD card. Storage 124 may be persistent and / or volatile. In some embodiments, storage 124 may take the form of a quantum computing memory device for storing data in the form of qubits. In embodiments where computer 101 is required to have a large amount of storage (for example, when computer 101 locally stores and manages a large database), this storage may be provided by peripheral storage devices designed to store very large amounts of data, such as a storage area network (SAN) shared by multiple geographically distributed computers. The IoT sensor set 125 consists of sensors that can be used in Internet of Things applications. For example, one sensor may be a thermometer and another may be a motion detector.

[0063] The network module 115 is a collection of computer software, hardware, and firmware that enables computer 101 to communicate with other computers via the WAN 102. The network module 115 may include hardware such as a modem or Wi-Fi® signal transceiver, software for packetizing and / or depacketizing data for communication network transmission, and / or web browser software for communicating data over the Internet. In some embodiments, the network control and network forwarding functions of the network module 115 are performed on the same physical hardware device. In other embodiments (e.g., embodiments utilizing Software-Defined Networking (SDN)), the control and forwarding functions of the network module 115 are performed on physically separate devices, such that the control function manages multiple different network hardware devices. Computer-readable program instructions for performing the method of the present invention can typically be downloaded to computer 101 from an external computer or external storage device via a network adapter card or network interface included in the network module 115.

[0064] WAN102 is any wide area network (e.g., the Internet) capable of communicating computer data over non-local distances using any currently known or future-developed technology for communicating computer data. In some embodiments, WAN102 may be replaced and / or complemented by a local area network (LAN), such as a Wi-Fi network, designed to communicate data between devices located in a local area. WANs and / or LANs typically include computer hardware such as copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and edge servers.

[0065] An end-user device (EUD) 103 is any computer system used and controlled by an end-user (e.g., a customer of the company operating computer 101) and can take any of the forms described above in relation to computer 101. EUD 103 typically receives useful and valuable data from the operation of computer 101. For example, in a hypothetical case where computer 101 is designed to provide recommendations to an end-user, these recommendations would typically be transmitted from computer 101's network module 115 to EUD 103 via WAN 102. In this way, EUD 103 can display or otherwise present the recommendations to the end-user. In some embodiments, EUD 103 may be a client device such as a thin client, heavy client, mainframe computer, desktop computer, and similar.

[0066] The remote server 104 is any computer system that provides at least some data and / or functionality to computer 101. The remote server 104 may be controlled and used by the same entity that operates computer 101. The remote server 104 represents a machine that collects and stores useful and valuable data for use by other computers, such as computer 101. For example, in a hypothetical case where computer 101 is designed and programmed to provide recommendations based on historical data, this historical data may be provided to computer 101 from the remote database 130 of the remote server 104.

[0067] The public cloud 105 is any computer system available for use by multiple entities, providing on-demand availability of computer system resources and / or other computing capabilities, particularly data storage (cloud storage) and computing power, without direct active management by the user. Cloud computing typically leverages resource sharing to achieve coherence and economies of scale. Direct and active management of the computing resources of the public cloud 105 is performed by the computer hardware and / or software of the cloud orchestration module 141. The computing resources provided by the public cloud 105 are typically implemented by virtual computing environments running on various computers that make up the host physical machine set 142, which is a universe of physical computers within and / or available in the public cloud 105. The virtual computing environment (VCE) typically takes the form of virtual machines from the virtual machine set 143 and / or containers from the container set 144. These VCEs may be stored as images and are understood to be transferable either as images or after VCE instantiation, among and between various physical machine hosts. The cloud orchestration module 141 manages the transfer and storage of images, deploys new VCE instantiations, and manages active instantiations of VCE deployments. The gateway 140 is a collection of computer software, hardware, and firmware that enables the public cloud 105 to communicate over the WAN 102.

[0068] Here, some further explanation of virtualized computing environments (VCEs) is provided. A VCE can be stored as an "image." A new active instance of a VCE can be instantiated from an image. Two well-known types of VCEs are virtual machines and containers. A container is a VCE that uses operating system-level virtualization. This refers to an operating system feature in which the kernel allows for the existence of multiple isolated user-space instances called containers. These isolated user-space instances typically behave like actual computers in terms of the programs running in them. Computer programs running on a normal operating system can utilize all the resources of that computer, including connected devices, files and folders, network shares, CPU power, and quantifiable hardware capabilities. However, programs running inside a container can only use the contents of the container and the devices allocated to that container; this feature is known as containerization.

[0069] The private cloud 106 is similar to the public cloud 105, except that its computing resources are available only for use by a single enterprise. While the private cloud 106 is illustrated as being in communication with the WAN 102, in other embodiments, the private cloud may be completely disconnected from the internet and accessible only through a local / private network. A hybrid cloud is a combination of multiple clouds of different types (e.g., private, community, or public cloud types), often implemented by different vendors. Each of the multiple clouds remains an independent entity, but the larger hybrid cloud architecture is coupled together by standardized or proprietary technologies that enable orchestration, management, and / or data / application portability between the multiple configuration clouds. In this embodiment, both the public cloud 105 and the private cloud 106 are part of a larger hybrid cloud.

[0070] Measurement Services: Cloud systems automatically control and optimize resource usage by leveraging measurement capabilities appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts) at a certain level of abstraction. Resource utilization can be monitored, controlled, reported, and billed, providing transparency to both service providers and consumers of the services used.

[0071] Referring to Figure 2, this figure shows a block diagram of an example computing environment according to an exemplary embodiment. In the exemplary embodiment, the computing environment includes the test case factoring module 200 shown in Figure 1.

[0072] In an exemplary embodiment, the test case factoring module 200 is configured to construct a graph data structure from test cases stored in the test case database 230. In one embodiment, the module 200 is configured to perform a process for test case refactoring based on the test case data stored in the test case database 230. In one embodiment, the process for factoring (and refactoring) test cases includes breaking down a set of multiple test cases into smaller test units and constructing a graph data structure to store these units as nodes in the graph. Furthermore, this process includes organizing existing test cases, creating a hierarchical structure based on specified criteria, subdividing test functions, merging duplicate modules, and creating shared test units. In an exemplary embodiment, the user device 220, the test case factoring module 200, the target system 210, and the test case database 230 may each communicate and interact with each other via an arbitrary preferred network 201 and perform the following exemplary operations accordingly.

[0073] In one embodiment, the process for test case factoring further includes optimizing the test case graph structure. In one embodiment, the optimization process for test case refactoring includes constructing a test case graph and assigning different weights to each test unit based on one or more algorithms. In some embodiments, upward iterative optimization is performed on all test units to create more efficient and rational minimum test units. Furthermore, different weight values ​​may be assigned to each minimum test unit based on one or more algorithms. In one embodiment, weighted automated testing may be performed based on user requirements and the weight values ​​of the test units. Automated assembly and testing of weight-based test cases may be specified according to user requirements and assigned weight values ​​to ensure comprehensive test coverage.

[0074] As will be discussed in more detail herein, weighted automated testing refers to a testing methodology in which test cases are prioritized and executed based on weights assigned to each test unit. These weights may be determined using specific algorithms and criteria to reflect the importance or complexity of the test unit. Weighted automated testing may include the automated assembly and execution of test cases based on the assigned weight values. By utilizing this methodology, tests can be executed more efficiently and / or focus can be placed on important or critical areas of the system, optimizing the use of test resources and maximizing efficiency while ensuring comprehensive test coverage.

[0075] In one embodiment, the process of creating the initial minimum test unit includes collecting user behavior data, analyzing relevant test scenarios, and individually aligning the test phases with user behavior in each test scenario. Furthermore, one embodiment includes constructing a mapping that defines the relationship between user behavior and test phases. In one embodiment, a complete test chain can be constructed by assembling atomic test units having different levels and functions during the test process. In one embodiment, assembling atomic test units into a test chain for automated testing includes combining the initial minimum test units into a comprehensive test chain that covers different levels and functions of the system. By creating such an interconnected structure of test units, the test process can address various aspects of the system's functionality and interactions, ensuring comprehensive test coverage across different scenarios and user behaviors.

[0076] In one embodiment, the optimization process may include assigning weight values ​​to atomic test units. In one embodiment, assigning weight values ​​to atomic test units serves the purpose of prioritizing and optimizing the test process. These weight values ​​are assigned based on specific criteria such as complexity, criticality, or importance of each atomic test unit. By assigning weight values, the test process can first focus on executing and verifying the most critical and high-priority test units, ensuring that critical functions are comprehensively tested. This prioritization contributes to efficient resource allocation, time management, and the effectiveness of the overall test. In addition, the weight values ​​help identify and address potential risks or vulnerabilities in the system by giving emphasis to testing in key areas that have a significant impact on the system's performance and reliability.

[0077] In one embodiment, the weights assigned to test units are updated based on consideration of shared test units and their impact on test coverage. For example, if a minimum test unit is part of a shared test unit, this implies that this particular test unit is more likely to be included in multiple test chains and tested during coverage testing across various scenarios. For example, in a scenario where a minimum test unit is associated with a shared test unit, the weight assigned to the test unit is adjusted by multiplying it by a corresponding coefficient based on the number of times this test unit has been shared. This adjustment takes into account the increased likelihood that the test unit will be executed multiple times due to its presence within a shared test unit, and ensures that its weight reflects its importance and frequency of testing across different test chains. By updating weights in this manner, the testing process can effectively prioritize shared test units and allocate resources based on their importance in achieving comprehensive test coverage.

[0078] In an exemplary embodiment, the target system 210 includes a software development environment. Furthermore, in one embodiment, the target system 210 includes a code repository corresponding to the software development environment. In one embodiment, the user can use a user device 220 to cause the test factoring module 200 to perform process mining techniques that monitor changes made to the code repository of the target system 210, detect user behavior and test cases performed in response to detected changes made to the code repository, and further create mappings that define the relationships between detected changes and executed test cases in the code repository. In one embodiment, the mappings may be further utilized to facilitate automated testing, as will be described in more detail herein.

[0079] Referring to Figure 3, this figure shows a block diagram of an example of a test case factoring module according to an exemplary embodiment. In one embodiment, the test case factoring module 300 comprises a software module having several other connected software modules. In one embodiment, the test case factoring module 300 comprises a monitoring module 302, an analysis module 304, a decomposition module 306, a mapping module 308, a graph module 310, an optimization module 314, a model trainer module 316, an API interface module 318, and an administrator interface module 320.

[0080] In an exemplary embodiment, the monitoring module 302 is configured to monitor changes made to a code repository corresponding to a specific software system, application, and / or component. Furthermore, in one embodiment, the monitoring module 302 is configured to monitor and collect data on user behavior and actions when changes made to the code repository are detected. In one embodiment, the monitoring module 302 continuously monitors modifications within the code repository and obtains user interactions and responses triggered by these changes.

[0081] In an exemplary embodiment, the analysis module 304 is configured to analyze data collected by the monitoring module 302 to determine user behaviors and software test cases that are executed in response to changes made to the code repository. In one embodiment, the analysis module 304 processes the monitoring data to identify user behaviors and software test cases that were executed after changes in the code repository. Through data analysis, the analysis module 304 identifies patterns, trends, and correlations between user actions and specific software test cases initiated as a result of code modifications.

[0082] In an exemplary embodiment, the disassembly module 306 is configured to divide a test case into smaller test units. In one embodiment, the disassembly process involves analyzing the structure and content of the test case to identify individual separable functions, behaviors, or scenarios. In one embodiment, the disassembly module 306 analyzes an existing test case, identifies individual functions or behaviors, and disassembles the test case into atomic test units. In one embodiment, the disassembly module 302 interacts with the assembly module 312 by providing the disassembled test units to the assembly module 312 for assembly into a consistent test case.

[0083] In an exemplary embodiment, the mapping module 308 is configured to build a mapping between software tests and changes made to the code repository, which defines a particular type of change made to the code repository along with a particular type of software test that is executed to evaluate the functionality of an application or component after the corresponding code changes have been implemented. By defining this mapping, the module outlines a particular type of code change and the corresponding tests required to verify these modifications. Thus, the monitoring module 302 collects data on changes to the code repository and user behavior and provides input to the analysis module 304. The analysis module 304 processes this data to determine user behavior and associated test cases, which are then used by the mapping module 308 to establish a mapping between code changes and software tests.

[0084] In the exemplary embodiment, the graph module 310 is responsible for structuring test cases and test units within a graph data structure. It stores test units as nodes in the graph, establishes relationships between different test units, and facilitates visualization of the test case hierarchy. The graph module 310 interacts with the assembly module 304 to receive assembled test cases for structuring within the graph, and interacts with the optimization module 308 to optimize the graph structure based on assigned weights.

[0085] In an exemplary embodiment, the assembly module 312 receives atomic test units generated by the disassembly module 312 and assembles the atomic test units into meaningful test cases. In one embodiment, the assembly module 312 combines the individual test units in a logical order to create a comprehensive test scenario that covers a specific function or user behavior. In one embodiment, the assembly module 312 interacts with the graph module 306 to structure the assembled test cases within a graph data structure.

[0086] In an exemplary embodiment, the optimization module 314 is configured to optimize the test case graph data structure. In one embodiment, the optimization module 308 is configured to optimize the test case graph data structure by assigning weights to nodes based on specific algorithms and criteria. In some embodiments, the optimization module 314 iteratively refines the weights of test units to prioritize critical features and / or improve test coverage. The optimization module 314 interacts with the graph module 306 to access structured graph data, adjust node weights, and optimize the entire graph structure for efficient testing. In some embodiments, the decomposition module 306, the assembly module 312, the graph module 310, and the optimization module 314 are configured to work together within the test case factoring module 300 to decompose, assemble, structure, and optimize test cases, ensuring comprehensive test coverage, an efficient testing process, and effective management of test case complexity.

[0087] In an exemplary embodiment, the model trainer module 316 is configured to perform automatic iteration and updating of the entire model according to a specified algorithm within the test case factoring system. This module ensures that the test structure remains fresh and stable in real time as new test cases are added to the system. In one embodiment, the model trainer module 316 automatically iterates over an existing model using a specified algorithm, incorporating any new test cases added to the system. Through iteration through the model, the trainer module 316 updates the structure to accommodate new test cases, thereby ensuring that the test framework is kept up-to-date and reflects current test requirements. Furthermore, throughout this iteration process, the model trainer module 316 maintains the stability and integrity of the test structure by adjusting the model to incorporate new test cases while preserving existing relationships and hierarchies within the system.

[0088] In an exemplary embodiment, the administrator interface module 310 allows a user with sufficient administrative privileges to adjust any or all of the settings and configurations within the test case factoring system. Some examples of the functions provided by the administrator interface module 310 may include, but are not limited to, the ability to customize the system according to specific requirements, the ability to manage user access and permissions, the ability to configure system behavior, the ability to integrate with external tools, the ability to ensure security measures, and the ability to optimize the test process for efficient and effective software test operation. In one embodiment, the administrator interface 320 allows an administrator user to adjust the weighting scheme or weights of nodes within the test case factoring system through a variety of customizable actions. Thus, an authorized user can configure the weighting scheme by defining criteria and algorithms used to assign weights to nodes, and adjust the scheme to suit specific test objectives. Within the administrator interface 320, the administrator can directly adjust the weights of individual nodes in the graph structure, increasing or decreasing weights based on the importance, criticality, or coverage importance of the node. This customization allows users to align the weighting scheme with the organization's own test priorities and strategies. The module enables real-time updates of node weights, ensuring that the weighting scheme remains up-to-date and reflects evolving test requirements or the addition of new test cases. Furthermore, authorized users can verify adjustments made to the weighting scheme through the administrator interface 320, confirming that the assigned weights align with the intended test objectives and goals. By providing this functionality, the administrator interface module 320 gives administrators the flexibility, control, and precision necessary to optimize test coverage, prioritize critical features, and improve the efficiency and effectiveness of the test framework.

[0089] In the exemplary embodiment, the API interface module 318 is configured to facilitate communication and interaction between the test case factoring system and external software applications or systems through an Application Programming Interface (API). This module acts as a bridge that enables the test case factoring system to communicate with external software components, tools, or services involved in the automated test process. By leveraging the API, the API interface module 314 enables the test case factoring system to retrieve test data, execute test cases, receive test results, and perform other test-related operations with external systems. In particular, the module enables the system to retrieve relevant test data from external sources, trigger the execution of automated test cases on an external test platform, acquire and process test results, integrate with third-party test tools, and automate the test process through seamless API interaction. Thus, the API module 314 acts as a communication interface connecting the test case factoring system and external software entities.

[0090] Referring to Figure 4, this figure shows a block diagram of an example of a system architecture according to an exemplary embodiment. In one embodiment, the system 400 includes the test case factoring module 200 in Figures 1 and 2 and / or the test case factoring module 300 in Figure 3.

[0091] In an exemplary embodiment, the test case library 406 stores data present in existing test cases. Furthermore, if the test case library receives one or more new functions 402 and / or new cases 404, the test case 406 is broken down into minimum test units 410. The resulting minimum test units 410 are then analyzed to construct various test case groups 412. In one embodiment, the system 400 is involved in the process of receiving the original test functions and test cases stored in the test case library 406 and breaking them down into minimum test units. These minimum test units are then assembled according to their respective functions and organized into test case groups 412.

[0092] In one embodiment, the system 400 is initiated by receiving the original test functions and test cases from the test case library 406. The decomposition process involves dividing the test cases into the smallest test units that represent the individual functions or behaviors under test. This decomposition stage aims to reduce the test cases to their smallest indivisible parts, which can then be reassembled during the testing process.

[0093] Therefore, once a test case is broken down into its smallest test units, System 400 assembles these units into test cases grouped according to their respective functions. This assembly process involves combining the smallest test units in a logical order to create comprehensive test cases that cover specific functions or behaviors within the software system. By grouping the smallest test units based on their functions, the system ensures that test cases are organized and structured according to their intended test objectives. System 400 facilitates the breakdown of test cases into smallest test units and then the assembly of these units into test cases grouped according to their respective functions.

[0094] In one embodiment, after test cases are assembled in block 416 based on their respective functions, these test cases may be further grouped according to different test scenarios in order to effectively organize and classify the test process. Grouping test cases according to different test scenarios enables targeted testing of specific user interactions, functions, or system behaviors under different conditions or use cases. In one embodiment, the scenario grouping process includes identifying different test scenarios, so that each test scenario represents a specific user interaction, system behavior, or functional requirement that needs to be tested. These scenarios are identified based on the software system specifications, user behavior, or test objectives. Furthermore, assembled test cases are mapped to corresponding test scenarios based on the functions or behaviors they cover. This mapping ensures that each test case is associated with the relevant test scenario it addresses. Additionally, test cases may be grouped together based on the test scenario to which they belong. Test cases verifying similar functions or behaviors within a particular scenario may be grouped together to streamline the test process.

[0095] In one embodiment, in block 414, function coverage weights are applied to test cases to prioritize and evaluate the coverage of different functions within the software system. The function coverage weights quantify the presence and importance of specific functions in the test cases, enabling a more targeted approach to testing based on the frequency and importance of each function. For example, in a scenario where function A is present in 100% of the test cases, function B is present in 60% of the cases, function C is present in 40% of the cases, and function D is present in 10% of the cases, the function coverage weights may be calculated as follows.

[0096] Since functional part A is present in 100% of the test cases, it may be assigned a higher functional coverage weight to reflect its importance and broad coverage across test scenarios. Since functional part B is present in 60% of the cases, it may receive a moderate functional coverage weight that reflects its importance but does not have as broad coverage as functional part A. Since functional part C is present in 40% of the cases, it may have a lower functional coverage weight compared to functional parts A and B, indicating less coverage and potentially lower priority in testing. Since functional part D is present in 10% of the cases, it may have the lowest functional coverage weight, indicating limited coverage and potentially lower criticality in the testing process. By applying functional coverage weights to test cases in this manner, testing can focus on features with higher weights, optimizing test resources based on the importance and frequency of features within the software system, prioritizing test activities, and ensuring comprehensive test coverage of critical features.

[0097] In one embodiment, test scenarios are stored in a test scenario library 408, refactored, and stored in a test case library 406, thereby streamlining the testing process and enhancing the organization of test cases based on specific scenarios. Once test scenarios are stored in the test scenario library 408, they undergo a refactoring process to be converted into executable test cases. This refactoring involves breaking down high-level scenarios into detailed stages, actions, or conditions that can be directly executed as test cases. The refactored test cases are then stored in the test case library 406. The refactored test cases in the test case library 406 are organized and structured based on the specific scenarios they address. Each test case is associated with a specific test scenario, ensuring that the test cases are consistent with the intended functionality or behavior of the system under test. By refactoring and storing test scenarios as test cases in the test case library 406, the testing process becomes more structured, efficient, and focused on verifying specific functionality or behavior within the software system.

[0098] In one embodiment, the test case library 406 is restructured according to a graph data structure that represents different test cases to be executed by assembling test case units through graph scanning based on different scenarios. This restructuring process involves organizing and structuring test cases within the graph data structure to facilitate efficient execution and management of test cases across various test scenarios. Initially, the test cases stored in the test case library 406 are mapped to corresponding test scenarios based on the functions, behaviors, or user interactions they cover. Each test case unit represents a specific set of test cases or test phases that verify a particular aspect of the software system.

[0099] In one embodiment, the graph data structure is then used to represent the relationships between different test cases, test case units, and test scenarios. Nodes in the graph correspond to individual test case units, while edges represent connections or dependencies between these units based on the test scenarios they address. During graph traversal, test case units are assembled and executed based on specific test scenarios defined in the graph structure. By traversing the graph, test case units are ordered and executed in a logical order consistent with the intended function or behavior of the object under test within each scenario.

[0100] Therefore, the graph data structure enables the systematic execution of test cases by following paths defined by a graph traversal algorithm. This approach ensures that test cases are executed in a structured and organized manner, covering the different scenarios and functions represented in the graph structure. By restructuring the test case library 406 according to the graph data structure and executing test cases by assembling test case units through graph traversal based on different scenarios, the test process becomes more systematic, organized, and effective in verifying software systems across various test scenarios and functions.

[0101] Referring to Figure 5, this figure shows a graph diagram of an example process for optimizing test case factoring according to an exemplary embodiment. In the exemplary embodiment, the graph data structure has a tree graph 500 including a first level 502, a second level 504, a third level 506, and a fourth level 508.

[0102] In one embodiment, test case units are stored on a tree graph data structure, organizing and representing the relationships between different test units in a hierarchical manner. In this structure, the root, leaf, node, and edge play distinct roles in defining the hierarchy and connections between test case units.

[0103] In graph data structures, the root represents the starting point or top-level node of the hierarchy. These roots function as the primary nodes from which the tree branches, and they represent the first test case unit or function from which the test process begins. In tree graph data structures, the leaf represents the end point or bottom-level node of the hierarchy. These leaves represent the final test case unit or function from which no child nodes branch. A leaf represents the smallest, indivisible test case unit that directly verifies a specific function or behavior within a software system.

[0104] The remaining nodes in the tree graph data structure represent intermediate levels or layers between the root and leaves. These nodes correspond to test case units organized hierarchically based on their relationships and dependencies. Each node may have child nodes branching from it, representing the decomposition of test case units into smaller, finer-grained units. The edges between nodes in the tree graph data structure represent connections or relationships between test case units. These edges define parent-child relationships between nodes and show how test case units are structured and organized within the hierarchy. The edges establish the flow of information, dependencies, and execution order between test case units as they are traversed and executed during the testing process.

[0105] In the exemplary embodiments, a directed acyclic graph (DAG) is constructed to store and organize test cases in a structured and efficient manner within a test framework. A DAG is a graph data structure consisting of nodes connected by directed edges, which have a specific direction and do not form any cycles. In one embodiment, each node in the DAG represents a specific test case unit or set of test phases that verify a particular function, behavior, or scenario within a software system. In some embodiments, nodes may be labeled with identifiers or descriptions to indicate the content or purpose of the test case unit.

[0106] In one embodiment, directed edges in a DAG represent relationships or dependencies between different test case units. As shown in the illustrative embodiment, an edge from a node at the first level 502 to a node at the second level 504 indicates that there is a dependency or sequence between the test case units represented by these nodes. For example, if test case unit B depends on the successful execution of test case unit A, then a directed edge exists from A to B.

[0107] The DAG structure allows for the representation of hierarchical relationships and dependencies between test case units. Test case units can be organized hierarchically, with parent nodes representing higher-level functions and child nodes representing finer-grained test case units that verify specific aspects of the system. The acyclic nature of DAGs ensures that there are no cycles or loops in the graph structure. This characteristic is useful in the context of test cases in preventing redundant or infinite loops in the test process and ensuring that test cases are executed in a structured, non-repetitive manner. Test cases can be organized within a DAG based on different test scenarios or functions. Test units of nodes can be grouped together based on the specific scenarios they address, enabling targeted testing of different user interactions, system behaviors, or functional requirements. The DAG structure facilitates the traversal and execution of test cases in a logical order based on directed edges. Test cases can be executed along paths defined by edges, ensuring that dependencies between test case units are maintained and the test process proceeds in an organized manner.

[0108] In one embodiment, different path scans representing sequences of actions assembled from test units can be triggered based on different test scenarios defined by scenario-based tests. This technique allows for the execution of specific sequences of actions tailored to different scenarios within the test framework. In one embodiment, each test scenario is defined by a set of multiple tests or test cases that need to be executed to verify a particular function, behavior, or user interaction within a software system. These scenarios outline specific conditions, inputs, and expected outcomes for the test process. The sequence of actions assembled from test units represents the steps or actions that need to be executed to verify a particular scenario. Each path scan corresponds to a sequence of test units interconnected based on dependencies and relationships defined within the test framework.

[0109] Furthermore, based on defined test scenarios, different path scans can be triggered to execute the corresponding sequence of actions. When a specific scenario is selected for testing, the associated path scan is activated, executing the sequence of test units that verify that scenario. Thus, triggering path scans based on test scenarios enables the dynamic execution of test cases tailored to different test conditions. By selecting a specific scenario, the test framework can automatically initiate the corresponding path scan to execute the necessary tests in a defined order. Executing path scans based on test scenarios enables scenario-based verification of the software system.

[0110] In one embodiment, a weighting function can be applied to the nodes of graph 500, thereby calculating the weight of each node based on the number of its connections to parent nodes, child nodes, or both. This weighting method facilitates prioritizing important nodes in the graph structure based on their relationships and / or dependencies. For example, for a node with parent-child connections, the node's weight may be calculated based on the number of child nodes to which it is connected. Nodes with multiple child nodes may be assigned a higher weight to indicate their importance when branching into multiple functions or scenarios within the test framework.

[0111] As another example, a node's weight can also be calculated based on the number of parent nodes to which it is connected. Nodes with multiple parent nodes may be assigned a higher weight to indicate their role in aggregating functions or behaviors from branches of different graph structures. As yet another example, in the case where a node has both parent and child connections, the weight calculation may take into account the total number of connections to both parent and child nodes. This comprehensive approach provides a holistic view of the importance of nodes in terms of branching into different functions and aggregating dependencies from multiple sources.

[0112] A weighting function can assign weight values ​​to nodes based on calculated connections, with nodes having more connections receiving higher weights. This weighting plays a central role in the graph structure, contributing to the prioritization of nodes with multiple dependencies and / or critical to the overall test process. Therefore, nodes with higher weights may represent important functions, key decision points, and / or core components within the test framework. By applying a weighting function based on connections to parent and child nodes, the graph structure can be optimized to focus on important nodes, streamline dependencies, and improve the efficiency and effectiveness of the test process. By applying a weighting function to DAG nodes based on the number of connections to parent nodes, child nodes, or both, the test framework can prioritize and assess the importance of nodes within the graph structure, enabling targeted testing, optimized traversal, and efficient management of dependencies in the test process.

[0113] In one embodiment, the construction of graph 500 enables the execution of a process for weighted automated testing, as described in more detail herein. In one embodiment, weighted automated testing using graph scanning involves assigning weights to nodes in a graph data structure representing test cases and test units. These weights may be calculated based on specific criteria such as complexity, criticality, or the frequency of connections of each node to its parent or child nodes. The weight values ​​assigned to nodes determine their importance in the testing process and guide the scanning algorithm to prioritize nodes with higher weights during test case execution.

[0114] In one embodiment, during graph scanning, the algorithm follows a path that maximizes the cumulative weight of the scanned nodes. By incorporating weights into the scanning process, the test framework can optimize the test sequence, focus on high-priority test cases, and efficiently verify key functions within the software system. Weighted automated testing techniques improve the effectiveness and efficiency of the test process by dynamically adjusting the scanning path based on assigned weights, ensuring comprehensive coverage of critical functions and targeted testing of key scenarios.

[0115] Referring to Figure 6, this figure shows a flowchart of an example of the test case factoring optimization process according to an exemplary embodiment. In one embodiment, the test case factoring optimization module 200 of Figures 1 and 2, the test case factoring optimization module 300 of Figure 3, and / or the system 400 of Figure 4 perform some or all aspects of the process 600.

[0116] In one embodiment, in step 602, the process receives a set of multiple test cases from a test case database. In one embodiment, in step 604, the process decomposes each test case from the set of multiple test cases into multiple test case units. In one embodiment, in step 606, the process constructs a graph data structure based on the case units corresponding to the test cases in the set of multiple test cases. In one embodiment, in step 608, the process detects a first test case scenario. In one embodiment, in step 610, the process traverses a portion of the graph data structure's path to execute a portion of the set of multiple test cases based on the first test case scenario. This traverse involves following a specific path within the graph structure to execute the corresponding test case units that verify the functionality or behavior defined by the test case scenario. By following these steps, the process systematically decomposes test cases, constructs a graph data structure, detects test case scenarios, executes test cases based on the identified scenarios, and enables efficient and targeted testing of the software system.

[0117] In this specification, test case scenarios are intended to be defined according to the type of software application or component under test in order to ensure comprehensive coverage and effective verification of the software system. In some embodiments, the definition of a test case scenario determines the scope and / or purpose of the test process. A test case scenario may be defined by identifying a specific function, feature, or user interaction within the software application or component that needs to be tested. Each function may represent a distinct aspect of the software system that needs to be verified. In user-centric applications, test case scenarios may be defined based on different use cases and user interactions. Illustrative test case scenarios may include, but are not limited to, a login process, a data entry form, a navigation flow, and other user actions that need to be tested.

[0118] Furthermore, test case scenarios can also be defined based on the expected behavior and response of a software system under different conditions. Scenarios may cover error handling, boundary conditions, performance benchmarks, and other system behaviors requiring verification. In cases where a software component or system interacts with an external service or component, test case scenarios can be defined based on integration points. Illustrative test case scenarios may include, but are not limited to, data exchange, API interactions, and integration tests.

[0119] Furthermore, regression test case scenarios can be defined based on changes or updates to the software application or component. The scenarios may encompass the impact of the modifications on existing functionality and ensure that the new changes do not introduce regressions or unexpected behavior. Test case scenarios may also focus on edge cases and exception handling to verify the robustness and reliability of the software application or component. Illustrative test case scenarios may include, but are not limited to, stress tests, boundary tests, and error scenarios for evaluating the resilience of the system under adverse conditions. Thus, by defining test case scenarios based on the type of software application or component under test, embodiments of the automation process described herein can be tailored to address specific functions, user interactions, system behavior, and integration points, ensuring comprehensive verification and effective test coverage of the software system.

[0120] The following definitions and abbreviations shall be used for interpretation of the claims and specification. Where used herein, the terms “comprises,” “comprising,” “includes,” “including,” “has,” “having,” “contains,” or “containing,” or any other variation thereof, are intended to cover non-exclusive inclusion. For example, a composition, mixture, process, method, article, or apparatus containing a list of elements is not necessarily limited to those elements alone, and may include other elements not expressly enumerated or specific to such composition, mixture, process, method, article, or apparatus.

[0121] Additionally, as used herein, the term “exemplary” means “serving as an example, case, or illustration.” No embodiment or design described herein as “exemplary” is necessarily construed to be preferable or advantageous to other embodiments or designs. The terms “at least one” and “one or more” are understood to include any integer greater than or equal to 1, i.e., 1, 2, 3, 4, etc. The term “multiple” is understood to include any integer greater than or equal to 2, i.e., 2, 3, 4, 5, etc. The term “connection” may include indirect “connection” and direct “connection.”

[0122] References in this specification to “one embodiment,” “one example,” “exemplary embodiment,” etc., indicate that the embodiments described may include certain features, structures, or characteristics, but not all embodiments may include or may not include such features, structures, or characteristics. Furthermore, such language does not necessarily refer to the same embodiment. Moreover, if certain features, structures, or characteristics are described in relation to one embodiment, it is considered within the knowledge of those skilled in the art that such features, structures, or characteristics will be affected in relation to other embodiments, whether or not they are explicitly described.

[0123] The terms “approximately,” “substantially,” and “roughly,” and their variations, are intended to include the degree of error associated with the measurement of a particular quantity based on equipment available at the time of filing of this application. For example, “approximately” may include a range of ±8%, 5%, or 2% of a given value.

[0124] The descriptions of various embodiments of the present invention are presented for illustrative purposes only and are not intended to be exhaustive or limit the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein has been selected to best describe the principles, practical applications, or technical improvements to the technologies available on the market of the embodiments, or to enable other those skilled in the art to understand the embodiments described herein.

[0125] The descriptions of various embodiments of the present invention are presented for illustrative purposes only and are not intended to be exhaustive or limit the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein has been selected to best describe the principles, practical applications, or technical improvements to the technologies available on the market of the embodiments, or to enable other those skilled in the art to understand the embodiments described herein.

[0126] Accordingly, exemplary embodiments provide computer implementations, systems, or devices and computer program products for managing participation in online communities and other related features, functions, or operations. Where one embodiment or part thereof is described in relation to a certain type of device, the computer implementation, system, or device, computer program product, or part thereof, is adapted or configured for use with a preferred and equivalent embodiment of that type of device.

[0127] When an embodiment is described as being implemented in an application, the provision of that application in a Software as a Service (SaaS) model is intended to be within the scope of the exemplary embodiment. In the SaaS model, the capabilities of an application implementing an embodiment are provided to the user by running the application on a cloud infrastructure. The user can access the application using a variety of client devices through a thin client interface such as a web browser (e.g., web-based email) or other lightweight client applications. The user does not manage or control the underlying cloud infrastructure, including the network, servers, operating system, or storage of the cloud infrastructure. In some cases, the user does not need to manage or control the capabilities of the SaaS application. In some other cases, the SaaS implementation of an application may allow possible exceptions to limited user-specific application configuration settings.

[0128] Embodiments of the present invention may also be provided as part of a service contract with a client company, non-profit organization, government agency, internal organizational structure, or similar entity. Aspects of these embodiments may include configuring and running a computer system and deploying software, hardware, and web services that implement some or all of the methods described herein. Aspects of these embodiments may also include analyzing client behavior, generating recommendations in response to the analysis, building a system that implements some of the recommendations, integrating the system into existing processes and infrastructure, measuring system usage, allocating costs to system users, and billing for system usage. While each of the above embodiments of the present invention has been described by listing its individual advantages, the present invention is not limited to any particular combination thereof. Rather, such embodiments can also be combined in any way and in any number in accordance with the intended development of the present invention without losing their beneficial effects.

Claims

1. The stage of breaking down each test case from a set of multiple test cases into sets of individual test cases; A step of constructing a graph data structure based on the set of multiple test case units, where each path in the graph data structure corresponds to one test case from the set of multiple test cases; The first step involves detecting a first test case scenario, where the first test case scenario corresponds to a first portion of the set of multiple test cases; The detection of the first test case scenario involves scanning a first portion of the multiple paths of the graph data structure, wherein the scanning of the first portion of the multiple paths causes the assembly of the first portion of the test cases; and The step of executing each test case assembled as a result of scanning each path of the first portion of the plurality of paths of the graph data structure. A computer implementation method comprising the following:

2. The computer implementation method according to claim 1, further comprising the step of assigning weight values ​​to each node of the graph data structure based on the number of connections to other nodes.

3. The computer implementation method according to claim 2, wherein the number of connections to the other nodes corresponds to the number of connections to the child nodes.

4. The computer implementation method according to claim 2, wherein the number of connections to other nodes corresponds to the number of connections to the parent node.

5. The computer implementation method according to claim 2, wherein the number of connections to other nodes corresponds to the combination of child nodes and parent nodes connected to the node.

6. The computer implementation method according to claim 2, wherein the step of scanning each path of the first portion of the plurality of paths of the graph data structure is performed in an order at least partially based on the cumulative weight value corresponding to the execution of each path.

7. To the processor: A procedure for breaking down each test case in a set of multiple test cases into sets of individual test cases; A procedure for constructing a graph data structure based on the set of multiple test cases, wherein each path in the graph data structure corresponds to one test case from the set of multiple test cases; A procedure for detecting a first test case scenario, wherein the first test case scenario corresponds to a first portion of the set of multiple test cases; A step of scanning a first portion of the multiple paths of the graph data structure when the first test case scenario is detected, wherein the step of scanning the paths of the first portion of the multiple paths causes the assembly of the test cases of the first portion of the multiple test cases; and A procedure for executing each test case assembled as a result of scanning each path of the first portion of the plurality of paths of the graph data structure. A computer program designed to execute something.

8. The computer program according to claim 7, wherein the computer program is stored in a computer-readable storage device within a data processing system, and the computer program is transferred from a remote data processing system via a network.

9. The computer program is stored in a computer-readable storage device within the server data processing system, and the computer program is downloaded to the remote data processing system via a network in response to a request for use in a computer-readable storage device associated with the remote data processing system. The computer program is configured on the processor, A procedure for measuring the usage of the computer program associated with the request; and Procedure for generating an invoice based on the measured usage amount. The computer program according to claim 7, which further executes the following.

10. The aforementioned processor, The computer program according to claim 7, further comprising the procedure of assigning weight values ​​to each node of the graph data structure based on the number of connections to other nodes in the graph data structure.

11. The computer program according to claim 10, wherein the number of connections to other nodes in the graph data structure includes the number of connections to child nodes.

12. The computer program according to claim 10, wherein the number of connections to other nodes in the graph data structure includes the number of connections to the parent node.

13. The computer program according to claim 10, wherein the number of connections to other nodes in the graph data structure includes combinations of the number of connections to child nodes and combinations to parent nodes.

14. The computer program according to claim 10, wherein the procedure for scanning each path of the first portion of the plurality of paths of the graph data structure is performed in an order at least partially based on the cumulative weight value corresponding to the execution of each path.

15. A processor and one or more computer-readable storage media, and program instructions collectively stored on the one or more computer-readable storage media. The program instructions are: A procedure for breaking down each test case in a set of multiple test cases into sets of individual test cases; A procedure for constructing a graph data structure based on the set of multiple test cases, wherein each path in the graph data structure corresponds to one test case from the set of multiple test cases; A procedure for detecting a first test case scenario, wherein the first test case scenario corresponds to a first portion of the set of multiple test cases; A step of scanning a first portion of the multiple paths of the graph data structure when the first test case scenario is detected, wherein the step of scanning the paths of the first portion of the multiple paths causes the assembly of the test cases of the first portion of the multiple test cases; and A procedure for executing each test case assembled as a result of scanning each path of the first portion of the plurality of paths of the graph data structure. A computer system that is executable by a processor to cause the processor to perform an operation having the following characteristics.

16. The computer system according to claim 15, further comprising a procedure for assigning weight values ​​to each node of the graph data structure based on the number of connections to other nodes in the graph data structure.

17. The computer system according to claim 16, wherein the number of connections to other nodes in the graph data structure includes the number of connections to child nodes.

18. The computer system according to claim 16, wherein the number of connections to other nodes in the graph data structure includes the number of connections to the parent node.

19. The computer system according to claim 16, wherein the number of connections to other nodes in the graph data structure includes combinations of the number of connections to child nodes and combinations to parent nodes.

20. The computer system according to claim 16, wherein the procedure for scanning each path of the first portion of the plurality of paths of the graph data structure is performed in an order at least partially based on the cumulative weight value corresponding to the execution of each path.

Images