Interface update crash risk detection method, device, electronic device and storage medium

Abstract

The present application discloses a method, apparatus, device and computer-readable storage medium for detecting the risk of interface update crash, the method comprising: obtaining a code of a project to be tested, and performing an interface update function detection on the code of the project to be tested to obtain a target interface update function; based on the target interface update function, generating function call relationship information corresponding to the code of the project to be tested; taking each target interface update function as a first end function, constructing multiple function chains using the function call relationship information, and identifying the second end function corresponding to each function chain; if any second end function is a non-main thread function, determining that the target function chain to which the non-main thread function belongs has an interface update crash risk; the method adopts a static testing method, can accurately and comprehensively identify the UI update crash existing in the code of the project to be tested, can cover all detection scenarios, and has a good detection effect; and does not require random detection, so the detection time is short and the detection efficiency is high.

Description

Technical Field

[0001] The present application relates to the field of software testing technology, and in particular to an interface update crash risk detection method, an interface update crash risk detection device, an electronic device, and a computer-readable storage medium. Background Art

[0002] Interface update crash can also be called UI (User Interface) update crash (i.e. crash), which is a software error caused by a child thread updating the UI. Whether the thread that updates the UI is the main thread often changes as the program runs, and there is a high degree of uncertainty. In order to prevent UI update crashes, interface update crash risk tests are usually performed during the program testing process. Related technologies usually use testing tools such as monkey to generate and send pseudo-random user event streams for dynamic testing to detect UI update crashes. However, related technologies cannot fully cover various detection scenarios, and the detection effect is poor; the detection time required is long, and the detection efficiency is low. Summary of the invention

[0003] In view of this, the purpose of the present application is to provide an interface update crash risk detection method, an interface update crash risk detection device, an electronic device and a computer-readable storage medium. By constructing a function chain and detecting whether the starting function of the function chain is a non-main thread function, it is possible to accurately and comprehensively detect whether the code of the project to be tested has a UI update crash risk, with high detection capability and efficiency.

[0004] To solve the above technical problems, in a first aspect, the present application provides an interface update crash risk detection method, comprising:

[0005] Obtain the code of the project to be tested, and perform interface update function detection on the code of the project to be tested to obtain a target interface update function;

[0006] Generate function call relationship information corresponding to the code of the project to be tested;

[0007] Taking each of the target interface update functions as a first end function, constructing a plurality of function chains using the function call relationship information, and identifying a second end function corresponding to each of the function chains;

[0008] If any of the second-end functions is a non-main thread function, it is determined that the target function chain to which the non-main thread function belongs has a risk of interface update crash.

[0009] In a feasible implementation, the method of taking each of the target interface update functions as a first end function, constructing a plurality of function chains using the function call relationship information, and identifying a second end function corresponding to each of the function chains includes:

[0010] Determine the direct calling function corresponding to each of the target interface update functions by using the function calling relationship information;

[0011] Determine the directly called function as the called function, and use the function call relationship information to determine whether there is an upper-level function corresponding to the called function;

[0012] If the upper-level function exists, determining the upper-level function as the called function;

[0013] If the upper-level function does not exist, it is determined that the function chain is constructed and the called function is determined as the second-end function.

[0014] In a feasible implementation manner, if the upper-level function does not exist, determining that the function chain is constructed includes:

[0015] If the superior function does not exist, using the function call relationship information to determine whether the called function has a corresponding target parent class function or target interface function;

[0016] If the target parent class function or the target interface function exists, determining the target parent class function or the target interface function as the called function;

[0017] If the target parent class function or the target interface function does not exist, it is determined that the function chain is constructed.

[0018] In a feasible implementation manner, before performing interface update function detection on the code of the project to be tested, the method further includes:

[0019] Using the interface update basic function to filter various functions, and determining the function that calls the interface update basic function as the interface update function;

[0020] Generate interface update function detection data using the function name corresponding to the interface update function;

[0021] Correspondingly, the interface update function detection is performed on the code of the project to be tested to obtain the target interface update function, including:

[0022] Using the interface update function detection data, matching the function names of the various functions to be tested in the code of the project to be tested;

[0023] The function to be tested matched by function name is determined as the target interface update function.

[0024] In a feasible implementation manner, the generating function call relationship information corresponding to the code of the project to be tested includes:

[0025] Get the detection plug-in and the corresponding detection plug-in information;

[0026] The detection plug-in information is added to the code of the project to be tested and compiled, and the detection plug-in is called during the compilation process to obtain the function call relationship information.

[0027] In a feasible implementation, it also includes:

[0028] generating a detection result using the objective function chain;

[0029] The executor information corresponding to the code of the project to be tested is obtained, and the test result is fed back using the executor information.

[0030] In a feasible implementation, it also includes:

[0031] Acquire uncalled function information, and mark the function corresponding to the uncalled function information in the code of the project to be tested as a uncalled function;

[0032] Correspondingly, if any of the second-end functions is a non-main thread function, determining that the target function chain to which the non-main thread function belongs has an interface update crash risk includes:

[0033] If any of the second-end functions is a non-main thread function, determining whether the non-main thread function is the non-calling function;

[0034] If any of the non-main thread functions is not the uncalled function, it is determined that the target function chain has the risk of interface update crash.

[0035] In a second aspect, the present application also provides an interface update crash risk detection device, comprising:

[0036] The update function detection module is used to obtain the code of the project to be tested, and perform interface update function detection on the code of the project to be tested to obtain the target interface update function;

[0037] A function call relationship information generating module, used to generate function call relationship information corresponding to the code of the project to be tested;

[0038] A function chain building module, used to use each of the target interface update functions as a first end function, build multiple function chains using the function call relationship information, and identify the second end function corresponding to each of the function chains;

[0039] The risk detection module is used to determine whether the target function chain to which any of the second-end functions belongs has the risk of interface update crash if the second-end function is a non-main thread function.

[0040] In a third aspect, the present application further provides an electronic device, including a memory and a processor, wherein:

[0041] The memory is used to store the computer program;

[0042] The processor is used to execute the computer program to implement the above-mentioned interface update crash risk detection method.

[0043] In a fourth aspect, the present application further provides a computer-readable storage medium for storing a computer program, wherein the computer program, when executed by a processor, implements the above-mentioned interface update crash risk detection method.

[0044] The interface update crash risk detection method provided in the present application obtains the code of the project to be tested, and performs interface update function detection on the code of the project to be tested to obtain the target interface update function; based on the target interface update function, the function call relationship information corresponding to the code of the project to be tested is generated; each target interface update function is used as the first end function, and multiple function chains are constructed using the function call relationship information, and the second end function corresponding to each function chain is identified; if any second end function is a non-main thread function, it is determined that the target function chain to which the non-main thread function belongs has an interface update crash risk.

[0045] It can be seen that when the method tests the code of the project to be tested, the target interface update function is first identified, and the target interface update function is the function in the code of the project to be tested that will cause the UI update. After obtaining the target interface update function, the function call relationship information is generated based on it. The function call relationship information records the call relationship between all functions in the code of the project to be tested, so it can be used to screen and obtain the call relationship between various functions related to the target interface update function in the code of the project to be tested. Taking the target interface update function as the first end function, the function corresponding to the other end of the function chain is the second end function. If the second end function is a non-main thread function, it means that the second end function is not a function that can only be called by the main thread, and it may be called by the child thread, and the child thread calling the second end function will cause the child thread to update the UI, so there is a risk of UI update crash, that is, it is determined that the target function chain to which it belongs has the risk of interface update crash. This method adopts a static test method, which can accurately and comprehensively identify the UI update crash in the code of the project to be tested, can cover all detection scenarios, and has a good detection effect. And there is no need for random testing, so the testing time is short and the testing efficiency is high, which solves the problems of poor testing effect and low testing efficiency existing in related technologies.

[0046] In addition, the present application also provides an interface update crash risk detection device, an electronic device, and a computer-readable storage medium, which also have the above-mentioned beneficial effects. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying any creative work.

[0048] Figure 1 A schematic diagram of a hardware composition framework applicable to an interface update crash risk detection method provided in an embodiment of the present application;

[0049] Figure 2 A schematic diagram of a hardware composition framework applicable to another interface update crash risk detection method provided in an embodiment of the present application;

[0050] Figure 3 A flowchart of a method for detecting the risk of an interface update crash provided by an embodiment of the present application;

[0051] Figure 4 A basic function call relationship diagram for interface update provided in an embodiment of the present application;

[0052] Figure 5 A structural schematic diagram of an interface update crash risk detection device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0053] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0054] Interface update crash, i.e. UI update crash, is a software error caused by the sub-thread updating the UI interface. Since the software project code is relatively complex, and as the software runs, whether the thread that updates the UI is the main thread will change accordingly, there is a high uncertainty as to whether the UI update crash will occur. In order to detect this type of crash, the relevant technology usually uses automatic testing tools such as monkey testing tools that contain thread interference, generates random event streams when the software is running, and then performs random testing, and captures the UI update crash that occurs during the test. However, random testing is time-consuming and inefficient. And it is impossible to cover all operations that can update the UI, that is, it is impossible to cover all detection scenarios. At the same time, the thread interference method cannot guarantee that the thread that updates the UI must be a sub-thread, and the detection reliability cannot be guaranteed, so the detection effect is poor. In order to solve the above problems, the present application generates function call relationship information corresponding to the project code to be tested, and uses it to construct a function chain. By judging whether the second end function in the function chain is a non-main thread function, it can be judged whether the function chain may be called by the sub-thread, and the sub-thread calling the function chain will cause the UI to be updated, and then the UI update crash occurs. Therefore, when the second-end function is a non-main thread function, it means that a UI update crash may occur, so it is determined that an interface update crash risk has been detected. This method advances the stage of problem discovery from the software running stage to the software compilation stage, and at the same time, by constructing the entire function chain of the project code to be tested, it realizes a comprehensive detection of the UI update crash risk, improves the detection accuracy, and makes the detection effect better. At the same time, there is no need for random detection, so the detection time is short and the detection efficiency is high.

[0055] For ease of understanding, the hardware composition framework used in the solution corresponding to the interface update crash risk detection method provided in the embodiment of the present application is first introduced. Figure 1 , Figure 1 A schematic diagram of a hardware composition framework applicable to an interface update crash risk detection method provided in an embodiment of the present application. The electronic device 100 may include a processor 101 and a memory 102, and may further include one or more of a multimedia component 103, an information input / information output (I / O) interface 104, and a communication component 105.

[0056] Among them, the processor 101 is used to control the overall operation of the electronic device 100 to complete all or part of the steps in the interface update crash risk detection method; the memory 102 is used to store various types of data to support the operation of the electronic device 100, and these data may include, for example, instructions for any application or method used to operate on the electronic device 100, and application-related data. The memory 102 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (Static Random Access Memory, SRAM), electrically erasable programmable read-only memory (Electrically Erasable Programmable Read-Only Memory, EEPROM), erasable programmable read-only memory (Erasable Programmable Read-Only Memory, EPROM), programmable read-only memory (Programmable Read-Only Memory, PROM), read-only memory (Read-Only Memory, ROM), magnetic memory, flash memory, magnetic disk or optical disk. In this embodiment, the memory 102 at least stores programs and / or data for implementing the following functions:

[0057] Obtain the code of the project to be tested, and perform interface update function detection on the code of the project to be tested to obtain the target interface update function;

[0058] Based on the target interface update function, generate the function call relationship information corresponding to the code of the project to be tested;

[0059] Taking each target interface update function as a first end function, constructing multiple function chains using function call relationship information, and identifying the second end function corresponding to each function chain;

[0060] If any second-end function is a non-main thread function, it is determined that the target function chain to which the non-main thread function belongs has a risk of interface update crash.

[0061] The multimedia component 103 may include a screen and an audio component. The screen may be, for example, a touch screen, and the audio component is used to output and / or input audio signals. For example, the audio component may include a microphone, which is used to receive external audio signals. The received audio signal may be further stored in the memory 102 or sent through the communication component 105. The audio component also includes at least one speaker for outputting audio signals. The I / O interface 104 provides an interface between the processor 101 and other interface modules, and the above-mentioned other interface modules may be keyboards, mice, buttons, etc. These buttons may be virtual buttons or physical buttons. The communication component 105 is used for wired or wireless communication between the electronic device 100 and other devices. Wireless communication, such as Wi-Fi, Bluetooth, Near Field Communication (NFC), 2G, 3G or 4G, or a combination of one or more of them, so the corresponding communication component 105 may include: Wi-Fi component, Bluetooth component, NFC component.

[0062] The electronic device 100 can be implemented by one or more application specific integrated circuits (ASIC), digital signal processors (DSP), digital signal processing devices (DSPD), programmable logic devices (PLD), field programmable gate arrays (FPGA), controllers, microcontrollers, microprocessors or other electronic components to execute the interface update crash risk detection method.

[0063] certainly, Figure 1 The structure of the electronic device 100 shown does not constitute a limitation on the electronic device in the embodiment of the present application. In actual applications, the electronic device 100 may include Figure 1 More or fewer components than shown, or combinations of certain components.

[0064] It is understandable that the number of electronic devices is not limited in the embodiments of the present application, and multiple electronic devices may work together to complete the interface update crash risk detection method. Figure 2 , Figure 2 A schematic diagram of a hardware composition framework applicable to another interface update crash risk detection method provided in an embodiment of the present application. Figure 2It can be known that the hardware composition framework may include: a first electronic device 11 and a second electronic device 12 , which are connected via a network 13 .

[0065] In the embodiment of the present application, the hardware structure of the first electronic device 11 and the second electronic device 12 can refer to Figure 1 In the electronic device 100. That is, it can be understood that there are two electronic devices 100 in this embodiment, and the two exchange data. Further, the form of the network 13 is not limited in the embodiment of the present application, that is, the network 13 can be a wireless network (such as WIFI, Bluetooth, etc.) or a wired network.

[0066] Among them, the first electronic device 11 and the second electronic device 12 can be the same electronic device, such as the first electronic device 11 and the second electronic device 12 are both servers; or they can be different types of electronic devices, for example, the first electronic device 11 can be a computer, and the second electronic device 12 can be a server. In one possible implementation, a server with strong computing power can be used as the second electronic device 12 to improve data processing efficiency and reliability, thereby improving the processing efficiency of interface update crash risk detection. At the same time, a computer with low cost and wide application range is used as the first electronic device 11 to realize the interaction between the second electronic device 12 and the user. It can be understood that the interaction process can be: the computer obtains the code of the project to be tested, and performs an interface update function detection on it to obtain the target interface update function. The computer sends the code of the project to be tested and the target interface update function to the server, and the server executes subsequent steps until the interface update crash risk detection of the code of the project to be tested is completed.

[0067] Based on the above description, please refer to Figure 3 , Figure 3 A flowchart of a method for detecting the risk of interface update crash provided in an embodiment of the present application. The method in this embodiment includes:

[0068] S101: Acquire the code of the project to be tested, and perform interface update function detection on the code of the project to be tested to obtain a target interface update function.

[0069] The code of the project to be tested is the code that needs to be tested for UI update crash risk detection, and its specific content is not limited. This embodiment does not limit the specific acquisition method of the code of the project to be tested. For example, in one embodiment, the code of the project to be tested can be obtained under a specified path. The specified path can be preset, or can be input by a user, or can be sent by other electronic devices. In another embodiment, the communication interface between certain electronic devices can be monitored, and the data transmitted by the communication interface can be determined as the code of the project to be tested. This embodiment does not limit the specific type, application scenario, specific number, etc. of the code of the project to be tested. For example, the code of the project to be tested corresponding to multiple Android APPs applied to smart phones can be obtained at one time. After obtaining the code of the project to be tested, the interface update function therein is detected to obtain the corresponding detection result, that is, the target interface update function, so the target interface update function is the interface update function in the code to be tested. It should be noted that the interface update function in this embodiment is a function that causes the interface to be updated, which may include a function that directly updates the interface, or may include a direct call function, and the direct call function is a function that directly calls a function that will update the interface.

[0070] This embodiment does not limit the specific detection method for the interface update function detection of the project code to be tested. For example, in a feasible implementation, the function content of the interface update function can be used to match the project code to be tested, and when the match is successful, it is determined that the target interface update function is detected. In another implementation, since the function is usually used in the code by calling the function and its content will not be rewritten, its function name can be used to match the project code to be tested, and when the match is successful, it is determined that the target interface update function is detected.

[0071] S102: Generate function call relationship information corresponding to the project code to be tested based on the target interface update function.

