README.md
1 # Android Comms Test Suite
2 The Android Comms Test Suite, is a lightweight Python-based automation tool set
3 that is used to perform automated testing of current and upcoming Android
4 devices. It provides a simple execution interface; a set of pluggable libraries
5 for accessing commercially avilable devices, Android devices, and a collection
6 of utility functions to further ease test development. It is an ideal desktop
7 tool for a wireless stack developer or integrator whether exercising a new code
8 path, performing sanity testing, or running extended regression test suites.
9
10 Included in the tests/google directory are a bundle of tests, many of which can
11 be run with as little as one or two Android devices with wifi, cellular, or
12 bluetooth connectivity, including:
13 1. Wifi tests for access point interopability, enterprise server integration,
14 WiFi scanning, WiFi auto join, and round trip time.
15 2. Bluetooth tests for low energy, GATT, SPP, and bonding.
16 3. Cellular tests for circuit switch and IMS calling, data connectivity,
17 messaging, network switching, and WiFi hotspot.
18
19 ACTS follows the Google Open-source
20 [Python Style Guide](https://google.github.io/styleguide/pyguide.html), and
21 it is recommended for all new test cases.
22
23 System dependencies:
24 - adb
25 - python3.4+
26 - python3.4-setuptools
27
28 Python dependencies (installed automatically by setup.py):
29 - future
30 - pyserial
31
32 To run unit tests:
33 $ python3 setup.py test
34 $ python setup.py test
35
36 ## ACTS Execution Flow Overview
37 Below is a high level view of the ACTS flow:
38
39 1. Read configuration files
40 2. Create controllers
41 3. Sequentially execute test classes
42
43 ```
44 FooTest.setup_class()
45 FooTest.setup_test()
46 FooTest.test_A()
47 FooTest.teardown_test()
48 FooTest.setup_test()
49 FooTest.test_B()
50 FooTest.teardown_test()
51 ....
52 FooTest.teardown_class()
53 BarTest.setup_class()
54 ....
55 ```
56
57 4. Destroy controllers
58
59 ## Preparing an Android Device
60 ### Allow USB Debugging
61 USB debugging must be enabled before a device can take commands from adb.
62 To enable USB debugging, first enable developer mode.
63 1. Go to Settings->About phone
64 2. Tap Build number repeatedly until "You're a developer now" is displayed.
65
66 In developer mode:
67 1. Plug the device into a computer (host)
68 2. Run `$adb devices`
69 - A pop-up asking to allow the host to access the android device may be
70 displayed. Check the "Always" box and click "Yes".
71
72 ## ACTS Setup
73
74 1. Install the system dependencies.
75 On Ubuntu, sudo apt-get install python3.4 python3-setuptools
76 2. Run "python3.4 setup.py install" with elevated permissions
77 3. To verify ACTS is ready to go, at the location for README, and run:
78 cd tests/ && act.py -c acts_sanity_test_config.json -tc IntegrationTest
79
80 After installation, `act.py` will be in usr/bin and can be called as command
81 line utilities. Components in ACTS are importable under the package "acts."
82 in Python, for example:
83
84 ```
85 $ python
86 >>> from acts.controllers import android_device
87 >>> device_list = android_device.get_all_instances()
88 ```
89
90 ## Breaking Down a Sample Command
91
92 Above, the command `act.py -c acts_sanity_test_config.json -tc IntegrationTest`
93 was run to verify ACTS was properly set up.
94 Below are the components of that command:
95 - `acts.py`: is the script that runs the test
96 - -c acts_sanity_test_config: is the flag and name of the configuration file
97 to be used in the test
98 - -tc IntegrationTest: is the name of the test case
99
100 ### Configuration Files
101 To run tests, required information must be provided via a json-formatted
102 text file. The required information includes a list of ***testbed*** configs.
103 Each specifies the hardware, services, the path to the logs directory, and
104 a list of paths where the python test case files are located. Below are the
105 contents of a sample configuration file:
106
107 ```
108 { "_description": "This is an example skeleton test configuration file.",
109 "testbed":
110 [
111 {
112 "_description": "Sample testbed with no devices",
113 "name": "SampleTestBed"
114 }
115 ],
116 "logpath": "/tmp/logs",
117 "testpaths": ["../tests/sample"],
118 "custom_param1": {"favorite_food": "Icecream!"}
119 }
120 ```
121 The ***testpaths*** and ***logpath*** keys may alternately be supplied via the
122 execution environment though the ACTS_TESTPATHS and ACTS_LOGPATH keys
123 respectively. To specify multiple test paths, the key should follow
124 standard a ':'-delimited format. Explicit keys in a configuration file will
125 override any defaults provided by the environment.
126
127 ### Test Class
128 Test classes are instantiated with a dictionary of controllers. The
129 controllers dictionary contains all resources provided to the test class
130 and are created based on the provided configuration file.
131
132 Test classes must also contain an iterable member self.tests that lists the
133 test case names within the class. More on this is discussed after the
134 following code snippet.
135
136 ```
137 from acts.base_test import BaseTestClass
138
139 class SampleTest(BaseTestClass):
140
141 def __init__(self, controllers):
142 BaseTestClass.__init__(self, controllers)
143 self.tests = (
144 "test_make_toast",
145 )
146
147 """Tests"""
148 def test_make_toast(self):
149 for ad in self.android_devices:
150 ad.droid.makeToast("Hello World.")
151 return True
152 ```
153 By default all test cases listed in a Test Class\'s self.tests will be run.
154 Using the syntax below will override the default behavior by executing only
155 specific tests within a test class.
156
157 The following will run a single test, test_make_toast:
158
159 `$ act.py -c sample_config.txt -tb SampleTestBed -tc SampleTest:test_make_toast`
160
161 Multiple tests may be specified with a comma-delimited list. The following
162 will execute test_make_toast and test_make_bagel:
163
164 - `$ act.py -c sample_config.txt -tb SampleTestBed -tc
165 SampleTest:test_make_toast,test_make_bagel`
166