mozilla
Your Search Results

    MTBF tests

    The MTBF tests are a suite of Firefox OS tests built on top of the Gaiatest (Gaia UI Tests) Framework. The tests run on real Firefox OS devices, and use Marionette to drive the device's UI. These tests are designed to measure application stability/reliability, and replace the now-discountinued Gaia endurance 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.

    Note: At the point where you start running through the following steps, the Firefox OS device should not be connected to your computer. You will be told when to connect it in the steps below.

    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.

    Note: If the risks are not acknowledged in the testvars file, the tests will not run.

    Step 5: Connect to USB and ADB Forward the Device

    Attach the Firefox OS device to your computer via USB.

    Note: If you’re using an Ubuntu VM, after attaching the device ensure the VM sees the device and connects to it; in the VM select VM > Removable Devices > Your Device > Connect and wait for the device to connect to the VM.

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

    adb forward tcp:2828 tcp:2828

    Note: If you are using the Firefox OS Leo device, you must first tell ADB to be the root user, like so:

    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 --address=localhost:2828 --testvars=mytestvars.json tests/{any folder or test}

    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.

    Note: The Gaia-UI MTBF tests now grab the Firefox OS device’s b2g process RSS value for the memory use checkpoint (it used to be the V-SIZE value.)

    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.

    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 wachen@mozilla.com

    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.

    Document Tags and Contributors

    Contributors to this page: ypwalter, PaulYang, chrisdavidmills
    Last updated by: chrisdavidmills,
    Hide Sidebar