Métodos y herramientas de prueba de software comunes

La herramienta de prueba de carga estándar de la industria LoadRunner es una herramienta de prueba de carga que predice el comportamiento y el rendimiento del sistema. LoadRunner puede simular decenas de millones de usuarios bajo cargas simultáneas, probar arquitecturas empresariales completas y monitorear el rendimiento en tiempo real para identificar y localizar problemas. Con LoadRunner, las empresas pueden minimizar el tiempo de prueba, optimizar el rendimiento y acelerar los ciclos de lanzamiento de aplicaciones. Herramienta de prueba funcional automatizada AutoRunnerAutoRunner es una herramienta de prueba de caja negra que se puede utilizar para completar pruebas funcionales, pruebas de regresión, pruebas de compilación diarias y pruebas de regresión automatizadas. Es una herramienta de prueba automatizada con un lenguaje de secuencias de comandos, proporciona funciones completas de seguimiento y depuración de secuencias de comandos, admite pruebas de IE y pruebas nativas de Windows y es la mejor herramienta de pruebas bancarias en China. Sistema global de gestión de pruebas testdirectorTestDirector es el primer sistema de gestión de pruebas basado en web de la industria que permite la gestión global de pruebas dentro y fuera de la empresa. TestDirector acelera drásticamente el proceso de prueba al integrar todos los aspectos de la gestión de pruebas, incluida la gestión de requisitos, la planificación de pruebas, la ejecución de pruebas y el seguimiento de errores, en una aplicación monolítica. TestCenterTestCenter es una potente herramienta de gestión de pruebas que puede realizar la gestión de requisitos de prueba, la gestión de casos de prueba, la gestión de componentes comerciales de prueba, la gestión de planes de prueba, la ejecución de pruebas, la visualización de registros de resultados de pruebas, el análisis de resultados de pruebas, la gestión de defectos y admite requisitos de prueba y relaciones entre pruebas. casos. Los requisitos de prueba se pueden indexar mediante casos de prueba. La herramienta de prueba automatizada de terminal TARTAR funciona con VT100, VT220 y otras aplicaciones estándar, admitiendo el modo de línea de comandos y el modo de ventana (aplicaciones escritas con el cursor). Admite el registro automático de aplicaciones de terminal. Admite grabación continua y grabación en ventana única. Admite componentes de ventana: campos, formularios, cuadros de diálogo, ventanas, etc. Herramienta de prueba funcional Rational RobotBorland SilkTest 2006 es una herramienta de prueba funcional de software y es una de las suites de soluciones de gestión de calidad de software propuestas por Borland. La herramienta utiliza asistentes para configurar y automatizar pruebas, lo que permite a programadores principiantes y experimentados configurar rápidamente pruebas funcionales y analizar errores funcionales. WASMicrosoft Web Application Stress Tool es un conjunto de herramientas desarrolladas por probadores de redes de Microsoft específicamente para realizar pruebas de estrés de sitios web reales. Esta poderosa herramienta de prueba de estrés le permite simular el impacto de una gran cantidad de usuarios en los servicios de red utilizando una pequeña cantidad de computadoras cliente. La herramienta automática de prueba de caja blanca JtestJtest es una herramienta de prueba automática de caja blanca para el lenguaje Java lanzada por Parasoft. Mejora la confiabilidad del código al ejecutar automáticamente pruebas unitarias de Java y verificación estándar del código. Parasoft también fabrica C Test, una herramienta de prueba de caja blanca de C/C. Herramienta de prueba funcional y de rendimiento JMeterJMeter es un proyecto de código abierto organizado por Apache. Es una herramienta de prueba funcional y de rendimiento, 100 implementaciones de Java. Herramienta de análisis y pruebas de rendimiento WEBLODE webload es una herramienta de análisis y pruebas de rendimiento de RadView, que permite a los desarrolladores de aplicaciones web realizar automáticamente pruebas de estrés y generar cargas de estrés simulando operaciones reales del usuario para probar el rendimiento de la web; Herramienta de prueba automatizada de nivel empresarial WinRunner WinRunner de Mercury Interactive es una herramienta de prueba funcional de nivel empresarial que verifica si una aplicación funciona como se espera y funciona correctamente.

