Skip to content

REAL_DFU_TEST_PLAN.md

Latest commit

 

History

History
142 lines (94 loc) · 3.61 KB

REAL_DFU_TEST_PLAN.md

File metadata and controls

142 lines (94 loc) · 3.61 KB

Real DFU Test Plan (ESP32 + iOS)

Objective

Validate reliable and repeatable BLE DFU updates from the iOS app to an ESP32 target using Nordic Legacy DFU semantics.

Scope

This plan covers:

  • Device discovery and selection
  • DFU transfer behavior and stage transitions
  • Recovery behavior (disconnect, cancel, retry)
  • File handling and error surfacing
  • Stability across repeated update cycles

This plan does not cover:

  • Firmware business logic validation beyond successful boot
  • Security hardening of the firmware image format

Test Environment

  • iPhone running iOS 16+
  • ESP32 device running compatible DFU firmware
  • Stable power source for ESP32
  • At least one known-good firmware binary
  • At least one intentionally invalid file

Preconditions

  • Bluetooth permission is granted to the app.
  • The ESP32 advertises the expected DFU service UUID.
  • The firmware file is accessible from Files/iCloud/local storage.
  • iPhone battery > 20% and ESP32 power is stable.

Functional Test Cases

TC-01 Happy Path Update

  1. Launch app and scan for devices.
  2. Select target ESP32.
  3. Select valid firmware binary.
  4. Start DFU.
  5. Wait for completion.

Expected:

  • Stage transitions progress in order to Completed.
  • Progress reaches 100%.
  • ESP32 reboots and runs updated firmware.

TC-02 Invalid File Handling

  1. Select an invalid or non-firmware file.
  2. Start DFU.

Expected:

  • DFU does not proceed successfully.
  • Error message is visible and actionable.
  • App remains responsive and does not crash.

TC-03 Disconnect During Transfer

  1. Start DFU with valid firmware.
  2. During transfer, force disconnect (move out of range / power cycle target).

Expected:

  • Session transitions to retry flow when enabled.
  • If retries are exhausted, stage transitions to Failed.
  • User can restart DFU afterward.

TC-04 User Cancellation

  1. Start DFU.
  2. Tap Cancel during firmware upload.

Expected:

  • Current operation is aborted cleanly.
  • Stage reports cancellation/failure state consistently.
  • No stuck BLE connection remains.

TC-05 Reconnect and Retry Success

  1. Cause one transient disconnect.
  2. Ensure auto reconnect is enabled.
  3. Verify operation resumes via retry path.

Expected:

  • Retry message appears.
  • Workflow either completes or exits with clear error.
  • No app restart is required.

TC-06 Multiple Sequential Updates

  1. Perform 5 to 10 successful updates in sequence.

Expected:

  • No crash or significant responsiveness degradation.
  • Memory usage remains stable (no obvious leak pattern).
  • Device remains discoverable and updatable each cycle.

Settings Matrix

Run TC-01 and TC-03 against at least these combinations:

  • PRN: 0, default, high value
  • MTU preference: minimum, default, maximum
  • Auto reconnect: on and off

Non-Functional Checks

  • App remains usable while scanning and during long transfer.
  • Screen awake behavior follows settings during active DFU.
  • Localization changes do not break runtime status rendering.

Pass Criteria

  • Zero crashes in all planned scenarios.
  • Deterministic stage behavior for success/failure.
  • Correct and understandable user-facing error messages.
  • Firmware boots after successful update.

Evidence to Collect

  • iOS logs with timestamps for DFU stages and BLE events
  • ESP32 serial logs around update, validate, reboot
  • Firmware hash/version before and after update
  • Video capture for at least one happy path and one failure path

Exit Criteria

Testing can be considered complete when:

  • All functional cases pass on at least one target device.
  • Critical and high severity defects are resolved.
  • Retry/cancel behavior has been validated at least twice.