Claims:1. A processor-implemented method for generation and execution of test cases associated with an application, the method comprising:
receiving, via one or more hardware processors, selection of at least one workflow of a plurality of workflows associated with the application and a depth of said workflow;
receiving, via the one or more hardware processors, one or more filters criteria;
generating automatically, via the one or more hardware processors, a test case corresponding to the at least one workflow and the depth of said workflow based on the one or more filter criteria, wherein generating automatically the test case comprises:
accessing a test case repository comprising optimized test paths for execution of a plurality of test cases associated with the application, the optimized test paths satisfying a predefined criteria for selection of the optimized test paths for test case generation; and executing, via the one or more hardware processors, the test case by using a prestored test case data.

2. The method as claimed in claim 1, further comprising generating the optimized test paths, wherein generating the optimized test paths comprises:
generating a process map from the application, the application comprising a plurality of workflows associated with distinct depths;
creating a graph from the process map, the graph comprising a plurality of decision nodes;
identifying one or more document object model to document object model (DOM-to-DOM) (D2D) graphs by traversing through the graph;
identifying a plurality of sub-graphs by traversing through the one or more D2D graphs based on the predefined criteria, a sub-graph of the plurality of sub-graphs comprising one or more subgraph-to-subgraph paths between node pairs of the plurality of decision nodes, the predefined criteria comprising detection of a sub-graph satisfying condition of minimal count path equal to maximum count path, the minimal count path and the maximum count path indicative of count of decision nodes encountered while traversing the sub-graph; and
merging the set of sub-graphs to generate the optimized test path for execution of the test case.

3. The method as claimed in claim 2, further comprising storing the set of sub-graphs.

4. The method as claimed in claim 1, wherein the one or more filters criteria comprises business rules, test data, decision boxes and the node values from said decision box.

5. A system for generation and execution of test cases associated with an application, the system comprising:
one or more memories; and
one or more hardware processors, the one or more memories coupled to the one or more hardware processors, wherein the one or more hardware processors are capable of executing programmed instructions stored in the one or more memories to:
receive selection of at least one workflow of a plurality of workflows associated with the application and a depth of said workflow;
receive one or more filters criteria;
generate automatically a test case corresponding to the at least one workflow and the depth of said workflow based on the one or more filter criteria, wherein to generate automatically the test case, the one or more hardware processors executes programmed instructions to:
access a test case repository comprising optimized test paths for execution of a plurality of test cases associated with the application, the optimized test paths satisfying a predefined criteria for selection of the optimized test paths for test case generation; and
execute the test case by using a prestored test case data.

6. The system as claimed in claim 5, wherein the one or more hardware processors are further configured by the instructions to generate the optimized test paths, and wherein to generate the optimized test paths, the one or more hardware processors are further configured by the instructions to:
generate a process map from the application, the application comprising a plurality of workflows associated with distinct depths;
create a graph from the process map, the graph comprising a plurality of decision nodes;
identify one or more document object model to document object model (DOM-to-DOM) (D2D) graphs by traversing through the graph;
identify a plurality of sub-graphs by traversing through the one or more D2D graphs based on the predefined criteria, a sub-graph of the plurality of sub-graphs comprising one or more subgraph-to-subgraph paths between node pairs of the plurality of decision nodes, the predefined criteria comprising detection of a sub-graph satisfying condition of minimal count path equal to maximum count path, the minimal count path and the maximum count path indicative of count of decision nodes encountered while traversing the sub-graph; and
merge the set of sub-graphs to generate the optimized test path for execution of the test case.

7. The system as claimed in claim 6, wherein the one or more hardware processors are further configured by the instructions to store the plurality of sub-graphs.

8. The system as claimed in claim 5, wherein the one or more filters criteria comprises business rules, test data, decision boxes and the node values from said decision box.
, Description:FORM 2

THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENT RULES, 2003

COMPLETE SPECIFICATION
(See Section 10 and Rule 13)

Title of invention:
SYSTEM AND METHOD FOR AUTOMATED TEST CASE
GENERATION AND EXECUTION

Applicant:
Tata Consultancy Services Limited
A company Incorporated in India under the Companies Act, 1956
Having address:
Nirmal Building, 9th floor,
Nariman point, Mumbai 400021,
Maharashtra, India

The following specification particularly describes the embodiments and the manner in which it is to be performed.

TECHNICAL FIELD
[0001] The disclosure herein generally relates to testing of software applications, and more particularly, to method and system for automated test case generation and execution.

