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 también 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 no se han solucionado errores críticos.

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.

  • 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 utilizado en plomería, reparación de instrumentos de viento, electrónica, desarrollo de software y la 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

    Fumar- 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

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. En un proyecto de equipo de desarrollo típico, 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 cambia 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 han descrito la compilación diaria como el pulso del reloj 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 sistema estable, excluyendo la posibilidad del correcto funcionamiento del programa de aplicación, errores de bloqueo;
  • 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 proyectos grandes puede haber más empleados de este tipo y dicho 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. En situaciones estresantes, los desarrolladores suelen cometer 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 todos los sistemas complejos de los últimos tiempos han sido sometidos a montajes diarios y pruebas de 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.

¡Hola, Habr! Un día en nuestro seminario interno, mi supervisor, el jefe del departamento de pruebas, comenzó su discurso con las palabras “las pruebas no son necesarias”. Todos en el salón se quedaron en silencio, algunos incluso intentaron caerse 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ánto más seguro se sentirá sabiendo 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. Así que sabemos de primera mano que las pruebas complejas y lentas son un obstáculo para el desarrollo. La prueba rápida es 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 armar la estufa, cerraron todos los enchufes, la inundaron y observaron que el humo saliera solo de los lugares correctos. 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 innecesariamente redundante.

Veamos un ejemplo sencillo. La preproducción de nuestra aplicación se encuentra en bryak.com (cualquier parecido con los sitios reales es pura coincidencia). Hemos preparado y subido una nueva versión para probar. ¿Qué se debe revisar primero? Comenzaría asegurándome de que la aplicación aún esté abierta. Si el servidor web nos responde con "200", entonces todo está bien y puede comenzar a probar la funcionalidad.

¿Cómo automatizar esta verificación? En principio, puede escribir una prueba funcional que abrirá el navegador, abrirá la página deseada y se asegurará de que se muestre como debería. Sin embargo, esta solución tiene una serie de desventajas. Primero, es largo: el proceso de iniciar el navegador llevará más tiempo que la verificación en sí. En segundo lugar, requiere el mantenimiento de infraestructura adicional: en aras de tal prueba sencilla necesitamos un lugar para mantener el servidor con navegadores. Conclusión: necesitamos resolver el problema de otra manera.

Nuestra primera prueba de humo

En Badoo, el back-end está escrito principalmente en PHP. Las pruebas unitarias, por razones obvias, están escritas en él. En total, ya tenemos PHPUnit. Para no producir tecnologías innecesariamente, decidimos escribir pruebas de humo también en PHP. Además de PHPUnit, necesitamos una biblioteca de cliente de URL (libcurl) y una extensión de PHP para trabajar con ella: cURL.

De hecho, las pruebas simplemente hacen las solicitudes que necesitamos al servidor y verifican las respuestas. Todo está vinculado al método getCurlResponse() y varios tipos de aserciones.

El método en sí se ve así:

Función pública getCurlResponse($url, array $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); ) if ($seguir_ubicación) ( curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1); ) if (isset($params['proxy']) && $params['proxy']) ( curl_setopt($c h, CURLOPT_PROXY, $parámetros['proxy']); ) if (isset($params['user_agent']) && $params['user_agent']) ( $user_agent = $params['user_agent']; ) else ($user_agent = USER_AGENT_DEFAULT; ) curl_setopt($ch, CURLOPT_USERAGENT, $usuario_agente); curl_setopt($ch, CURLOPT_AUTOREFERER, 1); $respuesta = curl_exec($ch); $this->logActionToDB($url, $user_agent, $params); if ($follow_location) ($this->assertTrue((bool)$response, "Se recibió una respuesta vacía. Error de curl: " . curl_error($ch) . ", errno: " . curl_errno($ch)); $this ->assertServerResponseCode($respuesta, $respuesta_esperada); ) curl_close($ch); devolver $respuesta; )
El método en sí puede devolver una respuesta del servidor en una URL determinada. Acepta parámetros como entrada, como cookies, encabezados, agente de usuario y otros datos necesarios para generar una solicitud. Cuando se recibe una respuesta del servidor, el método verifica que el código de respuesta coincida con el esperado. Si no es así, la prueba falla con un error que indica esto. Esto se hace para que sea más fácil determinar la causa de la caída. Si la prueba falla en alguna aserción, diciéndonos que no hay ningún elemento en la página, el error será menos informativo que el mensaje de que el código de respuesta es, por ejemplo, "404" en lugar del esperado "200".

