Menú

Guía completa de pruebas de verificación de compilación (pruebas de BVT)

build verification testing complete guide

Pruebe Nuestro Instrumento Para Eliminar Los Problemas

¿Qué es la prueba de verificación de compilación (BVT)?

La prueba de verificación de compilación es un conjunto de pruebas que se ejecutan en cada compilación nueva para verificar que la compilación se pueda probar antes de que se la envíe al equipo de prueba para realizar más pruebas.

Estos casos de prueba son casos de prueba de funcionalidad central que garantizan que la aplicación sea estable y se pueda probar a fondo. Normalmente, el proceso de BVT está automatizado. Si BVT falla, esa compilación se vuelve a asignar a un desarrollador para la corrección.

Prueba de verificación de compilación (prueba BVT)

BVT también se llama Prueba de humo o prueba de aceptación de compilaciones (BAT)

New Build se comprueba principalmente por dos cosas:

  • Validación de compilación
  • Generar aceptación

Algunos conceptos básicos de BVT:

  • Es un subconjunto de pruebas que verifican las principales funcionalidades.
  • Los BVT se ejecutan normalmente en compilaciones diarias y si el BVT falla, la compilación se rechaza y se lanza una nueva compilación después de que se realizan las correcciones.
  • La ventaja de BVT es que ahorra los esfuerzos de un equipo de prueba para configurar y probar una compilación cuando se rompe una funcionalidad importante.
  • Diseñe BVT con el cuidado suficiente para cubrir la funcionalidad básica.
  • Normalmente, BVT no debería durar más de 30 minutos.
  • BVT es un tipo de Pruebas de regresión , hecho en todas y cada una de las nuevas construcciones.

BVT comprueba principalmente la integridad del proyecto y comprueba si todos los módulos están integrados correctamente o no. Las pruebas de integración de módulos son muy importantes cuando diferentes equipos desarrollan módulos de proyectos. Escuché muchos casos de fallas en la aplicación debido a una integración incorrecta del módulo. Incluso en los peores casos, el proyecto completo se desecha debido a una falla en la integración del módulo.

¿Cuál es la tarea principal en Build Release? Obviamente, el archivo 'check-in', es decir, para incluir todos los archivos de proyecto nuevos y modificados asociados con las respectivas compilaciones. BVT se introdujo principalmente para verificar el estado de la compilación inicial, es decir, para verificar si todos los archivos nuevos y modificados están incluidos en la versión, todos los formatos de archivo son correctos, cada versión de archivo e idioma, banderas asociadas con cada archivo.

Estas comprobaciones básicas valen antes del lanzamiento de la compilación para que el equipo de prueba las pruebe. Ahorrará tiempo y dinero al descubrir las fallas de construcción desde el principio usando BVT.

¿Qué casos de prueba deberían incluirse en BVT?

conviértete en un probador de juegos gratis

Esta es una decisión muy complicada de tomar antes de automatizar la tarea BVT. Tenga en cuenta que el éxito de BVT depende de los casos de prueba que incluya en BVT.

Aquí hay algunos consejos sencillos para incluir Casos de prueba en su BVT Automation Suite:

  • Incluya solo casos de prueba críticos en BVT.
  • Todos los casos de prueba incluidos en BVT deben ser estables.
  • Todos los casos de prueba deberían haber conocido el resultado esperado.
  • Asegúrese de que todos los casos de prueba de funcionalidad crítica incluidos sean suficientes para la cobertura de prueba de la aplicación.

Además, no incluye módulos en BVT, que aún no son estables. Para algunas funciones en desarrollo, no puede predecir el comportamiento esperado ya que estos módulos son inestables y es posible que conozca algunas fallas conocidas antes de probar estos módulos incompletos. No tiene sentido usar tales módulos o casos de prueba en BVT.

Puede simplificar esta tarea de inclusión de casos de prueba de funcionalidad crítica comunicándose con todos los involucrados en el desarrollo del proyecto y el ciclo de vida de prueba. Dicho proceso debería negociar casos de prueba de BVT, que en última instancia garantizan el éxito de BVT. Establezca algunos estándares de calidad de BVT y estos estándares solo se pueden cumplir mediante el análisis de las principales características y escenarios del proyecto.

