Test scenario execution support system, test scenario execution support method, and test scenario execution support program

Abstract

To provide a test scenario execution support system, a test scenario execution support method, and a test scenario execution support program that can avoid the duplication of the same test scenario used in a plurality of execution settings and can obtain a list of test scenarios that match a purpose with a simple operation. [Solution] A test scenario execution support system equipped with a control unit, in which an automatic operation means of an application executes a test scenario, is capable of accessing a tag information table, a scenario management table, and an execution setting table, and the automatic operation means acquires the tag ID of the tag to be executed from the tag information table and the execution setting table based on the tag name specified in the execution setting instruction, or acquires the tag ID to be executed from the execution setting table based on the execution setting ID specified in regular automatic execution, and extracts and executes the test scenario having the tag ID from the scenario management table.

Description

[Technical Field]

[0001] The present invention relates to a test scenario execution support system, a test scenario execution support method, and a test scenario execution support program. [Background technology]

[0002] In recent years, low-code development tools have been attracting attention as tools that allow for easy application development. Furthermore, the use of low-code development tools is now expanding into mission-critical enterprise systems. Under these circumstances, a system for maintaining the quality of applications created with low-code development tools is becoming essential. Regression testing using RPA (Robotic Process Automation) has been attracting attention as a means for achieving this. Conventionally, a system for creating application operation scenarios is known, for example, from Patent Document 1. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Patent Publication No. 2021-9605 Summary of the Invention [Problem to be solved by the invention]

[0004] However, there are a wide variety of test scenarios for a large number of applications such as ERP (Enterprise Resources Planning), and even if the test scenarios executed by RPA are the same, it is necessary to create test scenarios for each setting pattern to be executed, or to deploy execution scenarios.In addition, while it is possible to manage a large number of test scenarios by grouping them, it is difficult to group and manage the required test scenario units.

[0005] The present invention has been made in consideration of the above, and aims to provide a test scenario execution support system, a test scenario execution support method, and a test scenario execution support program that can avoid creating duplicate test scenarios to be used in multiple execution settings by assigning tags set based on the purpose of the test to test scenarios executed by automatic operation means, and that can obtain a list of test scenarios that match the purpose with a simple operation. [Means for solving the problem]

[0006] In order to solve the above-mentioned problems and achieve the object, the present invention provides a test scenario execution support system that includes a control unit and in which an automatic operation means of an application executes a test scenario, and that has access to a tag information table that registers tag names set based on the purpose of the test in association with tag IDs, a scenario management table that includes the scenario CD of the test scenario, the tag ID, and scenario setting information, and an execution setting table that includes the execution setting ID and the tag ID, and the automatic operation means obtains the tag ID of the tag to be executed from the tag information table and the execution setting table based on the tag name specified in the execution setting instruction from the tester or scenario creator, or obtains the tag ID to be executed from the execution setting table based on the execution setting ID specified in the regular automatic execution, and extracts and executes the test scenario having the tag ID from the scenario management table.

[0007] The test scenario execution support system according to the present invention is characterized by comprising a tag creation means for accepting registration of the tag inputted on the tag creation screen and storing it in the tag information table.

[0008] Furthermore, the test scenario execution support system according to the present invention is characterized by comprising a scenario creation means for creating a test scenario in response to the scenario creator's operations on a scenario creation screen, obtaining the tag ID of the tag assigned to the created test scenario from the tag information table, and storing it together with the created test scenario in the scenario management table.

[0009] The test scenario execution support system according to the present invention is also characterized by comprising an execution setting table creation means for registering, via an execution setting screen, the setting of one or more tags that extract the test scenarios to be executed, or an execution pattern that extracts all test scenarios.

[0010] The test scenario execution support system according to the present invention is also characterized in that the tags can be collectively added or deleted for all test scenarios on a collective tagging screen.

[0011] Furthermore, the test scenario execution support method according to the present invention is a test scenario execution support method executed by a test scenario execution support system that has a control unit and in which automatic operation means of an application executes test scenarios, and is capable of accessing a tag information table that registers tag names set for the purpose of testing in association with tag IDs, a scenario management table that includes the scenario CD of the test scenario, the tag ID, and scenario setting information, and an execution setting table that includes the execution setting ID and the tag ID, and is characterized in that it includes a step of obtaining the tag ID of a tag to be executed from the tag information table and the execution setting table based on a tag name specified in an execution setting instruction from a tester or scenario creator, or obtaining the tag ID to be executed from the execution setting table based on the execution setting ID specified in periodic automatic execution, and extracting and executing a test scenario having the tag ID from the scenario management table.

