jmeter-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From fschumac...@apache.org
Subject svn commit: r1722623 - in /jmeter/trunk/xdocs/usermanual: best-practices.xml test_plan.xml
Date Sat, 02 Jan 2016 13:08:17 GMT
Author: fschumacher
Date: Sat Jan  2 13:08:17 2016
New Revision: 1722623

URL: http://svn.apache.org/viewvc?rev=1722623&view=rev
Log:
Markup changes. Mostly addition of code and note tags.

Modified:
    jmeter/trunk/xdocs/usermanual/best-practices.xml
    jmeter/trunk/xdocs/usermanual/test_plan.xml

Modified: jmeter/trunk/xdocs/usermanual/best-practices.xml
URL: http://svn.apache.org/viewvc/jmeter/trunk/xdocs/usermanual/best-practices.xml?rev=1722623&r1=1722622&r2=1722623&view=diff
==============================================================================
--- jmeter/trunk/xdocs/usermanual/best-practices.xml (original)
+++ jmeter/trunk/xdocs/usermanual/best-practices.xml Sat Jan  2 13:08:17 2016
@@ -204,7 +204,7 @@ Session started on port: 9001
 There is a sample script (<code>extras/remote.bsh</code>) you can use to test
the server.
 [Have a look at it to see how it works.]
 <br/>
-When starting it in the JMeter bin directory
+When starting it in the JMeter <code>bin</code> directory
 (adjust paths as necessary if running from elsewhere)
 the output should look like:
 <source>
@@ -265,8 +265,8 @@ java -jar ../lib/bshclient.jar localhost
 <p>
 Each BeanShell test element has its own copy of the interpreter (for each thread).
 If the test element is repeatedly called, e.g. within a loop, then the interpreter is retained
-between invocations unless the "Reset bsh.Interpreter before each call" option is selected.
-For intensive load testing, it is recommended to use a JSR223 scripting language whose ScriptingEngine
implements Compilable,
+between invocations unless the "<code>Reset bsh.Interpreter before each call</code>"
option is selected.
+For intensive load testing, it is recommended to use a JSR223 scripting language whose ScriptingEngine
implements <code>Compilable</code>,
 see JSR223 section below for more details.
 </p>
 <p>
@@ -370,11 +370,11 @@ The appropriate property file can be pas
 
 <section name="&sect-num;.12 JSR223 Elements" anchor="jsr223">
 <p>
-For intensive load testing, the recommended scripting language is one whose ScriptingEngine
implements the Compilable interface.
-Groovy scripting engine implements Compilable. However neither Beanshell nor Javascript do
so as of release date of JMeter 2.13, so it is
+For intensive load testing, the recommended scripting language is one whose ScriptingEngine
implements the <code>Compilable</code> interface.
+Groovy scripting engine implements <code>Compilable</code>. However neither Beanshell
nor Javascript do so as of release date of JMeter 2.13, so it is
 recommended to avoid them for intensive load testing.
-[Note: Beanshell implements the Compilable interface but it has not been coded - the method
just throws an Exception.
-JMeter has an explicit work-round for this bug.]
+<note>Note: Beanshell implements the <code>Compilable</code> interface
but it has not been coded - the method just throws an Exception.
+JMeter has an explicit work-round for this bug.</note>
 
 When using JSR 223 elements, always set caching key to a unique value to ensure the script
compilation is cached if underlying language supports it.
 Ensure the script does not use any variable using <code>${varName}</code> as
caching would take only first value of <code>${varName}</code>. Instead use :
@@ -407,7 +407,7 @@ If the value is not known until the test
 <b>instead copy the property from <code>jmeter.properties</code> and modify
its value in <code>user.properties</code> file</b>.<br/>
 Doing so will ease you migration to the next version of JMeter. <br/>
 Note that in the documentation <code>jmeter.properties</code> is frequently mentioned
but this should be understood as
-"Copy from jmeter.properties to user.properties the property you want to modify and do so
in the latter file".</p>
+"Copy from <code>jmeter.properties</code> to <code>user.properties</code>
the property you want to modify and do so in the latter file".</p>
 <note><code>user.properties</code> file supersedes the properties defined
in <code>jmeter.properties</code></note>
 </section>
 

Modified: jmeter/trunk/xdocs/usermanual/test_plan.xml
URL: http://svn.apache.org/viewvc/jmeter/trunk/xdocs/usermanual/test_plan.xml?rev=1722623&r1=1722622&r2=1722623&view=diff
==============================================================================
--- jmeter/trunk/xdocs/usermanual/test_plan.xml (original)
+++ jmeter/trunk/xdocs/usermanual/test_plan.xml Sat Jan  2 13:08:17 2016
@@ -31,7 +31,7 @@
 
 <section name="&sect-num;. Elements of a Test Plan">
 
-<p>The Test Plan object has a checkbox called "Functional Testing".  If selected, it
+<p>The Test Plan object has a checkbox called "<code>Functional Testing</code>".
 If selected, it
 will cause JMeter to record the data returned from the server for each sample.  If you have

 selected a file in your test listeners, this data will be written to file.  This can be useful
if
 you are doing a small run to ensure that JMeter is configured correctly, and that your server
@@ -39,7 +39,7 @@ is returning the expected results.  The
 JMeter's performance will suffer.  This option should be off if you are doing stress-testing
