BLOG

Perfil de la herramienta de prueba: ¿Por qué Threat Stack utiliza el medidor ThoughtWorks?

Miniatura F5
F5
Actualizado el 16 de marzo de 2022

Threat Stack ahora es F5 Distributed Cloud App Infrastructure Protection (AIP). Comience a utilizar Distributed Cloud AIP con su equipo hoy mismo .

Threat Stack tiene numerosas pruebas ejecutándose diariamente, verificando que todo funcione como se espera en nuestra Threat Stack Cloud Security Platform®. Para complementar las pruebas unitarias y de integración de los ingenieros de software, nuestro equipo de ingeniería de pruebas ha creado lo siguiente como parte de nuestro conjunto de pruebas de regresión automatizadas:

  • Pruebas basadas en navegador , escritas en Capybara, que verifican que solo los usuarios válidos puedan iniciar sesión en nuestro Tablero, navegar por nuestro sitio, ver el registro de eventos creados por su flota de AWS y crear y actualizar reglas basadas en estos eventos que generan alertas que su equipo de seguridad puede clasificar, todo a través de nuestra interfaz de usuario basada en web: Más de 150 pruebas.
  • Pruebas de API , que utilizan la gema Ruby Net/HTTP para interactuar con nuestra API Threat Stack , verificando que puede recuperar los últimos treinta días de registros de auditoría, enumerar alertas individuales y grupales por gravedad y tipo, enumerar todos los entornos virtuales monitoreados e investigados por Threat Stack y ver los conjuntos de reglas de cumplimiento base para HIPAA, ISO 27001, MPAA, PCI y SOC 2. Las pruebas también verifican que las alertas generadas por estas reglas preconfiguradas y personalizadas se pueden ver, suprimir o descartar, todo a través de la API Threat Stack: Más de 130 pruebas.

¿Cómo podemos realizar el seguimiento de casi trescientas pruebas de aceptación? Los ingenieros de pruebas aquí en Threat Stack configuran sus pruebas con ThoughtWorks Gauge , un marco de automatización de pruebas multiplataforma, gratuito y liviano. 

Una prueba de calibre consta de dos partes principales:

  • La especificación de la prueba, escrita en lenguaje sencillo, es una lista de instrucciones paso a paso en forma de viñetas sobre cómo llevar a cabo la prueba. La especificación debe leerse como un plan de prueba manual, claro y conciso con suficiente descripción para que otros puedan seguirlo.
  • La carpeta step_implementation incluye el código que ejecuta la prueba y envuelve cada paso en un bloque de código que puede reutilizarse cuando y donde sea que se lo llame en la especificación. 

Al permitir que Gauge separe el plan de prueba del código que ejecuta la prueba, nuestras pruebas son más legibles y fáciles de mantener, lo que permite compartir los pasos de prueba entre nuestras pruebas.

En el resto de esta publicación nos centraremos en diez de las características clave que nos encantan de Gauge: 

Instantánea:

  • Sitio web: Gauge.org , Github.com/getgauge
  • Fecha de lanzamiento: Julio de 2018
  • Idiomas compatibles: Java, C#, Ruby, Javascript, Go, Python
  • Sistemas operativos compatibles: Linux, macOS, Windows
  • Conectores IDE: Visual Studio, Visual Studio Code, IntelliJ

1.Facilidad de configuración

El medidor es muy fácil de instalar. Vaya a la página de instalación de Gauge y, al seleccionar su sistema operativo, lenguaje de programación e IDE, se mostrarán instrucciones personalizadas sobre cómo instalar todo. Las instalaciones de MacOS se pueden realizar en HomeBrew, las de Linux usando APT_GET y las de Windows usando su Windows Installer, si no desea instalar desde el código fuente . 

Una vez descargado todo, se puede instalar el ejecutor de lenguaje para un lenguaje de programación como Ruby escribiendo gauge install ruby en la línea de comando.

2.Proyecto de muestra incluido

Con un nuevo marco de automatización de pruebas, puede resultar difícil determinar qué archivos deben estar en qué carpetas y cómo configurar e iniciar las pruebas. 

Gauge evita esta confusión al incluir un proyecto de muestra, que incluye algunas pruebas con las que los nuevos usuarios del marco pueden experimentar. Digamos que tienes una palabra determinada como “Gauge”, “Mingle” o “Snap”. ¿Cómo podría diseñar pruebas que cuenten el número de vocales en la palabra, afirmando que el recuento esperado y el real coinciden? 

Las pruebas de ejemplo se basan en datos, y la entrada se captura en una tabla de datos con dos columnas: "Palabra" y el "Recuento de vocales" esperado.

El proyecto de muestra se puede ejecutar, inmediatamente después de la instalación, desde la línea de comando con gauge run spec .

Ejemplo de salida, línea de comandos: 

3.Separación entre la prueba y cómo se implementa la prueba

