KR101526108B1 - Method and System for capturing events, method and system for replaying the recorded events - Google Patents

Method and System for capturing events, method and system for replaying the recorded events Download PDF

Info

Publication number
KR101526108B1
KR101526108B1 KR1020140011564A KR20140011564A KR101526108B1 KR 101526108 B1 KR101526108 B1 KR 101526108B1 KR 1020140011564 A KR1020140011564 A KR 1020140011564A KR 20140011564 A KR20140011564 A KR 20140011564A KR 101526108 B1 KR101526108 B1 KR 101526108B1
Authority
KR
South Korea
Prior art keywords
event
information
shared variable
log file
unit
Prior art date
Application number
KR1020140011564A
Other languages
Korean (ko)
Inventor
이우진
아제이 쿠마르 자
Original Assignee
경북대학교 산학협력단
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 경북대학교 산학협력단 filed Critical 경북대학교 산학협력단
Priority to KR1020140011564A priority Critical patent/KR101526108B1/en
Application granted granted Critical
Publication of KR101526108B1 publication Critical patent/KR101526108B1/en

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/30Monitoring
    • G06F11/34Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

The present invention relates to a method and system of capturing events, and a method and system of reproducing the events recorded by the system of capturing events. More specifically, the present invention relates to the method and system of capturing events which collect operation failure event information of a corresponding application based on an activity when operating an android-based application, and to the method and system of reproducing events which reproduce the collected event information. The system of capturing events comprises: a data collection unit; an event recording unit; a checkpoint detection unit; a crash detection unit; and a log file generation unit.

Description

Technical Field [0001] The present invention relates to an event capture method, a system, and a recorded event playback method and system.

The present invention relates to an event capture method, a system, and an event playback method and system recorded by the event capture system. More particularly, the present invention relates to an event capturing method and system for collecting operation error event information of an application based on an activity based on an Android-based application operation, a system, and an event reproduction method and system for playing back collected event information.

With the rapid growth of smartphones, the use of Android-based applications is rapidly increasing. In addition, the Android platform is being expanded to various fields such as automobiles and home appliances as well as smart phones. As the Android application used in various fields is expanded, it is important to develop a technology for detecting the errors contained in the Android-based application and ensuring the safety of the application.

In general, the process of identifying errors in software is not an easy task. For example, it checks whether there is an error, such as a source code review, or a static program or a real program, such as testing. However, it is not easy to find out where the error actually exists, even if you find out that the program does not work properly through testing. In addition, embedded software using the Android platform has many non-deterministic factors during program execution, making it difficult to reproduce the crash situation.

Content-based and sequence-based capture and replay companies have been studied as a common technique for reproducing error situations. A content-based technique is a method of recording events and associated data generated and reproducing based on recorded information. This method has a time and spatial overhead because it has to store vast amount of log information.

Conversely, an order-based method records a relatively small amount of log but a minor change in the execution environment or input conditions can change the actual execution path of the regeneration step.

In addition, the event capture and playback techniques that reproduce the conventional error occurrence state operate in the Java environment and can not properly reflect the Android characteristics operating in the GUI and activity center.

Korean Patent Laid-Open Publication No. 10-2012-0081873

SUMMARY OF THE INVENTION The present invention provides an event capture method, system, event playback method, and system capable of capturing and playing back an error occurrence state of an Android-based application operating in the GUI and activity center I want to.

An event capturing system according to an aspect of the present invention includes a data collecting unit for collecting information on executed components, thread information, and shard variables output by the thread in a specific application operation; An event recording unit for recording event information collected by the data collection unit; A checkpoint detecting unit for deleting shared variable information among event information recorded by the event recording unit when an operation of a new component is detected during the application operation; A crash detection unit for detecting whether a crash occurs during the application operation; And a log file generation unit for generating a log file in which event information recorded by the event log unit is stored when a crash is detected by the crash detection unit.

The data collection unit may collect relevant event information by applying an aspect-oriented programming technique.

The checkpoint detection unit may detect whether an activity component that manages screen UI information during an Android-based application operation is operating.

