What can be tested? With Silk Performer you can thoroughly test various remote component models, including: Web Services Enterprise JavaBeans (EJB) Java RMI Objects General GUI-less Java components License requirements for replaying Java Frameworks script In order to replay a Java Frameworks script you must be licensed for either Standard or Premium virtual users. Access to developers Out of the box record/replay in almost all instances will not be successful as customization of the script is required and this involves implementing Java code. Access to developers should therefore be considered a pre-requisite as they have the knowledge on: the applications class/jar files required the methods to be called that simulate the client the parameters to the methods and how to customize their values exceptions that may be thrown by the application on replay and how to resolve. Script Generation Silk Performer offers the following approaches to creating test clients for remote components: Visually, without programming (via Java Explorer) Using an IDE (Eclipse SDK plug-in) Writing Java code using Silk Performer Workbench Recording an existing client (see next section) Importing JUnit or NUnit testing frameworks Importing Java classes Recording support Java applications can communicate via a wide range of protocols so it is important to identify the protocol utilized by the Java application you wish to test and make the appropriate protocol selection when creating the application profile. Silk Performer has Java level recording support for Java RMI and EJB applications. Silk Performer generates Java source code files with the recorded actions and BDL stub scripts that invoke recorded scripts via Silk Performer's Java Framework. Recording support includes: RMI client applications using the RMI registry or JNDI for bootstrapping of remote references JNDI support, including the JNDI service provider implementations of JBoss, WebLogic, and WebSphere EJB client applications for JBoss, WebLogic, and WebSphere application servers Any attempt to record a non RMI / EJB application at Java level will yield 0 functions. There are applications / APIs built on RMI that are unsuitable for recording at the RMI level. In these instances RMI is a basic transport layer with several layers of abstraction built on top and include some standard Java APIs like JMS. It may be possible to develop a Java Frameworks script for testing at a higher level of abstraction for such applications. The following resolution details how to configure an application profile to record a Java application. How do I set up an application profile to record my Java application? It may be possible to implement recording support for applications not supported out of the box via custom Java Hook configuration files. These Java Hook configuration files are XML files located in the "ClassFiles" directory in the SilkPerformer installation folder and are used by the SilkPerformer Java Recorder to determine what classes to record for specific applications. This means for example that it may be possible to implement recording support for non RMI/EJB applications. For more information see What are Java Hook Configuration Files? Supported JDK's SilkPerformer 2007, the latest version at the time of writing supports: Sun Microsystems Java Development Kit 1.1.6 Sun Microsystems Java Development Kit 1.1.7 Sun Microsystems Java Development Kit 1.1.8 Sun Microsystems JDK 1.2.2: classic and hotspot 1.0 Sun Microsystems Java Runtime Environment 1.2.2: classic and hotspot 1.0 Sun Microsystems Java Development Kit 1.3 Sun Microsystems Java Development Kit 1.4 Sun Microsystems Java Development Kit 1.5 Sun Microsystems Java Development Kit 1.6 IBM Java Development Kit 1.1.8 It is not possible to hook IBM"s JVM automatically therefore some manual intervention is required. You will need to edit the .BAT or .CMD file which launches the application as described in How can I hook the IBM JVM? Please note that if you decide that it is not possible to test the Java application at the Java level or a protocol level then there are alternative approaches. These alternative approaches are described in How can I loadtest an application if I am unable to record at the protocol level?
↧