c++ - loglevel - Uso de Robot Framework para ATDD

robot framework replace

Question

Me gustaría escuchar la experiencia de otras personas con Robot Framework para las pruebas de aceptación automatizadas.

¿Cuáles son sus principales fortalezas y debilidades, así como cualquier comparación con otros marcos (principalmente Fitnesse y Selenium)?

El código que se probará es el código heredado en tiempo real, principalmente en C ++.

Answer 1

Utilicé el framework Robot para los siguientes escenarios
Prueba de UI
1. Robot framework es realmente bueno para probar ui 2. Framework viene con el editor Ride que se puede usar para escribir casos de prueba. 3. No necesita ser experto en selenio y los comandos de selenio se pueden buscar en el Editor de andar. 4. Puede tener código compartido usando palabras clave y compartidas
recursos. Le permite simplemente reutilizar casos de prueba y probar el código de la biblioteca. 5 Puede llamar fácilmente a la función de biblioteca python para realizar tareas más tediosas.

Para las pruebas de servicio , encontré que Robot framework era un poco difícil de usar para el tipo de automatización de prueba que estaba llevando a cabo.
. Nuestra capa de servicio de aplicaciones está completamente escrita en C / C ++. Personalmente trabajo en la computadora portátil con Windows y nuestra aplicación reside en el servidor de Linux.
Encontré el framework fitnesse mucho más útil y más simple de hacer la automatización. Fitnesse tenía características extra mencionadas que permitían escribir casos de prueba fácilmente. No pude encontrar características similares en Robot.

Tabla de decisiones : puede escribir casos de prueba en formato Microsoft microsoft xls. Cada fila en la cuadrícula de datos representará un caso de prueba. Cada fila tendrá un conjunto de entradas y salidas. Las salidas irán precedidas de un signo de interrogación en el encabezado.

Tabla de consulta : la salida de la prueba será una lista de datos que desea validar.

También fitnesse permite una fácil integración con otros lenguajes como C (usando Slim Service). Esto no requiere ninguna codificación de integración. Los casos de prueba de Fitnesse ejecutan directamente aparatos de prueba, getters, setters.

Resumen de mi experiencia:

• Encontrado fácil de usar para la automatización de la interfaz de usuario.

• Me pareció un poco difícil de usar para la automatización del servicio.

Answer 2

Hemos estado utilizando Robot Framework en mi lugar de trabajo desde hace más de un año con un éxito moderado. Al igual que el póster, también hacemos trabajos en C ++. Nos tomamos un tiempo para evaluar Robot contra Fitnesse / Slim y, en ese momento, ambas soluciones eran buenas, pero los factores decisivos fueron (a partir de ~ 2009):

• Era más claro cómo Robot y sus informes se adaptarían a grandes proyectos
• No era obvio cómo controlar la versión de los artefactos de Fitnesse

Desde una perspectiva técnica, hemos estado utilizando SWIG para tender puentes entre Robot y C ++. Envolvemos nuestros accesorios de prueba en SWIG y lo vinculamos con el código de producción bajo prueba, dándonos un módulo de python que puede ser importado por Robot.

Usamos el formato .txt para la entrada de Robot casi exclusivamente: descubrimos que esta versión controla mejor, es más fácil de leer y simplemente no usamos las funciones avanzadas de HTML (que es donde comenzamos). Además, también estamos utilizando la sintaxis Robot "BDD Style" . Usamos GoogleMock con algunas envolturas para ayudarnos a establecer expectativas que se verifican durante el desmontaje de cada prueba de Robot.

En cuanto a organizar las pruebas, nos hemos basado en el siguiente enfoque (con inspiración del enfoque de Dale Emery dado aquí ):

• La jerarquía funcional principal está representada por una estructura de carpetas.
• Una cosa de tamaño de característica se describe en un nombre de archivo de prueba de Robot.
• Se usa una descripción de cada parte de esa característica en el nombre de caso de prueba de Robot.
• Un ejemplo se da como los pasos en el caso de prueba.
• El texto de ejemplo se divide en pasos usando las "palabras clave" de Robot.
• El dispositivo de prueba maneja el código de producción.

Por ejemplo, un teléfono podría tener algo como esto:

//  PhoneProject/MakingCalls/DialAPhoneNumber.txt

*** Test Case ***
A user can dial a US number with an area code, up to 10 digits
   Given a phone without any numbers dialed
   Expect the attempted phone number to be 123-456-7890
   When a user enters the numbers 1234567890


// A separate MakingCallsKeywords.txt or something similar
*** Keyword ***
Given a phone without any numbers dialed                CreateNewDialer
Expect the attempted phone number to be ${phoneNumber}  ExpectDialedNumber  ${phoneNumber}
When a user enters the numbers ${numbersEntered}        DialNumbers ${numbersEntered}

// MakingCallsFixture.cpp  (which gets wrapped by SWIG)

std::wstring MakingCallsFixture::DialNumbers(const std::wstring& numbersEntered)
{
   ... Drive production code ...
}

// CreateNewDialer, ExpectDialedNumber also go here

Luego emparejaríamos esto con pruebas unitarias que cubran las condiciones de la esquina (por ejemplo, asegurarnos de no permitir más de 10 dígitos) - o tal vez esa sería otra prueba de aceptación (especificación ejecutable) dependiendo de quién está leyendo las pruebas y su familiaridad con la dominio.

Creamos un borrador de estas especificaciones y lo revisamos con expertos de dominio y el equipo antes de comenzar a trabajar. Esto ha ayudado a aclarar una serie de malentendidos desde el principio.

