Monday, 11 January 2016

Bamboo and Squish session 1 vs session 0

Bamboo and Squish 
using different sessions

I am looking at integrating squish and bamboo for GUI testing using QT. Squish is a good choice of tool for this as the program is written in python and Squish can run scripts in python and so a good deal of knowledge can be carried over. However these are some caveats to this approach, the main one I shall address today is that the service and the user GUI run under different sessions and are therefore hard to integrate.

Windows uses different sessions for services, as Bamboo only runs as a service, it runs in session 0, so if a application is started in that session it will not have a GUI. This creates an issue for GUI testing. Squish helpfully gives an API that the squishrunner can use to solve this:


This tells the squish server to start the configured AUT, this will be created in the same session as the squish server which needs to be a user session so that a GUI is created. As you can see that's an other caveat of the process, in that the server needs to be in a user session and so it cannot be started by the bamboo service. Therefore we need to use the auto log-on feature of windows documentation on the windows site here which are summarised below:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]

Once logged on we can use a startup script (simple bat file in the startup folder) to run the squishserver and we have a squish server running in a user session that can talk to a squishrunner running in session 0 with the services.

There is another issue with


It starts the application from scratch, for an application with a large startup time this can be quite annoying and time consuming for each test that you need to run a better way is using the startaut application to start the application in an "attachable state" from the first instance. Therefore I wrote a little wrapper for this application so that the AUT is started from the python script in an attachable way. To start it in the user context I compiled the python using py2exe and pass it the attachable parameters...

   This will create the start aut wrapper for squish and bamboo  
   using py2exe it will start the AUT on the port given.  
 from __future__ import print_function  
 __author__ = 'jdengel'  
 # main program starts here  
 import os  
 import sys  
 import subprocess  
 import time  
 def is_number(string_to_test):  
   :param string_to_test: checks string is a int  
   :return: BOOL  
     return True  
   except ValueError:  
     return False  
 def validate_args():  
   validate the arguments  
   1. number port  
   2. AUT to start  
   3. location of the startaut from squish   
   if len(sys.argv) != 4:  
     print("incorrect number of paramter given\n"  
        "port, app, location of startaut")  
     return 2  
   if is_number(sys.argv[1]) is False:  
     print("Port is not a number {0}".format(sys.argv[1]))  
     return 3  
   if os.path.isfile(sys.argv[2]) is False:  
     print("file to start does not exist, this is an issue {0}".format(sys.argv[2]))  
     return 4  
   if os.path.isfile(sys.argv[3]) is False:  
     print("start aut application does not exist {0}".format(sys.argv[3]))  
     return 5  
   return 0  
 RET_VALUE = validate_args()  
 if RET_VALUE is not 0:  
 # open the AUT on the right port  
   subprocess.Popen([sys.argv[3], '--port={}'.format(sys.argv[1]), sys.argv[2]])  
   print("Starting application to test on port {0}", sys.argv[1])  
 except SystemError, exp:  
   print("Fatal error - {0}".format(exp.message))  
 print("finishing START_AU application")  

This allows the squish scripts to start the application in an attachable state and therefore streamline the process of testing since an application might take a long time to startup.

The only thing to be careful of it that you reset the application back to a known state after the test has finished. This can be done using the init and cleanup functions in the squish python script.

So now you can streamline your testing.

Wednesday, 6 January 2016

Restart Windows machine remotely.

Let's face it sometimes you have to restart a machine.

But it's a VM, or you remote into the machine so you don't have access to the machine itself.

You need a way to restart a machine remotely and easily without having to remote in each time you want to do it.

You need the shutdown command that's in the command prompt. It takes the following arguments.

-sShuts down the computer.
-rReboots the computer.
-fForce-close all running applications.
-m \\ComputerSpecifies a specific computer on the network that you want to shut down or reboot. Absent this parameter, the command affects only the local PC on which it is run.
-t xxSets a delay (xx seconds) before the specified operation commences.
-c "message"Add your own text inside the quotations to provide remote users with a message about why and when their PC will shut down or reboot.
/aAborts a shutdown or restart if used during the (-t) delay period.
/hHibernates the computer.
/?Displays the full help document with all commands.

Now imagine that you need to restart a bamboo agent cluster as you updated the server and it requires a restart of the agents.

No problem as you can whip up a bat file to go through the cluster restarting the agents. 

shutdown -f-r -m \\computer1
shutdown -f -r -m \\computer2

Now you have a simple script to restart a bank of computers without any trouble, no logging in or remotely accessing the machines.