Test Scope
The test scope for the Communications Control Software with WiFI/LTE/5G project covers the system's externally visible functionality, the interactions among its major architectural components, and the performance and quality characteristics that emerge only when those components operate together. The scope includes all behavior involved in establishing and maintaining communication between radios, processing and routing messages, handling user interaction, and managing system configurations. Testing also covers the correctness and robustness of communication protocols, including connection setup, transmission, reception, and error handling. As this plan focuses on integration and validation rather than unit-level behavior, the emphasis is placed on how subsystems cooperate once individually tested components are assembled into larger structures.
The scope includes evaluation of timing behavior related to message transmission, responsiveness of user-facing features, and the system's ability to sustain expected loads without experiencing degradation. Internal design characteristics are also part of the scope, particularly those that affect inter-component behavior such as reliability during partial failures, maintainability as reflected in the clarity of module interactions, and adaptability in areas where the design anticipates future expansion. Integration tests will therefore examine interfaces, data exchanges, communication sequences, and state transitions across subsystem boundaries. Validation testing will focus on demonstrating that the final assembled system satisfies the functional requirements stated for the radio system and behaves consistently with the expectations defined by the original project description.
The scope does not include evaluating individual modules in isolation, verifying internal algorithms within a single component, assessing development processes or resources, or performing detailed performance tuning at the hardware level. It concentrates on system behavior that emerges only when the designed architecture is executed as a whole, ensuring that the integrated system meets both its required functionality and its intended quality attributes.
Test Plan
For this project, we will conduct the integration testing in three main phases using a primarily bottom-up integration strategy aligned with the layered architecture of networking, communication control, and user interface. The first phase focuses on integrating the core communication control logic and the networking abstractions that support WiFi, LTE, 5G, and the legacy trunked radio network. The second phase extends the integrated core by adding multi radio coordination capabilities and the components that manage repeater towers, gateways, and failover behavior. The third phase completes the integration by adding the user facing interfaces and administrative tools, resulting in a build that represents the full Communications Control Software with WiFi, LTE, and 5G capabilities.
In the first phase, the partial build will contain the control channel manager, the network selection and handover logic, the session and talk group management services, and the basic networking interfaces that abstract the different underlying transport technologies. At this point, there is no graphical user interface or full operator console, and any physical radio hardware or external systems not yet integrated will be simulated with simple drivers and stubs. This phase allows us to test core behaviors such as establishing Push to Talk sessions, selecting an available network path, maintaining state across sessions, recording basic call metadata, and handling error conditions on a single or small number of radios. Because these services are responsible for satisfying requirements like automatic network switching, connection success rate, and basic latency constraints, exercising them early in isolation from higher layers makes it easier to identify design or protocol issues before they are obscured by user interface concerns.
In the second phase, the partial build will extend the core communication control services with the modules that manage interoperability gateways and repeater towers, as well as the logic for coordinating multiple radios and communication paths. This includes the components that interact with the LTE and WiFi gateways, the tower control and monitoring services, the priority and emergency routing logic, and the backup path selection and recovery mechanisms. The intention in this phase is to test scenarios where many radios and users share a pool of frequencies and broadband links, where traffic must be routed across different networks, and where failures or degraded links trigger automatic switchover to backup paths. By integrating gateways and tower control at this stage, we can evaluate capacity related requirements, such as the number of simultaneous connections and end to end delay under load, in an environment that is still simpler than the full user-facing system but already reflects realistic multi network behavior.
In the third phase, the build will include the complete user interface and operator consoles for both front line personnel and system administrators. This final integration step connects the communication control and networking layers to the user interface layer that implements Push to Talk buttons, emergency alert operations, talk group configuration screens, status dashboards for towers and gateways, and historical call record views. This phase allows us to verify that user actions are correctly translated into control requests, that feedback on system state and network selection is presented accurately, and that user workflows for common scenarios such as creating talk groups, responding to emergencies, and monitoring remote sites behave as intended. Because the underlying control and networking functionality has been exercised in the earlier phases, the focus here is on validating end to end behavior, usability-oriented flows, cross-platform consistency, and the correct propagation of failures and recovery events up to the user level.
A bottom-up integration strategy is appropriate for this system because the most complex and risk-prone behavior occurs in the lower layers that manage multiple heterogeneous networks, coordinate repeater towers, and maintain reliable sessions under failure conditions. Integrating and testing these layers first reduces the number of stubs required and allows the team to address issues in network selection algorithms, control channel handling, and failover logic before introducing user interface variability. Alternative strategies, such as starting with the user interface and stubbing out all communication services, would require extensive and fragile stubs to mimic detailed timing and failure scenarios on WiFi, LTE, and 5G paths. By instead building upward from the communication core, each subsequent phase reuses tested functionality and adds a thin layer of new behavior, which simplifies defect isolation and yields a clearer understanding of how the architecture supports the project's functional and nonfunctional requirements.
Phase One: Core Communication Control and Network Selection Logic
In Phase 1, we are testing the core communication control and network selection logic that forms the backbone of the Communications Control Software with WiFi, LTE, 5G, and P25. This phase focuses on the Communications Controller working with simplified representations of the Radio Firmware and Mobile Application, along with basic control channel behavior. As a result, we will be directly testing the following requirements from the original document: FR-1 Push to Talk behavior that sends a request to the control channel to join a talk group when the user activates PTT, FR-3 automatic switching between WiFi, 5G, LTE, and P25 to select the most stable connection, FR-4 emergency alerts that are prioritized and sent immediately to the command center and related units, FR-8 reporting abnormal conditions and switching to a backup communication path, and FR-9 recording time, channel, participating units, and users for each call and alert event.
We will also indirectly test FR-2 and FR-6 by having the controller operate with predefined talk groups and multiuser communication flows that assume group definitions already exist, even though user-facing group management and cross department workflows are not yet fully integrated. The tests in this phase will involve sending control and signaling requests from simulated radios and mobile clients into the Communications Controller, observing network selection decisions, verifying that PTT sessions and emergencies are correctly established and torn down, and confirming that abnormal network conditions trigger failover and are reflected in the system logs.
| Test Case Id | Test Case Objective | Test Case Description | Expected Results |
|---|---|---|---|
| P1-01 | Verify basic Push-to-Talk session establishment for a single unit (FR-1). | Using a simulated radio, the test harness sends a PTT request to join a predefined talk group over a stable primary network. The Communications Controller negotiates with the control channel stub to establish a session and allocate any required resources. | Controller sends a join request to the control channel; the session state for the unit transitions from idle to active in the talk group; the controller acknowledges the established session back to the simulated radio client. |
| P1-02 | Confirm PTT session establishment for multiple units in the same talk group (FR-1, FR-6). | Several simulated radios, all configured with the same existing talk group, sequentially send PTT join requests via the test harness. The Communications Controller processes each request using the same control channel and network abstraction layer. | All units are admitted into the talk group according to controller rules; each join is acknowledged; the internal state reflects all participating units in the session without conflicts or dropped requests. |
| P1-03 | Validate automatic network selection on initial session setup (FR-3). | The network simulator exposes WiFi, LTE, 5G, and P25 links with predefined quality levels. A simulated radio sends a PTT join request. The Communications Controller must choose the most stable network based on the configured selection algorithm. | The controller selects the network that matches the configured stability/priority policy and records the chosen path in session state. The join request completes successfully using that network. |
| P1-04 | Verify automatic network handover when the active network degrades (FR-3, FR-8). | Start a PTT session over a selected primary network. While the session is active, the network simulator gradually degrades the primary link beyond acceptable thresholds. The Communications Controller must detect the degradation and switch the session to a more stable alternate network without explicit user action. | The controller detects degradation based on configured metrics and switches the session to a backup network. The session remains logically active; the controller updates its internal state to reflect the new path and issues any necessary control messages to the control channel stub. |
| P1-05 | Ensure emergency alerts are prioritized and routed immediately (FR-4). | With normal PTT traffic already active, a simulated radio issues an emergency alert request to the Communications Controller. The controller must treat this request with higher priority than standard PTT join/leave operations. | The emergency alert is accepted and processed ahead of any queued non-emergency traffic. The controller sends alert messages to the command-center endpoint stub and all relevant units, and marks the originating unit/session as in an emergency state. |
| P1-06 | Verify emergency alerts generate appropriate log entries (FR-4, FR-9). | Trigger one or more emergency alert requests from different simulated radios and let the controller process and clear them. After execution, query the system log store through the test harness to inspect recorded events. | For each emergency alert, logs include at minimum: timestamp, originating unit, associated talk group, alert type, and any network path information. Logged entries appear in the correct order and can be correlated back to the originating requests. |
| P1-07 | Confirm detection and reporting of abnormal network conditions (FR-8). | While a PTT session is active, the network simulator injects abnormal conditions on the current network path but does not fully terminate the link. The controller must recognize the abnormal state and report it. | The controller flags the affected network as abnormal, raises an internal alarm or status indication, and records the condition in the logs. If policy dictates that the session remain on the current link, no unintended teardown occurs; otherwise, failover is initiated per configuration. |
| P1-08 | Verify automatic switchover to a backup communication path on failure (FR-8). | Establish a PTT session on a primary network. The network simulator then forces a hard failure of that network. The Communications Controller must switch the active session to a configured backup network and continue operation. | The controller detects the failure, selects an available backup network, transitions the session onto the backup, and updates its internal state. The session remains active from the simulated radio's perspective, and a corresponding failover event is logged. |
| P1-09 | Validate logging of call and session metadata for PTT flows (FR-9). | Execute a sequence of normal PTT sessions involving one or more simulated radios and talk groups. At the end of the sequence, query the log repository to inspect the records associated with these sessions. | For each session, logs capture at least: start and end time, talk group, channel or network used, participating units, and any failover events. Entries are complete, consistent with observed controller behavior, and can be matched to the sequence of test actions. |
| P1-10 | Confirm that preconfigured talk groups are correctly honored by the controller (FR-2, FR-6). | Initialize the Communications Controller with a predefined set of talk groups and member assignments. Use simulated radios to request PTT sessions for valid and invalid group IDs, and to attempt to join groups where membership should or should not be allowed. | For valid combinations, the controller establishes sessions using the existing group definitions. For invalid group IDs or unauthorized membership, the controller rejects the request and records an appropriate error or denial event in its logs, without impacting existing sessions. |
Phase Two: Integration of User Interface Layer
In Phase 2, we are testing the extended multi-network and multi-unit coordination capabilities by integrating the Tower Base Stations, the Communications Controller, and their interactions with both radio and broadband paths. This phase adds the logic that manages repeater towers, RF repeaters, interoperability gateways, and routing across different communication paths while still using test harnesses in place of the full dispatch and user interfaces. As a result, we will be directly testing the following requirements from the original document: FR-2 creation and modification of talk groups and assignment of channels at the system level as reflected in how towers and controllers apply configuration updates, FR-3 automatic network switching in a more realistic environment that includes RF, LTE, WiFi, and P25 links with varying quality, FR-5 real time monitoring of units, groups, users, and relay towers with status such as online or offline state and channel usage, FR-6 support for multiple units and departments sharing information by joining the same communication group and exchanging messages in real time, FR-8 automatic switchover to backup communication paths when the primary path is degraded or fails, and FR-9 recording of call and alert events across towers and gateways for later investigation. We will also indirectly exercise FR-1 and FR-4, because normal PTT and emergency traffic will traverse this integrated network, but the primary focus will be on how the infrastructure routes, prioritizes, and monitors those flows. The tests in this phase will involve driving traffic through the Tower Base Stations and Communications Controller using multiple simulated radios and mobile app clients, inducing interference and failures on different links, verifying that status and usage information is correctly aggregated for monitoring, and confirming that routing and failover behavior match the expected group and channel configurations.
| Id | Test Case Objective | Test Case Description | Expected Results |
|---|---|---|---|
| P2-01 | Verify the configuration of the towers and controllers upon group and channel assignments (FR-2). | Through the test harness, assign several simulated endpoints (i.e. radios and apps) to one of two talk groups and assign appropriate channels. Move some, but not all, endpoints from one talk group to the other and update the channels as appropriate. | Controllers and towers shall update their configurations to reflect the changes as directed by the commands sent via the dispatch module. Two talk groups should exist with the expected participating endpoints; each with the expected channel. |
| P2-02 | Verify automatic network switching based on current availability and network stability. (FR-3, FR8) | Within a simulated or controlled network environment begin with a known number of endpoints, on each network type (RF, LTE, WiFi, P25); quality of each network should vary across test instances. The number of endpoints on each network should be a quantity where the network is not “stressed”. Gradually degrade the performance of a network type until its stability / bandwidth is affected. Multiple instances should be run with varying types of networks being degraded. | The controller should automatically switch the radios, sitting on the network(s) targeted by degradation, to an alternative network with more stability. Switched devices should distributed across the remaining networks based on real time network performance, ensuing one network type is not flooded and degraded. |
| P2-03 | Verify real time monitoring of units, talk groups, users, and relay towers’ statuses (FR-5) | The test harness shall have a known number of endpoints configured in the system. Endpoints should have varying states of connected and disconnected, utilize a mix of network types (LTE, WIFI, radio), and have varying known, signal conditions. | Values reported out by the real time monitoring system should be equivalent to the known values configured within the test harness. |
| P2-04 | Verify different organizations can join the same talk group (FR-6) | Multiple organizations should be configured within the testing environment, each with a varying number of devices connected across different network types. Each organization should join one of two talk groups. | When each device sends a communication, all devices within the talk group should receive the communication in real time, as established in NFR-4. Devices not in that talk group should not receive the communication. |
| P2-05 | Verify endpoints switch to a new network when the connected network fails. (FR-8) | Within the testing environment, connect several devices to each of the network types. Artificially invoke a network failure of on network type. This test case should be repeated for all network types. | All devices on the failed network should automatically switch to the remaining functional and/or backup networks. Abnormal conditions should be reported. |
| P2-06 | Confirm system logging. (FR-9, FR-1, FR4) | Within the test environment initiate several calls and alerts at known times from various radios | Confirm the logs reflect the appropriate time, channel, participating units, and users for each call and alert |
| P2-07 | Verify the emergency alerts preempt non-emergency communication. (FR-4) | With multiple devices connected to the system, across different network types, have one device transmit a non-emergency communication. During this transmission, trigger an emergency communication from a second device. | Confirm the emergency communication is prioritized above the non-emergency communication and that the command center and related units receive the emergency communication even across varying network types. |
Phase Three: Integration of User Interface Layer
In Phase 3, we are completing the integration of the system by connecting the user interface layer to the communication control and tower infrastructure assembled in the earlier phases. This phase incorporates the Dispatch consoles, the Mobile Application on iOS and Android, and the operational behavior of the Radio Firmware so that all architectural layers interact as designed. The goal in this phase is to confirm that user-initiated actions are correctly translated into control operations, that system state information is accurately delivered to the interface components, and that the end-to-end data flows between subsystems function as intended.
This third phase introduces the full set of user facing components, it exercises several functional requirements. Directly affected requirements include FR-1 Push to Talk as triggered through hardware or software PTT controls, FR-2 creation, modification, and deletion of talk groups through dispatch interfaces, FR-3 network switching as experienced by mobile and radio clients moving across WiFi, LTE, 5G, and P25 coverage, FR-4 emergency alert initiation and delivery, FR-5 system monitoring displays that report the status of units, groups, users, and towers, FR-6 communication among multiple agencies within shared talk groups, FR-7 authentication, login, and authorization workflows, and FR-9 access to recorded call and alert histories. This phase also touches FR-8 indirectly because backup path switching, while already tested at lower levels, must continue to propagate through the upper layers and appear correctly in the user facing components.
The testing performed here is still integration focused. The intent is to verify that the interface components interact properly with the underlying services, that the control flows are correctly propagated through the system, and that user level operations trigger the expected architectural responses. The scenarios used in this phase include logging in, selecting or joining groups, initiating communication sessions, triggering emergency alerts, issuing configuration changes from dispatch, and navigating monitoring and log views to ensure that all layers of the system exchange information correctly.
| Id | Test Case Objective | Test Case Description | Expected Results |
|---|---|---|---|
| P3-01 | Verify that authentication and authorization work across Dispatch, iOS, Android, and that authorized groups/permissions are correctly reflected in the UI. | Attempt login from, Dispatch console (Windows/Mac), iOS app, and Android app using valid credentials with different roles (commander, regular user, multi-agency user) and Invalid Invalid credentials (wrong password, unknown user, disabled accounts). After successful login, navigate to group selection / status screens. | Valid credentials succeed; invalid or disabled accounts are rejected with clear error messages (FR-7). Each platform shows the same authorized talk groups and functions for the same user (FR-7, NFR-7). Users without commander role cannot see or use group configuration features (FR-2 / authorization). No access to PTT, group lists, or monitoring screens before successful login. |
| P3-02 | Verify that pressing PTT on hardware radios and mobile apps sends a join/request to the control channel, establishes a voice path through towers and controller, and displays correct state on Dispatch. | Log in one user on a hardware radio, another on the mobile app, and one dispatcher. From the radio select a specific talk group. Press and hold hardware PTT, then speak. From the mobile app Select the same talk group. Press software PTT, then speak. Observe Dispatch console and other devices for audio and status. | Each PTT press triggers a join request on the control channel for the selected talk group (FR-1). Communications Controller assigns a channel; Tower Base Stations relay the transmission. All members of that talk group (radio, mobile, dispatch) hear the audio clearly and see “unit X transmitting” or equivalent indicator on UI (FR-1, FR-6). PTT release stops audio and updates UI back to idle; no audio leakage when PTT is not engaged. Call details (time, channel, participating units/users) are logged for later retrieval (FR-9). Measured setup time from PTT press to speech path establishment meets ≤ 50 ms target where measurable (NFR-2). |
| P3-03 | Ensure that talk group management done at Dispatch propagates correctly to radios and mobile apps and affects communication behavior. | From Dispatch UI, create a new talk group and assign a set of users using various devices. Then, modify the group by adding and removeing users, changing the assigned channel/frequency, and deleting the talk group. On devices refresh or navigate to group list and attempt to join and use PTT before and after each changes. | Newly created talk group appears on all relevant clients after synchronization (FR-2, FR-6, NFR-7). Only assigned users can join and transmit in that group; removed users are no longer allowed to join or transmit after modification (FR-2, FR-7). Channel/frequency updates are sent via Communications Controller to Tower Base Stations and down to radios; audio flows use the updated configuration. After deletion, group disappears from the UIs and devices cannot join or PTT to it. All configuration changes and affected units are logged (FR-9). |
| P3-04 | Verify that the mobile application automatically switches between Wi-Fi/LTE/5G/P25 to maintain connectivity while not actively transmitting. | Log a mobile user into the app and join a talk group. With no active call in progress, progressively Disable Wi-Fi. Degrade or disable LTE signal. Introduce a P25 or 5G path as alternative. Monitor network indicators in the app and Dispatch's view of the unit's connection status. | Mobile client detects loss/degradation of current network and automatically switches to the next available path (Wi-Fi → LTE → 5G or P25) without requiring re-login (FR-3). Dispatch monitoring view continues to show the unit as online, but with updated network/status information (FR-5). Any brief connectivity disturbances do not exceed acceptable interruption thresholds of 1.5s (NFR-8). No user data or logs are lost during switches. |
| P3-05 | Confirm that active PTT voice sessions can survive a network handoff with minimal interruption as the client moves between coverage types. | Log in a mobile user and a dispatch operator; join the same talk group. Start a PTT session from the mobile client. While transmitting force a switch from Wi-Fi to LTE/5G. Monitor audio at Dispatch and the other clients, and observe any status indicators. | Communications Controller and Tower/Base Stations detect the network change and reroute without dropping the session (FR-3, FR-8). Voice may briefly glitch, but total interruption does not exceed 1.5 s as per NFR-8. PTT session resumes and completes without requiring users to re-press PTT or re-join the group. Dispatch UI must not show the unit as offline during the brief handoff (FR-5). No user data or logs are lost during the switch. |
| P3-06 | Ensure that an emergency alert triggered at the field device overrides normal traffic, reaches Dispatch and relevant units immediately, and is correctly shown and logged. | Set up several ongoing normal PTT conversations across multiple talk groups useing radios and mobile apps. On one radio device, press the dedicated emergency button; on a separate run, trigger emergency from the mobile app. Observe audio channels at towers, controller, dispatch UI, and other devices in the same group. | Emergency button press causes radio/mobile firmware to override normal traffic and send emergency request on the control channel (FR-4). Towers and Controller prioritize the emergency, temporarily pre-empting non-emergency transmissions where needed (FR-4, FR-3). Dispatch console shows prominent emergency alert notification, including radio ID/user and location (FR-5). Other relevant units in the emergency talk group receive the emergency alert or broadcast immediately. All emergency events are logged with time, originating unit, group, and channel; they are flagged as emergency in the history (FR-9). |
| P3-07 | Verify that Dispatch monitoring screens show correct real-time status of units/talk groups/towers and reflect backup path switching when an abnormal condition occurs. | With multiple active units and towers, open Dispatch monitoring/overview screens. Introduce an abnormal condition such as a tower outage or severe RFI causing loss of a primary path or a back-haul link failure so that Controller must route via backup. Observe monitoring views and behavior of ongoing or new PTT calls. | Monitoring dashboard shows updated status for affected tower(s) (FR-5). System detects abnormal condition and automatically switches to configured backup communication path (FR-8). New and ongoing PTT calls are routed via backup without user intervention and remain functional. Dispatch UI reflects that calls are still active; impacted components are clearly indicated so operators can respond. Events are logged, including outage start time, backup activation, and restoration time (FR-9). |
| P3-08 | Confirm that users from different agencies/departments can share a talk group and communicate in real time, while other groups stay isolated. | Configure a shared talk group containing users from at least two agencies, each on different device types. Log in all users and join the shared talk group; also ensure each user has at least one private/agency-specific group. Pass a sequence of messages including PTT transmissions from each agency to the shared group and PTT transmissions to private agency-specific groups. | All users in the shared group can hear each other's transmissions in real time regardless of agency or device type (FR-6, NFR-7). Users in agency-specific groups do not receive shared-group traffic unless explicitly joined, and vice versa (isolation of groups). Dispatch can monitor and optionally join the shared group and agency-specific groups as configured (FR-2, FR-5). All shared group conversations are logged with participating units and agencies (FR-9). |
| P3-09 | Verify that recorded calls and alerts are stored and accessible through user-facing components with required metadata. | Generate a sequence of normal and emergency calls involving multiple groups, networks, and device types. From Dispatch console inspect the call/alert history or recording log view. | All generated calls and alerts appear in the history with at least: call ID, timestamp, channel, users/units, connection status, and emergency flag where applicable (FR-9, NFR-6). Results are consistent across Dispatch and mobile where features overlap (NFR-7). No missing or obviously corrupted records for calls executed during the test. |
| P3-10 | Validate that the system maintains required connection rates and latency under high concurrent load. | Simulate or provision at least 150 concurrent active voice connections across multiple towers with a mix of radio, iOS, and Android clients and multiple talk groups. From a subset of clients, repeatedly press PTT, start/stop short calls, and switch groups. Monitor successful/failed connection attempts, any voice delay from PTT press to audio, and dispatch UI responsiveness and status updates. | System sustains ≥ 150 simultaneous voice connections without functional degradation (NFR-3). At least 90% of connection attempts succeed even if some networks are degraded (NFR-1). Average voice delay between PTT press and audio at receiving clients remains less than 200 ms (NFR-4), and PTT setup time continues to meet ≤ 50 ms where measured (NFR-2). Dispatch monitoring screens remain responsive and accurately reflect unit/talk group status despite the load (FR-5). No UI crashes, unrecoverable errors, or mass call drops occur during the test. |
Validation Testing
Test Case Skeletons
A. Core Communication and Emergency Functions
| Test Case ID | Req ID(s) | Test Objective | Test Steps/Actions (Skeleton) |
|---|---|---|---|
| VTC-101 | FR-1, NFR-2 | Verify Push-to-Talk (PTT) initiation and connection speed. |
|
| VTC-102 | FR-4 | Verify Emergency Alert prioritization and delivery. |
|
| VTC-103 | FR-3, NFR-8 | Verify Automatic Network Switching robustness and voice interruption time. |
|
B. Administrative and Monitoring Functions
| Test Case ID | Req ID(s) | Test Objective | Test Steps/Actions (Skeleton) |
|---|---|---|---|
| VTC-201 | FR-2 | Verify Talk Group Management functionality. |
|
| VTC-202 | FR-5 | Verify Real-Time Monitoring display accuracy. |
|
| VTC-203 | FR-9, NFR-6 | Verify Call Record Storage and Retrieval. |
|
C. Security, Reliability, and Performance
| Test Case ID | Req ID(s) | Test Objective | Test Steps/Actions (Skeleton) |
|---|---|---|---|
| VTC-301 | FR-7 | Verify Strict Identity Authentication and prevent unauthorized access. |
|
| VTC-302 | FR-8, NFR-5 | Verify Abnormal Condition Reporting and Backup Path Switching. |
|
| VTC-303 | NFR-3, NFR-4 | Verify High Load Capacity (≥ 150 connections) and Latency (≤ 200 ms) under load. |
|
| VTC-304 | NFR-1 | Verify Connection Success Rate in adverse conditions. |
|
| VTC-305 | FR-6, NFR-7 | Verify Cross-Platform Interoperability and Multi-Agency Sharing. |
|
2.2 Validation Traceability Matrix
This matrix maps every project requirement to its corresponding validation test case skeleton, ensuring that every functional and non-functional requirement is covered.
| Req ID | Requirement Description (Brief) | Type | Priority | Test Case ID(s) | Test Case Description (Brief) |
|---|---|---|---|---|---|
| FR-1 | Support Push-to-Talk (PTT) function. | Functional | High | VTC-101 | Verify PTT initiation and talk group request. |
| FR-2 | Allow commanders to create, modify, and delete talk groups. | Functional | High | VTC-201 | Verify Talk Group Management by Administrator. |
| FR-3 | Automatically switch between available networks for uninterrupted communication. | Functional | High | VTC-103 | Verify auto-switching under signal degradation. |
| FR-4 | Support Emergency Alert function with message prioritization. | Functional | High | VTC-102 | Verify Emergency Alert prioritization and delivery. |
| FR-5 | Support real-time monitoring of units, groups, and towers. | Functional | High | VTC-202 | Verify real-time status display accuracy. |
| FR-6 | Support sharing information between multiple units/departments. | Functional | High | VTC-305 | Verify multi-agency, cross-platform communication. |
| FR-7 | Provide strict identity authentication. | Functional | High | VTC-301 | Verify successful login and unauthorized session rejection. |
| FR-8 | Report abnormal conditions and switch to a backup path. | Functional | High | VTC-302 | Verify failure detection and backup path switching. |
| FR-9 | Record call/alert time, channel, and participants. | Functional | High | VTC-203 | Verify event record creation and retrieval. |
| NFR-1 | ≥ 90% connection success rate in weak signals. | Non-Functional | Medium | VTC-304 | Verify connection success rate under adverse signal conditions. |
| NFR-2 | Voice connection within ≤ 50 ms after PTT. | Non-Functional | High | VTC-101 | Measure PTT connection establishment time. |
| NFR-3 | Handle ≥ 150 simultaneous voice connections. | Non-Functional | High | VTC-303 | Verify system stability and capacity under high load. |
| NFR-4 | Average communication delay < 200 ms under high load. | Non-Functional | High | VTC-303 | Measure communication latency during high load test. |
| NFR-5 | 99.99% availability; ≤ 5 minutes annual downtime. | Non-Functional | High | VTC-302 | Measure auto-recovery time during controlled failure. |
| NFR-6 | Store communication records for ≥ 1 year. | Non-Functional | Medium | VTC-203 | Verify record storage format (metadata included). |
| NFR-7 | Consistent functionality across multiple platforms. | Non-Functional | High | VTC-305 | Verify consistent PTT functionality across all platforms. |
| NFR-8 | Voice interruption ≤ 1.5 s during network switch. | Non-Functional | High | VTC-103 | Measure voice interruption time during auto-switching. |