A Multi‑Layer Approach to Mobile Device Compatibility Test Design and Device Selection

Background – Compatibility testing is essential for terminal‑related testing, but the sheer variety of device models makes exhaustive coverage impractical.

First Layer of Thinking – Impact of Device Parameters – Key hardware specs such as CPU, memory, screen type, resolution, refresh rate, and manufacturer ROM directly affect app functionality and performance. For example, screen type influences UI layout, CPU and memory affect animation rendering, and ROM variations cause many compatibility bugs.

Second Layer – Market and Technical Insights – Beyond raw specs, testers should consider manufacturer roadmaps, flagship models, concept devices, and new releases. These sources help identify “water‑shed” models (e.g., iPhone X, Huawei foldable) and flagship devices that represent a large user base.

Third Layer – Market Share Considerations – Prioritize devices with high market share, high app‑specific usage, high bug incidence, and strong user feedback. Data can be gathered from Android Studio, internal usage statistics, bug databases, and feedback channels.

Fourth Layer – Performance Tier Classification – Classify devices into high, medium, and low tiers based on CPU and memory. High‑end devices match current flagship specs, mid‑range devices align with slightly older flagship configurations, and low‑end devices are identified by price (< ¥1000) or older chipset families (e.g., Qualcomm 6xx, MediaTek 7xx).

Fifth Layer – Special‑Case Devices – Account for unconventional devices such as foldable phones, custom ROMs, and OS versions that introduce unique compatibility challenges (e.g., iOS 14 vs. iOS 15 differences).

Sixth Layer – Scenario‑Driven Testing – Align test focus with the core feature of the scenario (e.g., animation, UI interaction). Combine functional impact with device parameters to select the most relevant device groups.

Design Idea – Build a system that links test scenarios to influential device parameters and maintains a comprehensive device‑parameter database. The algorithm groups devices with identical key parameters, ranks them by market share, and flags high‑risk devices based on bug frequency.

Implementation Algorithm Flow

1. Data Collection: Gather device specs, app usage share, and bug‑prone device lists into a database.

2. Data Maintenance: Continuously update device information and market‑share rankings.

3. Scenario Maintenance: Manually add new test scenarios as requirements evolve.

4. Recommendation Algorithm:

• Step 1: Identify the selected scenario and retrieve high‑weight device parameters.

• Step 2: Match these parameters against the device database, forming equivalence classes of devices with the same parameter set.

• Step 3: Prioritize devices from dominant manufacturers (Huawei, Xiaomi, Oppo, Vivo) within each class.

• Step 4: Highlight devices that have generated the most bugs for the scenario as high‑risk.

• Step 5: Display grouped devices, naming each group by its combined parameter values.

Algorithm Detail Example – For a scenario A, parameters b and c are critical. All devices sharing both b and c are grouped together, named after the combination (e.g., “Notch‑Screen + 1080p”). Resolution is abstracted to categories (720p, 1080p, 2K) to avoid over‑granular splits.

By following this structured, multi‑layer methodology, testers can efficiently select representative devices, reduce redundant testing, and improve coverage of compatibility bugs.