Algunas ideas sobre cómo elegir el marco de automatización de Android
Necesitamos dedicar algo de tiempo a aprender sobre varios marcos para determinar cuáles son adecuados para nuestro proyecto (tal vez escriba un resumen formal en ese momento).
Según tus requisitos, no deberías considerar MonkeyRunner y Robotium, pero me gustaría decirte que Robotium es bastante bueno si no necesitas pensar en el procesamiento cruzado de llamadas con otros. aplicaciones. En cuanto a MonkeyRunner, no lo recomiendo. Puedes leer mi respuesta a un comentario del Sr. Golden Sunshine: "Métodos y sugerencias para que MonkenRunner posicione controles a través de HierarchyViewer" (también lo publiqué simplemente al final del artículo). . En cuanto a Robotium, si compara los ejemplos de prueba de Note de cada marco escritos en mi blog, puede ver que Robotium es mucho más corto que otros marcos y el tiempo de desarrollo es mucho más largo que UIAutomator y Appium, por lo que debería ser relativamente maduro y Se puede integrar con Eclipse para depurar. También es muy conveniente. En comparación con los dos últimos, si hay alguna deficiencia, creo que es la siguiente:
1. Resumir todas las operaciones en una clase Solo carece de la idea de programación orientada a objetos, lo que a veces hace que las personas se sientan incómodas. incómodo. Si está familiarizado con las ideas de C y otros lenguajes procedimentales, no debería tener ningún problema.
2. Falta de métodos para obtener controles, solo hay unos pocos: Texto, ID, Nombre de clase, Índice, pero no tantos como los dos últimos.
3. : debido al marco del instrumento subyacente. La razón es que el paquete de prueba y la aplicación bajo prueba se empaquetan juntos y se ejecutan como un solo proceso, con subprocesos que se ejecutan a través de instrumentaiton. comunicación instrumentaiton, lo que hace que el proceso no pueda escapar del sandbox
4. Es imposible simular el teclado (pero esto también es una gran ventaja de Robotium, porque no necesita llamar al teclado como los dos últimos) causan varios problemas en la entrada), porque la lectura de entrada de Robotium en realidad se realiza directamente en la propiedad de texto del control. Lee la propiedad de texto del control directamente en lugar de ser controlado por el teclado. Si alguna vez ha realizado programación de interfaz de usuario, debe saber a qué me refiero, porque recuerde, su código de prueba y la aplicación de destino están empaquetados en el mismo proceso. , si desea acceder a una variable en otro hilo en el mismo proceso, ciertamente no hay ningún problema al utilizar el mecanismo IPC (comunicación entre procesos) correspondiente.
En cuanto a la pregunta comparativa que planteaste entre UIAutomator y Appium, personalmente lo veo de esta manera:
1. UIAutomator nació del padre biológico (google), por lo que puede. garantizar el desarrollo posterior y la intensidad del mantenimiento, a menos que Google quiebre (no entiendo por qué la actitud de Google hacia Monkeyrunner es tan desconcertante aquí, vea mi comentario sobre MonkeyRunner arriba)
2. , pero desde la fuerza El poderoso padrino, armado con omnipotencia (android, ios, firefox, navegador todo en uno), solo en términos de Android, la capa inferior usa UIAutomator, siempre que pueda mantenerse al día con las actualizaciones. de UIAutomator, no soy un fanático de él en términos de funcionalidad.
3. Pero esta también es la arquitectura de Appium: UIautomator/seledroidlt;-gt;Appium Serverlt;-gt;Selenium/AppiumDriverlt;-gt;Caso de prueba ("Diagrama del marco de arquitectura de Appium"). /zhubaitian/article/details/39453505), lo que hace que el marco sea un poco complicado. Cuando ocurre un problema, es difícil depurarlo y localizarlo. Pero cuando se trata de depuración, es mejor que UIAutomator. Al menos Appium se puede integrar directamente en eclipse para la depuración, pero UiAutomator debe enviarse a la máquina de destino cada vez antes de la ejecución. Hasta ahora sólo sé sobre impresión en bruto.
4. Problema de compatibilidad con versiones anteriores: Appium se puede eliminar a través del UIAutomator/Selendroid subyacente (no recuerdo el nombre); UIAutomator solo se puede eliminar en el nivel de API
17 ( incluido) Se utiliza lo anterior
5. Soporte de lenguaje: appium basic puede matar, UIAutomator usa java. Es suficiente usar java para UIAutomator
6. Multiplataforma: como dijiste, no hay problema con Android. Si necesitas expandirte a ios en el futuro, se recomienda usar appium<. /p>
7. Número de errores: Appium también tendrá problemas que UIAutomator tiene, y Appium puede tener problemas que UIAutomator no tiene^_^ (pero sigo siendo muy optimista acerca de Appium)
8. Si ingresa un problema, si hay un error, consulte mis blogs correspondientes, especialmente las entradas en chino, esta es una de las razones por las que mencioné específicamente Robotum hace un momento
9. soporte: se dice que UIAutomator comenzó a admitirlo a principios de este año. Personalmente, no necesito esto, por lo que no tengo el marco de investigación de Appium y el propio Selenium son los marcos de prueba web de código abierto más populares. PC, por lo que definitivamente serán compatibles. Cabe señalar que debe tener ciertos conocimientos de programación de Android. WebView no solo se refiere al control WebView, sino que también incluye aplicaciones multiplataforma encapsuladas por la vista web de Sencha Phonegap. Si no está seguro, busque en Google.
No se me ocurren otras diferencias en este momento, espero que ayude. Desde mi punto de vista personal, creo que es inevitable que UIAutomator continúe avanzando, pero es poco probable que eventualmente sea compatible con iOS. En cuanto a Appium, también estoy muy seguro de que seguirá avanzando en la dirección correcta y, teniendo en cuenta su soporte multiplataforma, estar basado en node.js (que es muy popular ahora), compatibilidad, etc., me gustaría Considere usarlo si fuera usted Appium (no hablaré de Robotium, si lo piensa de nuevo, debe resumir lo que dije antes ^_^).
Creo que esto es similar a la relación anterior entre Microsoft y Borland. La API pertenece a Windows, pero el IDE pertenece a Borland y ambos realizan sus respectivas funciones. Desafortunadamente (o afortunadamente), el poder de Microsoft sacó a Borland del negocio, pero ese no es el punto. ...
Por cierto, podría limpiar este correo electrónico y publicarlo en el blog con la esperanza de que otros comenten y te den algún consejo. Planeo echar un vistazo al conocimiento de easy_monkey esta noche, y escribirle este correo electrónico se ha convertido en un resumen temporal.
^_^
La respuesta al comentario del Sr. Jin Yangguang es la siguiente (opinión personal sobre MonkeyRunner)
---------------- -------------------------------------------------- -- ---------- ----------------------------------
Respuesta a haoorenmin2008: En primer lugar, adoración, ¡la llegada del Sr. Jin!
Para esto último, sí, UIAutomator requiere API nivel 17 (inclusive) o superior.
En cuanto al primero, debido a que no tengo experiencia con el proyecto MonkeyRunner, no me atrevo a comentar si es muy poderoso. Sin embargo, durante mi prueba reciente, tuve las siguientes ideas inmaduras:
1. Siento que la función no es muy estable. Probé el método getProperty de MonkeyDevice antes, pero a veces tenía éxito y otras fallaba.
2. El rendimiento no es muy bueno, especialmente cuando queremos utilizar la funcionalidad del visor de jerarquía.
3. Solo podemos usar el mismoAs de MonkeyImage para comparar capturas de pantalla, aunque podemos usar su getText agregando el visor de jerarquía, pero aún es muy limitado.
4. El posicionamiento de los controles se basa principalmente en los puntos de coordenadas y las ID proporcionadas por HierarchyViewer. Si el diseño de la interfaz de usuario se ajusta ligeramente, el primero debe seguir los cambios y no hay abstracción de alto nivel. al igual que otros marcos de control, a menos que se cambien los controles, de lo contrario no es necesario cambiarlos; en el último caso, muchos controles no tienen ID o hay varios controles con la misma ID.
5. La depuración no es sólida (al menos no he encontrado un buen método de depuración, como IDE Ecilpse y otros métodos de depuración integrados)
6. La estabilidad de HierarchyViewer también preocupa. En mi caso, encontré varias situaciones en las que se informaron excepciones al obtener información de control.
7. Falta de información, no solo en Baidu, sino también en Google.
8. La API proporcionada por el SDK no coincide con la API oficial. MonkeyDevice es el Por ejemplo, la API proporcionada por el SDK ni siquiera se puede utilizar, y la información proporcionada por Google no supera las 10 páginas, y muchas de ellas son duplicados, problemas reportados por los aturdidos internautas.
9. Además, realmente no puedo entender por qué las bibliotecas escritas por Java tienen que ser llamadas por jython. En primer lugar, no hablo de la pérdida de rendimiento (esto definitivamente está ahí). Por supuesto, la biblioteca nativa se llama en el idioma nativo (el más eficiente), solo quiero el siguiente "device.MonkeyRunner" en eclipse. "dispositivo = MonkeyRunner.waitForConnection()\n dispositivo.", y simplemente llame a un constructor directamente para crear una instancia del dispositivo = MonkeyDevice (xxx). No creo que esto sea un problema con mi configuración. problema con otro. Hay un problema con mi configuración, pero cambié al compilador estándar jython para llamar a la biblioteca estándar y existe el mismo problema.