Automatizar el 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 normales 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 ejecutarse durante "horas fuera del horario". 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:

1. Obtenga la compilación más reciente del código fuente del repositorio de código fuente.

2. Compile el código fuente.

3. Empaquetar archivos binarios para la implementación, normalmente mediante scripts o archivos de Microsoft Windows Installer.

4. Implemente el proyecto en un servidor de prueba.

5. Ejecute automáticamente un conjunto completo de pruebas de comprobación de compilación (BVT).

6. Publique un informe de compilación detallado a 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 los BVT son lo suficientemente completos para medir la calidad de la compilación, pero lo suficientemente pequeños como para ejecutarse dentro del tiempo diario asignado para la compilación.

Nota:

También debe tratar cualquier implementación, desinstalación, scripts de configuración e instalación o procesos 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 este.

Normalmente, este proceso se completa a principios de la mañana alrededor de las 6 a. m., lo que permite que los primeros miembros del equipo empiecen a trabajar en la construcción del nuevo día. Si se produjo un error en uno o varios de los BVT de la noche anterior, 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 ritmo regular de trabajo (compuesto por la compilación diaria más las pruebas básicas automatizadas). En segundo lugar, el uso de BVT fuerza la integración con sistemas, lo cual es una tarea complicada, y el hacerlo pronto por sí mismo reduce 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. Normalmente, las pruebas de esfuerzo y rendimiento se programan para realizarse en una versión de hito del 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 no es ciertamente trivial. Es importante que los scripts de implementación automatizados se desarrollen por adelantado. Si no lo hace, terminará desplegando y revirtiendo el despliegue de la solución manualmente 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. El uso de este programa está completamente en su propio riesgo.

Para obtener más información sobre la automatización de 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 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 añadirlos a los BVTs durante las etapas iniciales de un proyecto, se proporciona inmediatamente al menos cierta cobertura de código. A medida que crecen las pruebas funcionales y, por tanto, aumenta la cobertura de las pruebas, puede optar por eliminar las pruebas unitarias de las pruebas de verificación básica.

• Pruebas de humo: pruebas funcionales de un extremo a otro que prueban la funcionalidad básica de la solución. Si estos fallan, algo está seriamente mal. Normalmente se pueden ejecutar con relativamente 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 que haya aprobado que su solución es funcionalmente correcta.

• 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. Estas pruebas normalmente serán casos que no se cubrieron en las pruebas funcionales. 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 vuelto activa, 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 lograr esto.

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 alimentar 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 tenga en cuenta que algunos escenarios requieren que las entradas lleguen en un orden determinado y, en un momento determinado, y esto se comba 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 que espera en producción, sino también las rutas de acceso de error y las rutas de control de excepciones que ha implementado, pero que espera nunca usar; una frase que se suele usar para describir esto es probar el "escenario del peor día". Debe asegurarse de que todas las orquestaciones, todos los tipos de mensajes permitidos y todas las ramas de código son evaluados por su suite de pruebas funcionales. En las secciones siguientes se describe el desarrollo de casos de prueba funcionales positivos y negativos para cubrir todas las rutas de código.

Para obtener más información sobre las pruebas funcionales y las otras 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, asegurarse de que todas las combinaciones de mensajes, canalizaciones, orquestaciones y puntos de conexión se integran en la solución para que se ejecuten todos los flujos de mensajes. Para asegurarse de que pruebe todas las rutas de acceso de código, posiblemente requiera 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 uso del adaptador de archivos cuando se usará algún otro transporte en producción. Adoptar este enfoque está preparando tanto a usted como al proyecto en general para el fracaso 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); Cualquier otro dato que quede en repositorios de datos externos se debe tener en cuenta.

• Pruebe la ejecución de todas las directivas y reglas del motor de reglas de reglas de negocio (BRE) si la solución usa BRE.

Pruebas negativas

• Asegúrese de probar el manejo de mensajes no válidos a través de su sistema. Debe comprobar que la estrategia elegida (para rechazarlas antes de entrar en BizTalk Server o 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 sus escenarios de falla cubran todos los bloques de excepciones de sus 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, invierta el tiempo por adelantado para automatizar las pruebas. Las pruebas manuales consumen mucho tiempo, son propensos a errores y son costosos (en términos de tiempo y costo). Cada vez que realice una prueba manual, agregue otro lote de tareas que deben ser manejadas por 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 buenas pruebas funcionales 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 generar 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 provocará confusión y tiempo de desperdiciar la investigación de 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), puede que termines con menos casos de prueba. Esto significa que tendrá un nivel inferior de cobertura de pruebas en su código. Mediante el uso de un marco de pruebas, puede desarrollar casos de prueba más rápidos y fáciles y, por lo tanto, facilitar la cobertura de código completa. La mayoría de los marcos de pruebas recomendados usan un enfoque declarativo para definir pruebas. (Es decir, la configuración de una prueba se almacena en un archivo de configuración, que normalmente es un archivo XML). El uso de un buen marco de pruebas le permite desarrollar un conjunto de pruebas funcionales completo de una manera ágil y confiable y evita tener que "reinventar la rueda" una y otra vez, por así decirlo.

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 en los que 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.

Véase también

Implementación de pruebas automatizadas