CN108549598B

CN108549598B - Software testing method and system

Info

Publication number: CN108549598B
Application number: CN201810194311.4A
Authority: CN
Inventors: 王晓华; 王金波; 张涛; 瞿跃龙; 马云云
Original assignee: Technology and Engineering Center for Space Utilization of CAS
Current assignee: Technology and Engineering Center for Space Utilization of CAS
Priority date: 2018-03-09
Filing date: 2018-03-09
Publication date: 2021-09-24
Anticipated expiration: 2038-03-09
Also published as: CN108549598A

Abstract

The invention relates to a software testing method and a system, belonging to the technical field of software testing. The method comprises the following steps: acquiring requirement information in a software requirement protocol of software to be tested; splitting a software requirement specification according to requirement information to obtain a plurality of characteristics, wherein each characteristic comprises: characteristic information; according to task boundary information in each piece of feature information, splitting features corresponding to each piece of feature information to obtain a plurality of feature elements, wherein one feature corresponds to at least one feature element, and the feature elements comprise: feature meta-item information; and testing the software to be tested according to each feature element. On one hand, the method avoids the technical defects that the test process in the prior art is complex, the test basis is mixed, the test coverage is incomplete, the test result is difficult to reuse, the test result is wrong and the like; on the other hand, the requirement specification and the test analysis are displayed by taking the characteristic elements as the core, and the technical effect of efficiently and accurately testing the software to be tested is realized.

Description

Software testing method and system

Technical Field

The embodiment of the invention relates to the technical field of software testing, in particular to a software testing method and system.

Background

Software testing is one of key links and main means for ensuring the characteristics of software such as function, performance, credibility and reliability and the like to be approved by both parties of supply and demand. The software testing object is various types of software such as a computer, an embedded type software, a web software and the like, the testing basis is a software requirement specification, and the software requirement specification is implemented by a person independent of software development to check whether the software implementation is consistent with the software requirement.

In the prior art, software to be tested is tested by a software requirement specification described according to a natural language. In the software testing process, the testing process is complex, and various technical defects such as mixed testing bases, incomplete testing coverage, difficult test result multiplexing, wrong test results and the like are easily caused.

Disclosure of Invention

In order to solve the above technical problems, embodiments of the present invention provide a software testing method and system.

According to an aspect of an embodiment of the present invention, an embodiment of the present invention provides a software testing method, including:

acquiring requirement information in a software requirement protocol of software to be tested;

splitting the software requirement specification according to the requirement information to obtain a plurality of characteristics, wherein each characteristic comprises: characteristic information;

according to task boundary information in each piece of feature information, splitting features corresponding to each piece of feature information to obtain a plurality of feature elements, wherein one feature corresponds to at least one feature element, and the feature elements comprise: feature meta-item information;

and testing the software to be tested according to each feature element.

The embodiment provides that: the software requirement specification is split according to the acquired requirement information to obtain a plurality of characteristics, and the characteristic element item is determined according to the characteristic information in the characteristics so as to test the software to be tested according to the characteristic element item, so that on one hand, the technical defects that the test process is complex and wrong test results are easily generated in the prior art are avoided; on the other hand, the requirement specification and the test analysis are displayed by taking the feature elements as the core, so that the technical effect of efficiently and accurately testing the software to be tested is realized.

According to another aspect of embodiments of the present invention, there is provided a computer-readable storage medium including instructions which, when executed on a computer, cause the computer to perform the method as described above.

According to another aspect of the embodiments of the present invention, there is provided a terminal configured to perform the above method.

According to another aspect of an embodiment of the present invention, there is provided a software testing system including:

an acquisition module: the method comprises the steps of acquiring requirement information in a software requirement protocol of software to be tested;

splitting the module: the software requirement specification is split according to the requirement information to obtain a plurality of characteristics, wherein each characteristic comprises: the method comprises the steps of obtaining feature information, splitting features corresponding to each feature information according to task boundary information in each feature information to obtain a plurality of feature elements, wherein one feature corresponds to at least one feature element, and the feature elements comprise: feature meta-item information;

a test module: and the software to be tested is tested according to each feature element.

Drawings

Fig. 1 is a schematic flowchart of a software testing method according to an embodiment of the present invention;

FIG. 2 is a schematic structural diagram of a feature space provided in an embodiment of the present invention;

