Installation, Configuration, Integration

This chapter describes installation procedures, configuration and deployment options, and options to integrate TestMaker into your software development lifecycle, production monitoring, and build environment. This chapter covers the following topics:

• Installation
• What Can Go Wrong During Installation and Solutions
  
• Running TestMaker
  
• Configuration, including HTTPS/SSL
  
• Integration
• After Installation
  

Installation

PushToTest TestMaker comes with everything necessary to build and run tests. Installer requires Java 1.6 or higher. The Installer installs the TestMaker console, a TestNode and PTTMonitor on your computer. This is everything you need to create a test, run the test, and analyze the results. Additional installations to consider:

• Download the TestNode installer to install a TestNode, test injector, on a server, virtual environment, or blade server.
• Download the PTTMonitor installer to install an agent-based monitor that observes CPU, network, and memory utilizations as TestMaker operates tests.

TestMaker Installer installs several subsystems:

• Console, desktop application to build and operate tests and analyze results. Includes Designer to create test scripts and Editor to orchestrate test scripts into functional tests, load tests, and production monitors.
  
• Apache Derby, relational database (RDBMS) to store results of every transaction, step, and monitored resource. Derby is satisfactory for evaluating TestMaker and it is not acceptable for production environments. TestMaker supports MySQL, Oracle, IBM DB2, and MS SQL Server.
• Sahi Proxy, Designer uses integrated Sahi network proxy recorded technology to record test objects. TestNode uses Sahi to play test commands through browsers, including IE, Chrome, Safari, Opera, and HtmlUnit.
  
• TestNode, distributed test runner environment. The Test Injector provides test ScriptRunners to operate the tests in their native format, including Selenium, soapUI, Sahi, and unit tests written in Java, Ruby, Groovy, .NET, C#, and command-line shell scripts. The Test Injector Data Production Library (DPL) injects operational test data from relational database, comma separated value (CSV,) and data generation objects into tests. TestNode integrates Selenium RC service to run tests in IE, Chrome, Firefox, Safari, Opera browers and the headless HtmlUnit browser.
• Glassbox, uses Aspect Oriented Programming (AOP) to observe thread deadlocks, memory leaks, slow database queries in Java Enterprise Applications.
  
• PushToTest Monitor (PTTMonitor) is an agent based system. It monitors CPU, Network, and Memory resource usage as TestMaker operates tests. It acts as a gateway to Glassbox data, DynaTrace data, and other monitoring platforms.
  

Headless Installation, Command-line Operation

The PushToTest installers (TestMaker, TestNode, PTTMonitor) include an option to run in a full headless mode, without needing a graphical user interface. This is useful in the case of remotely accessed servers through SSH or similar means. To launch an installer in console mode rather than in GUI mode (the default) specify one of the following parameters on the command line:

-console: to run the installation in interactive console mode
-options-template: to generate a properties file whose name is specified in args[1]
-options: to run an installation while reading the properties from the properties file specified in args[1]

As an example, to launch an interactive console installation use the following:

java -jar ./PushToTest_TestNode_Install_Linux.jar -console

Browser Locations and Options

TestMaker is compatible with Microsoft Internet Explorer (MS IE) 8 and later, Firefox 3.6 and later, Opera 10 and later, Chrome 8 and later, and Safari 5 and later. Other versions are possible, just not tested and certified by PushToTest.

TestMaker needs browser path and options set prior to recording or playing back of a test. TestMaker uses the Installer's default values the majority of the time. Browser configuration comes in two parts: path to the browser and profile options to use the browser and proxy.

Change these values after TestMaker installation using the Tools menu, Preference command, Browser tab.

Browser options determine the Browser profile, including SSL settings, security policy, and proxy support settings.

Windows NT and 2000

The TestMaker.bat start-up script is incompatible with Windows NT and 2000 because of a problem in the Windows command-line program ( cmd.exe ). 

