WO2020245952A1

WO2020245952A1 - Log acquisition program, log acquisition method, and information processing device

Info

Publication number: WO2020245952A1
Application number: PCT/JP2019/022383
Authority: WO
Inventors: 尊雄中川; 一樹宗像
Original assignee: 富士通株式会社
Priority date: 2019-06-05
Filing date: 2019-06-05
Publication date: 2020-12-10
Also published as: JP7264245B2; JPWO2020245952A1

Abstract

The present invention causes a computer to perform a process of: relaying an electronic message transmitted and received between a server in which an application to be tested is operating and a terminal in which a Web API used in the application is operated; and, if the electronic message includes information indicating that a screen display is involved, outputting an instruction to the server directing division of a log file indicating the operation of the application.

Description

Log acquisition program, log acquisition method, information processing device

The present invention relates to a log acquisition program, a log acquisition method, and an information processing device.

Conventionally, as one of the tests of the Web application program, a test of operating the screen and visually verifying the display result has been known. The quality of this test is evaluated by comparing the test log acquired when the test is performed with the design document information of the Web application program. Therefore, it is desirable that the test log is divided for each screen shown in the design document. In addition, it is desirable that the log information acquisition method has a low load so as not to interfere with the operation of the system to be tested.

As a method of acquiring a test log, for example, a method of separating log information at the timing when an access to a Web application is made, a method of acquiring a test log once for calling the same function, and the like are known. There is.

Japanese Unexamined Patent Publication No. 2003-173275 Japanese Unexamined Patent Publication No. 2004-362000 JP-A-2015-52882

However, among the conventional methods described above, the former method increases the processing load and the required storage area when the program contains a huge loop, resulting in a high load. Further, in the latter method, even if a function for which log information has been acquired is called by mistake, this log information is not recorded, so that a malfunction cannot be detected.

On one aspect, the present invention aims to separate the test log of a program on a screen-by-screen basis.

In one embodiment, the message transmitted and received between the server on which the application under test is operated and the terminal on which the WebAPI used in the application is operated is relayed.
When the message includes information indicating that the screen is displayed, a computer is made to execute a process of outputting an instruction instructing division of a log file indicating the operation of the application to the server.

Each of the above processes may be a functional unit that realizes each of the above processes, a procedure for realizing each process, or a computer-readable storage medium that stores a program that causes a computer to execute each process.

The program test log can be separated for each screen.

It is a figure which shows an example of the system structure of the log acquisition system of 1st Embodiment. It is a figure which shows an example of the hardware configuration of a proxy server. It is a figure explaining the function of each apparatus of the log acquisition system of 1st Embodiment. It is a figure explaining the outline of the operation of the proxy server of 1st Embodiment. It is a 1st flowchart explaining the process of the server of 1st Embodiment. It is 1st flowchart explaining the process of the proxy server of 1st Embodiment. It is the 2nd flowchart explaining the process of the proxy server of 1st Embodiment. It is a 3rd flowchart explaining the process of the proxy server of 1st Embodiment. It is a figure which shows an example of the test performed in the terminal apparatus. It is the first figure which shows an example of a program file. It is a second figure which shows an example of a program file. It is a figure which shows an example of the file which shows the screen displayed on the terminal apparatus. It is an example of the candidate list information. It is the first figure which shows an example of a communication content. It is the first figure which shows an example of the determination result. It is a second figure which shows an example of a communication content. It is a second figure which shows an example of the determination result. It is a figure explaining the function of each apparatus of the log acquisition system of the 2nd Embodiment. It is a flowchart explaining the process of the proxy server of the 2nd Embodiment.

(First Embodiment)
The first embodiment will be described below with reference to the drawings. FIG. 1 is a diagram showing an example of a system configuration of the log acquisition system of the first embodiment.

The log acquisition system 100 of the present embodiment includes a server 200, a proxy server 300, and a terminal device 400. The terminal device 400 does not have to be included in the log acquisition system 100.

The server 200 is a Web application server on which a Web application program operates, and performs processing in response to a request from the terminal device 400. The proxy server 300 relays a message exchanged between the server 200 and the terminal device 400.

The terminal device 400 is, for example, a terminal device used by a tester who tests a Web application program running on the server 200. In the test in the terminal device 400, for example, the screen operation is performed in the terminal device 400 and the display result is visually verified. The terminal device 400 operates a Web API (Application Programming Interface) used in a Web application program.

