concepts.script

Software Testing Automation Framework (STAF)的开发代码

.***************************************************************************
.* Software Testing Automation Framework (STAF)
.* (C) Copyright IBM Corp. 2001
.*
.* This software is licensed under the Common Public License (CPL) V1.0. 
.****************************************************************************

.*************************-START-OF-PROLOG-****************************
.*
.*  File Name          : Overview SCRIPT
.*  Descriptive Name   : Software Test Automation Framework Overview
.*  Detail:
.*
.*     This file contains an overview of STAF.
.*
.**************************-END-OF-PROLOG-*****************************
:ih1.handles
:i2.concepts
:h1 id=concepts.Concepts
:h2 id=hndlcon.Handles
:p.A handle is a unique identifier, representing a given process.  This
handle is used when submitting requests to STAF.  This handle, combined with
the machine name, uniquely identifies a particular process in the STAF
Environment.  It is this combination of machine/handle that allows
services to track requests from multiple processes on different machines.
:p.In order to submit service requests to STAF, a process must have a handle.
Thus, the first thing a process should do is register with STAF to obtain a
handle.  Other data tied to this handle is the following:
:ul compact.
:li.Name - a descriptive name associated with the handle, which is specified
when a process registers with STAF.
:li.Last used date/time - a timestamp of the last time the handle was used to
submit a request.
:li.User authentication information - user authentication information
associated with the handle if the handle has been authenticated
:li.Variable pool - a means by which to store and retrieve information that the
process may use, such as configuration data.
:li.Queue - a priority queue used for interprocess communication between other
processes/machines using STAF.
:eul.
:p.Before a process exits it should unregister with STAF to free up any
resources used by that handle.
:note.Handle 1 is always allocated to the STAF Process itself.  The name
associated with this handle is STAF_Process.
:p.
If STAFProc is shutdown on a machine (or the machine is rebooted), STAF handles
for that machine are deleted.
:p.  
The SEM and RESPOOL services perform garbage collection for handles that have
been deleted.  If a handle is deleted and it owns a mutex semaphore or a 
resource pool entry (or has a pending request for a resource pool entry),
the handle will be garbage collected.  This means any mutex semaphores or
resource pool entries owned by the handle will be released and any pending
requests submitted by the handle will be removed. 

.*
.*---------------------------------------------------------------------
.*
:ih1.services
:ih2.general
:i3.concepts
:h2 id=srvcon.Services
:p.Services are what provide all the capability in STAF.  Services may be
internal services, in which case, the executable code for the service resides
within STAFProc.  Services may also be external services, in which case, the
executable code for the service resides outside of STAFProc, for example, in
a Java routine.
:p.Services are known by their name, such as PROCESS or LOG.  Internal
services are always available and have a fixed name.  External services must
be registered, and the name by which they are known is specified when they are
registered.  If an external service is not registered with STAF, then the
service is not available on that STAF Client.
:p.Services may also be delegated to another STAF Client.  In this case, when
a request is made for the service on the local STAF Client, it is automatically
forwarded to the machine to which this service has been delegated.  For example,
a testcase may request the local machine to log some information via the LOG
service.  If the LOG service has been delegated to another machine, the
LOG request will actually be handled by the machine to which logging has
been delegated.  In this way, all logs could be conviently stored on one
system, without the testcases needing to explicitly send their LOG requests
to the common system.  In a similar manner, if a service were only available
on a specific operating system, then all testcases could assume that the
service was available locally, when, in fact, the service was being delegated
to the machine running the required operating system.
:note.Internal services may not be delegated.
:p.External services and delegated services are both registered in the STAF
Configuration File.  External services also may be dynamically added (registered)
or removed (unregistered and terminated) 
.*replaced, or renamed
via the SERVICE service (see :hdref refid=srvService.).
:ih2.service loader
:p.Service loaders are external services whose purpose is to load services on-demand.
They allow services to be loaded only when they have been requested,
so they don't take up memory until needed.
They also allow dynamic service registration when a request is made so that
you don't have to change the STAF configuration file to register a
service.
:p.When a request is encountered for a service that doesn't exist,
STAF will call each service loader, in the order they were
configured, until the service exists or we run out of service loaders.
If we run out of service loaders, then the standard
RC:2 will be returned.  Otherwise, the request will be sent to the
newly added service.  
:p.A default serviceloader service (STAFDSLS) is shipped with STAF, and
it can dynamically load the Log, Zip, Monitor, and ResPool services.  This service
will automatically be configured in your STAF.cfg file.
:ih2.authenticator
:p.Authenticators are special external services whose purpose is to
authenticate users in order to provide user level trust, which can be used
in addition (or instead of) machine level trust.  An Authenticator is a
special service that accepts an authenticate request.  As a user, you
cannot directly submit a request to an authenticator service.
Authenticators are accessed indirectly via the Handle service.
:p.Authenticators can only be registered in the STAF configuration file --
they cannot be dynamically registered.  One or more Authenticators can be
registered.  The first Authenticator registered is the default, unless
overridden by using the DEFAULTAUTHENTICATOR operational parameter.
If you want to authenticate across systems, you must register the
Authenticator on each system using the same name (case-insensitive).
.*
.*---------------------------------------------------------------------
.*
:ih1.workload
:i2.concepts
:h2 id=wkldcon.Workloads
:p.A workload is a set of processes running on a set of machines.  A workload
may be as simple as a single process running on a single machine, or it may be
as complex as multiple processes on multiple machines coordinating together to
perform a larger complex task.  STAF was designed to help the creation and
automation of workloads of all sizes.
.*
.*---------------------------------------------------------------------
.*
:ih1.variables
:i2.concepts
:h2 id=varcon.Variables
:p.STAF provides a means to store and retrieve variables.  These variables
may be used for any purpose the tester desires, such as storing testcase
configuration parameters.  These variables provide two main capabilities
to testcase writers.  One, they provide a standard means by which to store
configuration data, i.e., each tester doesn't have to figure out how to store
and retrieve said configuration data.  Two, these variables may be changed
dynamically.  For example, if a testcase queries the WebServer variable
before sending a request off to the web server, and that web server goes down,
the WebServer variable can be dynamically changed by the tester to refer to a
different web server, and the testcase can continue execution.  Note how STAF
allows the variable's value to be changed outside of the scope of the running
testcase, thus allowing the testcase to continue execution without needing to
be stopped and restarted.
:p.STAF maintains a "system" variable pool that is common to all
the processes on a given STAF Client.
STAF also maintains a "shared" variable pool which is also system-wide,
but which will be sent across the network and used in variable resolution
on remote systems.
In addition, each process/handle has its own variable pool.
By default, the values of variables in a process' variable pool override the
values of variables in the system and shared variable pools.  However, the
process may override this behavior when asking for the value of a variable.
Basically, as part of every remote request, the originating handle and system 
shared variable pools are sent across the wire. These pools are stored only for 
the duration of the request for use in variable resolution.
:i2.predefined
:p.The following system variables are predefined:
:ul compact.
:li.STAF/Config/BootDrive - Indicates the drive from which the machine was
booted
:li.STAF/Config/CodePage - The codepage used by STAF
:li.STAF/Config/ConfigFile - The configuration file used to start STAF
:li.STAF/Config/DefaultAuthenticator - The default authenticator.  If no
authenticators are registered, it's value is "none".
:li.STAF/Config/DefaultInterface - The default interface.  If no
network interfaces are registered, it's value is "local" to show that
the local interface is the only interface available.
:li.STAF/Config/InstanceName - The name of this STAF instance.  The default