Canmove, confirm
2,041
edits
Changes
Created page with "= Boot2Gecko API Permissions Test Plan = == Summary == {| class="fullwidth-table" |- | style="width:20%" | '''Leads''' | [mailto:gmealer@mozilla.com Geo Mealer] (irc: geo)<br..."
= Boot2Gecko API Permissions Test Plan =
== Summary ==
{| class="fullwidth-table"
|-
| style="width:20%" | '''Leads'''
| [mailto:gmealer@mozilla.com Geo Mealer] (irc: geo)<br />
[mailto:dchan@mozilla.com David Chan] (irc: dchan)<br />
[mailto:ptheriault@mozilla.com Paul Theriault] (irc: ptheriault)
|-
| '''Contributors'''
| TBD
|-
| '''References'''
| [https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Security/Security_model Firefox OS Security Model Overview]
|}
== Scope ==
This test plan covers Gecko permissions interaction from the point an app has installed into the permissions database downwards. It does not cover installation flow of the app itself, aside from verifying that the permissions manager properly reflects installed permissions.
== Strategy ==
The original testing methodology for this was a simple round trip: we would install an app with a given set of permissions, then check that the app behaved consistently with those permissions. However, we hit a number of problems where testing dependencies were either unstable or not fully implemented and would interfere with one of more legs of this multi-step process.
This test plan takes a more isolated approach to testing permissions interaction, so that AUT instability doesn't block the entire test approach. As such, it's split into three major sections: what permissions look like by default, whether a (non-default) permission setting is properly honored by the API, and whether installed apps properly set permissions in the manager.
These test suites will likely be implemented in Mochitest, with a possible dependency on mochitest-chrome for the third suite to allow completion of install flow.
== Suites ==
===Suite 1: Verify default permissions===
Given an app context, and without modifying its permissions, are the default permissions as expected?
'''Tracking Bug'''
* TBD
'''Methodology'''
# Install or host an app with a context of either content, hosted, installed, or certified.
# Don't include a custom manifest or otherwise modify the permissions table.
# Query permissions manager directly for app and check against expected values.
'''Dependencies'''
* Install flow
* Permissions manager
===Suite 2: Verify API behavior===
Given permissions in the database, does API allow/deny/prompt as expected?
'''Tracking Bug'''
* TBD
'''Methodology'''
# Start from the context with lowest permissions (content, probably).
# Add permissions directly via SpecialPowers
# Test API allows/denies/prompts correctly.
'''Dependencies'''
* Individual APIs
* Permissions Manager
===Suite 3: Permissions Database Population===
Given an app context and manifest, does the permissions database populate correctly?
'''Tracking Bug'''
* TBD
'''Methodology'''
# Install (or host) application with customized manifest
# Query permissions database directly for app and check against expected values.
'''Dependencies'''
* Installation flow
* Permissions Manager
== Summary ==
{| class="fullwidth-table"
|-
| style="width:20%" | '''Leads'''
| [mailto:gmealer@mozilla.com Geo Mealer] (irc: geo)<br />
[mailto:dchan@mozilla.com David Chan] (irc: dchan)<br />
[mailto:ptheriault@mozilla.com Paul Theriault] (irc: ptheriault)
|-
| '''Contributors'''
| TBD
|-
| '''References'''
| [https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Security/Security_model Firefox OS Security Model Overview]
|}
== Scope ==
This test plan covers Gecko permissions interaction from the point an app has installed into the permissions database downwards. It does not cover installation flow of the app itself, aside from verifying that the permissions manager properly reflects installed permissions.
== Strategy ==
The original testing methodology for this was a simple round trip: we would install an app with a given set of permissions, then check that the app behaved consistently with those permissions. However, we hit a number of problems where testing dependencies were either unstable or not fully implemented and would interfere with one of more legs of this multi-step process.
This test plan takes a more isolated approach to testing permissions interaction, so that AUT instability doesn't block the entire test approach. As such, it's split into three major sections: what permissions look like by default, whether a (non-default) permission setting is properly honored by the API, and whether installed apps properly set permissions in the manager.
These test suites will likely be implemented in Mochitest, with a possible dependency on mochitest-chrome for the third suite to allow completion of install flow.
== Suites ==
===Suite 1: Verify default permissions===
Given an app context, and without modifying its permissions, are the default permissions as expected?
'''Tracking Bug'''
* TBD
'''Methodology'''
# Install or host an app with a context of either content, hosted, installed, or certified.
# Don't include a custom manifest or otherwise modify the permissions table.
# Query permissions manager directly for app and check against expected values.
'''Dependencies'''
* Install flow
* Permissions manager
===Suite 2: Verify API behavior===
Given permissions in the database, does API allow/deny/prompt as expected?
'''Tracking Bug'''
* TBD
'''Methodology'''
# Start from the context with lowest permissions (content, probably).
# Add permissions directly via SpecialPowers
# Test API allows/denies/prompts correctly.
'''Dependencies'''
* Individual APIs
* Permissions Manager
===Suite 3: Permissions Database Population===
Given an app context and manifest, does the permissions database populate correctly?
'''Tracking Bug'''
* TBD
'''Methodology'''
# Install (or host) application with customized manifest
# Query permissions database directly for app and check against expected values.
'''Dependencies'''
* Installation flow
* Permissions Manager
