CN116048951A

CN116048951A - Method and device for reproducing software problem, electronic equipment and storage medium

Info

Publication number: CN116048951A
Application number: CN202111266378.2A
Authority: CN
Inventors: 方毓娟
Original assignee: Beijing Xiaomi Mobile Software Co Ltd
Current assignee: Beijing Xiaomi Mobile Software Co Ltd
Priority date: 2021-10-28
Filing date: 2021-10-28
Publication date: 2023-05-02

Abstract

The present disclosure relates to a method of recurrence of software problems, which may include: acquiring related information of a target scene with a software problem, and generating a test case according to the related information; executing the test case and acquiring a test result obtained according to the test case; and if the test result is that the software problem is reproduced, taking the test path corresponding to the test case as a reproduction path. The method and the device can accurately position the software problem which occurs at low probability, and realize effective reproduction of the software problem.

Description

Method and device for reproducing software problem, electronic equipment and storage medium

Technical Field

The disclosure relates to the technical field of testing, and in particular relates to a method and a device for reproducing software problems, electronic equipment and a storage medium.

Background

With the rapid development of the mobile internet, the development period of the mobile terminal is also continuously shortened. In order to ensure that the mobile terminal can be normally used by a user after leaving a factory, strict test needs to be carried out on the mobile terminal, particularly, some low probability problems which are difficult to reproduce are required, and if such low probability problems cannot be found in time in the test process, bad products flow into the market, so that the use experience of the user can be influenced.

Disclosure of Invention

To overcome the problems in the related art, the present disclosure provides a method, an apparatus, an electronic device, and a storage medium for reproducing the software problems.

According to a first aspect of the embodiments of the present disclosure, there is provided a method for reproducing a software problem, including:

acquiring related information of a target scene with a software problem, and generating a test case according to the related information;

executing the test case and acquiring a test result obtained according to the test case;

and if the test result is that the software problem is reproduced, taking the test path corresponding to the test case as a reproduction path.

Optionally, the acquiring the related information of the target scene where the software problem occurs includes:

acquiring a log corresponding to a target scene where the software problem occurs, and extracting key thread information from the log, wherein the log comprises a plurality of thread information;

and if the key thread information meets the preset condition, determining the key thread information as the related information.

Optionally, the extracting the key thread information from the log includes:

detecting a first keyword and a second keyword in the log, wherein the first keyword and the second keyword are both log keywords of a restarting type;

And determining the thread information between the first keyword and the second keyword in the log as key thread information.

Optionally, if the critical thread information meets a preset condition, determining the critical thread information as the related information includes:

and if character strings which are not matched with the regular expression exist in the key thread information, determining the key thread information as the related information.

acquiring module information of at least one problem module matched with the target scene;

and determining module information of the at least one problem module as the related information.

Optionally, the generating the test case according to the related information includes:

and according to the module information, acquiring at least one initial test case corresponding to the problem module from a plurality of preset initial test cases as the test case.

Optionally, the related information further includes key thread information, and the obtaining, according to the module information, at least one initial test case corresponding to the problem module from a plurality of preset initial test cases as the test case includes:

According to the module information, at least one initial test case corresponding to the problem module is obtained from a plurality of preset initial test cases to serve as a first test case;

and acquiring a second test case corresponding to the key thread information from the first test case as the test case according to the key thread information.

acquiring a scene with the software problem as a similar scene, wherein the similar scene and the target scene are different scenes;

and acquiring the reproduction path of the similar scene, and determining the reproduction path of the similar scene as the related information.

Optionally, the acquiring a similar scenario in which the software problem occurs includes:

and acquiring the scene with the software problem from a preset scene database as a similar scene, wherein the scene database is constructed based on a plurality of scene information crawled from a preset project and transaction tracking platform.

Optionally, the method further comprises:

and if the test result is that the software problem is not reproduced, returning to the step of executing the related information of the target scene with the software problem until the test result is that the software problem is reproduced, wherein the related information obtained again comprises a log corresponding to the test result obtained by executing the test case each time before.

Optionally, the method further comprises:

performing reproduction operation for the software problem for designated times through the reproduction path, and recording the times of successfully reproducing the software problem;

and if the ratio of the times to the designated times is smaller than a ratio threshold value, returning to execute the step of acquiring the related information of the target scene with the software problem until the test result is the reproduction of the software problem, wherein the acquired related information again comprises a log corresponding to the test result obtained by executing the test case each time before.

Optionally, the method further comprises:

generating test prompt information according to the test case, and sending the test prompt information, wherein the test prompt information is used for prompting a tester to test the software problem through the test case.

Optionally, before the obtaining the related information of the target scene with the software problem and generating the test case according to the related information, the method further includes:

receiving an initial software problem uploaded by a user and a label of the initial software problem;

if the tag is a low probability problem tag, the initial software problem is determined to be the software problem.

