Contenido

Introducción

El objetivo de esta normativa es facilitar a los proveedores una serie de pautas para la correcta implementación de las pruebas funcionales automatizadas.

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 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:

• es.ja.csalud.sas.$sistemaInformacion$.cucumber.feature
  

 Incluirá tantos directorios como subsistemas tenga el proyecto a automatizar con los archivos .feature que corresponderán a los diferentes casos de pruebas.

• es.ja.csalud.sas.$sistemaInformacion$.cucumber.testrunner

Contendrá las clases lanzadoras de las pruebas para Cucumber

• es.ja.csalud.sas.$sistemaInformacion$.cucumber.stepdefinition

Este directorio stepdefinition también podrá estar dividido por subsistemas. Tendremos tantas clases como casos de pruebas. Estas clases tendrán instanciada un objeto de la clase caso de prueba con la coletilla step (por ejemplo CP001_001step) y tantos métodos (paso1) como pasos tenga dicho caso de prueba. También, deben tener como mínimo la llamada a los métodos imprimirPaso e imprimirResultadoEsperado de la librería utilidades (consultar el apartado correspondiente) para verificar que se está realizando el paso y cómo ha finalizado.

• es.ja.csalud.sas.$sistemaInformacion$.cucumber.step

El directorio step contiene las operaciones a bajo nivel. Habrá una clase por cada funcionalidad que tiene la aplicación.

• es.ja.csalud.sas.$sistemaInformacion$.cucumber.pageobject

Las clases que contendrán el DOM de los elementos  de la aplicación a automatizar, o el patrón Page Object Model.

• es.ja.csalud.sas.$sistemaInformacion$.cucumber.common

En el caso de no utilizar la librería "Utilidades" ofrecida por la OCA, es necesario la creación de un paquete "common" en el que se inicialicen los distintos navegadores para los que está certificada la aplicación.  Además, deberá contener los métodos que sean reutilizables para todos los elementos, como las esperas (implícitas o explicitas), la generación de capturas de pantalla o la interacción con el log.

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.

El patrón indicado se sustenta bajo el siguiente modelo:

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:

• Para la identificación de los elementos, sobre los que se interactúa en la prueba, es necesario la utilización de un id único en la etiqueta de cada componente.

Ejemplo:

<div id="page">

<div id="full-height-container">

<div id="header-precursor">

...

• 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).

Dentro de las features solo debe incluir información relativa al negocio, y nunca aspectos técnicos de configuración; estos irían dentro de profiles o directamente en los pipelines del Jenkins.

A continuación se indica un ejemplo de para la descripción de un caso de prueba utilizando Gherkin:

Scenario: descripción del escenario a ejecutar

     Given  Cumplo una precondición

     [And]

     When [Ejecuto una acción]

     Then [Observo este resultado]

     But [No debería poder observar este otro resultado]

Scenario outline: descripción del escenario parametrizable a ejecutar

Given  Cumplo una precondición con <input_1>

[And] y cumplo con <input_2>

When Ejecuto una acción sobre <button>

Then Observo este resultado <output>

But No debería poder observar este otro resultado

Examples:

| input_1   | input_2   | button     | output  |

| 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.

Las asociaciones se realizan mediante etiquetas:

• Al inicio del archivo se colocará la etiqueta @id_historiaDeUsuario. Es importante señalar que el id de la historia de usuario al que nos referimos es el correspondiente al del JIRA de la STIC.
• En lo relativo a las pre condiciones, se crearán tantas como la palabra "Given" aparezca tras el Background. Si la pre condición ya estuviese creada, se podrá enlazar a la prueba colocando la etiqueta @id_precondicion, donde el id de la pre condición será el del JIRA de la STIC.
• Se creará una prueba por cada escenario. Las etiquetas obligatorias que deberán colocar sobre cada escenario serán: @id (identificador único). @AUTO_Nombre del proveedor (por ej.: @AUTO_INDRA o @AUTO_EVERIS) y @nombre_componente (si la aplicación está dividida en subsistemas).

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:

• @DataProvider: Es un método para suministrar los datos necesarios al @test. Este método debe devolver un Object[x][y] que corresponde con los distintos test case que van a ejecutarse en el @test.
• @Parameters: Describe cómo pasar los parámetros al método @Test.
• @Test: Método para ejecutar el test. Es necesario pasarle por parámetros el DataProvider.

Por otro lado, podrían ser de utilidad las siguientes:

• @BeforeSuite - @AfterSuite:  Este método se ejecutará antes - después de lanzar todos los test suite.
• @BeforeTest - @AfterTest: Este método se ejecutará antes - después de lanzar los métodos que pertenecen a las clases <test>.
• @BeforeClass - @AfterClass: Este método se ejecutará antes - después del método @test de la propia clase.
• @BeforeMethod - @AfterMethod: Este método se ejecutará antes - después de cada método @test.

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:

• @Given ("^we are a user$") definirá el cumplimiento de una precondición.
• @And ("^we enter to application$") definirá los pasos de creación del driver de Appium y carga de la aplicación en el dispositivo móvil.
• @When ("^we make login with user and password $") definirá los pasos que realizará la prueba.
• @Then ("^the login is succesffull $") definirá los pasos para la verificación correcta de la prueba.

Adicionalmente se puede incluir la keyword @After para definir los pasos a ejecutar después de la prueba.

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:

• tags = {“@SmokeTest”} Ejecuta todos los escenarios bajo el tag @SmokeTest.
• tags = {“@gui”} Ejecuta todos los escenarios bajo el tag @gui, como en el ejemplo tenemos una feature bajo este tag, se ejecutarán todos los escenarios de esa feature.
• tags = {“@SmokeTest, @wip”} Ejecuta todos los escenarios que estén bajo el tag @SmokeTest o bajo el tag @wip (condición OR).
• tags = {“@SmokeTest”, “@RegressionTest”} Ejecuta todos los escenarios que estén bajo los tags @SmokeTest y @RegressionTest (condición AND).
• tags = {“~@SmokeTest”} ignora todos los escenarios bajo el tag @SmokeTest.
• tags = {“@RegressionTest, ~@SmokeTest”} ejecuta todos los escenarios bajo el tag @RegressionTest, pero ignora todos los escenarios bajo el tag @SmokeTest.
• tags = {“@gui“, “~@SmokeTest”, “~@RegressionTest”} ignora todos los escenarios bajo el tag @SmokeTest y @RegressionTest pero ejecuta todos los que estén bajo el tag “@gui”, si seguimos el ejemplo es como ejecutar todos los escenarios de la feature que no estén bajo ningún otro tag.

Para cada caso de prueba, en función de la criticidad acordada, se etiquetarán los scenarios con los siguientes tags:

• Prioridad Bloqueante: @SmokeTest.
• Prioridad Critica: @RegressionTest.

Para el resto de prioridades no será necesario asignar ningún tag por defecto.

Aquellos escenarios en los que el equipo de desarrollo esté trabajando en su codificación son etiquetados con el tag @wip. Dicho tag será eliminado en el momento en que se tenga completado la codificación del escenario y con ejecución positiva del mismo.

Todos aquellos casos de pruebas a ejecutar sobre un navegador web son  codificados usando la herramienta Selenium web driver. Además, los scenarios que componen el caso de prueba están etiquetados con el tag @gui.