EditTestComplete Training Information
Purchase TestComplete from Falafel at a
10% discount.
Microsoft Script Debugger - required for debugging support in TestComplete.
EditSample Web App & Web Service
ASP.NET TestComplete Sample Web App
ASP.NET Test Web service
ASP.NET sample website and web service
EditBuilding TestComplete Sample Applications
If you want to work with the Sample applications included with TestComplete you can build the .NET versions from the command line without having VS.NET installed as long as you have the .NET framework installed.
To build the C# versions of the samples:
- Change to the direction of the sample you wish to compile
- Execute the following command %SystemRoot%\Microsoft.NET\Framework\v2.0.50272\msbuild.exe
EditOther Resources
Microsoft Word Object Model OverviewEditTools
Process Explorer
Araxis Merge
MSSQL Management Studio Express
EditWorking with the Log and Sys Objects- Create a New Project
- Add a function to the script which outputs to the log information about the machine that the test is executing on. (Examples/ideas)
EditWorking with Stores and comparing data against the store- Create a new project
- Add the Stores Item to the project
- Validate an onscreen object's data against data from the store
EditCreate name mappings and use the name mappings in script- Create a new project
- Add the Name Mapping Item to your project
- Create a Name mapping to an object on screen (use Map Object from Screen toolbar button)
- Using script create a function to write the objects name to the log using Log.Message
EditWorking with Web Services- Add the Web Services Item to your project
- Using the following WSDL as your web service: WSDL
- Create a checkpoint against a web services method to validate the result
EditCreate Manual Tests- Create a new project
- Add the Manual Test item to the project
- Create new manual test for Windows Notepad
|
EditDebugging- Create a new Project
- Record a test script against Windows Notepad
- Start Notepad
- Type some text
- Change the Font
- End the recording and switch to the code editor
- Find the new recorded function
- Set a breakpoint on the first line of the function
- Right click the function and select Run current Routine
- When the breakpoint is hit click the watch window and add a watch for one of the variables from the function
- If the function's Value is [Object] use the Object Browser to locate that object and find a property you can evaluate
- Then change the watch to view the value of that property
EditUsing the Code Editor/Code Explorer- Create a new project
- Record a test against Windows Notepad
- Add a new script to the project
- Using the code explorer move the recorded test to the new script file
EditHandling unexpected Windows- Create a new project
- Add notepad to the list of Tested Apps
|
EditCopying a manual test (from AutomatedQA)
- Create a copy of the folder that stores the manual test files (for example, copy the contents of the "<ProjectFolder>\ManualTests\ManualTest1" folder to the "<ProjectFolder>\ManualTests\ManualTest2" folder).
- Rename the copy of the manual test file (it has the .tcMT extension). In other words, you need to rename the "ManualTest1.tcMT" file located in the "ManualTest2" folder to "ManualTest2.tcMT".
- Change the project item name in the copy of the manual test file. To do this, you need to find the following line in the "ManualTest2.tcMT" file and specify the "value" attribute as "ManualTest2":
<Prp name="node name" type="S" value="ManualTest1"/>
- Add the copy of the manual test to your project as an existing item.
EditUsing passwords with TestComplete (from AutomatedQA)
It's best not to have automated tests access sensitive systems.
The second best method is to have external security for the test workstations and not try to make the tests themselves secure.
After that, you get into compromises.
A pretty good method is to require the password to be entered manually when the test is run.
When the test starts, pop up a dialog and prompt the tester to manually enter the password. (See help topic "Entering Passwords") Store it in a global variable that doesn't persist when the test isn't executing. Use it while the test is running. Lose it when it's finished. The password is only in memory and is gone from the system when the test run is completed.
That could be inconvenient if there are many passwords or the tests are being re-started often.
You could store the passwords on a secure SQL DB or network file share and have the tester user account authenticate/login when they begin working so the test scripts have access to the securely stored passwords while the user is logged in to the other system.
A less secure method is to use a master password to encrypt the passwords used in the test and store those passwords in an unprotected file on the hard drive. The tester would enter the master password at the start of each test run and the test script would have to decrypt the passwords.