In order to test the load on the web application, I am making a test plan with JMeter. Because the UUID needs to be randomly POSTed in the POST data of the web application, the BSF PreProcessor is trying to randomly generate the UUID and use it in POST.
I want multiple HTTP requests to POST using the same UUID, but somehow the PreProcessor seems to be running over and over again, and I ran into a problem where the UUID changes for each HTTP request.
Test plan configuration is
thread groups
- Pre Processor (where JavaScript is used to randomly generate UUIDs and parameterize them with vars.put, parameter names give serial numbers)
- User parameters (set values for each user).authkey, etc.)
- HTTP request (POST JSON, where UUID with serial parameter name)
- Loop controllers
-- HTTP request (POST JSON related to POST above, same UUID)Specifies serial parameter names in loop count)
It is. Because the UUID in the loop changes, POST data is not relevant and web application testing is not successful.
Since all UUIDs are thrown in the first request and the details are POSTed one for each UUID in the subsequent loop, the parameter names are serial numbers.(Example: UUID1, UUID2....) Therefore, listing user parameters using ${__UUID()} is very strict.
Even if I google it, I can't find an article about the behavior of the Pre Processor. If anyone knows the solution, please let me know. Thank you for your cooperation.
javascript java
How about changing the BSF PreProcessor to a BSF Sampler?
The documentation can be found in 4.10 Scoping Rules linked from 4.7 Pre-Processor Elements.
The elements that make up the JMeter test plan can be categorized as ordered (controller and sampler) and hierarchical (other than that)
Some elements in the test trees are strict hierarchy (Listeners, Config Elements, Post-Processors, Pre-Processors, Assertions, Timers), and some are primary ordered (controllers, samples).
Hierarchical elements apply to all requests belonging to that parent element
Ifits parent is a Controller, then effects all requests that are descendants of that Controller.
When processing each request, it is easy to understand
to think that the test plan tree should be traced from parent to parent from their location to root, and that configuration (hierarchical) elements belonging to the elements visited should be collected and applied.image 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
The elements that make up JMeter's test plan can be categorized as ordered (controller and sampler) and hierarchical (otherwise)
Some elements in the test trees are strict hierarchy (Listeners, Config Elements, Post-Processors, Pre-Processors, Assertions, Timers), and some are primary ordered (controllers, samples).
The hierarchy element applies to all requests belonging to that parent element
Ifits parent is a Controller, then effects all requests that are descendants of that Controller.
When processing each request, it is easy to understand that you follow the test plan tree from your location to your roots and collect and apply configuration (hierarchical) elements that belong to the elements you visited.
image 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
In addition to an example of a test plan in this section, 4.9 Execution Order also has an example of the order of execution:
If you have the following test plan,
Run as follows:
Pre-Processor 1
Timer 1
Timer 2
Sampler1
Post-Processor 1
Post-Processor 2
Assertion 1
Pre-Processor 1
Timer 1
Timer 2
Sampler2
Post-Processor 1
Post-Processor 2
Assertion 1
© 2024 OneMinuteCode. All rights reserved.