Details
-
Type:
Bug
-
Status: Reopened (View Workflow)
-
Priority:
Major
-
Resolution: Unresolved
-
Component/s: hp-application-automation-tools-plugin
-
Environment:Jenkins master 1.606
Jenkins slave (where QTP tests are run) Windows Server 2012 (amd64)
HP Application Automation Tools 3.0.7
-
Similar Issues:
Description
1) Install HP Application Automation Tools 3.0.7 Plugin
2) Select Build action -> Execute HP tests from file system
3) Fill Tests field -> Specify path to several tests
4) Trigger job execution
Actual: only the first test is executed, all other tests are NOT executed and "QTP is not launched" error is reported
Expected: all specified tests are launched and executed
Attachments
Activity
doesn't reproduce anymore. Can be closed
Igor Tereshchuk
added a comment - doesn't reproduce anymore. Can be closed I am having the same issue and we use the latest version. I just checked the code in GitHub and noticed that there is a huge try block that is catched by one Exception:
Lines: 106 to 203.
Whatever creates here the issue we have no idea about it as we only get a Qtp Not Launched info.
Can you please reopen it and or add more debugging info, so that we see at least see which part is the problematic one.
For 100 lines of code getting only a Qtp NOt Launched message is not helping.
I am having the same issue and we use the latest version. I just checked the code in GitHub and noticed that there is a huge try block that is catched by one Exception:
Lines: 106 to 203.
Whatever creates here the issue we have no idea about it as we only get a Qtp Not Launched info.
Can you please reopen it and or add more debugging info, so that we see at least see which part is the problematic one.
For 100 lines of code getting only a Qtp NOt Launched message is not helping.
We know the exception happens at line 197 _qtpApplication.Launch();
but we dont know why the launch failed, a logic guessing is you are having some kind of user account control issue, you may try to run this with Admin account.
Thanks. Actually my info was incomplete. Just starting a search it revealed that the error can be returned from 3 different places.
- HandleOutputArguments
- The big try block we discussed about
- 212 to 219 - which is checking if the currently opened test was modified
If it would be number two, we would get as error message the message of the Exception(ErrorDesc). However we get as error message "QTP Not Started" which is coming from:
| if (_qtpApplication.Test != null && _qtpApplication.Test.Modified) | |
| { | |
| var message = Resources.QtpNotLaunchedError; | |
| errorReason = message; | |
| runDesc.TestState = TestState.Error; | |
| runDesc.ErrorDesc = errorReason; | |
| return runDesc; | |
| } |
Compared to:
| catch (Exception e) | |
| { | |
| errorReason = Resources.QtpNotLaunchedError; | |
| runDesc.TestState = TestState.Error; | |
| runDesc.ReportLocation = ""; | |
| runDesc.ErrorDesc = e.Message; | |
| return runDesc; | |
| } |
where ErrorDesc is the Message from the exception.
So our idea is that the check for opened and modified Test Cases is creating the problem.
Are we on the good way?
SO I've forked the repository and removed the part mentioned: Lines 212 - to 219.
It works fine.
Afterwards I have changed the error message to Resources.QtpUnsavedError; and this is what we receive. Now at least we can be sure that the error is here.
I tried a few things manually and this is what I noticed. After I execute a Test Case the Save Option becomes available, meaning something is changed and the Modified flag is True. I could not really track back what did really change but UFT is prompting if I want to save it: again this is happening manually as well.
Now the proposal would be: In the QtpTestCleanup just close the Test Case after the Stop(), without save.
In such a scenario we can be sure that the test case we run is gone, even if it set the modified flag, and the next test case will not get the modified flag, only if somebody let a test case open.
Of course we should change the error message returned as well.
Here are my edits: https://github.com/jbalooka/hpe-application-automation-tools-plugin/commit/81498f1bd5fb67de035e4158d1a1652bbf5509fa
Thank you for your investigation, it really helped a lot.
Is it possible to share your UFT test so we can continue investigation? you can attach a zip file to this issue. We tried to run a simple UFT test, it was not marked as dirty, I can't think of any case that may cause the test become dirty.
I looked into the github change you posted, closing UFT regardless if it has a dirty test is an option but it is risky that we would like to run a full test before add this fix to our next release.
i will keep monitoring this thread, hopefully the problem can be solved soon.
OKay. So I just did a run again and used the git diff to tell me the differences.
Our scripts do modify the design-time datatable as well not just the Run-time aka After a script is finished, the content of the run-time datatable is transferred back to the Default.xls file of the Test(which is the Design time table).
Our developers are using this as an easy way of persistence . In this way it is very easy to do run from steps and debug from steps.
I noticed that the QtpTestCleanup is used in other places as well, so your concerns are valid.
As an alternative we would propose then the explicit edition of Test.Close after a test was executed.
In this way all the other use cases could remain intacted, and use cases like ours(I am sure we are not the only one using UFT in such unorthodox ways) could still go on.
Glad to hear that you found root cause.
We had a discussion about this issue moment ago, we will change the error message from "unable to launch UFT" to "Unable to close UFT due to unsaved test", whether save the test or not is left for user to decide. You should be able to see the change in next release.
Thank you for your time and effort.
xiwen zhao I understand this issue is resolved?
Hi Daniel,
Due to release plan change this defect was moved to future release. It appears to have low priority because changing error message does not really solve the issue, it only gives a better hint for users.
cannot reproduce on my machine with UFT 14 build 1708 + Jenkins Plugin 5.0.1-beta-snapshot, by looking at the log i guess after the first run UFT is not closed properly for some reason.
QA will test again.