Pruebas de aplicaciones web con FitNesse y soapUI: ¿alguna práctica recomendada sobre administración y mantenimiento de pruebas?

Question

Para todos los expertos en automatización de pruebas :-)! Me gustaría escuchar sus opiniones sobre el siguiente escenario:

Hay una aplicación web que debo probar. Tengo que ejecutar pruebas de back-end en el servidor y pruebas de front-end en el cliente. También necesito ejecutar pruebas de extremo a extremo, involucrando tanto el back-end como el front-end.

El servidor expone servicios web (SOAP) y el cliente de aplicaciones para el usuario consume datos de estos servicios. También hay clientes de terceros que consumen datos de los servicios web. A veces, un escenario de prueba requiere que realice pruebas de extremo a extremo, es decir, realizo algunos cambios en la GUI del front-end y luego uso un servicio web en el back-end para averiguar si los cambios fueron exitosos o no.

Me gusta FitNesse - en mi opinión, la separación de WHAT y WHY de HOW es esencial para diseñar buenas pruebas. Está el módulo Selenesse, que permite integrar las pruebas de Selenium con las páginas wiki de FitNesse. Esto hace que sea fácil describir qué y por qué necesito probar algo (texto wiki) a partir de cómo quiero probarlo (tablas de escenarios y tablas de guiones) que es como quiero que sean las cosas.

El problema con FitNesse es que es algo engorroso probar los servicios web SOAP. O bien, necesito desarrollar un accesorio Java para el cliente SOAP especialmente diseñado, o tengo que escribir los dispositivos Java que extienden la clase ServiceFixture, escritos para FIT. De cualquier manera, el esfuerzo de desarrollo es significativamente mayor que si implemento estas pruebas en soapUI.

En mi opinión, el inconveniente con soapUI, es que no hay una manera fácil de explicar el QUÉ y el POR QUÉ de una prueba (al menos no de una manera que sea intuitiva).

Por lo tanto, suponiendo que deseo un esfuerzo de desarrollo razonable para las pruebas de extremo a extremo, me he conformado con el enfoque de escribir pruebas de GUI en FitNesse/Selenesse y pruebas de back-end en soapUI. Ahora tengo la opción de intentar ejecutar pruebas de soapUI desde FitNesse, administrar todas las pruebas allí o ejecutar pruebas de FitNesse desde soapUI ...

Tengo algunas preocupaciones con respecto a la administración de pruebas (no es tan fácil ver los resultados de las pruebas en una vista) y mantenimiento (dos herramientas con diferentes idiomas) de este enfoque. ¿Tiene alguna idea de la mejor/buena práctica con respecto a esto? ¿Sugeriría una tercera herramienta para manejar los otros dos?

Answer 1

¿Utiliza alguna herramienta de integración continua como hudson, bambú?

Estoy haciendo esta pregunta porque sugiero que prefiera el enfoque de integración continua para que pueda tener la oportunidad de probar las aplicaciones automáticamente después de cada commit/build.

Quiero decir que si usa hudson o bambú puede tener la oportunidad de ejecutar sus pruebas después de que un desarrollador haya confirmado algo. Y, además, puede ejecutar su prueba de forma programada.

Otra ventaja es que estas herramientas (hudson/bamboo) pueden registrar los scripts de prueba y pueden enviar un correo electrónico en caso de error/éxito (su elección). Para que pueda supervisar sus pruebas fácilmente.

Y también tiene la oportunidad de ejecutar selenio y soapUI en paralelo o consecutivamente.

---

También tengo algunas sugerencias sobre las pruebas de soapUI.

Cuantos más casos de prueba tenga, más tiempo tendrá para desarrollarlos, ejecutarlos y mantenerlos. El punto importante es considerar la mantenibilidad al diseñar las pruebas.

Si una aplicación tiene múltiples servicios web disponibles, los WSDL están obligados a cambiar y deben actualizarse en SoapUI. Con todo en un solo proyecto soapUI, solo necesita actualizar los WSDL en un solo lugar, no en múltiples proyectos. Entonces crea solo un proyecto soapUI para una aplicación.

Luego necesita crear casos de pruebas y conjuntos de pruebas.

Incluya todos los flujos principales de servicios (escenarios de éxito) en un solo conjunto de pruebas de regresión. Las solicitudes de los servicios web deben ordenarse de acuerdo con el flujo de negocios lógico. Por ejemplo, si prueba los servicios web de una tienda en línea, primero debe buscar el artículo y luego comprarlo. Si mantiene este orden comercial lógico en sus pruebas soapUI, puede establecer fácilmente una única variable global para cada paso de prueba. Quiero decir, en el primer paso puede buscar el elemento X y luego comprar el mismo artículo, de esta manera permite establecer una variable global para el elemento X. Es más fácil mantener o extender un proyecto soapUI. Tiene la oportunidad de crear una fuente de datos y recopilar variables (diferentes elementos en nuestro ejemplo de tienda en línea) y extender el caso para esos elementos en un bucle.

Answer 2

Le recomiendo que cree un conjunto de pruebas con soapui y que informe los resultados de las pruebas con jenkins.

Puede ejecutar pruebas de soapui y pruebas de fitnesse con jenkins y genrate xml test result file. Esta configuración es realmente útil al construir pruebas end2end. Podemos vincular muy bien cualquier conjunto de pruebas o pruebas junto con Jenkins y tienes una gran manera de presentar y preservar los resultados de las pruebas.

Al enfocarme en un componente activo, hacer las cosas en el sprint o la aplicación completa no es lo suficientemente estable como para invertir mucho esfuerzo en la prueba de trabajo end2end, creo que debería enfocarse en trabajar soapui test por separado.