JP2019185648A - Debugger, simulation device, and program for debugging - Google Patents

Abstract

To provide debug technology for efficiently debugging automatically.SOLUTION: In a debugger, a scene object management unit 200 generates touch information pertaining to a touch object on the basis of generation source information. The touch information includes at least the position of the touch object, touch hit determination (i.e., touch range) and the type of touch event (e.g., tap, drag, pin) among the information included in the generation source information. The scene object management unit 200 forms the touch information generated this way into a list, and debugs a program on the basis of a touch list that is formed into a list.SELECTED DRAWING: Figure 1

Description

  The present invention relates to a debugging device, a simulation device, and a debugging program.

  In software development, debugging work before shipping a product is one of very important steps (for example, see Patent Document 1). In particular, when a bug is found by user's indication after product shipment, not only the software but also the trust of the company that manufactures and sells the software is damaged.

JP-A-8-137713

  However, software such as consumer games has become increasingly complex in recent years, and programs tend to be enlarged. For this reason, the current situation is that sufficient checks cannot be made before release, and there is a high possibility that bugs will be found by user's indication. In addition, the current debugging work is a human naval tactic that is handled manually, and there is also a problem that it takes enormous costs.

  The present invention has been made in view of the above-described circumstances, and an object thereof is to provide a debugging technique for efficient automatic debugging.

  A debugging device according to an aspect of the present invention includes a creation unit that creates an object based on a program to be debugged, and touch information for specifying the touch object when the created object is a touch object. A first information generation unit that generates, a first list generation unit that generates a touch list that lists the generated touch information, and a debug execution unit that debugs a program based on the touch list And

  According to the present invention, automatic debugging can be efficiently performed.

It is a block diagram which shows the function outline | summary of a debugging apparatus. It is a flowchart which shows the initialization process of an object. It is a flowchart which shows the deletion process of an object. It is a flowchart which shows the production | generation process of touch information. It is a flowchart which shows the production | generation process of the skip condition of a touch object. It is a flowchart which shows the production | generation process of the touch information for pseudo touch objects. It is the figure which showed typically the process from a modal list being created until it is deleted.

  A preferred embodiment of the present invention will be described with reference to the accompanying drawings. Note that each function of the embodiment is realized by predetermined software controlling the computer and peripheral devices. Note that in this specification, description is made assuming a block corresponding to each function and each process (such as “˜unit”), and therefore each hardware and software element corresponds to each block in a one-to-one correspondence. do not do.

  A computer for realizing the present embodiment is installed with a debugging program for debugging the program. In addition to the CPU, ROM, RAM, etc., the computer includes, but is not limited to, an input device such as a keyboard and a mouse, an external storage device such as a hard disk device, an output device such as a liquid crystal panel, and a necessary input / output control circuit. Not the purpose.

  In addition, the form of software that implements the embodiment is typically application software on the OS. However, as long as the present invention can be implemented, the OS is not used, and the software can be freely changed by executing the software on an interpreter. obtain.

  In this specification, “input” includes not only external input but also input from a file or the like. Similarly, “output” includes not only output to the outside but also output to a file or the like.

A. First Embodiment FIG. 1 is a block diagram showing an outline of functions of a debugging device 100 according to the present embodiment.
The debugging apparatus 100 includes a scene object management unit 200 and a control object management unit 300 for an object of a program to be debugged (hereinafter simply referred to as “object”).

