KR102096085B1 - Apparatus and method for monitoring application - Google Patents

Abstract

App test device and method are presented, and the app test device receives test-related information from a communication unit communicating with a terminal for app testing, and a terminal under app testing, and filters the received information with preset driving conditions to drive the app. It includes a control unit that provides a situation, and the control unit filters at least one condition of an execution state indicating an activity history according to the execution of the app, an operating system version of the terminal, a terminal type of the terminal, and information about a connection area of the terminal. Set as the driving condition for.

Description

App monitoring device and method {APPARATUS AND METHOD FOR MONITORING APPLICATION}

Embodiments disclosed in the present specification relate to an app test device and method, and more particularly, to an app test device and method capable of confirming a driving state of an app before a fatal problem such as an app crash occurs.

Recently, IT technology has rapidly developed and various types of hardware modules are mounted in one electronic terminal. In particular, as the digital convergence phenomenon in which a new service or product is born by accelerating the convergence of various digital-based products or services has been accelerated, various operating systems capable of operating each of these electronic terminals have also been released.

In this situation, software developers have a greater degree of freedom to develop numerous applications to utilize the hardware resources included in these electronic terminals, and at the same time, they are under pressure to develop and test applications that run smoothly on various hardware and platforms. Became.

Referring to the related art publication No. 10-2014-0052200, if a crash occurs when the application is executed in the test terminal, the crash occurrence information including the operation scenario and crash content up to the occurrence of the crash is verified and managed. It describes a system for application verification to be transferred to. In this way, in a system for testing an application as in the prior art literature, a crash cannot occur to check information related to a crash, so it is possible to check information on a usage state before a crash occurs, thereby failing to check defects caused by application execution. There was.

On the other hand, in order to test the application prior to launching the application, there is a limitation in testing the application before the application is released because all user terminals to run the application are purchased and tested, or it takes a lot of time to test. Due to this, the application is tested while the application is released, but the defect of the application before the crash occurs causes inconvenience to the user, causing the user to exit.

Therefore, a technique for solving the above-described problems is needed.

On the other hand, the above-mentioned background technology is the technical information acquired by the inventor for the derivation of the present invention or acquired in the derivation process of the present invention, and is not necessarily a known technology disclosed to the general public before filing the present invention. .

The embodiments disclosed in the present specification have an object to provide an app test apparatus and method capable of confirming a defect by checking a driving state of an app before a crash occurs.

The embodiments disclosed herein are intended to provide an apparatus and method for testing an app capable of preventing a user from leaving due to a defect before a crash occurs.

As a technical means for achieving the above-described technical problem, according to an embodiment, a communication unit communicating with a terminal for testing an app, and receiving test-related information from a terminal under test for an app, and driving conditions for receiving the received information in advance And a control unit that provides a driving status of the app by filtering with the control unit, wherein the control unit includes an execution state indicating an activity history according to the execution of the app, an operating system version of the terminal, a terminal type of the terminal, and a connection area of the terminal. At least one condition among information on is set as the driving condition for the filtering.

According to another embodiment, in the app test method performed by the app test device, the method comprising: checking information of a terminal for testing an app, setting driving conditions for the testing of the app, and test-related information from the terminal Receiving, filtering the received information with the driving conditions to provide a driving status of the app, and setting the driving conditions includes: an execution state indicating an activity history according to the execution of the app; And setting at least one condition of the operating system version of the terminal, the terminal type of the terminal, and information on the access area of the terminal as the driving condition for the filtering.

According to any one of the above-described problem solving means, it is possible to present an app test apparatus and method capable of confirming a defect by checking the driving state of the app before a crash occurs.

In addition, according to any one of the above-described problem solving means, it is possible to present an apparatus and method for testing an app that can prevent a user from leaving due to a defect before a crash occurs.

Effects obtained in the disclosed embodiments are not limited to the above-mentioned effects, and other effects not mentioned are apparent to those skilled in the art to which the embodiments disclosed from the following description belong. It can be understood.