Further, the proxy server 300 of the present embodiment detects the timing when the screen is displayed on the terminal device 400 based on the analysis result of the Web application program and the communication content between the terminal device 400 and the server 200, and the server. Notify 200.

The communication content is a message including a request payload transmitted from the terminal device 400 to the server 200 and a response payload transmitted from the server 200 to the terminal device 400. The response payload also includes a header portion and a content portion. The request payload indicates the request description itself. The response payload includes a description of the header part and a description of the content part.

The operation of the log acquisition system 100 will be described below. In the log acquisition system 100, the server 200 analyzes the Web application program, acquires a list of URLs (Uniform Resource Locators) that are candidates for the screen, and outputs the list to the proxy server 300 (step S1). In the following description, the URL may be referred to as address information.

When the proxy server 300 receives the request from the terminal device 400 to the server 200 (step S2), the proxy server 300 relays the request to the server 200 (step S3). Further, when the proxy server 300 receives the response to the terminal device 400 from the server 200 (step S4), the proxy server 300 relays the response to the terminal device 400 (step S5).

Further, the proxy server 300 refers to the URL of the access destination included in the request payload received from the terminal device 400 and the list of acquired URLs, and determines whether or not there is a URL that is a candidate for the screen ( Step S6). Then, when the corresponding URL exists, the proxy server 300 refers to the header part of the response payload received from the server 200 and detects the presence / absence of the screen display. Then, when there is a screen display, the proxy server 300 notifies the server 200 of the division of the test log (step S7).

Upon receiving this notification, the server 200 isolates the test log and acquires it as another new file (step S8).

As described above, in the present embodiment, when the terminal device 400 accesses the server 200, the presence or absence of the screen display is determined from the analysis result of the Web application program and the communication content between the terminal device 400 and the server 200. When it is detected and the screen is displayed, the test log is separated and acquired.

Therefore, according to this embodiment, the test log can be separated for each screen.

The proxy server 300 included in the log acquisition system 100 of this embodiment will be described below. FIG. 2 is a diagram showing an example of the hardware configuration of the proxy server.

The proxy server 300 of the present embodiment includes an input device 31, an output device 32, a drive device 33, an auxiliary storage device 34, a memory device 35, an arithmetic processing unit 36, and an interface device 37, which are connected to each other by bus B, respectively. It is a computer.

The input device 31 is a device for inputting various types of information. The output device 32 is for outputting various kinds of information, and is realized by, for example, a display or the like. The interface device 37 includes a LAN card and the like, and is used for connecting to a network.

The log acquisition program of this embodiment is at least a part of various programs that control the proxy server 300. The log acquisition program is provided, for example, by distributing the storage medium 38 or downloading from the network. The storage medium 38 on which the log acquisition program is recorded is a storage medium such as a CD-ROM, a flexible disk, a magneto-optical disk, or the like that optically, electrically, or magnetically records information, a ROM, a flash memory, or the like. Various types of storage media such as a semiconductor memory that electrically records the data can be used.

Further, when the storage medium 38 on which the log acquisition program is recorded is set in the drive device 33, the log acquisition program is installed in the auxiliary storage device 34 from the storage medium 38 via the drive device 33. The log acquisition program downloaded from the network is installed in the auxiliary storage device 34 via the interface device 37.

The auxiliary storage device 34 realizes each storage unit and the like possessed by the proxy server 300, stores the log acquisition program installed in the proxy server 300, and stores various necessary files, data, and the like by the proxy server 300. Store. The memory device 35 reads and stores the log acquisition program from the auxiliary storage device 34 when the proxy server 300 is started. Then, the arithmetic processing unit 36 realizes various processes as described later according to the log acquisition program stored in the memory device 35.

Since the hardware configuration of the server 200 of this embodiment is the same as that of the proxy server 300, the description thereof will be omitted. Further, the terminal device 400 of the present embodiment may be a smartphone or a tablet terminal, or may be a portable game device, a music player, a wearable device, an in-vehicle device mounted on an automobile, or the like.

Next, with reference to FIG. 3, the function of each device included in the log acquisition system 100 of the present embodiment will be described.

