Automatización del proceso de compilación
Un proceso de compilación automatizado compila, implementa y ejecuta pruebas de comprobación de compilación (BVT) en el código fuente más reciente de un proyecto a intervalos regulares y predeterminados. A continuación, se divulga un "informe de compilación", que detalla el éxito o error del proceso de compilación, a las partes interesadas del proyecto. El informe de compilación se analiza para determinar qué áreas del proyecto necesitan atención y si el proyecto debe revertirse a una versión o compilación anterior.
La eficacia de un proceso de compilación automatizado es que se puede programar para que se ejecute durante las "horas fuera de servicio". De este modo, puede ayudar a garantizar la estabilidad del proyecto sin quitar ciclos directamente del tiempo de desarrollo. En este tema se proporciona información general sobre el proceso de compilación, se describe cómo encajan las pruebas de comprobación de compilación en el proceso de compilación, se describen los aspectos de las pruebas funcionales que se usan durante las pruebas de comprobación de compilación y se proporciona información sobre la importancia de automatizar el proceso de compilación.
Información general sobre el proceso de compilación
Antes de examinar los detalles de las pruebas, es importante tener en cuenta el contexto de cómo encajan las pruebas en el proceso de compilación general. Todos los grupos de productos de Microsoft funcionan desde la filosofía de que el proceso de compilación es el latido de cualquier proyecto de software. Este enfoque también lo usan muchas de las principales empresas de consultoría del mundo que crean soluciones críticas sobre la pila de software de Microsoft. Sin un latido estable y una comprobación regular de él, es imposible conocer el estado del proyecto. Para asegurarse de que los grupos de productos tienen una visión continua del estado general del proyecto, el proceso de compilación se ejecuta diariamente, normalmente a medianoche. En los pasos siguientes se resume un proceso de compilación automatizado típico:
Obtenga la compilación más reciente del código fuente del repositorio de código fuente.
Compile el código fuente.
Empaquetar archivos binarios para la implementación: normalmente se usan scripts o archivos de Microsoft Windows Installer.
Implemente el proyecto en un servidor de prueba.
Ejecute automáticamente un conjunto completo de pruebas de comprobación de compilación (BVT).
Publique un informe de compilación detallado en los miembros del equipo del proyecto.
Nota
Los BVT son pruebas funcionales que ejercen las principales características de la solución para probar su calidad. Debe asegurarse de que sus BVT son lo suficientemente completos como para medir la calidad de la compilación, pero lo suficientemente pequeño como para ejecutarse dentro del tiempo de compilación diario asignado.
Nota
También debe tratar los scripts o procesos de implementación, desinstalación, configuración e instalación como parte del proyecto de software con fines de prueba. Se deben probar las operaciones del proyecto, así como la implementación y la configuración de él.
Normalmente, este proceso se completa a primera hora de la mañana alrededor de las 6 a.m., lo que permite a los primeros miembros del equipo empezar a trabajar en la compilación del nuevo día. Si uno o varios de los BVT de la noche anterior fallaron, entonces es responsabilidad del equipo corregirlo lo antes posible.
El seguimiento de un proceso de compilación diario tiene muchas ventajas para el proyecto. En primer lugar, proporciona un latido regular (formado por la compilación diaria más los BVT automatizados). En segundo lugar, el uso de BVT fuerza la integración con sistemas que es una tarea complicada, y al hacerlo al principio y por sí mismo se reducen los riesgos del proyecto. Debido al tiempo necesario para completarlos, las pruebas de esfuerzo y rendimiento se realizan normalmente fuera del proceso de compilación diario. Las pruebas de esfuerzo y rendimiento normalmente están programadas para realizarse en una compilación de hito en el proyecto.
El proceso de compilación diario puede ser y se ha usado de forma muy eficaz en las soluciones de BizTalk. Sin embargo, debe asegurarse de que las tareas que normalmente quedan al final en los proyectos se realizan de forma iterativa desde el principio. Por ejemplo, la implementación en BizTalk Server ciertamente no es trivial. Es importante que los scripts de implementación automatizados se desarrolle por adelantado. Si no lo hace, terminará implementando e implementando manualmente la solución muchas veces a lo largo del proyecto, lo que le costará más tiempo al final. Hay herramientas disponibles para impulsar el proceso de compilación diario; Visual Studio Team System y Team Foundation Server son la opción principal para muchas personas. Los scripts de MSBuild se pueden usar para impulsar los pasos del proceso de compilación.
Nota
El uso de esta herramienta no es compatible con Microsoft y Microsoft no garantiza la idoneidad de estos programas. La utilización de este programa queda bajo su propia responsabilidad.
Para obtener más información sobre cómo automatizar las pruebas mediante el Administrador de pruebas de Microsoft, vaya a Ejecución de pruebas automatizadas.
Pruebas de comprobación de compilación
Las pruebas de comprobación de compilación normalmente constan de los siguientes elementos:
Pruebas unitarias : dado que las pruebas unitarias suelen ser las primeras pruebas que se van a desarrollar, lo ideal es que se creen antes de que se haya escrito realmente el código, si realmente usa un enfoque de desarrollo controlado por pruebas. Al agregarlos a BVT durante las primeras fases de un proyecto, se proporciona al menos cierta cobertura de código inmediatamente. A medida que crece el número de pruebas funcionales y, por tanto, la cobertura de pruebas, puede optar por quitar pruebas unitarias de los BVT.
Pruebas de humo : pruebas funcionales de un extremo a otro que prueban la funcionalidad básica de la solución. Si fallan, algo es gravemente incorrecto. Normalmente, se pueden ejecutar con relativa rapidez.
Pruebas funcionales : también tienen como destino escenarios de un extremo a otro, pero en este caso prueban todos los escenarios del proyecto. En el caso de los proyectos grandes, puede tener sentido clasificar aún más las pruebas funcionales (por ejemplo, para permitir que un componente determinado se pruebe de forma rápida, confiable y aislada). Estas pruebas funcionales deben bloquearse después de haber cerrado la sesión en la solución, ya que son funcionalmente correctas.
Pruebas de comprobación de regresión : cada vez que se encuentra y se corrige un error de solución, se deben agregar casos de prueba de comprobación de regresión para comprobar que el error se ha corregido y que no se vuelve a introducir más adelante en el ciclo de vida del proyecto. Normalmente, estas pruebas serán casos que no se trataron en los casos de prueba funcional. Debe esperar que las pruebas de comprobación de regresión aumenten en número incluso después de que la solución se haya puesto en marcha, si se detectan y corrigen nuevos errores.
En proyectos muy grandes, es posible que tenga que convertir los BVT en un subconjunto del conjunto de pruebas funcionales completo (debido al período de tiempo que tardan en ejecutarse). Para proyectos más pequeños, los BVT constituyen todo el conjunto. Obviamente, si va a integrar los BVT como parte de su compilación diaria, todo el proceso debe automatizarse. En el resto de este tema, nos centraremos en cómo puede usar BizUnit y otras herramientas para lograrlo.
Pruebas funcionales
En el contexto de las pruebas funcionales de las aplicaciones de BizTalk, pruebe un escenario específico de un extremo a otro. Al realizar este tipo de pruebas, resulta útil imaginar BizTalk Server como una caja negra que se prueba funcionalmente desde una perspectiva externa. Por ejemplo, una prueba puede implicar la alimentación de un mensaje de entrada (con valores conocidos) a un punto de conexión de ubicación de recepción (por ejemplo, dirección URL, ubicación FTP, sea cual sea su elección de transporte). A continuación, la prueba supervisaría el número correcto de mensajes con la salida correcta que se genera en el lado de envío. Esto puede sonar relativamente sencillo. Sin embargo, cuando se considera que algunos escenarios requieren que las entradas lleguen en un orden determinado y, en un momento determinado, y se acomoda con otros requisitos de solución (como, al grabar datos de seguimiento en BAM), queda claro que se puede usar una herramienta y un marco para orquestar esto.
Es fundamental que las pruebas funcionales están diseñadas para cubrir todas las posibles rutas de acceso a través de la solución. Esto debe incluir no solo los escenarios esperados en producción, sino también las rutas de acceso de error y las rutas de acceso de control de excepciones que ha implementado, pero espero que nunca se usen: una frase que se usa habitualmente para describir esto es la prueba para el "escenario de día incorrecto". Debe asegurarse de que el conjunto de pruebas funcionales ejecuta todas las orquestaciones, todos los tipos de mensajes permitidos y todas las ramas de código. En las secciones siguientes se describe el desarrollo de casos de prueba funcional positivos y negativos para cubrir todas las rutas de acceso de código.
Para obtener más información sobre las pruebas funcionales y las demás categorías de pruebas que se deben implementar antes de colocar una solución de BizTalk Server en producción, vaya a Lista de comprobación: Prueba de preparación operativa.
Pruebas positivas
Es importante al realizar pruebas positivas para asegurarse de que todas las combinaciones de mensajes, canalizaciones, orquestaciones y puntos de conexión se pasan a través de la solución para que se ejecuten todos los flujos de mensajes. Para asegurarse de que probar todas las rutas de acceso de código probablemente requerirá que procese mensajes diferentes con contenido diferente.
Al realizar pruebas, use el tipo de transporte que se usará en producción. Desafortunadamente, con demasiada frecuencia, las pruebas funcionales solo se realizan mediante el adaptador de archivos cuando se usará algún otro transporte en producción. La adopción de este enfoque es configurarle y el proyecto general para errores más adelante.
Valide la carga de todos los mensajes que se envían desde el sistema. Si los mensajes son XML, debe validar sus campos de esquema y clave en el mensaje mediante expresiones XPath.
Valide los datos de seguimiento almacenados en BAM (si se usan); Se deben tener en cuenta los demás datos que se dejan en repositorios de datos externos.
Pruebe la ejecución de todas las reglas y directivas del motor de reglas de negocios (BRE) si la solución usa BRE.
Pruebas negativas
Asegúrese de probar el control de mensajes no válidos a través del sistema. Debe comprobar que la estrategia elegida (para rechazarlas antes de que entren en BizTalk Server o para suspenderlas) ha funcionado correctamente.
Al probar el control de mensajes no válidos, asegúrese de probar que se han implementado las orquestaciones de control de errores del lado de recepción para controlar los mensajes suspendidos.
Asegúrese de que los escenarios de error cubren todos los bloques de excepciones de las orquestaciones. No probar esto adecuadamente es un problema común.
Si usa transacciones de larga duración con un comportamiento de compensación, pruebe estos escenarios con mucho cuidado. Esta es otra área en la que las pruebas inadecuadas incurrirán en consecuencias graves en un entorno de producción.
Asegúrese de que los errores se registran correctamente en los registros de errores adecuados.
La automatización es clave
Para hacer todo esto de forma eficaz y eficaz, invierte el tiempo por adelantado para automatizar las pruebas. Las pruebas manuales consumen mucho tiempo, son propensas a errores y son costosas (en términos de tiempo y costo). Cada vez que se realiza una prueba manual superada, se agrega otro lote de tareas que deben controlar los recursos del proyecto (personas del equipo). Al automatizar esto por adelantado, puede obtener un retorno de la inversión inicial necesaria para desarrollar las pruebas cada vez que se ejecuten. Las pruebas funcionales adecuadas deben ejecutarse de forma rápida y eficaz y ser repetibles; cada prueba también debe ser autónoma (debe ser independiente de cualquier otra; la adopción de este enfoque le permite ejecutar varias pruebas secuencialmente como un conjunto de pruebas). Las pruebas funcionales siempre deben producir el mismo resultado. Las pruebas funcionales mal escritas o el código mal escrito darán lugar a resultados de pruebas diferentes entre ejecuciones de pruebas, lo que provoca confusión y tiempo desperdiciado que investiga la causa principal del error.
Es importante minimizar el esfuerzo de desarrollo necesario para escribir cada prueba funcional. Normalmente, cuanto más caro sea producir algo (en términos de tiempo de desarrollo), menos casos de prueba es probable que termine con. Esto significa que tendrá un nivel inferior de cobertura de prueba sobre el código. Mediante el uso de un marco de pruebas, puede desarrollar casos de prueba más rápidos y más fáciles y, por lo tanto, facilitar la cobertura de código completa. La mayoría de los marcos de pruebas adecuados usan un enfoque declarativo para definir pruebas. (Es decir, la configuración de una prueba se almacena en un archivo de configuración, que suele ser un archivo XML). El uso de un buen marco de pruebas le permite desarrollar un conjunto de pruebas funcional completo de una manera ágil y confiable y evita tener que "reinventar la rueda" sobre y más, así que hablar.
Compatibilidad de MSBUILD con proyectos de BizTalk Server
BizTalk Server proporciona compatibilidad con la plataforma Microsoft Build Engine (MSBUILD), que admite la creación de proyectos administrados en entornos de laboratorio de compilación donde Visual Studio no está instalado. MSBUILD admite la creación de proyectos desde una línea de comandos y una funcionalidad avanzada, incluido el registro y el procesamiento por lotes de MSBUILD. Para obtener más información sobre MSBUILD, consulte Introducción a MSBuild.