JP2010267266A - Test support device and test support method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To efficiently test a computer program. <P>SOLUTION: The test support apparatus 300 has a test telegraphic message setting unit 302. The test telegraphic message setting unit 302 includes a means for acquiring a source code of an application; a means for extracting the name of an element for calling a function of the application, from the source code; a means for acquiring a first test telegraphic message, used by a creator of the source code in testing the application; a means for specifying a field with the element set thereto, to call the application function in the first test telegraphic message, on the basis of the name of the element; and a means for setting a second test telegraphic message to be used for new test with respect to the application, by setting a value of the element determined, in advance, with respect to the field specified. <P>COPYRIGHT: (C)2011,JPO&INPIT

Description

  The present invention relates to a data processing technique, and more particularly to a technique for supporting a test for a computer program.

  There are known penetration tests for detecting security vulnerabilities in applications. In the penetration test, for example, a test message in which a known attack pattern is set may be issued to a test target application, and the presence or absence of a vulnerability may be determined by verifying output data from the application.

JP 2005-228177 A

  In a series of application development steps, a programmer of an application source code may create a test message for a unit test of an application created by the programmer. On the other hand, when a penetration test is carried out in the integration test process, the inventor believes that the tester must create a test message for the penetration test from scratch, which has been a factor in increasing the test cost. It was.

  The present invention has been completed based on the above-mentioned problem recognition of the present inventor, and its main object is to provide a technique for supporting the realization of an efficient test for a computer program.

  In order to solve the above problems, a test support apparatus according to an aspect of the present invention includes a source code acquisition unit that acquires a source code of an application, and an element that extracts a name of an element for calling an application function from the source code According to the name extraction unit, the test message acquisition unit that acquires the first test message transmitted to the application in the application test by the creator of the source code, and the element name extracted by the element name extraction unit, A test message analysis unit that identifies a field in which an element for calling an application function in the first test message is set, and a value of a predetermined element for the specified field is set, thereby The second to send to the application in a new trial Comprising a test message setting section for setting a test message, a.

  Another aspect of the present invention is a test support method. This method is transmitted to the application in the steps of obtaining the source code of the application, extracting the name of the element for calling the function of the application from the source code, and testing the application by the source code creator. Obtaining a first test message, identifying a field in which an element for calling an application function is set in the first test message according to the name of the element extracted in the extracting step; Setting a value of a predetermined element for the specified field causes the computer to execute a step of setting a second test message to be transmitted to the application in a new test for the application.

  It should be noted that any combination of the above-described constituent elements and a representation of the present invention converted between an apparatus, a method, a system, a program, a recording medium storing the program, and the like are also effective as an aspect of the present invention.

  According to the present invention, implementation of an efficient test for a computer program can be supported.

It is a block diagram which shows the function structure of the test assistance apparatus in 1st Embodiment. It is a figure which shows the structure of the definition information of a control command node. It is a figure which shows the structure of logging command list information. It is a figure which shows the structure of logging command list information. It is a flowchart which shows operation | movement of a test assistance apparatus. It is a figure which shows the example of the program code of an original program. It is a figure which shows the example of the program code of an original program. It is a figure which shows an example of the original syntax tree produced | generated from the original program of Fig.5 (a). It is a figure which shows an example of the original syntax tree produced | generated from the original program of FIG.5 (b). FIG. 7 is a diagram illustrating a modified syntax tree obtained by modifying the original syntax tree of FIG. FIG. 7 is a diagram illustrating a modified syntax tree obtained by modifying the original syntax tree of FIG. It is a figure which shows the example of the program code of the program for a test. It is a figure which shows the example of the program code of the program for a test. It is a flowchart which shows operation | movement of the test assistance apparatus of 1st Embodiment. It is a figure which shows the output data of the program for a test output to the HTML file. It is a figure which shows the output data of the program for a test output to the HTML file. It is a flowchart which shows operation | movement of the test assistance apparatus of 1st Embodiment. It is a figure which shows the display image of the coverage status by a coverage status display part. It is a figure which shows the structure of the enterprise system of 2nd Embodiment. It is a block diagram which shows the detailed structure of the test message | telegram setting part of FIG. It is a figure which shows an example of a source file. It is a figure which shows an example of a source file. It is a figure which shows the example of the call element extracted from the source file. It is a figure which shows the example of the test message for UT. It is a figure which shows the example of the test message for UT. It is a figure which shows the example of the test message for IT. It is a figure which shows the example of the test message for IT. It is a figure which shows the example of the test message for IT. It is a flowchart which shows operation | movement of the test assistance apparatus of 2nd Embodiment. It is a block diagram which shows the functional block of the test part in a modification.

  In the embodiment, first, a technique for visualizing an execution flow of a program code in a penetration test will be described as a first embodiment (hereinafter referred to as “first embodiment”). Next, a technique for automatically setting a test message for a penetration test will be described as a second embodiment (hereinafter referred to as “second embodiment”).

(First embodiment)
The penetration test is a black box test that focuses on output data from a computer program without considering the internal structure of the computer program. Therefore, although it can be detected that there is a security vulnerability in the computer program to be tested, since the internal structure is a black box, it may take time to solve the problem existing in the computer program.

  As a first embodiment, a test support apparatus for visualizing an execution flow of a program code in a penetration test is proposed for an original program (hereinafter also referred to as “original program” as appropriate) to be a penetration test target. The test support apparatus is configured to output a message for notifying the user of the execution flow in accordance with the execution of the control instruction for controlling the execution flow of the original program among the instructions described in the program code in the original program. Modify the original program. This message is hereinafter referred to as an “execution flow message”.

  Specifically, the test support apparatus of the first embodiment generates an abstract syntax tree having each element of the program code described in the original program as a node. In the abstract syntax tree, for a node indicating a control instruction (hereinafter also referred to as a “control instruction node” as appropriate), a node indicating a logging instruction that outputs an execution flow message that can identify the control instruction (hereinafter referred to as “control instruction node”) (Also referred to as “logging command node” as appropriate). Then, the test support apparatus generates a program in which the original program is modified (hereinafter also referred to as “test program” as appropriate) from the abstract syntax tree to which the logging command node is added. In this test program, a logging command is associated with a control command.

