studio - programar tareas en android

¿Cómo se prueba una aplicación de Android en múltiples actividades?

Question

Estamos construyendo una aplicación Android compleja que consta de muchas pantallas y flujos de trabajo distribuidos en muchas actividades. Nuestros flujos de trabajo son similares a lo que puede ver en un cajero automático del Banco, por ejemplo, hay una Activity para iniciar sesión en esa transición a una Activity menú principal que puede hacer la transición a otras actividades según las elecciones del usuario.

Como tenemos tantos flujos de trabajo, necesitamos crear pruebas automatizadas que abarquen múltiples actividades para que podamos probar un flujo de trabajo de principio a fin. Por ejemplo, usando el ejemplo del cajero automático, nos gustaría ingresar un PIN válido, verificar que nos envíe al menú principal, elegir retirar efectivo, verificar que estamos en la pantalla de retirar efectivo, etc., y finalmente encontrarnos de nuevo en el menú principal o "desconectado".

Hemos jugado con las API de prueba que vienen con Android (por ejemplo, ActivityInstrumentationTestCase2 ) y también con Positron , pero ninguna parece ser capaz de probar más allá de los límites de una sola Activity , y aunque podemos encontrar alguna utilidad en estas herramientas para algunas pruebas de unidades, no satisfarán nuestras necesidades de escenarios de prueba que abarquen múltiples actividades.

Estamos abiertos a un marco xUnit, secuencias de comandos, grabadoras / reproducciones GUI, etc. y agradeceríamos cualquier consejo.

Answer 1

¿Se aceptará el enfoque de trabajo con diferentes actividades de diferentes aplicaciones, firmado por diferentes certificados? Si no, Robotium es la mejor manera de probar actividades dentro de la misma aplicación.

Answer 2

Antes que nada, use ''ActivityInstrumentationTestCase2'', no ''InstrumentationTestCase'', como su clase base. Uso Robotium y pruebo rutinariamente en múltiples actividades. Descubrí que tengo que especificar la actividad de inicio de sesión como el tipo genérico (y el argumento de clase para el constructor).

El constructor ''ActivityInstrumentationTestCase2'' ignora el argumento del paquete y no lo requiere. El constructor que toma el paquete está en desuso.

Desde los Javadocs: "ActivityInstrumentationTestCase2 (String pkg, Class activityClass) Este constructor está en desuso. Use ActivityInstrumentationTestCase2 (Class) en su lugar"

El uso de la clase base recomendada permite que el marco maneje cierto texto estándar, como comenzar su actividad. Esto se hace mediante la llamada a ''getActivity ()'', si es necesario.

Answer 3

Creé una herramienta de grabación y reproducción para Android y la hice disponible en GitHub . Es fácil de configurar y usar, no requiere programación, se ejecuta contra dispositivos reales (que no tienen que rootearse) y guarda automáticamente capturas de pantalla mientras se realizan las pruebas.

Answer 4

Echa un vistazo a Robotium
''Un marco de prueba de código abierto creado para realizar pruebas automáticas de caja negra de las aplicaciones de Android significativamente más rápido y más fácil de lo que es posible con las pruebas de instrumentación de Android listas para usar''.

Página de inicio: http://www.robotium.org/
Fuente: http://github.com/jayway/robotium

Tenga en cuenta que el proyecto Robotium es mantenido por la empresa para la que trabajo

Answer 5

Encontré esto útil con un par de modificaciones. En primer lugar getInstrumentation().waitForIdleSync() curará la descamación de SingleShot y también InstrumentationTestCase tiene una función lauchActivity que puede reemplazar las líneas de actividad de inicio.

Answer 6

Esta respuesta se basa en la respuesta aceptada, pero se modificó para resolver el problema del tiempo que para mí se volvió consistente después de agregar aproximadamente media docena de pruebas. @ pajato1 obtiene el crédito por resolver el problema del tiempo, como se cita en los comentarios de respuesta aceptados.

/**
 * Creates a test Activity for a given fully qualified test class name.
 *
 * @param fullyQualifiedClassName The fully qualified name of test activity class.
 *
 * @return The test activity object or null if it could not be located.
 */
protected AbstractTestActivity getTestActivity(final String fullyQualifiedClassName) {
    AbstractTestActivity result = null;

    // Register our interest in the given activity and start it.
    Log.d(TAG, String.format("Running test (%s) with main class: %s.", getName(), fullyQualifiedClassName));
    instrumentation = getInstrumentation();

    Intent intent = new Intent(Intent.ACTION_MAIN);
    intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
    intent.setClassName(instrumentation.getTargetContext(), fullyQualifiedClassName);
    // Wait for the activity to finish starting
    Activity activity = instrumentation.startActivitySync(intent);

    // Perform basic sanity checks.
    assertTrue("The activity is null!  Aborting.", activity != null);
    String format = "The test activity is of the wrong type (%s).";
    assertTrue(String.format(format, activity.getClass().getName()), activity.getClass().getName().equals(fullyQualifiedClassName));
    result = (AbstractTestActivity) activity;

    return result;
}

Answer 7

Estoy trabajando prácticamente en lo mismo, y probablemente vaya con una variación de la respuesta aceptada a esta pregunta, pero encontré Calculuon ( gitHub ) durante mis búsquedas de una solución.

Answer 8

Hay otra forma de hacer la actividad múltiple usando ActivityInstrumentation Class. Es un escenario de automatización normal ... Primero, concéntrate en el objeto que quieras y luego envía una clave Simple como ese código de muestra

button.requestFocus();
sendKeys(KeyEvent.KEYCODE_ENTER);

Lo único es entender que cada llamada de API nos ayudará.

Answer 9

Me siento un poco incómodo al responder mi propia pregunta de generosidad, pero aquí está ...

He buscado alto y bajo en esto y no puedo creer que no haya ninguna respuesta publicada en ningún lado. He venido muy cerca. Definitivamente puedo ejecutar pruebas que abarcan actividades ahora, pero mi implementación parece tener algunos problemas de tiempo donde las pruebas no siempre pasan de manera confiable. Este es el único ejemplo que conozco de esas pruebas en múltiples actividades con éxito. Afortunadamente mi extracción y anonimización no introdujeron errores. Esta es una prueba simplista en la que escribo un nombre de usuario y una contraseña en una actividad de inicio de sesión, y luego observo que se muestra un mensaje de bienvenida apropiado en una actividad diferente de "bienvenida":

package com.mycompany;

import android.app.*;
import android.content.*;
import android.test.*;
import android.test.suitebuilder.annotation.*;
import android.util.*;
import android.view.*;
import android.widget.*;

import static org.hamcrest.core.Is.*;
import static org.hamcrest.core.IsNull.*;
import static org.hamcrest.core.IsInstanceOf.instanceOf;
import static org.junit.Assert.*;
import static com.mycompany.R.id.*;

public class LoginTests extends InstrumentationTestCase {