Intentar averiguar qué se está probando realmente dentro de un conjunto de pruebas automatizadas puede ser un ejercicio frustrante, especialmente si necesita examinar numerosos bloques de código antes de descifrar el propósito de la prueba, los pasos que lleva a cabo la prueba o el código que ejecuta cada paso de la prueba. 

Gauge evita esta confusión al separar el plan de prueba y cómo se ejecuta este plan. Gauge organiza los pasos en un archivo Markdown , el lenguaje de formato de texto creado por Josh Gruber y Aaron Swartz en 2004. Los pasos de prueba se guardan como viñetas en archivos de especificaciones , que luego pueden ser ejecutados por step_implementations . 

Presupuesto: Las especificaciones no son simplemente una lista de las especificaciones de una característica de un producto: Son una forma de organizar el código de prueba y configurar los informes HTML o XML. Cada elemento del archivo *.spec corresponde a un elemento en Markdown. Las especificaciones son un “caso de prueba de la capa empresarial que también puede actuar como documentación de funciones”. Están escritos en lenguaje comercial. Normalmente, una especificación describe una característica particular de la aplicação bajo prueba”, según la documentación oficial de Gauge . 

Cada especificación tiene un encabezado que describe los distintos escenarios de prueba que se ejecutarán y los escenarios de prueba relacionados se describen como subencabezados. Estos encabezados y subencabezados se incluyen al ver los registros, para ver qué pasó y qué falló, y en el informe HTML. 

Definiciones de pasos: Cada paso enumerado en la especificación corresponde a un concepto o a una definición de paso reutilizable que combina el lenguaje simple de la especificación con el código Java, C#, Javascript, Python o Ruby que se ejecuta. 

Al separar la prueba del código que la ejecuta, permite que otros evaluadores, analistas comerciales y propietarios de productos vean claramente cómo se construyó la prueba mirando el archivo de especificaciones, sin tener que sumergirse en el código.

4.Las especificaciones están formateadas para facilitar su lectura

