Comprehensive Mobile Testing Plan for the Cloud Classroom Application

Background

As the Cloud Classroom feature set expands and services are optimized, the testing scope also grows, focusing on teacher‑student interactions within the classroom. Mobile users are primarily students, with some devices serving as teacher handwriting tablets.

Because mobile devices are diverse and used in complex scenarios, dedicated testing is required to uncover and resolve software issues early.

1. Security Testing

Goal: Identify security risks.

1. Software Permissions

Privacy leakage risks include access to phone information, internet connectivity, camera/microphone usage, reading and writing user data.

Validate input correctness, authentication, authorization, sensitive data storage, and encryption.

Security team found a login interface vulnerability: user ID parameters (uid) are sequential and can be enumerated, allowing data theft.

Solution: Use server‑side token validation and avoid processing raw user ID parameters; clients should send tokens.

Data reporting in Cloud Classroom

User behavior logs record operations performed in the classroom.

User playback logs record actions during video replay.

Data leakage and unauthorized access risks are addressed by enabling static code checks.

Dynamic code detection tools monitor anomalies and retain logs during testing.

2. Installation, Uninstallation, and Upgrade Security

Verify resource usage during app install/uninstall and upgrade, and ensure data consistency across upgrades.

3. Data Security

Passwords and sensitive data are never stored on the device nor displayed in plain text; ID/password length must be 4‑8 digits; users can cancel data deletion; write operations to important data must notify users.

4. Communication Security

During calls, SMS, Bluetooth, NFC, etc., the app should pause and resume correctly; network errors and delays must be reported to users.

5. Human‑Machine Interface Security

Menus remain accessible, command priority is enforced, device settings (volume, brightness, eye‑mode) do not affect app functionality, and the app handles unexpected user actions gracefully.

Android testing can use the Monkey tool:

adb shell monkey -p 包名 -v 1000

2. Static Code Inspection

Static analysis examines source code without execution, while dynamic analysis monitors runtime behavior.

1. OCLint

OCLint analyzes C, C++, Objective‑C for bugs such as empty condition statements, unused code, high cyclomatic complexity, redundant conditions, long methods, and bad coding habits.

Running OCLint

xcodebuild -workspace RoomBox.xcworkspace -scheme RoomBox -configuration Debug | xcpretty -r json-compilation-database -o compile_commands.json

xcpretty converts the Xcode log to a JSON compilation database, which OCLint then processes.

Report generated:

oclint_result.html

2. Infer

Facebook’s open‑source static analyzer, written in OCaml, supports Java, C, and Objective‑C using separation logic and bi‑abduction.

Infer command

infer --keep‑going --no‑xcpretty -xcodebuild -workspace RoomBox.xcworkspace -scheme RoomBox -configuration Debug -sdk iphonesimulator

Analyzing Results

Results are stored in an infer‑out folder containing bugs.txt and report.json.

Use

infer reportdiff --report‑current infer‑out/report.json --report‑previous report.json

to compare scans, producing introduced.json, fixed.json, etc.

3. SonarQube

SonarQube is an open‑source platform for managing code quality across many languages.

Docker Setup

docker run --name sq —link postgresqldb -e SONARQUBE_JDBC_URL=jdbc:postgresql://db:5432/sonar -p 9000:9000 -d sonarqube

Access at http://localhost:9000/ (default admin/admin).

Running Sonar Scanner

Edit sonar-project.properties and sonar-scanner.properties in the project root, then execute sonar‑runner.

3. Performance Testing

Evaluate time and space characteristics of the Cloud Classroom.

1. Stress Testing

Maximum concurrent users: 12 in multi‑video class (14 video streams) and 6 in small class (8 streams). Test chat, beauty‑filter FPS, and data reporting stability.

2. Performance Evaluation

Data points logged every two seconds.

Third‑party SDK data monitoring.

Test data archiving.

3. Competitive Benchmark Testing

Compared against ClassIn, Xueersi, Yuanfudao, Zuoyebang, Gaotu, etc., focusing on functionality, usability, security, performance, and compatibility.

4. Compatibility Testing

Ensuring the app works across diverse devices, OS versions, network conditions, and SDK integrations to reduce user churn.

1. Device, OS, Screen, Refresh Rate

Android Top 300, iOS Top 100 devices.

2. Network Compatibility

Test on 3G, 4G, 5G, Wi‑Fi, and combined 5G‑WiFi scenarios.

3. Version Compatibility

4. SDK Compatibility

Third‑party SDKs: Agora, LeBo, XiangXin, TingYun; plus the in‑house RTC‑SDK.

1. Cloud Classroom ↔ Third‑party SDK compatibility

2. Inter‑SDK compatibility

Agora with XiangXin, Agora with TingYun

In‑house RTC‑SDK with all third‑party SDKs

Conclusion

Targeted testing broadened QA perspectives, uncovered numerous issues, and ensured stable functionality of the Cloud Classroom. Current App Store rating: 4.6, ranking 305 in education category; the client is generally stable with mostly positive feedback.