New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 700967 link

Starred by 1 user

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug



Sign in to add a comment

Create better automated tests for Chrome/Android interaction

Project Member Reported by dhadd...@chromium.org, Mar 13 2017

Issue description

See issue 692393 for discussion and more context. 

Currently we have an "arc mode" version of many chromeos tests that just wait for Android to be booted successfully and then run the test. This was decided when ARC++ was getting up and running initially. In theory, these tests shouldn't be affected by the container running since they don't have any interaction with the container once booted. 

It is not clear if this approach has found many meaningful bugs so we should do a couple things:

1. Investigate the failures of arc mode tests and see what kind of bugs they have produced.

2. If they are not finding bugs we can disable arc mode in these tests. This will make tests run a lot faster and waste less resources in the CQ/lab.

3. Create a good test(s) that see that ChromeOS is not adversely affected when Android is doing various things. 
 
Just one point that hasn't been discussed: I believe one of the original intents of this was to make sure we don't regress Chrome performance meaningfully when Android is present.  If there are perf related tests we may still want to capture data when Android is and isn't present.

Comment 2 by ihf@chromium.org, Mar 21 2017

I see, that makes more sense. We don't quite have A/B testing like this for performance. Say on goldeneye crosbolt we would just see more noise. But one could report both graphs to chromeperf. Not sure how to plot them into the same chart instead of 2 charts.
Status: Assigned (was: Untriaged)
Components: Platform>Apps>ARC

Sign in to add a comment