TWI905825B - Apparatus, method, and recording medium for managing test data related to the execution of test case - Google Patents

Abstract

This invention provides an electronic device for managing test data related to the execution of test cases. The electronic device of this invention may include: one or more processors; and one or more memory stores commands to be executed by the one or more processors; and the electronic device is configured such that, when executing the commands, the one or more processors determine whether a test data pool storing a plurality of test data meets pre-set conditions for a target test item; if the test data pool does not meet the pre-set conditions, at least one test data related to the target test item is generated, and the generated at least one test data is stored in the test data pool.

Description

Apparatus, methods, and recording media for managing test data related to the execution of test cases.

This invention relates to a technique for managing test data related to the execution of test cases. More specifically, this invention relates to a technique for generating and storing test data for the smooth execution of test cases.

Software testing refers to the process of verifying whether software functions accurately as intended by the developer. Recently, the importance of automated testing in the software development process has been increasing. Software automated testing automates the execution of software testers, meaning the process of automatically executing pre-made or on-the-spot test cases using prepared test data. Software automated testing can shorten development cycles and minimize human error by effectively executing test cases, contributing to the delivery of high-quality software. However, several problems exist in the software automated testing process. One problem is the management of test data used to reliably execute test cases. Without proper test data preparation, it is difficult to ensure the stability and reliability of software automation testing, thus increasing the likelihood of inconsistent test results or failures. Therefore, preparing test data quickly and accurately in a software automation testing environment is a core element for successfully executing test cases.

[The problem that the invention aims to solve]

This invention relates to a technique for managing test data related to the execution of test cases. [Technical means to solve the problem]

This invention provides a method for managing test data related to the execution of test cases. One embodiment of this invention may include the following steps: determining whether a test data pool storing a plurality of test data meets pre-defined conditions for an object test item; when the test data pool does not meet the pre-defined conditions, generating at least one test data item related to the object test item; and storing the generated at least one test data item in the test data pool.

In one embodiment, the aforementioned pre-set conditions may include whether the aforementioned test data pool stores a critical number or more of valid test data related to the aforementioned object test items.

In one embodiment, the above-mentioned critical number can be set to more than the maximum number of test cases that are related to the above-mentioned object test items and are executed simultaneously.

In one embodiment, the above-mentioned generation steps may include the following steps: when the test data pool does not store more than the above-mentioned critical number of valid test data related to the above-mentioned target test item, generate test data related to the above-mentioned target test item according to the number obtained by subtracting the number of valid test data related to the above-mentioned target test item stored in the test data pool from the above-mentioned critical number.

In one embodiment, the above-mentioned determination steps may include the following steps: determining whether the above-mentioned test data pool meets the above-mentioned pre-set conditions for the test items of the above-mentioned object according to a pre-set time cycle.

In one embodiment, the above-mentioned determination step may include the following steps: when there are multiple types of test data related to the above-mentioned object test items, determine whether the above-mentioned test data pool stores valid test data for each of the multiple types, which is more than the number of critical values set for each of the above-mentioned types.

In one embodiment, the number of critical points set for the first type of the plurality of types may be different from the number of critical points set for the second type of the plurality of types.

An embodiment of the method may further include the following steps: as a test case related to the above-mentioned object test item is executed, any test data from the valid test data related to the above-mentioned object test item stored in the above-mentioned test data pool is assigned to the above-mentioned test case.

An embodiment of the method may further include the following steps: mapping tags to each of the plurality of test data stored in the test data pool; and the allocation step includes the following steps: allocating the arbitrary test data to the test case by providing tags mapped to the arbitrary test data in the test case.

An embodiment of the method may further include the following steps: during the execution of the test case using the aforementioned test data, activating the locking function of the aforementioned test data; and the aforementioned test data, after the locking function is activated, is terminated from being allocated to other test cases until the locking function is released.

An embodiment of the method may further include the following steps: when the execution of the above test case ends, unlocking the locking function of any of the above test data.

An embodiment of the method may further include the following steps: when any of the test data related to the above-mentioned object test item is non-reusable data, if the execution of the above-mentioned test case is successful, the state of the above-mentioned test data is changed from a valid state to an invalid state; if the execution of the above-mentioned test case fails, the state of the above-mentioned test data is kept in a valid state.

An embodiment of the method may further include the following steps: when any of the test data related to the above-mentioned object test items is reusable data, the state of the above-mentioned test data is kept in a valid state regardless of the execution result of the above-mentioned test case.

One embodiment of the method may further include the following steps: when executing a test case related to the above-mentioned object test item, if it is determined that there is no valid test data in the above-mentioned test data pool that can execute the above-mentioned test case, test data that can execute the above-mentioned test case is generated immediately.

One embodiment of the method may further include the following steps: when the test data pool does not meet the pre-set conditions, generating information indicating that the pre-set conditions are not met.

In one embodiment, the at least one test data may be generated based on at least one of one or more parameters embedded in the automation tool corresponding to the above-mentioned object test item and one or more parameters input by the user for the above-mentioned object test item.

This invention provides an apparatus for managing test data related to the execution of test cases. The electronic apparatus of this invention may include: one or more processors; and one or more memory units storing commands to be executed by the one or more processors. The electronic apparatus is configured such that, when executing the commands, the one or more processors can determine whether a test data pool storing a plurality of test data sets meets pre-set conditions for a target test item. If the test data pool does not meet the pre-set conditions, at least one test data set related to the target test item is generated, and the generated at least one test data set is stored in the test data pool.

This invention provides a non-transitory computer-readable recording medium for recording commands related to the management and execution of test data. In one embodiment of this invention, the commands recorded on the recording medium can be commands that can be executed by one or more processors or implemented on a computer. When executed by one or more processors, the commands can cause one or more processors to determine whether a test data pool storing a plurality of test data meets pre-set conditions for a test item. If the test data pool does not meet the pre-set conditions, at least one test data item related to the test item is generated and stored in the test data pool. [Effects of the Invention]

According to the present invention, since test data can be generated and stored in the test data pool before test cases are executed, test case execution failure due to insufficient test data can be prevented.