1 is a configuration diagram illustrating an app test system according to an embodiment.
2 is a block diagram illustrating an app test device according to an embodiment.
3 is a block diagram illustrating a control unit of an app test device according to an embodiment.
4 is a diagram illustrating a screen displaying driving conditions for filtering in an app test device according to an embodiment.
5 is a diagram illustrating detailed items corresponding to a driving situation in an app test device according to an embodiment.
6 is a diagram illustrating an app test operation in an app test device according to an embodiment.

Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings so that those skilled in the art to which the present invention pertains can easily practice. However, the present invention can be implemented in many different forms and is not limited to the embodiments described herein. In addition, in order to clearly describe the present invention in the drawings, parts irrelevant to the description are omitted, and like reference numerals are assigned to similar parts throughout the specification.

Throughout the specification, when a configuration is said to be "connected" to another configuration, this includes not only a case of 'directly connecting', but also a case of 'connecting another configuration in between'. In addition, when a configuration is said to "include" a configuration, this means that unless otherwise stated, other configurations may be excluded and other configurations may be further included.

Hereinafter, exemplary embodiments will be described in detail with reference to the accompanying drawings.

Before explaining this, however, the meanings of terms used below are defined first.

Here, the 'application' is a program for running on an electronic terminal or terminal to be described later to achieve a predetermined purpose, and is also referred to as an application program. These applications may be used interchangeably with the same meaning as 'app' below.

The 'drive condition' is a condition for confirming information about a driving environment in which the app is tested, and an execution state indicating an activity history according to the execution of the app, an operating system version of the terminal, a terminal type of the terminal, and information about a connection area of the terminal. It may include at least one of. Here, the driving conditions are exemplarily described, and if necessary, may further include hardware and software resources of the terminal for app testing or information about the environment around the terminal.

The 'drive situation' is information obtained by filtering information collected from the terminal according to driving conditions, and means an app test result. The driving situation may indicate an application usage state of the terminal or resource usage of the terminal according to the test of the app, and may be divided into detailed items. The detailed items may include, for example, at least one of an application usage flow, user interface (UI) rendering time, central processing unit usage, memory usage, network response time, and crash.

1 is a configuration diagram illustrating an app test system according to an embodiment.

As shown in FIG. 1, the app test system 10 may include terminals 110 and 120 and an app test device 200. The app test device 200 may communicate with the terminals 110 and 120 through the network N.

The terminals 110 and 120 are devices on which the app is executed, and may be regarded as a test terminal by running the app on the terminals 110 and 120 and testing the executed app. Here, the test terminal means a terminal selected for testing of the app to proceed or testing of the app.

The terminals 110 and 120 may provide various information necessary for testing the app to the app test device 200. For example, the terminals 110 and 120 may provide unique information (manufacturer, model name) of the terminal for testing the app to the app testing device 200. In addition, the terminals 110 and 120 may provide various information that can be generated or changed by the execution of the app to the app test device, and are generated according to changes in the state of the terminals 110 and 120 due to user movement. Information (for example, location information) may be provided to the app test device 200.