[0012] Furthermore, the test scenario execution support program of the present invention is a test scenario execution support program that has a control unit and is executed by a test scenario execution support system in which automatic operation means of an application executes test scenarios, and that has access to a tag information table that registers tag names set for the purpose of testing in association with tag IDs, a scenario management table that includes the scenario CD of the test scenario, the tag ID, and scenario setting information, and an execution setting table that includes the execution setting ID and the tag ID, and is characterized in that the automatic operation means obtains the tag ID of the tag to be executed from the tag information table and the execution setting table based on the tag name specified in an execution setting instruction from the tester or scenario creator, or obtains the tag ID to be executed from the execution setting table based on the execution setting ID specified in periodic automatic execution, and extracts and executes the test scenario having the tag ID from the scenario management table. [Effects of the Invention]

[0013] According to the present invention, it is possible to avoid creating the same test scenario twice to be used in a plurality of execution settings, and to obtain a list of test scenarios that match a purpose with a simple operation. [Brief explanation of the drawings]

[0014] [Figure 1] FIG. 1 is a block diagram showing an example of the configuration of a test scenario execution support system according to this embodiment. [Figure 2A] FIG. 2A is a diagram for explaining an overall execution image of the test scenario execution support system according to this embodiment. [Figure 2B] FIG. 2B is a diagram for explaining an overall execution image of the test scenario execution support system according to this embodiment. [Figure 3] FIG. 3 is a diagram illustrating an example of the tag setting information table. [Figure 4] FIG. 4 is a diagram illustrating an example of the tag information table. [Figure 5]FIG. 5 is a diagram showing an example of a scenario creation screen. [Figure 6] FIG. 6 is a diagram illustrating an example of the scenario management table. [Figure 7] FIG. 7 is a diagram showing an example of the execution setting screen. [Figure 8] FIG. 8 is a diagram illustrating an example of the execution setting table. [Figure 9] FIG. 9 is a diagram showing the relationship between the execution setting screen and the execution setting table. [Figure 10] FIG. 10 is a diagram showing an example of an execution pattern by the automatic operation unit. [Figure 11] FIG. 11 is a diagram showing an example of an execution pattern by the automatic operation unit. [Figure 12] FIG. 12 is a diagram showing an example of an execution pattern by the automatic operation unit. [Figure 13] FIG. 13 is a diagram showing an example of an execution pattern by the automatic operation unit. [Figure 14] FIG. 14 is a diagram illustrating batch tagging. [Figure 15] FIG. 15 is a diagram illustrating batch tag deletion. DETAILED DESCRIPTION OF THE INVENTION

[0015] Hereinafter, embodiments of a test scenario execution support system, a test scenario execution support method, and a test scenario execution support program according to the present invention will be described in detail with reference to the accompanying drawings. However, the present invention is not limited to these embodiments.

[0016] [1. Configuration] An example of the configuration of a test scenario execution support system 100 according to this embodiment will be described with reference to FIG. 1. The test scenario execution support system 100 can be configured, for example, on a low-code platform. It may also be configured on a no-code platform. FIG. 1 is a block diagram showing an example of the configuration of the test scenario execution support system 100. The test scenario execution support system 100 is a system for executing test scenarios used by scenario creators and testers. A tester here is a person who checks the operation of applications stored in the test scenario execution support system 100. In addition to being executed by scenario creators and testers, test scenarios can also be executed automatically on a regular basis by the system (automatic execution programs executed by an automatic operation unit, which will be described later).

[0017] The test scenario execution support system 100 may be a stationary information processing system such as a workstation or a desktop personal computer, or an information processing system such as a commercially available notebook personal computer.

[0018] The test scenario execution support system 100 comprises a control unit 102, a communication interface unit 104, a storage unit 106, and an input / output interface unit 108. Each unit of the test scenario execution support system 100 is connected to each other so that they can communicate with each other via any communication path.

[0019] The communication interface unit 104 communicatively connects the test scenario execution support system 100 to a network 300 via a communication system such as a router and a wired or wireless communication line such as a dedicated line. The communication interface unit 104 has a function for exchanging data with other devices via the communication line. Here, the network 300 has a function for communicatively connecting the test scenario execution support system 100 to other devices such as terminals (with browsers) used by scenario creators and testers (not shown) and a server 200, and is, for example, the Internet or a LAN (Local Area Network). Note that the development application DB 106a, automatic operation unit 102a, and application 102e (described later) may be installed in other systems.

[0020] An input device 112 and an output device 114 are connected to the input / output interface unit 108. The output device 114 may be a monitor (including a home television), a speaker, or a printer. The input device 112 may be a keyboard, a mouse, a microphone, or a monitor that cooperates with a mouse to achieve a pointing device function. In the following, the output device 114 may be referred to as the monitor 114, and the input device 112 may be referred to as the keyboard 112 or the mouse 112.

