sebb        2004/06/12 05:11:24

  Modified:    xdocs/usermanual Tag: rel-2_0 build-test-plan.xml
  Log:
  Change section 3.5 to subsection
  
  Revision  Changes    Path
  No                   revision
  No                   revision
  1.13.2.1  +5 -4      jakarta-jmeter/xdocs/usermanual/build-test-plan.xml
  
  Index: build-test-plan.xml
  ===================================================================
  RCS file: /home/cvs/jakarta-jmeter/xdocs/usermanual/build-test-plan.xml,v
  retrieving revision 1.13
  retrieving revision 1.13.2.1
  diff -u -r1.13 -r1.13.2.1
  --- build-test-plan.xml       14 Feb 2004 01:19:42 -0000      1.13
  +++ build-test-plan.xml       12 Jun 2004 12:11:24 -0000      1.13.2.1
  @@ -66,9 +66,8 @@
   is disabled, and "stop" is enabled, JMeter is running your test plan (or, at least, 
it
   thinks it is).</p>
   </subsection>
  -</section>
   
  -<section name="3.5 Scoping Rules" anchor="scoping_rules">
  +<subsection name="3.5 Scoping Rules" anchor="scoping_rules">
   <p>
   The JMeter test tree contains elements that are both hierarchical and ordered.  
Some elements in the test trees are strictly hierarchical (Listeners, Config Elements, 
Post-Procesors, Pre-Processors, Assertions, Timers), and some are primarily ordered 
(controllers, samplers).  When you create your test plan, you will create an ordered 
list of sample request (via Samplers) that represent a set of steps to be executed.  
These requests are often organized within controllers that are also ordered.  Given 
the following test tree:</p>
   <figure image="scoping1.png">Example test tree</figure>
  @@ -84,6 +83,8 @@
   <figure image="scoping3.png">complex example</figure>
   <p>In this example, the requests are named to reflect the order in which they will 
be executed.  Timer #1 will apply to Requests Two, Three, and Four (notice how order 
is irrelevant for hierarchical elements).  Assertion #1 will apply only to Request 
Three.  Timer #2 will affect all the requests.</p>
   <p>Hopefully these examples make it clear how configuration (hierarchical) elements 
are applied.  If you imagine each Request being passed up the tree branches, to its 
parent, then to its parent's parent, etc, and each time collecting all the 
configuration elements of that parent, then you will see how it works.  </p>
  +</subsection>
  +
   </section>
   
   </body>
  
  
  

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to