The terminals 110 and 120 may be implemented as a computer, a portable terminal, or a television that can connect to a remote server through a network N or connect to other terminals and servers. Here, the computer includes, for example, a laptop equipped with a web browser (WEB Browser), a desktop (desktop), a laptop (laptop), and the like, and the portable terminal is, for example, a wireless communication device that guarantees portability and mobility. , PCS (Personal Communication System), PDC (Personal Digital Cellular), PHS (Personal Handyphone System), PDA (Personal Digital Assistant), GSM (Global System for Mobile communications), IMT (International Mobile Telecommunication) -2000, CDMA (Code All kinds of handhelds such as Division Multiple Access (2000), W-Code Division Multiple Access (W-CDMA), Wireless Broadband Internet (Wibro), Smart Phone, Mobile Worldwide Interoperability for Microwave Access (WiMAX), etc. (Handheld) -based wireless communication device. In addition, the television may include Internet Protocol Television (IPTV), Internet Television (TV), terrestrial TV, and cable TV.

The app test device 200 may run the app to be tested on the terminals 110 and 120 and check the execution result. In addition, the app test device 200 may control the app installation operation of the terminals 110 and 120 to execute the app on the terminals 110 and 120. The app test apparatus 200 may be implemented through various electronic terminals including a personal computer (PC) as well as a portable terminal, and may be implemented as the same devices as the terminals 110 and 120 described above.

For example, a program for performing an app test may be installed in the app test device 200. In addition, the app test device 200 provides a user interface screen for communicating with a server (not shown) in which a program for performing app testing is installed, receiving input related to app testing, and displaying app test results You may. In the app installed on the terminals 110 and 120, a module for testing an app may be inserted in the form of a software development kit (hereinafter referred to as 'SDK'). The program for performing the app test can test the app in which the SDK is inserted.

The app test device 200 may receive information required for testing the app from the terminals 110 and 120 on which the app is executed. The app test device 200 may filter the information collected from the terminals 110 and 120 based on the driving conditions, and provide information about the driving situation as a filtered result. Here, the driving condition may be set by the user through the app test device 200.

In relation to this, the app test device 200 will be described later in more detail with reference to FIG. 2.

2 is a block diagram illustrating an app test device according to an embodiment.

2, the app test device 200 may include an input / output unit 210, a communication unit 220, a storage unit 230, and a control unit 240.

The input / output unit 210 may include an input unit for receiving input from a user, and an output unit for displaying information such as a result of performing a task or a state of the app test device 200. For example, the input / output unit 210 may include an operation panel for receiving user input, a display panel for displaying the screen, and the like.

Specifically, the input unit may include devices capable of receiving various types of user input, such as a keyboard, a physical button, a touch screen, a camera, or a microphone. Also, the output unit may include a display panel or a speaker. However, the present invention is not limited thereto, and the input / output unit 210 may include a configuration supporting various input / output.

Meanwhile, the communication unit 220 may perform wired / wireless communication with another device or network N. To this end, the communication unit 220 may include a communication module supporting at least one of various wired and wireless communication methods. For example, the communication module may be implemented in the form of a chipset.

The wireless communication supported by the communication unit 220 may be, for example, Wi-Fi (Wireless Fidelity), Wi-Fi Direct, Bluetooth (Bluetooth), UWB (Ultra Wide Band), or NFC (Near Field Communication). In addition, the wired communication supported by the communication unit 220 may be, for example, USB or HDMI (High Definition Multimedia Interface). The above-described communication is only an example, and various communication techniques enabling the app test device 200 to perform communication are possible.

Meanwhile, various types of data, such as files, applications, and programs, may be installed and stored in the storage unit 230. As an example of data, information for testing an app may be included, or information collected from terminals 110 and 120 for testing an app.

Data stored in the storage unit 230 may be accessed and used by the control unit 240 to be described later, or new data may be stored by the control unit 240. Also, the storage unit 230 may store a program that can be executed by the control unit 240.

The storage unit 230 may store information generated by the app test operation or information on the app test result by the control unit 240.

On the other hand, the control unit 240 controls the overall operation of the app test device 200, and may include a processor such as a CPU. The control unit 240 may control other components included in the app test device 200 to perform an operation corresponding to a user input received through the input / output unit 210.

For example, the control unit 240 may read data stored in the storage unit 230 or may store new data in the storage unit 230.

According to an embodiment, the control unit 240 may receive information related to the app test from the terminals 110 and 120 through the communication unit 220. The controller 240 may set driving conditions based on the information input through the input / output unit 210 to filter the received information.

The controller 240 may filter test-related information in the terminals 110 and 120 based on the driving conditions. The control unit 240 may indicate the driving status of the app by filtering the information from the terminals 110 and 120. The controller 240 may be provided by filtering a driving situation, which is information that can check a situation related to the app, according to a set driving condition even when a crash is not currently occurring. Here, a crash refers to an error that occurs when a normal shutdown operation is not performed due to power loss, system error, or application error.

Meanwhile, the control unit 240 will be described later in more detail with reference to FIG. 3.

Through this, the app test device 200 may perform a filtering operation to provide the user with information capable of identifying a defect that may occur in the app regardless of whether a crash occurs during the app test. As described above, the app test device 200 can solve the problem by providing the information on the defect (eg, excessive use of resources or deterioration of the app performance) caused by the app test before the crash occurs. So that it can prevent the user from leaving due to the defect of the app.

Moreover, the app test device 200 targets a defect that may occur when the app is executed before a crash occurs to correct the source code or a situation where the modification of the source code is unnecessary (for example, the access area of the app is located in a different area, CPU usage or memory usage exceeded due to a low-end terminal) can be determined. For this reason, the app test device 200 may prevent unnecessary modification of the source code by allowing the app manager to determine whether the source code needs to be modified when an issue occurs in the app.

3 is a block diagram illustrating a control unit of an app test device according to an embodiment.

3, the control unit 240 may include a test terminal management unit 241, a filter unit 242, and a test information processing unit 243.

According to an embodiment, the test terminal management unit 241 may communicate with the terminals 110 and 120 through the communication unit 220 and manage information of the terminals 110 and 120. The test terminal management unit 241 may manage information on hardware resources and software resources of the terminals 110 and 120. For example, the test terminal management unit 241 provides information about hardware resources such as the manufacturer, model name (or product name), and specifications (performance of CPU, memory, camera, display, and battery) of the terminals 110 and 120. You can manage or manage information about the operating system or operating system version.

The test terminal management unit 241 may collect information of the terminals 110 and 120 by storing information of the terminals 110 and 120 in the storage unit 230 or communicating with a manufacturer server of the terminals 110 and 120. In this case, the test terminal management unit 241 may receive the product names of the terminals 110 and 120 to obtain detailed information related to the terminal, that is, hardware resources and software resources.

The test terminal management unit 241 may be provided with information related to an app running on the terminals 110 and 120. In addition, the test terminal management unit 241 may receive various information related to the use of the app from the terminals 110 and 120. For example, the test terminal management unit 241 may receive execution state information as information related to a user's activity history according to the execution of the app. Here, the execution state means each state in which the app is executed according to user input. There may be an execution screen displayed on the terminal corresponding to each execution state. For example, the execution state may correspond to an activity in an Android operating system or an iOS view in an iOS.

According to an embodiment, the filter unit 242 may be configured to receive a driving condition from a user or set a driving condition in advance. The filter unit 242 may filter the information received from the terminals 110 and 120 under the set driving condition. For example, the filter unit 242 may include at least one of an execution state, an operating system version, a terminal type, and a condition for an access region as a driving condition for filtering.

First, the filter unit 242 may set an execution state indicating an activity history according to the execution of the app as a driving condition. Thereafter, the filter unit 242 may set the operating system version as the driving condition, and then set the terminal type as the driving condition. Finally, the filter unit 242 may set the connection area as a driving condition. As described above, the filter unit 242 may set an execution state, an operating system version, a terminal type, and a connection area as driving conditions, and when two or more driving conditions are used when setting the driving conditions, an AND operation may be used. Therefore, the filter unit 242 may perform filtering by performing AND operations on the execution state, operating system version, terminal type, and access area in order.

When setting the driving conditions, the filter unit 242 may output the frequency and risk (for example, a defect or a crash) in which a specific driving situation occurs for each driving condition using the input / output unit 210. Also, the filter unit 242 may output the filtered driving status to the test information processing unit 243.

According to an embodiment, the test information processing unit 243 may output the filtered driving situation by sorting or diagramming it. To this end, the test information processing unit 243 may output information using various methods such as a table, chart, and graph.

The test information processing unit 243 may output information about a driving situation, which is information filtered according to driving conditions, using the input / output unit 110. Through this, the test information processing unit 243 may provide the user with information to check for defects that may occur in the driving situation for testing the app.

The test information processing unit 243 may provide information on detailed items of the driving situation. Here, the detailed items include at least one of an application usage flow, user interface rendering time, central processing unit usage, memory usage, network response time, and crash. The test information processing unit 243 may display detailed items based on a specific period, a predetermined time, or a date set by the user when providing information about the detailed items.

The driving conditions or driving conditions used in the app test device 200 are illustratively described to describe the app testing operation, and various information other than the above-described information may be set as driving conditions or output as driving conditions. .

4 is a diagram illustrating a screen displaying driving conditions for filtering in an app test device according to an embodiment.

4, a driving condition 310 for filtering in the app test device 200 is illustrated.

The app test device 200 may include at least one of an execution state 311, an operating system version 312, a terminal type 313, and a connection area 314 as a driving condition 310. At this time, the user can set the driving condition by selecting the execution state 311, the operating system version 312, the terminal type 313, and the access area 314 through the app test device 200. When setting the driving conditions, the app test device 200 can end-operate the execution state 311, the operating system version 312, the terminal type 313, and the access area 314, one by one for the AND operation You can also choose.

However, various combinations of the driving conditions 310 for the execution state 311, the operating system version 312, the terminal type 313, and the access area 314 may be preset and stored in the app test device 200. have. At this time, the app test device 200 may set the driving conditions for filtering with only one selection for one combination, without having to individually set the preset conditions.

According to one embodiment, the execution state 311 is shown from A1 to A10. For example, in the execution state 311, A1 is the main execution state, A2 is the milllist execution state, A3 is the gallery execution state, A4 is the shared execution state, A5 is the management execution state, A6 is the help execution state, A7 is logged in The execution state, A8 may indicate a learning (tutorial) execution state, A9 a slideshow execution state, A10 a recommended execution state, and the like.

According to an embodiment, the operating system version 312 may refer to a version of an operating system used in a terminal, such as Android or iOS. For example, the operating system version 312 may assume an Android operating system, V1 is version 7.0, V2 is version 6.0.1, V3 is version 4.1.1, V4 is version 5.0, V5 is version 4.0.4, V6 Indicates version 4.3 and V7 can indicate version 4.4.2.

According to an embodiment, the terminal type 313 may indicate the type of terminal, and may include a device name or a model name of the device. For example, D1 may be G1 product of S company, D2 is H2 product of L company, D3 is I1 product of A company, D5 may be G2 product of S company, D6 may be H4 product of L company, D7 may be G4 product of S company.

According to an embodiment, the access area 314 may indicate a location accessed by the terminal or a current location of the terminal. For example, the location L1 may be Korea (KR).

Here, a circle corresponding to each execution state 311 indicates a ratio of test terminals that have executed the execution state 311 among all test terminals filtered by driving conditions. In addition, the color in the circle corresponding to each execution state 311 may represent the risk 320, and may be represented by danger (black), warning (gray), stability (white), and the like.

In the driving condition 310, the execution ratio and the degree of risk are illustrated based on the execution state 311 (330). At this time, the execution state 311 may be illustrated in a tree structure according to the use of the app, and the execution rate and risk of each execution state may be checked based on the main execution state (A1) representing the main screen of the app.

Further, in the case of a shared execution state such as A4, for example, A41 is divided into a Facebook shared execution state, and A42 is divided into an Instagram shared execution state, etc., and has a tree structure indicating a sub-execution state of each execution state. In addition, execution rates and risks can be checked for the lower execution states.

5 is a diagram illustrating detailed items corresponding to a driving situation in an app test device according to an embodiment.

As illustrated in FIG. 5, the app test device 200 may show each detailed item about the driving situation.

For example, the app test device 200 may be used as a detailed item of the app's usage flow 410, an app's user interface (UI) rendering time 420, CPU usage 430, and memory usage 440. And the like.

Looking at the usage flow 410 of the app, the app test device 200 is the main execution state 412, the server detail execution state 413, the URL detail execution state 414, the gallery among the entire usage state 411 of the app. The execution state 415, the login execution state 416, and the crash execution state 417 can be used.

Looking at the UI rendering time 420, the vertical axis represents the time (ms (milliseconds)) required for UI rendering, and the horizontal axis represents the date. Through the color of the display object displayed on the graph, it is possible to indicate the frequency of the driving situation corresponding to the display object.

Looking at the CPU usage 430, the vertical axis represents the CPU usage ratio (percentage (%)), and the horizontal axis represents the date. In addition, when looking at the memory usage 440, the vertical axis represents the memory usage capacity (megabytes (MB)), and the horizontal axis represents the date. In the CPU usage 430 and the memory usage 440, the frequency of a driving situation corresponding to the corresponding display object may be indicated through the color of the display object displayed on the graph.

Through this, the app test device 200 may provide information about the current driving state of the app so that when a defect generated during the test of the app is checked, an action for solving the defect of the app can be performed.

Meanwhile, the above-described date is an example of a period in which test data is collected, and may be variously set to minutes, hours, months, quarters, and the like.

Meanwhile, although not illustrated in FIG. 5, the app test device 200 may additionally provide network response time and crash information as detailed items.

6 is a diagram illustrating an app test operation in an app test device according to an embodiment.

As shown in FIG. 6, the app test device 200 checks terminal information for the app test (S511). The app test device 200 may check information related to the terminal, and in particular, information on an operating system version or terminal type used in the terminal. The app test device 200 may be used when filtering an operating system version and a terminal type according to a setting of driving conditions.

The app test device 200 may set driving conditions for filtering (S513). The app test device 200 may set driving conditions by an AND operation on the execution state, operating system version, terminal type, and access area. At this time, the app test device 200 may provide information on the execution rate and risk according to driving conditions.

The app test device 200 performs filtering according to the set driving condition (S515). The app test device 200 receives test-related information from the terminal under app testing, and filters the received information based on driving conditions.

The app test device 200 checks whether a detailed item of a driving item that is a filtering result is selected (S517). Through this, the app test device 200 may check information on a desired detailed item from among information on the filtered driving item. As a result of the check in step S517, when a detailed item is selected, the process proceeds to step S519. As a result of the check in step S517, if a detailed item is not selected, since it is requested to provide all information about the driving item, the app test device 200 proceeds to step S521.

The app test device 200 may provide information on the selected detailed item (S519). The app test device 200 may provide only the information desired by the user who performs the app test through the selection operation of the detailed item instead of providing all the information on the driving situation.

The app test device 200 may provide a driving situation of an app that is a filtering result (S521). For example, the app test device 200 may provide all information on all the detailed items of the driving situation. In addition, the app test device 200 may extract and provide only the information about the defects generated during the app test in the driving condition.

The app test device 200 determines whether to end the app test (S523). As a result of the determination in step S523, when the app test is finished, the process proceeds to step S525. If the app test device 200 does not end the app test, the process proceeds to step S513.

The app test device 200 determines whether to store the app test result (S525). When the verification result of step 525 and the app test result are stored, the app test device 200 proceeds to step S527. If the app test device 200 does not store the app test result, the app test device 200 ends.

The app test device 200 stores the app test result and ends (S527). The app test device 200 may match and store information corresponding to a driving condition for filtering or a driving situation that is a filtering result. In addition, the app test device 200 may receive a user input for modifying the source code of the app for a defect that is expected to be generated or crashed from a driving situation.

As described above, the app test device 200 stores a combination of driving conditions set for filtering (for example, a main execution state, Android 7.0 version, S company G series terminal, Korea, etc.), and information about the filtering group, By storing the driving conditions corresponding to the combination of driving conditions together, defects in the app test can be found.

When the app is abnormally terminated, the app test device 200 may check for defects by considering the cause analysis together with the resource situation in the mobile platform rather than the app itself, thereby improving the accuracy of the app test. Moreover, the app test device 200 may use the data collected for testing the app anytime, anywhere, regardless of the market or region where the app is distributed.

The term '~ unit' used in the above embodiments means software or hardware components such as a field programmable gate array (FPGA) or ASIC, and '~ unit' performs certain roles. However, '~ wealth' is not limited to software or hardware. The '~ unit' may be configured to be in an addressable storage medium or may be configured to reproduce one or more processors. Thus, as an example, '~ unit' refers to components such as software components, object-oriented software components, class components and task components, processes, functions, attributes, and procedures. , Subroutines, segments of program patent code, drivers, firmware, microcode, circuitry, data, database, data structures, tables, arrays, and variables.

The functionality provided within components and '~ units' may be combined into a smaller number of components and '~ units', or separated from additional components and '~ units'.

In addition, the components and '~ unit' may be implemented to play one or more CPUs in the device or secure multimedia card.

The app test method according to the embodiment described with reference to FIG. 6 may also be implemented in the form of a computer-readable medium that stores instructions and data executable by a computer. At this time, instructions and data may be stored in the form of program code, and when executed by a processor, a predetermined program module may be generated to perform a predetermined operation. Also, the computer-readable medium can be any available medium that can be accessed by a computer, and includes both volatile and nonvolatile media, removable and non-removable media. In addition, the computer-readable medium may be a computer recording medium, which is volatile and non-volatile implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Volatile, removable and non-removable media. For example, the computer recording medium may be a magnetic storage medium such as HDD and SSD, an optical recording medium such as CD, DVD and Blu-ray disk, or a memory included in a server accessible through a network.

In addition, the app test method according to the embodiment described with reference to FIG. 6 may be implemented as a computer program (or computer program product) including instructions executable by a computer. The computer program includes programmable machine instructions processed by a processor and may be implemented in a high-level programming language, object-oriented programming language, assembly language, or machine language. . In addition, the computer program may be recorded on a tangible computer-readable recording medium (eg, memory, hard disk, magnetic / optical medium, or solid-state drive (SSD), etc.).

Therefore, the app test method according to the embodiment described with reference to FIG. 6 may be implemented by executing the computer program as described above by the computing device. The computing device may include at least a portion of a processor, a memory, a storage device, a high-speed interface connected to the memory and a high-speed expansion port, and a low-speed interface connected to the low-speed bus and the storage device. Each of these components is connected to each other using various buses, and may be mounted on a common motherboard or mounted in other suitable ways.

Here, the processor is capable of processing instructions within the computing device, such as for displaying graphical information for providing a graphical user interface (GUI) on an external input or output device, such as a display connected to a high-speed interface. Examples include instructions stored in memory or storage devices. In other embodiments, multiple processors and / or multiple buses may be used with multiple memories and memory types as appropriate. In addition, the processor may be implemented as a chipset formed by chips including a plurality of independent analog and / or digital processors.

Memory also stores information within computing devices. In one example, the memory may be comprised of volatile memory units or a collection thereof. As another example, the memory may be composed of non-volatile memory units or a collection thereof. The memory may also be other types of computer readable media, such as magnetic or optical disks.

And the storage device can provide a large storage space for the computing device. The storage device may be a computer readable medium or a configuration including such a medium, and may include, for example, devices within a storage area network (SAN) or other configurations, and may include floppy disk devices, hard disk devices, optical disk devices, Or a tape device, flash memory, or other similar semiconductor memory device or device array.

The above-described embodiments are for illustration only, and those skilled in the art to which the above-described embodiments belong can easily be modified into other specific forms without changing the technical idea or essential characteristics of the above-described embodiments. You will understand. Therefore, it should be understood that the above-described embodiments are illustrative in all respects and not restrictive. For example, each component described as a single type may be implemented in a distributed manner, and similarly, components described as distributed may be implemented in a combined form.

The scope to be protected through the present specification is indicated by the claims, which will be described later, rather than the detailed description, and should be interpreted to include all modified or modified forms derived from the meaning and scope of the claims and their equivalent concepts. .

10: App test system 110, 120: test terminals
200: App test device 210: input and output unit
220: communication unit 230: storage unit
240: control unit 241: test terminal management unit
242: filter unit 243: test information processing unit

Claims (11)

Communication unit for communicating with the terminal for the app test; And
It includes a control unit for receiving test-related information from the terminal under test of the app, and filtering the received information to a preset driving condition to provide a driving state of the app,
The control unit,
An app test device that sets the driving condition for the filtering by combining the execution state, the operating system version of the terminal, the terminal type of the terminal, and the conditions for the access area of the terminal, showing activity details according to the execution of the app . delete According to claim 1,
The control unit,
The combination is performed by AND operation,
App testing device for filtering by performing an AND operation on the execution state, the operating system version, the terminal type and the access area in turn. According to claim 1,
The control unit,
App test device that provides the frequency and risk of each numerical value of the driving situation for the driving conditions. According to claim 1,
The control unit,
The driving situation includes information on detailed items,
The detailed item is an app test device including at least one of an application flow, user interface (UI) rendering time, central processing unit usage, memory usage, network response time, and crash. The method of claim 5,
The control unit,
App testing device that sorts the details based on the date the app is being tested. In the app test method performed by the app test device,
Checking the information of the terminal for testing the app;
Setting driving conditions for the app test; And
And receiving test-related information from the terminal and filtering the received information with the driving conditions to provide a driving status of the app,
The step of setting the driving conditions,
And setting the driving condition for the filtering by combining the execution state indicating the activity details according to the execution of the app, the operating system version of the terminal, the terminal type of the terminal, and the conditions for the access area of the terminal. How to test your app. The method of claim 7,
The step of setting the driving conditions,
The combination of performing the AND operation, and performing the AND operation on the execution state, the operating system version, the terminal type, and the access area in order to filter the app. The method of claim 7,
The step of providing the driving situation of the app,
Providing at least one of the usage flow, user interface (UI) rendering time, central processing unit usage, memory usage, network response time, and crash of the detailed items corresponding to the driving situation. The method of claim 9,
The step of providing the driving situation of the app,
Receiving at least some of the detailed items corresponding to the driving situation; And
And providing information on the selected detail item. The method of claim 10,
And matching and storing the information about the driving condition and the driving condition for testing the app.

Images