[0072] After detecting the target interface update function, it can be determined that the code of the project to be tested will perform UI updates during execution. In order to determine whether the function of UI update is called by the main thread, that is, whether the operation of UI update is performed by the main thread, it is also necessary to determine the calling relationship between functions, and then build a function chain. The target interface update function may be called by multiple layers, that is, the function that calls the target interface update function is also called by other functions. For example, when function A is the target interface update function, function A is called by function B, and function B is called by function C and function D. Therefore, the function chain may be composed of multiple single links, and each single line is used to represent the calling relationship between a function and the upper function or lower function that calls the function. Therefore, the generated function call relationship information can be a single-link function relationship, that is, each information item in the function call relationship information records the relationship between a certain function and the corresponding upper function, or records the relationship between a certain function and the lower function called by the function. The function call relationship information records the calling relationship between all functions in the code of the project to be tested, among which the upper function that directly calls the target interface update function must be recorded, so it can be used to generate a function chain corresponding to the target interface update function. This embodiment does not limit the specific form of the function call relationship information, for example, it may include multiple sub-information, each sub-information records multiple information items, and different sub-information records different information items. For example, in one implementation, it may include two sub-information, method and viewmethod, wherein the information item in viewmethod records the relationship between each target interface update function and the directly called function that directly calls the target interface update function, and method records the corresponding relationship between all functions in the code of the project to be tested.

[0073] This embodiment does not limit the specific method of generating function call relationship information. For example, in a feasible implementation, the AST (Abstract Syntax Tree) solution can be used to obtain function call relationship information; in another implementation, the AOP (Aspect Oriented Programming) solution can be used to obtain function call relationship information; in another implementation, the static reverse disassembly solution can be used to obtain function call relationship information; in another implementation, the ASM (a Java bytecode manipulation framework that can be used to dynamically generate classes or enhance the functions of existing classes) solution can be used to obtain function call relationship information. Depending on the different methods adopted, the specific process of obtaining the function call relationship information is also different. For details, please refer to the relevant technology, and this embodiment will not be repeated here.

[0074] S103: taking each target interface update function as a first end function, constructing multiple function chains using function call relationship information, and identifying a second end function corresponding to each function chain.

[0075] After obtaining the function call relationship information, each target interface update function is used as the first end function, that is, as the first end point of the function chain, and the call relationship between each function in the code of the project to be tested is determined according to the function call relationship information, and the function chain is constructed according to the call relationship. After the function chain is constructed, the function at the other end point is determined as the second end function, which is the most fundamental function for calling the target interface update function and the most fundamental function for causing the UI to update.

[0076] This embodiment does not limit the specific construction method of the function chain. For example, the directly called function corresponding to the target interface update function can be determined, and the function calling relationship can be used to determine whether the directly called function is called. If it is called, the parent function corresponding to the directly called function is determined, and further determined whether the parent function is called, until a function that has not been called is detected, then the function is the second end function.

[0077] S104: If any second-end function is a non-main thread function, it is determined that the target function chain to which the non-main thread function belongs has a risk of interface update crash.

[0078] It should be noted that the main thread function is a function that can only be called by the main thread, so the non-main thread function is a function that can be called by a non-main thread (i.e., a child thread), and its specific number and content are not limited. After the function chain is constructed, each function chain has a corresponding second-end function. If any second-end function is a non-main thread function, it means that the function can be called by a child thread, and calling the function will inevitably cause the UI to update. If the second-end function is called by the child thread, it will cause the UI update to crash. Therefore, when any second-end function is a non-main thread function, it means that there is a risk of UI update crash, and it is determined that the target function chain to which it belongs has the risk of interface update crash, that is, UI update crash risk.

[0079] The interface update crash risk detection method provided by the embodiment of the present application is applied. When testing the project code to be tested, the target interface update function is first identified. The target interface update function is a function in the project code to be tested that will cause the UI update. After obtaining the target interface update function, function call relationship information is generated based on it. The function call relationship information records the call relationship between all functions in the project code to be tested, so it can be used to screen and obtain the call relationship between each function related to the target interface update function in the project code to be tested. Taking the target interface update function as the first end function, the function corresponding to the other end of the function chain is the second end function. If the second end function is a non-main thread function, it means that the second end function is not a function that can only be called by the main thread, and it may be called by the child thread, and the child thread calling the second end function will cause the child thread to update the UI, so there is a UI update crash risk, that is, it is determined that the target function chain to which it belongs has an interface update crash risk. The method adopts a static test method, which can accurately and comprehensively identify the UI update crash in the project code to be tested, can cover all detection scenarios, and has a good detection effect. And there is no need for random testing, so the testing time is short and the testing efficiency is high, which solves the problems of poor testing effect and low testing efficiency existing in related technologies.

[0080] Based on the above embodiment, this embodiment specifically describes some steps in the above embodiment. In a specific implementation, before detecting the target interface update function in the project code to be tested, it is necessary to determine which functions are interface update functions. Therefore, before performing interface update function detection on the project code to be tested, the following steps may also be included:

[0081] Step 11: Use the interface update basic function to filter various functions, and determine the function that calls the interface update basic function as the interface update function.

[0082] The interface update basic function is a function for performing page updates, that is, a function for directly updating the interface, and is a function of the lowest level. Depending on the type of code corresponding to the project code to be tested, the content of the interface update basic function may be different, and the number of page update basic functions corresponding to each code type may be one or more. In other embodiments, the page update basic function may be directly used as the interface update function. In the present embodiment, since the project code to be tested is usually constructed with a function of a fixed level as the basic function, and these basic functions are usually not functions of the lowest level, but are composed by calling functions of a lower level than the level thereof, which necessarily include functions of the lowest level. Therefore, the interface update basic function cannot be directly used as the interface update function, because the interface update basic function does not exist in the project code to be tested. In this case, it is necessary to use the interface update basic function to filter each basic function, specifically to filter the function content of each basic function, and determine the basic function with the interface update function as the interface update function.