According to a second aspect of the embodiments of the present disclosure, there is provided a reproduction apparatus of a software problem, including: test case generation module, test module and reproduction path determination module, wherein:

the test case generation module is configured to acquire related information of a target scene where the software problem occurs and generate a test case according to the related information;

the test module is configured to execute the test case and acquire a test result obtained according to the test case;

and the reproduction path determining module is configured to take the test path corresponding to the test case as a reproduction path when the test result is the software problem reproduction.

According to a third aspect of embodiments of the present disclosure, there is provided an electronic device comprising:

a processor;

a memory for storing processor-executable instructions;

wherein the processor is configured to:

and when the test result is that the software problem is repeated, taking the test path corresponding to the test case as a reproduction path.

According to a fourth aspect of embodiments of the present disclosure, there is provided a computer readable storage medium having stored thereon computer program instructions which, when executed by a processor, implement the steps of the method for reproducing the software problem provided by the first aspect of the present disclosure.

The technical scheme provided by the embodiment of the disclosure can comprise the following beneficial effects: the method comprises the steps of obtaining relevant information of a target scene with a software problem, generating a test case according to the relevant information, generating the test case by taking the relevant information of the target scene with the software problem as a clue, tracing the source of the software problem, executing the test case, obtaining a test result obtained according to the test case, and finally if the test result is that the software problem is reproduced, indicating that a test path corresponding to the test case can cause the software problem, taking the test path corresponding to the test case as a reproduction path, namely accurately positioning the software problem, and effectively reproducing the software problem.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the disclosure and together with the description, serve to explain the principles of the disclosure.

FIG. 1 is a flow chart illustrating a method of recurrence of a software problem according to an exemplary embodiment.

Fig. 2 is a flow chart illustrating a method of recurrence of a software problem according to another exemplary embodiment.

Fig. 3 is a flowchart of step S201 of a method for reproducing a software problem according to the embodiment of fig. 2.

Fig. 4 is a flowchart of step S201 of another method for reproducing a software problem according to the embodiment of fig. 2.

Fig. 5 is a flowchart of step S201 of a method for reproducing a further software problem according to the embodiment of fig. 2.

FIG. 6 is a flowchart illustrating the operation of the test system according to the embodiment of FIG. 2.

Fig. 7 is a flowchart illustrating a method of reproducing a software problem according to still another exemplary embodiment.

Fig. 8 is a block diagram illustrating a software problem reproduction apparatus according to an exemplary embodiment.

Fig. 9 is a block diagram of an apparatus according to an example embodiment.

Fig. 10 is a block diagram of an apparatus according to another example embodiment.

Detailed Description

Reference will now be made in detail to exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, the same numbers in different drawings refer to the same or similar elements, unless otherwise indicated. The implementations described in the following exemplary examples are not representative of all implementations consistent with the present disclosure. Rather, they are merely examples of apparatus and methods consistent with some aspects of the present disclosure as detailed in the accompanying claims.

In the software development process, an indispensable part of the software test is that a software tester unintentionally or intentionally finds a BUG (fault problem) in the test process and feeds back to a developer, so that the process of the tester for finding the BUG in the test is required to be written out in detail as much as possible in order to avoid the time wasted by the developer in unconscious searching for the BUG, and then the developer is required to find the BUG found by the tester according to the process to confirm whether the BUG is the BUG or not, which is helpful for the developer to modify the BUG in the shortest time, and the process is called to reproduce the BUG.

However, the probability of occurrence of some software problems is low, and the problems may not occur after the system is initialized, so that it is difficult for a tester to select a suitable test path to reproduce the problems, and the difficulty of reproducing the problems is increased.

In the related art, when the low probability problem is repeated, a tester usually selects test conditions from a plurality of test strips one by one according to own experience to test, however, the test mode is limited by experience, knowledge and the like of a technician, the positioning accuracy of the low probability problem cannot be ensured, the test process is complicated, careless mistakes are easy to occur, the test efficiency is low, and the low probability problem is difficult to effectively repeat.

In view of the foregoing, embodiments of the present disclosure provide a method, an apparatus, an electronic device, and a storage medium for reproducing a software problem, which can accurately locate a software problem that occurs with low probability, and implement effective reproduction of the software problem.

FIG. 1 is a flow chart of a method of replication of a software problem, as shown in FIG. 1, that may be used in an electronic device, according to an exemplary embodiment, comprising the steps of:

in step S101, related information of a target scene in which a software problem occurs is acquired, and a test case is generated according to the related information.

In some embodiments, the electronic device may be a server, which may receive fault information of a software problem occurring in a target scenario uploaded by a user through the mobile terminal, and then extract relevant information of the target scenario in which the software problem occurs from the fault information.