Cuando se envía la solicitud y se recibe la respuesta, registramos la solicitud para que luego, si es necesario, sea fácil reproducir la cadena de eventos si la prueba se cae 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'; $response = $this->getCurlResponse($url); $this->assertHTMLPresent("
Esta prueba toma menos de un segundo. Durante este tiempo, hemos verificado 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 y hardware especiales para funcionar;
  • son fáciles de escribir y mantener;
  • son estables.
Respecto al último punto. Quiero decir, 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 todas las páginas no autorizadas que encontramos con pruebas. Nos sentamos un rato, nos regocijamos, pero luego nos dimos cuenta de que todas las cosas más importantes de nuestro proyecto están detrás de la autorización. ¿Cómo podría probar esto también?

La opción más sencilla es una cookie de autorización. Si lo agregamos a la solicitud, entonces el servidor nos “reconoce”. Dicha cookie se puede codificar en la 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 es necesario ingresar el nombre de usuario y la contraseña del usuario.

Abra esta página en cualquier navegador y abra el inspector. Ingresamos los datos del usuario y enviamos el formulario.

Apareció una solicitud en el inspector, que necesitamos 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, los datos de las cookies recibidas anteriormente, un agente de usuario, etc. Cada uno de estos parámetros deberá obtenerse previamente en la prueba antes de generar una solicitud de autorización.

En las herramientas de desarrollo de cualquier navegador, puede copiar la solicitud seleccionando copiar como cURL. De esta forma, el comando puede insertarse en la consola y verse allí. En el mismo lugar se puede probar cambiando o añadiendo parámetros.

En respuesta a dicha solicitud, el servidor nos devolverá las cookies, que agregaremos a otras solicitudes 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 por usuario y almacenarla en algún lugar. Por ejemplo, almacenamos tales cookies en una matriz. La clave es el inicio de sesión del usuario y el valor es información sobre ellos. Si aún no hay una clave para el próximo usuario, inicie sesión. Si la hay, hacemos la solicitud que nos interese inmediatamente.

Función pública testAuthPage() ( $url = 'bryak.com'; $cookies = $this->getAuthCookies(' [correo electrónico protegido]', '12345'); $respuesta = $esto->getCurlResponse($url, ['cookies' => $cookies]); $esto->afirmarHTMLPresent(" ", $respuesta, "Error: la prueba no puede encontrar el elemento del cuerpo en la página".); )
Como podemos ver, se ha agregado un método que recibe una cookie de autorización y simplemente la agrega a una solicitud posterior. El método en sí se implementa de manera bastante simple:

