JP2013030017A - Method, device, and program for generating test program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To improve working efficiency related to a black box test.SOLUTION: A method for generating test programs includes: recording a history of execution of a method by a use program using a collection of methods, according to a detection of the execution of the method; collating the history with rule information on a context related to the collection of the methods that a storage part stores, detecting violation of the rule information on the execution of the method by the use program, and recording the detection result in the storage part; and generating a test program for executing a test code that the storage part stores by associating with a combination of the rule information and the detection result.

Description

  The present invention relates to a test program generation method, a test program generation device, and a test program generation program.

  Conventionally, a test called a black box test has been performed on a program. The black box test is a test for confirming whether an output for an input is expected without being conscious of the internal structure of the program. The test item of the black box test is usually created based on a document that defines the external interface of the program, such as a functional specification. Therefore, the test item of the black box test can be created even by a person who does not know the internal structure of the program, such as a person in charge of coding. Therefore, the division of work such as coding creation, test item creation, and test execution is relatively easy, and the efficiency of the program development work can be improved.

  On the other hand, in recent years, program componentization has progressed, and the development efficiency of the program has been improved by using an existing library in which the componentized program is collected as a file. Some libraries have clear rules (or constraints) regarding the context of the function or method involved (eg, call order, etc.). If such a rule is not followed, a situation may occur in which the original functions of the library cannot be obtained effectively. Here, the method represents an operation or procedure for each object or the like that each object has in object-oriented programming or aspect-oriented programming.

  A prominent example is a security-related library (hereinafter referred to as “security library”) for performing encrypted communication or the like. When the security library is used, for example, if inappropriate initialization is performed or initialization is not performed, a situation may occur in which the safety expected to be originally expected cannot be ensured.

JP-A-11-224211 Japanese Patent Laid-Open No. 7-210424

However, in the following four cases, the black box test has a problem in that case A and case B or case C and case D, which have the same result, cannot be clearly distinguished.
(A) Correct implementation and result is OK
(B) There is a possibility of incorrect implementation (bug), the result is OK
(C) Despite the correct implementation, the result is NG
(D) There is a possibility of incorrect implementation (bug), and the result is NG
In order to distinguish the above, it is necessary to refine the test. With regard to refinement, in the conventional black box test, it is necessary to add a test to all input locations of a test target program or to input all possible input values. As a result, a large number of redundant test items are generated, which may reduce the efficiency of development work.

  Therefore, an object of the present invention is to provide a test program generation method, a test program generation device, and a test program generation program that can improve the work efficiency related to the black box test.

  Therefore, in order to solve the above-described problem, the test program generation method records the execution history in response to detection of the execution of the method by the use program that uses a set of methods, and the storage unit stores the history. Collating with contextual rule information regarding the set of methods, detecting violations of the rule information regarding execution of the method by the using program, recording a detection result in the storage unit, and detecting the rule information and the detection result The computer executes a process of generating a test program for executing the test code stored in the storage unit in association with the combination.

  Work efficiency related to black box test can be improved.

It is a figure which shows the hardware structural example of the test program production | generation apparatus in embodiment of this invention. It is a figure which shows the function structural example of the test program production | generation apparatus in embodiment of this invention. It is a figure which shows the example of the rule element which comprises a rule description. It is a figure which shows the example of the operator who comprises a rule description. It is a flowchart for demonstrating an example of the process sequence which a rule analysis part performs. It is a figure which shows an example of a 1st rule description. It is a figure which shows an example of the 1st rule description by an XML format. It is a figure which shows the example of a 1st rule element list. It is a flowchart for demonstrating an example of the process sequence which a program production | generation part performs. It is a figure which shows an example of an aspect model. It is a figure which shows notionally an example of the data structure for managing the call history of a library in this Embodiment. It is a figure which shows the specific example of a 1st aspect code. It is a flowchart for demonstrating an example of the process sequence of the history recording program production | generation process regarding a Before rule element. It is a figure which shows an example of a pointcut definition model. It is a figure which shows the 1st specific example of the pointcut definition in a log | history recording program. It is a figure which shows an example of a before advice definition model. It is a figure which shows an example of a log | history recording model. It is a figure which shows the 1st example of a concrete before advice definition. It is a figure which shows the 2nd specific example of the pointcut definition in a log | history recording program. It is a figure which shows an example of an after advice definition model. It is a figure which shows the 1st example of a concrete after advice definition. It is a figure which shows the 3rd specific example of the pointcut definition in a log | history recording program. It is a figure which shows an example of a log | history reference model. It is a figure which shows the 2nd example of a concrete after advice definition. It is a flowchart for demonstrating an example of the process sequence of a detection program production | generation process. It is a figure which shows the specific example of the pointcut definition in a detection program. It is a figure which shows an example of a detection log recording model. It is a figure which shows the specific example of the after advice definition in a detection program. It is a figure which shows the structural example of the detection log for one line. It is a figure which shows the specific example of the aspect code of the log | history recording program produced | generated regarding the 1st rule description of this Embodiment, and a detection program. It is a figure which shows the specific example of the aspect code of the log | history recording program produced | generated regarding the 1st rule description of this Embodiment, and a detection program. It is a figure which shows an example of a 2nd rule description. It is a figure which shows the example of a 2nd rule element list. It is a figure which shows the specific example of the aspect code of the log | history recording program produced | generated regarding the 2nd rule description of this Embodiment, and a detection program. It is a figure which shows the specific example of the aspect code of the log | history recording program produced | generated regarding the 2nd rule description of this Embodiment, and a detection program. It is a flowchart for demonstrating an example of the process sequence of the history recording program production | generation process regarding an After rule element. It is a flowchart for demonstrating an example of the process sequence of the log | history recording program production | generation process regarding a Call rule element. It is a flowchart for demonstrating an example of the process sequence at the time of execution of a history recording program and a detection program. It is a flowchart for demonstrating an example of the process sequence of the production | generation process of the test program for black box tests. It is a figure which shows the structural example of a test policy list memory | storage part. It is a figure which shows the 1st example of a scenario code. It is a figure which shows the 2nd example of a scenario code. It is a figure which shows an example of a 3rd rule description. It is a figure which shows the example of a 3rd rule element list. It is a figure which shows the example of mounting of the application of a test object. It is a figure which shows the specific example of a detection log. It is a figure which shows the 1st example of a test program. It is a figure which shows the 2nd example of a test program.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings. FIG. 1 is a diagram illustrating a hardware configuration example of a test program generation device according to an embodiment of the present invention. The test program generation device 10 in FIG. 1 includes a drive device 100, an auxiliary storage device 102, a memory device 103, a CPU 104, an interface device 105, a display device 106, and an input connected to each other via a bus B. Device 107.

  A program that realizes processing in the test program generation device 10 is provided by a recording medium 101 such as a CD-ROM. When the recording medium 101 on which the program is recorded is set in the drive device 100, the program is installed from the recording medium 101 to the auxiliary storage device 102 via the drive device 100. However, the program need not be installed from the recording medium 101 and may be downloaded from another computer via a network. The auxiliary storage device 102 stores the installed program and also stores necessary files and data.

  The memory device 103 reads the program from the auxiliary storage device 102 and stores it when there is an instruction to start the program. The CPU 104 realizes functions related to the test program generation device 10 in accordance with a program stored in the memory device 103. The interface device 105 is used as an interface for connecting to a network. The display device 106 displays a GUI (Graphical User Interface) or the like by a program. The input device 107 is a keyboard, a mouse, or the like, and is used for inputting various operation instructions.

  FIG. 2 is a diagram illustrating a functional configuration example of the test program generation device according to the embodiment of the present invention.

  The test program generation device 10 determines whether there is a violation of rules (rules) or restrictions on the context of the library (hereinafter referred to as “rules”) for an application developed using a library, for example. To detect. A contextual rule is a rule regarding whether or not a function or method included in a library is called, and the context (call order) of the call. The test program generation device 10 further generates a program (test program Tp) that limits the range of the black box test based on the detection of the violation of the rule and performs the black box test for the range.

  In order to realize such a function, the test program generation device 10 includes a rule analysis unit 12, a program generation unit 13, a test program generation unit 15, and the like. Each of these units is realized by processing executed by the CPU 104 by a program installed in the test program generation apparatus 10. The test program generation device 10 also includes a rule description storage unit 11, a template data storage unit 14, a detection log storage unit 16, a test policy list storage unit 17, a scenario code storage unit 18, and the like. Each of these storage units can be realized by using the auxiliary storage device 102 or a storage device connected to the test program generation device 10 via a network.

  The rule description storage unit 11 stores a rule description for a library used by an application, for example. The rule description refers to text data in which contextual rules relating to library use are described in a predetermined format or grammar. In the present embodiment, the rule description is described in an expression format in which rule elements are connected by an operator. A rule element refers to the minimum element of a rule. One rule description can be established by a single rule element. An operator refers to a symbol indicating a logical relationship between rule elements.

  FIG. 3 is a diagram illustrating an example of rule elements constituting the rule description. The figure shows four rule elements and a description format in the rule description of each rule element. In the description format shown in the figure, lower case alphabets (a to j) indicate functions or methods (hereinafter, referred to as “methods”) included in the library.

  The first is a rule element indicating that the a method is an essential condition before the execution of the b method in the c method. That is, in the c method, when the b method is executed, the rule element indicates that the a method must be executed before the b method is executed. The rule element is described in the rule description in the format of “@Before (a, b, c)”. Hereinafter, the rule element is referred to as “Before rule element”.

  The second is a rule element indicating that the d method is an essential condition after the execution of the e method in the f method. That is, in the f method, when the e method is executed, the rule element indicates that the d method must be executed after the e method is executed. The rule element is described in the rule description in the format of “@After (d, e, c)”. Hereinafter, the rule element is referred to as “After rule element”.

  The third is a rule element indicating that calling the g method within the h method is an essential condition. That is, it is a rule element indicating that the g method must be called in the h method. The rule element is described in the rule description in the format of “@Call (g, h)”. Hereinafter, the rule element is referred to as “Call rule element”.

  The fourth element is a rule element indicating a necessary condition for calling a method in which an argument type is specified. That is, a rule element indicating that a version for which an argument of a specific type is specified for an i method must be called in the j method. The rule element is described in the rule description in the format of “@Call (i (type), j)”. Hereinafter, the rule element is referred to as a “type designation call rule element”.

  FIG. 4 is a diagram illustrating an example of an operator constituting the rule description. The figure shows four operators and the description format in the rule description of each operator.

  The first is an operator for indicating the relationship between (Equation k) and (Equation 1). That is, it is an operator for describing a rule that both (expression k) and (expression 1) must be satisfied. The operator is described in the rule description by “&&”.

  The second is an operator for indicating the relationship of (Formula m) or (Formula n). That is, it is an operator for describing a rule that either (Expression m) or (Expression n) must be satisfied. The operator is described in the rule description by “||”.

  The third is an operator for indicating the relationship of (Expression p) if (Expression o). That is, it is an operator for describing a rule that (Expression p) must be satisfied when (Expression o) is satisfied. The operator is described in the rule description by “−>”.

  The fourth is an operator for indicating negation of (formula q). That is, it is an operator for describing a rule that (formula q) must not be satisfied. The operator is described in the rule description by “!”.

  The rules are different for each library. Therefore, the rule description may be created for each library by, for example, a library developer or a library user who is familiar with the library specifications.

  The rule analysis unit 12 analyzes the rule description stored in the rule description storage unit 11 and converts the content of the rule description into a format that can be easily processed by the program generation unit 13. More specifically, the rule analysis unit 12 extracts constituent elements (a rule element list and a formula structure described later) from the rule description. That is, since the rule description can be described by a person, it has a format that is easy for a person to understand. On the other hand, formats that are easy to understand for humans tend to be unsuitable for logical processing by computers. Therefore, the rule analysis unit 12 executes a process for mediating between a person and a computer (program generation unit 13).

  The program generation unit 13 automatically generates a source code of a program for detecting the presence or absence of rule violation based on the analysis result (the rule description component extracted by the rule analysis unit 12) by the rule analysis unit 12. To do. The program generation unit 13 includes a history recording program generation unit 131, a detection program generation unit 132, and the like. The history recording program generation unit 131 generates the history recording program Pr as part of a program for detecting the presence or absence of rule violation. The detection program generation unit 132 generates the detection program Pc as part of a program for detecting the presence or absence of rule violation.

  The history recording program Pr is a program that detects a method call (method execution) by an application to be developed and records a history of the call. The detection program Pc is a program that detects the presence or absence of rule violation based on the history recorded by the history recording program Pr. The detection program Pc records data (hereinafter referred to as “detection log”) indicating the detection result of the presence or absence of rule violation in the detection log storage unit 16. That is, the detection log storage unit 16 stores a detection log.

  The template data storage unit 14 stores data (model data) serving as a template of the source code of the history recording program Pr or the detection program Pc using the auxiliary storage device 102.

  The test program generation unit 15 generates a test program Tp that executes a black box whose test range is limited based on the detection log. By limiting the test range, it can be expected that test work will be more efficient. The test program generation unit 15 refers to the test policy stored in the test policy list storage unit 17 when generating the test program Tp. The test policy is data indicating a scenario code to be executed in accordance with a detection result (that is, the content of the detection log) of whether or not there is a violation of each rule (rule description). The test policy list storage unit 17 stores a list of such test policies (test policy list).

  The scenario code is a template (template) of a test code created in advance for a black box test. The scenario code storage unit 18 stores such a scenario code group.

  Therefore, the test program generation unit 15 acquires a scenario code corresponding to the detection result of the presence or absence of rule violation related to the detection log from the scenario code storage unit 18, and generates the test program Tp using the scenario code.

  The history recording program Pr, the detection program Pc, and the test program Tp are created based on aspect-oriented programming. One of the features of aspect-oriented programming is that it is suitable for the history recording program Pr, the detection program Pc, and the test program Tp. The feature is a property that it can act on the target program from the outside of the test target (inspection target) program (the application in the present embodiment). With such a property, it is possible to detect a call (execution) of a library method by an application without changing the library, the application, or the like. In this embodiment, AspectJ is used as an aspect-oriented programming language. However, other programming languages may be used.

  Hereinafter, a processing procedure of the test program generation device 10 will be described. FIG. 5 is a flowchart for explaining an example of a processing procedure executed by the rule analysis unit. The process shown in the figure is started in response to a process start instruction input by the user, for example. In this instruction, identification information of the rule description to be analyzed is specified. The identification information of the rule description is hereinafter referred to as “rule name”.

  In step S <b> 101, the rule analysis unit 12 reads the rule description relating to the specified rule name from the rule description storage unit 11 into the memory device 103. That is, the rule description is stored in the rule description storage unit 11 in association with the rule name.

  FIG. 6 is a diagram illustrating an example of the first rule description. The rule description rd1 shown in the figure includes a description d11 and a description d12.

  A description d11 indicates a method name that is a target of the rule description rd1. Therefore, it can be seen from the description d11 that the rule description rd1 is a rule description related to the method “SSLSocket.startHandshake ()”. Note that rules relating to a plurality of methods may be described in one rule description. A description indicating the target method name is not essential.

  The description d12 is an expression indicating a rule. In the description d12, two Before rule elements are connected by the “−>” operator. The Before rule element of the first term is “@Before (X509TrustManager.checkServerTrusted (), SSLSocket.startHandshake (), httpServlet.doPost ())”, and the Before rule element of the second term is “@Before (X509Certificate. checkValidity (), SSLSocket.startHandshake (), httpServlet.doPost ())) ”.

  Therefore, the expression related to the description d12 is “in httpServlet.doPost (), if X509TrustManager.checkServerTrusted () is executed before SSLSocket.startHandshake () (if executed), it will be in httpServlet.doPost (). , X509Certificate.checkValidity () must be executed before SSLSocket.startHandshake (). "

  The rule description rd12 describes rules regarding the use of the SSLSocket library in the implementation of an application as a Java (registered trademark) SSL (Secure Socket Layer) client.

  That is, in SSL communication, it is necessary to verify whether or not the server certificate is reliable. In the case of a Java (registered trademark) SSLSocket library, when handshake is started by calling startHandshake (), certificate verification processing is automatically performed, so there is usually no problem. However, if checkServerTrusted () is overridden in the X509TrustManager implementation class, the certificate verification process is overridden. Therefore, in this case, the certificate verification process must be appropriately implemented by the application developer.

  Therefore, the rules regarding the use of the SSLSocket library when an application as an SSL client is implemented are as follows.