For example, when a user is dead during a call using the mobile terminal, after the mobile terminal is restarted, the user may fill in a software problem that the target scene is "call" and appears as "dead" on a fault form provided by the mobile terminal, and upload information such as the filled-in fault form and a log generated by the mobile terminal in a time period when the dead occurs as fault information to the server. The server can determine the target scene of the mobile terminal according to the fault information, and can determine the log in the fault information as the related information of the target scene. Alternatively, the server may also use the module information of the module corresponding to the module matching the target scene as the related information, for example, the scene of making a call corresponds to the communication module in advance, and then the server may determine the module information of the communication module as the related information. Optionally, the server may also determine information of other scenes in which the same software problem occurs as related information, for example, if the mobile terminal is crashed in a scene of sending a short message, the server may determine that the mobile terminal is crashed in a scene of sending a short message as similar BUG, and determine a history of crashing in a scene of sending a short message obtained previously as related information.

It should be understood that, in addition to the logs, modules, and similar BUGs mentioned above, the related information of the target scenario may further include other information related to the target scenario, such as information of an operation record commonly used in the target scenario, a network state recorded in the target scenario, and the like, which is not limited herein.

After the server obtains the relevant information of the target scene, a test case can be generated according to the relevant information. For example, the server may formulate the content of the test task according to the related information, so as to obtain the test case, where the content of the test task may include: test targets, test environments, input data, test steps, expected results, test scripts, etc. Optionally, the server may determine a test script in the test case according to the log in the related information, and so on; the test targets and the like in the test cases can also be determined according to the module information in the related information, for example, the module corresponding to the module information is determined as the test target; and the test environment, the test steps and the like can be determined according to the history record of the similar BUG, if the appearance scene of the similar BUG is a short message sending scene, the test environment in the test case can be configured as the short message sending environment, and the test steps are configured as operation steps possibly involved in sending the short message. The test contents except the input data and the expected result can be regarded as execution conditions, and the input data, the execution conditions and the expected result can form a complete test path.

It can be understood that the more abundant the content of the related information is, the smaller the test range is, and the more accurate the test is.

In step S102, a test case is executed, and a test result obtained according to the test case is obtained.

In some embodiments, the server may send the test case to the mobile terminal to instruct the mobile terminal to automatically execute the test case. After receiving the test case, the mobile terminal can execute the test case by running a test path corresponding to the test case, and obtain a test result after the running is completed, wherein the test result comprises software problem reproduction or software problem non-reproduction.

Wherein the mobile terminal can be connected with the server through a universal serial bus (Universal Serial Bus, USB)

In step S103, if the test result is a software problem reproduction, the test path corresponding to the test case is taken as a reproduction path.

In some embodiments, the mobile terminal may feed back the test result to the server, and when the server detects that the test result is a software problem replication, the server may use a test path corresponding to the test case as a replication path, so as to complete positioning and replication of the software problem.

In some embodiments, the electronic device for executing the method for reproducing the software problem may also be the mobile terminal itself, and the mobile terminal may automatically generate a test case according to the obtained related information of the target scenario, and operate a test path corresponding to the test case, and if the software problem is reproduced, use the test path corresponding to the test case as the reproduction path. Optionally, one test case may correspond to at least one test path, and if each test path in the at least one test path corresponding to the test case can reproduce the software problem, each test path corresponding to the test case may be used as a reproduction path. For example, when the test case d is executed, whether the three test paths can reproduce the software problem may be sequentially tested, and if the test paths 2 and 3 can reproduce the software problem, the test paths 2 and 3 are determined as reproduction paths. The test case may include a corresponding test path. Optionally, the mobile terminal includes, but is not limited to: smart phones, personal computers, tablet computers, smart wearable devices, etc.

In this embodiment, by acquiring relevant information of a target scenario in which a software problem occurs, generating a test case according to the relevant information, executing the test case, and acquiring a test result obtained according to the test case, if the test result is that the software problem is reproduced, finally, if the test result is that a test path corresponding to the test case causes the software problem, the test path corresponding to the test case can be used as a reproduction path, that is, the software problem can be accurately located, and effective reproduction of the software problem is achieved. Therefore, the related information of the target scene of the software problem can be used as clues to generate the test case so as to trace the source of the software problem, the problem that a tester blindly configures test conditions to test the software problem and spends a great deal of useless time and manpower is avoided, the reliability of a strategy is improved, the research and development can be responded quickly, and the problem is solved quickly; the inaccurate positioning of the software problem caused by omission of a tester is avoided, and the testing efficiency and the reproduction accuracy of the software problem are improved; in addition, in the aspect of processing the user feedback problem, the workload of the revisiting user can be effectively reduced.

Fig. 2 is a flowchart illustrating a method of reproducing a software problem according to another exemplary embodiment, and as shown in fig. 2, the method of reproducing a software problem may be used in an electronic device, which may be a server, and the method may include the steps of:

in step S201, related information of a target scene in which a software problem occurs is acquired, and a test case is generated according to the related information.

In some embodiments, as shown in fig. 3, the following steps may be included in step S201:

