Prefacio
A medida que el dividendo de Internet desaparece gradualmente, a las empresas de Internet les resulta cada vez más difícil y costoso adquirir nuevos clientes. Los operadores responsables del crecimiento de usuarios deben probar constantemente diferentes estrategias de adquisición nuevas y adaptarse rápidamente en función de los comentarios de los usuarios y los datos, y al mismo tiempo Al mismo tiempo, podrá seguir rápidamente los puntos calientes del mercado e iterar rápidamente las características del producto. Nuestro departamento realiza un gran número de negocios financieros (lingotes de oro, pagos, pequeña tesorería, fondos, etc.) para captar nuevos clientes. Para satisfacer las necesidades comerciales de entrega rápida sin sacrificar la calidad del producto, hemos formulado un sistema de control de acceso a la calidad para el crecimiento de usuarios. A través de actividades de calidad estandarizadas, el acceso y el acceso de calidad se llevan a cabo en cada etapa de la entrega de la demanda, paso a paso, para satisfacer las necesidades del producto en crecimiento del usuario Garantía de calidad de entrega "siete puertas".
El primer nivel de la puerta: casos de uso por adelantado: prepárese para un día lluvioso y elimine los defectos en la etapa de brotación
TDD (Desarrollo basado en pruebas) es una práctica importante de pruebas ágiles que enfatiza escribir código de prueba antes de escribir código para impulsar la mejora de la calidad del código y la cobertura funcional. Combinado con el estado actual de control de calidad en el departamento de I+D de la plataforma, la mayoría de los casos de prueba están en forma de descripciones de texto escritas en Por lo tanto, en la primera etapa, priorizamos la implementación de casos de prueba, es decir, la redacción y revisión. de los casos de prueba están precedidos por una revisión del diseño o desarrollo de código, y los requisitos funcionales, requisitos de desempeño, procesos de excepción, requisitos de datos y estándares de aceptación, y compensan los puntos funcionales y las deficiencias del proceso que pueden pasarse por alto en el proceso de revisión de requisitos, previenen defectos por adelantado y reducir los costos de retrabajo y reparación en la etapa de prueba posterior. A través de proyectos piloto de múltiples proyectos en los campos de crecimiento de usuarios, microelectrónica, etc., todas las partes han brindado comentarios positivos y el alcance del piloto actualmente se está ampliando, con el objetivo de cumplir con el 80% de los requisitos antes de su uso . casos.
Puerta doble: prueba unitaria: divide y vencerás para garantizar la corrección de cada unidad funcional mínima
La prueba unitaria es una prueba independiente de la unidad comprobable más pequeña del software (es decir, funciones, métodos, clases, etc.) en el código. Su objetivo principal es verificar que cada unidad funcione correctamente como se espera. Las pruebas unitarias tienen varios beneficios:
- Mejorar la calidad del código: al escribir pruebas unitarias, los desarrolladores pueden verificar que cada unidad se comporta como se espera, lo que puede ayudar a descubrir posibles errores, casos extremos y comportamientos anómalos.
- Garantice la independencia entre módulos: las pruebas unitarias requieren que cada unidad se pruebe de forma independiente, lo que ayuda a crear un código más flexible, escalable y mantenible.
- Admite refactorización y reutilización de código: puede ayudar a los desarrolladores a verificar si el código refactorizado aún puede funcionar correctamente y garantizar que los componentes reutilizados se comporten como se espera en el nuevo entorno.
- Reduzca el tiempo de depuración: las pruebas unitarias pueden identificar rápidamente problemas, limitar el alcance de la depuración y acelerar la resolución de problemas.
- Genere confianza y documentación: al escribir pruebas unitarias integrales, los desarrolladores pueden generar confianza en el comportamiento de su código y, cuando el código cambia, pueden ejecutar pruebas rápidamente para verificar que el código aún funciona correctamente.
En resumen, las pruebas unitarias son un método eficaz de prueba de software, implementado y ejecutado por la codificación de los desarrolladores, que encarna plenamente el concepto de garantía de calidad nacional. En el proyecto de crecimiento de usuarios, I+D se centró más en las pruebas unitarias y escribió una gran cantidad de código de pruebas unitarias mientras codificaba. En particular, el equipo de I+D de crecimiento de usuarios se conectó con ChatGPT y unió fuerzas con otros departamentos del grupo para formar un proyecto conjunto JoyCoder. equipo A través de la optimización iterativa continua, ahora es posible generar rápida y automáticamente un código de prueba unitario más estandarizado, lo que puede reducir en gran medida la carga de trabajo de las pruebas unitarias.
Puerta triple: demostración de humo: verifique estrictamente para garantizar que las funciones básicas sean normales
Las pruebas de humo desempeñan un papel en la detección temprana de problemas y la evaluación preliminar de la calidad de los requisitos que se deben cumplir en el aseguramiento de la calidad del producto. Las pruebas de humo calificadas pueden detectar problemas rápidamente, ayudar al equipo a optimizar los recursos y la asignación de trabajo, y lograr una evaluación preliminar de la calidad del producto, lo que puede promover la mejora de la eficiencia de entrega del equipo. En la práctica del aseguramiento de la calidad del crecimiento de usuarios, generalmente verificamos si el sistema es adecuado para pruebas más profundas en la etapa inicial ejecutando un conjunto de casos de prueba básicos para funciones clave y procesos centrales. Generalmente utilizamos demostraciones de humo. El equipo cree que tiene la capacidad de mejorar. Después de probar las condiciones, invite a los estudiantes de prueba a demostrar y revisar el caso de uso del humo en el sitio. En nuestra práctica, alrededor del 30% del total de casos de uso generalmente están marcados como casos de uso de fumar, que generalmente son puntos de verificación para el proceso principal y las funciones principales. La proporción de casos de uso de fumar puede variar mucho para diferentes requisitos, lo que está relacionado con la dificultad del requisito, la cantidad de procesos principales involucrados, etc. En circunstancias normales, es fácil para I+D y pruebas llegar a un consenso sobre el Contenido y proporción de casos de uso de fumar.
Puerta cuádruple: ejecución de pruebas: observe cada detalle y capture los defectos uno por uno
En el proceso de entrega de productos, proyectos y demandas, la ejecución de pruebas es la cuarta línea de defensa para el aseguramiento de la calidad del producto y uno de los pasos más críticos para garantizar la calidad del software. Mediante una ejecución eficaz de las pruebas, se pueden descubrir los defectos del producto lo antes posible. Los tipos de defectos incluyen, entre otros: problemas funcionales, problemas de experiencia del usuario, problemas de rendimiento, vulnerabilidades de seguridad, especificaciones de puntos enterrados, compatibilidad, control de riesgos y anti- cepillado, etc La fase de ejecución de la prueba es el período de trabajo más largo para los estudiantes de prueba, y también es el contenido del trabajo de prueba con el que otros roles están más familiarizados. Por lo general, los defectos de demanda descubiertos en esta etapa pueden alcanzar más del 95%. En circunstancias normales, la carga de trabajo en la etapa de ejecución de pruebas representa del 30% al 50% del trabajo total de I + D. Por supuesto, la proporción de la carga de trabajo de pruebas puede ser diferente. Para diferentes requisitos, mayor, especialmente la proporción de pruebas de regresión y la proporción de pruebas automatizadas en las pruebas de regresión, afectará directamente la carga de trabajo y la duración de la fase de ejecución de la prueba.
Puerta quíntuple: verificación del producto: seguir mejorando, la función, el rendimiento y la experiencia son indispensables
La verificación del producto es la quinta línea de defensa para garantizar la calidad del software, incluida la UAT, el recorrido de la interfaz de usuario y la aceptación de la experiencia. Antes de que los requisitos estén listos para estar en línea, invitaremos al gerente de producto a verificar las funciones que se entregarán en el entorno de prelanzamiento o de prueba. En este momento, los evaluadores y gerentes de producto participarán en la verificación del sistema del producto. y los estudiantes de prueba demostrarán el proceso principal o el gerente de producto lo hará de forma independiente. Verificará que la funcionalidad, el rendimiento y la experiencia del usuario cumplan con los requisitos y expectativas originales, así como también verificarán la configuración operativa para detectar problemas. Los resultados de la verificación del producto se dividen en dos situaciones: aprobado y reprobado. Para aquellos que aprueben, podemos comenzar a trabajar en el lanzamiento y entrega final. Para aquellos que fallan, proporcionaremos comentarios al equipo de desarrollo lo antes posible para que el problema pueda repararse y optimizarse de manera oportuna. Durante la etapa de aceptación del producto, según el diseño del producto y las perspectivas del usuario, los gerentes de producto pueden presentar varios puntos de vista y opiniones para mejorar aún más el producto. Este tipo de comentarios y opiniones diversificados pueden ayudar al equipo a identificar y resolver problemas potenciales antes de conectarse. Aunque ya se encuentra en la última etapa de entrega de la demanda, dado que el sistema aún no se ha lanzado a los clientes, todavía hay una cierta cantidad de Es hora de solucionar los problemas, para evitarlos en la medida de lo posible. Los problemas se escapan en línea para generar quejas de los clientes.
Además, si existen más requisitos de interacción front-end, es necesario invitar a los diseñadores de UI a realizar recorridos de UI y a colegas de experiencia del usuario a realizar la aceptación de la experiencia después de la verificación del producto. Como aceptación de las operaciones del usuario y la experiencia del usuario antes de conectarse, si la aceptación falla debido a defectos en la experiencia, los colegas de experiencia del usuario tienen derecho a decidir posponer el lanzamiento hasta que se complete la optimización o todas las partes lleguen a un consenso sobre el problemas de experiencia, luego se puede iniciar primero la experiencia del usuario y completar la optimización antes del lanzamiento a gran escala.
Seis puertas: Aceptación operativa-orientada a resultados, examina las funciones a liberar desde la perspectiva dual de usuarios y operaciones.
La aceptación operativa es principalmente para invitar a los estudiantes de operación a realizar la aceptación final en línea después de que los requisitos estén en línea. Los estudiantes de operación se posicionan desde las perspectivas del negocio y del usuario para verificar si las funciones que se entregarán son consistentes con las expectativas originales. La etapa de aceptación de la operación es la última paso antes de que las funciones se lancen a los clientes. La línea de defensa se basa en un conocimiento profundo de los usuarios, una aguda intuición y una investigación profunda sobre funciones similares en el mercado. En esta etapa, los estudiantes de operación a menudo pueden descubrir algunos problemas o defectos que son fácilmente pasados por alto. Al mismo tiempo, lo que es más importante, puede verificar si hay algún problema con la configuración del backend, si el presupuesto es suficiente, determinar la tasa de desvío de funciones nuevas y antiguas, si los defectos están dentro del rango de tolerancia, si es necesario informar al servicio de atención al cliente y determinar la estrategia operativa y el ritmo operativo después del lanzamiento y la posterior planificación de la iteración del producto. En esta etapa, ocasionalmente puede haber desacuerdos entre las opiniones operativas y las opiniones de productos, así como entre las opiniones de I + D y pruebas, por lo que esta etapa también es una etapa importante para la persuasión mutua y la alineación del entendimiento.
Siete puertas: simulacros de recuperación ante desastres: prevenga desastres antes de que ocurran y mantenga la continuidad del negocio en circunstancias extremas
Con la gran popularidad del desarrollo empresarial, la arquitectura de microservicios, la arquitectura distribuida y la tecnología de contenedores virtualizados, la complejidad de la arquitectura de software aumenta constantemente y la incertidumbre causada por la dependencia entre servicios también aumenta exponencialmente.De esta manera, en la red de llamadas de servicio, Los cambios normales o anormales en cualquier enlace pueden tener un impacto similar al efecto mariposa en otros servicios. A medida que los usuarios crecen, las actividades de marketing en línea, las nuevas herramientas y los componentes públicos continúan aumentando, el crecimiento general de los enlaces y el flujo de datos son complejos y la disponibilidad y estabilidad de todo el sistema se ven cada vez más desafiadas, por lo que es muy necesario averiguarlo de manera proactiva. Luego, los enlaces vulnerables en el sistema se refuerzan y previenen de manera específica para evitar consecuencias graves cuando ocurren fallas, mejorar aún más la alta disponibilidad del sistema comercial y mejorar las capacidades de soporte de emergencia del sistema comercial. En los últimos años se han producido varios fallos a gran escala en el país y en el extranjero, lo que ha provocado una interrupción prolongada de los servicios a un gran número de usuarios, lo que ha tenido un enorme impacto negativo. Para reducir efectivamente el impacto de las fallas ambientales internas y externas en el sistema, simulamos varios tipos de fallas en el trabajo diario para probar el impacto en el sistema y las capacidades de respuesta al riesgo del equipo de investigación y desarrollo. contenido en el campo del crecimiento de usuarios.Simulacro de desastre:
- Uno es Ingeniería del Caos a nivel de aplicación.
Los simulacros de caos son un método práctico para probar y mejorar la confiabilidad del sistema mediante la introducción intencional de aleatoriedad, inestabilidad y fallas en el sistema. Está diseñado para ayudar a las organizaciones a identificar y resolver fallas potenciales del sistema y problemas de rendimiento para reducir las fallas del sistema y mejorar la tolerancia a fallas del sistema. El concepto clave de los ejercicios de caos es "encontrar fallas introduciendo fallas". Al introducir factores inestables y escenarios de falla de manera controlada, como cerrar un servicio, simular retrasos en la red, causar fallas de hardware, etc., los simulacros de caos pueden verificar la resiliencia, la tolerancia a fallas y las capacidades de recuperación del sistema. Puede ayudarnos a descubrir debilidades ocultas del sistema, identificar cuellos de botella en el rendimiento y puntos de falla independientes, y brindar oportunidades para mejorar la estabilidad y confiabilidad del sistema.
- El segundo es la alta disponibilidad del almacenamiento de datos y el simulacro de recuperación ante desastres de la red de la sala de computadoras.
Resumir
Este artículo presenta las siete líneas de defensa establecidas para garantizar la calidad de la entrega y al mismo tiempo entregar productos rápidamente en el campo del crecimiento de usuarios. Cada línea de defensa es como un control de acceso. Sólo cuando se cumplan los requisitos de acceso se podrá pasar a la siguiente etapa. se utiliza para estandarizar cada etapa de las actividades de calidad y sirve como estándar de ejecución para todo el proceso de aseguramiento de la calidad. Cabe señalar que en la práctica de calidad real, las actividades de calidad anteriores no se realizan de manera metafísica, simple y cruda. Haremos ajustes flexibles o adaptaciones hasta cierto punto en función de la situación real de los productos y las necesidades comerciales para lograr un equilibrio entre calidad y eficiencia, un equilibrio dinámico y moderado.
Lei Jun: La versión oficial del nuevo sistema operativo de Xiaomi, ThePaper OS, ha sido empaquetada. Una ventana emergente en la página de lotería de la aplicación Gome insulta a su fundador. El gobierno de Estados Unidos restringe la exportación de la GPU NVIDIA H800 a China. La interfaz de Xiaomi ThePaper OS está expuesto. Un maestro usó Scratch para frotar el simulador RISC-V y se ejecutó con éxito. Kernel de Linux Escritorio remoto RustDesk 1.2.3 lanzado, soporte mejorado para Wayland Después de desconectar el receptor USB de Logitech, el kernel de Linux falló Revisión aguda de DHH de "herramientas de empaquetado ": no es necesario construir la interfaz en absoluto (Sin compilación) JetBrains lanza Writerside para crear documentación técnica Herramientas para Node.js 21 lanzadas oficialmenteAutor: Tecnología Jingdong Wang Xianke
Fuente: Comunidad de desarrolladores de JD Cloud Indique la fuente al reimprimir