FIG. 3 is a diagram illustrating the functions of each device of the log acquisition system of the first embodiment. The server 200 of this embodiment has a program storage unit 210, a screen candidate extraction unit 220, and a log division unit 230.

The program storage unit 210 stores a Web application program running on the server 200. The screen candidate extraction unit 220 extracts and holds candidate list information 221 indicating a list of URLs (Uniform Resource Locators) that are screen candidates from the Web application program stored in the program storage unit 210. Details of the processing of the screen candidate extraction unit 220 will be described later.

The log division unit 230 receives a notification from the proxy server 300 and separates and acquires the test log.

The proxy server 300 has a list acquisition unit 310, a screen candidate detection unit 320, a screen display determination unit 330, a notification unit 340, and a relay unit 350.

The list acquisition unit 310 acquires the candidate list information 221 extracted by the screen candidate extraction unit 220 from the server 200.

When the screen candidate detection unit 320 receives access to the server 200 from the terminal device 400, it detects whether or not the URL included in the candidate list information 221 exists in the communication content. In other words, the screen candidate detection unit 320 determines whether or not the communication content of the communication between the terminal device 400 and the server 200 includes a URL that is a candidate for the screen.

The screen display determination unit 330 determines whether or not the screen is displayed on the terminal device 400 based on the payload of the communication content detected by the screen candidate detection unit 320.

That is, the screen candidate detection unit 320 is an example of the first determination processing unit that performs the first determination processing, and the screen display determination unit 330 is an example of the second determination processing unit that performs the second determination processing. is there. Details of the processing of the screen candidate detection unit 320 and the screen display determination unit 330 will be described later.

The notification unit 340 determines that the communication content includes a URL that is a candidate for the screen by the screen candidate detection unit 320, and determines that the communication content is accompanied by a screen display by the screen display determination unit 330. Is notified of the isolation of the test log. In other words, the notification unit 340 notifies the server 200 of the test log division command according to the determination results of the screen candidate detection unit 320 and the screen display determination unit 330.

The relay unit 350 relays the communication content (telegram) transmitted and received between the terminal device 400 and the server 200. Specifically, when the relay unit 350 receives the request from the terminal device 400, the relay unit 350 transmits the received request to the server 200. When the relay unit 350 receives the response from the server 200, the relay unit 350 transmits the received response to the terminal device 400.

The terminal device 400 has a display unit 410. The display unit 410 is realized by a Web API (Web Application Program Interface) or the like used in the Web application program of the server 200.

Next, the outline of the operation of the proxy server 300 of the present embodiment will be described with reference to FIG. FIG. 4 is a diagram illustrating an outline of the operation of the proxy server of the first embodiment.

In the example of FIG. 4, when the proxy server 300 receives the first access ac1 from the terminal device 400 to the server 200, the communication content associated with the access ac1 includes a URL that is a candidate for the screen and displays the screen. Judge whether or not it is accompanied by. In the example of FIG. 4, the communication content associated with the access ac1 includes a URL that is a candidate for the screen and is accompanied by a screen display, and requests the display of the login screen to the terminal device 400.

Therefore, the proxy server 300 notifies the server 200 of the isolation of the test log by the notification unit 340. In other words, the proxy server 300 instructs the server 200 to divide the test log file by the notification unit 340.

Upon receiving this notification, the server 200 acquires the test log acquired after the notification as a new file 41.

In the example of FIG. 4, the server 200 executes the login function (1) and the login function (2) after the access ac1.

Next, when the proxy server 300 receives the second access ac2 from the terminal device 400 to the server 200, does the communication content associated with the access ac2 include a URL that is a candidate for the screen and is accompanied by a screen display? Judge whether or not. In the example of FIG. 4, it is assumed that the communication content associated with the access ac2 includes a URL that is a candidate for the screen and is accompanied by a screen display, and requests the terminal device 400 to display the form list screen. ..

Therefore, the proxy server 300 notifies the server 200 of the isolation of the test log by the notification unit 340.

Upon receiving this notification, the server 200 acquires the test log acquired after the notification as a new file.

The server 200 generates a new test log file 42 in addition to the test log file 41 acquired after receiving the notification based on the access ac1 from the proxy server 300. Then, the server 200 sets the test log acquired after the access ac2 as the file 42.

