Pruebas de caja negra / gris de API de descanso y UI

Question

Estamos eligiendo qué sistema para las pruebas de aceptación automatizadas para comenzar a utilizar (cambiar) en nuestra empresa. Actualmente, la mayoría de los casos de prueba de backend están escritos por nuestro ex probador en Python y para nuevos evaluadores es difícil de usar y mantenerlo; Para ui usamos la Robot Framework .

Me gustaría usar algo estándar para que los nuevos "probadores típicos de la calle" puedan comenzar a usar y, sin embargo, debería ser bastante flexible.

En mis trabajos anteriores, los probadores usaban Soapui o incluso Apache Jmeter con scripts groovy, pero por alguna razón, las personas en mi compañía actual no te gusta.

Estamos considerando FITNESSE o marco de robot.

Requisitos:

• Se debe usar para ambos backend (API de reposo, algunos controles de DB) y pruebas de UI
• Debe usar un lenguaje simple, por lo que incluso los no programadores / probador pueden entender los casos de prueba (los propietarios de productos deben poder ver si todos los criterios de aceptación están cubiertos)
• debe apoyar la integración con Jenkins
• Debería admitir la versión de los casos de prueba para que para una versión de producto en particular también podamos visitar los casos de prueba relevantes En este momento usamos TestRail (Prueba de administración de casos SW); así sería bueno si se integra con él (al menos es posible programarlo, así que envíe los resultados de las pruebas allí) o lo reemplaza completamente

Acabo de jugar rápidamente con Fitnesse y para mí, la forma tabular se ve bastante fea. A primera vista, el DOC no es genial (no encontré posibles "comandos", por ejemplo, afirmaciones, algunos bucles) y documentación para, por ejemplo. La residencia es aún peor (ninguna).

También no vi ningún accesorio para los controles de DB. Por lo tanto, al final, un desarrollador debe involucrarse para programar y mantener algunos accesorios personalizados, que para mí se ve peor que use nuestra suite de prueba de Python Python.

¿Alguna idea, experiencia?

gracias, Radek

PS: Hice esta pregunta también en el foro de control de calidad, pero es mucho menos activo que StackOverFlow, lo siento mucho por esta duplicación.

Answer 1

No puedo hablar con el uso de Fitnesse, pero Robot Framework cumple con todas las cosas que solicita y más. Lo elijo para mis proyectos por las siguientes razones:

1. Puede usar una sola herramienta (y, por lo tanto, un solo formato de informes) para SOAP - y Resto Servicios de base, Validación de la base de datos, pruebas de UI basadas en la web , e incluso pruebas de aplicación de escritorio . También se puede utilizar para pruebas de integración y unidad, aunque a menudo hay mejores herramientas para ese trabajo.
2. Puede usar pruebas de robot para implementar pruebas manuales usando la cuadro de diálogos biblioteca, o un personalizado Biblioteca. He visto una aceleración significativa en el rendimiento del probador cuando corrieron pruebas manuales escritas en robot que al ejecutar pruebas similares escritas en Microsoft Word. Desafortunadamente, no se escribe mucho en la web sobre esta poderosa característica, pero puede obtener el mismo tipo de informes, control de versiones, etiquetado, etc. Características para todas sus pruebas de aceptación, tanto manuales como automatizadas.
3. Si invierte el tiempo en la creación de una buena biblioteca de palabras clave, las pruebas pueden ser fácilmente legibles (y ser escritas) por no probadores
4. Hay una complemento robot para Jenkins que hace navegar resultados de la prueba fácil
5. Robot Framework Test Suites son archivos de texto sin formato , por lo que Pueden ser versionados justo al lado de su código.
La salida de prueba
6. es un archivo XML muy fácil de entender y analizar. También puede generar Salida de estilo XUNIT para la integración con otras herramientas. El robot también viene con herramientas para convertir este XML a registros e informes que respetuosos humanos. La interfaz de oyente hace que sea fácil capturar o transmitir resultados de prueba en vivo .
7. Hay un número creciente de Herramientas y complementos de editor que funcionan con Robot, para que los miembros de su equipo puedan usar Las herramientas con las que están más cómodas.
8. Robot es muy extensible - Las bibliotecas de palabras clave pueden ser Escrito en casi cualquier idioma, de forma nativa en Python, así como Java, si corres con Jython, o .NET, idiomas si corres con IronPython. Y con el Interfaz de biblioteca remota , puede escribir palabras clave en cualquier El lenguaje que puede abrir un zócalo y actuar como servidor.

En cuanto a los accesorios para las pruebas de DB, hay un genérico biblioteca de base de datos basada en Java , y un genérico Biblioteca de base de datos basada en Python que puede conectarse a cualquier base de datos común . También hay una biblioteca específicamente para hablar con mongodb .

Relacionado con la pregunta que tenía sobre el control de versiones, Robot tiene un muy poderoso > Mecanismo de etiquetado que puede encontrar útil. Podría, por ejemplo, etiquetar todas las pruebas con la versión del producto con las que van. Luego, simplemente echa un vistazo a todo, pero use robots Opciones de línea de comandos < / a> para seleccionar solo las pruebas etiquetadas con una versión en particular. Como beneficio comercial del etiquetado, los informes descomponen las estadísticas de paso / falla por etiqueta.

Robot no es un sistema de prueba perfecto, pero es muy bueno. Argumentaría que hay muchos marcos de prueba igualmente buenos, pero no estoy seguro de que hay que sean objetivamente mejores. Ciertamente, para las cosas que enumeró que son importantes para usted, Robot Framework hace todo lo que necesita.

Answer 2

Estaba en un escenario casi similar antes. Tuvimos que decidir entre RF, FITNESSE e IBM's STAF / STAX

Elegimos el marco de robot y funcionó bien.

1. se debe utilizar para ambos backend (API de descanso, algunos controles de DB) y UI Pruebas: para el descanso, RF's solicitudes Biblioteca junto con varias bibliotecas de DB se pueden usar juntas.
2. debe usar un lenguaje simple, por lo que incluso los no programadores / probador pueden comprender los casos de prueba (los propietarios de productos deben poder ver Si todos los criterios de aceptación están cubiertos): la RF está destinada a hacer precisamente esto.
3. debe apoyar la integración con Jenkins - RF tiene una jenkins Plugin
4. debe admitir la versión de los casos de prueba para que para un particular Versión del producto También podemos ver los casos de prueba relevantes en este momento - RF's Etiquetas

   Existe un marco de robot API , por lo que es bastante programable según Los requisitos de integración.