Preferably, the checkpoint detection unit may delete the shared variable information among the event information recorded by the event record unit when the operation of the previous activity is completed and a new activity is performed.

According to another aspect of the present invention, there is provided an event reproducing system for reproducing a log file generated by the proposed event capturing system, comprising: an event reproducing unit for reproducing an event using recently executed component and thread information; .

The event reproducing unit reproduces an event using the component and thread information stored in the log file, compares the shared variable value output by the executed thread information with the shared variable value stored in the log file, Value and the shared variable value stored in the log file are different from each other, execution of the current thread information is stopped and the other thread information is executed to compare the output value of the shared variable and the shared variable value stored in the log file.

According to another aspect of the present invention, there is provided an event capturing method comprising: a data collecting step of collecting information on a component to be executed, thread information, and shard variable information output by the thread during a specific application operation; An event recording step of recording event information collected through the data collection step; A checkpoint sensing step of sensing whether a new component is operating during the application operation; A common variable initialization step of deleting the shared variable information among the information collected through the data collection step when it is detected that the new component is operated through the checkpoint sensing step; A crash detection step of detecting whether a crash occurs during the application operation; And a log file storing step of storing information collected through the data collecting step and the shared variable initializing step into a log file when a crash is detected by the crash detecting step.

In the data gathering step, related information may be collected by applying an aspect-oriented programming technique.

In the checkpoint sensing step, an operation of an activity component that manages screen UI information during an Android-based application operation can be detected.

Preferably, in the checkpoint sensing step, it is detected whether an operation of the previous activity is completed and a new activity is performed, and in the initializing of the shared variable, the new activity is detected through the checkpoint sensing step The shared variable information among the information collected through the data collection step can be deleted.

According to another aspect of the present invention, there is provided an event reproducing method for reproducing a log file generated by the event capturing method, the event reproducing method comprising: an event reproducing step of reproducing an event using recently executed component and thread information; .

Wherein the event reproducing step reproduces an event using the component and thread information stored in the log file, compares the shared variable value output by the executed thread information with the shared variable value stored in the log file, When the variable value is different from the shared variable value stored in the log file, execution of the current thread information is suspended and the other thread information is executed to compare the shared variable value output from the shared variable value stored in the log file.

The event capturing method according to an embodiment of the present invention may be implemented as a program that can be executed by a computer, and may be recorded in a computer-readable recording medium.

An event reproducing method according to another embodiment of the present invention can be implemented as a program that can be executed by a computer, and can be recorded on a computer-readable recording medium.

The event capturing method and system according to the preferred embodiment of the present invention can capture GUI events by reflecting the GUI characteristics of Android by recording events based on activity which is a basic component of the Android system.

In addition, the event capturing method, the system, and the event regeneration method and system according to the preferred embodiment of the present invention have an advantage that the average overhead value is low as compared with the conventional event capturing and reproducing method, and there is no need to modify the source code.

1 illustrates an event capture system in accordance with an exemplary embodiment of the present invention;
2 illustrates a log file generated according to an event capture system according to an embodiment of the present invention, and FIG.
3 is a flowchart illustrating an event capturing method according to another example of the present invention.

BRIEF DESCRIPTION OF THE DRAWINGS The present invention is capable of various modifications and various embodiments, and specific embodiments are illustrated in the drawings and described in detail in the detailed description. It should be understood, however, that it is not intended to be limited to the specific embodiments of the invention but includes all modifications, equivalents, and alternatives falling within the spirit and scope of the invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, the present invention will be described in detail with reference to the accompanying drawings.

The terms first, second, etc. may be used to describe various components, but the components should not be limited by the terms. The terms are used only for the purpose of distinguishing one component from another.

The terminology used in this application is used only to describe a specific embodiment and is not intended to limit the invention. The singular expressions include plural expressions unless the context clearly dictates otherwise. In the present application, the terms "comprises" or "having" and the like are used to specify that there is a feature, a number, a step, an operation, an element, a component or a combination thereof described in the specification, But do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, or combinations thereof.

Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings.