Las especificaciones están configuradas para ser muy legibles. 

  • Los encabezados están precedidos por un hashtag (“#”) donde el autor puede describir lo que harán los escenarios.
  • Los escenarios de prueba individuales se enumeran como subtítulos indicados con hashtags dobles (“##”). 
  • Los pasos de prueba que llevan a cabo el escenario bajo prueba están precedidos por un asterisco, como una viñeta (“*”). 

¿Necesita un ejemplo de un archivo de especificaciones? Aquí está la especificación del proyecto de demostración que Gauge instala al inicializar un nuevo proyecto Gauge:

# Encabezado de especificación
Este es un archivo de especificación ejecutable. Este archivo sigue la sintaxis Markdown. Cada encabezado en este archivo denota un escenario. Cada punto con viñetas indica un paso.
* Las vocales en inglés son "aeiou".
## Recuento de vocales en una sola palabra
* La palabra "gauge" tiene "3" vocales.
## Recuento de vocales en varias palabras
Este es el segundo escenario de esta especificación. Aquí tienes un paso que requiere una tabla.
* Casi todas las palabras tienen vocales.
|Palabra |Conteo de vocales|
|------|-----------|
|Indicador |3 |
|Mingle|2 |
|Ajustar |1 |
|GoCD |1 |

Cada viñeta de esta especificación corresponde a un paso de prueba que aparece en la carpeta step_implementations. 

¿Necesitas otro ejemplo? Digamos que tienes en la carpeta de especificaciones una prueba llamada login.spec que inicia sesión en un sitio:

# Prueba de inicio de sesión
## Verificar que usuarios válidos puedan iniciar sesión en el sitio
* INICIO DE SESIÓN: Ingrese su nombre de usuario: “info@threatstack.com”
* INICIAR SESIÓN: Introducir contraseña: “1234”
* INICIAR SESIÓN: Seleccione [INICIAR SESIÓN]

Cada paso colocado en la carpeta step_implementations puede ser ubicado y ejecutado automáticamente por la prueba.

login_spec.rb paso 'INICIAR SESIÓN: Ingresar nombre de usuario: ' do | nombredeusuario | fill_in(EMAIL_TEXTBOX, with: nombredeusuario) end

¿Sientes que estás ejecutando la misma serie de pasos una y otra vez? Puede colocar estos tres pasos de inicio de sesión en un archivo de concepto , en Login.cpt . 

login.cpt # Iniciar sesión como y * INICIAR SESIÓN: Ingresar nombre de usuario: * INICIAR SESIÓN: Ingresar contraseña: * INICIAR SESIÓN: Seleccione [INICIAR SESIÓN]

Si otras pruebas tienen un componente de inicio de sesión, en lugar de copiar y pegar los tres pasos, puede insertar solo una línea en la prueba: Inicie sesión como “info@threatstack.com” y “1234”

5.Buena documentación y soporte

Aprender un nuevo marco de automatización puede ser confuso. A veces leer la documentación no es suficiente. ¿Tiene alguna pregunta que no pueda responderse leyendo la documentación completa de Gauge.org? Los desarrolladores son bastante receptivos en StackOverflow , Google Groups y Gitter Chat .

6.Informes HTML creados según la especificación de prueba

Las especificaciones de pruebas, como hemos visto, están escritas en Markdown . Estas pruebas enumeradas en la especificación se pueden utilizar como documentación real sobre cómo funciona el producto de software bajo prueba. Dado que figuran en Markdown, las especificaciones se pueden utilizar para crear informes HTML fáciles de leer.

Echemos un vistazo al informe HTML del proyecto de demostración, contando el número de vocales en una palabra:

Podemos ver que el informe HTML contiene:

  • La hora y la fecha en que se ejecutaron las pruebas y el tiempo que tardaron en ejecutarse.
  • ¿Cuántas especificaciones y escenarios se ejecutaron?
  • ¿Cuántas especificaciones y escenarios se aprobaron y fallaron?
  • ¿Qué pasos se ejecutaron? Los pasos aprobados están en verde y los pasos fallidos están en rojo. Los mensajes de error se incluyen en el informe. 

7.Suministros de calibre Ganchos de ejecución

Cualquier buen marco de automatización incluye formas de establecer condiciones previas para una prueba y un método de desmantelamiento que se ejecuta después de que se hayan completado las pruebas. 

Un ejemplo sería una suite de automatización que se centra en las pruebas del navegador, que tendría un método de configuración que inicializa el navegador cuando se inicia la suite de pruebas y un método de desmontaje que cierra el navegador cuando se han completado las pruebas. 

Gauge proporciona ganchos de ejecución que se pueden ejecutar antes y después de cada suite, especificación, escenario o paso en su suite de pruebas de automatización.

Al utilizar los códigos de ejecución, Gauge elimina la duplicación de código que debe ejecutarse antes de cada suite, especificación, escenario o paso. 

8.Funcionalidad de la línea de comandos

Gauge tiene lo que ellos llaman “soporte de refactorización de primera clase” tanto en el IDE como en la línea de comandos. Por ejemplo, para aquellos a quienes les gusta modificar continuamente la redacción de una prueba para que quede cada vez más claro lo que realmente está haciendo la prueba, escriban lo siguiente en la línea de comando: 

$ gauge --refactor "nombre del paso anterior" "nombre del paso nuevo"

Para obtener más información sobre las herramientas de línea de comandos para Gauge, consulte manpage.gauge.org . 

9.Las pruebas pueden basarse en datos

Las pruebas se pueden configurar para que se diseñen en función de los datos, de modo que las pruebas que son simplemente variaciones de un tema puedan alimentarse con una tabla de parámetros de prueba para usar. 

Digamos que tienes una serie de servicios web que necesitan ser probados, llegando a un punto final de API. Dado el nombre del servicio web, el esquema y el puerto, debe verificar que la respuesta HTTP sea 200 OK . 

Como cada prueba es similar a la otra, los datos se pueden formatear en una tabla fácil de leer.

webservice_test.spec

Cada fila de información se introduce en el paso de prueba y se ejecuta mediante la implementación del paso correspondiente, lo que evita al autor la duplicación del trabajo. 

10.Los datos se pueden almacenar sobre la marcha

A veces es necesario compartir datos entre los pasos de prueba, guardándolos y almacenándolos para más tarde. Al igual que en la prueba de API anterior, una vez que recibe la respuesta al llegar al punto final, tiene pasos de prueba para asegurarse de que esté en un formato válido con el esquema JSON correcto, o si desea asegurarse de que se enumeren los mensajes de error adecuados al ejecutar una prueba negativa. 

Gauge utiliza tres tipos de almacenes de datos: ScenarioStore, SpecStore y SuiteStore, guardan datos como pares clave/valor para el ciclo de vida del escenario, la especificación o todo el conjunto de pruebas. 

Example: En la sección de implementación del paso, puedes agregar identificadores de elementos de la siguiente manera:

// Añadiendo valor
scenario_store = DataStoreFactory.scenario_datastore;
scenario_store.put("element-id", "455678");
// Obteniendo valor
element_id = scenario_store.get("element-id");

Terminando...

Como indicamos al principio, cuando se ejecutan tantas pruebas como las que realizamos en Threat Stack a diario, se necesita un marco de automatización de pruebas multiplataforma que sea a la vez robusto y ágil, y que tenga las características y capacidades para abordar sus necesidades de pruebas específicas, al tiempo que proporciona una importante facilidad de uso y automatización para que pueda realizar pruebas exhaustivas, en un período de tiempo razonable, con la cantidad justa de esfuerzo y aporte por parte del evaluador.

Manténganse al tanto: En una próxima publicación, analizaremos algunas de las otras herramientas de prueba que utilizamos en Threat Stack, incluido Capybara.

Threat Stack ahora es F5 Distributed Cloud App Infrastructure Protection (AIP). Comience a utilizar Distributed Cloud AIP con su equipo hoy mismo .