Target method: javax.net.ssl.SSLSocket # startHandshake ()
Rule: When checkServerTrusted () of X509TrustManager (implementing class) is executed before javax.net.ssl.SSLSocket # startHandshake () in the process called from the servlet, X509Certificate # checkValidity () The rule description rd1 represents the rule using a rule element and an operator.

  Here, a Web application called from a servlet is an example of an application to be inspected. HttpServlet.doPost () is a method that is called when a POST command of an HTTP request is received in the Web server. Therefore, “httpServlet.doPost ()” is applied to the “process called from the servlet”.

  The rule description may be described in a structured document format such as an XML format in consideration of the convenience of the analysis processing.

  FIG. 7 is a diagram illustrating an example of the first rule description in the XML format. The rule description rd2 in the figure describes the same rules as those defined in the rule description rd1 in FIG. 6 in the XML format.

  The value of the library attribute (“SSLSocket.startHandshake ()” of the rule element (element enclosed by the <rule> tag) that is the root element indicates the name of the target method. The tag name of the child element rd21 of the rule element ( “->”) Indicates an operator that connects two Before rule elements included as the value of the child element, before element rd22 corresponds to the Before rule element of the first term in the description d12 of FIG. The before element rd23 corresponds to the before rule element of the second term in the description d12 of Fig. 6. That is, in each before element, the proc attribute, the succ attribute, and the with attribute are the a method and b method of the Before element, respectively. , C method (see FIG. 3).

  Data in XML format can be easily analyzed by an existing XML parser. Therefore, the processing content of the rule analysis unit 12 can be simplified.

  Subsequently, the rule analysis unit 12 analyzes the structure of the read rule description (S102). Specifically, rule elements and operators in the rule description are disassembled and structured. That is, the rule analysis unit 12 recognizes the logical relationship between each rule element. In the case where the rule description is in the XML format as shown in FIG. 7, reading into the DOM (Document Object Model) format by the XML parser corresponds to the analysis in step S102. Therefore, when the rule description is described in a structured document format, steps S101 and S102 can be substantially one step.

  Subsequently, the rule analysis unit 12 transforms (or converts) the rule description formula as necessary (S103). In the present embodiment, the expression including the operator “->” is transformed (or converted) using the operators “!” And “||”. Specifically, an expression having a structure of “A-> B” is transformed into “! A || B”. In this case, where the logical relationship between A and B is the same before and after the transformation, the operators “!” And “||” evaluate the logical value (true value) of the expression (the rule indicated by the expression). This is because it is easy to evaluate whether or not the above is satisfied. Here, “A” and “B” indicate one rule element or expression. In step S103, all the operators “->” are resolved (replaced).

  Subsequently, the rule analysis unit 12 extracts a rule element from the analysis result of the rule description rd1 (S104). Subsequently, the rule analysis unit 12 generates (assigns) a variable name for each extracted rule element (S105). The variable name is an identification name for a variable for storing a logical value (true / false value) of the rule element. As long as uniqueness is ensured between rule elements, the naming rules for variable names are not limited to predetermined ones. Subsequently, the rule analysis unit 12 stores (outputs) a list of pairs of rule elements and variable names in the auxiliary storage device 102 in association with the rule names (S106). This list is hereinafter referred to as “rule element list”.

  FIG. 8 is a diagram illustrating an example of a first rule element list. The rule element list rL1 in the same figure is a rule element list generated based on the rule description rd1 shown in FIG. In the figure, the variable name “R1” is assigned (generated) to the Before rule element of the first term, and the variable name “R2” is assigned (generated) to the Before rule element of the second term. Example) is shown.

  Subsequently, the rule analysis unit 12 sets an expression structure in which each rule element in the rule description expression is replaced with a variable name corresponding to the rule element (S107). In addition, about the formula deform | transformed in step S103, the formula after a deformation | transformation is made into the object of substitution. The formula structure based on the rule element description rd1 in FIG. 6 and the rule element list rL1 in FIG. 8 is as shown in (1) below.

! R1 || R2 (1)
For each rule element of the rule description rd1, the result of simple substitution with a variable name is
R1-> R2
However, the expression structure extracted from the rule description rd1 by the modification in step S103 is as described in (1) above.

  Subsequently, the rule analysis unit 12 stores (outputs) the formula structure in the auxiliary storage device 102 in association with the rule name (S108).

  Subsequently, a processing procedure of the program generation unit 13 will be described. FIG. 9 is a flowchart for explaining an example of a processing procedure executed by the program generation unit. The process shown in the figure is started in response to a process start instruction input by the user, for example. In the instruction, a rule name is specified. However, it may be executed synchronously with the process of FIG. 5 (automatically following the process of FIG. 5). In this case, the rule name specified at the start of the process of FIG. 5 may be used in the process of FIG.

  In step S <b> 201, the program generation unit 13 reads an aspect template (aspect template) from the template data storage unit 14 into the memory device 103.

  FIG. 10 is a diagram illustrating an example of an aspect template. As shown in the figure, the aspect template is a template for defining an aspect in an aspect-oriented programming language (AspectJ). In the aspect template t1 in the figure, the aspect name is parameterized. That is, “<aspect name>” is described in the aspect name, not a specific value. In addition, one line of step s11 is described in the aspect template t1. In step s11, the generation of a MAP <MAP> type variable varTable in the memory (memory device 103) is defined. The MAP <MAP> type refers to a data type that can store a key name and a MAP type variable in association with each other. In the present embodiment, using such a MAP <MAP> type variable varTable, a library method call history (execution history) by an application to be inspected is managed.

  FIG. 11 is a diagram conceptually illustrating an example of a data structure for managing a library call history in the present embodiment.

  In the figure, the variable varTable is represented in a table format for convenience. The variable varTable stores a thread identifier as a key and a history table as a value. The thread identifier is an identifier of a thread in which the history recording program Pr operates during application test (inspection). In a multi-thread environment, the history recording program Pr can be executed in parallel on a plurality of threads. And the rule description about the library (rule about the context) needs to be satisfied for each thread. Therefore, the variable varTable stores a history table in association with each thread. In the case of a library for communication, a history table may be stored for each session (corresponding to a session ID) in the variable varTable. In addition, when the rule description needs to be satisfied in units other than threads or sessions, a history table may be associated with each unit.

  On the other hand, the history table is a variable of the MAP <boolean> type that is referred to by a variable name “currentTable” in the history recording program Pr generated in the present embodiment. The currentTable variable (history table) stores a variable name of a rule element as a key or a variable name assigned to each method in the rule element, and a true / false value indicating whether the rule element is satisfied as a value, or A true / false value indicating whether or not the method is called (executed) is stored.

  Subsequently, the program generation unit 13 applies the rule name specified by the user to the <aspect name> of the aspect template t1 (replaces <aspect name> with the rule name) and relates to the rule name. A specific aspect source code (aspect code) corresponding to the rule description rd1 is generated (S202).

  FIG. 12 is a diagram illustrating a specific example of the first aspect code. In the aspect code ac1 in the figure, “<Aspect name>” in FIG. 10 is replaced with “SSLSocket”. That is, in the present embodiment, it is assumed that the rule name related to the rule description rd1 is “SSLSocket”.

  In step S202, not only the rule name fitting but also a file including the aspect code ac1 to which the rule name is applied is generated in the auxiliary storage device 102.

  Subsequently, the history recording program generation unit 131 reads the rule element list rL1 (FIG. 8) and the formula structure associated with the designated rule name from the auxiliary storage device 102 into the memory device 103 (S203). Subsequently, the history recording program generation unit 131 sets an unprocessed rule element as a processing target in the read rule element list rL1 (S204). An unprocessed rule element refers to a rule element that is not a processing target in step S205. Accordingly, initially, all rule elements included in the read rule element list rL1 are unprocessed rule elements.

  Subsequently, the history recording program generation unit 131 executes generation processing of the history recording program Pr for the rule element to be processed (hereinafter referred to as “current rule element”) (S205). In the generation process of the history recording program Pr, the source code as the history recording program Pr is added to the aspect code ac1 generated in step S202 for the current rule element. Step S205 is executed in order for all rule elements included in the read rule element list rL1 (S206).

  Subsequently, the detection program generation unit 132 executes generation processing of the detection program Pc (S207). In the generation process of the detection program Pc, the source code as the detection program Pc for the rule description corresponding to the specified rule name is added to the aspect code ac1 generated in step S202. Therefore, the history recording program Pr and the detection program Pc are generated as one source code as a file unit (as a source code unit).

  Next, details of the process of generating the history recording program Pr in step S205 will be described. The generation process of the history recording program Pr differs depending on whether the current rule element is a Before rule element, an After rule element, a Call rule element, or a type designation Call rule element. Therefore, the history recording program generation unit 131 determines which type the current rule element is, and branches the process. Hereinafter, each processing procedure after branching will be described.

  First, generation processing of the history recording program Pr related to the Before rule element (@Before (a, b, c)) will be described. In the generation process, a history recording program Pr for executing the following process is generated. In the following description, a method, b method, and c method refer to a method, b method, or c method in @Before (a, b, c).

  (1) The execution of the c method is hooked (detected), and the evaluation value of the Before rule element (a true / false value indicating whether the requirement of the element is satisfied) is set to true. Further, a true / false value indicating whether or not the a method has been executed is set to false (not executed).

  (2) The execution of the a method is hooked (detected), and a true / false value indicating whether or not the a method has been executed is set to true (executed).

  (3) The execution of the b method is hooked (detected), and a true / false value indicating whether or not the a method has been executed is set as the evaluation value of the Before rule element.

  Therefore, when the a method is not executed before the b method is executed even though the b method is executed, the history recording program Pr that records false as the evaluation value of the Before rule element is generated.

  The details of the process of generating the history recording program Pr will be described below.

  FIG. 13 is a flowchart for explaining an example of the processing procedure of the history recording program generation processing regarding the Before rule element. That is, this figure is an example of the processing procedure of the generation process of the history recording program Pr when the current rule element is the Before rule element.

  In step S301, a pointcut definition for hooking the call to the c method of the current rule element is additionally generated in the aspect code ac1. Specifically, the history recording program generation unit 131 acquires the pointcut definition template from the template data storage unit 14, and adds the result of applying the c method of the current rule element to the pointcut definition template to the aspect code ac1. The point cut definition is a definition of a set of one or more join points in an aspect-oriented programming language. A join point is a point on the code that weaves an aspect. In other words, the join point refers to a position where hooking is performed in the target program.

  FIG. 14 is a diagram illustrating an example of a pointcut definition template. In the pointcut definition template t2 in the figure, the pointcut name and the method name of the method to be the join point are parameterized as <pointcut name> or <method name>, respectively. The point cut type of the point cut definition template t2 is “call”. Accordingly, the pointcut definition template t2 is a pointcut definition template that uses a method call related to <method name> as a join point.

  In step S301, the history recording program generating unit 131 replaces <pointcut name> of the pointcut definition template t2 with an appropriate value, replaces <method name> with the method name of the c method of the current rule element, and A pointcut definition for the c method is generated.

  FIG. 15 is a diagram showing a first specific example of the pointcut definition in the history recording program. The point cut definition pc11 in the figure is applied when the c method of the rule element on the first line in FIG. 8 (hereinafter referred to as “rule element R1”) is applied to the point cut definition template t2 in FIG. Pointcut definition to be generated. That is, it is assumed that the rule element R1 is the current element at the current stage.

  In the point cut definition pc11, <point cut name> of the point cut definition template t2 is replaced with “callR1-c”. Also, <method name> in the pointcut definition template t2 is replaced with the method name “httpServlet.doPost ()” of the c method in the rule element R1. The pointcut name is guaranteed to be unique among the pointcut definitions, and an arbitrary character string may be designated within the scope of the programming language specification. In the present embodiment, the pointcut name for the c method of the Before rule element is generated according to a naming rule “call <variable name of current rule element> -c”. <Variable name of current rule element> is replaced by the variable name for the current rule element. Since the variable name of the rule element R1 is “R1”, it is replaced with “R1”.

  Subsequently, the history recording program generation unit 131 additionally generates before advice definition ad11 (see FIG. 34) for the point cut definition pc11 in the aspect code ac1 (S302). Specifically, the history recording program generation unit 131 acquires a before advice definition template from the template data storage unit 14, and generates a before advice definition based on the before advice definition template.

  Advice refers to processing executed on a joint point in an aspect-oriented programming language. Among advices, before advice means “pre-processing”. That is, the before advice is a process that is woven (incorporated) before the joint point is executed.

  FIG. 16 is a diagram illustrating an example of a before advice definition template. In the before advice definition t5 in the figure, the point cut name is parameterized as <point cut name>.

  Also, the before advice definition template t5 includes three processing steps. Includes three processing steps. Step s51 obtains the identifier of the current thread. In step s52, the history table corresponding to the current thread is acquired from the variable varTable (see FIG. 11), and is substituted into the variable currentTable. Step s53 generates a history table corresponding to the current thread if it has not yet been generated, and substitutes the generated history table into the variable currentTable.

  In step S302, the history recording program generating unit 131 generates a before advice definition by replacing <point cut name> of the before advice definition template t5 with the point cut name ("callR1-c") generated in step S301. To do.

  Subsequently, the history recording program generation unit 131 adds a step for temporarily recording in the history table (variable currentTable) that the requirements of the current rule element are satisfied to the before advice definition (S303). Specifically, the history recording program generation unit 131 acquires a history recording template from the template data storage unit 14, and adds a step related to recording processing to the history table based on the history recording template.

  FIG. 17 is a diagram illustrating an example of a history recording template. In the history record template t4 in the figure, the key name and the value recorded (set) in the history table (variable currentTable) are parameterized as <key name> and <value>, respectively. In step S303, the history recording program generating unit 131 replaces <key name> with the variable name (R1) for the c method of the current rule element (rule element R1), and replaces <value> with true before. Add to advice definition. Details of steps s41 and s42 will be described later.

  Subsequently, the history recording program generation unit 131 adds a step for recording in the history table (variable currentTable) that the a method has not been executed to the before advice definition (S304). Specifically, the history recording program generation unit 131 replaces <key name> of the history recording template t4 with the variable name for the a method of the current rule element (rule element R1), and replaces <value> with false. Add the result to the before advice definition. In the present embodiment, the variable name for the a method is generated according to the naming rule “<variable name of current rule element> -pred”. Therefore, for the a method of rule element R1, <key name> is replaced by the value "R1-pred".

  By executing step S304, a specific before advice definition for the pointcut definition generated in step S301 is completed. FIG. 18 is a diagram illustrating a first example of specific before advice definition.

  For each step included in the before advice definition ad11 in the same figure, the same step number is assigned to the same step as in FIG. 16 or FIG.

  Steps s51 to s53 are as described in FIG. In step s41-1, true is recorded in the history table for the key name of the variable name “R1” of the current rule element. That is, it is temporarily recorded in the history table that the requirement of the rule element R1 is satisfied before the c method is executed. This is because the before advice definition ad11 shown in the figure is executed before the execution of the c method by the action of the pointcut definition pc11. Step s42-1 stores the history table in the variable varTable in association with the identifier of the current thread. As a result, the fact that the requirement of the rule element R1 is satisfied in the current thread is provisionally recorded in the variable varTable.

  Step s41-2 records false for the variable name ("R1-pred") for the a method of the current rule element in the history table (currentTable). That is, it is recorded in the history table that the a method has not been executed. In step s42-2, the history table is stored in the variable varTable in association with the identifier of the current thread. As a result, it is recorded in the variable varTable that the a method is not executed in the current thread.

  Subsequently, the history recording program generation unit 131 additionally generates a pointcut definition for hooking the call of the a method of the current rule element in the aspect code ac1 (S305). Specifically, the history recording program generation unit 131 replaces <point cut name> in the point cut definition template t2 (FIG. 14) with an appropriate value, and replaces <method name> with the method name of the a method of the current rule element. To generate a pointcut definition for the a method.

  FIG. 19 is a diagram showing a second specific example of the pointcut definition in the history recording program. The point cut definition pc12 in the figure is a point cut definition generated when the a method of the rule element R1 (FIG. 8) is applied to the point cut definition template t2 in FIG.

  In the point cut definition pc12, <point cut name> of the point cut definition template t2 is replaced with “callR1-pred”. Also, the <method name> of the pointcut definition template t2 is replaced with the method name “X509TrustManager.checkServerTrusted ()” of the a method in the rule element R1. Note that the point cut name for the a method of the Before rule element is generated according to a naming rule of “call <variable name of current rule element> -pred”.

  Subsequently, the history recording program generation unit 131 additionally generates an after advice definition for the point cut definition generated in step S305 in the aspect code ac1 (S306). Specifically, the history recording program generation unit 131 acquires an after advice definition template from the template data storage unit 14, and generates an after advice definition based on the after advice definition template.

  After advice means “post processing”. That is, the after advice is a process to be incorporated (incorporated) after the joint point is executed.

  FIG. 20 is a diagram illustrating an example of an after advice definition template. In the after advice definition template t3 in the figure, the point cut name is parameterized as <point cut name>.

  The after advice definition template t3 includes three processing steps. Step s31 obtains the identifier of the current thread. In step s32, the history table corresponding to the current thread is acquired from the variable varTable (see FIG. 11), and is substituted into the variable currentTable. A step s33 generates a history table corresponding to the current thread if it has not been generated yet, and substitutes the generated history table into a variable currentTable.

  In step S306, the history recording program generation unit 131 generates an after advice definition by replacing <point cut name> of the after advice definition template t3 with the point cut name ("callR1-pred") generated in step S305. To do.

  Subsequently, the history recording program generation unit 131 adds a step for recording that the a method has been called to the history table (variable currentTable) to the after advice definition generated in step S306 (S307). . Specifically, the history recording program generation unit 131 acquires the history recording template t4 (FIG. 17) from the template data storage unit 14, and adds a step related to the recording process to the history table based on the history recording template t4. . That is, the history recording program generation unit 131 replaces <key name> of the history recording template t4 with the variable name (R1-pred) for the a method of the current rule element (rule element R1), and <value> by true. The replacement result is added to the after advice definition.

  By executing step S307, a specific after advice definition for the pointcut definition generated in step S305 is completed.

  FIG. 21 is a diagram illustrating a first example of a specific after advice definition. With respect to each step included in the after advice definition ad12 in the same figure, the same step number is assigned to the same step as in FIG. 17 or FIG.

  Steps s31 to s33 are as described in FIG. In step s41, true is obtained for the variable name (“R1-pred”) for the a method of the current rule element in the history table (currentTable) acquired from the variable varTable (s32) or newly generated (s33). Record. That is, the fact that the a method has been called is recorded in the history table. In step s42, the history table is stored in the variable varTable in association with the identifier of the current thread. As a result, the fact that the a method has been called in the current thread is recorded in the variable varTable.

  Subsequently, the history recording program generation unit 131 additionally generates a point cut definition for hooking the call of the b method of the current rule element in the aspect code ac1 (S308). Specifically, the history recording program generation unit 131 acquires the pointcut definition template t2 (FIG. 14) from the template data storage unit 14, and applies the b method of the current rule element to the pointcut definition template t2. Add to code ac1. As a result, the point cut definition shown in FIG. 22 is added to the aspect code ac1.

  FIG. 22 is a diagram showing a third specific example of the pointcut definition in the history recording program. The point cut definition pc13 in the figure is a point cut definition generated when the b method of the rule element R1 is applied to the point cut definition template t2 in FIG.

  In the pointcut definition pc13, <pointcut name> of the pointcut definition template t2 is replaced with “callR1-succ”. Also, the <method name> of the pointcut definition template t2 is replaced with the method name “SSLSocket.startHandshake ()” of the b method in the rule element R1. In the present embodiment, the pointcut name for the b method of the Before rule element is generated according to a naming rule “call <variable name of current rule element> -succ”.

  Subsequently, the history recording program generation unit 131 additionally generates an after advice definition for the point cut definition generated in step S308 in the aspect code ac1 (S309). Specifically, the history recording program generation unit 131 replaces the <point cut name> of the after advice definition template t3 with the point cut name (“callR1-suc”) generated in step S308, thereby changing the after advice definition. Generate.

  Subsequently, the program generation unit 13 adds a step for referring to the call history (execution history) related to the a method that should be called before the b method to the after advice definition generated in step S309 (S310). ). This step is generated based on the history reference template acquired from the template data storage unit 14.

  FIG. 23 is a diagram illustrating an example of a history reference template. In the history reference template t6 in the figure, the key name for acquiring a value from the history table (variable currentTable) and the variable name of the variable for storing the acquired value (reference variable) are <key name> and < Parameterized as reference variable name>. In step S310, the history recording program generation unit 131 replaces <reference variable name> with an appropriate value, and replaces <key name> with a variable name for the a method (here, "R1-pred"). Is added to the after advice definition. In the present embodiment, the variable name for referring to the value corresponding to the variable name of the a method is “r1”. Therefore, <reference variable name> is replaced with “r1”. Details of steps s61 and s62 will be described later.

  Subsequently, the program generation unit 13 uses the history recording template t4 (FIG. 17) to add a step for recording the evaluation value of the current rule element in the variable varTable to the after advice definition generated in step S309. (S311). Specifically, the <key name> of the history record template t4 is replaced with the variable name (“R1”) of the current rule element, and the <value> is <reference variable name> of the history record template t4 (FIG. 23). The result of replacement with the same variable name (“r1”) as the replacement destination is added to the after advice.

  By executing step S311, a specific after advice definition for the pointcut definition generated in step S308 is completed.

  FIG. 24 is a diagram illustrating a second example of a specific after advice definition. For each step included in the after advice definition ad13 in the same figure, the same step number is assigned to the same step as in FIG. 16, FIG. 23, or FIG.

  Steps s31 to s33 are as described in FIG. In step s61, a value recorded for the key name “R1-pred” in the history table (variable currentTable) corresponding to the current thread is acquired and substituted into the variable r1. That is, a true / false value indicating whether or not the a method of the current rule element has been executed is assigned to the variable r1.

  Step s62 assigns false to the variable r1 when the value of the variable r1 is null (that is, when the before advice definition ad11 and the after advice definition ad12 are not executed). Therefore, when the advice definition ad13 is executed after the a method is executed, the variable r1 is in a state where true is substituted. In other cases, the variable r1 is in a state where false is substituted. The after advice definition ad13 is a process executed after the b method is executed. Therefore, the case where the advice definition ad13 is executed after the a method is executed corresponds to the case where the b method is executed after the a method is executed. This means that the requirement of the current rule element which is the Before element is satisfied.

  In step s41, the value of the variable r1 is recorded in the history table for the key name of the variable name “R1” of the current rule element. That is, the value of the variable r1 is recorded in the history table as the evaluation value of the current rule element. This is because the value of the variable r1 indicates whether or not the requirement of the current rule element is satisfied as described above.

  In step s42, the history table is stored in the variable varTable in association with the identifier of the current thread. As a result, whether or not the requirements of the current rule element are satisfied in the current thread is recorded in the variable varTable.

  This is the end of the processing procedure when the current rule element is the Before rule element. As shown in FIG. 8, in the case of the present embodiment, the second rule element (rule element R2) in the rule element list rL1 in FIG. 8 is also a Before rule element. Therefore, the processing procedure shown in FIG. 13 is also executed for rule element R2. As a result, in the rule element R2, the source code as described above is generated for each method corresponding to the method a, b, or c.

  Next, the detection program Pc generation process in step S207 in FIG. 9 will be described based on the rule element list rL1 in FIG. Note that the description of the processing procedure of the history recording program Pr generation process when the current element is an After rule element, a Call rule element, or a type designation Call rule element will be deferred for convenience.

  FIG. 25 is a flowchart for explaining an example of the processing procedure of the detection program generation processing.

  In step S401, the detection program generation unit 132 creates a pointcut definition for hooking a method (hereinafter referred to as “caller method”) specified as the last argument of each rule element in the rule element list rL1. To the aspect code ac1. The c rule for the Before rule element, the f method for the After rule element, the h method for the Call rule element, and the j method for the type-specified Call rule element correspond to the caller method. In the present embodiment, the caller method of each rule element in one rule (rule description) needs to be common. This is because it is necessary to detect whether there is a rule violation or not at one place after execution of the caller method.

  The point cut definition template t2 (FIG. 14) is used for generating the point cut definition in step S401. FIG. 26 is a diagram illustrating a specific example of the pointcut definition in the detection program.

  In the point cut definition pc17 of FIG. 14, <point cut name> of the point cut definition template t2 of FIG. 14 is replaced with “callLib”. Also, <method name> is replaced by the method name (“httpServlet.doPost ()”) of the target method of the rule description rd1 (that is, the caller method of each rule element of the rule description rd1). Note that the pointcut name in the pointcut definition for the target method is fixedly replaced with “callLib” in the present embodiment. However, the point cut name may be arbitrarily determined within the specification range of the programming language.

  Subsequently, the detection program generation unit 132 additionally generates an after advice definition for the point cut definition generated in step S401, using the after advice definition template t3 (S402). Specifically, the result obtained by replacing the <point cut name> of the after advice definition template t3 with the point cut name (“callLib”) that is the replacement destination in step S401 is added to the aspect code ac1.

  Subsequently, the detection program generation unit 132 adds a step for referring to the value for the variable name for each variable name included in the expression structure (! R1 || R2) of the rule description rd1 to the aspect code ac1. (S403). Specifically, the detection program generation unit 132 acquires the history reference template t6 (FIG. 23) from the template data storage unit 14, and assigns the variable name to the history reference template t6 as an aspect code for each variable name. Add to ac1.

  The expression structure (! R1 || R2) includes a variable name R1 and a variable name R2. Therefore, the result obtained by replacing <reference variable name> in the history reference template t6 with “r1” and replacing <key name> with “R1” is added. Further, the result of replacing <reference variable name> with “r2” and replacing <key name> with “R2” in the history reference template t6 is added.

  Subsequently, the detection program generating unit 132 adds a step for recording the detection result (detection log) of the presence or absence of rule violation to the aspect code ac1 (S404). This step is generated using the detection log recording template acquired from the template data storage unit 14.

  FIG. 27 is a diagram illustrating an example of a detection log recording template. In the detection log recording template t7 in the figure, <expression> is replaced by an expression in which each variable name in the expression structure is replaced by the variable name of the reference variable to which the value for the variable name is assigned. Details of steps s71 to s74 will be described later.

  By executing step S404, the after advice definition generated in step S402 is completed as shown in FIG.

  FIG. 28 is a diagram illustrating a specific example of after advice definition in the detection program. For each step included in the after advice definition ad17 in the same figure, the same step number is assigned to the same step as in FIG. 20, FIG. 23, or FIG.

  Steps s31 to s33 are as described in FIG. 20, and are generated in step S402. Steps s61-1 to s62-2 are generated in step S403. In step s61-1, the value recorded for the key name “R1” in the history table (variable currentTable) corresponding to the current thread is acquired and substituted into the reference variable r1. That is, a true / false value indicating the evaluation value of the rule element R1 is substituted into the variable r1. Step s62-1 assigns false to the reference variable r1 when the value of the reference variable r1 is null (empty). Therefore, when the requirement of the rule element R1 is satisfied, true is assigned to the reference variable r1, and when the requirement of the rule element R1 is not satisfied, false is assigned to the reference variable r1. Become.

  In step s61-2, the value recorded for the key name “R2” in the history table (variable currentTable) corresponding to the current thread is acquired and substituted into the reference variable r2. That is, a true / false value indicating the evaluation value of the rule element R2 is substituted into the reference variable r2. Step s62-2 assigns false to the reference variable r2 when the value of the reference variable r2 is null (empty). Therefore, when the requirement of the rule element R2 is satisfied, true is assigned to the reference variable r2, and when the requirement of the rule element R2 is not satisfied, false is assigned to the reference variable r2. Become.

  Steps s71 to s74 are processes for recording the detection log for one line (for one record) in the detection log storage unit 16, and are generated in step S404. In the present embodiment, the detection log for one line has a configuration as shown in FIG.

  FIG. 29 is a diagram illustrating a configuration example of a detection log for one line. As shown in the figure, in the present embodiment, the detection log has items such as a rule name, a detection location, and a detection result. The rule name is the rule name of the rule used to detect whether there is a rule violation. The detected part is a part where the existence of violation is detected. In the present embodiment, the detection location is indicated by the method name of the caller method. This is because the presence or absence of rule violation is detected for each caller method. The detection result is a detection result of whether or not there is a rule violation, and “positive” or “negative” is recorded. “Positive” indicates that it is positive for a rule violation, that is, the possibility of a rule violation has been detected. “Negative” indicates that the rule violation is negative, that is, the possibility of the rule violation is not detected.

  Returning to FIG. Step s71 records the rule name of the detection log for one line to be recorded. That is, “log_rule ()” in step s71 is a function for recording a rule name that is a constituent element of the detection log. Also, “rule_name” specified as an argument of “log_rule” is a variable in which the rule name specified at the start of FIG. 5 or FIG. 9 is stored. In step s72, the method name of the caller method common to each rule element of the rule description rd1 is recorded as a detection part of the detection log for one line to be recorded. That is, “log_point ()” in step s72 is a function for recording a detection location that is a constituent element of the detection log. Also, “thisJoinPoint” specified in the argument of “log_point” is a variable in which the method name of the caller method is stored.

  Step s73 determines the true / false value of “! (! R1 || r2)”, and if the value of “! (! R1 || r2)” is true (ie, the rule is not satisfied). In addition, “positive” is recorded in the detection result which is a component of the detection log for one line to be recorded. In step s74, when the value of “! (! R1 || r2)” is false (ie, when the rule is satisfied), detection that is a constituent element of the detection log for one line to be recorded Record “negative” in the result. In other words, “log_result” in steps s73 and s74 is a function that records the value designated as an argument in the detection result that is a component of the detection log.

  The generation of the source code (aspect code ac1) of the history recording program Pr and the detection program Pc for the rule description rd1 is thus completed. As a result, the aspect code ac1 is as shown in FIGS.

  FIGS. 30 and 31 are diagrams showing specific examples of the aspect code of the history recording program and the detection program generated with respect to the first rule description of the present embodiment. 30 and 31 show one aspect code ac1 divided into two drawings for convenience.

  In FIG. 30, the same reference numerals are assigned to the same pointcut definition or advice definition as in FIG. 15, FIG. 18, FIG. 19, FIG. 21, FIG. That is, FIG. 30 shows a point cut definition or an advice definition related to the rule element R1 extracted from the rule description rd1.

  In FIG. 31, the same reference numerals are assigned to the same pointcut definition or advice definition as in FIG.

  In FIG. 31, the pointcut definition pc14 and the after advice definition ad14 are pointcut definitions or advice definitions generated by executing steps S301 to S304 of FIG. 13 for the rule element R2. The point cut definition pc15 and the after advice definition ad15 are point cut definitions or advice definitions generated by executing steps S305 to S307 in FIG. 13 with respect to the rule element R2. The pointcut definition pc16 and the after advice definition ad16 are pointcut definitions or advice definitions generated by executing steps S308 to S311 in FIG. 13 for the rule element R2.

  Next, the case where the current rule element is an after rule element, which is deferred for convenience, will be described with respect to the process of generating the history recording program Pr in step S205 of FIG. Here, it is assumed that the rule description shown in FIG. 32 is read by the rule analysis unit 12 in step S101 of FIG.

  FIG. 32 is a diagram illustrating an example of the second rule description. In the expression described in the rule description rd2 shown in the figure, two After rule elements are connected by the “||” operator. The After rule element of the first term is "@After (java.io.File.delete (), java.io.File.createTempFile (), httpServlet.doPost ())", and the After rule element of the second term Is "@After (java.io.File.deleteOnExit (), java.io.File.createTempFile (), httpServlet.doPost ())".

  Therefore, the expression related to the rule description rd2 is “if java.io.File.createTempFile () is called in httpServlet.doPost (), then java.io.File.createTempFile () will be called after java.io.File.createTempFile ()”. File.delete () must be called, or after calling java.io.File.createTempFile () if java.io.File.createTempFile () is called in httpServlet.doPost () , Java.io.File.deleteOnExit () must be called. "

  When a file is temporarily generated in an application, there is a risk of information leakage unless the file is deleted at the end of the application. In order for the file to be deleted appropriately, a rule that delete () or deleteOnExit () needs to be executed after execution of Java.io.File # createTempFile () may be defined. A rule description rd2 represents the rule using a rule element and an operator.

  As a result of executing Steps S102 to S106 of FIG. 5 for the rule description rd2, the rule element list shown in FIG. 33 is recorded (output) in the auxiliary storage device 102.

  FIG. 33 is a diagram illustrating an example of a second rule element list. In the figure, the variable name “R3” is assigned (generated) to the After rule element of the first term, and the variable name “R4” is assigned (generated) to the After rule element of the second term. Example) is shown. Hereinafter, the after rule element of the first term is referred to as “rule element R3”, and the after rule element of the second term is referred to as “rule element R4”.

  Subsequently, in step S107, the following formula structure (2) is generated.

R3 || R4 (2)
Subsequently, the process described in FIG. 9 is executed by the program generation unit 13 with respect to the rule description rd2. In step S202, a part of the aspect code related to the rule description rd2 is generated.

  FIG. 34 and FIG. 35 are diagrams showing specific examples of the aspect code of the history recording program and the detection program generated with respect to the second rule description of the present embodiment.

  In the drawing, the completed form of the aspect code ac2 generated for the rule description rd2 is shown. The part generated in step S202 is the definition of the aspect and step s11. That is, the content is the same as the aspect code ac1 shown in FIG. Step s11 is the same as step s11 in the aspect code ac1 of FIG. That is, the data structure for recording the history (see FIG. 11) is the same regardless of the type of rule element.

  Next, step S205 in FIG. 9 will be described. All rule elements included in the rule element list rL2 (FIG. 33) are After rule elements. Therefore, the history recording program generation unit 131 executes a process for generating the history recording program Pr related to the After rule element as the generation process of the history recording program Pr. In the generation process, a history recording program Pr for executing the following process is generated. In the following description, d method, e method, and f method refer to d method, e method, and f method in @After (d, e, f).

  (1) The execution of the f method is hooked, and the evaluation value of the After rule element is set to true.

  (2) The execution of the e method is hooked and the evaluation value is set to false.

  (3) The execution of the d method is hooked, and the evaluation value is set to true.

  As described above, when the e method is executed, if the d method is not executed after that, the history recording program Pr having the evaluation value of the After rule element as false is generated.

  The details of the process of generating the history recording program Pr will be described below.

  FIG. 36 is a flowchart for explaining an example of the processing procedure of the history recording program generation processing regarding the After rule element. In the following description, regarding the rule description rd2, the aspect code generated in step S202 of FIG. 9 is referred to as “aspect code ac2”. The state of the aspect code ac2 at the start time in FIG. 36 is the same as the aspect code ac1 shown in FIG.

  In step S501, the history recording program generation unit 131 uses the pointcut definition template t2 (FIG. 14) to generate the aspect code of the pointcut definition pc21 for hooking the call of the f method of the current rule element (rule element R3). Generate additional to ac2. Specifically, the history recording program generation unit 131 replaces <pointcut name> of the pointcut definition template t2 with “callR3-f”, and replaces <method name> with the method name of the f method of the current rule element (“ httpServlet.doPost () "), and a pointcut definition pc21 (see FIG. 34) for the f method is generated. In the present embodiment, the pointcut name for the f method of the After rule element is generated according to the naming rule “call <variable name of current rule element> -f”.

  Subsequently, the history recording program generation unit 131 generates a before advice definition ad21 (see FIG. 34) for the pointcut definition pc21 using the before advice definition template t5 (FIG. 16) and adds it to the aspect code ac2 (S502). ). In step S502, steps s51 to s53 are generated in the before advice definition ad21. The step number corresponds to FIG.

  Subsequently, the history recording program generation unit 131 adds a step for temporarily recording in the history table (variable currentTable) that the requirement of the current rule element is satisfied to the before advice definition ad21 (S503). ). The history recording template t4 (FIG. 17) is used to add the step. The added steps correspond to s41 and 42 in the advice definition ad21 (FIG. 34).

  In step s41 in the advice definition ad21, the variable name (“R3”) of the current rule element (rule element R3) is added to the history table (currentTable) acquired from the variable varTable (s52) or newly generated (s53). ) For true. That is, the fact that the requirement of the rule element R3 is satisfied is temporarily recorded in the history table before the f method is executed. In step s42, the history table is stored in the variable varTable in association with the identifier of the current thread. As a result, the fact that the requirement of the rule element R3 is satisfied in the current thread is temporarily recorded in the variable varTable.

  Subsequently, the history recording program generation unit 131 uses the pointcut definition template t2 (FIG. 14) to generate the pointcut definition pc22 for hooking the call of the e method of the current rule element (rule element R3) with the aspect code ac2 (S504). Specifically, the history recording program generation unit 131 replaces <point cut name> of the point cut definition template t2 with “R3-pred”, and replaces <method name> with the method name of the e method of the current rule element (“ java.io.File.createTempFile () ”) to generate a pointcut definition pc22 (see FIG. 34) for the e method. In the present embodiment, the pointcut name for the e method of the After rule element is generated according to a naming rule “call <variable name of current rule element> -pred”.

  Subsequently, the history recording program generation unit 131 generates an after advice definition ad22 (see FIG. 34) for the pointcut definition pc22 using the after advice definition template t3 (FIG. 20) and adds it to the aspect code ac2 (S505). ). In step S505, steps s31 to s33 are generated in the after advice definition ad22. The step number corresponds to FIG.

  Subsequently, the history recording program generation unit 131 adds a step for temporarily recording in the history table (variable currentTable) that the current rule element is not satisfied to the after advice definition ad22 (S506). . The history recording template t4 (FIG. 17) is used to add the step. The added steps correspond to s41 and s42 in the advice definition ad22 (FIG. 34).

  Step s41 in the advice definition ad22 is false for the variable name (“R3”) of the rule element R3 in the history table (currentTable) acquired from the variable varTable (s32) or newly generated (s33). Record. That is, after the e method is executed, the fact that the requirement of the rule element R3 is not satisfied is temporarily recorded in the history table. In step s42, the history table is stored in the variable varTable in association with the identifier of the current thread. As a result, it is temporarily recorded in the variable varTable that the requirement of the rule element R3 is not satisfied in the current thread.

  In subsequent steps S507 and S508, the history recording program generation unit 131 executes the processing described in steps S504 and S505 for the d method. As a result, the point cut definition pc23 and the after advice definition ad23 from s31 to s33 are generated. In the present embodiment, the pointcut name for the d method of the After rule element is generated according to the naming rule “call <variable name of current rule element> -succ”.

  Subsequently, the history recording program generation unit 131 adds a step for recording in the history table (variable currentTable) that the current rule element is satisfied to the after advice definition ad23 (S509). The history recording template t4 (FIG. 17) is used to add the step. The added steps correspond to s41 and s42 in the advice definition ad23 (FIG. 34).

  This is the end of the processing procedure when the current rule element is an After rule element. As shown in FIG. 33, in the case of the present embodiment, the second rule element (rule element R4) in the rule element list rL2 of FIG. 8 is also an After rule element. Therefore, the processing procedure shown in FIG. 36 is also executed for rule element R4. As a result, in the rule element R4, the source code as described above is generated for each method corresponding to the method d, e, or f. The description of the processing procedure is omitted because it is self-evident from the above.

  Next, regarding the generation process of the history recording program Pr in step S205 of FIG. 5, a case where the current rule element is a Call rule element will be described.

  FIG. 37 is a flowchart for explaining an example of the processing procedure of the history recording program generation processing regarding the Call rule element. In the following description, the g method and h method refer to the g method or h method in @Call (g, h).

  In step S601, the history recording program generation unit 131 additionally generates a pointcut definition for hooking the call to the h method of the current rule element using the pointcut definition template t2 (FIG. 14). To do.

  Subsequently, the history recording program generation unit 131 generates a before advice definition for the pointcut definition using the before advice definition template t5 (FIG. 16) and adds it to the aspect code (S602).

  Subsequently, the history recording program generation unit 131 adds a step for temporarily recording an evaluation value indicating that the requirement of the current rule element is not satisfied to the history table (variable currentTable) to the before advice definition. (S603).

  Subsequently, the history recording program generation unit 131 uses the pointcut definition template t2 (FIG. 14) to add a pointcut definition for hooking the g method call of the current rule element (rule element R3) to the aspect code. Generate (S604).

  Subsequently, the history recording program generation unit 131 generates an after advice definition for the pointcut definition using the after advice definition template t3 (FIG. 20) and adds it to the aspect code (S605).

  Subsequently, the history recording program generation unit 131 adds a step for recording an evaluation value indicating that the current rule element is satisfied in the history table (variable currentTable) to the after advice definition (S606). The history recording template t4 (FIG. 17) is used to add the step.

  Thus, for the Call rule element, the evaluation value is set to false in response to detection of execution of the h method, and the evaluation value is set to true in response to detection of execution of the g method. Therefore, the evaluation value is true only when the g method is called.

  The generation process of the history recording program Pr related to the type designation Call rule element may be, for example, a process in which the h method in FIG. 37 is replaced with the j method and the g method is replaced with the i method. .

  Next, the processing procedure at the time of executing the history recording program Pr and the detection program Pc, specifically the aspect code ac1 (FIGS. 30 and 31) or the aspect code ac2 (FIGS. 35 and 36) will be described.

  FIG. 38 is a flowchart for explaining an example of a processing procedure when the history recording program and the detection program are executed. Prior to the execution of the processing procedure of the figure, the aspect code ac1 or ac2 is compiled. The compiled program is a program that functions as the history recording program Pr and the detection program Pc.

  In step S701, the history recording program Pr and the detection program Pc (that is, the aspect code) are activated in a state where they are applied to the application. In the figure, for the sake of convenience, the application is started in the test program generation device 10. However, the processing of FIG. 38 may be executed in another computer. Further, since application of the aspect code is a known technique, description thereof is omitted.

  A library method is executed (called) in accordance with the progress of processing of the started application. In response to the method execution, the history recording program Pr causes the CPU 104 to record the method execution history (S702). Specifically, the library method call is hooked by the application by the pointcut definition in the history recording program Pr. The advice definition in the history recording program Pr is executed according to the hook of the call, and the history regarding the call is recorded in the variable varTable.

  Subsequently, when the execution of the caller method by the application is completed, the detection program Pc detects whether there is a rule violation based on the history recorded in step S702 and a detection log storage unit for detection results (detection log (FIG. 29)). 16 is executed by the CPU 104 (S703). Specifically, after the caller method is executed, the advice definition in the detection program Pc is executed to detect whether the requirements such as the rule description rd1 or rd2 are satisfied. The detection result is recorded in the detection log storage unit 16 in the form of a detection log (FIG. 29).

  Next, a process for generating the test program Tp for the black box test will be described. FIG. 39 is a flowchart for explaining an example of a processing procedure for generating a test program for a black box test. Before the processing of FIG. 10 is executed, at least one (one line) detection log is stored in the detection log storage unit 16 by executing the history recording program Pr and the rule verification program Pc (applied to the application to be inspected). It shall be remembered.

  In step S <b> 801, the test program generation unit 15 attempts to acquire (read) one unprocessed (one line) detection log from the detection log storage unit 16. “Unprocessed” means that it is not set as a processing target for step S803 and subsequent steps. When the acquisition (reading) is successful (Yes in S802), the test program generation unit 15 tests the test policy corresponding to the rule name and the detection result of the acquired detection log (hereinafter referred to as “target log”). Extracted (searched) from the policy list storage unit 17 (S803).

  FIG. 40 is a diagram illustrating a configuration example of the test policy list storage unit. In the figure, a test policy list storage unit 17 stores a list of test policies (test policy list). One test policy includes information such as a rule name, a detection result, and a test scenario name.

  The rule name and the detection result are the rule name and the detection result corresponding to the test policy. That is, regarding the rule relating to the rule name, when the detection result is detected, it indicates that the test policy is valid (applied). Therefore, it can be said that the rule name and the detection result in the test policy are the application conditions of the test policy. The test scenario name is an identification name of a scenario code to be used for generating the test program Tp when the test policy is applied.

  For example, in the first test policy, in the first test policy, when the detection result is “positive” for the rule (rule description) whose rule name is “SQL-inj”, the scenario named “checkSQLLinj1” The code is shown to be used. In the second test policy, for a rule (rule description) whose rule name is “SQL-inj”, if the detection result is “positive”, a scenario code named “checkSQLLinj2” should be used. It has been shown. Here, the rule names and detection results of the first test policy and the second test policy match. Thus, a plurality of test scenario names (that is, scenario codes) may be associated with the same application condition. Further, the same test scenario name (that is, scenario code) may be associated with a plurality of application conditions (rule name and detection result).

  In step S803, a test policy whose target log matches the rule name and the detection result is extracted. Subsequently, the test program generation unit 15 obtains a copy (duplication) of the scenario code related to the test scenario name specified in the extracted test policy from the scenario code storage unit 18 (S804). When a plurality of test policies are extracted, copies of a plurality of scenario codes are acquired. Here, “copy” is acquired in order to prevent the original version of the scenario code from being rewritten, as will be described later. Accordingly, in the following steps, a copy of the scenario code is the processing target, but is simply referred to as “scenario code”.

  FIG. 41 is a diagram illustrating a first example of a scenario code. FIG. 42 is a diagram illustrating a second example of the scenario code.

  The scenario code sc1 in FIG. 41 is a scenario code whose test scenario name is “checkSQLLinj1”. The scenario code sc2 in FIG. 42 is a scenario code whose test scenario name is “checkSQLLinj2”. Each scenario code independently constitutes one aspect in the aspect-oriented programming language (AspectJ), and basically includes a pointcut definition and an advice definition.

  For example, the scenario code sc1 includes a point cut definition pc31 and an around advice definition ad31. The scenario code sc2 includes a point cut definition pc32 and an around advice definition ad32. The “round advice” is advice that causes a process defined in the “round advice” to be executed instead of the process that should be executed. Note that the advice does not necessarily have to be around advice.

  In the point cut definition of each scenario code, the method name used as a join point is blank (blank) or parameterized, and is represented as <detection location> in FIG. <Detection location> means being replaced by the method name related to the detection location of the detection log. That is, the scenario code has a content that hooks a detection location in the detection log and executes the process defined in the advice definition for the detection location. In the advice definition, a black box test process (test scenario) is defined according to the rule name and the detection result. Therefore, a test scenario that is considered to be effective when a violation or compliance with a specific rule is detected at a specific location (method) is installed in the scenario code.

  In the present embodiment, the aspect name of each scenario code is used as the test scenario name of the scenario code. However, other identification information such as the file name of each scenario code may be used as the test scenario name.

  Subsequently, the test program generation unit 15 writes the value (method name) of the detection location of the target log in the blank portion (<detection location> portion) of each acquired scenario code (S805). Alternatively, the blank part of the acquired scenario code is replaced with the value (method name) of the detected part of the target log.

  Subsequently, the test program generation unit 15 outputs (for example, stores in the auxiliary storage device 102) each scenario code in which the method name is written as the test program Tp (S806). When a plurality of scenario codes are acquired, a plurality of test programs Tp are output.

  Thereafter, the test program generation unit 15 executes steps S803 to S806 for all the detection logs in the detection log storage unit 16 (No in S802), and then ends the process of FIG.

  The test program Tp generated as described above is compiled and applied to an application that uses a library, thereby executing a black box test.

  Next, generation of the test program Tp for the black box test and execution of the black box test will be described based on a specific example of rule description shown in FIG.

  FIG. 43 is a diagram illustrating an example of the third rule description. In the expression described in the rule description rd3 shown in the figure, one Call rule element and two After rule elements are connected by an “&&” operator. The Call rule element of the first term indicates that it is necessary to call PreparedStatement.set * () in AdminLoginServlet.login () (see FIG. 3). Note that “* (asterisk)” in “set *” is a regular expression. Therefore, PreparedStatement.set * () indicates any method that matches the regular expression PreparedStatement.set * ().

  The After rule element in the second term indicates that the execution of PreparedStatement.set * () is essential after the execution of Connection.prepareStatement () in AdminLoginServlet.login () (see FIG. 3). The After rule element of the third term indicates that the execution of PreparedStatement.set.executeQuery () is essential after the execution of PreparedStatement.set * () in AdminLoginServlet.login () (see FIG. 3).

Accordingly, the rule description rd3 defines a rule that each method needs to be called in the following order (a), (b), (c) in AdminLoginServlet.login ().
(A) Connection.prepareStatement ()
(B) PreparedStatement.set * ()
(C) PreparedStatement.set.executeQuery ()
This rule is a contextual rule for countermeasures against SQL injection. This is because it is necessary to call each method in the order of (a), (b), and (c) in order to prevent SQL injection. For convenience, each method is hereinafter referred to as a method (a), a method (b), or a method (c). Further, it is assumed that the rule name related to the rule description rd3 is “SQL-inj”.

  As a result of executing steps S102 to S106 in FIG. 5 for the rule description rd3, the rule element list shown in FIG. 44 is recorded (output) in the auxiliary storage device 102.

  FIG. 33 is a diagram illustrating an example of a third rule element list. In the figure, the variable name “R5” is assigned (generated) to the Call rule element of the first term, and the variable name “R6” is assigned (generated) to the After rule element of the second term. ), An example in which the variable name “R7” is assigned (generated) to the after rule element of the third term is shown. Hereinafter, the Call rule element of the first term is referred to as “rule element R5”, the After rule element of the second term is referred to as “rule element R6”, and the After rule element of the third term is referred to as “rule element R7”.

  Subsequently, in step S107, the following formula structure (3) is generated.

R5 && R6 && R7 (3)
Subsequently, with respect to the rule list and formula structure (3) shown in FIG. 43, the processing described with reference to FIG. 9 and the like is executed, and the history recording program Pr and the detection program Pc related to the rule description rd3 are generated. Since the generation process of the history recording program Pr and the detection program Pc and the contents of the aspect code generated by the generation process are obvious from the description of the rule description rd1 and the rule description rd2, they are omitted.

  Consider a case where the history recording program Pr and the detection program Pc related to the rule description rd3 are applied to an application having the implementation shown in FIG.

  FIG. 45 is a diagram illustrating an implementation example of an application to be inspected. An implementation example (source code) of FIG. An implementation example of the login method is shown. In the login method, the method (a) is called at the portion indicated by (a). Also, the method (c) is called in the part shown in (c).

  When the history recording program Pr and the detection program Pc based on the rule description rd3 are applied to the application ap1 shown in FIG. 45, for example, a detection log as shown in FIG. 46 is recorded in the detection log storage unit 16. The

  FIG. 46 is a diagram showing a specific example of the detection log. In the detection log L1 in the figure, it is indicated that a rule violation (positive) is detected in the AdminLoginServlet.login method for the rule with the rule name SQL-inj (rule description rd3). This is because in the application ap1, the detection program Pc detects that the method (b) has not been called.