[0083] Taking the Java programming language as an example, please refer to Figure 4 , Figure 4 A basic function call relationship diagram for interface update provided in an embodiment of the present application. When updating the UI, the checkThread function in the underlying ViewRootImpl.java must be called, and checkThread is called by the requestLayout function and incalidateChildInParent function in ViewRootImpl.java, and the requestLayout function in ViewRootImpl.java is called by the requestLayout function in View.java, and the incalidateChildInParent function is called by the invalidate function in View.java. In actual use, users usually use the functions of the View class (including View.java, ImageView.java, TextView.java, ViewGroup.java, etc.) as the basic functions to build project codes. Therefore, when determining the interface update function, it is necessary to scan the View class for functions that use requestLayout and invalidate as interface update functions. For example, the setText function, the setVisibility function, etc.

[0084] Step 12: Generate interface update function detection data using the function name corresponding to the interface update function.

[0085] Since the interface update function will be directly called when used by inputting its function name, the function name of each interface update function can be used to generate interface update function detection data, so as to use it to detect the target interface update function in the future. Accordingly, the step of performing interface update function detection on the code of the project to be tested and obtaining the target interface update function may include:

[0086] Step 13: Use the interface update function detection data to match the function name of each function to be tested in the code of the project to be tested.

[0087] Step 14: Determine the function to be tested matched by function name as the target interface update function.

[0088] When performing interface update function detection, the interface update function detection data can be used as a matching standard to match the function names of the various functions to be tested in the code of the project to be tested. The function to be tested can be any function in the code of the project to be tested. If the function name of the function to be tested matches a function name in the code of the project to be tested, it means that the function name matching is passed, and the function to be tested that passes the matching is the target interface update function.

[0089] Based on the above embodiment, in a specific implementation, in order to improve versatility and achieve the effect of flexibly selecting a computing device and quickly enabling it to have the ability to detect interface update crash risks when needed, the function call relationship information can be obtained by using a detection plug-in. Specifically, the process of generating the function call relationship information corresponding to the code of the project to be tested can specifically include the following steps:

[0090] Step 21: Obtain the detection plug-in and the corresponding detection plug-in information;

[0091] It is understandable that the specific category of the detection plug-in may be different depending on the different acquisition schemes used for the function call relationship information. For example, when the ASM scheme is used to obtain the function call relationship information, the detection plug-in may be an ASM plug-in. The detection plug-in information is used to communicate with the code of the project to be tested to generate a detection script, and its specific content is not limited, for example, it may be an operation mode, etc. The detection plug-in can be generated in advance, and its specific generation method can refer to the relevant technology, which will not be repeated here. It should be noted that the detection plug-in may also be different depending on the specific type of electronic device.

[0092] Step 22: Add the detection plug-in information to the project code to be tested and compile it. During the compilation process, call the detection plug-in to obtain the function call relationship information.

[0093] The detection plug-in information is combined with the code of the project to be tested and then compiled. Specifically, the detection plug-in information can be configured in the build.gradle file of the project code to be tested, and then the project code to be tested is compiled. During compilation, the detection plug-in can be called based on the above configuration, and the detection plug-in can be used to generate function call relationship information according to its internal logic. By setting the way the detection plug-in is compiled, the function call relationship information can be generated on any electronic device (such as an Android device) that matches the detection plug-in when needed, thereby completing the UI update crash risk detection and improving versatility.

[0094] Based on the above embodiment, in one implementation, since the target interface update function may be called multiple times, and different target interface update functions may be called at different times, in order to accurately construct a function chain and then accurately identify the second end function, each target interface update function is used as a first end function, and multiple function chains are constructed using function call relationship information, and the process of identifying the second end function corresponding to each function chain may include the following steps:

[0095] Step 31: Determine the direct calling function corresponding to each target interface update function by using the function calling relationship information.

[0096] In this embodiment, in order to quickly build a function chain, the function call relationship information may include direct call information, which records each target interface update function and the direct call function that directly calls the target interface update function. Through the direct call information, the direct call function can be directly obtained, and there is no need to filter the call relationship between all functions corresponding to the project code to be tested according to the target interface update function, thereby improving the construction speed of the function chain. The direct call information can be called ViewMethod information, and its form can be txt format. Specifically, its content format can be:

[0097] A class name--function A--A parameters--A parent class--A interface list {B class name-the called target interface update function B--B parameters};

[0098] In one implementation, a function A may call multiple target interface update functions. In this case, the first target interface update function called by function A may be determined as function B. Therefore, when generating direct call information, when a target interface update function and a corresponding direct call function are detected, it may be determined whether the target interface update function is the first interface update function called by the direct call function. If so, the corresponding relationship is written into the direct call information. If not, no operation is performed.

[0099] Step 32: Determine the directly called function as the called function, and use the function call relationship information to determine whether there is an upper-level function corresponding to the called function.

[0100] In this embodiment, the function call relationship information may include function relationship information, which is information recording the call relationship between all functions corresponding to the project code to be tested. Since there may be multiple layers of calls, after determining the direct call function, the function relationship information can also be used to determine whether the called function is called by other functions, that is, to determine whether there is a superior function corresponding to the called function. The function relationship information can be called Method information, and its form can be txt format. Specifically, its content format can be:

[0101] A class name -- function A -- A parameters -- A parent class -- A interface list {B class name -- called function B -- B parameters, C class name -- called function C -- C parameters, ...};

