Guideline of Test Suite Construction for GUI Software Centered on Grey-Box Approach ()
1. Introduction
GUI (Graphical User Interface) software has become the majority of current software and played a dominant role for mobile and desktop software in update engineering system [1] , and the GUI software has covered a wide area for engineering application as shown in Figure 1. Further, we believe that this trend will be sustainable for a long period in the future. However, the testing of GUI
![]()
Figure 1. Popular composition of GUI software.
software has also faced some difficulties especially for the large scale software system with many communication interfaces and data scenarios. Of course, the difficulty of test suite construction for GUI software is the main aspect including the problem of how to improve the testing efficiency and how to assure testing quality. Generally, for the former, test engineer must consider how to do software testing with less time, which the grey-box approach has been proposed for GUI software testing in our study and testing practice [2] , and for another problem, it will refer to accurately testing and BUG location for GUI software, which FTA (Fault Tree Analysis) has used in regression testing to deal with the software change [3] . However, concerning the core problem with test suite construction, this study will mainly focus on the grey-box approach which applied in GUI software testing.
This guideline is prepared for software companies and relative application areas, and it is a technical guidance which its thought and essence is scientifically summarized from testing practice and it also is derived from software programming technique in fact [4] [5] [6] , in which there is not a bit of practical joke and baloney. As a result, this guideline will be illustrated and verified by a set of factual software testing examples [7] . However, this guideline must be fine-tuned in terms of the actual situation of software companies and relative application areas to assure the effectiveness of method application [8] .
2. Related Literature and Work
Emil Alegroth, Robert Feldt [8] imply that test suite construction is done all through the process of software testing in the case company—Spotfy, but the importance of testing data is ignored or omitted in their observation. Ron Patton in his writings “Software Testing” discussed the specific testing of GUI by using one chapter [5] , and proposed seven aspects about it including 1) directly perceiving through the senses, 2) consistency, 3) nimbleness, 4) comfort, 5) correctness, and 6) usefulness, however the systemic approach for GUI software testing is lack especially for specific testing phase e.g. unit testing and integration testing. Fu Bing [6] puts forward that the test case constructing is the core matter of software testing as an effective measure for improving controllability and software should be checked and tested with test case according to the requirement from user. At the same time, the difficulty of software testing for GUI was conscious in the writings of Fu Bing, and Fu Bing et al. thought that the study of GUI testing is in the initial phase at present and existed technology cannot assure the quality of factual GUI software. Additionally, the magnitude of test data is ignored too. Li Fan [7] proposed the main content of test design for test suite construction, and has considered the magnitude of testing sequence in software testing activity.
As a consequence, our study and testing practice [9] [10] [11] [12] has demonstrated the magnificence of data-driven in engineering application software, and the grey-box approach is proposed for dealing with the difficulty of software testing for GUI based on window frame in our recent research [2] .
Further, the test suite construction, as the key aspect of software testing activity, should be paid more attention, so previous work [12] has investigated the test suite construction of smoke test. Moreover, the recent study [2] has proposed the grey-box technique of integration testing for GUI software, and more recent research [3] has provided the constructing method of test suite, including the testing method of data boundary value of input controls and the typical disposing method of function and state testing using the improved STD (State Transform Diagram).
Consequently, this study gives the guideline of test suite construction for GUI software centered on grey-box approach, and deeply discusses the constructing method and process including unit testing and integration testing by a typical case of GUI software—PQMS (Product Quality Monitoring Software/System).
3. Background and Definition of Terminology
When we start a task of software testing, regardless of any testing type, the first matter must be the construction of test case or test suite. In fact, test suite construction has become the key and most important work in software testing. However, how to construct test case or test suite for GUI software with engineering method? It probably is not a very easy-to-answer problem. As such, we would build some references in the following.
3.1. Research Methodology
Generally, software testing can be divided into four testing phases including unit testing, integration testing, system testing and validity testing. Furthermore, white box method and black box method are usual testing methods in software testing. And white box method is the traditional method previously in unit testing especially for logic testing, but black box method is more usually used in function testing [5] [6] [7] .
For the view of testing phase, test suite construction should generally include test suite construction of unit testing and test suite construction of integration testing. However, in some situations, test suite construction of system testing and test suite construction of validation testing must be considered too [6] .
For the view of software production, test suite construction generally has two aspects, i.e. test suite construction of baseline version and test suite construction of incremental change [3] .
In actual software testing, all above objects should be considered in terms of factual requirement. In order to deeply investigate the test suite construction, we firstly outlined a whole view of test suite construction centered on grey-box approach as shown in Figure 2 [9] [10] [11] .
3.2. Software Testing for GUI Software
For GUI software, the GUI testing is a very important context and should be taken as a high-level testing, especially in large scale GUI software system. Consequently, we gave a general overview about the level of GUI testing in software testing as shown in Figure 3.
In contrast to previous DOS software, such as the runtime software of industrial control device, the GUI testing in large scale software system faced some challenges [13] as follows:
· Functionalities of software system are much more.
· States of software system are much more and transformed with more branch and loop.
· Data organizing type and saving mode are more complex.
· Information interchanging is done by more widely and rapidly mode such as internet.
· Application scenarios will be happened with more layers and more entities.
![]()
Figure 2. Constructing scheme of test suite centered on grey-box approach.
![]()
Figure 3. The level of GUI testing in software testing.
Facing to these challenges, the test suite construction of GUI software should consider more concerns from more requirements [14] [15] especially to strengthen the usability of user. Firstly, the GUI testing is taken as a more important part in GUI software testing including the testing of GUI controls and components and the general testing of function and state, besides the traditional logic testing.
3.3. Construction Process of Software Test Suite
The workload of test suite construction almost has the ratio of 60% in software testing. The testing organizing of test suite construction will determine the quality and efficiency of software testing. Some basic and preparing work must be done before starting the test suite construction, such as familiarizing the code submitted from programmer, analyzing the requirement of testing environment and the dependency of units, and determining the general testing strategy and method, etc. If it is necessary, all preparing work should be organized by skilled tester or manager. In general, the procedure of test suite construction should be executed according to Figure 4.
3.4. Definition of Terminology
In this paper, the following terminology is used to understand the accurate meaning of our study. For our study opinion, new software testing method should be explored because of some old traditional methods are not fitted for the GUI software testing, which mainly includes the “Triple-step method” in unit testing and “Grey-box approach” in integration testing.
In order to deeply discuss the problem of the GUI software testing, the GUI testing is defined that is taken as a high-level testing and usually implies the software testing from GUI aspect for general GUI software. The GUI testing based on “Sheet/Form” is factually adopted as a strategy of software testing, which the “Sheet/Form” is taken as a single unified entity with all controls/components and internal function disposing. Test suite construction of GUI software implies the constructing processing of test suite for GUI software, and it should include the dependency analysis with FTA, the writing and assigning of test case, and
![]()
Figure 4. Procedure of test suite construction.
the modifying and updating of test suite, etc.
In the procedure of test suite construction for GUI software, “Triple-step method” should be adopted for unit testing in terms of the testing sequence of “data testing → function testing → state testing”, and data boundary value testing of GUI input controls must be done firstly to assure the correctness and accuracy of data input, and process boundary value testing must be executed to avoid various leaks e.g. the leakage in the “getting the best deal”, and the data interface and format testing must be strengthened to get the good usability. Function testing is the core task in the unit testing, and the limitation testing is generally done in the process of function testing, which limitation testing include all obliged limitation e.g. limitation of data input, limitation of function running, etc. At the same time, the state testing should be finished in unit testing to improve the software quality really, and “0-switch state testing” may be executed for general GUI software which every effective single-step transformation must be completely tested [7] . Consequently, the “Grey-box approach” should be adopted for integration testing. In general, integration testing has distinguished requirement with the unit testing, data boundary value testing of GUI input controls should not be repeated, and function testing only occurred among units regardless of internal function disposing for GUI software, and state testing should be executed in terms of factual situation of software/system.
4. Grey-Box Approach [2]
For GUI software, the grey-box approach can be mainly used for constructing the test suite of baseline version in integration testing and it will achieve minimum of testing time for dealing with combinatory explosion of GUI testing. The principle of grey-box approach is shown in Figure 5.
In Figure 5, the front part is interface controls of Windows GUI, i.e. “Windows control 1”, “Windows control 2”, ···, “Windows control m”. And in the center part of Figure 5, “Message handling” and “ Map function” are the core part of message disposing based on event from C1, C2, ···, Cm. As a consequence, the function disposing unit, i.e. “Handling unit 1”, “Handling unit 2”, ···, “Handling unit n”, is the actual function handling part by message map route, i.e. H1,
![]()
Figure 5. The principle of grey-box approach for GUI software.
H2, ···, Hn. We insert a pole in the beginning of mapping function which it marked with the point illustrated in Figure 5, for the section in the front of the pole, the white-box method is used to test, and for the section behind the pole, the black-box method is applied for actual function testing. Using this approach, we can only test the message path {C1→H1}, {C1→H2}, {C1→……}, {C1→Hn}, it will cover all message path {{C1→H1}, {C1→H2}, {C1→……}, {C1→Hn}}, {{C2→H1}, {C2→H2}, {C2→……}, {C2→Hn}}, {{……→H1}, {……→H2}, {……→……}, {……→Hn}}, {{Cm→H1}, {Cm→H2}, {Cm→……}, {Cm→Hn}}.
Generally, the selection of the pole position has several methods, details are specified as follows: 1) The path aggregation point by white-box analysis. 2) The point that message route must go through. 3) The entrance point of map function. 4) The entrance point of the initial member function.
By analysis and computation with factual example [2] , we conclude that, in integration testing for GUI Software, the application of grey-box technique will greatly improve the testing efficiency with about four times according to testing executed time.
5. Software Test Suite Construction of Unit Testing
In a large sense, the majority of application software at present is GUI software, and the unit testing of GUI software is the indispensible phase. Thus, test suite construction of unit testing is an impassible and basic work.
Generally, the unit testing of GUI software should execute “Triple-step method” as shown in Figure 6, including 1) step 1—data testing, 2) step 2—function testing, and 3) step 3—state testing. For data testing, there are boundary value testing, data format and interface testing, and data safety testing, in which boundary value testing should include data boundary value testing and process boundary value testing. For function testing, it not only includes function-self run testing but also may have the limitation testing, such as the limitation of unpermitted empty, the input format limitation, the comparing and computing limitation, etc. In some cases, the limitation testing can be incorporated into
![]()
Figure 6. The composition of “Triple-step method”.
data testing, e.g. the testing for the control limitation is given independently. For state testing, the improved STD should be applied with “0-switch” requirement for general situation.
In the test suite construction of data testing, some matters should be considered as follows: 1) Sampling testing method in data boundary value testing may be adopted in terms of the situation of factual software. 2) Data format and interface testing has several types including text file, database, etc. 3) Data safety testing is generally delayed to integration testing and system testing. 4) Usual items of test case include “ID”, “Input”, and “Expected output”, etc., and test environment may be given if necessary.
In the test suite construction of function and state testing, some matters should be also noticed as follows: 1) Function-self run testing should be constructed firstly, particularly noticing the construction for the window access controls and white-box testing in grey-box approach. 2) Limitation testing must be completely conducted as careful as possible. 3) Before state test suite constructing, all states and state-transform should be depicted correctly and completely in the improved STD. 4) Items in the table of test cases should contain “ID”, “Start state”, “End state”, ”Input”, “Expected output” etc., and precondition should be given if necessary. 5) The ID must be unified by specification. 6) The description of “Input” and “Expected output” must be clear and easy-to-understand.
5.1. Test Suite Construction of Baseline Version
5.1.1. Window Access Controls or Window Controls of Function Access
Window access controls or window controls of function access is one kind of GUI controls, which the interface control locates and is contained in the window interface and user can access the software function by this control. For Windows system, usual controls have the menu item of main menu, the menu item of popup menu, shortcut key, toolbar, hotkey, etc.
The test suite construction of window access controls should be prior to do in unit testing especially in preparation of integration testing for grey-box approach [2] [3] , and it must be considered in specific terms including testing organizing e.g. “cross-testing” [3] [11] . The specific format of the writing of test case and test suite may be executed according to the actual situation of software companies, and we give a basic reference format for guidance in this paper. Consequently, a typical example of test case of the menu item testing is given in Table 1, which is a “Basic Setting” menu of PQMS2 (Product Quality Monitoring Software 2.0) [16] .
Matters needed attention in writing test case of window access controls are: 1) all test cases for a main menu should be together, 2) only highlighting the menu item is required rather calling the function, 3) including the content checking of window access controls e.g. the spelling of words.
5.1.2. Basic Setting Unit
For a software system, the basic setting is generally needed for the change of user status and application status. Being different from the window access control, the basic setting unit has the interaction of data, and its test suite construction should include data testing and function and state testing.
1) Data testing
In general, test suite construction of the basic setting unit may be similar to general basic “Sheet/Form” [3] including the testing of data boundary value, process boundary value, and data format and interface etc. Here, the data boundary value testing is a new testing project and testing method possibly applying sampling testing, details may be referred to [3] . For the “Basic Setting” sheet of PQMS2, as a typical small “Sheet/Form”, the testing of data boundary value should be prior to be conducted for GUI software, and the specific format of test cases is given in Table 2.
2) Function and state testing [3]
The function and state testing of the “Basic Setting” sheet is relatively simple because less type and quantity of controls are used, and the specific format of test cases of function testing is given as shown in Table 3.
For the state testing of this basic setting unit, the improved STD should be applied, and details are shown in Figure 7, which the event ei and action ai are given with an attached list and all of symbol description are omitted here. Consequently, the construction of test cases can be done according to this diagram,
![]()
Table 1. Test cases of the window access controls for baseline version.
![]()
Table 2. Test cases of the window access controls for baseline version.
and the specific format of test cases of state testing is given as shown in Table 4.
5.1.3. Initialization Unit
Because the initialization unit is driven directly by a menu item with the member function rather than driven by controls in a “Sheet/Form”, this unit has not data testing of input controls.
For the function and state testing, it is necessary to analyze with the improved STD even though it may be not complex. The improved STD of initializing to delete all inspection data from category is shown in Figure 8. Consequently, test cases can be designed according to this improved STD with less difficulty according above method. As such, test cases of function testing in this initialization unit are given in Table 5, and test cases of state testing are given in Table 6.
5.1.4. Basic “Sheet/Form” Unit
By a lot of testing practice, in our opinion, the GUI testing of software system may be executed based on “Sheet/Form” [3] . In detail, all controls and components in a “Sheet/Form” should be taken as a unified unit if the function is implemented within the “Sheet/Form”. For the function of software is directly driven by a control and component in the window interface, the testing should be similarly done in terms of the member function driven by event of the control in
![]()
Table 3. Test cases of the function testing for basic setting unita.
a. In writing test case of function testing for general situation, it is noticed that all correct and error possibility of function running must be considered.
![]()
Figure 7. The improved STD of “Basic setting” sheet unit.
![]()
Figure 8. The improved STD of initialization unit.
![]()
Table 4. Test cases of the state testing for basic setting unitb.
b. In writing test case of state testing for general situation, it is noticed that the correct and completed STD is needed and 0-switch state testing is passable for most situation in general software system.
the “Sheet/Form”, i.e. the testing of this situation should be disposed in the level of member function.
The “Product and class” sheet of PQMS2 [16] , as shown in Figure 9, is a typical popular “Sheet/Form” including basic GUI controls and components, and popular functions of data adding, data modifying, data deleting. As such, the test suite construction of data testing, function and state testing for this basic sheet is
![]()
Table 5. Test cases of function testing in initialization unit.
![]()
Table 6. Test cases of the state testing for basic setting unit.
![]()
Figure 9. The GUI of “Product and class” sheet unit in PQMS2.
discussed in detail in the following.
1) Data testing of the “Product or class” sheet
a) Data boundary value testing of “input controls”
Similarly, for the “Product and class” sheet, as a typical popular “Sheet/Form”, the testing of data boundary value should also be prior to be conducted while the limitation testing is incorporated into function testing for GUI software, and the specific format of test cases is given in Table 7.
2) Data testing of the “Product or class” sheet
The function and state testing of the “Product or class” sheet is a typical example because functions and types of controls are representative in some extent, and the specific format of test cases of function testing of this basic “Sheet/Form” unit is given as shown in Table A1 of the Appendix.
Similarly, the improved STD should be applied to construct the state test case of the “Product or class” sheet, and details are shown in Figure 10. Consequently, the test case construction of the state testing can be accomplished according to this diagram, and the specific format of test cases of state testing is given as shown in Table A2 of the Appendix.
5.1.5. Complex “Sheet/Form” Unit
In various “Sheet/Form” units, there is a kind of sheet that there are many kinds of control or component and it has data exchange with other sheet or component, and the “Inspection process” sheet unit is a typical example, as shown in Figure 11 [16] . In the “Inspection process” sheet unit, the function of “Add to the monitoring category” with “Button control” will do data exchange with the “Tree control” component in main window.
In Figure 11, as a more complex “Sheet/Form” unit, the sight of typical sheet of data disposing is presented. Moreover, the “Tree control” on the left of the sheet is to display the data chain of “product or class - part/component - inspection process”, and detail information of inspection process taken in the “List control” can be found on the up-right of panel, and the area on the down-right of panel is to accomplish the input of inspection process data including popular EditBox control, ComBoBox control, Button control, etc.
![]()
Table 7. Test cases of the data boundary value testing for the “Product or class” sheet.
![]()
Figure 10. The improved STD of “Product or class” sheet unit.
![]()
Figure 11. The GUI of “Inspection process” sheet unit.
For this “Inspection process” sheet unit, its unit testing should similarly include data testing, function testing and state testing.
1) Data testing
As mentioned above, test suite construction of data testing of the “Inspection process” sheet unit should include the testing of data boundary value, the testing of process boundary value, and the testing of data format and interface etc., while the testing of data limitation is incorporated into function testing.
a) Data boundary value testing of “input controls”
At first, the testing of data boundary value should be similarly executed as a new testing project for GUI software, and the specific result of test design is given in Table A3 of the Appendix.
b) Data format testing of data file
In general, the complex “Sheet /Form” unit has the processing of many kinds of data I/O including the data type of controls, the data type of text file, and the data type of database. The data type of inputting from controls has been discussed as above. Here, the data interface and format testing for the data type of text file will be investigated in this “Inspection process” sheet.
In the testing of data format and interface for the “Inspection process” sheet unit, the format of file name should be tested firstly, and the format of every data may be checked and verified in sequence. Test cases of the data format testing for the “Inspection process” sheet is given in Table A4 of the Appendix. Additionally, Table A5 of the Appendix is the specification of data format with the checking of “the tail of file cannot be empty” for “Import inspection process data” in the “Inspection process” sheet. And other test cases of data format testing are accomplished with code of “PQMS2-PDI-UNI-TC010~TC016”, details are omitted here.
2) Function and state testing
As a complex “Sheet/Form” unit, the function and state testing of the “Inspection process” sheet unit is relatively difficult not only due to many controls and components but also because of a lot of function disposing.
For the function testing of the “Inspection process” sheet unit, it must include 1) initialization displaying of the sheet with default data—test case “PQMS2-IDF-UNI-TC010”, 2) clicking and displaying of inspection process data in monitoring category—test case “PQMS2-IDF-UNI-TC011”, 3) adding of inspection process data—test case “PQMS2-IDF-UNI-TC030~TC044” and “PQMS2-IDF-UNI-TC003-AD~TC004-AD”, 4) modifying of inspection process data—test case “PQMS2-IDF-UNI-TC012~TC029” and “PQMS2-IDF-UNI-TC001-AD~TC002-AD”, 5) deleting of inspection process data—test case “PQMS2-IDF-UNI-TC050~TC053” and “PQMS2-IDF-UNI-TC005-AD~TC006-AD”, 6) searching of inspection process data according to name—test case “PQMS2-IDF-UNI-TC054~TC058” and “PQMS2-IDF-UNI-TC007-AD, and 7) resetting of dada input—test case “PQMS2-IDF-UNI-TC059”.
As a guidance of test suite construction, we only give some test case examples for adding of inspection process data as shown in Table A6 of the Appendix, and remaindering is omitted here. Consequently, Table A6 has given the function-self run testing with “PQMS2-IDF-UNI-TC030” and the limitation testing of “unpermitted overlapping” and “unpermitted empty” with “PQMS2-IDF-UNI-TC031~TC034”. As such, other test case constructing of limitation testing can be done in a similar way.
For the state testing of the “Inspection process” sheet unit, the improved STD should be drawn before constructing the state test suite. In consequence, Figure 12 has shown the details of the improved STD of the “Inspection process” sheet
![]()
Figure 12. The improved STD of the “Inspection process” sheet unit.
in PQMS2. As such, we can construct the test suite of state testing for the “Inspection process” sheet unit in PQMS2 in terms of the improved STD. Consequently, the specific format of test cases of state testing is given as shown in Table A7 of the Appendix.
5.2. Test Suite Construction of Incremental Unit Testing
In the cycle of software developing and maintenance, all composing parts of software will change to fitful the varied requirement of customers, e.g. GUI, data and data organizing etc. For this kind of variety, incremental construction of test suite must be done in regression testing [9] . At the same time, we must known whether the modified or added part has influenced the other unit of the software [9] . Generally, because the unit testing based on “Sheet/Form” has been independent of other units for specified requirement, the dependency analysis of unit testing could be usually omitted instead of integration testing, but the testing of the member function must be concerned with distinguished consideration. As a consequence, the incremental construction is demonstrated in terms of grey-box approach [2] in the following.
5.2.1. Incremental Unit Testing of Window Access Controls
Usually, window access controls are changing including its content and layout according to requirement of users and manager. In the view of quality assurance, this variety must be tested and controlled in terms of the specification of regression testing.
1) Modification of window access controls
If the content of a menu item or main menu is modified, this modification must be tested for regression testing. Consequently, the test case of this window access control must be constructed again. One typical example is shown in “ID—PQMS2-MEF-UNI-TC017-MF” of Table 8, which it has tiny difference from PQMS2-MEF-UNI-TC017 of Table 1.
2) Addition of window access controls
![]()
Table 8. Test cases of window access controls for incremental unit testing.
When a set of functions are added for a software system, all additions must be tested for regression testing. Consequently, test cases of all added window access controls must be constructed. One typical example is the adding of “Report output” in an application, the construction of test cases in PQMS is shown in “ID-PQMS2-MEF-UNI-TC025-AD~TC026-AD”of Table 8.
5.2.2. Incremental Unit Testing of “Sheet/Form” Unit
1) Data testing
Modification of basic “Sheet /Form” unit
If the control of a basic “Sheet/Form” is changed, this change must be tested for regression testing in terms of this change. Consequently, the test case of this basic “Sheet/Form” must be constructed again. Similarly, if the data boundary of controls is changed, the test case of data boundary value must be conducted again. One typical example is the change of data length in two EditBoxes of “Product or class” sheet as shown in “PQMS2-PDB-UNI-TC010-MF~TC011-MF” of Table 9, which it has some difference from Table 7.
2) Function and state testing
Addition of basic “Sheet/Form” unit
When an interface control and implement function are added for a “Sheet/Form”, this adding must be tested for regression testing. Consequently, test cases for this adding change must be constructed. One typical example is the adding of “Search-Name” in the data processing sheet, the construction of test cases is similar to the data testing above, but the function testing of member function of “Search-Name” button must be added, and state testing of this button must be inserted into the state test suite.
6. Software Test Suite Construction of Integration Testing
6.1. Test Suite Construction of Baseline Version
In general, the test suite construction of integration testing for baseline version should be done using grey-box approach [2] for GUI software, except that it is very simple program or non-GUI software. As mentioned in Section 4, the
![]()
Table 9. Test cases of the data boundary value testing for incremental unit testing.
grey-box approach is a better method in integration testing for GUI software based on window frame with efficiency improved about four times.
For the constructing of test suite of integration testing based on grey-box approach, the general procedure can be demonstrated as follows.
· For one function disposing, several test cases of fore-end white-box testing should be constructed according to all kinds of control types in window frame.
· In terms of factual software, using black-box testing method, test cases of function testing are conducted in sequence and distinguishing with various running situation, generally ignoring finished parts in unit testing.
· Conducting test case for all follow-up function disposing with black-box testing method.
· In the process of all follow-up construction of function test case, the mapping function should be chosen with the most rapid route.
· If it is necessary, the test case of fore-end white-box testing must be conducted for all follow-up construction including controls activated in other units such as “Hotkey”.
· Necessary description should be given in the process of test case construction.
Here, the constructing method and writing format are given for the integration testing with the case software, it is noticed that the precondition is generally needed for grey-box approach.
Without loss representative and typicality for GUI software, the integration testing of “Division and department” sheet in PQMS2 is investigated for baseline version according to the grey-box approach.
6.1.1. Test Suite Construction for “Division and Department” Sheet
The “Division and department” sheet is a basic “Sheet/Form” for getting basic data of factory division and department in PQMS2, which the GUI is similar to Figure 9. For shortening aim, the test suite constructing of integration function of “Add to monitoring category” in the “Division and department” sheet is only given here. Using the grey-box approach, test cases of the front-end white-box testing are given in Table 10, and test cases of the black-box testing are given in Table 11.
6.1.2. Modification of Window Access Controls
As we all known, window access controls and its implementation functions usually are needed to modify sometimes, e.g. for fulfilling the supervision of key sampling or UI check. If the window access control changed, the test case of integration testing must be constructed again in terms of grey-box approach. As a typical example, in PQMS2, the menu item of “Output of inspection data” is modified to “Backup of inspection data output”, and test cases of fore-end white-box were changed with ID “P QMS2-ENT-INT-TC368-MF~TC369-MF” as shown in Table 12, but test cases of the black-box testing are unnecessary to
![]()
Table 10. Test cases of front-end white-box for the “Division and department” sheet.
![]()
Table 11. Test cases of black-box for the function of “Add to monitoring category”.
![]()
Table 12. Test cases for the menu item of “Backup of inspection data output”.
modify again if without change in implementation function.
6.1.3. Addition of Window Access Controls and Disposing Functions
“Batch restoring of inspection data” is important function for factual requirement in PQMS, which was not developed in the past. In order to improve the safety of inspection data, this function is arranged to add. Consequently, “Batch restoring of inspection data” is added to the main menu “Data I/O” and the actual function is implemented by programmer. For the “cross-testing”, after the testing task arrangement of manager, tester should do incremental regression testing. As a consequence, testing engineer as the tester analyzed the original code from programmer with FTA tool. During this period, it is noticed that the testing engineer should not only apply FTA tool with careful manner but also be familiar with the code and check it. As a result, Figure 13 has shown the result of FTA which has been accomplished by testing engineer. [9]
In Figure 13, in order to implement the requirement change of “Batch restoring of inspection data is necessary to add”, “Adding coordination-offset coefficient for R chart is necessary respectively in XAve-R chart” is conducted as the top event, and it is noted with mark A. Consequently, Ai,j,… presents the middle event of fault-tree, and Xi,j,k… is the final event of fault-tree, while Ci is the additional condition. Correspondingly, details are demonstrated in Table 13. At the same time, the test case choice and adding for “Batch restoring of inspection data”, derived from final events, are shown in Table 14.
In terms of the result of FTA as above, we can construct test case of incremental testing. In general, Table 14 can be directly use to execute the test design i.e. test suite construction. As such, the front-end test cases of white-box testing is firstly constructed using grey-box approach as shown in Table 15, and PQMS2-ENT-INT-TC145-AD is the added test case for incremental function
![]()
Figure 13. FTA for batch restoring of inspection data in PQMS.
![]()
Table 13. The events of FTA for batch restoring of inspection data.
![]()
Table 14. Choice and adding of test case for batch restoring of inspection data.
![]()
Table 15. Test cases of front-end for adding function of batch restoring inspection data.
![]()
Table 16. Test case of black box for adding function of restoring inspection data.
testing of integration testing, detail is shown in Table 16. Of course, it is noticed that the state testing should be finished in unit testing.
In conclusion, the test suite construction of integration testing has some differences from that of unit testing. On the one hand, the data boundary value testing of input controls is omitted in the data testing of integration testing, except that the testing of data accessing/visiting safety and the testing of obliged data interface and format must be accomplished in sequence. On the other hand, the function integration testing should focus on the function interface among units while limitation testing and state testing should be executed in terms of actual situation of software.
7. Summary
Test suite construction is the most important work in software testing, because workload of test design has the ratio of 60% in software testing activity. Test suite construction is not the same as mechanical design etc., and it can be taken as a kind of process design which directly is projected from the factual software product.
Test suite construction is generally linked to software testing phases, mainly focusing on unit testing phase and integration testing phase in this study. For GUI software testing, in unit testing phase, the test suite construction should generally be done in terms of “Triple-step method” including data testing, function testing and state testing. As a consequence, in integration testing, the “Grey-box approach” is an effective and useful testing methodology for GUI software with prior disposing of window access controls.
This paper aims to provide a referring guidance for researchers and industrial practitioners when conducting test cases and test suite for GUI software in software engineering, and it is based on software testing activity of the case GUI software—PQMS and the author’s own experience of test design. Consequently, it is noticed that tiny tune is needed for software testing practice.
Appendix
![]()
Table A1. Test cases of the function testing for “product or class” sheet unit.
![]()
Table A2. Test cases of the state testing for “product or class” sheet unit.
![]()
Table A3. Test cases of the data boundary value testing for “Inspection process” sheet unit.
![]()
Table A4. Test cases of the data format testing for “Inspection process” sheet unit.
![]()
Table A5. The specification of data format for “Import inspection process data”.
![]()
Table A6. Test cases of unit function testing of adding inspection process data.
![]()
![]()
Table A7. Test cases of the state testing of “inspection process” sheet.