Continuando una serie de res煤menes con HL2018. Los muchachos de Badoo (Vladimir
Yants vyants y Nikolay Krapivny) me ayudaron a revisar este resumen, por lo que les agradezco mucho. Espero que esto tenga un efecto positivo en la calidad del mensaje del informe.
Caracter铆sticas del proceso de desarrollo:
La responsabilidad del desarrollador no termina con el lanzamiento del backend. Es responsable antes de la implementaci贸n en plataformas.
Hay pruebas manuales, pero el cliente no est谩 listo en el momento del lanzamiento y se libera con un retraso (impredecible). A menudo no sabemos cu谩ndo los clientes comenzar谩n a implementarlo. Algunas veces (no con frecuencia) las caracter铆sticas comienzan a hacerse despu茅s de un largo tiempo. Por lo tanto, probar con las manos es dif铆cil y no todo es posible. Por lo tanto, se necesitan pruebas autom谩ticas.
Pruebas
Pruebas unitarias
Escrito en phpunit.
Prueba una peque帽a unidad. No van a la base de datos ni a los servicios (no deben interactuar con nada).
Legacy todav铆a tiene y complica el proceso de prueba.
Desarrollaron la biblioteca softMocks: engancha todo incluir / requerir y lo reemplaza con el modificado.
Puede liquidar cualquier m茅todo: est谩tico, privado, final.
La biblioteca est谩 disponible en c贸digo abierto.
Problema: las softmocks se relajan y le permiten escribir c贸digo no probado (y cubrirlo con pruebas).
Acept贸 las reglas:
- El nuevo c贸digo deber铆a ser f谩cil de probar phpunit
- SoftMocks - caso extremo (c贸digo antiguo / largo / costoso / complicado)
Observamos la revisi贸n del c贸digo para estas reglas.
Prueba de calidad
Prueba de mutaci贸n
- Toma el c贸digo
- Tomar cobertura de c贸digo
- Analizamos el c贸digo y aplicamos mutaciones (cambio + => -; verdadero => falso, etc.)
- Para cada mutaci贸n, ejecutamos un conjunto (conjunto) de pruebas.
- Si las pruebas fallan, entonces aprox. Si no, no son lo suficientemente efectivos. Entendemos, cambiar / agregar pruebas.
Existen soluciones listas para usar (Humbug, Infecci贸n), pero no encajan (no son compatibles con las softmocks, existen dificultades con la cobertura del c贸digo). Por lo tanto, escribieron los suyos.
La prueba de mutaci贸n a煤n no est谩 disponible para la prueba manual. Disponible para ejecutarse manualmente, desde la consola. Ahora lo estamos implementando en la tuber铆a de CI, estamos construyendo el proceso. El resultado estar谩 en Habr.
Pruebas de integraci贸n
Probar el funcionamiento de varios componentes en conjunto; Verificamos el trabajo con la base y / o servicios.
Enfoque est谩ndar para pruebas de bases de datos (DBUnit):
- Levantar la base de datos de prueba
- Llenarlo
- Ejecute la prueba
- Limpiamos la base de datos
Los problemas:
- Es necesario admitir tablas de datos y conjuntos de datos (relevancia de los contenidos de la base de datos)
- Lleva tiempo preparar la base de datos
- Los lanzamientos paralelos hacen que las pruebas sean inestables y provoquen puntos muertos
Soluci贸n: biblioteca DBMocks (soluci贸n propia)
Principio de funcionamiento:
- M茅todos de controlador de base de datos interceptados utilizando SoftMocks en la prueba de configuraci贸n
- De la solicitud parsim db + table
- Tmpfs crea tablas temporales con el mismo esquema
- Todas las consultas van solo a tablas temporales
- En TearDown, se eliminan.
La biblioteca es peque帽a, pero a煤n no est谩 abierta en c贸digo abierto.
Resultados:
- Las pruebas no pueden da帽ar los datos en las tablas originales
- Las pruebas est谩n aisladas unas de otras (se pueden ejecutar en paralelo)
- Prueba de compatibilidad de consultas con la versi贸n MySQL
Pruebas de API
- Imita una sesi贸n de cliente
- Capaz de enviar solicitudes de backend
- El backend responde casi como un cliente real
T铆picamente, tales pruebas requieren un usuario autorizado. Debe crearse antes de la prueba y eliminarse despu茅s. Esto introduce riesgos adicionales (replicaci贸n, tareas en segundo plano).
Soluci贸n: Creamos un grupo de usuarios de prueba. Aprend铆 a limpiarlos.
Los usuarios de prueba est谩n en el mismo entorno que los reales, porque devel! = Prod. Es necesario aislar a los usuarios de prueba y en vivo.
Para el aislamiento, se agreg贸 el indicador is_test_user para el usuario. Y estos usuarios tambi茅n est谩n excluidos del an谩lisis y los resultados de las pruebas a / b.
Puede hacerse m谩s barato enviando usuarios de prueba "a la Ant谩rtida", donde nadie los ver谩 (excepto los ping眉inos).
API de control de calidad
Una herramienta para preparar el entorno en pruebas de API, de hecho, una puerta trasera en el servidor para cambiar r谩pidamente la configuraci贸n del usuario / entorno.
- M茅todos de API bien documentados
- Administre datos de forma r谩pida y sencilla.
- Los desarrolladores escriben backend
- Solo se puede aplicar a usuarios de prueba.
Permite al usuario cambiar datos inmutables (por ejemplo, fecha de registro).
Protecci贸n requerida:
- A nivel de red (disponible solo desde la red de la oficina)
- Se pasa un secreto con cada solicitud, cuya validez se verifica
- Los m茅todos solo funcionan con usuarios de prueba.
Hay un programa BugsBounty en HackerOne. Pagan por las vulnerabilidades encontradas. Uno no puede encontrarlo con la API de control de calidad.
Simulacros remotos
Moki para el backend remoto.
Trabaja sobre la base de simulacros suaves. La prueba le pide al backend que se inicialice para la sesi贸n simulada. Al recibir la solicitud, el backend verifica la lista de mox para la sesi贸n y los aplica usando SoftMocks.
Ejemplo de prueba:
Las pruebas de API son demasiado convenientes. Es tentador escribirlos en lugar de Unit. Pero las pruebas de API son mucho m谩s lentas.
Adopt贸 un conjunto de reglas:
- El prop贸sito de las pruebas API es probar el protocolo y la integraci贸n.
- Comprobaci贸n v谩lida de flujo complejo
- La variabilidad peque帽a no se puede probar.
- En la revisi贸n de c贸digo, tambi茅n probamos las pruebas.
Pruebas de Ui
El comando backend no escribe.
La caracter铆stica est谩 cubierta por las pruebas de Ui cuando se estabiliza.
Usado por selenium para la web. Para calabaza m贸vil.
Prueba de funcionamiento
100.000 pruebas unitarias. 6,000 integraci贸n, 14,000 pruebas de API.
En 1 flujo, el tiempo es de 40 min / 90 min / 10 horas.
Made TestCloud: una nube para ejecutar pruebas.
La distribuci贸n de la prueba entre hilos:
- Puede igualmente (mal, todas las pruebas son diferentes, resulta desigual en partes de tiempo)
- Ejecute m煤ltiples subprocesos y alimente las pruebas de phpunit de una en una (sobrecarga de inicializaci贸n. 隆Largo!)
Soluci贸n:
- Recopilaci贸n de estad铆sticas sobre el tiempo de ejecuci贸n.
- Dise帽o de pruebas para que el fragmento no se ejecute m谩s de 30 segundos
El problema con las pruebas de API es mucho tiempo, muchos recursos y no permiten que otros se ejecuten.
Para resolverlo, dividimos la nube en 2 partes:
- Ejecuta solo pruebas r谩pidas.
- Ejecuta ambos tipos de pruebas.
El resultado es una aceleraci贸n del tiempo para:
- Unidad - 1 min
- Integraci贸n - 5 min
- API - 15 minutos.
Ejecuci贸n de cobertura de c贸digo
驴Qu茅 pruebas realizar? Mostrar谩 la cobertura del c贸digo.
- Obtenemos rama diff
- Crea una lista de archivos modificados
- Obtenga una lista de pruebas para estos archivos.
- ejecutamos la suite solo desde estas pruebas.
La cobertura se forma una vez al d铆a, por la noche, para la rama maestra. Los resultados (diff) se agregan a la base de datos.
Pros:
- Realizamos menos pruebas: menos carga de hardware y comentarios de prueba m谩s r谩pidos
- Puede ejecutar pruebas para parches. Esto le permite implementar r谩pidamente la revisi贸n. En parches, la velocidad es lo m谩s importante.
Contras:
- Lanzamiento de backend 2 veces al d铆a. Despu茅s del almuerzo, la cobertura es menos relevante (pero al desplegar un ritmo, siempre manejamos una suite completa).
- Las pruebas de api generan una amplia cobertura. Para ellos, este enfoque no proporciona muchos ahorros.
Si el desarrollador necesita ver de inmediato la cobertura del c贸digo, es decir, una herramienta que se puede iniciar en la consola e inmediatamente obtener una nueva m茅trica para la cobertura de un archivo / componente en particular.
Se considera complicado: se toman los datos del maestro de cobertura, se agregan todas las pruebas modificadas, resulta un peque帽o conjunto en el que ya se considera la cobertura.
Resumen
- Necesita todos los niveles de prueba
- Cantidad! = Calidad. Hacer revisi贸n de c贸digo y pruebas de mutaci贸n
- A铆sle a los usuarios de prueba de los reales.
- Los backends en el backend simplifican y aceleran las pruebas de escritura
- Recopilar estad铆sticas sobre las pruebas.
Referencias