2010-04-17 15 views
7

¿Hay alguna razón para automatizar las pruebas que se centran en la GUI (y no en las cosas que están debajo)? En mi opinión, la GUI (y los cambios en ella) siempre debe ser probada por una persona real.¿Las GUI deben tener sus propias pruebas automatizadas?

¿Qué se puede ganar con las pruebas automáticas de enfoque de GUI? Mi propia experiencia ha sido que las pruebas de enfoque GUI casi siempre se rompen porque alguien cambió algo por una buena razón. Rara vez parecen encontrar algo interesante.

Respuesta

4

Esta es una pregunta difícil. Las herramientas y los marcos de prueba automatizados hacen un gran trabajo y bien valen la pena el tiempo y el esfuerzo siempre que la GUI no cambie demasiado. El problema con las pruebas automatizadas es que se descompone precisamente cuando más lo necesita: cuando la GUI cambia rápidamente durante un ciclo de desarrollo.

Como resultado, he establecido un enfoque híbrido para los proyectos que lidero y administro. Me gusta usar pruebas manuales en áreas de la GUI que cambian rápidamente durante un ciclo de desarrollo. Una vez que las cosas están bastante estables, hacemos algún tipo de prueba automática de GUI (por ejemplo, Selenium para aplicaciones web) que incluimos en el proceso de compilación para evitar regresiones futuras. Si es posible, las personas de QA escriben las pruebas automáticas. A veces los desarrolladores tienen que vincularse con los verificadores de QA para hacer esto cuando la herramienta automatizada es demasiado codificada.

Este enfoque híbrido parece funcionar bien siempre que utilicemos buenas prácticas de diseño que separen las preocupaciones adecuadamente para que las pruebas unitarias puedan ejercer toda la lógica subyacente correctamente. Lo único que debe evitar es entrelazar la lógica de la aplicación en la capa de la GUI.

+0

Estoy de acuerdo con su enfoque de "crear pruebas automatizadas al final del ciclo de desarrollo", cuando la GUI es más estable. Escribir pruebas automatizadas para una GUI es muy difícil de hacer en una GUI que cambia constantemente. –

0

Depende de "qué" parte de la GUI que prueba. ¿Probas el comportamiento del sistema mediante la ejecución de una prueba GUI, o quieres probar si tu GUI se muestra correctamente en todo momento?

En este último caso, depende de su aplicación. Si el diseño y el diseño son importang, estoy de acuerdo. Sin embargo, si se trata de una aplicación donde la funcionalidad central no es el diseño en sí, no tiene sentido invertir tiempo para el diseño de prueba. Sería mejor escribir una prueba GUI que pruebe la funcionalidad mediante el uso de la GUI en lugar de algunas llamadas a funciones. De esta manera, el comportamiento real se simula mejor.

0

Los humanos son excelentes para probar GUI. Sin embargo, son caros. Las herramientas de prueba automatizadas, al menos teóricamente, disminuyen el costo de probar las IU. Si lo suelta con frecuencia, el tiempo de prueba de IU manual puede ir muy rápido.

yo personalmente nunca han herramientas de pruebas de interfaz de usuario automatizados visto pagar empacar sus costos de instalación, para los proyectos en los que he estado. Sus pruebas tienden a ser frágiles y no reaccionan bien a los cambios de diseño. Por esa razón, dudo en poner mucha confianza en ellos. Sin embargo, estaría feliz de haber demostrado que estaba equivocado.

0

Eso es posible. Para el navegador, tiene trajes de prueba como el selenio, que interactúan con el navegador.

2

Depende.

Si su GUI es una capa relativamente delgada sobre su lógica comercial y los errores menores en la GUI no son críticos para su negocio, entonces puede optar por no perder tiempo probando su GUI exhaustivamente con pruebas unitarias. Ese tiempo quizás podría invertirse mejor en la prueba de código más crítico.