According to this invention, since test data related to the test items can be automatically generated by automation tools through the verification of the test data pool without user input, the time required to generate test data can be shortened.

According to the present invention, test cases can be executed stably by activating the locking function of the test data input into the test cases during the execution of the test cases, thereby preventing the test data from being used for multiple test cases at the same time.

According to this invention, the status of test data can be updated as test cases are executed, thereby maintaining a fixed number of valid test data in the test data pool.

The effects of the technical concept of this invention are not limited to those mentioned above. Those skilled in the art can clearly understand other effects not mentioned based on the description in the manual.

The various embodiments described herein are illustrated for the purpose of clearly illustrating the technical concept of the invention and are not intended to limit them to specific embodiments. The technical concept of the invention includes various modifications, equivalents, alternatives, and embodiments obtained by selectively combining all or part of the embodiments described herein. Furthermore, the scope of the technical concept of the invention is not limited to the various embodiments shown below or their specific descriptions.

The terms used in this invention, including technical or scientific terms, shall, unless otherwise defined, have the meanings commonly understood by a person of common knowledge in the technical field to which this invention pertains.

The use of terms such as "including," "may include," "possibly possess," "has," "may have," and "may have" in this invention implies the presence of object features (e.g., functions, actions, or constituent elements), and does not exclude the existence of other additional features. That is, the above-mentioned expressions should be understood as open-ended terms that have the possibility of including other embodiments.

Unless otherwise stated, the singular expressions used in this invention may contain the meaning of the plural form, and this also applies to the singular expressions recorded in the scope of the patent application.

The terms “first,” “second,” “first,” “second,” etc., used in this document are, unless otherwise specified, used to distinguish one object from others when referring to multiple objects of the same kind, and are not used to define the order or importance of such objects.

The expressions “A, B and C”, “A, B or C”, “A, B and/or C”, “at least one of A, B and C”, “at least one of A, B or C”, or “at least one of A, B and/or C” as used herein may refer to each of the listed items or all possible combinations of the listed items. For example, “at least one of A or B” may refer to (1) at least one A, (2) at least one B, or (3) at least one A and at least one B.

The term "based on" as used in this invention is used to describe one or more factors described in the statement or text containing the term that affect the determination or judgment of an action or behavior. The term does not exclude other factors that affect the determination or judgment of an action or behavior.

The expression used in this invention to say that a certain constituent element (e.g., the first constituent element) is "connected" or "linked" to another constituent element (e.g., the second constituent element) may not only mean that the aforementioned constituent element is directly connected or linked to the aforementioned other constituent element, but may also mean that it is connected or linked to the aforementioned other constituent element through a new other constituent element (e.g., the third constituent element).

The phrase "configured to" as used in this invention can have meanings such as "configured in a ~ manner," "possessing ~ capabilities," "modified in a ~ manner," "made in a ~ manner," and "capable of ~ operations," depending on the context. This phrase is not limited to the meaning of "specially designed in hardware." For example, a processor configured to perform a specific action can refer to a general-purpose processor that can perform that specific action by executing software, or a special-purpose computer that performs that specific action through programming.

The various embodiments described in this invention will now be described with reference to the accompanying drawings. In the drawings and their descriptions, identical or substantially equivalent constituent elements may be assigned the same reference numerals. Furthermore, in the following descriptions of the embodiments, repeated descriptions of identical or corresponding constituent elements may be omitted, but this does not mean that the constituent element is not included in that embodiment.

Figure 1 illustrates the environment in which an electronic device of one embodiment of the present invention can be applied.

Test cases may include or represent a series of operations, actions, conditions, and/or variables designed to verify whether the software meets specific design specifications. To execute a test case, more than one set of test data may need to be entered. To ensure stable execution of test cases, an electronic device 110 in one embodiment may manage the test data. More specifically, the electronic device 110 may be a device for generating and storing more than one set of test data.

In one embodiment, electronic device 110 may be implemented as more than one computing device. For example, all functions of electronic device 110 may be implemented in a single computing device. As another example, a first function of electronic device 110 may be implemented in a first computing device and a second function may be implemented in a second computing device. As yet another example, a plurality of computing devices may be used to implement all or specific functions of electronic device 110. The computing device described above may be a desktop computer, laptop computer, application server, proxy server, or cloud server, but is not limited thereto; all types of devices with computing capabilities may be computing devices.

In one embodiment, user terminal 120 can generate test cases and transmit them to electronic device 110. Electronic device 110 can store test cases received from user terminal 120 in a test case pool. Furthermore, electronic device 110 can execute test cases received from user terminal 120 by inputting pre-prepared test data or real-time generated test data, and can transmit the execution result of the test cases to user terminal 120. However, the generator of test cases is not limited to user terminal 120; electronic device 110 can generate test cases by receiving information from user terminal 120. Furthermore, the electronic device 110 can automatically generate test cases even without receiving information from the user terminal 120.

In one embodiment, user terminal 120 can generate test data for executing test cases and transmit it to electronic device 110. Electronic device 110 can store the test data received from user terminal 120 in a test data pool. Alternatively, electronic device 110 can generate test data by receiving information from user terminal 120, or it can automatically generate test data even without receiving information from user terminal 120.

In one embodiment, the electronic device 110 and the user terminal 120 can operate as a single device. The user terminal 120 can be included as all or part of the constituent elements of the electronic device 110. In this case, for example, the various information exchanged between the electronic device 110 and the user terminal 120 via a network can be various information exchanged between the constituent elements within a single device.

In one embodiment, user terminal 120 may be implemented as a terminal capable of sending and receiving various information with electronic device 110 via a network. For example, user terminal 120 may be one of a computer, laptop, portable communication terminal (smartphone, etc.), portable multimedia device, wearable device, or HMD (Head-Mounted Display). However, the type of user terminal 120 is not limited to these, and user terminal 120 may be any device that includes an input/output interface capable of receiving or sending information to the user, and communicates with electronic device 110 or other devices via a network.