In the example of FIG. 4, the server 200 executes the login function (1), the form list function, and the form search function after the access ac2. Therefore, the server 200 acquires the test log of these operations as a file 42.

Next, when the proxy server 300 receives the third access ac3 from the terminal device 400 to the server 200, does the communication content associated with the access ac3 include a URL that is a candidate for the screen and is accompanied by a screen display? Judge whether or not.

In the example of FIG. 4, it is assumed that the communication content associated with the access ac3 does not include the URL that is a candidate for the screen, and requests the allocation of individual forms. Therefore, the proxy server 300 does not notify the isolation of the test log.

Therefore, the server 200 continues to acquire the test log when the form detail function executed after the access ac3 is executed as the file 42.

As described above, in this embodiment, the test log can be divided and acquired for each screen.

At this time, in this embodiment, if the method once called is called again in the same screen, the test log is not acquired. That is, in the present embodiment, the test log is acquired only once when the same method is called in the same screen. Therefore, according to the present embodiment, the processing load can be reduced.

The processing of the screen candidate extraction unit 220 by the server 200 of the present embodiment will be described below with reference to FIG.

FIG. 5 is a first flowchart illustrating the processing of the server of the first embodiment. The server 200 of the present embodiment inputs the source code of the Web application program stored in the program storage unit 210 into the screen candidate extraction unit 220 (step S501).

The screen candidate extraction unit 220 extracts the base path from the input source code setting file and setting program (step S502). Specifically, the screen candidate extraction unit 220 extracts the address and the port from the setting file of the server 200 or the setting file of the application in which the source code is stored in the program storage unit 210.

Subsequently, the screen candidate extraction unit 220 starts the processing after step S504 for each program file included in the source code (step S503).

The screen candidate extraction unit 220 determines whether or not the annotation, the method name, and the class name include the address information (URL) indicating the Web address (step S504). If the address information is included in step S504, the screen candidate extraction unit 220 extracts the address information (step S505) and proceeds to step S508 described later.

If the address information is not included in step S504, the screen candidate extraction unit 220 determines whether or not there is a file for which the address information is automatically generated (step S506).
The file in which the address information is automatically generated may be, for example, a file created in advance when the source code is described.

If the corresponding file exists in step S506, the screen candidate extraction unit 220 extracts the address information (step S507) and proceeds to step S508 described later.

Subsequently, the screen candidate extraction unit 220 combines the base path and the address information and saves the candidate list information 221 (step S508).

When the screen candidate extraction unit 220 finishes the processing up to step S508 for the program file included in the source code (step S509), the screen candidate list information 221 is output to the proxy server 300 (step S510), and the processing ends.

The timing of outputting the candidate list information 221 to the proxy server 300 may be any timing, and as shown in FIG. 5, it is not necessary to continue the processing of steps S501 to S509. For example, the server 200 may hold the candidate list information 221 and output the candidate list information 221 to the proxy server 300 when the acquisition request of the candidate list information 221 is received from the proxy server 300.

Next, the processing of the proxy server 300 will be described with reference to FIGS. 6 to 8. FIG. 6 is a first flowchart illustrating processing of the proxy server of the first embodiment.

When the proxy server 300 of the present embodiment detects access to the server 200 from the terminal device 400, the list acquisition unit 310 acquires the candidate list information 221 (step S601).

Subsequently, the proxy server 300 determines whether or not the address information included in the candidate list information 221 exists in the communication content between the terminal device 400 and the server 200 by the screen candidate detection unit 320 (step S602). This determination is the first determination process.

Subsequently, the proxy server 300 determines whether or not this communication is accompanied by a screen display based on the communication content between the terminal device 400 and the server 200 by the screen display determination unit 330 (step S603). This determination is the second determination process.

Subsequently, the proxy server 300 instructs the server 200 to divide the test log file according to the results of steps S602 and S603 by the notification unit 340 (step S604).

Specifically, the notification unit 340 determines that the address information included in the candidate list information 221 exists in the communication content in the first determination process of step S602, and the screen is displayed in the second determination process of step S603. When it is determined that the display is accompanied, the server 200 is instructed to divide the test log. Then, the notification unit 340 does not instruct the server 200 to divide the test log except in the case described above.

