CN110928784B - Software testing environment monitoring method and device - Google Patents
Software testing environment monitoring method and device Download PDFInfo
- Publication number
- CN110928784B CN110928784B CN201911148365.8A CN201911148365A CN110928784B CN 110928784 B CN110928784 B CN 110928784B CN 201911148365 A CN201911148365 A CN 201911148365A CN 110928784 B CN110928784 B CN 110928784B
- Authority
- CN
- China
- Prior art keywords
- software
- monitoring
- software system
- target
- testing environment
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3664—Environments for testing or debugging software
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
- G06F11/302—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system component is a software system
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3051—Monitoring arrangements for monitoring the configuration of the computing system or of the computing system component, e.g. monitoring the presence of processing resources, peripherals, I/O links, software programs
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Abstract
The application provides a software testing environment monitoring method and device, wherein the method comprises the following steps: acquiring a monitoring test case applied to a target software test environment; and running the monitoring test case to monitor the core functions of each software system and/or the interaction functions among different software systems in the target software testing environment. In the application, the monitoring of the software testing environment can be realized in the above mode, and the monitoring effect is improved.
Description
Technical Field
The present application relates to the field of software testing technologies, and in particular, to a method and an apparatus for monitoring a software testing environment.
Background
Before the software is put into use, a software testing environment (which can be understood as a software system environment for testing, including a plurality of software systems in a testing state) is generally built and tested.
Whether the software testing environment is stable or controllable can affect the testing effect of the software, so that the software testing environment is necessary to be monitored, but how to monitor the software testing environment becomes a problem.
Disclosure of Invention
In order to solve the technical problems, the embodiment of the application provides a method and a device for monitoring a software testing environment, so as to achieve the purposes of monitoring the software testing environment and improving the monitoring effect, and the technical scheme is as follows:
a software testing environment monitoring method, comprising:
acquiring a monitoring test case applied to a target software test environment;
and running the monitoring test case to monitor the core functions of each software system and/or the interaction functions among different software systems in the target software testing environment.
Preferably, the running the monitoring test case includes:
and periodically running the monitoring test cases by using continuous integrated software, and monitoring the core functions of each software system and/or the interaction functions among different software systems in the target software testing environment.
Preferably, the monitoring the core function of each software system and/or the interaction function between different software systems in the target software testing environment, after obtaining the monitoring result, further includes:
and recording the availability data of each software system.
Preferably, the method further comprises:
and analyzing the dependency relationship among different software systems in the target software testing environment every other preset time to obtain a dependency relationship analysis result.
Preferably, the analyzing the dependency relationship between different software systems in the target software testing environment once every preset time to obtain a dependency relationship analysis result includes:
acquiring log data within a set time range every preset time;
searching a transaction identifier of a target software system in the target software testing environment;
searching a log record related to the transaction identifier in the log data as a target log record;
sequencing the target log records according to the transaction time, a transaction initiating software system and a transaction receiving software system to obtain an ordered list of triples, wherein the triples comprise the transaction time, the transaction initiating software system and the transaction receiving software system as a dependency relationship side set;
acquiring a software system corresponding to the transaction identifier from the log data, and deleting repeated software systems in the software system corresponding to the transaction identifier, wherein the acquired software system set is used as a dependency relationship node set;
and constructing a software system dependency graph according to the dependency edge set and the dependency node set, and taking the software system dependency graph as a dependency analysis result.
Preferably, the method further comprises:
and marking the availability of the nodes in the software system dependency graph by utilizing the availability data of each software system.
A software testing environment monitoring device, comprising:
the acquisition module is used for acquiring a monitoring test case applied to the target software testing environment;
and the operation module is used for operating the monitoring test case and monitoring the core function of each software system and/or the interaction function among different software systems in the target software testing environment.
Preferably, the operation module is specifically configured to:
and periodically running the monitoring test cases by using continuous integrated software, and monitoring the core functions of each software system and/or the interaction functions among different software systems in the target software testing environment.
Preferably, the operation module is further configured to:
and running the monitoring test case, monitoring the core function of each software system and/or the interaction function among different software systems in the target software testing environment, and recording the availability data of each software system.
Preferably, the apparatus further comprises:
and the analysis module is used for analyzing the dependency relationship among different software systems in the target software testing environment once every preset time to obtain a dependency relationship analysis result.
Preferably, the analysis module is specifically configured to:
acquiring log data within a set time range every preset time;
searching a transaction identifier of a target software system in the target software testing environment;
searching a log record related to the transaction identifier in the log data as a target log record;
sequencing the target log records according to the transaction time, a transaction initiating software system and a transaction receiving software system to obtain an ordered list of triples, wherein the triples comprise the transaction time, the transaction initiating software system and the transaction receiving software system as a dependency relationship side set;
acquiring a software system corresponding to the transaction identifier from the log data, and deleting repeated software systems in the software system corresponding to the transaction identifier, wherein the acquired software system set is used as a dependency relationship node set;
and constructing a software system dependency graph according to the dependency edge set and the dependency node set, and taking the software system dependency graph as a dependency analysis result.
Preferably, the apparatus further comprises:
and the marking module is used for marking the availability of the nodes in the software system dependency graph by utilizing the availability data of each software system.
Compared with the prior art, the application has the beneficial effects that:
in the application, since the software testing environment is composed of a plurality of software systems, the monitoring of the software testing environment can be equivalent to the monitoring of the software systems in the software testing environment, and particularly, the monitoring test cases can be operated to monitor the core functions of each software system and/or the interaction functions among different software systems in the target software testing environment. Because the testing link focuses on the functional test of the software system and the interactive function test among different software systems, the core function monitoring and/or the interactive function monitoring among different software systems are carried out in a targeted manner, and the monitoring effect is improved.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are needed in the description of the embodiments will be briefly described below, it being obvious that the drawings in the following description are only some embodiments of the present application, and that other drawings may be obtained according to these drawings without inventive effort to a person skilled in the art.
FIG. 1 is a flow chart of a software testing environment monitoring method provided by the application;
FIG. 2 is a flow chart of another software testing environment monitoring method provided by the present application;
FIG. 3 is a flow chart of yet another method for monitoring a software testing environment provided by the present application;
FIG. 4 is a flow chart of yet another method for monitoring a software testing environment provided by the present application;
FIG. 5 is a flow chart of yet another method for monitoring a software testing environment provided by the present application;
FIG. 6 is a schematic diagram of a software system dependency graph provided by the present application;
FIG. 7 is a flow chart of yet another method for monitoring a software testing environment provided by the present application;
fig. 8 is a schematic logic structure diagram of a software testing environment monitoring device provided by the application.
Detailed Description
The following description of the embodiments of the present application will be made clearly and completely with reference to the accompanying drawings, in which it is apparent that the embodiments described are only some embodiments of the present application, but not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the application without making any inventive effort, are intended to be within the scope of the application.
The embodiment of the application discloses a software testing environment monitoring method, which comprises the following steps: acquiring a monitoring test case applied to a target software test environment; and running the monitoring test case to monitor the core functions of each software system and/or the interaction functions among different software systems in the target software testing environment. According to the application, the monitoring of the software testing environment is realized, and the monitoring effect is improved.
As shown in fig. 1, a flowchart of an embodiment 1 of a software testing environment monitoring method provided by the present application includes the following steps:
and S11, acquiring a monitoring test case applied to the target software testing environment.
The monitoring test case can be understood as: test cases for monitoring the availability of a target software test environment.
The design of the monitoring test case is related to the monitoring target of the software testing environment. For example, the software development period test focuses on the correctness of the software functions, the robustness of exception handling and the coverage of branches, and the monitoring test cases mainly comprise automatic unit tests and integration tests; the software acceptance period focuses on the correctness of software functions, the correct processing capability of the software for abnormality, the coincidence degree of the software functions and the requirements of users, the safety, the performance and other nonfunctional characteristics of the software, and the monitoring test cases comprise automatic functional tests, automatic safety tests, automatic performance tests and manual exploration tests.
The development process of the monitoring test case in this embodiment may be:
one or more software development projects are established, an automatic test framework is selected, different automatic monitoring test cases are developed for different software test environments based on the automatic test framework, related monitoring test cases can be organized into a set to serve as a test suite set, and the test suite set is arranged in the software development projects to be managed.
And managing and monitoring the test cases by the source code management system through the software development engineering hosting and source code management system.
In this embodiment, a monitoring test case applied to the target software test environment may be obtained from the source code management system.
And step S12, running the monitoring test case, and monitoring the core functions of each software system and/or the interaction functions among different software systems in the target software testing environment.
The monitoring of the core functions of each software system and/or the interaction functions between different software systems in the target software testing environment can be understood as follows: the availability of individual software systems in a target software testing environment is monitored.
As another alternative embodiment of the present application, referring to fig. 2, a schematic flow chart of an embodiment 2 of a software testing environment monitoring method provided by the present application is mainly a refinement of the software testing environment monitoring method described in the foregoing embodiment 1, and as shown in fig. 2, the method may include, but is not limited to, the following steps:
and S21, acquiring a monitoring test case applied to the target software testing environment.
The detailed process of step S21 can be referred to the related description of step S11 in embodiment 1, and will not be repeated here.
And S22, periodically running the monitoring test cases by using continuous integrated software, and monitoring the core functions of each software system and/or the interaction functions among different software systems in the target software testing environment.
And periodically running the monitoring test cases by using continuous integrated software, and monitoring the core functions of each software system and/or the interaction functions among different software systems in the target software testing environment so as to realize uninterrupted monitoring of the target software testing environment and improve the monitoring reliability.
As another alternative embodiment of the present application, referring to fig. 3, a schematic flow chart of an embodiment 3 of a software testing environment monitoring method provided by the present application is mainly an extension of the software testing environment monitoring method described in the foregoing embodiment 1, and as shown in fig. 3, the method may include, but is not limited to, the following steps:
and S31, acquiring a monitoring test case applied to the target software testing environment.
And step S32, running the monitoring test case, monitoring the core function of each software system and/or the interaction function among different software systems in the target software testing environment, and recording the availability data of each software system.
The process of monitoring the core functions of each software system and/or the interaction functions between different software systems in the target software testing environment may refer to the related description of monitoring the core functions of each software system and/or the interaction functions between different software systems in the target software testing environment in embodiment 1, which is not described herein.
The monitoring test case monitors the core functions of all the software systems in the target software testing environment and/or the interaction functions among different software systems, and meanwhile, availability data of all the software systems in the target software testing environment are generated and recorded.
The availability data of the software system can be understood as: data characterizing the availability of a software system.
The availability data of each software system recorded by the monitoring test case can be used as guide data for developing the monitoring test case and maintaining the target software testing environment.
After the monitoring test case records the availability data of each software system, the recorded availability data of each software system can be pushed to relevant operation and maintenance personnel or relevant platforms; of course, the monitoring test case may also provide a query interface for externally querying availability data of each software system.
As another alternative embodiment of the present application, referring to fig. 4, a schematic flow chart of an embodiment 4 of a software testing environment monitoring method provided by the present application is mainly an extension of the software testing environment monitoring method described in the foregoing embodiment 3, and as shown in fig. 4, the method may include, but is not limited to, the following steps:
and S41, acquiring a monitoring test case applied to the target software testing environment.
And step S42, running the monitoring test case, monitoring the core function of each software system and/or the interaction function among different software systems in the target software testing environment, and recording the availability data of each software system.
The detailed procedure of steps S41-S42 can be referred to the related description of steps S31-S33 in embodiment 3, and will not be repeated here.
And S43, analyzing the dependency relationship among different software systems in the target software testing environment every preset time to obtain a dependency relationship analysis result.
It should be noted that there are call and called dependencies between various software systems in the target software test environment. The software dependencies are determined at the software design stage, but such static relationships lose accuracy as the software functions change. Dynamic analysis of dependencies between software is therefore required to ensure accuracy.
The dependency relationship among different software systems in the target software testing environment is analyzed every preset time to obtain a dependency relationship analysis result, the dependency relationship analysis result can be used as a function of a monitoring test case, and the dependency relationship among different software systems in the target software testing environment is analyzed every preset time by operating the monitoring test case to obtain the dependency relationship analysis result.
Of course, a dependency analysis program may be set separately, and the dependency analysis program may be run to analyze the dependency between different software systems in the target software test environment once every preset time, so as to obtain a dependency analysis result.
In this embodiment, the dependency analysis result may guide development of the monitoring test case.
As another alternative embodiment of the present application, referring to fig. 5, a schematic flow chart of an embodiment 5 of a software testing environment monitoring method provided by the present application is mainly a refinement of the software testing environment monitoring method described in the foregoing embodiment 4, and as shown in fig. 5, the method may include, but is not limited to, the following steps:
and S51, acquiring a monitoring test case applied to the target software testing environment.
And step S52, running the monitoring test case, monitoring the core function of each software system and/or the interaction function among different software systems in the target software testing environment, and recording the availability data of each software system.
The detailed procedure of steps S51-S52 can be referred to the related description of steps S41-S43 in embodiment 4, and will not be repeated here.
Step S53, log data in a set time range is acquired every preset time.
The set time range may be set as needed, and is not limited herein.
Step S54, searching the transaction identification of the target software system in the target software testing environment.
It should be noted that, when the target software system performs a transaction, the transaction identifier of the target software system is transferred between the software systems along with the transaction data, and is recorded in the log data.
Thus, when a dependency relationship between the target software system and other software systems needs to be analyzed, a transaction identification of the target software system needs to be looked up.
Step S55, searching the log record related to the transaction identifier in the log data, and taking the log record as a target log record.
And step S56, sequencing the target log records according to the transaction time, the transaction initiating software system and the transaction receiving software system to obtain an ordered list of triples, wherein the triples comprise the transaction time, the transaction initiating software system and the transaction receiving software system as a dependency relationship edge set.
And sequencing the target log records according to the transaction time, the transaction initiating software system and the transaction receiving software system to obtain a plurality of sequencing results, wherein each sequencing result can be understood as the ordered information of the triples.
Accordingly, an ordered list of triples can be understood as: a list of ordered information comprising a plurality of triples.
Step S57, acquiring the software system corresponding to the transaction identifier from the log data, and deleting the repeated software system in the software system corresponding to the transaction identifier, wherein the obtained software system set is used as a dependency relation node set.
And acquiring the software system corresponding to the transaction identifier from the log data, and deleting the repeated software system in the software system corresponding to the transaction identifier, so that the reliability of the dependency relationship node set can be ensured.
And S58, constructing a software system dependency graph according to the dependency edge set and the dependency node set, and taking the software system dependency graph as a dependency analysis result.
And constructing a software system dependency graph according to the dependency edge set and the dependency node set, so that the dependency among software systems can be more intuitively displayed.
In this embodiment, taking an aviation service software system as an example, a software system dependency graph is illustrated, for example, the software system dependency graph may be referred to fig. 6. As shown in FIG. 6, the 2-1 Internet unified access system has a dependency relationship with a 1-1 airline website system and a 1-2 airline mobile APP background service system.
Steps S53-S58 are a specific implementation of step S43 in example 4.
In this embodiment, the dependency graph of the software system may also be visually displayed.
As another alternative embodiment of the present application, referring to fig. 7, a schematic flow chart of an embodiment 6 of a software testing environment monitoring method provided by the present application is mainly an extension of the software testing environment monitoring method described in the foregoing embodiment 5, and as shown in fig. 7, the method may include, but is not limited to, the following steps:
step S61, obtaining a monitoring test case applied to a target software testing environment.
And step S62, running the monitoring test case, monitoring the core function of each software system and/or the interaction function among different software systems in the target software testing environment, and recording the availability data of each software system.
Step S63, log data in a set time range is obtained every preset time.
Step S64, searching the transaction identification of the target software system in the target software testing environment.
Step S65, searching the log records related to the transaction identification in the log data as target log records.
And step S66, sequencing the target log records according to the transaction time, the transaction initiating software system and the transaction receiving software system to obtain an ordered list of triples, wherein the triples comprise the transaction time, the transaction initiating software system and the transaction receiving software system as a dependency relationship edge set.
Step S67, the software system corresponding to the transaction identifier is obtained from the log data, repeated software systems in the software system corresponding to the transaction identifier are deleted, and the obtained software system set is used as a dependency relation node set.
And step 68, constructing a software system dependency graph according to the dependency edge set and the dependency node set, and taking the software system dependency graph as a dependency analysis result.
The detailed process of steps S61-S68 can be referred to the related description of steps S51-S58 in embodiment 5, and will not be repeated here.
And step S69, marking the availability of the nodes in the software system dependency graph by utilizing the availability data of each software system.
The nodes in the software system dependency graph can be understood as: the target software tests the software system in the environment.
And marking the availability of the nodes in the software system dependency graph by utilizing the availability data of each software system, so that the dependency relationship among the software systems and the availability of each software system can be intuitively displayed in the software system dependency graph.
In this embodiment, the availability of the nodes in the dependency graph of the software system may be marked by, but not limited to, color marking. For example, available nodes in FIG. 6 (e.g., 1-1 airline website systems and 1-2 airline mobile APP background service systems) may be marked blue, unavailable nodes (e.g., 2-1 Internet unified access systems) may be marked red, and nodes with unknown availability (e.g., 3-1 available flight inquiry systems, etc.) may be marked white.
The software testing environment monitoring device provided by the application is described next, and the software testing environment monitoring device described below and the software testing environment monitoring method described above can be referred to correspondingly.
Referring to fig. 8, the software testing environment monitoring device includes: an acquisition module 11 and a running module 12.
The acquisition module 11 is used for acquiring a monitoring test case applied to a target software testing environment;
and the operation module 12 is used for operating the monitoring test case and monitoring the core functions of each software system and/or the interaction functions among different software systems in the target software testing environment.
In this embodiment, the operation module 12 may specifically be configured to:
and periodically running the monitoring test cases by using continuous integrated software, and monitoring the core functions of each software system and/or the interaction functions among different software systems in the target software testing environment.
In this embodiment, the operation module 12 may be further configured to:
and running the monitoring test case, monitoring the core function of each software system and/or the interaction function among different software systems in the target software testing environment, and recording the availability data of each software system.
In this embodiment, the software testing environment monitoring device may further include:
and the analysis module is used for analyzing the dependency relationship among different software systems in the target software testing environment once every preset time to obtain a dependency relationship analysis result.
In this embodiment, the analysis module may specifically be configured to:
acquiring log data within a set time range every preset time;
searching a transaction identifier of a target software system in the target software testing environment;
searching a log record related to the transaction identifier in the log data as a target log record;
sequencing the target log records according to the transaction time, a transaction initiating software system and a transaction receiving software system to obtain an ordered list of triples, wherein the triples comprise the transaction time, the transaction initiating software system and the transaction receiving software system as a dependency relationship side set;
acquiring a software system corresponding to the transaction identifier from the log data, and deleting repeated software systems in the software system corresponding to the transaction identifier, wherein the acquired software system set is used as a dependency relationship node set;
and constructing a software system dependency graph according to the dependency edge set and the dependency node set, and taking the software system dependency graph as a dependency analysis result.
In this embodiment, the software testing environment monitoring device may further include:
and the marking module is used for marking the availability of the nodes in the software system dependency graph by utilizing the availability data of each software system.
It should be noted that, in the present specification, each embodiment is described in a progressive manner, and each embodiment is mainly described as different from other embodiments, and identical and similar parts between the embodiments are all enough to be referred to each other. For the apparatus class embodiments, the description is relatively simple as it is substantially similar to the method embodiments, and reference is made to the description of the method embodiments for relevant points.
Finally, it is further noted that relational terms such as first and second, and the like are used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Moreover, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.
For convenience of description, the above devices are described as being functionally divided into various units, respectively. Of course, the functions of each element may be implemented in the same piece or pieces of software and/or hardware when implementing the present application.
From the above description of embodiments, it will be apparent to those skilled in the art that the present application may be implemented in software plus a necessary general hardware platform. Based on such understanding, the technical solution of the present application may be embodied essentially or in a part contributing to the prior art in the form of a software product, which may be stored in a storage medium, such as a ROM/RAM, a magnetic disk, an optical disk, etc., including several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the method described in the embodiments or some parts of the embodiments of the present application.
The above describes in detail a method and apparatus for monitoring a software testing environment provided by the present application, and specific examples are applied herein to illustrate the principles and embodiments of the present application, where the above examples are only used to help understand the method and core ideas of the present application; meanwhile, as those skilled in the art will have variations in the specific embodiments and application scope in accordance with the ideas of the present application, the present description should not be construed as limiting the present application in view of the above.
Claims (12)
1. A method for monitoring a software testing environment, comprising:
acquiring a monitoring test case applied to a target software test environment, wherein the monitoring test case is used for monitoring the availability of the target software test environment, and corresponds to different monitoring test cases aiming at different software test environments, the monitoring test case at least comprises an automatic integrated test in a software development period, and at least comprises an automatic function test in a software acceptance period, and the development process of the monitoring test case is as follows: one or more software development projects are established, an automatic test framework is selected, relevant monitoring test cases are organized into a set aiming at different software test environments based on the automatic test framework, the set is used as a test suite set, and the test suite set is arranged in the software development projects for management;
and running the monitoring test case to monitor the core functions of each software system and/or the interaction functions among different software systems in the target software testing environment.
2. The method of claim 1, wherein the running the monitoring test case comprises:
and periodically running the monitoring test cases by using continuous integrated software, and monitoring the core functions of each software system and/or the interaction functions among different software systems in the target software testing environment.
3. The method according to claim 1, wherein the monitoring the core functions of each software system and/or the interaction functions between different software systems in the target software testing environment, after obtaining the monitoring result, further comprises:
and recording the availability data of each software system.
4. A method according to claim 3, characterized in that the method further comprises:
and analyzing the dependency relationship among different software systems in the target software testing environment every other preset time to obtain a dependency relationship analysis result.
5. The method of claim 4, wherein analyzing the dependency relationship between different software systems in the target software testing environment once every preset time to obtain the dependency relationship analysis result comprises:
acquiring log data within a set time range every preset time;
searching a transaction identifier of a target software system in the target software testing environment;
searching a log record related to the transaction identifier in the log data as a target log record;
sequencing the target log records according to the transaction time, a transaction initiating software system and a transaction receiving software system to obtain an ordered list of triples, wherein the triples comprise the transaction time, the transaction initiating software system and the transaction receiving software system as a dependency relationship side set;
acquiring a software system corresponding to the transaction identifier from the log data, and deleting repeated software systems in the software system corresponding to the transaction identifier, wherein the acquired software system set is used as a dependency relationship node set;
and constructing a software system dependency graph according to the dependency edge set and the dependency node set, and taking the software system dependency graph as a dependency analysis result.
6. The method of claim 5, wherein the method further comprises:
and marking the availability of the nodes in the software system dependency graph by utilizing the availability data of each software system.
7. A software testing environment monitoring device, comprising:
the system comprises an acquisition module, a test management module and a control module, wherein the acquisition module is used for acquiring a monitoring test case applied to a target software test environment, the monitoring test case is used for monitoring the availability of the target software test environment, and corresponds to different monitoring test cases aiming at different software test environments, the monitoring test case at least comprises an automatic integrated test in a software development period, the monitoring test case at least comprises an automatic functional test in a software acceptance period, and the development process of the monitoring test case is as follows: one or more software development projects are established, an automatic test framework is selected, relevant monitoring test cases are organized into a set aiming at different software test environments based on the automatic test framework, the set is used as a test suite set, and the test suite set is arranged in the software development projects for management;
and the operation module is used for operating the monitoring test case and monitoring the core function of each software system and/or the interaction function among different software systems in the target software testing environment.
8. The device according to claim 7, wherein the operation module is specifically configured to:
and periodically running the monitoring test cases by using continuous integrated software, and monitoring the core functions of each software system and/or the interaction functions among different software systems in the target software testing environment.
9. The apparatus of claim 7, wherein the run module is further configured to:
and running the monitoring test case, monitoring the core function of each software system and/or the interaction function among different software systems in the target software testing environment, and recording the availability data of each software system.
10. The apparatus of claim 9, wherein the apparatus further comprises:
and the analysis module is used for analyzing the dependency relationship among different software systems in the target software testing environment once every preset time to obtain a dependency relationship analysis result.
11. The apparatus according to claim 10, wherein the analysis module is specifically configured to:
acquiring log data within a set time range every preset time;
searching a transaction identifier of a target software system in the target software testing environment;
searching a log record related to the transaction identifier in the log data as a target log record;
sequencing the target log records according to the transaction time, a transaction initiating software system and a transaction receiving software system to obtain an ordered list of triples, wherein the triples comprise the transaction time, the transaction initiating software system and the transaction receiving software system as a dependency relationship side set;
acquiring a software system corresponding to the transaction identifier from the log data, and deleting repeated software systems in the software system corresponding to the transaction identifier, wherein the acquired software system set is used as a dependency relationship node set;
and constructing a software system dependency graph according to the dependency edge set and the dependency node set, and taking the software system dependency graph as a dependency analysis result.
12. The apparatus of claim 11, wherein the apparatus further comprises:
and the marking module is used for marking the availability of the nodes in the software system dependency graph by utilizing the availability data of each software system.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911148365.8A CN110928784B (en) | 2019-11-21 | 2019-11-21 | Software testing environment monitoring method and device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911148365.8A CN110928784B (en) | 2019-11-21 | 2019-11-21 | Software testing environment monitoring method and device |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN110928784A CN110928784A (en) | 2020-03-27 |
| CN110928784B true CN110928784B (en) | 2023-09-05 |
Family
ID=69850537
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201911148365.8A Active CN110928784B (en) | 2019-11-21 | 2019-11-21 | Software testing environment monitoring method and device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN110928784B (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112799962A (en) * | 2021-02-26 | 2021-05-14 | 平安消费金融有限公司 | Software testing method, device, equipment and medium |
Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1851665A (en) * | 2005-11-07 | 2006-10-25 | 华为技术有限公司 | Method for completing product automation test utilizing test kit |
| KR20090104275A (en) * | 2008-03-31 | 2009-10-06 | 한국항공우주산업 주식회사 | Pairwise test case generation method based on module dependency and computer readable medium for recording program thereof |
| CN108073488A (en) * | 2016-11-14 | 2018-05-25 | 北京京东尚科信息技术有限公司 | Service monitoring method and device |
| CN108628918A (en) * | 2017-09-29 | 2018-10-09 | 南京途牛科技有限公司 | System deployment and dependence automatic Plotting System and method |
| CN108710577A (en) * | 2018-06-01 | 2018-10-26 | 平安普惠企业管理有限公司 | Operation system test method, device, computer equipment and storage medium |
| CN108845937A (en) * | 2018-06-01 | 2018-11-20 | 平安普惠企业管理有限公司 | Test environment control method, device, computer equipment and storage medium |
| CN109144874A (en) * | 2018-08-22 | 2019-01-04 | 北京奇虎科技有限公司 | A kind of monitoring method and device for testing environment |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20160147646A1 (en) * | 2014-11-21 | 2016-05-26 | Wipro Limited | Method and system for executing automated tests in an integrated test environment |
| US9703909B2 (en) * | 2014-12-16 | 2017-07-11 | International Business Machines Corporation | Verification environments utilizing hardware description languages |
-
2019
- 2019-11-21 CN CN201911148365.8A patent/CN110928784B/en active Active
Patent Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1851665A (en) * | 2005-11-07 | 2006-10-25 | 华为技术有限公司 | Method for completing product automation test utilizing test kit |
| KR20090104275A (en) * | 2008-03-31 | 2009-10-06 | 한국항공우주산업 주식회사 | Pairwise test case generation method based on module dependency and computer readable medium for recording program thereof |
| CN108073488A (en) * | 2016-11-14 | 2018-05-25 | 北京京东尚科信息技术有限公司 | Service monitoring method and device |
| CN108628918A (en) * | 2017-09-29 | 2018-10-09 | 南京途牛科技有限公司 | System deployment and dependence automatic Plotting System and method |
| CN108710577A (en) * | 2018-06-01 | 2018-10-26 | 平安普惠企业管理有限公司 | Operation system test method, device, computer equipment and storage medium |
| CN108845937A (en) * | 2018-06-01 | 2018-11-20 | 平安普惠企业管理有限公司 | Test environment control method, device, computer equipment and storage medium |
| CN109144874A (en) * | 2018-08-22 | 2019-01-04 | 北京奇虎科技有限公司 | A kind of monitoring method and device for testing environment |
Non-Patent Citations (1)
| Title |
|---|
| 面向持续集成测试优化的强化学习奖励机制;何柳柳 等;《软件学报》;第30卷(第5期);1438-1449 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN110928784A (en) | 2020-03-27 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20240086399A1 (en) | Web services for creation and maintenance of smart entities for connected devices | |
| Farshchi et al. | Metric selection and anomaly detection for cloud operations using log and metric correlation analysis | |
| US10901727B2 (en) | Monitoring code sensitivity to cause software build breaks during software project development | |
| Gupta et al. | The anatomy of a large-scale experimentation platform | |
| Musa | The operational profile in software reliability engineering: an overview | |
| US7788205B2 (en) | Using stochastic models to diagnose and predict complex system problems | |
| US20190391798A1 (en) | Reducing overhead of software deployment based on existing deployment occurrences | |
| US20070006041A1 (en) | Analytical regression testing on a software build | |
| US9116779B2 (en) | Test management domain asset discovery and analysis | |
| CN102968374A (en) | Data warehouse testing method | |
| US9569782B1 (en) | Automated customer business impact assessment upon problem submission | |
| Bedjeti et al. | Modeling context with an architecture viewpoint | |
| EP2113874A1 (en) | Method and system for monitoring computer-implemented processes | |
| CN102609789A (en) | Information monitoring and abnormality predicting system for library | |
| CN112711438A (en) | Dependent component information extraction method, dependent component information extraction device, and computer-readable storage medium | |
| CN110162441A (en) | Centralized monitoring method and device, electronic equipment, the storage medium of application system | |
| GB2604007A (en) | Software upgrade stability recommendations | |
| US20230281249A1 (en) | Computer-implemented methods, systems comprising computer-readable media, and electronic devices for enabled intervention into a network computing environment | |
| CN114490375A (en) | Method, device and equipment for testing performance of application program and storage medium | |
| US10949333B1 (en) | Application maturity console | |
| CN110928784B (en) | Software testing environment monitoring method and device | |
| Vukovic et al. | Managing enterprise IT systems using online communities | |
| US20200391885A1 (en) | Methods and systems for identifying aircraft faults | |
| Wenzler | Automated performance regression detection in microservice architectures | |
| Ravi et al. | Unsupervised time series data analysis for error pattern extraction for predictive maintenance |
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 |