1 is a diagram illustrating an event capture system according to an exemplary embodiment of the present invention.

1, the event capture system 100 according to a preferred embodiment of the present invention includes a data collector, an event recorder, a checkpoint detector, a crash detector, A crash detector and a log file generator.

The data collecting unit 110 collects the executed component, thread information, and shard variable information output by the thread during a specific application operation.

Specifically, when the specific application is executed and operated, the data collection unit 110 collects all information about the operation of the application. For example, the application may execute a component, thread information, and shared variable information output by the thread.

In an embodiment applicable to the present invention, the event capture system 100 may be applied to an Android-based application 10. [ At this time, the Android application 10 is composed of four components: an activity 11, a service 12, a content provider 13, and a broadcast receiver 14.

The activity 11 is a basic building block of the Android application 10 and displays a user interface occupying a screen on the screen and processes input by the user. One application is composed of a plurality of activities 11 for displaying respective screens.

The service 12 is mainly used when a task or a remote process task to be performed for a long time is performed in the background, and there is no user interface. When the service 12 is started, it may perform one task indefinitely without giving the caller the result. The bound service, however, provides the caller with a client server interface that interfaces with the service 12.

The content provider 13 manages the data set of the shared application. The application 10 can access data such as files, SQLite databases, the web, or other storage.

Broadcast receiver 14 is responsive to system generated broadcast events such as screen off, battery low, screen capture, and the like. Broadcast events can be generated in applications as well as systems.

The event capturing system 100 according to the present invention collects event information based on the activity (11) component among the four components. That is, the data collecting unit 110 according to the preferred embodiment of the present invention collects activity 11, thread information, and shard variable information output by the thread in which the application operates.

The data collection unit 110 may collect relevant event information by applying an aspect-oriented programming technique. For example, you can use AspectJ programming, which supports view-oriented programming techniques, to collect relevant event information.

Such perspective-oriented programming is a weaving process in which a developer develops cross-cutting concerns that span multiple components into independent modules and then inserts them into related components. For example, commonly used transverse functions such as log, security, etc., are developed as independent modules, transverse interests, and then automatically inserted into the associated portions. The main syntax of context-oriented programming includes a join point to indicate where the interest will be traversed in the main program, a pointcut to indicate when the join point will be matched, a concern code to be executed when the pointcut is activated And advice.

That is, the data collecting unit 110 may collect event information of the Android by inserting a probe code using AspectJ that supports the above-described perspective-oriented programming technique. The probe-code insertion technique based on the viewpoint-oriented programming as described above has an advantage that the application code and the probe code are separated and managed, thereby eliminating the need to modify the existing application code and reusing the probe code.

At this point, join points represent specific points that the developer can intervene in the middle of the application, such as method calls. Advice is an implementation of aspects common to many components, such as storing method call information, and a pointcut defines the point at which such advice is called from a join point. In addition, application execution information is handed over through point cut to utilize for advice body implementation.

The data collecting unit 110 collects the event information together with the execution of the application in which the probe code is inserted. As described above, the data collecting unit 110 collects information about shared variables to be shared by the activity 11, the thread, and one or more threads to be executed.

The event recording unit 120 records event information collected by the data collecting unit 110 through the above-described method. For example, the event recording unit 120 may record the event information in a RAM (Read Access Memory), which is one example of a volatile memory, and may record the event information in a storage device, which is one example of a nonvolatile memory. Alternatively, the event recording unit 120 may record the event information in a separate file.

The event recording unit 120 may record the event information through various methods as described above.

The checkpoint detection unit 130 deletes the shared variable information among the event information recorded by the event recording unit 120 in a specific situation. Specifically, when an operation of a new component, preferably an Android-based activity, of an application is detected during a specific application operation, the checkpoint detection unit 130 detects the shared variable information among the information collected by the data collection unit 110 .

In other words, the checkpoint detecting unit 130 may checkpoint each activity 11 to be executed so that only the information about the related events can be recorded when a subsequent crash occurs.

In general, the Android activity 11 may or may not pass a return value. In the case of returning the return value, since the call activity 11 operates in close cooperation with the call activity 11, the same operation context as the call activity 11 is handled. That is, in the above case, the checkpoint sensing unit 130 does not determine that the new activity 11 is to be operated.

Conversely, the activity 11 that does not pass the return value sets the checkpoint as a start of a new execution context. That is, when the return value is not passed, the checkpoint sensing unit 130 determines that the new activity 11 is to be operated. For example, when the startActivity () method indicating the start of the Android activity 11 is called, the checkpoint detection unit 130 may collect and record the data using the clearLog () pointcut and advise by the data collection unit 110 And deletes the shared variable information among the event information.

In addition, there are cases where the Android activities 11 are sequentially called, but there are cases where the two activities 11 coexist. For example, there may be a case where the first activity 11 is restarted after another activity 11 is executed while one activity 11 is paused. In this case, the storage unit is divided into the activities 11 There may be difficulties in regeneration. Accordingly, since the onPause () is called when the activity 11 is temporarily stopped, the checkpoint detecting unit 130 calls the startActivity () of the other activity 11 without generating the onDestory () end event after the onPause It is possible to continuously store the event information without deleting the event information in the same execution context without newly setting the ground check point.

The crash detection unit 140 detects whether a crash occurs during the application operation. More specifically, the crash detection unit 140 detects whether an exception occurs in which an application is not operated.

In addition, when the crash is detected, the crash detection unit 140 may cause the event recording unit 120 to store the corresponding exception status information as event information.

When a crash is detected by the crash detection unit 140, the log file generation unit 150 generates a log file in which event information recorded by the event recording unit 120 is stored. The log file generation unit 150 receives the related information from the event log unit 120 and generates a log file. However, the log file generation unit 150 generates a log file from the crash detection unit 140, When the detection information is received, the log file can be generated using the event related information recorded by the event recording unit 120 until that time.

Hereinafter, the operation of each technology configuration of the event capture system 100 will be described in detail with reference to an example of FIG.

FIG. 2 is a diagram illustrating a log file generated according to an event capture system according to an embodiment of the present invention.

As shown in FIG. 2, a log file generated according to the event capture system 100 according to an embodiment of the present invention includes an activity, a thread, and a shared variable value . ≪ / RTI > At this time, the value of the shared variable may be initialized and stored every time a new activity is modified. Hereinafter, the operation of each component will be described in detail.

The data collecting unit 110 collects activity, thread, and shared variable values to be performed while the application is operating. At this time, the data collecting unit 110 can collect activity and thread related information and shared variable values according to the thread execution. For example, the A1 activity is running and the T1 thread is running, collecting all shared variable values that are output.

The event information thus collected is recorded by the event recording unit 120.

The checkpoint detection unit 130 determines whether a new activity is operating while the application is operating and deletes a shared variable value among information recorded by the event recording unit 120 when a new activity is performed. That is, the checkpoint detecting unit 130 deletes the collected (or recorded) shared variable value in the previous activity operation by setting the time when the new activity operates as a check point. For example, when the A2 activity is newly activated, all the output shared variable values are deleted according to the execution of the A1 activity (T1 thread), and when the A3 activity is newly activated, the output shared by the A2 activity (T2 thread) The variable value is also deleted.

The data collecting unit 110, the event recording unit 120, and the checkpoint sensing unit 130 repeat the above-described operation during the operation of a specific application. If an exception (i.e., a crash) that is not handled in the application operation occurs during the repetitive execution, the crash detection unit 140 detects the crash and transmits the exception status information to the event log 120. The log file generating unit 150 generates a log file that stores event related information (activity, thread, and shared variable) recorded by the event recording unit 120 until a crash occurs. For example, when a crash occurs when the T4 thread of the A3 activity operates, the log file generating unit 150 generates a log file that stores event related information recorded by the event log unit 120 so far. An example of the generated log file can be shown in FIG.

As described above, the log file stored by the event capturing system 100 according to the present invention includes all activity and thread information performed until a specific application operates and a crash occurs. It has the following advantages.

First, all the activity information is stored in the log file as described above, thereby making it possible to determine whether the execution step (activity call sequence) before the occurrence of the crash is performed in the same manner.

Second, such a technology structure has the advantage that the same identification information (e.g., id information) can be allocated to the same thread, so that operating thread information can be easily grasped.

Hereinafter, an event reproducing system for reproducing an event using log file information generated through the above method will be described in detail.

The event reproducing system according to the present invention includes an event reproducing unit capable of reproducing a log file generated by the event capturing system 100 as described above.

At this time, the event reproducing unit reproduces the event using the recently executed component and thread information among the information in the log file. Preferably, the event reproducing unit may execute an Android application and play an event using recently executed activity and thread information.

That is, when the log file shown in FIG. 2 is generated according to an example of the present invention, the event can be reproduced using the A3 activity and the T3 and T4 thread information.

The event reproducing unit compares the value of the shared variable output by the thread operation with the value of the shared variable stored in the log file while reproducing the event in the same manner as described above. If the output value of the shared variable is different from the value of the shared variable stored in the log file, execution of the current thread information is stopped and the other thread information is executed to compare the output value of the shared variable with the value of the shared variable stored in the log file do.

According to one example of FIG. 2, the event regenerator can execute the A3 activity and execute the T3 thread. At the same time, the shared variable value output according to each operation is compared with the shared variable value stored in the log file. That is, the A3 activity is performed, and the output value of the shared variable and the T3 thread are executed, and the output value of the shared variable is compared in order of '0'.

Thereafter, the event reproducing unit may control operations of the T3 thread and the T4 thread using a semaphore. That is, the event regenerator can control the semaphore to access only the process of the T3 thread or the T4 thread using the semaphore.

That is, the event regenerator may additionally reproduce the T3 thread and compare the output value of the shared variable with the value of the third shared variable stored in the log file. At this time, when the shared variable value output by the T3 thread is '1', the output value is different from the shared variable value stored in the log file. In this case, the event reproducing unit may use the semaphore to reproduce the T4 thread, not the T3 thread, and compare the output value of the shared variable with the value of the third shared variable stored in the log file. Through this process, it is confirmed that the T4 thread is executed and '0' is outputted as the shared variable value, so that the event can be reproduced according to the order in which the event occurred in the event of a crash.

Hereinafter, an event capture method and a playback method according to another exemplary embodiment of the present invention will be described in detail with reference to FIG.

3 is a flowchart illustrating an event capturing method according to another embodiment applicable to the present invention.

3, the event capturing method according to a preferred embodiment of the present invention includes a data collecting step S320, an event recording step S330, a checkpoint detecting step S340, a shared variable initializing step S350 ), A crash detection step (S360), and a log file creation step (S380).