Answer 3

Utilicé Robot Framework en tres compañías diferentes que abarcan aproximadamente seis años en el momento en que escribo esto, y todas han sido exitosas de una manera u otra.

Mis experiencias

Empresa 1

El primer lugar que utilicé Robot fue una aplicación web basada en Java para una compañía de viajes de Internet de primer nivel. Utilizamos Robot con Jython, que nos permite crear palabras clave en Java y actuar directamente con el sistema bajo prueba. Usamos selenio para manejar el navegador web, con la mayoría de nuestras pruebas en Firefox. Si bien el esfuerzo de prueba fue en gran medida exitoso con la organización de control de calidad, la organización de desarrollo no pudo abrazarlo, prefirieron usar JUnit en lugar de Robot.

Compañía 2

Mi segunda compañía, creo, fue un éxito rotundo. Usamos Robot de muchas maneras. El uso principal fue conducir IE para la aceptación y la prueba de regresión de una aplicación web .NET comercial de gran éxito. También lo usamos para probar una aplicación de iPad combinando selenio con appium. Usamos Robot para probar los servicios RESTful que suministraron datos a la aplicación. Escribimos palabras clave especializadas que nos permiten hacer análisis de imágenes, y también utilizamos pruebas de Robot para hacer un análisis rápido de nuestro equipo de entrenamiento antes de cada sesión de entrenamiento. Tuvimos palabras clave que nos permiten tomar una instantánea de una base de datos antes de una prueba, y restaurar la base de datos después de una prueba.

También comenzamos a usar Robot para ayudar con las pruebas manuales. Colocamos casos de prueba manual en Robot, lo que nos permite aprovechar las funciones de informe y etiquetado de Robot. Cuando se ejecutaran estas pruebas, solicitarían al usuario realizar los pasos manuales, lo que resultó ser mucho más eficiente que cuando los verificadores leían los pasos manuales de una herramienta de administración de casos de prueba o un documento de Word.

Compañía 3

La tercera empresa era una gran empresa (ingresos de $ 1B) con un personal de TI bastante grande. Tenían probadores con muy poca habilidad técnica (recuerdo uno que no tenía idea de lo que era una línea de comando). Contamos con un equipo dedicado a escribir un conjunto básico de palabras clave y a proporcionar capacitación y asesoramiento a los otros equipos. Creo que el uso del robot fue decisivo para sacar provecho de los probadores menos capacitados, aunque incluso con palabras clave de alto nivel fue una lucha con ellos.

Compañía 4

Más recientemente, me mudé a una empresa muy pequeña con solo un puñado de desarrolladores y sin testers dedicados. Abrazamos el uso de objetos de página con framework de robots y ahora contamos con un conjunto excepcionalmente estable de pruebas de aceptación de alto nivel fácilmente legibles. El uso del robot en esta empresa ha sido un éxito rotundo.

Fortalezas

La mayor fortaleza del Robot es su flexibilidad. Hemos utilizado Robot para admitir pruebas manuales, pruebas de servicios SOAP y REST, pruebas de interfaz de usuario basadas en la web, pruebas de bases de datos, pruebas de imágenes y pruebas de aplicaciones móviles. Debido a que Robot es tan fácil de extender con bibliotecas adicionales, no hay casi nada que no puedas probar si estás dispuesto a arremangarte y escribir algunas palabras clave. Dependiendo de su configuración, puede escribir palabras clave en Python, Java, .NET o prácticamente cualquier idioma a través de la API remota de Robot.

Debido a que los casos de prueba de Robot y las palabras clave están escritos en texto plano, no está bloqueado para usar una herramienta patentada para crear o ver pruebas. Los usuarios pueden elegir la herramienta que elijan: Visual Studio, Eclipse, Emacs, Bloc de notas, etc. También hay un IDE específico del robot (RIDE), aunque no lo recomiendo. Además, como los archivos son de texto plano, se integran bien con otras herramientas de software: son fáciles de diferenciar y fusionar, buscar, etc.

Debilidades

Robot hace que sea fácil escribir pruebas de baja calidad. Si bien hay instalaciones para documentar palabras clave y casos de prueba, y para usar nombres legibles por humanos para palabras clave, casos de prueba y variables, no hay una buena forma de aplicar las mejores prácticas. Escribir un gran conjunto de pruebas y palabras clave requiere disciplina. Como dice el refrán, Robot te da muchas sogas para ahorcarte.

Otra debilidad es que el ritmo del progreso en Robot es bastante lento. En el lado positivo, Robot es robusto y relativamente libre de errores por lo que no hay una gran necesidad de parches frecuentes. Sin embargo, hay solicitudes de funciones que languidecen en su rastreador de problemas durante años sin movimiento, lo que puede ser desalentador.

Resumen

En todas las compañías hemos disfrutado de poder aprovechar la flexibilidad proporcionada por la sintaxis de Robot para crear pruebas basadas en datos, pruebas de estilo BDD, así como pruebas de procedimientos simples. Y en todos los casos, debido a que las pruebas son archivos de texto plano, los activos de prueba fueron fáciles de administrar con nuestras herramientas de SCM (Mercurial, Subversion, Git)

Para mí, Robot ha demostrado ser fácil de usar, extremadamente fácil de extender y útil para una amplia gama de tareas de prueba, desde pruebas unitarias de funciones de Python, hasta pruebas de servicios web, pruebas de interfaz de usuario basadas en navegador y tableta, el prueba de imágenes, pruebas de bases de datos e incluso para mejorar la eficacia de las pruebas manuales.