- Prueba de humo en archivo de jerga
Fundación Wikimedia. 2010 .
Vea qué es "Prueba de humo" en otros diccionarios:
prueba de humo- sustantivo Un método de prueba de fugas en tuberías de drenaje o chimeneas mediante la introducción de humo denso, a menudo mediante el uso de una bomba de humo Entrada principal: humo ... Diccionario inglés útil
prueba de humo- Prueba realizada para determinar la integridad de la combustión... Diccionario de términos automotrices
prueba de humo- 1. sustantivo a) Una prueba de fugas que implica soplar humo en un tubo o tubería. b) Una prueba preliminar en una pieza de equipo electrónico recién construida, que consiste simplemente en la aplicación de energía eléctrica, para asegurarse de que no haya cableado atroz... ... Wikcionario
prueba de humo- es un término usado en plomería, reparación de instrumentos de viento, electrónica, desarrollo de software de computadora, y el industria del entretenimiento. Se refiere a la primera prueba realizada después de las reparaciones o el primer montaje para garantizar que el sistema bajo prueba... ... Wikipedia
prueba de humo- bzw. Rauchtest ist ein Begriff aus dem Englischen, gebräuchlich im handwerklichen Bereich (z. B. in der Klempnerei, Elektronik oder beim Bau von Holzblasinstrumenten) wie auch in der Softwareentwicklung. Es bezeichnet den ersten… … Wikipedia en alemán
Humo- es la colección de partículas y gases sólidos y líquidos transportados por el aire [Manual de ingeniería de protección contra incendios de la SFPE] emitidos cuando un material se somete a… … Wikipedia
Banco de pruebas- En el desarrollo de software, un conjunto de pruebas, menos comúnmente conocido como conjunto de validación, es una colección de casos de prueba destinados a probar un programa de software para demostrar que tiene un conjunto específico de comportamientos. Un conjunto de pruebas a menudo... ... Wikipedia
bomba de humo- Una bomba de humo es un fuego artificial diseñado para producir humo al encenderse. Si bien hay dispositivos generadores de humo que se lanzan desde los aviones, el término bomba de humo se utiliza para describir los tres tipos de dispositivos:# Una bola de humo es una cereza hueca… … Wikipedia
Las pruebas sanitarias y de humo comienzan inmediatamente después del lanzamiento de la próxima versión del proyecto. Para muchos probadores jóvenes, este proceso parece un caos absoluto. ¿Te reconociste? Entonces este articulo es para usted. Ahora veremos las definiciones de humo y pruebas de salud, y mostraremos la diferencia entre ellas con ejemplos fáciles de entender.
Prueba de humo:
La prueba de humo se lleva a cabo para asegurarse de que la construcción resultante sea adecuada para la prueba. También se llama cheque de día cero.
Es este tipo de prueba el que no le permitirá perder el tiempo. Es lógico que probar toda la aplicación no tenga sentido si hay problemas con características clave y los errores críticos no se han solucionado.
Pruebas sanitarias:
Las pruebas sanitarias se llevan a cabo en la etapa de lanzamiento para verificar la funcionalidad principal de la aplicación. Por lo general, no van más allá. Estas pruebas a veces se denominan una versión abreviada de las pruebas de regresión.
Cuando un lanzamiento está bajo presión, es casi imposible realizar pruebas de regresión exhaustivas. En este caso, las pruebas de cordura hacen un gran trabajo, ya que comprueban el funcionamiento de las funciones principales de la aplicación.
Un ejemplo para comprender mejor la diferencia entre las pruebas de humo y saneamiento:
Hay un proyecto para el cual se planea un lanzamiento inicial. El equipo de desarrollo lanza una compilación para la prueba, el equipo de prueba comienza a trabajar. La primera prueba es la prueba de idoneidad. Debe averiguar si puede trabajar con esta versión o no. Esta es la prueba de humo. Si el equipo da el visto bueno para seguir trabajando con la compilación, pasa a etapas más profundas de prueba. Imagine que la compilación tiene tres módulos: "Iniciar sesión", "Administrador" y "Empleado". El equipo de prueba verifica el desempeño de solo las funciones principales de cada uno de los módulos, sin profundizar en los detalles. Esto será una prueba de salud.
Algunas diferencias más entre las pruebas de humo y saneamiento:
- Las pruebas de humo las realizan tanto los desarrolladores como los evaluadores;
- Las pruebas sanitarias son realizadas solo por probadores.
- La prueba de humo cubre toda la funcionalidad principal de la aplicación de principio a fin;
- Las pruebas sanitarias solo prueban un componente específico de una aplicación.
- La prueba de humo pasa por construcciones estables y no estables;
- Una versión relativamente estable de la construcción se está sometiendo a pruebas de saneamiento.
Kirill Flyagin, diseñador de juegos, líder de control de calidad
Dibujemos una analogía de verano con este tipo de pruebas. Digamos que quieres comprar una sandía. La prueba de humo es cuando lo revisas visualmente, miras las tiras, aprietas, golpeas, evalúas. Hay maestros que logran comprar una baya realmente sabrosa de esta manera. En las pruebas de salud, cortas una pirámide en la parte superior y compruebas su color (como uno de los componentes), sin saber en absoluto si toda la sandía es así. Pero para la parte cortada estás completamente seguro.
Después de realizar los cambios necesarios, como corregir un error/defecto, software debe volver a probarse para confirmar que el problema se ha resuelto. Los siguientes son los tipos de pruebas que deben realizarse después de instalar el software para confirmar que la aplicación funciona o que se ha corregido un defecto:
- Prueba de humo(Prueba de humo)
- Pruebas de regresión(Pruebas de regresión)
- Pruebas de compilación(Prueba de verificación de compilación)
- Pruebas sanitarias o verificación de consistencia/salud(Prueba de cordura)
concepto prueba de humo vino de la ingeniería. A la hora de poner en marcha nuevos equipos ("hierro"), se consideraba que la prueba había sido satisfactoria si no salía humo de la instalación. En el campo de las pruebas de software, tiene como objetivo una verificación superficial de todos los módulos de la aplicación para verificar la operatividad y la presencia de defectos críticos y de bloqueo que se encuentran rápidamente. De acuerdo con los resultados de las pruebas de humo, se llega a una conclusión si se acepta o no. versión instalada software para pruebas, operación o entrega al cliente. Para facilitar el trabajo, ahorrar tiempo y recursos humanos, se recomienda implementar la automatización de escenarios de prueba para pruebas de humo.
Pruebas de regresión es un tipo de prueba destinada a verificar los cambios realizados en una aplicación o ambiente(arreglar un defecto, fusionar código, migrar a otro sistema operativo, base de datos, servidor web o servidor de aplicaciones) para confirmar que la funcionalidad preexistente funciona como antes (consulte también Pruebas sanitarias o Comprobación de estado/consistencia). La regresión puede ser funcional, entonces no funcional pruebas
Por regla general, para las pruebas de regresión se utilizan casos de prueba, escritos en primeras etapas desarrollo y pruebas. Esto asegura que los cambios en nueva versión las aplicaciones no duelen funcionalidad existente. Se recomienda automatizar las pruebas de regresión para acelerar el proceso de prueba posterior y detectar defectos en las primeras etapas del desarrollo del software.
El término "prueba de regresión" en sí mismo, según el contexto de uso, puede tener un significado diferente. Sam Kaner, por ejemplo, describió 3 tipos principales pruebas de regresión:
- Regresión de errores es un intento de demostrar que un error solucionado no está realmente solucionado.
- Regresión de errores antiguos- un intento de demostrar que un cambio reciente en el código o en los datos rompió la corrección de errores antiguos, es decir, viejos errores comenzaron a jugar de nuevo.
- Regresión efecto secundario(Regresión de efectos secundarios)- un intento de demostrar que un código reciente o un cambio de datos rompió otras partes de la aplicación que se estaba desarrollando.
Pruebas de cordura o Pruebas de consistencia (Pruebas de cordura) – esta es una prueba limitada, suficiente para demostrar que una función en particular funciona de acuerdo con los requisitos establecidos en la especificación. Es un subconjunto de las pruebas de regresión. Se utiliza para determinar el estado de una parte particular de la aplicación después de que se hayan realizado cambios en ella o en el entorno. Por lo general, se hace manualmente.
La diferencia entre las pruebas sanitarias y las pruebas de humo. Algunas fuentes creen erróneamente que las pruebas sanitarias y de humo son lo mismo. Creemos que estos tipos de pruebas tienen "vectores de movimiento", direcciones en lados diferentes. A diferencia de las pruebas de humo, las pruebas de cordura se dirigen profundamente a la función probada, mientras que las pruebas de humo se dirigen en amplitud, para cubrir la mayor funcionalidad posible con pruebas en el menor tiempo posible.
Pruebas de compilación(Build Verification Test) es una prueba destinada a determinar si la versión lanzada cumple con los criterios de calidad para iniciar la prueba. De acuerdo con sus objetivos, es un análogo de la prueba de humo, destinado a aceptar una nueva versión para realizar más pruebas u operaciones. Puede penetrar más en las profundidades, según los requisitos de calidad de la versión lanzada.
Pruebas de instalación - tiene como objetivo verificar la instalación y configuración exitosas, así como actualizar o desinstalar el software. Por el momento, la instalación más común de software usando instaladores(programas especiales que también requieren pruebas adecuadas). En condiciones reales, puede que no haya instaladores. En este caso, deberá instalar el software usted mismo, utilizando la documentación en forma de instrucciones o archivos Léame, describiendo paso a paso todas las acciones y comprobaciones necesarias. En los sistemas distribuidos donde la aplicación se implementa en un entorno que ya se está ejecutando, un simple conjunto de instrucciones puede no ser suficiente. Para ello, muchas veces, se redacta un plan de deployment (Deployment Plan), que incluye no solo los pasos para instalar la aplicación, sino también los pasos de rollback (roll-back) a la versión anterior, en caso de falla. El plan de instalación en sí también debe pasar por un procedimiento de prueba para evitar problemas cuando se ponga en funcionamiento. Esto es especialmente cierto si la instalación se realiza en sistemas donde cada minuto de tiempo de inactividad es una pérdida de reputación y una gran cantidad de fondos, por ejemplo: bancos, compañías financieras o incluso redes de publicidad. Por lo tanto, las pruebas de instalación pueden considerarse una de las tareas más importantes para garantizar la calidad del software.
Exactamente así Un enfoque complejo con planes de escritura, verificación paso a paso de la instalación y reversión de la instalación, puede llamarse correctamente prueba de instalación o prueba de instalación.
Si desea crear un sencillo programa de computadora, que consta de un solo archivo, solo necesita recopilar y vincular todo el código que escribió en este archivo. Realmente proyecto regular, que está a cargo del equipo de desarrollo, hay cientos, incluso miles de archivos. Esto "contribuye" al hecho de que el proceso de creación de un programa ejecutable se vuelve más complejo y lento: debe "ensamblar" el programa a partir de varios componentes.
La práctica utilizada, por ejemplo, en Microsoft y algunas otras empresas de desarrollo de software, es construir el programa diariamente, que se complementa con pruebas de humo. Diariamente, después de compilar (construir, crear), vincular (vincular) y combinar cada archivo en un programa ejecutable, el programa mismo se somete a un conjunto bastante simple de pruebas, cuyo propósito es ver si el programa "fuma" durante el trabajo. Estas pruebas se denominan pruebas de humo (del inglés smoke - humo). La mayoría de las veces, este proceso está bastante bien automatizado (o debería estarlo).
BENEFICIOS. Este proceso simple proporciona varios beneficios significativos.
Minimización de riesgos durante la integración
Uno de los riesgos más importantes a los que se enfrenta un equipo de desarrollo es que los propios desarrolladores trabajen el código por separado, de forma independiente unos de otros, por lo que un programa complejo no funcione como se esperaba a la hora de construir el código desarrollado. Dependiendo de cuándo se descubrió la incompatibilidad en el proyecto, la depuración del programa puede demorar más que con la integración anterior, especialmente si la interfaz del programa ha cambiado o después de la implementación de cambios importantes en las partes principales del programa.
El montaje y ejecución diaria de pruebas de humo permite reducir el riesgo de errores de integración, responder a tiempo a los mismos y evitar su acumulación.
Reducir el riesgo de mala calidad del producto de software
La baja calidad del producto depende directamente de las fallas y problemas durante la integración. La ejecución diaria de un conjunto mínimo de pruebas de humo evita que los errores y los problemas se apoderen del proyecto. Si lleva el proyecto a un estado estable una vez, permanecerá estable para siempre. De esta manera, nunca permitirá que la calidad disminuya hasta el nivel en el que se producen errores.
Ayuda en el diagnóstico de errores.
Si un día el producto no se compila (construido con errores), es mucho más fácil encontrar la causa del problema compilando diariamente y ejecutando una serie de pruebas de humo. Un producto que funcionó ayer y no funcionó hoy es un indicio claro de que algo salió mal entre las dos compilaciones.
Mejora de la moral
Si el producto funciona y adquiere más y más cualidades y funciones nuevas todos los días, la moral de los desarrolladores, en teoría, debería crecer y no importa en absoluto qué debería hacer exactamente este producto. Siempre es un placer para un desarrollador ver su “creación original” en funcionamiento, incluso si el producto muestra un rectángulo en la pantalla :)
Uso de compilaciones diarias y pruebas de humo
Aquí hay algunos detalles de este principio.
Creación diaria de aplicaciones
Una parte fundamental de la construcción diaria es la construcción de la pieza que se hizo en último lugar. Jim McCarthy en Dynamics of Software Development (Microsoft Press, 1995) llamó a la compilación diaria del proyecto su latido. Si no hay latido, no hay proyecto, está muerto. De forma menos figurativa, Michael Cusumano y Richard W. Selby describieron la compilación diaria como el impulso sincronizador del proyecto (Microsoft Secrets, The Free Press, 1995). Cada desarrollador escribe el código a su manera y él, el código, puede ir más allá del marco generalmente aceptado en el proyecto; esto es normal, pero con cada exposición a un pulso de sincronización, el código vuelve al estándar. Al insistir en desarrollar con el pulso de sincronización constantemente, evita que el proyecto se desincronice por completo.
En algunas empresas, es costumbre recoger el proyecto no todos los días, sino una vez a la semana. Este sistema es erróneo, porque en el caso de una "falla" en el proyecto esta semana, pueden pasar un par de semanas antes de la próxima construcción exitosa. En este caso, la empresa pierde todos los beneficios del sistema de construcción de proyectos diarios.
Comprobar si hay una compilación fallida
En el caso de una compilación diaria del proyecto, se supone que el proyecto debería funcionar. Sin embargo, si el proyecto no funciona, arreglarlo se convierte en una tarea con prioridad 1.
Cada proyecto tiene su propio estándar y una señal de lo que se llama "fallo de construcción". Este estándar debe especificar un nivel de calidad que sea suficiente para realizar un seguimiento de los defectos menores y no pasar por alto los defectos que "bloquean" el proyecto.
Una buena construcción es aquella en la que al menos:
- todos los archivos, bibliotecas y otros componentes se compilan con éxito;
- los enlaces a todos los archivos, bibliotecas y otros componentes son válidos;
- no contiene ningún sistémico estable, excluyendo la posibilidad operación correcta errores de bloqueo del programa de aplicación;
- pasan todas las pruebas de humo.
Pruebas diarias de humo
Se deben realizar pruebas de humo en todo el proyecto de principio a fin. No tienen que ser exhaustivos y completos, pero deben contener una prueba de todas las funciones principales. La prueba de humo debe ser lo suficientemente profunda como para que, si pasa con éxito, pueda llamar al proyecto estable y llamarlo de tal manera que pueda someterse a pruebas más profundas.
El punto de montaje diario se pierde sin pruebas de humo. Este proceso vela por la calidad del producto y no permite ningún problema de integración. Sin esto, el proceso de compilación diario es una pérdida de tiempo, cuyo propósito es verificar la compilación.
Las pruebas de humo deberían evolucionar con el proyecto. Al principio, las pruebas de humo verificarán algo tan simple como si el proyecto puede producir un mensaje de "¡Hola, mundo!". A medida que el sistema evoluciona, las pruebas de humo se vuelven más profundas. El tiempo dedicado a las primeras pruebas de humo se calcula en unos pocos segundos, sin embargo, a medida que crece el sistema, también aumenta la cantidad de tiempo necesario para la prueba de humo. Al final de un proyecto, la prueba de humo puede durar horas.
Definición de grupo de compilación
En la mayoría de los proyectos, hay una persona designada responsable de verificar la construcción diaria del sistema y realizar pruebas de humo. Este trabajo es parte de los deberes de este empleado, pero en grandes proyectos puede haber más empleados de este tipo y ese trabajo es su principal responsabilidad. Por ejemplo, había cuatro personas en el equipo de compilación del proyecto Windows NT 3.0 (Pascal Zachary, espectáculo tapón!, La Prensa Libre, 1994).
Solo agregue una revisión a una compilación si tiene sentido.
Por lo general, los desarrolladores escriben individualmente el código con la suficiente lentitud para que se puedan agregar cambios significativos al sistema a diario. Tienen que trabajar en gran parte del código e integrarlo en el sistema cada pocos días.
|
Ingrese un sistema de sanciones por interrumpir el lanzamiento del siguiente ensamblaje (lanzamiento de un ensamblaje que no funciona). |
La mayoría de los proyectos tienen un sistema de sanciones por no lanzar la próxima compilación. Al comienzo del proyecto, vale la pena dejar en claro que la preservación del borrador de trabajo es la tarea de la más alta prioridad. Romper el lanzamiento de la próxima compilación puede ser la excepción, pero de ninguna manera la regla. Insista en que los desarrolladores dejen todo hasta que el sistema vuelva a funcionar. En el caso de fallas de compilación frecuentes (lanzamiento de una compilación que no funciona), es bastante difícil volver a encarrilar el proyecto.
Destacan las multas menores un alto grado la necesidad de monitorear la calidad de construcción del sistema. En algunos proyectos, los desarrolladores que hacen que el ensamblaje se bloquee reciben recompensas por liberar un ensamblaje que no funciona. El letrero correspondiente cuelga en la puerta de la oficina de dicho desarrollador hasta que arregle el ensamblaje (siempre que los desarrolladores tengan oficinas separadas :)). En otros proyectos, los desarrolladores culpables deben usar cuernos de cabra artificiales o contribuir con una cierta cantidad a un "fondo de moral" (ejemplos tomados de la historia de empresas reales).
Pero en algunos proyectos, se introducen sanciones más graves. Por ejemplo, los desarrolladores de Microsoft en proyectos de alta prioridad (Windows NT, Windows 95, Excel) usaban buscapersonas y tenían que presentarse a trabajar si se detectaba una inspección. Incluso si se descubrió una avería o un error a las 3 am.
Construya el sistema y "huméelo" incluso bajo presión
Cuando se intensifica la presión sobre el cronograma de lanzamiento de un proyecto, el trabajo de verificar la compilación de un sistema todos los días puede parecer una pérdida de tiempo. Sin embargo, no lo es. V situaciones estresantes Los desarrolladores a menudo cometen errores. Sienten tal presión para lanzar implementaciones que simplemente no tienen en condiciones normales. Verifican su código con pruebas unitarias con mucho menos cuidado de lo habitual. En tales situaciones, el código tiende al estado de entropía mucho más rápido que en situaciones menos estresantes.
¿Quién se beneficia de este proceso? Algunos desarrolladores protestan contra las compilaciones diarias, justificando sus protestas con la impracticabilidad de esta actividad y su gran costo de tiempo. Pero todo sistemas complejos han sido sometidos recientemente a pruebas diarias de montaje y humo. En el momento de su lanzamiento, Microsoft Windows NT 3.0 contenía 5,6 millones de líneas en 40.000 archivos. Una compilación completa tomó 19 horas y se ejecutó en varias computadoras. A pesar de esto, los desarrolladores lograron ensamblar el sistema diariamente. Como equipo profesional, el equipo de desarrollo de NT debe gran parte de su éxito a las compilaciones diarias. Aquellos desarrolladores que trabajan en proyectos menos complejos y, por lo tanto, no aprovechan el proceso de construcción diario, deberían considerar encontrar algunas explicaciones razonables para ellos mismos.
Los errores simples pueden ser fatales para su sitio, especialmente si es una empresa SaaS (software como servicio ing.), como nosotros. Si un usuario visita su sitio y no puede completar una tarea simple como registrarse o restablecer su Contraseña olvidada, corre el riesgo de perder a este usuario para siempre.
Lo hemos experimentado en nuestra propia piel. Por supuesto, tener su propia gente en el equipo que prueba la aplicación y busca errores es importante, pero no siempre es apropiado o no es lo suficientemente exhaustivo. En este artículo, queremos presentarles a ustedes, los humanistas, el mundo de las pruebas de humo.
Si aún tiene preguntas, puede completar los espacios en blanco visitando
La prueba de humo se concibió originalmente para explicar cómo los ingenieros eléctricos probaban si su aparato funcionaba: lo encendían y si salía humo...
Espera, ¿cómo se puede aplicar esto a las aplicaciones?
La importancia (y la rentabilidad) de las pruebas de humo generalmente es desconocida para los gerentes y cofundadores de humanidades. Las pruebas sistemáticas de humo pueden verse como una parte esencial para prevenir un aumento en la probabilidad de un ataque. Minimizan la posibilidad de que su aplicación web o telefónica se bloquee y, como todos sabemos, solo una falla y puede perder un cliente para siempre.
Esta es una guía introductoria sobre qué es, cómo se puede implementar, qué recursos se utilizan para llevarlo a cabo y ejemplos para guiar a los lectores.
Las pruebas de humo están diseñadas para probar la funcionalidad básica y deben ser una parte integral de su proceso de prueba. Pueden incluir algo tan simple como "¿Puedo registrarme?".
Las pruebas de humo ayudan a garantizar que ninguna de las fallas más importantes y obvias se deje al azar. No debe realizar una prueba más profunda hasta que haya realizado pruebas de humo al 100%, ya que eliminan errores fundamentales en el software.
Paso 1: Decida qué probar
Determine lo que su aplicación está tratando de lograr. ¿Cuáles son los pasos "pequeños" más obvios que se necesitan para entrar en él? ¿Cuáles son los requisitos vitales mínimos y en qué orden lógico los enumeraría?
Cree un conjunto de pruebas. Un conjunto de pruebas es una colección agrupada de casos de prueba (casos de prueba) relacionados de cierta manera (por ejemplo, por funcionalidad).
Las pruebas de humo no incluirán variables o preguntas "¿qué pasaría si?". Asume solo respuestas de sí/no, pero antes de pasar a pruebas más detalladas, todos los casos de prueba deben aprobarse con un resultado positivo.
Tomemos como ejemplo la creación de un foro interactivo. Para que funcione tengo que:
- Registrarse.
- crear nombre de usuario.
- sube una foto de avatar.
- escribir mensajes.
- responder mensajes.
Paso 2: escribe los resultados en una tabla
La imagen de arriba es un ejemplo de nuestro equipo. Puedes encontrar el patrón. Esto es necesario para mantener un registro de lo que funciona para nosotros y lo que no: la organización básica ahorrará mucho tiempo más adelante. Dividimos nuestros puntajes en Aprobado, Parcial y Reprobado.
- Pasado: todo funciona perfectamente.
- Parcial: Inicialmente, es posible que no entienda que algunas acciones pueden subdividirse más y, por lo tanto, una parte funciona y la otra no.
- Error: no funciona.
Hemos descrito los pasos exactos que queríamos reproducir y luego, en la siguiente columna, hemos agregado una breve descripción de lo que esperamos que sea el resultado. Ejemplo:
Paso 3: Automatización de pruebas de humo
Es muy importante no tomar como un axioma que si alguna acción se completó una vez, siempre tendrá un resultado positivo. Las pruebas de humo le permiten verificar constantemente que las funciones principales no han sufrido con el tiempo o no se han roto durante un período prolongado.
No dejes de hacer pruebas de humo. Nunca.
Cuando su conjunto de casos de prueba de humo se completa con éxito en 100%, considera automatizarlos. La frecuencia recomendada de las pruebas de humo es todos los días si su empresa desarrolla todos los días.
Lo mínimo es realizar pruebas de humo antes de cada lanzamiento y después de cada parche.
Regla general para las pruebas de humo:
- Tiempo mínimo: 30 minutos.
- Tiempo máximo: 60 minutos.
V perspectiva adicional automatizar las pruebas de humo ahorra tiempo, pero cuando se ejecutan las mismas pruebas una y otra vez, el ojo humano puede dejar de notar los detalles, pero la máquina no.