Las pruebas del sistema ArcGIS deben validar que el diseño implementado funcionará como se espera y admitirá los flujos de trabajo, los usuarios y la carga a los que está destinado. Las pruebas del sistema ofrecen la oportunidad de descubrir y corregir problemas antes de que aparezcan en la producción. Aunque puede que no sea realista someter todos los componentes, eventos o situaciones posibles a pruebas, debería definirse algún planteamiento pragmático para probar los aspectos clave del sistema. Por ejemplo, la capacidad del sistema para admitir flujos de trabajo definidos, recuperarse de un fallo de un componente o gestionar una nueva carga de trabajo.
Las pruebas intencionadas y estructuradas son fundamentales para el éxito de cualquier aplicación, flujo de trabajo o sistema. Hay muchos tipos diferentes de pruebas que tienen relevancia a lo largo del ciclo de desarrollo, incluidas las pruebas funcionales, las pruebas de accesibilidad y las pruebas de aceptación, entre otras. Las pruebas son una parte clave del proceso de arquitectura, ya que ayudan tanto a validar una recomendación arquitectónica como a proporcionar datos que podrían conducir a un cambio arquitectónico sugerido, como que una determinada base de datos o versión de software funcione significativamente mejor o peor que otra oferta.
A efectos de esta sección, este tema se centrará en las pruebas de rendimiento: los métodos y procesos que ayudan a identificar si se cumplen las características de rendimiento de la línea base del sistema. Las pruebas deben producirse en paralelo a la monitorización telemétrica y deben permitir la prueba de cada componente monitorizado. A medida que se introducen cambios en el sistema, es imprescindible volver a realizar las pruebas para identificar cualquier degradación. Las pruebas también deben utilizarse para informar de los posibles cuellos de botella de la arquitectura en función de los cambios de carga previstos.
Este nivel ideal de pruebas iterativas, normalizadas y repetibles requiere la automatización del proceso para tener éxito. Con los patrones de implementación de SaaS, la realización de pruebas automatizadas y, en especial, de pruebas de rendimiento, también requiere la coordinación con otros proveedores, sistemas y partes interesadas.
Por encima de todo, un planteamiento de pruebas sólido debe determinar los objetivos de las pruebas, lo que probará y lo que no (el alcance), lo que se medirá (la telemetría) y los criterios de éxito.
Durante las pruebas de rendimiento, hay muchos factores que influyen en el rendimiento de un flujo de trabajo, como el hardware del cliente final, la conectividad de la red con el sistema backend y la configuración del sistema backend. Comprender los detalles de estos componentes es fundamental para saber si las mediciones de rendimiento están influidas principalmente por el software ArcGIS que se está probando o por otros componentes como un proxy, una base de datos o un conmutador de red que introduce latencia o interrupciones.
Se pueden utilizar distintos tipos de pruebas para alcanzar objetivos diferentes. Por ejemplo, quizá desee:
Al elaborar una estrategia de pruebas, si se identifican claramente los objetivos, los pasos adicionales se desarrollarán de forma más eficiente.
Muchos sistemas mantienen un entorno «inferior» (de prueba, provisional o de preproducción, por ejemplo) destinado a las pruebas funcionales o de carga. Para obtener más información sobre el uso correcto de los entornos de prueba o de ensayo, consulte la página de aislamiento de entornos de este sitio.
Con frecuencia, un sistema empresarial cuenta con varias aplicaciones independientes en las que se ejecutan los flujos de trabajo, incluidos los clientes de escritorio, móviles y web, y puede incluir flujos de trabajo de lectura/escritura y de elaboración de informes, así como admitir muchos tipos de usuarios diferentes. Tratar simplemente de «probar el sistema» sin definir primero este límite dará lugar a muchos casos de prueba y a una probabilidad reducida de que la información sea útil para acciones posteriores.
Una buena prueba del sistema imitará la forma en que se utilizará el sistema, para que sepa que funcionará y se comportará como se espera. Por lo tanto, el alcance de la prueba debe incluir los flujos de trabajo que el sistema está destinado específicamente a admitir y diseñado para proporcionar las métricas necesarias para evaluar los criterios de éxito. Por ejemplo, si está actualizando el software de un sistema existente, el alcance debe incluir todos los flujos de trabajo clave ejercitados bajo una carga que represente las operaciones máximas previstas por hora.
Es posible que algunas cargas de trabajo no se produzcan al mismo tiempo, como el procesamiento nocturno de scripts que importan o exportan datos, frente a las operaciones diurnas normales. En esos casos, el sistema podría probarse dos veces; una para asegurarse de que gestiona las cargas diurnas de personas que acceden al sistema y otra para garantizar que el procesamiento nocturno se completa en el tiempo requerido. El sistema también debe volver a probarse cuando se introduzca cualquier cambio para determinar si ha causado algún impacto negativo.
La telemetría se utiliza durante las pruebas del sistema para recopilar información sobre el rendimiento del sistema en otros escenarios con el fin de evaluar si el sistema cumple los requisitos y para identificar problemas o anomalías. Aunque mucha gente puede pensar inicialmente en realizar pruebas de carga en la implementación de ArcGIS Server, es importante capturar telemetría en todo el sistema. Por ejemplo, puede recopilar telemetría en toda la infraestructura de servidores que muestre que el sistema tenía un alto rendimiento, solo para enterarse más tarde de que los usuarios finales tenían problemas para completar los flujos de trabajo porque sus equipos de sobremesa tenían pocos recursos, por lo que el rendimiento aceptable del sistema backend les parecía un sistema inaceptablemente lento.
Un objetivo clave debería ser modelar el script de prueba y las solicitudes que se envían en las pruebas basándose en las solicitudes recogidas mediante la monitorización telemétrica, tanto las solicitudes medias como las que tienen un valor atípico. Las pruebas también deben tratar de probar los componentes individuales junto con los procesos de extremo a extremo. Con la complejidad de la mayoría de los sistemas empresariales, puede que no sea posible utilizar una única herramienta de prueba para todas las funciones de prueba, pero los ejecutores de pruebas automatizados, como JMeter, deben configurarse para permitir el ajuste de las rutinas de prueba con entradas y salidas de prueba normalizadas.
Unos criterios de éxito adecuados le permitirán determinar si el sistema ha superado o no una prueba y dónde pueden radicar los problemas. Sus criterios de éxito informarán del alcance de sus pruebas y del tipo y granularidad de la telemetría que capture. Los criterios podrían incluir métricas como el número de operaciones por hora, los usuarios concurrentes, el rendimiento del hardware o el tiempo de finalización del flujo de trabajo.
Otros recursos relacionados con las pruebas son: