MTBF tests

Mean time between failures (MTBF) is the predicted elapsed time between inherent failures of a system during operation. MTBF can be calculated as the arithmetic mean (average) time between failures of a system. The MTBF is typically part of a model that assumes the failed system is immediately repaired (mean time to repair, or MTTR), as a part of a renewal process. This is in contrast to the mean time to failure (MTTF), which measures average time to failures with the modeling assumption that the failed system is not repaired (infinite repair time).

Current Environment & Setup

MTBF tests are run by automation; the test suite collects general test cases like send sms, email, set alarm, etc., and executes them to emulate typical user behavior.  Right now we have more than 10 Firefox OS phones concurrently running tests in our test lab.

How often are the tests run?

MTBF is purposed to test on versions or branches with 0 functional failures.  it runs when everything passes in our smoke tests; the testing code should be in the Aurora (next release) branch.

Where can I see the results?

MTBF is still being developed and you can mail us for an early report (try the dev-b2g or dev-gaia mailing lists).  You can set up the necessary environment to run the tests yourself and generate your own reports by following the below steps.

Running the tests

Let's go through the steps required to set up the Gaia-UI MTBF test environment and run the tests on your local machine and Firefox OS device.

Prerequisites

• Ubuntu 12.04 (or better) x64 or Mac OS X (these instructions are confirmed for 10.8 but should work on previous versions of 10, theoretically.)
• A Firefox OS device ALREADY FLASHED with an ENGINEERING build of Firefox OS B2G-18 V1-Train (1.1.)
• ADB installed, and the environment variable ADB_PATH pointing to your ADB location.

If you are on Ubuntu, you need to check that it is configured to support the USB connection to the Firefox OS device. To verify this, connect the device to your computer via USB, open a terminal and enter the adb logcat command to see if it connects. If not, you may need to set up a udev rule for the device.

Step 1: Clone the MTBF-Driver repository from Mozilla-TWQA

The Gaia-UI MTBF Tests are located in the Mozilla Github Gaia repository. Assuming that you haven’t done so already, the first step is to clone that repo:

git clone https://github.com/Mozilla-TWQA/MTBF-Driver.git

You may want to go get a coffee and come back in five minutes. Furthermore, you can get all the branches and try to switch to the current MTBF branch (e.g. master or v1.4+.) In this case, master matches the current master branch Gaia, and v1.4+ matches the v1.4/v1.3 branch Gaia.

Step 2: Run the GaiaTest setup

The Gaia-UI MTBF tests are built upon the GaiaTest framework (which uses Marionette). The next step is to run the setup script to install GaiaTest and all of the required dependencies. You may wish to create a new virtual environment to use with the Gaia-UI MTBF Tests. If you don’t, you may need to use sudo while running the setup command. In your terminal, type:

cd MTBF-Driver
python setup.py develop

Step 3: Get memory tools if you need them

To access the memory tools, find them in the tools directory in the B2G repo. If you've not already got this, clone it from Github like so (this is also a large download):

git clone https://github.com/mozilla-b2g/B2G.git

You should copy the tools folder into the MTBF-Driver/mtbf_drivers directory.

Step 4: Set test vars and acknowledge risks

GaiaTest uses a special file to set certain variables that are required for test configuration, for example to tell the device which WiFi network it should use. Before running the Gaia-UI MTBF Tests, you must set up the test vars file. Make a copy of the gaia/tests/python/gaia-ui-tests/gaiatest/testvars_template.json file in its existing location (rename it to something memorable) and edit it:

• If the Firefox OS device has a SIM card, add the corresponding phone number in the phone number field in the carrier section, e.g. "phone_number": "5551234567".
• Add the same phone number inside the "remote_phone_number" field.
• In the wifi section, add the SSID for the Wifi network that the Firefox OS device is to connect to during the tests in the ssid field, for example "ssid": "Wifi Network Name".

Running the Gaia-UI MTBF tests will result in data being erased from the Firefox OS device and microSD card. This is to ensure that the tests start cleanly each time. For example, running a contacts test on a device that already has 10,000 contacts will have very different memory value results compared to running the same test on a device with no existing contacts. In order to run the tests, you must acknowledge that you are aware of this data loss risk. You should also backup any data you don't want to lose.

To acknowledge the risks, add the following entry to your testvars file as the first field in the list: "acknowledged_risks": true.

Step 5: Connect to USB and ADB Forward the Device

Attach the Firefox OS device to your computer via USB.

Now tell adb to forward the device port to GaiaTest using the following command:

adb forward tcp:2828 tcp:2828

adb root
adb forward tcp:2828 tcp:2828

Step 6: Run a Test

Now you’re ready to actually try running a test. Use the following commands:

cd {MTBF Driver Folder}
MTBF_TIME=1d MTBF_CONF=conf/local.json mtbf --address=localhost:2828 --testvars=mytestvars.json

We can parse the MTBF_TIME by d(ay), h(our), or m(inute).

If you get a “connection refused” error it means the device USB connection didn’t work; just repeat the device connection and try again.

The Firefox OS device b2g process should now restart, then the specified test will run with a single iteration. If you watch the Firefox OS device, you’ll see the device UI being manipulated by Marionette. After the test finishes, a memory checkpoint will be performed.

The test result will be displayed in the terminal window. Note that this result doesn’t include the b2g process memory value; this value is stored in a text file, created at the time of the checkpoint in the checkpoints directory. To see the resulting b2g process, open this file. This "suite_summary" file will contain the average b2g process memory use (RSS) value, averaged from all the test checkpoints (in our example there was only one checkpoint.)

There are two other files present in the checkpoints folder (assuming the test run was the "add contact" test):

• The checkpoint_add_contact_(datetime)_summary.log file contains a summary for the test run. This includes the number of iterations, all of the RSS value readings from each checkpoint, the average RSS value, etc.
• The checkpoint_add_contact_(datetime).log file contains the raw data received from each of the device checkpoints, from which the summary files were produced.

Step 7: Using Variables and Config Files

We use envrionment variable MTBF_TIME for running duration.  The other one is MTBF_CONF which refers to json file, specific runner options include test case repository and list.  A normal config file should look like 

{
  "memory_report": false,
  "logcat": true,
  "overall_status": true,
  "b2g_status": true,
  "get_event": true,
  "rootdir": "tests/mtbf",
  "workspace": "/tmp/workspace",
  "manifest_prefix": "mtbf",
  "archive": "output",
  "runlist": "runlist/all.list",
  "level": 4
}

• memory_report, locat, overall_status, b2g_status and get event help: options for collecting debug information.
• rootdir: root of test case repository for searching and matching in runlist.
• workspace: running materials will be stored here for replay.
• manifest_prefix: currently not available.
• archive: specifying folder for storing report and debug information
• runlist: json file by a list of test case file path.  Test cases will be randomly picked and put into running queue.
• level: specify how often a dummy case (to simulator user not focusing) should be triggered. level 0 is no test will be run, where level 5 means no dummy test enqueued.

Contributing to the project

If you have any questions about the Firefox OS MTBF tests or are interested in contributing to this important automation development effort, feel free to contact us at [email protected]

How to migrate test cases from Gaia-ui-tests

This section provides a guide to migrating tests between gaia-ui tests and MTBF.

Step 1: Rename

• from MtbfTestCase import GaiaMtbfTestCase
  • (original) from gaiatest import GaiaTestCase
• class XXX(GaiaMtbfTestCase)
  • (original) class XXX(GaiaTestCase)
• If it has a setUp() or tearDown() method, use GaiaMtbfTestCase
  • (original) GaiaTestCase

Step 2: Add

• If there's no setUp() method , add it before the general test function.
• Add GaiaMtbfTestCase.setUp(self) as the first step of setUp().
  • Environment check/recovery and app initialization.
  • launch > launch_by_touch if possible.
  • Get the handle using self.app_id.
• If there's no tearDown() method, add it after the general test function.
• Add GaiaMtbfTestCase.tearDown(self) as the last step of tearDown().
  • Handle data after the test is finished (delete/remove/move/etc.)

Step 3: Principles

• Modify assert() functions in your tests (make sure they work for multiple test cases.)
• If porting cases from Gaia-UI-Test, you need to declare app as a test class member.
• If multiple apps init/launch in a case; please refer to the card_view cases.
  • Unless your clean actions don't involve UI interactions, avoid this scenario if you can.
  • For example, use device manager to remove the file on the device.
  • In such cases, you may need to call marionette.refresh() to get the latest update.
• Replace datetime.fromtimestamp with datetime.utcfromtimestamp if you want to implement calendar related cases.

Step 4: About apps

1. apps > mtbf_apps if needed.
2. Import original apps.
3. Add __init__() and any functions you need.

Step 5: After you have finished

1. Test each test case using Test full suite > Test full suite with shuffle
2. Check PEP8 errors
3. Use a pull request to add your test cases to the main repo! Do not push directly.