How to Test a CPMS: The Complete Testing Guide

Quick answer: CPMS testing is the systematic validation of your Charging Station Management System—the backend controlling, monitoring, and billing every EV charging session. It spans seven testing types: protocol conformance, integration, load, security, regression, end-to-end, and roaming. Run most coverage on virtual emulation and keep physical hardware for final acceptance to catch bugs before production.

A single OCPP protocol bug can cause thousands of failed charging sessions, costing operators real money in lost revenue and avoidable truck rolls. Multiply that across a large network and the losses from a single regression add up quickly.

CPMS testing is the systematic validation of your Charging Station Management System — the backend that controls, monitors, and bills every EV charging session on your network. It covers everything from OCPP message parsing to database consistency under load, from TLS certificate handling to roaming interoperability.

This guide covers the seven types of CPMS testing, a detailed testing checklist, and how to build a testing pipeline that catches bugs before they reach production.

What Is a CPMS?

A CSMS (Charging Station Management System) is the central backend platform that communicates with charging stations over OCPP, manages user authorization, tracks energy delivery, and generates billing records (CDRs). It is the operational backbone of any EV charging network.

If you are new to CPMS architecture, read our deep dive: What Is a CPMS?. For a hands-on walkthrough of building one, see How to Build a CPMS.

The rest of this guide assumes you have a CPMS — either built in-house or procured from a vendor — and you need to test it thoroughly.

What Are the 7 Types of CPMS Testing?

Every mature CPMS testing program includes these seven categories. Skip any one of them and you leave a class of bugs undetected.

1. Protocol Conformance Testing

Protocol conformance testing validates that your CPMS correctly implements every OCPP message flow according to the OCPP specification published by the Open Charge Alliance. This is the foundation — if your CPMS cannot parse a valid BootNotification request or sends a malformed StatusNotification response, nothing else matters.

What to validate:

• Message schema compliance: Every request and response conforms to the OCPP JSON schema (1.6) or the OCPP 2.0.1 JSON schema. Fields have correct types, required fields are present, and enums contain only valid values.
• Message flow sequencing: The CPMS handles messages in the correct order. For example, a StartTransaction should only be accepted after a successful BootNotification and StatusNotification with status Available.
• Error handling: The CPMS returns correct OCPP error codes (OCPP 1.6: NotImplemented, NotSupported, InternalError, ProtocolError, SecurityError, FormationViolation, PropertyConstraintViolation, OccurenceConstraintViolation, TypeConstraintViolation, GenericError; OCPP 2.0.1 and 2.1 rename FormationViolation to FormatViolation, spell OccurrenceConstraintViolation with two "r"s, and add MessageTypeNotSupported and RpcFrameworkError) when it receives malformed or unexpected messages. See our OCPP Error Codes Reference for the full list.
• Optional feature profiles: If your CPMS advertises support for SmartCharging, FirmwareManagement, or Reservation profiles, every message in those profiles must be handled correctly.
• Version negotiation: For OCPP 2.0.1, the CPMS must correctly negotiate the protocol version during the WebSocket handshake.

How to test it:

Send every valid OCPP message type to your CPMS and verify the response. Then send every invalid variation — missing required fields, wrong types, unknown enum values, oversized strings — and verify the error response. Automate this with a test harness that iterates through the OCPP schema.

2. Integration Testing

Integration testing validates that your CPMS works with real-world chargers from different vendors. The OCPP specification leaves enough room for interpretation that two spec-compliant implementations can still fail to communicate.

Common vendor-specific behaviors:

• ABB chargers may send meter values with different measurand formats than what your CPMS expects.
• EVBox chargers handle offline transaction queuing differently, sending batched StartTransaction and StopTransaction messages when reconnecting.
• Wallbox units may use non-standard DataTransfer messages for proprietary features.
• Schneider Electric chargers may have different timeout behaviors for BootNotification retry intervals.

What to test:

• Connect chargers from at least three different vendors and run full charging sessions.
• Test the DataTransfer message handling for vendor-specific extensions.
• Validate that your CPMS handles firmware version differences within the same vendor (charger firmware updates often change OCPP behavior subtly).
• Test charger provisioning workflows — adding a new charger, updating its configuration, and decommissioning it.

If you do not have access to physical chargers from multiple vendors, virtual charger emulators that replicate vendor-specific behaviors are essential. This is where tools like OCPPLab become critical — you can emulate different vendor behaviors without purchasing hardware.

3. Load Testing

Load testing answers the question: what happens when your entire network comes online at once?