in step S2011A, a log corresponding to a target scenario where a software problem occurs is obtained, and key thread information is extracted from the log, where the log includes a plurality of thread information.

The log corresponding to the target scene with the software problem is a record for describing the process and experience of the mobile terminal with the software problem in detail. The log may be uploaded to the server by the user through the mobile terminal or automatically by the mobile terminal.

As an embodiment, a specific embodiment of step S2011A may include: and detecting a first keyword and a second keyword in the log, wherein the first keyword and the second keyword are both restart type log keywords. Then, thread information located between the first keyword and the second keyword in the log is determined as key thread information.

Illustratively, after obtaining the log, the server may view 284log of the log, decompress 284log, and view buserelt. Then, a regular expression of python (computer programming language) can be used to match the first keyword "WATCHDOG" and return the line number l1 where the first keyword is located, and match the second keyword "GOODBYE" and return the line number l2 where the second keyword is located. Finally, the thread information between the line number l1 and the line number l2 in the log can be determined as the key thread information.

In step S2012A, if the critical thread information satisfies the preset condition, the critical thread information is determined as related information.

As an embodiment, a specific embodiment of step S2012A may include: if character strings which are not matched with the regular expression exist in the key thread information, the key thread information is determined to be related information.

By adopting the above example, the server can perform regular expression matching on all character strings between the line number l1 and the line number l2 in the log, if character strings which are not matched with the regular expression exist in all character strings between the line number l1 and the line number l2 in the log, a process name similar to com.

In this embodiment, by acquiring the log corresponding to the target scenario in which the software problem occurs, and extracting the critical thread information from the log, if the critical thread information meets the preset condition, the critical thread information is determined to be related information, so that the software problem occurring in the target scenario can be accurately located in the log.

In other embodiments, as shown in fig. 4, the following steps may be included in step S201:

in step S2011B, the scenes with the software problems are obtained as similar scenes, and the similar scenes and the target scenes are different scenes.

As one way, a database may be configured in the server, where a history of different software problems occurring in different scenarios may be pre-stored, for example, where each software problem in the database is associated with at least one occurring scenario. For example, the database stores a history of the occurrence of a crash in a scene of sending a short message, a history of the occurrence of a crash in a scene of receiving a video phone in a micro message, a history of the occurrence of no response in a scene of opening a split screen of an Android application package (Android application package, APK), a history of the occurrence of a flash back in a scene of using a setting interface, and the like. The server can search the scenes with the software problems from the database according to the software problems as similar scenes. For example, if the problem of dead halt also occurs in the scene of sending the short message, the scene of sending the short message can be determined as a similar scene.

As another way, in step S2011B, a specific embodiment of acquiring a scene in which a software problem has occurred as a similar scene may include:

and acquiring a scene with the software problem from a preset scene database as a similar scene, wherein the scene database is constructed based on a plurality of scene information crawled from a preset project and transaction tracking platform.

Illustratively, the server can match similar scenarios with the same BUG (software problem) by automatically invoking the BUG management platform interface. For example: the method comprises the steps of making a call and crashing, wherein the scenes such as sending a short message and the like are matched with the defect that the crash problem exists, and the scenes with the similar scenes and the crashing of the short message are obtained. For example, the server may extract the BUG information from the jira platform (project and transaction tracking platform). Specifically, a python third party jira library is utilized to connect to a remote jira server; then simulating to log in a Jira platform; and then, crawling the information such as the titles of all jira and jira id in the platform by using the python crawler, and classifying the information into separate tables to obtain crawling data. Then, connecting a Mysql database by calling a Python DB-API interface, creating a database table, and then inserting crawling data into the database; then opening database connection, executing get_datasset method to inquire the BUG appearing in the input target scene, and searching out the information of similar scene which appears in the BUG; and finally, closing the connection of the database and outputting similar scenes.

In step S2012B, the reproduction path of the similar scene is acquired, and the reproduction path of the similar scene is determined as the related information.

The database of the server also stores a first mapping relation table between the plurality of scenes and the plurality of reproduction paths, and each scene in the plurality of scenes corresponds to at least one reproduction path in the first mapping relation table. The reproduction paths are verified test paths capable of reproducing the corresponding BUG scenes, and after determining similar scenes, the server can find the reproduction paths corresponding to the similar scenes from the first mapping relation table and determine the reproduction paths of the similar scenes as relevant information. Wherein the number of similar scenes may be one or more.

Considering that the software problems occurring in the target scene and the similar scene are the same, the reasons for the occurrence of the problems may be associated, in this embodiment, the scene in which the software problems occur is obtained as the similar scene, the similar scene and the target scene are different scenes, the reproduction path of the similar scene is obtained again, and the reproduction path of the similar scene is determined as the relevant information, so that the software problem piece can be tested in combination with the reproduction path of the similar scene, the content of the relevant information is enriched, and the accuracy of reproducing the software problems is improved.

