CN109614335A - Module ash box behavior specification and grey box testing case designing method - Google Patents
Module ash box behavior specification and grey box testing case designing method Download PDFInfo
- Publication number
- CN109614335A CN109614335A CN201811501135.0A CN201811501135A CN109614335A CN 109614335 A CN109614335 A CN 109614335A CN 201811501135 A CN201811501135 A CN 201811501135A CN 109614335 A CN109614335 A CN 109614335A
- Authority
- CN
- China
- Prior art keywords
- module
- function
- variable
- box testing
- tested
- 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.)
- Granted
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3684—Test management for test design, e.g. generating new test cases
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3688—Test management for test execution, e.g. scheduling of test suites
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
Abstract
The present invention relates to a kind of module ash box behavior specifications and grey box testing case designing method, belong to computer software engineering technical field.The problem which solve existing Black-box Testing test cases is excessive, testing efficiency is low.The present invention includes: to introduce ash box behavior specification: tested module internal members' variable is the input and output that member function is made, and input/output relation divides the equivalence class of variate-value according to this, and the equivalent state set of tested module is determined with its reasonable combination；Good, the conditional outcome that the two is called collectively as interface function by tested module interface function input and output equivalence class partition；Introduce grey box testing case designing: tested module initialization directly checks module status variate-value in module interface calling interface function according to module ash box behavior specification setting module state variable value.The present invention has many advantages, such as to reject redundancy Black-box testing Cases, improves testing efficiency, can be widely used in computer software exploitation and examine detection occasion.
Description
Technical field
The present invention relates to a kind of module ash box behavior specifications and grey box testing case designing method, and it is soft to belong to computer
Part field of engineering technology.
Background technique
Software action specification is software development significant design recording documents, and software test is that software development is essential
Link.And the main technical content of software test procedure is exactly to write software according to the behavior that software action description defines
Then test case operates tested program according to test case, assess software quality and find software defect.
Software test is divided into Black-box Testing, white-box testing and grey box testing by Software Industry at present.Black-box Testing is being advised
Under fixed software use environment, input is provided and calls tested module external interface function, then whether verifying output is correct.It is black
Tested module as a black box, is only investigated input and output by box test.White-box testing mentions under defined software use environment
For inputting and calling tested module external interface function, then whether verifying output is correct, and checks inside function and realize.Whitepack
Test check tested module all: the input and output that Black-box Testing is investigated, module data structure and all member functions are realized.
But grey box testing is defined between the test form between black box and whitepack by current industry, allow from white to black it
Between any gray scale, this definition randomness affect its value in actual operation.
Black-box Testing determines tested software state using testing procedure, and due to not seeing internal realization, two test cases are
Just effect is the same, also can only be as two test cases.In addition, Black-box Testing should how many testing procedure be also to be a lack of reason
By foundation.The Module Reliability model of Black-box Testing needs to be implemented a large amount of test cases to reach some preset reliability
Value.A large amount of test cases include many redundancy testing use-cases and testing procedure.Therefore, black box behavioural analysis be more suitable for by
Survey object internal mechanism knows nothing or elusive occasion.And white-box testing is due to heavy workload, very for little module
It is necessary also practical；When software measurand becomes larger, whitepack analysis method can become heavy.
Summary of the invention
In view of the foregoing defects the prior art has, the invention proposes a kind of module ash box behavior specification and ash box
Method for test examples design, the problem which solve existing Black-box Testing test cases is excessive, testing efficiency is low.
Module ash box behavior specification and grey box testing case designing method of the present invention, includes the following steps:
Step 1: introduce ash box behavior specification: tested module internal members' variable is that the input that member function is made is defeated
Out, according to this input/output relation divide variate-value equivalence class, the equivalent state set of tested module is determined with its reasonable combination；
According to black box behavior specification requirement, tested module interface function input and output equivalence class partition is good, the two collectively as
The conditional outcome that interface function calls, specifically includes following small step:
Step 1: determining tested module；
Step 2: determining the member variable of tested module；
Step 3: determining the member function of tested module；
Step 4: determining the module member function of the external interface of composition tested module；
Step 5: determining the equivalence class partition of the module member function input and output of the external interface of composition tested module；
Step 6: determining the member function for influencing member variable in tested module；
Step 7: designing according to the member function for influencing member variable in tested module, determine that the member of tested module becomes
The equivalence class partition of amount；
Step 8: using above-mentioned steps as a result, describing module interface function behavior；
Step 2: introduce grey box testing case designing: tested module initialization is directly said according to module ash box behavior specification
Bright setting module state variable value checks module status variate-value in module interface calling interface function, specifically includes following small
Step:
Step 1: the first step of each test case is module initialization；
Step 2: each grey box testing use-case second step is the variate-value of each variable inside setting module, setting module
State；Each grey box testing use-case second step further include: according to the input and output equivalence class of module interface function, and including ring
The condition of other needs such as border sets other function call conditions；
Step 3: each grey box testing use-case define both calling interface function and expected results, including line face all or
Person is first: 1) module Black-box Testing input and output；2) inside modules state outcome；
Step 3: according to above-mentioned Test Sample Design step, test case set is formed.
Preferably, in the first step of the step 1, tested module includes java class.
Preferably, in the second step of the step 1, member variable is selected as the reflection mechanism setting object with java, or
Getter and Setter is arranged in each member variable value of person's object.
Preferably, in the 7th step of the step 1, the state that tested module built-in variable is stated, according to member variable
It is the input and output of member function, the equivalence class partition of the member variable of determining module.
Preferably, in the 8th step of the step 1, the state of inside modules variable statement is divided into module interface method tune
In the condition and expected results of function behavior description.
Preferably, it in the second step of the step 2, is set using the variate-value of Java reflection mechanism realization class or right
Each member variable is a pair of of function, a Getter, a Setter, it is therefore an objective to directly read and be arranged in test mode
Variate-value.
Preferably, in the second step of the step 2, according to the input and output equivalence class of module interface function, and including
The condition of other needs such as environment sets other function call conditions.
Preferably, in the second step of the step 2, grey box testing use-case includes in testing procedure directly setting module
The variate-value of each variable in portion reduces test case step so that module directly reaches particular state.
Preferably, in the second step of the step 2, the characteristics of memory using modularity function, reduction test case step
Suddenly.
Preferably, in the third step of the step 2, definition calls expected results to include both line faces all or be
First: 1) module Black-box Testing input and output；2) inside modules state outcome.
It should be understood that module member function majority does not allow not comprising static variable, such as java and C#.
Under this condition, function itself is not remembered.The n-th calling of function is not aware that this calling is n-th, all notes
Recall and is undertaken by the member variable of module.So as long as module equivalent state class is determined, under each equivalent state, root
It according to function call condition (environment and input), calls function primary, verifies expected results.
In addition, static variable can be drawn to the column to the member variable of module if function has static variable.
The present invention is summarized as follows:
One, module ash box behavior specification part: tested module internal members variable (member variable) is into
The input and output that member's function (member function) is made, input/output relation divides the equivalence class of variate-value according to this, is closed with it
Reason combines the equivalent state set for determining tested module；According to the requirement of black box behavior specification, by tested module interface function
Input and output equivalence class partition is good.The conditional outcome that the two is called collectively as interface function.
Two, grey box testing case designing part: tested module initialization；Directly set according to module ash box behavior specification
Cover half bulk state variate-value；In module interface calling interface function；Check module status variate-value.
The beneficial effects of the present invention are:
(1) strict definite definition module behavior specification and grey box testing of the present invention draw inside modules state variable
Enter investigation object, shortens test case step number.
(2) strict definite definition module behavior specification and grey box testing of the present invention draw inside modules state variable
Enter investigation object, reach and reject redundancy testing use-case, reducing test case quantity, I does not reduce the purpose of test quality.
(3) strict definite definition module behavior specification and grey box testing of the present invention are analyzed software action and soft
Part testing time and Reliability modeling will all have good directive significance；Grey box testing ambiguity in definition at present, practical guidance meaning
Justice is not strong, it is difficult to establish software ash box reliability model.
(4) present invention has many advantages, such as to reject redundancy Black-box testing Cases, improves testing efficiency, tight in software test field
Lattice explication grey box testing, can refer to guide module reliability model, can be widely used in computer software exploitation and examines inspection
Survey occasion.
Detailed description of the invention
Fig. 1 is flowage structure block diagram of the invention.
Specific embodiment
In order to which the object of the invention, technical solution is more clearly understood, below with reference to embodiment, the present invention is made further
It is described in detail.
Embodiment 1:
The grey cartridge module behavior specification and grey box testing method that the present invention proposes a stringent explication are as solution
One of the approach of certainly above-mentioned black box problem.Grey box testing is simpler than white-box testing, more high-efficient than Black-box Testing.
Software is made of module.Module is made of smaller module.The smallest module can be a class, and maximum module is
By exploitation software itself.Module can be regarded as to be made of a data structure and a function set.Data structure is become by member
Amount is realized.Whether according to being called by the module external world, member function is segmented into: the interface of a kind of comprising modules and extraneous interaction,
One kind is internal use.Whether member function again can be influences module member variable value and is divided into two classes.Black-box Testing concern
The behavior of the function of comprising modules and extraneous interactive interface.Grey box testing pays close attention to module status, therefore grey box testing concern member becomes
Amount.Member variable is the input and output of modular approach, therefore grey box testing concern influences the member function row of module member variable value
For.
Module ash box behavior specification: according to tested module internal members variable (member variable) by member
The case where function (member function) changes as input and output, divides the equivalence class of variate-value, true with its reasonable combination
Determine the equivalent state set of tested module；According to the requirement of black box behavior specification, by tested module interface function input and output
Equivalence class partition is good.The conditional outcome that the two is called collectively as interface function.
Module grey box testing under defined software use environment, according to module ash box behavior specification setting module at
Member's variate-value, so that setting module state, provides input and call tested module external interface function, then whether verifying output
Correctly, whether authentication module data structure is correct, but does not check inside function and realize.
The present invention, which is that the following technical solution is employed, to be realized, correlation step is intuitively shown using form, such as the following table 1
It is shown.
Table 1: the test case set step table of embodiment 1
Module member function majority does not allow not comprising static variable, such as java and C#.Under this condition,
Function itself is not remembered.The n-th calling of function is not aware that this calling is n-th.All memories are by module
Member variable undertakes.So as long as module equivalent state class is determined, under each equivalent state, according to function call item
Part (environment and input) calls function primary, verifies expected results.
If function has static variable, static variable can be drawn to the column to the member variable of module.
Embodiment 2:
In the present embodiment 2, Getter and Setter is arranged by each member variable value to object, so that it is determined that object
State, correlation step use form intuitively to show, as shown in table 2 below.
Table 2: the test case set step table of embodiment 2
Embodiment 3:
The present embodiment provides a simple C# class method.Using the present embodiment 3, the method that provides, it is possible to reduce test
Use-case quantity and test case step number.
SimpleClass is a very simple C# class
Only there are three functions for this class: SimpleClass (), Get () and Set (int a).If using Black-box Testing
Theory is all different test case below:
1.SimpleClass (), Set (5), Get ()
2.SimpleClass (), Set (5), Set (5), Get ()
3.SimpleClass (), Set (5) Set (5), Set (5) ... ..., Set (5), Get ()
According to any Black-box Testing software reliability model, many test cases are had.
However, if the equivalence class of the variable x of class is 2 using grey box testing model16≤ SimpleClass.x≤
216.If selecting a typical test data to this equivalence class, test case can be three:
1.SimpleClass()；AssertState (SimpleClass.x=0)；
2.SimpleClass()；AssertState (SimpleClass.x=0)；SimpleClass.Get()；
AssertState (SimpleClass.x=0)
3.SimpleClass()；AssertState (SimpleClass.x=0)；SimpleClass.Set(5)；
AssertState (SimpleClass.x=5).
Strict definite definition module behavior specification and grey box testing of the present invention examine the cut-in of inside modules state variable
Object is examined, test case step number is shortened.Strict definite definition module behavior specification and grey box testing of the present invention, will
Inside modules state variable is divided into investigation object, reaches and rejects redundancy testing use-case, and reducing test case quantity, I does not reduce survey
Try the purpose of quality.Strict definite definition module behavior specification and grey box testing of the present invention, for software action analysis and
Software test time and Reliability modeling will all have good directive significance.Grey box testing ambiguity in definition at present, it is practical to instruct
Meaning is not strong, it is difficult to establish software ash box reliability model.The present invention, which has, rejects redundancy Black-box testing Cases, improves test effect
The advantages that rate.Stringent explication grey box testing, can refer to guide module reliability model in software test field, can extensive utilization
Detection occasion is developed and examined in computer software.
Certainly, above content is only presently preferred embodiments of the present invention, be should not be construed as limiting to implementation of the invention
Example range.The present invention is also not limited to the example above, and those skilled in the art are in essential scope of the invention
Interior made all the changes and improvements etc., should all belong in patent covering scope of the invention.
Claims (8)
1. a kind of module ash box behavior specification and grey box testing case designing method, which comprises the steps of:
Step 1: introduce ash box behavior specification: tested module internal members' variable is the input and output that member function is made, according to
This input/output relation divides the equivalence class of variate-value, and the equivalent state set of tested module is determined with its reasonable combination；According to
The requirement of black box behavior specification, tested module interface function input and output equivalence class partition is good, and the two is collectively as interface
The conditional outcome of function call specifically includes following small step:
Step 1: determining tested module；
Step 2: determining the member variable of tested module；
Step 3: determining the member function of tested module；
Step 4: determining the module member function of the external interface of composition tested module；
Step 5: determining the equivalence class partition of the module member function input and output of the external interface of composition tested module；
Step 6: determining the member function for influencing member variable in tested module；
Step 7: designing according to the member function for influencing member variable in tested module, the member variable of tested module is determined
Equivalence class partition；
Step 8: using above-mentioned steps as a result, describing module interface function behavior；
Step 2: introduce grey box testing case designing: tested module initialization is directly set according to module ash box behavior specification
Cover half bulk state variate-value checks module status variate-value in module interface calling interface function, specifically includes following small step:
Step 1: the first step of each test case is module initialization；
Step 2: each grey box testing use-case second step is the variate-value of each variable inside setting module, setting module state；
Each grey box testing use-case second step further include: according to the input and output equivalence class of module interface function, and including environment etc.
The condition of other needs sets other function call conditions；
Step 3: each grey box testing use-case define both calling interface function and expected results, including line face all or only
It is first: 1) module Black-box Testing input and output；2) inside modules state outcome；
Step 3: according to above-mentioned Test Sample Design step, test case set is formed.
2. module ash box behavior specification according to claim 1 and grey box testing case designing method, feature exist
In in the first step of the step 1, tested module includes java class.
3. module ash box behavior specification according to claim 2 and grey box testing case designing method, feature exist
In in the second step of the step 1, member variable is selected as reflection mechanism setting each of object or object with java
Getter and Setter is arranged in member variable value.
4. module ash box behavior specification according to claim 1 or 3 and grey box testing case designing method, feature
It is, in the 7th step of the step 1, the state that tested module built-in variable is stated is member function according to member variable
Input and output, the equivalence class partition of the member variable of determining module.
5. module ash box behavior specification according to claim 4 and grey box testing case designing method, feature exist
In in the 8th step of the step 1, the state of inside modules variable statement is divided into the function behavior of module interface method call
In the condition and expected results of description.
6. module ash box behavior specification and grey box testing case designing method according to claim 1 or 5, feature
It is, in the second step of the step 2, realizes that the variate-value of class is set using Java reflection mechanism, or become to each member
Amount is a pair of of function, a Getter, a Setter, it is therefore an objective to directly read and be arranged variate-value in test mode.
7. module ash box behavior specification according to claim 6 and grey box testing case designing method, feature exist
In in the second step of the step 2, grey box testing use-case includes each variable inside testing procedure directly setting module
Variate-value reduces test case step so that module directly reaches particular state.
8. module ash box behavior specification according to claim 7 and grey box testing case designing method, feature exist
In, in the second step of the step 2, the characteristics of memory using modularity function, reduction test case step.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811501135.0A CN109614335B (en) | 2018-12-10 | 2018-12-10 | Module ash box behavior specification description and ash box test case design method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811501135.0A CN109614335B (en) | 2018-12-10 | 2018-12-10 | Module ash box behavior specification description and ash box test case design method |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN109614335A true CN109614335A (en) | 2019-04-12 |
| CN109614335B CN109614335B (en) | 2021-10-15 |
Family
ID=66008053
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201811501135.0A Active CN109614335B (en) | 2018-12-10 | 2018-12-10 | Module ash box behavior specification description and ash box test case design method |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN109614335B (en) |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102103539A (en) * | 2011-03-11 | 2011-06-22 | 天津大学 | Z-specification-based test case generating method |
| CN104461875A (en) * | 2014-11-23 | 2015-03-25 | 国云科技股份有限公司 | Method for designing software testing case according to equivalence classes |
| US10025696B2 (en) * | 2016-02-09 | 2018-07-17 | General Electric Company | System and method for equivalence class analysis-based automated requirements-based test case generation |
| CN108415830A (en) * | 2018-02-05 | 2018-08-17 | 广东睿江云计算股份有限公司 | A kind of generation method and device of software test case |
| CN108427632A (en) * | 2017-02-14 | 2018-08-21 | 腾讯科技（深圳）有限公司 | Automatic test approach and device |
| US20180293156A1 (en) * | 2017-04-06 | 2018-10-11 | At&T Intellectual Property I, L.P. | System and method for testing software applications in a software defined network |
-
2018
- 2018-12-10 CN CN201811501135.0A patent/CN109614335B/en active Active
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102103539A (en) * | 2011-03-11 | 2011-06-22 | 天津大学 | Z-specification-based test case generating method |
| CN104461875A (en) * | 2014-11-23 | 2015-03-25 | 国云科技股份有限公司 | Method for designing software testing case according to equivalence classes |
| US10025696B2 (en) * | 2016-02-09 | 2018-07-17 | General Electric Company | System and method for equivalence class analysis-based automated requirements-based test case generation |
| CN108427632A (en) * | 2017-02-14 | 2018-08-21 | 腾讯科技（深圳）有限公司 | Automatic test approach and device |
| US20180293156A1 (en) * | 2017-04-06 | 2018-10-11 | At&T Intellectual Property I, L.P. | System and method for testing software applications in a software defined network |
| CN108415830A (en) * | 2018-02-05 | 2018-08-17 | 广东睿江云计算股份有限公司 | A kind of generation method and device of software test case |
Non-Patent Citations (1)
| Title |
|---|
| 王瑞雪 等: "UML模型驱动的划分测试用例生成方法研究", 《计算机应用研究》 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN109614335B (en) | 2021-10-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN107066375B (en) | System and method for generating automatic demand-based test case of safety-critical software | |
| Khan | Different approaches to black box testing technique for finding errors | |
| US8527965B2 (en) | Layered static program analysis framework for software testing | |
| US20130117855A1 (en) | Apparatus for automatically inspecting security of applications and method thereof | |
| US20070061641A1 (en) | Apparatus and method for generating test driver | |
| US20170132116A1 (en) | Methods Circuits Apparatuses Systems and Associated Computer Executable Code for Generating a Software Unit Test | |
| US11888885B1 (en) | Automated security analysis of software libraries | |
| Seidel et al. | Type targeted testing | |
| US20170261552A1 (en) | Methods and systems for generating functional test patterns for manufacture test | |
| CN109783346A (en) | Keyword-driven automatic testing method and device and terminal equipment | |
| Sankar et al. | Specifying and testing software components using ADL | |
| Brar et al. | Differentiating integration testing and unit testing | |
| CN111679977A (en) | Jest-based React project unit testing method, equipment and storage medium | |
| US10324829B2 (en) | Application testing | |
| CN106649110A (en) | Software test method and system | |
| CN109614335A (en) | Module ash box behavior specification and grey box testing case designing method | |
| Villalobos-Arias et al. | Evaluation of a model‐based testing platform for Java applications | |
| US10853051B2 (en) | Automated candidate repair patch generation | |
| CN112286802B (en) | Method and device for testing program performance and electronic equipment | |
| Andrews | Theory and practice of log file analysis | |
| CN115292178A (en) | Test data searching method, device, storage medium and terminal | |
| CN113836825A (en) | Application method of key standard and verification chip of neural network processor | |
| KR20120072133A (en) | Apparatus and method for software static testing | |
| CN110659215A (en) | Open type industrial APP rapid development and test verification method | |
| Xie et al. | Mutation analysis of parameterized unit tests |
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 |