As in the test support apparatus of the first embodiment, in order to modify the original program, the program code itself is not analyzed, but the abstract syntax tree corresponding to the original program is analyzed, thereby associating with the control instruction. This makes it easy to set logging commands. For example, even in the same conditional branch process, there are various description patterns as program codes as in the following three examples.
First description pattern:
If (status) operation;
Second description pattern:
If (status) {
operation;
}
Third description pattern:
If (status)
{
operation;
}

  When analyzing the program code itself, an analysis process corresponding to each pattern of the above three examples is required. On the other hand, in the abstract syntax tree, the difference in the format level of the program code is absorbed and becomes the same node configuration, so that the process of adding the logging command node to the control command node can be made common. In other words, it is possible to perform processing with a common logic independent of the program code description pattern. As a result, the program code for realizing the test support apparatus can be reduced in code amount and easy maintenance can be realized.

  Further, the test support apparatus of the first embodiment executes a penetration test on the generated test program. And the execution flow message which can specify the control command which controlled the execution flow is output by the logging command performed in this penetration test. According to the test support apparatus of the first embodiment, the execution flow at the time of the penetration test execution for the original program is visualized, and it becomes easy to identify the problem location existing in the original program, and can support the quick solution of the problem.

  FIG. 1 is a block diagram illustrating a functional configuration of the test support apparatus 100 according to the first embodiment. The test support apparatus 100 includes a storage unit 10, a UI unit 30, and a data processing unit 40. The storage unit 10 is a storage area for holding various data. The UI unit 30 is responsible for user interface processing for the user, such as a program developer or a tester. The data processing unit 40 executes various types of data processing based on data held in the storage unit 10 and data acquired by the UI unit 30. The data processing unit 40 also serves as an interface between the storage unit 10 and the UI unit 30.

  Each block shown in the block diagram of the present specification can be realized in terms of hardware by an element such as a CPU of a computer or a mechanical device, and in terms of software, it can be realized by a computer program or the like. The functional block realized by those cooperation is drawn. Therefore, those skilled in the art will understand that these functional blocks can be realized in various forms by a combination of hardware and software. For example, the memory or the auxiliary storage device may execute the processing of the storage unit 10. In addition, the CPU reads a program module in which the processing contents of the UI unit 30 and the data processing unit 40 are mounted into the memory, and executes various processes of the UI unit 30 and the data processing unit 40 according to the respective program modules. Also good.

Storage unit 10:
The storage unit 10 includes an original program holding unit 12, a node definition holding unit 14, a logging command holding unit 16, a test program holding unit 18, an input data holding unit 20, and an output data holding unit 22. The original program holding unit 12 holds the source code of the original program. There is no limitation on the programming language for describing the original program, and for example, PHP / JAVA (registered trademark) may be used.

  The node definition holding unit 14 holds control instruction node definition information. Specifically, for abstract structure trees generated from original programs written in different programming languages such as PHP and JAVA, the definition information of control instruction nodes that can exist in each abstract syntax tree is held. . A specific example of this definition information will be described later with reference to FIG.

  The logging command holding unit 16 holds attribute information of each logging command as logging command list information for a plurality of logging commands set in association with each of the plurality of control commands in the test program. A specific example of the logging command list information will be described later with reference to FIG. The test program holding unit 18 holds a test program in which the original program is modified.

  The input data holding unit 20 holds test data for executing a penetration test on the original program. This test data is typically data in which a known attack pattern for confirming the presence or absence of a program vulnerability is set. For example, it may be test data including a program code written in a script language for verifying the presence or absence of vulnerability to cross-site scripting. Further, it may be test data including a character string for verifying the presence or absence of vulnerability to SQL (Structured Query Language) injection. The output data holding unit 22 holds output data output from the test program in the penetration test.

UI unit 30:
The UI unit 30 includes an instruction receiving unit 32, an execution flow display unit 34, and an coverage status display unit 36. The instruction receiving unit 32 receives various instructions input by the user via various input devices. The execution flow display unit 34 displays output data from the test program in the penetration test on the display.

  The coverage status display unit 36 displays on the display the ratio (hereinafter referred to as “coverage rate” as appropriate) that the program code of the original program is executed in the penetration test in the entire program code of the original program. The coverage status display unit 36 displays a list of logging commands set in the test program. At that time, logging commands that have not been executed in the penetration test are displayed on the display in a manner that is easier for the user to see than the executed logging commands. For example, an unexecuted logging command may be displayed in a character size larger than an executed logging command, a display color that is more easily visible, or the like.

Data processing unit 40:
The data processing unit 40 includes a modification unit 50 that modifies the original program into a test program, and a test unit 60 that performs a penetration test on the test program. The modification unit 50 includes an original program acquisition unit 52, a syntax tree generation unit 54, a syntax tree modification unit 56, and a test program output unit 58. The test unit 60 includes a test program acquisition unit 62, a test execution unit 64, and an coverage status specifying unit 66.

  The original program acquisition unit 52 reads the data of the original program from the original program holding unit 12 into the memory. The syntax tree generation unit 54 performs lexical analysis and syntax analysis on the program code described in the original program by a predetermined method according to the grammar rules of the programming language being used. Then, data of an abstract syntax tree (hereinafter referred to as “original syntax tree” as appropriate) based on the original program is generated in the memory.

  The syntax tree generation unit 54 may create an original syntax tree by a known method such as an LR syntax analysis method, or may create an original syntax tree by calling a known parsing function. As an example of the latter, by passing data of an original program described in JAVA to a library function of JDT (Java Development Tools) provided by Eclipse (registered trademark), an abstract syntax tree corresponding to the original program is obtained. It may be generated. Similarly, an abstract syntax tree corresponding to the original program described in PHP may be generated by calling a library function of PDT (PHP Development Tools) provided by Eclipse.

  The syntax tree modifying unit 56 refers to the control instruction node definition information stored in the node definition holding unit 14 and identifies a control instruction node corresponding to the programming language of the original program among the nodes of the original syntax tree. This control instruction node includes, for example, a node indicating a method declaration, a method call instruction, a conditional branch instruction such as if / else / switch, a repeat instruction such as for / while, and an exception processing instruction such as try / catch.

  The syntax tree modifying unit 56 is associated with the control instruction node, and typically sets a logging instruction node as a node immediately below the control instruction node in the original syntax tree, thereby modifying the original syntax tree ( Hereinafter, the data of “modified syntax tree” is set as appropriate. When setting the modified syntax tree, the syntax tree modifying unit 56 associates the identification information of the control instruction node in the original syntax tree with the identification information of the logging instruction node in the modified syntax tree and stores them in the logging instruction holding unit 16. Let

  The syntax tree generation unit 54 may generate an object of a DOM (Document Object Model) tree having each node of the original syntax tree as a child node under the root node as data in the original syntax tree. At this time, each child node may have information indicating the type of control instruction as its attribute (for example, class type). The syntax tree modifying unit 56 traverses the DOM tree indicating the original syntax tree to detect a control instruction node, and sets a logging instruction node to be associated with the detected control instruction node as a new child node in the DOM tree. Also good. In this case, the DOM tree to which the logging command node is added becomes the modified syntax tree data.

  The test program output unit 58 generates a test program according to the modified syntax tree data and the logging command list information stored in the logging command holding unit 16 and stores it in the test program holding unit 18. This test program may be a source code in which a logging instruction is set in association with each of a plurality of control instructions in the original program, or may be an executable binary code corresponding to the source code.

  Here, the test program setting process in the test program output unit 58 will be described in detail. First, the test program output unit 58 determines an execution flow message to be output by the logging command according to the correspondence relationship between the control command node and the logging command node stored as the logging command list information. Specifically, the identification information of the control command corresponding to the logging command, for example, the identification name and position information of the control command in the original program is set as the execution flow message.

  Next, the test program output unit 58, by inputting the execution flow message to a predetermined conversion function, differs from the execution flow message, and after-conversion data for uniquely specifying the execution flow message (hereinafter referred to as the execution flow message). As appropriate, also referred to as “message identification data”). For example, an execution flow message may be input to a predetermined hash function, and a hash value uniquely generated from the execution flow message may be acquired as message identification data. The test program output unit 58 further associates the execution flow message with the message identification data corresponding to the execution flow message and causes the logging command holding unit 16 to further store the execution flow message.

  Next, the test program output unit 58 determines a logging command corresponding to the programming language of the original program. The logging command may be a command for outputting argument data to a standard output or a predetermined log file, or a command for recording argument data in a predetermined database. For example, when the original program is written in PHP, the “echo” command may be used as the logging command. The test program output unit 58 sets the message identification data as an argument of the logging command so that the message identification data corresponding to the execution flow message is output by the logging command, not the execution code notification message itself.

  Finally, the test program output unit 58 refers to the modified syntax tree and generates a test program in which logging instructions are appropriately inserted into the program code of the original program. When generating the source code of the test program, the source code corresponding to the modified syntax tree may be generated by sequentially setting a predetermined program code corresponding to each node of the modified syntax tree. Similarly to the syntax tree generation unit 54, a source code may be generated from data of an abstract syntax tree by calling a known library function. When generating an executable binary code, it is only necessary to sequentially execute semantic analysis, link processing, and the like on the modified syntax tree and output the binary code, as in normal compilation processing.

  The test program acquisition unit 62 reads test program data from the test program storage unit 18 into the memory. The test execution unit 64 executes a penetration test for the test program. Specifically, the test data stored in the input data holding unit 20 is acquired and input to the test program to operate the test program, and the output data from the test program is stored in the output data holding unit 22 Let This output data includes the processing result of the test data by the test program and the message identification data from the logging command set in association with the control command.

  The coverage status specifying unit 66 refers to the logging command list information recorded in the logging command holding unit 16 and the message identification data recorded in the output data holding unit 22, and specifies the logging command executed in the penetration test. To do. The coverage status specifying unit 66 calculates the ratio of the number of output message identification data to the total number of logging commands in the logging command list information as the coverage rate of the penetration test for the original program. When calculating the number of output message identification data, the same message identification data is counted as 1 even if it is output a plurality of times.

  FIG. 2 shows the structure of the definition information of the control instruction node. In the language column, the type of programming language is recorded. In the control instruction column, identification information of a control instruction node among a plurality of types of nodes that can exist in the abstract syntax tree of each programming language is recorded. That is, the syntax tree modifying unit 56 refers to the control instruction field corresponding to the programming language of the original program, and when the control instruction node recorded in the control instruction field is detected in the original syntax tree, immediately after the control instruction node. Insert a predetermined logging instruction node.

  3A and 3B show the structure of the logging command list information. In the logging command ID column, identification information for uniquely specifying the logging command inserted into the test program is recorded. In the logging command node column, identification information of the logging command node in the modified syntax tree is recorded. In the figure, it is recorded in the format of “identification name of logging command node: line number in test program”. In the control instruction node column, identification information in the original syntax tree of the control instruction node in which the logging instruction node is set in the modified syntax tree is recorded. In the figure, it is recorded in the format of “identification name of control instruction node: line number in original program”. An execution flow message is recorded in the execution flow message column, and message identification data is recorded in the message identification data column.

The operation of the above configuration will be described below.
FIG. 4 is a flowchart showing the operation of the test support apparatus 100. When the instruction receiving unit 32 receives an instruction to create a test program from the user, the original program acquiring unit 52 acquires the data of the original program from the original program holding unit 12 (S10). FIG. 5A and FIG. 5B show examples of the program code of the original program. FIG. 5A shows an original program written in JAVA and includes control instructions 102a to 102g. FIG. 5B shows an original program written in PHP and includes control instructions 102h to 102k. Returning to FIG.

  The syntax tree generator 54 generates data of the original syntax tree corresponding to the original program in the memory (S12). FIG. 6A shows an example of an original syntax tree generated from the original program of FIG. The control instruction nodes 104a to 104g in FIG. 6A correspond to the control instructions 102a to 102g in FIG. In the figure, each control instruction node is shown in the format of “control node identification name: line number in original program”. Each node in the subsequent abstract syntax tree is shown in the same format. FIG. 6B shows an example of an original syntax tree generated from the original program shown in FIG. The control command nodes 104h to 104k in FIG. 6B correspond to the control commands 102h to 102k in FIG. Returning to FIG.

  The syntax tree modifying unit 56 sets a modified syntax tree in which the original syntax tree is modified by detecting a control instruction node existing in the original syntax tree and setting a logging instruction node in association with the control instruction node. (S14). Then, the syntax tree modifying unit 56 associates the identification information of the control instruction node in the original syntax tree with the identification information of the logging instruction node set for the control instruction node in the modified syntax tree to the logging instruction holding unit 16. Store (S16). Here, the logging command ID column, the logging command node column, and the control command node column of the logging command list information are set.

  FIG. 7A shows a modified syntax tree obtained by modifying the original syntax tree of FIG. In the modified syntax tree of FIG. 6, the logging command nodes 106a to 106g are associated with the control command nodes 104a to 104g in FIG. Also, the logging command node column and the control command node column of the logging command ID “001” in FIG. 3A indicate data recorded when setting the logging command node 106a in association with the control command node 104a. Yes. That is, the logging command node column indicates identification information of the logging command node 106a in the modified syntax tree, and the control command node column indicates identification information of the control command node 104a in the original syntax tree. Similarly, the records of the logging command IDs “002” to “007” in FIG. 3A are recorded when the logging command nodes 106b to 106g are set in association with the control command nodes 104b to 104g, respectively. Data is shown.

  FIG. 7B shows a modified syntax tree obtained by modifying the original syntax tree of FIG. In the modified syntax tree of FIG. 6, the logging command nodes 106h to 106k are associated with the control command nodes 104h to 104k in FIG. Further, the logging command node column and the control command node column of the logging command ID “001” in FIG. 3B indicate data recorded when setting the logging command node 106h in association with the control command node 104h. Yes. That is, the logging command node column indicates identification information of the logging command node 106h in the modified syntax tree, and the control command node column indicates identification information of the control command node 104h in the original syntax tree. Similarly, the records of the logging command IDs “002” to “004” in FIG. 3B are recorded when the logging command nodes 106i to 106k are set in association with the control command nodes 104i to 104k, respectively. Data is shown. Returning to FIG.

  The test program output unit 58 refers to each record of the logging command list information, determines an execution flow message to be output by the logging command, and determines message identification data corresponding to the execution flow message. Then, the execution flow message and message identification data are added and recorded in each record of the logging command list information (S18). The test program output unit 58 is added with a logging command for outputting message identification data according to the modified syntax tree and the logging command list information, and stores the test program in which the original program is modified in the test program holding unit 18. (S20).

  The execution flow message column in FIG. 3A and FIG. 3B is “test log fixed character string | logging instruction ID | original program file name | control instruction identification name | control instruction line number in original program” An execution flow message of the form Of these, “control command identification name | control program line number in the original program” is set to the record data of the control command node column. Also, the message identification data column in FIGS. 3A and 3B shows a hash value obtained by inputting the execution flow message into a predetermined hash function.

  FIG. 8A shows an example of a test program corresponding to the original program shown in FIG. This figure shows the program code generated in accordance with the modified syntax tree of FIG. 7A and the logging instruction list information of FIG. In the figure, each of the logging instructions 108a to 108g is set in association with each of the control instructions 102a to 102g described in the original program. FIG. 8B shows an example of a test program corresponding to the original program shown in FIG. This figure shows the program code generated in accordance with the modified syntax tree of FIG. 7B and the logging instruction list information of FIG. 3B. In the figure, logging commands 108h to 108k are set in association with the control commands 102h to 102k described in the original program.

  When the logging command node set in the logging command list information is detected by the modified syntax tree, the test program output unit 58 generates a test program by setting the message identification data as an argument of a predetermined logging command. To do. The logging instruction “insert” in FIGS. 8A and 8B is a function defined by the user, and outputs character string data specified by an argument to a predetermined file or database.

  The logging command of the first embodiment is a command for outputting character string data specified by an argument to the output destination of the processing result in the original program. Thus, message identification data is output in parallel with the processing result output by the program code described at the beginning of the original program, and the correspondence between the processing result and the execution flow is facilitated. Further, the logging command of the first embodiment is a command for outputting the message identification data specified by the argument in such a manner that it is normally hidden in software for browsing the processing result in the original program. For example, when the output destination of the processing result in the original program is a structured document such as an HTML file or an XML file, the character string data specified by the argument is output as a comment sentence in the structured document.

  FIG. 9 is a flowchart showing the operation of the test support apparatus 100 of the first embodiment. The instruction receiving unit 32 receives from the user an instruction to start a penetration test for the test program, and the test program acquiring unit 62 reads the test program data from the test program holding unit 18 (S30). The test execution unit 64 reads the test data stored in the input data holding unit 20, operates the test program by inputting the test data into the test program, and executes the penetration test (S32). When executing the test program, if the test program is a source code, it is appropriately converted into an executable binary code as necessary.

  Subsequently, the test execution unit 64 stores the output data from the test program accompanying the operation of the test program in the output data holding unit 22 (S34). This output data includes message identification data output by the logging command. The test execution unit 64 may store the output data from the test program as character data in the structured document file, or may store it as a record of a predetermined table in the database.

  The instruction receiving unit 32 receives a display request for output data from the test program from the user (S36). If it is a display request from a user who does not have the authority to refer to the execution flow message (N in S38), the execution flow display unit 34 displays the output data from the test program as it is. FIG. 10 shows the output data of the test program output to the HTML file. This figure shows output data when the “theMethod” method indicated by the control instruction 102h in FIG. 8B is called in the penetration test. In the figure, since the message identification data is displayed as it is, it is difficult to grasp the execution flow of the original program in the penetration test. Returning to FIG.

  If it is a display request from a user who has the authority to refer to the execution flow message (Y in S38), the execution flow display unit 34 refers to the logging command list information in the logging command holding unit 16 and outputs from the test program. The message identification data, which is data, is converted into an execution flow message associated with the message identification data and displayed (S40). FIG. 11 shows the output data of the test program output to the HTML file. In the figure, since the message identification data of FIG. 10 is converted into a corresponding execution flow message, the execution flow of the original program in the penetration test can be easily confirmed. Whether or not the user has the reference authority may be determined by a known user authentication method, and may be determined by, for example, the ID of the user terminal or user input data at the time of login.

  FIG. 12 is a flowchart illustrating the operation of the test support apparatus 100 according to the first embodiment. S30 to S34 in the figure are the same as S30 to S34 in FIG. The instruction receiving unit 32 receives from the user a request to display the test coverage for the original program. The coverage status specifying unit 66 refers to the message identification data stored in the output data holding unit 22 and specifies a logging command executed by the test (S50). In other words, the logging command corresponding to the message identification data stored in the output data holding unit 22 can be specified as the logging command executed by the test. The coverage status specifying unit 66 refers to the logging command list information in the logging command holding unit 16 and calculates the number of executed logging commands in the total number of logging commands as a coverage rate (S52). The coverage status display unit 36 displays the coverage rate calculated by the coverage status specifying unit 66 on the display (S54). Further, when displaying the logging commands in a list, the coverage status display unit 36 highlights the logging commands that have not been executed in the test more than the executed logging commands (S56).

  FIG. 13 shows a display image of the coverage status by the coverage status display unit 36. Note that the coverage status in FIG. 5 indicates the test coverage status for the original program in FIG. In this example, since the total number of logging instructions is 7 and the number of executed logging instructions is 5, the code coverage is displayed as 71%. In the execution flow message list display, a message output in an unexecuted logging command is highlighted with a bold font and a larger character size than other messages. The user who confirms the result can recognize that the test data or the like should be adjusted so that the condition determination on the 15th line in the original program in FIG. 5A becomes true in order to improve the coverage rate.

  According to the test support apparatus 100 of the first embodiment, when the penetration test for the original program is to be executed, the penetration test is executed for the test program in which the logging command is set in association with the control command. Thereby, the user can check the execution flow of the original program when the penetration test is executed. When a problem is detected in the penetration test, the problem part can be quickly identified by referring to the corresponding part of the original program execution flow. In the logging instruction, the description position of the control instruction in the original program is output instead of the description position of the control instruction in the test program. Thereby, it becomes easy to identify the problem location which exists in the original program. Since the original program is to be repaired by the user, the repair work by the user can be further supported. Further, not the program code itself described in the original program but the abstract syntax tree corresponding to the original program is modified to generate a test program. As a result, the control command can be detected easily and accurately without depending on the description style of the original program, and the setting of the logging command can be realized easily and accurately.

  Further, according to the test support apparatus 100, a control instruction node that matches the definition is detected by referring to a table that records the definition of the control instruction node for each of a plurality of programming languages. By referring to the definition corresponding to the programming language describing the original program, the control instruction node can be detected by common logic independent of the programming language, and the logging instruction node can be set in association with the control instruction node.

  Further, according to the test support apparatus 100, the processing result of the test program in the penetration test is output as structured document data, and the output data by the logging command is output as a comment sentence in the structured document. In other words, in the structured document browsing program, it is output in a mode that is normally hidden. Thereby, it is possible to avoid difficulty in browsing the processing result of the test program due to the output data by the logging command. For example, when the processing result of the test program is output as HTML file data, if the output data by the logging command is displayed as it is, there may be a problem in display on the web browser. However, since it is output as a comment sentence, the processing result of the test program can be displayed without any problem in the web browser. In addition, if the source data of the HTML file is referred to, a message by a logging command can be referred to, and the execution flow can be easily specified.

  Furthermore, according to the test support apparatus 100, message identification data is output as output data by the logging command instead of the execution flow message itself. When an authorized user refers to the output data from the logging command, the message identification data is converted into an execution flow message and displayed. As a result, the execution flow message can be concealed from unauthorized users, and information leakage such as the internal structure of the original program can be prevented.

  Furthermore, according to the test support apparatus 100, it is possible to provide the user with a coverage rate indicating the execution rate of the program code in the penetration test. In the test support apparatus 100, since a logging instruction is set in association with each of a plurality of control instructions via an abstract syntax tree, high accuracy can be achieved without depending on the size of the original program or the format of the original program. The coverage rate can be calculated easily.

  The present invention has been described based on the first embodiment. This embodiment is an exemplification, and it will be understood by those skilled in the art that various modifications can be made to combinations of the respective constituent elements and processing processes, and such modifications are also within the scope of the present invention. is there.

  In the first embodiment described above, both the modification unit 50 and the test unit 60 are provided in one test support apparatus 100. In a modification, the modification unit 50 and the test unit 60 may be distributed and provided in a plurality of different devices. In other words, the second device different from the first device reads the test program data generated in the first device, and the second device performs a penetration test, a test result display, and the like. Also good.

  Moreover, the program module which implement | achieves each functional block of the test assistance apparatus 100 may be mounted as a plug-in with respect to other software programs, such as IDE (Integrated Development Environment). For example, it may be implemented as a plug-in for Eclipse, and the user may add this plug-in to Eclipse to execute a test program generation and a penetration test. As a result, the user can seamlessly execute a penetration test for the program code after coding the program code in Eclipse.

  In 1st Embodiment mentioned above, the example which applied the technical idea of this invention to the penetration test was shown. However, the technical idea of the present invention can be applied not only to the penetration test but also to the entire computer program test, and even in this case, those skilled in the art will understand that the effects described in the first embodiment can be achieved. is there.

  Although not specifically mentioned in the first embodiment described above, when a logging instruction that outputs an execution flow message is executed in the test program, the execution flow message may be buffered once. Then, after the execution of the test program is completed, the output may be delayed to the output destination of the processing result. The test execution unit 64 may include a message output unit that is a functional block for that purpose. When a logging command is executed in the execution of the test program, the message output unit temporarily stores message identification data, which is the output content of the logging command, in a predetermined buffer area. After the execution of the test program, the message identification data stored in the buffer area is added to a field in the file that is the output destination of the processing result that does not destroy the structure of the file.

  For example, if the output destination of the processing result is a structured document, the message output unit adds message identification data to a field that does not affect that the document is well-formed or that the document has validity To do. More specifically, when the output destination of the processing result is an HTML file, the message output unit detects the position of the </ body> tag in the HTML file, and outputs message identification data after the </ body> tag. Also good. In this case, the message identification data in FIG. 10 and the execution flow message in FIG. 11 are output between the </ body> tag and the </ html> tag, respectively. According to this modification, it is possible to reliably avoid destruction of the structure of the output destination document of the execution flow message due to the output of the execution flow message (message identification data).

  Further, the test execution unit 64 may receive an HTTP request from a predetermined web client such as a web browser, execute the test program, and send an HTTP response including an HTML document indicating the result to the web client. In this case, the message output unit may provide a predetermined header in the response header of the HTTP response and set the message identification data as the value. When the web client detects the predetermined header in the response header, the web client may output message identification data that is the value to the predetermined log file. Further, the web client may cooperate with the execution flow display unit 34 to convert the message identification data into an execution flow message, and then output the execution flow message in a log or display it on a screen. The message output unit may set message identification data separately from the HTML document data in the response body of the HTTP response. The operation of the web client is the same as when message identification data is set in the response header.

