| 3424656b6b49785aa4203d9c338307bba0cda905 |
|
18-Sep-2012 |
Keun young Park <keunyoung@google.com> |
add timeout per package for PTS
- Motivation: PTS tests can run for long time and needs customized timeout.
- each method can declare timeout using @TimeoutReq(minutes=value)
annotation.
- timeout is specified in minutes with 0 meaning no timeout.
- xml generator add timeout information like Class:method:10 if timeout
annotation is present.
- CTS parses the xml and read timeout per each method, but the current
architecture allows only one timeout for the whole package.
- Due to the restriction, the biggest timeout for the package is set.
- If timeout is not set, the current default of 10 mins will be used.
- The new annotation, TimeoutReq is defined in ctsutil.
CTS tests can use it too. But it is ** strongly recommended to use this
in a new package ** to prevent increasing test time too much.
- all file system tests and UI tests set to have timeout of 30 mins.
Change-Id: I9a19cb02b91376c581e13522d248872af8c7eee9
|
| 3769d33a2a5facc0caf497718b2730e16bf47ba2 |
|
29-Aug-2012 |
Keun young Park <keunyoung@google.com> |
performance test initial work
- pts build added (not yet pulled by cts)
- cts-tradefed has PTS mode where binary is under android-pts
- performance measurement is delivered to host by throwing exception!
: This can reduce the amount of code duplication as all existing
instrumentation test code can be re-used.
When performance test throws PtsException, it is treated as PASS and
the message is stored to the xml.
- UI scrolling performance
: scroll 10k list from top to bottom and measure time
- File system performance
: sequential write, sequential read, update
update with almost full disk
actural disk I/O can be checked by monitoring /proc/self/io
if kernel supports it. But it is only for debugging
Change-Id: Id83988fe34b6040bc20c98061a2b4f3d2f878b86
|
| 50455b3f14f3cd835150e63bea640cb76c7c2cb4 |
|
13-Sep-2012 |
Keun-young Park <keunyoung@google.com> |
Revert "performace test initial work"
This reverts commit b6ea46e3f074720ddae5e018b80e616f72272ed0
Change-Id: I2becc16ff320bed2174582df0ca79dcc01067e4a
|
| b6ea46e3f074720ddae5e018b80e616f72272ed0 |
|
29-Aug-2012 |
Keun young Park <keunyoung@google.com> |
performace test initial work
- pts build added (not yet pulled by cts)
- cts-tradefed has PTS mode where binary is under android-pts
- performance measurement is delivered to host by throwing exception!
: This can reduce the amount of code duplication as all existing
instrumentation test code can be re-used.
When performance test throws PtsException, it is treated as PASS and
the message is stored to the xml.
- UI scrolling performance
: scroll 10k list from top to bottom and measure time
- File system performance
: sequential write, sequential read, update
update with almost full disk
actural disk I/O can be checked by monitoring /proc/self/io
if kernel supports it. But it is only for debugging
Change-Id: Ice908d72c9ebb381c7e8e644d859904b17b7ef2a
|
| 1a522479ad0c2ea81ad7323224313ec25f698267 |
|
19-Jul-2012 |
Brian Muramatsu <btmura@android.com> |
Fix DocletRunner to use updated TF path
Change-Id: I8bd781dd3a4e89412faab1a953b8de9ded3182b3
|
| 2eb57f8136c236861882a2d98d925e19db34c9ae |
|
12-Jun-2012 |
Brian Muramatsu <btmura@google.com> |
Fix missing tests
Use external Junit since the libcore one is no longer present.
Change-Id: I78dbe78304f8052cbab64316cdfd97d93ed237e9
|
| 5df641c2f3c8fca177feeaa8e61d06b5dc7920ed |
|
29-Dec-2011 |
Brian Muramatsu <btmura@google.com> |
Move Test XML Generation from buildCts.py
buildCts.py was the central script that generated all the
test package XMLs each time CTS was built. This had a
couple problems:
1. All the XML files for ~40 packages needed to be made
every time CTS was made. Even if those packages were
not touched at all.
2. Couldn't shard the XML generation process across the
available cores on a machine. A pool was added to the
python script, but it was set to a fixed number.
This change moves the test XML generation into a
smaller Java program called "cts-java-scanner" and
the doclet it relies upon to scan the Java files
into "cts-java-scanner-doclet.jar". The output of
the scanner like "cts-native-scanner" for native EXEs
is piped to the existing cts-xml-generator to
produce the test XMLs.
New CTS specific rules replace the standard
BUILD_PACKAGE and BUILD_HOST_JAVA_LIBRARY. They just
add extra rules for the package XML. The BUILD_CTS_PACKAGE
rule also adds a rule for copying the "package.apk"
to something more like "CtsFooTestCases.apk" to the
test case out directory. All the apks, exes, and xmls
are now thrown into a "cts-testcases" directory, before
they are copied to the final CTS distribution.
This change should prevent rebuilding the XMLs
unnecessarily and make rebuilding CTS quicker while
writing tests.
There are still the libcore tests that are always rebuilt,
but they can be adapted to fit into this model someday...
Change-Id: I52a916aa37fd679057e2709bb0ccec694c9fca01
|