When running TestMaker_home/TestMaker.bat from the desktop, a command-line window will flash and disappear on the screen. Open a command window ( Start >Run>cmd.exe ) to see the error message. For Windows NT and 2000, the error message was The input line is too long . Windows NT and 2000 have a maximum batch file line length of 2048 characters. 

Workaround this by using the Windows XP command-line program in Windows NT or 2000. Windows XP has a maximum batch file length of 8192. Copy the cmd.exe file from WinXP to c:\winnt\system32\ with the name cmd_XP.exe . Open a command window using cmd_XP.exe file ( Start>Run>cmd_XP.exe ) and run TestMaker.bat .

Windows Vista, Windows 7

The TestMaker Installer automatically sets the write privileges to the TestMaker directory on Windows XP, Windows Vista and 7, both 32-bit and 64-bit environments. Read the Special Instructions to learn how to set the write privileges manually: Special Instructions To Set File Privileges on Windows Vista and Windows 7

Please be sure to download and install TestMaker for Windows 64-bit systems for the 64-bit version of Windows Vista and Windows 7. See the PushToTest Web site for the TestMaker 64-bit Installer.

Installer saves TestMaker.cmd and TestMaker.exe to your installation directory to run TestMaker. TestMaker.exe requires special privilege settings on Windows 7 64-bit systems: Right-click TestMaker.exe, choose Properties, choose Compatibility tab, select "Run this problem in compatibility mode," click Ok.

Macintosh

TestMaker is fully compatible with Mac OS X 10.5.x and 10.6.x ("Snow Leopard") and later.

What Can Go Wrong During Installation and Solutions

TestMaker users encounter a variety of installation and configuration issues. Here are the most likely and how to solve them.

• Install Over An Existing Installation - A really bad idea. When using the TestMaker installer, always install to a new directory. The Installer depends on the operating environment file privileges to replace existing files. The Installer will not warn you when it fails to replace an existing file.
  
• Install On Windows Using The Wrong Installer - PushToTest provides separate TestMaker Installer programs for 64-bit and 32-bit versions of Windows. Using the 32 bit Installer on 64 bit environment causes the Shortcut Setup step of an installation to fail. The Installer displays an empty page and freezes. The only solution is to force the Installer to quit. Using the 64 bit Installer on 32 bit environments causes the Shortcut Setup step of an installation to fail. The Installer finishes but the Shortcut does not exist.
• Install Editor and Designer on Windows Server Environments - PushToTest certifies the test authoring components (Editor and Designer) to run on Windows XP, Vista, and 7, both 32-bit and 64-bit systems. These authoring components do not run on Windows server environments, including Windows 2003 Enterprise Server, Windows 2008 Enterprise Server. TestNode runs on Windows server environments.
• Install To A Windows Secure Directory - TestMaker Installer makes its best attempt to configure directory access privileges for TestMaker to store, update, and remove files in the TestMaker installation directory. TestMaker Installer operates the access_testmaker.cmd command shell script at the end of an installation. access_testmaker.cmd operates the icacls utility (Icacls "$INSTALL_PATH" /grant Users:W /T) to grant permission to TestMaker on Windows Vista and 7 environments. It uses cacls (cacls "$INSTALL_PATH" /g User:w /t) on Windows XP environments.
  
• Wrong path to a browser - TestMaker plays Designer Script, Sahi, and Selenium tests in a browser (IE, Firefox, Safari, Chrome, Opera and HtmlUnit.) TestMaker Installer asks you to identify the path to these browsers. It sets the path and profile information for each browser in XML-formatted files. At test runtime TestMaker uses these XML files to operate the browser.
  
  TestMaker provides a Browsers tab in the Tools menu, Preferences command to set and change the paths to the locally installed browsers.
  
  TestNode uses the windows.xml, mac.xml, linux.xml file in TestNode/bundles/sahi/20101123/ to store the path to the locally installed browsers. Use a text editor to modify the path in these files, depending on the operating environment.
  
