JP2014085762A - Analysis system, analysis device, analysis method and analysis program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To efficiently increase code coverage in the dynamic analysis of a program accompanied by a GUI (Graphical User Interface) operation.SOLUTION: An analysis device according to one embodiment includes: a transition model storage part; a transition model updating part; an event execution control part; and a log acquisition part. A transition model storage part is configured to store the transition model of a screen in an application in which a screen transits in accordance with a user event. The transition model updating part is configured to, on the basis of structure information related to the currently displayed current screen, determine similarity between a known screen and the current screen, and to update the transition model such that the current screen which is not similar to the known screen is added. An event execution control part is configured to execute an unexecuted user event on the screen corresponding to the current screen in the transition model.

Description

  The present invention relates to an analysis system, an analysis apparatus, an analysis method, and an analysis program.

  In recent years, software that performs malicious behavior (hereinafter may be referred to as “malware”) is increasing. Analyzing the program code of software as a method to detect unknown malware can be considered, but there are a lot of software on the world, and there are many obfuscated program codes Based on the above, it is considered effective to perform dynamic analysis that monitors the behavior by actually executing the software.

D. Amalfitano, A. Fasolino, and P. Tramontana, “A GUI Crawling-based technique for Android Mobile Application Testing,” In IEEE Fourth International Conference on Software Testing, Verification and Validation Workshops (ICSTW), 2011.

  However, in the conventional dynamic analysis, it has been difficult to efficiently increase the execution rate of program code (hereinafter sometimes referred to as “code coverage”) in software that involves GUI (Graphical User Interface) operations. .

  Specifically, many software program codes are not executed unless a specific input is given. For this reason, in order to obtain high code coverage, it is necessary to give such specific input to the program code. In particular, since software that operates on smartphones that have become popular in recent years is predicated on a GUI, it is necessary to provide input that simulates a user event such as a tap operation or text input. However, unlike the testing process in software development, the specification of the software to be analyzed is not clear in the situation where an unspecified number of software is automatically analyzed. It was difficult to prepare in advance. For this reason, it has been difficult to increase the code coverage efficiently in the conventional dynamic analysis.

  Although it is conceivable to generate user events at random, it is difficult to increase the code coverage even with such a method, and it cannot be said that the dynamic analysis is more efficient.

  The technology disclosed in the present application has been made in view of the above, and an analysis system, an analysis device, an analysis method, and an analysis program that can efficiently increase code coverage in a dynamic analysis of a program that involves a GUI operation. The purpose is to provide.

  An analysis system according to an embodiment is an analysis system including an execution device and an analysis device, and the execution device executes an application whose screen changes in response to a user event that is a user operation, and the application For each screen displayed by the providing unit providing structural information indicating the structure of the screen to the analysis device, the analysis device stores a transition model indicating the screen transition in the application, Each time the user event is executed by the execution unit, a structure information acquisition unit that acquires structure information about the current screen that is currently displayed by the application from the providing unit, and structure information acquired by the structure information acquisition unit Based on the above, the similarity between the known screen whose structure information has been acquired and the current screen is determined, and An update unit that updates the transition model so that a current screen that is not similar to a known screen is added, and an unexecuted user event is executed on the execution unit on the screen corresponding to the current screen in the transition model And an execution control unit for executing log information acquisition from the execution device each time the user event is executed by the execution unit.

  The analysis system, the analysis device, the analysis method, and the analysis program according to the embodiment have an effect that the code coverage can be efficiently increased in the dynamic analysis of the program accompanied with the GUI operation.

FIG. 1 is a diagram illustrating a configuration example of an analysis system according to the first embodiment. FIG. 2 is a diagram illustrating an example of analysis processing performed by the analysis apparatus according to the first embodiment. FIG. 3 is a diagram illustrating an example of a screen displayed by the application. FIG. 4 is a diagram for explaining the structure information according to the first embodiment. FIG. 5 is a diagram illustrating an example of the transition model storage unit according to the first embodiment. FIG. 6 is a diagram illustrating an example of screen state information according to the first embodiment. FIG. 7 is a flowchart illustrating an analysis processing procedure performed by the analysis apparatus according to the first embodiment. FIG. 8A is a diagram for explaining a specific example of the analysis processing according to the first embodiment. FIG. 8B is a diagram for explaining a specific example of the analysis processing according to the first embodiment. FIG. 8C is a diagram for explaining a specific example of the analysis processing according to the first embodiment. FIG. 9 is a diagram illustrating a computer that executes an analysis program.

  Hereinafter, embodiments of an analysis system, an analysis device, an analysis method, and an analysis program according to the present application will be described in detail with reference to the drawings. In addition, the analysis system, the analysis apparatus, the analysis method, and the analysis program according to the present application are not limited by this embodiment.