In the present embodiment, by performing the first determination process and the second determination process in this way, for example, it is possible to detect access to a static Web screen from the terminal device 400 or access without a screen. It is possible to prevent it and acquire a test log for each screen that transitions according to the operation.

Next, the process of step S602 of FIG. 6 will be described with reference to FIG. 7. FIG. 7 is a second flowchart illustrating the processing of the proxy server of the first embodiment. FIG. 7 shows the processing of the screen candidate detection unit 320 in step S602.

The screen candidate detection unit 320 of the present embodiment receives the input of the payload included in the communication content (step S701). More specifically, the screen candidate detection unit 320 accepts the input of the request payload and the header portion of the response payload.

Subsequently, the screen candidate detection unit 320 accepts the input of the candidate list information 221 acquired from the server 200 (step S703). The candidate list information 221 may be acquired from the server 200 in advance, or may be acquired from the server 200 following step S701.

Subsequently, the screen candidate detection unit 320 extracts the address information of the access destination from the payload (step S703). Subsequently, the screen candidate detection unit 320 determines whether or not the access destination indicated by the extracted address information is the server 200 (step S704).

In step S704, if the access destination is not the server 200, the screen candidate detection unit 320 ends the process.

In step S704, when the access destination is the server 200, the screen candidate detection unit 320 determines whether or not the extracted address information is included in the candidate list information 221 (step S705).

Specifically, when the address information is included in the candidate list information 221, the screen candidate detection unit 320 determines that the communication content is a candidate for the screen, and the address information is included in the candidate list information 221. If not, it is determined that the communication content is not a screen candidate.

Subsequently, the screen candidate detection unit 320 notifies the notification unit 340 of the determination result (step S706), and ends the process.

Next, the process of step S603 of FIG. 6 will be described with reference to FIG. FIG. 8 is a third flowchart illustrating the processing of the proxy server of the first embodiment. FIG. 8 shows the processing of the screen display determination unit 330 in step S603.

The screen display determination unit 330 of the present embodiment receives the input of the payload included in the communication content (step S801). More specifically, the screen display determination unit 330 accepts the input of the request payload and the header portion of the response payload.

Subsequently, the screen display determination unit 330 verifies whether or not the request is an XMLHttpp request (step S802).

Subsequently, the screen display determination unit 330 determines the verification result of step S802 (step S803). Specifically, in step S803, the screen display determination unit 330 ends the process when the request is an XMLHttpp request.

In step S803, if the request is not an XMLHttpp request, the screen display determination unit 330 verifies whether or not the content portion exists in the response payload (step S804).

Subsequently, the screen display determination unit 330 determines the verification result of step S804 (step S805). Specifically, in step S805, the screen display determination unit 330 ends the process when the content portion does not exist in the response payload.

In step S805, when the content portion exists in the response payload, the screen display determination unit 330 verifies whether or not the response status in the header portion of the recommendation payload is successful (step S806). In other words, the screen display determination unit 330 verifies whether or not the server 200 has succeeded in accepting the request from the terminal device 400.

Subsequently, the screen display determination unit 330 determines the verification result of step S806 (step S807). Specifically, the screen display determination unit 330 determines whether or not the status code in the header portion of the recommendation payload is in the 200s. In step S807, if the status code is not in the 200s, that is, if the server 200 fails to accept the request, the screen display determination unit 330 ends the process.

In step S807, when the status code is in the 200s, that is, when the server 200 succeeds in accepting the request, the screen display determination unit 330 verifies whether or not the content portion of the recommendation payload performs screen display. (Step S808).

Subsequently, the screen display determination unit 330 determines the verification result of step S806 (step S809). In other words, the screen display determination unit 330 determines the presence or absence of screen display. Specifically, the screen display determination unit 330 determines that the screen display is present if the content type in the header portion of the recommendation payload is a type that displays the screen, such as text / css. Further, the screen display determination unit 330 determines that there is no screen display if the content type in the header portion of the recommendation payload is a type that does not display the screen.

If it is determined in step S809 that there is no screen display, the screen display determination unit 330 ends the process.

If it is determined in step S809 that there is a screen display, the screen display determination unit 330 notifies the notification unit 340 that there is a screen display (step S810), and ends the process.

The notification unit 340 notifies the server 200 when the screen candidate detection unit 320 notifies the determination result that the communication content is a screen candidate, and the screen display determination unit 330 notifies the determination result that the communication content is a display candidate. In response to this, the test log file split instruction is notified.

