Por qué son importantes las pruebas
En este tema se proporciona información general sobre la mentalidad que conduce a pruebas insuficientes, se describen los riesgos asociados con la falta de prueba de soluciones de BizTalk y se contrastan las dificultades de las pruebas manuales con las ventajas de las pruebas automatizadas.
Pruebas como "sobrecarga"
Desafortunadamente, con una demanda cada vez mayor de rentabilidad de la inversión (ROI), la fase de prueba de un proyecto a menudo se considera uno de los primeros aspectos de un plan de proyecto que se puede reducir horizontalmente.
Un argumento para probar las soluciones de BizTalk es que "No es necesario probar nuestra solución porque Microsoft ya prueba exhaustivamente BizTalk Server". Aunque es cierto que Microsoft realiza pruebas exhaustivas BizTalk Server, diferentes escenarios de uso requieren una de las casi innumerables permutaciones de los requisitos empresariales para el rendimiento, la alta disponibilidad, el uso del adaptador, la latencia, los requisitos de seguimiento, el uso de orquestación y el código personalizado. Dado que BizTalk Server es extremadamente flexible y puede dar cabida a muchos escenarios de uso diferentes, simplemente no es posible prever y probar todos ellos. Además, la configuración predeterminada que se aplica en un entorno de BizTalk Server debe optimizarse para adaptarse a cada escenario de uso. La única manera de determinar la configuración óptima para un escenario de uso determinado es probar la solución, medir varios parámetros, ajustar el entorno y volver a probar. Considere el siguiente diagrama, que muestra una arquitectura física de ejemplo para una solución de BizTalk Server.
Ejemplo de arquitectura física de BizTalk
Puede ver en el diagrama anterior que la solución BizTalk Server contiene muchas partes móviles, incluidos varios equipos que ejecutan BizTalk Server, equipos que ejecutan SQL Server, nodos de clúster de servidor y dominios de Active Directory. Una vez que el sistema esté en funcionamiento, habrá muchos ajustes de configuración aplicados para optimizar la aplicación según los requisitos empresariales, con el fin de maximizar el ROI general de la solución. En este único escenario se muestra que hay muchas variables en juego. Además de la arquitectura física del entorno, tenga en cuenta el siguiente diagrama, que muestra el flujo de un mensaje a través de BizTalk Server.
Sample Logical BizTalk Message Flow
Al examinar el diagrama lógico de un mensaje que fluye a través de BizTalk Server, vemos otras variables que requieren pruebas por proyecto, incluidos los componentes personalizados de envío y recepción de canalización y clases personalizadas a las que se puede llamar desde orquestaciones de BizTalk. Dado que la complejidad y el uso de tipos de componentes personalizados y componentes de BizTalk varían de proyecto a proyecto, resulta más evidente por qué es importante realizar pruebas para cada escenario de uso específico.
Metodología de pruebas y escalas de tiempo
Para garantizar que las pruebas se realicen de forma eficaz y eficaz, el arnés de pruebas debe estar totalmente automatizado para que sea fácilmente reproducible y minimice la posibilidad de error humano. Además, se debe asignar un tiempo adecuado para las pruebas al planear el proyecto. Un enfoque minimalista para las pruebas constaría de pasos manuales similares a los siguientes:
Cargue manualmente uno o varios mensajes en un punto de conexión de recepción, como una colocación de archivos o mediante un cliente SOAP para llamar a un servicio web.
Valide manualmente el contenido y la estructura correctos de un mensaje. Dado que varios esquemas a menudo están presentes en un proyecto, los mensajes pueden ser una combinación de archivos planos y XML y también pueden contener dependencias entre campos.
Nota
Un ejemplo de esto sería cualquier proyecto que implique mensajes SWIFT. Estos son mensajes de archivo plano que tienen dependencias entre campos. Es decir, el valor de un campo depende de otro: la validación XSD simple no se realizará aquí; por lo tanto, el Acelerador de SWIFT usa el motor de reglas de BizTalk para la validación de los mensajes. Para obtener más información sobre el acelerador de SWIFT.
Compruebe manualmente los registros de eventos en los equipos BizTalk Server si hay errores.
Compruebe manualmente las bases de datos bam (si se usan) para validar que la información de actividad se registra correctamente.
El uso de un proceso manual como se ha descrito anteriormente para las pruebas es propenso a errores y subjetivas. Considere la posibilidad de examinar un mensaje SWIFT de cien líneas con dependencias entre campos para 10 casos de prueba diferentes. La mayoría de los desarrolladores de proyectos no podrían o incluso si fueran capaces, no se inclinarían a participar en esta tarea de forma confiable y precisa. La implementación de un proceso de prueba subjetiva, manual y propenso a errores agrega riesgo a un proyecto y aumenta la posibilidad de error.
A menudo, el riesgo de error se amplifica mediante escalas de tiempo de planificación de proyectos que no incorporan tiempo suficiente para las pruebas. Con demasiada frecuencia, una estrategia de pruebas de proyecto depende de un único pase de prueba manual, que se programa una semana o así antes de la fecha de puesta en marcha. Estas pruebas limitadas colocan el proyecto en riesgo. Dada una escala de tiempo limitada para las pruebas, si se detectan problemas, el proyecto puede retrasarse porque no se ha asignado tiempo para corregir problemas. Además, si se detecta y se corrige un problema, puede faltar tiempo suficiente para realizar exámenes posteriores antes de que el sistema pase.
La realidad de las pruebas "compilación final única, pase de prueba única, toma el proyecto en vivo" es que a menudo da lugar a que el proyecto se retrase, el proyecto supere el presupuesto, o incluso peor, el proyecto ha fallado por completo. En el caso de los sistemas críticos, este tipo de metodología de pruebas es un desastre que espera a producirse.
Probar de forma eficaz y eficaz
Dado que las pruebas adecuadas a menudo se consideran un lujo costoso en lugar de un requisito integral, todo se a menudo se agrupa en el extremo final de un proyecto. Dada la complejidad de la pila de hardware y software usada en entornos empresariales heterogéneos, este enfoque no es realista. La implementación de un enfoque de prueba automatizado que se puede volver a ejecutar a petición es la mejor manera de probar de forma eficaz y eficaz y es un componente integral de proyectos exitosos que, en última instancia, ofrecen un excelente ROI para la empresa. Al invertir al principio del proyecto en pruebas funcionales completas de un extremo a otro para cada ruta de acceso de código a través del sistema que está generando recursos de prueba. Estos activos requieren inversión (es decir, tiempo de desarrollo) para aprovechar las ventajas de aumentar la eficacia y la eficacia de las pruebas más adelante. Para minimizar la inversión necesaria del proyecto para derivar este marco de trabajo, se recomienda usar el marco de pruebas de carga de Visual Studio 2010. Visual Studio 2010 incluye la mayoría de los pasos de prueba comunes necesarios para realizar pruebas correctas y es el marco que se usa en los escenarios de prueba presentados más adelante en esta guía.