At this point, it can be seen that the application ap1 corresponds to the case (B) or the case (D) among the following four cases.
(A) Correct implementation and result is OK
(B) There is a possibility of incorrect mounting, and the result is OK.
(C) Despite the correct implementation, the result is NG
(D) There is a possibility of incorrect mounting, the result is NG
When the process of FIG. 39 is executed based on the detection log L1 and the test policy list shown in FIG. 40, the test policies of the first and second lines in FIG. 40 are extracted. Therefore, the detection location (AdminLoginServlet.login) in the detection log L1 is written to each of the scenario code sc1 shown in FIG. 41 and the scenario code sc2 shown in FIG. As a result, a test program Tp as shown in FIGS. 47 and 48 is generated.

  FIG. 47 is a diagram illustrating a first example of a test program. FIG. 48 is a diagram showing a second example of the test program. 47 and 48, the same or corresponding parts as those in FIG. 41 or 42 are denoted by the same reference numerals.

  In the test program Tp1 of FIG. 47 and the test program Tp2 of FIG. 48, the blank portions (<detection location> in the figure) are respectively replaced by “AdminLoginServlet.login”. Therefore, the test programs Tp1 and Tp2 are programs that hook the call (execution) of the AdminLoginServlet.login method by the application and execute the around advice ad31 or ad32.

  47, in step s81, the character string “dummy” is substituted for id which is the first argument of the AdminLoginServlet.login method. In step s82a, the character string "\" or \ "A \" = \ "A" is substituted for pass, which is the second argument of the AdminLoginServlet.login method.

  In step s83, a process to be originally executed (AdminLoginServlet.login method in FIG. 45) is executed, and the return value is stored in the result. Therefore, in step s83, the AdminLoginServlet.login method is executed based on the values forcibly substituted in steps s81 and s82a for the first argument and the second argument. Note that the AdminLoginServlet.login method returns “true” when authentication is successful, and returns “false” when authentication fails. Therefore, the authentication result is stored in the result of step s83. Step s84a outputs the authentication result.

  On the other hand, in the around advice ad32 in FIG. 48, the same step number is assigned to the same step as the around advice ad31 in FIG. Here, the parts with different step numbers will be described. In step s82b, the character string "\ 'or \' A \ '= \' A" is substituted for pass, which is the second argument of the AdminLoginServlet.login method. The character string is obtained by replacing the double quotation mark (") of the character string" \ "or \" A \ "= \" A "in step s82a of FIG. 47 with a single quotation mark ('). Step s83b outputs the return value (that is, the authentication result) of the AdminLoginServlet.login method, and step s83b outputs a character string ("SQL-inj_single_quot result =") that is output together with the authentication result as shown in FIG. It is different from the character string (“SQL-inj_double_quote result =”) in step s83a. This is because the execution result of the test program Tp1 in FIG. 47 and the execution result of the test program Tp2 in FIG. 48 can be identified.

  Note that the test program Tp1 and the test program Tp2 are both test programs Tp for attempting SQL injection. That is, originally, authentication must fail in both cases of the test program Tp1 and the test program Tp2. This is because the id and pass specified in the test program Tp1 and the test program Tp2 are not valid id or pass.

  However, in the application ap1, the method (b) is not called. Therefore, when the test program Tp1 is applied to the application ap1, the authentication fails, but when the test program Tp2 is applied to the application ap1, Authentication succeeds. That is, in the case of the test program Tp2, SQL injection is successful.

As a result, it is possible to detect security vulnerabilities for the application ap1 by the test program Tp2. That is, it can be seen that the application ap1 corresponds to the case D among the following two cases.
(B) There is a possibility of incorrect mounting, and the result is OK.
(D) There is a possibility of incorrect mounting, the result is NG
Therefore, the tester can recognize that the application ap1 needs to be corrected so as to call the method (b).

It is assumed that only a general black box test is executed instead of a black box test by the test program Tp based on the detection log by the detection log by the history recording program Pr and the detection program Pc. In this case, if a black box test corresponding to the test program Tp1 happens to be executed, authentication in the AdminLoginServlet.login method for the application ap1 fails. Therefore, the tester can recognize that the case falls under either case A or case B below.
(A) Correct implementation and result is OK
(B) There is a possibility of incorrect mounting, and the result is OK.
However, it is difficult to immediately distinguish whether it corresponds to case A or case B.

If a black box test corresponding to the test program Tp2 happens to be executed, authentication in the AdminLoginServlet.login method is successful for the application ap1. Therefore, the tester can recognize that it corresponds to one of the following cases C or D.
(C) Despite the correct implementation, the result is NG
(D) There is a possibility of incorrect mounting, the result is NG
However, it is difficult to immediately distinguish whether it corresponds to case C or case B.

  As described above, according to the present embodiment, first, the presence / absence of a rule violation in context is detected, and the locations where the black box test is performed are narrowed down based on the detection result. Also, a test program Tp for black box test is automatically generated based on the detection result.

  Therefore, the black box test can be carried out in detail with respect to the narrowed portions. As a result, the bug detection accuracy can be improved as compared with the case where only the black box test is performed from the beginning. In addition, since the locations where the black box test is carried out in detail are narrowed down, it is possible to expect an increase in the efficiency of the test work.

  Of the cases A to D, the case A and the case C, and the case B and the case D can be determined by a detection log based on a rule before the black box is executed. In addition, the case A and the case C are discriminated, and the case B and the case D are discriminated based on a black box by the test program Tp automatically generated based on the detection log, the test policy, and the scenario code. Can do.

  In addition, if the program to be inspected contains various processing flows, the black box test results and the detection log indicate whether the black box test satisfies the processing flow coverage originally assumed. It is possible to verify by browsing together. As a result, it can be expected that test coverage will be improved.

  Further, the detection result of rule violation and the scenario code can be associated with each other by a test policy. The test policy can be created based on a policy or intention regarding the black box test owned by the tester. Therefore, the detection result and the scenario code can be freely associated according to the policy or intention of the tester.

  The test policy associates a scenario code according to a combination of a rule name and a location where a rule violation is detected. In other words, different scenario codes can be associated depending on the detected location. As a result, the test program Tp based on the scenario code suitable for the detected location can be generated.

  Further, according to the present embodiment, by creating a rule description, the history recording program Pr and the detection program Pc are automatically generated based on the rule description. By applying the history recording program Pr and the detection program Pc to an application that uses a library, it is possible to check whether or not the library is used by the application. Therefore, the test program generation device 10 can appropriately support detection of violations of rules in the context of the library.

  More specifically, the history recording program Pr collects and records a library method call history. The detection program Pc determines whether or not the history contents conform to the contextual rules of the library. Therefore, it is possible to detect not only the call stack (call parent-child relationship) but also a rule violation related to the presence or absence of the call or the context as in the debugger.

  In the present embodiment, a dynamic hook mechanism is employed for method invocation, and library invocation by an application is detected. Therefore, there is no need to modify the library or application source code. As a result, for example, after the library is created, a rule can be created later and can be provided integrally with the library. By doing so, it is possible to automatically detect contextual rule violations in the course of application testing without providing a separate inspection tool.

  In the present embodiment, the history recording program Pr is an example of a history recording unit. The detection program Pc is an example of a detection unit. The test program generation unit 15 is an example of a generation unit.

  As mentioned above, although the Example of this invention was explained in full detail, this invention is not limited to such specific embodiment, In the range of the summary of this invention described in the claim, various deformation | transformation・ Change is possible.

Regarding the above description, the following items are further disclosed.
(Appendix 1)
Record the execution history according to the detection of the execution of the method by the using program that uses the set of methods,
The history is collated with contextual rule information regarding the set of methods stored in the storage unit, a violation of the rule information regarding execution of the method by the use program is detected, and a detection result is stored in the storage unit. Record,
A test program generation method in which a computer executes a process of generating a test program for executing a test code stored in the storage unit in association with a combination of the rule information and the detection result.
(Appendix 2)
The detection result includes a method name of the method in which the violation is detected,
The test program generation method according to appendix 1, wherein the generation process generates the test program for executing the test precode in response to detection of execution of the method relating to the method name.
(Appendix 3)
A process of generating a history recording program for recording a history of the execution in response to detection of the execution of the method according to the rule information;
The computer executes a process of collating the history with the rule information and generating a detection program for detecting violations of the rule information with respect to the execution of the method by the utilization program,
The history program causes the computer to execute processing for recording the history,
The test program generation method according to appendix 1 or 2, wherein the detection program causes the computer to execute the detection procedure.
(Appendix 4)
The rule information specifies that in the c method, if the b method is executed, the a method must be executed before the b method is executed.
The process of recording the history records that the a method has not been called in response to detection of execution of the c method, records that the a method has been executed in response to detection of execution of the a method, and b The test program generation method according to any one of appendices 1 to 3, wherein the test program generation method detects whether or not the requirement defined in the rule information is satisfied based on whether or not the method a is executed in response to detection of the execution of the method. .
(Appendix 5)
The rule information specifies that, in the f method, if the e method is executed, the d method must be executed after the e method is executed.
The process of recording the history records that the requirement specified in the rule information is satisfied according to the detection of the execution of the f method, and the requirement is satisfied according to the detection of the execution of the e method. 5. The test program generation method according to any one of appendices 1 to 4, wherein the test program generation method records that there is no data and detects that the requirement is satisfied in response to detection of execution of the d method.
(Appendix 6)
The rule information specifies that the g method must be executed in the h method,
The process of recording the history records that the requirement specified in the rule information is not satisfied according to the detection of the execution of the h method, and the requirement is satisfied according to the detection of the execution of the g method. The test program generation method according to any one of appendices 1 to 5, wherein the test program is detected.
(Appendix 7)
A history recording unit that records a history of the execution in response to detection of the execution of the method by a use program that uses a set of methods;
The history is collated with contextual rule information regarding the set of methods stored in the storage unit, a violation of the rule information regarding execution of the method by the use program is detected, and a detection result is stored in the storage unit. A detector for recording;
A test program generation apparatus comprising: a generation unit that generates a test program that executes a test code stored in the storage unit in association with a combination of the rule information and the detection result.
(Appendix 8)
The detection result includes a method name of the method in which the violation is detected,
The test program generation device according to appendix 7, wherein the generation unit generates the test program for executing the test precode in response to detection of execution of the method relating to the method name.
(Appendix 9)
A history recording program generating unit that generates a history recording program for recording the history of the execution in response to detection of the execution of the method according to the rule information;
A detection program generating unit that generates a detection program for detecting violations of the rule information with respect to execution of the method by the use program by comparing the history with the rule information;
The history program causes the test program generation device to function as the history recording unit,
The test program generation device according to appendix 7 or 8, wherein the detection program causes the test program generation device to function as the detection unit.
(Appendix 10)
The rule information specifies that in the c method, if the b method is executed, the a method must be executed before the b method is executed.
The history recording unit records that the a method has not been called in response to detection of execution of the c method, records that the a method has been executed in response to detection of execution of the a method, 10. The test program generation device according to any one of appendices 7 to 9, which detects whether or not a requirement defined in the rule information is satisfied based on whether or not the a method has been executed in response to detection of execution.
(Appendix 11)
The rule information specifies that, in the f method, if the e method is executed, the d method must be executed after the e method is executed.
The history recording unit records that the requirement specified in the rule information is satisfied according to the detection of the execution of the f method, and the requirement is not satisfied according to the detection of the execution of the e method. The test program generation device according to any one of appendices 7 to 10, wherein the test program generation device detects that the requirement is satisfied in response to detection of execution of the d method.
(Appendix 12)
The rule information specifies that the g method must be executed in the h method,
The history recording unit records that the requirement specified in the rule information is not satisfied in response to detection of execution of the h method, and that the requirement is satisfied in response to detection of execution of the g method. 12. The test program generation device according to any one of appendices 7 to 11 for detecting the error
(Appendix 13)
Record the execution history according to the detection of the execution of the method by the using program that uses the set of methods,
The history is collated with contextual rule information regarding the set of methods stored in the storage unit, a violation of the rule information regarding execution of the method by the use program is detected, and a detection result is stored in the storage unit. Record,
A test program generation program for causing a computer to execute a process for generating a test program for executing a test code stored in the storage unit in association with a combination of the rule information and the detection result.
(Appendix 14)
The detection result includes a method name of the method in which the violation is detected,
14. The test program generation program according to appendix 13, wherein the generation process generates the test program for executing the test precode in response to detection of execution of the method relating to the method name.
(Appendix 15)
Processing for generating a history recording program for generating a history recording program for recording the history of the execution in response to detection of execution of the method according to the rule information;
Causing the computer to execute a process for generating a detection program for generating a detection program for detecting violations of the rule information with respect to the execution of the method by the usage program by comparing the history with the rule information;
The history program causes the computer to execute processing for recording the history,
15. The test program generation program according to appendix 13 or 14, wherein the detection program causes the computer to execute the detection procedure.
(Appendix 16)
The rule information specifies that in the c method, if the b method is executed, the a method must be executed before the b method is executed.
The process of recording the history records that the a method has not been called in response to detection of execution of the c method, records that the a method has been executed in response to detection of execution of the a method, and b The test program generation program according to any one of appendices 13 to 15, which detects whether or not a requirement defined in the rule information is satisfied based on whether or not the method a has been executed in response to detection of method execution. .
(Appendix 17)
The rule information specifies that, in the f method, if the e method is executed, the d method must be executed after the e method is executed.
The process of recording the history records that the requirement specified in the rule information is satisfied according to the detection of the execution of the f method, and the requirement is satisfied according to the detection of the execution of the e method. 17. The test program generation program according to any one of appendices 13 to 16, wherein the test program generation program records that the requirement is satisfied in response to detection of the execution of the d method.
(Appendix 18)
The rule information specifies that the g method must be executed in the h method,
The process of recording the history records that the requirement specified in the rule information is not satisfied according to the detection of the execution of the h method, and the requirement is satisfied according to the detection of the execution of the g method. 18. The test program generation program according to any one of supplementary notes 13 to 17, which detects that the

DESCRIPTION OF SYMBOLS 10 Test program generation apparatus 11 Rule description storage part 12 Rule analysis part 13 Program generation part 14 Model data storage part 15 Test program generation part 16 Detection log storage part 17 Test policy list storage part 18 Scenario code storage part 100 Drive apparatus 101 Recording medium 102 Auxiliary storage device 103 Memory device 104 CPU
105 Interface Device 106 Display Device 107 Input Device 131 History Recording Program Generation Unit 132 Detection Program Generation Unit B Bus Pr History Recording Program Pc Detection Program Tp Test Program

Claims (5)

Record the execution history according to the detection of the execution of the method by the using program that uses the set of methods,
The history is collated with contextual rule information regarding the set of methods stored in the storage unit, a violation of the rule information regarding execution of the method by the use program is detected, and a detection result is stored in the storage unit. Record,
A test program generation method in which a computer executes a process of generating a test program for executing a test code stored in the storage unit in association with a combination of the rule information and the detection result. The detection result includes a method name of the method in which the violation is detected,
The test program generation method according to claim 1, wherein the generating process generates the test program for executing the test precode in response to detection of execution of the method related to the method name. A process of generating a history recording program for recording a history of the execution in response to detection of the execution of the method according to the rule information;
The computer executes a process of collating the history with the rule information and generating a detection program for detecting violations of the rule information with respect to the execution of the method by the utilization program,
The history program causes the computer to execute processing for recording the history,
The test program generation method according to claim 1, wherein the detection program causes the computer to execute the detection procedure. A history recording unit that records a history of the execution in response to detection of the execution of the method by a use program that uses a set of methods;
The history is collated with contextual rule information regarding the set of methods stored in the storage unit, a violation of the rule information regarding execution of the method by the use program is detected, and a detection result is stored in the storage unit. A detector for recording;
A test program generation apparatus comprising: a generation unit that generates a test program that executes a test code stored in the storage unit in association with a combination of the rule information and the detection result. Record the execution history according to the detection of the execution of the method by the using program that uses the set of methods,
The history is collated with contextual rule information regarding the set of methods stored in the storage unit, a violation of the rule information regarding execution of the method by the use program is detected, and a detection result is stored in the storage unit. Record,
A test program generation program for causing a computer to execute a process for generating a test program for executing a test code stored in the storage unit in association with a combination of the rule information and the detection result.

Images