List Icon
Archiv Mailingliste

2019 bis Juli 2022  2018  | 2017 2016 2015 | 2014 | 2013

Die Mailingliste ist seit Juli 2022 geschlossen, dient aber weiterhin als Informationsarchiv zu QF-Test.
Wenn Sie aber über Neuerungen zu QF-Test informiert bleiben wollen, können Sie einfach unseren
Newsletter abonnieren

Um aktuell die Informationen zu jeder Release - auch Minor Releases - zu bekommen, können Sie den
RSS-Feed abonnieren oder uns in sozialen Medien folgen.
Alternativ bietet QF-Test auch selbst eine Versionsinformation an.

Eine weitere Informationsquelle ist unser Blog, in dem es aktuelle Beiträge zu allgemeinen Themen, zur Firma QFS und auch diverse "How-Tos" gibt:
Blog abonnieren


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [QF-Test] QF-Test playback lockup when performing actions on specific components


  • Subject: Re: [QF-Test] QF-Test playback lockup when performing actions on specific components
  • From: Gregor Schmid <Gregor.Schmid@?.de>
  • Date: Sat, 13 Sep 2014 20:28:42 +0200

Hello Ron,

that's an interesting case. QF-Test itself is not deadlocked and
according to your description neither is the SUT. Such a case can
happen, for example, when you trigger something from an SUT script
which triggers a nested event loop, e.g. to display a modal dialog.
The SUT is still live, but control doesn't return to the script until
the dialog is closed.

There are various workarounds available, depending on the actual
situation. If after the deadlock timeout the test can continue as if
nothing had happened, a common solution is:

+ Server script 1
+ Try
  + Action that triggers the deadlock
  + Catch DeadlockTimeoutException
  + Finally
    + Server script 2

In server script 1, set the deadlock detection timeout to a reasonable
small value, e.g. 3 seconds:

rc.setOption(Options.OPT_PLAY_TIMEOUT_DEADLOCK, 3)

In server script 2, reset the option

rc.unsetOption(Options.OPT_PLAY_TIMEOUT_DEADLOCK)

If that is not good enough, please send a run-log showing the
exception to our support. It would also be helpful if you could send a
full thread dump taken at the time while QF-Test is waiting for the
SUT. You can take it either with QF-Test via the >>Clients<< menu,
provided that output from the SUT is shown in QF-Test, or with a tool
like jvisualvm that comes with the JDK (not with a JRE though).

Best regards,
    Greg

Ron Britzius <britziusr@?.net> writes:

> Hello,
>
> The issue we are experiencing is that when QF-Test attempts to perform an action on specific
> components (there are 2 known examples in our project) it will occasionally completely lock up and
> effectively end that test-run.  When it occurs, the play arrow remains highlighted and the pause
> button does not change (as if it is still actively playing). It will remain this way until the
> deadlock detection timeout elapses and the SUT lockup message appears even though the SUT is
> perfectly fine. 
>
> If the playback stop button is pressed while QF-Test is locked up like this, the action it became
> stuck on will execute. If the dialog or window that contains the component it became locked up on
> is manually closed during lock-up the playback will move to the next step.
>
> Both components seem to be search-related. One is a search bar and the other is a dropdown combo
> that populates its combo list based on the text you enter in the combo text box.
>
> Thank you,
> Ron Britzius 
>
> _______________________________________________
> qftest-list mailing list
> qftest-list@?.de
> http://www.qfs.de/mailman/listinfo/qftest-list

--
Gregor Schmid

E: gregor.schmid@?.de
T: +49 (0)8171 38648-11
F: +49 (0)8171 38648-16

Quality First Software GmbH | www.qfs.de
Tulpenstr. 41 | 82538 Geretsried | Germany
GF Gregor Schmid, Karlheinz Kellerer
HRB München 140833