First, when the Android application 10 is executed (S310), the data collection unit 110 collects event related information in the process of executing the Android application 10 (S320). Specifically, in operation S320, information on a component to be executed, thread information, and shard variable information output by the thread are collected during a specific application operation.

The data collecting unit 110 transmits the event related information collected in step S320 to the event recording unit 120, and the event recording unit 120 records the transmitted information in step S330.

Steps S320 and S330 are repeatedly performed while the Android application 10 is operating.

The checkpoint detection unit 130 detects whether there is a checkpoint in the operation of the Android application 10 (S340). Specifically, in step S340, the checkpoint sensing unit 130 senses a checkpoint by sensing whether a new component is operating during the application operation.

If it is detected in operation S340 that the new component is activated, the checkpoint detection unit 130 deletes the shared variable information among the event information recorded by the event recording unit 120 in operation S350. For example, the checkpoint detecting unit 130 may control to delete the shared variable information among the event related information recorded by the event recording unit 120 through step S350.

Steps S340 and S350 are repeatedly performed during the operation of the Android application 10 as in steps S320 and S330.

At this time, the crash detection unit 140 detects whether a crash occurs during the operation of the Android application 10 (S360). At this time, if a crash occurs, the crash detection unit 140 transmits information on an exception condition to the event log 120 (S370). The event recorder 120 receiving the exception information through step S370 records the received exception information as event information.