In still other embodiments, as shown in fig. 5, the following steps may be included in step S201:

and step S2011C, acquiring module information of at least one problem module matched with the target scene.

Illustratively, a second mapping relation table between the multiple scenes and the multiple modules is also stored in the database of the server, and after the target scene is determined, the server can find at least one problem model matched with the similar scene from the second mapping relation table. Optionally, the module information of the problem module may include information such as identification, description, etc. of the problem module.

The server may also illustratively match the problem module from the log, e.g., see the critical thread on the stack for binder communication, and the interface for communication is IVold, so it may be presumed that the failure problem is caused by a blockage during communication with vold, and further match the problem module to be an external storage module.

In step S2012C, the module information of at least one problem module is determined as related information.

In this embodiment, by acquiring the module information of at least one problem module matched with the target scene and determining the module information of at least one problem module as the related information, the content of the related information for generating the test case can be further enriched, which is equivalent to narrowing the test range, and further improving the accuracy of reproducing the software problem.

In still other embodiments, the server may combine the module information of the problem module, the reproduction path of the similar scenario, and the log obtained in the foregoing embodiments to generate relevant information, and generate a test case according to the relevant information.

As shown in fig. 6, the server may be configured with a test system, where the test system includes a main module, a thread module, and an interaction module, where the main module may be configured to obtain module information of at least one problem module matched with a target scene, the thread module may be configured to extract, from a log, thread information that does not meet a preset condition, and the interaction module may be configured to obtain a reproduction path corresponding to a similar scene. In practical application, the test system acquires data through the three modules in a data importing stage, generates test cases according to the acquired data in a test strategy analysis stage, and tests the software problems in a test execution stage in an automatic test mode or a non-automatic test mode, wherein the automatic test can connect the mobile terminal with a server computer, the server computer tests the mobile terminal, and the non-automatic test can send the test cases to a tester in an email mode through the server to instruct the tester to test.

In some embodiments, in step S201, a specific embodiment of generating a test case according to the related information may include: and according to the module information, acquiring at least one initial test case corresponding to the problem module from a plurality of preset initial test cases as a test case.

Optionally, the related information further includes key thread information, where, according to the module information, obtaining, from a plurality of preset initial test cases, at least one initial test case corresponding to the problem module as a specific implementation manner of the test case may be: according to the module information, at least one initial test case corresponding to the problem module is obtained from a plurality of preset initial test cases to serve as a first test case; and acquiring a second test case corresponding to the key thread information from the first test case as a test case according to the key thread information.

For example, a plurality of initial test cases, such as initial test case 1, initial test case 2, initial test case 3, and initial test case 4, are preset, where the problem module a corresponds to the initial test case 1, the initial test case 2, and the initial test case 3 in advance, and the thread information a corresponds to the initial test case 2, the initial test case 3, and the initial test case 4. If the currently obtained module information is the module information of the problem module and the currently obtained key thread information is the thread information a, the initial test case 2 and the initial test case 3 can be determined to be test cases.

In another example, on the basis of the above example, if the initial test case corresponding in advance to the reproduction path a of the currently obtained similar scene is the initial test case 2 and the initial test case 4, the initial test case 2 may be determined to be the test case.

In step S202, a test case is executed, and a test result obtained according to the test case is obtained.

In step S203, it is determined whether the test result is a software problem recurrence.

In step S204, if the test result is a software problem reproduction, the test path corresponding to the test case is taken as a reproduction path.

In step S205, if the test result is that the software problem is not reproduced, the step of executing the obtaining the related information of the target scenario where the software problem occurs is returned until the test result is that the software problem is reproduced, where the related information obtained again includes a log corresponding to the test result obtained by executing the test case each time before.

For example, if the server detects that the execution of the test case generated by the nth test is completed and the software problem is not repeated, the method may return to step S201 to reacquire the relevant information of the target scenario in which the software problem occurs, obtain relevant information required by the (n+1) th test, and add the log corresponding to the test result of the nth test to the relevant information required by the (n+1) th test, thereby obtaining new relevant information. The log corresponding to the test result of the nth test is a log generated in the process of executing the test case of the nth test, and n is a positive integer.

And then, the server executes the steps S202 to S203 according to the new related information, if the test result is that the software problem is not reproduced, the n+2th test is executed through the test mode, and if the test result is that the software problem is reproduced, the test path corresponding to the test case is taken as a reproduction path, and the test is stopped.

In this embodiment, if the test result is that the software problem is not reproduced, the step of obtaining the relevant information of the target scene where the software problem occurs is performed back until the test result is that the software problem is reproduced, where the relevant information obtained again includes a log corresponding to the test result obtained by executing the test case each time before, so that automatic test on the software problem can be implemented until the software problem is reproduced, and the data used for the next test can be enriched by learning the test result each time, so that accuracy of the software problem is continuously reproduced, and further efficiency of the test is improved.

