259 Putting Together the AutomatedGUITest Tool { GUITDC = new GUITestDataCollector(); GUITDC.guiInfo = new GUITestUtility.GUIInfo(); tempList = new ArrayList(); GUITDC.guiInfo.GUIControlName = ➥PopulateGUINameTypeLists(formUTBoxed, GUITDC.guiInfo.GUIHandle, true); tempList.Sort(); GUITDC.ControlNameList = tempList; tempList = new ArrayList(); GUITDC.guiInfo.GUIControlType = ➥PopulateGUINameTypeLists(formUTBoxed, GUITDC.guiInfo.GUIHandle, false); tempList.Sort(); GUITDC.controlTypeList = tempList; GUITDC.PopulateGUIInfo(); if (GUITDC.GUIInfoState == DialogResult.OK) { GUITDC.guiInfo.GUIMemberType = ➥GetMemberType(GUITDC.guiInfo.GUIControlName); GUITestSeqList.GUIList.Add(GUITDC.guiInfo); } } private string PopulateGUINameTypeLists( ➥Control formUT, int hwnd, bool enforceName) { if (formUT == null) return ""; foreach( Control ctrl in formUT.Controls) { if (enforceName) { tempList.Add(ctrl.Name); if ((int)ctrl.Handle == hwnd) GuiProperty = ctrl.Name; } else { if (!tempList.Contains(ctrl.GetType().ToString())) 4351Book.fm Page 259 Tuesday, September 28, 2004 11:21 AM 260 Chapter 7 • Architecture and Implementation of the Automatic GUI Test Tool tempList.Add(ctrl.GetType().ToString()); if ((int)ctrl.Handle == hwnd) GuiProperty = ctrl.GetType().ToString(); } PopulateGUINameTypeLists(ctrl, hwnd, enforceName); } return GuiProperty; } private string GetMemberType(string ctrlName) { if (formUT == null) return ""; BindingFlags allFlags = BindingFlags.Public | BindingFlags.NonPublic | BindingFlags.Static | BindingFlags.Instance; Type StartupForm = formUT.GetType(); FieldInfo[] fis = StartupForm.GetFields(allFlags); foreach (FieldInfo fi in fis) { if (fi.Name == ctrlName) { return "VerifyField"; } } PropertyInfo[] ppis = StartupForm.GetProperties(allFlags); foreach (PropertyInfo ppi in ppis) { if (ppi.Name == ctrlName) { return "VerifyProperty"; } } return ""; } private void btnRunTest_Click(object sender, System.EventArgs e) { sveDataStore.Title = "Location to save GUI test data"; sveDataStore.Filter = "XML Files (*.xml)|*.xml|All Files (*.*)|*.*"; if (sveDataStore.ShowDialog() == DialogResult.OK) { TestCaseStore = sveDataStore.FileName; } else { return; } GUITestSeqList.AUTStartupForm = startupForm; 4351Book.fm Page 260 Tuesday, September 28, 2004 11:21 AM 261 Conducting the First Automatic GUI Testing GUITestUtility.SerilizeInfo(TestCaseStore, GUITestSeqList); GUITestScript guiTS = new GUITestScript(TestCaseStore, currDir); GUITestSeqList = null; } private void btnRerun_Click(object sender, System.EventArgs e) { opnAUT.Title = "Select an existing data store"; opnAUT.Filter = "XLM test cases (*.xml)|*.xml|All Files (*.*)|*.*"; if (opnAUT.ShowDialog() == DialogResult.OK) { GUITestScript guiTS = new GUITestScript(opnAUT.FileName, currDir); } } private void btnExit_Click(object sender, System.EventArgs e) { Application.Exit(); } private void Form1_Resize(object sender, System.EventArgs e) { dgAvailableGUIs.Width = this.Width - 48; dgAvailableGUIs.Height = this.Height - 144; } } } After you successfully build this project, your tool is ready for software testing projects with the implemented capabilities. Although more testing functions are on the way, the Automated- GUITest tool has been enabled with a lot of automatic testing features for functions that require tedious, time-consuming, and manual interactions in other tools. The next section will walk you through the first automatic GUI test without writing and recording a test script. Conducting the First Automatic GUI Testing Now, you have pressed F5, the building is successful, and the AutomatedGUITest tool, which looks similar to Figure 7.5, debuts on your desktop. This tool separates a GUI test process into five big steps indicated by the five buttons implemented in the frmMain class: 1. Start the application under test, which makes the GUI components of the application visible to the tool. 2. Conduct a GUI survey, which enables a thorough test. 4351Book.fm Page 261 Tuesday, September 28, 2004 11:21 AM 262 Chapter 7 • Architecture and Implementation of the Automatic GUI Test Tool FIGURE 7.5 The GUI interface of the AutomatedGUITest for the first test run 3. Run the specified test from the GUI survey results. 4. Rerun the saved test scenario to accomplish an effective regression testing. 5. The test is completed. Click the Exit button to terminate the tool. Based on the test script developed in Chapter 6 for testing the C# API Text Viewer, this section uses the same scenario for exemplary purposes. A normal scenario is reiterated here: 1. When the C# API Text Viewer is running on the desktop, click the ListBox control to advance the vertical scroll bar and select a name of a custom function. 2. Click the Add button to add the selected C# marshalling code into the RichTextBox control. 3. Click the Copy button set the selected function to the clipboard, from which it can be trans- ferred to other word processors or code editors. 4. Click inside the RichTextBox control and it gets the focus. 5. Click the Remove button to remove the first line of code inside the RichTextBox. 6. Click the Clear button to empty the RichTextBox. Complete the test and close the appli- cation under test. To complete this scenario with the AutomatedGUITest tool, you can follow these steps: 1. Click the Start GUI Test button. An open file dialog box pops up. From this dialog box, navigate to the C:\GUISourceCode\Chapter03\CSharpAPITextViewer\bin\Debug folder, select the CSharpAPITextViewer.exe file, and click the Open button. The Types under Test form shows up with the possible class names in the check box list. Among them, one is the startup form class, Form1 in this case. Figure 7.6 displays the Types under Test form of this running session. 4351Book.fm Page 262 Tuesday, September 28, 2004 11:21 AM 263 Conducting the First Automatic GUI Testing FIGURE 7.6 Selecting the startup form class from the possible class names of the C# API Text Viewer 2. Check the check box beside CSharpAPITextViewer.Form1 and click the OK button. The C# API Text Viewer starts on the desktop. If it covers the AutomatedGUITest application, you can rearrange the applications on your screen and make the AutomatedGUITest tool visible. But make sure there is only one copy of the C# API Text Viewer is running on your system. 3. Click the GUI Survey button on the AutomatedGUITest tool. The tool minimizes itself to expose the application under test. You can visualize the mouse movement from the top down- ward to the bottom, and from the left toward the right inside the application until every spot of this window is visited. Then, the AutomatedGUITest tool appears normally on the screen with DataGrid filled with the available GUI descriptions, as shown in Figure 7.7. The first column lists the values of the child GUI components, which is for reference purposes so that the tool can collect specific information, not for test data collection. The second, third, and fourth columns list the values of the associated GUI text, class name, and parent text. 4. You first collect the GUI information for the ListBox of the C# API Text Viewer. The value of the GUI text for this ListBox is empty at the initial stage when no item is selected from the ListBox. You can read its class name as its identifier, WindowsForms10.LISTBOX.app3, to locate the row index and double-click besides the row in the left edge. The GUI Test Data Collector form appears on the screen with the ComboBox and TextBox controls populated with correct values of the respective GUI properties (Figure 7.8). From the GUI Test Data Collector form, you simply click the OK button. NOTE To select a GUI object from the DataGrid, you first place the cursor on the row containing the GUI object, then double-click the gray or blue area on the left edge or on the top to popup the GUI Test Data Collector. 4351Book.fm Page 263 Tuesday, September 28, 2004 11:21 AM 264 Chapter 7 • Architecture and Implementation of the Automatic GUI Test Tool FIGURE 7.7 The AutomatedGUI- Test tool with the collection of the GUI components after surveying the C# API Text Viewer FIGURE 7.8 The first step is to specify a GUI action on the ListBox of the C# API Text Viewer 5. Repeat step 4 for the Add, Copy, RichTextBox, Remove, and Clear controls in the available GUI complonent list. These controls can be easily identified by reading their GUI texts. However, the text for the RichTextBox is still empty. 6. After the designated six GUI events are selected from the available GUI list and confirmed in the GUI Test Data Collector form, you need to terminate the C# API Text Viewer because, when you click the Run button to execute the test, the test script of the tool will start up another copy of the application under test. Two copies of the application running 4351Book.fm Page 264 Tuesday, September 28, 2004 11:21 AM 265 Conducting the First Automatic GUI Testing ➲ on the same system will confuse the tool at this point. However, when you develop a tool for web page stress testing, you need to run multiple copies of the same application. 7. Simply click the Run Test button from the AutomatedGUITest tool. When the save file dia- log box appears, type in a filename with an XML extension, such as C:\Temp\TestC#APIText- Viewer.xml . Then click the Save button. Sit and watch. The C# API Text Viewer shows up again, the GUI actions of the mouse clicking occur in sequence, and the application closes by itself after the execution. The first test is completed. At this point, you can view or edit the saved XML document in any text editor or XML editor; the document is shown in Listing 7.30. You can also use the XmlTreeViewer.exe developed in Chapter 5 to view this XML document by expanding the child XML elements one by one. Listing 7.30 The XML Data Store Containing the GUI Test Instruction to Drive the Execution of the Test Script by Late Binding <?xml version="1.0" encoding="utf-8"?> <GUIInfoSerializable xmlns:xsd= ➥"http://www.w3.org/2001/XMLSchema" xmlns:xsi= ➥"http://www.w3.org/2001/XMLSchema-instance"> <AUTPath>C:\GUISourceCode\Chapter03\ ➥CSharpAPITextViewer\bin\Debug\CSharpAPITextViewer.exe</AUTPath> <AUTStartupForm>CSharpAPITextViewer.Form1</AUTStartupForm> <GUIInfoSerializable> <GUIInfo> <GUIHandle>1246684</GUIHandle> <GUIText /> <GUIClassName>WindowsForms10.LISTBOX.app3</GUIClassName> <GUIParentText>C# API Text Viewer</GUIParentText> <GUIControlName>lstAvailableFuncs</GUIControlName> <GUIControlType>System.Windows.Forms.ListBox</GUIControlType> <GUIMemberType>VerifyField</GUIMemberType> </GUIInfo> <GUIInfo> <GUIHandle>2819536</GUIHandle> <GUIText>Add</GUIText> <GUIClassName>WindowsForms10.BUTTON.app3</GUIClassName> <GUIParentText>C# API Text Viewer</GUIParentText> <GUIControlName>btnAdd</GUIControlName> <GUIControlType>System.Windows.Forms.Button</GUIControlType> <GUIMemberType>VerifyField</GUIMemberType> </GUIInfo> <GUIInfo> <GUIHandle>1639876</GUIHandle> <GUIText>Copy</GUIText> <GUIClassName>WindowsForms10.BUTTON.app3</GUIClassName> <GUIParentText>C# API Text Viewer</GUIParentText> <GUIControlName>btnCopy</GUIControlName> <GUIControlType>System.Windows.Forms.Button</GUIControlType> 4351Book.fm Page 265 Tuesday, September 28, 2004 11:21 AM 266 Chapter 7 • Architecture and Implementation of the Automatic GUI Test Tool <GUIMemberType>VerifyField</GUIMemberType> </GUIInfo> <GUIInfo> <GUIHandle>1377762</GUIHandle> <GUIText /> <GUIClassName>WindowsForms10.RichEdit20W.app3</GUIClassName> <GUIParentText>C# API Text Viewer</GUIParentText> <GUIControlName>txtSelected</GUIControlName> <GUIControlType>System.Windows.Forms.RichTextBox</GUIControlType> <GUIMemberType>VerifyField</GUIMemberType> </GUIInfo> <GUIInfo> <GUIHandle>787840</GUIHandle> <GUIText>Remove</GUIText> <GUIClassName>WindowsForms10.BUTTON.app3</GUIClassName> <GUIParentText>C# API Text Viewer</GUIParentText> <GUIControlName>btnRemove</GUIControlName> <GUIControlType>System.Windows.Forms.Button</GUIControlType> <GUIMemberType>VerifyField</GUIMemberType> </GUIInfo> <GUIInfo> <GUIHandle>722368</GUIHandle> <GUIText>Clear</GUIText> <GUIClassName>WindowsForms10.BUTTON.app3</GUIClassName> <GUIParentText>C# API Text Viewer</GUIParentText> <GUIControlName>btnClear</GUIControlName> <GUIControlType>System.Windows.Forms.Button</GUIControlType> <GUIMemberType>VerifyField</GUIMemberType> </GUIInfo> </GUIInfoSerializable> </GUIInfoSerializable> 8. Click the Rerun Test button. When the open file dialog box pops up, navigate to the data store you just saved, C:\Temp\TestC#APITextViewer.xml in this case. Click the Open but- ton. The test is run again and the first regression testing is completed. After steps 7 and 8, the test results are saved in the same folder where the test data store is saved, but the filename is appended with _result.xml. You can open the C:\Temp\TestC#APIText- Viewer_result.xml in a text editor such as Notepad; the results are shown in Listing 7.31. The XML document saves the value of the Text property of a GUI control only at the moment it receives a test action in sequence. ➲ Listing 7.31 The Test Results at This Stage of the Tool Saved in an XML Document <?xml version="1.0" encoding="utf-8"?> <ArrayOfAnyType xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi= ➥"http://www.w3.org/2001/XMLSchema-instance"> <anyType xsi:type="xsd:string">AddAccessAllowedAce</anyType> <anyType xsi:type="xsd:string">Add</anyType> 4351Book.fm Page 266 Tuesday, September 28, 2004 11:21 AM 267 Summary <anyType xsi:type="xsd:string">Copy</anyType> <anyType xsi:type="xsd:string">[DllImport("advapi32.dll")] public static extern int AddAccessAllowedAce([MarshalAs(UnmanagedType.Struct)] ➥ref ACL pAcl, int dwAceRevision, int AccessMask, int pSid); </anyType> <anyType xsi:type="xsd:string">Remove</anyType> <anyType xsi:type="xsd:string">Clear</anyType> </ArrayOfAnyType> Although this tool is still in an early stage at this point, you can use it to test a complex appli- cation. It will find bugs in a product at its earlier development stage, which the other tools can’t do. The available GUI test tools require the user to successfully and manually operate the appli- cation under test in order to record a test script. If there is a bug, the recording has to be aban- doned. The tool user reports this bug for the developers to fix. After the bug is fixed, the user is able to resume the recording process and, possibly, encounter the next bug. The whole pro- cess of recording a successful test script detects bugs one by one manually. However, the AutomatedGUITest tool collects the descriptive properties of the GUI com- ponents and runs the test. Once the GUI components are visible in the application, the opera- tion can be entered into the test data store. There is no physical operation needed until the test executes. Thus, it will automatically find the early stage bugs of a project under development by verifying the behavior of the desired GUI event. Chapter 8 will discuss how to conduct effective verifications and continue to develop the AutomatedGUITest tool with more functions. Summary This chapter discussed the requirements of a fully automated test tool. The improvements of the current testing infrastructures are based on such requirements. A brief introduction pre- sented the fundamentals of the AutomatedGUITest architecture. The rest of this chapter completely implemented a workable GUI test tool and elaborated on its architecture in detail. You can follow the discussion to understand the principles and the techniques for developing such a tool with high degrees of automation. The first time this tool was used, GUI test automation was easily achieved. Since defining a sequence of operating an application, even a simple application, is a highly intellectual and mental process, a machine can’t figure out a suitable order by itself. The traditional test tools have used the capture/playback broadly to make this compensation. However, this tool com- pletes a GUI survey and informs the user of all the GUI components in need of testing. The specification of a GUI event sequence has reduced the need for human user interaction to a minimum. The process is error proof, easy, and not time consuming. 4351Book.fm Page 267 Tuesday, September 28, 2004 11:21 AM 268 Chapter 7 • Architecture and Implementation of the Automatic GUI Test Tool Based on your testing requirements, you may not need to have a dedicated form for the GUI Test Data Collector if you are confident that the tool will assign all of the GUI property values correctly. Using such a form in this book is mainly for instructive purpose and to make the dis- cussion clearer. For some software projects, if the sequential triggering is not important, the tool developers can enable this tool to make numerous combinations of the GUI events ran- domly, thus the tool becomes totally automatic. Usually, it is easier to modify a document by cutting, copying, and pasting than to build a document by specification. Another effective approach for this tool, to avoid manipulating the application manually, is to include all the GUI events from the survey in the XML test data store. Then users scrutinize the GUI actions and make the following modifications: ● Remove the unneeded events ● Rearrange the order of events in a desired sequence ● Duplicate some events in a proper order if they are desired In the next chapter, I will discuss some effective test verification and result presentation methods. Thereafter, the rest of the chapters will be dedicated to developing methods for specific testing requirements and presenting general ideas on how to extend these methods for the test requirements of your organization. 4351Book.fm Page 268 Tuesday, September 28, 2004 11:21 AM [...]... reason testers have created one test script to test against each testing case Testing a single application may require several test scripts and testing data stores However many test scripts there are, no testing method can ensure that an application can be thoroughly tested because manual test scripts created by humans can not cover all the aspects of an application under test On the other hand, it’s... verification and will implement the AutomatedGUITest tool with a few of them as examples You can use these examples to enhance the testing and verifying capabilities of the tool later for your specific test projects Automated Verifications Testing tools can easily achieve the automatic playback of the mouse and keyboard actions by recording a test script The AutomatedGUITest tool even can read instructions... to the AutomatedGUITest project Enhancing the AutomatedGUITest Tool You implemented the AutomatedGUITest tool in Chapter 7 This tool is fully capable of seeing and handling the GUI components by invoking methods from the GUI test library But it conducts the minimum verification at this point Test script execution is driven by a collected GUI data store in the format of an XML document Each GUI component... names and the functionality of the fields and properties before manual test script and verification are implemented A good understanding of the purpose of the application under test is essential for a manual test and a test using the available testing tools However, the AutomatedGUITest tool developed in the preceding chapter has provided a better foundation to understand the the application under test. .. has a counterpart handling method in the GUI test library When other GUI controls need to be handled, you will always be able to add new GUI handling methods into the library In this chapter, you will add code to the AutomatedGUITest tool and enhance its capability for test verification To resume coding the AutomatedGUITest tool, you can create a project folder for this chapter, C:\GUISourceCode\Chapter08... verification and is Enhancing the AutomatedGUITest Tool 277 the most effective one But the testers need to have knowledge of the application under test and know the critical areas in need of verification Testers will be required to carefully develop a test plan Because testers know where defects will and will not occur, they can specify the appropriate members to be verified with each testing step The information... visually observing the execution of the test scripts Automation by such tools and methods is limited U Chapter 7 introduced a different approach to collect GUI information and conduct an active GUI test At this point, the AutomatedGUITest tool is developed and able to conduct a thorough survey of the GUI components contained in an application Users can choose the GUI components to invoke actions from... tool even can read instructions from an XML document to perform the desired mouse clicks However, that is only the first part of the GUI Automated Verifications 275 testing Saving the testing output and automating the verification process are more important and beneficial to a fully automated GUI test The other testing methods focus more on generating testing inputs than automatically generating code for... of the verification methods the tester can choose from First, double-click the Specific radio button and add the code in Listing 8.1 Enhancing the AutomatedGUITest Tool 279 FIGURE 8.1 The updated GUITestDataCollector form for GUI testing and verification data collection ➲ Listing 8.1 Code for the Added Fields and the rdSpecific_CheckedChanged() Event of the Updated GUITestDataCollector Class private... that a manual tester has the flexibility to choose an aspect to verify and configure an Verification Requirements 271 expected result instantly But automated software testing requires that the details of the verification are carefully planned in advance so that the tool can pinpoint to the area and confirm the results Many of these verifications can be done programmatically For example, you can program . to the AutomatedGUITest project. Enhancing the AutomatedGUITest Tool You implemented the AutomatedGUITest tool in Chapter 7. This tool is fully capable of see- ing and handling the GUI components. AM 261 Conducting the First Automatic GUI Testing GUITestUtility.SerilizeInfo(TestCaseStore, GUITestSeqList); GUITestScript guiTS = new GUITestScript(TestCaseStore, currDir); GUITestSeqList = null; } . AM 266 Chapter 7 • Architecture and Implementation of the Automatic GUI Test Tool <GUIMemberType>VerifyField</GUIMemberType> </GUIInfo> <GUIInfo> <GUIHandle>1 377 762</GUIHandle>