(First embodiment)
[Configuration of analysis system]
First, the analysis system according to the first embodiment will be described with reference to FIG. FIG. 1 is a diagram illustrating a configuration example of an analysis system 1 according to the first embodiment. The analysis system 1 illustrated in FIG. 1 includes an execution device 10 and an analysis device 100. The execution device 10 and the analysis device 100 are connected to be communicable with each other. Note that the execution device 10 and the analysis device 100 may be communicably connected via a network (not shown).

  The execution device 10 is an emulator that provides an execution environment for application software (hereinafter simply referred to as “application”) analyzed by the analysis device 100. The execution device 10 may be realized by a physical machine such as a PC (Personal Computer), a mobile phone, or a PDA (Personal Digital Assistant), or may be realized by a virtual machine.

  The execution device 10 executes the analysis target application 11 shown in FIG. 1 as an application analyzed by the analysis device 100. The analysis target application 11 is an application analyzed by the analysis apparatus 100, and can be downloaded from a predetermined site (server apparatus), for example. Such an analysis target application 11 is not developed by an analyst using the analysis apparatus 100, and the specification is not clear to the analyst.

  In the following, it is assumed that the analysis target application 11 is an application that operates on an Android OS (Operating System) in a smartphone, a tablet PC, or the like as an example. Many of the analysis target applications 11 are based on a GUI, and the screen changes according to a user operation. For example, the analysis target application 11 receives various user operations by pressing a touch-panel display screen with a finger or a dedicated instrument (for example, a touch pen). Examples of user operations include a tap operation that presses the display screen with a finger and releases it in a short time, a double tap operation that presses the display screen twice, a drag operation that slides the finger while the display screen is pressed, For example, a pinch operation in which both fingers are brought closer to or away from each other while the display screen is pressed with two fingers. Further, the analysis target application 11 accepts not only a user operation for pressing a display screen but also a user operation for pressing a hard key provided in a real machine such as a smartphone. Hereinafter, user operations that can be accepted by the analysis target application 11 may be referred to as “user events”.

  The analysis apparatus 100 analyzes the operation of the analysis target application 11 by causing the execution apparatus 10 to execute the analysis target application 11. Such an analysis apparatus 100 may be realized by a physical machine such as a PC (Personal Computer), or may be realized by a virtual machine.

  Here, analysis processing by the analysis apparatus 100 will be briefly described with reference to FIG. FIG. 2 is a diagram illustrating an example of analysis processing performed by the analysis apparatus 100 according to the first embodiment. As illustrated in FIG. 2, the analysis apparatus 100 according to the first embodiment simulates a user event to the execution apparatus 10 so as to circulate through the generated transition model while generating a screen transition model. Let it run. At this time, the analysis apparatus 100 does not treat each screen that can be actually displayed during the execution of the analysis target application 11 as a different screen, but treats similar screen groups as the same screen.

  Specifically, the analysis apparatus 100 acquires the screen state by analyzing the structure of the screen displayed by the analysis target application 11 after causing the execution apparatus 10 to execute the user event in a simulated manner. Here, the “screen state” indicates an abstract screen structure represented by characteristic parts of the screen structure. In other words, screen groups having the same characteristic parts of the screen structure have the same screen state.

  As shown in FIG. 2, the analysis apparatus 100 sets the screen state as a node (also referred to as “contact” or “vertex”) and the user event as an edge (also referred to as “branch” or “side”). Is generated as a transition model. In this way, the analysis device 100 generates a graph having the screen state as a node, and causes the execution device 10 to sequentially execute an unexecuted user event (edge) in each screen state included in the generated graph.

  For example, FIG. 2 shows that when the user event “tap button A” is executed in the screen state v11, no transition is made from the screen state v11. Here, in practice, the user event “tap button A” may be executed to change to a different screen. However, since the analysis apparatus 100 according to the first embodiment determines the screen transition based on the “screen state” indicating the abstract screen structure, the user event “tap button A” is executed in the screen state v11. Even in such a case, a new screen state is not added to the graph as long as the screen state is the same.

  Here, the reason for treating similar screen groups as the same screen will be described with reference to FIG. FIG. 3 is a diagram illustrating an example of a screen displayed by the application. FIG. 3 shows an example of a screen displayed in the calculator application. Specifically, FIG. 3A shows an example of a screen for inputting numerical values, operators, and the like. FIG. 3B shows an example of a screen in which the numerical value “1” is input in the state of FIG. FIG. 3C shows an example of a screen in a state where a numerical value “2” is input in the state of FIG. FIG. 3D shows an example of a screen for inputting an operator different from those shown in FIGS.

  Among these various screens, when dynamic analysis is performed after treating all of FIGS. 3A to 3D as different screens, the numerical value “0” in each of FIGS. 3A to 3C. ”To“ 9 ”, various user events to which a decimal point and various operators are input are executed. However, in each of FIGS. 3A to 3C, generating a similar user event is redundant, and cannot be said to be an efficient dynamic analysis of an application.

  For example, the behavior of the calculator application when the operator “+” is input in FIG. 3B is the same as the behavior of the calculator application when the operator “+” is input in FIG. Is likely. FIGS. 3B and 3C show the state where the numerical value “1” or “2” is input, but other than these numerical values (for example, “0.1”, “3”, “ In each state where “10”, “100”, etc.) are input, the behavior of the calculator application when the operator “+” is input is also likely to be the same. If dynamic analysis is performed after handling multiple screens with different input numerical values as different screens, user events will be executed excessively, increasing the cost of dynamic analysis. .

  Therefore, the analysis apparatus 100 according to the first embodiment treats similar screen groups as the same screen. For example, the analysis apparatus 100 treats the screens illustrated in FIGS. 3A to 3C as the same screen, and the screen of FIG. 3D to each of FIGS. 3A to 3C. Treat as a different screen. In this case, after executing the user event for inputting the operator “+” in the state of FIG. 3A, the analysis apparatus 100 performs the operator “+” in the state of FIGS. 3B and 3C. Do not execute user event to input. The analysis apparatus 100 treats FIGS. 3B and 3C as the same screen, and treats FIG. 3A as different screens from FIGS. 3B and 3C. May be.

  As described above, the analysis apparatus 100 according to the first embodiment executes an unexecuted user event in each screen state while generating a graph (transition model) having a screen state having an abstract screen structure as a node. The apparatus 10 is made to execute. In other words, the analysis device 100 can prevent similar user events from being executed on a plurality of substantially identical screens by treating similar screens as the same screen state, so that analysis can be performed efficiently. The target application 11 can be executed. Furthermore, since the analysis apparatus 100 sequentially executes unexecuted user events in each screen state that is a node of the graph, the analysis target application 11 can be comprehensively executed. For this reason, the analysis apparatus 100 according to the first embodiment can efficiently increase code coverage in the dynamic analysis of an application that involves a GUI operation. Hereinafter, the execution device 10 and the analysis device 100 that realize such analysis processing will be described in detail.

[Execution device configuration]
First, the configuration of the execution device 10 described above will be described with reference to FIG. As illustrated in FIG. 1, the execution apparatus 10 includes an analysis target application 11, a structure information providing unit 12, and an execution unit 13. Since the analysis target application 11 has already been described, the description thereof is omitted here.

  The structure information providing unit 12 provides the analysis apparatus 100 with structure information indicating the structure of the screen for each screen displayed by the analysis target application 11. The structure information providing unit 12 is realized by, for example, “Window Manager”. Here, the structure information will be described with reference to FIG. FIG. 4 is a diagram for explaining the structure information according to the first embodiment.

  The GUI screen G10 shown in FIG. 4 is a screen for inputting a mail address. The GUI screen G10 includes layouts C21 and C22 in the top layout C11. Further, the layout C21 includes a button C31 (OK button) and a button C32 (Cancel button) for interacting with the user. The layout C22 includes a text C33 such as “Enter e-mail:” and a text box C34 in which an interaction with the user is performed.

  As a data structure for representing such a GUI screen G10, a tree structure as shown on the right side in FIG. 4 is generally used. Among such tree structures, components (button C31, button C32, text C33, text box C34, etc.) that actually interact with the user are arranged in a leaf node. Also, in such a tree structure, components (layouts C11, C21, C22, etc.) relating to the layout and the like are arranged in root nodes other than leaf nodes and internal nodes.

  The structure information providing unit 12 provides structure information represented by a tree structure as shown on the right side of FIG. Note that the structural information represented by such a tree structure corresponds to “View Hierarchy” in the Android application, HTML (HyperText Markup Language) in the Web screen, and the like.

  Returning to the description of FIG. 1, the execution unit 13 executes the analysis target application 11. Specifically, the execution unit 13 executes a user event on the analysis target application 11 in a simulated manner in accordance with an instruction from an event execution control unit 132 of the analysis apparatus 100 described later. Here, “simulated execution” means that when the user event is a tap operation, for example, when the tap operation is not performed on the display screen of the execution apparatus 10 but actually performed. This indicates that the analysis target application 11 is instructed to execute processing. The execution unit 13 is realized by, for example, “addb (adb daemon)” in the Android OS.