FIG. 3 is a flowchart illustrating a software testing method according to another embodiment of the present invention;

FIG. 4 is a schematic structural diagram of a software testing system according to an embodiment of the present invention;

FIG. 5 is a schematic structural diagram of a software testing system according to another embodiment of the present invention;

fig. 6 is a diagram of a test example of a microsatellite attitude and orbit control software according to an embodiment of the present invention.

Detailed Description

In the following description, for purposes of explanation and not limitation, specific details are set forth such as the particular system architecture, interfaces, techniques, etc., in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced in other embodiments that depart from these specific details. In other instances, detailed descriptions of well-known methods and systems are omitted so as not to obscure the description of the present invention with unnecessary detail.

The embodiment of the invention provides a software testing method and system.

According to an aspect of an embodiment of the present invention, an embodiment of the present invention provides a software testing method.

Referring to fig. 1, fig. 1 is a schematic flow chart illustrating a software testing method according to an embodiment of the present invention.

As shown in fig. 1, the method includes:

s100: acquiring requirement information in a software requirement protocol of software to be tested;

s200: splitting a software requirement specification according to requirement information to obtain a plurality of characteristics, wherein each characteristic comprises: characteristic information;

s300: according to task boundary information in each piece of feature information, splitting features corresponding to each piece of feature information to obtain a plurality of feature elements, wherein one feature corresponds to at least one feature element, and the feature elements comprise: feature meta-item information;

s400: and testing the software to be tested according to each feature element.

Each feature corresponds to a unique feature identifier, and each feature element corresponds to a unique feature element identifier.

In this embodiment, the features are split according to the task boundary information to obtain feature elements. That is, a feature element has an independent basic functional feature, which has the same interface attribute as the feature to which it belongs, but has a different task boundary from other feature elements that are not the feature element itself, and the feature element is denoted META.

In the process from the feature iteration to the feature meta item, the decomposition of the elements in the attached feature set F corresponding to the meta item is iterated step by step, and finally the attached feature elements fi are decomposed to each feature meta item. If the relationship set contained in the natural language description requirement between the feature elements is LR, the set relationship of the logical relationship of the feature elements is RELATION ═ F ═ u LR. The feature space SP can be represented by:

SP: B × F (formula 1)

SP: META | fun < < META × RELATION > (formula 2)

In formula 1, B × F represents that the feature space is composed of basic features and attached features attached thereto according to logical relationships inherent in the basic features and required by the attached features.

Relative in formula 2 represents a set formed by legal logical RELATIONs of feature elements, a feature space expressed (explicitly expressed or implied) in a software requirement specification can be constructed from META x relative according to logic specified by a function fun, and similarly, a composite feature can also be constructed. That is, for a feature space or a certain defined feature, it can be hierarchically expanded into an expression containing only feature elements by continuously decomposing and replacing compound features in the expression.

In a possible implementation solution, after S200, the method further includes:

constructing a feature space according to each feature;

and testing the software to be tested according to the characteristic space.

In the prior art, a software requirement specification is used as a basis for testing software. However, the software requirement specification has the problems of complexity, ambiguity, incompleteness, non-specification and the like, so when the software to be tested is tested by taking the software requirement specification as a basis, the technical disadvantages of complex test and inaccurate test result are easily caused. In order to avoid the technical disadvantage, the embodiment of the invention provides a software testing method.

In this embodiment, the requirement information in the software requirement specification is acquired first, and specifically, the requirement information can be acquired by analyzing the software requirement specification.

It can be understood that the requirement information includes a plurality of requirements, and the software requirement specification is split according to different requirements to obtain a plurality of characteristics. Features can be understood as the way in which the specification of software requirements is partitioned and organized. Different features may represent different capabilities or features, reflecting different requirements and understandings. It follows that features are functional and that different features have different functions, and that features may also be understood as requirements for quality attributes, constraints, etc.

And constructing a feature space by using the obtained multiple features. For example: and when the number of the features is 10, constructing a feature space according to the 10 features, and using the feature space as a basis for testing the software to be tested, thereby realizing the test of the software to be tested.

In a technical solution that may be implemented, constructing a feature space according to each feature specifically includes:

classifying the plurality of features according to each feature information to obtain a basic feature and an auxiliary feature;

determining a main node of the initial feature space according to the basic features;

