Академический Документы
Профессиональный Документы
Культура Документы
Autotest test cases are implemented as individual scripts that execute commands on a target device.
Supports server-side and client-side tests: Server-side test: Server script uses host objects to represent SSH connection to the test device, through which the server executes code on the client(s). Client-side test: Runs entirely on the target host. The entire Autotest client dir is installed on the host machine before calling the test. We'll focus on a client test case that is kicked off by an external monitor process (autoserv + ssh). Useful links: Chromium OS Autotest howto/FAQ: http://goto/cros-autotest Autotest API docs: http://autotest.kernel.org/wiki/TestDeveloper
Upstream tests exist under (client|server)/tests Test should be prefixed with Tracker focus area, e.g. o desktopui_* o platform_* Upstream useful libraries live in client/common_lib o base_utils o site_ui o site_power_status Chromium OS specific useful libraries exist under client/cros o cros_ui o login Rule of thumb is that our specific modules have either a site_* prefix (autotest convention) or in a cros directory.
client/site_tests/logging_UserCrash/ control logging_UserCrash.py src/ The control file tells the autotest framework how to setup and execute its test. All test logic, methods, setup, teardown go in the identically named Python module. You can build your own test dependencies here in a src directory or include it in the chromeos-test ebuild. The latter is preferred if the test dep isn't large.
run_remote_test.sh is a wrapper around Autotest's autoserv that takes care of test updating, locating, remote authorization, test summary... You can use --nocleanup (and --results_dir_root) to preserve the test result directories containing useful test run logs and debug information You can use the --build option to force it to use the latest code from your autotest directory without re-running build_packages (requires you have cros work'd on autotest). You can also use the bin/cros_run_vm_test wrapper scripts to start a KVM VM (created from image_to_vm --test_image) and run the test.
2. Write some Python (or use utils.system(...) to invoke shell commands), which checks that the 'chrome' process is running, and fails otherwise. 3. Add test to chromeos-base/autotest-tests ebuild (???) 4. Build/install your test by "working on" autotest / autotest-tests and running run_remote_tests.sh --build <test>, ensuring that it passes on the client. 5. You have now mastered using Autotest in command-line mode... Onward!
ebuild chroot cross-compilation environment o run_remote_tests.sh builds all client tests immediately
before they are launched o Autotest along with the pre-built tests are installed under ${SYSROOT}/usr/local/autotest
Test suites
You can run a set of tests in a suite. Suites are defined solely in control files.
Current Suites: suite_Smoke - Run on builders to verify every build. Defined in client/site_tests/suite_Smoke. suite_HWQual - The HWQual is in client/site_tests/suite_HWQual. Due to its semi-automatic nature, it has an accompanying readme with instructions on how to run. BVT suite - Large verification test suite run in the Kirkland test farm. Defined in server/suites/control.bvt. Results of these tests can be seen in http://cautotest/results/dashboard Many more ...
Last things
Some of documentation may be stale. Please feel edit and fix it. Reminder: Chromium OS Autotest howto/FAQ: http://goto/crosautotest