[0021] Various databases, tables, files, etc. are stored in the storage unit 106. Computer programs that work in conjunction with an OS (Operating System) to issue commands to a CPU (Central Processing Unit) to perform various processes are recorded in the storage unit 106. The storage unit 106 can be, for example, a memory system such as RAM (Random Access Memory) or ROM (Read Only Memory), a fixed disk system such as a hard disk, a flexible disk, an optical disk, etc.

[0022] The storage unit 106 includes a development application DB 106a, etc. The development application DB 106a is a database for development that stores a tag information table 106b, a scenario management table 106c, an execution setting table 106d, etc.

[0023] The tag information table 106b registers tag names set based on the purpose of the test and tag IDs in association with each other. As shown in an example in Fig. 4, the tag information table 106b registers tag IDs automatically assigned by the test scenario execution support system 100 in association with tag names. Here, the tag name is a name set based on the purpose and perspective of the test. For example, tag names are set according to the test execution frequency (daily, monthly, as needed, etc.), the type of application to be tested (master maintenance, master list, etc.), the purpose of regression testing (unit testing, scenario testing, batch non-impact testing after program modification or environment change, etc.), the scope of testers (developer, tester, periodic automatic execution by the system, etc.), and differences by stage (initial development, pre-delivery, post-operation, etc.).

[0024] Here, the "daily" tag for the execution frequency is intended to be executed regularly, about once a day; "monthly" is intended to be executed regularly, about once a month; and "as needed" is intended to be executed as needed. Also, "early development" is intended to be tested at the beginning of a development project; "pre-delivery" is intended to be tested before the application is delivered to the customer; and "post-go-live" is intended to be tested when the application has been delivered to the customer and they have begun to use it. "Master maintenance" is intended to be tested for an application that registers master data; and "master list" is intended to be tested for an application that checks the data registered in master maintenance in a report.

[0025] The scenario management table 106c includes the scenario CD, tag ID, and scenario setting information of the test scenario. As shown in an example in FIG. 6, the scenario management table 106c stores the scenario CD, tag information (tag ID), and scenario setting information, such as the start RPA operation key, RPA operation key, operation type, screen type, target, and operation key list, for each test scenario. The start RPA operation key is a list of RPA operation keys that start the test scenario. Furthermore, the operation type is a classification of RPA operations. Representative RPA operations include "launch screen," "operate screen," "operate basic page," "operate system-wide search dialog," "pause," and "screenshot." The RPA key list is a list of RPA operation keys operated on the corresponding screen (the active screen at execution time).

[0026] The execution setting table 106d includes an execution setting ID and the tag ID. As shown in an example in Fig. 8, the execution setting table 106d stores an execution setting ID automatically assigned to the test scenario execution support system 100, a setting name (execution setting name), and a tag ID as execution setting information. The execution setting table 106d-1 in Fig. 8 is an execution setting table for "daily regression testing," while the execution setting table 106d-2 is also for "daily regression testing," but excludes test scenarios tagged as "unexecutable." Fig. 8 illustrates an execution setting table in which execution target scenarios are specified by tags, but an execution setting table in which execution target scenarios are all scenarios can also be registered as the execution setting table 106d.

[0027] The control unit 102 is a CPU or the like that performs overall control of the test scenario execution support system 100. The control unit 102 has an internal memory for storing control programs such as an OS, programs that define various processing procedures, required data, etc., and executes various information processing operations based on these stored programs.

[0028] The control unit 102 conceptually includes an automatic operation unit 102a, a tag creation unit 102b, a scenario creation unit 102c, an execution setting table creation unit 102d, an application 102e, and the like.

[0029] The automatic operation unit 102a executes automatic operations on the application 102e in accordance with the test scenario registered in the scenario management table 106c. The automatic operation unit 102a is, for example, an RPA execution program. Here, the RPA execution program is a program that operates the screen of an application provided by the low-code development platform and is the subject that performs the operations in the automatic regression test. Furthermore, the test scenario is a test scenario that is set so that the RPA execution program can operate the screen of the application provided by the low-code development platform according to the expected operating procedures.

[0030] Specifically, the automatic operation unit 102a obtains the tag ID to be executed from the execution setting table 106d or the tag information table 106b based on the execution instruction from the tester or scenario creator, or the tag name or execution setting ID instructed in regular automatic execution, extracts the test scenario having the instructed tag ID from the scenario management table 106c, and executes it.

[0031] The tag creating unit 102b accepts registration of a tag (name) input on a tag creating screen (to be described later), and stores it together with the tag ID in the tag information table 106b.

