Test support system, and test support method

Abstract

To provide a test support system capable of supporting the creation of source code to automate tests.SOLUTION: A test support system 100 includes: a test scenario creation terminal 10 that creates a test scenario 13 that prescribes the test procedure for a test target system 40 using a set of test operation steps; and a test control device 30 that controls the test on the test target system 40 by executing the operation steps read from the test scenario 13. The test scenario creation terminal 10 creates a test scenario 13 by inputting operation steps selected from a set of operation steps and placing them in order on the editing screen.SELECTED DRAWING: Figure 1

Description

[Technical Field]

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

[0002] In UI (User Interface) testing, testers operate web browsers directly to check the operation of web systems, etc. Automating this manual testing reduces human error and improves testing efficiency.

[0003] For example, Patent Document 1 describes a GUI test support system that includes an OS (Operating System), an application program having an input operation unit controlled by the OS and an OS-based GUI (Graphical User Interface) and a web GUI to be tested, a test execution tool that executes testing of the application program according to an object description method, and a storage device that has a test script file that stores a test script obtained by the test execution tool. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Japanese Patent Application Laid-Open No. 2008-40537 Summary of the Invention [Problem to be solved by the invention]

[0005] The tester must create source code that specifies what operations to perform and in what order for the test execution tool of Patent Document 1. For example, when automating the operation "click button A," how to express the object name "button A" and the operation name "click" in the source code requires specialized programming knowledge.

[0006] The present invention has been made in consideration of the above circumstances, and its main object is to support the creation of source code for automating tests. [Means for solving the problem]

[0007] In order to solve the above problems, the test support system of the present invention has the following features. The present invention provides a test scenario creation terminal that creates a test scenario that defines a test procedure for a system under test by using a set of test operation steps; a test control device that controls a test on the system under test by executing the operation steps read from the test scenario, The test scenario creation terminal creates the test scenario by inputting the operation steps selected from the set of operation steps to be arranged in order on an editing screen. Other features will be described later. [Effects of the Invention]

[0008] According to the present invention, it is possible to assist in creating source code for automating testing. [Brief explanation of the drawings]

[0009] [Figure 1] FIG. 1 is a configuration diagram of a test support system according to an embodiment of the present invention. [Figure 2] FIG. 10 is an explanatory diagram of a case in which one test scenario is processed in parallel by multiple servers according to the present embodiment. [Figure 3] FIG. 10 is an explanatory diagram of a case where a plurality of test scenarios are processed in parallel according to the present embodiment. [Figure 4] FIG. 10 is a screen diagram showing an input screen for common settings according to the present embodiment. [Figure 5] FIG. 10 is a screen diagram showing an input screen for setting Web driver options according to the present embodiment. [Figure 6]FIG. 10 is a screen diagram showing a test scenario input screen according to the present embodiment. [Figure 7] FIG. 2 is a screen diagram showing a first example of a test scenario input support screen according to the present embodiment. [Figure 8] FIG. 10 is a screen diagram showing a second example of a test scenario input support screen according to the present embodiment. [Figure 9] FIG. 9 is a screen diagram related to the second example of FIG. 8 according to this embodiment. [Figure 10] 10 is a flowchart showing a main process for executing a test scenario according to the present embodiment. [Figure 11] 10 is a flowchart showing details of a process for supplementing a test scenario with authentication information according to the present embodiment. [Figure 12] 10 is a flowchart showing details of a process for step-executing a test scenario according to the present embodiment. [Figure 13] 13 is a flowchart showing details of an operation step for saving a screenshot, among the processing steps executed in FIG. 12 according to this embodiment. [Figure 14] 13 is a flowchart showing details of the operation steps of selecting a desired screen such as an authentication screen from a plurality of currently displayed screens, among the processing steps executed in FIG. 12 according to this embodiment. [Figure 15] FIG. 2 is a hardware configuration diagram of each device of the test support system according to the present embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0010] Hereinafter, an embodiment of the present invention will be described with reference to the drawings.

