JP6514244B2 - Difference detection device and program - Google Patents

Description

  The present invention relates to a difference detection device and program.

  In recent years, in order to provide services meeting needs quickly, development styles for providing services in a short cycle have been increasing, and the frequency of software testing has been increasing accordingly. Under these circumstances, in Web applications, there is a problem that the screen transition test in the function test takes work. Functional test is defined according to JSTQB (Non-Patent Document 1) as “test performed based on analysis of functional specification of component (minimum unit of software that can be independently tested) or system (set of components)”. There is a test to confirm the level function, and a test to confirm the system level function.

  The screen transition test in the functional test is, among the functional tests, "a test for a function that can confirm whether or not it is implemented as specified from a screen displayed on the client side with respect to interaction from the client side". Here we define it.

  The function of screen transition test in functional test takes place because human interaction such as clicking on a link or button on the screen or entering an appropriate value in a form is required as interaction from the client side. . As a method of automating such screen transition test and aiming at operation reduction, there is widely known a method of scripting test cases and automatically executing them.

Manual scripting of test cases takes time, so the following two test script automatic generation techniques exist.
・ Automatic generation of test script using Capture and Replay technology (Non-patent document 2)
・ Automatic generation of test script by model based test (Non-patent document 3)

"JSTQB", [online], Internet <URL: http://jstqb.jp/syllabus.html> "Selenium IDE", [online], Internet <URL: https://addons.mozilla.org/ja/firefox/addon/selenium-ide/> "Proposal and Evaluation of Test Item Automatic Generation Method in Bonding Test", T. Tanno, T. Zhang, T. Hoshino, IEICE Technical Report, Oct 2010

  In the Capture and Replay technology, the user can execute a test case created manually from the specification, thereby recording the operation on the user's screen and outputting it as a test script. However, when using the Capture and Replay technology, additional operations such as tool operations for recording screen operations occur, so if you do not perform equivalent tests three or more times in general, you can not get the source of the operation. There is a drawback of that.

  In model-based testing, by describing the specifications in a form that can be read by a machine, test cases can be automatically generated from the read specifications and output as test scripts. However, there is a disadvantage that it takes additional work to describe the model.

  From the above, it can be said that the existing test script automatic generation technology has a problem that an additional operation for generating a test script occurs.

  On the other hand, when attempting to improve the efficiency of automatic generation of test scripts by reducing additional operations, it becomes a problem whether all screen transitions defined as the specifications of the test object can be extracted. That is, when there is a leak in the extraction of the screen transition which has been defined as the specification, there is a possibility that a test related to a part of the screen transition may be leaked in the automatically generated test script. Therefore, a technique for detecting screen transitions that can not be realized by automatically generated test scripts is desired.

  The present invention has been made in view of the above-described point, and an object of the present invention is to enable detection of screen transitions which can not be realized by a test script automatically generated for a Web application.

  Therefore, in order to solve the above problem, the difference detection device extracts an information of the first screen transition defined in the source code from the source code of the Web application, and a screen displayed regarding the Web application. An operation unit that operates automatically, a generation unit that generates information on a second screen transition realized by the automatic operation, and information on the first screen transition and the information on the second screen transition And a detection unit that detects a difference.

  It is possible to enable detection of screen transitions that can not be realized by test scripts that are automatically generated for Web applications.

It is a figure which shows the example of the screen to test as the same screen and a different screen. It is a figure which shows an example of Tree Edit Distance. It is a figure showing an example of system configuration in an embodiment of the invention. It is a figure which shows the example of a hardware constitutions of the client apparatus 10 in embodiment of this invention. It is a figure which shows the function structural example of the client apparatus 10 in embodiment of this invention. It is a flowchart for demonstrating an example of the process sequence which the client apparatus 10 performs. It is a figure which shows an example of static analysis. It is a figure which shows an example of a screen transition diagram. It is a flowchart for demonstrating an example of the process sequence of a production | generation process of a dictionary. It is a flowchart for demonstrating an example of the process sequence of the extraction process of screen transition information. It is a flowchart for demonstrating an example of a processing procedure of test case generation and execution processing. It is a figure which shows an example of a form. It is a flowchart for demonstrating an example of the process sequence of a production | generation process of a test input value. It is a flow chart for explaining an example of processing procedure of judgment processing of a transition destination screen. It is a figure which shows an example of a DOM tree. It is a flowchart for demonstrating an example of a process sequence of a production | generation process of a screen transition figure. It is a flowchart for demonstrating an example of the process sequence of the output process of a test script.

  Hereinafter, embodiments of the present invention will be described based on the drawings. In the present embodiment, an approach is proposed in which a specification is reversed from a test target, an exhaustive test case is automatically generated based on the reversed specification, and a test script is output as a test script. With this approach, exhaustive test scripts can be generated automatically without the need for additional operations.