[Configuration of analyzer]
Next, the configuration of the analysis apparatus 100 described above will be described. As illustrated in FIG. 1, the analysis apparatus 100 includes a transition model storage unit 110, a transition model generation unit 120, and a terminal control unit 130.

  The transition model storage unit 110 is realized by, for example, a semiconductor memory element such as a RAM (Random Access Memory) or a flash memory, a hard disk, an optical disk, or the like. The transition model storage unit 110 stores a transition model indicating screen transition in the analysis target application 11. Specifically, the transition model storage unit 110 according to the first embodiment stores a graph as illustrated in FIG. 2 as a transition model.

  Here, FIG. 5 illustrates an example of the transition model storage unit 110 according to the first embodiment. In the example illustrated in FIG. 5, the transition model storage unit 110 includes items such as “node”, “edge”, “transition destination node”, “screen state information”, and “log information”. 5 shows an example in which various information corresponding to the graph illustrated in FIG. 2 is stored.

  “Node” indicates a screen state in the transition model. “Edge” indicates a user event in the transition model. “Transition destination node” indicates the screen state of the transition destination when the user event indicated by “edge” is executed in the screen state indicated by “node”. “Screen state information” is information for identifying a screen state, and is information on an abstract screen structure represented by a characteristic component (component) of the screen structure in the screen state indicated by “node”. Show. “Log information” indicates a log acquired by the log acquisition unit 133 described later when a user event indicated by “edge” is executed in the screen state indicated by “node”. The screen status information and the log acquired by the log acquisition unit 133 will be described later.

  For example, FIG. 5 shows that in the screen state v11, user events “tap on button A”, “pressing hard key X”, and “text input” can be executed. FIG. 5 shows that when the user event “tap button A” is executed in the screen state v11, the screen information v11 is changed to the screen state v11, and the log information acquired by the log acquisition unit 133 at that time is “log L11”. ". FIG. 5 shows that the screen state information for identifying the screen state v11 is “I11”.

  Returning to the description of FIG. 1, the transition model generation unit 120 generates a transition model by analyzing the structure information provided by the structure information providing unit 12. The transition model generation unit 120 includes a structure information acquisition unit 121 and a transition model update unit 122.

  The structure information acquisition unit 121 requests the structure information from the execution apparatus 10 and acquires the structure information provided by the structure information providing unit 12 in response to the request. Specifically, the structure information acquisition unit 121 displays a screen (hereinafter referred to as “hereinafter,“ The structure information is acquired from the structure information providing unit 12 in some cases. For example, the structure information acquisition unit 121 acquires a dump of “View Hierarchy” as structure information from the structure information providing unit 12 realized by “Window Manager” or the like.

  The transition model update unit 122 generates a transition model based on the structure information acquired by the structure information acquisition unit 121 and updates the transition model stored in the transition model storage unit 110. Specifically, the transition model update unit 122 generates screen state information from the structure information acquired by the structure information acquisition unit 121. Then, the transition model update unit 122 determines whether the generated screen state information is stored in the transition model storage unit 110. As a result, the transition model update unit 122 determines the similarity between a known screen for which structure information has been acquired and the current screen.

  Then, the transition model update unit 122 updates the transition model storage unit 110 so that a current screen that is not similar to a known screen is added to the transition model. Specifically, the transition model update unit 122 registers the screen state information of the current screen in the “node” and “transition destination node” of the transition model storage unit 110.

  Here, the screen state information generated by the transition model update unit 122 will be described with reference to FIG. FIG. 6 is a diagram illustrating an example of screen state information according to the first embodiment. As described above, the structure information of each screen provided by the structure information providing unit 12 of the execution apparatus 10 is represented by a tree structure. For example, as shown on the left side of FIG. 6, the structure information providing unit 12 provides tree structure data T11 in which structure information is dumped. In the tree structure data T11, the numerical value shown on the left of each row indicates the depth in the tree structure (the number of edges from the root node to the internal nodes and leaf nodes). Further, in the tree structure data T11, “*” (asterisk) is added to the right side of the numerical value of the node that is the target of the user event. Although not shown in FIG. 6, the tree structure data T11 provided by the structure information providing unit 12 has attributes such as the node arrangement position and whether or not such a node is displayed for each node. Information is also included.

  When the tree structure data T11 is acquired by the structure information acquisition unit 121, the transition model update unit 122 selects each node included in the tree structure data T11 from the nodes included in the tree structure data T11. Based on the attribute information and the position of the node in the tree structure, the node that is the target of the user event is determined.

  Specifically, the transition model update unit 122 determines a node that satisfies the following conditions (1) to (4) as a target node of the user event. The transition model update unit 122 can determine whether the following conditions (1) to (3) are satisfied based on the attribute information of each node.

Condition (1): Node that is not arranged outside the screen Condition (2): Node that is not specified to be hidden on the screen Condition (3): Node that corresponds to the user event
(That is, a node with “*” added to the right of the depth value)
Condition (4): a node that is a leaf node in the tree structure

  The transition model update unit 122 generates screen state information by removing all other nodes and edges that do not exist in the path from the target node thus determined to the root node.

  To explain using the example shown in FIG. 6, the transition model updating unit 122 uses two leaf nodes “6: [*] android.widget.Button” among the nodes included in the tree structure data T11 as a user. Assume that the event has been determined as a target node. In such a case, the transition model update unit 122 routes from the two leaf nodes “6: [*] android.widget.Button” to the root node “0: com.android.internal.policy.impl.... The tree structure data T12 shown on the right side of FIG. 6 is generated by removing all other nodes and edges that do not exist in FIG. Then, the transition model update unit 122 extracts only information related to the tree structure from the tree structure data T12 and converts it into a character string (for example, “0, 1, 2, 3, 4, 5, 6 *, 6 * ]) Is hashed to generate screen state information.

  As described above, the transition model update unit 122 generates the screen state information with the node satisfying the above conditions (1) to (4) as the target node of the user event, so that the similarity in each screen can be determined with high accuracy. Can be done. That is, since the transition model update unit 122 can prevent substantially different screens from being handled as the same screen, it is possible to prevent omission of execution of user events. In addition, the transition model update unit 122 removes all other nodes and edges that do not exist in the route from the target node of the user event to the root node, so that substantially the same screen is displayed in the same screen state. Can be handled as That is, since the transition model update unit 122 can prevent the registration of substantially the same screen in the transition model, execution of excessive user events can be reduced.

  The transition model update unit 122 extracts only the information about the tree structure and converts it into a character string (for example, “0, 1, 2, 3, 4, 5, 6 *, 6 *”), and the package name. Further, hashed data may be generated as the screen state information after concatenating the activity name, the input state of the text box (for example, binary indicating whether information is input to all the text boxes), or the like. Here, the “package name” indicates, for example, a name for identifying an application. The “activity name” is, for example, a name given to a module that performs screen operations by an application developer or the like. Since different screens may be controlled by the same module, the same activity name may correspond to different screens. For example, the same activity name may correspond to all the screens shown in FIGS. Without being limited to this example, the same activity names correspond to the screens shown in FIGS. 3A to 3C, and the screens shown in FIG. In some cases, different activity names may correspond to the screen.

  For example, when the screen state information includes the input state of the text box (the binary value indicating whether or not information is input to all the text boxes), the screen state of FIG. This is different from the screen states of b) and (c). On the other hand, when the text box input state is not included in the screen state information, the screen states in FIGS. 3A to 3D are all different. Whether or not to include the package name, activity name, and input state of the text box in such screen state information can be set by an analyst using the analysis apparatus 100.

  Returning to the description of FIG. 1, the terminal control unit 130 causes the execution device 10 to execute the analysis target application 11 and acquires a log from the execution device 10. The terminal control unit 130 includes an event specifying unit 131, an event execution control unit 132, and a log acquisition unit 133.

  The event identification unit 131 identifies an unexecuted user event in the screen state corresponding to the current screen among the transition models stored in the transition model storage unit 110. In addition, when there is no unexecuted user event in the screen state corresponding to the current screen, the event specifying unit 131 searches for an unexecuted user event in another screen state. The processing by the event specifying unit 131 will be described later with reference to FIGS. 7 and 8A to 8C.

  The event execution control unit 132 causes the execution unit 13 of the execution device 10 to execute the user event specified by the event specifying unit 131 in a simulated manner. The processing by the event execution control unit 132 will be described later with reference to FIGS. 7 and 8A to 8C.

  The log acquisition unit 133 acquires log information from the execution device 10 every time a user event is executed by the execution unit 13 according to control by the event execution control unit 132. For example, the log acquisition unit 133 acquires from the execution device 10 information related to the execution environment (application execution log, system log, communication log, etc.), a screen shot on the display screen of the execution device 10, and the like as a log. The processing by the log acquisition unit 133 will be described later with reference to FIGS. 7 and 8A to 8C.

  Note that the transition model generation unit 120 and the terminal control unit 130 described above, for example, a CPU (Central Processing Unit), an MPU (Micro Processing Unit), or the like, causes a program stored in a storage device (not shown) to store the RAM in a work area. This is realized by being executed as Further, for example, the transition model generation unit 120 and the terminal control unit 130 are realized by an integrated circuit such as an application specific integrated circuit (ASIC) or a field programmable gate array (FPGA).