determining the sub-nodes of the initial feature space according to the auxiliary features;

and determining a feature space according to the main node, the sub-nodes and the initial feature space.

Specifically, when the features are taken as basic organization units, the feature space can be expressed as follows:

where B is { B1, B2, …, bm }, and F is { F1, F2, …, fn }.

Where S is the feature space, B is the set of base features, and fi (i ∈ 1,2, …, n) is a number of attached features attached to the base feature set. That is, the features include basic features, attached features attached to the basic features.

Referring to fig. 2, fig. 2 is a schematic structural diagram of a feature space according to an embodiment of the present invention.

As shown in fig. 2, if the software requirement specification is complete and can be cut according to effective files such as a contract and a software evaluation task book, the feature space is a subset of the software requirement specification, and the content of the software test is included therein.

The feature space not only displays the logical relationship between the basic features, but also corresponds the performance, constraint relationship and the like to the related basic functional features. The process can easily find the problems of missing, logic abnormality, unquantized performance and the like of the software requirement specification on the functional items, thereby being capable of communicating with a developer in time to solve the problems.

The feature space may be considered a directed connected graph. The node is a basic feature in the B set or an auxiliary feature depending on the B in the F set, and the edge is various relationships of the node, such as dependency, mutual exclusion, conjunction, disjunction and the like. The characteristics of the F set depend on the elements of the B set, and each fi can be embodied in the elements of the B set by the logical operations of dependence, multiple selection and the like. Node elements may be decomposed into smaller granularity features and edges may be decomposed into more detailed relationships to represent logic between smaller granularity features.

In a technical solution of a possible implementation, the method further includes:

constructing a feature space according to each feature;

constructing a feature element space according to each feature element, each feature and the feature space;

and testing the software to be tested according to the feature element space.

In this embodiment, it can be understood that, when constructing the feature space: by identifying the basic feature set B and the accessory feature set F, the feature space expressed by formula (1) is composed. In the software test, input driving software runs, and output verification software is correct or not, and the input driving software and the output verification software are essential elements of basic features. Defining the interface set of the software as INF, the feature input set as Ib, the output set as Ob,

wherein:

let B be the basic feature element, B be the basic feature set,

the input set Ib and the output set Ob of the b are respectively subsets of the software interface set INF and simultaneously satisfy

The functional requirement points defined in the software requirement specification are alternative elements of the basic feature set B. Selecting alternative basic feature set Be according to logic relation between function demand points, and judging whether its input set is available or not for element bei in the alternative basic feature set Be

And is

If yes, the element can become an element bi in the basic feature set, otherwise, the bei is merged into other function points bej according to the logical relationship, the input and output conformity of the bei is judged again for bej, if yes, the bei enters B to become a feature element bj, otherwise, the bei is merged again until the bei becomes a feature element bk.

After the B sets are sorted out, a directed connected graph GB1 is formed, GB1 is < VB1, EB1>, wherein V is a set of nodes, each node represents a basic feature element B, E is a set of edges, and for any edge E, an ordered pair < vbi, vbj > of the node corresponds to the edge E. GB1 expresses control flow, data flow relationships between features, and the path from the start node vb0 to the end node vbk is a task profile of software.

The elements in set F correspond to the dependent B elements. If the characteristics which are difficult to quantify and depend on are difficult to find in the corresponding process, the requirements and the specifications are mixed and are difficult to quantify, and the requirements and the specifications are corrected.

If B is a basic characteristic element and B is a basic characteristic set, then U.b belongs to BI_bIs equal to INF, and U is equal to_b∈BO_b＝INF。

All the input and output in the software requirement specification should have basic features corresponding to the input and output, and all the basic features have external input and output interfaces of the software.

Through the construction of the feature space described by the formula (1), the task profile of software in a feature layer can be combed, the object to be tested is identified, and the problem of fuzzy and contradictory description of the layer is solved. If the software requirement specification is a description of conversion from a real world to a software space, the construction of the feature space of the formula (1) is quantitative reproduction and verification of the description and the requirements of real world tasks. If the work in this step can intervene in the development process as early as possible, the efficiency of the subsequent work can be effectively improved.

