¿Cuál es el proceso completo de prueba de software (desde el inicio de los requisitos del proyecto hasta el final del proyecto)? El director de pruebas y el PM revisan TC: Resumen del proceso de pruebas ágiles: En el método ágil, el método XP enfatiza la importancia de las pruebas durante todo el proceso de desarrollo del proyecto. Las pruebas ágiles para métodos de desarrollo ágiles son diferentes de las pruebas anteriores para modelos de desarrollo tradicionales. En un equipo ágil, las pruebas son la "gran luz" para todo el equipo del proyecto, ya que les dice a todos dónde se encuentran ahora y en qué dirección van. Los evaluadores brindan al equipo del proyecto una gran cantidad de información para que pueda tomar decisiones correctas basadas en esta información confiable. No sólo los evaluadores tienen que garantizar la calidad, sino que todos los miembros del equipo del proyecto son responsables de la calidad. Los evaluadores no se preocupan por los errores de los desarrolladores, sino que los ayudan a encontrar sus objetivos y trabajar hacia el objetivo final del proyecto. Las pruebas ágiles también requieren un trabajo altamente iterativo, comentarios frecuentes de los clientes y ajustes dinámicos a los planes de prueba y la ejecución de las pruebas. Además, los probadores ágiles participan en actividades de producción más ágiles, lo que tiene un impacto positivo en las decisiones y planes realizados por el equipo. De acuerdo al modelo de desarrollo ágil adoptado actualmente por los proyectos de la empresa, se recomienda que las pruebas ágiles correspondientes adopten el siguiente proceso: 1. Los requisitos de verificación y los requisitos de diseño y diseño generalmente incluyen: (1) especificaciones de diseño funcional escritas por el gerente del proyecto con base en el texto de requisitos; (2) especificaciones de diseño de implementación escritas por los desarrolladores con base en el texto funcional, incluidos (documentos de arquitectura, declaraciones del alcance del proyecto, casos de uso). Como evaluador, el objetivo de la auditoría es comprobar la integridad y el rigor de la definición textual de los requisitos del usuario, así como la capacidad de prueba del diseño funcional. En la etapa inicial de las pruebas, los evaluadores deben aprender a realizar pruebas estáticas y hacer un buen trabajo en el análisis de la demanda y el análisis de la lógica del diseño. Los evaluadores deberían prestar más atención a la viabilidad de los requisitos y participar activamente en el análisis de requisitos, el diseño y el desarrollo de proyectos y sistemas como primer usuario. Participe activamente en el trabajo preliminar y envíe rápidamente los resultados de sus pruebas estáticas al diseño y desarrollo. Comience a probar lo antes posible, no espere hasta que la función esté completamente completa. Salida: La prueba debe enviar un documento de resultados de la revisión, lo que le permite participar más en la revisión del diseño y el marco de la base de datos. 2. Plan de pruebas, casos de prueba 2.1. En el desarrollo ágil, el tiempo se estima en función de la historia de cada usuario. Los desarrolladores evaluarán las historias de usuario completas necesarias para esta iteración. Los desarrolladores pueden comunicarse directamente con los clientes para priorizar cada historia de usuario. Beneficio: los clientes pueden comprender claramente qué historia de usuario lleva, cuánto tiempo y cuáles son sus prioridades. Problema: los desarrolladores a menudo subestiman las estimaciones del tiempo de las historias de los usuarios. Las versiones no se pueden publicar a tiempo o deben trabajar horas extras para publicarse. Análisis: Debido a la rápida actualización de la versión, el tiempo de la tarea se estima en horas. Los desarrolladores generalmente ignoran el tiempo fuera del desarrollo, como el tiempo en que se encuentran problemas durante el desarrollo, el tiempo para reuniones, el tiempo para ayudar a otros miembros, etc. Por ejemplo, el desarrollador estima que tomará 1,5 días codificar una historia de usuario, y el desarrollador estima que tomará medio día para otras ocasiones. Por tanto, el tiempo estimado dado por el desarrollador es de 2 días. El tiempo real dedicado a la fase de desarrollo es el siguiente y el tiempo dedicado a las reuniones periódicas cada día. Otros miembros del proyecto requieren apoyo técnico durante las reuniones periódicas. Así que estuve tres horas ayudando. Se encontraron algunos problemas inesperados durante el proceso de desarrollo y se necesitaron 4 horas para resolverlos. (probablemente más). Necesidad de afrontar algunos asuntos inesperados de la empresa, etc. Por lo tanto, se recomienda encarecidamente que tenga en cuenta otros factores al estimar el tiempo. Según un libro relacionado con XP, el mejor momento para estimar es 2 o 3 veces el tiempo de codificación. Suena aterrador, pero en la práctica lleva mucho tiempo. Los evaluadores preparan planes de prueba y diseñan casos de prueba basados en requisitos y diseños aprobados. Entre los tres textos mencionados anteriormente, el texto de diseño funcional es la base principal. Ambos textos de la prueba también deben ser revisados por el director del proyecto y el desarrollador. 2.2 Revisión de casos de prueba Para permitir que los desarrolladores participen en la revisión de casos de prueba, garantizar la calidad y viabilidad de TC, garantizar el progreso fluido de la prueba y permitir que los desarrolladores comprendan rápidamente los puntos clave de la prueba y brinden los correspondientes. opiniones y sugerencias, el evaluador debe crear una TC_Matrix (matriz de seguimiento de casos de prueba) mientras realiza TC. Indique qué características han sido cubiertas por TC y especifique la cantidad de TC correspondientes a cada característica, de modo que el administrador de pruebas y el PM puedan comprender claramente la cobertura de TC al revisar TC e identificar áreas con cobertura insuficiente (como casos de prueba insuficientes). para una característica clave) dar opiniones oportunas.
Además, durante la reunión de la mañana todas las mañanas, los evaluadores pueden hablar brevemente sobre las partes clave de las pruebas del día y los errores graves que existen en el proyecto, para que los desarrolladores puedan comprender cuáles son los puntos clave de las pruebas de ese día y cómo realizar las pruebas. y exponer sus propias opiniones y sugerencias. Esto mejora la comunicación entre desarrolladores y evaluadores, lo que permite que las pruebas se realicen de manera más eficiente y fluida. Los evaluadores deben tomarse el tiempo para actualizar los casos de prueba al final de una iteración. 3. Para implementar pruebas en ejecución en métodos ágiles, existen dos tipos de pruebas: pruebas unitarias y pruebas de recepción. Las pruebas unitarias las realizan los desarrolladores y las pruebas de aceptación las realizan los representantes del cliente. Como nuestros clientes no podían estar en el sitio, adoptamos, los desarrolladores realizan pruebas unitarias, los evaluadores realizan pruebas de verificación y, finalmente, el cliente realiza pruebas de aceptación. Los evaluadores deben probar cada versión antes de lanzarla a los clientes. Después del lanzamiento, los clientes realizarán pruebas de aceptación y propondrán los cambios que deban realizarse. Las áreas que deben modificarse se completarán en la próxima versión. ? Antes de proporcionar la versión de compilación diaria para la prueba, primero se deben realizar pruebas unitarias para informar los enlaces débiles en el software con anticipación y ayudar a los evaluadores a ajustar el enfoque de la prueba. El beneficio de las pruebas unitarias es que pueden mejorar la calidad de la versión, reducir la carga de trabajo de las pruebas y reducir la incidencia de errores superficiales, lo que permite a los evaluadores dedicar más energía a encontrar errores profundos. ? En términos generales, las pruebas de verificación realizadas por probadores de verificación son el proceso de poner en práctica los casos de prueba diseñados en el paso anterior según lo planeado. Las pruebas en esta etapa deben planificarse cuidadosamente. Esta planificación se refleja en primer lugar en la coordinación y cooperación del desarrollo y las pruebas. De acuerdo con las dependencias de la arquitectura del producto y los módulos funcionales, avanzaremos conjuntamente de acuerdo con el plan general del proyecto. Desde la perspectiva del proceso de prueba, la ejecución de la prueba puede apuntar a ciertas funciones al principio y puede expandirse gradualmente más adelante. Luego, se utiliza un proceso iterativo para completar la tarea de prueba, es decir, la tarea de prueba se divide en varios ciclos. Primero, puede realizar algunas pruebas funcionales clave y las partes reutilizables del código (componentes, partes) se pueden probar por completo. El siguiente ciclo de iteración se puede utilizar para pruebas funcionales de borde y otras pruebas, y las últimas iteraciones se deben utilizar para pruebas de regresión y pruebas clave de rendimiento y estabilidad. 3.1 Proporcionar tendencias de errores todos los días. Para medir convenientemente el progreso del proyecto, la prueba puede proporcionar tendencias de errores después de las pruebas diarias, es decir, la cantidad de errores nuevos generados y la cantidad de errores resueltos cada día se marcan como gráficos de tendencias. Generalmente, la curva del número de errores nuevos mostrará una tendencia ascendente en la etapa inicial del proyecto, la curva del número de errores resueltos tenderá a aumentar en las etapas intermedias y posteriores del proyecto, y la curva del número de errores resueltos tenderá a aumentar en las etapas intermedias y posteriores del proyecto. El número de errores nuevos debería ser menor. Al final del proyecto, ambas curvas se acercan a cero. El primer ministro continuará observando este gráfico para garantizar el desarrollo saludable del proyecto y, al mismo tiempo, predecirá los errores del proyecto mediante el análisis. Para cada versión de error, los desarrolladores deben pensar por qué ocurren tales problemas, especialmente errores de muy bajo nivel, y si se pueden evitar errores similares. Es necesario considerar las pruebas: Preparación de casos de prueba exploratorios 3.2 Mantenimiento de casos de prueba Durante la implementación de la fase de prueba, los evaluadores deben mantener los casos de prueba existentes de manera oportuna. Generalmente es necesario agregar algunos casos de prueba en las dos situaciones siguientes: primero, para áreas donde el diseño de la prueba estaba incompleto al principio, y segundo, para errores externos (como los errores informados por los clientes Beta) que no están cubiertos por las normas existentes. casos de prueba. Cuando el diseño funcional del producto cambia (el diseño funcional a menudo cambia en proyectos ágiles), los casos de prueba involucrados deben modificarse en consecuencia para mantenerlos sincronizados con los requisitos funcionales existentes. 3.3 Sumar conocimientos continuamente según el proyecto. Durante el proyecto, los evaluadores deben acumular experiencia continuamente y complementar y mejorar continuamente los estándares de sentido común para diversos fines. Por ejemplo, el sentido común estándar de EE. UU. resumido en el proyecto CTTS debe seguirse estrictamente en futuros proyectos de EE. UU. para garantizar que los errores que ocurrieron antes no reaparecerán en futuras pruebas de proyectos. Mientras garantizamos la calidad del proyecto, seguimos acumulando nueva experiencia. 3.4 Control de versiones intermedias Para garantizar mejor la calidad del software y evitar riesgos, es necesario fortalecer el control de las versiones intermedias. Por ejemplo, si un cliente requiere o planea enviar una versión el viernes, entonces debe enviar una versión intermedia para prueba el miércoles, lo que significa controlar la versión intermedia para evitar completar todo el trabajo en el momento más urgente en la etapa posterior. En proyectos anteriores, la etapa inicial del proyecto fue fácil, pero hubo cada vez más errores en la etapa posterior. Los desarrolladores y evaluadores están muy ocupados y, a menudo, trabajan horas extras.