[Analysis processing procedure]
Next, an analysis process procedure performed by the analysis apparatus 100 will be described. In the following, the flow of analysis processing will be described first with reference to FIG. 7, and then a specific example of analysis processing will be described with reference to FIGS. 8A to 8C. FIG. 7 is a flowchart illustrating an analysis processing procedure performed by the analysis apparatus 100 according to the first embodiment.

  As shown in FIG. 7, the structure information acquisition unit 121 of the analysis apparatus 100 acquires the structure information of the current screen currently displayed by the analysis target application 11 from the structure information providing unit 12 (step S101).

  Subsequently, the transition model update unit 122 generates screen state information from the structure information acquired by the structure information acquisition unit 121 (step S102). Specifically, as described with reference to FIG. 6, the transition model update unit 122 removes all other nodes and edges that do not exist in the route from the node that is the target of the user event to the root node. , Generate screen state information.

  Subsequently, the transition model update unit 122 determines whether the screen state information generated in step S102 is stored in the transition model storage unit 110, thereby determining whether the screen state of the current screen is an unknown screen state. It is determined whether or not (step S103).

  Then, when the screen state of the current screen is an unknown screen state (Yes at Step S103), the transition model update unit 122 adds the screen state of the current screen to the transition model stored in the transition model storage unit 110. It adds as a node (step S104). Specifically, the transition model update unit 122 stores information for identifying the screen state of the current screen in the “node” of the transition model storage unit 110 and the “screen state information” of the transition model storage unit 110. The screen state information generated in step S102 is stored. Furthermore, the transition model update unit 122 stores the user event obtained from the screen state information in the “edge” of the transition model storage unit 110.

  That is, when a new screen state is stored in the “node” of the transition model storage unit 110, “edge” and “screen state information” are also stored. Thereby, the event specifying unit 131 described later can determine that an “edge” in which no information is stored in the “transition destination node” is an unexecuted user event.

  Subsequently, the transition model update unit 122 determines whether or not there is a user event executed last time after the processing in step S104 when the screen state of the current screen is not an unknown screen state (No in step S103). (Step S105). That is, the transition model update unit 122 determines whether or not the processing in steps S101 to S104 has been performed after the execution unit 13 executes the user event.

  Then, when there is a user event executed last time (Yes at Step S105), the transition model update unit 122 changes the screen state of the current screen from the previous screen state to the transition model stored in the transition model storage unit 110. An edge for is added (step S106). Specifically, the transition model updating unit 122 selects “transition” of the record in which information for identifying the previous screen state is stored in “node” among the records stored in the transition model storage unit 110. Information for identifying the screen state of the current screen is stored in the “destination node”.

  Subsequently, the event specifying unit 131 determines whether there is an unexecuted user event in the screen state of the current screen (step S107). Specifically, as described above, the event specifying unit 131 stores information in the “transition destination node” among the “edges” stored in the transition model storage unit 110 in association with the screen state of the current screen. If there is an “edge” that is not present, it is determined that an unexecuted user event exists.

  Then, when there is an unexecuted user event (Yes at Step S107), the event identifying unit 131 identifies the unexecuted user event as a user event that causes the execution apparatus 10 to execute. Here, when there are a plurality of unexecuted user events, the event specifying unit 131 specifies an arbitrary user event as a user event that causes the execution apparatus 10 to execute.

  Subsequently, the event execution control unit 132 causes the execution unit 13 of the execution device 10 to execute the user event specified by the event specifying unit 131 (step S108). In addition, after the user event is executed by the execution unit 13, the log acquisition unit 133 acquires a log from the execution device 10 and stores it in the transition model storage unit 110 (step S108). At this time, the log acquisition unit 133 stores the screen state before the user event is executed by the execution unit 13 among the records stored in the transition model storage unit 110 in the “node”, and The log acquired from the execution apparatus 10 is stored in “log information” of the record in which the user event executed by the execution unit 13 is stored in “edge”.

  Then, as long as an unexecuted user event exists in the screen state of the current screen (Yes at Step S107), the analysis apparatus 100 repeatedly performs the processing procedure at Steps S101 to S108.

  On the other hand, when there is no unexecuted user event in the screen state of the current screen (No at Step S107), the event specifying unit 131 sets “1” to the predetermined variable “i” (Step S109).

  Subsequently, the event specifying unit 131 refers to the transition model stored in the transition model storage unit 110, so that the transition can be performed by executing the user event for each user event that can be executed on the current screen. And the total number (score) of unexecuted user events in the screen state up to a depth “i” (i = 1 in this example) that can be transitioned from the screen state of the current screen. (Step S110). In other words, for each user event that can be executed on the current screen, the event specifying unit 131 calculates the total number (score) of user events that have not been executed in the screen state where the number of screen transitions from the screen state of the current screen is “i”. calculate.

  Subsequently, the event identification unit 131 determines whether there is a user event whose score calculated in step S110 is not “0” (step S111).

  Then, when there is a user event whose score is not “0” (Yes at Step S111), the event specifying unit 131 specifies the user event having the maximum score as a user event that causes the execution apparatus 10 to execute.

  Subsequently, the event execution control unit 132 causes the execution unit 13 of the execution device 10 to execute the user event specified by the event specifying unit 131 (step S112).

  On the other hand, when there is no user event whose score is not “0” (No at Step S111), the event specifying unit 131 determines the number of hops (the number of screen transitions) from the current screen state to the transitionable screen state. The maximum value “Dmax” is obtained, and it is determined whether or not the obtained “Dmax” is larger than “i” (step S113).

  If “Dmax” is larger than “i” (Yes at Step S113), the event specifying unit 131 increments “i” (Step S114), and returns to the process of Step S110.

  On the other hand, when “Dmax” is not larger than “i” (No at Step S113), the event specifying unit 131 has the same screen state as the current screen and the screen state at the start of execution of the analysis target application 11. It is determined whether or not there is (step S115).

  Then, when the screen state of the current screen and the screen state at the start are the same (Yes at Step S115), the event specifying unit 131 ends the analysis process. On the other hand, if the screen state of the current screen and the screen state at the start are not the same (No in step S115), the event execution control unit 132 sends a user event for returning to the previous screen from the current screen to the execution unit 13. This is executed (step S116). Here, the “user event returning to the previous screen” is not a user event provided by the analysis target application 11 but, for example, a user event provided by the OS or the like, or an application for operating the analysis target application 11 Corresponds to a user event provided by (browser etc.).

  Note that the log acquisition unit 133 may acquire the log from the execution device 10 and store it in the transition model storage unit 110 even after the user event for returning to the previous screen is executed. In this case, the log acquisition unit 133 stores a user event such as “BACK” at the edge of the transition model storage unit 110 and stores the log acquired from the execution device 10 in the log information of the transition model storage unit 110.

  In the description of FIG. 7 described above, the execution unit 13 is caused to execute a user event for returning from the current screen to the previous screen when the screen state of the current screen and the screen state at the start are not the same. However, even if the screen state of the current screen and the screen state at the start are not the same, the analysis apparatus 100 may end the process without executing the user event for returning to the previous screen. .