• Invalid repository path or port number - When running the tutorial TestScenarios on a TestMaker installation, TestMaker assumes use of the Derby RDBMS running on the local machine. When you run a TestScenario on a remote machine using the TestNode software, change the logging location for the RDBMS in the Options tab of the Editor for the TestScenario. The typical URL looks like this jdbc:derby://host-name:1527/testmaker. Replace host-name with the IP address or host name of the machine running the RDBMS.

Running TestMaker

TestMaker comes fully configured to run without changes to the supplied configuration. When you start TestMaker, the local TestNode, PTTMonitor, and Sahi Proxy start automatically. Choose the Windows menu, Output command to view the output tabs and status for each service. Use the Tools menu, Preferences command to change the start-up settings for each service.

Once you start TestMaker, use the Help menu, Tutorials command to learn about building tests in a variety of application styles. Each tutorial includes step-by-step instruction to implement a test.

When you are ready to run tests in one or more TestNodes, install a TestNode on a separate machine. Download the TestNode installer from the downloads page at http://www.pushtotest.com/products-comparison. With the TestNode installed, start the TestMaker by running TestNode/startup.bat (for Windows) and startup.sh (for Linux and Mac.)

Install the PTTMonitor on servers you need to monitor while TestMaker operates a test. Download the PTTMonitor installer from the downloads page at http://www.pushtotest.com/products-comparison. Wtih PTTMonitor installed, start PTTMonitor by running the PTTMonitor/StartMonitor.cmd (for Windows) and StartMonitor.sh (for Linux and Mac.)

Configuration

PushToTest TestMaker, TestNode and Resource Monitor software is built in Java and HTML 5 technology. Java features its own memory manager, classpath loader and thread management. The PushToTest software package comes with program launcher shell scripts. Use these scripts to set options for memory settings, additional software packages and debugging options.

Changing Java Virtual Machines

TestMaker's installer sets the Java Runtime used to launch the installer to start TestMaker, TestNode, and PTTMonitor. Change the Java Runtime by editing the following files:

TestMaker_home/TestMaker.sh (or.bat)
TestMaker_home/TestNetwork/TestNode/startup.sh (or .bat)
TestMaker_home/PTTMonitor/startMonitor.sh (or .bat)

Changing TestMaker Memory Settings

Change memory settings for TestMaker by opening the TestMaker_home/TestMaker.bat for Windows and TestMaker_home/TestMaker.sh for Unix and Linux systems. The bottom of these files contains a call to the Java Virtual Machine. Add -Xms and -Xmx arguments to define the initial and maximum heap sizes.

Mac OS X users use a text editor to add the following to TestMaker.app/Contents/Info.plist:

VMOptions.x86_64
-Xms2g -Xmx8g

Changing TestNode Memory Settings

To set the memory for an installed TestNode, change the contents of TestMaker_home/TestNetwork/TestNode/startup.bat for Windows and TestMaker_home/TestNetwork/TestNode/startup.sh for Unix, Linux and Mac OS X systems. These files contain the following command line:

@"%Java_HOME%/bin/java" -Xmx128M -DSTOP.PORT=8079 -DSTOP.KEY=secret -jar start.jar @echo "TestNode? Started"

Adjust the memory settings using the -Xmx parameter.

Enabling Java Server Mode for Faster TestNode Performance

The Java Virtual Machine (JVM) running the TestNode uses just-in-time compilation and other techniques to deliver good performance of your tests. You have two choices of JVM: Java Runtime Environment (JRE) and Java Development Kit (JDK.)

To see which JVM you are running, open a command shell and run: java -version.

The JDK offers a special -server switch. This tells the JVM to use pre-compilation and other techniques to improve your test performance. The tradeoff of -server is the test will take longer to start and use more memory.

To enable Java Server Mode in the TestNode edit the TestMaker_home/TestMaker.bat for Windows and TestMaker_home/TestMaker.sh for Unix, Linux and Mac OS X systems. Add -server to the first line of these files.

Network Port Usage

TestMaker uses the following network-base communication:

Selenium RC service at port 4444. Change the port by using the Editor, Options tab

TestMaker communicates with the Editor over port 8099. Change the port in the Tools menu, Preferences command, Editor tab

Designer uses the Sahi Proxy at port 9999. Change the port number by editing sahi/config/sahi.properties

TestNode uses the Sahi Proxy at port 9999. Change the port number by editing TestNode/bundles/sahi/20101123/

TestMaker communicates with a TestNode over port 8080 by default. Change the port number by editing TestNode/etc/jetty.xml on line 49. Then change the port number in your TestScenarios using the TestNode tab

Proxy Server Configuration

If you normally need a proxy service to access Web sites, instruct TestMaker to use the proxy with the following instructions:

• For Designer, configure the external proxy by editing sahi/userdata/config/userdata.properties and setting these properties:
  
  ext.http.proxy.enable=true
  ext.http.proxy.host=external_proxy_server_hostname_or_ip
  ext.http.proxy.port=external_proxy_server_port
  
  If your proxy needs authorization, you should set these properties too:
  
  ext.http.proxy.auth.enable=true
  ext.http.proxy.auth.name=proxy_authorization_username ext.http.proxy.auth.password=proxy_authorization_password
  
  Make the same changes with ext.https settings for https sites.
  
  In addition, if you need to bypass the external proxy for some local sites you need to configure that too in sahi.properties like this
  
  ext.http.both.proxy.bypass_hosts=localhost|127.0.0.1|*.yourinternaldomain.com
  
  Note that there is only one bypass setting for both http and https.
  
  
• For TestNode, configure the external proxy by changing the settings in the Options tab when using the Editor to configure the TestScenario.
  
  

  

  
  

TestMaker_home/TestNetwork/TestNode/startup.sh (or .bat)
TestMaker_home/PTTMonitor/startMonitor.sh (or .bat)

Browser Configuration To Use Sahi Proxy in Designer and TestNode

Designer automates browser configuration to use the Sahi proxy. However, there are many browsers in the world and the automation may not work for your operating environment and browser. The following describes how to manually set your browser's proxy setting to use the Sahi proxy.

• Firefox
  
  Go to Tools > Options > General > Connection Settings >
  Set to “Manual Proxy Configuration”
  Set “HTTP Proxy” to “localhost”
  Set “Port” to “9999”. (This setting can be modified through /config/sahi.properties)
  Do the same for “SSL Proxy” too, if you wish to record and playback https sites
  Keep “Use the same proxy for all protocol” unchecked as the Sahi Proxy does not understand protocols other than HTTP
  NOTE: “No Proxy for” should NOT have localhost in it.
  
  TestMaker and the Sahi Proxy are compatible with Firebug. Bring up Firefox in the Designer using the Record button, then install Firebug. The Sahi Proxy reuses the Firefox profile during playback, including Firebug.
  
  
• Internet Explorer
  
  Go to Tools > Internet Options > Connections > LAN Settings >
  In “Proxy server” section, Check “Use a proxy server for your LAN”
  Click on “Advanced”
  For HTTP: set “Proxy address to use” to “localhost” and set “Port” to “9999”
  For Secure: set “Proxy address to use” to “localhost” and set “Port” to “9999” (if you want to test https sites too)
  Clear out anything in “Do not use proxy server for addresses beginning with:”
  OK
  Leave “Bypass proxy server for local addresses” unchecked
  OK > OK

Additional Sahi specific security settings are available here.

Debugging Sahi Proxy Configuration for Designer Script Tests

TestMaker Installer puts a the TestMaker Console, a TestNode, and a PTTMonitor onto the local machine. Installer does this to enable users to build, debug, and operate tests. PushToTest provides a separate TestNode and PTTMonitor installer to configure servers in a QA lab or in a Cloud environment to operate tests remotely and to scale the test horizontally.

• Running A Designer Script Test in a local TestNode