[0011] FIG. 1 is a diagram showing the configuration of a test support system 100. The test support system 100 is configured by connecting a test scenario creation terminal 10, a storage device 20, a test control device 30, and a test target system 40 via a network. The test scenario creation terminal 10 defines a test procedure for the test target system 40 by a set of test operation steps. Therefore, the test scenario creation terminal 10 creates a test scenario 13 by inputting operation steps selected from the set of operation steps and arranging them in order on an editing screen. The test control device 30 controls the test on the system under test 40 by executing the operation steps read from the test scenario 13 . The test target system 40 and the system to be tested include, for example, a Web server 41 and an authentication server 42 .

[0012] The test scenario creation terminal 10 includes a spreadsheet 11, a test scenario editing unit 12, and a test scenario 13. The spreadsheet 11 is table data generated by spreadsheet software such as Excel (registered trademark). The test scenario editing unit 12 is provided with a table editing function of the spreadsheet software that handles the spreadsheet 11, as well as a support function that assists in editing the spreadsheet 11 using the macro function of the spreadsheet software. The test scenario 13 is a source code for automating a test, which is a spreadsheet 11 edited by the test scenario editing unit 12 and converted into text format by the macro function of the spreadsheet software, and is saved as a test scenario 21 in the storage device 20. The data format of the test scenario 13 is, for example, a format of a human-readable data description language such as YAML (Yet Another Markup Language).

[0013] The storage device 20 stores a test scenario 21, an execution log 22, authentication information 23, and a screenshot 24 as various data used in the test. The test scenario 21 and authentication information 23 are files input to the test control device 30 for testing, and are prepared by the tester before the test. The execution log 22 and screenshot 24 are output files generated by the test control device 30 as test results. The tester can use these output files in system operation and maintenance work as evidence to confirm the soundness (normal operation) of the system 40 under test.

[0014] The test control device 30 is a test execution environment that includes a UI test execution unit 31, a UI automatic operation unit 32, and a browser web driver 33. The test control device 30 may use a server that is owned by the tester and managed by the tester, or may use a server that is available via a network as a cloud server such as AWS (Amazon Web Services, registered trademark) (a serverless architecture that does not use a private server). The UI test execution unit 31 executes the UI test by calling each operation step of the UI test described in the read test scenario 21 to the UI automatic operation unit 32. Furthermore, when testing an operation that requires authentication information, such as a password input operation, the UI test execution unit 31 uses the authentication information 23 acquired via the authentication information acquisition unit 31A. In this way, by separating the test scenario 21 and the authentication information 23 and not directly entering passwords and the like in the test scenario 21, security is enhanced. The UI test execution unit 31 also includes a screenshot creation unit 31B for recording the display screen during execution of the UI test as a screenshot 24 in the storage device 20.

[0015] The UI automatic operation unit 32 executes each operation step instructed by the UI test execution unit 31, thereby inputting an automatic operation signal to the browser web driver 33. The UI automatic operation unit 32 is implemented as a software framework for automating the operation of a web browser, such as Selenium. The browser web driver 33 receives an automatic operation signal from the UI automatic operation unit 32 and operates the UI in the same way as manual operations (mouse clicks, character input, etc.) by the tester, thereby generating data access to the system under test 40. The browser web driver 33 is implemented as a program that controls the operation of a web browser that uses the W3C WebDriver protocol, such as Microsoft Edge WebDriver.

[0016] FIG. 2 is an explanatory diagram of a case where one test scenario 21 is processed in parallel by a plurality of servers. The UI test execution unit 31 reads the first test data 29A, in which the test scenario 21 and the authentication information 23 (omitted in FIG. 2) are associated with each other, from the storage device 20, and executes the UI test according to the contents of the first test data 29A. Here, the test scenario 21 of the first test data 29A includes both an operation step for the Web server 41 and an operation step for the authentication server 42. One UI test execution unit 31 can process one test scenario 21 in parallel on multiple servers by expanding each operation step of the test scenario 21 into predetermined processing content and instructing the UI automatic operation unit 32. As a result, the UI test execution unit 31 stores the execution log 22 (omitted in FIG. 2) and the screenshot 24 as the execution results of the UI test in the first test data 29A.

