Framework:

      A set of procedures to execute the test script is
called framework.

      There r so many frameworks will be available. As per
my knowledge 4 frameworks

      1. Modularity framework
      2. Test driver framework
      3. 3-level framework
      4. data driven framework
Batch is nothing but excution of one or more tests at a time

hi pratichi,

can u bried more about the frameworks u hv listed..plz it 
could be of grt help for job seekers.

thanks in advance


regds,
swati
swty79@rediffmail.com

1>The test script modularity framework requires the creation
of small, independent scripts that represent modules,
sections, and functions of the application-under-test. These
small scripts are then used in a hierarchical fashion to
construct larger tests, realizing a particular test case.

Of all the frameworks I'll review, this one should be the
simplest to grasp and master. It's a well-known programming
strategy to build an abstraction layer in front of a
component to hide the component from the rest of the
application. This insulates the application from
modifications in the component and provides modularity in
the application design. The test script modularity framework
applies this principle of abstraction or encapsulation in
order to improve the maintainability and scalability of
automated test suites.

2> Test Driver frameworks "drive" the replay of scripts. For
example, the SAFS framework uses keywords in plain text
files rather than a matrix of function calls.

This makes it faster and easier to use test tools because they:

   1. Provide common functions for error detection, logging,
etc. not provided by test tools. Because the framework's
functions automatically performs validations on every object
within every action without additional coding, many hours of
script coding and debugging is avoided. For example, the
WRSAFS framework includes the CSO libraries of functions for
WinRunner users

   2. Provide complete examples. For example, WRSAFS
installation enables a complete test of the "flight"
application that is WinRunner's sample application.

   3. Define de-facto naming conventions for common
environment variables, functions, messages, and other
terminology.

   4. Make test specs independent of the test tool. Another
tool can potentially be substituted for WinRunner because
rather than making calls to the unique syntax of each tool's
API, the framework processes generic keywords in plain text
files. Otherwise, test scripts crafted for one test tool are
usually useless for use in competitive tools.

   5. Allow testing work to begin sooner. Unlike
capture/playback, which requires the application to be
operational, the framework's three-layer test specification
hides low-level details. During application design, when use
cases are known, Test Analysts can define "what" to test
(the "high-level" test cycles) without knowing the scripting
language. When specific application variable names are
known, analysts can define test suites with specific values.
"How" the application's gui map and scripts implement the
action keywords is done as the application matures.

   6. Enables testing work to progress in a structured,
top-down, distributed approach by several specialists
working separately.

      Unlike tracing function calls within many pages of
test script code, keyword test specs don't have extraneous
programming characters, so they are easier to follow what is
being tested. This makes it easier to have separate
(several) script programmers working on different parts of
the app, making the test project easier to scale larger.

      This makes for a much more manageable process to plan
and track.

   7. Use of public domain frameworks distributes the work.
For example, here are the recent changes to the framework
source:
          * ANSI wide character support