[0032] The scenario creation unit 102c creates a test scenario in response to the scenario creator's operations on the scenario creation screen described below, obtains the tag ID of the tag assigned to the created test scenario from the tag information table 106b, and stores it in the scenario management table 106c.

[0033] The execution setting table creating unit 102d registers, via an execution setting screen described later, an execution setting table 106d that sets one or more tags for extracting test scenarios to be executed, or that is an execution pattern for extracting all test scenarios.

[0034] The application 102e is, for example, one or more business applications. The applications are stored in the storage unit 106, and the applications stored in the storage unit 106 and executed by the control unit 102 are expressed functionally as the application 102e of the control unit 102.

[0035] [2. Processing] A specific example of the processing of the test scenario execution support system 100 according to this embodiment will be described with reference to Fig. 2 to Fig. 15. In the following description, the automatic operation unit 102a is an RPA execution program.

[0036] 2A and 2B are diagrams for explaining an overall execution image of the test scenario execution support system according to this embodiment. As shown in Fig. 2(A), in the test scenario execution support system 100 according to this embodiment, test scenarios created on the scenario creation screen MA are stored in a scenario management table 106c in the development application DB 106a together with tags (tag IDs acquired from the tag information table 106b) assigned in the tag selection field on the scenario creation screen MA. Furthermore, tag information in which one or more tags for extracting test scenarios to be executed are set on the execution setting screen MB is stored in the development application DB 106a as an execution setting table 106d.

[0037] In the test scenario execution support system 100, once tags are assigned to test scenarios and the execution setting table 106d, which is the execution pattern for the test scenarios, is registered, test scenarios are extracted and executed via two routes, as shown in FIG. 2(B). When an execution setting is instructed by a tester or scenario creator, the RPA execution program (automatic operation unit 102a) acquires the tag ID of the tag to be executed from the tag information table 106b and the execution setting table 106d based on the execution setting name instructed for the execution setting, extracts the test scenario to which the acquired tag ID is assigned, and executes it. In addition, in the case of daily batch or periodic automatic execution by a tester, the RPA execution program (automatic operation unit 102a) acquires the tag ID to be executed from the execution setting table 106d based on the instructed execution setting ID, extracts the test scenario having the acquired tag ID from the scenario management table 106c, and executes it.

[0038] (1) Tag registration Tags to be assigned to test scenarios are registered on a tag creation screen MB, an example of which is shown in Fig. 3. When a user inputs a tag name into the tag creation screen MB and presses the "Register" button, the tag creation unit 102b accepts the registration of the tag (name) and stores it in the tag information table 106b together with an automatically assigned tag ID. Fig. 4 shows an example of the tag information table 106b. For example, the tag name "Daily" is a tag intended for regular execution about once a day, "Monthly" is a tag intended for regular execution about once a month, "Master Maintenance" is a tag intended for testing an application that registers master data, "Master List" is a tag intended for testing an application that checks data registered in master maintenance using a report, and "Not Executable" is a tag assigned when a problem occurs in a test scenario and the scenario is temporarily excluded because it will take time to correct the module.

[0039] (2) Scenario creation Test scenarios are created using a scenario creation screen MA, an example of which is shown in Figure 5. The scenario creation screen includes a scenario CD, a setting field for the scenario name, a tag selection field, and a scenario setting area. Although not shown, the scenario setting area can be switched between displaying and viewing the scenario execution area, which executes the test scenario.

[0040] When the scenario creator specifies the scenario CD and scenario name on the scenario creation screen MA, selects the operation target (control) in the scenario setting area, and selects the operation, a test scenario corresponding to the operation content is created. Also, by assigning the required tag from a list of all tags registered in the tag information table 106b in the tag selection field, the test scenario to which the tag is assigned is registered in the scenario management table 106c of the development application DB 106a. On the scenario creation screen MA shown in Figure 5, the tags "Daily" and "Master Maintenance" are assigned to the test scenario with the scenario CD "S-01-001-0010" and the scenario name "Does new customer registration (new) work?"

[0041] FIG. 6 shows an example of the scenario management table 106c. The scenario management table 106c is configured with a scenario CD, a scenario name, tag information, and scenario setting information (start RPA operation key, RPA operation). The scenario management table 106c shown in FIG. 6 contains the following: scenario CD "S-01-001-0010," scenario name "Is the registration of Customer Master Maintenance (New) correct?", tag information "T-01 (Daily)," "T-03 (Master Maintenance)," RPA operation start key "A1," RPA operation "RPA operation key: A1, operation type: launch screen, screen type: low-code platform, target: Customer Master Maintenance (list), RPA operation key list: A11, A12, A13, B1, A14," and so on. The scenario creation unit 102c obtains the tag ID of the tag assigned to the test scenario on the scenario creation screen MA from the tag information table 106b and stores it in the scenario management table 106c.