The determination result of the screen candidate detection unit 320 and the determination result of the screen display determination unit 330 are information indicating the presence / absence of the screen candidate in the communication content and the presence / absence of the screen display, and are returned from the Web API or the like of the terminal device 400. This is the information contained in the telegram.

Therefore, the notification unit 340 notifies the server 200 of the isolation of the test log when the message returned from the WebAPI or the like contains information indicating that the screen is displayed.

In the present embodiment, the information indicating that the screen is displayed is the determination result of the screen candidate detection unit 320 and the screen display determination unit 330.

The processing of the proxy server 300 of this embodiment will be specifically described below. FIG. 9 is a diagram showing an example of a test performed in a terminal device.

In FIG. 9, a request is sent from the terminal device 400 to the Web application program to display the screen, an operation of inputting a numerical value in the input field and pressing the button 92a is performed, and a test is performed to visually verify the display result. Shows the case.

The screen 91 of FIG. 9 is an example of a screen displayed on the display unit 410 of the terminal device 400 by transmitting the request 1 from the terminal device 400 to the Web application program. The Web application program runs on the server 200.

The screen 91 includes an input field 92, a button 92A, and a display field 93. In the example of FIG. 9, when "8201" is input to the input field 92 and the button 92A is pressed, the request 2 is transmitted from the terminal device 400 to the server 200, and the display field 83 is the numerical value and the corresponding book information. Is updated to the display field 93A in which is displayed.

Next, with reference to FIGS. 10 to 12, an example of the source code of the Web application shown in FIG. 9 is shown. The source code shown in FIGS. 10 to 12 is stored in, for example, the program storage unit 210 of the server 200.

FIG. 10 is a first diagram showing an example of a program file, and FIG. 11 is a second diagram showing an example of a program file.

The program file 101 shown in FIG. 10 describes, for example, a process of searching for book information corresponding to the numerical value input in the input field 92A. The program file 111 shown in FIG. 11 describes, for example, a process of displaying a screen on the terminal device 400.

FIG. 12 is a diagram showing an example of a file showing a screen displayed on the terminal device. The file 121 shown in FIG. 12 describes a screen that is interpreted by the browser of the terminal device 400 and displayed on the terminal device 400. Further, the description shown in FIG. 12 is a content portion of the response payload transmitted from the server 200 to the terminal device 400.

The processing of the screen candidate extraction unit 220 of the server 200 will be specifically described below with reference to FIGS. 10 to 12.

Note that the screen candidate extraction unit 220 shall acquire "http: // localhost: 9001" as the base path of the Web application from the setting file of the Web application program or the like.

Next, the screen candidate extraction unit 220 determines whether or not the annotation, the method name, and the class name include the address information (URL) indicating the Web address for each of the program file 101 and the program file 111, and the address information. If is included, extract it.

In the program file 101 shown in FIG. 10, description 101-1 and description 101-2 correspond to address information indicating a Web address. Therefore, the screen candidate extraction unit 220 extracts "/ book / {id: \\ d}" as address information from the description 101-1 and the description 101-2 of the program file 101.

Further, in the program file 111 shown in FIG. 11, the address information is included in the description 111-1. Therefore, the screen candidate extraction unit 220 extracts "/ bookFetcher" as the address information from the description 111-1 of the program file 111.

Next, the screen candidate extraction unit 220 combines the base path and the address information to obtain the candidate list information 221.

FIG. 13 is an example of candidate list information. The candidate list information 221 is a list of combinations of the base path 131 and the address information 132.

The base path 131 shown in FIG. 13 is "http: // localhost: 9001", the address information 132-1 is "/ book / {id: \\ d}", and the address information 132-2 is. It is "/ bookFetcher".

Therefore, the candidate list information 221 is information including the combination 133-1 of the base path 131 and the address information 132-1 and the combination 133-2 of the base path 131 and the address information 132-2.

The proxy server 300 of this embodiment acquires the candidate list information 221 from the server 200.

FIG. 14 is a first diagram showing an example of communication contents. FIG. 14 shows the request payload of the request 1 transmitted from the terminal device 400 to the Web application program, and the header portion of the response payload from the Web application program for the request 1.

