Contributions
- 2.5KViews0likes2Comments
Re: Message posted to wrong log folder
Indeed... Idon't remember clearly, but maybe I could catch the problem (maybe a pop-folder in a different place wasn't always invoked), but then I dropped the idea of maintaining two parallel 2nd level folders in the log, since it proved to be hard to track things from historical point of view, what happened first, and what next.2.5KViews0likes4CommentsRe: Log saved in OnStopTest event missing latest errors
Hi Joseph, Thanks for the reply. Yes, I use SaveResultsAs, and it saves the log correctly, but without the error entries which cause the event to be triggered. It's like those events would be logged after the event handler completes.1.1KViews0likes0CommentsLog saved in OnStopTest event missing latest errors
Hi, I have created an OnStopTest event handler to be able to send email notification for prematurely terminated tests, such as when a tested app cannot be launched and the such. In my event handler, I save the log to an MHT, zip the MHT, and send an email with the ZIP file attached. Now my problem is that the MHT file does not contain the error events causing the tests to terminate, that is, exactly those few entries are missing which would be relevant. Taking a look at TestComplete's native log, I realized that the errors are logged only after the event handler completes. (I know this because the mail sending routing logs a message to the log upon successful mail sending, and the entries for the terminating errors appear below this.) Is there a way to save a version of the log which contains the errors causing execution to terminate? I've attached a screenshot to explain more clearly what is contained in the MHT and what I'm missing badly.1.1KViews0likes2CommentsRe: The operation cannot be performed, because the user session is disconnected.
Thanks a lot! It seems working this way. To quickly sum the solution for other readers: I do not need the tscon in my script. I only need to log on to the computer, then issue a tscon <sessionID> /dest:console command, and everything keep up and running. No more errors claiming for disconn'd user session.5.5KViews1like2CommentsRe: The operation cannot be performed, because the user session is disconnected.
Oh I see, you mean to issue the tscon redirection once scheduling the task. Actually why I created two version of the tscon command is that it turned out that session id/name could not be obtained from the shell when Task Scheduler triggered the test run, even if I kept the remote desktop window open. Can you confirm the solution worked for you when you scheduled the task, instead of manually starting?5.5KViews0likes4CommentsRe: The operation cannot be performed, because the user session is disconnected.
Hi, I'm sure it helps, however I need to ask for the details. Where and how should I exit from the script with redirection? Do you mean I should replace my call to tscon with the one provided? And how can I make sure that generic user (which is our goal to implement) always runs in session 2?5.5KViews0likes6CommentsThe operation cannot be performed, because the user session is disconnected.
Hi, I have a GUI test suite which I need to run on a remote computer according to a schedule, and I came to a problem I seem to unable to circumvent. To put it simple, the test suite performs GUI testing of a rich Windows client. The test package contains a VB script which launches TestExecute and supplies the various parameters required. I run this script on a test machine, accessed via Remote Desktop (that is, if the computer is named XY, the script is run on XY, accessed remotely, and launches TestExecute on XY). As part of this script, I have included a tscon.exe redirection so that the remote desktop window can be closed. I have created a scheduled task running this VB script regularly. When I run the script directly, it properly closes the remote desktop connection, and completes the tests successfully. When run by the task scheduler, it fails at some point with the error The operation cannot be performed, because the user session is disconnected. The relevant portion of my VB script ([...] indicates removed code]: ' Paramteres -------------------------------------------------------------------------------------- ' Dim TCPath ' Path to TestComplete.exe Dim ProjectSuite ' Full path of the project suite to invoke Dim LogFolder ' Path to log folder Dim IniConfPath ' Path to the configuration ini file Dim LetAlone ' Set to True when test runs on remote desktop which you don't want to ' keep open ' Set parameter values TCPath = [...] ProjectSuite = [...] LogFolder = [...] IniConfPath = [...] LetAlone = true ' Global variables -------------------------------------------------------------------------------- ' Dim fso ' For file system access Dim sh ' Shell object for environment variables Dim operationalLog ' Log file for Test Complete runtime / command line errors Dim businessLog ' Test log in MHT format Dim timestamp ' Timestamp of invocation Dim sessionName ' Session name for remote desktop sessions ' Preparatory steps ------------------------------------------------------------------------------- silent = false timestamp = Now() Set fso = CreateObject("Scripting.FileSystemObject") Set sh = CreateObject("WScript.Shell") [...] ' Check if we need to redirect session so that GUI tests can run even when ' remote desktop session is terminated. If LetAlone Then ' Get session name sessionName = sh.ExpandEnvironmentStrings("%SESSIONNAME%") ' Redirect session ' Version 1: when run manually on the remote computer ' sh.Run "tscon.exe " & sessionName & " /dest:console" ' Version 2: when run by task scheduler sh.Run "tscon.exe 0 /dest:console" End If ' Compose command line for test execution Dim command command = [...] ' Launch test sh.Run command, bWaitOnReturn = False When starting manually on the remote desktop, the code line sh.Run "tscon.exe " & sessionName & " /dest:console" is uncommented, and code line sh.Run "tscon.exe 0 /dest:console" is commented. It properly obtains the session name and redirects it to the console, the connection is closed, and the test completes successfully. However I found that task scheduler always creates a session with ID of zero, so for the production configuration, the first line is commented out, and the second is made effective. The script properly closes the connection when run by task scheduler, and it performs successfully one of the GUI tests. This test opens the tested application and measures startup time by waiting for a control on its main screen to appear. The second test is more complex, and it includes steps of clicking a DevEx XtraBars ribbon. This is the point where it fails: Aliases.Foo.Ribbon.ClickItem("Project|Create Project|New Project|DropDownButton|New Project"); Do you have any tips for a workaround? What other differences may there be between running under a "real" remote session and under the session 0 created or used by Task Scheduler? I cannot get the point why it succeeds under a named session, and why not under session 0.Solved5.6KViews0likes8Comments