Thereafter, the event recording unit 120 transmits the event-related information recorded until the time when the crash is detected to the log file generation unit 150 (S380). In step S390, the log file generation unit 150 generates a log file storing the event information transmitted in step S380.

The description of the steps S310 through S390 is the same as that described in detail with respect to the functions of the respective technical configurations of FIG. 1 and the event capture system 100, and will not be described below.

The event playing method according to the preferred embodiment of the present invention can play back event information using the log file information stored by the event capturing method according to the above method. Specifically, the event capturing method can reproduce an event using recently executed component and thread information included in the log file information.

Hereinafter, the detailed description is given above with reference to the event reproduction system, and the following description is omitted.

According to another embodiment of the present invention, a computer-readable program embodying the above-described event capture method or event playback method may be recorded.

The event capturing method or the event reproducing method according to the embodiment of the present invention may be implemented as a program to be executed in a computer and stored in a computer-readable recording medium. The computer-readable recording medium includes all kinds of storage devices in which data that can be read by a computer system is stored. Examples of the computer-readable recording medium include ROM, RAM, CD-ROM, magnetic tape, floppy disk, optical data storage, and the like.

Hereinafter, the simulation results performed to confirm the effectiveness of the event capturing method and the event reproducing method of the present invention will be described in detail.

In order to confirm the utility of the present invention, the performance overheads of other prior art applications and related studies were compared. To do this, we used KidsMusicLand, an unlisted Android app for 3,457 lines, 18 shows, and 21 classes. The used computer and application environment used Intel Core i3 3.10GHz, 4GB RAM, Windows 7, Eclipse Indigo, Android 4.03, JDK 1.5 and AspectJ 1.6.12.