[0017] FIG. 3 is an explanatory diagram of a case where a plurality of test scenarios 21 are processed in parallel. 2, the test control device 30 handles one first test data 29A, but in Fig. 3, the test control device 30 handles three test data (first test data 29A, second test data 29B, and third test data 29C) simultaneously. Therefore, a UI test execution unit 31 is required for each test data to control the execution of the test scenario 21.

[0018] Therefore, the test control device 30 creates a first container 39A that forms a UI test execution unit 31 that exclusively handles the first test data 29A, a second container 39B that forms a UI test execution unit 31 that exclusively handles the second test data 29B, and a third container 39C that forms a UI test execution unit 31 that exclusively handles the third test data 29C from the same container image 38. That is, when the test control device 30 executes multiple test scenarios 13 in parallel, it forms the UI test execution units 31 that execute each test scenario 13 as separate containers. This allows the UI test execution units 31 of each container to process three test scenarios 21 simultaneously without interfering with the processing of other containers.

[0019] The container image 38 is a package (standalone executable file) that compiles information necessary for running a container. The container image 38 includes libraries, dependencies, and files necessary for running the container. A container is an application execution unit and an isolated execution environment created from a container image at runtime. When a new container is started for each execution, the container is usually discarded when the processing ends, and the processing content executed within it is lost unless it is properly saved externally. On the other hand, the test control device 30 of this embodiment starts the UI test execution unit 31 separately for each container, allowing multiple test scenarios 21 for multiple servers to be processed in parallel.

[0020] 4 to 9, the following describes each process executed by the test scenario creation terminal 10 as preparation for executing the test scenario 21. This preparation includes not only the process in which the test scenario creation terminal 10 creates the test scenario 21, but also the process in which the test scenario creation terminal 10 creates various settings to be used when executing a UI test.