(Second Embodiment)
First, the outline of the second embodiment will be described. In the development process of a web application (hereinafter also referred to as “web AP”) in a company, the programmer who created the web AP source code deploys the web AP created by himself / herself to the web server in the local terminal and performs a unit test. May be performed. At this time, the programmer transmits a test message for a unit test (hereinafter also referred to as a “UT test message”) to the web server, thereby calling a function of the web AP and performing debugging work. For example, by inputting a URL for calling a function of the web AP to the web browser, an HTTP request is transmitted from the web browser to the web server, and the web AP is executed in the web server.

  In the web AP combination test process, the tester may perform a penetration test on the web AP deployed to the web server in the test server. At that time, the test person set a test message for penetration test (hereinafter also referred to as “IT test message”), for example, an input variable value (argument) for confirming the vulnerability of the Web AP. It was necessary to prepare a test message from scratch, which was a factor in increasing the test cost.

  The present inventor indicates that a test message for a web AP includes a field that changes according to a test environment such as a web server address (hereinafter referred to as an “environment-dependent field”) and a web AP that is independent of the test environment. It was noted that there are fields that change according to the configuration (hereinafter referred to as “AP-dependent fields”). For example, if the URL of the test message for UT is “http: // localhost: 8080 / test / login.php? User = user1 & pass = pass1”, the part of “http: // localhost: 8080 / test /” This is a dependency field, and the part of “login.php? User = user1 & pass = pass1” is an AP dependency field. Then, they came up with a mechanism for automatically setting an IT test message based on the UT test message.

  Specifically, the test support apparatus identifies the environment-dependent field and the AP-dependent field in the UT test message. The environment information of the test server is set in the environment dependent field, while a predetermined parameter value for penetration test (hereinafter also referred to as “IT parameter value”) is set in the AP dependent field. Thereby, automatic generation of the IT test message from the UT test message can be realized, and the burden on the person in charge of the test can be reduced. In other words, an efficient test for the web AP can be realized, and the test cost can be reduced. Hereinafter, the configuration of the second embodiment will be described.

  FIG. 14 shows the configuration of the enterprise system of the second embodiment. The enterprise system 1000 includes a plurality of information processing apparatuses interposed between the development and operation of an application for providing a service to a customer. These information processing apparatuses are connected via known communication means such as LAN, WAN, and the Internet.

  The development PC 200a, the development PC 200b, and the development PC 200c, which are collectively referred to as the development PC 200, are PC terminals that are operated by each of a plurality of programmers that create web AP source code. Web application server software (hereinafter referred to as “web AP server”) is installed in each development PC 200 for a unit test by a programmer for the web AP. Further, the development PC 200 is installed with a capture tool that acquires the UT test message transmitted to the local web AP server in the web AP unit test at any time and notifies the test support apparatus 300 of it.

  An SCM (Source Code Management) device 202 centrally manages the change history of web AP source files created on each development PC 200 using a predetermined repository. In other words, it is also a version management device. For example, the check-in of the source file from the development PC 200 and the check-out of the source file to the development PC 200 are controlled. The test server 204 has a web AP server installed therein, and provides a test environment for a penetration test for the web AP. The operation server 206 is installed with a web AP server, and provides a service by the web AP to the customer PC 208 via the Internet.

  The test support apparatus 300 is an information processing apparatus that supports the implementation of a penetration test for a web AP. The test support apparatus 300 includes a test message setting unit 302, a test message holding unit 304, and an execution flow visualization unit 306.

  The test message setting unit 302 automatically sets the IT test message based on the web AP source code acquired from the SCM device 202 and the UT test message acquired from the development PC 200. The detailed configuration of the test message setting unit 302 will be described later. The test message holding unit 304 is a storage area in which the IT test message set by the test message setting unit 302 is stored. The execution flow visualization unit 306 executes a penetration test for the web AP using the IT test message stored in the test message holding unit 304. At that time, in order to visualize the execution flow of the web AP, the source code of the web AP is modified by the technique of the first embodiment. The execution flow visualization unit 306 includes various functional blocks described in FIG.

  FIG. 15 is a block diagram showing a detailed configuration of the test message setting unit 302 in FIG. The test message setting unit 302 includes a storage unit 310 that is a storage area for holding various data, and a data processing unit 320 that executes various data processing. The storage unit 310 includes an environment information holding unit 312 and a parameter holding unit 314. The data processing unit 320 includes a source code acquisition unit 322, a source code analysis unit 324, a UT test message acquisition unit 326, a test message analysis unit 328, and an IT test message setting unit 330.

  The environment information holding unit 312 holds information related to the test environment of the penetration test. This information includes a setting value of the web AP server for accessing the web AP deployed on the web AP server of the test server 204. The environment information holding unit 312 according to the second embodiment includes an IP address “192.168.1.100” of the test server 204, a port number “3000” of the web AP server in the test server 204, and a directory path “for accessing the web AP”. "/ it /" is held in correspondence.

  The parameter holding unit 314 holds the IT parameter value to be set in the IT test message for the penetration test. This parameter value is a data string for detecting the vulnerability of the web AP, and may be a character string for confirming the operation of the web AP against a known security threat. For example, it may be illegal input data for attempting cross-site scripting or SQL injection for the web AP. As an example of the latter, even if login information such as a user ID is invalid, it may be a character string configured to determine that the login information is correct.

  The source code acquisition unit 322 periodically monitors the SCM device 202 and acquires from the SCM device 202 a source file that is checked into the SCM device 202. The source code analysis unit 324 is an element (hereinafter also referred to as “call element”) for calling a function (web AP function) of the web AP described in the source file acquired by the source code acquisition unit 322. Is extracted from the source code. For example, when the description language of the source code is PHP, the source code analysis unit 324 extracts the PHP source file name as the application name, and detects a predetermined character string for referring to the argument of the GET method or the POST method. Extract the input variable name. Specific examples are shown below.

  FIG. 16A and FIG. 16B show an example of a source file. In FIG. 16A, the file name is “login.php”, and the code line 400 refers to the arguments “user” and “pass” of the GET method. In FIG. 16B, the file name is “rcvform.php” and the code line 402 refers to the argument “text1” of the POST method.

  FIG. 17 shows an example of call elements extracted from a source file. ID in the figure is identification information for uniquely identifying the source file. ID “001” corresponds to the source file in FIG. 16A and ID “002” corresponds to the source file in FIG. The source code analysis unit 324 extracts the file name of the source file of FIG. 16A as the application name, and inputs the character strings “user” and “pass” set immediately after the keyword “$ _GET” as input variables. Extract as a name. Similarly, for the source file in FIG. 16B, the file name is extracted as the application name, and the character string “text1” set immediately after the keyword “$ _POST” is extracted as the input variable name.

  A variable (for example, “$ param”) is specified immediately after the keywords “$ _GET” and “$ _POST”, and the contents indicated by the variable (for example, the above-mentioned character string “user”, etc.) May be specified separately by location or another source file referenced by "require" and "include". For this reason, the source code analysis unit 324 executes an alias analysis for specifying the contents when a variable immediately follows a keyword. This alias analysis is the same processing as the pointer analysis in the source code described in C language. Specifically, an assignment statement for a variable immediately after a keyword (also called a “target variable”) and an assignment statement for another variable assigned to the target variable are sequentially performed in the source file and in another source file to be referenced. A scalar value (for example, a constant value / literal value such as a character string without “$” designation) finally indicated by the target variable may be specified as an input variable name by searching.

  If the description language of the source code is Rubyon Rails, the source code analysis unit 324 extracts the controller name, action name, and input variable name from the source code. For example, the controller name may be specified by specifying a controller name setting field using a keyword such as “class” or “ApplicationController”. Alternatively, the call name may be extracted by specifying the action name and input variable name setting fields using a keyword such as “def”. The record of ID “003” in FIG. 17 indicates a call element extracted from the source code of RubyOnRails.

  Returning to FIG. 15, the UT test message acquisition unit 326 acquires from the development PC 200 the UT test message issued to the web AP in the development PC 200. FIG. 18A and FIG. 18B show examples of UT test messages. The UT test message may be acquired in the URL format. For example, the URL corresponding to FIG. 18A is “http: // localhost: 8080 / ut / 001 / login.php? User = user1 & pass = pass1”, and the URL corresponding to FIG. http: // localhost: 8080 / rcvform.php ". When the request body exists (in the case of POST), the UT test message acquisition unit 326 also acquires the content of the request body.

  The test message analysis unit 328 associates the call element of the web AP extracted by the source code analysis unit 324 with the UT test message in which the call element is set. For example, since the call element of ID “001” in FIG. 17 is set in the UT test message in FIG. 18A, these are associated with each other. Similarly, the UT test message in FIG. 18B is associated with the call element with ID “002” in FIG.

  The test message analysis unit 328 specifies the environment-dependent field and the AP-dependent field in the UT test message according to the application name (or controller name + action name) of the call element. Specifically, in the UT test message, the data field before the application name is specified as the environment-dependent field, and the data field after the application name is specified as the AP-dependent field.

  For example, for the UT test message in FIG. 18A, “/ ut / 001 /” is specified as the environment-dependent field among the schema, host name, port number, and directory path. In the case of the URL format, “http: // localhost: 8080 / ut / 001 /” is specified as the environment-dependent field. On the other hand, “login.php” in the directory path and the query character string are specified as the AP-dependent field. In the case of the URL format, “login.php? User = user1 & pass = pass1” is specified as the AP-dependent field.

  For the UT test message in FIG. 18B, “/” is specified as an environment-dependent field among the schema, host name, port number, and directory path. In the case of the URL format, “http: // localhost: 8080 /” is specified as the environment-dependent field. On the other hand, “rcvform.php”, content length, and request body in the directory path are specified as AP-dependent fields.

  The IT test message setting unit 330 generates an IT test message from the UT test message by converting each of the environment-dependent field and the AP-dependent field of the UT test message. Specifically, information indicating the test environment held in the environment information holding unit 312 is set in the environment-dependent field of the UT test message. At the same time, the IT parameter value held in the parameter holding unit 314 is set as the value of the input variable set in the query character string or request body of the AP-dependent field. The IT test message setting unit 330 stores the created IT test message data in the test message holding unit 304.

  FIG. 19A and FIG. 19B show examples of IT test messages. The IT test message in FIG. 19A is a modification of the UT test message in FIG. 18A, and the IT test message in FIG. 19B is the UT test message in FIG. 18B. Has been modified. The environment information of the test server 204 is set in each host name, port number, and directory path. Further, in the query character string in FIG. 19A and the request body in FIG. 19B, a character string for penetration test, for example, a character string for detecting vulnerability to SQL injection is set. In the content length column of FIG. 19B, a new data length of the request body is set. When creating the IT test message in FIG. 19A in the URL format, “http://192.168.1.100:3000/it/login.php?user=arbitrary character string 'OR 1 = 1− -& pass = arbitrary character string ”is set. Of course, a URL-encoded result character string may be set as the query character string.

  When there is a call element for which a corresponding UT test message is not detected among the call elements extracted from the source code, the IT test message setting unit 330 further creates an IT test message in which the call element is set. And stored in the test message holding unit 304. In this case, the environment-dependent field in which the environment information of the test server 204 is set, the application name (controller name and action name), and the input variable in which the IT parameter value is set are connected, thereby the IT test. A telegram may be created. FIG. 19C also shows an example of an IT test message. This figure shows an IT test message in which the call element of ID “003” in FIG. 17 is set when the corresponding UT test message is not detected.