The comparative analysis of the present invention and the related related studies are analyzed to analyze event information necessary for crash reproduction and a comparison table as shown in Table 1 below is obtained.

Figure 112014009941316-pat00001

In Table 1, the symbol √ indicates that the item is included, and the symbol X indicates that the item is not included. As can be seen from Table 1, the proposed method includes all the capture information used in the related related art studies and additionally includes GUI related events. SCARPE and ReCrash methods are not suitable for GUI-based Android applications because they can not deal with GUI events. JRapture and ReCrash methods are used to acquire information through object serialization, so all classes have to implement Serializable interface. Meanwhile, the event capturing method and the event reproducing method according to the present invention provide a function of capturing general system conditions including a GUI event by a method specific to Android.

To ensure that the system is properly detected and replayed, we have inserted an IndexOutOfBoundsException in the TransportSound activity of the example, an UllegalArgumentException in the AnimalSound activity, and a NullPointerException in the PlaySong activity. All inserted errors were correctly detected and reproduced while generating 2.45KB, 6.41KB, and 2.24 KB, respectively.

In order to check the efficiency of the probe code added for event capture, we compared the execution time of each probe before and after probe insertion. The Android application has difficulty to measure the execution time due to a lot of user input through the GUI, so it uses the preset input value using the Dalik Debug Monitor Server (DDMS) without depending on the user input. Table 2 below summarizes the pre-probe average execution time, the maximum execution time after the probe, and the maximum overhead for the eight activities performed in the detection and playback scenarios of the three errors inserted in the previous example. The maximum overheads of KidsMusicLand and MakeSong are slightly higher at 56.8% and 44.5%, while the remaining activities are not as high overall. In general, the maximum overhead is worst case and the average value is much lower.

Figure 112014009941316-pat00002

Table 3 below shows the result of comparing the execution time average overhead with the Java-based capture and playback technique and the event capturing and playback method according to the present invention. The average overhead values of the JRapture, SCARPE, and ReCrash methods shown in Table 3 are the same as those of the overhead provided in the related art, and the overhead values according to the present invention are applied to various execution scenarios The overhead value generated by each activity was averaged to obtain the interval value of 4 ~ 11%. That is, the maximum value of the execution time overhead is described in Table 2, and the average of the execution time overhead by activity is shown as the interval value in Table 3 below.