In one embodiment, user terminal 120 can provide information received from electronic device 110 to the user, and can receive input from the user and transmit it to electronic device 110. Specifically, user terminal 120 can obtain input from the user instructing them to call various pages, and generate commands instructing them to call various pages in response to the obtained input. User terminal 120 can transmit commands instructing them to call various pages to electronic device 110. Input obtained from the user can include various forms of input such as mouse clicks, touchpad or touchscreen clicks, voice recognition, and other electronic inputs. User terminal 120 can receive various pages from electronic device 110 and output the received pages.

The network enables the connection of electronic device 110 to user terminal 120 or other external devices. For example, the network provides connection paths so that user terminal 120 or other external devices can connect to electronic device 110 and send and receive packet data with electronic device 110. The network can be implemented as various types of wired or wireless networks, such as Local Area Network (LAN), Wide Area Network (WAN), Mobile Radio Communication Network, and Wibro (Wireless Broadband Internet).

Figure 2 is a block diagram of an electronic device according to one embodiment of the present invention. The electronic device 200 (e.g., the electronic device 110 of Figure 1) can generate and store more than one set of test data. In one embodiment, the electronic device 200 may include one or more processors 210, one or more memory units 220, and a communication interface 230 as constituent elements. In one embodiment, at least one of the constituent elements of the electronic device 200 may be omitted, or other constituent elements may be added to the electronic device 200. In one embodiment, some constituent elements may be additionally or alternatively integrated, or implemented as a single or multiple entities. In the present invention, one or more processors 210 may be referred to as processor 210. Unless otherwise specified in the text, the term "processor 210" may refer to a collection of one or more processors. In this invention, one or more memory units 220 may be referred to as memory 220. Unless otherwise specified in the text, the term "memory unit 220" may refer to a collection of one or more memory units. In one embodiment, at least some of the internal/external components of the electronic device 200 are interconnected via buses, GPIO (General Purpose Input/Output), SPI (Serial Peripheral Interface), or MIPI (Mobile Industry Processor Interface), thereby enabling the transmission and reception of information (data, signals, etc.).

In one embodiment, processor 210 can control at least one component of electronic device 200 connected to processor 210 via driver software (e.g., commands, programs, etc.). Furthermore, processor 210 can perform various actions related to the present invention, such as calculation, processing, data generation, and manipulation. Processor 210 can load data from memory 220 or store data in memory 220. In one embodiment, processor 210 can control communication interface 230, thereby requesting and receiving various information from a user terminal (e.g., user terminal 120 in FIG. 1).

In one embodiment, memory 220 may store various information (data). The information stored in memory 220 is information that can be obtained, processed, or used by at least one component of electronic device 200, and may include software (e.g., commands, programs, etc.). Memory 220 may include volatile and/or non-volatile memory. In this invention, commands and programs are software stored in memory 220, and may include operating systems for controlling the resources of electronic device 200, applications, and/or middleware that provides various functions to applications so that applications can utilize the resources of electronic device 200. In one embodiment, memory 220 may store commands that, when executed by processor 210, cause processor 210 to perform calculations. Memory 220 may store at least a portion of information received from a database via communication interface 230 and/or information sent to a database via communication interface 230. Specifically, memory 220 may store commands executed by processor 210.

In one embodiment, the communication interface 230 enables wireless or wired communication between the electronic device 200 and a database or other external electronic device. For example, the communication interface 230 can implement communication based on eMBB (enhanced Mobile Broadband), URLLC (Ultra Reliable Low-Latency Communications), MMTC (Massive Machine Type Communications), LTE (Long-Term Evolution), LTE-A (LTE Advance), NR (New Radio), UMTS (Universal Mobile Telecommunications System), GSM (Global System for Mobile communications), CDMA (Code Division Multiple Access), WCDMA (Wideband CDMA), WiBro (Wireless Broadband), WiFi (Wireless Fidelity), Bluetooth, NFC (Near Field Communication), and GPS (Global Positioning System). Wireless communication can be achieved using methods such as the Global Positioning System (GPS) or GNSS (Global Navigation Satellite System). For example, the communication interface 230 can implement wired communication based on methods such as USB (Universal Serial Bus), HDMI (High Definition Multimedia Interface), RS-232 (Recommended Standard-232), or POTS (Plain Old Telephone Service). In one embodiment, the electronic device 200 can also be integrated with other devices. In this case, the communication interface 230 functions as a connection circuit or interface for connecting the electronic device 200 to the other device.

The actions described below in Figures 3 to 9 as being performed by an electronic device can be understood as being performed by the processor 210 of the electronic device 200 described in Figure 2.

Figure 3 is a flowchart illustrating the process by which an electronic device of one embodiment of the present invention generates and stores at least one piece of test data related to a test item of the object.

In action S310, the electronic device 110 can determine whether the test data pool storing multiple test data meets the conditions preset for the test items of the target.

In one embodiment, electronic device 110 can store a plurality of test data in a test data pool. Electronic device 110 can store test data associated with various test items. Electronic device 110 can map one piece of test data to one or more test items.

In this specification, test items may represent specific scenarios in the software testing process. For example, consider the testing of software for a food ordering application (hereinafter referred to as the "Application"). In this case, the software testing process may include scenarios related to logging into the Application, scenarios related to ordering requests made through the Application, and scenarios related to the output of store information made through the Application. Each scenario can represent a test item.

During software testing, the scenarios represented by the test items need to be verified. For this purpose, multiple test cases can be prepared to verify the scenarios represented by the test items. Specifically, a test item can correspond to multiple test cases, each of which performs the function of verifying the scenarios represented by the test item. A test case can include at least one of one or more test steps and one or more verification steps. Furthermore, each of the multiple test cases corresponding to a test item can use test data related to the test item as input data. In other words, the test data related to the test item represents the data that can be used to execute the test cases used to verify the scenarios represented by the test item.