The scene object management unit 200 manages a basic screen (so-called “scene”) of a program to be debugged, and performs processes described later in a scene initialization phase, a scene execution phase, and a scene end phase, respectively. Execute. When a scene is changed, the scene to be displayed next is initialized and the currently displayed scene is discarded.
There are various types of objects in the scene, and some of them include touch objects (that is, objects that transition to the next scene or the like in response to a user's touch operation). Examples of touch objects include buttons and banners, but are not limited to this.

[Scene Object Manager 200]
[From scene initialization phase to scene execution phase]
FIG. 2 is a flowchart showing object initialization processing executed by the scene object management unit 200.

  The scene object management unit 200 first determines whether or not it is in a modal state (step S1). Here, the modal state means a state in which the operation target application (in this case, the program to be debugged) is temporarily transiting to a mode that accepts only limited input. For example, the operation target application is modal. For example, a window or modal dialog is open.

  When the scene object management unit 200 determines that the state is a modal state (step S1; YES), the scene object management unit 200 notifies the control object management unit 300 of a modal start (step S2), proceeds to step S3, and selects an object such as a modal window. create. Note that details of the processing after the modal start notification is made will be made clear in the following description.

  On the other hand, when the scene object management unit (creating unit) 200 determines that it is not in a modal state (step S1; NO), it creates an object of the scene (step S3). Here, when the object to be created is a touch object, the scene object management unit 200 notifies the control object management unit 300 that the touch object is to be created (touch object creation notification).

  When the scene object management unit 200 creates the object of the scene, the scene object management unit 200 determines whether all the objects of the scene have been created (step S4). When the scene object management unit 200 determines that there is an object that has not yet been created in the scene (that is, the next object) (step S4; NO), the scene object management unit 200 returns to step S3 and continues creating the object of the scene. If the scene object management unit 200 determines that all objects have been created in the scene during the repeated execution of steps S3 and S4 (step S4; YES), the scene object management unit 200 initializes the objects to the control object management unit 300. Notification is made (step S5), and the process ends.

[Scene execution phase to scene end phase]
FIG. 3 is a flowchart showing object deletion processing executed by the scene object management unit 200.

  For example, when the scene transition timing comes, the scene object management unit 200 starts deleting an object created in the scene (step S1A). Here, when the deleted object is a touch object, the scene object management unit 200 notifies the control object management unit 300 that the touch object is deleted (touch object deletion notification).

  When the scene object management unit 200 deletes the object of the scene, the scene object management unit 200 determines whether all the objects of the scene have been deleted (step S2A). When the scene object management unit 200 determines that there is an object that has not yet been deleted in the scene (that is, the next object) (step S2A; NO), the scene object management unit 200 returns to step S1A and continues to delete the object of the scene. If the scene object management unit 200 determines that all objects have been deleted in the scene while repeatedly executing step S1A and step S2A (step S2A; YES), the scene object management unit 200 determines whether the current state is a modal state. (Step S3A).

  When the scene object management unit 200 determines that the current state is a modal state (step S3A; YES), the scene object management unit 200 notifies the control object management unit 300 of a modal end (step S4A).

  On the other hand, when the scene object management unit 200 determines that the current state is not a modal state (step S3A; NO), the scene object management unit 200 notifies the control object management unit 300 of the end notification of the scene (step S5A) and ends.

[Control Object Management Unit 300]
FIG. 4 is a flowchart showing touch information generation processing executed by the control object management unit 300.
When the control object management unit 300 receives the touch object creation notification of the scene from the scene object management unit 200, the control object management unit 300 acquires information necessary for generating touch information from the created touch object (step S1B). More specifically, the control object management unit 300 determines the position and size of the touch object, the touch hit determination (that is, the touch range), the type of touch event (for example, tap, drag, pin, etc.), and the content of the touch event (for example, , Information representing billing information change, character item change, and the like (hereinafter referred to as “generation source information”) is acquired from the touch object.

  Based on the generation source information, the control object management unit 300 determines whether or not the touch object matches the touch object skip condition (step S2B). The “touch object skip condition” is a condition for determining that the touch object is not executed (that is, skipped), and will be described in detail later.

  If the scene object management unit 200 determines that the touch object meets the skip condition of the touch object based on the generation source information (step S2B; YES), the touch object generation process does not execute the following steps. Exit.

  On the other hand, when the scene object management unit (first information generation unit) 200 determines that the touch object does not match the skip condition of the touch object based on the generation source information (step S2B; NO), the touch information of the touch object Is generated (step S3B). The touch information includes at least the position of the touch object, the touch determination (that is, the touch range), and the type of touch event (for example, tap, drag, pin, etc.) among the information included in the generation information. However, touch information can be expanded, and more complicated control is possible by including other information.

  When the scene object management unit (first list generation unit) 200 generates touch information, the scene object management unit (first list generation unit) 200 generates (registers) a touch list in which the generated touch information is listed (step S4B), and ends the process.

FIG. 5 is a flowchart showing a touch object skip condition generation process executed by the control object management unit 300.
The control object management unit 300 reads a record of the touch object to be skipped (hereinafter referred to as “skip touch object record”) from the definition file of the debugging program (step S1C). As the skip touch object record, for example, it is assumed that the name of the skip condition and the contents of the skip condition (the touch object name, the touch object position, etc.) are registered in association with each other. is not.

  The control object management unit (setting unit) 300 analyzes the skip touch object record and determines whether or not the skip condition is specified by “name of touch object” (step S2C). When the skip condition is defined by the name of the touch object (for example, the first character object) (step S2C; YES), the control object management unit 300 uses the touch object name to be skipped as a touch object. Is registered (added) to the skip list for specifying (step S3C), and it is determined whether or not there is a next skip touch object record (step S7C). If there is a next skip touch object record (step S7C; YES), the control object management unit 300 returns to step S2C and executes the above-described process, but does not have a next skip touch object record. (Step S7C; NO), the process ends.

  Here, if the skip condition is not defined by “name of touch object” (step S2C; NO), the control object management unit (setting unit) 300 defines the skip condition by “position of touch object”. It is determined whether it has been done (step S4C). When the skip condition is defined by the position of the touch object (for example, a predetermined area at the right end of the window) (step S4C; YES), the control object management unit 300 skips the touch object area as described above. It is added to the list (step S5C), and it is determined whether or not there is a next skip touch object record (step S7C). If there is a next skip touch object record (step S7C; YES), the control object management unit 300 returns to step S2C and executes the above-described process, but does not have a next skip touch object record. (Step S7C; NO), the process ends.

  Here, if the skip condition is neither “name of touch object” nor “position of touch object”, the control object management unit 300 determines that an error has occurred in the skip touch object record of the definition file. And reporting that an error has occurred (step S2C → step S4C → step S6C). The control object management unit 300 determines whether there is a next skip touch object record (step S7C). If there is a next skip touch object record (step S7C; YES), the control object management unit 300 returns to step S2C and executes the above-described process, but does not have a next skip touch object record. (Step S7C; NO), the process ends.

FIG. 6 is a flowchart showing a process for generating touch information for a pseudo touch object executed by the control object management unit 300.
The control object management unit 300 reads a record of the pseudo touch object (hereinafter referred to as “pseudo touch object record”) from the definition file for debugging (step S1D). Here, the pseudo touch object means a pseudo touch object that is not included in the program to be debugged. In the present embodiment, as the pseudo touch object record, for example, the name and behavior of the pseudo touch object are registered in association with each other.

  The control object management unit (third information generation unit) 300 analyzes the pseudo touch object record (step S2D), and generates touch information for the pseudo touch object (step S3D). The touch information for the pseudo touch object includes, for example, the name and behavior of the pseudo touch object, but may include other information. When the control object management unit (third list generation unit) 300 generates touch information, the control object management unit (third list generation unit) 300 generates (registers) a pseudo touch list in which the generated touch information is listed (step S4D).

  Then, the control object management unit 300 determines whether or not there is a next pseudo touch object record (step S5D). If there is a next pseudo touch object record (step S5D; YES), the control object management unit 300 returns to step S2D and executes the above-described processing, while there is no next pseudo touch object record. In that case (step S5D; NO), the process is terminated.

  When generating the pseudo touch list, the same pseudo touch object is repeatedly registered in the pseudo touch list to increase the hit rate of the pseudo touch object (in other words, increase the weight value). You may do it. Further, the pseudo touch list and the touch list may be integrated into a single list.

[In the modal state]
When receiving a modal start notification from the scene object management unit 200, the control object management unit 300 performs the following processing.

  In the modal state, no other operation is allowed until the operation requested in the modal window or the like is completed. For this reason, the debug device 100, after starting modal, separates the normal touch list generated for each scene described so far and has an independent list (hereinafter referred to as “modal list”) having higher priority than the normal touch list. Create).

FIG. 7 is a diagram schematically showing a process from creation of a modal list to deletion of the modal list.
When not in a modal state (that is, in a non-modal state before modal start), when the control object management unit 300 creates touch objects for each scene, the control object management unit 300 sequentially generates touch information for these touch objects and registers (adds to the touch list). (See A1 shown in FIG. 7).

  On the other hand, after the modal start, the control object management unit (second information generation unit, second list generation unit) 300 creates a touch object (hereinafter referred to as a modal touch object) related to each modal window or the like. Touch information is sequentially created for the object, and (registered) is added to the modal list (see A2 to A5 shown in FIG. 7).

  After that, when receiving the modal end notification from the scene object management unit 200, the control object management unit 300 deletes the modal list in order, thereby promptly shifting from the modal state to the non-modal state and ending the processing (FIG. A6 and A7 shown in Fig. 7).

  A debugging apparatus (100 debugs a program based on a touch list (including a modal list) created as described above.

  As described above, according to the present embodiment, touch information is generated for each touch object, and the program is debugged based on the touch list in which the touch information is listed. This makes it possible to realize efficient debugging work. Among touch objects, touch objects for which touch information should not be generated (for example, touch objects that hinder debugging work such as a “back button”) are registered in the skip list. For touch objects registered in the skip list, touch information is not generated (that is, not registered in the touch list), so touch objects unnecessary for debugging work are not selected, and debugging work proceeds more efficiently. It becomes possible.

B. Others The present invention is not limited to the above-described embodiments and modifications, and can be implemented in various other forms without departing from the gist of the present invention. For example, the above-described processing steps can be arbitrarily changed in order as long as the processing contents do not contradict each other, or can be executed in parallel.

Further, in this specification, “unit” does not simply mean a physical configuration, but also includes a case where processing executed by the “unit” is realized by software. In addition, even if a process executed by one “unit” is realized by two or more physical configurations or devices, a process executed by two or more “units” is realized by one physical means or device. Also good.
In this embodiment, the program to be debugged has been described as an example. However, the present invention can also be applied to a program not intended for debugging (for example, a simulation program for obtaining some prediction result).

  In addition, a program for performing each process described in this specification may be stored in a recording medium. If this recording medium is used, the above program can be installed in the computer constituting the debugging device 100. Here, the recording medium storing the program may be a non-transitory recording medium. The non-transitory recording medium is not particularly limited, but may be a recording medium such as a CD-ROM.

DESCRIPTION OF SYMBOLS 100 ... Debugging device, 200 ... Sea object management part, 300 ... Control object management part.

Claims (6)

Based on the program to be debugged, a creation unit that creates objects,
When the created object is a touch object, a first information generation unit that generates touch information for specifying the touch object;
A first list generation unit that generates a touch list in which the generated touch information is listed;
A debug device comprising: a debug execution unit that debugs the program based on the touch list. A setting unit for setting a skip condition for identifying a touch object that should not generate the touch information among the touch objects;
The debugging device according to claim 1, wherein the first information generation unit generates the touch information for a touch object that does not match the skip condition among the touch objects. The created objects include modal objects related to modal windows,
When the modal object is a touch object, a second information generation unit that generates modal touch information for specifying the touch object;
The debug device according to claim 1, further comprising: a second list generation unit configured to generate a modal touch list in which the generated modal touch information is listed. A third information generation unit that generates touch information of a pseudo touch object that is not included in the program to be debugged;
The debugging device according to any one of claims 1 to 3, further comprising: a third list generation unit that generates a pseudo touch list in which touch information of the generated pseudo touch object is listed. A creation section for creating an object based on a program;
When the created object is a touch object, a first information generation unit that generates touch information for specifying the touch object;
A first list generation unit that generates a touch list in which the generated touch information is listed;
A simulation apparatus comprising: a simulation execution unit that simulates the program based on the touch list. Computer
Based on the program to be debugged, a creation unit that creates objects,
When the created object is a touch object, a first information generation unit that generates touch information for specifying the touch object;
A first list generation unit that generates a touch list in which the generated touch information is listed;
A debugging program for functioning as a debug execution unit that debugs the program based on the touch list.