Al registrar, detectar y reproducir automáticamente las operaciones de las aplicaciones del usuario, WinRunner puede ayudar eficazmente a los evaluadores a probar diferentes versiones de aplicaciones empresariales complejas, mejorar la eficiencia y la calidad del trabajo de los evaluadores y garantizar una liberación sin problemas y una estabilidad a largo plazo de aplicaciones empresariales complejas multiplataforma. correr.

Los gerentes de pruebas y los gerentes de proyectos revisan TC:

Descripción general del proceso de pruebas ágiles:

En los métodos ágiles, el método XP enfatiza el papel de las pruebas durante todo el desarrollo del proyecto. importancia del proceso. Las pruebas ágiles en métodos de desarrollo ágiles son diferentes de las pruebas en modelos de desarrollo tradicionales. En un equipo ágil, las pruebas son el "foco" para todo el equipo del proyecto, y les dicen a todos dónde se encuentran ahora y hacia dónde se dirigen. Los evaluadores proporcionan al equipo del proyecto una gran cantidad de información sobre la cual pueden tomar decisiones. No son sólo los evaluadores los responsables de la calidad, sino todos los miembros del equipo del proyecto. En lugar de insistir en los errores de los desarrolladores, los evaluadores los ayudan a encontrar sus objetivos y trabajar juntos para lograr el objetivo final del proyecto. Las pruebas ágiles también requieren un alto grado de trabajo iterativo, comentarios frecuentes de los clientes y ajuste dinámico de los planes de prueba y la ejecución de las pruebas. Además, los probadores ágiles participarán en actividades de producción más ágiles y tendrán un impacto positivo en las decisiones y planes del equipo.

De acuerdo con el modelo de desarrollo ágil adoptado actualmente por los proyectos de la empresa, se recomienda adoptar el siguiente proceso para las pruebas ágiles:

1. Verificar requisitos y diseño

Los requisitos y el diseño generalmente incluyen (1) El texto de diseño funcional (Especificación de diseño funcional.Especificación) escrito por el gerente del proyecto en base al texto de requisitos (2) El texto de diseño de implementación (Especificación de diseño de implementación) escrito por el desarrollador; El texto funcional incluye (documento de arquitectura, descripción del alcance del proyecto, casos de uso). Como evaluador, el objetivo de la revisión es comprobar la integridad, el rigor y la capacidad de prueba del diseño funcional del texto de definición de requisitos del usuario.

En la etapa inicial de las pruebas, los evaluadores deben aprender a realizar pruebas estáticas, hacer un buen trabajo en el análisis de la demanda y hacer un buen trabajo en el análisis de la lógica del diseño. Los evaluadores deberían pensar más en 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 esté completamente funcional.

Resultado: Las pruebas deben enviar documentos de resultados de la revisión, lo que permite que las pruebas participen más en la revisión del diseño y el marco de la base de datos.

2. Plan de prueba, caso de prueba

2.1 Redacción de planes y casos de prueba

En el proceso de desarrollo ágil, se basa en la estimación de tiempo de cada historia de usuario. Los desarrolladores evaluarán las historias de usuarios que deben completarse para esta iteración. Los desarrolladores pueden comunicarse directamente con los clientes para priorizar cada historia de usuario.

Ventajas:

Los clientes pueden entender claramente qué historias de usuario toman, cuánto tiempo y cuáles son sus prioridades.

Problema:

Los desarrolladores a menudo subestiman el tiempo de las historias de los usuarios. Esto da como resultado que las versiones no se publiquen a tiempo o que haya que trabajar horas extras para publicarlas.

Análisis:

Debido al rápido ritmo al que se lanzan las actualizaciones, las tareas se estiman en horas. Los desarrolladores a menudo pasan por alto el tiempo fuera del desarrollo, como el tiempo dedicado a desarrollar problemas, asistir a reuniones, brindar asistencia a otros miembros, etc.