For example, test cases for verifying scenarios related to application login may include test cases for logging into the application with a customer account, a merchant account, or a delivery account. However, scenarios related to application login are not limited to test cases that verify the login action; they may include test cases that verify various actions that can be performed after login. This scenario could include test cases such as clicking a specific icon or button on the home page to confirm the result after logging into the application with a customer account. At this time, the test data, which can be used to execute test cases to verify the scenario, may include test accounts (e.g., customer accounts, store accounts, delivery person accounts) including account identifiers and account passwords. The electronic device 110 can map each test data to the test items representing the scenario related to application login and store them in the test data pool.

For example, test cases used to verify scenarios related to order requests made through the application may include test cases of a store accepting a customer's delivery order and test cases of a delivery person accepting and assigning a customer's delivery order. In this case, the test data used to execute the test cases verifying the scenario may include test orders containing information such as the menu of the store selected by the customer, the customer's payment information, and the delivery location information. The electronic device 110 can map each test data to test items representing scenarios related to order requests made through the application and store them in a test data pool. In the following description, for ease of explanation, any scenario in the software testing process will be described as an object test item.

In action S320, when the test data pool does not meet the conditions pre-set for the test item of the object, the electronic device 110 may generate at least one test data related to the test item of the object.

As described above, the test data stored in the test data pool can be mapped to one or more test items. The electronic device 110 can identify the test data related to the target test item among the plurality of test data stored in the test data pool. The electronic device 110 can determine whether the test data related to the target test item stored in the test data pool meets the preset conditions.

Pre-defined conditions may include whether the test data pool stores a critical number or more of valid test data related to the target test item. Here, the critical number can be fixed or variable. Furthermore, the critical number can be determined differently depending on the test item. For example, the critical number set for the first test item (e.g., 5) may differ from the critical number set for the second test item (e.g., 10). However, the pre-defined conditions are not limited to this. Pre-defined conditions may also include whether the number of valid test data related to the target test item stored in the test data pool that includes specific identification information is a fixed number or more. Here, specific identification information may represent conditions required for use as input data for a portion of test cases corresponding to an object test item. For example, when the object test item is a test order item, specific identification information may be identification information related to "wine order". That is, a portion of the test cases may receive test orders related to "wine order" as input data, and whether the test order is data related to "wine order" can be determined by whether it includes identification information related to "wine order". For example, in order to determine whether the test data pool meets the pre-set conditions, electronic device 110 may determine whether the number of valid test data related to the test order item that includes identification information related to "wine order" is a fixed number or more.

Test data can be categorized as valid or invalid based on its status. The status of test data will be described below.

In one embodiment, when the test data pool contains more than a critical number of valid test data related to the target test item, the electronic device 110 may not generate test data related to the target test item. Conversely, when the test data pool contains fewer than a critical number of valid test data related to the target test item, the electronic device 110 may generate at least one piece of test data related to the target test item.

In action S330, electronic device 110 may store at least one piece of test data generated in relation to the target test item in a test data pool. At this time, electronic device 110 may map each of the generated test data to the target test item.

Figure 4 is a diagram illustrating the process of generating test data by an electronic device according to one embodiment of the present invention. In one embodiment, the electronic device 110 may include a data management unit 410 and a data verification unit 440. The data management unit 410 can manage a plurality of test data. The data verification unit 440 can verify the plurality of test data managed by the data management unit 410.

In one embodiment, the data management unit 410 may include a test data pool 420 and a data generation module 430. The test data pool 420 may store a plurality of test data, and the data generation module 430 may generate test data related to the test items.

In one embodiment, the data verification unit 440 can verify the test data pool 420 included in the data management unit 410. First, the data verification unit 440 can access the data management unit 410. The data verification unit 440 can determine whether the test data pool 420 meets the pre-set conditions for each of the plurality of test items. If the test data pool 420 does not meet the pre-set conditions for the test items, the data verification unit 440 can transmit the information indicating that the pre-set conditions for the test items are not met to the data generation module 430 of the data management unit 410. The following mainly explains the condition that the test data pool 420 stores more than the critical number of valid test data related to the test items for the target.

In one embodiment, the data validation unit 440 can determine whether the test data pool 420 stores more than a critical number of valid test data related to the target test item. In this case, the critical number can be set to more than the maximum number of test cases related to the target test item that can be executed simultaneously. This is because, for stable execution of test cases, simultaneously executed test cases should use different test data. For example, if multiple test cases input a customer account as test data and execute them simultaneously, an account login conflict will occur, thus increasing the likelihood of test case failure. Test cases related to the target test item can represent test cases that use test data related to the target test item as input data. In other words, test cases related to the object test item can represent test cases that verify the scenario represented by the object test item.

In one embodiment, the maximum number of test cases related to and simultaneously executable in the object test item can be determined based on the verification frequency of the scenario represented by the object test item. The verification frequency of the scenario represented by the object test item can be expressed as the number of times test cases are executed to verify the scenario within a pre-set time period. When software testing errors, such as test case execution failures, occur during the verification process of the scenario represented by the object test item, the data verification unit 440 can increase the verification frequency of that scenario. When the data verification unit 440 increases the verification frequency of the scenario represented by the object test item, the maximum number of test cases related to the object test item that can be executed simultaneously can increase. In this situation, since the maximum number of test cases that can be executed simultaneously related to the target test item increases, the data validation unit 440 can increase the number of critical points corresponding to the target test item. Conversely, when the data validation unit 440 reduces the validation frequency of the scenario represented by the target test item, the maximum number of test cases that can be executed simultaneously related to the target test item can decrease, and the number of critical points corresponding to the target test item can also decrease. In this case, the data validation unit 440 can set different validation frequencies for each scenario, so the maximum number of test cases that can be executed simultaneously related to each test item can be determined differently depending on the test item.

In one embodiment, when the test data pool 420 does not store more than the critical number of valid test data related to the target test item, the data validation unit 440 can calculate the number of test data related to the target test item that needs to be generated. The data validation unit 440 can calculate the number obtained by subtracting the number of valid test data related to the target test item stored in the test data pool 420 from the critical number. The data validation unit 440 can transmit the calculated number to the data generation module 430. The data generation module 430 can generate test data related to the target test item according to the calculated number, or can generate more test data than the received number as needed. For example, referring to Figure 4, test data related to test account item 421, test order item 422, and test store item 423 can be stored in test data pool 420. Data generation module 430 can generate test data for the test account (action 431), test order test data (action 432), or test store test data (action 433) based on information received from data verification unit 440. In this case, data generation module 430 can use automation tools to generate test data.

