Test preparation efficiency improvement device, test preparation efficiency improvement method, and test preparation efficiency improvement program
The test preparation efficiency improvement device automates the creation of definition and screen operation command tables from test scenario data, addressing inefficiencies in manual table creation and standardizing test preparations, thereby enhancing software testing efficiency.
Patent Information
- Application Number
- JP2022097562
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Filing Date
- 2022-06-16
- Publication Date
- 2025-11-12
- Estimated Expiration
- 2042-06-16
AI Technical Summary
Existing software testing methods require inefficient manual creation of definition management tables and screen operation command tables, leading to non-standardized test preparations and increased workload.
A test preparation efficiency improvement device that generates definition management and screen operation command tables based on test scenario data in tabular text format, automating the process and standardizing test preparations.
Streamlines and standardizes test preparation by automating the generation of necessary tables, reducing manual effort and ensuring consistent test execution.
Smart Images

Figure 0007768844000001 
Figure 0007768844000002 
Figure 0007768844000003
Abstract
Description
[Technical Field]
[0001] The present invention relates to a test preparation efficiency improvement device, a test preparation efficiency improvement method, and a test preparation efficiency improvement program. [Background technology]
[0002] Patent Document 1 discloses a software business process testing simplification device that aims to simplify the software operation and program implementation work of testers and reduce the amount of testing work by enabling unit testing of business process methods in the controller layer for software developed using the MVC architecture without implementing and launching view layer programs (see paragraph 0011 of Patent Document 1). [Prior art documents] [Patent documents]
[0003] [Patent Document 1] Japanese Patent Application Laid-Open No. 2014-56388 Summary of the Invention [Problem to be solved by the invention]
[0004] As described in Patent Document 1, when software is developed, tests such as operation verification are carried out, but reducing the amount of work required for this testing has become an issue in recent years.
[0005] If you have developed a screen that automatically executes a certain action when a certain operation is performed, you need to conduct a test to confirm whether the action actually occurs correctly when the operation is performed. For example, this test could be a test to confirm whether the "action" of displaying a character string in a character string label occurs correctly when the "operation" of pressing a certain button is performed.
[0006] In order to perform such tests automatically, it is necessary to generate a definition management table, which is a table for defining and managing the operations, and a screen operation command table, which is a table for storing commands related to the operations.
[0007] However, in the past, the creation of such definition management tables and screen operation command tables (i.e., preparation for testing) was performed manually by the person in charge, which was inefficient, and the contents of the tables to be created were not standardized among the people in charge.
[0008] The present invention has been made in consideration of the above-mentioned problems, and aims to provide a test preparation efficiency improvement device, a test preparation efficiency improvement method, and a test preparation efficiency improvement program that can streamline and standardize test preparation by generating a definition management table and a screen operation command table based on test scenario data in which the information necessary to test operations that are automatically executed on a screen is written as tabular text data. [Means for solving the problem]
[0009] In order to solve the above-mentioned problems and achieve the object, the test preparation efficiency improvement device of the present invention is a test preparation efficiency improvement device equipped with a control unit that can streamline the preparations required to test operations that are automatically executed on a screen, and is characterized in that the control unit comprises: a definition management generation means that generates a definition management table, which is a table for defining and managing the operations, based on test scenario data in which information required to perform the test is written as tabular text data; and an operation command generation means that generates a screen operation command table, which is a table for storing commands related to automatic screen operations that are executed during the test, based on the test scenario data.
[0010] In addition, in the test preparation efficiency improvement device of the present invention, the definition management table is characterized in that it includes at least one piece of information selected from the group consisting of control information, which is information about targets on the screen; action information, which is information about each of the operations that are automatically executed on the screen; logic flow information, which is information about a flowchart that summarizes a series of the operations; and linking information, which defines that the logic flow information is linked to the control information so that when the control information is selected, the flowchart defined by the corresponding logic flow information will run.
[0011] In the test preparation efficiency improvement device according to the present invention, the test scenario data is data in Excel format.
[0012] Furthermore, in the test preparation efficiency improvement device according to the present invention, the control unit further comprises a screen operation execution means for executing screen operations based on the screen operation command table, and as a result of the screen operation by the screen operation execution means, if there is no abnormality, the operation based on the definition management table is automatically executed on the screen, whereas if there is an abnormality, the operation based on the definition management table is not automatically executed on the screen.
[0013] In the test preparation efficiency improvement device according to the present invention, the screen operation execution means stores the results of the screen operations performed by the screen operation execution means as test evidence.
[0014] In addition, in the test preparation efficiency improvement device according to the present invention, the test evidence is a screenshot of a screen operated by the screen operation execution means.
[0015] Furthermore, the test preparation efficiency improvement method according to the present invention is a test preparation efficiency improvement method executed by an information processing device having a control unit, which can streamline the preparations required to test operations that are automatically executed on a screen, and is characterized by including: a definition management generation step of generating a definition management table, which is a table for defining and managing the operations, based on test scenario data executed by the control unit, in which information required to perform the test is written as tabular text data; and an operation command generation step of generating, based on the test scenario data, a screen operation command table, which is a table for storing commands related to automatic screen operations that are executed during the test.
[0016] Furthermore, the test preparation efficiency improvement program of the present invention is a test preparation efficiency improvement program to be executed by an information processing device having a control unit, which can streamline the preparations required to test operations that are automatically executed on a screen, and is characterized by including: a definition management generation step of generating a definition management table, which is a table for defining and managing the operations, based on test scenario data in which the information required to perform the test is written as tabular text data, to be executed by the control unit; and an operation command generation step of generating, based on the test scenario data, a screen operation command table, which is a table for storing commands related to automatic screen operations that are executed during the test. [Effects of the Invention]
[0017] According to the present invention, by generating a definition management table and a screen operation command table based on test scenario data in which the information necessary to test operations that are automatically executed on the screen is written as tabular text data, it is possible to achieve the effect of streamlining and standardizing test preparation. [Brief explanation of the drawings]
[0018] [Figure 1]FIG. 1 is a block diagram showing an example of the configuration of a test preparation efficiency improvement device. [Figure 2] Figure 2 shows an example of a traditional overview of low-code development and testing. [Figure 3] FIG. 3 is a diagram illustrating an example of an overview of low-code development and testing in this embodiment. [Figure 4] FIG. 4 is a diagram showing an example of a general configuration of test scenario data. [Figure 5] FIG. 5 is a diagram showing a specific example of test scenario data. [Figure 6] FIG. 6 is a diagram showing an example of an image of generation of a UI definition and a screen operation command table by the scenario registration program. [Figure 7] FIG. 7 is a diagram showing an example of an image of generation of a UI definition by the scenario registration program. [Figure 8] FIG. 8 is a diagram showing an example of an image of generation of a screen operation command table by the scenario registration program. [Figure 9] FIG. 9 is a diagram showing an example of an image of execution of a screen operation by the screen operation program. [Figure 10] FIG. 10 is a diagram showing an example of information in a screen operation command table that is read by the screen operation program. [Figure 11] FIG. 11 is a diagram showing an example of four operations when executing the scenario of SEQ001 in the screen operation command table. [Figure 12] FIG. 12 is a diagram showing an example of the first operation of the four operations. [Figure 13] FIG. 13 is a diagram showing an example of the second operation of the four operations. [Figure 14] FIG. 14 is a diagram showing an example of the third operation of the four operations. [Figure 15] FIG. 15 is a diagram showing an example of the fourth operation of the four operations. [Figure 16]FIG. 16 is a diagram showing an example of an image of an input test for a control. [Figure 17] FIG. 17 is a diagram illustrating an example of test scenario data and a user interface. [Figure 18] FIG. 18 is a diagram illustrating an example of test scenario data and a definition management table. [Figure 19] FIG. 19 is a diagram showing an example of test scenario data and a screen operation command table. [Figure 20] FIG. 20 is a diagram showing an example of an image of a branch test. [Figure 21] FIG. 21 is a diagram showing an example of test scenario data and a user interface. [Figure 22] FIG. 22 is a diagram illustrating an example of test scenario data. [Figure 23] FIG. 23 is a diagram showing an example of test scenario data and a flow image. [Figure 24] FIG. 24 is a diagram illustrating an example of test scenario data. [Figure 25] FIG. 25 is a diagram illustrating an example of test scenario data and a definition management table. [Figure 26] FIG. 26 is a diagram illustrating an example of the definition management table. [Figure 27] FIG. 27 illustrates an example of a definition management table. [Figure 28] FIG. 28 is a diagram showing an example of test scenario data and a screen operation command table. [Figure 29] FIG. 29 is a diagram showing an example of a table summarizing a list of screen operation command information samples. [Figure 30] FIG. 30 is a diagram illustrating an example of a flowchart for registering a test scenario. [Figure 31] FIG. 31 is a diagram showing an example of an image of reading a definition ID. [Figure 32] FIG. 32 is a diagram showing an example of an image of screen startup. [Figure 33] FIG. 33 shows an example of a screen operation command table and an execution screen when an input test of a control is performed. [Figure 34] FIG. 34 shows an example of a screen operation command table and a saved file when an input test of a control is performed. [Figure 35] FIG. 35 shows an example of a screen operation command table and an execution screen when an input test of a control is performed. [Figure 36] FIG. 36 shows an example of a screen operation command table and a saved file when an input test for a control is performed. [Figure 37] FIG. 37 shows an example of a screen operation command table and an execution screen when a branch test is performed. [Figure 38] FIG. 38 shows an example of a screen operation command table and a saved file when a branch test is performed. [Figure 39] FIG. 39 shows an example of a screen operation command table and an execution screen when a branch test is performed. [Figure 40] FIG. 40 shows an example of a screen operation command table and an execution screen when a branch test is performed. [Figure 41] FIG. 41 shows an example of a screen operation command table and a saved file when a branch test is performed. [Figure 42] FIG. 42 is a diagram illustrating an example of a flowchart for executing a test scenario. DETAILED DESCRIPTION OF THE INVENTION
[0019] Hereinafter, embodiments of a test preparation efficiency improvement device, a test preparation efficiency improvement method, and a test preparation efficiency improvement program according to the present invention will be described in detail with reference to the accompanying drawings. Note that the present invention is not limited to these embodiments.
[0020] [1. Overview] Conventionally, the field of low-code development has had problems such as the following 1 to 4. 1. When managing only the generated UI (user interface) definition, it was impossible to know what settings were ultimately saved. 2. It was not possible to guarantee that the UI definition used in regression testing was the same as the previous test. 3. The way the testers operated the screen varied. 4. Testers took screenshots of the test screen in different ways.
[0021] Therefore, in this embodiment, for example, the following 1 to 4 can be performed. 1. By converting test scenarios set in Excel, simplified testing became possible. This meant that testers only had to manage the test scenarios when changing test content or adding scenarios. 2. It is now possible to manage UI definition information and screen operation command information using test scenarios that are structured based on tabular text, enabling centralized management of information. 3. Using a low-code development tool, we automated the generation of UI definitions and screen operations, which improved the efficiency of testing. 4. Using a low-code development tool, we automated the generation of UI definitions, screen operations, and screenshots of test screens, making it possible to repeat simple tests at any time.
[0022] In short, in this embodiment, it is possible to automatically generate a UI definition (definition management table) and a screen operation command table from a test scenario. Furthermore, in this embodiment, it is possible to automatically execute a test and automatically generate test evidence (e.g., screenshots) based on the generated definition management table and screen operation command table. Specific configurations and operations are described below.
[0023] [2. Configuration] An example of the configuration of a test preparation efficiency improvement device 100 according to this embodiment will be described with reference to Fig. 1. Fig. 1 is a block diagram showing an example of the configuration of the test preparation efficiency improvement device 100.
[0024] The test preparation efficiency improving device 100 is a commercially available desktop personal computer. Note that the test preparation efficiency improving device 100 is not limited to a stationary information processing device such as a desktop personal computer, but may also be a portable information processing device such as a commercially available notebook personal computer, a PDA (Personal Digital Assistant), a smartphone, or a tablet personal computer.
[0025] The test preparation efficiency improving device 100 includes a control unit 102, a communication interface unit 104, a storage unit 106, and an input / output interface unit 108. The units included in the test preparation efficiency improving device 100 are connected to each other so as to be able to communicate with each other via any communication path.
[0026] The communication interface unit 104 communicably connects the test preparation efficiency improving device 100 to a network 300 via a communication device such as a router and a wired or wireless communication line such as a dedicated line. The communication interface unit 104 has a function of communicating data with other devices via the communication line. Here, the network 300 has a function of connecting the test preparation efficiency improving device 100 and the server 200 so that they can communicate with each other, and is, for example, the Internet or a LAN (Local Area Network). Note that data such as various masters described below may be stored in the server 200, for example.
[0027] 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.
[0028] Various databases, tables, files, etc. are stored in the storage unit 106. Computer programs that work in conjunction with the OS (Operating System) to issue commands to the 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 device such as RAM (Random Access Memory) or ROM (Read Only Memory), a fixed disk device such as a hard disk, a flexible disk, an optical disk, etc.
[0029] The storage unit 106 includes, for example, test scenario data 106a, a definition management table 106b, and a screen operation command table 106c.
[0030] The test preparation efficiency improving device 100 according to this embodiment can improve the efficiency of preparations required to test operations that are automatically executed on the screen.
[0031] The test scenario data 106a contains information necessary for carrying out the test written as text data in a table format, and is preferably data in Excel format.
[0032] As shown in FIG. 4, the test scenario data 106a includes, as elements, for example, an outline of the test case, information (UI definition) that serves as the basis for generating the definition management table 106b, information (screen operation commands) that serves as the basis for generating the screen operation command table 106c, and test confirmation details.
[0033] The definition management table 106b is a table for defining and managing the operations. As shown in Fig. 18 and Fig. 25 to Fig. 27, the definition management table 106b includes, for example, at least one piece of information selected from the group consisting of control information, which is information about targets on the screen, action information, which is information about each of the operations automatically executed on the screen, logic flow information, which is information about a flowchart summarizing a series of the operations, and linking information, which defines that the control information is linked to the logic flow information so that when the control information is selected, the flowchart defined by the corresponding logic flow information runs, and a definition ID (ID).
[0034] The screen operation command table 106c is a table for storing commands related to automatic screen operations executed during the test. As shown in Fig. 19 and Fig. 28, the screen operation command table 106c includes, for example, screen operation command information, definition ID (ID), etc. A list of the screen operation command information is, for example, as shown in the table of Fig. 29.
[0035] The screen operation command table 106c includes further information according to the type of the screen operation command information. For example, if the screen operation command information is "SetText", it further includes information on what value to set to which control (target), if the screen operation command information is "ClickElement", it further includes information on which control (target) to click, and if the screen operation command information is "ScreenShot", it further includes information on what file name to save the captured image under and what confirmation items to include.
[0036] The control unit 102 is a CPU or the like that performs overall control of the test preparation efficiency improvement device 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.
[0037] The control unit 102, in terms of functional concept, includes, for example, (1) a definition management generation unit 102a as definition management generation means for generating a definition management table, which is a table for defining and managing the operations, based on test scenario data in which the information necessary for performing the test is written as tabular text data; (2) an operation command generation unit 102b as operation command generation means for generating, based on the test scenario data, a screen operation command table, which is a table for storing commands related to automatic screen operations to be performed during the test; and (3) a screen operation execution unit 102c as screen operation execution means for executing screen operations based on the screen operation command table.
[0038] The definition management generating unit 102a generates a definition management table 106b based on the test scenario data 106a.
[0039] The operation command generating unit 102b generates a screen operation command table 106c based on the test scenario data 106a.
[0040] The screen operation execution unit 102c executes screen operations based on the screen operation command table 106c. If there is no abnormality as a result of the screen operation by the screen operation execution unit 102c, the operation based on the definition management table 106b is automatically executed on the screen. On the other hand, if there is an abnormality as a result of the screen operation by the screen operation execution unit 102c, the operation based on the definition management table 106b is not automatically executed on the screen.
[0041] The screen operation execution unit 102c saves the results of the screen operations performed by the screen operation execution unit 102c, including cases where no abnormality is found, as test evidence. The format of the test evidence is not particularly limited, but may be, for example, a screenshot of the screen, a database update, or a CSV output.
[0042] [3. Processing Overview] This section explains the overall picture of low-code development and testing, the key points of this embodiment, and an overview of the processing of this embodiment.
[0043] [3-1. Overview of low-code development and testing] Figure 2 shows the overall picture of low-code development and testing in the past. As shown in Figure 2, testers traditionally manually registered test scenarios, executed them, and analyzed the results of their execution.
[0044] Figure 3 shows an overview of low-code development and testing in this embodiment. In this embodiment, as shown in Figure 3, the latest test scenarios can be automatically registered using a scenario registration program, and test scenarios can be automatically executed using a screen operation program. Therefore, as shown in Figure 3, testers only need to manually analyze the results of test scenario execution.
[0045] The scenario registration program is a program for causing the control unit 102 to execute the same processing as that executed by the definition management generation unit 102a and the operation command generation unit 102b. The screen operation program is a program for causing the control unit 102 to execute the same processing as that executed by the screen operation execution unit 102c.
[0046] [3-2. Key Points of the Present Embodiment] In this section, the key points of this embodiment will be explained. The key point of this embodiment is that a simple test can be performed simply by setting a test scenario in Excel or the like.
[0047] Specifically, in this embodiment, it is possible to generate a UI definition (definition management table 106b) from the test scenario data 106a, which makes the following 1 to 3 possible. 1. It is now possible for developers to generate UI definitions without operating the layout development screen. 2. It is now possible to generate UI definitions with the same settings even when regenerating. 3. By editing the test scenario, developers can now replicate UI definitions without having to operate the layout development screen.
[0048] In addition, in this embodiment, it is possible to generate the screen operation command table 106c from the test scenario data 106a and to specify the timing of taking a screenshot of the test screen in the test scenario data 106a. This makes it possible to achieve the following 1 and 2, for example: 1. It became possible for testers to standardize the screen operation methods and timing of taking screenshots on the test screen. 2. Even when re-running the test, it is now possible to perform the same screen operations and obtain the same test screen screenshots.
[0049] [3-3. Processing Overview of This Embodiment] This section will provide an overview of the processing of this embodiment. First, the configuration of the test scenario data 106a will be described, then the generation of the UI definition (definition management table 106b) and the screen operation command table 106c will be described, and finally the execution of the screen operation command will be described.
[0050] (1) Configuration of test scenario data 106a The test scenario data 106a is configured based on tabular text, and has, for example, the general configuration shown in Fig. 4. Specifically, as shown in Fig. 4, the test scenario data 106a includes, for example, information that outlines the test (the "Test Case Outline" element in Fig. 4), setting information that is the basis for the application to be tested (the "UI Definition" element in Fig. 4), information for operating the application (the "Screen Operation Command" element in Fig. 4), and information on confirmation items corresponding to screenshots (the "Test Confirmation Contents" element in Fig. 4).
[0051] A specific example of the test scenario data 106a is shown in Fig. 5. In the test scenario data 106a in Fig. 5, a test scenario (ID=SEQ001) for performing an operation test on character string labels and a test scenario (ID=SEQ002) for performing an operation test on numeric labels are set.
[0052] (2) Creation of UI definition (definition management table 106b) and screen operation command table 106c As shown in FIG. 6, the scenario registration program reads test scenario data 106a and generates a UI definition (definition management table 106b) and a screen operation command table 106c.
[0053] The UI definition (definition management table 106b) is information on the UI definition of a virtually generated application. The screen operation command table 106c is information on screen operation commands for automatically executing an application.
[0054] The generation of UI definitions (definition management table 106b) will now be described. Generating UI definitions (definition management table 106b) is a process in which the scenario registration program virtually generates and registers application definition data from information corresponding to the UI definitions in the test scenario data 106a. Figure 7 shows an example of the scenario registration program reading the test scenario data 106a, which is tabular text data, and generating the UI definitions (definition management table 106b).
[0055] The generation of the screen operation command table 106c will now be described. The generation of the screen operation command table 106c is a process in which the scenario registration program generates and registers screen operation definitions required for automatically operating an application from information corresponding to the screen operation commands in the test scenario data 106a. Fig. 8 shows an example of the scenario registration program reading the test scenario data 106a, which is text data in tabular format, and generating the screen operation command table 106c.
[0056] (3) Execution of screen operation commands As shown in FIG. 9, the screen operation program uses the screen operation command table 106c to automatically operate the low-code execution platform.
[0057] In the screen operation command table 106c, operation information is saved for each scenario, as shown in Fig. 10. The screen operation program reads the operation information for each scenario and operates the screen.
[0058] Here, as a specific example of the operations, we will explain in order the four operations when the screen operation program executes the scenario of SEQ001 in Fig. 10. The overall operations when executing the scenario of SEQ001 are as shown in the table in Fig. 11.
[0059] As the first operation, the screen operation program selects and starts SEQ001_screen from the menu in accordance with the execution command "Screen startup SEQ001_screen" as shown in FIG.
[0060] As the second operation, the screen operation program inputs "abc" into the character string text box on the screen in accordance with the execution command "set value to text character string text box abc" as shown in FIG.
[0061] As the third operation, the screen operation program clicks button 1 in accordance with the execution command "button click button 1" as shown in FIG.
[0062] As the fourth operation, the screen operation program takes a screenshot named "SEQ001 Image 1" in accordance with the execution command "Take screenshot SEQ001 Image 1" as shown in FIG.
[0063] [4. Specific examples of processing] This section describes specific examples of processing according to this embodiment. In the following [4-1], we will explain in detail the processing that the scenario registration program causes the control unit 102 to execute, i.e., the processing performed by the definition management generation unit 102a and the operation command generation unit 102b. In addition, in the following [4-2], we will explain in detail the processing that the screen operation program causes the control unit 102 to execute, i.e., the processing performed by the screen operation execution unit 102c.
[0064] [4-1. Processing that the scenario registration program causes the control unit 102 to execute] This section explains specific examples of the processing (test scenario registration) that the scenario registration program causes the control unit 102 to execute. In the following [4-1-1], as a specific example, the generation of the definition management table 106b and the screen operation command table 106c required to perform input tests of controls is explained. In the following [4-1-2], as a specific example, the generation of the definition management table 106b and the screen operation command table 106c required to perform branch tests is explained. In the following [4-1-3], a sample of screen operation command information and a flowchart for registering a test scenario are explained.
[0065] [4-1-1. Control input test] In this section, the generation of the definition management table 106b and the screen operation command table 106c required for performing input tests on controls will be described.
[0066] The control input test in this section refers to a test that verifies that no error is displayed when a character string is entered in the character string text box, as shown in Figure 16, and that an error is displayed when no character string is entered in the character string text box. In the example of Figure 16, the error is a speech bubble that reads "Item not entered."
[0067] In this section, we will explain what kind of definition management table 106b and screen operation command table 106c are generated when it is desired to generate a test scenario for carrying out such a test.
[0068] It is assumed that the information in the test scenario data 106a that is the basis for generating the definition management table 106b is the test scenario data 106a shown in Fig. 17. In this case, the user interface generated from the test scenario data 106a shown in Fig. 17 will be as shown in the example screen of Fig. 17.
[0069] (1) Creation of the definition management table 106b Assume that the information in the test scenario data 106a that is the basis for generating the definition management table 106b is the test scenario data 106a shown in Fig. 18 (the same content as the test scenario data 106a shown in Fig. 17). In this case, the definition management generation unit 102a generates the definition management table 106b shown in Fig. 18 based on the test scenario data 106a shown in Fig. 18.
[0070] Here, the contents defined by the definition management table 106b in Fig. 18 will be described. In the definition management table 106b in Fig. 18, as indicated by hatching, the mandatory setting "TRUE" is set for control key 3 (corresponding to the character string text box). This means that it is mandatory to input a character string in the character string text box in the example screen of Fig. 16. For this reason, if no character string text is input in the character string text box in the example screen of Fig. 16, an error message will be displayed.
[0071] (2) Generation of the screen operation command table 106c It is assumed that the information in the test scenario data 106a that is the basis for generating the screen operation command table 106c is the test scenario data 106a shown in Fig. 19. In this case, the operation command generating unit 102b generates the screen operation command table 106c shown in Fig. 19 based on the test scenario data 106a shown in Fig. 19.
[0072] Here, the contents defined by the screen operation command table 106c shown in FIG. 19 will be described.
[0073] 19, the type "SetText," the target "control key 3," and the value "'a'" are set in the first row of the screen operation command table 106c. This means that the operation is to automatically input the character "a" into the character string text box of control key 3.
[0074] 19, the type "ScreenShot," file name "SEQ001 Image 1," and confirmation item "When entering "a," confirm that the required check box is not selected" are set. This means that after entering the character "a," a screenshot is taken and the data is saved under the name "SEQ001 Image 1," and the confirmation item is "that no errors are displayed."
[0075] In contrast, the third row of the screen operation command table 106c shown in FIG. 19 has the type "SetText", the target "control key 3" and the value """. This means that no operation is performed to automatically input characters into the character string text box of control key 3 (in other words, an operation is performed to automatically input a blank character).
[0076] 19, the type "ScreenShot," the file name "SEQ001 Image 2," and the confirmation item "Confirm that a required error message is displayed if no information is entered" are set. This means that after entering a blank character, a screenshot is taken and the data is saved under the name "SEQ001 Image 2," and the confirmation item is "Confirm that an error message is displayed."
[0077] [4-1-2. Second example (branch test)] In this section, the generation of the definition management table 106b and the screen operation command table 106c required for performing the branch test will be described.
[0078] The branch test in this section is a test that verifies that when the Confirm button is pressed (without pressing the switch button), the message "branched to True" is displayed, as shown in Figure 20, and that when the Confirm button is pressed after pressing the switch button, the message "branched to False" is displayed.
[0079] In this section, we will explain what kind of definition management table 106b and screen operation command table 106c are generated when it is desired to generate a test scenario for carrying out such a test.
[0080] It should be noted that part of the information in the test scenario data 106a that is the basis for generating the definition management table 106b is assumed to be the same as the test scenario data 106a shown in Fig. 21. In this case, the user interface generated from the test scenario data 106a shown in Fig. 21 will be as shown in the example screen of Fig. 21.
[0081] Furthermore, the information in the test scenario data 106a that is the basis for generating the definition management table 106b is assumed to be the test scenario data 106a shown in Figures 22 and 23. In this case, the flow image generated from the test scenario data 106a shown in Figures 22 and 23 is as shown in the flowchart in Figure 23.
[0082] (1) Creation of the definition management table 106b Assume that the information in the test scenario data 106a that is the basis for generating the definition management table 106b is the test scenario data 106a shown in Figures 24 and 25 (the content is the same as the test scenario data 106a shown in Figures 22 and 23). In this case, the definition management generation unit 102a generates the definition management table 106b shown in Figures 25 to 27 based on the test scenario data 106a shown in Figures 24 and 25.
[0083] Here, the contents defined by the definition management table 106b shown in FIGS. 25 to 27 will be explained in reference to the flowchart of FIG.
[0084] Referring to linked element 1 in the linked information in definition management table 106b in Figure 25, the logic flow corresponding to control key 2 (corresponding to the "confirm button") is logic flow key 1. Here, referring to the logic flow information in Figure 25, logic flow 1 defined by logic flow key 1 consists of five elements, from flow element 1 to flow element 5. This means that when the "confirm button" is pressed, the flow will flow from flow element 1 to flow element 5 (however, this includes branches, so not all flows will flow in a straight line).
[0085] Below, the operations of flow elements 1 to 5 included in logic flow key 1 will be explained.
[0086] Flow element 1 has a previous action ID of "start action ID" and a next action ID of "branch action ID." Referring to the action information in FIG. 25, the type of the start action is "start" and the type of the branch action is "branch." As described above, when the "confirm button" is pressed, the processing first branches. The operations defined by flow element 1 are the operations from the "start action" to "branch 1" in the flowchart in FIG. 23.
[0087] For flow element 2, the previous action ID is the "branch action ID," the next action ID is the "screen update 1 action ID," and the callback key is "TRUE." In this case, if the information returned when the previous action is executed is the callback key "TRUE," the next action is executed. Referring to the action information in FIG. 25, the type for the branch action is "branch." Referring to the action information in FIG. 26, the type for the screen update 1 action is "screen update 1," the source value is "branched to True," and the destination type is "control." Therefore, if a callback key of "TRUE" is returned after branching, screen update 1 (a screen update that displays "branched to True" in the control; see FIG. 20) is executed. In the flowchart of FIG. 23, the behavior defined by flow element 2 is the behavior from "branch 1" to "TRUE" and up to "screen update 1."
[0088] For flow element 3, the previous action ID is the "branch action ID," the next action ID is the "screen update 2 action ID," and the callback key is "FALSE." In this case, if the information returned when the previous action is executed is the callback key "FALSE," the next action is executed. Referring to the action information in FIG. 25, the type for the branch action is "branch." Referring to the action information in FIG. 26, the type for the screen update 2 action is "screen update 2," the source value is "branched to False," and the destination type is "control." Therefore, if a callback key of "FALSE" is returned after branching, screen update 2 (a screen update that displays "branched to False" in the control; see FIG. 20) is executed. In the flowchart in FIG. 23, the behavior defined by flow element 3 is the behavior from "branch 1" to "FALSE" and up to "screen update 2."
[0089] Here, in this specific example, the value set as variable 1 is returned as the callback key. As shown by "Variable 1" and "TRUE" in the "Setting 3" column of the test scenario data 106a in FIG. 22, "TRUE" is set as the initial value of variable 1, but if the switch button is pressed beforehand, the value of variable 1 is updated from "TRUE" to "FALSE" (this update to "FALSE" will be explained in flow element 1 of logic flow key 2 below). In other words, if the confirm button is pressed without pressing the switch button, "TRUE", which is the initial value of variable 1, is returned as the callback key (in the case of flow element 2), but on the other hand, if the confirm button is pressed after pressing the switch button, "FALSE", which is the updated value of variable 1, is returned as the callback key (in the case of flow element 3).
[0090] Flow element 4 has a previous action ID of "Screen Update 1 Action ID" and a next action ID of "End Action ID." Referring to the action information in FIG. 26, the type of screen update action 1 is "Screen Update 1," and the type of end action is "End." As described above, when screen update 1 (a screen update that displays "Branched to True" in the control, see FIG. 20) is executed, the processing ends. The operation defined by flow element 4 is the operation from "Screen Update 1" to "End Action" in the flowchart of FIG. 23.
[0091] Flow element 5 has a previous action ID of "Screen Update 2 Action ID" and a next action ID of "End Action ID." Referring to the action information in FIG. 26, the type of screen update action 2 is "Screen Update 2," and the type of end action is "End." As described above, when screen update 2 (a screen update that displays "branched to False" in the control, see FIG. 20) is executed, the processing ends. The operation defined by flow element 5 is the operation from "Screen Update 2" to "End Action" in the flowchart of FIG. 23.
[0092] This concludes the explanation of the operations of flow elements 1 to 5 included in logic flow key 1.
[0093] Next, referring to linking element 2 in the linking information in definition management table 106b in Figure 25, the logic flow corresponding to control key 3 (corresponding to the "switch button") is logic flow key 2. Here, referring to the logic flow information in Figure 26, logic flow 2 defined by logic flow key 2 consists of two elements, flow element 1 to flow element 2. This means that when the "switch button" is pressed, a flow from flow element 1 to flow element 2 will flow.
[0094] Below, we will explain each operation from flow element 1 to flow element 2 included in logic flow key 2.
[0095] For flow element 1, the previous action ID is the "ID of the start action" and the next action ID is the "ID of the screen update 3 action." Here, referring to the action information in FIG. 25, the type for the start action is "start." Also, referring to the action information in FIG. 27, for the screen update 3 action, the type is "screen update 3," the source value is "FALSE," and the destination type is "variable." From the above, when the "switch button" is pressed, the initial value of variable 1, "TRUE," is updated to "FALSE."
[0096] Flow element 2 has a previous action ID of "Screen Update 3 Action ID" and a next action ID of "End Action ID." Referring to the action information in FIG. 27, the type for screen update action 3 is "Screen Update 3." Referring to the action information in FIG. 26, the type for the end action is "End." As a result, when screen update 3 (updating variable 1 from "TRUE" to "FALSE") is executed, the processing ends.
[0097] This concludes the explanation of the operations from flow element 1 to flow element 2 included in logic flow key 2.
[0098] (2) Generation of the screen operation command table 106c It is assumed that the information in the test scenario data 106a that is the basis for generating the screen operation command table 106c is the test scenario data 106a shown in Fig. 28. In this case, the operation command generating unit 102b generates the screen operation command table 106c shown in Fig. 28 based on the test scenario data 106a shown in Fig. 28.
[0099] Here, the contents defined by the screen operation command table 106c shown in FIG. 28 will be described.
[0100] The type "ClickElement" and the target "Control Key 2" are set in the first row of the screen operation command table 106c shown in Fig. 28. This means that an operation to automatically press (automatically click) Control Key 2 (confirmation button) is to be performed.
[0101] 28, the second row of the screen operation command table 106c has the type "ScreenShot," the file name "SEQ002 Image 1," and the confirmation item "Confirm that 'branched to True' is displayed when the confirmation button is pressed." This means that after pressing the confirmation button, an operation is performed to take a screenshot and save the data with the name "SEQ002 Image 1," and the confirmation item is "the character string 'branched to True' is displayed."
[0102] In contrast to this, the type "ClickElement" and the target "Control Key 3" are set in the third row of the screen operation command table 106c shown in Fig. 28. This means that an operation to automatically press (automatically click) Control Key 3 (switch button) is to be performed.
[0103] 28, the type "ClickElement" and the target "Control Key 2" are set in the fourth row of the screen operation command table 106c. This means that an operation to automatically press (automatically click) the control key 2 (confirmation button) is to be performed.
[0104] 28, the fifth row of the screen operation command table 106c has the type "ScreenShot," the file name "SEQ002 Image 2," and the confirmation item "Confirm that when the confirm button is pressed after the switch button is pressed, the message "branched to False" is displayed." This means that after pressing the confirm button after pressing the switch button, an operation is performed to take a screenshot and save the data with the name "SEQ002 Image 2," and the confirmation item is "the character string "branched to False" is displayed."
[0105] [4-1-3. Sample of screen operation command information and test scenario registration flowchart] This section explains a sample of screen operation command information and a flowchart for registering a test scenario.
[0106] A sample of screen operation command information will be described. As specific examples of screen operation command information, SetText (setting a specified value in a control), ClickElement (clicking a button), and ScreenShot (taking a screenshot) have been described above in [4-1-1] and [4-1-2]. In this embodiment, various other screen operation command information can be set in addition to these. A table listing sample screen operation command information is shown in FIG. 29.
[0107] A flowchart for registering a test scenario will be described with reference to Fig. 30. First, when the process starts (Start in Fig. 30), the contents of the definition management table 106b and the screen operation command table 106c are cleared (Step S1 in Fig. 30). Next, a definition ID is obtained from the execution setting file (Step S2 in Fig. 30). Next, one definition ID is read from the test scenario data 106a (Step S3 in Fig. 30).
[0108] Next, the definition management generation unit 102a registers the information in the definition management table 106b (step S4 in FIG. 30). Specifically, the definition management generation unit 102a registers the screen variable information, layout information, control information, action information, logic flow information, and event setting information in the test scenario data 106a in the definition management table 106b, for example, in this order. Note that this order is merely an example and is not particularly limited.
[0109] Next, the operation command generating unit 102b registers the information in the screen operation command table 106c (step S5 in FIG. 30).
[0110] Next, it is determined whether the information was successfully registered in the definition management table 106b and the screen operation command table 106c (step S6 in FIG. 30). If the information was successfully registered (step S6 in FIG. 30: Yes), the process returns to step S3, and the next definition ID is read from the test scenario data 106a. On the other hand, if the information was not successfully registered (step S6 in FIG. 30: No), an error log is output (step S7 in FIG. 30), and the process returns to step S3, and the next definition ID is read from the test scenario data 106a.
[0111] The above-described processing of steps S3 to S7 is repeated up to the last definition ID in the test scenario data 106a, and when there is no definition ID that can be acquired, the processing ends (end of FIG. 30).
[0112] [4-2. Processing that the screen operation program causes the control unit 102 to execute] This section explains specific examples of the processing (test scenario execution) that the screen operation program causes the control unit 102 to execute. In the following [4-2-1], as a specific example, screen operations when performing a control input test are explained. In the following [4-2-2], as a specific example, screen operations when performing a branch test are explained. In the following [4-2-3], a flowchart of test scenario execution is explained.
[0113] Before operating the screen, it is necessary to load the definition ID and launch the screen, so these two processes will be explained first.
[0114] The reading of a definition ID will be described with reference to Fig. 31. As shown in Fig. 31, the screen operation execution unit 102c reads the execution setting file and acquires the definition ID of the test execution target. Next, as shown in Fig. 31, the screen operation execution unit 102c acquires screen operation command information associated with the acquired definition ID from the screen operation command table 106c, and operates the low-code execution platform according to the acquired screen operation command information. The screen operation execution unit 102c repeats this series of processes as many times as the number of acquired definition IDs.
[0115] Screen launching will be described with reference to FIG. 32. The screen operation execution unit 102c operates the low-code execution platform to launch the screen in the screen operation command information linked to the acquired definition ID. In the example of FIG. 32, the screen operation execution unit 102c launches the screen SEQ001. The low-code execution platform dynamically generates and displays a user interface for executing the test prepared in accordance with the screen operation command described below, based on the information in the definition management table 106b corresponding to the launched screen SEQ001 linked to the acquired definition ID, and waits for the screen operation command to be received.
[0116] [4-2-1. Screen operations when performing control input tests] This section describes automatic screen operations when performing input tests on controls. In this section, it is assumed that the screen operation execution unit 102c executes screen operations based on the screen operation command table 106c (shown again in FIGS. 33 to 36) shown in Fig. 19, which was generated in (2) of [4-1-1].
[0117] (1) When entering a, screen operations to confirm that the required check box is not selected First, we will explain how to operate the screen to confirm that the required check box is not selected when entering a.
[0118] The type "SetText," the target "control key 3," and the value "a" are set in the first row of the screen operation command table 106c shown in Fig. 33. Therefore, the screen operation execution unit 102c inputs the character "a" into the character string text box for control key 3, as shown in Fig. 33.
[0119] Next, in the second row of screen operation command table 106c shown in Fig. 34, the type "ScreenShot," file name "SEQ001 Image 1," and confirmation item "When entering "a," confirm that the mandatory check box is not selected" are set. Therefore, as shown in Fig. 34, screen operation execution unit 102c takes a screenshot after entering the character "a" and saves the data under the name "SEQ001 Image 1." Note that screen operation execution unit 102c does not go as far as checking the confirmation items.
[0120] (2) Screen operation to confirm that a required error message is displayed when information is not entered Next, we will explain how to operate the screen to confirm that a required error is displayed when information is not entered.
[0121] In the third row of the screen operation command table 106c shown in FIG. 35, the type "SetText", the target "control key 3" and the value """ are set. Therefore, the screen operation execution unit 102c inputs an empty string (= inputs nothing) into the string text box for control key 3, as shown in FIG. 35.
[0122] Next, in the fourth row of the screen operation command table 106c shown in Fig. 36, the type "ScreenShot," the file name "SEQ001 Image 2," and the confirmation item "Confirm that a mandatory error message is displayed if no information is entered" are set. Therefore, after inputting a blank character, the screen operation execution unit 102c takes a screenshot and saves the data under the name "SEQ001 Image 2," as shown in Fig. 36. Note that the screen operation execution unit 102c does not go as far as checking the confirmation items.
[0123] [4-2-2. Screen operations when performing branch testing] This section describes automatic screen operations when a branch test is performed. In this section, it is assumed that the screen operation execution unit 102c executes screen operations based on the screen operation command table 106c (shown again in FIGS. 37 to 41) shown in Fig. 28, which was generated in [4-1-2] (2).
[0124] (1) When you press the Confirm button, the screen operation to confirm that "branched to True" is displayed First, we will explain the screen operations to confirm that "branched to True" is displayed when the Confirm button is pressed.
[0125] The type "ClickElement" and the target "control key 2" are set in the first row of the screen operation command table 106c shown in Fig. 37. Therefore, the screen operation execution unit 102c presses (clicks) the confirmation button of the control key 2, as shown in Fig. 37.
[0126] Next, in the second row of screen operation command table 106c shown in Fig. 38, the type "ScreenShot", file name "SEQ002 Image 1", and confirmation item "Confirm that 'branched to True' is displayed when the confirmation button is pressed" are set. Therefore, as shown in Fig. 38, after the confirmation button is pressed (clicked), screen operation execution unit 102c takes a screenshot and saves the data under the name "SEQ002 Image 1". Note that screen operation execution unit 102c does not go as far as checking the confirmation items.
[0127] (2) When you press the Confirm button after pressing the Switch button, you can confirm that the message "Branched to False" is displayed. Next, we will explain the screen operations to confirm that "branched to False" is displayed when you press the Confirm button after pressing the Switch button.
[0128] The type "ClickElement" and the target "control key 3" are set in the third row of the screen operation command table 106c shown in Fig. 39. Therefore, the screen operation execution unit 102c presses (clicks) the switching button of the control key 3, as shown in Fig. 39.
[0129] Next, the type "ClickElement" and the target "control key 2" are set in the fourth row of the screen operation command table 106c shown in Fig. 40. Therefore, the screen operation execution unit 102c presses (clicks) the confirmation button of the control key 2, as shown in Fig. 40.
[0130] Next, in the fifth row of screen operation command table 106c shown in Fig. 41, the type "ScreenShot," file name "SEQ002 Image 2," and confirmation item "Confirm that when the Confirm button is pressed after pressing the Switch button, it is displayed that the branch has been made to False," are set. Therefore, as shown in Fig. 41, after pressing the Confirm button after pressing the Switch button, screen operation execution unit 102c takes a screenshot and saves the data under the name "SEQ002 Image 2." Note that screen operation execution unit 102c does not go as far as confirming the confirmation items.
[0131] [4-2-3. Test scenario execution flowchart] In this section, the flowchart for executing a test scenario will be explained with reference to Figure 42.
[0132] First, when the process starts (Start in FIG. 42), the test target of the low-code execution platform is replaced to take the latest screenshot. That is, the latest version of the low-code execution platform is downloaded from the management location (Step S1 in FIG. 42).
[0133] Next, the screen operation execution unit 102c acquires a definition ID from the execution setting file (step S2 in FIG. 42), then reads one definition ID from the screen operation command table 106c (step S3 in FIG. 42), and further acquires screen operation command information linked to the acquired definition ID from the screen operation command table 106c (step S4 in FIG. 42).
[0134] Next, the screen operation execution unit 102c starts the screen (step S5 in FIG. 42), and determines whether the screen operation command information acquired in step S4 is a ScreenShot command (step S6 in FIG. 42). If it is determined to be a ScreenShot command (step S6 in FIG. 42: Yes), the screen operation execution unit 102c outputs a screenshot (step S7 in FIG. 42).
[0135] After outputting the screenshot in step S7, or if it is determined in step S6 that the command is not a ScreenShot command (step S6: No in FIG. 42), the screen operation execution unit 102c performs screen operation in accordance with the screen operation command information acquired in step S4 (step S8 in FIG. 42). Note that in step S8, an SQL query can also be issued to update the database or output data in CSV format. The screen operation execution unit 102c determines whether the screen operation was successful (step S9 in FIG. 42). If it is determined that the screen operation was successful (step S9 in FIG. 42: Yes), the screen operation execution unit 102c returns to step S4 and acquires the next screen operation command information from the screen operation command table 106c. On the other hand, if it is determined that the screen operation was not successful (step S9 in FIG. 42: No), the screen operation execution unit 102c outputs an error log (step S10 in FIG. 42), and then returns to step S4 and acquires the next screen operation command information from the screen operation command table 106c.
[0136] The screen operation execution unit 102c repeats the above steps S4 to S10 for the last screen operation command information within the same definition ID, and when there is no more screen operation command information to acquire, it returns to step S3 and reads the next definition ID (=next test scenario) from the screen operation command table 106c.
[0137] The above process is repeated until the last definition ID in the screen operation command table 106c is reached, and when there are no more definition IDs that can be obtained, the image comparison program outputs a list of differences (step S11 in Figure 42), and the process ends (End in Figure 42).
[0138] [5. Summary of this embodiment] As described above, the test preparation efficiency improving device 100 according to this embodiment can generate the definition management table 106b and the screen operation command table 106c based on the test scenario data 106a, as explained in [4-1]. Therefore, the test preparation efficiency improving device 100 according to this embodiment can improve the efficiency and standardize test preparation.
[0139] Furthermore, as explained in [4-2], the test preparation efficiency improving device 100 according to this embodiment can automatically execute screen operations based on the screen operation command table 106c. Therefore, the test preparation efficiency improving device 100 according to this embodiment can improve the efficiency and standardize not only test preparation but also test execution.
[0140] [6. 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.
[0141] 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.
[0142] Furthermore, this embodiment can contribute to strengthening control and governance, which can contribute to the achievement of Goal 16 of the SDGs.
[0143] 7. 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.
[0144] 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.
[0145] 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.
[0146] Furthermore, with regard to the test preparation efficiency improvement device 100, the components shown in the figures are functional concepts, and do not necessarily have to be physically configured as shown in the figures.
[0147] For example, all or any part of the processing functions of the test preparation efficiency improving device 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 device to execute the processes described in this embodiment, and is mechanically read by the test preparation efficiency improving device 100 as needed. That is, a computer program for providing 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.
[0148] In addition, this computer program may be stored in an application program server connected to the test preparation efficiency improving device 100 via any network, and it is also possible to download all or part of it as needed.
[0149] 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.
[0150] 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 structure, but also includes a structure that is distributed as multiple modules or libraries, or a structure that achieves its function by cooperating with a separate program, such as an OS. Note that the specific configuration and reading procedure for reading a recording medium in each device shown in the embodiments, as well as the installation procedure after reading, can use well-known configurations and procedures.
[0151] The various databases stored in the memory unit are storage means such as memory devices such as RAM and ROM, fixed disk devices 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.
[0152] The test preparation efficiency improving device 100 may be configured as an information processing device such as a known personal computer or workstation, or may be configured as the information processing device connected to any peripheral device. The test preparation efficiency improving device 100 may also be realized by installing software (including programs, data, etc.) that causes the device to perform the processes described in this embodiment.
[0153] Furthermore, the specific form of distribution and integration of the devices is not limited to that shown in the drawings, and all or part of them can be configured by functionally or physically distributing and integrating them in any unit depending on 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]
[0154] The present invention is useful, for example, in the field of screen development, and is particularly useful when developing screens using low-code. [Explanation of symbols]
[0155] 100 Test Preparation Efficiency Devices 102 Control section 102a Definition management generation section 102b Operation command generation unit 102c Screen operation execution unit 104 Communication interface unit 106 Storage section 106a Test scenario data 106b Definition management table 106c Screen operation command table 108 Input / Output Interface Section 112 Input Device 114 Output Device 200 servers 300 Network
Claims
1. A test preparation efficiency improvement device having a control unit that can improve the efficiency of preparations required to test operations that are automatically executed on a screen, The control unit a definition management generation means for generating a definition management table, which is a table for defining and managing the operations, based on test scenario data in which information required for performing the test is written as tabular text data; an operation command generating means for generating a screen operation command table, which is a table for storing commands related to automatic screen operations to be executed during the test, based on the test scenario data; Equipped with The test scenario data includes information that outlines the test, setting information that is the basis of the application to be tested, which is a UI definition, information for operating the application, which is a screen operation command, and information on confirmation items corresponding to screenshots; the definition management table includes screen variable information, layout information, control information, action information, logic flow information, and event setting information in the test scenario data, the definition management generation means virtually generates and registers definition data of an application from setting information that is the basis of the application to be tested, which is the UI definition of the test scenario data; the operation command generating means generates and registers a screen operation definition required for automatically operating the application from information for operating the application, which is a screen operation command of the test scenario data; A test preparation efficiency device characterized by:
2. The test scenario data is in Excel format.
2. The test preparation efficiency improving device according to claim 1,
3. The control unit further comprising a screen operation execution means for executing screen operations based on the screen operation command table; as a result of the operation of the screen by the screen operation execution means, if there is no abnormality, the operation based on the definition management table is automatically executed on the screen, and conversely, if there is an abnormality, the operation based on the definition management table is not automatically executed on the screen; 3. The test preparation efficiency improving device according to claim 1 or 2.
4. The screen operation execution means storing the results of the screen operation by the screen operation execution means as test evidence; 4. The test preparation efficiency improving device according to claim 3.
5. The test evidence is a screenshot of a screen operated by the screen operation execution means; 5. The test preparation efficiency improving device according to claim 4.
6. A test preparation efficiency improvement method executed by an information processing device having a control unit, which can improve the efficiency of preparations required to test operations automatically executed on a screen, comprising: Executed by the control unit, a definition management generation step of generating a definition management table, which is a table for defining and managing the operations, based on test scenario data in which information required for performing the tests is written as tabular text data; an operation command generation step of generating a screen operation command table, which is a table for storing commands related to automatic screen operations to be executed during the test, based on the test scenario data; Including, The test scenario data includes information that outlines the test, setting information that is the basis of the application to be tested, which is a UI definition, information for operating the application, which is a screen operation command, and information on confirmation items corresponding to screenshots; the definition management table includes screen variable information, layout information, control information, action information, logic flow information, and event setting information in the test scenario data, The definition management generation step virtually generates and registers definition data of an application from setting information that is the basis of the application to be tested, which is the UI definition of the test scenario data; the operation instruction generating step generates and registers a screen operation definition required for automatically operating the application from information for operating the application, which is a screen operation instruction of the test scenario data; A method for efficiently preparing for tests.
7. A test preparation efficiency improvement program for an information processing device having a control unit, which can improve the efficiency of preparations required to test an operation automatically executed on a screen, To cause the control unit to execute a definition management generation step of generating a definition management table, which is a table for defining and managing the operations, based on test scenario data in which information required for performing the tests is written as tabular text data; an operation command generation step of generating a screen operation command table, which is a table for storing commands related to automatic screen operations to be executed during the test, based on the test scenario data; Including, The test scenario data includes information that outlines the test, setting information that is the basis of the application to be tested, which is a UI definition, information for operating the application, which is a screen operation command, and information on confirmation items corresponding to screenshots; the definition management table includes screen variable information, layout information, control information, action information, logic flow information, and event setting information in the test scenario data, The definition management generation step virtually generates and registers definition data of an application from setting information that is the basis of the application to be tested, which is the UI definition of the test scenario data; the operation instruction generating step generates and registers a screen operation definition required for automatically operating the application from information for operating the application, which is a screen operation instruction of the test scenario data; A test preparation efficiency program featuring:
Citation Information
Patent Citations
Automatic generation device of program for verification, and method and program thereof
JP2009205242A
Software task processing test simplification device
JP2014056388A
Application test support apparatus, data processing method thereof, and program
JP2016048470A
System and method for automated generation of test cases and test data for validating a software application
US20220091968A1