Figure 112014009941316-pat00003

This interval value is significantly smaller than the SCARPE and ReCrash methods and is relatively larger than jRapture. However, in the case of jRapture, the API of Java is modified and applied. Therefore, the execution time average overhead is small, but fundamentally, serialization of all classes requires modification of the source code.

The present invention has been described with reference to the preferred embodiments. It will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention as defined by the appended claims. Therefore, the disclosed embodiments should be considered in an illustrative rather than a restrictive sense. The scope of the present invention is defined by the appended claims rather than by the foregoing description, and all differences within the scope of equivalents thereof should be construed as being included in the present invention.

10: Android Applications
11: Activity
12: Service
13: Content Provider
14: Broadcast Receiver
100: Event capture system
110: Data collecting unit
120: Event log
130: Checkpoint detection unit
140: Crash detection unit
150: Log file generation unit

Claims (14)

A data collecting unit for collecting information on a component to be executed, thread information and shard variable information output by the thread in a specific application operation;
An event recording unit for recording event information collected by the data collection unit;
A checkpoint detecting unit for deleting shared variable information among event information recorded by the event recording unit when an operation of a new component is detected during the application operation;
A crash detection unit for detecting whether a crash occurs during the application operation; And
And a log file generation unit for generating a log file storing event information recorded by the event recording unit when a crash is detected by the crash detection unit.
The method according to claim 1,
Wherein the data collecting unit comprises:
And an event-oriented programming technique is applied to collect event related information.
The method according to claim 1,
The checkpoint sensing unit may include:
And detects whether an activity component that manages screen UI information during operation of an Android-based application is operating.
The method of claim 3,
The checkpoint sensing unit may include:
And deletes the shared variable information among the event information recorded by the event recording unit when the operation of the previous activity is completed and a new activity is performed.
7. An event reproducing system for reproducing a log file generated by an event capturing system according to any one of claims 1 to 4,
And an event reproducing unit for reproducing an event using the recently executed component and thread information.
6. The method of claim 5,
Wherein,
And a shared variable value stored in the log file is compared with a shared variable value output by the executed thread information,
When the output value of the shared variable is different from the value of the shared variable stored in the log file, execution of the current thread information is stopped and the other thread information is executed to compare the output value of the shared variable with the value of the shared variable stored in the log file Features an event playback system.
A data collecting step of collecting information on a component to be executed, thread information and shard variable information output by the thread in a specific application operation;
An event recording step of recording event information collected through the data collection step;
A checkpoint sensing step of sensing whether a new component is operating during the application operation;
A common variable initialization step of deleting the shared variable information among the information collected through the data collection step when it is detected that the new component is operated through the checkpoint sensing step;
A crash detection step of detecting whether a crash occurs during the application operation; And
And a log file storing step of storing information collected through the data collecting step and the shared variable initializing step as a log file when a crash is detected by the crash detecting step.
8. The method of claim 7,
In the data collection step,
And an aspect-oriented programming technique is applied to collect relevant information.
8. The method of claim 7,
In the checkpoint sensing step,
And detecting an operation of an activity component that manages screen UI information during an Android-based application operation.
10. The method of claim 9,
In the checkpoint sensing step,
Detecting whether the previous activity is completed and a new activity is to be performed,
In the shared variable initialization step,
Wherein the shared variable information is deleted from the information collected through the data collection step when it is detected that the new activity is activated through the checkpoint detection step.
An event reproducing method for reproducing a log file stored by an event capturing method according to any one of claims 7 to 10,
And an event reproducing step of reproducing the event using the recently executed component and thread information.
12. The method of claim 11,
In the event reproducing step,
And a shared variable value stored in the log file is compared with a shared variable value output by the executed thread information,
When the output value of the shared variable is different from the value of the shared variable stored in the log file, execution of the current thread information is stopped and the other thread information is executed to compare the output value of the shared variable with the value of the shared variable stored in the log file A feature to play an event.
A computer-readable recording medium,
A recording medium on which a computer-executable program is recorded, which implements the event capturing method according to any one of claims 7 to 10.
A computer-readable recording medium,
12. A recording medium on which a computer-executable program is recorded, which implements the event reproducing method according to claim 11.
KR1020140011564A 2014-01-29 2014-01-29 Method and System for capturing events, method and system for replaying the recorded events KR101526108B1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
KR1020140011564A KR101526108B1 (en) 2014-01-29 2014-01-29 Method and System for capturing events, method and system for replaying the recorded events

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020140011564A KR101526108B1 (en) 2014-01-29 2014-01-29 Method and System for capturing events, method and system for replaying the recorded events