(it
 is off by default).  </p>
 <p>If you are not recording the data to file, this option makes no difference.</p>
-<p>You can also use the Configuration button on a listener to decide what fields to
save.</p>
+<p>You can also use the <code>Configuration</code> button on a listener
to decide what fields to save.</p>
 
 <subsection name="&sect-num;.1 Thread Group" anchor="thread_group">
 <p>Thread group elements are the beginning points of any test plan.
@@ -257,7 +257,7 @@ Other listeners provide summary or aggre
 Additionally, listeners can direct the data to a file for later use.  
 Every listener in JMeter provides a field to indicate the file to store data to.
 There is also a Configuration button which can be used to choose which fields to save, and
whether to use CSV or XML format.
-<b>Note that all Listeners save the same data; the only difference is in the way the
data is presented on the screen.</b>
+<note>Note that all Listeners save the same data; the only difference is in the way
the data is presented on the screen.</note>
 </p>
 
 <p>
@@ -305,10 +305,10 @@ add an assertion to a HTTP Request that
 will then check that the text is present in the HTTP response.  If JMeter cannot find the
 text, then it will mark this as a failed request.</p>
 
-<p>
+<note>
 Note that assertions apply to all samplers which are in its <a href="#scoping_rules">scope</a>.
 To restrict the assertion to a single sampler, add the assertion as a child of the sampler.
-</p>
+</note>
 
 <p>To view the assertion results, add an Assertion Listener to the Thread Group.
 Failed Assertions will also show up in the Tree View and Table Listeners, 
@@ -359,9 +359,9 @@ See the <a href="test_plan.html#scoping_
 <li>Pre-Processors</li>
 <li>Timers</li>
 <li>Sampler</li>
-<li>Post-Processors (unless SampleResult is null)</li>
-<li>Assertions (unless SampleResult is null)</li>
-<li>Listeners (unless SampleResult is null)</li>
+<li>Post-Processors (unless SampleResult is <code>null</code>)</li>
+<li>Assertions (unless SampleResult is <code>null</code>)</li>
+<li>Listeners (unless SampleResult is <code>null</code>)</li>
 </ol>
 
 <note>
@@ -422,30 +422,30 @@ that Controller.  In the following test
 <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>
-<b>
+<note>
 The Configuration elements Header Manager, Cookie Manager and Authorization manager are
 treated differently from the Configuration Default elements.
 The settings from the Configuration Default elements are merged into a set of values that
the Sampler has access to.
 However, the settings from the Managers are not merged.
 If more than one Manager is in the scope of a Sampler, 
-only one Manager is used, but there is currently no way to specify <b>which</b>
is used.
-</b>
+only one Manager is used, but there is currently no way to specify <em>which</em>
is used.
+</note>
 </subsection>
 
 
 <subsection name="&sect-num;.11 Properties and Variables" anchor="properties">
 
 <p>
-JMeter <b>properties</b> are defined in jmeter.properties (see <a href="get-started.html#configuring_jmeter">Getting
Started - Configuring JMeter</a> for more details).
+JMeter <em>properties</em> are defined in <code>jmeter.properties</code>
(see <a href="get-started.html#configuring_jmeter">Getting Started - Configuring JMeter</a>
for more details).
 <br></br>
 Properties are global to jmeter, and are mostly used to define some of the defaults JMeter
uses.
-For example the property remote_hosts defines the servers that JMeter will try to run remotely.
+For example the property <code>remote_hosts</code> defines the servers that JMeter
will try to run remotely.
 Properties can be referenced in test plans 
 - see <a href="functions.html#__property">Functions - read a property</a> -
 but cannot be used for thread-specific values.
 </p>
 <p>
-JMeter <b>variables</b> are local to each thread. The values may be the same
for each thread, or they may be different.
+JMeter <em>variables</em> are local to each thread. The values may be the same
for each thread, or they may be different.
 <br></br>
 If a variable is updated by a thread, only the thread copy of the variable is changed.
 For example the <complink name="Regular Expression Extractor"/> Post-Processor 
@@ -480,7 +480,7 @@ For example, the name of a host, or the
 When deciding how to structure a Test Plan, 
 make a note of which items are constant for the run, but which may change between runs.
 Decide on some variable names for these - 
-perhaps use a naming convention such as prefixing them with C_ or K_ or using uppercase only
+perhaps use a naming convention such as prefixing them with <code>C_</code> or
<code>K_</code> or using uppercase only
 to distinguish them from variables that need to change during the test.
 Also consider which items need to be local to a thread - 
 for example counters or values extracted with the Regular Expression Post-Processor.
@@ -493,8 +493,8 @@ HOST             www.example.com
 THREADS          10
 LOOPS            20
 </pre>
-You can refer to these in the test plan as ${HOST} ${THREADS} etc.
-If you later want to change the host, just change the value of the HOST variable.
+You can refer to these in the test plan as <code>${HOST}</code> <code>${THREADS}</code>
etc.
+If you later want to change the host, just change the value of the <code>HOST</code>
variable.
 This works fine for small numbers of tests, but becomes tedious when testing lots of different
combinations.
 One solution is to use a property to define the value of the variables, for example:
 <pre>



Mime
View raw message