Un ejemplo de ello es el tiempo utilizado para publicar.

Ejemplo:

El desarrollador estima que codificar una historia de usuario llevará 1,5 días y el desarrollador estima que el tiempo restante será medio día. Entonces el tiempo estimado dado por los desarrolladores es de 2 días. El tiempo real dedicado durante la fase de desarrollo es el siguiente, incluido el tiempo de reunión diaria. Durante estas reuniones, otros miembros del proyecto requieren apoyo técnico. Así que pasé 3 horas ayudando. Durante el proceso de desarrollo, se encontraron algunos problemas inesperados y se necesitaron 4 horas para resolverlos.

(probablemente más). Necesidad de afrontar algunos problemas inesperados de la empresa, etc. Por lo que es muy recomendable que tengas en cuenta otros factores a la hora de estimar tu tiempo. Un libro relacionado con XP dice que el mejor momento para estimar es 2 o 3 veces el tiempo de codificación. Esto suena aterrador, pero en realidad lleva mucho tiempo.

Los evaluadores escriben planes de prueba y diseñan casos de prueba basados ​​en los requisitos y diseños aprobados. Entre los tres textos mencionados anteriormente, el texto de diseño funcional es la base principal. Los directores de proyectos y desarrolladores también revisan estos dos textos de prueba.

2.2 Revisión de casos de prueba

Para permitir que los desarrolladores participen en la revisión de casos de prueba para garantizar la calidad y viabilidad de TC, garantizar el buen progreso del trabajo de prueba y Además, para permitir que los desarrolladores comprendan rápidamente los puntos clave de las pruebas y presenten las opiniones y sugerencias correspondientes, los evaluadores deben establecer una TC_Matrix (matriz de seguimiento de casos de prueba) al proponer TC, indicando qué funciones cubre el TC y el TC correspondiente a cada función. Número, para que el administrador de pruebas y el PM puedan comprender claramente la cobertura del TC al revisar el TC y puedan hacer sugerencias oportunas en caso de cobertura insuficiente (como: ............. .. ....por ejemplo, no hay suficientes casos de prueba para una característica clave).

Esta es la primera vez que veo un TC con una carcasa funcional.

Además, durante la reunión de la mañana de cada mañana, los evaluadores pueden describir brevemente las partes clave de las pruebas del día y qué errores graves existen en el proyecto, para que los desarrolladores puedan comprender cuáles son los puntos clave de las pruebas de ese día. son cómo probar y dar sus propias opiniones y sugerencias. Esto mejora el intercambio y la comunicación entre desarrolladores y evaluadores, haciendo que las pruebas sean más eficientes y fluidas.

Al final de una iteración, las pruebas toman tiempo para actualizar los casos de prueba.

3. Implementar pruebas en ejecución

En los métodos ágiles, existen dos tipos de pruebas: pruebas unitarias y pruebas de aceptación. Las pruebas unitarias las realizan los desarrolladores, mientras que las pruebas de aceptación las realizan los representantes del cliente.

Dado que el cliente no puede visitar el sitio en persona, adoptamos el método en el que 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. Una vez lanzada la versión, los clientes realizarán pruebas de aceptación y propondrán los cambios que deban realizarse. Los cambios se realizarán en la próxima versión. Pruebas unitarias

Antes de crear una versión todos los días y probarla, se deben desarrollar pruebas unitarias para informar los puntos débiles del software con anticipación y ayudar a los evaluadores a ajustar el enfoque de las pruebas.

La ventaja de realizar pruebas unitarias es que puede mejorar la calidad de la versión, reducir la carga de trabajo de las pruebas, reducir la incidencia de errores superficiales y permitir que los evaluadores dediquen más energía a las pruebas.

El beneficio de las pruebas unitarias es que puede mejorar la calidad de la versión, reducir la carga de trabajo de los evaluadores y reducir la incidencia de errores superficiales, lo que permite a los evaluadores dedicar más energía a encontrar errores profundos. Pruebas de verificación