In one embodiment, the data verification unit 440 can determine whether the test data pool 411 meets the pre-set conditions for the target test items at a pre-defined time cycle. Here, the pre-set time can be a fixed time or a variable time. For example, the pre-set time can be 5 minutes. Furthermore, the pre-set time can be determined differently depending on the test item. For example, the time cycle for determining whether the pre-set conditions for the first test item are met can be different from the time cycle for determining whether the pre-set conditions for the second test item are met. In one embodiment, the preset time for a test item can be changed according to the verification frequency of the scenario represented by the test item. For example, if the verification frequency of the scenario represented by the test item increases, the data verification unit 440 can reduce the preset time. Conversely, if the verification frequency of the scenario represented by the test item decreases, the data verification unit 440 can increase the preset time.

Figure 5 illustrates an embodiment of the present invention for determining whether pre-set conditions are met when there are multiple types of test data for a test item.

In one embodiment, test data related to a test item may exist in multiple types. For example, test data related to test account item 421 may be classified into one of the following: type 1 corresponding to a customer account, type 2 corresponding to a store account, and type 3 corresponding to a delivery person account, but the type of test data related to test account item 421 is not limited to this. As another example, test data related to test order item 422 may be classified into one of the following: type 1 corresponding to a delivery order, type 2 corresponding to a wine order, and type 3 corresponding to a purchase order, but the type of test data related to test order item 422 is not limited to this. Referring to Figure 5, the test data pool 420 can store test orders of type 1 531 and 534, test orders of type 2 532 and 535 and test orders of type 3 533 and 536 related to test order item 422.

In one embodiment, the data validation unit 440 can determine whether the test data pool 420 stores valid test data for each of the multiple types, exceeding the threshold number set for each type. In other words, when there are multiple types of tests related to the test items of the target, the data validation unit 440 can validate the test data related to each type. Specifically, when the test data pool 420 does not store valid test data related to a specific type among the multiple types, exceeding the threshold number set for a specific type, the data generation module 430 can generate at least one test data related to the specific type. In this case, the threshold number set for each of the multiple types may be the same or different. The number of thresholds set for a plurality of Type 1 test cases can differ from the number of thresholds set for a plurality of Type 2 test cases. For example, consider more than one test case used to verify that a customer is placing an order with multiple stores through an application. In this case, to execute more than one test case, one Type 1 customer account for a customer logging into the application and multiple Type 2 store accounts for each store logging into the application are required. That is, the number of Type 1 test data required to execute more than one test case can differ from the number of Type 2 test data, and therefore the number of thresholds set for each type can differ. For example, referring to Figure 5, the data verification unit 440 can independently determine whether the test data pool 420 stores 2, 6, or 5 or more valid test data of type 1, type 2, and type 3 related to the test order item 422.

In one embodiment, when the test data pool 420 does not store valid test data for a specific type among multiple types related to the target test item that exceed the threshold number set for a specific type, the data validation unit 440 can calculate the number obtained by subtracting the number of valid test data related to the specific type stored in the test data pool 420 from the threshold number. The data validation unit 440 can transmit the calculated number to the data generation module 430. The data generation module 430 can generate test data related to the specific type of the target test item according to the calculated number. The data generation module 430 can map the generated test data to the specific type of the target test item.

Figure 6 is a diagram illustrating the process by which an electronic device of one embodiment of the present invention distributes test data to test cases.

In one embodiment, the electronic device 110 may include a test execution unit 650, which may include a test case pool 660. A plurality of test cases (test case 1 651, test case 2 652, test case 3 653, ...) may be stored in the test case pool 660. The test cases may be executed during CI/CD pipeline operations (continuous integration/continuous delivery pipeline), online patrol, daily run, and debugging processes. CI/CD pipeline operations can represent the steps of automating the entire software development and release process by continuously compiling and releasing code changes; online inspections represent the steps of monitoring systems that are in real-time operation to detect potential problems or performance degradation early and address them; daily operations represent the software testing process performed periodically; and debugging represents the steps of detecting, analyzing, and correcting errors that occur in the software. In one embodiment, the test execution unit 650 can execute test cases stored in the test case pool 660 and can store the execution results of the test cases. However, the device for storing test cases is not limited to electronic device 110. Test cases may also be stored by an external device (e.g., user terminal 120), and electronic device 110 may receive test cases from the external device (e.g., user terminal 120) for execution.

In one embodiment, the test execution unit 650 can assign any test data from the valid test data related to the target test item stored in the test data pool 420 to a test case as a test case related to the target test item is executed. Furthermore, the execution status of a test case can include executing the test case and waiting for input data. Specifically, the data management unit 410 can map labels to each of the plurality of test data stored in the test data pool 420. The labels mapped to each of the plurality of test data stored in the test data pool 420 can be different. For example, the data generation module 430 can generate test data and can generate labels corresponding to the generated test data and map them to the test data. The data generation module 430 can map test data to tags and store it in the test data pool 420. The tags mapped to the test data can include the test item, type, and status corresponding to the test data. That is, when the test item, type, or status corresponding to the test data is updated, the tags mapped to the test data can be updated simultaneously. As a test case related to an object test item is executed, the test execution unit 650 provides the tags of any test data mapped to the valid test data related to the object test item stored in the test data pool 420 to a test case, thereby allowing any test data to be assigned to a test case. The following section explains in more detail the process of assigning arbitrary test data to a test case.