The feature space of the formula (1) is a first-level quantitative decomposition of a software requirement specification, so that an object can be clearly analyzed, and inconsistent and fuzzy contents before and after the object is removed. However, with the increasing software scale, more and more complex structures appear in the basic features, and if the elements in the basic feature set B are directly used as test analysis objects, the problems of complicated analysis content and difficulty in overall test coverage still exist. Therefore, the basic features need to be further divided into feature elements. By identifying the feature element, a feature element space described by equation (2) is constructed.

The feature with a single function is a feature element. The characteristic with more complex functions is divided downwards according to different processing modes and is decomposed into a plurality of characteristic elements. For example, the feature b is processed into links I, II and IV within the time [ T0, T0+300], and the processing mode is kept unchanged no matter what instructions are annotated. In the time range of non [ T0, T0+300], when the instruction alpha is injected, the processing links of the function are I, II, III, IV and V; when the instruction beta is filled, the processing links of the function are I, II, IV and V; under the default condition, the processing links are I, II, III and V. The characteristic b can be divided into four characteristic elements of METAbt0, METAb alpha, METAb beta and METAbd.

There is a commonality of features that can be broken down into multiple feature elements: firstly, the functional structure is complex, and more links for completing task functions are provided; secondly, although the input interface and the output interface are the same, the completed task functions are basically consistent, but the specific processing mode has larger difference due to the reasons of input data, time phase, upper notes instruction, environment and the like; third, if analyzed as a whole, it is very easy to cause missing and difficult to fully cover the feature functions. The characteristic elements and the subordinate characteristics thereof have the following properties:

if METAbi is a feature element of feature b, input element set I_METAbiIb, set of output elements O_METAbiOb and meta pi is consistent with the b processing functional goal, the processing framework is the same.

Let E be the environment condition set of the characteristic element b, I be the input element set of b, IDA be the value set of I,

Ei≠Ej，

IDAi ≠ IDAj, and the processing of b caused by Ei or IDAi is different from the processing of b under Ej and IDAj conditions, then METAbi and METAbj are respectively the feature elements of b, and the collection of feature elements { METAb1, … and METAbk } forms the task processing stream cluster of b.

If the directed connected graph GB1 composed of B sets represents a task section of software, each feature element item of a feature B is a task section of B, and the METAb is expanded at a node B, the method is equivalent to the decomposition of the node GB1 to form a more specific GBM. The feature element space shown in the formula (2) is a decomposition of leaf nodes in the feature space to form a more specific and clear task profile. In this process, fuzzy, inconsistent content within the feature is also discovered. If the work of the step can be intervened as early as possible, the accuracy and the efficiency of design can be effectively improved.

In a technical solution that may be implemented, please refer to fig. 3, and fig. 3 is a flowchart illustrating a software testing method according to an embodiment of the present invention.

As shown in fig. 3, after constructing the feature meta-item space from each feature meta-item, each feature and the feature space, the method further comprises:

s700: according to each piece of feature element information, splitting the feature element corresponding to each piece of feature element information to obtain a plurality of test items, wherein one feature element corresponds to at least one test item;

s800: allocating a unique identifier to each test item to obtain an identified test item, wherein one identified test item comprises: the method comprises the steps of testing content information, a plurality of testing sufficiency items and a unique identifier, wherein each testing sufficiency item corresponds to at least one decomposition item; each decomposition item corresponds to a unique decomposition item identifier, each decomposition item corresponds to at least one decomposition item entry, each decomposition item entry corresponds to at least one test case, each decomposition item entry corresponds to a unique decomposition item identifier, and each test case corresponds to a unique test case identifier.

S900: and testing the software to be tested according to each identification test item.

In this embodiment, the unique identifier is an ID. For example:

the ID is the only and unique identification of the test item. The Name (Name) is a meaningful Name for the test item, which describes the purpose of the test item. The description (exposure) briefly describes the main contents of feature element processing of a test item to be tested, including test emphasis, test direction and the like. The sufficiency requirement (Adequacy Claim) is a test sufficiency coverage entry, and each sufficiency is supported by the corresponding decomposition item of the test item. The sufficiency requirement entry is uniquely identified by a sufficiency identification (Adequacy ID).

and testing each identification test item according to the decomposition item and a preset test rule to obtain a test result so as to realize the test of the software to be tested, wherein the decomposition item is a recording unit which supports the test sufficiency of the software to be tested when different test cases generated by a test method are used for testing the software to be tested.