In some embodiments, after step S205, the method for reproducing a software problem may further include: step S206 and step S207.

In step S206, the software problem is subjected to the reproduction operation for a specified number of times through the reproduction path, and the number of times of successfully reproducing the software problem is recorded.

Illustratively, for example, the designated number of times is i, and the number of times of successfully reproducing the software problem after the server performs i times of reproduction operations on the software problem through the reproduction path is k times.

In step S207, if the ratio of the number of times to the specified number of times is smaller than the ratio threshold, the step of executing the obtaining of the related information of the target scene where the software problem occurs is returned until the test result is a recurrence of the software problem, where the related information obtained again includes a log corresponding to the test result obtained by executing the test case each time before.

With the above example, for example, the ratio threshold is j, if the server detects that i/k is less than j, which indicates that the reproduction path cannot stably reproduce the software problem, and the test needs to be performed again, the process returns to step S201 to step S207.

In this embodiment, if the ratio of the number of times to the designated number of times is smaller than the ratio threshold, the step of acquiring the relevant information of the target scene where the software problem occurs is returned until the test result is that the software problem is reproduced, so that it can be ensured that the obtained reproduction path can stably reproduce the software problem.

Fig. 7 is a flowchart illustrating a method of reproducing a software problem, which may be used in an electronic device, as shown in fig. 7, according to still another exemplary embodiment, including the following steps.

In step S301, an initial software problem uploaded by a user and a tag of the initial software problem are received.

In an exemplary process of using the mobile terminal, if an initial software problem occurs in a target scene, the user can manually configure a label for the initial software problem, and if the user considers that the occurrence probability of the initial software problem is low, the user can configure a low-probability problem label for the initial software problem so as to indicate that the initial software problem is not easy to reproduce. The user may then upload the initial software problem and the tag of the initial software problem to the server via the mobile terminal.

In step S302, if the tag is a low probability problem tag, it is determined that the initial software problem is a software problem.

For example, if the server detects that the tag of the initial software problem is a low probability problem tag, the initial software problem may be determined to be a software problem. Alternatively, if the server detects that the tag of the initial software problem is not a low probability problem tag, it indicates that the initial software problem is not a low probability problem and may not be processed.

In step S303, related information of a target scene in which a software problem occurs is acquired, and a test case is generated according to the related information.

In step S304, a test case is executed, and a test result obtained according to the test case is obtained.

In step S305, if the test result is a software problem reproduction, the test path corresponding to the test case is taken as the reproduction path.

In step S306, test prompt information is generated according to the test case, and the test prompt information is sent out, where the test prompt information is used to prompt a tester to test the software problem through the test case.

Exemplary test cues include, but are not limited to: email, short message, video, audio, etc.

FIG. 8 is a block diagram of a replication device showing a software problem according to an exemplary embodiment. Referring to fig. 8, the software problem reproduction apparatus 400 includes: test case generation module 410, test module 420, and reproduction path determination module 430. Wherein:

the test case generation module 410 is configured to obtain related information of a target scene where a software problem occurs, and generate a test case according to the related information.

The test module 420 is configured to execute a test case and obtain a test result obtained according to the test case.

The reproduction path determining module 430 is configured to take the test path corresponding to the test case as the reproduction path when the test result is the software problem reproduction.

In some implementations, the test case generation module 410 includes:

the log obtaining sub-module is configured to obtain a log corresponding to a target scene with a software problem, extract key thread information from the log, and the log comprises a plurality of thread information.

The first related information determining sub-module is configured to determine the critical thread information as related information when the sub-critical thread information meets a preset condition.

In some embodiments, the log acquisition sub-module includes:

and the keyword detection unit is configured to detect a first keyword and a second keyword in the log, wherein the first keyword and the second keyword are both log keywords of a restarting type.

And a key thread determining unit configured to determine thread information located between the first key and the second key in the log as key thread information.

In some embodiments, the first related information determination submodule is specifically configured to: and when the character strings which are not matched with the regular expression exist in the key thread information, determining the key thread information as related information.

In some implementations, the test case generation module 410 includes:

and the module information acquisition sub-module is configured to acquire module information of at least one problem module matched with the target scene.

And a second related information determination sub-module configured to determine module information of at least one problem module as related information.

In some implementations, the test case generation module 410 includes:

the similar scene acquisition sub-module is configured to acquire a scene with a software problem as a similar scene, wherein the similar scene and the target scene are different scenes.

And a third related information determination sub-module configured to acquire a reproduction path of the similar scene and determine the reproduction path of the similar scene as related information.

In some implementations, the test case generation module 410 further includes:

the test case determination submodule is configured to acquire at least one initial test case corresponding to the problem module from a plurality of preset initial test cases as a test case according to the module information.

