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.

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 e_i and action a_i 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,

and the specific format of test cases of state testing is given as shown in Table 4.

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.

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

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.

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

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.

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.

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

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.

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

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.

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.

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.

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

modify again if without change in implementation function.

“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, A_i,j,… presents the middle event of fault-tree, and X_i,j,k… is the final event of fault-tree, while C_i 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

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.