In this embodiment, the resolution term is a recording unit that supports test sufficiency analysis using the same or different test methods. The test method comprises equivalence class, boundary value, function decomposition, decision table, cause and effect diagram, state machine and the like, and can also be incorporated into updated research results along with the development of test technology. The equivalence class and the boundary value are generally used for analyzing an input domain, the function decomposition, the decision table, the causal graph and the state machine are generally analyzed in combination with a processing process, and in order to ensure the completeness of a test, the full coverage of an output domain, the maximum jump of a count value of the output domain and the like are used for testing and analyzing the output domain.

The analysis items record analysis contents and the corresponding relation between the analysis contents and the sufficiency requirement and the test case by the analysis tables corresponding to the test methods. For example, the equivalence class table records the equivalence class analysis for the input, and each analysis entry of the equivalence class table includes its own identifier, a corresponding sufficiency identifier, and a corresponding test case identifier, so as to run through the test items, the decomposition items, and the test cases.

Through the implementation of a test system, a software requirement protocol can be comprehensively covered by a practical test technology, the problems of mixed and fuzzy requirements can be solved, the progress of the test technology research is fully utilized, and the follow-up regression and multiplexing can be effectively supported.

Each decomposition item corresponds to one unique decomposition item identifier, each decomposition item corresponds to at least one decomposition item entry, each decomposition item entry corresponds to at least one test case, each decomposition item entry corresponds to one unique decomposition item identifier, and each test case corresponds to one unique test case identifier.

In this embodiment, further, the software to be tested is tested according to each test case.

and tracking the test process according to the feature element item, the decomposition item and the test case.

Specifically, let the feature item set be META, the test item set be TEO, the test item decomposition item set be TEI, and the test case set be TUC. Both directions from META to TUC, TUC to META may indicate that the full flow is trackable, full coverage.

1. META to TUC orientation

There is a fat-fire function from the test case set TEO to the feature element set META direction. The function fTUC-TEI, TUC- > TEI, the function fTEI-TEO, TEI- > TEO, and the function fTEO-META, TEO- > META, are diathermanous. It should be noted that the complex function composed of fTUC-TEI, fTEI-TEO, and fTEO-META is also an integer function.

g1 ═ fTUC-TEI ° fTEI-TEO: TUC- > TEO, g1 is the diathermy function;

g2 ═ fTEI-TEO ° fTEO-META: TEI- > META, g2 is the diathermy function;

g3 ═ fTUC-TEI ° fTEI-TEO ° fTEO-META: TUC- > META, g3 is a fill-shoot function. The description of the f series and the g series of functions,

2. TUC to META orientation

There is no function from the characteristic element set META to the testing case set TEO direction, and only the relation between the sets. Let set META to set TEO exist a set of relationships RMETA-TEO: META — (META)>TEO, (meta, test object) is an ordered pair in R, if

Is bound to

(

object i | test object i ∈ TEO1), constituting an ordered pair (meta, test object i ∈ RMETA-TEO), where

Similarly, there is a set of relationships RTEO-TEI from the set TEO to the set TEI: TEO- (TEO) -C>TEI, if

object | test object ∈ TEO, necessarily

(

item | test item ∈ TEI1) to form an ordered pair (test object, test item ∈ RTEO-TEI), where

There is a set of relationships RTEI-TUC from set TEI to set TUC: TEI- (TEI) -C>TUC, if

item | test item ∈ TEI, inevitably

(

use case | test use case ∈ TUC1) constituting an ordered pair (test item, test use ase) ∈ RTEI-TUC, where

Three types of combination relations Rg1, Rg2 and Rg3 are formed by RMETA-TEO, RTEO-TEI and RTEI-TUC.

Rg1＝RMETA-TEO°RTEO-TEI：META——>TEI；

Rg2＝RTEO-TEI°RTEI-TUC：TEI——>TUC；

Rg3＝RMETA-TEO°RTEO-TEI°RTEI-TUC：META——>TUC。

Let the FIRST set of elements be FIRST and the SECOND set of elements be SECOND, then

(

|, [ SECOND ∈ SECOND1 ]), wherein

The Rg-series combination relationship also satisfies the above-mentioned constraints.