After a power outage, a firmware update rollout, or a scheduled reboot window, thousands of chargers reconnect simultaneously. Each one sends a BootNotification, followed by StatusNotification messages for every connector, followed by queued offline transactions. Your CPMS must handle this surge without dropping connections or losing data.

Key metrics to measure:

• Concurrent WebSocket connections: Can your CPMS maintain 10,000+ persistent WebSocket connections simultaneously? 50,000? What is the ceiling before connections start failing?
• Message throughput: How many OCPP messages per second can your CPMS process? A network of 10,000 chargers sending meter values every 30 seconds generates ~333 messages per second at steady state — but during a reconnection surge, you may see 10x that.
• Database write throughput: Every MeterValues message, every StartTransaction, every StopTransaction triggers database writes. What is your write throughput under peak load?
• Response latency: OCPP requires the CPMS to respond within a timeout window (typically 30 seconds, configurable). Under load, if your response latency exceeds this window, chargers will treat it as a timeout and may drop the connection.
• Memory consumption: Long-running WebSocket connections accumulate state. Does your CPMS leak memory over hours of sustained load?

Load testing approach:

1. Start with a baseline: 100 simulated chargers running normal charging sessions.
2. Ramp to 1,000, then 5,000, then 10,000 concurrent connections.
3. At each level, measure throughput, latency (p50, p95, p99), error rate, and resource consumption.
4. Simulate a "thundering herd" scenario: all chargers disconnect and reconnect within a 60-second window.
5. Run sustained load for 24+ hours to detect memory leaks and connection pool exhaustion.

For a detailed comparison of physical and virtual load testing approaches, see the Physical vs Virtual Testing section below.

4. Security Testing

A CPMS is a network-facing service that controls physical infrastructure and handles billing data. Security testing is not optional.

TLS and transport security:

• Validate that your CPMS enforces TLS 1.2 or higher on all WebSocket connections.
• Test each OCPP 2.0.1 security profile: Security Profile 1 (HTTP Basic Auth over plain ws://, no TLS), Security Profile 2 (HTTP Basic Auth over wss:// with server TLS certificate), and Security Profile 3 (mutual TLS — both server and client X.509 certificates over wss://). OCPP 1.6 deployments using the Security Whitepaper edition 2 use the same three profiles with the same numbers.
• Verify certificate validation: does the CPMS reject expired certificates, self-signed certificates (unless explicitly allowed), and certificates with wrong hostnames?
• Test certificate rotation workflows without service interruption.

Authentication and authorization:

• Validate that unknown charge point identities are rejected at connection time.
• Test RFID-based authorization with valid, expired, blocked, and unknown tokens.
• Test remote start authorization — ensure the CPMS only accepts remote start requests from authenticated and authorized users.
• Validate that Plug & Charge (ISO 15118) certificate chains, defined in ISO 15118-2, are verified correctly.

Input validation and injection:

• Send malformed JSON payloads to test for JSON injection vulnerabilities.
• Test with oversized messages to validate buffer handling.
• Send messages with unexpected Unicode characters, null bytes, and control characters.
• Verify that charge point identifiers and user inputs are sanitized before database queries.

Penetration testing:

• Test WebSocket connection hijacking scenarios.
• Attempt to impersonate a charge point by reusing a valid charge point identity from a different IP.
• Test for information leakage in error messages.
• Validate rate limiting on authentication attempts.

Read our OCPP WebSocket guide for more on securing OCPP WebSocket connections.

5. Regression Testing

Regression testing ensures that new code changes do not break existing charger compatibility. This is especially critical for CPMS platforms that support multiple OCPP versions (1.6 and 2.0.1) simultaneously.

What regression testing catches:

• A database migration that changes column types, breaking serialization of MeterValues timestamps.
• A refactor of the authorization logic that accidentally rejects valid RFID tokens with leading zeros.
• An optimization to WebSocket message handling that drops messages under specific timing conditions.
• A new feature (e.g., smart charging) that introduces a side effect in the transaction lifecycle.

How to build a regression suite:

1. Record real traffic: Capture OCPP message sequences from production chargers (sanitize sensitive data). Replay these sequences against your staging CPMS after every code change.
2. Vendor-specific test suites: Maintain a test suite for each charger vendor you support, covering their known OCPP behavior quirks.
3. Golden file testing: Store expected CPMS responses for a set of input messages. After each build, compare actual responses against the golden files.
4. Backward compatibility checks: If you support OCPP 1.6 and 2.0.1, run the full regression suite for both versions on every code change.

6. End-to-End Testing

End-to-end testing validates the entire charging session lifecycle, from the moment a driver plugs in to the generation of a final billing record.

A complete e2e test covers:

1. Charger boot: BootNotification → CPMS responds Accepted with a heartbeat interval.
2. Status reporting: Charger sends StatusNotification with Available for all connectors.
3. Authorization: Driver presents RFID → charger sends Authorize → CPMS responds Accepted.
4. Transaction start: Charger sends StartTransaction with connector ID, meter start value, and ID tag → CPMS responds with transaction ID.
5. Meter values: Charger sends periodic MeterValues with energy (Wh), power (W), current (A), voltage (V), SoC (%), and temperature readings.
6. Smart charging (optional): CPMS sends SetChargingProfile → charger acknowledges and adjusts power output.
7. Transaction stop: Driver unplugs → charger sends StopTransaction with meter stop value and reason → CPMS responds Accepted.
8. CDR generation: The CPMS generates a Charge Detail Record with accurate energy delivered, session duration, and cost calculation.
9. Status update: Charger sends StatusNotification with Available — ready for the next session.

Edge cases to cover in e2e tests:

• Driver unplugs mid-charge (abnormal stop).
• Network drops during an active session — charger queues messages offline and replays on reconnect.
• CPMS sends RemoteStopTransaction while a session is active.
• Two sessions start simultaneously on a dual-connector charger.
• Meter value discrepancies between start/stop values and intermediate readings.
• Session that spans a clock rollover (midnight, DST change).

7. Roaming Testing

If your charging network participates in roaming — allowing drivers from other networks to charge on your stations — you need to validate your OCPI integration—the open roaming standard maintained by the EVRoaming Foundation—with CPOs, eMSPs, and roaming hubs.

What to test:

• Token synchronization: eMSP tokens are correctly synced to your platform via OCPI Tokens module. Test with valid, expired, and revoked tokens.
• CDR delivery: After a roaming session, the CDR is correctly formatted and delivered to the eMSP via OCPI CDRs module.
• Tariff exchange: Your tariffs are correctly published via OCPI Tariffs module and correctly applied during roaming sessions.
• Real-time authorization: POST /commands/START_SESSION from an eMSP triggers a RemoteStartTransaction on the correct charger.
• Location data: Your charge point locations, EVSEs, and connectors are correctly published and updated via OCPI Locations module.
• Hub integration: If you connect through a roaming hub like Gireve or Hubject, validate that messages correctly route through the hub.

For a detailed comparison of roaming protocols, see OCPI vs OICP vs OCHP.

CPMS Testing Checklist

Use this checklist as a baseline for your testing coverage. Every item should have at least one automated test.

BootNotification Handling

• Accept valid BootNotification with all required fields
• Handle vendor-specific optional fields (vendor name variations, firmware versions)
• Return correct heartbeat interval in response
• Handle duplicate BootNotification from the same charger (reconnect scenario)
• Reject BootNotification from unknown/unauthorized charge points
• Handle BootNotification with Pending status for chargers requiring configuration

Transaction Lifecycle

• StartTransaction with valid RFID token
• StartTransaction with remote start (no local token)
• StopTransaction with all standard stop reasons (EmergencyStop, EVDisconnected, HardReset, Local, Other, PowerLoss, Reboot, Remote, SoftReset, UnlockCommand, DeAuthorized)
• Offline transactions: charger sends queued StartTransaction and StopTransaction after reconnection with correct timestamps
• Transaction with zero energy delivered (plug in, immediate unplug)
• Concurrent transactions on multi-connector chargers
• Transaction ID uniqueness and sequential assignment

Smart Charging Profile Management

• SetChargingProfile with TxDefaultProfile, TxProfile, and the versioned max profile (ChargePointMaxProfile on 1.6; ChargingStationMaxProfile on 2.0.1, where ChargingStationExternalConstraints comes from the station via NotifyChargingLimit)
• Charging schedule with multiple periods and power limits
• Profile stacking and priority handling
• ClearChargingProfile for specific profiles and bulk clearing
• GetCompositeSchedule returns correct merged schedule
• Profile validation: reject profiles with invalid timestamps, negative power values, or overlapping periods

Firmware Update Workflows

• UpdateFirmware with valid URI → charger downloads and installs
• Firmware update status notifications (Downloading, Downloaded, Installing, Installed, InstallationFailed)
• Firmware update during active charging session (should be deferred)
• Invalid firmware URI handling
• Firmware update retry on download failure

Error Recovery

• Network drop during active session — session state preserved, messages replayed on reconnect
• CPMS restart — active sessions recovered from database, chargers reconnect gracefully
• Timeout handling: charger does not respond to a RemoteStartTransaction within timeout window
• Malformed OCPP message handling — return appropriate error, do not crash
• WebSocket ping/pong keepalive and connection health detection
• Database connection pool exhaustion — graceful degradation, not crash

Authorization Flows

• RFID authorization with local auth list
• RFID authorization with online validation
• Remote start via CPMS API → RemoteStartTransaction
• Plug & Charge (ISO 15118) certificate-based authorization
• Authorization cache behavior (cache hit, cache miss, cache expiry)
• Blocked/expired/invalid token handling
• Parent ID tag grouping (fleet cards)

Concurrent Session Handling

• 100 chargers running simultaneous sessions — all transactions recorded correctly
• 1,000 chargers sending meter values simultaneously — no dropped messages
• Mixed OCPP versions (1.6 and 2.0.1) running concurrently
• WebSocket connection pool under concurrent load

Database Consistency Under Load

• Transaction records match exactly: start meter value + energy from meter values = stop meter value
• No duplicate transaction IDs under concurrent writes
• CDR amounts match calculated energy × tariff
• Timestamps are stored and returned in correct timezone (UTC)
• Database deadlocks under concurrent transaction updates

Physical vs Virtual Testing

The practical approach: Use virtual testing for most of your CPMS testing — protocol conformance, load testing, regression testing, and CI/CD integration. Reserve physical testing for final hardware acceptance testing and electrical safety validation.

For a deeper analysis, read Virtual vs Physical Testing for EV Chargers.

How Do You Build a CPMS Testing Pipeline?

A production-grade CPMS testing pipeline integrates automated OCPP tests into your CI/CD workflow so that every code change is validated before it reaches production.

Stage 1: Unit Tests (Run on Every Commit)

Unit tests validate individual CPMS components in isolation:

• OCPP message parser: correct serialization/deserialization for every message type.
• Authorization logic: token validation, cache behavior, parent ID grouping.
• Tariff calculation engine: energy cost, time cost, flat fees, tax calculations.
• Database models: ORM mapping, constraint enforcement, migration compatibility.

Target: < 2 minutes execution time. Run on every commit.

Stage 2: Integration Tests (Run on Every PR)

Integration tests validate CPMS behavior against simulated chargers:

• Spin up a test CPMS instance with an in-memory or ephemeral database.
• Connect 5–10 simulated chargers using an OCPP emulator.
• Run the full charging session lifecycle for each OCPP version you support.
• Validate database state after each test scenario.

Target: < 10 minutes execution time. Run on every pull request.

Stage 3: Load Tests (Run Nightly or Pre-Release)

Load tests validate scalability:

• Deploy the CPMS to a staging environment that mirrors production.
• Ramp up to your target concurrent connection count (e.g., 10,000 chargers).
• Run sustained load for 1–4 hours.
• Capture and trend performance metrics: latency, throughput, error rate, memory.
• Fail the build if any metric exceeds the defined threshold.

Target: 1–4 hours. Run nightly or before every release.

Stage 4: Regression Tests (Run Pre-Release)

Regression tests replay recorded production traffic:

• Use sanitized production OCPP message captures as test inputs.
• Compare CPMS responses against golden file baselines.
• Flag any response that differs from the expected baseline.
• Include vendor-specific regression suites for every charger model you support in production.

Target: 30–60 minutes. Run before every release.

Stage 5: Security Scan (Run Weekly)

• Dependency vulnerability scanning (CVEs in OCPP libraries, WebSocket frameworks, TLS libraries).
• Static analysis for injection vulnerabilities.
• TLS configuration validation (cipher suites, certificate chain, protocol version).
• Authentication bypass testing.

Which CPMS Bugs Does Virtual Testing Catch?

These are real-world bugs that teams have caught through systematic virtual CPMS testing:

1. Off-by-one in meter value parsing: A CPMS parsed the sampledValue array index incorrectly, reading voltage where it expected energy. This went undetected in production for weeks because most chargers sent meter values in a consistent order — until a new charger vendor sent them in a different order. Virtual testing with randomized meter value ordering caught it immediately.

2. Transaction ID overflow: A CPMS used a 32-bit integer for transaction IDs. After 2.1 billion transactions, the ID wrapped to negative values. Chargers rejected negative transaction IDs, causing all new sessions to fail. A virtual load test simulating high transaction volumes would have caught this before production.

3. Timezone handling in CDRs: A CPMS stored all timestamps in local time instead of UTC. When chargers in different timezones sent StopTransaction messages, the CDR duration calculations were wrong — sometimes negative. Virtual testing with chargers configured in multiple timezones exposed this immediately.

4. WebSocket connection leak: A CPMS did not properly clean up WebSocket connections when chargers disconnected without sending a close frame (common during power outages). Over days, the connection pool filled up, and new chargers could not connect. A 24-hour virtual load test with periodic forced disconnections caught this.

5. Race condition in concurrent authorization: Two Authorize requests arriving within milliseconds for the same RFID token caused a database deadlock. This only manifested at scale — virtual testing with 500 concurrent authorization requests reproduced it consistently.

6. Heartbeat interval ignored after reconnect: After a charger reconnected, the CPMS sent a new heartbeat interval in the BootNotification response, but the charger-side cache was not cleared. The old interval persisted, leading to either excessive heartbeats (wasting bandwidth) or missed heartbeats (triggering false offline alarms). Virtual testing with configurable reconnection scenarios caught the discrepancy.

7. Smart charging profile rejected silently: The CPMS sent a SetChargingProfile that the charger accepted, but the response contained an error detail in a vendor-specific field that the CPMS did not parse. The charger never applied the profile, but the CPMS assumed it did. Virtual testing with strict response validation caught the silent failure.

What Tools Are Available for CPMS Testing?

Several tools are available for CPMS testing, ranging from open-source libraries to commercial platforms:

• OCPPLab: A cloud-based OCPP emulator that simulates chargers at scale. Supports OCPP 1.6, 2.0.1 and 2.1, configurable vendor behaviors, and CI/CD integration via API. Designed specifically for CPMS testing.
• SteVe: An open-source CPMS implementation that can serve as a reference for testing your own CPMS against a known baseline.
• OCPP.js: A JavaScript library for building OCPP clients and servers. Useful for writing custom test harnesses.
• Custom test harnesses: Many teams build their own using WebSocket libraries in Python, Go, or Node.js, combined with the OCPP JSON schemas for validation.

For a detailed comparison of these tools, read Best OCPP Testing Tools Compared.

Frequently Asked Questions

How many test cases does a thorough CPMS test suite need?

A comprehensive CPMS test suite for OCPP 1.6 typically includes 200–400 test cases covering all message types, error conditions, and edge cases. OCPP 2.0.1 adds another 200–300 due to the expanded message set and security profiles. Load and performance tests add 20–50 more. The total depends on how many charger vendors and OCPP versions you support.

Can I test a CPMS without physical chargers?

Yes. Virtual OCPP emulators can simulate charger behavior at the protocol level, which covers most CPMS testing — protocol conformance, integration, load, regression, and security testing. Physical chargers are only necessary for final hardware acceptance testing and validating electrical-layer behavior. See the Physical vs Virtual Testing comparison above.

How do I test CPMS behavior during network outages?

Use a virtual emulator that supports programmatic network control. Simulate a network drop during an active charging session: disconnect the WebSocket, wait a configured duration (30 seconds to 5 minutes), then reconnect and send the queued offline messages (StartTransaction, MeterValues, StopTransaction with historical timestamps). Validate that your CPMS correctly processes the replayed messages and reconstructs the session.

What is the difference between OCPP conformance testing and CPMS testing?

OCPP conformance testing is one component of CPMS testing. Conformance testing validates that your CPMS correctly implements the OCPP protocol specification. CPMS testing is broader — it also covers load testing, security testing, integration testing with multiple vendors, end-to-end session validation, roaming interoperability, and database consistency.

How often should I run CPMS load tests?

Run a lightweight load test (1,000 simulated chargers, 30 minutes) nightly as part of your CI/CD pipeline. Run a full-scale load test (10,000+ chargers, 4+ hours) before every production release and after any infrastructure changes (database migration, WebSocket server upgrade, scaling configuration changes).

Should I test OCPP 1.6 and 2.0.1 separately?

Yes. Maintain separate test suites for each OCPP version because the message schemas, security models, and feature sets differ significantly. However, also test them running concurrently — most production CPMS platforms support both versions simultaneously, and interactions between the two codepaths can introduce bugs. Read our comparison of OCPP 1.6 vs 2.0.1 for the key differences.

How do I validate CPMS billing accuracy?

Create test scenarios with known energy delivery values and tariffs, then verify that the generated CDRs calculate the correct cost. Cover edge cases: sessions that span tariff changes (peak/off-peak transitions), sessions with minimum fees, sessions with multiple tariff components (energy fee + time fee + connection fee), and sessions with tax calculations. Compare your CDR output against a reference calculation for every test case.

What should I do when a charger vendor reports a compatibility issue?

First, capture the exact OCPP message exchange from the charger (most chargers have diagnostic logging). Replay that message sequence against your CPMS in a test environment to reproduce the issue. Once reproduced, add it as a permanent regression test case for that vendor. Fix the issue, verify the fix against the captured traffic, and ensure the fix does not break other vendor test suites.