• The TestNode starts the Sahi Proxy using a shell script located at TestNode/bundles/sahi/20101123/windows.xml (or mac.xml, linux.xml)
• When the test object uses the SahiHtmlunit browser then the TestNode starts the Htmlunit browser using a shell script located attm6/TestNode/bundles/sahi/20101123/SahiHtmlunit/bin/htmlunit.bat (or htmlunit.sh)
  

• Running A Designer Script from the Designer

• TestMaker Console starts the Sahi Proxy. See the Tools menu, Preferences command, Proxy tab to control the location and start-up configuration for the Sahi Proxy.
• Designer uses browser settings set in the Designer Options menu, Preferences command. Designer saves these settings to Editor/Resources/TOD/TestMaker.properties (on Windows) and Editor/Editor.app/Contents/Resources/TOD/TestMaker.properties (on Macintosh.)
  

• Running A Designer Script in a local TestNode using the SahiHtmlUnit browser
  

• The TestNode runs the HtmlUnit browser using a shell script located at TestNode/bundles/sahi/20101123/SahiHTMLUnit/bin/htmlunit.bat (or htmlunit.sh for Mac and Linux)
  

PushToTest intends to consolidate these settings into one location in TestMaker 6.1.

There are the various reasons why Designer may not work with HTTPS/SSL Web sites:

• Java keytool is not in TestMaker's path and that is why certs are not created. Verify the keytool by executing command %JAVA_HOME%\bin\keytool in a command shell
• Sahi/userdata/certs folder priviledges are set to read-only. Change the priviledges to read-write.
  
• TestMaker is installed in a path with spaces and the certificate creation command is not working properly. This is very rare. When it happens this is a bug in TestMaker and should be reported.
• Website is not recognized by the Java version being used. Possible solution is to update your Java to a more recent version.
  
  

Registering SSL Certificates

TestMaker supports HTTPS and Secure Socket Layer (SSL) security protocols. These protocols use the Java Cryptography Architecture to work with SSL certificates. Most secure Web sites require the Sahi proxy and browser to register the server-side certificate before running a test.

A special Video TechNote on registering SSL Certificates is found here.

• Registering SSL Certificates Using Sahi Certificate Manager

• Start a new recording in Designer.
  
• Navigate to the HTTPS site. You will get a page which warns you that the connection is untrusted or incorrect. In Firefox, click on “Add Exception” and then “Confirm Security Exception”. The web site will then be displayed.
• At this point, the website which has been displayed may not work properly if it fetches css and Javascript files from another https domain or sub-domain.
  
• Next you must register the SSL certificate with the Sahi Proxy. Open another tab in the browser, and navigate to http://localhost:9999/_s_/dyn/SSLManager. Note: You must do this step with the browser connecting through the Sahi Proxy.
  
  
  
  The Sahi Proxy displays the SSL Certificate Manager. You will now see a list of domains with Sahi created certificates. Ones marked Install need to be accepted. Click these to get the same certificate dialog which you would need to accept in a browser.
  
  
  
  Check marks indicate registered SSL certificates.
  
  
  
  
• Repeat this process to accept the SSL certificate for sahi.example.com. This is normally the first site listed. You will need to accept this SSL certificate only once. If you do not accept the sahi.example.com certification Designer will record the navigateto command and not record the subsequent click and type commands.
• Once you accept this SSL certificate you must End Recording and then start a new recording
• The Sahi proxy stores SSL certificates in Sahi/userdata/certs. Remove SSL certificates by deleting files from this directly. Check that TestMaker has read and write priviledges to this directory.
• Watch a video of accepting SSL certificates on Internet Explorer
  
• For auto acceptance of certificates, have a look at this forum post
  
  

• Registering SSL Certificates Using Java Keystore
  
