Tipos de pruebas relacionadas con cambios

¡Hola Habr! Una vez en nuestro seminario interno, mi supervisor, el jefe del departamento de pruebas, comenzó su discurso con las palabras "no es necesario realizar pruebas". Todos en el pasillo guardaron silencio, algunos incluso intentaron caer de sus sillas. Continuó con su pensamiento: sin pruebas, es muy posible crear un proyecto complejo y costoso. Y lo más probable es que funcione. Pero imagine cuánta más confianza se sentirá al saber que el producto funciona como debería.

En Badoo, los lanzamientos ocurren con bastante frecuencia. Por ejemplo, la parte del servidor, junto con la web de escritorio, se lanza dos veces al día. Por eso sabemos de primera mano que las pruebas complejas y lentas son un obstáculo para el desarrollo. Las pruebas rápidas son una bendición. Entonces, hoy hablaré sobre cómo se organizan las pruebas de humo en Badoo.

¿Qué es la prueba de humo?

Este término fue utilizado por primera vez por los fabricantes de estufas, quienes, después de ensamblar la estufa, cerraron todos los enchufes, la inundaron y se aseguraron de que el humo saliera solo de los lugares designados. Wikipedia

En su aplicación original, la prueba de humo está destinada a probar los casos más simples y obvios, sin los cuales cualquier otro tipo de prueba sería injustificadamente redundante.

Veamos un ejemplo sencillo. La versión de preproducción de nuestra aplicación se encuentra en bryak.com (cualquier similitud con sitios reales es aleatoria). Hemos preparado y subido una nueva versión allí para probarla. ¿Qué deberías comprobar primero? Yo empezaría comprobando que la aplicación sigue abierta. Si el servidor web nos responde “200”, entonces todo está bien y podemos empezar a comprobar la funcionalidad.

¿Cómo automatizar dicho control? En principio, puede escribir una prueba funcional que abra el navegador, abra la página deseada y se asegure de que se muestra como se esperaba. Sin embargo, esta solución tiene una serie de desventajas. En primer lugar, es largo: el proceso de inicio del navegador llevará más tiempo que la verificación en sí. En segundo lugar, esto requiere mantener una infraestructura adicional: para una prueba tan simple, necesitaremos tener un servidor con navegadores en algún lugar. Conclusión: necesitamos resolver el problema de otra manera.

Nuestra primera prueba de humo

En Badoo, el lado del servidor está escrito principalmente en PHP. Por razones obvias, las pruebas unitarias están escritas en él. Entonces ya tenemos PHPUnit. Para no multiplicar tecnologías innecesariamente, decidimos escribir pruebas de humo también en PHP. Además de PHPUnit, necesitaremos una biblioteca cliente para trabajar con URL (libcurl) y una extensión PHP para trabajar con ella: cURL.

Básicamente, las pruebas simplemente realizan las solicitudes que necesitamos al servidor y verifican las respuestas. Todo está ligado al método getCurlResponse() y a varios tipos de afirmaciones.

El método en sí se parece a esto:

Función pública getCurlResponse($url, matriz $params = [ 'cookies' => , 'post_data' => , 'headers' => , 'user_agent' => , 'proxy' => , ], $follow_location = true, $ respuesta_esperada = '200 OK') ( $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, $url); curl_setopt($ch, CURLOPT_HEADER, 1); curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); if (isset( $params['cookies']) && $params['cookies']) ( $cookie_line = $this->prepareCookiesDataByArray($params['cookies']); curl_setopt($ch, CURLOPT_COOKIE, $cookie_line); ) if ( isset($params['headers']) && $params['headers']) ( curl_setopt($ch, CURLOPT_HTTPHEADER, $params['headers']); ) if (isset($params['post_data']) && $params['post_data']) ( $post_line = $this->preparePostDataByArray($params['post_data']); curl_setopt($ch, CURLOPT_POST, 1); curl_setopt($ch, CURLOPT_POSTFIELDS, $post_line); ) si ($follow_location) ( curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1); ) if (isset($params['proxy']) && $params['proxy']) ( curl_setopt($ch, CURLOPT_PROXY, $params['proxy ']);
El método en sí puede devolver una respuesta del servidor basada en una URL determinada. Acepta parámetros como entrada, como cookies, encabezados, agente de usuario y otros datos necesarios para realizar una solicitud. Cuando se recibe una respuesta del servidor, el método comprueba que el código de respuesta coincida con el esperado. Si este no es el caso, la prueba falla con un error que lo indica. Esto se hace para que sea más fácil determinar la causa de la caída. Si la prueba falla en alguna afirmación, diciéndonos que no hay ningún elemento en la página, el error será menos informativo que un mensaje que indique que el código de respuesta, por ejemplo, es “404” en lugar del esperado “200”.

Cuando se envía la solicitud y se recibe la respuesta, registramos la solicitud para que en el futuro, si es necesario, sea fácil reproducir la cadena de eventos si la prueba falla o se rompe. Hablaré de esto a continuación.

La prueba más simple se parece a esto:

Función pública testStartPage() ( $url = ‘bryak.com’; $respuesta = $this->getCurlResponse($url); $this->assertHTMLPresent("
Esta prueba dura menos de un segundo. Durante este tiempo, verificamos que la página de inicio responde con “200” y tiene un elemento de cuerpo. Con el mismo éxito, podemos probar cualquier cantidad de elementos en la página, la duración de la prueba no cambiará significativamente.

Las ventajas de tales pruebas:

• Velocidad: la prueba se puede ejecutar tantas veces como sea necesario. Por ejemplo, por cada cambio de código;
• no requieren software o hardware especial para funcionar;
• son fáciles de escribir y mantener;
• son estables.

Respecto al último punto. Me refiero a no menos estable que el proyecto en sí.

Autorización

Imaginemos que han pasado tres días desde que escribimos nuestra primera prueba de humo. Por supuesto, durante este tiempo cubrimos con pruebas todas las páginas no autorizadas que encontramos. Nos sentamos un rato, nos alegramos, pero luego nos dimos cuenta de que todo lo más importante de nuestro proyecto está detrás de la autorización. ¿Cómo puedo tener la oportunidad de probar esto también?

La opción más sencilla es una cookie de autorización. Si lo añadimos a la petición el servidor nos “reconocerá”. Una cookie de este tipo se puede codificar en una prueba si su vida útil es bastante larga, o se puede obtener automáticamente enviando solicitudes a la página de autorización. Echemos un vistazo más de cerca a la segunda opción.

Nos interesa el formulario donde debemos ingresar el nombre de usuario y contraseña del usuario.

Abra esta página en cualquier navegador y abra el inspector. Introduce los datos del usuario y envía el formulario.

Ha aparecido una solicitud en el inspector, que debemos simular en la prueba. Puede ver qué datos, además de los obvios (nombre de usuario y contraseña), se envían al servidor. Es diferente para cada proyecto: puede ser un token remoto, datos de cookies recibidas anteriormente, un agente de usuario, etc. Cada uno de estos parámetros deberá obtenerse primero en la prueba antes de generar una solicitud de autorización.

En las herramientas de desarrollo de cualquier navegador, puede copiar la solicitud seleccionando la opción copiar como cURL. De esta forma, el comando se puede insertar en la consola y verlo allí. Allí podrás probarlo cambiando o agregando parámetros.

En respuesta a dicha solicitud, el servidor nos devolverá cookies, que agregaremos a solicitudes posteriores para probar las páginas autorizadas.

Dado que la autorización es un proceso bastante largo, sugiero obtener la cookie de autorización solo una vez para cada usuario y almacenarla en algún lugar. Por ejemplo, almacenamos dichas cookies en una matriz. La clave es el inicio de sesión del usuario y el valor es información sobre él. Si aún no hay una clave para el siguiente usuario, inicie sesión. Si lo hay, realizamos la solicitud que nos interese inmediatamente.

Función pública testAuthPage() ( $url = 'bryak.com'; $cookies = $this->getAuthCookies(' [correo electrónico protegido]', '12345'); $respuesta = $this->getCurlResponse($url, ['cookies' => $cookies]);
$this->assertHTMLPresent("

", $respuesta, "Error: la prueba no puede encontrar el elemento del cuerpo en la página."); )
El método primero verifica si un correo electrónico determinado (en su caso, podría ser un inicio de sesión o algo más) tiene una cookie de autorización recibida previamente. Si lo hay, lo devuelve. De lo contrario, realiza una solicitud a la página de autorización (por ejemplo, bryak.com/auth_page_adds) con los parámetros necesarios: correo electrónico de usuario y contraseña. En respuesta a esta solicitud, el servidor envía cabeceras, entre las que se encuentran las cookies que nos interesan. Se parece a esto:

HTTP/1.1 200 OK Servidor: nginx Tipo de contenido: texto/html; charset=utf-8 Codificación de transferencia: fragmentada Conexión: mantener vivo Set-Cookie: nombre=valor; caduca = miércoles, 30 de noviembre de 2016, 10:06:24 GMT; Edad máxima = -86400; ruta=/; dominio=bryak.com
A partir de estos encabezados, usando una expresión regular simple, necesitamos obtener el nombre de la cookie y su valor (en nuestro ejemplo es nombre=valor). Nuestro método que analiza la respuesta se ve así:

$this->assertTrue((bool)preg_match_all("/Set-Cookie: (([^=]+)=([^;]+);.*)\n/", $respuesta, $mch1), " No se pueden obtener "cookies" de la respuesta del servidor: " . $respuesta);
Una vez recibidas las cookies, podemos agregarlas de forma segura a cualquier solicitud para autorizarla.

Análisis de pruebas fallidas.

De lo anterior se deduce que dicha prueba es un conjunto de solicitudes al servidor. Hacemos una solicitud, manipulamos la respuesta, hacemos la siguiente solicitud, etc. Se me viene a la cabeza un pensamiento: si una prueba de este tipo falla en la décima solicitud, puede que no sea fácil descubrir el motivo de su fracaso. ¿Cómo simplificar tu vida?

En primer lugar, me gustaría recomendar pruebas de atomización tanto como sea posible. No deberías probar 50 casos diferentes en una sola prueba. Cuanto más sencilla sea la prueba, más fácil será en el futuro.

También es útil para recolectar artefactos. Cuando nuestra prueba falla, guarda la última respuesta del servidor en un archivo HTML y lo arroja al almacenamiento de artefactos, donde este archivo se puede abrir desde un navegador especificando el nombre de la prueba.

Por ejemplo, nuestra prueba falló porque no pudo encontrar un fragmento de HTML en la página:

Enlace
Nos dirigimos a nuestro recopilador y abrimos la página correspondiente:

Puede trabajar con esta página como cualquier otra página HTML en su navegador. Puedes utilizar un localizador CSS para intentar encontrar el elemento que falta y, si realmente no está allí, decidir si ha cambiado o se ha perdido. ¡Es posible que hayamos encontrado un error! Si el elemento está en su lugar, tal vez cometimos un error en algún lugar de la prueba; debemos mirar cuidadosamente en esa dirección.

El registro también ayuda a hacer la vida más fácil. Intentamos registrar todas las solicitudes realizadas por una prueba fallida para que puedan repetirse fácilmente. En primer lugar, esto le permite realizar rápidamente una serie de acciones similares con las manos para reproducir el error y, en segundo lugar, le permite identificar pruebas que fallan con frecuencia, si tenemos alguna.

Además de ayudarnos a solucionar errores, los registros descritos anteriormente nos ayudan a crear una lista de páginas autorizadas y no autorizadas que hemos probado. Al mirarlo, es fácil encontrar y eliminar huecos.

Lo último que puedo aconsejar, pero no menos importante, es que las pruebas sean lo más cómodas posible. Cuanto más fáciles sean de lanzar, más a menudo se utilizarán. Cuanto más claro y conciso sea el informe de la caída, más detenidamente será estudiado. Cuanto más simple sea la arquitectura, más pruebas se escribirán y menos tiempo llevará escribir otras nuevas.

Si cree que utilizar pruebas es un inconveniente, lo más probable es que no lo crea. Esto debe solucionarse lo antes posible. De lo contrario, corre el riesgo de que en algún momento empiece a prestar menos atención a estas pruebas, lo que puede provocar que se pase por alto un error en producción.

En palabras la idea parece obvia, estoy de acuerdo. Pero, en realidad, todos tenemos margen de mejora. Simplifique y optimice sus creaciones y viva sin errores. :)

Resultados

Por el momento tenemos *abierto TimCity* vaya, ya hay 605 pruebas. Todas las pruebas, si no se realizan en paralelo, pasan en poco menos de cuatro minutos.

Durante este tiempo nos aseguramos de que:

• nuestro proyecto se abre en todos los idiomas (de los cuales tenemos más de 40 en producción);
• para los principales países, se muestran las formas de pago correctas con el conjunto correspondiente de métodos de pago;
• las solicitudes API básicas funcionan correctamente;
• la página de destino para redirecciones funciona correctamente (incluso a un sitio móvil con el agente de usuario adecuado);
• Todos los proyectos internos se muestran correctamente.

Las pruebas en Selenium WebDriver para todo esto requerirían mucho más tiempo y recursos.

Agregar etiquetas

Las pruebas sanitarias y de humo comienzan inmediatamente después del lanzamiento de la próxima versión del proyecto. Para muchos jóvenes probadores, este proceso parece un caos absoluto. ¿Te reconoces a ti mismo? Entonces este artículo es para ti. Ahora veremos las definiciones de prueba de humo y prueba sanitaria y mostraremos las diferencias entre ellas con ejemplos fáciles de entender.

Se llevan a cabo pruebas de humo para garantizar que la construcción resultante sea adecuada para la prueba. También se le llama verificación de “día cero”.

Este tipo de pruebas evitará que pierdas el tiempo. Es lógico que probar toda la aplicación no tenga sentido si hay problemas con características clave y 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 básica de la aplicación. Generalmente no van más allá. Esta prueba a veces se denomina versión abreviada de la prueba de regresión.
Cuando los plazos de lanzamiento son ajustados, realizar pruebas de regresión exhaustivas es casi imposible. En este caso, las pruebas sanitarias, que comprueban el funcionamiento de las funciones principales de la aplicación, hacen un gran trabajo.

Un ejemplo para comprender mejor la diferencia entre pruebas de humo y sanitarias:

Hay un proyecto para el que está previsto un lanzamiento inicial. El equipo de desarrollo publica la compilación para realizar pruebas y el equipo de pruebas comienza a trabajar. La primera prueba es la prueba de aptitud. Debe averiguar si puede trabajar con esta versión o no. Esta es una prueba de humo. Si el equipo da el visto bueno para seguir trabajando con la compilación, se envía a etapas de prueba más profundas. Imaginemos que la compilación tiene tres módulos: "Inicio de sesión", "Administrador" y "Empleado". Un equipo de probadores comprueba la funcionalidad sólo de las funciones básicas de cada módulo, sin entrar en detalles. Serán pruebas sanitarias.

Algunas diferencias más entre las pruebas de humo y sanitarias:

• Las pruebas de humo las llevan a cabo tanto los desarrolladores como los evaluadores;
• Las pruebas sanitarias las realizan únicamente los evaluadores.

• Las pruebas de humo cubren todas las funciones principales de la aplicación de principio a fin;
• Las pruebas de saneamiento solo prueban un componente específico de la aplicación.

• Las pruebas de humo pasan tanto en construcciones estables como inestables;
• Una versión relativamente estable de la construcción está siendo sometida a pruebas sanitarias.

Kirill Flyagin, diseñador de juegos, responsable de control de calidad

Hagamos una analogía veraniega 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 y evalúas. Hay artesanos que de esta manera consiguen comprar bayas realmente sabrosas. En las pruebas sanitarias, se corta una pirámide en la parte superior y se comprueba su color (como uno de los componentes), pero no se sabe en absoluto si toda la sandía es así. Pero tienes plena confianza en la parte cortada.

La traducción se diluye con reflexiones del autor y añadidos de su propia experiencia.

¿De qué se trata todo esto?

Como ingeniero de pruebas, probablemente haya oído hablar de las pruebas de humo, las pruebas de cordura, las repruebas y las pruebas de regresión. Es muy posible que utilices muchos de estos tipos a diario.

En este artículo, me gustaría aclarar y explicar la diferencia entre estos tipos de pruebas e intentar resolverla, trazar límites (aunque condicionales) donde termina un tipo de prueba y comienza otro.

Para aquellos nuevos en las pruebas (e incluso para los probadores experimentados), separar estos conceptos puede resultar difícil. Y realmente, ¿cómo se puede saber dónde comienzan las pruebas de saneamiento y dónde terminan las pruebas de humo? ¿Cuánto necesitamos limitar las pruebas de parte de la funcionalidad del sistema o sus componentes para llamarlas pruebas de “humo”? ¿Ingresar un nombre de usuario/contraseña en el formulario de inicio de sesión de un usuario en un sitio es una prueba de humo, o el hecho mismo de su aparición en la página de un sitio ya es una prueba aprobada?

Estrictamente hablando, aún puedes realizar pruebas, aunque no podrás saber exactamente cuál es la diferencia. Ni siquiera tienes que pensar en distinguir qué tipo de pruebas estás realizando actualmente. Pero aún así, para superarte a ti mismo en un sentido profesional, necesitas saber qué estás haciendo, por qué y qué tan correctamente lo estás haciendo.

programa educativo

A continuación se presentan breves definiciones de los tipos de pruebas que comparamos hoy:

• Pruebas de humo: se realizan cada vez que recibimos una nueva compilación (versión) de un proyecto (sistema) para probar, considerándolo relativamente inestable. Necesitamos asegurarnos de que las funciones críticas AUT (Aplicación bajo prueba) funcionen como se espera. La idea de este tipo de prueba es identificar problemas graves lo antes posible y rechazar esta compilación (devolver para revisión) en una etapa temprana de la prueba, para no profundizar en pruebas largas y complejas, evitando así el desperdicio. tiempo en software obviamente defectuoso.
• Pruebas sanitarias: Se utiliza cada vez que obtenemos una compilación de software relativamente estable para determinar el rendimiento en detalle. En otras palabras, se trata de validar que partes importantes de la funcionalidad del sistema funcionen según se requiere a un nivel bajo.

Ambos tipos de pruebas tienen como objetivo evitar la pérdida de tiempo y esfuerzo para determinar rápidamente las deficiencias del software y su criticidad, así como si merece o no pasar a una fase de prueba más profunda y exhaustiva.

• Volver a probar: se lleva a cabo si la característica/funcionalidad ya tenía defectos y estos defectos se solucionaron recientemente
• Pruebas de regresión: en realidad, qué requiere la mayor parte del tiempo y por qué existe la automatización de pruebas. Las pruebas de regresión de AUT se llevan a cabo cuando es necesario asegurarse de que las funciones nuevas (agregadas) de la aplicación/defectos solucionados no afecten la funcionalidad actual, ya existente, que funcionó (y probó) anteriormente.

Para una mejor comprensión, a continuación se presenta un cuadro comparativo de estos conceptos y áreas de aplicación:

Fumar	Cordura	Regresión	Volver a probar
Realizado para verificar que las partes funcionales críticas del AUT estén funcionando como se esperaba.	Dirigido a establecer que ciertas partes de AUT aún funcionan como se esperaba después de cambios menores o correcciones de errores.	Confirma que los cambios recientes en el código o la aplicación en su conjunto no tienen un impacto negativo en la funcionalidad/conjunto de características existente.	Vuelve a verificar y confirma el hecho de que los casos de prueba previamente fallidos pasan después de que se solucionan los defectos.
El objetivo es comprobar la “estabilidad” del sistema en su conjunto para dar luz verde a pruebas más exhaustivas.	El objetivo es comprobar el estado general del sistema en detalle para poder proceder con pruebas más exhaustivas.	El objetivo es garantizar que los nuevos cambios en el código no tengan efectos secundarios en la funcionalidad de trabajo establecida.	La nueva prueba verifica que el defecto esté solucionado.
Verificar los defectos no es el objetivo de Smoke	La nueva verificación de defectos no es el objetivo de Sanity	Volver a comprobar los defectos no es el propósito de la regresión	El hecho de que el defecto se haya solucionado se confirma mediante Re-Test
Pruebas de humo realizadas antes regresión	Se realizan pruebas sanitarias. antes regresión y después pruebas de humo	Realizada en función de los requisitos del proyecto y la disponibilidad de recursos (cerrada con pruebas automáticas), la "regresión" se puede llevar a cabo en paralelo con nuevas pruebas.	- Se realiza una nueva prueba antes de la prueba de cordura. - Además, la prioridad de la nueva prueba es mayor que la de las comprobaciones de regresión, por lo que debe realizarse antes que ellas.
Se puede hacer de forma automática o manual.	La mayoría de las veces se hace manualmente	La mejor razón para automatizar este tipo de pruebas es porque... manual puede consumir muchísimos recursos o mucho tiempo	No se puede automatizar
Es un subconjunto de las pruebas de regresión.	Subconjunto de pruebas de aceptación	Realizado para cualquier modificación o cambio en un proyecto existente.	Se lleva a cabo una nueva prueba en un ensamblaje corregido utilizando los mismos datos, en el mismo entorno, pero con un conjunto diferente de datos de entrada.
Los casos de prueba son parte de los casos de prueba de regresión, pero cubren una funcionalidad extremadamente crítica.	El saneamiento se puede realizar sin casos de prueba, pero se requiere conocimiento del sistema que se está probando.	Los casos de prueba de pruebas de regresión se pueden obtener a partir de requisitos o especificaciones funcionales, manuales de usuario y se llevan a cabo independientemente de lo que los desarrolladores hayan solucionado.	Se utiliza el mismo caso de prueba que identificó el defecto.

¿Pero esencialmente?

Daré un ejemplo de la distinción entre conceptos en mi proyecto actual.

Ejemplo: Tenemos un servicio web con una interfaz de usuario y una API RESTful. Como evaluadores, sabemos:

• Que tenga 10 puntos de entrada, por simplicidad, en nuestro caso ubicados en la misma IP
• Sabemos que todos aceptan una solicitud GET de entrada y devuelven algunos datos en formato json.

Luego se pueden hacer una serie de afirmaciones sobre qué tipos de pruebas deberían utilizarse y en qué momento:

• Al ejecutar una solicitud GET simple a uno de estos puntos de entrada y recibir una respuesta en formato json, ya estamos convencidos de que la prueba de humo ha pasado.
  Si uno de estos puntos de entrada también devuelve datos de la base de datos, mientras que el primero no, deberá ejecutar adicionalmente otra consulta para asegurarse de que la aplicación
  procesa correctamente las solicitudes a la base de datos. Y esto completa la prueba del “humo”.

  Es decir, completamos la solicitud: llegó una respuesta del servicio y no "fumó", es decir, no devolvió el error 4xx o 5xx, y algo vago, en lugar de json. Llegados a este punto podemos decir que se ha pasado la prueba del “humo”. Para comprobar que la interfaz de usuario funciona de la misma manera, sólo necesita abrir la página una vez en el navegador.

• Las pruebas sanitarias en este caso consistirán en ejecutar una solicitud a los 10 puntos de entrada a la API, verificando el json recibido con el esperado, así como la presencia de los datos requeridos en el mismo.
• Las pruebas de regresión consistirán en humo + cordura + UI ejecutándose juntas en el mismo montón. Objetivo: verificar que al agregar el undécimo punto de entrada no se haya roto, por ejemplo, la recuperación de contraseña.
• La nueva prueba en este ejemplo es una verificación punto por punto de que, por ejemplo, un punto de entrada de API roto en la siguiente compilación funciona según lo previsto.

Además, si esta API también acepta solicitudes de publicación, entonces es obvio que estas solicitudes deben incluirse en otro conjunto de pruebas de cordura. Por analogía con la interfaz de usuario, comprobaremos todas las páginas de la aplicación.

resumámoslo

Espero que después de leer este artículo, tenga claridad para determinar qué tipo de prueba utiliza en cada etapa y cuál es la diferencia entre estos tipos de pruebas. Como se mencionó al principio, la frontera entre estos conceptos es muy arbitraria y queda a su discreción en el marco del proyecto.

UPD:
A menudo, las "pruebas de coherencia" o las "pruebas de cordura" se denominan "pruebas sanitarias". Creo que esto se debió a las propiedades fonéticas de la palabra inglesa cordura, que suena similar a algo “sanitario”. Google Translate aporta claridad. Ambas opciones están disponibles en Internet. Con respecto a este artículo, considere las pruebas "sanitarias" como "pruebas de coherencia".

Gracias por el consejo

Después de realizar los cambios necesarios, como corregir un error o defecto, se debe volver a probar el software para confirmar que el problema realmente se ha resuelto. Los siguientes son los tipos de pruebas que se deben realizar después de instalar el software para confirmar la funcionalidad de la aplicación o la corrección de la corrección del defecto:

- Prueba de humo(Prueba de humo)

- Pruebas de regresión(Prueba de regresión)

- Probando la construcción(Prueba de verificación de construcción)

- Pruebas sanitarias o verificación de consistencia/funcionalidad.(Prueba de cordura)

Concepto prueba de humo Proviene del entorno de la ingeniería. Al poner en marcha nuevos equipos (“hardware”), se consideró que la prueba era exitosa si no salía humo de la instalación. En el campo de las pruebas de software, su objetivo es una verificación superficial de todos los módulos de la aplicación para determinar su operatividad y la presencia de defectos críticos y de bloqueo que se encuentran rápidamente. Según los resultados de las pruebas de humo, se llega a una conclusión sobre si la versión instalada del software se acepta o no para pruebas, operación o entrega al cliente. Para facilitar el trabajo y ahorrar tiempo y mano de obra, se recomienda implementar la automatización del script de prueba para las pruebas de humo.

Pruebas de regresión es un tipo de prueba destinada a verificar los cambios realizados en una aplicación o entorno (corregir 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 según lo previsto y antes. (ver también Pruebas sanitarias o pruebas de consistencia/funcionalidad). Las regresiones pueden ser como funcional, así y no funcional pruebas.

Como regla general, para las pruebas de regresión se utilizan casos de prueba escritos en las primeras etapas de desarrollo y prueba. Esto garantiza que los cambios en la nueva versión de la aplicación no dañen la 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 propio término "prueba de regresión", según el contexto de uso, puede tener diferentes significados. Sam Kaner, por ejemplo, describió 3 tipos principales prueba de regresión:

- Regresión de errores– un intento de demostrar que el error corregido en realidad no se corrige.

- Regresión de errores antiguos– un intento de demostrar que un cambio reciente en el código o los datos rompió la corrección de errores antiguos, es decir viejos errores comenzaron a aparecer nuevamente.

- Regresión de efectos secundarios– un intento de demostrar que un cambio reciente en el código o los datos rompió otras partes de la aplicación que se estaba desarrollando.

Pruebas de cordura – Se trata de pruebas altamente enfocadas que son suficientes para demostrar que una característica particular funciona según lo especificado en la especificación. Es un subconjunto de las pruebas de regresión. Se utiliza para determinar el rendimiento de una determinada parte de la aplicación después de cambios realizados en ella o en el entorno. Generalmente se hace manualmente.

La diferencia entre pruebas sanitarias y pruebas de humo. Algunas fuentes creen erróneamente que las pruebas sanitarias y de humo son lo mismo. Creemos que este tipo de pruebas tienen “vectores de movimiento”, direcciones en diferentes direcciones. A diferencia de las pruebas de humo, las pruebas de cordura están dirigidas en profundidad a la función que se está probando, mientras que las pruebas de humo están dirigidas de manera amplia, para cubrir la mayor cantidad de funcionalidad posible con pruebas en el menor tiempo posible.

Probando la construcción La prueba de verificación de compilación es una prueba destinada a determinar el cumplimiento de la versión publicada con los criterios de calidad para comenzar la prueba. En cuanto a sus objetivos, es análogo a Smoke Testing, cuyo objetivo es aceptar una nueva versión para realizar más pruebas u operar. Puede penetrar más profundamente, dependiendo de los requisitos de calidad de la versión lanzada.

Pruebas de instalación – destinado a verificar la instalación y configuración exitosa, así como a actualizar o desinstalar el software. Actualmente, la forma más común de instalar software es mediante instaladores(programas especiales que también requieren pruebas adecuadas). En condiciones reales, es posible que no haya instaladores. En este caso, tendrá que instalar el software usted mismo, utilizando documentación en forma de instrucciones o archivos Léame que describen paso a paso todas las acciones y comprobaciones necesarias. En 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 hacer esto, a menudo se escribe un plan de instalación (Plan de implementación), que incluye no solo los pasos para instalar la aplicación, sino también los pasos para volver a la versión anterior en caso de falla. El propio plano de instalación también debe someterse a 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 inactividad significa una pérdida de reputación y una gran cantidad de fondos, por ejemplo: bancos, compañías financieras o incluso redes de banner. Por lo tanto, las pruebas de instalación pueden considerarse una de las tareas más importantes para garantizar la calidad del software.

Es este enfoque integral con planes de redacción, pruebas de instalación paso a paso y reversión de la instalación lo que con razón puede denominarse prueba de instalación o prueba de instalación.

Los errores simples pueden ser fatales para su sitio, especialmente si es una empresa SaaS (ing. Software as a Service) como nosotros. Si un usuario llega a su sitio y no puede completar una tarea simple como registrarse o restablecer su contraseña olvidada, corre el riesgo de perder ese usuario para siempre.

Experimentamos esto de la manera más difícil. Por supuesto, tener su propia gente en el equipo que pruebe la aplicación y busque errores es importante, pero no siempre es apropiado o lo suficientemente completo. En este artículo queremos introduciros a vosotros, humanistas, en el mundo de las pruebas de humo.

Si aún tienes preguntas, puedes completar los espacios visitando

La prueba de humo se inventó originalmente para explicar cómo los ingenieros eléctricos comprobaban si su aparato funcionaba encendiéndolo y si salía humo...

Espera, ¿cómo se aplica esto a las aplicaciones?

Los directores y cofundadores de humanidades generalmente desconocen la importancia (y la rentabilidad) de las pruebas de humo. Las pruebas de humo sistemáticas pueden considerarse una parte integral para prevenir el aumento de la probabilidad de piratería. Minimizan la posibilidad de que su aplicación web o telefónica falle y, como todos sabemos, basta con un fallo y puede perder un cliente para siempre.

Esta es una guía introductoria a 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 principal y deben ser una parte integral de su proceso de prueba. Podrían incluir algo tan simple como "¿Puedo registrarme?"

Las pruebas de humo ayudan a garantizar que ninguno de los fallos más importantes y obvios quede al azar. No deberías hacer una prueba más profunda hasta que hayas terminado al 100% con las pruebas de humo porque eliminan errores fundamentales del software.

Paso 1: decidir qué probar

Defina lo que su aplicación pretende lograr. ¿Cuáles son los pequeños pasos más obvios que se necesitan para llegar allí? ¿Cuáles son los requisitos mínimos vitales 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 ni preguntas de "¿y si?". Solo asume respuestas de sí o 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 debo:

1. registro.
2. crear un nombre de usuario.
3. sube una foto a tu avatar.
4. escribir mensajes.
5. responder a los mensajes.

Paso 2: Registre los resultados en una tabla.

La imagen de arriba es un ejemplo de nuestro equipo. Puedes encontrar la plantilla. Esto es necesario para mantener un registro de lo que nos funciona y lo que no: una organización básica nos ahorrará mucho tiempo en el futuro. Dividimos nuestros resultados en aprobados, parciales y fallidos.

• Aprobado: todo funciona perfectamente.
• Parcialmente: Es posible que inicialmente no te des cuenta de que algunas actividades pueden subdividirse aún más, de modo que una parte funciona y otra no.
• Fallido: no funciona.

Describimos los pasos exactos que queríamos reproducir y luego, en la siguiente columna, agregamos una breve descripción de lo que esperábamos generar. Ejemplo:

Paso 3: Automatizar las pruebas de humo

Es muy importante no tomar como axioma que si cualquier acción se ha realizado una vez, siempre tendrá un resultado positivo. Las pruebas de humo le permiten comprobar continuamente que las funciones principales no se han dañado con el tiempo ni se han interrumpido durante un período prolongado.

No dejes de realizar pruebas de humo. Nunca.

Cuando su conjunto de casos de prueba para pruebas de humo se complete con un resultado exitoso en 100%, piensa en automatizarlos. La frecuencia recomendada para realizar pruebas de humo es todos los días si su empresa las desarrolla todos los días.

El requisito mínimo es realizar pruebas de humo antes de cada lanzamiento y después de cada parche.

Regla general para una prueba de humo:

• Tiempo mínimo: 30 minutos.
• Tiempo máximo: 60 minutos.

A la larga, 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.