In the present embodiment, since the screen transition test in the function test is targeted, the process is executed in the following steps.
(1) The test object is analyzed, and a screen and a connection between the screens constituting the test object are extracted as specifications, and means for reaching each screen are extracted.
(2) The screen transition diagram suitable for the screen transition test in the function test is generated from the specifications acquired in (1).
(3) Output the test script corresponding to each transition of the screen transition diagram generated in (2) according to the script format to be output based on the information of the means for reaching the screen extracted in (1) .

  In (1), the screen that constitutes the test object and the means for reaching that screen are extracted. In Web applications, it is common to dynamically generate screens in response to requests from the client side from files that are the origin of screens (HTML) such as jsp files. Therefore, information on what kind of screen the test object is configured and how they are connected is not directly described in the source code, so appropriate analysis is required (Technical Problem 1: Test) Consider how to reverse the specification from the subject).

  Further, also in the extraction of means for reaching the screen, in the Web application, there is a screen transition which can not be transitioned unless a specific input value is given. For example, in a system in which a telephone number is registered, there may be a case where it is not possible to transition to a registration completion screen unless it is an 11-digit half-width number. It is necessary to generate an appropriate input value for such screen transition (Technical Problem 2: Examination of an appropriate input value generation method for realizing screen transition).

  In (2), the screen transition diagram suitable for the screen transition test in the function test is generated using the screen information constituting the test object acquired in (1). The screen transition test in the function test needs to identify the screen by the function granularity. Generally, screens are identified by URLs, but even screens with the same URL may be determined to be different screens in a functional test. For example, in the search site, the screen when there is no search result and the screen when there is a search result may be the same when viewed by URL, but they are regarded as separate screens from the viewpoint of functional test . Therefore, it is necessary to perform appropriate screen identification in line with the viewpoint of functional test (Technical Problem 3: Examination of an appropriate screen identification method in functional test).

  Step (3) is a step of generating a test script in accordance with a script format desired to be output. Describe the means for reaching the screen extracted in (1) (clicks on links or buttons, input to a form, etc.) in the form of a script to be output. In this step, it is considered that there is no technical problem since only the extracted means is described by the corresponding method.

From the above, this approach is considered to have the following three technical issues.
Technical issue 1: Examination of a method to reverse the specification from the test object.
Technical problem 2: Examination of an appropriate input value generation method to realize screen transition.
Technical Problem 3: Examination of an appropriate screen identification method in functional test.

