CN107229558B - Software testing method and device - Google Patents

Software testing method and device Download PDF

Info

Publication number
CN107229558B
CN107229558B CN201610168942.XA CN201610168942A CN107229558B CN 107229558 B CN107229558 B CN 107229558B CN 201610168942 A CN201610168942 A CN 201610168942A CN 107229558 B CN107229558 B CN 107229558B
Authority
CN
China
Prior art keywords
test
program
target program
test point
software testing
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
Application number
CN201610168942.XA
Other languages
Chinese (zh)
Other versions
CN107229558A (en
Inventor
刘俊峰
姚文辉
张海勇
朱家稷
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Alibaba Group Holding Ltd
Original Assignee
Alibaba Group Holding Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Alibaba Group Holding Ltd filed Critical Alibaba Group Holding Ltd
Priority to CN201610168942.XA priority Critical patent/CN107229558B/en
Priority to TW106105130A priority patent/TW201734791A/en
Priority to PCT/CN2017/076399 priority patent/WO2017162058A1/en
Publication of CN107229558A publication Critical patent/CN107229558A/en
Application granted granted Critical
Publication of CN107229558B publication Critical patent/CN107229558B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/3668Software testing
    • G06F11/3672Test management
    • G06F11/3688Test management for test execution, e.g. scheduling of test suites

Landscapes

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

Abstract

The invention provides a software testing method and a software testing device, which are characterized in that test points are preset in a target program, so that in the process of executing the target program, the test program corresponding to the test points is called to test the target program after the test points are executed to the positions where the test points are set. When different abnormal paths need to be simulated, the codes of the target program do not need to be modified, and only the test program needs to be updated, so that the process of recompiling the target program caused by modifying the codes of the target program in the prior art is omitted, and the test efficiency is improved.

Description

Software testing method and device
Technical Field
The invention relates to computer technology, in particular to a software testing method and device.
Background
The software testing is a link which is necessary before the software is operated on line, and different software testing methods can be adopted to test the software according to different application environments of the software, so that the operation stability of the software in the on-line operation process is ensured.
Among various software test methods, a failure recovery (Failover) test is a test method for testing a process of software for handling a failure and recovery. At present, when a failure recovery test is performed on software, a test code is often written in a program code of the software to be tested in advance, so that the test is performed after compiling.
Because a plurality of execution failure scenarios are often required to be tested in the failure recovery test, the tested software is required to simulate the abnormal exit scenario under various different paths, that is, what is called a simulated abnormal path, and therefore, in the prior art, each abnormal path is tested, a programmer is required to update codes and recompile the codes, and the test efficiency is low.
Disclosure of Invention
The invention provides a software testing method and device, which are used for solving the technical problem of low efficiency of failure recovery testing in the prior art.
In order to achieve the above purpose, the embodiment of the invention adopts the following technical scheme:
in a first aspect, a software testing method is provided, including:
executing the target program;
and when the preset test point in the target program is executed, calling the test program corresponding to the test point to test the target program.
In a second aspect, a software testing apparatus is provided, including:
the execution module is used for executing the target program;
and the calling module is used for calling the test program corresponding to the test point to test the target program when the preset test point in the target program is executed.
According to the software testing method and device provided by the embodiment of the invention, the test points are preset in the target program, so that in the process of executing the target program, the test program corresponding to the test points is called to test the target program after the test points are executed to the positions where the test points are set. When different abnormal paths need to be simulated, the codes of the target program do not need to be modified, and only the test program needs to be updated, so that the process of recompiling the target program caused by modifying the codes of the target program in the prior art is omitted, and the test efficiency is improved.
The foregoing description is only an overview of the technical solutions of the present invention, and the embodiments of the present invention are described below in order to make the technical means of the present invention more clearly understood and to make the above and other objects, features, and advantages of the present invention more clearly understandable.
Drawings
Various other advantages and benefits will become apparent to those of ordinary skill in the art upon reading the following detailed description of the preferred embodiments. The drawings are only for purposes of illustrating the preferred embodiments and are not to be construed as limiting the invention. Also, like reference numerals are used to refer to like parts throughout the drawings. In the drawings:
fig. 1 is a schematic flowchart of a software testing method according to an embodiment of the present invention;
fig. 2 is a schematic flowchart of a software testing method according to a second embodiment of the present invention;
fig. 3 is a schematic structural diagram of a software testing apparatus according to a third embodiment of the present invention;
fig. 4 is a schematic structural diagram of a software testing apparatus according to a fourth embodiment of the present invention.
Detailed Description
Exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be embodied in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.
The following describes in detail a software testing method and apparatus provided by an embodiment of the present invention with reference to the accompanying drawings.
Example one
Fig. 1 is a schematic flowchart of a software testing method according to an embodiment of the present invention, as shown in fig. 1, including:
and step 101, executing the target program.
When the target program code is written, test points are already preset in the target program. The contents of the test point include the identification of the test point, such as the name of the test point, and the test point may further include a macro and a custom code, wherein the macro is used for indicating the execution sequence of the custom code and the calling test program. Since the test program is usually described in a fixed format such as an execution mode, event content, and event type, in order to improve the flexibility of the test, a user may write a piece of custom code for the test in advance in the test point when writing the target program code.
Furthermore, before the target program is executed, each test point in the target program can be set to be in a closed state, and then the target program is compiled, so that the target program is not influenced by the test points, and the integrity of the target program and the independence of the target program relative to the test program are ensured. After the compiling is completed, the client sends a Remote Procedure Call Protocol (RCP) request as a request for setting an on-off state, the server sets a test point in the target program to be in an on state or an off state according to the RCP request, and then the server calls the corresponding test program when the server confirms that the test point is in the on state in the process of running the target program.
And 102, calling the test program corresponding to the test point to test the target program when the preset test point in the target program is executed.
Specifically, as a possible application scenario, a test program is called to perform a failure recovery test on the target program. As another possible application scenario, a test program is called to test the execution time of a target program.
For an application scenario for performing the failure recovery test, specifically, according to a test point identifier in a test point, a test program marked by the test point identifier is queried in a container for recording the test program, and the failure recovery test is performed on a target program according to an execution mode, event content and/or event type indicated by the test program.
The execution mode can be specifically single execution, multiple execution, random execution and the like; the event type may specifically be delay, error code return, exception throw, process termination, etc., and the event content may be specific time of delay, etc.
Therefore, the test points preset in the target program are adopted, and when the test points are executed, the test programs corresponding to the test points are called to test the target program, so that simulation of various scenes can be realized.
In addition, because the target program and the test program are independent, when the test program needs to be modified, the target program does not need to be recompiled, and the test efficiency and the test convenience are improved. Especially, when the scheme in this embodiment is applied to a distributed system, the advantage of not needing to modify code and compile an object program running in the distributed system is more sufficient because the complexity of running and deploying the distributed system is higher.
Example two
Fig. 2 is a flowchart of a software testing method according to a second embodiment of the present invention, and in order to eliminate and explain an execution flow when a client modifies a test program of a server, the embodiment provides a specific flowchart as shown in fig. 2.
The method provided by the embodiment is executed by a server side and a client side, wherein the server side is used for running the target program, and a container (Map) storing the test program is arranged on the server side. The client can request to update the test program in the Map through the RCP.
For the server side, on one hand, a test point, such as a bug removal (debug) point, is inserted into a desired test position in the target program.
Specifically, the debug point may be designed by adopting a singleton mode, and a name of the debug point is declared at a position where the debug point needs to be added in the code of the target program, for example: DECLARE _ DBG _ POINT (New _ DebugPiontName), where New _ DebugPiontName is the name of this debug POINT. After declaring the debug point, the debug point may be inserted into the code of the target program at a location where a test point needs to be added, for example: DBG _ POINT _ PRE _ EXEC (New _ DebugPiontName, code). Wherein, code is a section of custom code, and DBG _ POINT _ PRE _ EXEC is a macro, which indicates that the custom code is executed before the test program corresponding to the debug POINT is executed.
Different macros may specify that a piece of custom code be executed before execution or after execution of a test program at the debug point. Since the custom code of this portion is located in the object program, it cannot be modified by the client, and needs to be determined when the code of the object program is written.
On the other hand, the Map stores test programs corresponding to the test points, and the test programs include execution modes (Point types), event contents (actions) and event types (Action types) of the debug points. The execution mode can be specifically single execution, multiple execution, random execution and the like; the event type may specifically be delay, error code return, exception throw, process termination, etc., and the event content may be specific time of delay, etc.
As shown in fig. 2, the software testing method includes:
step 201, the client sends an RCP request.
The RPC request carries the name of the debug point, and the execution mode, the event content and the event type of the test program corresponding to the debug point after being updated.
Step 202, the server side updates the test program according to the RCP request.
After receiving the RCP request, the server side modifies the corresponding execution mode, event content and event type in the test program corresponding to the debug point in the Map container into the execution mode, event content and event type in the RCP request.
Step 203, when the server runs the target program to the test point position, inquiring the test program corresponding to the test point.
For example: when the server executes to a test POINT DBG _ POINT _ PRE _ EXEC (New _ DebugPiontName, code), the server executes a custom code first, and then calls a singleton method of the debug POINT, so as to inquire whether events needing to be executed exist in a Map container, wherein the events comprise event content, event types and execution modes of the events.
And if the event needing to be executed exists, executing. Because the event type and the execution mode of the event contained in the event have various values, various expected logics can be simulated according to different combinations.
Step 204, determining whether the event type in the test program is delayed, if yes, performing step 205, otherwise, performing step 206.
Step 205, determining an execution time according to the remaining delay time of the test program whose delay time is not finished and the delay time indicated in the current test program, and delaying according to the determined execution time.
Specifically, before executing the delay-type event, it is required to query whether there is a debug point with an event type delay and an unfinished delay time in the debug points executed before the debug point, if not, execute the event, and if so, take a difference between the delay time remaining at the unfinished debug point and the delay time of the current event as the delay time to be executed by the event, and execute the delay event according to the calculated delay time to be executed when the delay time to be executed by the event is a positive number.
This is because the previous debug point is in a delayed state if the previous debug point is not completely executed, and if the current debug point is also delayed, the delay is continued based on the delay of the previous debug point, so that the actual delay time is the sum of the delay time of the previous debug point and the delay time of the current debug point. In order to make the actual delay time conform to the delay time indicated by the test program, the delay time remaining in the test program for which the delay time has not ended and the delay time indicated in the current test program are required to determine the actual delay time.
And step 206, executing the test program corresponding to the test point.
If the event type in the test program is not delayed, the test is directly performed according to the content in the test program, that is, the event execution mode, the event content and the event type indicated by the test program are executed.
In this embodiment, by setting the test point in the target program in advance, in the process of executing the target program, the test program corresponding to the test point is called to test the target program after the test point is executed to the position where the test point is set. When different abnormal paths need to be simulated, the codes of the target program do not need to be modified, and only the test program needs to be updated, so that the process of recompiling the target program caused by modifying the codes of the target program in the prior art is omitted, and the test efficiency is improved.
EXAMPLE III
Fig. 3 is a schematic structural diagram of a software testing apparatus according to a third embodiment of the present invention, as shown in fig. 3, including: an execution module 31 and a calling module 32.
And the execution module 31 is used for executing the target program.
And the calling module 32 is configured to call the test program corresponding to the test point to test the target program when the test point preset in the target program is executed.
Wherein, the test point can include: test point identification, macro and custom code.
Specifically, the calling module 32 is specifically configured to call the test program to perform the failure recovery test on the target program.
In this embodiment, by setting the test point in the target program in advance, in the process of executing the target program, the test program corresponding to the test point is called to test the target program after the test point is executed to the position where the test point is set. When different abnormal paths need to be simulated, the codes of the target program do not need to be modified, and only the test program needs to be updated, so that the process of recompiling the target program caused by modifying the codes of the target program in the prior art is omitted, and the test efficiency is improved.
Example four
Fig. 4 is a schematic structural diagram of a software testing apparatus according to a fourth embodiment of the present invention, and as shown in fig. 4, on the basis of the software testing apparatus provided in fig. 3, the invoking module 32 further includes: query unit 321 and test unit 322.
The query unit 321 is configured to query, according to the test point identifier in the test point, the test program marked by the test point identifier in a container for recording the test program.
The testing unit 322 is configured to perform a failure recovery test on the target program according to the execution mode, the event content, and/or the event type indicated by the test program.
Further, the test unit 322 includes: a query sub-unit 3221, a computation sub-unit 3222, and an execution sub-unit 3223.
The querying subunit 3221 is configured to, when the event type of the test program is delay, query whether there is a test program whose delay time is not ended in the executed test programs.
A calculating subunit 3222, configured to determine, if the delay time does not end, an actual delay time of the test program according to the remaining delay time of the test program and the delay time indicated by the event content of the test program.
An executing subunit 3223 is configured to delay the target program according to the actual delay time of the test program.
Further, the software testing device further comprises: a customization module 33, a receiving module 34, an updating module 35, a compiling module 36, a status receiving module 37, a setting module 38 and a confirmation module 39.
And the custom module 33 is configured to execute the custom code according to the custom code indicated by the macro in the test point and the execution sequence of the test program.
A receiving module 34, configured to receive an update request.
The update request comprises a test point identification, an execution mode, event content and/or an event type.
And the updating module 35 is configured to update the test program indicated by the update request according to the update request.
Specifically, the updating module 35 is specifically configured to correspondingly update the execution mode, the event content, and/or the event type in the test program corresponding to the test point identifier in the update request to the execution mode, the event content, and/or the event type in the update request.
And the compiling module 36 is configured to compile the object program after setting each test point in the object program to be in a closed state.
A state receiving module 37, configured to receive a request for setting an open/close state.
A setting module 38, configured to set a test point in the target program to be in an open state or a closed state according to the request for setting the open/close state.
And the confirming module 39 is configured to confirm that the test point is in an open state before the test program corresponding to the test point is called to test the target program.
The apparatus provided in this embodiment is specifically configured to execute the methods shown in fig. 1 and fig. 2, and specific implementation methods of each functional module refer to relevant descriptions in corresponding embodiments, which are not described in detail in this embodiment.
Those of ordinary skill in the art will understand that: all or a portion of the steps of implementing the above-described method embodiments may be performed by hardware associated with program instructions. The program may be stored in a computer-readable storage medium. When executed, the program performs steps comprising the method embodiments described above; and the aforementioned storage medium includes: various media that can store program codes, such as ROM, RAM, magnetic or optical disks.
Finally, it should be noted that: the above embodiments are only used to illustrate the technical solution of the present invention, and not to limit the same; while the invention has been described in detail and with reference to the foregoing embodiments, it will be understood by those skilled in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some or all of the technical features may be equivalently replaced; and the modifications or the substitutions do not make the essence of the corresponding technical solutions depart from the scope of the technical solutions of the embodiments of the present invention.

Claims (14)

1. A software testing method, comprising:
executing the target program;
when the preset test point in the target program is executed, calling the test program corresponding to the test point to test the target program
The method is characterized in that the step of calling the test program corresponding to the test point to test the target program comprises the following steps:
according to the test point identification in the test point, inquiring the test program marked by the test point identification in a container for recording the test program;
and performing failure recovery test on the target program according to the execution mode, the event content and/or the event type indicated by the test program.
2. The software testing method according to claim 1, wherein the performing the failure recovery test on the target program according to the execution mode, the event content and/or the event type indicated by the test program comprises:
when the event type of the test program is delay, inquiring whether a test program with delay time not finished exists in the executed test programs;
if yes, determining the actual delay time of the test program according to the residual delay time of the test program of which the delay time is not finished and the delay time indicated by the event content of the test program;
and delaying the target program according to the actual delay time of the test program.
3. The software testing method of claim 1, wherein the test points comprise: test point identification, macro and custom code; after the executing to the test point preset in the target program, the method further comprises:
and executing the custom code according to the custom code indicated by the macro in the test point and the execution sequence of the test program.
4. The software testing method according to any one of claims 1 to 3, wherein before the calling the test program corresponding to the test point to test the target program, the method further comprises:
receiving an update request;
and updating the test program indicated by the updating request according to the updating request.
5. The software testing method according to claim 4, wherein the update request comprises a test point identifier, and an execution mode, an event content and/or an event type;
the updating the test program indicated by the update request according to the update request includes:
and correspondingly updating the execution mode, the event content and/or the event type in the test program corresponding to the test point identifier in the update request into the execution mode, the event content and/or the event type in the update request.
6. The software testing method according to any one of claims 1 to 3, wherein before executing the target program, the method further comprises:
setting all test points in the target program to be in a closed state;
and compiling the target program.
7. The software testing method of claim 6, wherein after compiling the object program, further comprising:
receiving a request for setting an open-closed state;
setting the test point in the target program to be in an opening state or a closing state according to the request for setting the opening and closing state;
before the calling the test program corresponding to the test point to test the target program, the method further includes:
and confirming that the test point is in an open state.
8. A software testing apparatus, comprising:
the execution module is used for executing the target program;
a calling module, configured to call the test program corresponding to the test point to test the target program when the preset test point in the target program is executed
The calling module is characterized by comprising:
the query unit is used for querying the test program marked by the test point identification in a container for recording the test program according to the test point identification in the test point;
and the test unit is used for carrying out failure recovery test on the target program according to the execution mode, the event content and/or the event type indicated by the test program.
9. The software testing apparatus according to claim 8, wherein the testing unit comprises:
the query subunit is configured to query whether a test program with an unfinished delay time exists in the executed test programs when the event type of the test program is delay;
the calculation subunit is used for determining the actual delay time of the test program according to the residual delay time of the test program of which the delay time is not finished and the delay time indicated by the event content of the test program if the delay time exists;
and the execution subunit is used for delaying the target program according to the actual delay time of the test program.
10. The software testing method of claim 8, wherein the test points comprise: test point identification, macro and custom code; the device, still include:
and the custom module is used for executing the custom code according to the custom code indicated by the macro in the test point and the execution sequence of the test program.
11. The software testing apparatus according to any one of claims 8 to 10, wherein said apparatus further comprises:
a receiving module, configured to receive an update request;
and the updating module is used for updating the test program indicated by the updating request according to the updating request.
12. The software testing method according to claim 11, wherein the update request comprises a test point identification, and an execution mode, an event content and/or an event type;
the update module is specifically configured to correspondingly update the execution mode, the event content, and/or the event type in the test program corresponding to the test point identifier in the update request to the execution mode, the event content, and/or the event type in the update request.
13. The software testing apparatus according to any one of claims 8 to 10, wherein said apparatus further comprises:
and the compiling module is used for compiling the target program after setting each test point in the target program to be in a closed state.
14. The software testing apparatus of claim 13, further comprising:
the state receiving module is used for receiving a request for setting an opening and closing state;
the setting module is used for setting the test points in the target program to be in an opening state or a closing state according to the request for setting the opening and closing state;
and the confirming module is used for confirming that the test point is in an open state before the test program corresponding to the test point is called to test the target program.
CN201610168942.XA 2016-03-23 2016-03-23 Software testing method and device Active CN107229558B (en)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CN201610168942.XA CN107229558B (en) 2016-03-23 2016-03-23 Software testing method and device
TW106105130A TW201734791A (en) 2016-03-23 2017-02-16 Software test method and device
PCT/CN2017/076399 WO2017162058A1 (en) 2016-03-23 2017-03-13 Software test method and device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201610168942.XA CN107229558B (en) 2016-03-23 2016-03-23 Software testing method and device

Publications (2)

Publication Number Publication Date
CN107229558A CN107229558A (en) 2017-10-03
CN107229558B true CN107229558B (en) 2020-10-16

Family

ID=59899200

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201610168942.XA Active CN107229558B (en) 2016-03-23 2016-03-23 Software testing method and device

Country Status (3)

Country Link
CN (1) CN107229558B (en)
TW (1) TW201734791A (en)
WO (1) WO2017162058A1 (en)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10248554B2 (en) 2016-11-14 2019-04-02 International Business Machines Corporation Embedding profile tests into profile driven feedback generated binaries
CN108256331A (en) * 2018-01-04 2018-07-06 郑州云海信息技术有限公司 A kind of test method of server B MC safety approach
US10929117B2 (en) 2018-02-08 2021-02-23 Red Hat, Inc. Container image building using shared resources
TWI682295B (en) 2018-11-05 2020-01-11 財團法人資訊工業策進會 Device and method for producing test data
CN111143229A (en) * 2019-12-31 2020-05-12 中国银行股份有限公司 Software testing method and device, computer equipment and computer readable storage medium
CN112069083A (en) * 2020-11-12 2020-12-11 深圳开源互联网安全技术有限公司 Test case design method and device and storage medium
CN113568796A (en) * 2021-08-04 2021-10-29 上海肇观电子科技有限公司 Module testing method and device

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103761184A (en) * 2013-12-31 2014-04-30 华为技术有限公司 Method, device and system for testing code segment of program
CN104834590A (en) * 2014-02-11 2015-08-12 腾讯科技(深圳)有限公司 Software test method and system
CN105095087A (en) * 2015-08-31 2015-11-25 武汉启明联创信息科技有限公司 Permission operation based software test system and method

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100543701C (en) * 2007-12-25 2009-09-23 中兴通讯股份有限公司 A kind of method and system that realize embedded software unconventionality testing
WO2016001982A1 (en) * 2014-06-30 2016-01-07 株式会社 日立製作所 Test data generation assistance device and test data generation assistance method
CN105224466B (en) * 2015-11-17 2018-08-28 广州亦云信息技术有限公司 A kind of integration test method and system based on Docker

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103761184A (en) * 2013-12-31 2014-04-30 华为技术有限公司 Method, device and system for testing code segment of program
CN104834590A (en) * 2014-02-11 2015-08-12 腾讯科技(深圳)有限公司 Software test method and system
CN105095087A (en) * 2015-08-31 2015-11-25 武汉启明联创信息科技有限公司 Permission operation based software test system and method

Also Published As

Publication number Publication date
WO2017162058A1 (en) 2017-09-28
TW201734791A (en) 2017-10-01
CN107229558A (en) 2017-10-03

Similar Documents

Publication Publication Date Title
CN107229558B (en) Software testing method and device
US11748245B2 (en) Object-oriented regression-candidate filter
CN110603527B (en) Method, system and apparatus for conditional debugging of server-side production code
CN109101416B (en) Kernel fault injection method and electronic equipment
US9063819B2 (en) Extensible patch management
CN106897090B (en) Embedded equipment program upgrading method and system
WO2007001108A1 (en) System for providing feature-oriented software product line engineering environment
JP6726140B2 (en) Technical system operating software modification and simulation
CN106055368A (en) Application updating method and device
KR20100084036A (en) Apparatus and method for detecting error of software
CN108228190B (en) Persistent integration and delivery methods, systems, devices, and computer-readable storage media
US20190073292A1 (en) State machine software tester
US7908596B2 (en) Automatic inspection of compiled code
CN110990289B (en) Method and device for automatically submitting bug, electronic equipment and storage medium
CN111580898A (en) Method and device for automatically executing simulation software
CN110347735A (en) The data forwarding of configurationization mends processing method, device and readable storage medium storing program for executing extremely
CN111930398B (en) Application program updating method, device, system, medium and equipment
JP7015625B2 (en) Step-back mechanism for developing and diagnosing process applications
US20160004625A1 (en) Method of executing test scripts based on runtime test selection
CN104679648A (en) Cross-application automatic testing method
CN114610516B (en) Application program repairing method and device, computer equipment and storage medium
CN111427795A (en) Code test control method and device, storage medium and electronic equipment
CN115858012B (en) Program variable configuration method, device, electronic equipment and storage medium
US20100293018A1 (en) Test Model Abstraction For Testability in Product Line Engineering
CN113360406B (en) Method and device for testing JSbridge method of application program

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
GR01 Patent grant
GR01 Patent grant