• TestMaker supports HTTPS and Secure Socket Layer (SSL) protocols. These protocols use the Java Cryptography Architecture to work with SSL certificates. The TestMaker protocol handler will throw an SSLHandshakeException when connecting to a server over SSL protocols when the server-side SSL certificate is unknown and generates the message:
  
  javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
  
  Follow these steps to register the SSL certificate:
  
  1. Download the server-side SSL certificate to the local machine. Many browsers save the certificate. For instance, clicking the SSL icon in Microsoft Internet Explorer will display the certificate. In Mac OS X Safari, click the SSL (lock) icon and drag the certificate icon to a directory.
  
  2. Within the Java Development Kit (JDK) installed, use the Java Keytool to import the SSL certificate into the Keystore. Use the following command from the command shell or terminal window:
      * keytool -keystore "TestMaker_home/pushtotest.keystore" -import -alias mycertificate -file "mydirectory/sslcertificate.cer"
  
  3. Tell TestMaker to use Keystore by modifying the TestMaker_home/TestMaker.sh (for Unix, Linux, and Mac OS X users) and TestMaker_home/TestMaker.bat (for Windows users). Add the following to the last line of the start-up script:
      * java $maxqarg $lookarg $python $testnetwork -Djavax.net.ssl.trustStore=TestMaker_home/pushtotest.keystore -Dfrank=cohen -classpath $TMCP com.pushtotest.testmaker.Main "$@"
      * The -Djavax.net.ssl.trustStore added to the start-up script.
  
  4. Tell the TestNode on the local TestMaker instance to use Keystore. Modify the TestMaker_home/TestNetwork/TestNode/startup.sh (for Unix, Linux, and Mac OS X users) and TestMaker_home/TestNetwork/TestNode/startup.bat (for Windows users) as follows:
      * $Java_HOME/bin/java -DSTOP.PORT=8079 -DSTOP.KEY=secret
        -Djavax.net.ssl.trustStore=TestMaker_home/pushtotest.keystore -jar start.jar
  
  5. Tell the installed TestNodes to use Keystore. Modify the TestNode_home/startup.sh (for Unix, Linux, and Mac OS X users) and TestNode_home/startup.bat (for Windows users) as follows:
      * $Java_HOME/bin/java-DSTOP.PORT=8079-DSTOP.KEY=secret
        -Djavax.net.ssl.trustStore=TestMaker_home/pushtotest.keystore -jar start.jar
  

• Registering SSL Certificates with Sahi Proxy Manually
  
  Sahi stores SSL certificates in sahi/userdata/certs. In this directory the file name is the domain name for the certificate. Manually copy certificates into this directory. Then accept the certificate in the browser.

Additional Sahi specific security settings are available here.

NTLM Authentication

TestMaker supports NTLM authentication. Designer Script files run with the Sahi command language automatically handles NTLM. In case there is a NTLM challenge prompted by the website, Sahi converts it into a simple web page with a username password field.

For integrated Windows authentication, Sahi logs-in using the Windows user's credentials. There is however a bug in Java which causes the first logged in user's credentials to be cached, which means he cannot logout of it currently. This is only if the application uses integrated Windows authentication.

Flex, Flash, SWF Configuration

TestMaker supports record/playback of Flex, Flash, and SWF configuration. Your machine must have the Flex plug-in installed prior to using Designer.

Adobe implements security policies to control Flex and SWF component operations. Use the Flash Global Security Settings panel to allow TestMaker to display and record Flex and Flash components. Read instructions on accessing the settings panel at:

http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager04.html

Repository (RDBMS) Configuration

TestMaker stores test results data in a repository. TestMaker ships with the Apache Derby database to make it easy to evaluate TestMaker. Derby is satisfactory for evaluating TestMaker and it is not acceptable for production environments. TestMaker supports MySQL, Oracle, IBM DB2, and MS SQL Server.

Change the repository using the Tools menu, Preferences command, Repository tab. TestMaker creates a database schema (tables and indexes) automatically for Derby and MySQL. Use the Create Database button to create the tables and indexes for the TestMaker repository schema for Oracle, DB2, and SQL Server.

Integration Options

PushToTest was designed to integrate into software development environments.

Run From The Command Line