Función pública getAuthCookies($email, $password) ( // comprobar si la cookie ya se ha obtenido If (array_key_exist($email, self::$known_cookies)) ( return self::$known_cookies[$email]; ) $url = self::DOMAIN_STAGING .'/auth_page_adds'; $post_data = ['email' => $email, 'password' => $password]; $response = $this->getCurlResponse($url, ['post_data' => $ post_data]); $cookies = $this->parseCookiesFromResponse($response); // guarda la cookie para su uso posterior self::$known_cookies[$email] = $cookies; return $cookies; )
El método primero verifica si el correo electrónico proporcionado (en su caso, puede ser un inicio de sesión o algo más) tiene una cookie de autorización que ya se recibió anteriormente. Si lo hay, lo devuelve. Si no, hace una solicitud a una página de autorización (por ejemplo, bryak.com/auth_page_adds) con los parámetros requeridos: correo electrónico y contraseña del usuario. En respuesta a esta solicitud, el servidor envía encabezados, entre los que hay cookies de nuestro interés. Se ve algo como esto:

HTTP/1.1 200 OK Servidor: nginx Tipo de contenido: texto/html; charset = utf-8 Codificación de transferencia: conexión fragmentada: cookie de conjunto permanente: nombre = valor; expira = miércoles, 30 de noviembre de 2016 10:06:24 GMT; Max-Edad=-86400; camino=/; 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, esto 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: " . $response);
Una vez que se reciben las cookies, podemos agregarlas de manera segura a cualquier solicitud para que sea autorizada.

Análisis de ensayos de caída

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, y así sucesivamente. El pensamiento se cuela en mi cabeza: si tal prueba falla en la décima solicitud, puede ser difícil averiguar el motivo de su falla. ¿Cómo simplificar tu vida?

En primer lugar, me gustaría aconsejarle que atomice las pruebas tanto como sea posible. No debe verificar 50 casos diferentes en una prueba. Cuanto más simple 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 carga en el repositorio de artefactos, donde este archivo se puede abrir desde el navegador especificando el nombre de la prueba.

Por ejemplo, nuestra prueba falló porque no puede encontrar una parte de HTML en la página:

Enlace
Vamos a nuestro colector y abrimos la página correspondiente:

Puede trabajar con esta página de la misma manera que con cualquier otra página HTML en el navegador. Puede utilizar el localizador de 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 alguna parte de la prueba; debemos mirar cuidadosamente en esta dirección.

El registro también hace la vida más fácil. Intentamos registrar todas las solicitudes que realizó la prueba fallida para que puedan repetirse fácilmente. En primer lugar, esto le permite realizar rápidamente un conjunto de acciones similares para reproducir el error con las manos y, en segundo lugar, identificar pruebas de caídas frecuentes, si las tenemos.

Además de ayudar con el análisis de errores, los registros descritos anteriormente nos ayudan a crear una lista de páginas autorizadas y no autorizadas que hemos probado. Mirándolo, es fácil encontrar y eliminar huecos.

Por último, pero no menos importante, puedo aconsejar que las pruebas sean lo más convenientes 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 cuidadosamente será estudiado. Cuanto más simple sea la arquitectura, más pruebas se escribirán y menos tiempo llevará escribir una nueva.

Si te parece que es inconveniente usar pruebas, lo más probable es que no te parezca. Esto debe ser tratado lo antes posible. De lo contrario, corre el riesgo de comenzar a prestar menos atención a estas pruebas en algún momento, y esto ya puede conducir a saltar el error a producción.

En palabras, la idea parece obvia, estoy de acuerdo. Pero, de hecho, todos tenemos mucho por lo que luchar. Así que simplifica y optimiza tus creaciones y vive sin errores. :)

Resultados

Sobre el este momento*abrimos Teamcity* guau, ya son 605 pruebas. Todas las pruebas, si no se ejecutan en paralelo, se ejecutan 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 de métodos de pago correspondiente;
  • las principales solicitudes a la API funcionan correctamente;
  • la página de destino para los redireccionamientos funciona correctamente (incluso a un sitio móvil con el agente de usuario apropiado);
  • todos los proyectos internos se muestran correctamente.
Las pruebas de Selenium WebDriver para todo esto requerirían muchas veces más tiempo y recursos. Agregar etiquetas

Después de realizar los cambios necesarios, como corregir un error/defecto, el software debe volver a probarse para confirmar que el problema se ha solucionado. A continuación se enumeran los tipos de pruebas que se deben realizar después de la instalación software, para confirmar que la aplicación está funcionando o que el defecto ha sido corregido:

- 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 (ver también Pruebas sanitarias o controles de salud/consistencia). La regresión puede ser funcional, asi que no funcional pruebas

Como regla general, los casos de prueba escritos en las primeras etapas de desarrollo y prueba se utilizan para las pruebas de regresión. Esto asegura que los cambios en la nueva versión de la aplicación no rompan 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 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 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 este tipo de pruebas tienen "vectores de movimiento", direcciones en diferentes direcciones. 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. A este momento La forma más común de instalar software es a través de 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 esto, a menudo se escribe un Plan de implementación, que incluye no solo los pasos para instalar la aplicación, sino también los pasos de reversión (roll-back) para versión previa, en caso de fallo. 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.

Es este enfoque integrado con la redacción de planes, la verificación de la instalación paso a paso y la reversión de la instalación lo que puede llamarse correctamente prueba de instalación o prueba de instalación.