In one embodiment, the test execution unit 650 can execute a test case (e.g., test case 661). With the execution of a test case, the test execution unit 650 can allocate test data to be input into that test case. Specifically, the test execution unit 650 can identify the object test item corresponding to a test case. The test execution unit 650 can request from the data management unit 410 to allocate valid test data from the test data pool 420 related to the object test item (e.g., test account item 421) corresponding to a test case. The data management unit 410 can select any test data from the valid test data related to the target test item stored in the test data pool 420, and transmit the tag mapped to the arbitrary test data to the test execution unit 650. The test execution unit 650 can verify the tag received from the data management unit 410 to determine whether the arbitrary test data mapped to the tag is suitable for input into a test case. The test execution unit 650 can determine whether the test item, the type of test item, and the status included in the tag are suitable for input into a test case. For example, the test execution unit 650 can determine whether the test item included in the tag is consistent with the target test item corresponding to a test case, and whether the status included in the tag is a valid status. When the test execution unit 650 determines that any test data mapped to a tag is suitable for input into a test case, it may assign the tag to a test case.

In summary, after executing a test case, the test execution unit 650 can assign tags received from the data management unit 410 to a test case, use the tags to receive arbitrary test data mapped to the tags from the data management unit 410, and input the arbitrary test data into a test case. The test execution unit 650 can store the execution result of a test case. This specification mainly describes assigning one piece of test data to a test case, but it is not limited to this; multiple pieces of test data can be assigned to a test case. For example, a specific test case can verify multiple scenarios. When a specific test case verifies the actions of multiple pages, multiple scenarios can be verified. In this situation, in order to verify each of the multiple scenarios, a specific test case needs to input test data related to the test items representing each scenario. That is, multiple test data can be assigned to a specific test case, and the test items corresponding to the multiple assigned test data may be different.

Furthermore, a test case can also specify the specific type of the object test item to be received. For example, when a test case specifies the specific type of the object test item, the test execution unit 650 can also request the data management unit 410 to allocate valid test data related to the specific type of the object test item specified by the test case as the test case is executed.

Figure 7 is a diagram illustrating the process of locking the test data activation function of an electronic device according to one embodiment of the present invention.

In one embodiment, during the execution of a test case using allocated test data, the electronic device 110 may activate a locking function for the test data. Here, activating the locking function for test data indicates the termination of the allocation of the test data to any test case other than the one assigned to the test case. In other words, when the locking function for test data is activated, allocation to other test cases is terminated until the locking function is released. That is, for stable execution of test cases, simultaneously executed test cases must use different test data, hence the activation of the locking function for the test data. Specifically, the data management unit 410 can activate the locking function of the test data when the tag mapped to the test data is transmitted to the test execution unit 650, or when the test data is provided to the test execution unit 650.

In one embodiment, when assigning test data to be input into a test case, the electronic device 110 may additionally verify whether the locking function of the test data is activated. Specifically, the electronic device 110 may identify valid test data with the locking function not activated that is associated with the object test item corresponding to a test case, and assign any of the identified test data to a test case. For example, referring to FIG7, the electronic device 110 may execute test case 711 and may assign a valid test order 531 with the locking function not activated that is associated with the first type of test order item 422 indicated by test case 711. Electronic device 110 can input test order 531 in test case 711 and can activate the locking function of test order 531 during the execution of test case 711. Alternatively, electronic device 110 can assign test order 536 as test case 712 is executed. Electronic device 110 can activate the locking function of test order 536 during the execution of test case 712.

In one embodiment, when the execution of a test case ends, the electronic device 110 can unlock the test data. The end of test case execution includes not only successful or failed execution, but also interruption caused by a specific condition (e.g., an error) during execution. Specifically, after the execution of a test case ends, the test execution unit 650 can transmit information indicating the end of a test case to the test management unit 410. The test management unit 410 can unlock the test data upon receiving this information from the test execution unit 650. For example, referring to Figure 7, when the execution of test case 711 and test case 712 has ended, the electronic device 110 can independently unlock the locking function of test order 531 and test order 536.

Figures 8 and 9 illustrate the process by which an electronic device of one embodiment of the present invention determines the state of test data.

In one embodiment, test data related to a test item can be either non-reusable or reusable. Non-reusable test data can represent data, such as a test order, that is used in one test case and does not need to be used in other test cases. For example, data that is used in one test case and does not need to be used in other test cases can represent situations where, when the test data is used in other test cases, additional information cannot be obtained based on the execution results of the previous test cases. Conversely, reusable data can represent data such as a test account that, after being used in one test case, can be used in other test cases and additional information can be obtained based on the execution results of the other test cases.

In one embodiment, test data related to a portion of the test items among a plurality of test items may be non-reusable, while test data related to the remaining test items may be reusable. That is, the criterion for determining whether test data is reusable can be determined based on the test item to which the test data belongs.

Figure 8 primarily illustrates the situation where test data related to an object test item is non-reusable. In one embodiment, electronic device 110 can determine that test data (e.g., test orders) related to an object test item is non-reusable. Electronic device 110 can determine the validity status of test data allocated to a test case based on whether the execution of the test case corresponding to the object test item is successful.

In one embodiment, after the successful execution of a test case corresponding to an object test item, the electronic device 110 can change the status of the test data assigned to the test case from a valid state to an invalid state. After the execution of the test case ends, the electronic device 110 can change the status of the test data from a valid state to an invalid state. Specifically, the test execution unit 650 can transmit the information indicating the completion of test case execution, along with the execution result of the test case, to the test management unit 410. The test management unit 410 can change the status of the test data at the moment the test execution unit 650 receives this information. Here, successful execution of a test case can mean that the execution result obtained by inputting test data into the test case is the same as the predicted result for the test case. For example, referring to Figure 8, the electronic device 110 can execute test case 711 and assign test order 831 associated with the first type of test order item 422 to test case 711. After successful execution of test case 711, the electronic device 110 can change the status of test order 831 from a valid state (e.g., the first state) to an invalid state (e.g., the second state). In this case, the valid test data of the first type of test order item 422 in the test data pool 420 decreases. The data verification unit 440 determines at a pre-set time cycle whether the test data pool 420 contains a specific number or more of valid test data of type 1 of test order item 422. In this way, the data generation module 430 can regenerate test orders of type 1 of test order item 422 and store them in the test data pool 420.