Operate a PushToTest TestScenario from the command line using the TestMaker_home/TestMaker.bat (for Windows and TestMaker_home/TestMaker.sh for Linux, Unix) start-up script. In this example, TestMaker is installed in:
C:\Program Files\PushToTest_TestMaker_ent_0518

Use the following in a Windows shell script:

cd "C:\Program Files\PushToTest_TestMaker_ent_0518" "C:\Program Files\PushToTest_TestMaker_ent_0518\TestMaker.cmd" -t "C:\Program Files\PushToTest_TestMaker_ent_0518\tutorials\Web_Test_Tutorial\Ajax_Functional_Test.scenario" -log-junit junitreport.xml

The above example runs myTest.scenario from the command line. PushToTest sends operational messages to the command line shell as it operates the TestScenario. Results and standard output is also sent to the Results directory for this TestScenario. Finally, TestMaker creates a JUnit-style output report.

PushToTest normally starts a local TestNode and a local PTTMonitor (to observe CPU, network and memory utilitization) when the PushToTest application is started. When running TestMaker from the command-line, start the TestNode and optionally the PTTMonitor, from the command-line also.

TestNode/startup.bat

(The above is for Windows, use .sh for Unix/Linux/Mac OS X systems)

Start the local Resource Monitor - PTTMonitor using:

PTTMonitor/startMonitor.cmd

 Continuous Integration Environments (Hudson, Cruise Control, Bamboo)

Operate PushToTest TestMaker tests from Continuous Integration environments. Read the Continuous Integration Guide for detailed instructions.

 Parameterized Input Values to a TestScenario

Run a TestMaker test from the command-line. The command-line may optionally include parameters that will replace values in the TestScenario. Use the -p command-line switch to pass-in a value. Identify the parameter in the TestScenario using the ${..} notation.

For example, the following TestScenario includes a parameter for the sequence proportion value:

...
  
...

Call this test using the following command-line instruction:

TestMaker.cmd -t some_test.scenario -p myproportion=100

When TestMaker operates the test it will use the following sequence proportion value:

   

TestMaker reads properties from a properties file using the -pfile command-line instruction:

TestMaker.cmd -t some_test.scenario -pfile myfile.properties

The properties file contains a list of name/value pair fields.

Ant Integration

Operate PushToTest from within Ant build scripts. The following is an Ant example for Windows environments:

    
   
   
   
     
         
     
   

PushToTest requires many supporting class libraries. See the TestMaker_home/TestMaker.bat (or TestMaker.sh for Linux, Unix, Mac OS X systems) for a list of required libraries.

jUnit Integration

PushToTest can be invoked from JUnit-tests. Consider the following example:

public void testRunner() throws Exception
{
    com.pushtotest.testmaker.Main pushtotest =
         new com.pushtotest.testmaker.Main("-t","c:\mytests\myTestScenario.xml");
}

PushToTest requires many supporting class libraries. See the TestMaker_home/TestMaker.bat (or TestMaker.sh for Linux, Unix, Mac OS X systems) for a list of required libraries.

Exit Report

TestMaker ends a command-line TestScenario operation by returning a JUnit-style exit report. Use the -log-junit command line option for TestMaker to return a jUnit-style XML formatted report to indicate test operation details. Click here for an example.

Maven Integration

PushToTest is compatible with Maven by running PushToTest as an Ant task.

Special Considerations

TestMaker support of Selenium and Sahi requires special considerations.

Same Origin Security

Selenium follows the browser Same Origin Policy. This security restriction is applied by every browser to ensure that site content will never be accessible by a script from another site. Code loaded within the browser can only operate within that website’s domain. For example, JavaScript code loaded from www.mysite.com does not run against www.mysite2.com. Same Origin Policy prevents Cross-site Scripting (XSS.) Without Same Origin Policy a script placed on any website would be able to read information from a second site opened in another browser window.