Publications (1)

Publication Number Publication Date
KR101526108B1 true KR101526108B1 (en) 2015-06-04

Family

ID=53499624

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020140011564A KR101526108B1 (en) 2014-01-29 2014-01-29 Method and System for capturing events, method and system for replaying the recorded events

Country Status (1)

Country Link
KR (1) KR101526108B1 (en)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20080109361A (en) * 2007-06-13 2008-12-17 (주)아이비즈소프트웨어 Framework
KR20120097141A (en) * 2011-02-24 2012-09-03 한양대학교 산학협력단 Apparatus and method for recording and replaying event at occurred points for record and replay of the program
KR101346835B1 (en) * 2011-12-15 2014-01-06 이지케어텍(주) Method and appratus for processing error of application

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20080109361A (en) * 2007-06-13 2008-12-17 (주)아이비즈소프트웨어 Framework
KR20120097141A (en) * 2011-02-24 2012-09-03 한양대학교 산학협력단 Apparatus and method for recording and replaying event at occurred points for record and replay of the program
KR101346835B1 (en) * 2011-12-15 2014-01-06 이지케어텍(주) Method and appratus for processing error of application

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
'XML을 이용한 안드로이드 GUI 위젯의 기능 테스트 자동화', 정보처리학회논문지D 제19-D권 제2호(2012. 4) *

Similar Documents

Publication Publication Date Title
CN111756575B (en) Performance analysis method and device of storage server and electronic equipment
US20120131456A1 (en) Capture and Playback for GUI-Based Tasks
US9229738B2 (en) Software development tool for providing user context information to improve message quality at development time
US9176840B2 (en) Tool for analyzing and resolving errors in a process server
CN107391333B (en) OSD disk fault testing method and system
CN102479084A (en) Method and device for acquiring log by Android terminal
US20150006961A1 (en) Capturing trace information using annotated trace output
US8756569B2 (en) Deterministic pseudo-random fault event recordation and injection tool
US20100180245A1 (en) Methods and products for determining and visualizin ic behavior
KR101541970B1 (en) Test scenario generating device, allication testing system comprising the same, test scenario generating method, and recordable meduim thereof
CN111191248B (en) Vulnerability detection system and method for Android vehicle-mounted terminal system
CN102541731B (en) Platform-agnostic diagnostic data collection and display
Moran et al. On-device bug reporting for android applications
WO2018068639A1 (en) Data recovery method and apparatus, and storage medium
CN109669858B (en) Program deadlock test method, device and equipment
CN110597704B (en) Pressure test method, device, server and medium for application program
KR101976629B1 (en) Commit sensitive tests
CN106980572B (en) Online debugging method and system for distributed system
CN105718353A (en) Testing method, apparatus and system for graphic interface application
CN109542341B (en) Read-write IO monitoring method, device, terminal and computer readable storage medium
US20140095938A1 (en) Latent defect identification
CN106649000A (en) Fault recovery method for real-time processing engine, and corresponding server
CN116820610A (en) Method and device for dynamically tracking user state program in observable field
US8997048B1 (en) Method and apparatus for profiling a virtual machine
KR101526108B1 (en) Method and System for capturing events, method and system for replaying the recorded events

Legal Events

Date Code Title Description
E701 Decision to grant or registration of patent right
GRNT Written decision to grant
FPAY Annual fee payment

Payment date: 20190429

Year of fee payment: 5