[Technical Problem 1: Examination of Method to Reverse Specifications from Test Target]
<Prior art and problems>
As a technology to reverse the specification from the application, there is a technology using static analysis (for example, "" Reconstructing Software Architecture for J2EE Web Applications ", Minmin Han, Christine Hofmeister, Robert L. Nord, Proceedings of the 10th Working Conference on Reverse Engineering 2003 "). However, the specification can not be completely reversed because it can not acquire information that can not be generated without execution, such as HTML generated dynamically from a jsp file. There are also technologies that combine static analysis and dynamic analysis to compensate for these drawbacks (eg, “Silva CE, Campos JC. 2013.“ Combining Static and Dynamic Analysis for the Reverse Engineering of Web Applications ”. Proceedings of the 5th Symposium on Engineering Interactive Computing Systems-EICS.: 107-112. In this technology, we aim to cover the behavior of Web application by identifying the paths in the program by static analysis and generating test cases that cover all the paths by dynamic analysis. However, in order to acquire a path passed by dynamic analysis, it is necessary to insert code that can acquire a log in all places where an input value can pass, and the user can The purpose of this embodiment is to reduce the additional operation for introducing a tool, because it is necessary to accurately understand the configuration and prepare an environment for outputting a log representing the place where the program has passed. Does not match. In addition, there is a possibility that the behavior may change by modifying the test target, and when a test case generated from such a test target is used for the actual test, the test scenario is different from the expected test scenario. Risk exists.

<Proposal in this Embodiment: Reverse Technology of Specifications Using Static Analysis and Dynamic Analysis Focusing on Controller>
In the present embodiment, in the configuration of a model view controller (MVC) that is a design pattern generally used in Web applications, attention is focused on a controller that determines processing to be executed for a request from the client side. For example, a servlet is an example of a controller. All the transitions allocated by the controller are grasped by static analysis, and by covering those transitions in the subsequent dynamic analysis, the screens that constitute the test object and the connection between the screens, and the means for reaching each screen are leaked It is possible to reverse without. As a difference from the conventional method, in this embodiment, since only the controller is focused, it is possible to infer the extent to which the transition destination indicated by the controller can be covered from the information on the client side. The advantage is that the operation to be prepared can be eliminated or reduced. In the conventional method of acquiring the execution path of a program, it is impossible to infer detailed information on the execution path from the client side.

[Technical Problem 2: Examination of a suitable input value generation method to realize screen transition]
<Prior art and problems>
As a method for generating appropriate input values to realize screen transition, there is a method called Concolic Testing (eg, "Concolic testing" Koushik Sen. 2007. In Proceedings of the twenty-second IEEE / ACM international conference on Automated software engineering (ASE '07). ACM, New York, NY, USA, 571-572. Concolic Testing puts input values as symbols, and obtains constraint information (path expression) for passing a path while executing a program. By solving a new path expression generated by inverting the obtained path expression using a constraint solver, it is possible to generate a test input value necessary to pass the desired path. However, because Concolic Testing is a method of tracking input values as symbols, it is necessary to obtain a log of where and how the input values are processed. In order to acquire such information, it is necessary to insert a code that can acquire a log in all the places where the input value can pass, and the user accurately grasps the system configuration from the client side to the server side. Since the environment for outputting the log must be prepared, there is a drawback that the threshold of introduction is high. In particular, on the server side, business Web applications are generally composed of various systems such as Web servers, application servers, and DB servers, and logs are acquired for all those systems. Providing a suitable environment requires many operations, which is not consistent with the purpose of the present embodiment, which aims to reduce the additional operation for introducing a tool.

<Proposal in the present embodiment: Test input value generation technology using client-side information>
Generally, in Web applications, there are the following two patterns in which screen transition is determined by input values.
(1) Normal system screen transition when an appropriate input value is input for the specification (2) For quasi-normal system screen transition (2) when an inappropriate input value is input for the specification It is empirically understood that there are many cases that can be realized by inputting random values or not giving input values. However, since it is necessary to give an appropriate input value to (1), it is highly likely that screen transition can not be realized only by giving a random test input value. In this embodiment, using client-side information, it is inferred what kind of input value is required for the input form, and the test input for (1) is given by giving an appropriate input value. Implement value generation.

[Technical problem 3: Examination of appropriate screen identification method in functional test]
<Prior art and problems>
In the present embodiment, the screen transition test in the function test is also confirmed in the function test whether “the interaction from the client side is implemented according to the specification from the screen displayed on the client side. It defines as "the test for the function which can be done". Generally, screens are identified by URLs, but in the screen transition test in this definition, it is important to test screens of the same URL as different screens depending on the screen. For example, in the search site, the screen when there is no search result as shown in FIG. 1 and the screen when there is a search result may be the same when viewed in URL, but they are different in terms of functional test Consider it as a screen. In such a case, it should be identified from the displayed screen, not the URL. However, when the screens displayed simply are compared as images, even if the functional part to be confirmed is the same, if the other parts are different, it is determined that the screens are different. Therefore, it is necessary to compare some of the elements that make up the screen, not the entire screen. The screen is mainly composed of elements such as HTML, Document Object Model (DOM) structure, text, images, and Cascading Style Sheets (CSS).

  Although the places to be focused differ depending on the test point of view, in the present embodiment, the case where the difference in function appears in the DOM structure of HTML is targeted. There is a method using Tree Edit Distance (hereinafter referred to as "TED") as an existing method for comparing DOM structures of HTML (for example, "A survey on tree edit distance and related problems" Philip Bille. 2004. Theoretical Computer Science. Volume 337, Issues 1-3, 9 June 2005, Pages 217-239.

  TED is the number of deletions / insertions when deleting / inserting nodes until both DOM trees match. For example, to match DOM tree 1 and DOM tree 2 in FIG. 2, it is necessary to delete three nodes <p>, <strong> and <U> of DOM tree 2 and insert an <img> node. Because there is, TED has a value of 4. When the threshold is 3 or less, the structures of the DOM tree 1 and the DOM tree 2 can be determined to be unmatched, and when the threshold is 4 or more, the structures of the DOM tree 1 and the DOM tree 2 can be determined to match.

As a drawback of the structure comparison of the screen using TED, it is difficult to set the threshold because the appropriate threshold is different for each screen. There are two possible causes for the need for a threshold (acceptable range for TED):
Cause 1: Existence of node that does not affect screen identification in functional test Cause 2: Existence of parallelized node Does not affect screen identification in functional test such as bold tag <b> for cause 1 It can be mentioned that nodes exist. For the cause 2, there are heading tags and the like. For example, in a news site, even if the number of headings is different, the function of displaying news is the same, so it can be said that the number of headings does not affect the function. As such, there are nodes that do not affect the screen identification, and these nodes increase the value of TED, so it is necessary to set a threshold.

<Proposal in this Embodiment: Screen Identification Technology Using Similarity of HTML DOM Structure>
In the present embodiment, the function is performed without requiring the setting of the threshold value by abstracting the HTML by deleting the nodes related to the cause 1 and aggregating the nodes related to the cause 2 and comparing the abstracted HTML. Enable appropriate screen identification in the test.

  Hereinafter, specific examples for realizing the above will be described. FIG. 3 is a diagram showing an example of a system configuration in the embodiment of the present invention. In FIG. 3, the server device 20 and the client device 10 are connected via a network such as a LAN (Local Area Network) or the Internet, for example.

  The server device 20 is one or more computers including a system to be tested including a web application.

  The client device 10 is a device that supports a test (verification) on a Web application that the server device 20 has.

  FIG. 4 is a diagram showing an example of the hardware configuration of the client device 10 according to the embodiment of the present invention. The client device 10 of FIG. 4 includes a drive device 100, an auxiliary storage device 102, a memory device 103, a CPU 104, an interface device 105, a display device 106, an input device 107, and the like which are mutually connected by a bus B.

  A program for realizing the processing in the client device 10 is provided by a recording medium 101 such as a CD-ROM. When the recording medium 101 storing the program is set in the drive apparatus 100, the program is installed from the recording medium 101 to the auxiliary storage apparatus 102 via the drive apparatus 100. However, the installation of the program does not necessarily have to be performed from the recording medium 101, and may be downloaded from another computer via a network. The auxiliary storage device 102 stores the installed program and also stores necessary files and data.

  The memory device 103 reads out the program from the auxiliary storage device 102 and stores it when there is an instruction to start the program. The CPU 104 implements the function related to the client device 10 in accordance with the program stored in the memory device 103. The interface device 105 is used as an interface for connecting to a network. The display device 106 displays a graphical user interface (GUI) according to a program. The input device 107 includes a keyboard, a mouse, and the like, and is used to input various operation instructions.

  FIG. 5 is a diagram showing an example of a functional configuration of the client device 10 according to the embodiment of the present invention. In FIG. 5, the client device 10 includes a screen transition information extraction unit 11, a test scenario generation unit 12, a screen automatic operation unit 13, a screen evaluation unit 14, a test material generation unit 15, and the like. These units are realized by processing that one or more programs installed in the client device 10 cause the CPU 104 to execute.

  The screen transition information extraction unit 11 analyzes the controller using static analysis technology based on the source code of the controller of the Web application, and acquires the number of transition destinations for each request.

  The test scenario generation unit 12 generates a test scenario and a test input value for each screen displayed in the test. The test input value for each form of a screen is generated using the peripheral information of the form in the HTML DOM tree of the screen. The peripheral information of the form is an example of information defined for the form in HTML.

  The screen automatic operation unit 13 implements dynamic analysis by automatically executing screen operations using the generated test scenario and test input value as test cases.

  The screen evaluation unit 14 determines whether the screen transitioned by the execution of the screen operation has already been transitioned using information such as a URL and HTML. The screen evaluation unit 14 performs editing processing for abstracting the HTML data of the screen transitioned by the execution of the screen operation and the HTML data of the screen which has already transitioned, and the HTML data after editing Compare

  The test material generation unit 15 generates a screen transition diagram based on the information obtained by static analysis and dynamic analysis. The test material generation unit 15 also outputs the test scenario and the test input value generated by the test scenario generation unit 12 in the form of a test script.

  The processing procedure executed by the client device 10 will be described below. FIG. 6 is a flowchart for explaining an example of the processing procedure executed by the client device 10.

  In step S101, the test scenario generation unit 12 generates a dictionary used to generate a test input value. The dictionary is data having a configuration in which the hypernym of the word is attached as a tag for each word. In the present embodiment, for example, two types of dictionaries prepared in advance and a dictionary generated from DB data accessed by the Web application in the server device 20 are used. The latter dictionary is generated in step S101. By using a value registered in the DB as a test input value, it is possible to enable transition to a screen such as a search display screen that can not be transitioned unless the test input value is registered in the DB. The user can generate a test input value without providing DB data as an input, but when DB data is not given as an input, when data registered in the DB affects screen transition conditions, It may not be possible to generate appropriate input values.

  Subsequently, the screen transition information extraction unit 11 analyzes the source code of the controller using static analysis technology, and acquires the number of transition destinations for each request from the information of the controller which determines the transition destination of the screen (S102) ). Information indicating the number of transition destinations for one request is called "screen transition information", and a list of screen transition information is called "screen transition information list".

  FIG. 7 is a diagram showing an example of static analysis. FIG. 7 shows a part of source code of the controller. The description d1 in FIG. 7 indicates a request. The description d2 and the description d3 indicate transition destinations corresponding to the request. In step S102, it is extracted from the descriptions d1, d2 and d3 that there are two transition destinations for the request "owners / new". Such extraction is performed for every request defined in the source code.

  Subsequently, the screen automatic operation unit 13 accesses the initial URL and acquires HTML data and the like corresponding to the initial URL (S103). As a result, a screen based on the HTML data or the like is displayed on the display device 106. The initial URL may be input by the user, for example, or may be stored in advance in the auxiliary storage device 102.

  In the subsequent steps S104 to S109, dynamic analysis or the like is performed on the HTML data corresponding to the initial URL and all HTML data that can be transited from the screen related to the HTML data as a starting point. Specifically, as a dynamic analysis, the screen operation of the test target is automatically implemented automatically from the screen corresponding to the initial URL so as to cover all transition destinations for each request acquired by static analysis. Be done. In dynamic analysis, clicks are performed for all links on each screen, and if there is an input form and a corresponding submit button, static analysis is performed for the request when the submit button is pressed. Test input values are generated and screen operations are repeated until the acquired number of transition destinations of the request is satisfied. As to whether or not the number of transition destinations of the request is satisfied, the screen of the transition destination is compared with the screen that has already transitioned, it is determined whether it is a newly transitioned screen, and the number of arrived screens is counted. Through the above dynamic analysis, information on the transition destination screen (HTML, URL, etc.) and the connection between the screens, and means for reaching the screen are acquired. In addition, when a screen transition not passing through the controller is found by dynamic analysis, information on the screen transition is also added. The screen transition not passing through the controller is, for example, a screen transition that occurs when the link in the a tag is clicked.

  Hereinafter, the HTML data to be processed between steps S104 and S109 will be referred to as "target HTML".

  In step S105, the test scenario generation unit 12 generates a test scenario for the screen related to the target HTML (hereinafter, referred to as "target screen"). That is, a test scenario including a combination of an operation and a locator is generated for each screen element (link, submit button, etc.) that causes a screen transition in the target screen. The operation is an operation such as a click. The locator is identification information of the screen element to be operated.

  The following steps S106 to S108 are performed for each of the test scenarios generated in step S105. The test scenario to be processed in S106 to S108 is hereinafter referred to as "target test scenario".

  In step S107, the test scenario generation unit 12 generates a test case based on the target test scenario, and the screen automatic operation unit 13 executes the test case on the target screen. As a result, screen transition occurs. When the target test scenario requires an input value, a test input value is generated in step S107.

  When steps S104 to S109 are executed on all screens (HTML) of the transition destination, the test material generation unit 15 generates a screen transition diagram (S110). Specifically, the test material generation unit 15 compares the generated screen transition information list with the screen transition actually generated in steps S104 to S109, and if there is a screen transition that has not occurred in the test. The screen transition is extracted (detected), and a screen transition diagram is generated by combining the screen transition which could be transitioned with the information of the screen transition which could not be transitioned. For screen transitions that can not be transitioned, since test scripts can not be generated, support such as manual creation may be performed.

  FIG. 8 is a diagram showing an example of the screen transition diagram. In FIG. 8, transition from screen A to screen B and screen C and transition from screen C to screen B are shown. Also, a dashed rectangle indicates a screen where transition is planned in the specification but no transition occurs in the test. That is, in the source code, it is defined that there is a screen transitioning from the screen C, but the dynamic analysis indicates that the transition to the screen does not occur.

  Subsequently, the test material generation unit 15 outputs a test scenario and a test input value when each screen transition occurs in the form of a test script (S111).

  Subsequently, the details of step S101 will be described. FIG. 9 is a flowchart for explaining an example of the processing procedure of the dictionary generation processing.

  In step S201, the test scenario generation unit 12 reads DB data in the server device 20. The DB data may be acquired via a network.

  Subsequently, the test scenario generation unit 12 executes steps S202 to S210 for each column (each column) of DB data. Hereinafter, a column to be processed is referred to as a "target column".

  Subsequently, the test scenario generation unit 12 executes steps S203 to S205 for each value of the target column of each record in the row direction of the DB data. In step S204, the test scenario generation unit 12 analyzes the category, type, and the like of the value to be processed, and extracts the broader word of the value. For example, the hypernym extraction can be performed using a word database such as WordNet ("Japanese WordNet", http://nlpwww.nict.go.jp/wn-ja/). For example, if the value is "Telegraph Telegraph", a broader term such as "Last name, Name" is extracted. If the value is a telephone number, a broader term such as "telephone number" is extracted.

  When the broader term of the value of the target column is extracted for all the records, the test scenario generation unit 12 specifies the broader term extracted most frequently for the target column as a tag for the target column (S206).

  In the subsequent steps S207 to S209, the test scenario generation unit 12 executes step S208 with the value of the target column of each record as the processing target. In step S208, the test scenario generation unit 12 sets the value to be processed and the tag specified in step S206 as a set, and adds the set to the dictionary.

  Subsequently, details of step S102 in FIG. 6 will be described. FIG. 10 is a flowchart for explaining an example of the processing procedure of the screen transition information extraction processing.

  In step S301, the screen transition information extraction unit 11 reads the source code of the controller. The source code may be stored in advance in the auxiliary storage device 102.

  Subsequently, the screen transition information extraction unit 11 executes steps S302 to S304 for each request detected from the source code. In step S303, the screen transition information extraction unit 11 specifies the number of transition destinations for the processing target request with reference to the source code, and adds a combination of the request and the number to the screen transition information list. Therefore, in the screen transition information list, information on all screen transitions scheduled in the source code (specification) is registered.

  Subsequently, the details of step S107 in FIG. 6 will be described. FIG. 11 is a flowchart for explaining an example of the processing procedure of test case generation and execution processing.

  In step S401, the test scenario generation unit 12 determines whether the operation of the target test scenario includes an input operation to a form. When the operation of the target test scenario does not include the input operation to the form (No in S401), the test scenario generation unit 12 sets the target test scenario as the test case as it is (S402). Subsequently, the screen automatic operation unit 13 executes the test case on the target screen (S403). The execution of the test case generates a screen transition. Subsequently, the screen evaluation unit 14 stores the request generated by the click of the link or the depression of the button by the execution of the test case as the “request A” (S405).

  Subsequently, the screen evaluation unit 14 determines whether the screen transited in step S403 has already been transited using information such as a URL and HTML (S405). At this time, when the screen transitioned in step S403 is a screen which has not been transitioned yet, information on the transition is added as an element of the transition list. The transition list is a list having information on the transition between screens generated in the dynamic analysis as an element. The elements include the URL of the screen before transition, the URL of the screen after transition, request A, the HTML of the screen after transition, and a test case.

  On the other hand, when the operation of the target test scenario includes an input operation to the form (Yes in S401), the test scenario generation unit 12 generates an input value (test input value) to the form (S406). For example, if the target screen is as shown in FIG. 12, in the target test scenario, the input operation to the form corresponding to the surname, the input operation to the form corresponding to the first name, the input to the form corresponding to the e-mail address The operation and the pressing of the registration button are included. Thus, in this case, test input values are generated for each form. Multiple test input values may be generated for one form. Therefore, the subsequent steps S407 to S412 are executed for each combination of test input values for each form. The combinations may be all combinations, or a predetermined number of combinations may be extracted from all combinations. All combinations are, for example, N test input values for the surname, M test input values for the first name, and L test input values for the email address. M × L combinations are said. Hereinafter, the combination of processing targets is referred to as “target combination”.

  In step S408, the test scenario generation unit 12 generates, based on the target test scenario, a test case in which each test input value belonging to the target combination is to be input to the corresponding form. Subsequently, the screen automatic operation unit 13 executes the test case on the target screen (S409). That is, a test input value belonging to the target combination is input to each form to which a value is input in the target test scenario, and the submit button to be pressed in the target test scenario is pressed. As a result, screen transition occurs.

  Subsequently, the screen evaluation unit 14 stores a request generated by pressing the button as “request A” (S410). Subsequently, the screen evaluation unit 14 executes the same process as step S405 (S411).

  When steps S407 to S412 are executed for all combinations, the screen evaluation unit 14 determines the number of URLs of the screen after transition for the request A in the transition list (that is, the number of elements including the request A, the number of dynamic transitions below). ) Is equal to the number of transition destination URLs corresponding to request A in the screen transition information list (hereinafter referred to as “the number of static transitions”) (S413). That is, in step S413, it is determined whether all the transitions defined in the source code for the request A have been detected.

  If the number of dynamic transitions is equal to the number of static transitions (Yes in S413), the process of FIG. 11 ends for the target test scenario. When the number of dynamic transitions has not reached the number of static transitions (No in S413), steps S406 and subsequent steps are repeated. That is, for the target test scenario, different combinations of test input values are generated and the test case is executed. Note that test input values that cover static transition numbers can not always be generated. Therefore, an upper limit may be provided to the number of loops when step S413 is No.

  Subsequently, the details of step S406 will be described. FIG. 13 is a flowchart for describing an example of a processing procedure of test input value generation processing.

  Steps S501 to S506 are executed for each form to be input in the target test scenario. Hereinafter, the form to be processed is referred to as "target form".

  In the subsequent steps S502 to S505, test input values for the target form are generated based on the peripheral information of the target form. The peripheral information of the target form is, for example, peripheral elements of the target form in the DOM tree of the target HTML. The peripheral elements of the form are, for example, incidental information such as form id, name, class, value, text, etc. or attribute information. That is, there can be a plurality of peripheral elements for one form. Therefore, steps S502 to S505 are performed for each peripheral element of the target form. Hereinafter, the peripheral element to be processed is referred to as “target peripheral element”.

  In step S503, the test scenario generation unit 12 extracts the hypernym of the value of the target peripheral element. Specifically, the test scenario generation unit 12 estimates the item name of the target form using a regular expression matching technique or the like. For example, if the target peripheral element is id and “id = address”, the test scenario generation unit 12 is a form in which the target form is “address” (the item name of the target form is “address”) I guess. In this case, "address" is extracted as a broader term of the value of the target peripheral element.

  Subsequently, the test scenario generation unit 12 extracts a value associated with the tag matching the extracted broader term from the dictionary, and sets the value as one of test input values for the target form (S504). When steps S502-S505 are performed for each peripheral element of the target form, one or more test input values are generated for the target form.

  Subsequently, the details of steps S405 and S411 in FIG. 11 will be described. FIG. 14 is a flowchart for describing an example of a processing procedure of determination processing of a transition destination screen.

  In step S601, the screen evaluation unit 14 includes the URL of the current transition destination screen (that is, the target screen) as the URL of the post-transition screen in one of the elements including the request A in the transition list. Determine if there is. When the URL of the current transition destination screen is not included in the transition list as the URL of the post-transition screen of request A (No in S601), the screen evaluation unit 14 displays the request A, the URL of the screen before transition, the current transition destination An element including the screen URL, the current transition target screen HTML (target HTML), and the test case related to the target test scenario is added to the transition list (S602).

  On the other hand, when the URL of the current transition destination screen is included in the transition list as the URL of the post-transition screen of request A (Yes in S601), the screen evaluation unit 14 includes request A in the transition list and is currently Steps S603 to S611 are executed for each HTML data of the screen after transition of an element including the URL of the transition destination screen as the URL of the screen after transition. Hereinafter, the HTML to be processed is referred to as “target transitioned HTML”. Also, the HTML of the current transition destination screen is referred to as "target HTML" as defined above.

  Subsequently, the screen evaluation unit 14 executes steps S604 to S608 for each of the target transition completed HTML and the target HTML. Of the target transition completed HTML and the target HTML, the HTML to be processed is referred to as “targeted HTML”.

  In step S605, the screen evaluation unit 14 generates a DOM tree of the HTML of interest. FIG. 15 shows an example of the DOM tree. As shown in FIG. 15, the DOM tree shows the hierarchical structure of each node (each screen element).

  Subsequently, the screen evaluation unit 14 deletes a node that does not affect the role of the screen (that is, does not affect the identification of the screen) from the DOM tree (S606). There are three types of nodes that do not affect the role of the screen, such as attribute nodes, text nodes, size and font of characters, and nodes representing positions (Center tag, U tag, etc.). Therefore, the node indicated by the dashed rectangle in FIG. 15 is deleted.

  Subsequently, the screen evaluation unit 14 consolidates nodes (parallel nodes) having a parallel relationship in the DOM tree into one node (S607). A parallel node refers to a plurality of nodes with the same tag name belonging to the same hierarchy in the hierarchical structure of the DOM tree. In FIG. 15, nodes corresponding to two <h1> tags surrounded by an alternate long and short dash line correspond to parallel nodes. The aggregation of nodes may be realized by leaving one of the parallel nodes and deleting the other, or by replacing the parallel nodes by one node abstracting each node. Good.

  By executing steps S604 to S608 for each of the target transitioned HTML and the target HTML, an abstracted DOM tree is generated for each of the target transitioned HTML and the target HTML.

  Subsequently, the screen evaluation unit 14 converts each of the two abstracted DOM trees into HTML, compares the conversion results, and outputs the comparison result (S609). That is, the sameness between the screen related to the target transitioned HTML and the screen related to the target HTML is determined. If the compared HTML matches, "match" is output as the comparison result. Otherwise, "mismatch" is output as the comparison result. Note that perfect match may not be required for the matched HTML. For example, the appearance order of the same tag may be allowed to be different.

  If the comparison result is "match" (Yes in S610), the process regarding the target transitioned HTML ends. When the comparison result is “mismatch” (No in S610), the screen evaluation unit 14 executes the same process as step S602 (S612), and ends the process of FIG.

  Subsequently, details of step S110 in FIG. 6 will be described. FIG. 16 is a flowchart for describing an example of a processing procedure of generation processing of the screen transition diagram.

  Steps S701 to S703 are executed for each of the elements included in the transition list (URL of screen before transition, URL of screen after transition, request, HTML of screen after transition, and set of test cases). Hereinafter, the element to be processed is referred to as a "target element".

  In step S702, the test material generation unit 15 adds an element including the request of the target element, the URL of the screen before transition of the target element, and the URL of the screen after transition of the target element to the screen transition diagram list. That is, the screen transition diagram list is a list in which a set of the request, the URL of the screen before transition, and the URL of the screen after transition is one element.

  Steps S704 to S709 are executed for each element of the screen transition diagram list. Hereinafter, the element to be processed is referred to as a "target element".

  In step S705, the test material generation unit 15 counts, in the screen transition diagram list, the number of elements in which the URL of the request and the screen before transition is common to the target element. The number of elements is the number of screens transitioned from the same screen (screen before transition) in the dynamic analysis based on the same request. Hereinafter, the number of elements is referred to as “dynamic transition number n”.

  Subsequently, the test material generation unit 15 acquires the number of transition destinations corresponding to the request of the target element from the screen transition information list (S706). The number of transition destinations is the number of transition destinations of the request extracted from the source code in static analysis. Hereinafter, the number of transition destinations is referred to as “the number of static transitions m”.

  Subsequently, the test material generation unit 15 determines whether the dynamic transition number n is equal to or more than the static transition number m (S707). If the dynamic transition number n is equal to or more than the static transition number m (Yes in S 707), the processing for the target element ends. When the dynamic transition number n is less than the static transition number m (Yes in S 707), the test material generation unit 15 detects the difference between the dynamic transition and the static transition. That is, the presence of a screen not transitioning in the dynamic analysis is detected. Therefore, the test material generation unit 15 adds elements including the request of the target element and the URL of the screen before transition of the target element to the screen transition diagram list by the number of m−n (S708). That is, an element relating to the transition corresponding to the dashed rectangle in FIG. 8 is added.

  When steps S704 to S709 are executed for all elements of the screen transition diagram list, the test material generation unit 15 generates a screen transition diagram based on the screen transition diagram list (S710). Under the present circumstances, about the element without URL of the screen after transition, it is expressed as a screen which could not be changed, such as a rectangle of a dashed line. The generated screen transition diagram may be displayed on the display device 106, or data indicating the screen transition diagram may be stored in the auxiliary storage device 102.

  Subsequently, details of step S111 in FIG. 6 will be described. FIG. 17 is a flowchart for explaining an example of a processing procedure of test script output processing.

  In steps S801 to S803, the test material generation unit 15 outputs a test script by outputting the test case included in each element of the transition list in the form of a script.

  As described above, according to the present embodiment, information on screen transition scheduled as the specification of the Web application (information on static screen transition) is extracted from the source code, and the operation on the Web application is automatically executed. Automatically extracts screen transition information (dynamic screen transition information) generated by repeating screen transition, and detects differences between static screen transition information and dynamic screen transition information can do. As a result, it is possible to detect screen transitions which are defined on source code but can not be generated by a test script. That is, it is possible to detect a screen transition which can not be realized by a test script automatically generated for a Web application. Therefore, for example, it is possible to enhance the possibility of detecting a failure of the web application before the market outflow, and also enable short-term development.

  Further, according to the present embodiment, it is possible to reverse the specification from the test target, automatically generate a test case based on the reversed specification, and output it as a test script. As a result, test script generation for comprehensive screen transition test in Web application can be automatically performed without the need for additional operation. As a result, for example, the cost for software testing can be reduced.

  Further, according to the present embodiment, regarding the technical subject 1, it is possible to automatically reverse the connection between the screens constituting the test object and the screens and to reach each screen without omission from the test object. In addition, since information on the number of screen transitions for a request can be obtained in advance by static analysis, it is easy to determine the search termination during dynamic analysis, and processing can be performed in a realistic time. In the present embodiment, since server side information is not required, there is no need for the user to prepare an environment for acquiring server side information, and it is possible to suppress additional operation for introducing a tool.

  Moreover, according to the present embodiment, with regard to the technical problem 2, it is possible to generate an appropriate test input value for realizing the screen transition using the client side information (HTML). Unlike the prior art, since the server side information is not required, the user does not have to prepare an environment for acquiring the server side information, and it is possible to suppress the additional operation for introducing the tool.

  Furthermore, according to the present embodiment, with regard to the technical problem 3, it is possible to appropriately identify the screen in the functional test without requiring the setting of the threshold, and it is possible to improve the quality of the verification pattern.

  In the present embodiment, the client device 10 is an example of the difference detection device. The screen transition information extraction unit 11 is an example of an extraction unit. The screen automatic operation unit 13 is an example of the operation unit. The screen evaluation unit 14 is an example of a generation unit. The test material generation unit 15 is an example of a detection unit. The test scenario generation unit 12 is an example of a generation unit. HTML data is an example of screen description information. The screen transition information list is an example of first screen transition information. The transition list is an example of second screen transition information. HTML data is an example of description information.

  Although the embodiments of the present invention have been described above in detail, the present invention is not limited to such specific embodiments, and various modifications may be made within the scope of the present invention as set forth in the claims.・ Change is possible.

DESCRIPTION OF SYMBOLS 10 Client apparatus 11 Screen transition information extraction part 12 Test scenario production | generation part 13 Screen automatic operation part 14 Screen evaluation part 15 Test material production | generation part 20 Server apparatus 100 Drive apparatus 101 Recording medium 102 Auxiliary storage device 103 Memory device 104 CPU
105 interface device 106 display device 107 input device B bus

Claims (6)

An extraction unit for extracting information of a first screen transition defined in the source code from a web application source code;
An operation unit that automatically operates a screen displayed regarding the web application;
A generation unit that generates information of a second screen transition that is realized by an automatic operation;
A detection unit that detects a difference between the information of the first screen transition and the information of the second screen transition;
What is claimed is: 1. A difference detection apparatus comprising: The generation unit performs predetermined editing on each of the description information of the first screen and the description information of the second screen related to the information of the second screen transition, and compares the description information after the editing. Determining the identity between the first screen and the second screen,
The difference detection device according to claim 1, wherein the difference is detected. The predetermined editing is to combine screen elements having a parallel relationship,
The difference detection apparatus according to claim 2, wherein the difference is detected. The predetermined editing is to delete screen elements that do not affect screen identification.
The difference detection apparatus according to claim 2, wherein the difference is detected. And a generation unit configured to generate an input value based on the information defined for the screen element in the description information of the screen for the screen element to be the input destination of the value in the screen displayed regarding the Web application,
The operation unit inputs an input value generated by the generation unit.
The difference detection device according to any one of claims 1 to 4, wherein the difference is detected. An extraction unit for extracting information of a first screen transition defined in the source code from a web application source code;
An operation unit that automatically operates a screen displayed regarding the web application;
A generation unit that generates information of a second screen transition that is realized by an automatic operation;
A detection unit that detects a difference between the information of the first screen transition and the information of the second screen transition;
A program characterized by causing a computer to function.

Images