Selenium supports Same Origin Policy by requiring scripts to be placed in the same origin as the Application Under Test, using the same URL. TestMaker does not have this limitation when running a Selenium script in a TestNode using the Selenium RC service. Selenium spoofs the browser to believe it is working on a single Website that the Server provides.

Additional Selenium help is available here.

Sahi Proxy Architecture

Sahi tests web applications by simulating user events (clicking buttons, entering text) on the browser. There are multiple ways of doing this, but one of the simplest ways is to use Javascript to simulate events. Javascript is especially suited for this purpose because it is supported by all major browsers and allows excellent access to various elements in the browser.

TestMaker integrates the Sahi Proxy Server into the TestNode. To execute our simulation Javascript code on our website, we first need to get into the browser’s process. We can do this in multiple ways again. One would be to write extensions of all known browsers and keep updating them with each browser release. Another would be to be independent of the browser and inject the needed Javascript into the application through some other means.

With Sahi the browser sends an HTTP requests to the Web Server and the Web Server responds with a HTTP response which the browser understands and displays on its user interface. A proxy server is something that sits between the browser and the Web Server, such that now the communication proceeds like this: The browser sends the request to the proxy server, the proxy server forwards the request to the Web Server, the Web Server sends its response to the proxy server, which the proxy server forwards to the browser. The good thing is, the proxy server can now inject what ever code it wants and it will be available on the browser.

Sahi uses this approach. When the browser uses Sahi as its proxy server, Sahi injects its Javascript code into the web page, which when displayed on the browser, helps us record and playback events on the browser.

The role of the proxy server is not just limited to injection of Javascript code. It does the following too:

• Understand recording sessions: The Javascript injected into the browser, communicates with the proxy to save needed events into a script file.
• Understand playback sessions: The proxy executes the Sahi scripts in a rhino Javascript engine and sends messages to the browser which the browser understands and executes.
• Understand execution of suites and batch execution of scripts.
• Create playback reports.
• Do other server side operations like database access, file access etc.
• Understand custom rules to block unwanted urls.
• Handle events that are not possible via client side Javascript on the browser, like file uploads and file downloads
  
  

Where Do I Go After Installation?

After installation, consider the following instructions for each type of application under test.

Web Application Test

Web applications provide users with functions accessible through a Web browser. PushToTest TestMaker features Record and Playback technology for Web applications. PustToTest TestMaker watches the use of a browser and writes a test agent script, which is a functional test (also referred to as a unit test). Learn more about PushToTest TestMaker in a Web application test environment by reviewing the Web Testing Tutorial.

Service Oriented Architecture (SOA) and Web Service Tests

Service Oriented Architecture and Web services provide server-to-server and application-to-application communication. PushToTest TestMaker features Eviware soapUI for fast and easy test suite authoring. soapUI imports WSDL and REST definitions of a service. The Web Service perceives the test as a server or application making requests and expecting responses. PushToTest TestMaker includes SOAP, REST, and XML-RPC protocol handlers. These handlers support soap document-style (message) encoding, soap RPC-encoding, HTTP authentication, soap over HTTPS communication and cookies. PushToTest TestMaker provides XML parsing and query capabilities through the included JDOM, XPATH, Xerces and JAXB libraries. Learn more about TestMaker in SOA and Web service environments by reading the SOAP Testing Tutorial and using the soapUI tool. Also, start soapUI using the Tools drop-down menu and Start soapUI menu.

Tests Written In Java

Write test script in Java. Learn more about PushToTest TestMaker operating tests written in Java by reading the MailerCheck tutorial.

Flex/Flash Application Tests

Adobe Flex and Flash provide a single and integrated means to build Rich Internet Applications. Flex even provides an efficient binary message format between a Flex component running in the browser and the server-side application. Learn more about PushToTest TestMaker operating tests written in Java by reading the AMF Tutorial

Additional documentation, product downloads and updates are at www.PushToTest.com. While the PushToTest testMaker software is distributed under an open-source license, the documenation remains (c) 2011 PushToTest. All rights reserved. PushToTest is a trademark of the PushToTest company.