The description 141 shown in FIG. 14 shows the request payload of the request 1, and the description 142 shows the header part of the response payload. The content portion of the response payload in this case is the description 121 shown in FIG.

The proxy server 300 of the present embodiment extracts the address information from the header portion of the request payload and the response payload by the screen candidate detection unit 320.

In the example of FIG. 14, description 141-1 is extracted as address information from the request payload. Since the address information indicated by the description 141-1 is included in the candidate list information 221, the screen candidate detection unit 320 notifies the notification unit 340 that there is a screen candidate in the communication content.

Next, the proxy server 300 verifies whether or not the request 1 is an XMLHtp request by the screen display determination unit 330.

In the example of FIG. 14, since the value of the XMLHtp request does not exist, it can be seen that it is not the XMLHtp request.

Next, the screen display determination unit 330 determines whether or not the content portion exists in the request payload. In the example of FIG. 14, it can be seen from the description 142-1 in the description 142 that the content portion exists.

Further, in the example of FIG. 14, since the status code indicated by the description 142-2 in the description 142 is in the 200s, it can be seen that the response status in the header part of the recommendation payload is a successful system. That is, the description 142-2 is information indicating that the request has been successfully received.

Further, in the example of FIG. 14, it can be seen from the description 142-1 in the description 142 that the content type is the type that displays the screen. That is, the description 142-1 is information indicating that the type of content included in the response payload is for displaying the screen. Therefore, the screen display determination unit 330 notifies the notification unit 340 that there is a screen display in the communication content.

FIG. 15 is the first diagram showing an example of the determination result. Regarding the communication content shown in FIG. 14, the screen candidate detection unit 320 notifies the notification unit 340 of the determination result 151 that the communication content is “screen candidate”. Further, the screen display determination unit 330 notifies the notification unit 340 of the determination result 152 that "there is a screen display" in the communication content.

The notification unit 340 notifies the server 200 of the isolation of the test log from the determination result 151 and the determination result 152.

In the example of FIG. 9, since the screen 91 is displayed on the terminal device 400 by the access 1, here, the test log corresponding to the screen 91 can be acquired as a new file.

FIG. 16 is a second diagram showing an example of communication contents. FIG. 16 shows the request payload of the request 2 transmitted from the terminal device 400 to the Web application program, and the header portion of the response payload from the Web application program for the request 1.

The description 161 shown in FIG. 16 shows the request payload of the request 1, and the description 162 shows the header part of the response payload.

The proxy server 300 of the present embodiment extracts the address information from the header portion of the request payload and the response payload by the screen candidate detection unit 320. In the example of FIG. 16, description 161-1 is extracted as address information from the request payload. Since the address information indicated by the description 161-1 is included in the candidate list information 221, the screen candidate detection unit 320 notifies the notification unit 340 that there is a screen candidate in the communication content.

Next, the screen display determination unit 330 verifies whether or not the request 1 is an XMLHttpp request. In the example of FIG. 16, since the description 161-2 in the description 161 is an XMLHttpp request, the screen display determination unit 330 determines that there is no screen display and ends the process.

FIG. 17 is a second diagram showing an example of the determination result. Regarding the communication content shown in FIG. 15, the screen candidate detection unit 320 notifies the notification unit 340 of the determination result 171 that the communication content is “screen candidate”. Further, since the screen display determination unit 330 determines that there is no screen display, the determination result is not notified to the notification unit 340. Therefore, since there is no notification from the screen display determination unit 330, the notification unit 340 sets "no screen display" as the determination result 172.

The notification unit 340 does not notify the server 200 of the test log separation because the determination result 171 is "screen candidate" but the determination result 172 is "no screen display".

In the example of FIG. 9, in access 2, only the display field 93 of the screen 91 is updated on the terminal device 400, and no new screen is displayed. Therefore, in the present embodiment, the operation corresponding to the access 2 can be acquired as the test log of the screen 91.

As described above, according to the present embodiment, the test log of the Web application program can be separated for each screen.

Also, in this embodiment, if the method once called is called again in the same screen, the test log is not acquired. In other words, even if the same method is called multiple times in the same screen, only the test log related to one call is acquired.

Therefore, according to the present embodiment, for example, even when the Web application program includes a loop, the storage area required for holding the test log is not increased.

