Integrating QTP With Non-Mercury Products
Jeff posted a comment about my implication that we have integrated QuickTest Pro into our build processes. I thought I'd elaborate on that a little.
The first thing I should say is that it's not perfect, that we cobbled it together in between developing our testing strategy for our current release and writing regression test cases for some legacy products. We've got plans to improve it, we know pretty much what's missing, but, as with most meta-testing projects, IT WORKS.
The second thing I should say is that we're trying to follow an Agile methodology here, and while we haven't worked it all out, we at least use some of the terminology. If you see some term you're not familiar with, it probably comes from that school.
I'll start with an overview of the process, then discuss some of the steps in detail:
- At about 2am, CruiseControl starts what we call the "Nightly" build
- The Nightly build is just an Ant task that starts by building the software (it's a Tomcat webapp, but that's not critical to the process discussed here)
- A blank test database is created
- The build is unit-tested, then deployed to a test server
- QuickTest is called upon to run a test that just verified the most basic things: a user logs in, then several objects are tested for existence and properties
- The build is declared "Valid", and a more comprehensive suite of tests is run (via QuickTest Pro and other automated testing tools
- After each test is run, test results are reported back to Rally (our Agile project management software)
As you may see, these processes take the place of many Mercury products (Quality Center, IT Governance, etc.). We're a small shop and can't afford all those tools, and even with the amount of man hours spent on these side projects, I'll bet we've only spent a fraction of what we would spend were we to buy them. I can't quantify that, and I'm sure someone at Mercury would argue that I'm not factoring in anything, but one thing I know for sure: there is a heck of a lot about our needs that Mercury doesn't factor in when they charge their astronomical fees and we do actually pay them. They've provided some tools that allow us to get this stuff done, so we're taking full advantage.
And that should put to bed any speculation that we're secretly in league with Mercury and just using this forum to promote their products.
[/rant]
Here's the list of things we used to do it:
We've written a web-based interface to our suite of QuickTest Pro tests, which allows anyone to run any test at any time on the box running QTP. It's a simple cgi script that takes several parameters: you select the test, enter where you want the results stored, and when the test is complete, it redirects you to an html representation of the test results.
What that really get us is the ability to launch any QTP script from any application that can make an HTTP request. Ant can do this, so we just have a series of Ant tasks that call the GET method, like so:
-
<target name="runQuickTest">
-
<get verbose="true" src="http://servername/qtp/LaunchQTP.plx?testname=LoginTest"
-
dest="${outputDirectory}/results.html" />
-
</target>
The @dest attribute just tells Ant where to put the resulting document on the build machine. We post it at a location that will be stored as a link in the Artifacts folder of the given build.
So, a Perl script, a VB script, heck, a wget command can launch QTP. That means you can integrate with nearly any product out there.
Now, as to the Perl script itself? It's kinda involved. I'll post that later when I'm able to cover it in more detail. The plot summary is that it uses the Win32::OLE library (available from CPAN, but usually distributed with any ActiveState version of Perl) to do exactly the same kind of interaction with QTP as you could do with VBS. The fact that it's in Perl means we don't have to do any special magic to get to it from within our test harness or any of our other interfaces, most of which are written in Perl.
The ability to integrate QTP tests with our existing build process was invaluable. It allowed us to keep on the track we were on before, using Open Source and keeping tight control over the minutae of our processes.
Tags: QTP-API, QTP-Automation, QuickTest Pro, QuickTest-Pro-API, Software-Testing
July 31st, 2006 at 6:16 am
Hi all the Guru’s of QTP….
I am new to this testing line, and recently been trainied on this QTP.I like this tool very much…but doesn’t get a chance to implement it on the project.
I as a starter want help from u peoples as I find problem in Writing the regular expressions and parameterisation.So can somebody provide me with some demo Scripts showing some discriptive programing also ….
I be waiting for reply …
Reply to Gagan Preet
August 2nd, 2006 at 12:23 pm
Can you provide more detail on how you invoked QTP thru the cgiscript. I am new to QTP and want to integrate with our continous build tool - cruise control like you.
Reply to QTPNovice
September 29th, 2006 at 7:28 am
[...] Like I said before, I don’t know of any reason you couldn’t use Apache as your web server, but I haven’t actually tested it. [...]
Reply to The Software Inquisition » A CGI Script to Launch QTP Tests
October 6th, 2006 at 11:09 am
Could you please give me the code to launch QTP from command line using VBScript.
Reply to Sanjay
January 2nd, 2007 at 7:32 am
Hi,
I’m trying to run some QTP tests on our application however I need to run EMMA (a code coverage tool) to see how effective our tests are.
I need to launch and run the QTP tests from within ANT. Is this possible? And if so, can you please give me some pointers on how to do so?
Cheers
Reply to Nush
May 8th, 2007 at 11:51 pm
I have a requirement something like this where in I have to run my QTP Scripts one after another from another system. I can send http request.
So If you could give me this web-based interface developed for running QTP scripts with all the information of setting it up and using it, it would help me a lot. Please respond.
Reply to Harsha
May 10th, 2007 at 8:24 am
Are you familiar with JUnit Tests? We would like to automate QTP scripts in a similar fashion and also tie them to cruisecontrol for reporting.
Reply to Rohit
May 10th, 2007 at 8:24 am
Can we take the scripts developed by you and point them to another instance of the application? I will walk you through tomorrow to show what I mean.
Reply to Rohit
June 15th, 2007 at 6:07 pm
What I don’t get is: LaunchQTP.plx which is used in your Ant GET example, do you built it on the fly with another script or it sits in your ../QTP directory?
Could you please post this script?
Thank you
Reply to Dan_M
August 25th, 2007 at 1:39 am
Yahoo Update Database…
Add your blog to yahoo database…
Reply to RobertM
January 15th, 2008 at 4:53 am
Can we Perl scripting for QTP
Reply to akila
May 26th, 2008 at 9:40 pm
Hi all
Not sure how this list works… however…
Does anyone know where I’d find some doco for the PerlScript API. From Quality Center, I easily created a test, included below.
The comments in the test Steps is fromt he text I’d typed into the actual test step Description and Expected Results.
I can’t seem to find any doco that articulates the methods and variables available from the $currentRun or $Step objects.
What I’d like to do is access the Test Name, Step Name(s), Descriptions and Expected Results…. then I can easily write back the Actual Results and Status (as per the code below)… after having done the real work via Perl.
…so, to reiterate the question, is there any Doco available for those methods/vars?
thanks.
# t5 [PerlScript]
# Created by Quality Center
# 27/05/2008 12:11:16 PM
# ====================================================
# —————————————————-
# Main Test Function
# Debug - Boolean. Equals to false if running in [Test Mode] : reporting to Quality Center
# CurrentTestSet - [OTA COM Library].TestSet.
# CurrentTest - [OTA COM Library].TSTest.
# CurrentRun - [OTA COM Library].Run.
# —————————————————-
sub Test_Main
{
($Debug, $CurrentTestSet, $CurrentTest, $CurrentRun)=@_;
# clear output window
$TDOutput->Clear();
# TODO: put your code here
if (!$Debug)
{
$Steps = $CurrentRun->StepFactory->NewList(”");
# first step
# Description:
# do this
# do that
# do the other
# Expected Result:
# some good stuff…
$Steps->Item(1)->LetProperty($Field, “ST_ACTUAL”, “”);
$Steps->Item(1)->{Status} = “Passed”;
# second step
# Description:
# now do this
# now do that
# Expected Result:
# now check this out
$Steps->Item(2)->LetProperty($Field, “ST_ACTUAL”, “”);
$Steps->Item(2)->{Status} = “Passed”;
# update steps
$Steps->Post();
}
# handle errors
if (Win32::OLE->LastError())
{
$TDOutput->Print(”Run-time error : “, Win32::OLE->LastError());
# update execution status in “Test” mode
if (!$Debug)
{
$CurrentRun->{Status} = “Failed”;
$CurrentTest->{Status} = “Failed”;
}
}
}
Reply to Steve