Pre-Load-Testing Checklist (JMeter)
A premium, interactive checklist for preparing a JMeter load test, worked through against AtlasBank's International Transfer feature — the same feature used throughout Performance Testing v1.0.
Use this interactive tool to track your load-test preparations. Your checks are persisted in your browser's local storage.
Checklist Completion
Track your testing preparations live. Your progress is saved automatically.
0 of 53 items completed0% Done
🎯1. Business & Testing Objectives0/4
Purpose of the test clearly defined.
Example: Evaluate the International Transfer feature's stability and correctness-preserving performance under Load, Stress, Spike, and Soak conditions ahead of the Q3 promotional campaign.
Business scenarios (critical flows) identified.
Example: transfer submission, compliance-aggregation check, balance debit/credit, confirmation and notification delivery.
Success criteria / SLOs defined.
Example: p95 response time under 1,500ms at expected peak; error rate under 0.1%; zero data-consistency defects; graceful recovery after stress/spike.
Key metrics identified.
Example: Throughput (TPS), p50/p90/p95/p99 latency, error rate, concurrency, CPU/memory utilization, database connection-pool usage, queue depth.
🖥️2. Test Environment Readiness0/5
Environment matches production-like configuration.
Example: Infrastructure specs, service configuration, and worker pool sizing genuinely comparable to production.
Network conditions comparable to production.
Example: No artificial throttling or unrepresentative latency between the load generator and the system under test.
No other tests running on the environment during the test window.
Example: Ensures no noise or CPU spikes from functional, automated, or manual tests interfere with calculations.
Environment stability confirmed before execution.
Example: Health checks, service availability, and baseline resource utilization all verified clean.
Test data volume matches production shape and distribution.
Example: Ensures search indexing and db caches are loaded with realistic production volume data, not just row count.
📈3. Load Profile Definition0/5
Virtual user count defined.
Example: Grounded in a real or estimated concurrent-user target, not an arbitrary guess.
Ramp-up period defined.
Example: Matched deliberately to the test type — gradual for load, incremental for stress, near-immediate for spike.
Steady-state duration defined.
Example: Long enough to observe consistent behavior (load), or extended for a genuine soak run (hours, not minutes).
Think time / pacing defined.
Example: Simulating realistic user behavior rather than back-to-back, unthrottled thread requests.
Peak vs. normal load distinguished explicitly.
Example: Both stated as concrete numbers, not relative terms (e.g. Normal: 50 TPS, Peak: 200 TPS).
💾4. Test Data Preparation0/5
Unique test data per virtual user.
Example: Avoiding data collisions or duplicate keys across concurrent testing threads.
No hardcoded credentials.
Example: All sensitive inputs externalized and parameterized.
Parameterized inputs.
Example: Using JMeter CSV Data Set Config or equivalent for realistic, variable test data.
Test data shaped to match production's real volume and distribution.
Example: Not a uniform, artificially even dataset; should contain edge names, long descriptions, etc.
Data reset / cleanup plan defined.
Example: Steps to revert database states or clear created records after test execution.
⚙️5. JMeter Script Validation0/7
Scripts recorded and cleaned.
Example: Recording artifacts and duplicate headers removed, samplers clearly named.
HTTP headers configured correctly.
Example: Authorization, Content-Type, Accept, and User-Agent headers matched.
Cookies / sessions handled correctly.
Example: Or token-based authentication confirmed stateless where applicable.
Correlation implemented.
Example: Dynamic values like token hashes, session IDs, and generated user identifiers captured and reused.
Response assertions added.
Example: Ensure that only genuinely successful responses count as passing samples, not generic 200 OK blank pages.
Error handling verified.
Example: Failures are captured and logged, not silently dropped or allowed to abort the run.
Timers configured.
Example: Using Gaussian Random Timers or Constant Throughput Timers for realistic pacing.
🧪6. Baseline Test (Mandatory)0/3
Run with a small number of users first.
Example: Run 1–5 users to validate script correctness before scaling to hundreds of threads.
Verify clean execution variables.
Example: No authentication/request errors, correct responses, stable response times, and correct dynamic-value handling.
Fix all script issues before increasing load.
Example: A baseline defect only gets harder to diagnose and isolate at scale.
📊7. Monitoring & Observability Setup0/5
Server-side monitoring enabled.
Example: CPU, memory, disk I/O, network metrics active across every relevant service.
Application-level monitoring enabled.
Example: Tracking response times, transaction throughput, and thread/worker pool health.
Database monitoring enabled.
Example: Connection pool usage, query execution times, lock contention.
Application, database, and system logs enabled.
Example: Crucial for post-test correlation and bottleneck investigation.
A load-generation and a monitoring tool are both running together.
Example: One tool alone cannot confirm a bottleneck location.
🔧8. Tool & Infrastructure Readiness0/6
JMeter version documented.
Example: Ensure all test run logs note the specific executable package versions.
Any plugins used are documented.
Example: e.g., Custom Thread Groups, Dummy Sampler, JSON Path Extractor.
Load generator sized correctly.
Example: Ensure generator CPU and heap sizes can handle target throughput without bottlenecking locally.
Distributed testing setup validated.
Example: Required if a single load generator cannot reach target load on its own.
Non-GUI execution mode configured.
Example: Run in Non-GUI mode (`jmeter -n -t ...`) for any real test run; GUI reserved for script authoring and debugging only.
Sufficient disk space confirmed.
Example: JMeter output files (`.jtl` log files) can grow very large during high-throughput runs.
📅9. Test Execution Plan0/5
Start and end time clearly scheduled.
Example: Run during low-traffic windows to avoid affecting real system users.
Abort / rollback criteria defined.
Example: Specific conditions (e.g. error rate > 5% for 1 min, cpu > 95% for 2 mins) that trigger an early stop.
Stakeholders informed.
Example: Send notifications to dev ops, product owners, and customer support leads before the test window opens.
Communication channel defined.
Example: Active Slack or Teams war-room channel for real-time coordination during execution.
Scripts, test data, and configuration backed up.
Example: Save script revisions in Git version control for traceability and repeatability.
⚠️10. Risk & Assumptions0/4
Known limitations documented.
Example: e.g., a single load-generator region, which may not fully represent geographically distributed traffic.
Scope exclusions documented.
Example: Clear statements on what this specific test does and does not cover (e.g. third-party APIs mocked).
Assumptions about user behavior stated explicitly.
Example: Request distribution profiles, pacing assumptions, and initial database data state assumptions.
Data-cleanup impact considered.
Example: Check whether test-generated records will interfere with reporting, accounting, or reconciliation pipelines.
📝11. Result & Reporting Readiness0/4
Result file naming convention defined.
Example: Ensure filenames include test profile, user count, and timestamp for traceability across repeated runs.
Metrics to report agreed.
Example: Minimum of Average, p90/p95/p99, error rate, throughput, and CPU usage.
Comparison against a prior baseline planned.
Example: Measure degradation or improvements against previous release metrics.
A bottleneck-analysis approach defined in advance.
Example: Determine which resource dimensions will be correlated against the load timeline, rather than deciding ad hoc.
Related Guides
- Performance Testing v1.0 — the full learning path this checklist condenses
- Performance Testing Strategy — how to decide what deserves this checklist's full rigor in the first place
- Result Analysis and Reporting — turning this checklist's output into a communicated result