The operation of the above configuration will be described below.
FIG. 20 is a flowchart illustrating the operation of the test support apparatus 300 according to the second embodiment. A web AP programmer creates a web AP source code on the development PC 200 and performs a web AP unit test. Then, the web AP source code for which the unit test has been completed is checked into the SCM device 202. When the web AP unit test is executed on the development PC 200 (Y in S100), the UT test message acquisition unit 326 of the test support apparatus 300 acquires the UT test message used in the unit test and performs predetermined processing. (S102). If the web AP unit test is not executed in the development PC 200 (N in S100), S102 is skipped.

  When the source code of the web AP is updated, in the second embodiment, when a new source code is checked into the SCM device 202 (Y in S104), the source code acquisition unit 322 of the test support device 300 uses the new source code. A source code is acquired (S106). The source code analysis unit 324 extracts a call element (function name or argument name) for calling a function (function) of the web AP from the web AP source code, and stores it in a predetermined storage area (S108). If the web AP source code is not updated (N in S104), S106 and S108 are skipped.

  When the test message analysis unit 328 of the test support apparatus 300 detects a predetermined trigger for creating an IT test message (Y in S110), the UT test message stored in a predetermined storage area and the web AP call The elements are associated with each other (S112). This trigger may be that an instruction to create an IT test message is received from the user, or that the arrival of a predetermined date and time is detected. The test message analysis unit 328 specifies the environment-dependent field and the AP-dependent field in the UT test message based on the name of the call element (S114).

  The IT test message setting unit 330 sets predetermined information indicating the test environment of the penetration test in the environment-dependent field in the UT test message. At the same time, an IT test message is generated from the UT test message by setting a parameter value predetermined for the penetration test in the AP-dependent field in the UT test message (S116). The processing from S112 to S116 is repeatedly executed for each UT test message. When a call element that does not correspond to the UT test message remains (Y in S118), the IT test message setting unit 330 further sets an IT test message according to the call element (S120). Thereby, an IT test message corresponding to all the call elements is set. The IT test message setting unit 330 stores the generated IT test message in the test message holding unit 304. If there is no call element not corresponding to the UT test message (N in S118), S120 is skipped. If the IT test message creation trigger has not been detected (N in S110), the flow in FIG.

  Similar to the source code acquisition unit 322 of the test message setting unit 302, the original program acquisition unit 52 in the execution flow visualization unit 306 of the test support apparatus 300 acquires the source code of the web AP as an original program. Thereafter, a test program for visualizing the execution flow in the penetration test is set by the method described in the first embodiment. The test program acquisition unit 62 deploys the test program to the test server 204. The test execution unit 64 uses the IT test message stored in the test message holding unit 304 to execute a penetration test for the test program. For example, an HTTP request for a penetration test is set from the IT test message, and the data is transmitted to the web AP server of the test server 204. As a result, a message indicating an execution flow in the penetration test of the web AP is output to a predetermined log file. The test support apparatus 300 starts the actual operation by deploying a Web AP program for which the penetration test has been completed, typically a program in which there is no problem in the penetration test (or a bug has been corrected) to the operation server 206. .

  According to the test support apparatus 300 of the second embodiment, a test message for a web AP combination test (a penetration test in the embodiment) to be performed in the test server 204 is transmitted to a web AP in the development PC 200 for each programmer. It can be automatically set based on the test message used in the unit test. This eliminates the need for creating a test message for the penetration test from scratch. Further, after the web AP unit test on the development PC 200, the process until the web AP is deployed to the operation server 206 is fully automated. Thus, according to the test support apparatus 300, an efficient test for an application can be realized, and costs such as time and labor cost required for the test can be reduced.

  In general, the combination test is a black box test based on the specification of the Web AP, while the unit test is a white box test based on the description content of the source code. Since the penetration test is for detecting the vulnerability of the Web AP, it is desirable that the finest granularity test be performed as much as possible. According to the test support apparatus 300, since the IT test message is created with the granularity of the UT test message, the accuracy of detecting the vulnerability of the web AP can be increased.

  Also, according to the test support apparatus 300, when there is a web AP call element that does not correspond to the UT test message, an IT test message in which the call element is set is additionally created. The test message for UT used in the unit test is a subset of the call elements implemented in the source code, and there is a possibility that the function corresponding to the call element for which the unit test has not been performed has a vulnerability. According to the test support apparatus 300, even if the unit test is not performed, since the test message for IT is set for all call elements detected from the source code, the penetration of the penetration test is improved. Vulnerability in web AP can be detected without omission.

  The present invention has been described based on the second embodiment. This embodiment is an exemplification, and it will be understood by those skilled in the art that various modifications can be made to combinations of the respective constituent elements and processing processes, and such modifications are also within the scope of the present invention. is there.

  In the second embodiment, the execution flow visualization unit 306 of the test support apparatus 300 executes the process for visualizing the execution flow at the time of the penetration test in the test server 204. In the modification, the execution flow visualization unit 306 executes the web AP in the unit test using the test message for UT by modifying the source code of the web AP in the unit test of the web AP in the development PC 200. The flow may be visualized. Specifically, the modification unit 50 of the execution flow visualization unit 306 may receive a notification that the unit test is executed from the development PC 200 together with the source code, and provide the modified test program to the development PC 200. . As a result, a message indicating the execution flow of the web AP may be output to the log file in which the result of the unit test is output.

  According to this modification, it is possible to solve the problem that it is difficult to associate the call element of the web AP with the UT test message. For example, when the default directory path is automatically set on the Web AP server of the development PC 200 or when a directory path alias is set, the call element is not clearly indicated in the UT test message (URL), and both It may be difficult to attach. According to this modification, the execution flow of the web AP in the unit test is visualized, so that the call elements (application name, action name, input variable name) of the web AP called by the UT test message can be easily grasped. Thus, the association between the call element of the web AP and the test message for UT can be facilitated.

  Further, the test message analysis unit 328 of the test message setting unit 302 may identify the call element of the web AP called by the UT test message with reference to the execution flow message output to the log file. For example, the application name or the input variable name described in the code line of the source code specified by the line number of the execution flow message may be specified as the call element. The test message analysis unit 328 may collate the call element with the call element of the web AP extracted by the source code analysis unit 324. That is, among the call elements of the web AP extracted by the source code analysis unit 324, those that match the call element of the web AP called by the UT test message may be associated with the UT test message.

  Further, the test unit 60 of the execution flow visualization unit 306 may further include a change detection unit 340 and a test message selection unit 342. FIG. 21 is a block diagram illustrating functional blocks of the test unit 60 according to the modification. The change detection unit 340 acquires information regarding the source code (updated source code) newly checked in with respect to the SCM device 202 from the SCM device 202. The test message selection unit 342 refers to the execution flow in the web AP unit test corresponding to the updated source code, and identifies the call element of the web AP called by the UT test message as the call element to be tested. . The test message selection unit 342 uses the IT test message stored in the test message holding unit 304 to use the test message corresponding to the call element to be tested in the penetration test associated with the source code change. Select as a message. In other words, the test message corresponding to the call element to be tested is a test message set based on the call element to be tested, and in other words, the test message in which the call element to be tested is set.

  The test execution unit 64 uses the IT test message selected by the test message selection unit 342 to execute a penetration test associated with the update of the web AP. According to this modification, an IT test message to be used in a penetration test accompanying a change in source code is automatically selected, and an efficient test can be realized. Further, by specifying the execution flow of the web AP, even if the source code is partially changed, a series of call elements to be called from the changed portion is specified. That is, call elements that can be affected by changes in the source code are specified, and a penetration test using the test message for IT corresponding to these call elements is performed. As a result, a regression test to be performed in accordance with the change of the source code can be executed without omission. In addition, since a test element for an IT that is not affected by the source code change, in other words, a call element that does not require a second penetration test is not selected, the test cost associated with the change of the source code can be reduced.

  In the second embodiment, the UT test message acquisition unit 326 of the test message setting unit 302 directly acquires the UT test message from the development PC 200. In a modification, in the unit test in the development PC 200, a UT test message may be transmitted to the web AP via a predetermined proxy server. In this case, the UT test message acquisition unit 326 may acquire the UT test message from the predetermined proxy server.

  Although not specifically mentioned in the second embodiment, the development PC 200, the SCM device 202, the test server 204, and the operation server 206 may be installed on the user company side, and the test support device 300 may be installed on the service provider side. . In this case, the test support apparatus 300 collects source codes and UT test messages via a communication network such as the Internet, sets an IT test message, and performs a penetration test using the IT test message via the communication network. May be executed. In other words, an IT test message automatic creation service or a penetration test automation service for a web AP may be provided in the form of ASP / SaaS.

  Any combination of the above-described embodiments and modifications is also useful as an embodiment of the present invention. The new embodiment generated by the combination has the effects of the combined embodiment and the modified examples.

  It should also be understood by those skilled in the art that the functions to be fulfilled by the constituent elements described in the claims are realized by the individual constituent elements shown in the embodiments and the modification examples or by their cooperation.

  12 original program holding unit, 14 node definition holding unit, 16 logging command holding unit, 18 test program holding unit, 20 input data holding unit, 22 output data holding unit, 34 execution flow display unit, 36 coverage status display unit, 52 Original program acquisition unit, 54 syntax tree generation unit, 56 syntax tree modification unit, 58 test program output unit, 62 test program acquisition unit, 64 test execution unit, 66 coverage status identification unit, 100 test support device, 200 for development PC, 202 SCM device, 204 test server, 206 operation server, 300 test support device, 302 test message setting unit, 304 test message holding unit, 306 execution flow visualization unit, 322 source code acquisition unit, 324 source code analysis unit, 326 Test message for UT Obtaining unit, 328 test message analysis unit, 330 IT test message setting unit, 340 change detection unit, 342 test message selection unit, 1000 enterprise system.