[0102] It can be understood that this format is that function A calls function B, function C and other functions.

[0103] Step 33: If there is an upper-level function, the upper-level function is determined as the called function.

[0104] If there is a superior function, it means that the current called function is still called by other functions. Therefore, the superior function can be determined as the new called function, so as to execute again the step of using the function call relationship information to determine whether there is a superior function corresponding to the called function, and determine whether the superior function still exists.

[0105] Step 34: If there is no upper-level function, it is determined that the function chain is constructed and the called function is determined as the second-end function.

[0106] If the called function does not have a superior function, it means that the called function has not been called by any function and is the initiator of the function chain. In this case, it can be determined that the function chain is built and the called function is determined as the second end function.

[0107] Furthermore, in a specific implementation, there may be an overridden function in the code of the project to be tested. The overridden function is a function obtained by overriding a parent class function or an interface function. Function overriding is actually function coverage. When a member function that is exactly the same as a base class function is declared in a derived class, the base class function is covered. When the base class function is called, the overridden derived class function, i.e., the overridden function, is actually called. When overriding a function, the function class name may be modified. Therefore, if the called function is an overridden function, its function class name may be different from the function class name of its corresponding parent class function or interface function. Therefore, it may be mistakenly believed that it has no superior function, resulting in a break in the function chain, making the generated function chain an erroneous function chain. In order to solve this problem, if there is no superior function, the process of determining that the function chain is built can include the following steps:

[0108] Step 41: If there is no superior function, use the function call relationship information to determine whether the called function has a corresponding target parent class function or target interface function.

[0109] In this embodiment, the function call relationship information may also contain rewrite function information, which is used to record the correspondence between each rewrite function and its corresponding parent class function or interface function. If a called function does not have an upper-level function, it means that it may be a rewrite function. In this case, it can be used to filter the rewrite function information to determine whether there is a corresponding target parent class function or target interface function. The rewrite function information can be called Super_Inter_Method information, and its format can be txt. Specifically, its content format can be:

[0110] A class name--parent class or interface function A--A parameter--A parent class--A interface list {B class name--override function B--B parameter, C class name--override function C--C parameter,...};

[0111] It should be noted that the only difference between the called function and the target parent class function or the target interface function is the function class name, and the rest of the content is the same. Taking the above content format as an example, the class name of A is different from the class name of B, the parameters of A are the same as the parameters of B, and the parent class or interface function A (i.e. the function name of the A function) is the same as the rewriting function B (i.e. the function name of the B function). Therefore, when judging whether there is a target parent class function or a target interface function, it can be based on whether there is a function with a different class name from the called function but the same function name and function parameters.

[0112] Step 42: If there is a target parent class function or a target interface function, the target parent class function or the target interface function is determined as the called function.

[0113] If it exists, it can be determined that the current called function is an overwritten function. Therefore, in order to avoid breaking the function chain, the target parent class function or the target interface function can be determined as the new called function, so that the new called function can be used to re-execute the step of using the function call relationship information to determine whether there is a superior function corresponding to the called function, and continue to build the function chain to obtain an accurate function chain.

[0114] Step 43: If the target parent class function or the target interface function does not exist, it is determined that the function chain is constructed.

[0115] If there is no target parent class function or target interface function, it means that the called function is the second port function, and the function chain is completed. Specifically, the format of the function chain can be:

[0116] {

[0117] A class name -- function A -- A parameter (first end)

[0118] B class name -- function B -- B parameter

[0119] C class name -- function C -- C parameter ...

[0120] X class name--function X--X parameter (second end)

[0121] }

[0122] Therefore, the function chain indicates that function A is called by function B, function B is called by function C, and so on, and the final second-end function is function X.

[0123] Based on the above embodiments, in one implementation, there may be uncalled functions in the project code under test, for example, after the project code under test has been modified multiple times, there may be functions that were called before the modification but not called after the modification. Although these functions exist, they are not called by the project code under test, that is, they will not be executed. Therefore, even if they eventually call the target interface update function, the project code under test will not cause UI update when it is running, so there is no risk of UI update crash. Therefore, in order to improve the accuracy of risk detection, this embodiment may also include:

[0124] Step 51: Obtain the uncalled function information, and mark the function corresponding to the uncalled function information in the code of the project to be tested as a uncalled function.

[0125] In this embodiment, the uncalled function information may consist of a function name, function parameters, and function class name, or may be a function number, etc. After obtaining the uncalled function information, the corresponding functions may be marked as uncalled functions, that is, although these functions exist in the code of the project to be tested, they are not actually called, that is, they are not executed.

[0126] Correspondingly, if any second-end function is a non-main thread function, the process of determining that the target function chain to which the non-main thread function belongs has a risk of interface update crash may include the following steps:

[0127] Step 52: If any second-end function is a non-main thread function, determine whether the non-main thread function is a non-calling function.

[0128] When the presence of a non-main thread function is detected, it can be further determined whether it is a non-calling function to prevent the UI update crash risk from being incorrectly detected. This embodiment does not limit the specific judgment method. For example, the function name, function parameters and function class name of the non-main thread function can be used to match the function name, function parameters and function class name of the non-calling function. If the function name, function class name and function parameters are the same, it is determined that the match is successful. If the match is successful, it is determined that it is a non-calling function; or the function content of the non-main thread function can be used to match the function content of the non-calling function. If the match is successful, it is determined that it is a non-calling function.

[0129] Step 53: If any non-main thread function is not a non-called function, it is determined that the target function chain has an interface update crash risk.

