QA/Automation/Projects/Mozmill Automation/On Demand Test Framework: Difference between revisions

Jump to navigation Jump to search
m
 
(39 intermediate revisions by 3 users not shown)
Line 1: Line 1:
==Overview==
==Overview==
TBD
(need to expand this, this is not at all final wording)
 
The On-Demand Test Framework will be a full-service execution framework for Mozmill and perhaps eventually other tests. It will allow execution of tests across a grid of machines. Eventually, it will include auto-provisioning that grid and features to allow more granular parallel execution.


{| style="width: 90%; margin: 0 0 1em 1em" |
{| style="width: 90%; margin: 0 0 1em 1em" |
Line 10: Line 12:
  |- valign="top"
  |- valign="top"
  | '''Leads:'''
  | '''Leads:'''
  | [mailto:gmealer@mozilla.com Geo Mealer], [mailto:hskupin@mozilla.com Henrik Skupin]
  | [mailto:gmealer@mozilla.com Geo Mealer], [mailto:dhunt@mozilla.com Dave Hunt]
  |- valign="top"
  |- valign="top"
  | '''Contributors:'''
  | '''Contributors:'''
  | TBD
  | TBD
  |- valign="top"
  |- valign="top"
  | '''Tracker:'''
  | '''Pivotal:'''
  | TBD
  | https://www.pivotaltracker.com/projects/404111
  |- valign="top"
  |- valign="top"
  | '''QA Tracking Page:'''
  | '''Bugzilla:'''
  | TBD
  | https://bugzilla.mozilla.org/show_bug.cgi?id=698654
  |- valign="top"
  |- valign="top"
  | '''Etherpad:'''
  | '''Other Docs:'''
  | TBD
  | [[/Docs|Index]]
|}
|}


==Goals for Q4/11==
==Goal History==
TBD
 
{| class="fullwidth-table" |
{| class="fullwidth-table" |
  | style="background:#EFEFEF; width: 15%" | Status
  | style="background:#EFEFEF; width: 20%" | '''Period'''
  | style="background:#EFEFEF; width: 25%" | Task
  | style="background:#EFEFEF; width: 20%" | '''Status'''
  | style="background:#EFEFEF; width: 60%" | Description
  | style="background:#EFEFEF; width: 60%" | '''Goal'''
  |- valign="top"
  |- valign="top"
  | Not started
  | 2011 Q4
  | Subgoal 1
  | {{ok|}}
| Description
  | Implementation of a remote mechanism to trigger Mozmill functional and update tests for Firefox releases
|- valign="top"
| Not Started
| Subgoal 2
  | Description
|}
|}
==Requirements==
* We want to be able to kick off test runs with as little interaction and micromanaging as we can.
* A test run equates to a script with one or more parameters, which will be run on one or more environments. These parameters correspond mostly to the test matrix, and will vary per run type.
* The test run is capable of, within a given environment, doing everything from app deployment to testing to app cleanup. Or we can split these up if more convenient.
* We'll want the system to spread testing among a number of available machines per environment, and ultimately create the machines as needed.
* Ultimately, we'd like the ability to slice the test run on a parameter value to run in parallel. If we can get it, understanding how to slice the test run per-test would be even better.
* We'd like to clearly monitor run progress, and watchdog for hung machines.
* We'd like to see understandable test results, preferably consolidated across a whole run (at least per-env, if not cross-env).


==Project Milestones==
==Project Milestones==
TBD
{| class="fullwidth-table" |
{| class="fullwidth-table" |
  | style="background:#EFEFEF; width: 15%" | Status
  | style="background:#EFEFEF; width: 20%" | '''Milestone'''
  | style="background:#EFEFEF; width: 25%" | Milestone
  | style="background:#EFEFEF; width: 20%" | '''Status'''
  | style="background:#EFEFEF; width: 60%" | Description
  | style="background:#EFEFEF; width: 60%" | '''Description'''
|- valign="top"
| Basic Execution
| Design Stage
{{ok|}}
| System allows execution of test-run demands against standing machines.
|- valign="top"
| Auto-Provisioning
| Not started
| System automatically provisions and/or resets virtual machines
  |- valign="top"
  |- valign="top"
| Parallelism
  | Not started
  | Not started
  | Milestone 1
  | System knows how to slice up a test run more finely than per-platform
| Description
|- valign="top"
| Not Started
| Milestone 2
| Description
|}
|}


==Modules/Interfaces==
==Architecture==
[[Image:On_Demand_Arch.png|On-Demand Test Framework Architecture]]
[[Image:On_Demand_Arch.png|On-Demand Test Framework Architecture]]


The Trigger and Config Generator components are a proposed part of integrating the CI goal into this system by automatically generating a Demand, and will not be covered in this project.
The Trigger and Config Generator components are a proposed part of integrating the CI goal into this system by automatically generating a Demand, and will not be covered in this project.


{| class="fullwidth-table" |
{| class="fullwidth-table" |
  | style="background:#EFEFEF; width: 25%" | Component
  | style="background:#EFEFEF; width: 25%" | '''Component'''
  | style="background:#EFEFEF; width: 55%" | Description
  | style="background:#EFEFEF; width: 75%" | '''Description'''
  |- valign="top"
  |- valign="top"
  | [[/Demand|Demand]]  
  | [[/Demand|Demand]]  
Line 78: Line 88:
  |- valign="top"
  |- valign="top"
  | [[/Executor|Executor]]  
  | [[/Executor|Executor]]  
  | Kicks off and centrally controls the test run
  | Kicks off and centrally monitors the test run
  |- valign="top"
  |- valign="top"
  | [[/Provisioner|Provisioner]]  
  | [[/Provisioner|Provisioner]]  
  | Locates or creates an appropriate machine for execution
  | Initializes appropriate machines for execution
  |- valign="top"
  |- valign="top"
  | [[/Machine|Machine]]  
  | [[/Machine|Machine]]  
  | Agent on target machines for remote execution
  | Environment on target machines for remote execution
|}
|}
If an off-the-shelf CI tool like Jenkins turns out be appropriate for our needs, it may subsume the Dashboard and Executor components.
The question of which module controls/watchdogs the individual Test Machines performing the run has not been answered yet. Further analysis will show whether that's better as part of the Executor, Provisioner, whether the machine can run relatively autonomously once it's been initialized, or whether a new component is needed.


In addition to these, Status formats must be defined where they exist in the architecture. It is unknown yet as to which module will define these, or whether they will be significant enough to require subprojects.
In addition to these, Status formats must be defined where they exist in the architecture. It is unknown yet as to which module will define these, or whether they will be significant enough to require subprojects.


==Resources==
==Resources==
* [[/CI Documentation|Continuous Integration Details]]
* [[/Public|Public Posts and Discussions]]
* [[/Public|Public Posts and Discussions]]
* [[/Presentations|Presentations]]
* [[/Presentations|Presentations]]
* [[/FAQ|FAQ]]
* [[/FAQ|FAQ]]
* [[/Contribution|How to Contribute]]
* [[/Contribution|How to Contribute]]
canmove, Confirmed users, Bureaucrats and Sysops emeriti
4,747

edits

Navigation menu