[0021] FIG. 4 is a screen diagram showing the input screen for common settings. Common settings are settings that are commonly used when the UI test execution unit 31 executes any test scenario 21. Common settings include, for example, parameters such as the wait time for screen rendering (page load) and the wait time for JavaScript timeout. The screen diagram in FIG. 4 includes a reference table 211 that is prepared and displayed in advance, and a common setting edit field 212 in which the tester enters settings while referring to the reference table 211. In the reference table 211, a setting name (logical), a setting name (physical), a data type, a required field, and a setting description are associated with each other for each record number (#). For example, the record number (#=1) is associated with a setting name (logical) called element search timeout, a setting name (physical) called implicitly_wait, a data type called String (character string type), an optional blank field, and a setting description that reads, "Set the maximum wait time (seconds) until an element of the specified driver is found."

[0022] The common setting edit field 212 is a text box in which the tester enters common settings. For example, the tester who referenced the record number (#=1) in the reference table 211 enters "implicitly_wait:10" to indicate that the element search timeout has been set to 10 seconds. Note that parameter values ​​defined by default may also be displayed in the reference table 211. This allows even testers who are not familiar with programs to enter appropriate parameter values, making it possible to perform UI tests of a certain quality.

[0023] FIG. 5 is a diagram showing an input screen for setting Web driver options. Web driver option settings are settings used when the browser Web driver 33 is running. Web driver option settings include, for example, display size and proxy server settings for access. The screen diagram in Figure 5 includes a reference table 221 that is prepared and displayed in advance, and a Web driver option setting edit field 222 in which the tester enters information while referring to the reference table 221. In the reference table 221, an option name, a setting name (physical), a data type, a required item, and an option description are associated with each other for each record number (#).

[0024] For example, record number (#=1) corresponds to an option name of "disable sandboxing," a setting name (physical) of "--no-sandbox," a data type of "String," a required check mark, and an option description of "Disables sandboxing for all process types that are normally sandboxed." The Web driver option setting editing field 222 is a text box in which the tester enters the Web driver option settings. For example, the tester who referenced the record number (#=1) in the reference table 221 enters "--no-sandbox-" to indicate that the sandbox has been disabled.

[0025] FIG. 6 is a diagram showing an input screen for the test scenario 13. As shown in FIG. The screen diagram of FIG. 6 includes a test procedure display field 231 that is prepared and displayed in advance, and a test scenario editing field 232 into which the tester inputs data while referring to the test procedure display field 231. The test procedure display field 231 displays an explanation of each operation step of a UI test, such as executing the second step "2. Access the URL of system A" after the first step "1. Launch a web browser." These explanations indicate the test procedures that originally exist for each system under test 40, based on rules of thumb and standard manuals used in conventional manual execution. The test scenario 13 is source code for automating the test procedures.

[0026] The test scenario 13 input in the test scenario editing field 232 is executed in order from top to bottom for each operation step to which a step ID is assigned. Each operation step is associated with a set of parameters. For example, the operation step with step ID=302 uses three parameters: [type: "NAME"], [target: "identifier"], and [secret_name: "Secret_01"]. The step IDs written in the test scenario 13 are IDs for identifying which operation steps are to be executed, and the operation steps are selected from a set of operations such as waiting, screen drawing, etc. This allows the tester to easily write the test scenario 13 by simply writing it as a step ID in the test scenario 13, even if they do not know the command statement corresponding to a specific operation such as "click a button."

[0027] FIG. 7 is a screen diagram showing a first example of an input support screen for the test scenario 13. As shown in FIG. In the screen diagram of Figure 6, the tester manually inputs the text of test scenario 13, which requires the tester to have programming knowledge and the cost of inputting the data is high. Therefore, in FIG. 7, the test scenario editing unit 12 replaces the editing fields so that the tester enters the execution sequence number (#), step ID (step_id), and parameters used in the operation step in correspondence with each other in the tabular test scenario editing sheet 242 (spreadsheet 11 in FIG. 1).

[0028] Furthermore, in FIG. 7, a reference table 241 may also be displayed for the tester to refer to so that the tester can input the step IDs and their parameters into the test scenario editing sheet 242 even if the tester does not know them. In the reference table 241, a function classification, a step name, a SID (step ID), a description, a parameter, and a setting example are associated with each operation step. For example, the operation step with SID (step ID) = 101 corresponds to the function classification "window operation," the step name "open specified URL in browser," the explanation "open specified URL in browser (GET)," the requirement to set the parameter "target_url: URL to access," and the setting example "target_url: "https: / / X.co.jp / "." As described above in FIG. 7, the test scenario creation terminal 10 may create the test scenario 13 via a tabular editing screen in which the ID (i.e., SID) of each operation step selected from a set of operation steps and the parameter set used by each operation step are used as column elements, and the execution order of each operation step is used as row elements.

[0029] FIG. 8 is a screen diagram showing a second example of the input support screen for the test scenario 13. In FIG. In the screen diagram of FIG. 7, the tester inputs characters into a test scenario editing sheet 242 showing the contents of the test scenario 13, which requires a relatively high input cost. 8, the test scenario editing unit 12 provides an editing field in which the tester selects candidate operation steps listed on the test step selection screen 110, orders them on the test step editing screen 120, and performs a drag-and-drop operation 123. For example, the tester drags the operation step "0101: Open specified URL in browser" from the test step selection screen 110 and drops it onto the beginning 124 of the test procedure on the test step editing screen 120 (immediately after "Start").

[0030] As described above in FIG. 8, the test scenario creation terminal 10 may create a test scenario 13 via an editing screen in which each operation step selected by dragging from a set of operation steps is dropped into a position corresponding to the execution order. This allows the tester to reduce the time and effort required to enter the step ID (ID of the operation step) as characters. The test step editing screen 120 also includes an export button 122 for temporarily saving the test scenario 13 being edited, and an import button 121 for loading the temporarily saved test scenario 13.

[0031] In this way, the test scenario editing sheet 242 in FIG. 7 and the test step editing screen 120 in FIG. 8 each correspond to an example of an "editing screen" when the test scenario creation terminal 10 creates a test scenario 13 by inputting each operation step selected from a set of operation steps and arranging them in order on the editing screen.

[0032] FIG. 9 is a screen diagram related to the second example of FIG. The screen shot of FIG. 9 is closely related and is displayed together with (eg, on the same screen as) the screen shot of FIG. The parameter setting screen 130 is a screen for setting parameters for each operation step added to the test step editing screen 120, and for example, it is assumed that the head position 124 in FIG. 8 is double-clicked. In this case, the test scenario editing unit 12 displays a data table for the tester to input a parameter value 132 of the parameter name 131 “target_url” required to execute the operation step “0101: Open specified URL in browser.” The tester inputs a parameter such as “https: / / X.co.jp / ” into the cell for the parameter value 132.

[0033] Based on the input data to the test scenario editing sheet 242 or the step ID and its parameters read from the input data on the test step editing screen 120 and the parameter setting screen 130, the test scenario editing unit 12 uses the macro function of the spreadsheet software to convert the data so that it has the same format as the test scenario 13 entered in the test scenario editing field 232 in Figure 6.

[0034] The test simulation screen 140 displays a screen showing the results of the UI test execution unit 31 executing the test scenario 13 inputted to the test step editing screen 120 . The test simulation screen 140 includes buttons for controlling the execution of the UI test execution unit 31, such as a play button 141 for starting the execution, a pause button 142 for pausing the execution, and a stop button 143 for stopping the execution. In the execution example of Figure 9, a text box 145 and a search button 146 are displayed in a test target screen 144, and the UI test execution unit 31 executes, for example, an operation step of entering search characters into the text box 145 and an operation step of clicking the search button 146, as described in the test scenario 13.

[0035] FIG. 10 is a flowchart showing the main process for executing the test scenario 21. This main process is executed at a predetermined timing, for example, automatically every month, after applying a patch to the server, etc. Furthermore, as arguments given when starting this main process, paths in the storage device 20 indicating the storage destinations of each file for each test data such as the first test data 29A (path of the test scenario 21, path of the execution log 22, path of the authentication information 23, and path of the screenshot 24) are given by the tester. The test control device 30 starts the UI test execution unit 31 by importing the standard library and Selenium (S11).

[0036] The UI test execution unit 31 acquires parameters used to execute the UI test from the storage device 20 (S12), and also acquires the test scenario 21 (S13). The authentication information acquisition unit 31A supplements the test scenario 21 of S13 with the authentication information 23 read from the storage device 20 (S14, details in FIG. 11). After initializing the browser Web driver 33 (S15), the UI test execution unit 31 executes a loop (S21 to S23) in which it selects Web driver options (see Figure 5) one by one and sets the selected Web driver options in the browser Web driver 33 (S22). The UI test execution unit 31 sets options for the test scenario 21, such as the common settings in FIG. 4 (S24).

[0037] The screenshot creation unit 31B initializes the screenshot 24 (S25). After executing the operation steps of the test scenario 21 (S26, see FIG. 12 for details), the UI test execution unit 31 terminates the browser Web driver 33 (S27).

[0038] FIG. 11 is a flowchart showing the details of the process (S14) of supplementing the test scenario with authentication information. The authentication information acquisition unit 31A defines the variables of the authentication information 23 (S141), and then acquires the authentication information 23 from the storage device 20 (S142). If a secret string exists in the test scenario 21 (S143, Yes) and a secret key that replaces that secret string exists in the authentication information 23 (S144, Yes), the authentication information acquisition unit 31A complements (replaces) the secret key of the authentication information 23 with the secret string of the test scenario 21 (S145).

[0039] For example, the secret character string is a character string such as "***" that conceals the input characters of the password, and the secret key is the input characters of the password that is actually used. On the other hand, if the answer is No in S143 or No in S144, the authentication information acquisition unit 31A executes error processing such as displaying a message that the authentication information 23 cannot be acquired (S146). In this way, when a secret character string exists in an operation step read from the test scenario 13, the test control device 30 replaces the secret character string with a secret key read from authentication information 23 other than the test scenario 13, and then executes the operation step.

[0040] FIG. 12 is a flowchart showing the details of the process (S26) of step-executing the test scenario. The UI test execution unit 31 executes a loop in which the operation steps (step IDs) described in the test scenario 21 are selected in order (S260A to S260B). Within this loop, UI test execution unit 31, depending on the currently selected step ID (S261A to S266A), searches for and executes the step process corresponding to that step ID from reference table 241 (S261B to S266B). If the currently selected step ID is not registered in reference table 241 (No in all of S261A to S266A), UI test execution unit 31 executes error processing, such as notifying the user that the step ID number has been entered incorrectly (S267).

[0041] FIG. 13 is a flowchart showing the details of the operation step for saving the screenshot among the processing steps executed in FIG. Screenshot creation unit 31B executes a loop of selecting each screen as a subject to be captured from the beginning to the end of the screen (S301 to S305), and then returns the scroll to the beginning of the screen (S306). In this loop, the screenshot creation unit 31B scrolls the currently selected screen to the capture position (S302), waits until the scrolling is completed (S303), and acquires (takes) the screenshot 24 (S304).

[0042] As a result, after the UI test execution unit 31 executes the test scenario 21, the execution result is lost from a workspace such as a memory, but before that, the screenshot 24 can be saved as an image file in the storage device 20. Similarly, by describing the operation step for saving the execution log 22 in the test scenario 21, the UI test execution unit 31 can save the execution result in the storage device 20 as a file of the execution log 22. The operation steps of the test scenario 21 may include a process for saving the screen during test execution as a screenshot, and a process for saving the state during test execution as an execution log.

[0043] FIG. 14 is a flowchart showing details of the operation steps of the process executed in steps in FIG. 12, in which a desired screen such as an authentication screen is selected from the multiple screens currently being displayed. The UI test execution unit 31 acquires a list of windows that exist during test execution, such as the test target screen 144 in FIG. 9, from the browser Web driver 33 (S311). The UI test execution unit 31 executes a loop in which windows included in the window list of S311 are selected in order (S312 to S314). In this loop, if the title of the window being washed matches the title of the desired screen (S313, Yes), the UI test execution unit 31 breaks the loop (S315), allowing the UI test execution unit 31 to transition to a state in which the desired screen is selected.

[0044] FIG. 15 is a diagram showing the hardware configuration of each device in the test support system 100. Each device of the test support system 100 (test scenario creation terminal 10, storage device 20, test control device 30, and test target system 40) is configured as a computer 900 having a CPU 901, RAM 902, ROM 903, HDD 904, communication I / F 905, input / output I / F 906, and media I / F 907. The communication I / F 905 is connected to an external communication device 915. The input / output I / F 906 is connected to an input / output device 916. The media I / F 907 reads and writes data from a recording medium 917. Furthermore, the CPU 901 executes a program (also called an application or an app for short) loaded into the RAM 902 to improve and control each processing unit. This program can be distributed via a communication line or recorded on a recording medium 917 such as a CD-ROM and distributed.

[0045] The test support system 100 of this embodiment described above allows the tester to easily input the input data required to write the test scenario 21 by using the test scenario editing sheet 242 in Figure 7, the test step editing screen 120 in Figure 8, the parameter setting screen 130 in Figure 9, etc. This allows the test control device 30 to reduce the effort required to directly input the test scenario 13 in source code format into the test scenario editing field 232 in Fig. 6. In other words, the test control device 30 can provide a means for inputting the test scenario 13 without using code.

[0046] Specifically, a tester can easily create a test scenario 13 by simply setting parameters via the test scenario editing unit 12, without having to develop a program himself or ask a system engineer to develop a program. The step IDs included in this test scenario 13 identify each operation step, including waiting for screen rendering when a UI test is executed. In addition, by referencing the parameters defined by default for each operation step, a tester can execute a UI test of a certain quality even if he or she is not familiar with programming.

[0047] Furthermore, the present invention is not limited to the above-described embodiments, and various other applications and modifications are possible without departing from the spirit of the present invention as defined in the claims. For example, the above-described embodiments provide a detailed and specific description of the configuration of the test support system 100 in order to clearly explain the present invention, and the system is not necessarily limited to systems that include all of the components described. Furthermore, it is possible to replace part of the configuration of one embodiment with a component of another embodiment. It is also possible to add a component of another embodiment to the configuration of one embodiment. It is also possible to add, replace, or delete other components from part of the configuration of each embodiment.

[0048] Furthermore, the above-described configurations, functions, processing units, etc. may be partially or entirely implemented in hardware, for example, by designing them as integrated circuits. As the hardware, a broad processor device such as an FPGA (Field Programmable Gate Array) or an ASIC (Application Specific Integrated Circuit) may be used. Furthermore, each component of the test support system 100 according to the above-described embodiment may be implemented in any hardware as long as the respective hardware can transmit and receive information to and from each other via a network. Furthermore, the processing performed by a certain processing unit may be realized by a single piece of hardware, or may be realized by distributed processing using multiple pieces of hardware. [Explanation of symbols]

[0049] 10 Test scenario creation terminal 11. Spreadsheets 12 Test Scenario Editorial Department 13 Test Scenarios 20 Storage Devices 21 Test Scenarios 22 Execution Log 23 Authentication Information 24 Screenshots 30 Test control device 31 UI Test Execution Unit 31A Authentication Information Acquisition Unit 31B Screenshot Creation Department 32 UI automatic operation section 33 Browser Web Driver 40 Systems Under Test 41 Web Server 42 Authentication Server 100 Test Support System 120 Test step editing screen

Claims

1. a test scenario creation terminal that creates a test scenario that defines a test procedure for a system under test by a set of test operation steps; a test control device that controls a test on the system under test by executing the operation steps read from the test scenario, The test scenario creation terminal creates the test scenario by inputting the operation steps selected from the set of operation steps to be arranged in order on an editing screen. Test support system.

2. When a secret character string exists in the operation step read from the test scenario, the test control device replaces the secret character string with a secret key read from authentication information other than the test scenario, and then executes the operation step. The test support system according to claim 1 .

3. The operation step includes a process of saving a screen during test execution as a screenshot, and a process of saving a state during test execution as an execution log. The test support system according to claim 1 .

4. When the test control device executes a plurality of the test scenarios in parallel, the UI test execution units that execute the respective test scenarios are formed as separate containers. The test support system according to claim 1 .

5. The test scenario creation terminal creates the test scenario via the editing screen in a table format in which the ID of each operation step selected from the set of operation steps and a parameter set used by each operation step are used as column elements, and the execution order of each operation step is used as row elements. The test support system according to claim 1 .

6. The test scenario creation terminal creates the test scenario via the editing screen by dragging and dropping each operation step selected from the set of operation steps to a position corresponding to the execution order. The test support system according to claim 1 .

7. The test support system includes a test scenario creation terminal and a test control device, the test scenario creation terminal, in a step of creating a test scenario that defines a test procedure for a test target system by a set of test operation steps, creates the test scenario by inputting the operation steps selected from the set of operation steps to be arranged in order on an editing screen; The test control device controls the test on the system under test by executing the operation steps read from the test scenario. Testing support methods.

Images