[0130] If the non-main thread function is not a non-calling function, it means that the non-main thread function is indeed called, that is, it is indeed executed, and it is a non-main thread function, which means that it may be called by a child thread. Therefore, it is determined that the target function chain to which it belongs has a UI update crash risk, that is, an interface update crash risk. By determining whether the non-main thread function is a non-calling function, risk false alarms can be avoided and detection accuracy can be improved.

[0131] Furthermore, in order to enable the user to accurately know the specific location of the UI update crash risk so that the user can efficiently repair the risk, the following steps may be included:

[0132] Step 61: Generate detection results using the target function chain.

[0133] By using the target function chain to generate the detection results, the specific functions and function chains that cause the risk of interface update crash can be accurately described in the detection results, so that users can repair the risks accordingly.

[0134] Step 62: Obtain the executor information corresponding to the project code to be tested, and use the executor information to feedback the test result.

[0135] Since the detection of each project code to be tested requires a certain amount of time, the executor information corresponding to the project code to be tested can be preset. The executor information can represent the user corresponding to the project code to be tested. By using the executor information to feedback the detection results, the user can know the detection results as soon as possible after the detection is completed.

[0136] The following is an introduction to an interface update crash risk detection device provided in an embodiment of the present application. The interface update crash risk detection device described below and the interface update crash risk detection method described above can be referenced to each other.

[0137] Please refer to Figure 5 , Figure 5 A schematic diagram of a structure of an interface update crash risk detection device provided in an embodiment of the present application includes:

[0138] The update function detection module 110 is used to obtain the code of the project to be tested, and perform interface update function detection on the code of the project to be tested to obtain the target interface update function;

[0139] The function call relationship information generating module 120 is used to generate the function call relationship information corresponding to the code of the project to be tested;

[0140] The function chain construction module 130 is used to use each target interface update function as a first end function, construct multiple function chains using function call relationship information, and identify the second end function corresponding to each function chain;

[0141] The risk detection module 140 is used to determine whether the target function chain to which the non-main thread function belongs has an interface update crash risk if any second end function is a non-main thread function.

[0142] The interface update crash risk detection device provided by the embodiment of the present application is applied. When testing the project code to be tested, the target interface update function is first identified. The target interface update function is a function in the project code to be tested that will cause the UI update. After obtaining the target interface update function, function call relationship information is generated based on it. The function call relationship information records the call relationship between all functions in the project code to be tested, so it can be used to screen and obtain the call relationship between each function related to the target interface update function in the project code to be tested. Taking the target interface update function as the first end function, the function corresponding to the other end of the function chain is the second end function. If the second end function is a non-main thread function, it means that the second end function is not a function that can only be called by the main thread, and it may be called by the child thread, and the child thread calling the second end function will cause the child thread to update the UI, so there is a UI update crash risk, that is, it is determined that the target function chain to which it belongs has an interface update crash risk. The device adopts a static test method, which can accurately and comprehensively identify the UI update crash in the project code to be tested, can cover all detection scenarios, and has a good detection effect. And there is no need for random testing, so the testing time is short and the testing efficiency is high, which solves the problems of poor testing effect and low testing efficiency existing in related technologies.

[0143] Optionally, the function chain building module 130 includes:

[0144] A direct calling function determining unit, used to determine the direct calling function corresponding to each target interface update function by using the function calling relationship information;

[0145] The upper-level function determination unit is used to determine the directly called function as the called function, and use the function call relationship information to determine whether there is an upper-level function corresponding to the called function;

[0146] A called function determination unit, used for determining the upper-level function as the called function if there is an upper-level function;

[0147] The second end function determination unit is used to determine that the function chain is constructed if there is no upper-level function, and determine the called function as the second end function.

[0148] Optionally, the second-end function determination unit includes:

[0149] The rewrite judgment subunit is used to use the function call relationship information to judge whether the called function has a corresponding target parent class function or target interface function if there is no superior function;

[0150] The called function determination subunit is used to determine the target parent class function or the target interface function as the called function if there is a target parent class function or a target interface function;

[0151] The construction completion determination subunit is used to determine that the function chain construction is completed if the target parent class function or the target interface function does not exist.

[0152] Optionally, it also includes:

[0153] An interface update function determination module, used to filter various functions using the interface update basic function, and determine the function that calls the interface update basic function as the interface update function;

[0154] A detection data generation module, used to generate interface update function detection data using a function name corresponding to the interface update function;

[0155] Accordingly, the function detection module is updated, including:

[0156] A function name matching unit, used for matching the function names of various functions to be tested in the code of the project to be tested by using the interface update function detection data;

[0157] The target interface update function determination unit is used to determine the function to be tested matched by function name as the target interface update function.

[0158] Optionally, the function call relationship information generation module includes:

[0159] A plug-in acquisition unit, used to acquire a detection plug-in and corresponding detection plug-in information;

[0160] The detection script generation unit is used to add the detection plug-in information to the code of the project to be tested and compile it. During the compilation process, the detection plug-in is called to obtain function call relationship information.

[0161] Optionally, it also includes:

[0162] A detection result generation module, used for generating detection results using a target function chain;

[0163] The result feedback module is used to obtain the executor information corresponding to the project code to be tested, and use the executor information to feedback the detection results.

[0164] Optionally, it also includes:

[0165] The uncalled function marking module is used to obtain the uncalled function information and mark the function corresponding to the uncalled function information in the code of the project to be tested as the uncalled function;

[0166] Correspondingly, the risk detection module includes:

[0167] a non-called function determination unit, used for determining whether the non-main thread function is a non-called function if any second end function is a non-main thread function;

[0168] The risk determination unit is used to determine that the target function chain has an interface update crash risk if any non-main thread function is not a non-calling function.

