Probando APIs

Como bien sabemos, las pruebas de software se han convertido en una etapa imperdonable dentro del ciclo del desarrollo de software, ya sea que se trate de software de aplicación o software de sistemas.

La estrategia, el enfoque, y herramientas para realizar las pruebas pueden variar cuando se trata de probar APIs. Sin embargo hay algunas técnicas que pueden igualmente ser aplicables al llevar a cabo un proyecto de testing que implique contar con una GUI (Graphic User Interface) o cuando no se cuenta con ella, sino sólo con una serie de funciones, métodos, procedimientos que requieren ser llamados.

Y justo para adentrarnos un poco más en este tema, vale la pena considerar algunos conceptos esenciales, sólo para asegurar que estemos dentro de un mismo contexto.

Partamos de que una API (Application Programming Interface) o Interfaz de Programación de Aplicaciones, es una colección de funciones, procedimientos o métodos que están disponibles para ser ejecutados por otras aplicaciones de software; su fin principal es ofrecer acceso a ciertos servicios y proveer de cierta capacidad de comunicación entre componentes de software. Facilitan la vida a los desarrolladores ya que pueden beneficiarse de la funcionalidad de una API, evitando así el tener que volver a programar dicha funcionalidad desde cero. Se utilizan de forma muy común en las llamadas bibliotecas. Ejemplos: Microsoft Win32 API, OpenGL, OpenCL, CORBA, Microsoft Framework .NET, Google Web API’s, API de Twitter, API de Facebook, API REST.

API Testing

Entendamos éste como el proceso de someter metódicamente a evaluación, las llamadas o ejecuciones de dichos métodos, procedimientos o funciones a través de aplicaciones de software externas que ejercitarían diversas técnicas para simular el uso de dichas APIs con diversas y creativas variantes en los parámetros de las mismas, así como configurando pre-condiciones especiales en el ambiente, interactuando con bases de datos, dispositivos, archivos, etcétera, a fin de evidenciar errores.

Al igual que ocurre en un proyecto de testing para evaluar cualquier otro tipo de software, se requieren las típicas fases de:

Iniciación -> Planeación -> Ejecución y Control -> Cierre

Entendiendo que, dentro de dichas etapas del proyecto, igualmente requeriríamos llevar a cabo algunas de las actividades básicas, como:

• Análisis: entendimiento de funcionalidad y comportamiento esperado, conocer estructura y parámetros, valor de retorno esperado.
• Diseño y aplicación de técnicas de pruebas: clases de partición de equivalencias, valores al límite, condición negativa, prueba funcional básica-camino feliz, etcétera.
• Identificación de dependencias y características de interoperabilidad.
• Diseño de pruebas: elaboración de scripts/casos de prueba –comúnmente a través de lenguajes de scripting, aunque también se pueden efectuar pruebas manuales.
• Preparación de ambiente.
• Preparación de datos de prueba: identificación de parámetros de entrada y valores esperados de retorno.
• Ejecución de pruebas.
• Reporte, administración y seguimiento de incidencias/defectos.
• Obtención y análisis de métricas.

Preparación de ambiente para probar APIs

Probar una API es diferente en ciertos aspectos, dado que para empezar, muy rara vez pudiera llegar a ocurrir que se tenga una GUI. Pro esto no significa que no haya que preparar algún ambiente de pruebas.

Como ya lo decíamos, son importantes tanto 1) la preparación de los artefactos y ambiente donde correrán las pruebas, así como 2) la configuración propiamente de la aplicación.

En el primero de los casos, podríamos considerar:

• Configuraciones de base de datos.
• Creación de scripts automatizados para las pruebas.
• Creación de queries si se pretende a través de ellas realizar consultas o modificar datos.
• Arrancar el servidor.

En el segundo de los casos, podría requerirse:

• Preparación de diversas combinaciones de parámetros para las llamadas a funciones.
• Creación de ciertos objetos, previo a las llamadas a la API.
• Crear las condiciones iniciales bajo las cuales se pretende realizar las diversas formas de llamadas a las APIs (de forma directa, mediante algún evento o en respuesta a alguna excepción).