[Concrete example]
Next, a specific example of analysis processing by the analysis apparatus 100 will be described with reference to FIGS. 8A to 8C. 8A to 8C are diagrams for explaining a specific example of the analysis processing according to the first embodiment. Hereinafter, a specific example of the analysis process will be described in association with the step number shown in FIG. 8A to 8C, a circle is a node indicating a screen state, a dotted arrow is an edge indicating an unexecuted user event, and a solid arrow is an edge indicating an executed user event.

  In the following description, the initial state is a state in which the analysis target application 11 is activated in the execution apparatus 10 and the initial screen is displayed by the analysis target application 11. In addition, it is assumed that various information is not stored in the transition model storage unit 110 at the start of analysis processing by the analysis apparatus 100.

  First, the structure information acquisition unit 121 acquires the structure information of the current screen (initial screen) from the structure information providing unit 12 (step S101). And the transition model update part 122 produces | generates the screen state information of the present screen based on the structure information acquired by the structure information acquisition part 121 (step S102).

  Here, since various information is not stored in the transition model storage unit 110, the transition model update unit 122 determines that the generated screen state information is not stored in the transition model storage unit 110. That is, the transition model update unit 122 determines that the screen state of the current screen (referred to as screen state v0) is an unknown screen state (Yes in step S103), and stores the current screen in the “node” of the transition model storage unit 110. Information for identifying the current screen state v0 (referred to as “v0”) is stored, and the screen state information of the current screen is stored in “screen state information” of the transition model storage unit 110 (step S104). Also, the transition model update unit 122 stores all user events that can be executed in the screen state v0 of the current screen in the “edge” of the transition model storage unit 110 based on the screen state information of the current screen (step S104). .

  Accordingly, when the transition model stored in the transition model storage unit 110 is represented by a graph, the state illustrated in FIG. 8A (a) is obtained. FIG. 8A (a) shows that there are unexecuted user events e11 and e12 in the screen state v0. That is, the transition model storage unit 110 stores the node “v0”, the edge “e11”, and the screen state information of the screen state v0 in association with each other, and stores the node “v0” and the edge “e12”. And the screen state information of the screen state v0 are stored in association with each other.

  Subsequently, the event specifying unit 131 specifies one of the unexecuted user events e11 and e12 as a user event to be executed by the execution device 10 by referring to the transition model in FIG. 8A (a). Here, it is assumed that the event specifying unit 131 specifies the user event e11. Therefore, the event execution control unit 132 causes the execution unit 13 to execute the user event e11 (step S108). In addition, the log acquisition unit 133 acquires a log from the execution device 10 after the execution unit 13 executes the user event e11, and stores the acquired log in the transition model storage corresponding to the node “v0” and the edge “e11”. The log information is stored in the log information of the unit 110 (step S108).

  Thereafter, the terminal control unit 130 requests the structure information acquisition unit 121 to acquire the structure information. Thereby, the structure information acquisition unit 121 acquires the structure information of the current screen from the structure information providing unit 12 (step S101). And the transition model update part 122 produces | generates the screen state information of a present screen based on the acquired structure information (step S102).

  Here, it is assumed that the screen state of the current screen is different from the screen state v0 before the user event e11 is executed. That is, the transition model update unit 122 determines that the screen state of the current screen (screen state v1) is an unknown screen state (Yes in step S103), and sets “v1” in the “node” of the transition model storage unit 110. , The screen state information of the current screen is stored in “screen state information”, and user events e13, e14, and e15 that can be executed in the screen state v1 are stored in “edge” (step S104).

  Moreover, since the user event e11 executed last time exists (Yes at Step S105), the transition model update unit 122 adds an edge “e11” from the previous screen state v0 to the screen state v1 of the current screen (Step S106). Specifically, the transition model update unit 122 stores “v1” in “transition destination node” of the transition model storage unit 110 corresponding to the node “v0” and the edge “e11”.

  Thus, when the transition model stored in the transition model storage unit 110 is represented by a graph, the state shown in FIG. 8A (b) is obtained. FIG. 8A (b) shows that the user event e11 has been executed in the screen state v0. Further, FIG. 8A (b) shows that the screen state v0 is changed to the screen state v1 when the user event e11 is executed. FIG. 8A (b) shows that there are unexecuted user events e13, e14, and e15 in the screen state v1.

  Subsequently, the event specifying unit 131 specifies a user event to be executed by the execution apparatus 10 by referring to the transition model in FIG. 8A (b). Here, it is assumed that the event specifying unit 131 specifies the user event e13 among the unexecuted user events e13, e14, and e15. Therefore, the event execution control unit 132 causes the execution unit 13 to execute the user event e13 (step S108). In the following, the description of the log acquisition process by the log acquisition unit 133 is omitted, but the log acquisition unit 133 acquires a log from the execution device 10 and makes a transition every time a user event is executed by the execution unit 13. The log information is stored in the model storage unit 110 (step S108).

  Thereafter, the structure information acquisition unit 121 acquires the structure information of the current screen from the structure information providing unit 12 (step S101), and the transition model update unit 122 determines the screen state of the current screen based on the acquired structure information. Information is generated (step S102).

  Here, it is assumed that the screen state of the current screen is the same as the screen state v1 before the user event e13 is executed. That is, since the transition model update unit 122 determines that the screen state v1 of the current screen is not an unknown screen state (No at Step S103), “v1” is not added to the “node” of the transition model storage unit 110.

  However, since there is the user event e13 executed last time (Yes at Step S105), the transition model update unit 122 adds the edge “e13” from the previous screen state v1 to the screen state v1 of the current screen (Step S106). Specifically, the transition model update unit 122 stores “v1” in the “transition destination node” of the transition model storage unit 110 corresponding to the node “v1” and the edge “e13”.

  Subsequently, the event specifying unit 131 specifies the user event e14 that is to be executed by the execution device 10 among the unexecuted user events e14 and e15 in the screen state v1 of the current screen. Therefore, the event execution control unit 132 causes the execution unit 13 to execute the user event e14 (step S108).

  Thereafter, the structure information acquisition unit 121 acquires the structure information of the current screen from the structure information providing unit 12 (step S101), and the transition model update unit 122 determines the screen state of the current screen based on the acquired structure information. Information is generated (step S102).

  Here, the screen state of the current screen is different from the screen state v1 before the user event e14 is executed. That is, the transition model update unit 122 determines that the screen state of the current screen (referred to as screen state v2) is an unknown screen state (Yes in step S103), and sets “v2” in the “node” of the transition model storage unit 110. Is stored in “screen state information”, and user events e16, e17, and e18 that can be executed in the screen state v2 are stored in “edge” (step S104).

  In addition, since there is the user event e14 executed last time (Yes at Step S105), the transition model update unit 122 sets “transition destination node” in the transition model storage unit 110 corresponding to the node “v1” and the edge “e14” to “ v2 "is stored (step S106). Thus, when the transition model stored in the transition model storage unit 110 is represented by a graph, the state shown in FIG. 8A (c) is obtained.

  By repeatedly performing the above-described processing, the event execution control unit 132 executes the user event e16 in the screen state v2, as shown in FIG. 8B (d). As a result, the screen state v2 changes to the screen state v1. Further, it is assumed that the event execution control unit 132 has executed an unexecuted user event e15 in the screen state v1. As a result, it is assumed that the screen state v1 transits to the screen state v3. Thereafter, it is assumed that the event execution control unit 132 has executed an unexecuted user event e19 in the screen state v3. As a result, it is assumed that the screen state v3 has transitioned to the screen state v1.

  When the user events are executed in this order, there is no unexecuted user event in the screen state v1 of the current screen (No at Step S107). Therefore, the event specifying unit 131 sets “1” to the variable “i” (step S109), and the user event is executed for each of the user events e14 and e15 that can be executed in the screen state v1 of the current screen. The total number (score) of unexecuted user events is calculated in the screen state in which the screen state is transitionable and the number of screen transitions from the current screen state v1 to “1” (step S110).

  Here, as shown in FIG. 8B (d), the user events e17 and e18 are not executed in the screen state v2, and the user events e20, e21, and e22 are not executed in the screen state v3. Therefore, the event specifying unit 131 calculates “2” (total number of unexecuted user events in the screen state v2) as the score of the user event e14, and “3” (unexecuted in the screen state v3) as the score of the user event e15. Total number of user events).

  In this example, the event specifying unit 131 does not calculate a score for the user event (the user event e13 in the example of FIG. 8B (e)) for the screen state of the current screen. This is to prevent the scores of the user events from being similar by going through the screen state of the current screen in the search from the screen state of the transition destination of each user event.

  Subsequently, since there is a user event whose score is not “0” (Yes at Step S111), the event specifying unit 131 specifies the user event e15 having the maximum score among the user events e14 and e15. Then, the event execution control unit 132 causes the execution unit 13 to execute the user event e15 specified by the event specifying unit 131 (step S112).

  As a result, the screen state v1 transits to the screen state v3. Since there are unexecuted user events e20 to e22 in the screen state v3 of the current screen (Yes in step S107), the event specifying unit 131 specifies any user event, and the event execution control unit 132 specifies the event The execution unit 13 is caused to execute the user event specified by the unit 131 (step S112). Here, it is assumed that the event execution control unit 132 has executed the user event e20.

  As a result, as shown in FIG. 8B (e), the screen state v3 is transited to the screen state v4. Here, in the screen state v4, there is no unexecuted user event (No in step S107), and there is no screen state that can be transitioned from the screen state v4 (No in step S111, and step S113). denial).

  In this case, since the screen state v4 of the current screen is not the same as the screen state v0 at the start (No at Step S115), the event execution control unit 132 executes the user event for returning from the current screen to the previous screen. (Step S116). In FIG. 8B (e), a one-dot chain arrow from the screen state v4 to the screen state v3 indicates a user event that returns the screen.

  By repeatedly performing the processing described above, the event execution control unit 132 causes the user event e21 to be executed in the screen state v3 and the user event e23 to be executed in the transition destination screen state v5 as shown in FIG. 8C (f). Suppose that As a result, the screen state of the current screen becomes the screen state v3. Thereafter, it is assumed that the event execution control unit 132 executes the user event e22 in the screen state v3 and executes the user event e29 in the transition destination screen state v6. As a result, the screen state of the current screen becomes the screen state v1.

  Then, through the processing in steps S109 to S112, the event execution control unit 132 causes the user event e17 to be executed in the screen state v2 after transitioning from the screen state v1 to the screen state v2, as shown in FIG. 8C (g). It is assumed that the user event e30 is executed in the transition destination screen state v7. As a result, the screen state of the current screen becomes the screen state v2. Thereafter, the event execution control unit 132 executes the user event e18 in the screen state v2, and executes the user event e32 in the transition destination screen state v8. As a result, the screen state of the current screen becomes the screen state v1.

  When the user events are executed in this order, there is no unexecuted user event in the screen state v1 of the current screen (No at Step S107). Therefore, the event specifying unit 131 sets “1” to the variable “i” (step S109), and the user event is executed for each of the user events e14 and e15 that can be executed in the screen state v1 of the current screen. The total number (score) of unexecuted user events is calculated in the screen state in which the screen state is transitionable and the number of screen transitions from the current screen state v1 to “1” (step S110).

  Here, as shown in FIG. 8C (g), there are no unexecuted user events in the screen states v2 and v3. Therefore, the event specifying unit 131 calculates “0” as the scores of the user events e14 and e15.

  Subsequently, since there is no user event whose score is not “0” (No in step S111), the event specifying unit 131 sets “i” = “2” by adding “1” to the variable “i”. (Step S114).

  The event specifying unit 131 is a screen state that can be transitioned by executing the user event for each of the user events e14 and e15 that can be executed in the screen state v1 of the current screen, and the screen of the current screen The total number (score) of unexecuted user events in the screen state where the number of screen transitions from state v1 is “2” is calculated (step S110). Here, the event specifying unit 131 sets “3” as the score of the user event e14 (the total number “1” of unexecuted user events in the screen state v7 and the total number “2” of unexecuted user events in the screen state v8). Is calculated. Further, the event specifying unit 131 sets “5” (the total number of unexecuted user events in the screen state v5 “3”) and the total number “2” of unexecuted user events in the screen state v6 as the score of the user event e15. Sum).

  Subsequently, since there is a user event whose score is not “0” (Yes in step S111), the event specifying unit 131 specifies the user event e15 having the maximum score as a user event that causes the execution apparatus 10 to execute. Thereby, the event execution control unit 132 causes the execution unit 13 to execute the user event e15 (step S112). As a result, the screen state of the current screen is the screen state v3.

  Then, as shown in FIG. 8C (g), since there is no unexecuted user event even in the screen state v3 (No at Step S107), the event specifying unit 131 sets “1” to the variable “i” ( In step S109, a score is calculated for each of the user events e20 to e22 that can be executed in the screen state v3 of the current screen (step S110). As a result, the event specifying unit 131 specifies the user event e21 having the maximum score, and the event execution control unit 132 executes the user event e21. Thereafter, the event specifying unit 131 specifies any of the user events e24 to e26 that have not been executed in the screen state v5, and the event execution control unit 132 sends the user event specified by the event specifying unit 131 to the executing unit 13. Will be executed.

  In this way, the analysis apparatus 100 causes the execution apparatus 10 to execute an unexecuted user event so as to cycle through the graph (transition model) while generating a graph (transition model) having the screen state as a node. .

[Effect of the first embodiment]
As described above, the analysis system 1 according to the first embodiment includes the execution device 10 and the analysis device 100. The execution device 10 includes a structure information providing unit 12 and an execution unit 13. And the execution part 13 performs the application from which a screen changes according to the user event which is user operation. Further, the structure information providing unit 12 provides structure information indicating the structure of the screen to the analysis apparatus 100 for each screen displayed by the application. The analysis apparatus 100 includes a transition model storage unit 110, a structure information acquisition unit 121, a transition model update unit 122, an event execution control unit 132, and a log acquisition unit 133. And the transition model memory | storage part 110 memorize | stores the transition model which shows the screen transition in an application. The structure information acquisition unit 121 acquires, from the structure information providing unit 12, structure information regarding the current screen that is currently displayed by the application every time a user event is executed by the execution unit 13. Based on the structure information acquired by the structure information acquisition unit 121, the transition model update unit 122 determines the similarity between the known screen from which the structure information has been acquired and the current screen, and is similar to the known screen. Update the transition model so that no current screen is added. The event execution control unit 132 causes the execution unit 13 to execute an unexecuted user event on the screen corresponding to the current screen in the transition model. The log acquisition unit 133 acquires log information from the execution device 10 every time a user event is executed by the execution unit 13.

  That is, the analysis system 1 according to the first embodiment generates a screen transition model after treating each similar screen as the same screen state, and refers to the transition model to generate an unexecuted user event. The execution apparatus 10 is made to execute. Accordingly, the analysis system 1 according to the first embodiment can prevent the same user event from being executed on a plurality of substantially identical screens, and thus efficiently executes the analysis target application 11. be able to. Furthermore, since the analysis system 1 sequentially executes unexecuted user events, the analysis target application 11 can be comprehensively executed. For this reason, the analysis system 1 according to the first embodiment can efficiently increase the code coverage in the dynamic analysis of the application accompanied by the GUI operation.

  For example, when the analysis system 1 according to the first embodiment is used, high code coverage can be realized. Therefore, an analyst using the analysis apparatus 100 refers to a log stored in the transition model storage unit 110. Thus, it is possible to analyze with high accuracy whether or not the analysis target application 11 is malware.

  In the analysis system 1 according to the first embodiment, the structural information providing unit 12 displays structural information represented by a tree structure having nodes related to components related to screen layout and components corresponding to user events on the screen. provide. Further, the transition model update unit 122 is based on whether the node groups included in the route from the root node to the node corresponding to the component corresponding to the user event are the same among the tree structure representing the structure information. The similarity between the known screen and the current screen is determined.

  As a result, the analysis system 1 according to the first embodiment can perform the determination of similarity on each screen with high accuracy, and thus can prevent substantially different screens from being handled as the same screen. As a result, the analysis system 1 can prevent omission of execution of the user event. In addition, the analysis system 1 can prevent duplicate registration of substantially the same screen in the transition model, thereby reducing the execution of excessive user events.

  Further, in the analysis system 1 according to the first embodiment, the event specifying unit 131 included in the analysis apparatus 100 is based on the transition model when there is no unexecuted user event on the screen corresponding to the current screen. For each user event that can be executed on the screen, the total number of unexecuted user events on the screen that can be transitioned by executing the user event and has the smallest number of screen transitions from the current screen. Calculate and identify the user event for which the calculated total is the maximum. In addition, the event execution control unit 132 causes the execution unit 13 to execute the user event specified by the event specifying unit 131.

  As a result, the analysis system 1 according to the first embodiment executes an unexecuted user event by giving priority to a screen having a small number of screen transitions from the current screen and a large number of unexecuted user events. Therefore, the transition model can be circulated efficiently.

  In the analysis system 1 according to the first embodiment, the event execution control unit 132 executes a user event for returning to the previous screen from the current screen when the user event is not specified by the event specifying unit 131. To run.

  As a result, the analysis system 1 according to the first embodiment can search for an unexecuted user event even when the current screen is in a screen state (such as a completion screen) without screen transition. Therefore, the code coverage can be efficiently increased in the dynamic analysis of the application accompanied by the GUI operation.

(Second Embodiment)
The analysis system 1 described above may be implemented in various different forms other than the above embodiment. Therefore, in the second embodiment, another embodiment of the analysis system 1 will be described.

[System configuration]
Of the processes described in the above embodiment, all or part of the processes described as being automatically performed can be performed manually, or all of the processes described as being performed manually or A part can be automatically performed by a known method. In addition, the processing procedures, specific names, and information including various data and parameters shown in the document and drawings can be arbitrarily changed unless otherwise specified.

  Further, each component of each illustrated apparatus is functionally conceptual, and does not necessarily need to be physically configured as illustrated. In other words, the specific form of distribution / integration of each device is not limited to that shown in the figure, and all or a part thereof may be functionally or physically distributed or arbitrarily distributed in arbitrary units according to various loads or usage conditions. Can be integrated and configured.

  For example, in the example illustrated in FIG. 1, the structure information acquisition unit 121 and the transition model update unit 122 may be integrated. Further, for example, the event specifying unit 131 and the event execution control unit 132 may be integrated.

[program]
It is also possible to create a program that describes the processing executed by the analysis apparatus 100 described in the above embodiment in a language that can be executed by a computer. For example, an analysis program in which processing executed by the analysis apparatus 100 is described in a language that can be executed by a computer can be created. In this case, when the computer executes the analysis program, the same effect as that of the above embodiment can be obtained. Further, the same processing as in the above embodiment may be realized by recording the analysis program on a computer-readable recording medium, and reading and executing the analysis program recorded on the recording medium. As an example, an example of a computer that executes an analysis program that realizes the same function as that of the analysis apparatus 100 illustrated in FIG. 1 will be described.

  FIG. 9 is a diagram illustrating a computer 1000 that executes an analysis program. As illustrated in FIG. 9, the computer 1000 includes, for example, a memory 1010, a CPU 1020, a hard disk drive interface 1030, a disk drive interface 1040, a serial port interface 1050, a video adapter 1060, and a network interface 1070. These units are connected by a bus 1080.

  The memory 1010 includes a ROM (Read Only Memory) 1011 and a RAM 1012 as illustrated in FIG. The ROM 1011 stores a boot program such as BIOS (Basic Input Output System). The hard disk drive interface 1030 is connected to the hard disk drive 1031 as illustrated in FIG. The disk drive interface 1040 is connected to the disk drive 1041 as illustrated in FIG. For example, a removable storage medium such as a magnetic disk or an optical disk is inserted into the disk drive. The serial port interface 1050 is connected to a mouse 1051 and a keyboard 1052, for example, as illustrated in FIG. The video adapter 1060 is connected to a display 1061, for example, as illustrated in FIG.

  Here, as illustrated in FIG. 9, the hard disk drive 1031 stores, for example, an OS 1091, an application program 1092, a program module 1093, and program data 1094. That is, the above analysis program is stored in, for example, the hard disk drive 1031 as a program module in which a command executed by the computer 1000 is described. For example, a structure information acquisition procedure for executing information processing similar to that of the structure information acquisition unit 121 illustrated in FIG. 1, a transition model update procedure for executing information processing similar to that of the transition model update unit 122, An event specifying procedure for executing the same information processing, an event execution control procedure for executing the same information processing as the event execution control unit 132, and a log acquisition procedure for executing the same information processing as the log acquisition unit 133 are described. The program module 1093 is stored in the hard disk drive 1031.

  In addition, various data held by the transition model storage unit 110 described in the above embodiment is stored as program data, for example, in the memory 1010 or the hard disk drive 1031. Then, the CPU 1020 reads the program module 1093 and program data 1094 stored in the memory 1010 and the hard disk drive 1031 to the RAM 1012 as necessary, and obtains a structure information acquisition procedure, a transition model update procedure, an event identification procedure, an event execution control procedure, Execute the log acquisition procedure.

  Note that the program module 1093 and the program data 1094 related to the analysis program are not limited to being stored in the hard disk drive 1031, but may be stored in, for example, a removable storage medium and read out by the CPU 1020 via the disk drive or the like. Good. Alternatively, the program module 1093 and the program data 1094 related to the analysis program are stored in another computer connected via a network (LAN (Local Area Network), WAN (Wide Area Network), etc.), and via the network interface 1070. May be read by the CPU 1020.

DESCRIPTION OF SYMBOLS 1 Analysis system 10 Execution apparatus 11 Analysis object application 12 Structure information provision part 13 Execution part 100 Analysis apparatus 110 Transition model memory | storage part 121 Structure information acquisition part 122 Transition model update part 131 Event specification part 132 Event execution control part 133 Log acquisition part

Claims (8)

An analysis system including an execution device and an analysis device,
The execution device is
An execution unit that executes an application whose screen changes in response to a user event that is a user operation;
For each screen displayed by the application, a providing unit that provides structural information indicating the structure of the screen to the analysis device,
The analysis device includes:
A storage unit for storing a transition model indicating screen transition in the application;
Each time the user event is executed by the execution unit, a structure information acquisition unit that acquires structure information about the current screen that is currently displayed by the application from the providing unit;
Based on the structure information acquired by the structure information acquisition unit, the similarity between a known screen for which structure information has been acquired and the current screen is determined, and a current screen that is not similar to the known screen is added. An updating unit for updating the transition model to be
An execution control unit that causes the execution unit to execute an unexecuted user event on a screen corresponding to the current screen among the transition models;
An analysis system comprising: a log acquisition unit that acquires log information from the execution device each time the user event is executed by the execution unit. The providing unit includes:
Providing structural information represented by a tree structure having nodes as components related to the layout of the screen and components corresponding to user events on the screen;
The update unit
Based on whether the node group included in the path from the root node to the node corresponding to the component corresponding to the user event is the same among the tree structure representing the structure information, the known screen and the The analysis system according to claim 1, wherein similarity with the current screen is determined. The analysis device includes:
When there is no unexecuted user event on the screen corresponding to the current screen, transition is possible by executing the user event for each user event that can be executed on the current screen based on the transition model. And a specific unit for calculating the total number of unexecuted user events on the screen having the smallest number of screen transitions from the current screen, and identifying the user event having the largest calculated total number,
The execution control unit
The analysis system according to claim 1 or 2, wherein the execution unit is caused to execute the user event specified by the specifying unit. The execution control unit
The analysis system according to claim 3, wherein when the user event is not specified by the specifying unit, the execution unit is caused to execute a user event that returns from the current screen to the previous screen. A storage unit that stores a transition model indicating a screen transition in an application in which a screen transitions according to a user event that is a user operation;
Each time the user event is executed in the execution environment of the application, a structure information acquisition unit that acquires, from the execution environment, structure information regarding the current screen that is currently displayed by the application;
Based on the structure information acquired by the structure information acquisition unit, the similarity between a known screen for which structure information has been acquired and the current screen is determined, and a current screen that is not similar to the known screen is added. An updating unit for updating the transition model to be
An execution control unit for executing an unexecuted user event in the execution environment on the screen corresponding to the current screen in the transition model;
An analysis apparatus comprising: a log acquisition unit that acquires log information from the execution environment each time the user event is executed. An analysis method executed by an analysis system including an execution device and an analysis device,
An execution step in which the execution device executes an application whose screen changes in response to a user event that is a user operation;
A step of providing the analysis apparatus with structural information indicating a structure of the screen for each screen displayed by the application, the execution device;
A structure information acquisition step for acquiring, from the execution device, structure information related to a current screen that is currently displayed by the application each time the user event is executed by the execution device.
Based on the structure information acquired by the structure information acquisition step, the analysis device determines similarity between a known screen for which structure information has been acquired and the current screen, and indicates a screen transition in the application An update process for updating the transition model so that a current screen not similar to the known screen is added to the model;
An execution control step in which the analysis device causes the execution device to execute an unexecuted user event on a screen corresponding to the current screen in the transition model;
An analysis method comprising: a log acquisition step of acquiring log information from the execution device each time the execution event is executed by the execution device. An analysis method executed by an analysis device,
Whenever the user event is executed in an execution environment of an application whose screen changes in response to a user event which is a user operation, structural information acquisition for acquiring structural information about the current screen currently displayed by the application from the execution environment Process,
Based on the structure information acquired by the structure information acquisition step, the similarity between the known screen from which the structure information has been acquired and the current screen is determined, and the known transition model indicating the screen transition in the application An update process for updating the transition model so that a current screen not similar to the screen is added;
An execution control step of causing an unexecuted user event to be executed in the execution environment in a screen corresponding to the current screen in the transition model;
A log acquisition step of acquiring log information from the execution environment each time the user event is executed. Whenever the user event is executed in an execution environment of an application whose screen changes in response to a user event which is a user operation, structural information acquisition for acquiring structural information about the current screen currently displayed by the application from the execution environment Procedure and
Based on the structure information acquired by the structure information acquisition procedure, the similarity between the known screen from which the structure information has been acquired and the current screen is determined, and the known transition model indicating the screen transition in the application An update procedure for updating the transition model so that a current screen that is not similar to the screen is added,
An execution control procedure for executing an unexecuted user event in the execution environment in a screen corresponding to the current screen in the transition model;
An analysis program causing a computer to execute a log acquisition procedure for acquiring log information from the execution environment each time the user event is executed.

Images