mwalleig avatar image
mwalleig asked RICKSTER edited

workspace issue with running from HPQC

From: Walleigh, Mike []
Sent: Monday, June 21, 2010 4:18 PM
To: Chris Bowlds
Subject: Desperate need for some help with QC client operation


Hello Chris,


I am on the hot seat to get QC up and running with iTest…four months for IT to get the test type and a couple of weeks for me. Here is what I am seeing.


Placed this in the system variables ‘HPQC_ITEST_WORKSPACE c:/iTest ‘per the documentation QC-DOC-IGC-340 Rev. 3 as to not use default workspace.


When I run the test set [a single test in this case] from Quality Center…it appears that the ENV is ignored and the test is launched with this location: file:/C:/DOCUME~1/mwalleig/LOCALS~1/Temp/TD_80/b15f6c50/Test/QC-BetaTest_3794/3794/3794/QC-BetaTest.fftc with no reference to the workspace (NO RESOURCES)


I have been playing with the itestcli.bat using a command like this: itestcli.bat -w "c:/iTest" "project://iTest_dev/test_cases/OverHeadDev/QC-BetaTest.fftc" and as you would expect it operates as expected. But utilizing any of the qc switches brings no joy what so ever.


Here is where I think my malfunction lies, within this same document it references 3rd party software to be installed - the first file [vcredist_x86.exe] auto selects its install location. C:\Documents and Settings\Mikew\Desktop\hpqcDownLoadsItest


And the second file [vbrun60sp6.exe] the document references to install queries for the install location - but the document defines no install location.


So the simple question is where is this stuff suppose to live? And is this the source of the above described issue?


Please let me know where I went astray… I’m at my wits end with this windows stuff. And looking at the 4.0 document I would anticipate the same scenario.




iTestinstallation - licensing
10 |950

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

RICKSTER avatar image
RICKSTER answered RICKSTER edited

In iTest 4.4, go to the "Quality Center" tab on the test case and check the box "Store primary test case information in Quality Center" if you want the test case to execute in the workspace pointed to by the environment variable. If this box is not checked, the test case is copied to a temporary location before itestcli is invoked.

10 |950

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

KumarS avatar image
KumarS answered KumarS posted

When you run a testcase through HPQC, the testcase attached to HPQC has to have the association of where the testcase is in the iTest workspace. If there is no such association, we will copy the file which is attached in HPQC to a temporary location and then run that testcase. As long as the testcase uses "project://" urls to access parameters, testbeds, and session profiles, it should execute properly.


If you publish the testcase to HPQC with correct association, then iTest will use the testcase in the workspace to execute.


In iTest 4.0, if you go to QualityCenter tab of a testcase, the checkbox which controls this is called: "Store primary testcase information in Quality Center".


Depending on the users workflow, some people tend to keep testcases in HPQC while others in other source control systems like Subversion. If you keep files in Subversion, then you should store the testcase location information in HPQC so that the testcase to be run is picked up from workspace. If you keep your testcase files in HPQC, then you may or may not want this association and the testcases will be executed from a temporary location (if no such association exists). In such a mode, the testcases have to use absolute "project://" URIs to refer to testbeds, parameters, session profile or other files.

10 |950

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

mwalleig avatar image mwalleig commented ·

After working with support Case #9574 for the majority of last week, it has been determined that the project is not being obtained correctly. I have include the response which was requested in regards to this case and additional have communicated the same to our SME Chris Bowlds.

All of our code is contained within the revision control system Perforce.

Here is the down and dirty of it…Can’t find resources within the project (other than my_project) the HPQC runtime itestcli can’t decode the call project:///resources/library/Library.fftc?systemInit -num_duts [param CONFIG/NUM_DUTS], as it doesn’t know a thing about the project (in this case iTest_dev)


But here is how I see a solution that is viable: the addition of another system variable HPQC_ITEST_PROJECT and the executable jar files to be modified to use that system variable…much like HPQC_ITEST_WORKSPACE and HPQC_ITEST_ARGS.


I believe that if this additional ENV can be implemented within the HPQC utilization of itestcli…it should remove the need for extensive code churn within our multi-project single workspace test environment.

I haven't to date found a viable work around...


0 Likes 0 ·
KumarS avatar image KumarS mwalleig commented ·

This sounds like a bug or some feature interaction issue. I think the projects may not be getting refreshed (I am not completely sure how Perforce integration with iTest works). There is another environment variable which allows you to add additional arguments to itestcli when a testcase is executed from HPQC. You may want to add "refresh workspace" option and see if it solves your problem.


Anyway - I think this should all be working. From your description, it seems more like a bug or a setup issue. I would press on Fanfare Support to get this investigated to determine whether it is a bug or a set up issue.

0 Likes 0 ·
AmishP avatar image AmishP KumarS commented ·



In 3.4.x, the only option you have is to store the iTest test case on the QC server. So at execution time, it will use the workspace defined by HPQC_ITEST_WORKSPACE variable. Now as a result of that, the test will be downloaded from server on to the local client and then run. As a result all the URIs in the test must refer to absolute URIs.


In 4.0, as Kumar mentioned , you could check the "Store primary...." checkbox so that iTest TC is not stored on QC server but instead in some source control. If it is checked, we store the URI of the test case on the QC server instead of the test case. So next time you execute, it is going to invoke itestcli with the TC URI stored in QC. As a result, everything will work eventhough the URIs might not be absolute.


In short, in 3.4.x, make sure all the URIs are absolute.


One thing i noticed is that your URI  "project:///resources/library/Library.fftc?systemInit -num_duts [param CONFIG/NUM_DUTS]" is incorrect. You should use "project://<project name>/<file name>" format. e.g in your case it would be "project://resources/library/Library.fftc?systemInit"(note the double slash instead of 3 slashes).



0 Likes 0 ·
ChrisB avatar image ChrisB AmishP commented ·

I had them try the 4.0 option you described and relative URL's still don't work. Both styles:


project:/// ...

project://[info projectPath main]/ ...



0 Likes 0 ·
YujieL avatar image YujieL ChrisB commented ·

the info command wouldn't work in this scenario because the test case is stored at a temporary location.  It's not part of any project.  I would hardcode the project path and see if that works.

0 Likes 0 ·

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.