Técnicas para probar APIs

Se ponen a consideración las siguientes técnicas, de entre las cuales incluso existen algunas que pueden ser también empleadas en el testing convencional, ya sea incluso manual o automatizado. En el testing de APIs, particularmente se pueden considerar como base para el diseño de los scripts/caso de prueba, las siguientes:

1) Selección de parámetros y valores de retorno. Consiste en ejercitar las llamadas a funciones/métodos de la API aplicando una creativa selección de parámetros y generación de valores de retorno que evalúen éstas mediante la variación no sólo de los valores empleados sino en las formas de llamarlos (con vacíos, null, uno, dos o más parámetros, diversos tipos de parámetros distintos al tipo esperado), la secuencia en las llamadas también puede ejercitarse.

2) Condición negativa. Se recomienda validar los mecanismos para el manejo de errores y excepciones, ejercitando con diversos casos posibles que puedan evidenciar ya sea una incorrecta o ausente validación. La API debiera seguir funcionando ante una inesperada o incorrecta forma de llamada, por ejemplo: ante una lectura incorrecta de un archivo o corrupción de éste, intento de lectura de un archivo no abierto previamente, intento de uso de un dispositivo inaccesible, valores de entrada incorrectos en alguna llamada, o nombres de funciones, procedimientos, métodos inexistentes.

3) Valores al límite. Se requiere ejercitar la API realizando llamadas a funciones donde se evalúe que éstas funcionan adecuadamente ante parámetros de entrada que contemplan valores no sólo en los límites máximo y mínimo permitidos, sino además, al menos en: (N-1); 0; N; (N+1).

Se sugiere un mayor rigor cuando el caso lo amerite, considerando los siguientes posibles escenarios: (LInf-1); LInf; (LInf+1); 0; N; (LSup-1); LSup; (LSup+1) donde LInf es el límite inferior y LSup el límite superior.

Por ejemplo, considerando un parámetro de entrada cuyo valor debe ser un entero entre 10 y 50, se recomendaría probar la función con los siguientes parámetros:

Func(10-1); Func(10); Func(10+1); Func(0); Func(30); Func(50-1); Func(50); Func(50+1)

4) Clases de partición de equivalencias. Como ya lo explicaba en un artículo de la edición 41 de SG [1], esta técnica de pruebas de caja negra permite establecer una relación entre los elementos de un conjunto de valores que comparten cierta característica o propiedad que los representa. Esto permite reagrupar dichos elementos en clases de equivalencia válidas y clases inválidas (grupos de elementos similares) cuyos valores revelarían el mismo error si todos fueran empleados en varias pruebas. La ejemplaridad de dichos valores de entrada permite limitar la cantidad de datos a usar en las pruebas.

5) Prueba Funcional Básica (happy path). Consiste en probar el flujo básico, en este caso, considerando llamadas a funciones de la API cuyo resultado genere los resultados esperados ejecutando cada función o método también en la secuencia “normal”. Ejemplo:

Inicializar();
Configurar (20,1,1);
CargarDatos();

6) Modificación de recursos accedidos por la API. Se sugiere evaluar las llamadas a la API que impliquen modificar ciertos recursos, como: modificación de registros, eliminar ciertos procesos, insertar, actualizar, remover datos de una base de datos, etc. Y una vez que se efectúen dichas tareas, asegurarse que efectivamente sean realizadas como se esperaba.

Recordemos que una de las características importantes de la calidad externa del software que pretende probarse en las API’s es la interoperabilidad, es decir, “la habilidad de dos o más sistemas o componentes para intercambiar información y utilizar la información intercambiada”[2]. Teniendo esos requisitos de interoperabilidad en mente, así como el resto del comportamiento funcional de la API y el software que hará uso de ellas, se deberá planear la adecuada cobertura para obtener las métricas objetivo del proyecto.

Referencias

[1] B. Ruiz. “Preparación y Gestión de Datos de Prueba” SG Software Guru #41. http://sg.com.mx/revista/41/preparacion-y-gestion-datos-prueba

[2] Institute of Electrical and Electronics Engineers. IEEE Standard Computer Dictionary.