In one embodiment, after the execution of a test case corresponding to an object test item fails, the electronic device 110 can maintain the status of the test data assigned to the test case as valid. Furthermore, even if the execution of a test case corresponding to an object test item is interrupted, the electronic device 110 can still maintain the status of the test data assigned to the test case as valid. A test case may include more than one consecutive test step. For example, if a specific test step fails during the execution of more than one test step, the test case will terminate, or all test steps may be executed until termination. In both cases, the electronic device 110 can determine that the test case execution has failed. After the test case execution ends, the device can maintain the status of the test data input into the test case as valid. For example, referring to Figure 8, the electronic device 110 can execute test case 712 and assign test order 536 related to the third type of test order item 422 to test case 712. Test case 712 may be interrupted or fail to execute during the input and execution of test order 536. After the execution of test case 712 fails or is interrupted, the electronic device 110 can maintain the status of test order 536 as valid (e.g., the first status).

Figure 9 primarily illustrates the case where test data related to an object test item is reusable. In one embodiment, electronic device 110 can determine that test data (e.g., test accounts) related to an object test item is reusable. Electronic device 110 can determine the validity status of test data assigned to a test case, independent of the execution result of the test case corresponding to the object test item.

In one embodiment, the electronic device 110 can maintain the state of the test data assigned to the test case in a valid state regardless of the execution result of the test case corresponding to the test item. For example, referring to FIG9, the electronic device 110 can execute test case 911 and can assign test account 931 associated with the first type of test account item 421 to test case 911. The electronic device 110 can maintain the state of test account 931 in a valid state (e.g., the first state) regardless of the execution result of test case 911. In other words, the electronic device 110 can adjust the locking function of test account 931 as test case 911 is executed, but can also choose not to adjust the state of test account 931. The data generation module 430 can regenerate the test account when the execution frequency of the test cases corresponding to the test account item 421 becomes high, instead of regenerating the test account related to the test account item 421 each time based on whether each test case (e.g., test case 911, test case 912) is executed. Furthermore, if the test generation module 430 finds errors in the test data related to the test account item 421 stored in the test data pool 420, or if the test data does not include the information required to execute the test cases, the data management unit 410 can delete the test data from the test data pool 420. Therefore, the test generation module 430 can also regenerate the test account.

The above embodiments illustrate the process by which the data validation unit 440 determines whether the test data pool 420 meets the pre-set conditions for the test item, thereby enabling the data generation module 430 to generate test data in advance. However, the process of generating test data is not limited to the above embodiments. In one embodiment, the data generation module 430 can also generate test data in real time. Specifically, the test execution unit 650 can execute test cases stored in the test case pool 660 and can request the data management unit 410 to allocate test data to be input into the test cases. At this time, there may not be valid test data in the test data pool 420 that can be used to execute the test case. For example, test data pool 420 may not store test data related to the test item corresponding to the test case, or even if test data pool 420 stores test data related to the test item corresponding to the test case, it may not contain test data including the data required by the test case. In this case, data generation module 430 can generate test data that can execute the test case in real time.

Furthermore, the above embodiments illustrate that the data generation module 430 generates test data without external (e.g., user) intervention, but it is not limited to this; test data can also be generated with external intervention. In one embodiment, when the test data pool does not meet the pre-set conditions for the test items of the target object, the electronic device 110 can generate a message indicating that the pre-set conditions are not met. The electronic device 110 can transmit this message to the user terminal 120. For example, the electronic device 110 can transmit this message together with an alarm message to the user terminal 120. User terminal 120 can transmit a test data generation command to electronic device 110 based on information received from electronic device 110 in order to meet pre-set conditions for the target test item. User terminal 120 can also transmit detailed information about the test data to be generated (e.g., the type of target test item) to electronic device 110 as needed. Electronic device 110 can then use data generation module 430 to generate test data related to the target test item according to the command from user terminal 120.

In one embodiment, the data generation module 430 can generate at least one set of test data related to the target test item based on various parameters. More specifically, the data generation module 430 can generate test data based on at least one of one or more parameters corresponding to the target test item embedded in the automation tool and one or more parameters input by the user for the target test item. The data generation module 430 can generate test data considering all finely configured conditions such as the characteristics of the target test item, the required verification scenarios, boundary value analysis, and error cases. Therefore, the data generation module 430 can provide a wealth of test data to simulate and verify various situations that may occur in the actual operating environment. This functionality can significantly improve the reliability of the software testing process and play an important role in identifying and resolving potential defects in advance.

The method of this invention can be implemented by a computer. The computer may include, for example, an electronic device capable of processing. In this invention, the steps of the method are shown and described in a specific order, but the steps can be performed not only sequentially, but also in any combination according to this invention. In one embodiment, at least some steps may be performed in parallel, repeatedly, or inspiredly. This invention does not preclude variations or modifications to the method. In one embodiment, at least some steps may be omitted, or other steps may be added.

Various embodiments of the present invention can be implemented as software recorded on a machine-readable recording medium. The software can be software used to implement the various embodiments of the present invention described above. Programmers in the art to which the present invention pertains can infer the software based on the various embodiments of the present invention. For example, the software can be machine-readable commands (e.g., code or code segments) or programs. A device is an apparatus capable of performing actions according to commands invoked from a recording medium, such as a computer. In one embodiment, the device can be an electronic device of an embodiment of the present invention. In one embodiment, the processor of the device executes the invoked commands, thereby enabling the components of the device to perform functions corresponding to those commands. In one embodiment, the processor may be the processor of the embodiment of the present invention. Recording medium may refer to all types of recording medium that can be read and stored by a device. Recording medium may include, for example, ROM (Read Only Memory), RAM (Random-Access Memory), CD-ROM (Compact Disc Read-Only Memory), magnetic tape, floppy disk, optical data storage device, etc. In one embodiment, the recording medium may be memory. In one embodiment, the recording medium may also be implemented in a form distributed across computer systems connected to a network. Software may be distributed and executed within computer systems, etc. Recording media can be non-transitory. Non-transitory recording media refers to media that actually exist regardless of whether the data is stored semi-permanently or temporarily, and does not include transiently transmitted signals.