[0042] (3) Registering execution setting patterns FIG. 7 shows an example of an execution setting screen MC. (A) shows an example of an execution setting pattern without an exclusion setting, and (B) shows an example with an exclusion setting. The execution setting screen MC allows you to set the execution setting name, the target scenario to be executed, tag selection, and the scenario to be excluded. The execution setting screen MC-1 shows the execution setting name "For daily regression testing," the target scenario to be executed "Tag specification," the tag selection "Daily," and the scenario to be excluded "- (None)." The execution setting screen MC-2 is the same as the execution setting screen MC-1, with the execution setting name "For daily regression testing," the target scenario to be executed "Tag specification," and the tag selection "Daily." It differs in that the excluded scenario "Not executable" is selected. "Not executable" is a tag assigned when a test scenario has a problem and it takes time to fix the module, so the scenario is temporarily excluded. Test scenarios assigned the selected "Daily" tag, but further assigned the "Not executable" tag, are excluded from the test. In the execution setting screens MC-1 and MC-2, only one tag is selected in the tag selection, but it is also possible to select two or more tags.

[0043] When an execution pattern is registered in the execution setting screen MC, an execution setting table 106d, an example of which is shown in Fig. 8, is registered. The execution setting table 106d includes an execution setting ID, setting name, tag ID, etc., and holds information for executing a test scenario as an execution setting. The execution setting table 106d-1 corresponds to the execution setting screen MC-1 in Fig. 7, and the execution setting table 106d-2 corresponds to the execution setting screen MC-2. Fig. 9 is a diagram showing the correspondence between the execution setting screens and the execution setting information. A plurality of execution setting patterns are registered in the development application DB 106a, and when issuing an instruction for regular automatic execution to the RPA execution program (automatic operation unit 102a), the execution setting pattern to be used is specified by specifying the execution setting ID.

[0044] (4) Test scenario execution process 10 to 13 are diagrams showing examples of execution patterns by the automatic operation unit. The flow of processing in which the RPA execution program (automatic operation unit 102a) executes a test scenario based on the execution setting pattern set on the execution setting screen will be explained for each execution setting pattern.

[0045] FIG. 10 shows an example of execution processing based on an execution setting table with "daily" set as the tag. When an execution instruction is given by a user or an execution instruction is given by periodic automatic execution, the RPA execution program (automatic operation unit 102a) obtains the setting information to be executed from the execution setting table of the development application DB 106a. The RPA execution program (automatic operation unit 102a) determines whether the type of the execution setting table for the specified execution pattern is tag specified. If it is not tag specified, it obtains all test scenarios registered in the scenario management table. In this example, since tag specification is given and "T-01 (daily)" is specified, it obtains the test scenario assigned to "T-01" from the scenario management table.

[0046] The scenario management table in Figure 10 stores five test scenarios: scenario CDs "S-01-001-0010" to "S-01-005-0010." The tag for scenario CD "S-01-001-0010" is "T-01," the tag for scenario CD "S-01-002-0010" is "T-02," the tag for scenario CD "S-01-003-0010" is "T-02," the tag for scenario CD "S-01-004-0010" is "T-01," and the tag for scenario CD "S-01-005-0010" is "T-01." Among these test scenarios, the RPA execution program (automatic operation unit 102a) acquires "S-01-001-0010," "S-01-004-0010," and "S-01-005-0010," which have the tag "T-01."

[0047] After acquiring the test scenarios to which the specified tags are assigned, the RPA execution program (automatic operation unit 102a) determines whether any scenarios to be excluded are set in the execution setting table. If so, the RPA execution program (automatic operation unit 102a) executes tests on the test scenarios excluding the scenarios to be excluded. In this example, no scenarios to be excluded are set, so the RPA execution program (automatic operation unit 102a) executes tests on the acquired "S-01-001-0010," "S-01-004-0010," and "S-01-005-0010."

[0048] FIG. 11 shows an example of execution processing based on an execution setting table in which "master maintenance" and "master list" are selected as tags. When an execution instruction is given by a user or an execution instruction is given by regular automatic execution, the RPA execution program (automatic operation unit 102a) obtains the setting information to be executed from the execution setting table of the development application DB 106a. The RPA execution program (automatic operation unit 102a) determines whether the type of the execution setting table for the specified execution pattern is tag specified. If it is not tag specified, it obtains all test scenarios registered in the scenario management table. In this example, since tag specification is used and "T-03 (master maintenance)" and "T-04 (master list)" are specified, it obtains test scenarios assigned to "T-03" and "T-04" from the scenario management table.

