Patent Application
20220229767
The present invention relates to a test script generation device, a test script generation method, and a program.
In order to promptly provide services that meet diverse needs of consumers there has been, in recent years, an increase in the development style of developing software in short cycles and frequently releasing services. With services being provided in short cycles, there has also been an increase in the frequency of software testing to confirm that software is normally operated. In the software testing, function tests are performed to confirm whether a web application under test operates as intended by a designer. However, the function tests may take a huge amount of time for a test made by combining a plurality of functions (hereinafter, referred to as a “scenario test”).
At this point, a collection of one or more screens is defined as a function. The scenario test takes the time not only because a lot of contents are executed in one test due to a test combined a plurality of functions, but also because interaction from a client side requires operation with human intervention such as click operation of a link or a button on a screen or input of an appropriate value in an input form. Because these operations are repeatedly performed on all screens, it takes a huge amount of time, and thus labor saving is required.
As a method for reducing time required for the test, a method for automatically executing the test by producing a test case as a script is widely known (Non Patent Literature 1). However, creating a test script also takes time, and it is generally said that the effect of task time does not appear unless automated testing using a created test script is performed three times or more. In addition, because a created test script cannot be used when a change is applied to an existing function, it is necessary to create a test script every time a specification is changed.
In order to solve such problems, there is a reverse-based test script automated generation technique (hereinafter, referred to as a “reverse-based test technique”) that restores specification information by analyzing a web application to be tested and automatically generates the test script from the restored specification information (Non Patent Literature 2).
In the reverse-based test technique, crawling is performed such that the screen transition under test is covered, and operations in performing the crawling are output as the script, so that a test script that performs the test covering screen transitions can be automatically generated. It is theoretically possible to automatically generate the test script for the scenario test by applying the reverse-based test technique to perform the crawling so as to cover a combination of functions.
However, generating the test script by performing crawling to cover a combination of functions is not practical because it is too time-consuming. For example, there are 27,000 patterns for combining 3 functions chosen from 30 functions. As the pattern increases explosively depending on the number of functions and the number of combinations, it is not efficient to apply the reverse-based test technique as is to the scenario test.
In view of the foregoing, an object of the present invention is to streamline the application test that provides the function by the screen transition.
In order to solve the above problem, a test script generation device includes: an identifying unit configured to identify a path through a screen specified by a user in a screen transition diagram; and a generation unit configured to generate a test script based on a combination of a value input to a transition source screen in generation of the screen transition diagram for a transition included in the path and an operation related to the transition.
Testing of applications that provide functionality through screen transitions can be streamlined.
An embodiment of the present disclosure will be described below with reference to the drawings. In the embodiment, a user specifies a screen and a transition sequence that indicate a scenario (defined as a set of consecutive screens and transitions) to be tested for a Web application, and a test script implementing only the scenario is automatically generated with the reverse-based test technique, thereby automatically generating the test script of the scenario test within a real time. In this case, there are two technical problems.
Technical problem (1): How a user specifies what scenario to be tested?
Technical problem (2): How to generate the test script corresponding to the specified scenario?
Technical Problem (1) is solved by presenting a screen transition diagram obtained by restoring a specification to be tested using the reverse-based test technique disclosed in Non Patent Literature 2 to the user, and specifying the scenario to be tested through the screen transition diagram by the user.
Technical Problem (2) is solved by storing an input value and operation in each screen transition performed during the crawling in the reverse-based test technique, combining the input value and the operation in accordance with the specified scenario to create an operation row, and outputting the operation row as a test script.
A test script generation device 10 that performs the above description will be described in detail below.
A program implementing processing in the test script generation device 10 is provided by a recording medium 101 such as a CD-ROM. When the recording medium 101 in which a program is stored is set in the drive device 100, the program is installed in the auxiliary storage device 102 from the recording medium 101 through the drive device 100. However, the program is not necessarily installed by the recording medium 101, and may be downloaded from another computer through a network. The auxiliary storage device 102 stores the installed program and stores necessary files, data, and the like.
When an instruction for starting a program is given, the memory device 103 reads the program from the auxiliary storage device 102 and stores the program. The CPU 104 implements a function relevant to the test script generation device 10 in accordance with the program stored in the memory device 103. The interface device 105 is used as an interface for connection to a network. The display device 106 displays a graphical user interface (GUI) or the like based on the program. The input device 107 is constituted by a keyboard, a mouse, and the like, and is used for inputting various operation instructions.
A processing procedure executed by the test script generation device 10 will be described below.
In step S101, the specification information restoring unit 11 restores specification information to an application to be tested (hereinafter, referred to as a “target application”), and generates a screen transition diagram. The generation of the screen transition diagram may be performed using known reverse-based test techniques (Non Patent Literature 2). For example, the generated screen transition diagram is displayed on the display device 106.
The specification information restoring unit 11 stores an input value and operation information for each screen transition performed during the crawling for generating the screen transition diagram, for example, in the auxiliary storage device 102. The input value refers to the value entered with respect to the transition source screen. The operation information refers to information indicating an operation that triggers the screen transition. For example, in a login screen, values are entered into input forms of a user ID and a password, and then a login button is clicked. In this case, the information regarding each operation of inputting the values and clicking the login button is stored as the operation information, and the values entered into the input forms of the user ID and the password are stored as the input value set while associated with information indicating the transition performed in response to the operation (hereinafter, referred to as “transition information”). Hereinafter, an example of the operation information and input value set stored in association with the transition information for the transition from the login screen to successful login (transition from “login” to “login success” in
driver.findElement (By.id (“id of login ID input form”)).sendKeys (value 1);
driver.findElement (By.id (“id of password input form”)).sendKeys (value 2);
driver.find_element (:xpath, “xpath of login button”).click
Input value set
Value 1: abcd
Value 2: aaaa1234
Each of the operation information and the input value set is stored in association with the transition corresponding to the operation information and the input value set.
Subsequently, the test information acquisition unit 12 performs a modification of the information (operation information, input value set, and the like) stored in the screen transition diagram (
Input value set
[Normal account]
Value 1: abcd
Value 2: aaaa1234
[Administrator account]
Value 1: xxxyyyzzz
Value 2: xyz1111
Note that in the above description, the “normal account” is the name assigned to the first input value set and the “administrator account” is the name assigned to the second input value set.
Subsequently, the test information acquisition unit 12 receives the specification of the scenario to be tested by the user through the screen transition diagram (S103). The receipt of the specification is performed by selection of the screen included in the screen transition diagram. The transition may also be selected as well as the screen. However, not all screens and transitions constructing the scenario need to be specified, and some screens and transitions may be omitted. For example, in the embodiment, the scenario in which the user wants the test is supposed to be the following four patterns.
(a) Top→login→(login in normal account)→login success→TOP→membership registration→membership registration (second page)→membership registration (confirmation screen)
(b) Top→login→(login in administrator account)→login success→TOP→membership registration→membership registration (second page)→membership registration (confirmation screen)
(c) Top→login→(login in normal account)→login success→TOP→membership registration→membership registration (input error)→membership registration (second page)→membership registration (confirmation screen)
(d) Top→login→(login in administrator account)→login success→TOP→membership registration→membership registration (input error)→membership registration (second page)→membership registration (confirmation screen)
In the above description, the transition to top is included in the middle of the process, but the transition from the node (terminal screen) at the terminal end of the screen transition diagram to the top is omitted for convenience in
In step S103, the operation may be performed to enable only one input value set for a transition in which a plurality of input value sets are set. In this case, for example, when the transition is right-clicked in the screen transition diagram, a menu ml that includes a list of input value sets stored in association with the transition information of the transition is displayed as illustrated in
Subsequently, the test script generation unit 13 identifies all paths (scenarios) in the screen and transitions specified by the user (between the paths through (1) to (5) in
Such complement will automatically generate all four pattern scenarios (a) to (d) to generate this test script, even if the specification as in
Subsequently, the test script generation unit 13 generates a test script that satisfies each specified scenario. Specifically, for each specified scenario, the test script generation unit 13 combines the input values and the operation information in each transition stored in step S101 to exhaustively generate an operation row implementing the specified scenario, and outputs the test script including the operation row (S105).
Subsequently, details of step S101 will be described.
In step S201, the specification information restoring unit 11 acquires an initial uniform resource locator (URL) of a target application. The term “initial URL” refers to a URL for a screen serving as a starting point in screen transition of the target application. The initial URL may be input by a user at timing of step S201, or may previously be stored in the auxiliary storage device 102 or the like.
Next, the specification information restoring unit 11 acquires display data (such as HTML data) of an initial screen corresponding to the initial URL by accessing a target URL, and uses a Web browser to display the initial screen on the display device 106 based on the display data (S202). In the example of
Subsequently, the specification information restoring unit 11 executes loop processing L1 including steps S203 to S207 for each of all transition destination screens. Hereinafter, a screen which is a processing target in the loop processing L1 is referred to as a “target screen”. Initially, the initial screen becomes the target screen.
In step S203, the specification information restoring unit 11 stores screen information (HTML, title, identification information, and the like) of the target screen in the auxiliary storage device 102. Then, when the target screen is not a terminal screen (Yes at S204), steps S205 to S207 are performed.
In step S205, the specification information restoring unit 11 automatically operates the target screen to make the transition of the screen. At this time, in the case where the input of the value is required for the target screen, the input value is automatically generated using known technique (for example, Non Patent Literature 2). Subsequently, the specification information restoring unit 11 acquires the display data of the screen corresponding to the URL of the transition destination by accessing the URL, and uses the Web browser to display the screen on the display device 106 based on the display data (S206). Subsequently, the specification information restoring unit 11 stores the operation information indicating the operation in step S205, the input value set related to the operation, and transition information related to the transition performed in response to the operation in the auxiliary storage device 102. For example, the transition information is information that includes identification information of each screen of the transition source and the transition destination.
When the loop processing L1 is executed for all the transition destination screens, the specification information restoring unit 11 generates the screen transition diagram based on screen information, transition information, input value sets, and operation information stored for each screen or each transition, and outputs (displays) the screen transition diagram (S208).
As described above, according to the embodiment, the test script corresponding to the screen and the transition sequence specified by the user is automatically generated. In other words, the scenario that is subject to the automatically generated test script is limited to the scenario specified by the user. As a result, the test of application that provides the functionality through the screen transition can be streamlined.
The embodiment may be applied to an application other than the Web application as long as the application provides the function by the screen transition.
In the embodiment, the test script generation unit 13 is an example of the identifying unit and the generation unit. The test information acquisition unit 12 is an example of the receiving unit.
Although the embodiment of the present invention has been described above, the present invention is not limited to such specific embodiments, and can be modified and changed variously without departing from the scope of the invention described in the appended claims.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/JP2019/021551 | 5/30/2019 | WO | 00 |
