QA/Mobile/TelemetryTestPlan: Difference between revisions
Rpappalardo (talk | contribs) m (data integrity) |
Rpappalardo (talk | contribs) m (format) |
||
Line 58: | Line 58: | ||
== Ping Scenarios == | == Ping Scenarios == | ||
=== Summary === | === Summary === | ||
A "ping" refers to a JSON blob | A "ping" refers to a JSON data blob sent from the client to the telemetry service. There are three basic types (scenarios): | ||
# [https://github.com/mozilla-mobile/android-components/blob/master/components/service/glean/docs/pings/baseline.md baseline ping] | # [https://github.com/mozilla-mobile/android-components/blob/master/components/service/glean/docs/pings/baseline.md baseline ping] | ||
# [https://github.com/mozilla-mobile/android-components/blob/master/components/service/glean/docs/pings/events.md events ping] | # [https://github.com/mozilla-mobile/android-components/blob/master/components/service/glean/docs/pings/events.md events ping] | ||
# [https://github.com/mozilla-mobile/android-components/blob/master/components/service/glean/docs/pings/metrics.md metrics pings] | # [https://github.com/mozilla-mobile/android-components/blob/master/components/service/glean/docs/pings/metrics.md metrics pings] | ||
In addition, [https://github.com/mozilla-mobile/android-components/blob/master/components/service/glean/docs/pings/custom.md custom pings] (i.e. activation, sync pings) can be defined using the [https://github.com/mozilla-mobile/fenix/blob/master/app/pings.yaml pings.yaml] and [https://github.com/mozilla-mobile/fenix/blob/master/app/metrics.yaml metrics.yaml] files. Test cases should be designed around these various "ping scenarios." | In addition, [https://github.com/mozilla-mobile/android-components/blob/master/components/service/glean/docs/pings/custom.md custom pings] (i.e. activation, sync pings) can also be defined using the [https://github.com/mozilla-mobile/fenix/blob/master/app/pings.yaml pings.yaml] and [https://github.com/mozilla-mobile/fenix/blob/master/app/metrics.yaml metrics.yaml] files. Test cases should be designed around these various "ping scenarios." | ||
This wiki will explain how to test each of these scenarios. | This wiki will explain how to test each of these scenarios. |
Revision as of 17:31, 9 May 2019
Summary
Product Coverage
This is the test plan for verification of telemetry service clients for the following Mozilla Android products:
Fenix
Frequency:
- thorough first pass and on releases, spot check w/ sprints (to be verified w/ kbrosnan)
Issues:
Reference Browser
Frequency:
- upon request from dev, management
android-components - sample apps
Frequency:
- upon request from dev, management
Firefox for FireTV
Frequency:
- TBD - pending Glean implementation
Test Demo
This demo video illustrates the basic steps for test setup and execution. This is not intended to illustrate a real test case. Additionally, you will want to monitor all local activity using logcat on Android Studio.
In this demo, you can observe:
- Telemetry being sent from client to the server
- Telemetry arrives at the server without excessive latency (can be viewed from the Glean Debug Dashboard)
- Telemetry is complete and data integrity maintained
NOTES:
- For ease of demonstration, an X86 device was used, but all testing should be done using physical devices.
- Test steps in video are outlined in wiki below
Test Strategy
Test Types
The Mobile QA team will perform two test types of telemetry verification for all our mobile projects:
- End-to-end (client-to-server) manual tests
- Client-side only verification automated tests (TBD)
This wiki outlines a test plan for manual testing.
Manual Tests
Frequency:
- upon request from devs, management
Who:
- SoftVision engineers
Tools:
- Glean CLI, Glean Debug Dashboard
Automated Tests
Frequency:
- github trigger on merge-to-master
Who:
- No-Jun's team
Tools:
- see discussion: discussion
Ping Scenarios
Summary
A "ping" refers to a JSON data blob sent from the client to the telemetry service. There are three basic types (scenarios):
In addition, custom pings (i.e. activation, sync pings) can also be defined using the pings.yaml and metrics.yaml files. Test cases should be designed around these various "ping scenarios."
This wiki will explain how to test each of these scenarios.
Ping Activities
Summary
Testing ping integrity from end-to-end can be broken down into three high-level steps:
- Data Collection
- Ping data is collected on the client (and stored locally on disk) when certain specific actions are performed.
- Our test coverage must ensure we trigger data collection for each of the ping scenarios by performing those actions in the proper sequence.
- Generated data will first be verified locally via logcat
- Data Submission
- Using the Glean CLI tool, we'll force data to be submitted to the telemetry server immediately, rather than waiting for a scheduled trigger event(s) or for thresholds to be met, etc.
- Data Integrity
- Using the Glean Debug Dashboard, we must verify that the ping data we've tagged and forced to be submitted (using the Glean CLI tool), arrives without undue latency (within approx. 10-20 seconds).
- Drill down on the JSON data and verify the correct data has been submitted.
Test Execution
Summary
This will be a "client-to-server (end-2-end) verification" test using the production telemetry service across the real network (not a mock service on localhost). Execution requires manually triggering a telemetry ping to be sent to the telemetry service by emulating a specific set of user activities in the application.
Pings can be successfully verified by ensuring they have arrived in the telemetry server - viewable in the Glean Debug Dashboard.
- Authentication requires SSO login
- see: Debugging products using Glean
- Features
- Glean Debug Dashboard makes data received by the pipeline from some devices visible in real-time
- Enabling debug mode either returns a unique identifier, or the ID you want to use (see tagPings parameter below), enabling immediate query of test pings
Setup
Download Application
- Download the Fenix (or other) release apk file
- choose: public/target.x86.apk or public/target.aarch64.apk
NOTE:
- Debug builds won't work, but test build can otherwise be custom build or from PlayStore (no special build needed)
Install Application
- Connect an Android (physical) device via USB
- Open terminal
- Verify device is connected:
$ adb devices
- Install the apk:
$ adb install ~/Downloads/target.aarch64.apk
- Verify app has been installed on device
- NOTE: Do not open the application, Glean will do this for us
Check Network
- ping Glean Debug Dashboard: [1]
Data Collection
Next, we will do three things (see "Examples" below):
- Tag our telemetry pings with a custom identifier
- Trigger ping generation on client
Data Submission
Once we have performed the above steps to locally collect data for the desired scenario, we will need to force it to be submitted immediately. By default, data is only submitted at scheduled times or when certain data thresholds are reached. We don't want to wait!
Perform the following steps to force immediate data submission for ALL scenarios:
- Close and uninstall any previous instances of app-under-test
- Re-install a fresh instance of app on device
- Launch app with Glean CLI command (not manually)
- Move app to the background (this should immediately trigger send)
Data Integrity
Now let's verify that data has arrived to telemetry service intact.
see: [# Verify JSON data per pings doc
Open Ping
- Open Glean Debug Dashboard: [2]
- Verify real-time receipt of tagged ping in dashboard
- Verify ping entry contains correct field data
- Drill down into ping
- Verify that "Recent pings..." entry contains correct ping types
- Drill down to JSON data
Verify Common Info
- Verify data in all fields per common fields doc
- NOTE: if common info is good on baseline ping, SHOULD BE good on others - no need to repeat for other ping scenarios! (All use same path of execution)
Verify Baseline Info
Verify the following fields:
- common fields info
- duration
- should roughly approximate difference between start_time, end_time
- Verify locale string
Verify Events Info
Verify the following fields:
Verify events that were performed have arrived in Dashboard
Verify Metrics Info
Verify the following fields:
- common fields info
- default browser
Review fields in metrics.yaml
Verify Custom Info
[Reference]
Test Tools
Summary
You will need the following tools to execute end-to-end telemetry tests:
- Android physical device
- Testing can be done on an x86 device but is less reliable
- Glean currently broken on x86: issue/2291
- Browser
- Test plan (this page)
- Taskcluster APK download page
- Glean Debug Dashboard
- to verify server-side activity
- Terminal
- You will run all your ADB, Glean commands from here
- Logcat
- Open Android Studio to monitor all client-side activity
Glean CLI
Below is a brief summary of the Glean CLI features documented here: Debugging products using Glean
logPings
- To dump Glean logs to logcat
adb shell -n ...GleanDebugActivity --ez logPings true
sendPing
- To force sending a ping immediately use:
adb shell -n ...GleanDebugActivity --es sendPing metrics
- (or instead of metrics other ping names)
- Look at Glean frontend to verify data is landing
tagPings
- To tag a ping with a user label for easy query in Glean Debug dashboard
adb shell -n ...GleanDebugActivity --es tagPings rpapa-test1
, then spotrpapa-test1
in the frontend to identify your pings.
Examples
For running the commands with any Firefox Android app, adjust the application ID part in the command:
Fenix
adb shell -n org.mozilla.fenix/mozilla.components.service.glean.debug.GleanDebugActivity --ez logPings true --es sendPing baseline --es tagPings rpapa-test1
Android Components (sample apps)
adb shell -n org.mozilla.samples.glean/mozilla.components.service.glean.debug.GleanDebugActivity --ez logPings true --es sendPing baseline --es tagPings rpapa-test1
Reference Browser
adb shell -n org.mozilla.reference.browser.debug/mozilla.components.service.glean.debug.GleanDebugActivity --ez logPings true --es sendPing baseline --es tagPings rpapa-test1
- NOTES
- even with telemetry enabled, reference-browser doesn't define any metric outside of the ones we provide out of the box, which are sent in the baseline ping.
- suggestion: run commands against a version of reference-browser that has telemetry enabled (e.g. the one from the play store), and send a ping for which we're sure to have data:
- NOTES
Reference
Automated Tests (Firefox Desktop)
DESCRIPTION
- Automated tests for Firefox desktop do "client verification only test" also rely on a local HTTP client as a kind of simple mock telemetry server, used to capture, read and verify the outbound JSON payload locally
- Events are triggered, data integrity is verified
- see source: mozilla-central