In some embodiments, the related information further includes critical thread information, and the test case determination submodule is specifically configured to obtain, according to the module information, at least one initial test case corresponding to the problem module from a plurality of preset initial test cases as a first test case; and acquiring a second test case corresponding to the key thread information from the first test case as a test case according to the key thread information.

In some embodiments, the similar scene acquisition sub-module includes:

the similar scene acquisition unit is configured to acquire a scene with a software problem from a preset scene database as a similar scene, wherein the scene database is constructed based on a plurality of scene information crawled from a preset project and transaction tracking platform.

In some embodiments, the software problem reproduction apparatus 400 further includes:

and the first return module is configured to return to the step of executing the acquisition of the related information of the target scene with the software problem when the test result is that the software problem is not repeated until the test result is that the software problem is repeated, wherein the acquired related information again comprises a log corresponding to the test result obtained by executing the test case each time before.

the number recording module is configured to perform reproduction operation on the software problem for a designated number of times through the reproduction path and record the number of times of successfully reproducing the software problem.

And the second return module is configured to return to the step of executing the related information of the target scene with the software problem when the ratio of the times to the designated times is smaller than the ratio threshold value until the test result is the reproduction of the software problem, wherein the related information acquired again comprises a log corresponding to the test result obtained by executing the test case each time before.

the prompt module is configured to generate test prompt information according to the test cases and send out the test prompt information, wherein the test prompt information is used for prompting a tester to test software problems through the test cases.

and the initial software problem receiving module is configured to receive the initial software problem uploaded by the user and the label of the initial software problem.

And the software problem determining module is configured to determine that the initial software problem is a software problem when the label is a low-probability problem label.

The specific manner in which the various modules perform the operations in the apparatus of the above embodiments have been described in detail in connection with the embodiments of the method, and will not be described in detail herein.

The present disclosure also provides a computer readable storage medium having stored thereon computer program instructions which, when executed by a processor, implement the steps of the method of the present disclosure for the replication of software problems.

Fig. 9 illustrates a block diagram of an apparatus 800 for the recurrence of software problems, according to an exemplary embodiment. For example, apparatus 800 may be a mobile phone, computer, digital broadcast terminal, messaging device, game console, tablet device, medical device, exercise device, personal digital assistant, or the like.

Referring to fig. 9, apparatus 800 may include one or more of the following components: a processing component 802, a memory 804, a power component 806, a multimedia component 808, an audio component 810, an input/output (I/O) interface 812, a sensor component 814, and a communication component 816.

The processing component 802 generally controls overall operation of the apparatus 800, such as operations associated with display, telephone calls, data communications, camera operations, and recording operations. The processing component 802 may include one or more processors 820 to execute instructions to perform all or part of the steps of the methods described above. Further, the processing component 802 can include one or more modules that facilitate interactions between the processing component 802 and other components. For example, the processing component 802 can include a multimedia module to facilitate interaction between the multimedia component 808 and the processing component 802.

The memory 804 is configured to store various types of data to support operations at the apparatus 800. Examples of such data include instructions for any application or method operating on the apparatus 800, a first mapping table, a second mapping table, preset conditions, and the like. The memory 804 may be implemented by any type or combination of volatile or nonvolatile memory devices such as Static Random Access Memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic or optical disk.

The power component 806 provides power to the various components of the device 800. The power components 806 may include a power management system, one or more power sources, and other components associated with generating, managing, and distributing power for the device 800.

The multimedia component 808 includes a screen between the device 800 and the user that provides an output interface. In some embodiments, the screen may include a Liquid Crystal Display (LCD) and a Touch Panel (TP). If the screen includes a touch panel, the screen may be implemented as a touch screen to receive input signals from a user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensor may sense not only the boundary of a touch or slide action, but also the duration and pressure associated with the touch or slide operation. In some embodiments, the multimedia component 808 includes a front camera and/or a rear camera. The front camera and/or the rear camera may receive external multimedia data when the apparatus 800 is in an operational mode, such as a photographing mode or a video mode. Each front camera and rear camera may be a fixed optical lens system or have focal length and optical zoom capabilities.

The audio component 810 is configured to output and/or input audio signals. For example, the audio component 810 includes a Microphone (MIC) configured to receive external audio signals when the device 800 is in an operational mode, such as a call mode, a recording mode, and a voice recognition mode. The received audio signals may be further stored in the memory 804 or transmitted via the communication component 816. In some embodiments, audio component 810 further includes a speaker for outputting audio signals.

The I/O interface 812 provides an interface between the processing component 802 and peripheral interface modules, which may be a keyboard, click wheel, buttons, etc. These buttons may include, but are not limited to: homepage button, volume button, start button, and lock button.