   @MediumTest
   public void testAValidUserCanLogIn() {

      Instrumentation instrumentation = getInstrumentation();

      // Register we are interested in the authentication activiry...
      Instrumentation.ActivityMonitor monitor = instrumentation.addMonitor(AuthenticateActivity.class.getName(), null, false);

      // Start the authentication activity as the first activity...
      Intent intent = new Intent(Intent.ACTION_MAIN);
      intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
      intent.setClassName(instrumentation.getTargetContext(), AuthenticateActivity.class.getName());
      instrumentation.startActivitySync(intent);

      // Wait for it to start...
      Activity currentActivity = getInstrumentation().waitForMonitorWithTimeout(monitor, 5);
      assertThat(currentActivity, is(notNullValue()));

      // Type into the username field...
      View currentView = currentActivity.findViewById(username_field);
      assertThat(currentView, is(notNullValue()));
      assertThat(currentView, instanceOf(EditText.class));
      TouchUtils.clickView(this, currentView);
      instrumentation.sendStringSync("MyUsername");

      // Type into the password field...
      currentView = currentActivity.findViewById(password_field);
      assertThat(currentView, is(notNullValue()));
      assertThat(currentView, instanceOf(EditText.class));
      TouchUtils.clickView(this, currentView);
      instrumentation.sendStringSync("MyPassword");

      // Register we are interested in the welcome activity...
      // this has to be done before we do something that will send us to that
      // activity...
      instrumentation.removeMonitor(monitor);
      monitor = instrumentation.addMonitor(WelcomeActivity.class.getName(), null, false);

      // Click the login button...
      currentView = currentActivity.findViewById(login_button;
      assertThat(currentView, is(notNullValue()));
      assertThat(currentView, instanceOf(Button.class));
      TouchUtils.clickView(this, currentView);

      // Wait for the welcome page to start...
      currentActivity = getInstrumentation().waitForMonitorWithTimeout(monitor, 5);
      assertThat(currentActivity, is(notNullValue()));

      // Make sure we are logged in...
      currentView = currentActivity.findViewById(welcome_message);
      assertThat(currentView, is(notNullValue()));
      assertThat(currentView, instanceOf(TextView.class));
      assertThat(((TextView)currentView).getText().toString(), is("Welcome, MyUsername!"));
   }
}

Este código obviamente no es muy legible. De hecho, lo he extraído en una biblioteca simple con una API similar a la del inglés, así que puedo decir cosas como esta:

type("myUsername").intoThe(username_field);
click(login_button);

He probado a una profundidad de aproximadamente 4 actividades y estoy satisfecho de que el enfoque funciona, aunque, como he dicho, parece que hay un problema de tiempo ocasional que no he descubierto por completo. Todavía estoy interesado en conocer otras formas de probar las actividades.

Answer 10

Me sorprende que nadie haya mencionado algunas de las principales herramientas de prueba funcional automatizadas . Comparado con Robotium, estos no requieren escribir código Java.

MonkeyTalk : una herramienta de código abierto respaldada por la empresa Gorilla Logic. Pros: proporciona la grabación así como un lenguaje de scripting de alto nivel más fácil para usuarios no técnicos, y es multiplataforma (incluye iOS). Dados esos beneficios como requisitos, hemos encontrado que esta es la mejor solución. También permite la customization más allá de lo que se puede hacer en su lenguaje de scripts utilizando Javascript.

Calabash-Android : una herramienta de código abierto para las características de estilo Pepino. Pros: escriba funciones en el lenguaje Gherkin que es legible por negocios, lenguaje específico del dominio que le permite describir el comportamiento del software sin detallar cómo se implementa dicho comportamiento. Soporte similar pero no exacto está disponible para iOS en cucumber-ios . Las capacidades de grabación no son tan buenas, ya que producen una salida binaria.

Un par de otras referencias:

• Aquí hay algunas comparaciones adicionales entre Robotium, Monkeytalk y Calabash. Menciona TestDroid como otra posibilidad.
• Este blog menciona lo anterior más NativeDriver y Bot-bot.

Answer 11

No lo he usado personalmente, pero ApplicationTestCase parece que podría ser lo que estás buscando.

Answer 12

Siempre puedes usar Robotium. Es compatible con pruebas de blackbox como Selenium, pero para Android. Lo encontrarás en Robotium.org

Answer 13

puede hacerlo así para evitar que los tiempos de espera de copos se desincronicen:

final Button btnLogin = (Button) getActivity().findViewById(R.id.button);
Instrumentation instrumentation = getInstrumentation();

// Register we are interested in the authentication activity...
Instrumentation.ActivityMonitor aMonitor = 
        instrumentation.addMonitor(mynextActivity.class.getName(), null, false);

getInstrumentation().runOnMainSync(new Runnable() {
         public void run() {
             btnLogin.performClick();
         }
     });

getInstrumentation().waitForIdleSync();

//check if we got at least one hit on the new activity
assertTrue(getInstrumentation().checkMonitorHit(aMonitor, 1)); 

Answer 14

Prueba la prueba de la herramienta Monkey

Paso 1:

abra el terminal de estudio de Android (Herramientas-> terminal abierto)

Paso 2:

Para usar monkey, abra un símbolo del sistema y simplemente navegue al siguiente directorio.

 export PATH=$PATH:/home/adt-bundle-linux-x86-20140702/sdk/platform-tools

Paso 3:

agrega este comando mono en la terminal y presiona enter ...

mira la magia en tu emulador

adb shell monkey -p com.example.yourpackage -v 500

500- es el recuento de frecuencia o el número de eventos que se enviarán para la prueba.

puedes cambiar este conteo ...

Más referencia,

http://www.tutorialspoint.com/android/android_testing.htm

http://androidtesting.blogspot.in/2012/04/android-testing-with-monkey-tool.html