1. Antecedentes
Requisitos de especificación del proyecto en el trabajo: para proyectos con un cronograma de prueba superior a 3D, se debe escribir un plan de prueba. Después de investigar la situación de algunos estudiantes, sobre la base de los requisitos de esta especificación de proceso, también se preparará un plan de prueba para situaciones como una lógica compleja de requisitos o una implementación técnica compleja.
Personalmente, soy el principal responsable de la prueba del sistema OMS, que es un nodo importante en todo el flujo de cumplimiento del contrato. El posicionamiento del sistema es administrar los datos del pedido en el núcleo de circulación del cumplimiento del contrato. Dado que el sistema tiene un gran impacto en el proceso comercial general, la estructura del proceso del sistema debe ser muy clara y la calidad debe garantizarse estrictamente. Quiero compartir brevemente mi pequeño hábito de escribir planes de prueba basados en mi perspectiva personal y la situación del sistema.
2. La forma de escribir
El método de cada persona para escribir planes de prueba es diferente. Después de algunas estadísticas de personal, la mayoría de los planes de prueba de los estudiantes comenzaron después de que se completó la revisión del plan técnico. Debido a las características del sistema, la comprensión del sistema y los hábitos personales de escritura, etc., el nodo de tiempo para escribir el plan de prueba es después de completar la revisión de requisitos, y luego en el diseño técnico, revisión técnica y otras etapas de optimización continua. y mejora
2.1 Fase 1: Antes de que comience la revisión de requisitos
¿Cuál es la comprensión preliminar de esta demanda?
El producto enviará los requisitos por adelantado, y es necesario verificar los antecedentes de los requisitos, los objetivos y el diseño de los requisitos por adelantado. Verifica si hay algún lugar poco claro según la demanda, por ejemplo: ¿Hay una segunda fase? ¿Es una solución temporal? ¿Versatilidad? ¿Faltan procesos de negocio? ¿Están claros los límites de los requisitos? ¿La función se ajusta al posicionamiento del sistema? ¿Es el proceso perfecto y razonable? etc. Llevar a cabo la revisión de requisitos con estas preguntas ayuda a analizar los requisitos y evita algunos detalles comerciales imprecisos. Intente confirmar todo lo que se puede confirmar en una revisión.
2.2 La segunda etapa: después de que comienza la revisión de la demanda, el diseño de la solución técnica
Después de la revisión de requisitos:
1. Complete el plan de prueba: complete la información clara sobre el nivel de demanda, como los antecedentes y los objetivos del proyecto en el plan de prueba.
2. Comunicación preliminar: aclare si este cambio de demanda involucra múltiples sistemas comerciales y comunique previamente para aclarar el límite de la demanda y la persona a cargo del sistema relacionado. Problemas relacionados pueden localizar rápidamente a la persona a cargo.
3. Borre el proceso de demanda y dibuje la primera versión del diagrama de flujo: utilice la perspectiva de control de calidad para dibujar el diagrama de flujo de demanda. Es mejor dibujarlo de nuevo cuando involucre el proceso. El desarrollo de este nodo comienza con el diseño de la solución técnica, primero se puede dibujar el diagrama de flujo desde la perspectiva de la demanda y pensando en el proceso de negocio puro, y registrar las dudas.
Todavía hay algo que decir sobre el diagrama de flujo: en términos generales, el producto tendrá un diagrama de flujo en la demanda. Lo que pensé al principio fue que si hay un producto, simplemente use el producto. Hasta que hubo una revisión del plan de prueba, el producto decía: "Este diagrama de flujo 'me copió'". También es una "buena cara" temporal, ¡tal vez sea solo una imagen! Lo dibujo yo mismo. Cuando lo dibujé por primera vez, descubrí que el diagrama de flujo del producto original tenía algunos "puntos ciegos" para el control de calidad, como: el flujo de estado no era lo suficientemente claro y el procesamiento lógico no era lo suficientemente detallado. En el proceso de dibujar el diagrama de flujo, use la perspectiva de las pruebas de control de calidad para comprender en detalle el proceso de flujo comercial, el procesamiento lógico y los resultados en diferentes escenarios.
En el diseño del esquema técnico:
1. Mejore el diagrama de flujo por primera vez:
Una vez que se completa el dibujo preliminar del diagrama de flujo, existe una alta probabilidad de que haya algunos problemas de proceso, como diferencias en la comprensión de los métodos de implementación del flujo de estado, procesamiento lógico, etc., o discrepancias en la implementación. Tenemos que discutir con el desarrollo y seguir mejorando. Este es el proceso de combinar demanda y desarrollo, y también el proceso de supervisión de la vinculación. Afectar la implementación de la tecnología desde una perspectiva comercial para evitar el diseño ciego del desarrollo, lo que resulta en un "retrabajo" causado por la falta de lógica de demanda o desviaciones de comprensión.
2. Comunicación adicional y aclaración preliminar de información:
(1) Confirmación de los límites de los requisitos, hitos, etc.: en el proceso de requisitos que involucra la integración de múltiples sistemas, los límites claros de los requisitos deben tener un sentido de propiedad. Si la persona a cargo de las pruebas de requisitos no es él mismo, también debe tomar la iniciativa para comprender el ritmo del sistema asociado, la persona a cargo de las pruebas de sistemas múltiples, la división de funciones de requisitos, etc. Información clara como los límites de cada sistema. No habrá "moscas sin cabeza" durante la prueba.
(2) Confirmación simultánea de demandas y análisis preliminar. Si depende de otros sistemas para brindar cooperación o si necesita proporcionar algunas capacidades a otros sistemas, tales como: preparación de datos, estructura de datos, configuración de información, etc.
(3) Comunicación de ritmo: la comprensión preliminar del ritmo de prueba de otros sistemas puede mejorar los planes de prueba y las estrategias de prueba.
Por ejemplo:
El servicio dependiente se inicia más tarde y las tareas de prueba relacionadas con esta función se pondrán en cola más tarde;
Si la capa superior se basa en esta función de servicio, si el ritmo está unificado, la capa superior puede iniciar la cobertura de la escena; si la capa superior llega tarde a la prueba, puede probar la interfaz por sí misma;
Si varios sistemas dependen de él, las pruebas internas deben realizarse con anticipación para no afectar el ritmo de otros sistemas, etc. Conocerlos puede generar condiciones previas de riesgo, como una fuerte dependencia y diferencias de ritmo excesivas.
2.3 La tercera etapa: después del diseño de soluciones técnicas
Es necesario aclarar la configuración involucrada, el diseño de la tabla de biblioteca y la implementación del proceso. La corrección secundaria del plan de implementación de la función, actualizar el contenido correspondiente del plan de prueba.
1. Confirmación de la lógica del proceso:
Verifique si el diagrama de flujo es consistente con la implementación después de la revisión de la solución técnica;
Dependencia funcional de la interacción de múltiples partes, dependencia secuencial
2. Confirmación de configuración:
Por ejemplo, Apollo, la configuración de la página y algunos procesos en línea deben confirmarse con el producto y el desarrollo de la configuración de datos en línea, y deben realizarse verificaciones de la zona de pruebas.
3. Diseño de mesa de biblioteca:
El diseño de la tabla de la biblioteca se centra en si afecta el proceso y los datos en línea;
Ya sea que haya cambios de campo en tablas de datos a gran escala, dicho SQL solo se puede ejecutar por la noche. Antes del sandbox, es necesario recordar al desarrollador que ejecute la declaración SQL el día anterior, para evitar que el progreso de la verificación sea afectados por no ejecución;
Ya sea que cambie la máquina de estado, si cambia la máquina de estado de OMS, no se puede reiniciar en línea después de implementar el espacio aislado; de lo contrario, no se puede iniciar el servicio y se debe comunicar el front-end de O&M. Las demandas simultáneas no se pueden fusionar en línea.
4. Cambios en la interfaz:
Si hay un procesamiento de campo de aumento o disminución para la interfaz original, y si es necesario aclarar quién llama a la interfaz, si el paquete jar se actualizará en consecuencia. Tome como ejemplo agregar un campo. Cuando se agrega el campo y hay una lógica de verificación, la persona que llama no ha actualizado el jar. Si el campo es nulo y hay lógica, aparecerá un puntero nulo. En este caso, se debe hacer una regresión compatible.
2.4 La cuarta etapa: antes de la revisión del plan de prueba
Para este nodo, si existen otros sistemas relacionados, cada dirección debe tener claramente definido el diseño de requisitos y el diseño técnico. En este momento, es necesario tomar una determinación final con la persona de control de calidad a cargo de cada sistema y mejorar el contenido vago en el primer borrador del plan de prueba;
1. Si existe una dependencia de la estructura de datos
2. La escena de la interacción de la función del sistema, la parte principal y la parte interesada de los casos de uso de escena relacionados sincrónicamente;
3. Para la situación de confiar en otros sistemas, de acuerdo con el ritmo de prueba de otros sistemas, evaluar el impacto y analizar si es necesario ajustar su propio plan de prueba y estrategia de prueba;
4. ¿Qué debo proporcionar para otros sistemas, el nodo de tiempo esperado, etc.
2.5 Fase 5: Revisión del plan de prueba
Suelo hacer la revisión del plan de pruebas el mismo día que el plan técnico, mientras siga el “calor” de la demanda, es mejor alinear las perspectivas, unificar el ritmo y las diferencias. Todos tienen más claro qué hacer a continuación y el ritmo del proyecto es más claro.
3. Cambios de enfoque
Después de comprender realmente el contenido del plan de prueba, encontramos que la plantilla del plan de prueba utilizada por nuestra empresa incluye las características de cada sistema. El contenido al que se debe prestar atención en la prueba del proyecto es como un esquema detallado, recordándonos que debemos prestar atención a algún contenido que no se ha considerado. Completar concienzudamente cada ítem puede ayudarnos a afinar el método y el ritmo de la prueba. También existe un cierto proceso para que las personas cambien su mentalidad desde que entraron en contacto por primera vez con el plan de prueba hasta que entendieron el plan de prueba.
Actuar de acuerdo con las normas:
Al principio, de acuerdo con los requisitos de la especificación del proyecto, se escribió el plan de prueba para el proyecto más grande que 3D. El proceso de escribir un plan de prueba es también un "llenar el espacio en blanco" de "no saber por qué". En el proceso de escribir varios planes de prueba, descubrí que el módulo del plan de prueba en el plan de prueba puede refinar el cronograma y facilitar el ritmo claro de los requisitos. Los hitos de ritmo claros están en el plan de prueba, lo que ayuda a planificar el ritmo de prueba de manera razonable.
Centrarse en : hitos del proyecto, plan del proyecto
Investigación multipartidista, conociéndose a sí mismo y al enemigo:
Después de un período de tiempo, OMS comenzó a recopilar acceso comercial durante este período. Con el acceso continuo de múltiples negocios como bocadillos y tiendas, la acumulación del proceso en sí comenzó a prestar atención al límite de prueba del sistema, la función de conexión nodos en la entrega de múltiples sistemas, y el sistema En el proceso de cooperación de múltiples sistemas, esta información es muy importante. Es posible localizar más rápidamente el problema y su sistema y los contactos del sistema, y solucionar los problemas con mayor rapidez. Aclare su propio negocio, reduzca los puntos ciegos de otros sistemas y mejore su pensamiento empresarial.
Puntos clave de atención : límites de demanda, división de demanda, personal de acoplamiento del sistema multipartidista, preparativos preliminares, etc.
Las tácticas son claras:
La disposición de los medios de prueba es tan importante como la formulación de tácticas en el campo de batalla. Aumentar la importancia de este módulo en una demanda de optimización de la tecnología interna de OMS. Después de que la empresa se involucró en el sistema OMS a gran escala, comenzó la optimización interna del sistema dentro del OMS, y el mayor cambio central fue el ajuste del modelo de inventario. Este requisito no es consciente del negocio externo, pero la estructura interna cambia mucho. El contenido de este plan de pruebas también fue optimizado muchas veces durante el proceso solicitado por el responsable. Es necesario tener una comprensión profunda de la solución técnica y mejorar el contenido del plan de prueba, como: estrategia de escala de grises, configuración relacionada, estrategia de prueba y métodos de prueba, etc. También confirmar y comunicar previamente el alcance de la devolución, el sistema afectado y la persona encargada de atender la devolución. Minimice el riesgo, continúe corrigiendo la dirección que debe confirmarse y asegure la calidad.
Puntos clave de atención : proceso de solución técnica, estrategia de prueba, medios de prueba, elementos de configuración e inspección, etc.
Cerca de negocios:
Con la acumulación de horas de trabajo, me di cuenta de que si quiero entender realmente el sistema, tengo que acercarme al negocio. Es muy importante comprender el posicionamiento del sistema, la dirección del desarrollo y el próximo plan. De esta manera, en algunos requisitos grandes, el diseño de los requisitos se puede analizar de acuerdo con la dirección comercial, los objetivos a largo plazo, el posicionamiento del sistema y si se trata de un desarrollo a largo plazo, y si la dirección del diseño técnico se analiza en colaboración si es adecuado para iteraciones a largo plazo. Solo prestando atención a los objetivos, antecedentes y cumplimiento de los requisitos podemos controlar mejor la calidad.La premisa del proyecto debe ser comercial.
Centrarse en : antecedentes del proyecto, objetivos del proyecto, etc.
4 Resumen
Espero que no solo sea un QA, sino también un vinculador que pueda vincular productos y tecnologías, haciendo que la tecnología y yo esté más cerca del negocio, y espero que los productos puedan comprender el sistema en múltiples dimensiones. Espero que al tiempo que protege la calidad del sistema, también es un protector de ritmo de proyecto calificado.
Los anteriores son algunos de mis pequeños hábitos, ¡compartir un poco!
Finalmente: para retribuir a los fanáticos acérrimos, he compilado un video tutorial de aprendizaje de prueba de software completo para usted. Si lo necesita, puede obtenerlo gratis【保证100%免费】
Documentación de la entrevista de prueba de software
Debemos estudiar para encontrar un trabajo bien remunerado. Las siguientes preguntas de la entrevista son los materiales de entrevista más recientes de empresas de Internet de primer nivel como Ali, Tencent y Byte, y algunos jefes de Byte han dado respuestas autorizadas. Termine este conjunto Los materiales de la entrevista creen que todo el mundo puede encontrar un trabajo satisfactorio.