The sensor assembly 814 includes one or more sensors for providing status assessment of various aspects of the apparatus 800. For example, the sensor assembly 814 may detect an on/off state of the device 800, a relative positioning of the components, such as a display and keypad of the device 800, the sensor assembly 814 may also detect a change in position of the device 800 or a component of the device 800, the presence or absence of user contact with the device 800, an orientation or acceleration/deceleration of the device 800, and a change in temperature of the device 800. The sensor assembly 814 may include a proximity sensor configured to detect the presence of nearby objects without any physical contact. The sensor assembly 814 may also include a light sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, the sensor assembly 814 may also include an acceleration sensor, a gyroscopic sensor, a magnetic sensor, a pressure sensor, or a temperature sensor.

The communication component 816 is configured to facilitate communication between the apparatus 800 and other devices, either in a wired or wireless manner. The device 800 may access a wireless network based on a communication standard, such as WiFi,2G or 3G, or a combination thereof. In one exemplary embodiment, the communication component 816 receives broadcast signals or broadcast related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, the communication component 816 further includes a Near Field Communication (NFC) module to facilitate short range communications. For example, the NFC module may be implemented based on Radio Frequency Identification (RFID) technology, infrared data association (IrDA) technology, ultra Wideband (UWB) technology, bluetooth (BT) technology, and other technologies.

In an exemplary embodiment, the apparatus 800 may be implemented by one or more Application Specific Integrated Circuits (ASICs), digital Signal Processors (DSPs), digital Signal Processing Devices (DSPDs), programmable Logic Devices (PLDs), field Programmable Gate Arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic elements for executing the methods described above.

In an exemplary embodiment, a non-transitory computer readable storage medium is also provided, such as memory 804 including instructions executable by processor 820 of apparatus 800 to perform the above-described method. For example, the non-transitory computer readable storage medium may be ROM, random Access Memory (RAM), CD-ROM, magnetic tape, floppy disk, optical data storage device, etc.

In another exemplary embodiment, a computer program product is also provided, comprising a computer program executable by a programmable apparatus, the computer program having code portions for performing a method of recurrence of the software problem described above when executed by the programmable apparatus.

Fig. 10 is a block diagram illustrating an apparatus 1900 for a method of recurrence of software problems, according to an example embodiment. For example, the apparatus 1900 may be provided as a server. Referring to fig. 10, the apparatus 1900 includes a processing component 1922 that further includes one or more processors and memory resources represented by memory 1932 for storing instructions, such as application programs, that are executable by the processing component 1922. The application programs stored in memory 1932 may include one or more modules each corresponding to a set of instructions. Further, processing component 1922 is configured to execute instructions to perform the methods described above.

The apparatus 1900 may further include a power component 1926 configured to perform power management of the apparatus 1900, a wired or wireless network interface 1950 configured to connect the apparatus 1900 to a network, and an input/output (I/O) interface 1958. The apparatus 1900 may operate based on an operating system stored in the memory 1932, such as Windows Server ^TM ，Mac OS X ^TM ，Unix ^TM ，Linux ^TM ，FreeBSD ^TM Or the like.

Other embodiments of the disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the disclosure. This application is intended to cover any adaptations, uses, or adaptations of the disclosure following, in general, the principles of the disclosure and including such departures from the present disclosure as come within known or customary practice within the art to which the disclosure pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the disclosure being indicated by the following claims.

It is to be understood that the present disclosure is not limited to the precise arrangements and instrumentalities shown in the drawings, and that various modifications and changes may be effected without departing from the scope thereof. The scope of the present disclosure is limited only by the appended claims.

Claims

1. A method for reproducing a software problem, comprising:

2. The method of claim 1, wherein the obtaining information about the target scenario in which the software problem occurs comprises:

3. The method of claim 2, wherein the extracting critical thread information from the log comprises:

4. The method according to claim 2, wherein determining the critical thread information as the related information if the critical thread information satisfies a preset condition comprises:

5. The method of claim 1, wherein the obtaining information about the target scenario in which the software problem occurs comprises:

6. The method of claim 5, wherein generating test cases from the relevant information comprises:

7. The method of claim 6, wherein the related information further includes critical thread information, and the obtaining, according to the module information, at least one initial test case corresponding to the problem module from a preset plurality of initial test cases as the test case includes:

8. The method of claim 1, wherein the obtaining information about the target scenario in which the software problem occurs comprises:

9. The method of claim 8, wherein the obtaining similar scenarios in which the software problem occurred comprises:

10. The method according to any one of claims 1-9, further comprising:

11. The method according to any one of claims 1-9, further comprising:

12. The method according to any one of claims 1-9, further comprising:

13. The method according to any one of claims 1 to 9, further comprising, before the acquiring the related information of the target scenario in which the software problem occurs and generating the test case according to the related information:

14. A device for reproducing a software problem, comprising:

15. An electronic device, comprising:

a processor;

a memory for storing processor-executable instructions;

wherein the processor is configured to:

16. A computer readable storage medium having stored thereon computer program instructions, which when executed by a processor, implement the steps of the method of any of claims 1-13.