In this embodiment, since the test log can be acquired for each screen with a low load in this way, the accuracy of matching the design document and the test log can be improved.

(Second embodiment)
The second embodiment will be described below with reference to the drawings. The second embodiment is different from the first embodiment in that the screen candidate detection unit 320 instructs the server 200 to separate the test log when the communication content includes the address information that is the screen candidate. .. Therefore, in the following description of the second embodiment, the differences from the first embodiment will be described, and those having the same functional configuration as the first embodiment will be described in the description of the first embodiment. A code similar to the code used will be assigned, and the description thereof will be omitted.

FIG. 18 is a diagram illustrating the functions of each device of the log acquisition system of the second embodiment. The log acquisition system 100A of the present embodiment has a proxy server 300A. The proxy server 300A has a list acquisition unit 310, a screen candidate detection unit 320, a notification unit 340A, and a relay unit 350.

When the notification unit 340A of the present embodiment receives a notification from the screen candidate detection unit 320 indicating that it is a screen candidate, it instructs the server 200 to separate the test log.

That is, in the present embodiment, the information indicating that the message returned from the WebAPI is accompanied by the screen display indicates the determination result of "screen candidate" by the screen candidate detection unit 320.

FIG. 19 is a flowchart illustrating the processing of the proxy server of the second embodiment.

When the proxy server 300A of the present embodiment detects access to the server 200 from the terminal device 400, the list acquisition unit 310 acquires the candidate list information 221 (step S1901).

Subsequently, the proxy server 300A detects whether or not the address information included in the candidate list information 221 exists in the communication content between the terminal device 400 and the server 200 by the screen candidate detection unit 320 (step S1902).

Subsequently, the proxy server 300A instructs the server 200 to divide the test log file according to the result of step S1902 by the notification unit 340A (step S1903).

As described above, according to the present embodiment, when there is a screen candidate in the communication content, it is possible to instruct the server 200 to divide the test log file. Therefore, according to the present embodiment, the test log can be acquired for each screen without increasing the load.

The present invention is not limited to the specifically disclosed embodiments, and various modifications and changes can be made without departing from the scope of claims.

100, 100A Log acquisition system 200 Server 210 Program storage 220 Screen candidate extraction unit 221 Candidate list information 230 Log division unit 300, 300A Proxy server 310 List acquisition unit 320 Screen candidate detection unit 330 Screen

display judgment unit

340, 340A Notification unit 350 Relay unit 400 terminal device

Claims

The message sent and received between the server on which the application under test operates and the terminal on which the WebAPI used in the application operates is relayed.
A log acquisition program that outputs to the server an instruction instructing division of a log file indicating the operation of the application when the message includes information indicating that a screen is displayed, and causes a computer to execute a process.
Obtain the candidate list information which is a list of address information which is a candidate for the screen extracted from the source code of the application.
The log acquisition program according to claim 1, wherein the computer is made to execute a process of determining whether or not the message includes information indicating that the screen is displayed by using the candidate list information.
The message is
The payload of the request transmitted from the terminal to the server and the payload of the response transmitted from the server to the terminal are included.
The determination process is
The first determination process for determining whether or not the address information included in the candidate list information exists in the payload of the request and the payload of the response, and
The log acquisition program according to claim 2, further comprising a second determination process for determining whether or not the content type of the response is to display a screen based on the header portion of the payload of the response.
When it is determined by the first determination process that the address information exists, and when it is determined by the second determination process that the screen is to be displayed, an instruction is output to the server. , The log acquisition program according to claim 3.
The second determination process is
When the header portion of the payload of the response includes information indicating that the request has been successfully accepted and information indicating that the type of the content is for displaying the screen, the screen is displayed. The log acquisition program according to claim 3 or 4, which determines that the display is to be performed.
It is a method of acquiring logs by a computer, and the computer
The message sent and received between the server running the application under test and the terminal running the WebAPI used in the application is relayed.
A log acquisition method for outputting to the server an instruction instructing division of a log file indicating the operation of the application when the message includes information indicating that the screen is displayed.
A relay unit that relays messages sent and received between the server on which the application to be tested operates and the terminal on which the WebAPI used in the application operates.
An information processing device including a notification unit that outputs a command for instructing division of a log file indicating the operation of the application to the server when the message includes information indicating that the screen is displayed.