[0049] The scenario management table in Figure 11 stores five test scenarios: scenario CDs "S-01-001-0010" to "S-01-005-0010." The tags for scenario CD "S-01-001-0010" are "T-01" and "T-03," the tags for scenario CD "S-01-002-0010" are "T-02" and "T-03," the tags for scenario CD "S-01-003-0010" are "T-02" and "T-05," the tags for scenario CD "S-01-004-0010" are "T-01" and "T-05," and the tags for scenario CD "S-01-005-0010" are "T-01" and "T-04." Among these, the RPA execution program (automatic operation unit 102a) acquires "S-01-001-0010," "S-01-002-0010," and "S-01-005-0010," whose tags are "T-03" or "T-04."

[0050] After acquiring the test scenarios to which the specified tags are assigned, the RPA execution program (automatic operation unit 102a) determines whether any scenarios to be excluded are set in the execution setting table. If so, the RPA execution program (automatic operation unit 102a) executes tests on the test scenarios excluding the scenarios to be excluded. In this example, no scenarios to be excluded are set, so the RPA execution program (automatic operation unit 102a) executes tests on the acquired "S-01-001-0010," "S-01-002-0010," and "S-01-005-0010."

[0051] FIG. 12 shows an example of execution processing based on an execution setting table in which "daily" is selected as the tag and "unexecutable" is set as the scenario to be excluded. When an execution instruction is given by the user or an execution instruction is given by regular automatic execution, the RPA execution program (automatic operation unit 102a) obtains the setting information to be executed from the execution setting table of the development application DB 106a. The RPA execution program (automatic operation unit 102a) determines whether the type of the execution setting table for the specified execution pattern is tag specified. If it is not tag specified, it obtains all test scenarios registered in the scenario management table. In this example, tag specification is given and "T-01 (daily)" is specified, so it obtains the test scenario assigned to "T-01" from the scenario management table.

[0052] The scenario management table in Figure 12 stores five test scenarios: scenario CDs "S-01-001-0010" to "S-01-005-0010." The tags for scenario CD "S-01-001-0010" are "T-01" and "T-11," the tag for scenario CD "S-01-002-0010" is "T-02," the tag for scenario CD "S-01-003-0010" is "T-02," the tag for scenario CD "S-01-004-0010" is "T-01," and the tags for scenario CD "S-01-005-0010" are "T-01" and "T-11." Among these, the RPA execution program (automatic operation unit 102a) acquires "S-01-001-0010," "S-01-004-0010," and "S-01-005-0010," which have the tag "T-01."

[0053] After acquiring the test scenario to which the specified tag is assigned, the RPA execution program (automatic operation unit 102a) determines whether any scenarios to be excluded are set in the execution setting table. If so, the RPA execution program (automatic operation unit 102a) executes tests on the test scenarios excluding the scenarios to be excluded. In this example, the tag "T-11" of the scenario to be excluded is set, so the RPA execution program (automatic operation unit 102a) excludes "S-01-001-0010" and "S-01-005-0010" to which "T-11" is attached, and executes tests on "S-01-004-0010."

[0054] FIG. 13 shows an example of execution processing based on an execution setting table in which the target of the scenario to be executed is set to "all" and the scenario to be excluded is set to "unexecutable." When an execution instruction is given by the user or an execution instruction is given by regular automatic execution, the RPA execution program (automatic operation unit 102a) obtains the setting information to be executed from the execution setting table of the development application DB 106a. The RPA execution program (automatic operation unit 102a) determines whether the type of the execution setting table for the specified execution pattern is tag specified. In this example, since it is not tag specified, all test scenarios registered in the scenario management table are obtained.

[0055] The scenario management table in FIG. 13 stores five test scenarios, scenario CDs "S-01-001-0010" to "S-01-005-0010," and the RPA execution program (automatic operation unit 102a) acquires all of the test scenarios.

[0056] After acquiring the test scenario to which the specified tag is assigned, the RPA execution program (automatic operation unit 102a) determines whether any scenarios to be excluded are set in the execution setting table. If so, the RPA execution program (automatic operation unit 102a) executes tests on the test scenarios excluding the scenarios to be excluded. In this example, the tag "T-11" of the scenario to be excluded is set, so the RPA execution program (automatic operation unit 102a) excludes "S-01-001-0010" and "S-01-005-0010" to which "T-11" is attached, and executes tests on "S-01-002-0010," "S-01-003-0010," "S-01-004-0010," and "S-01-006-0010."

[0057] (5) Bulk tag setting and bulk deletion In the test scenario execution support system 100, a batch tagging screen allows batch tagging or batch tag deletion for all test scenarios.