BACKGROUND
[0002] Software testing lifecycle (STLC) is a process including specific steps pertaining to testing of software applications. Particularly, STLC defines the stages in the process of testing. The steps have to be executed in a sequential manner to ensure that quality goals for software application are met.
[0003] Conventionally various testing systems or tools are available for accomplishing STLC. Said tools conduct testing of software applications in two stages, namely, a design stage and an execution stage. The design stage primarily focuses on requirements review, test planning and test designing. For example, in design stage, software requirements are reviewed and tests are designed based on said requirements. In execution stage, a test environment is setup with a goal of replicating end-users’ environment, and the test cases are executed in said environment.
[0004] The inventors here have recognized several technical problems with such conventional testing systems, as explained below. Software testing using conventional testing systems involves substantial manual effort for identifying and creating test cases, thereby leading to reduced test coverage, lower productivity, high manual errors and higher human dependency. As the complexity and size of software application increases, generation and maintenance of the test case become even more challenging.

SUMMARY
[0005] Embodiments of the present disclosure present technological improvements as solutions to one or more of the above-mentioned technical problems recognized by the inventors in conventional systems. For example, in one embodiment, a system for generation and execution of test cases associated with an application is provided. The system includes one or more memories and one or more hardware processors. The one or more memories coupled to the one or more hardware processors. The one or more hardware processors are capable of executing programmed instructions stored in the one or more memories to receive selection of at least one workflow of a plurality of workflows associated with the application, and a depth of said workflow. Further, the one or more hardware processors are capable of executing programmed instructions to receive one or more filters criteria. Further, the one or more hardware processors are capable of executing programmed instructions to generate automatically a test case corresponding to the at least one workflow and the depth of said workflow based on the one or more filter criteria. To generate the test case automatically, the one or more hardware processors executes programmed instructions to access a test case repository comprising optimized test paths for execution of a plurality of test cases associated with the application. The optimized test paths satisfying a predefined criteria for selection of the optimized test paths for test case generation. Moreover, the one or more hardware processors are capable of executing programmed instructions to execute the test case by using a prestored test case data.
[0006] In another aspect, a processor-implemented method for generation and execution of test cases associated with an application is provided. The method includes receiving, via one or more hardware processors, selection of at least one workflow of a plurality of workflows associated with the application and a depth of said workflow. Further, the method includes receiving, via the one or more hardware processors, one or more filters criteria. Furthermore, the method includes generating automatically, via the one or more hardware processors, a test case corresponding to the at least one workflow and the depth of said workflow based on the one or more filters criteria, Generating automatically the test case includes accessing a test case repository comprising optimized test paths for execution of a plurality of test cases associated with the application. The optimized test paths satisfy a predefined criteria for selection of the optimized test paths for test case generation. Also, the method includes executing, via the one or more hardware processors, the test case by using a prestored test case data.
[0007] In yet another aspect, a non-transitory computer readable medium having embodied thereon a computer program for executing a method for implemented method for generation and execution of test cases associated with an application is provided. The method includes receiving selection of at least one workflow of a plurality of workflows associated with the application, and a depth of said workflow. Further, the method includes receiving one or more filters criteria. Furthermore, the method includes generating automatically a test case corresponding to the at least one workflow and the depth of said workflow based on the one or more filter criteria. Generating automatically the test case includes accessing a test case repository comprising optimized test paths for execution of a plurality of test cases associated with the application. The optimized test paths satisfy predefined criteria for selection of the optimized test paths for test case generation. Also, the method includes executing the test case by using a prestored test case data.
[0008] It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed.

BRIEF DESCRIPTION OF THE DRAWINGS
[0009] The accompanying drawings, which are incorporated in and constitute a part of this disclosure, illustrate exemplary embodiments and, together with the description, serve to explain the disclosed principles:
[0010] FIG. 1 illustrates a network implementation of a system for automated test case generation and execution, in accordance with an example embodiment.
[0011] FIG. 2 illustrates a block diagram of a system for automatic test case generation and execution, in accordance with an example embodiment.
[0012] FIGS. 3A-3C illustrates an example graph of a business process and a process sequence for identifying optimal path from the graph for test case generation and execution are described in accordance with an example embodiment.
[0013] FIG. 4 is a flow diagram illustrating a method for automated test case generation and execution in accordance with some embodiments of the present disclosure.
[0014] FIGS. 5A and 5B represents User interface (UIs) illustrating an example of automated test case generation and execution, in accordance with an example embodiment.

