CN107273283B - Automatic software detection method and device - Google Patents
Automatic software detection method and device Download PDFInfo
- Publication number
- CN107273283B CN107273283B CN201610214549.XA CN201610214549A CN107273283B CN 107273283 B CN107273283 B CN 107273283B CN 201610214549 A CN201610214549 A CN 201610214549A CN 107273283 B CN107273283 B CN 107273283B
- Authority
- CN
- China
- Prior art keywords
- tested
- event
- software
- real
- time
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/362—Software debugging
- G06F11/3636—Software debugging by tracing the execution of the program
Abstract
The invention relates to an automatic software detection method and a device, and the method provided by the embodiment of the invention comprises the following steps: generating an event to be tested according to a logic script which is edited in advance and corresponds to the software to be tested; controlling the software to be tested to automatically run the event to be tested; the method and the device have the advantages that the real-time data of the software to be detected are monitored in the process of running the event to be detected, the event that the software to be detected is abnormal is determined and recorded according to the real-time data, the real-time data of the software to be detected are monitored in the process of automatically running the event to be detected by the software to be detected, the event that the software to be detected is abnormal is determined and recorded according to the real-time data, the labor cost for detecting the software to be detected is saved, and the detection efficiency of the software to be detected.
Description
Technical Field
The invention relates to the field of computers, in particular to an automatic software detection method and device.
Background
Memory leakage, also referred to as "memory leakage," is the space dynamically created by the dynamic memory allocation function that is not freed after use, resulting in the memory cell being occupied all the time. Until the end of the procedure, the so-called memory leak. Classified by the way it occurs, memory leaks can be classified into 4 categories: common memory leak, accidental memory leak, one-time memory leak, implicit memory leak. From the perspective of software usage by a user, the memory leak itself does not pose any harm, and as a general user, the memory leak is not felt to exist at all. What is really harmful is the accumulation of memory leaks, which eventually consume all of the memory of the system. Common memory leak hazards are: CPU resource exhaustion (no reaction of an intelligent terminal running software), process ID exhaustion (no new process or serial port can be created), and hard disk exhaustion. In order to prevent the above hazards, developers need to find out the memory leak of the software and find out the running code with the memory leak in the process of developing the software, so as to improve the software and provide better experience for users.
Similarly, in order to provide better experience for users, developers need to monitor the electricity consumption (excessive electricity consumption), the flow consumption (excessive consumed flow) and the running condition (whether the software crashes) of the software, find the software running code when the software is abnormally used, and further perfect the software.
With the development of intelligent terminals and the continuous development of operating system functions, software on the intelligent terminals is increasingly abundant, and in order to enable users to obtain better experience, higher requirements are made on the use conditions of memory, flow and electric quantity of the software and the running stability of the software. The prior art mainly adopts a manual detection mode to detect aiming at the problems, but the manual detection needs to consume a large amount of human resources, the manual detection efficiency is low, and whether the detection result is accurate or not is limited by the detection level of detection personnel.
Disclosure of Invention
Aiming at the problems in the prior art, the application provides an automatic software detection method and device to realize automatic software detection and improve detection accuracy and efficiency.
In a first aspect, an embodiment of the present invention provides an automated software detection method, where the method includes: generating an event to be tested according to a logic script which is edited in advance and corresponds to the software to be tested; controlling the software to be tested to automatically run the event to be tested; monitoring real-time data generated by the software to be tested in the process of running the event to be tested, and determining and recording the abnormal event of the software to be tested according to the real-time data.
In a second aspect, an embodiment of the present invention provides an automated software testing apparatus, including:
the to-be-tested event generation module is used for generating to-be-tested events according to the pre-edited logic script corresponding to the to-be-tested software;
the control module is used for controlling the to-be-tested software to automatically run the to-be-tested event;
and the monitoring module is used for monitoring real-time data generated by the software to be tested in the process of running the event to be tested, and determining and recording the abnormal event of the software to be tested according to the real-time data.
According to the technical scheme provided by the embodiment of the invention, on one hand, firstly, a to-be-detected event running in the to-be-detected software is generated according to a pre-edited logic script corresponding to the to-be-detected software, so that the generated to-be-detected event is more consistent with the to-be-detected software; and secondly, determining and recording an abnormal event of the software to be detected according to real-time data of the software to be detected in the process of running the event to be detected, wherein the real-time data can reflect the real condition of the software to be detected in the process of running the event to be detected most truly, so that the generated event is more accurate. On the other hand, the automatic software detection is realized, manual participation is not needed, the labor cost is reduced, and the efficiency is improved.
Drawings
FIG. 1 is a schematic diagram of an application scenario of an embodiment of the present invention;
FIG. 2 is a schematic flow chart illustrating an automated software inspection method according to an embodiment of the present invention;
fig. 3 is a schematic structural diagram of an automated software inspection apparatus according to an embodiment of the present invention.
Detailed Description
As shown in fig. 1, the technical solution provided by the embodiment of the present invention may be suitable for automatic detection of to-be-detected software running on a notebook computer, a desktop computer, a tablet computer, a mobile phone, and other terminal devices. The technical scheme provided by the invention can be that a simulator is generated on the terminal equipment, a to-be-detected event corresponding to the to-be-detected software is generated through the simulator, the to-be-detected software is controlled to run the to-be-detected event, and an abnormal event (such as a memory leakage event, a flow use abnormal event, an electric quantity use abnormal event, a running crash event and the like) of the to-be-detected software is obtained according to real-time data generated in the process that the to-be-detected software runs the to-be-detected event, so that developers can find problems existing in the to-be-detected software in time, process the problems according to specific problems, and perfect.
The technical solution of the present invention is further described in detail by the accompanying drawings and embodiments.
Fig. 2 is a schematic flow chart of an automated software detection method according to an embodiment of the present invention, where the method includes:
and step S101, generating an event to be tested according to a logic script which is edited in advance and corresponds to the software to be tested.
In the embodiment of the present invention, the step S101 may be implemented as follows: firstly, analyzing a logic script which is edited in advance and corresponds to software to be tested to obtain an operation instruction for operating the software to be tested and an operation rule of the operation instruction; secondly, generating an event to be tested according to the operation instruction and the operation rule, and indicating the software to be tested to execute the corresponding operation instruction on the software to be tested according to the operation rule in the event to be tested so that the software to be tested can execute the corresponding operation instruction according to the operation rule in the event to be tested.
In this embodiment, a logic script required by the software to be tested is written in advance according to the functions of the software to be tested, and the logic script includes an operation instruction for operating each function of the software to be tested and an operation rule for executing the operation instruction. Taking electronic map software as an example, the electronic map software includes functions of POI search, road condition viewing, electronic map dragging, electronic map zooming, route planning, navigation, peripheral POI query, etc., and the logic script corresponding to the electronic map software edited in advance may include the following instructions: clicking a navigation control, selecting a navigation mode (including driving navigation, bus navigation, bicycle navigation and walking navigation), inputting a starting point and an input end point on a route planning page, clicking an amplifying control, clicking a reducing control, clicking a route control, clicking a nearby control, clicking a road condition control, downloading an offline map, searching POI (point of interest), clicking a map interface randomly and the like.
In this embodiment, the event to be detected may be a randomly generated event, where one event to be detected corresponds to one operation instruction, or one event to be detected corresponds to multiple operation instructions. The operation instructions may have different kinds of divisions, taking electronic map software as an example, the operation instructions include: randomly clicking a screen (any position of the screen), clicking a control, dragging, inputting characters, inputting voice, rotating the screen, switching pages and the like. The rules of the operation instructions may include the timing of execution of the operation instructions, the manner of execution, the order of execution, the proportion of execution, etc. For example: the random clicking screen accounts for 70% of the operation instruction, the clicking control accounts for 10% of the operation instruction, the page switching accounts for 10% of the operation instruction, and the like. The execution sequence of the operation instructions is as follows: click randomly on screen > page switch > click control > page switch > screen rotate > drag, etc.
And S102, controlling the to-be-tested software to automatically run the to-be-tested event.
In step S102, the software to be tested is controlled to execute the corresponding operation instruction according to the operation rule in the event to be tested.
Step S103, monitoring real-time data generated by the software to be tested in the process of running the event to be tested, and determining and recording the abnormal event of the software to be tested according to the real-time data.
In the embodiment of the present invention, the foregoing steps S101 to S103 are steps executed for each event to be tested, that is, each time an event to be tested is generated, the software to be tested is controlled to run the event to be tested, and an event that the software to be tested is abnormal is determined and recorded according to the real-time data; and after the completion, continuing to generate the next event to be detected, and repeating the steps.
In the embodiment of the invention, the event of the abnormal occurrence of the software to be tested, which is determined and recorded according to the real-time data, at least comprises one of the following events: memory leak events, traffic usage exception events, power usage exception events, operational crash events, and the like.
In the following, how to determine and record the memory leak event, the traffic usage exception event, the power usage exception event, and the operation crash event according to the real-time data is described in detail through specific embodiments.
Optionally, the step 103 may specifically include step a1 and step a2, where the record corresponding to the memory leak event:
step a1, dynamically monitoring the situations of applying for and releasing the memory block during the operation of the to-be-tested software, adding one to the number of users of the memory block when applying for the memory block, and subtracting one from the number of users of the memory block when releasing the memory block; and the number of the first and second groups,
step a2, determining whether the memory block has no pointer pointing and the number of users is greater than zero, if yes, using the operation code corresponding to the pointer allocated when applying for the memory block and the memory block as a memory leak event record.
In step a2, dynamically monitoring whether the memory block has no pointer pointing, and if so, continuing to dynamically monitor; if no pointer points, whether the number of users using the memory block is larger than zero is judged, if yes, the operation code corresponding to the pointer distributed when the memory block is applied and the memory block are used as the memory leakage event record, and if not, no processing is carried out.
Taking the memory block a as an example, when the software to be tested applies for using the memory block a, allocating a pointer to the memory block a to point to the memory block a to indicate that the memory block a is applied for use, and at this time, adding 1 to the number of users of the memory block a; when the software to be tested finishes releasing the memory block A, the pointer does not point to the memory block A any more to indicate that the memory block A is released, and at the moment, the number of users of the memory block A needs to be reduced by 1; when the number of users of the memory block a is 0, the memory block a is completely released. Obviously, when the memory block a is not pointed but the number of users is greater than 0, it indicates that the memory block a is not released after the software to be tested is applied for use, and the memory block a has a memory leak.
The working principle and process of obtaining the memory leak event will be described by way of example:
first, the following are exemplified:
memory block B2 (pointer 1, pointer 2) represents: the number of users of the memory block B is 2, and the pointer 1 and the pointer 3 point to the memory block B;
memory block C1 (pointer 3) represents: the number of users of the memory block C is 1, and the pointer 3 points to the memory block C;
the memory block D3 (pointer 1, pointer 2, pointer 3) represents: the number of users of the memory block D is 3, and the pointer 1, the pointer 2, and the pointer 3 point to the memory block D.
The results of monitoring the memory block used by the software to be tested for the first time are as follows: memory chunk B2 (pointer 1, pointer 2), memory chunk C1 (pointer 3), memory chunk D3 (pointer 1, pointer 2, pointer 3);
the result of the second monitoring (e.g. after 10 s) of the memory block used by the software to be tested is as follows: as can be seen from the second monitoring result, the memory block C has a memory leak in the memory block B2 (pointer 1, pointer 2), the memory block C1 (no pointer), and the memory block D3 (pointer 1, pointer 2, and pointer 3), and at this time, the operation code corresponding to the memory block C and the pointer 3 assigned when the memory block C is applied is recorded as a memory leak event.
Optionally, the step 103 may specifically include step B1 and step B2, where the record of the corresponding flow usage abnormal event:
step B1, dynamically monitoring and recording the real-time flow consumed by the software to be tested in the process of running the event to be tested, wherein the real-time flow is the flow consumed in unit time; and the number of the first and second groups,
step B2, judging whether the real-time flow is in a preset reference flow range, and if not, taking the real-time flow, the current time and a to-be-detected event of the to-be-detected software running at the current time as a flow use abnormal event record; and if so, continuously judging whether the real-time flow is in a preset reference flow range.
In the embodiment of the invention, the real-time flow of the software to be tested in the process of running the event to be tested is dynamically monitored, and if the monitored real-time flow at a certain time t exceeds the reference flow range, the real-time flow at the time t and the event to be tested running at the time t are taken as flow use abnormal event records. The event to be tested, which is determined to run at the time t, can be obtained by querying the system log, and the event to be tested, which runs in a certain time range of the time t, of the software to be tested can be obtained.
The preset reference flow range in the event to be detected can be obtained according to the operation instruction corresponding to the event to be detected and the network connection mode (wifi, bluetooth, data flow and the like) of the terminal device where the software to be detected is located. The reference flow range can also be set to [0.9a,1.1a ], wherein a is the average value of real-time flow consumed by the software to be tested in the process of running the running event to be tested; or a is an empirical value of the preset setting.
Optionally, the step 103 may specifically include a step C1 and a step C2, where the record of the corresponding electricity usage event:
step C1, dynamically monitoring and recording the real-time electric quantity consumed by the software to be tested in the process of running the event to be tested, wherein the real-time electric quantity is the electric quantity consumed in unit time;
the dynamic monitoring may be a periodic monitoring, for example, every 10 s. And taking the difference value of the power consumption obtained by the current monitoring and the power consumption obtained by the last monitoring as the power consumption of the software to be detected in one period, and obtaining the real-time power of the software to be detected according to the power consumption of the software to be detected in one period and the time length of one period.
And step C2, judging whether the real-time electric quantity is within a preset reference electric quantity range, and if not, taking the real-time electric quantity, the current time and the event to be detected of the software to be detected running at the current time as an electric quantity use abnormal event record.
The preset reference electric quantity range in the event to be detected can be obtained according to the operation instruction corresponding to the event to be detected. The reference flow range can also be set to [0.9b,1.1b ], wherein b is the average value of the real-time electric quantity consumed by the software to be tested in the process of running the running event to be tested; or b is an empirical value of the preset setting.
Optionally, the step 103 may specifically include a step D1 and a step D2, where the recording of the corresponding run crash event:
step D1, judging whether a crash event of the crash and the operation code of the crash occurs in the process of operating the event to be tested by the software to be tested is recorded in a system log, if so, executing step D2, and if not, executing step D1;
and D2, recording the crash event as an operation crash event.
The system of the terminal device generates a system log in real time during the running process of the software, so that if the software to be tested crashes during the running process of the event to be tested, a crash event (such as time of occurrence of crash, running code, etc.) is necessarily generated in the system log. The crash event mainly refers to the condition that the software to be tested does not conform to the normal operation of the software to be tested, such as no response, stop operation, automatic exit and the like.
Preferably, in the process of running the event to be tested by the software to be tested, generating a change curve graph of the real-time electric quantity changing along with time according to the dynamically monitored real-time electric quantity; and/or generating a change curve graph of the real-time flow changing along with time according to the dynamically monitored real-time flow in the process of running the event to be detected by the software to be detected; therefore, the use condition of the electric quantity and/or the flow of the software to be tested in the process of running the event to be tested can be more intuitively and quickly known by a person skilled in the art.
In summary, the aforementioned step 103 may include at least one set of the following steps: group 1 (step a 1-step a2), group 2 (step B1-step B2), group 3 (step C1-step C2), group 4 (step D1-step D2).
Fig. 3 is a schematic structural diagram of an automated software inspection apparatus according to an embodiment of the present invention, and as shown in fig. 3, the apparatus according to the embodiment of the present invention includes:
the to-be-tested event generating module 11 is configured to generate a to-be-tested event according to a pre-edited logic script corresponding to the to-be-tested software;
the control module 12 is used for controlling the to-be-tested software to automatically run the to-be-tested event;
and the monitoring module 13 is configured to monitor real-time data generated by the to-be-tested software in the process of running the to-be-tested event, and determine and record an event that the to-be-tested software is abnormal according to the real-time data.
Preferably, the event to be detected generation module 11 is specifically configured to: analyzing a logic script which is edited in advance and corresponds to the software to be tested to obtain an operation instruction for operating the software to be tested and an operation rule of the operation instruction; and generating an event to be tested according to the operation instruction and a preset operation rule, wherein the event to be tested indicates the software to be tested to execute a corresponding operation instruction on the software to be tested according to the operation rule.
Preferably, in one embodiment, the monitoring module 13 comprises:
the memory monitoring unit is used for dynamically monitoring the conditions of applying and releasing the memory block in the process of operating the to-be-detected event by the to-be-detected software, adding one to the number of users of the memory block when applying for the memory block, and subtracting one from the number of users of the memory block when releasing the memory block;
and the memory leak event recording unit is used for judging whether the memory block has no pointer direction and the number of users is larger than zero, and if so, taking the operation code corresponding to the pointer distributed when the memory block is applied and the memory block as the memory leak event record.
Preferably, in one embodiment, the monitoring module 13 comprises:
the flow monitoring unit is used for dynamically monitoring and recording the real-time flow consumed by the software to be tested in the process of running the event to be tested, and the real-time flow is the flow consumed in unit time;
and the flow use abnormal event recording unit is used for judging whether the real-time flow is within a preset reference flow range, and if not, taking the real-time flow, the current time and a to-be-detected event of the to-be-detected software running at the current time as a flow use abnormal event record.
Preferably, in a further embodiment, the monitoring module 13 comprises:
the electric quantity monitoring unit is used for dynamically monitoring and recording the real-time electric quantity consumed by the software to be tested in the process of running the event to be tested, and the real-time electric quantity is the electric quantity consumed in unit time;
and the electric quantity use abnormal event recording unit is used for judging whether the real-time electric quantity is within a preset reference electric quantity range or not, and if not, taking the real-time electric quantity, the current time and the to-be-detected event of the to-be-detected software running at the current time as an electric quantity use abnormal event record.
In a last embodiment, the monitoring module 13 comprises:
the crash event monitoring unit is used for judging whether crash events of the to-be-tested software and the operation codes which are subjected to crash occur in the process of operating the to-be-tested event are recorded or not, and if yes, the crash event recording unit is triggered to operate;
and the operation crash event recording unit is used for recording the crash event as an operation crash event.
It should be noted that, a developer may analyze the problem of the software to be tested according to the recorded event that the software to be tested is abnormal, and perform corresponding processing for the problem. If the event that the software to be tested is abnormal is a memory leakage event, modifying and perfecting the running code recorded in the memory leakage event; if the event that the software to be tested is abnormal is a crash event, modifying and perfecting the running code recorded in the crash event; if the event that the software to be detected is abnormal in flow use, detecting the code corresponding to the event to be detected recorded in the abnormal event in flow use, and if the code has a problem, modifying the code; if the event that the software to be detected is abnormal in electricity consumption, detecting the code corresponding to the event to be detected recorded in the abnormal event in electricity consumption, and if the code has a problem, modifying the code.
In summary, in the present embodiment, the detection module 13 at least includes the following units: group 1 (memory monitoring unit and memory leakage event recording unit), group 2 (flow monitoring unit and flow use abnormal event recording unit), group 3 (electric quantity monitoring unit and electric quantity use abnormal event recording unit), and group 4 (crash event monitoring unit and operation crash event recording unit).
Obviously, the automatic software detection method provided by the embodiment of the invention is suitable for terminal devices of various operating systems, such as mac, Android, iOS, Linux, Windows, and the like.
Those of skill would further appreciate that the various illustrative components and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both, and that the various illustrative components and steps have been described above generally in terms of their functionality in order to clearly illustrate this interchangeability of hardware and software. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.
The steps of a method or algorithm described in connection with the embodiments disclosed herein may be embodied in hardware, a software module executed by a processor, or a combination of the two. A software module may reside in Random Access Memory (RAM), memory, Read Only Memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.
The above-mentioned embodiments are intended to illustrate the objects, technical solutions and advantages of the present invention in further detail, and it should be understood that the above-mentioned embodiments are merely exemplary embodiments of the present invention, and are not intended to limit the scope of the present invention, and any modifications, equivalent substitutions, improvements and the like made within the spirit and principle of the present invention should be included in the scope of the present invention.
Claims (10)
1. An automated software inspection method, the method comprising:
generating an event to be tested according to a logic script which is edited in advance and corresponds to the software to be tested;
controlling the software to be tested to automatically run the event to be tested;
monitoring real-time data generated by the software to be tested in the process of running the event to be tested, and determining and recording the abnormal event of the software to be tested according to the real-time data;
the generating of the event to be tested according to the pre-edited logic script corresponding to the software to be tested specifically includes:
analyzing a logic script which is edited in advance and corresponds to the software to be tested to obtain an operation instruction for operating the software to be tested and an operation rule of the operation instruction; the operation rule comprises at least one of the execution time, the execution mode, the execution sequence and the execution proportion of the operation instruction;
and generating an event to be tested according to the operation instruction and a preset operation rule, wherein the event to be tested indicates the software to be tested to execute a corresponding operation instruction on the software to be tested according to the operation rule.
2. The method according to claim 1, wherein the monitoring of real-time data generated by the software to be tested during the running of the event to be tested, and the determining and recording of the abnormal event of the software to be tested according to the real-time data specifically comprises:
dynamically monitoring the conditions of applying and releasing the memory block by the software to be tested in the process of running the event to be tested, adding one to the number of users of the memory block when applying for the memory block, and subtracting one from the number of users of the memory block when releasing the memory block; and
and judging whether the memory block has no pointer pointing and the number of users is larger than zero, if so, taking the operation code corresponding to the pointer distributed when the memory block is applied and the memory block as a memory leakage event record.
3. The method according to claim 1, wherein the monitoring real-time data generated by the software to be tested during the running of the event to be tested, and determining and recording an event that the software to be tested is abnormal according to the real-time data specifically comprises:
dynamically monitoring and recording the real-time flow consumed by the software to be tested in the process of running the event to be tested, wherein the real-time flow is the flow consumed in unit time; and the number of the first and second groups,
and judging whether the real-time flow is within a preset reference flow range, and if not, taking the real-time flow, the current time and a to-be-detected event of the to-be-detected software running at the current time as a flow use abnormal event record.
4. The method according to claim 1, wherein the monitoring of real-time data generated by the software to be tested during the running of the event to be tested, and the determining and recording of the abnormal event of the software to be tested according to the real-time data specifically comprises:
dynamically monitoring and recording the real-time electric quantity consumed by the software to be tested in the process of running the event to be tested, wherein the real-time electric quantity is the electric quantity consumed in unit time; and
and judging whether the real-time electric quantity is within a preset reference electric quantity range, and if not, taking the real-time electric quantity, the current time and a to-be-detected event of the to-be-detected software running at the current time as an electric quantity use abnormal event record.
5. The method according to claim 1, wherein the monitoring of real-time data generated by the software to be tested during the running of the event to be tested, and the determining and recording of the abnormal event of the software to be tested according to the real-time data specifically comprises:
judging whether a crash event of the to-be-tested software and the operation code which is crashed in the process of operating the to-be-tested event is recorded in a system log, and if so, taking the crash event as an operation crash event record.
6. An automated software detection apparatus, the apparatus comprising:
the to-be-tested event generation module is used for generating to-be-tested events according to the pre-edited logic script corresponding to the to-be-tested software;
the control module is used for controlling the to-be-tested software to automatically run the to-be-tested event;
the monitoring module is used for monitoring real-time data generated by the software to be tested in the process of running the event to be tested, and determining and recording the abnormal event of the software to be tested according to the real-time data;
the event generation module to be tested is specifically configured to:
analyzing a logic script which is edited in advance and corresponds to the software to be tested to obtain an operation instruction for operating the software to be tested and an operation rule of the operation instruction; the operation rule comprises at least one of the execution time, the execution mode, the execution sequence and the execution proportion of the operation instruction;
and generating an event to be tested according to the operation instruction and a preset operation rule, wherein the event to be tested indicates the software to be tested to execute a corresponding operation instruction on the software to be tested according to the operation rule.
7. The apparatus of claim 6, wherein the monitoring module comprises:
the memory monitoring unit is used for dynamically monitoring the conditions of applying and releasing the memory block in the process of operating the to-be-detected event by the to-be-detected software, adding one to the number of users of the memory block when applying for the memory block, and subtracting one from the number of users of the memory block when releasing the memory block;
and the memory leak event recording unit is used for judging whether the memory block has no pointer direction and the number of users is larger than zero, and if so, taking the operation code corresponding to the pointer distributed when the memory block is applied and the memory block as the memory leak event record.
8. The apparatus of claim 6, wherein the monitoring module comprises:
the flow monitoring unit is used for dynamically monitoring and recording the real-time flow consumed by the software to be tested in the process of running the event to be tested, and the real-time flow is the flow consumed in unit time;
and the flow use abnormal event recording unit is used for judging whether the real-time flow is within a preset reference flow range, and if not, taking the real-time flow, the current time and a to-be-detected event of the to-be-detected software running at the current time as a flow use abnormal event record.
9. The apparatus of claim 6, wherein the monitoring module comprises:
the electric quantity monitoring unit is used for dynamically monitoring and recording the real-time electric quantity consumed by the software to be tested in the process of running the event to be tested, and the real-time electric quantity is the electric quantity consumed in unit time;
and the electric quantity use abnormal event recording unit is used for judging whether the real-time electric quantity is within a preset reference electric quantity range, and if not, taking the real-time electric quantity, the current time and the to-be-detected event of the to-be-detected software running at the current time as an electric quantity use abnormal event record.
10. The apparatus of claim 6, wherein the monitoring module comprises:
the crash event monitoring unit is used for judging whether crash events of the to-be-tested software and the operation codes which are subjected to crash occur in the process of operating the to-be-tested event are recorded or not, and if yes, the crash event recording unit is triggered to operate;
and the operation crash event recording unit is used for recording the crash event as an operation crash event.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201610214549.XA CN107273283B (en) | 2016-04-07 | 2016-04-07 | Automatic software detection method and device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201610214549.XA CN107273283B (en) | 2016-04-07 | 2016-04-07 | Automatic software detection method and device |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN107273283A CN107273283A (en) | 2017-10-20 |
| CN107273283B true CN107273283B (en) | 2020-10-09 |
Family
ID=60052322
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201610214549.XA Active CN107273283B (en) | 2016-04-07 | 2016-04-07 | Automatic software detection method and device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN107273283B (en) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108459938A (en) * | 2017-12-26 | 2018-08-28 | 海南智媒云图科技股份有限公司 | A kind of method and device that PHP code data monitoring is collected |
| CN108551404B (en) * | 2018-04-20 | 2019-10-01 | 北京百度网讯科技有限公司 | Method, apparatus, storage medium and the terminal device of client-side information analysis |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103530209A (en) * | 2013-09-17 | 2014-01-22 | 福建升腾资讯有限公司 | Automated testing method for code keyboard |
| CN104270630A (en) * | 2014-09-05 | 2015-01-07 | 深圳创维数字技术有限公司 | Terminal testing method and terminal |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7707553B2 (en) * | 2005-12-08 | 2010-04-27 | International Business Machines Corporation | Computer method and system for automatically creating tests for checking software |
| CN101887392A (en) * | 2010-07-06 | 2010-11-17 | 中兴通讯股份有限公司 | Method and device for testing software system operation stability |
| CN104809054B (en) * | 2014-01-23 | 2018-07-24 | 腾讯科技（深圳）有限公司 | Realize the method and system of program test |
-
2016
- 2016-04-07 CN CN201610214549.XA patent/CN107273283B/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103530209A (en) * | 2013-09-17 | 2014-01-22 | 福建升腾资讯有限公司 | Automated testing method for code keyboard |
| CN104270630A (en) * | 2014-09-05 | 2015-01-07 | 深圳创维数字技术有限公司 | Terminal testing method and terminal |
Non-Patent Citations (1)
| Title |
|---|
| 软件完整性自动检测系统的设计与实现;梁红伟;《中国优秀硕士学位论文全文数据库 信息科技辑》;20130315;I138-282 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN107273283A (en) | 2017-10-20 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110968985B (en) | Method and device for determining integrated circuit repair algorithm, storage medium and electronic equipment | |
| CN108829580B (en) | Multi-version test data processing method, device, equipment and storage medium | |
| EP2996366B1 (en) | Application recommendation method, system and server | |
| CN107506300B (en) | User interface testing method, device, server and storage medium | |
| CN103109276B (en) | System detection method | |
| CN107066390B (en) | Dynamic memory leak detection method and system | |
| CN103838663A (en) | Application testing method and device | |
| CN102402479B (en) | For the intermediate representation structure of static analysis | |
| CN105302714A (en) | Method and apparatus for monitoring memory leak in test process | |
| CN110059939A (en) | A kind of risk checking method and device | |
| CN113032215A (en) | Thread snapshot analysis method, device, equipment and storage medium | |
| CN107977318B (en) | Energy consumption and performance test method for Android application program | |
| CN106998336B (en) | Method and device for detecting user in channel | |
| CN112445686A (en) | Memory leak detection method, device and computer-readable storage medium | |
| CN107273283B (en) | Automatic software detection method and device | |
| CN111796578A (en) | Vehicle controller testing method, device and system and storage medium | |
| CN111966603A (en) | Memory leak detection method and device, readable storage medium and electronic equipment | |
| CN115686961A (en) | Processor testing method and device and electronic equipment | |
| CN104809054A (en) | Method and system for realizing program testing | |
| CN107544902B (en) | Program testing method, device and equipment | |
| CN109491702B (en) | Optimization scheme determination method and device, terminal equipment and storage medium | |
| US9824005B1 (en) | Process level memory allocation by memory type | |
| CN110941549B (en) | Memory leak detection method, device, medium and electronic equipment | |
| CN115576737B (en) | Abnormality detection method, abnormality detection device, electronic device, and storage medium | |
| CN112269591A (en) | Version release method, device, equipment and storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| TA01 | Transfer of patent application right | ||
| TA01 | Transfer of patent application right |
Effective date of registration: 20200422 Address after: 310051 room 508, floor 5, building 4, No. 699, Wangshang Road, Changhe street, Binjiang District, Hangzhou City, Zhejiang Province Applicant after: Alibaba (China) Co.,Ltd. Address before: Daheng Technology Building No. three Beijing 100080 Haidian District Suzhou Street 16 layer 2. Applicant before: AUTONAVI INFORMATION TECHNOLOGY Co.,Ltd. |
|
| GR01 | Patent grant | ||
| GR01 | Patent grant |