Contenido

Introducción

El objetivo de este artículo es exponer esta normativa es facilitar a los proveedores una serie de directrices relacionadas con pautas para la correcta implementación de las pruebas funcionales automatizadas. Es importante señalar que esta página es sólo una parte de la normativa que está pendiente de publicar.

En ella van a aparecer tanto frameworks a utilizar como estrategias a la hora de la organización del código. En lo relacionado con las herramientas necesarias Con respecto a las herramientas necesarias para llevar a cabo la automatización de las pruebas, el documento se basa en la triada Gherkins-Cucumber-Selenium. Sólo las dos primeras (Gherkins y Cucumber) son de obligado uso. El equipo de arquitectura junto con la OCa evaluará cualquier propuesta alternativa a Selenium que se pretenda utilizar.

Estructura del proyecto

DIRECTRIZ 1:  Nombre y ubicación del código

La pruebas automatizadas se agruparán en un módulo de la aplicación llamado <nombre-proyecto>-testproject.

DIRECTRIZ 2: Carpetas principales

Directorio es.ja.csalud.sas.$sistemaInformacion$.cucumber. Contendrá los siguientes paquetes:

...

Directorio es.ja.csalud.sas.$sistemaInformacion$.integración. Para el caso en el que se vayan a implementar pruebas de integración, este paquete contendrá los XML necesarios para realizar pruebas a los web services y que son implementados en la herramienta SoapUI.

Buenas prácticas

DIRECTRIZ 3: Uso de Page Object Model

La ejecución automatizada de un conjunto de pruebas funcionales requiere de un modelo de clases que de soporte a su implementación y que sirva de marco para cualquier proyecto desarrollado por y para la STIC. Para ello, el patrón a seguir es “Page Object” que consiste en crear un objeto por cada conjunto de elementos significativos de la interfaz con la que se interactúa. Aunque el nombre sugiera (y generalmente suceda) que cada objeto debe representar una página de la navegación del sistema de información, si dentro de la página existen componentes visuales reutilizables en otras partes, es necesario construir un Page Object de ese elemento para poder reutilizarlo. De esta forma, si se realiza un cambio en la interfaz de usuario, el cambio solo se realiza una única vez, y éste se vea reflejado en todos los test del sistema.

...

Por tanto, se encuentran las clases Page Objects donde se ha de implementar los elementos de la interfaz de usuario que permiten interactuar con el sistema de información. Y por otro lado las clases de test con las pruebas a realizar, donde se desarrolla la lógica del test utilizando los elementos descritos en las clases Page Object. Por último, es necesario y fundamental tener presente los distintos navegadores donde se pueden ejecutar los casos de prueba.

DIRECTRIZ 4: Implementación de la clase Page Object

Para la codificación de cada clase page object se utilizarán los métodos proporcionados por Selenium para interactuar con los diferentes elementos de la página web, como por ejemplo:

...

• Hacer click en un botón o enlace elemento.click();
• Escribir información en un campo de texto elemento.sendKeys(“Texto a introducir”);
• Recuperar el texto de un elemento: elemento.getText();
• Verificar si el elemento se encuentra disponible en la página inputSearch.isDisplayed();

DIRECTRIZ 5: Uso de framework y librerías

Para la codificación de las pruebas automatizadas se recomienda el uso del siguiente conjunto de herramientas:

• JUnit: Framework para la ejecución de test unitarios y de integración.
• TestNG: Framework basado en JUnit pero que cubre el espectro completo de pruebas: unitarias, integración, funcionales, end-to-end…
• Selenium: Framework para la ejecución de scripts de pruebas sobre un navegador web.
• LogBack: Framework para la generación de trazas. Teniendo que guardar en ellas los pasos del proceso de cada prueba.
• Librería de Utilidades: Se recomienda el uso de una librería de Utilidades que ha sido desarrollada por el equipo de la Oficina de Calidad y que contiene las acciones básicas para inicializar el driver, escribir el log, etc. A continuación se describe cómo hacer buen uso de ella, así como alguna de sus funcionalidades.
  •  Se tendrá que instanciar un objeto de tipo UtilSelenium y la clase que instancie el objeto UtilSelenium hereda de la clase BasePrueba de la librería. Para instanciar dicho objeto se utiliza el método getInstancia el cual recibe tres parámetros. 
    • Nombre del log
    • Navegador a utilizar en la prueba
    • Versión del Selenium WebDriver a utilizar
  • imprimirPaso: Utilizado para escribir en el log el paso X (autoincremental) y la información que se pasa como texto como resultado de la realización de dicho paso. Recibe un parámetro String con la descripción del paso a realizar.
  • getLogger: Embebe las utilidades del LogBack dentro de la librería.
  • getDriver: Embebe las utilidades del WebDriver dentro de la librería.
  • imprimirResultadoEsperado: Comprueba el parámetro que indica si la prueba ha ido bien con un Assert y escribe en el log dicho resultado. Este método recibe un parámetro Booleano que indica si la prueba ha ido bien o no.
  • cerrarDriver finaliza la instancia del objeto UtilSelenium.
    
    

Redacción de pruebas

DIRECTRIZ 6: Uso de Gherkin

Cada caso de prueba deberá contener definido el escenario de la prueba a realizar en lenguaje GHERKIN pudiendo elegir entre los tipos “Scenario” o “Scenario outline” (caso de prueba parametrizado mediante una tabla).

...

| valor1      | valor2     | etiqueta   | salida   |

DIRECTRIZ 7: Etiquetado

La REST API de X-ray permite la importación de archivos .feature de Cucumber a JIRA. Esto es una manera de crear los tests, de forma masiva y automática, asociándolos a la historia de usuario y a las pre condiciones necesarias para la ejecución de la prueba.

...

Toda la información relacionada con este tema puede consultarse pulsando en el siguiente enlace: https://confluence.xpand-it.com/display/public/XRAY/Importing+Cucumber+Tests+-+REST 

Codificación de pruebas

DIRECTRIZ 8: Codificación de tests unitarios

Para la ejecución de las pruebas dentro del flujo de integración continua, es necesario crear las clases de tipo TestNG. Para la codificación de cada clase TestNG se utilizarán mínimo las siguientes anotaciones:

...

Aquellos tests en los que no sean necesario incluir su ejecución por el momento se pueden excluir de la ejecución global indicándolo en el XML Suite de la siguiente forma:

DIRECTRIZ 9: Uso de cucumber

Para la codificación de cada background y de los pasos de cada scenario se utilizarán las siguientes keywords:

...

Para la ejecución de las pruebas dentro del flujo de integración continua, es necesario crear una clase lanzadora con la siguiente información como mínimo:

DIRECTRIZ 10: Etiquetado

A continuación se describen un conjunto de tags a usar para la ejecución o no de escenarios durante las pruebas. Los tags son anotaciones que sirven para agrupar y organizar escenarios e incluso features, estos se escriben con el símbolo @ seguido de un texto significativo. Ejemplos:

...