Надежен ли Robotium для тестирования того, как быстро начинаются действия и фрагменты?
Я пытаюсь написать автоматические тесты "черного ящика", чтобы утверждать, что "убедитесь, что целевая страница появляется в течение 500 мс после запуска приложения" и "убедитесь, что вход в систему занимает менее 2 секунд". Я хочу сделать это, управляя пользовательским интерфейсом реального приложения, чтобы максимально точно имитировать реальных пользователей.
Я использую Robotium 5.0.1 для своих тестов пользовательского интерфейса "черного ящика", и я надеялся, что будет просто добавить некоторый простой код синхронизации. Тем не менее, кажется, что тесты периодически дают сбой в разных местах, даже в тех местах, которые не делают сетевых запросов. Похоже, что при локальном запуске нескольких тестов в эмуляторе возникают случайные задержки в ~2 секунды (мы также запускаем тесты на Jenkins в облаке с использованием CloudBees, хотя я еще не пробовал там тесты).
Является ли Robotium подходящим инструментом для такого рода тестирования? Есть ли у вас какие-либо советы о том, как лучше проводить такие тесты?
Вот мой тест:
public void testLogin() {
AppData.getAppData().clear();
startTimer();
launchActivity();
assertTrue(solo.waitForFragmentByTag("landingfragment", 3000));
stopTimer();
assertWasQuickerThan(500);
startTimer();
solo.clickOnButton("Log In");
assertTrue(solo.waitForFragmentByTag("loginfragment", 3000));
stopTimer();
assertWasQuickerThan(500);
solo.enterText(0, TestUtils.EXISTING_USER_EMAIL);
solo.enterText(1, TestUtils.EXISTING_USER_PASSWORD);
startTimer();
solo.clickOnButton("Next");
assertTrue(solo.waitForActivity(LaunchActivity.class, 3000));
stopTimer();
assertWasQuickerThan(2000);
}
Вот logcat (это показывает, что целевая страница появилась в течение 16 мс, но после нажатия кнопки входа в систему потребовалось 2079 мс для появления страницы входа):
03-12 14:46:11.535 386-571/system_process I/ActivityManager﹕ START u0 {cmp=com.example/com.example.ui.LaunchActivity} from pid 1180
03-12 14:46:11.555 1180-1193/com.example D/MyApp﹕ LoginTest: Step took 16ms to complete,
03-12 14:46:12.035 1180-1180/com.example D/dalvikvm﹕ GC_FOR_ALLOC freed 1470K, 47% free 3456K/6424K, paused 96ms, total 98ms
03-12 14:46:12.045 1180-1180/com.example I/dalvikvm-heap﹕ Grow heap (frag case) to 4.842MB for 1463056-byte allocation
03-12 14:46:12.145 1180-1281/com.example D/dalvikvm﹕ GC_FOR_ALLOC freed 5K, 25% free 4880K/6424K, paused 87ms, total 102ms
03-12 14:46:12.405 386-400/system_process I/ActivityManager﹕ Displayed com.example/com.example.ui.LaunchActivity: +848ms
03-12 14:46:13.115 1180-1180/com.example I/MyApp﹕ USER: LandingFragment: Sign in pressed,
03-12 14:46:13.315 1180-1180/com.example D/dalvikvm﹕ GC_FOR_ALLOC freed 1478K, 46% free 3508K/6424K, paused 21ms, total 23ms
03-12 14:46:13.315 1180-1180/com.example I/dalvikvm-heap﹕ Grow heap (frag case) to 4.761MB for 1324816-byte allocation
03-12 14:46:13.345 1180-1180/com.example D/dalvikvm﹕ GC_FOR_ALLOC freed 3K, 26% free 4798K/6424K, paused 23ms, total 23ms
03-12 14:46:13.395 1180-1180/com.example D/dalvikvm﹕ GC_FOR_ALLOC freed <1K, 26% free 4798K/6424K, paused 31ms, total 31ms
03-12 14:46:13.405 1180-1180/com.example I/dalvikvm-heap﹕ Grow heap (frag case) to 6.153MB for 1463056-byte allocation
03-12 14:46:13.425 1180-1281/com.example D/dalvikvm﹕ GC_FOR_ALLOC freed 0K, 21% free 6227K/7856K, paused 26ms, total 26ms
03-12 14:46:13.445 1180-1180/com.example I/Choreographer﹕ Skipped 47 frames! The application may be doing too much work on its main thread.
03-12 14:46:13.635 1180-1193/com.example D/MyApp﹕ LoginTest: Step took 2079ms to complete,
03-12 14:46:14.695 1180-1180/com.example I/Choreographer﹕ Skipped 52 frames! The application may be doing too much work on its main thread.
03-12 14:46:15.325 1180-1193/com.example I/TestRunner﹕ failed: testLogin(com.example.blackbox.LoginTest)
03-12 14:46:15.335 1180-1193/com.example I/TestRunner﹕ ----- begin exception -----
03-12 14:46:15.335 1180-1193/com.example I/TestRunner﹕ junit.framework.AssertionFailedError: Step was too slow, expected 500ms but took 2079ms
at junit.framework.Assert.fail(Assert.java:50)
at junit.framework.Assert.assertTrue(Assert.java:20)
at com.example.blackbox.BaseBlackBoxTest.assertWasQuickerThan(BaseBlackBoxTest.java:57)
at com.example.blackbox.LoginTest.testLogin(LoginTest.java:52)
... а вот мой BaseBlackBoxTest класс, который расширяет мой тестовый класс:
abstract class BaseBlackBoxTest<T extends android.app.Activity>
extends ActivityInstrumentationTestCase2<T> {
protected Solo solo;
protected long mStartTime;
protected long mStopTime;
@Before
public void setUp() throws Exception {
solo = new Solo(getInstrumentation(), getActivity());
}
@After
public void tearDown() throws Exception {
solo.finishOpenedActivities();
}
public BaseBlackBoxTest(Class clazz) {
super(clazz);
}
protected void launchActivity() {
Activity activity = getActivity();
Intent intent = new Intent(activity, activity.getClass());
activity.startActivity(intent);
solo.assertCurrentActivity("Expecting " + activity.getClass(), activity.getClass());
}
// TIMING UTILITIES //
protected void startTimer() {
mStartTime = System.nanoTime();
}
protected void stopTimer() {
mStopTime = System.nanoTime();
}
protected void assertWasQuickerThan(long maxDurationMillis) {
long durationMillis = (mStopTime - mStartTime) / 1000000;
LogIt.d(this, "Step took " + durationMillis + "ms to complete");
assertTrue("Step was too slow, expected " + maxDurationMillis + "ms but took " + durationMillis + "ms",
durationMillis < maxDurationMillis);
}
}
1 ответ
ИМХО Я думаю, вам не следует делать такие автоматические тесты производительности, так как вы не контролируете производительность эмуляторов. Вы должны сосредоточиться на тестировании того, что показывает ваше приложение, а не на том, насколько быстро оно работает.
Если вам нужно проверить доступность ваших веб-сервисов, вы можете выполнить отдельные тесты, которые вызывают HTTP-запросы и дают сбой по истечении указанного вами времени ожидания.