Por ejemplo, Casos de prueba que se incluirán en BVT para la aplicación de edición de texto (Solo algunas pruebas de muestra):

  • Caso de prueba para crear el archivo de texto.
  • Casos de prueba para escribir algo en el editor de texto
  • Caso de prueba para copiar, cortar y pegar la funcionalidad del editor de texto
  • Caso de prueba para abrir, guardar, eliminar archivos de texto.

Estos son algunos casos de prueba de muestra, que se pueden marcar como 'críticos' y para cada cambio menor o mayor en la aplicación, estos casos de prueba críticos básicos deben ejecutarse. BVT puede realizar esta tarea fácilmente.

Los trajes de automatización de BVT deben mantenerse y modificarse de vez en cuando. P.ej. Incluya casos de prueba en BVT cuando haya nuevos módulos de proyectos estables disponibles.

¿Qué sucede cuando se ejecuta BVT Suite?

Diga el conjunto de pruebas de automatización de verificación de compilación ejecutado después de cualquier nueva compilación.
#1) El resultado de la ejecución de BVT se envía a todos los ID de correo electrónico asociados con ese proyecto.
#2) El propietario de BVT (persona que ejecuta y mantiene la suite BVT) inspecciona el resultado de BVT.
#3) Si el BVT falla, el propietario del BVT diagnostica la causa de la falla.
#4) Si la causa de la falla es el defecto en la construcción, toda la información relevante con los registros de fallas se envía a los desarrolladores respectivos.
#5) Desarrollador en su diagnóstico inicial responde al equipo sobre la causa de la falla. ¿Si esto es realmente un error? Y si es un error, ¿cuál será su escenario de corrección de errores?
#6) En la corrección de errores, una vez más, se ejecuta el conjunto de pruebas BVT y, si la compilación pasa BVT, la compilación se pasa al equipo de prueba para obtener más detalles sobre la funcionalidad, el rendimiento y otras pruebas.

Este proceso se repite para cada nueva construcción.

¿Por qué fallaron BVT o Build?

El BVT se rompe a veces. Esto no significa que siempre haya un error en la compilación. Hay otras razones para fallar en la construcción, como el error de codificación del caso de prueba, el error de la suite de automatización, el error de infraestructura, las fallas de hardware, etc.
Debe solucionar la causa de la rotura del BVT y debe tomar las medidas adecuadas después del diagnóstico.

Consejos para el éxito de BVT:

#1) Dedique un tiempo considerable a escribir scripts de casos de prueba de BVT.
#2) Registre tanta información detallada como sea posible para diagnosticar el resultado de aprobación o falla de BVT. Esto ayudará al equipo de desarrolladores a depurar y conocer rápidamente la causa de la falla.
#3) Seleccione casos de prueba estables para incluirlos en BVT. Para nuevas funciones, si un nuevo caso de prueba crítico pasa consistentemente en una configuración diferente, entonces promueva este caso de prueba en su suite BVT. Esto reducirá la probabilidad de fallas frecuentes en la construcción debido a nuevos módulos inestables y casos de prueba.
#4) Automatice el proceso de BVT tanto como sea posible. Desde el proceso de lanzamiento de la compilación hasta el resultado de BVT, automatice todo.
#5) Tenga algunas penalizaciones por romper la construcción ;-) Algunos chocolates o una fiesta de café en equipo de un desarrollador que rompe la construcción será suficiente.

Conclusión

BVT no es más que un conjunto de casos de prueba de regresión que se ejecutan cada vez para la nueva compilación. A esto también se le llama prueba de humo. La compilación no se asigna al equipo de prueba a menos que y hasta que pase el BVT.

El desarrollador o evaluador puede ejecutar BVT y el resultado de BVT se comunica a todo el equipo y se toman medidas inmediatas para corregir el error si falla BVT. El proceso de BVT generalmente se automatiza escribiendo scripts para casos de prueba.

cómo hacer pruebas de penetración para un sitio web

En BVT solo se incluyen casos de prueba críticos. Estos casos de prueba deben garantizar la cobertura de la prueba de la aplicación. BVT es muy eficaz tanto para construcciones diarias como a largo plazo. Esto ahorra mucho tiempo, costos, recursos y, después de todo, no hay frustración para el equipo de prueba por la construcción incompleta.

Si tiene alguna experiencia en el proceso de BVT, compártala con nuestros lectores en los comentarios a continuación.

Lectura recomendada

^