Add Glossary

Author: bubafinder

examples/performance-testing-antipattern-examples.md

@@ -2,13 +2,7 @@
 
 ## Antipattern 1: Ignoring Think Time
 
-Excluding think time between user actions can result in unrealistic performance
-metrics for certain types of tests, such as average, stress, and soak tests.
-However, think time is less critical for tests like breakpoint and spike tests,
-as other parameters can control these scenarios effectively. Incorporating
-think time is crucial when simulating real user behavior based on user
-scenarios. In the provided example, user actions are executed without any delay,
-which does not accurately reflect real-world conditions for this type of test.
+Excluding think time between user actions can result in unrealistic performance metrics for certain types of tests, such as average, stress, and soak tests. However, think time is less critical for tests like breakpoint and spike tests, as other parameters can control these scenarios effectively. Incorporating think time is crucial when simulating real user behavior based on user scenarios. In the provided example, user actions are executed without any delay, which does not accurately reflect real-world conditions for this type of test.
 
 ```javascript
 export default function () {
@@ -84,7 +78,7 @@ export default function () {
 
 ### Solution
 
-Executors control how k6 schedules VUs and iterations. The executor that you choose depends on the goals of your test and the type of traffic you want to model. For example, the `ramping-vus` executor gradually increases the number of VUs over a specified duration, allowing for more realistic load testing for specific test types.
+Executors control how K6 schedules VUs and iterations. The executor that you choose depends on the goals of your test and the type of traffic you want to model. For example, the `ramping-vus` executor gradually increases the number of VUs over a specified duration, allowing for more realistic load testing for specific test types.
 
 ```javascript
 export const options = {
@@ -112,13 +106,28 @@ export default function () {
 
 Based upon our test scenario inputs and results:
 
-- The configuration defines 2 stages for a total test duration of 30 seconds;
-- Stage 1 ramps up VUs linearly from the startVUs of 0 to the target of 10 over a 20 second duration;
-- From the 10 VUs at the end of stage 1, stage 2 then ramps down VUs linearly to the target of 0 over a 10 second duration;
-- Each iteration of the default function is expected to be roughly 515ms, or ~2/s;
-- As the number of VUs changes, the iteration rate directly correlates; each addition of a VU increases the rate by about 2 iters/s, whereas each subtraction of a VU reduces by about 2 iters/s;
+- The configuration defines 2 stages for a total test duration of 30 seconds.
+- Stage 1 ramps up VUs linearly from the 0 to the target of 10 over a 20 second duration.
+- From the 10 VUs at the end of stage 1, stage 2 then ramps down VUs linearly to the target of 0 over a 10 second duration.
+- Each iteration of the default function is expected to be roughly 515ms, or ~2/s.
+- As the number of VUs changes, the iteration rate directly correlates; each addition of a VU increases the rate by about 2 iterations/s, whereas each subtraction of a VUs reduces by about 2 iterations/s.
 - The example performed ~300 iterations over the course of the test.
 
 #### Chart representation of the test execution
 
 ![ramping-vus execution chart](../assets//images//examples/ramping-vus.png)
+
+## Glossary
+
+### **VU**
+
+- Virtual User
+
+### **Think Time**
+
+- Amount of time a script stops during test execution to
+replicate delays experienced by real users while using an application.
+
+### **Iteration**
+
+- A single execution of the default function in a K6 script.