[0058] FIG. 14 is a diagram explaining bulk tagging. The bulk tagging screen MD-1 shown in FIG. 14 displays the titles, tags, last updater, and modification date and time of all test scenarios registered in the scenario management table 106c. Selecting the test scenario you want to select from the test scenarios with "Ctrl+Click" and pressing the "Change Tag" button, and then selecting the tag you want to add in the tag change field d1 that appears, allows you to assign tags all at once. The selection list d2 in the tag change field d1 displays all tags registered in the tag information table 106b, from which you can select the tag you want to tag all at once. On the bulk tagging screen MD-1, scenarios A and E are selected from among the scenarios A to E displayed on the screen, and as shown in the bulk tagging screen MD-2, the selected scenarios A and E are tagged with the tag "Not executable" all at once.

[0059] Figure 15 is a diagram explaining bulk tag deletion. The bulk tagging screen MD-1 shown in Figure 15 displays the titles, tags, last updater, and modification date and time of all test scenarios registered in the scenario management table 106c. Tags can be deleted in bulk by selecting the test scenario you want to select from the test scenarios using "Ctrl+Click," pressing the "Change Tag" button, and then selecting the tag you want to delete in the tag change field d3 that appears. On the bulk tagging screen MD-1, scenarios A and E are selected from scenarios A to E displayed on the screen, and as shown in bulk tagging screen MD-3, the "Not executable" tag has been deleted from the selected scenarios A and E in bulk.

[0060] As described above, according to this embodiment, by assigning multiple tags to one test scenario, it is possible to eliminate the need to prepare and arrange multiple identical test scenarios. Furthermore, by assigning tags, which indicate flexible granularity, concepts, and purposes, to test scenarios executed by the automatic operation unit 102a according to their properties, a list of test scenarios that match the purpose can be obtained with simple operations at any time, enabling efficient batch execution of test scenarios without omission. Furthermore, if there is a scenario that you want to exclude from the created test scenarios, adding an exclusion tag can reduce the effort required to delete the test scenario or create an execution setting that excludes the test scenario. Furthermore, by batch tagging or batch tag deletion, tags can be easily added and removed.

[0061] [3. Contribution to the United Nations-led Sustainable Development Goals (SDGs)] This embodiment can contribute to improving business efficiency and promoting appropriate management decisions by companies, thereby contributing to the achievement of SDGs Goals 8 and 9.

[0062] Furthermore, this embodiment can contribute to reducing waste and promoting paperless and electronic systems, thereby contributing to the achievement of SDGs Goals 12, 13, and 15.

[0063] Furthermore, this embodiment can contribute to strengthening control and governance, which can contribute to the achievement of Goal 16 of the SDGs.

[0064] 4. Other Embodiments The present invention may be implemented in various different embodiments other than those described above within the scope of the technical concept set forth in the claims.

[0065] For example, among the processes described in the embodiments, all or part of the processes described as being performed automatically can be performed manually, or all or part of the processes described as being performed manually can be performed automatically using known methods.

[0066] Furthermore, the processing procedures, control procedures, specific names, information including parameters such as registered data and search conditions for each process, screen examples, and database configurations shown in this specification and drawings can be changed as desired unless otherwise specified.

[0067] Furthermore, with regard to the test scenario execution support system 100, the components shown in the figures are functional concepts, and do not necessarily have to be physically configured as shown in the figures.

[0068] For example, all or any part of the processing functions of the test scenario execution support system 100, particularly the processing functions performed by the control unit, may be implemented by a CPU and a program interpreted and executed by the CPU, or may be implemented as hardware using wired logic. The program is recorded on a non-transitory, computer-readable recording medium containing programmed instructions for causing the information processing system to execute the processes described in this embodiment, and is mechanically read by the test scenario execution support system 100 as needed. That is, a computer program for issuing instructions to the CPU in cooperation with the OS and performing various processes is recorded in a storage unit such as a ROM or HDD (Hard Disk Drive). This computer program is executed by being loaded into RAM, and cooperates with the CPU to form the control unit.

[0069] In addition, this computer program may be stored in an application program server connected to the test scenario execution support system 100 via any network, and it is also possible to download all or part of it as needed.

[0070] Furthermore, the program for executing the processes described in this embodiment may be stored in a non-transitory computer-readable recording medium or configured as a program product. Here, the term "recording medium" includes any "portable physical medium" such as a memory card, a Universal Serial Bus (USB) memory, a Secure Digital (SD) card, a flexible disk, a magneto-optical disk, a ROM, an Erasable Programmable Read Only Memory (EPROM), an Electrically Erasable and Programmable Read Only Memory (EEPROM (registered trademark)), a Compact Disk Read Only Memory (CD-ROM), a Magneto-Optical disk (MO), a Digital Versatile Disk (DVD), and a Blu-ray (registered trademark) disc.

