¿Robotium es confiable para probar cuán rápido comienzan las actividades y fragmentos?
Estoy tratando de escribir pruebas automatizadas caja negra para afirmar cosas como "asegurarse de que la página de destino aparece dentro de 500ms de lanzar la aplicación" y "asegurarse de que un inicio de sesión tarda menos de 2 segundos". Quiero hacer esto mediante la conducción de la interfaz de usuario de la aplicación real, para simular los usuarios reales lo más cerca posible.
Estoy usando Robotium 5.0.1 para mi caja negra pruebas de interfaz de usuario, y esperaba que sería simple para añadir un código de tiempo simple. Sin embargo, las pruebas parecen fallar intermitentemente en diferentes lugares, incluso en lugares que no hacen solicitudes de red. Parece que se producen retrasos ocasionales de ~ 2 segundos al ejecutar varias pruebas localmente en un emulador (también realizamos pruebas en Jenkins en la nube usando CloudBees , aunque todavía no he probado las pruebas allí).
- Cómo manejar la actividad de la aplicación externa en android utilizando robotium
- Utilice tanto InstrumentationTestRunner como AndroidJUnitRunner con Robotium y Espresso
- ¿Cómo resolver la excepción durante la construcción de la suite?
- Robotium: Instale un nivel de API Android compatible (15 o superior)
- La prueba de instrumentación falla al azar con multidexado activado
¿Es Robotium la herramienta adecuada para este tipo de pruebas? ¿Tiene algún consejo sobre la mejor manera de hacer este tipo de pruebas?
Aquí está mi prueba:
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); }
Aquí está el logcat (esto muestra que la página de destino apareció dentro de 16ms, pero después de presionar el botón de inicio de sesión tomó 2079ms para que aparezca la página de inicio de sesión):
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)
… y aquí está mi clase BaseBlackBoxTest
que mi clase de prueba se extiende:
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); } }
- Cómo probar el evento swipe / fling usando jUnit en Android testcase
- Cómo conseguir que la actividad se ejecute desde otro proceso utilizando Robotium
- Crear prueba Android apk utilizando el sistema de compilación gradle
- ¿Cómo iniciar el proyecto de Instrumentación mediante programación con Android Intent?
- ¿Cómo hacer clic en el botón de "búsqueda" del teclado con Robotium?
- ¿Conoces alguna herramienta de instrumentación dinámica para Android con soporte para múltiples dispositivos (idealmente en Python o Jython)?
- Google Espresso o Robotium
- Android Espresso prueba el flujo de aplicaciones
IMHO Creo que no deberías realizar pruebas de rendimiento automatizadas, ya que no controlas el rendimiento de los emuladores. Debe centrarse en probar lo que muestra su aplicación y no en su velocidad.
Si necesita comprobar la disponibilidad de sus servicios web, puede realizar pruebas separadas que llaman a solicitudes HTTP y fallan después del tiempo de espera especificado.
- Base de datos de Android Intent
- Android ¿Qué permisos se requieren para llamar a PowerManager.goToSleep (n) poner el dispositivo en modo de suspensión?