Claims (7)

A source code acquisition unit for acquiring application source code;
An element name extraction unit for extracting the name of an element for calling the function of the application from the source code;
A test message acquisition unit that acquires a first test message transmitted to the application in the test of the application by the creator of the source code;
A test message analysis unit that identifies a field in which an element for calling a function of the application is set in the first test message according to the name of the element extracted by the element name extraction unit;
A test message setting unit that sets a second test message to be transmitted to the application in a new test for the application by setting a value of a predetermined element for the identified field;
A test support apparatus comprising:   The test message setting unit sets a second test message for a penetration test by setting a test character string for a penetration test in the specified field as a value of the element. The test support apparatus according to claim 1.   The test message setting unit includes a test message in which an unset element is set for an element that is not set in the field specified by the test message analysis unit among the element names extracted by the element name extraction unit. The test support apparatus according to claim 1, wherein the test support apparatus is set as a second test message.   If there is an unset function name in the field specified by the test message analysis unit among the function names extracted by the element name extraction unit, the test message setting unit also calls the test message for calling the function. The test support apparatus according to claim 3, wherein the test support apparatus is set as a second test message. A syntax tree generation unit that generates a syntax tree having each element of the source code as a node according to a grammatical rule of a programming language to which the source code conforms;
In the syntax tree, a syntax tree in which a node of a control instruction that controls the execution flow of the application is set in association with a node of a logging instruction that outputs a message indicating that the execution flow is controlled by the control instruction. A modification section;
A program for making it possible to confirm an element for calling a function of the application included in the execution flow of the application when the first test message is issued, and corresponding to a control command A program output unit that outputs a test program in which a logging command is set with reference to the syntax tree;
The test support apparatus according to claim 1, further comprising: A change detection unit for detecting that at least a part of the source code of a plurality of source codes managed in the device or the external device has been changed;
Referring to the execution flow of the application related to the changed source code, issue a second test message in which an element for calling the function of the application included in the execution flow is set in the test accompanying the change of the source code A test message selector to select as a test message to be
The test support apparatus according to claim 5, further comprising: Getting the application source code;
Extracting a name of an element for calling a function of the application from the source code;
Obtaining a first test message sent to the application in a test of the application by the creator of the source code;
Identifying a field in which an element for calling a function of the application is set in the first test message according to the name of the element extracted in the extracting step;
Setting a second test message to be transmitted to the application in a new test for the application by setting a predetermined element value for the identified field;
A test support method characterized by causing a computer to execute.

Images