WinRunner and Test Complete Comparison
1. SUPPORTED LANGUAGES:
a. Mercury WinRunner:
It makes use of its own C-like test script language. No other language support is
provided. TSL is easy to use & very user friendly.
b. TestComplete:
It makes use of C++ Script, C# Script, Jscript, VBScript and DelphiScript. What I have
found using TestComplete is that it is not user friendly in terms of coding. It requires
significant effort to get used to the syntax of the scripting languages supported unlike
Mercury WinRunner.
2. EASINESS:
a. Mercury WinRunner:
WinRunner is very easy to use because of its C-like syntax.
b. TestComplete:
User has to get familiarized with the syntax of scripting languages in order to use it.
3. FEATURE ENRICHMENT:
a. Mercury WinRunner:
Mercury WinRunner has relatively less features as compared to TestComplete, e.g. to test
an application, it needs to be run through script. Moreover, the objects (buttons, labels
etc) stored during the recording are mapped onto a GUI Map Editor and needs to be
stored as a GUI MAP File. If the stored GUI MAP file is lost, it’s a tough job to record
everything all over again.
b. TestComplete:
It is enriched with many features as compared to Mercury WinRunner, e.g. any
application being tested can be added to the “TestedApps” list without writing a script for
it. In addition to this, the object browser is a prominent feature which displays currently
running processes in the system along with their properties, fields, methods & events.
4. TEST RECORDING:
a. Mercury WinRunner:
It supports Test Recording.
b. TestComplete:
It supports Test Recording.
5. TEST RE-RUNNING/EXECUTION:
a. Mercury WinRunner:
It supports Test-rerunning & execution.
b. TestComplete:
It supports Test-rerunning & execution.
6. ANALOG RECORDING:
a. Mercury WinRunner:
It supports analog recording.
b. TestComplete:
I haven’t come across using any feature like analog recording.
7. IMAGE CAPTURE:
a. Mercury WinRunner:
It supports image capture but stores the captured images inside the project folder
invisible to user.
b. TestComplete:
It supports image capture and stores the capture images within the project tree in
Project Workspace visible to user.
8. TEST REPORT GENERATION:
a. Mercury WinRunner:
It supports executing a re-run in three modes:
i. Verify Mode: It keeps track of every test iteration & stores it in the project folder.
ii. Debug Mode: It does not keep track of actions & previous test iterations.
iii. Update Mode: Similar to verify mode.
b. TestComplete:
There are no separate execution modes. As a test run is executed, all activities are logged
inside the project tree of Project Explorer.
9. TRACK OF ALL PREVIOUS REPORTS
a. Mercury WinRunner:
It keeps track of all previous test attempts, if the test was run in Verify/Update Mode. All
test results are stored inside the project folder.
b. TestComplete:
It also keeps track of all previous test attempts within the project tree in Project Explorer.
10. DATABASE CONNECTIVITY:
a. Mercury WinRunner:
It supports Database connectivity.
b. TestComplete:
It supports Database connectivity.
11. BUILT IN FUNCTIONS:
a. Mercury WinRunner:
A large number of built in functions are available in Mercury WinRunner. These functions
are related to ActiveX controls, Arithmetic, Database, Drag drop, GUI configuration, GUI
Verification etc. Such specific functions are very useful and most of the times fulfill the
needs. All scripts currently written in TSL for Validity SDK make an excessive use of these
functions. Moreover, further more are also available freely on the internet. There is no
.NET support available in Mercury WinRunner.
b. TestComplete:
It also contains a huge library of functions. But, I could not find the specific functions as
WinRunner is equipped with. With TestComplete we can call functions from our scripts
that reside in any .NET assembly which require .NET Framework.
12. SPECIFIC FUNCTIONS RELATED TO GUI MATCHING & STRING:
a. Mercury WinRunner:
WinRunner supports capturing a portion of screen or an object, which ultimately helps
reading that object again when test is run.
b. TestComplete:
No such feature was observed in TestComplete.
13. LOGGING:
a. Mercury WinRunner:
Specific functions for logging are provided in Mercury WinRunner.
b. TestComplete:
Specific functions for logging are also provided in TestComplete.
14. SUPPORTED TESTING TECHNIQUES:
a. Mercury WinRunner:
Mercury WinRunner supports only web applications & windows applications testing
(functional & interface testing). It does not support load tests or unit tests.
b. TestComplete:
TestComplete supports a large number of testing techniques as mentioned in the
comparison chart above.
15. ACCESS INTERNAL OBJECTS, METHODS AND PROPERTIES OF APPLICATIONS:
a. Mercury WinRunner:
Feature not available in Mercury WinRunner.
b. TestComplete:
All internal objects, methods & properties of applications are accessible through Object
Browser in TestComplete.
16. AVAILABLE AUTOMATION FRAMEWORKS:
a. Mercury WinRunner:
A number of automation frameworks are available on the internet for free of cost like
WRSAFS (WinRunner Software Automation Framework Support), SAFS (Software
Automation Framework Support).
Software automation frameworks reduce the effort of changing the written script every
time, the GUI of an application under test changes.
b. TestComplete:
I have not encountered any such automation framework related to TestComplete yet.
17. SOURCE CONTROL SUPPORT:
a. Mercury WinRunner:
No support for Source Control.
b. TestComplete:
It provides support for Microsoft Visual Source Safe.
a. Mercury WinRunner:
It makes use of its own C-like test script language. No other language support is
provided. TSL is easy to use & very user friendly.
b. TestComplete:
It makes use of C++ Script, C# Script, Jscript, VBScript and DelphiScript. What I have
found using TestComplete is that it is not user friendly in terms of coding. It requires
significant effort to get used to the syntax of the scripting languages supported unlike
Mercury WinRunner.
2. EASINESS:
a. Mercury WinRunner:
WinRunner is very easy to use because of its C-like syntax.
b. TestComplete:
User has to get familiarized with the syntax of scripting languages in order to use it.
3. FEATURE ENRICHMENT:
a. Mercury WinRunner:
Mercury WinRunner has relatively less features as compared to TestComplete, e.g. to test
an application, it needs to be run through script. Moreover, the objects (buttons, labels
etc) stored during the recording are mapped onto a GUI Map Editor and needs to be
stored as a GUI MAP File. If the stored GUI MAP file is lost, it’s a tough job to record
everything all over again.
b. TestComplete:
It is enriched with many features as compared to Mercury WinRunner, e.g. any
application being tested can be added to the “TestedApps” list without writing a script for
it. In addition to this, the object browser is a prominent feature which displays currently
running processes in the system along with their properties, fields, methods & events.
4. TEST RECORDING:
a. Mercury WinRunner:
It supports Test Recording.
b. TestComplete:
It supports Test Recording.
5. TEST RE-RUNNING/EXECUTION:
a. Mercury WinRunner:
It supports Test-rerunning & execution.
b. TestComplete:
It supports Test-rerunning & execution.
6. ANALOG RECORDING:
a. Mercury WinRunner:
It supports analog recording.
b. TestComplete:
I haven’t come across using any feature like analog recording.
7. IMAGE CAPTURE:
a. Mercury WinRunner:
It supports image capture but stores the captured images inside the project folder
invisible to user.
b. TestComplete:
It supports image capture and stores the capture images within the project tree in
Project Workspace visible to user.
8. TEST REPORT GENERATION:
a. Mercury WinRunner:
It supports executing a re-run in three modes:
i. Verify Mode: It keeps track of every test iteration & stores it in the project folder.
ii. Debug Mode: It does not keep track of actions & previous test iterations.
iii. Update Mode: Similar to verify mode.
b. TestComplete:
There are no separate execution modes. As a test run is executed, all activities are logged
inside the project tree of Project Explorer.
9. TRACK OF ALL PREVIOUS REPORTS
a. Mercury WinRunner:
It keeps track of all previous test attempts, if the test was run in Verify/Update Mode. All
test results are stored inside the project folder.
b. TestComplete:
It also keeps track of all previous test attempts within the project tree in Project Explorer.
10. DATABASE CONNECTIVITY:
a. Mercury WinRunner:
It supports Database connectivity.
b. TestComplete:
It supports Database connectivity.
11. BUILT IN FUNCTIONS:
a. Mercury WinRunner:
A large number of built in functions are available in Mercury WinRunner. These functions
are related to ActiveX controls, Arithmetic, Database, Drag drop, GUI configuration, GUI
Verification etc. Such specific functions are very useful and most of the times fulfill the
needs. All scripts currently written in TSL for Validity SDK make an excessive use of these
functions. Moreover, further more are also available freely on the internet. There is no
.NET support available in Mercury WinRunner.
b. TestComplete:
It also contains a huge library of functions. But, I could not find the specific functions as
WinRunner is equipped with. With TestComplete we can call functions from our scripts
that reside in any .NET assembly which require .NET Framework.
12. SPECIFIC FUNCTIONS RELATED TO GUI MATCHING & STRING:
a. Mercury WinRunner:
WinRunner supports capturing a portion of screen or an object, which ultimately helps
reading that object again when test is run.
b. TestComplete:
No such feature was observed in TestComplete.
13. LOGGING:
a. Mercury WinRunner:
Specific functions for logging are provided in Mercury WinRunner.
b. TestComplete:
Specific functions for logging are also provided in TestComplete.
14. SUPPORTED TESTING TECHNIQUES:
a. Mercury WinRunner:
Mercury WinRunner supports only web applications & windows applications testing
(functional & interface testing). It does not support load tests or unit tests.
b. TestComplete:
TestComplete supports a large number of testing techniques as mentioned in the
comparison chart above.
15. ACCESS INTERNAL OBJECTS, METHODS AND PROPERTIES OF APPLICATIONS:
a. Mercury WinRunner:
Feature not available in Mercury WinRunner.
b. TestComplete:
All internal objects, methods & properties of applications are accessible through Object
Browser in TestComplete.
16. AVAILABLE AUTOMATION FRAMEWORKS:
a. Mercury WinRunner:
A number of automation frameworks are available on the internet for free of cost like
WRSAFS (WinRunner Software Automation Framework Support), SAFS (Software
Automation Framework Support).
Software automation frameworks reduce the effort of changing the written script every
time, the GUI of an application under test changes.
b. TestComplete:
I have not encountered any such automation framework related to TestComplete yet.
17. SOURCE CONTROL SUPPORT:
a. Mercury WinRunner:
No support for Source Control.
b. TestComplete:
It provides support for Microsoft Visual Source Safe.
Comments
Win runner online training
Win runner online training in hyderabad