JP6535038B2 - Screen determination apparatus, screen determination method and program - Google Patents

Description

The present invention relates to a screen determination apparatus , a screen determination method, and a 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 automatic generation of test scripts by reducing the additional operation, the exhaustivity of the screen transition realized by the test script becomes a problem. That is, in general, screens are identified by URLs, but even screens of the same URL may need to be distinguished as 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 Is desirable. Moreover, even if there is a slight difference, it is desirable from the viewpoint of functional testing that the same screen is regarded as the same screen if it is functionally the same. If the identity of each screen is not properly determined, it is difficult to cover the transition to each screen, and the test coverage is reduced. Therefore, a technique that can appropriately determine the identity of screens related to web applications is desired.

  The present invention has been made in view of the above-described points, and an object of the present invention is to make it possible to appropriately determine the identity of a screen related to a Web application.

Then, in order to solve the above-mentioned subject, a screen judging device is paralleled to each of the descriptive information of the 1st screen about Web application, and the descriptive information of the 2nd screen about the same or different Web application as the Web application. An editing unit that edits to combine screen elements having a relationship into one, and a determination unit that compares the description information after editing and determines the identity between the first screen and the second screen; Have.

  It is possible to appropriately determine the identity of the screen related to the web application.

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 present 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 a screen transition diagram. 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 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 is collected while searching for the test target using dynamic analysis technology. Specifically, the HTML of each screen transitioning in the dynamic analysis is analyzed, information such as buttons and links is automatically acquired, and a test case is generated in which all the buttons and links are clicked. Also, if there is an input form, a random value is used as a test input value. Aim for coverage of screen transitions by repeating the above for each screen.

  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 accordance with the viewpoint of functional test (Technical Problem 1: 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 technical issues.
Technical issue 1: Examination of appropriate screen identification method in functional test.

[Technical problem 1: 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 test scenario generation unit 11, a screen automatic operation unit 12, a screen evaluation unit 13, a test material generation unit 14, 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 test scenario generation unit 11 generates a test scenario and a test input value for each screen displayed in the test.

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

  The screen evaluation unit 13 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 13 performs editing processing for abstracting the HTML data of the screen transited by execution of the screen operation and the HTML data of the screen which has already transited, and the edited HTML data Compare

  In FIG. 5, the screen evaluation unit 13 includes a node deletion unit 131, a node aggregation unit 132, and a comparison unit 133. The node deletion unit 131 executes deletion of the node related to the above cause 1 as a part of the above editing process. The node aggregation unit 132 executes, as part of the above-described editing process, aggregation of nodes involved in the above-mentioned cause 2. The comparison unit 133 compares the two HTMLs abstracted by the editing process such as deletion of nodes and aggregation of nodes, and determines the identity of the screen related to the two HTMLs.

  The test material generation unit 14 generates a screen transition diagram based on the information obtained by static analysis and dynamic analysis. The test material generation unit 14 also outputs the test scenario and the test input value generated by the test scenario generation unit 11 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 screen automatic operation unit 12 accesses the initial URL and acquires HTML data and the like corresponding to the initial URL. 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 S102 to S107, 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 the dynamic analysis, the screen operation of the test target is automatically implemented automatically from the screen corresponding to the initial URL. In dynamic analysis, clicks are performed for all links on each screen, and if there is an input form and a corresponding submit button, test input values are generated for the request when the submit button is pressed. And the screen operation is repeated. The screen of the transition destination is compared with the screen that has already transitioned, and it is determined whether the screen has newly transitioned, 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. The controller is a part that determines processing to be executed for a request from the client side in the configuration of a model view controller (MVC), which is a design pattern generally used in Web applications. For example, a servlet is an example of a controller.

  Hereinafter, the HTML data to be processed in steps S102 to S107 will be referred to as "target HTML".

  In step S103, the test scenario generation unit 11 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 S104 to S106 are executed for each of the test scenarios generated in step S103. The test scenario to be processed in S104 to S106 is hereinafter referred to as "target test scenario".

  In step S105, the test scenario generation unit 11 generates a test case based on the target test scenario, and the screen automatic operation unit 12 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 S105.

  When steps S102 to S107 are executed for all screens (HTML) of the transition destination, the test material generation unit 14 generates a screen transition diagram (S108). Specifically, the test material generation unit 14 generates a screen transition diagram showing the screen transition actually generated in steps S102 to S107.

  FIG. 7 is a diagram showing an example of the screen transition diagram. FIG. 7 shows transition from screen A to screen B and screen C, and transition from screen C to screen B.

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

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

  In step S201, the test scenario generation unit 11 determines whether the operation of the target test scenario includes an input operation to the form. When the operation of the target test scenario does not include the input operation to the form (No in S201), the test scenario generation unit 11 sets the target test scenario as the test case as it is (S202). Subsequently, the screen automatic operation unit 12 executes the test case on the target screen (S203). The execution of the test case generates a screen transition. Subsequently, the screen evaluation unit 13 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” (S205).

  Subsequently, the screen evaluation unit 13 determines whether the screen transited in step S203 has already been transited using information such as URL and HTML (S205). At this time, when the screen transitioned in step S203 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 the input operation to the form (Yes in S201), the test scenario generation unit 11 substitutes 0 into the variable i. The variable i is a variable for storing the number of times of execution after step S207. Subsequently, the test scenario generation unit 11 generates an input value (test input value) to the form (S207). For example, if the target screen is as shown in FIG. 9, 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, one test input value is randomly (randomly) generated for each form.

  In step S208, the test scenario generation unit 11 generates, based on the target test scenario, a test case in which each of the generated test input values is to be input to the corresponding form. Subsequently, the screen automatic operation unit 12 executes the test case on the target screen (S209). That is, a test input value 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 13 stores the request generated by pressing the button as "request A" (S210). Subsequently, the screen evaluation unit 13 executes the same process as step S205 (S211).

  Subsequently, the screen evaluation unit 13 adds 1 to the variable i (S212). Subsequently, the screen evaluation unit 13 determines whether the value of the variable i has reached N (S213). N is a constant preset as the number of loops after step S207. As the value of N is increased, the coverage of screen transition in dynamic analysis can be improved, but the processing time becomes longer.

  If the value of the variable i is equal to N (Yes in S213), the process of FIG. 8 ends for the target test scenario. If the value of the variable i has not reached N (No in S213), step S207 and subsequent steps are repeated. That is, for the target test scenario, different test input values are generated and the test case is executed.

  Subsequently, details of steps S205 and S211 in FIG. 8 will be described. FIG. 10 is a flowchart for describing an example of a processing procedure of determination processing of a transition destination screen.

  In step S301, the screen evaluation unit 13 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 S301), the screen evaluation unit 13 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 (S302).

  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 S301), the screen evaluation unit 13 includes request A in the transition list and is currently Steps S303 to S311 are executed for each HTML data of the screen after transition of the 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 13 executes steps S304 to S308 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 S305, the screen evaluation unit 13 generates a DOM tree of the HTML of interest. FIG. 11 shows an example of a DOM tree. As shown in FIG. 11, the DOM tree shows the hierarchical structure of each node (each screen element).

  Subsequently, the node deletion unit 131 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 (S306). 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. 11 is deleted.

  Subsequently, the node aggregation unit 132 aggregates nodes (parallel nodes) having a parallel relationship in the DOM tree into one node (S307). 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. 11, 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 S304 to S308 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 comparison unit 133 converts each of the two abstracted DOM trees into HTML, compares the conversion results, and outputs the comparison result (S309). 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 “matched” (Yes in S310), the process regarding the target transitioned HTML ends. When the comparison result is “mismatch” (No in S310), the screen evaluation unit 13 executes the same process as step S302 (S312), and ends the process of FIG.

  Subsequently, details of step S108 in FIG. 6 will be described. FIG. 12 is a flowchart for explaining an example of the processing procedure of the screen transition diagram generation process.

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

  In step S402, the test material generation unit 14 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.

  Subsequently, the test material generation unit 14 generates a screen transition diagram based on the screen transition diagram list (S404). 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, the details of step S109 in FIG. 6 will be described. FIG. 13 is a flowchart for explaining an example of the processing procedure of the test script output process.

  In steps S501 to S503, the test material generation unit 14 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, in comparison between the screen of the transition destination and the screen after transition, each HTML data is subjected to predetermined editing processing, and the HTML data after editing is compared and identical. Sex is determined. As a result, even if it is a screen of the same URL like a search result screen, it can be determined that it is a different screen. In addition, it is possible to reduce the possibility that it is determined that the same screen is functionally or functionally different. That is, it is possible to appropriately determine the identity of the screen related to the web application. As a result, for example, it is possible to enhance the possibility of detecting a failure of a web application before the market outflow, and also enable short-term development. The present embodiment may be applied not only to the sameness of the screens related to the same Web application, but also to the judgment of the sameness of the screens related to different Web applications.

  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.

  Furthermore, according to the present embodiment, with regard to technical problem 1, it is possible to appropriately identify the screen in the functional test without the need for setting 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 screen determination device. The node deletion unit 131 and the node aggregation unit 132 are an example of an editing unit. The comparison unit 133 is an example of a determination unit. HTML data is an example of screen 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 REFERENCE NUMERALS 10 client device 11 test scenario generation unit 12 screen automatic operation unit 13 screen evaluation unit 14 test material generation unit 20 server device 100 drive device 101 recording medium 102 auxiliary storage device 103 memory device 104 CPU
105 interface device 106 display device 107 input device 131 node deletion unit 132 node aggregation unit 133 comparison unit B bus

Claims (3)

Editing that consolidates screen elements having a parallel relationship into one for each of the description information of the first screen related to the Web application and the description information of the second screen related to the Web application that is the same as or different from the Web application The editorial department to
A determination unit that compares the edited description information and determines the identity between the first screen and the second screen;
A screen determination apparatus characterized by having:   Editing that consolidates screen elements having a parallel relationship into one for each of the description information of the first screen related to the Web application and the description information of the second screen related to the Web application that is the same as or different from the Web application The editing procedure to be performed,
  A determination procedure of comparing the edited description information to determine the identity between the first screen and the second screen;
And a computer executes the screen determination method. Editing that consolidates screen elements having a parallel relationship into one for each of the description information of the first screen related to the Web application and the description information of the second screen related to the Web application that is the same as or different from the Web application The editorial department to
A determination unit that compares the edited description information and determines the identity between the first screen and the second screen;
A program characterized by causing a computer to function.

Images