En términos generales, las pruebas de verificación de los evaluadores son el proceso de implementar los casos de prueba diseñados en el paso anterior según lo planeado. Esta fase de prueba debe planificarse cuidadosamente. Este tipo de planificación se refleja primero en la coordinación y cooperación mutuas del desarrollo y las pruebas, en función de las dependencias de la arquitectura del producto y los módulos funcionales, y de acuerdo con el plan general del proyecto ****. Desde la perspectiva del proceso de prueba, la ejecución de la prueba inicial puede apuntar a algunas funciones y puede ampliarse gradualmente más adelante. Luego comience a usar un proceso iterativo para completar la tarea de prueba, es decir, divida la tarea de prueba en varios ciclos. Puede realizar algunas pruebas funcionales clave al principio y puede reutilizar partes del código (componentes, componentes). pruebas completas. El siguiente ciclo de iteración se puede utilizar para pruebas funcionales de borde y otras pruebas, y los últimos ciclos de iteración se deben utilizar para pruebas de regresión y pruebas clave de rendimiento y estabilidad.

3.1 Proporcionar tendencia de error diaria

Para medir fácilmente el progreso del proyecto, la prueba puede proporcionar la tendencia de error diaria de la prueba una vez completada la prueba, es decir, Marque la tendencia de error diaria en forma de gráfico de tendencia. Número de nuevos errores generados y errores resueltos diariamente. En términos generales, al comienzo del proyecto, la cantidad de errores nuevos tendrá una tendencia ascendente, mientras que en las etapas intermedia y final del proyecto, la cantidad de errores resueltos tendrá una tendencia ascendente, mientras que la cantidad de errores nuevos tendrá una tendencia a la baja, y al final del proyecto, ambas curvas tienden a cero. El PM continuará observando este gráfico para garantizar el desarrollo saludable del proyecto y, al mismo tiempo, predecirá los errores del proyecto analizando este gráfico

Para cada versión de error, los desarrolladores

Para cada versión de error, los desarrolladores deben pensar por qué aparece, especialmente para errores de muy bajo nivel, y si se pueden evitar errores similares.

Las pruebas deben considerar: escribir casos de prueba exploratorios

3.2 Mantener los casos de prueba

Durante la ejecución de la fase de prueba, los evaluadores deben mantener los casos de prueba existentes en Casos de prueba de manera oportuna. Por lo general, se agregan algunos casos de prueba nuevos en las dos situaciones siguientes: uno es para áreas donde el diseño de la prueba no se consideró completamente al principio y el otro es para errores externos que no están cubiertos por los casos de prueba existentes (como los informados por Clientes Beta) error). Cuando el diseño funcional del producto cambia (el diseño funcional cambia con frecuencia en proyectos ágiles), los casos de prueba involucrados también deben modificarse en consecuencia, de modo que los casos de prueba estén sincronizados con los requisitos funcionales existentes.

3.3 Complementar continuamente el sentido común según la situación del proyecto

Durante el proceso del proyecto, los evaluadores deben acumular experiencia continuamente y complementar y mejorar constantemente los estándares de sentido común para diferentes proyectos. Por ejemplo, en futuros proyectos estadounidenses, las pruebas deben realizarse estrictamente de acuerdo con los estándares de "sentido común estadounidense" resumidos por el proyecto CTTS para garantizar que los errores que ocurrieron en el pasado ya no aparezcan en pruebas futuras del proyecto. 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 reforzar el control de las versiones intermedias. Por ejemplo, si el cliente requiere o planea enviar una versión el viernes, entonces la versión intermedia debe enviarse para prueba el miércoles. Es decir, la versión intermedia debe controlarse para evitar que todo el trabajo se complete en el momento más urgente. tiempo en la etapa posterior. En proyectos anteriores, ha habido situaciones en las que la etapa inicial del proyecto fue fácil, pero en la etapa posterior hubo cada vez más errores y los desarrolladores y evaluadores estaban extremadamente ocupados y, a menudo, trabajaron horas extras. Para reducir la carga de trabajo en la etapa posterior y evitar riesgos, se recomienda utilizar Daliy Build durante el desarrollo o realizar una compilación una vez que se complete una función y probar la función. Esto puede evitar eficazmente la aparición de más y más errores. en la etapa posterior, la cantidad se reducirá en consecuencia y la calidad del proyecto estará más garantizada.

