CN115827453B - Reliability test section structure and test case generation method of networked software system - Google Patents
Reliability test section structure and test case generation method of networked software system Download PDFInfo
- Publication number
- CN115827453B CN115827453B CN202211537772.XA CN202211537772A CN115827453B CN 115827453 B CN115827453 B CN 115827453B CN 202211537772 A CN202211537772 A CN 202211537772A CN 115827453 B CN115827453 B CN 115827453B
- Authority
- CN
- China
- Prior art keywords
- profile
- test
- software system
- software
- networked software
- 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
-
- 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 invention discloses a networked software system reliability test section structure and a test case generation method, which comprises the following steps: identifying and describing the software state and the system state in the continuous running process of the networked software system; setting functional constraint conditions and/or operation constraint conditions by combining the identified state parameters; determining a transition probability value between functions or operations of the networked software system by adopting a preset method; constructing various types of reliability test sections according to the structure and the behavior of the networked software system and based on the application scene of the networked software system; and (3) completing the generation of the reliability test cases of the networked software to form a complete reliability test solution of the networked software system. The method can be used for effectively testing the reliability of the networked software, and is beneficial to improving the performance of the active equipment and the development of new generation digital armed equipment.
Description
Technical Field
The invention relates to the technical field of software reliability engineering, in particular to a networked software system reliability test section structure and a test case generation method.
Background
A networked software system is a complex system that exhibits layering, openness, and nonlinearity in terms of functionality, behavior, and architecture. The single subsystem is autonomous and reactive, i.e., has relative independence, initiative, adaptivity, and the ability to perceive external operating and use environments and provide useful information to the system evolution; the multiple subsystems have interoperability and evolution, i.e., the ability of the multiple subsystems to interconnect, interwork, collaborate, and federate, and to dynamically adjust functions, structures, and behaviors as desired. On this basis, the networked software system can finally form an ordered structure in terms of space, time, behavior and function in an ad hoc manner. The military command control system is an important component in tactical Internet as a typical networked software system, and the reliability of the military command control system is the most direct part of the reliability of an informationized war system.
Since the 70 s of the last century, software reliability test studies have been conducted abroad, and particularly, in recent years, many scholars have conducted comprehensive and systematic studies on software reliability tests deeply from various levels and angles. In the study of the software reliability test method based on the operation profile, the most representative is the operation profile method proposed by Musa of AT & T in the united states, which illustrates the relation between the running and input and output states, and indicates that for driving the test to proceed, inputs need to be continuously provided thereto, and these inputs and the frequency of occurrence thereof constitute the operation profile of the program. The software reliability test method based on the operation profile proposed by Musa has very important significance for software reliability research.
However, the Musa operation profile construction method has some limitations, such as that it is mainly oriented to desktop operation software with simple input and independent operation, but cannot characterize distribution, autonomy, openness and isomerism of networking software. The Musa operation section contains independent operation and occurrence probability thereof, however, in the test of a networked software system, the operation is difficult to implement, and the operation section is limited greatly by adopting a table and a tree diagram description method, so that the constraint and time sequence condition among the operations cannot be shown, and the application range is limited.
The software reliability test case generating method is a test data generating method based on use, and most of the software reliability test case methods are built on a Musa method at present. The test profile is the basis for test case generation, so research of test profile generation is a precondition for test data generation. In recent years, methods for generating test sections have also been greatly developed, and typical ones of these methods are: methods for obtaining test profiles using expert knowledge, methods for guiding the generation of operational profiles using CP (Configuration Profile) and UP (Usage Profile) in a decomposition manner. Application of UML (standard modeling language) to the test profile generation method is also under investigation.
According to analysis, the reliability test research level of the networking software is far lower than that of common software, and at present, a model, a simulation test environment and a test case generation method which can be suitable for the reliability test of the networking software can not be found from the existing literature. The conventional method has a plurality of defects in coping with complex system characteristics of the networked software. These problems restrict the reliability test and evaluation work of the networked software, and influence the performance improvement of the active equipment and the development of new generation digital armed equipment.
Therefore, a reliability testing method for a networked software system needs to be developed to overcome the defects of the prior art in testing and evaluating the reliability of the networked software.
Disclosure of Invention
Aiming at the problem that a software reliability test method based on a Musa operation section cannot meet the reliability test requirement of networked software, the invention provides a reliability test section construction and test case generation method aiming at the networked software.
In order to achieve the above purpose, the technical scheme adopted by the invention is as follows:
the invention provides a networked software system reliability test section structure and a test case generation method, which comprises the following steps of;
s1, identifying and describing a software state and a system state in the continuous running process of a networked software system;
s2, setting functional constraint conditions and/or operation constraint conditions by combining the identified state parameters;
s3, determining a transition probability value between functions or operations of the networked software system by adopting a preset method;
s4, constructing various types of reliability test sections according to the structure and the behavior of the networked software system and based on the application scene of the networked software system; the various types of reliability test profiles include: user profile, task scene profile, network architecture profile, functional profile, and operational profile;
s5, completing the generation of the reliability test cases of the networked software, wherein the generation comprises test item design, input variable description, test case generation process, test data generation algorithm and test case optimization strategy, and a complete reliability test solution of the networked software system is formed.
Further, the step S1 includes:
Identifying the current working state of the software in the continuous running process of the networked software system, and confirming the conversion relation between the current working state and other working states in the subsequent running process;
identifying environment variable parameters in the continuous running process of the networked software system, and identifying the states of peripheral equipment interacted with the environment in the running environment;
and according to the identified state and/or parameters, the description of the state is realized by constructing a state parameter table.
Further, the step S3 includes:
when the section structure is simple, judging a transition probability value between functions or operations of the networked software system by adopting an expert experience judging method;
when the functional profile structure is complex, a summation principle is adopted to determine the transition probability value between functions or operations of the networked software system.
Further, constructing the user profile in the step S4 includes:
identifying the user types which are obviously different from the networked software system, abstracting independent user groups from the user types, counting the proportion occupied by the user groups, and completing the construction of the user profile.
Further, the constructing a task scene profile in step S4 includes:
Analyzing a task scene according to the use mode of the user group of the networked software system;
the method comprises the steps of abstracting and classifying the use modes according to the standpoint of different users, and determining the use mode of a networked software system;
and classifying the task scenes so that a tester only pays attention to one type of relatively independent user use mode in one task scene to complete the construction of the task scene section.
Further, the constructing a network architecture profile in step S4 includes:
after analyzing the task scene section, adopting a hierarchical analysis method to analyze main node components in the network architecture layer by layer, and the time sequence and the transfer sequence among the nodes to complete the construction of the network architecture section;
the method adopts an analytic hierarchy process to analyze the main node composition, the time sequence and the transfer sequence among the nodes in the network architecture layer by layer to complete the construction of the network architecture section, and specifically comprises the following steps:
a) Abstract system hierarchy: abstracting various subsystem nodes deployed on a network to serve as a subsystem layer;
b) The analysis device deploys the network: taking various hardware devices in a network system as nodes and the communication relation among the devices as edges to construct a device deployment network;
c) Constructing a software deployment network: abstracting the software subsystem on each hardware node, replacing hardware with the software subsystem, and establishing a preliminary software deployment network;
d) Analyzing software components on a plurality of nodes, and abstracting out basic tasks of all nodes of all subsystems by using a modeling method;
e) And analyzing the dependency and transfer relation among the nodes according to the task flow, and establishing a network architecture section based on the task scene.
Further, the constructing a functional profile in step S4 includes:
acquiring an independent function set of the software from a development requirement document of the software, and analyzing possible transfer and constraint relations between functions of the software in the running process on the whole;
and part of functions are thinned by supplementing the functional sub-sections, so that the structure of the functional sections is completed.
Further, the constructing an operation profile in step S4 includes:
all operations and usage relationships within each function or sub-function are described separately, completing the construction of the operational profile.
Further, the inputting variable descriptions in the step S5 includes:
and completing the input variable description according to the external interface relation of the networked software system or according to the time sequence and information flow logic relation.
Further, the test case generating process in step S5 includes:
after the input scalar of all operations is described, the required reliability test cases are generated according to the test profile sequence, and the specific generation process comprises the following steps:
1) In the task scene section, starting from a starting point, and extracting a task scene according to the transition probability value;
2) In the functional section, starting from a starting point, extracting single or multiple functions in sequence according to transfer relations among the functions;
3) In the test section, starting from a starting point, sequentially extracting single or multiple operations according to the transfer relation among the operations;
4) The extraction in the value range is uniform, and the random number in the value range is used as the assignment of the variable;
5) Returning to the variable layer from the value range of the assignment of the operation variables, if a plurality of variables need to be assigned at the same time in one operation, carrying out variable assignment extraction on each variable in sequence until all variables needing to be assigned in one operation are assigned;
6) The subsequent extraction of the test section;
7) Extracting the functional section subsequently;
8) Ending the test case generation;
9) Circularly executing the steps 1) to 8) until the number of the generated test cases meets the reliability test requirement; the test case generation work of the reliability test ends.
Further, the step S5 of testing the data generation algorithm includes:
and adopting an operation sequence generation algorithm, an operation generation algorithm and an operation value-taking algorithm, carrying out constraint processing by combining operation information on each operation point, and adding corresponding auxiliary information to generate a complete and executable test case.
Further, the step S5 of testing the case optimizing policy includes:
determining whether the test case set contains a boundary value test case or not, and supplementing corresponding boundary value cases for operations without generating boundary and secondary boundary values;
for an operation sequence in which the input is discrete, consider the combination relationship between the individual operations; if all the combination correlation coefficients among the operations are larger than the number of test cases distributed by the operation sequence, an orthogonal test method is adopted to optimize the randomly generated reliability test cases.
Compared with the prior art, the invention has the following beneficial effects:
the embodiment of the invention provides a networked software system reliability test section structure and a test case generation method, which comprises the following steps: identifying and describing the software state and the system state in the continuous running process of the networked software system; setting functional constraint conditions and/or operation constraint conditions by combining the identified state parameters; determining a transition probability value between functions or operations of the networked software system by adopting a preset method; constructing various types of reliability test sections according to the structure and the behavior of the networked software system and based on the application scene of the networked software system; the various types of reliability test profiles include: user profile, task scene profile, network architecture profile, functional profile, and operational profile; the method comprises the steps of completing the generation of the reliability test cases of the networked software, including test item design, input variable description, test case generation process, test data generation algorithm and test case optimization strategy, and forming a complete reliability test solution of the networked software system. The method can be used for effectively testing the reliability of the networked software, and is beneficial to improving the performance of the active equipment and the development of new generation digital armed equipment.
Drawings
FIG. 1 is a flow chart of a reliability test section structure and test case generation method for a networked software system according to an embodiment of the present invention;
FIG. 2 is a flow chart of a reliability test cross-section configuration provided by an embodiment of the present invention;
FIG. 3 is a schematic view of a task scenario provided in an embodiment of the present invention;
FIG. 4 is a schematic cross-sectional view of a network architecture according to an embodiment of the present invention;
FIG. 5 is a schematic diagram of a software reliability test case generating step according to an embodiment of the present invention;
FIG. 6 is a schematic diagram of a schematic cross-section of a scenario of a commercial command task according to an embodiment of the present invention;
FIG. 7 is a schematic cross-sectional view of a support request processing function according to an embodiment of the present invention;
fig. 8 is a schematic view of an operational section of a combat plan according to an embodiment of the present invention.
Detailed Description
The invention is further described in connection with the following detailed description, in order to make the technical means, the creation characteristics, the achievement of the purpose and the effect of the invention easy to understand.
In the description of the present invention, it should be noted that the directions or positional relationships indicated by the terms "upper", "lower", "inner", "outer", "front", "rear", "both ends", "one end", "the other end", etc. are based on the directions or positional relationships shown in the drawings, are merely for convenience of describing the present invention and simplifying the description, and do not indicate or imply that the devices or elements referred to must have a specific direction, be configured and operated in the specific direction, and thus should not be construed as limiting the present invention. Furthermore, the terms "first," "second," and the like, are used for descriptive purposes only and are not to be construed as indicating or implying relative importance.
In the description of the present invention, it should be noted that, unless explicitly specified and limited otherwise, the terms "mounted," "provided," "connected," and the like are to be construed broadly, and may be fixedly connected, detachably connected, or integrally connected, for example; can be mechanically or electrically connected; can be directly connected or indirectly connected through an intermediate medium, and can be communication between two elements. The specific meaning of the above terms in the present invention will be understood in specific cases by those of ordinary skill in the art.
Referring to fig. 1, the invention provides a method for generating a test case and a reliability test section structure of a networked software system, which comprises the following steps of;
s1, identifying and describing a software state and a system state in the continuous running process of a networked software system;
s2, setting functional constraint conditions and/or operation constraint conditions by combining the identified state parameters;
s3, determining a transition probability value between functions or operations of the networked software system by adopting a preset method;
s4, constructing various types of reliability test sections according to the structure and the behavior of the networked software system and based on the application scene of the networked software system; the various types of reliability test profiles include: user profile, task scene profile, network architecture profile, functional profile, and operational profile;
S5, completing the generation of the reliability test cases of the networked software, wherein the generation comprises test item design, input variable description, test case generation process, test data generation algorithm and test case optimization strategy, and a complete reliability test solution of the networked software system is formed.
The method can be used for effectively testing the reliability of the networked software, and is beneficial to improving the performance of the active equipment and the development of new generation digital armed equipment.
Embodiments of the present invention are described in detail below in two ways:
first aspect: reliability test profile construction of networked software system:
the network software system structure and behavior are dynamically evolved, and the running environment is a network with changeable structure and behavior. The invention provides a test section based on an application scene, which covers various types such as a user section, a task scene section, a network architecture section, a functional section, an operation section and the like.
The networking software reliability test profile construction flow is shown in fig. 2, and specifically includes the steps of user profile, task scene profile, network architecture profile, function profile, operation profile, and the like. Referring to fig. 2, each link in the test profile construction flow for networked software is described below.
(1) User profile construction
Different users have different use modes for the software, so that the user types with obvious differences for the software use should be identified first, independent user groups (with certain representativeness and not aiming at a specific user) are abstracted from the user types, and the proportion occupied by the users is counted. The construction of the user profile is a process of investigation and analysis.
The graphical symbols of the user group are consistent with the "function" and may be referred to as a user package. Described within the user package is the use of software under this type of user. The user profile is at the top of the entire test profile. For example, the user profile of a piece of software represents the 10% of the cases used by the administrator and 90% used by the general user, where the probability value is the transition probability, rather than the absolute or relative probability mentioned in the conventional test profile construction method.
(2) Task scene profile construction
The task scene can be analyzed according to the use mode of the user group of the networked software system, and different types of user groups have different purposes and habits on the use mode of the software and have larger difference. The usage mode of the networked software system is an abstraction and classification of usage modes, such as user seat usage modes of the finger control software, usage under high load and low load conditions, and usage under normal usage and maintenance conditions, standing on the standpoint of different users. The task scenes are classified, so that testers can pay attention to only one type of relatively independent user use mode in one task scene, and the reconstructed function and test section based on the task scene are more targeted.
The task scene profile needs to be analyzed in a system working mode, and a task sub-profile may exist in the task scene profile. For example, for a certain travel command software, there may be a travel level command center mode of operation, a weapon platform mode of operation, etc. in the normal mode of operation. Different system sub-modes may have an impact on the elements and inputs of the functional profile and the operational profile, e.g. the parameter inputs for the interface display function in the hotel command center mode of operation are clearly different from those in the army mode of operation. It should be noted that the functional section and the operation section under different system mode sub-sections may be substantially identical, and only the input fields of the operation variables may be different, and the same functional section and operation section may be shared in this case, which is only required to be considered when generating the test case.
Taking the combat command task scene as an example, a task scene section is constructed, and is specifically shown in fig. 3. The graphical symbol of the task scene is consistent with the function, and the graphical symbol can be called a task scene package, and the use condition of software under the task scene is described in the task scene package. It is necessary to summarize the major task scenario profile of a command software system, where each package corresponds to a combat task.
(3) Network architecture profile construction
The networked software system is deployed on a network, and each software subsystem has a respective composition system, so that the software system shows hierarchy. Integrating subsystems on the same level constitutes a hierarchy of systems that have similar or identical roles in the system.
The network architecture profile consists of several levels of network architecture, each of which may in turn contain its own sub-architecture profile, in various possible timing and association relationships. The network architecture profile can not only show the time sequence and transfer relation between the software network nodes through the relation elements, but also describe the constraint relation between the network nodes through the pre-condition and post-condition of the nodes, and can also reduce the description complexity caused by the layering of the network architecture through the form of the sub-architecture profile so as to show the logic relation of the software on the network architecture level.
After the task scene profile is analyzed, the network architecture profile construction can analyze the main node composition, the time sequence and the transfer sequence among the nodes in the network architecture layer by adopting a hierarchical analysis method. The network architecture profile analytic hierarchy process comprises the following steps:
a) An abstract system layer, which abstracts various subsystem nodes deployed on a network as a subsystem layer;
b) Analyzing a device deployment network, and constructing the device deployment network by taking various hardware devices in a network system as nodes and the communication relationship among the devices as edges;
c) Constructing a software deployment network, abstracting out software subsystems on each hardware node, replacing hardware with the software subsystems, and establishing a preliminary software deployment network;
d) Analyzing software components on a plurality of nodes, and abstracting out basic tasks of all nodes of all subsystems by using a modeling method;
e) And analyzing the dependency and transfer relation among the nodes according to the task flow, and establishing a network architecture section based on the task scene.
The above construction method constitutes a stepwise analysis process. For the command control system, various subsystems or equipment nodes deployed on a command control network are abstracted through the analysis method. Under different orchestration modes (full building, dispatching and unit system) and different command patterns (step-by-step command, override command and alternative command), main software node compositions and connection relations in the network architecture are analyzed layer by layer. And analyzing the dependency and time sequence transfer relation among the software nodes according to the operational task scene flow, and establishing a network architecture section of each layer.
Fig. 4 is a schematic diagram of a cross section of a carrier network architecture, which illustrates the network connection relationship in a step-by-step command pattern, an override command pattern, and a dispatch configuration mode.
(4) Functional profile construction
The functional profile is a hierarchical network system taking 'functions' as basic elements, and the system not only comprises information of functions and the use probability thereof, but also comprises constraint and transfer information among possible functions, and is a dynamic description profile. In principle, a functional package in a functional profile corresponds to a logically independent software function, and the content contained in the package is the set of operations belonging to that function and its usage information. If some "functions" require further analysis, then the concept of "function" sub-profiles may be used to describe. The "function" sub-section takes the "sub-function" as a basic element, takes the function package as an organization container thereof, and describes a sub-function set belonging to the function and use information thereof. It should be noted that the sub-functions are also composed of several operations and usage information thereof.
The functional profile consists of several functions in various possible timing and associative relationships, each of which in turn may contain sub-functional profiles belonging to itself. Functional profiles are very flexible concepts that can represent not only the timing and transfer relationships between functions through relational elements, but also constraint relationships between functions through preconditions and post-conditions of the functions, and can reduce the complexity of description caused by functionality hierarchy through the form of functional sub-profiles, thereby completely and clearly representing the logical relationships of software on a functional level.
In particular, when each of the functions in the function profile is isolated from each other, and there is no timing and transfer relationship, the operation profile in the conventional art is obtained, so that the operation profile in the conventional art is only a special case of improvement technology from a certain point of view.
The functional profile may be constructed using a top-down systematic approach. Firstly, an independent function set of the software can be obtained from a development requirement document of the software, the possible transfer and constraint relation between functions of the software in running is analyzed on the whole, and then, part of the functions are refined by supplementing a function sub-section. That is, in the function section, if the use condition included in the function is relatively simple, the operation section belonging to the function may be directly included in the function package thereof; if the use case is more complex, a functional sub-section can be constructed in its functional package, in which the operating section of the function is further described.
(5) Operational profile construction
An "operation" is the smallest independent task unit of software that can only consist of input variables, and there is no concept of sub-operations. If an operation is considered to be necessarily described by several operations in common when the operation is divided, the operation should be promoted to a sub-function or function. The process of constructing an operating profile is essentially a description of all operational and usage relationships within each function (or sub-function), respectively, referred to as an operating profile unit. The principle of description of the operation profile unit is substantially similar to that of the functional profile, and there are also so-called transfer relationships, constraint relationships (operation pre-or post-conditions), etc., which will not be described in detail.
It can be seen that the operation of the networked software system and its use are encapsulated within the functionality, and there is no situation where one operation can be used by multiple functions, which would be easier to understand and to calculate probability information, than a traditional desktop application.
(6) Static and dynamic state parameter identification
As software continues to run, the software or environment may be in a number of specific states that may affect subsequent software functions, operations, and parameter inputs to the operations. The "state" mainly includes two types:
1) Software state. For example, a certain type of inertial navigation software has five working states when in normal use: GC. FAST, NAV, CAL, ATT when it is determined that the current software is in the GC state, the subsequent state conversion function from the GC state to the other state can be executed only, but the state conversion function between the other states cannot be executed;
2) System status. The system state includes both static and dynamic types. The static system state is in fact a so-called environment variable as mentioned in the prior art, for example for a certain display control system, the provided display functions may differ when the resolution supported by the display is different. The dynamic system state refers to the state of other crosslinking devices in the running environment. For example, when the scout radar system crosslinked with the networked command control system is in a standby state, at this time, the command control system either executes a radar state command to reenter a normal operating state, or selects to execute a function that can be used in radar standby, but cannot directly execute other functions.
It is necessary and important to identify and describe all the more important evolution states before the operating profile of the networking software is built. Because the state changes along with the progress of the test, each test case should be generated in a targeted manner according to the current state conditions of the software and the system, so that the actual use condition of the software can be described more accurately, and the traditional reliability test case generation technology cannot reflect the dynamic real-time property.
In the operation section, the state is not described by a graph, and a state parameter table can be independently manufactured for the state, so that the state parameter table is taken as a necessary basis when the operation section is constructed and test cases are generated.
(7) Setting of constraints
Whether a function or operation can be used in a test case generation process or not, in addition to being determined by its probability of use, also considers constraints. It is usually implemented by setting so-called preconditions in the function or operation. The constraints of a function may have an effect on the operation profile elements belonging to the function, while the constraints of an operation may have an effect on the value of the input variables of the operation. The constraint condition may be derived from the value of the previous input variable, the time, or the output value of the target system whose value is unknown (in this case, the support of the use environment is needed).
The constraint condition describes the operation section when constructing the operation section, but the test case cannot be generated in advance according to the constraint condition, and whether the current function or operation meets the constraint condition or not must be judged along with the execution of the test case so as to dynamically generate a new test case. It can be seen that a "state parameter" is a special constraint.
(8) Transition probability value determination
Transfer between functions or operations is divided into two types: sequential transfer and conditional transfer. The transition probability value on the sequential transition is 1. Transition probabilities are relative probabilities that represent the likelihood of transitioning from a current profile element (function, operation, system mode, etc.) to the next profile element. Typically, absolute probability values and relative probability values for the software profile elements are derived from statistical analysis of the software usage history. In the following, a functional profile will be taken as an example, which illustrates how absolute probabilities and relative probabilities are used to calculate transition probability values on conditional transitions.
1) Expert experience judgment method. If the profile structure is simpler, the transition probability value is determined by using an expert experience method. For example, function 1 may then be transferred to function 2 or to function 3. If the expert can directly judge that the function 1 is possibly transferred to the function 2 with the probability of 0.4 or to the function 3 with the probability of 0.6 according to experience, the transition probability value from the function 1 to the function 2 can be directly determined to be 0.4, and the transition probability value from the function 1 to the function 3 is directly determined to be 0.6.
2) Objective calculation based on the "summation principle". In general, the structure of the functional profile is relatively complex, and the disadvantage that expert experience is too subjective is revealed. To this end, the present invention provides an objective calculation method for calculating a transition probability value between functions using absolute probability values of functions, which has the core concept that firstly, a history of software use is collected, absolute use probability of each function is calculated using a ratio of the total number of times each function is operated to the total number of times all functions are operated, and then the transition probability value between functions is calculated according to a "summation principle" to be described below.
Let the functional section of the software have n functions in total, and the absolute probability of the functions is thati e {1,2, …, n }; a software functional profile is constructed (only the possible transitions between functions, no probability values have yet been transferred). For function f i Is provided with a common path in the functional section i The transfer path (a path formed by several functions and transfer from the start point to the end point) can pass through the function f i These transfer paths are called functions f i Is provided. Recording function f i Is (k=1 … path) i ) On share K ik The probability of one transition (absolute or relative) is noted as tp ikj (j＝1,2，…K ik ，tp ikj And is less than or equal to 1). Then at function f i The sum of all transition probability products on each of the previous reachable paths should be equal to the function f i Absolute probability of use of (1), namely:
(summing principle).
According to the summation principle, the probability value of each transition in the functional section can be accurately calculated by adding some necessary normalization works in combination with the constraint that the sum of all transition probabilities from one function must be 1.
The absolute probability values of the obtaining functions 1 to 4 are set to be 0.4, 0.3, 0.2 and 0.1 respectively according to the historical data of the software. Then p can be derived from the "sum criterion 01 ＝0.4，p 02 ＝0.3，p 01 *p 13 ＝0.2，p 02 *p 24 =0.1, thereby calculating p 13 ＝0.5，Combining all transition probabilities from one function to be 1, the final all transition probabilities are respectively obtained as follows:
p 13 ＝0.5，/>p 15 ＝0.5，/>p 35 ＝p 45 ＝1
and after the steps are all completed, the operation section of the networked software reliability test is constructed.
In a second aspect, networked software system reliability test case generation:
on the basis of the test section construction, the reliability test case generation method suitable for the networked software system is shown in fig. 5, and comprises the following specific contents:
(1) Input variable description
An input variable is a specific implementation of an operation, which consists of one or several variables. One-time operation of the operation is realized by one-time value of the input variable set to which the operation belongs, so that the description of the input variable directly influences the generation of the test case. The input variable description of the networked software system is not a simple input domain division, and the value of the input variable may be affected by various factors, such as time factors, constraints, variable types, and the like. Not only is the combinational logic covered according to the system structure diagram, but also the time sequence consistency is met according to the time sequence diagram. The influence of the networking characteristics on the running result of the software is also a factor to be considered in the generation of the test cases, and the special distributed characteristics of the test cases, including interaction, cooperation, competition and the like among different resources, should be fully considered. Test case generation cannot be limited to steady-state input and output, and also needs to consider the emergence, synergy, uncertainty and dynamic evolution of system group behaviors. The traditional technology has very simple description of input variables, and can not meet the requirement of the reliability test of the networked software. Therefore, the invention researches the description method of the input variable according to the characteristics of the networking software.
For networking software, there are two common established principles for input variables: one is established according to the external interface relation of the networked software system; one is based on a logical relationship between timing and information flow.
1) Establishing input variables according to interface relation of target system
And establishing an input variable according to the interface relation of the target system, so that the established input variable directly corresponds to the interface relation of the target system. The establishing process is visual, and the data members in the input variables are only required to be organized into a required format when the test data are generated. The input variable establishing mode is suitable for some digital interfaces, such as buses of CAN, MIL-STD-1553B, flexray, ARINC, ARINC629 and the like, and CAN directly obtain the member information of the input variable data from the formats of the data frames.
2) Establishment according to the logic relation between time sequence and information flow
The method is characterized in that the input variables are built according to the time sequence and information flow logic relationship, mainly by utilizing the ideas of object-oriented and distributed, the input variables are further packaged from the angles of input time and logic relationship, the expression and organization are convenient, and the form of the input variables is similar to the input variables built according to the interface relationship of a target system. This principle comparison applies to analog inputs and to discrete inputs that are not very related to each other. For analog inputs, it encapsulates temporally consistent analog quantities into the same input variable type. The basic steps are as follows: the input variables are classified into continuous type and discrete type inputs. Continuous input variables can be classified as one input variable type if they have the same input time and have the same or multiple of the sampling period, and vice versa. For example, input variables representing voltage and current are all input in 0-1000 seconds and have the same sampling period, they can be abstracted into two data members of one input variable type. If the input time of the current input variables is 0-50 seconds and the voltage input variables is 30-80 seconds, it is not appropriate that they are abstracted as data members of the same input variable type.
Discrete input variables that are not very related to each other typically represent switching or control commands, and do not emphasize temporal consistency, so the packaging process is simpler and can be performed as needed. For example, a control command of a certain type may be encapsulated into the same input variable type.
(2) Test case generation process
According to the reliability test section of the networking software provided by the invention, after the input scalar of all operations is described, the required reliability test cases can be generated according to the test section sequence. The specific generation steps are as follows:
and step one, extracting a task scene. For example, in a task scene section, from a starting point, there are two probability transitions, one transition to a "maintenance mode" with probability 0.3, and the other transition to a "management mode" with probability 0.7, a random number η, η e (0, 1) is generated corresponding to the two probability intervals (0, 0.3) and (0.3,1), and it is observed which probability interval η falls in, if η satisfies (0.3,1), η corresponds to the probability value of 0.7, then the randomly extracted task scene is the "management mode", and conversely, if η satisfies (0, 0.3), η corresponds to the probability value of 0.3, then the randomly extracted task scene is the "maintenance mode", and after extracting to a task scene, it enters the corresponding function section, and performs function extraction.
And secondly, extracting functions. In the functional section, from the starting point, a single or a plurality of functions are sequentially extracted according to the transfer relation between the functions. If probability transition exists, the function is extracted according to the extraction principle of the first step. After extracting one function, entering a test section of the function, and performing operation extraction.
And thirdly, operating extraction. In the test section, single or multiple operations are sequentially extracted from a starting point according to the transfer relation between the operations. If the probability is transferred, operation extraction is performed according to the extraction principle of the first step. After an operation is extracted, the variable assignment extraction for the operation is started.
And fourthly, variable assignment extraction. Assume that a variable of an operation is an integer value, ranging from 0 to 360. If the variable is set to be uniformly extracted in the value range, a random number is generated between 0 and 360 according to uniform distribution as the assignment of the variable. Correspondingly, if the extraction of the variable in the value domain has a specific requirement, a random number is generated between 0 and 360 according to a specific distribution rule to be used as the assignment of the variable. In particular, if the variable has multiple selectable value ranges, the value range needs to be extracted first, and then assignment extraction is performed in the extracted value range. Thus far, through layer-by-layer extraction, a running instance of an operation has been generated, but it cannot be said that a test case has been generated, and the running instance may be only a subset of the test cases.
And fifthly, extracting assignment among variables. And returning to the variable layer from the assignment value field of the operation variable, if a plurality of variables need to be assigned simultaneously in one operation, carrying out variable assignment extraction on each variable in sequence as described in the fourth step until all variables needing to be assigned in one operation are assigned.
And sixthly, the subsequent extraction of the test section. After the variable in one operation in the test section is assigned, returning to the test section, extracting all possible operations after the assigned operation according to the transfer relation among the operations in the test section, and carrying out corresponding variable assignment until the end mark of the test section, and ending the test section extraction and variable assignment under the function.
And seventh, the subsequent extraction of the functional profile. And after the operations and the variables of the operations in one of the functional sections are extracted and assigned, returning to the functional section, extracting all the functions possibly executed after the selected functions according to the transfer relation among the functions in the functional section, and carrying out corresponding operation extraction and variable assignment until the end mark of the functional section is reached, and ending the functional section extraction in the task scene.
And eighth, ending the test case generation. In general, since each system mode in a task scene section is independent, one test case is generated after the extraction of a function section in one task scene is completed. It can be seen that in the present invention, a test case is actually a collection of instantiations of several functions and their operations (i.e., assignment extraction of manipulated variables) in sequence.
And ninth, repeatedly executing the first step to the eighth step until the number of the generated test cases meets the reliability test requirement. The test case generation work of the reliability test ends.
Therefore, the method for generating the reliability test case for the networking software is a repeated process from top to bottom. It should be noted that if a precondition exists in a task scenario, a function or an operation to be extracted, whether the extraction is valid should be determined according to whether the current condition satisfies the precondition, and if the current condition does not satisfy the precondition of the system mode, the function or the operation, the extraction is considered invalid even if the extraction reaches the system mode, the function or the operation, and the probability of occurrence of other usage relationships needs to be correspondingly improved (this is a dynamic adjustment process) to re-perform the extraction.
(3) Test data generation algorithm
The software reliability test data generation process is a process of organizing data according to information described by the established usage model and the test input model and randomly sampling. Because constraint conditions and some numerical calculation relations exist in the usage model and the test input value model, such as operation and package preconditions, branch conditions in operation descriptions, member functions in usage classes, straight lines and curve equations in continuous operation descriptions and the like, which influence the generation of test data from the angles of logic branching and numerical calculation, the generation process of the test data is not random sampling in a simple sense, and also comprises logic operation and numerical calculation. And according to whether the determined operation sequence can be obtained in the test data generation process, further randomly selecting operation to obtain complete test data.
1) Operation sequence generation algorithm
The operation sequence acquisition can adopt a method of traversing the operation section deeply. Each time starting from a uniquely determined starting point, traversing the path that can be traversed using the relationship to a uniquely determined ending point, a traversal being a process in which the software is actually running. The probability of occurrence of an operation sequence is the product of the probabilities of the operations traversed at one pass. According to the method, after all paths are traversed, all path sequence information, namely all actually running process information of the software, can be obtained. The specific traversal algorithm is as follows:
The most important of the algorithm is the acquisition of an AdjMatrix [ i ] [ j ] of the vertexes in the graph, if i, j in the graph are adjacent, the AdjMatrix [ i ] [ j ] >0, and the value of the AdjMatrix is the transition probability from the vertex i to the vertex j. For a test profile comprising multiple layers of sub-profiles, if the adjacency matrix of the actual usage profile that can have multiple layers of sub-profiles is abstracted, all paths from the start point to the end point can be found using the search algorithm.
2) Operation generation algorithm
The operation is selected randomly according to the occurrence probability of the operation in the operation section, and the operation can be automated. The algorithm for randomly selecting an operation according to the occurrence probability is divided into the following two steps.
The first step: a section between each operation or sequence of operations i and 0,1 is associated, the length of the section being equal to the probability level P (i) that the operation occurs.
And a second step of: any random number eta epsilon (0, 1) is given, which interval eta falls in is observed, the corresponding P (i) is found, and the corresponding operation is selected.
The random selection operation algorithm is as follows:
the randomly pumped run is Oj.
3) Operation value algorithm
After a certain operation is selected, a specific value in each operation interval in running needs to be determined. The specific implementation method is as follows:
After the operation and the specific numerical values are extracted, constraint processing is carried out by combining the operation information on each operation point, and corresponding auxiliary information is added, so that a complete and executable test case can be generated.
(4) Test case optimization strategy
By randomly generating cases by the test profile, the combination relationships between the individual important test cases and operations, such as boundaries, associations, transition cases, etc., may sometimes be ignored. In order to expose more software failures and improve the reliability test efficiency of the software, randomly generated reliability test cases should be optimized and necessary test cases should be supplemented.
First, it is determined whether the test case set contains boundary value test cases. Software errors tend to occur at the boundaries of the input or output range. Therefore, to determine the boundary condition and the sub-boundary condition of each operation, the operation which does not generate the boundary and the sub-boundary value is supplemented with the corresponding boundary value use case.
Secondly, for an operation sequence with discrete input, fully considering the combination relation among the operations, if all the combination relation coefficients among the operations are larger than the number of test cases distributed by the operation sequence, namely, the randomly generated test cases cannot cover all the combination relations, and at the moment, a higher coverage rate and a better test effect can be achieved by adopting an orthogonal test method. The basic idea is to introduce the experimental design method into the test, and the specific method is as follows:
1) And constructing a factor state table. Each individual parameter in the operating profile is considered a factor and the different values of each parameter are considered horizontal. Determining factors and states is critical to designing test cases. The value is determined as comprehensively as possible so as to ensure that the design of the test case is complete and effective.
2) Importance weighting, the choice of factors and states may be weighted by their importance. The weight can be determined according to the action of each factor and state, the frequency of occurrence and the test requirement.
3) The corresponding test data sets are supplemented with orthogonal tables.
The reliability test cases are optimized and supplemented, the use characteristics and the random characteristics of the test cases are ensured, and meanwhile, higher test coverage is achieved, so that the quality of the test cases is improved, the software reliability test process is accelerated, and the software reliability test efficiency is improved.
Aiming at the characteristics of a networked software system, the invention provides a test section construction method based on application scenes, analyzes specific application scenes of the networked software system, provides a specific test section construction method process, covers various types such as a user section, a network architecture section, a task scene section, a functional section, an operation section and the like, solves the problem that the traditional Musa test section construction method cannot completely meet the requirements of the characteristics of the networked software system, and can characterize the distribution, autonomy and heterogeneous system characteristics of the networked software. Based on the test section, the invention further provides a method for generating the reliability test case of the networked software system, which comprises a specific generation algorithm and an optimization strategy, and describes input scalar of all operations to generate the specific reliability test case. The method has high error uncovering efficiency of the test cases, can cover the combination logic, is not limited to steady-state input and output aiming at the special distributed characteristics of the networked software system, can also describe the cooperation of the network structure characteristics and the system behaviors of the system, and realizes the efficient generation of the networked software test cases and the test data.
The technical scheme of the invention is illustrated by way of example below:
for example, the application implementation of a case is completed aiming at a certain model of command system software, the reliability test profile construction and the test case design generation are carried out, the complete test profile is constructed, the reliability test case set is formed, the test implementation and execution are completed, the designed reliability test profile and the test requirement are covered, and the rationality and feasibility of the proposed method are verified.
Because of the sensitivity of the model item content, specific technical details are omitted, and only the general part is described.
Example software Profile
The system comprises a camping command post, a machine step connection, an assault connection, a mortar connection, an air defense connection, a guarantee team, complete information reconnaissance, command control, technical guarantee and other equipment, and can realize the whole-course automatic command from target acquisition, information processing and transmission, command decision and weapon equipment control. The command software system can be deployed on corresponding seat computers of a camping command vehicle, an auxiliary camping command vehicle, a mortar continuous command vehicle, an air defense continuous command vehicle, a machine step continuous command vehicle, an assault continuous command vehicle, a reconnaissance vehicle and a target indication radar, and different service functions are started according to different software of a unified configuration strategy and a user role, so that the operational requirements of various levels of command equipment and reconnaissance equipment are met.
(II) reliability test Profile construction
The command software system structure and behavior are dynamically combined and changed, and the operation environment is on computers of various equipment such as a command post, various arms and links, a scout car, a target command radar and the like, and the node equipment is built into a network with changeable structure and behavior through a radio station, a LAN interface and the like. The invention researches and builds a complete test section, and covers various types such as a user section, a task scene section, a network architecture section, a functional section, an operation section and the like.
Space is limited by just two typical profile examples. The task scene of the command software system can be analyzed according to the use modes of the command software system on specific user seats on different vehicles, and users on different seats have different task scenes and operation flows for software use. Taking a combat command task scene as an example to construct a task scene section, wherein the combat command task scene flow generally comprises the flows of task receiving, combat preparation, combat implementation, cooperative action, combat transfer and the like.
The section of the barrage command task scene is specifically shown in fig. 6: wherein the combat mission requires input of enemy sketch and my sketch mission and release. The organization starting function requires to select a starting scheme, the organization completes the starting of the system, and the organization stores a transfer route. The preparation guidance is to input various preparation parameters of normal abnormality on command software of the camping command vehicle according to a camping preparation guidance flow.
According to the scene flow of the operation command task, specific function sections are respectively constructed for the functions, including fight task, organization start, preparation guidance, support request processing, quick command, fight action management and fight evaluation. The support request processing function is shown in detail in FIG. 7.
The operational profile of the combat plan is shown in figure 8.
(III) reliability test case design and Generation
Firstly, designing reliability test items according to a test section, defining and refining each measurable requirement in the section, analyzing 13 groups of reliability test requirements according to task scene sections, functional sections, operation sections and the like in the test section, software development task books and software requirement specification, dividing 13 reliability test items, further dividing test sub-items by combining the functional sections and the operation sections, and respectively describing the specific test method and steps, test input and output, judgment criteria and other elements of each measurable requirement.
Based on the test case generation process and the test data generation algorithm in the invention, the command software reliability test case set is generated, and all designed reliability test items are covered, wherein the reliability test cases specifically comprise software single operation and system operation, and can respectively support and complete the single operation reliability test process and the system operation reliability test process.
It will be apparent to those skilled in the art that various modifications and variations can be made to the present invention without departing from the spirit or scope of the invention. Thus, it is intended that the present invention also include such modifications and alterations insofar as they come within the scope of the appended claims or the equivalents thereof.
Claims (5)
1. A networked software system reliability test section structure and test case generation method is characterized by comprising the following steps of;
s1, identifying and describing a software state and a system state in the continuous running process of a networked software system;
s2, setting functional constraint conditions and/or operation constraint conditions by combining the identified state parameters;
s3, determining a transition probability value between functions or between operations of the networked software system by adopting a preset method;
s4, constructing various types of reliability test sections according to the structure and the behavior of the networked software system and based on the application scene of the networked software system; the various types of reliability test profiles include: user profile, task scene profile, network architecture profile, functional profile, and operational profile;
S5, completing the generation of the reliability test cases of the networked software, wherein the generation comprises test item design, input variable description, test case generation process, test data generation algorithm and test case optimization strategy, and a complete reliability test solution of the networked software system is formed;
wherein, constructing the user profile in the step S4 includes:
identifying user types which are obviously different from the networked software system, abstracting independent user groups from the user types, and counting the proportion occupied by the user groups to complete the construction of the user profile;
the constructing a task scene profile in step S4 includes:
analyzing a task scene according to the use mode of the user group of the networked software system;
the method comprises the steps of abstracting and classifying the use modes according to the standpoint of different users, and determining the use mode of a networked software system;
classifying the task scenes, so that a tester only pays attention to one type of independent user use mode in one task scene, and completing the construction of the task scene profile;
the constructing a network architecture profile in step S4 includes:
after analyzing the task scene section, analyzing the node composition in the network architecture layer by adopting a hierarchical analysis method, and completing the construction of the network architecture section along with the time sequence and the transfer sequence among the nodes;
The method adopts an analytic hierarchy process to analyze the node composition in the network architecture layer by layer, and the time sequence and the transfer sequence among the nodes to complete the construction of the network architecture section, and specifically comprises the following steps:
a) Abstract system hierarchy: abstracting various subsystem nodes deployed on a network to serve as a subsystem layer;
b) The analysis device deploys the network: taking various hardware devices in a network system as nodes and the communication relation among the devices as edges to construct a device deployment network;
c) Constructing a software deployment network: abstracting the software subsystem on each hardware node, replacing hardware with the software subsystem, and establishing a preliminary software deployment network;
d) Analyzing software components on a plurality of nodes, and abstracting each node task of each subsystem by using a modeling method;
e) According to the task flow, analyzing dependency and transfer relation among nodes, and establishing a network architecture section based on a task scene;
the constructing a functional profile in step S4 includes:
acquiring an independent function set of the software from a development requirement document of the software, and analyzing transfer and constraint relations among functions of the software in running on the whole;
part of functions are thinned by supplementing the functional sub-sections, so that the structure of the functional sections is completed;
The constructing an operation profile in step S4 includes:
all operations and usage relationships within each function or sub-function are described separately, completing the construction of the operational profile.
2. The method for generating a test case and a reliability test profile structure for a networked software system according to claim 1, wherein the step S1 comprises:
identifying the current working state of the software in the continuous running process of the networked software system, and confirming the conversion relation between the current working state and other working states in the subsequent running process;
identifying environment variable parameters in the continuous running process of the networked software system, and identifying the states of peripheral equipment interacted with the environment in the running environment;
and according to the identified state and/or parameters, the description of the state is realized by constructing a state parameter table.
3. The method for generating a test case and a reliability test profile structure for a networked software system according to claim 1, wherein the step S3 comprises:
judging a transition probability value between functions or between operations of the networked software system by adopting an expert experience judging method;
or alternatively
And determining a transition probability value between functions or between operations of the networked software system by adopting a summation principle.
4. The method for generating a test case and a reliability test profile of a networked software system according to claim 1, wherein the inputting variable description in the step S5 comprises:
and completing the input variable description according to the external interface relation of the networked software system or according to the time sequence and information flow logic relation.
5. The method for generating a test case and a test profile for reliability test of a networked software system according to claim 4, wherein the test case generating process in step S5 comprises:
after the input scalar of all operations is described, the required reliability test cases are generated according to the test profile sequence, and the specific generation process comprises the following steps:
1) In the task scene section, starting from a starting point, and extracting a task scene according to the transition probability value;
2) In the functional section, starting from a starting point, extracting single or multiple functions in sequence according to transfer relations among the functions;
3) In the test section, starting from a starting point, sequentially extracting single or multiple operations according to the transfer relation among the operations;
4) The extraction in the value range is uniform, and the random number in the value range is used as the assignment of the variable;
5) Returning to the variable layer from the value range of the assignment of the operation variables, if a plurality of variables need to be assigned at the same time in one operation, carrying out variable assignment extraction on each variable in sequence until all variables needing to be assigned in one operation are assigned;
6) The subsequent extraction of the test section;
7) Extracting the functional section subsequently;
8) Ending the test case generation;
9) Circularly executing the steps 1) to 8) until the number of the generated test cases meets the reliability test requirement; the test case generation work of the reliability test ends.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211537772.XA CN115827453B (en) | 2022-12-01 | 2022-12-01 | Reliability test section structure and test case generation method of networked software system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211537772.XA CN115827453B (en) | 2022-12-01 | 2022-12-01 | Reliability test section structure and test case generation method of networked software system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN115827453A CN115827453A (en) | 2023-03-21 |
| CN115827453B true CN115827453B (en) | 2023-09-08 |
Family
ID=85543732
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202211537772.XA Active CN115827453B (en) | 2022-12-01 | 2022-12-01 | Reliability test section structure and test case generation method of networked software system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN115827453B (en) |
Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101894068A (en) * | 2010-05-31 | 2010-11-24 | 北京航空航天大学 | Embedded software reliability accelerated test method |
| CN102662841A (en) * | 2012-04-01 | 2012-09-12 | 北京航空航天大学 | Constitution method of comprehensive reliability testing profile for both software and hardware |
| CN103914353A (en) * | 2014-04-17 | 2014-07-09 | 北京航空航天大学 | Combined test method for combining software reliability tests with hardware reliability tests |
| CN109933047A (en) * | 2019-03-22 | 2019-06-25 | 北京航空航天大学 | A kind of joint reliability test sectional plane building method of software and hardware hybrid system |
| CN111639141A (en) * | 2020-05-26 | 2020-09-08 | 李云祥 | Data testing method and device and computer terminal |
| CN112860570A (en) * | 2021-03-06 | 2021-05-28 | 东南大学 | Software and hardware hybrid system combined test profile construction method based on combined test |
| CN113190457A (en) * | 2021-05-17 | 2021-07-30 | 中国船舶工业综合技术经济研究院 | Software reliability evaluation method for networked system |
| CN113296126A (en) * | 2021-04-25 | 2021-08-24 | 中国空间技术研究院 | Reliability verification and evaluation method for autonomous navigation software |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP5854274B2 (en) * | 2012-03-28 | 2016-02-09 | ソニー株式会社 | Information processing apparatus and method, and program |
-
2022
- 2022-12-01 CN CN202211537772.XA patent/CN115827453B/en active Active
Patent Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101894068A (en) * | 2010-05-31 | 2010-11-24 | 北京航空航天大学 | Embedded software reliability accelerated test method |
| CN102662841A (en) * | 2012-04-01 | 2012-09-12 | 北京航空航天大学 | Constitution method of comprehensive reliability testing profile for both software and hardware |
| CN103914353A (en) * | 2014-04-17 | 2014-07-09 | 北京航空航天大学 | Combined test method for combining software reliability tests with hardware reliability tests |
| CN109933047A (en) * | 2019-03-22 | 2019-06-25 | 北京航空航天大学 | A kind of joint reliability test sectional plane building method of software and hardware hybrid system |
| CN111639141A (en) * | 2020-05-26 | 2020-09-08 | 李云祥 | Data testing method and device and computer terminal |
| CN112860570A (en) * | 2021-03-06 | 2021-05-28 | 东南大学 | Software and hardware hybrid system combined test profile construction method based on combined test |
| CN113296126A (en) * | 2021-04-25 | 2021-08-24 | 中国空间技术研究院 | Reliability verification and evaluation method for autonomous navigation software |
| CN113190457A (en) * | 2021-05-17 | 2021-07-30 | 中国船舶工业综合技术经济研究院 | Software reliability evaluation method for networked system |
Non-Patent Citations (1)
| Title |
|---|
| 基于使用剖面的软件可靠性测试用例生成方法;张旭 等;《计算机仿真》;第26卷(第12期);66-69 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN115827453A (en) | 2023-03-21 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11481309B2 (en) | Capability test method based on joint test support platform | |
| CN112580217A (en) | Communication system structure parameterization modeling method based on complex network | |
| CN108229685A (en) | A kind of unmanned Intelligent Decision-making Method of vacant lot one | |
| CN111782544B (en) | Software radio conformance testing method based on multi-population genetic algorithm | |
| KR101732319B1 (en) | IRIS: Goal-oriented big data business analytics framework | |
| CN112632744A (en) | Combat system architecture modeling method and space exploration algorithm based on hyper-network model | |
| CN110866602A (en) | Method and device for integrating multitask model | |
| CN113435033A (en) | Multi-resolution-based complex system operation flow simulation method and system | |
| Dortmans | Forecasting, backcasting, migration landscapes and strategic planning maps | |
| CN116016206A (en) | Elasticity evaluation method and system of unmanned cluster system in open environment | |
| CN105391490B (en) | A kind of satellite communication network selection algorithm based on cognition | |
| CN101715203A (en) | Method and device for automatically positioning fault points | |
| Mehraghdam et al. | Placement of services with flexible structures specified by a YANG data model | |
| CN115827453B (en) | Reliability test section structure and test case generation method of networked software system | |
| Audrito et al. | Fostering resilient execution of multi-agent plans through self-organisation | |
| Fu et al. | Modeling and performance analysis of product development process network | |
| Gassara et al. | Towards a multi-scale modeling for architectural deployment based on bigraphs | |
| CN106529061B (en) | Aircraft evaluation method and evaluation system | |
| CN114757448B (en) | Manufacturing inter-link optimal value chain construction method based on data space model | |
| CN109889366A (en) | Network flow accrual accounting, analysis method and system | |
| Khan et al. | GAN and DRL based intent translation and deep fake configuration generation for optimization | |
| Gill et al. | Approaches for software performance modelling, cloud computing and openstack | |
| Adams et al. | Mixed initiative planning and control under uncertainty | |
| Vega et al. | Exploring local service allocation in community networks | |
| Bianchessi et al. | A mathematical programming algorithm for planning and scheduling an earth observing SAR constellation |
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 |