In the direction from the characteristic element set META to the test case set TEO, the relation of the R series and the Rg series meets the requirement that the elements in the set where the first element of the ordered pair is located are selected, a subset necessarily exists in the second element set, and the ordered pair formed by any element in the subset and the first element belongs to the combined relation set;

f series and g series of diathermy functions exist from the TEO to the META direction;

in the software testing process, the device can be tracked and can be completely covered before and after.

According to another aspect of the embodiments of the present invention, there is provided a computer-readable storage medium, which includes instructions, when executed on a computer, cause the computer to perform the method according to any one of the above-mentioned possible implementation solutions.

According to another aspect of the embodiments of the present invention, there is provided a terminal configured to perform the method in any one of the foregoing possible technical solutions.

The terminal may be a user device such as a computer, a mobile phone, a tablet, etc., which can process (e.g., edit) an (electronic file, etc.).

The structure of the terminal includes: a processor and a memory. The processor is a control center of the terminal, connects various parts of the whole terminal through various bus interfaces, and executes various functions of the terminal and processes data by running or executing software programs (or instructions and the like) stored in the memory and calling the data stored in the memory, thereby monitoring the whole terminal.

For example, in this embodiment, the memory is used to store a program or an instruction corresponding to the execution of the method in any one of the foregoing possible implementation solutions, and the processor executes the program or the instruction to implement the method flow in any one of the foregoing possible implementation solutions.

The memory may mainly include a storage program area and a storage data area, wherein the storage program area may store an operating system, an application program required for at least one function, and the like; the storage data area may store data created according to the use of the terminal, and the like. Further, the memory may include high speed random access memory, and may also include non-volatile memory, such as at least one magnetic disk storage device, memory device, or other volatile solid state storage device.

According to another aspect of the embodiment of the invention, the embodiment of the invention provides a software testing system corresponding to the method.

Referring to fig. 4, fig. 4 is a schematic structural diagram of a software testing system according to an embodiment of the present invention.

As shown in fig. 4, the system includes:

splitting the module: the method is used for splitting the software requirement specification according to the requirement information to obtain a plurality of characteristics, wherein each characteristic comprises: the method comprises the following steps of obtaining feature information, splitting features corresponding to each feature information according to task boundary information in each feature information to obtain a plurality of feature elements, wherein one feature corresponds to at least one feature element, and the feature elements comprise: feature meta-item information;

In a technical solution that may be implemented, please refer to fig. 5, and fig. 5 is a schematic structural diagram of a software testing system according to another embodiment of the present invention.

As shown in fig. 5, the system further includes: building a module, wherein,

the building module is used for: constructing a feature space according to each feature, and constructing a feature element space according to each feature element, each feature and the feature space;

the test module is further configured to: and testing the software to be tested according to the feature element space.

As shown in fig. 5, the system further includes: a distribution module, wherein,

the splitting module is further configured to: according to each piece of feature element information, splitting the feature element corresponding to each piece of feature element information to obtain a plurality of test items, wherein one feature element corresponds to at least one test item;

the allocation module is to: allocating a unique identifier to each test item to obtain an identified test item, wherein one identified test item comprises: the method comprises the steps of testing content information, a plurality of testing sufficiency items and a unique identifier, wherein each testing sufficiency item corresponds to at least one decomposition item; each decomposition item corresponds to one unique decomposition item identifier, each decomposition item corresponds to at least one decomposition item entry, each decomposition item entry corresponds to at least one test case, each decomposition item entry corresponds to one unique decomposition item identifier, and each test case corresponds to one unique test case identifier.

The test module is further configured to: and testing the software to be tested according to each identification test item.

The splitting module splits the test item into a plurality of test sufficiency entries, the splitting module splits the test sufficiency entries into at least one split item, the splitting module splits the split item into at least one split item entry, and the splitting module splits the split item entry into at least one test case.

Specifically, the test module is configured to: and testing the software to be tested according to each test case.

Further, the test module is further configured to: and testing each identification test item according to the decomposition item and a preset test rule to obtain a test result so as to realize the test of the software to be tested, wherein the decomposition item is a recording unit which supports the test sufficiency of the software to be tested when different test cases generated by a test method are used for testing the software to be tested.

In one possible implementation of the solution according to the invention,

the building module is further configured to: constructing a feature space according to each feature;

the test module is further configured to: and testing the software to be tested according to the characteristic space.

In a possible implementation technical solution, the building block is specifically configured to:

