What should OCPP testing prove?

OCPP testing should prove three different things. Conformance testing checks whether an implementation follows the specification. Interoperability testing checks whether a particular charger and CPMS work together. Project acceptance testing checks whether the complete setup behaves as the operator requires.

 

A successful WebSocket connection only proves that the two systems can connect. It does not prove that authorisation, transaction records, remote commands, security, offline operation or smart charging work correctly.

Define the exact system under test

Freeze the test configuration before starting. Record the charger model, firmware, CPMS release, OCPP version, security profile, endpoint, network route and enabled functions. Optional OCPP features should be agreed rather than assumed.

 

Use production-like credentials and certificate rules without exposing live secrets. Keep the configuration and logs with the test results so that a later firmware or CPMS update can be compared against the same baseline.

Run OCPP conformance tests

The Open Charge Alliance Compliance Test Tool (OCTT) runs predefined conformance scenarios for OCPP 1.6 and OCPP 2.0.1 charging stations, software stacks and management systems. When a charger is tested, OCTT acts as the management system, and vice versa.

 

OCTT is useful for finding message, validation and sequence errors. It is not a general-purpose charger or CPMS simulator, and running it internally does not create an independent OCPP certificate. Formal OCPP certification uses the official tests through an approved laboratory.

Test the real charger and CPMS together

Next, connect the actual charger, firmware and CPMS release selected for the project. Capture both charger and backend logs so that message timing, retries and rejected requests can be traced from both sides.

 

Interoperability events such as OCPP Plugfests are useful because implementations can be tested against several partners. A deployment still needs its own bilateral test because configuration, optional functions and operating rules differ between projects.

How this applies to amina charging stations

amina’s OCPP documentation states that implemented features are validated with OCTT, internal test automation, field testing and regression tests. The CSMS integration guide also documents production provisioning of the endpoint, certificates and charger identity. For project acceptance, confirm that the selected CSMS accepts the charger serial number, the provisioned endpoint and certificates are correct, and the charger reaches its connected state. Read live configuration values rather than assuming defaults, particularly where an order has customer-specific provisioning.

Test complete charging and operating scenarios

Build test cases around real operations, not isolated messages. At minimum, cover:

  • boot, heartbeat, time synchronisation and status changes;
  • local and remote authorisation, including rejected credentials;
  • session start, meter values, final energy totals and CPMS transaction records;
  • remote start, remote stop, reset, unlock and configuration changes where supported;
  • firmware and diagnostic-log workflows where required;
  • smart-charging profiles, limits and schedule changes where required;
  • the reported maximum-current setting, authorisation defaults and offline rules against the ordered and installed configuration;
  • multiple connectors or EVSEs, if the product has them; and
  • reboot and recovery during an active or interrupted session.

Test security, connectivity and failure behaviour

Repeat key scenarios with a wrong password, an untrusted or expired certificate, an incorrect clock and a broken network connection. Test CPMS outages, reconnects, queued messages, duplicate events and messages arriving in an unexpected order.

 

Confirm what the charger may do offline, how long data is retained, which local authorisation rules apply and what happens when storage or retry limits are reached. The amina authentication guide provides the documented settings and defaults to test. The system should recover predictably without losing or duplicating billable session data.

Test CPMS performance at representative scale

One physical charger cannot prove fleet capacity. Use simulated chargers to test the expected number of concurrent connections, bursts of meter values and remote commands, and mass reconnection after an outage. Monitor response time, WebSocket stability, queueing, database load and alerting against the planned fleet size and growth margin.

Set acceptance criteria before rollout

Each test needs an expected result, evidence, severity and named owner. Define which failures block deployment and which documented limitations can be accepted. Retest corrected issues and run a controlled site pilot before expanding to the full fleet.

 

The handover should include the tested versions, supported functions, credentials and certificate ownership, logs, known exceptions, offline rules and rollback process. Re-run the critical test set after changes to charger firmware, CPMS releases, security settings or network architecture.