DETAILED DESCRIPTION OF EMBODIMENTS
[0015] Exemplary embodiments are described with reference to the accompanying drawings. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. Wherever convenient, the same reference numbers are used throughout the drawings to refer to the same or like parts. While examples and features of disclosed principles are described herein, modifications, adaptations, and other implementations are possible without departing from the spirit and scope of the disclosed embodiments. It is intended that the following detailed description be considered as exemplary only, with the true scope and spirit being indicated by the following claims.
[0016] Software testing lifecycle or STLC involves multiple stages including generation of test cases as well and execution of said test cases. These multiple stages of software testing are to be performed in a definite sequence to ensure the quality of the software under test. Conventionally, the entire STLC cycle involves substantial manual effort, thereby leading to reduced test coverage, lower productivity, high manual errors and higher human dependency. Consequently, the system performance of STLC tools is lowered, thereby leading higher CPU utilization and memory leaks. Moreover, the system downtime is increased leading to productivity loss and longer time to market. Another primary drawback of the conventional systems is inability to execute the test cases during off peak hours without human dependency. Due to human dependence, there is risk of domain loss in case of attrition. Automated execution of functional test cases may be difficult since such test cases are non-consistent in nature. Various efforts have been made to create automation script of the regression test cases, however creation of automation scripts involves a lot of effort and specialized technical expertise.
[0017] Various embodiments of the present disclosure provide method and system for generation of test cases and execution of the test cases in an automatic manner, thereby precluding the need for human intervention for testing of software applications. For example, the system for generation and execution of test cases includes an auto generator module to automatically generate the test cases based on workflow and depth of the software application. The workflow and the depth can be selected by a user for automatically generating the test scripts. Additionally, the system includes an auto executor module for automatically executing the test cases generated by the auto generator module. Using the disclosed system for generation and execution of test cases, issues related to faster time to market, process standardization, knowledge retention, productivity improvement, process transparency and effective change impact analysis can be addressed. Moreover, efficiency in the software testing is achieved by implementing data structures with faster read operation for storing business related data of the software application. Said business related data is accessed for generating the test case based on various rules or test strategies. The system and method for automatic test case generation and execution are described further with reference to FIGS. 1 to 5B.
[0018] Referring now to the drawings, and more particularly to FIGS. 1 through 5B, where similar reference characters denote corresponding features consistently throughout the figures, there are shown preferred embodiments and these embodiments are described in the context of the following exemplary system and/or method.
[0019] FIG. 1 illustrates a network implementation 100 of a system 102 for automated test case generation and execution, in accordance with an example embodiment. The system 102 may be configured to automatically create test cases and further execute the test cases. In one aspect, the system 102 proposes method for an automated test case generation and execution. The system 102 enables in accessing business related information associated with an application. For example, the business related information may include business rules, database information, data values, KPIs, and other such information. In an embodiment, the business related information may be arranged in a hierarchical form. The system utilizes the business related information to perform change impact analysis and auto-generate the impacted test cases. Further, the system 102 automatically executes the generated test cases so as to achieve process standardization, knowledge retention, productivity improvement, process transparency and effective change impact analysis.
[0020] In an embodiment, the network implementation 100 includes a plurality of computing devices which can access the system 102. It should be noted that the term “computing devices” can be referred to as encompassing one or more client devices, one or more physical and/or virtual servers, cloud computing devices and/or other components in the system 100. For example, the network implementation 100 includes computing devices, which may be user devices such as user devices 104-1, 104-2…104-N, and server(s) such as server 106, connected over a communication network such as a network 108.
[0021] The servers, such as the server 106, include but are not limited to application servers, database servers, computation farms, data centers, virtual machines, cloud computing devices, mail or web servers and the like. The server 106 includes one or more computing devices or machines capable of operating one or more Web-based and/or non-Web-based applications that may be accessed by other computing devices (e.g. client devices, other servers) via the network 108. One or more servers 106 may be front end Web servers, application servers, and/or database servers. Such data includes, but is not limited to Web page(s), image(s) of physical objects, user account information, and any other objects and information. It should be noted that the server 106 may perform other tasks and provide other types of resources.
[0022] The server 106 may include a cluster of a plurality of servers which are managed by a network traffic device such as a firewall, load balancer, web accelerator, gateway device, router, hub and the like. In an aspect, the server 106 may implement a version of Microsoft® IIS servers, RADIUS servers and/or Apache® servers, although other types of servers may be used and other types of applications may be available on the servers 106.
[0023] In an embodiment, the network implementation 100 includes one or more databases such as a database 110, communicatively coupled to the servers 106. The database 110 may be configured to allow storage and access to data, files or otherwise information utilized or produced by the system 102. Herein, it is assumed that the database 110 is embodied in computing devices configured external to the servers 106. It will however be noted that in alternative embodiments, the databases 110 may be embodied in the servers 106.
[0024] The system 102 may be accessed by multiple users through one or more user devices 104-1, 104-2…104-N, collectively referred to as user devices 104 hereinafter, or applications residing on the user devices 104. In one implementation, the system 102 may include a cloud-based computing environment in which a user may operate individual computing systems configured to execute remotely located applications. Examples of the user devices 104 may include, but are not limited to, a portable computer, a personal digital assistant (PDA), a handheld device, and a workstation. Herein, the network environment 100 is shown to include a limited number of user devices, such as user devices 104-1, 104-2…104-N, however, it will be understood that the network environment 100 may include any other numbers and types of devices in other arrangements, without limiting the scope of the various embodiments disclosed herein.
[0025] In an aspect, the user device 104 may be configured to run a Web browser or other software module that provides a user interface for human users to interact with and access the system 102, as will be described in more detail below. For example, the client device may include a locally stored mobile application which allows the user to request resources and/or information via the mobile application.
[0026] The user devices 104 are communicatively coupled to the system 102 through the network 108. In one implementation, the network 108 may be a wireless network, a wired network or a combination thereof. The network 108 can be implemented as one of the different types of networks, such as intranet, local area network (LAN), wide area network (WAN), the internet, and the like. The network 108 may either be a dedicated network or a shared network. The shared network represents an association of the different types of networks that use a variety of protocols, for example, Hypertext Transfer Protocol (HTTP), Transmission Control Protocol/Internet Protocol (TCP/IP), Wireless Application Protocol (WAP), and the like, to communicate with one another. Further the network 106 may include a variety of network devices, including routers, bridges, servers, computing devices, storage devices, and the like.
[0027] FIG. 2 illustrates a block diagram of a system 200 for automatic test case generation and execution, in accordance with an example embodiment. The system 200 may be an example of the system 102 (FIG. 1). In an example embodiment, the system 200 may be embodied in, or is in direct communication with the system, for example the system 102 (FIG. 1). The system 200 includes or is otherwise in communication with at least one processor such as a processor 202, at least one memory such as a memory 204, and an I/O interface 206. The processor 202, memory 204, and the I/O interface 206 may be coupled by a system bus such as a system bus 208 or a similar mechanism.
[0028] The I/O interface 206 may include a variety of software and hardware interfaces, for example, a web interface, a graphical user interface, and the like The interfaces 206 may include a variety of software and hardware interfaces, for example, interfaces for peripheral device(s), such as a keyboard, a mouse, an external memory, a camera device, and a printer. Further, the interfaces 206 may enable the system 102 to communicate with other devices, such as web servers and external databases. The interfaces 206 can facilitate multiple communications within a wide variety of networks and protocol types, including wired networks, for example, local area network (LAN), cable, etc., and wireless networks, such as Wireless LAN (WLAN), cellular, or satellite. For the purpose, the interfaces 206 may include one or more ports for connecting a number of computing systems with one another or to another server computer. The I/O interface 206 may include one or more ports for connecting a number of devices to one another or to another server.
[0029] The hardware processor 202 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the hardware processor 202 is configured to fetch and execute computer-readable instructions stored in the memory 204.
[0030] The memory 204 may include any non-transitory computer-readable medium namely computer readable or processor readable storage media, which are examples of machine-readable storage media. Computer readable storage/machine-readable storage media may include volatile, nonvolatile, removable, and non-removable media implemented in any method or technology for storage of information. Such storage media stores computer readable/machine-executable instructions, data structures, program modules and components, or other data, which may be obtained and/or executed by one or more processors, such as device processor 202. Examples of computer readable storage media include, volatile memory, such as static random access memory (SRAM) and dynamic random access memory (DRAM), and/or non-volatile memory, such as read only memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes.
[0031] In an embodiment, the memory 204 includes a plurality of modules 220 and a repository 230 for storing data processed, received, and generated by one or more of the modules 220. The modules 220 may include computer readable/machine executable instructions, routines, programs, objects, components, data structures, and so on, which perform particular tasks or implement particular abstract data types. It is contemplated that the modules 220 may alternatively be housed in another memory external to the memory 204. Such stored instructions allow the processor 202 to perform actions, including implementing an operating system for controlling the general operation of the system 200 to perform one or more portions of the novel process described below. The modules 220 are configured to cause the system 200 to perform the test case generation and execution method to verify the functionalities of all the applications in a business process model, as will be described in more detail further below.
[0032] In one implementation, the modules 220 may include an auto-planning module 222, an auto-execution module 224 and other modules 226. The other modules 226 may include programs or coded instructions that supplement applications and functions of the system 200. The repository 230, amongst other things, includes a system database 232 and other data 234. The other data 234 may include data generated as a result of the execution of one or more modules in the other modules 226. The repository 230 is further configured to maintain a business process data 236, graph data 238, and a prestored test case data 240.
[0033] In an embodiment, the system 200 may be caused to capture a business process associated with the software application. The business process may be a structured hierarchical process model having a plurality of workflows. The term ‘workflow’ refers to a series of actions documented to execute the process. It includes decision boxes, start and stop steps, data points to execute the steps. The workflows may be representative of Business Process Maps categorized into multiple levels or depths. The plurality of workflows may be associated with distinct levels depths. Herein, the term ‘Depth’ may indicate the levels of workflow. For e.g. level 1 for a business process “Send an email using Gmail account” may be log into gmail -> open new message -> send email -> log out. Level 2 for the step “Log into gmail is -> open browser -> enter www.(mailbrowser).com -> enter userID and password-> click on log in, and so on. In an embodiment, the business process can be captured by generating a process map of the software application. In an embodiment, the business process may be stored as the business process data 236 in the repository 230.
[0034] In an embodiment, the auto-planning module 222 converts the process map into a graph. The graph from the process maps may include a plurality of nodes and a plurality of edges interconnecting the plurality of nodes. The plurality of nodes may include a set of decision nodes, and a set of activity nodes arranged between pairs of decision nodes. A decision node may refer to a node in the graph which may be split into two or more branches. The decision nodes may be representative of a test on an attribute while the two or more branches emanating from the decision node may be representative of outcome of the test. An activity node may be referred to as a node which is representative of an activity being performed at said node. For the purpose of present description, the decision node is distinct from the activity node. An example graph having decision nodes and activity nodes generated based on a process map is described further with reference to FIGS. 3A-3C.
[0035] In an embodiment, the graph may be stored in an XML Process Definition Language (XPDL) format. The XPDL format may include information such as edges, decision points, vertex, and so on, and may be stored as the graph data 238 in the system 200. In an embodiment, said information may be stored as a data structure in the system 200. The graph is indicative of function flow of the business process representing all the possible workflow execution sequences of activities associated with the software application.
[0036] In an embodiment, the system 200 is caused to identify optimized test paths for execution of a plurality of test cases from the graph. The optimized test paths may include the path satisfying predefined criteria for selection of that path for test case generation. The predefined criteria include identifying paths having minimal count path equal to maximum count path. In an embodiment, the auto-planning module 222 identifies the paths satisfying the predetermined criteria.
[0037] In an embodiment, the auto-planning module 222 identifies the paths satisfying the predetermined criteria by identifying smaller sub-graphs (having subgraph-to-subgraph (S2S) paths) where minimal count path is equal to maximum count path. Herein, it will be noted that the minimal count path and maximal count path refers to the number of decision nodes in a path which are adjacent to the path. In a S2S graph, i.e. a sub-graph between the decision points, there may exist some decision points. Between the adjacent decision points, the number of minimal count paths is equal to maximal count paths. In other words, when the path is computed between two adjacent decision nodes, the path count is same for minimal condition and the maximal condition. Accordingly, while calculating the path between the two adjacent decision nodes, the number of paths is verified for the condition of minimal and maximal paths. It will be noted that identification of the optimized path forms the basis for increasing computation efficiency of the system in test case generating and execution, since the optimized path determines the total number of test cases and the test scenarios that can be generated.
[0038] In an embodiment, to generate the optimized test paths for various test cases, the auto-planning module 222 traverses through Document Object Model (DOM)-to-DOM (D2D) graphs in the graph, and identify one or more (S2S) paths arranged between pairs of decision nodes within the D2D graphs. In an embodiment, the graph may be cut by using horizontal cuts into multiple D2D graphs. A D2D graph may be understood as a document object model subgraph that may appear between two decision nodes in the graph. Upon cutting the graph using horizontal lines, a graph that is separated out by only single cut in the graph can be referred to as a D2D graph. Example of D2D graph in a graph is illustrated and described further with reference to FIGS. 3A-3C.
[0039] In an embodiment, in each D2D graph, the auto-planning module 222 identifies plurality of subgraphs. Each sub-graph of the plurality of sub-graphs includes one or more S2S paths between the pairs of decision nodes. In an embodiment, the paths inside S2S graphs are realized and stored in memory for indexing purpose. A detailed example of identifying the sub-graphs and storing the sub-graphs associated with the predetermined criteria is described further with reference to FIGS. 3A-3C.
[0040] In a D2D graph, all S2S sub-graphs are merged according to the predefined criteria. In an embodiment, the predefined criteria may include one of minimal and maximum test criteria. The minimal test criteria may refer to the test criteria where the E2E test case is generated and executed by merging at least one path from each of the S2S graph. The maximal criteria is the test criteria where the E2E test case is generated and executed by merging all the possible paths from each of the S2S graph.
[0041] In an embodiment, multiple sub-graphs that are identified and stored in the repository 230 may be merged together to generate an end-to end (E2E) path, where the E2E path is generated for a test case in an optimal manner. For example, in order to generate a test case, a user may provide a selection of at least a workflow of a plurality of workflows and a depth of said workflow associated with the application. Herein, depth of the workflow may be indicative of level of component that is to be accessed in the graph of the business process. An example of the depth of workflow is described further with reference to FIG. 5A.
[0042] In an embodiment, the system 200 may further receive a selection of one or more filters criteria. In an embodiment, the auto-planning module may include a filter module to receive the plurality of filter criteria Herein, the filter criteria can be defined based on business rules, data points, decision points, node values of the decision points, and so on. In an embodiment, the selection of the workflow, the depth of the workflow and filter criteria may be received at the auto-planning module 222. In an embodiment, the selection of the workflow, the depth of the workflow and filter criteria may be received from a user. Herein, the user may be understood to as a ‘testing professional’ or a ‘tester’ performing testing of the application.
[0043] Based on the selection of the workflow, the depth of the workflow and filter criteria, the auto-planning module 222 may create a merged and clean and optimized End-to-End (E2E) path indicative of the test case. In an embodiment, the auto-planning module 222 may include an optimization module for generating the optimized paths based on the predefined criteria. It will be noted herein that since corresponding to various test cases, the S2S paths (and not the E2E paths) are stored in the memory, memory out exception is avoided by using iterative loops. In addition, efficiency of test case generation is achieved since the data structures storing the filters are associated with faster read operation. Moreover, the E2E paths are generated by S2S paths that are stored in the memory, thereby reducing number of hops while path generation, as compared to the conventional approaches of path generation. Only required E2E paths are generated lazily based on test strategies applied. The optimized E2E paths generated may be presented on the UI of the system 200.
[0044] The system 200 includes an auto-execution module 224. The auto-execution module 224 receives the test cases generated by the auto-planning module 222, and executes said test cases by using the test case data 240. In an embodiment, the prestored test case data 240 may be prestored in the repository. Alternatively, the prestored test case data may be stored in a remote database and may be accessible by the system 200. In an embodiment, the prestored test case data 240 may be stored in a method and the method parses through the code and retrieves the stored test case data 240 to execute the test case. For example, in case there are two rows of prestored test case data 240 for a variable, then the code may execute twice for said data values. An example process flow for test case generation and execution is described further with reference to FIGS. 3A-3C below.
[0045] FIGS. 3A-3C illustrates an example graph 310 of a business process and a process sequence for identifying optimal path from the graph for test case generation and execution are described in accordance with an example embodiment.
[0046] Referring to FIG. 3A, the graph 310 is a graph for an example business process. The graph 310 includes a plurality of decision nodes marked as 1,3 ,6,7,10,11,12,13,14,15,16,and 17, and a plurality of activity nodes marked as 2, 18, 19, 4, 5, 8, 9, 20, 21, 22, 23, 24, 25, and 26. The nodes marked as A and A’ are start and end nodes.
[0047] First step is to compute D2D (DOM-to-DOM) graph from the graph 310. As mentioned previously, a D2D graph includes a single horizontal cut only. It can be noted that if a horizontal cut such as cut 1-1’ is made, it cuts the graph at more than one places, while a cut such as cut 2-2’ is made, it cuts the graph at only one place. The cuts 2-2’ which cuts the graph at only one place facilitates in identifying the D2D graphs in the graph 310. In particular, a portion of the graph 310 occurring between the cuts 2-2’ and 3-3’ can be assumed to be the D2D graph. In accordance with the above, the graph 310 is shown to include D2D graphs, namely, D2D graph 320, D2D graph 330, D2D graph 340, and D2D graph 350 (refer, FIG. 3B).
[0048] The system 200 is caused to identify S2S graphs in each of the D2D graphs (of FIG. 3B), based on a predetermined criteria such that upon merging the identified S2S graphs, an end-to-end (E2E) path can be identified which is the most optimal path for generation of the test case. In accordance with various embodiments of the present disclosure, such S2S paths can be identified based on predetermined criteria of maximal path equal to minimal path.
[0049] As is seen from FIG. 3B, the D2D graphs, namely D2D graph 320 and the D2D graph 350 includes no decision nodes, while the graphs, D2D graph 330 and the D2D graph 340 contains all the decision nodes. Accordingly, the E2E path can be determined upon determination of the S2S paths from the graphs D2D graph 330 and the D2D graph 340. In the present example, the D2D graph 330 and the D2D graph 340 are similar to each other, and hence the S2S paths of the D2D graph 330 may also be similar to the S2S paths of the D2D graph 340. For the brevity of description, only identification of S2S paths and E2E paths from the D2D graph 330 is explained below in FIG. 3B.
[0050] Referring to FIG. 3B, identifying the S2S paths from the D2D graph 330 includes traversing the D2D graph 330 from one decision point and move till a neighbor or adjacent decision point of that decision point. For example, in the D2D graph 330, the system may initiate traversing from the decision node 1, and moves towards other decision nodes till nodes till the neighbor decision node 11 is reached. Upon such traversing, the system 200 may determine following S2S graphs and decision points:
S2S 1: two paths, adjacent decision point (1 and 11, 1 and 3)
S2S 2: two paths, adjacent decision point (3 and 6)
S2S 3: two paths, adjacent decision point (7 and 10)
S2S 4: only one path, adjacent decision point (10 and 11)
[0051] During such traversal the system may identify smaller sub graphs or S2S graphs in which minimal paths is equal to maximum path. Such paths inside the S2S graphs are realized and stored in memory 204. Herein, it will be noted that only S2S graphs leading to E2E graphs are stored in the memory, and the E2E paths are generated therefrom at the time of execution of the test cases. Since the E2E paths are not stored in the memory, the problem of memory out exception, present in conventional tools is tackled by the disclosed system. An example UI for the system is described further with reference to FIGS. 5A-5B.
[0052] FIG. 4 is a flow diagram illustrating a method for automated generation and execution of test cases, in accordance with some embodiments of the present disclosure. The method 400 may be described in the general context of computer executable instructions. Generally, computer executable instructions can include routines, programs, objects, components, data structures, procedures, modules, functions, etc., that perform particular functions or implement particular abstract data types. The method 400 may also be practiced in a distributed computing environment where functions are performed by remote processing devices that are linked through a communication network. The order in which the method 400 is described is not intended to be construed as a limitation, and any number of the described method blocks can be combined in any order to implement the method 400, or an alternative method. Furthermore, the method 300 can be implemented in any suitable hardware, software, firmware, or combination thereof.
[0053] In an embodiment, the method 400 depicted in the flow chart may be executed by a system, for example, the system 200 of FIG. 2. In an example embodiment, the system 200 may be embodied in a computing device.
[0054] At 404 the method includes receiving, via one or more hardware processors, selection of a workflow of a plurality of workflows and a depth of said workflow. The plurality of workflows may be associated with the software application. At 404, the method 400 includes receiving, via the one or more hardware processors, one or more filters criteria. The filter criteria may include, but are not limited to, business rules, test data, decision boxes and the node values from said decision box.
[0055] At 406 the method 400 includes automatically generating a test case corresponding to the workflow and the depth of said workflow based on the one or more filters criteria. In an embodiment, generating the automated test case includes accessing a test case repository having optimized test paths for execution of a plurality of test cases (at 408). The optimized test paths are the test paths that satisfy a predefined criteria for selection of the optimized test path for test case generation. An example of generation of optimized test paths is described with reference to FIGS. 3A-3C.
[0056] At 410, the method 400 includes executing the test case by using a prestored test case data. In an embodiment, the test case data may be stored in a method and the method parses through the code and retrieves the stored test case data to execute the test case. For example, in case there are two rows of test case data for a variable, then the code may execute twice for said data values. An example UI of automated test case generation and execution is illustrated and described further with reference to FIGS. 5A and 5B.
[0057] FIGS. 5A and 5B represents User interface (UIs) 510 and 550 illustrating an example of automated test case generation and execution, in accordance with an example embodiment. In an embodiment, the example automated test case can be generated and executed by an automated test case generation and execution system, for example, the system 200 (FIG. 2).
[0058] Referring now to FIG. 5A, a UI 510 for the system 200 includes various fields such as a process name field, a workflow name field, level of the workflow field, test data field, and a package name. Upon providing relevant details in the various fields of the UI 510, the system automatically generates the test cases, and also executes the same. For example, as illustrated in FIG. 5A, the process (or the software application) for which the test case is to be generated may be selected as ‘Webex’. The selection of the process or the software application is followed by selection of other details such as workflow and level. Herein, the term workflow may refer to the various transitions that can be performed at various ‘levels’ thereof. The levels may be user access levels that may be initiated by the user for triggering such transactions. For instance, in the present example, the workflow name corresponding to the process ‘Webex’ may be selected as ‘Webex’. Other available workflows that can be selected for the present example, may include, ‘Schedule estimate meeting time, ‘click on schedule a meeting’, ‘Enter attended email ID’, ‘Set meeting password’, and so on.
[0059] On clicking the ‘Generate’ button on the UI 500, the system 200 is caused to generate a process flow corresponding to the selected workflow and the level. Herein it will be noted that the disclosed process flow is the representative process flow corresponding to the selected workflow and the level. Said optimal workflow (or E2E path) is obtained based on the process flow graph and identifying the optimal workflow from the graph based on the predetermined criteria, as explained with reference to FIG. 2. An example graph representing most optimal workflow that is generated for the selected workflow and level thereof is illustrated in FIG. 5A.
[0060] The UI 510 may also prompt to select the test data corresponding to the selected workflow and the level of the workflow. The test data may be utilized for execution of the test case. In an embodiment, the system 200 may be configured to automatically select the test data corresponding to the selected workflow and the level upon selection of the workflow and the level. An example UI 550 of the execution of the test case using the test data is illustrated with reference to FIG. 5B.
[0061] The written description describes the subject matter herein to enable any person skilled in the art to make and use the embodiments. The scope of the subject matter embodiments is defined by the claims and may include other modifications that occur to those skilled in the art. Such other modifications are intended to be within the scope of the claims if they have similar elements that do not differ from the literal language of the claims or if they include equivalent elements with insubstantial differences from the literal language of the claims.
[0062] The embodiments of present disclosure herein addresses unresolved problem of test case generation and execution in a memory efficient and automated manner. The embodiments, thus provides a method and system for test case generation and execution for software applications. The disclosed system converts the business logic of the software application into process maps, which are then converted into a graph. Multiple subgraphs are identified from the graph. Each subgraph includes various paths between a start node and an end node of the sub-graph. A subgraph is selected from the multiple subgraphs based on a predefined criteria, such that the subgraph provides a most optimized path. The system takes into consideration all the possible permutations and combinations of the paths to generate the final output. It is humanly impossible to create test cases in the number of thousands and lacs, however, the disclosed system eases the process of automatically generating cases in an optimized manner.
[0063] Further executing these test cases is time consuming activity and further creation of the automation scripts requires specialized skill sets. The disclosed system bypasses both of these time consuming activities by automating them. Efficiency is achieved by incorporating data structure with faster read operation, reducing number of hops while path generation, and generating only required E2E paths lazily based on test strategies applied. Moreover the disclosed system enables in avoiding memory out exception by using iterable loop as the E2E paths are not stored.
[0064] It is to be understood that the scope of the protection is extended to such a program and in addition to a computer-readable means having a message therein; such computer-readable storage means contain program-code means for implementation of one or more steps of the method, when the program runs on a server or mobile device or any suitable programmable device. The hardware device can be any kind of device which can be programmed including e.g. any kind of computer like a server or a personal computer, or the like, or any combination thereof. The device may also include means which could be e.g. hardware means like e.g. an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or a combination of hardware and software means, e.g. an ASIC and an FPGA, or at least one microprocessor and at least one memory with software modules located therein. Thus, the means can include both hardware means and software means. The method embodiments described herein could be implemented in hardware and software. The device may also include software means. Alternatively, the embodiments may be implemented on different hardware devices, e.g. using a plurality of CPUs.
[0065] The embodiments herein can comprise hardware and software elements. The embodiments that are implemented in software include but are not limited to, firmware, resident software, microcode, etc. The functions performed by various modules described herein may be implemented in other modules or combinations of other modules. For the purposes of this description, a computer-usable or computer readable medium can be any apparatus that can comprise, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.
[0066] The illustrated steps are set out to explain the exemplary embodiments shown, and it should be anticipated that ongoing technological development will change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration, and not limitation. Further, the boundaries of the functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope and spirit of the disclosed embodiments. Also, the words “comprising,” “having,” “containing,” and “including,” and other similar forms are intended to be equivalent in meaning and be open ended in that an item or items following any one of these words is not meant to be an exhaustive listing of such item or items, or meant to be limited to only the listed item or items. It must also be noted that as used herein and in the appended claims, the singular forms “a,” “an,” and “the” include plural references unless the context clearly dictates otherwise.
[0067] Furthermore, one or more computer-readable storage media may be utilized in implementing embodiments consistent with the present disclosure. A computer-readable storage medium refers to any type of physical memory on which information or data readable by a processor may be stored. Thus, a computer-readable storage medium may store instructions for execution by one or more processors, including instructions for causing the processor(s) to perform steps or stages consistent with the embodiments described herein. The term “computer-readable medium” should be understood to include tangible items and exclude carrier waves and transient signals, i.e., be non-transitory. Examples include random access memory (RAM), read-only memory (ROM), volatile memory, nonvolatile memory, hard drives, CD ROMs, DVDs, flash drives, disks, and any other known physical storage media.
[0068] It is intended that the disclosure and examples be considered as exemplary only, with a true scope and spirit of disclosed embodiments being indicated by the following claims.