The technical concept of this invention has been described above based on various embodiments. However, the technical concept of this invention includes various substitutions, variations, and modifications that can be implemented within the scope understandable to a person of ordinary skill in the art to which this invention pertains. Furthermore, it should be understood that such substitutions, variations, and modifications may be included within the scope of the appended invention claims. The embodiments of this invention can be combined with each other. The embodiments can be combined in various ways depending on the number of cases, and the combined embodiments also fall within the scope of this invention.

110: Electronic Device 120: User Terminal 200: Electronic Device 210: Processor 220: Memory 230: Communication Interface 410: Data Management Department 420: Test Data Pool 421: Test Account Item 422: Test Order Item 423: Test Store Item 430: Data Generation Module 431: Action 432: Action 433: Action 440: Data Verification Department 531: (Type 1) Test Order 532: (Type 2) Test Order 533: (Type 3) Test Order 534: (Type 1) Test Order 535: (Type 2) Test Order 536: (Type 3) Test Order 650: Test Execution Department 660: Test Case Pool 661: Test Case 1 662: Test Case 2 663: Test Case 3 711: Test Case 712: Test Case 831: Test Order 911: Test Case 912: Test Case 931: Test Account S310: Action S320: Action S330: Action

Figure 1 illustrates the environment in which an electronic device according to an embodiment of the present invention can be applied. Figure 2 is a block diagram of the electronic device according to an embodiment of the present invention. Figure 3 is a flowchart illustrating the process by which the electronic device according to an embodiment of the present invention generates and stores at least one test case related to an object test item. Figure 4 is a diagram illustrating the process by which the electronic device according to an embodiment of the present invention generates test data. Figure 5 is a diagram illustrating a method according to an embodiment of the present invention for determining whether pre-set conditions are met when there are multiple types of test data for an object test item. Figure 6 is a diagram illustrating the process by which the electronic device according to an embodiment of the present invention allocates test data to test cases. Figure 7 illustrates the process of activating the test data locking function of an electronic device according to an embodiment of the present invention. Figures 8 and 9 illustrate the process of determining the state of test data using an electronic device according to an embodiment of the present invention.

S310: Action

S320:Action

S330: Action

Claims (16)

A method for managing test data, implemented via an electronic device, includes the following steps: determining whether a test data pool storing a plurality of test data meets pre-set conditions for a test item of a target; when the test data pool does not meet the pre-set conditions, generating at least one test data related to the test item of the target; storing the generated at least one test data in the test data pool; mapping tags to each of the plurality of test data stored in the test data pool; and As a test case related to the aforementioned object test item is executed, any test data from the valid test data related to the aforementioned object test item stored in the aforementioned test data pool is allocated to the aforementioned test case, wherein the allocation includes allocating the aforementioned test data to the aforementioned test case by providing a tag mapped to the aforementioned arbitrary test data to the aforementioned test case. As in Request 1, the aforementioned pre-set conditions include: whether the aforementioned test data pool stores more than a critical number of valid test data related to the aforementioned object test items. As in Request 2, the critical number is set to be greater than or equal to the maximum number of test cases that are related to and executed simultaneously with the above-mentioned object test items. As in claim 2, the above-mentioned generation steps include the following steps: When the above-mentioned test data pool does not store more than the above-mentioned critical number of valid test data related to the above-mentioned object test item, generate test data related to the above-mentioned object test item according to the number obtained by subtracting the number of valid test data related to the above-mentioned object test item stored in the above-mentioned test data pool from the above-mentioned critical number. As in Request 1, the above-mentioned determination steps include the following steps: Determine whether the above-mentioned test data pool meets the above-mentioned pre-set conditions for the above-mentioned test items according to a pre-set time cycle. As in the method of Request 1, the above-mentioned determination steps include the following steps: When there are multiple types of test data related to the above-mentioned test items, determine whether the above-mentioned test data pool stores valid test data for each of the multiple types, which is more than the number of critical values set for each of the above-mentioned types. As in the method of claim 6, the number of critical points set for the first type of the aforementioned plurality of types is different from the number of critical points set for the second type of the aforementioned plurality of types. The method of claim 1 further includes the following steps: during the execution of the test case using the aforementioned test data, activating the locking function of the aforementioned test data; and the aforementioned test data is terminated from being allocated to other test cases after the locking function is activated until the locking function is released. The method of Request 8 further includes the following steps: when the execution of the above test case ends, unlock the locking function of any of the above test data. The method of Request 1 further includes the following steps: In the case where any of the test data related to the above-mentioned test items is non-reusable data, if the execution of the above-mentioned test case is successful, the status of the above-mentioned test data is changed from a valid state to an invalid state; if the execution of the above-mentioned test case fails, the status of the above-mentioned test data is kept in a valid state. The method of Request 1 further includes the following steps: when any of the test data related to the above-mentioned object test items is reusable data, the state of the above-mentioned test data is kept in a valid state regardless of the execution result of the above-mentioned test case. The method of claim 1 further includes the following steps: When executing another test case related to the above-mentioned object test item, if it is determined that there is no valid test data in the above-mentioned test data pool that can execute the other test case, test data that can execute the other test case is generated immediately. The method of Request 1 further includes the following steps: when the test data pool does not meet the pre-set conditions, generating information indicating that the pre-set conditions are not met. The method of claim 1, wherein the above-mentioned at least one test data is generated based on at least one of one or more parameters embedded in the automation tool corresponding to the above-mentioned object test item and one or more parameters input by the user for the above-mentioned object test item. An electronic device includes: one or more processors; and one or more memory stores commands to be executed by the one or more processors; and the electronic device is configured such that, when executing the commands, the one or more processors perform a method of executing any one of requests 1 to 14. A non-temporary computer-readable recording medium that records commands that, when executed by one or more processors, cause the one or more processors to perform actions, is configured in such a way as to provide a method by which the commands cause the one or more processors to perform any one of requests 1 to 14.