[0169] The computer-readable storage medium provided in an embodiment of the present application is introduced below. The computer-readable storage medium described below and the interface update crash risk detection method described above can be referenced to each other.

[0170] The present application also provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of the above-mentioned interface update crash risk detection method are implemented.

[0171] The computer-readable storage medium may include: a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and other media that can store program codes.

[0172] In this specification, each embodiment is described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the embodiments can be referred to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the method part.

[0173] Those skilled in the art may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented with electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in terms of function in the above description. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art may use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0174] The steps of the method or algorithm described in conjunction with the embodiments disclosed herein may be implemented directly using hardware, a software module executed by a processor, or a combination of the two. The software module may be placed in a random access memory (RAM), a memory, a read-only memory (ROM), an electrically programmable ROM, an electrically erasable programmable ROM, a register, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

[0175] Finally, it should be noted that, in this article, relationships such as first and second, etc. are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms include, include or any other variations are intended to cover non-exclusive inclusion, so that a process, method, article or device that includes a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device.

[0176] Specific examples are used herein to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method of the present application and its core idea. At the same time, for those skilled in the art, according to the idea of ​​the present application, there will be changes in the specific implementation methods and application scope. In summary, the content of this specification should not be understood as a limitation on the present application.

Claims

1. A method for detecting the risk of interface update crash, characterized in that: include: Obtain the code of the project to be tested, and perform interface update function detection on the code of the project to be tested to obtain a target interface update function; Generate function call relationship information corresponding to the code of the project to be tested; Taking each of the target interface update functions as a first end function, constructing a plurality of function chains using the function call relationship information, and identifying a second end function corresponding to each of the function chains; If any of the second-end functions is a non-main thread function, determining that the target function chain to which the non-main thread function belongs has an interface update crash risk; The method of taking each of the target interface update functions as a first end function, constructing a plurality of function chains using the function call relationship information, and identifying a second end function corresponding to each of the function chains includes: Determine the direct calling function corresponding to each of the target interface update functions by using the function calling relationship information; Determine the directly called function as the called function, and use the function call relationship information to determine whether there is an upper-level function corresponding to the called function; If the upper-level function exists, determining the upper-level function as the called function; If the upper-level function does not exist, it is determined that the function chain is constructed and the called function is determined as the second-end function.

2. The interface update crash risk detection method according to claim 1, characterized in that: If the upper-level function does not exist, determining that the function chain is constructed includes: If the superior function does not exist, using the function call relationship information to determine whether the called function has a corresponding target parent class function or target interface function; If the target parent class function or the target interface function exists, determining the target parent class function or the target interface function as the called function; If the target parent class function or the target interface function does not exist, it is determined that the function chain is constructed.

3. The interface update crash risk detection method according to claim 1, characterized in that: Before performing interface update function detection on the code of the project to be tested, it also includes: Using the interface update basic function to filter various functions, and determining the function that calls the interface update basic function as the interface update function; Generate interface update function detection data using the function name corresponding to the interface update function; Correspondingly, the interface update function detection is performed on the code of the project to be tested to obtain the target interface update function, including: Using the interface update function detection data, matching the function names of the various functions to be tested in the code of the project to be tested; The function to be tested matched by function name is determined as the target interface update function.

4. The method for detecting the risk of interface update crash according to claim 1, characterized in that: The generating of function call relationship information corresponding to the code of the project to be tested includes: Get the detection plug-in and the corresponding detection plug-in information; The detection plug-in information is added to the code of the project to be tested and compiled, and the detection plug-in is called during the compilation process to obtain the function call relationship information.

5. The method for detecting the risk of interface update crash according to claim 1, characterized in that: Also includes: generating a detection result using the objective function chain; The executor information corresponding to the code of the project to be tested is obtained, and the test result is fed back using the executor information.

6. The method for detecting the risk of interface update crash according to any one of claims 1 to 5, characterized in that: Also includes: Acquire uncalled function information, and mark the function corresponding to the uncalled function information in the code of the project to be tested as a uncalled function; Correspondingly, if any of the second-end functions is a non-main thread function, determining that the target function chain to which the non-main thread function belongs has an interface update crash risk includes: If any of the second-end functions is a non-main thread function, determining whether the non-main thread function is the non-calling function; If any of the non-main thread functions is not the uncalled function, it is determined that the target function chain has the risk of interface update crash.

7. An interface update crash risk detection device, characterized in that: include: The update function detection module is used to obtain the code of the project to be tested, and perform interface update function detection on the code of the project to be tested to obtain the target interface update function; A function call relationship information generating module, used to generate function call relationship information corresponding to the code of the project to be tested; A function chain building module, used to use each of the target interface update functions as a first end function, build multiple function chains using the function call relationship information, and identify the second end function corresponding to each of the function chains; a risk detection module, configured to determine, if any of the second-end functions is a non-main thread function, that a target function chain to which the non-main thread function belongs has an interface update crash risk; The function chain building module includes: A direct calling function determining unit, used to determine the direct calling function corresponding to each of the target interface update functions by using the function calling relationship information; An upper-level function determination unit, used to determine the directly calling function as the called function, and to determine whether there is an upper-level function corresponding to the called function by using the function calling relationship information; a called function determining unit, configured to determine the upper-level function as the called function if the upper-level function exists; The second end function determination unit is used to determine that the function chain is completed if the upper-level function does not exist, and determine the called function as the second end function.

8. An electronic device, characterized in that: comprising a memory and a processor, wherein: The memory is used to store the computer program; The processor is used to execute the computer program to implement the interface update crash risk detection method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that: Used to store a computer program, wherein when the computer program is executed by a processor, the interface update crash risk detection method according to any one of claims 1 to 6 is implemented.

Images