Si su interfaz gráfica de usuario es muy sofisticado y es un gran punto de venta para su aplicación, entonces es posible que puede que desee invertir tiempo en las pruebas de que tanto automática como manualmente. Las pruebas automáticas no reemplazan por completo las pruebas manuales, ya que todavía necesita verificadores humanos para asegurarse de que la GUI se vea correcta y de que la interfaz sea clara e intuitiva.

Consulte Wikipedia para obtener más información sobre la prueba de GUI, por ejemplo, registrando el mouse y la entrada de clave y repitiéndolo. También hay a list of software que pueden ayudarlo a crear pruebas de unidades GUI.

+0

Nunca antes había oído hablar de * GUI * no importante. –

+2

@Robert Harvey: Una GUI que solo será utilizada por personal interno, quizás solo por otros desarrolladores, puede no requerir tantas pruebas como una GUI que se envía a sus clientes. Debe hacer un análisis de costo-beneficio. –

0

Mi enfoque en esta situación es por lo general a las capas no gráficos unidad de prueba, el uso de pruebas automatizado para la interfaz gráfica de usuario lo más lejos posible y luego probar manualmente todo lo que queda. También utilizo pruebas manuales para la detección ad-hoc de defectos para identificar casos de prueba faltantes.

Para mí, esto proporciona la mejor relación entre la cobertura de prueba y el costo. En última instancia, depende de lo que esté tratando de lograr: ¿se trata de un software de misión crítica o de una aplicación simple en la que la falla es puramente un inconveniente?

0

Es mejor dejar que la prueba de usabilidad sea lo primero. Además, ¿cómo vas a probar la unidad de interfaz gráfica de usuario? ¿Cuál sería la salida? Si alguien hace clic en algo y obtiene lo que "inicialmente" estaba buscando? ¿Qué se debe considerar un comportamiento no aceptado?

Obtendrá toneladas de bullcrap para mirar. La usabilidad es una gran palabra, pero la prueba de usabilidad simple es contratar a un compañero tuyo (preferiblemente no a alguien que conozcas, un amigo de un amigo) que puedas considerar como el "público objetivo" de la aplicación. Poner en una camtasia/camstudio (software de grabación de escritorio, podría ser bueno para grabar su cara). Dale algunas tareas en un pedazo de papel (o en persona, a veces el papel es mejor porque no interferirás - un escenario más realista). ¡Y mira lo que está haciendo!

Si necesita ayuda, verá secciones de atención para su desarrollo futuro. Nunca intentes influir en el chico diciéndole cosas como "pero mira aquí está este botón, pensé que era más conveniente de esta manera".

Obtendrá resultados mucho mejores de dicha prueba, en lugar de perder el tiempo con las pruebas de computadora a computadora. GUI es una INTERFAZ entre humanos y computadora. Gui de prueba de unidad es como tratar de analizar el libro que acabas de escribir y ver si es bueno. Claro, eliminará los errores de corrección ortográfica, por ejemplo, pero es una cosa muy pequeña -> en comparación con los objetivos reales del libro.

+0

Las pruebas de usabilidad no son realmente lo mismo que las pruebas automatizadas, y no tienen los mismos objetivos. –

+0

Estoy seguro. Pero veo poco sentido en la interfaz de prueba de la unidad. Demasiadas operaciones y datos para obtener resultados. Sé que hay compañías que hacen pruebas pesadas como esta. Convertir supercomputadoras grandes para escribir en formas todo lo que sea posible, hasta ahora parece una pérdida de tiempo para mí. –

0

Sí, por supuesto GUis debería tener sus propias pruebas unitarias. Ver por ejemplo IcuTest.

El problema es que las pruebas de interfaz gráfica de usuario es complicado. Una vez que tienes eso resuelto, el mundo es tuyo.

0

Si tiene tareas repetitivas y monótonas en las pruebas de la GUI y necesita hacer eso para múltiples combinaciones de navegadores y sistema operativo, vale la pena automatizar la GUI. Con las técnicas de mantenimiento, la famosa pregunta "Los cambios de la interfaz de usuario harán que la automatización sea irrelevante" puede ser respondida.

Cuestiones relacionadas