[0071] Furthermore, a "program" is a data processing method written in any language or description method, regardless of the format, such as source code or binary code. Note that a "program" is not necessarily limited to a single program, but also includes programs that are distributed as multiple modules or libraries, or programs that achieve their functions by cooperating with other programs, such as an OS. Note that well-known configurations and procedures can be used for the specific configurations and reading procedures for reading a recording medium in each system described in the embodiments, as well as installation procedures after reading.

[0072] The various databases stored in the memory unit are storage means such as memory systems such as RAM and ROM, fixed disk systems such as hard disks, flexible disks, and optical disks, and store various programs, tables, databases, and web page files used for various processes and providing websites.

[0073] The test scenario execution support system 100 may be configured as an information processing system such as a known personal computer or workstation, or may be configured as an information processing system connected to any peripheral system. The test scenario execution support system 100 may also be realized by installing software (including programs, data, etc.) that causes the system to perform the processing described in this embodiment.

[0074] Furthermore, the specific form of distribution and integration of the system is not limited to that shown in the drawings, and all or part of the system can be configured by functionally or physically distributing and integrating in any unit according to various additions or functional loads. In other words, the above-described embodiments can be implemented in any combination, or embodiments can be implemented selectively. [Industrial Applicability]

[0075] The present invention can be used in all business sectors and industries. [Explanation of symbols]

[0076] 100 Test Scenario Execution Support System 102 Control section 102a Automatic operation section 102b Tag Creation Section 102c Scenario Creation Department 102d Execution setting table creation section 102e Applications 104 Communication interface unit 106 Storage section 106a Development application database 106b Tag information table 106c Scenario Management Table 106d Execution Settings Table 108 Input / Output Interface Section 112 Input Device 114 Output Device 200 servers 300 Network

Claims

1. A test scenario execution support system including a control unit, in which an automatic operation means for an application executes a test scenario, a tag information table that associates and registers tag names set for the purpose of testing with tag IDs; a scenario management table including a scenario CD of the test scenario, the tag ID, and scenario setting information; an execution setting table including an execution setting ID and the tag ID; is accessible to The automatic operation means acquires the tag ID of the tag to be executed from the tag information table and the execution setting table based on the tag name specified in the execution setting instruction from the tester or scenario creator, or acquires the tag ID to be executed from the execution setting table based on the execution setting ID instructed for regular automatic execution, extracts the test scenario having the tag ID from the scenario management table, and executes it.

2. a tag creation means for accepting registration of the tag inputted on the tag creation screen and storing the same in the tag information table; 2. The test scenario execution support system according to claim 1, further comprising:

3. a scenario creation means for creating a test scenario in accordance with an operation by a scenario creator on a scenario creation screen, acquiring a tag ID of a tag assigned to the created test scenario from the tag information table, and storing the tag ID together with the created test scenario in the scenario management table; 2. The test scenario execution support system according to claim 1, further comprising:

4. an execution setting table creation means for registering, via an execution setting screen, the setting of one or more tags for extracting the test scenarios to be executed, or an execution pattern for extracting all test scenarios; 2. The test scenario execution support system according to claim 1, further comprising:

5. 2. The test scenario execution support system according to claim 1, wherein a batch tagging screen is used to batch tag or batch delete tags for all test scenarios.

6. A test scenario execution support method executed by a test scenario execution support system including a control unit, wherein an automatic operation means for an application executes a test scenario, the method comprising: a tag information table that associates and registers tag names set for the purpose of testing with tag IDs; a scenario management table including a scenario CD of the test scenario, the tag ID, and scenario setting information; an execution setting table including an execution setting ID and the tag ID; is accessible to Executed in the automatic operation means, a step of acquiring a tag ID of a tag to be executed from the tag information table and the execution setting table based on a tag name specified in an execution setting instruction from a tester or a scenario creator, or acquiring the tag ID to be executed from the execution setting table based on an execution setting ID specified in periodic automatic execution, extracting a test scenario having the tag ID from the scenario management table, and executing the test scenario; A test scenario execution support method comprising:

7. A test scenario execution support program executed by a test scenario execution support system including a control unit and an automatic operation means for an application that executes a test scenario, a tag information table that associates and registers tag names set for the purpose of testing with tag IDs; a scenario management table including a scenario CD of the test scenario, the tag ID, and scenario setting information; an execution setting table including an execution setting ID and the tag ID; is accessible to The automatic operation means A test scenario execution support program that obtains the tag ID of a tag to be executed from the tag information table and the execution setting table based on a tag name specified in an execution setting instruction from a tester or scenario creator, or obtains the tag ID to be executed from the execution setting table based on an execution setting ID instructed for regular automatic execution, extracts a test scenario having the tag ID from the scenario management table, and executes it.

Images