determining a sub-node of the initial feature space according to the auxiliary features;

In order to make the technical scheme of the application more clearly understood, a test example of the minisatellite attitude and orbit control software is explained and the effectiveness of the method is proved.

Referring to fig. 6, fig. 6 is a diagram of a test example of a moonlet attitude and orbit control software according to an embodiment of the present invention.

As shown in fig. 6, the control of the minisatellite attitude and orbit control software is realized by three functions, namely GPS positioning, attitude control and orbit control.

Specifically, a software requirement protocol of the software test is split according to requirement information and can be split into a GPS positioning feature, an attitude control feature and a track control feature. Wherein the GPS location feature converts and extrapolates the current track position, velocity data to the type of data that the attitude control feature needs to use. The attitude control characteristic utilizes data collected by the sun sensor and the magnetometer and orbit data to jointly calculate the current attitude angle and angular speed. And the track control characteristic judges whether the current attitude determination state is a normal attitude determination state by utilizing the attitude angle calculated by the attitude control characteristic so as to decide whether normal orbital transfer can be performed.

The characteristics are further analyzed, the GPS positioning characteristics include two positioning modes, a GPS standalone mode and an injection orbit mode, the interfaces of the two positioning modes are consistent, but the processing flows are different, and the two positioning modes are divided into 2 characteristic elements, as shown in fig. 6.

The conversion between the GPS single machine characteristic element item and the injection orbit characteristic element item is complex, and in the test item analysis of the characteristic element item, the test item is arranged in the GPS single machine characteristic element item as an independent conversion flow test item so as to avoid the omission and redundancy of the analysis. In the decomposition item corresponding to the test item, a case corresponding to the functional decomposition method is found to have a defect such as time limitation.

The attitude control features are complex, not only are algorithms numerous and difficult, but also processing logics complex, and the description of the required protocols is carried out by taking attitude control in different modes as a whole, and the situations of missing measurement and misjudgment are easy to occur if the attitude control is not decomposed in detail.

According to the characteristic element analysis, the attitude control characteristic is divided into a power-on unseparated characteristic element, a ground orientation characteristic element, a sun orientation characteristic element, a fly-around characteristic element, an orbital transfer attitude maneuver characteristic element, an orbital transfer attitude maintenance characteristic element and a safety characteristic element, as shown in fig. 6.

The power-on unseparated feature elements have little space in the requirement specification of software, but the analysis of the feature elements shows that almost all instruction control operations can be performed under the implicit mode, the satellite attitude can be influenced, and the feature elements need to be independent. Although the orbital transfer attitude maneuver and the orbital transfer attitude maintenance are orbital transfer adjustment attitudes, the orbital transfer attitude maneuver and the orbital transfer attitude maintenance have different attention points and different influences on the orbital control characteristics and need to be respectively and independently used as characteristic elements. The conversion rule among all the feature elements in the attitude control feature is clear, and analysis is carried out in the main flow of the test item corresponding to each feature element. The decomposition items corresponding to the test items not only support the sufficiency of test item analysis, but also clarify the description of various vague and missing places in the requirements, determine the judgment basis and find more than fifty defects by utilizing various methods such as functional decomposition, equivalence class and the like. If the feature elements are not decomposed, at least twenty defects will be missed in the analysis.

Similarly, the track control feature may be subdivided into a pre-release feature element, a track control security feature element, a preheat feature element, a point-to-point preparation feature element, and a thruster feature element. The corresponding test items are main processes of each meta item, and the sufficiency items of the test items are supported by decomposition items composed of a plurality of test methods, as shown in fig. 6. Under the characteristic, through analysis of decomposition items of the sufficiency of the test items under different characteristic elements, different results caused by injection of instructions or track data at different stages are found by corresponding test cases, and some of the results can cause task failure. And the feature elements are difficult to be tested by directly utilizing the requirement specification without being subdivided.