3.5 Escriba notas de la versión antes de lanzar una versión

Antes de cada lanzamiento, los evaluadores deben escribir notas de la versión basadas en la próxima versión para que los clientes tengan una comprensión clara de la versión lanzada. Problemas conocidos. Entre ellos, la parte Corregida son los errores principales que existían en la versión anterior que esta versión solucionará; la parte de Nuevas Funciones son las funciones recién agregadas en esta versión; la parte de Problemas Conocidos son los problemas principales que aún existen en esta versión; se enumerarán a continuación. Mejorarlo en la primera versión o enumerar las áreas donde los requisitos no están claros y dar respuestas claras a las opiniones de los clientes.

4. Gestión de requisitos

En proyectos que utilizan el modelo de desarrollo ágil, las necesidades del cliente suelen cambiar. Por tanto, la gestión de la demanda es una tarea muy necesaria e importante. A lo largo del proceso del proyecto, se debe realizar un seguimiento de los cambios en los requisitos, y cada cambio de requisitos debe tener un registro histórico correspondiente para facilitar el trabajo posterior de gestión y mantenimiento. Cada cambio se puede organizar y registrar en el documento de seguimiento de requisitos, y el documento se puede actualizar en cualquier momento para mantenerse al día con el ritmo de los cambios en la demanda.

Problema:

Los clientes pueden cambiar sus requisitos de un lado a otro en un determinado punto de función. Es posible que necesiten una determinada función al principio, pero luego se sientan mal por ella una vez completada. entonces ya no lo usan. Más tarde, por alguna razón, fue necesario agregar la función. Puede haber muchas revisiones yendo y viniendo a lo largo del proceso. Luego asegúrese de registrar el contenido y la fecha de la modificación. Quizás los clientes más adelante se pregunten por qué una función lleva tanto tiempo no se realizó durante mucho tiempo. En este momento, estos registros son la mejor prueba para resolver las inquietudes de los clientes. Para decirlo sin rodeos, hay pruebas de que hemos realizado muchos cambios. Quizás estés pensando, ¿cómo puede ser esto un problema? De hecho, cuando un proyecto dura más de medio año, tal vez la memoria de todos no sea confiable (:p)

Sugerencia:

Actualmente, estoy usando la herramienta vss y cada día Haga una copia de seguridad de los requisitos de cambio mencionados en el correo electrónico y el documento lleve el nombre de la fecha en que se recibió el correo electrónico

5. Realice actividades de "limpieza de errores" al final del desarrollo del proyecto

Durante el desarrollo del proyecto. Al finalizar, podrás realizar actividades de "Limpieza de errores". Reserve un período de tiempo dedicado durante el cual todos los involucrados en el proyecto centren toda su atención en buscar errores en el proyecto. Tenga en cuenta lo siguiente:

(1) Aunque se trata de una actividad de prueba, los participantes no se limitan a los evaluadores. Los directores de proyectos, los desarrolladores e incluso los altos directivos deberían participar, como en una movilización nacional. El propósito es realizar una lluvia de ideas; (2) fomentar la búsqueda cruzada entre departamentos y campos, porque las nuevas ideas y perspectivas generalmente ayudan a encontrar más errores (3) para movilizar el entusiasmo y aumentar el interés, se puede introducir adecuadamente un mecanismo de competencia; como Al final de la actividad, las personas que encontraron la mayor cantidad de errores y los errores más graves serán juzgadas y recibirán recompensas materiales y espirituales. (4) Puede comenzar con temas como seguridad, usabilidad de la interfaz de usuario, internacionalización y localización, etc.