In the test of the attitude and orbit control software of the small satellite, the characteristics, the characteristic elements and the test items corresponding to the requirement specification are definitely sorted out by utilizing the test system analysis based on the characteristic elements, and the problems of confusion, deficiency and analysis omission of the requirement specification are avoided. The feature elements and the relation thereof are decoupled into each test item, so that the capability of comprehensive coverage and parallel analysis is ensured. Aiming at the characteristics of different test items, the decomposition item flexibly applies a plurality of test technologies to ensure the high efficiency and the advancement of the test. In the software test example, the test system based on the feature element generates about 1000 test cases in total, and the test cases and the features can be tracked bidirectionally. The 5 characteristic elements are difficult to clearly analyze in a traditional test mode, correspond to about 400 cases, and find more than thirty defects. Experiments prove that the method can comprehensively and effectively test and analyze the software.

The reader should understand that in the description of this specification, reference to the description of the terms "one embodiment," "some embodiments," "an example," "a specific example," or "some examples," etc., means that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the invention. In this specification, the schematic representations of the terms used above are not necessarily intended to refer to the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, various embodiments or examples and features of different embodiments or examples described in this specification can be combined and combined by one skilled in the art without contradiction.

It is clear to those skilled in the art that, for convenience and brevity of description, the specific working processes of the above-described apparatuses and units may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.

In the several embodiments provided in the present application, it should be understood that the disclosed apparatus and method may be implemented in other ways. For example, the above-described apparatus embodiments are merely illustrative, and for example, a division of a unit is merely a logical division, and an actual implementation may have another division, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed.

Units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment of the present invention.

In addition, functional units in the embodiments of the present invention may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a form of hardware, and can also be realized in a form of a software functional unit.

It will be appreciated that in the above embodiments, all or part may be implemented by software, hardware, firmware or any other combination. When implemented in software, may be implemented in whole or in part in the form of a computer program product.

The integrated unit, if implemented in the form of a software functional unit and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present invention essentially or partially contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product stored in a storage medium and including instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method according to the embodiments of the present invention. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk, and other various media capable of storing program codes.

It should also be understood that, in the embodiments of the present invention, the sequence numbers of the above-mentioned processes do not mean the execution sequence, and the execution sequence of each process should be determined by its function and inherent logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

While the invention has been described with reference to specific embodiments, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention as defined by the appended claims. Therefore, the protection scope of the present invention shall be subject to the protection scope of the claims.

Claims

1. A method for testing software, the method comprising:

testing the software to be tested according to each feature element;

the method further comprises the following steps:

constructing a feature space according to each feature;

testing the software to be tested according to the feature element space;

after said constructing a feature meta-item space from each said feature meta-item, each said feature and said feature space, said method further comprises:

splitting the feature element item corresponding to each feature element item information according to each feature element item information to obtain a plurality of test items, wherein one feature element item corresponds to at least one test item;

allocating a unique identifier to each test item to obtain an identified test item, wherein one identified test item comprises: the method comprises the steps of testing content information, a plurality of testing sufficiency items and a unique identifier, wherein each testing sufficiency item corresponds to at least one decomposition item;

and testing the software to be tested according to each identification test item.

2. A software testing method according to claim 1, characterized in that said method further comprises:

3. A software testing method according to claim 2,

each decomposition item corresponds to a unique decomposition item identifier, each decomposition item corresponds to at least one decomposition item entry, each decomposition item entry corresponds to at least one test case, each decomposition item entry corresponds to a unique decomposition item identifier, and each test case corresponds to a unique test case identifier.

4. A software testing system, the system comprising:

a test module: the software to be tested is tested according to each feature element;

the system further comprises: building a module, wherein,

the construction module: the feature space is constructed according to each feature, and a feature element space is constructed according to each feature element, each feature and the feature space;

the test module is further configured to: testing the software to be tested according to the feature element space;

the system further comprises: a distribution module, wherein,

the splitting module is further configured to: splitting the feature element item corresponding to each feature element item information according to each feature element item information to obtain a plurality of test items, wherein one feature element item corresponds to at least one test item;

the allocation module is configured to: allocating a unique identifier to each test item to obtain an identified test item, wherein one identified test item comprises: the method comprises the steps of testing content information, a plurality of testing sufficiency items and a unique identifier, wherein each testing sufficiency item corresponds to at least one decomposition item;

5. A software testing system according to claim 4,

the test module is further configured to: and testing each identification test item according to the decomposition item and a preset test rule to obtain a test result so as to realize the test of the software to be tested, wherein the decomposition item is a recording unit which supports the test sufficiency of the software to be tested when different test cases generated by a test method are used for testing the software to be tested.

6. A software testing system according to claim 5,