5 tendencias principales de pruebas de software en el futuro y la ruta avanzada de pruebas de software

Las empresas de todo el mundo evolucionan todos los días para enfrentar los desafíos del mercado y satisfacer las necesidades cada vez más sofisticadas de los clientes. Incluso los avances tecnológicos en curso están haciendo que los expertos en pruebas de software se centren más y sean más precisos en su práctica.

　　2021 trae nuevas soluciones tecnológicas al campo de las pruebas de software, así como la implementación de la garantía de calidad y las pruebas de software. Al mismo tiempo, prácticas como Agile, DevOps, DevSecOps y automatización de pruebas continúan manteniendo su relevancia y aplicación a lo largo del ciclo de pruebas de software.

　　Algunas tendencias fuertes en el campo de las pruebas y el desarrollo de software en 2022-2023 son principalmente las siguientes:

　　1. La IA facilita las pruebas de software

　　Un artículo de Forbes titulado "Inteligencia artificial en las pruebas de software: ¿los robots ocuparán su lugar?" menciona: "La tendencia de confiar en la tecnología para completar tareas altamente repetitivas mientras libera a las personas para que se concentren en actividades de alto valor, como la generación de ingresos, la construcción de relaciones , y la gestión del crecimiento están acelerando el ritmo del cambio. Debido a que muchos espacios de prueba se duplican, hay razones para creer que la IA se puede usar fácilmente en estas áreas. El resto se dejará en manos de los evaluadores, quienes serán el trabajo de revisar el sistema, trabajando con inteligencia artificial, para revolucionar la forma en que se realizan las pruebas".

　　Esto ilustra la necesidad y la importancia de la IA en las pruebas de software. A medida que se acelera la transformación digital de los negocios, la aplicación de inteligencia artificial en la velocidad y precisión de las pruebas de software aumentará. Incluso el aprendizaje automático está dando grandes pasos en el proceso de prueba y desarrollo de software , especialmente en el análisis predictivo, el análisis de registros, el seguimiento de requisitos y el análisis de defectos.

　　2. Transformación Digital e Integración Continua

　　Durante el año pasado, ha habido muchos debates y artículos sobre la transformación digital . Las empresas están pasando por una transformación digital masiva, lo que ha creado muchas inseguridades y desafíos. Al usar métodos como Agile y DevOps, el proceso de prueba se vuelve más flexible y receptivo a las necesidades comerciales.

　　Sin embargo, dado que las nuevas características deben entregarse de forma incremental, esto intensificará la necesidad de una implementación e integración continuas en las aplicaciones que están en funcionamiento. Las transformaciones comerciales presentan nuevos desafíos todos los días, que pueden estar relacionados con el rendimiento, la seguridad o la funcionalidad. Como resultado, la necesidad de desarrollo e integración continuos solo aumentará con el tiempo.

　　3. Aplicación efectiva de datos de prueba en los negocios

　　Tal como predijeron los expertos en negocios y los geeks tecnológicos, los datos mejorarán las capacidades de toma de decisiones comerciales de los evaluadores y permitirán capacidades de toma de decisiones efectivas. Y lo que es más importante, los datos de prueba, que pueden garantizar que las inferencias extraídas sean precisas y se comuniquen de forma fácil de entender. Los evaluadores deben verificar que los terabytes de datos se procesen de manera eficiente y se dividan en grupos precisos para obtener las inferencias deseadas.

　　Estos datos de prueba se pueden aplicar a pruebas de rendimiento, pruebas funcionales e incluso pruebas de seguridad. En las pruebas de big data, es muy importante garantizar la calidad de los datos. Las pruebas de big data se pueden verificar a partir de características tales como precisión, exactitud, consistencia y repetibilidad.

　　4. Prueba aplicaciones inteligentes

　　Según un informe de ResearchAndMarkets, "El mercado mundial de aplicaciones inteligentes fue de USD 8390 millones en 2017 y se prevé que alcance los USD 93,400 millones para 2026, con una CAGR del 30,7 % durante el período de pronóstico". en tecnología para implementar nuevos productos y el aumento en el mercado de big data y análisis están impulsando el crecimiento de las aplicaciones inteligentes. Profundizar la aceptación en las economías en desarrollo ofrece importantes oportunidades para la expansión del mercado.

　　Este informe resume los requisitos de las aplicaciones inteligentes, podemos evaluar las tendencias futuras, los requisitos de prueba solo aumentarán. También existe una necesidad creciente de probar de manera efectiva estas aplicaciones en cuanto a precisión, rendimiento, seguridad, funcionalidad y todo lo que se base en los requisitos.

　　5. Ingeniería de rendimiento, no solo pruebas de rendimiento

　　Asegurarse de que su aplicación o software funcione como se espera en condiciones cambiantes o desafiantes es siempre una consideración importante. Las pruebas de rendimiento siempre han sido un aspecto clave de las pruebas de software y, a medida que se desarrolla la tendencia, las pruebas de rendimiento eventualmente cambiarán a la ingeniería de rendimiento. La atención se centrará principalmente en todos los factores que pueden garantizar el rendimiento, la seguridad, la disponibilidad, la compatibilidad de la red, etc., todos los cuales deben estar comprometidos con la entrega de aplicaciones de alta calidad para satisfacer las crecientes demandas de los clientes.

　　Incluso en los próximos años, la necesidad y el papel de las pruebas de software solo se volverán más prominentes, y los desafíos en términos de tecnología y entorno digital aumentarán aún más. Por lo tanto, es igualmente importante que la necesidad de pruebas de software y garantía de calidad siga siendo relevante en estos entornos cambiantes.

 Ruta de aprendizaje de pruebas de software

Mapa de planificación de aprendizaje: los amigos que están estudiando y haciendo pruebas pueden hacer clic en la tarjeta pequeña a continuación
https://jq.qq.com/?_wv=1027&k=3T9tmL0t https://jq.qq.com/?_wv=1027&k=3T9tmL0t

 

1. Modelo de prueba y software

El modelo de ciclo de vida del desarrollo de software se refiere al marco estructural de todo el proceso, actividades y tareas del desarrollo de software. El desarrollo de un proyecto de software incluye etapas como requisitos, diseño, codificación, prueba, estabilización, implementación y mantenimiento.

Los modelos comunes de desarrollo de software incluyen el modelo en cascada, el desarrollo iterativo, el desarrollo en espiral y el desarrollo ágil.

1 modelo de cascada

El modelo en cascada es el método predictivo más típico, que sigue estrictamente la secuencia planificada previamente de análisis, diseño, codificación, integración, prueba y mantenimiento de requisitos. Los resultados de los pasos como un medio para medir el progreso, como especificaciones de requisitos, documentos de diseño, planes de prueba y revisiones de código, entre otros. La cascada tiene principalmente los siguientes problemas:

1. La división de cada etapa es completamente fija, y se genera una gran cantidad de documentos entre etapas, lo que aumenta mucho la carga de trabajo;
2. Dado que el modelo de desarrollo es lineal, los usuarios solo pueden ver los resultados del desarrollo hasta el final de todo el proceso, lo que aumenta el riesgo de desarrollo;
3. Es posible que los primeros errores no se descubran hasta más adelante en el desarrollo durante la fase de prueba, con graves consecuencias.

Por lo tanto, un enfoque en cascada es en gran medida inviable cuando los requisitos son desconocidos y pueden cambiar durante el curso del proyecto.

2 modelo de desarrollo iterativo

El desarrollo iterativo es un proceso de desarrollo de software que es lo opuesto al desarrollo en cascada tradicional y tiene una mayor tasa de éxito y productividad. En el desarrollo iterativo, todo el trabajo de desarrollo se organiza como una serie de pequeños proyectos cortos y de duración fija (como 3 semanas), que se completan paso a paso, por lo que es iterativo. Cada iteración incluye análisis de requisitos, diseño, implementación y pruebas. Con este método, el trabajo de desarrollo se puede iniciar antes de que se determinen por completo los requisitos, y el desarrollo de una parte de las funciones del sistema o la lógica comercial se puede completar en una sola iteración. Luego, utilice los comentarios de los clientes para perfeccionar los requisitos y comenzar una nueva ronda de iteraciones. El desarrollo iterativo tiene las siguientes ventajas:

1. reducir el riesgo. Si un desarrollador repite una iteración, la pérdida es solo el costo de esa iteración que se desarrolló incorrectamente.
2. Adaptarse a las necesidades cambiantes. Dado que las necesidades de los usuarios no están completamente definidas al principio, generalmente se refinan en etapas posteriores.
3. Las pruebas e integración continuas reducen la carga de trabajo y los riesgos en la etapa posterior.

3 Modelo de desarrollo en espiral

El desarrollo en espiral, que combina el modelo en cascada y el modelo de creación rápida de prototipos, enfatiza el análisis de riesgos que otros modelos ignoran y es especialmente adecuado para sistemas grandes y complejos. El "modelo en espiral" comienza pequeño y se desarrolla gradualmente a medida que el proyecto se vuelve más definido y más estable. El núcleo del "modelo en espiral" es que no es necesario definir todo claramente al principio. Vaya con calma, defina la característica más importante, impleméntela y escuche a sus clientes antes de pasar a la siguiente etapa. Repita este ciclo hasta que obtenga el producto final con el que esté satisfecho. El desarrollo en espiral se divide en las siguientes cuatro fases:

1. Haga un plan: determine el objetivo del software, seleccione el plan de implementación y aclare las limitaciones del desarrollo del proyecto;
2. Análisis de riesgos: analizar y evaluar las opciones seleccionadas, y considerar cómo identificar y eliminar riesgos;
3. Ingeniería de implementación: implementación de desarrollo y verificación de software;
4. Evaluación del cliente: evalúe el trabajo de desarrollo, haga sugerencias para las correcciones y formule planes para el próximo paso.

Una etapa es primero determinar los objetivos de esta etapa, completar la selección de estos objetivos y sus limitaciones, y luego analizar la estrategia de desarrollo del plan desde la perspectiva del riesgo, tratar de eliminar varios riesgos potenciales y, a veces, debe ser se completa con la construcción de un prototipo. Si no se pueden descartar ciertos riesgos, el programa finaliza inmediatamente; de ​​lo contrario, se inicia el siguiente paso de desarrollo. Finalmente, evaluar los resultados de esta fase y diseñar la siguiente fase.

4 Modelo de desarrollo ágil

El desarrollo ágil es un nuevo tipo de método de desarrollo de software que gradualmente ha atraído una atención generalizada desde la década de 1990. Es una capacidad de desarrollo de software que responde a necesidades que cambian rápidamente. En relación con "no ágil", se pone más énfasis en la estrecha colaboración entre los equipos de programadores y los expertos en negocios, la comunicación cara a cara (considerada más efectiva que los documentos escritos), la entrega frecuente de nuevas versiones de software, equipos compactos y autoorganizados. , capaz de Un enfoque de la codificación y la organización del equipo que se adapta bien a los cambios en los requisitos y también presta más atención al papel de las personas en el desarrollo de software.

1. Individuos e interacciones sobre procesos y herramientas.
2. El software de trabajo es más importante que la documentación completa y completa.
3. Colaboración con el cliente sobre la negociación del contrato.
4. Responder al cambio es más importante que seguir un plan.

Aunque el contenido de la derecha tiene su valor, el contenido de la izquierda es el más importante. El personal tiene confianza entre sí, hay pocas personas pero capaces, y pueden comunicarse cara a cara.

Los principales métodos de trabajo del equipo de desarrollo ágil se pueden resumir en: trabajar como un todo; trabajar en un ciclo de iteración corto; entregar algunos resultados en cada iteración; centrarse en la prioridad del negocio; inspección y ajuste.

Quizás el factor más importante es el tamaño del proyecto. La comunicación cara a cara se vuelve más difícil a medida que aumenta el tamaño, por lo que los métodos ágiles son más adecuados para equipos más pequeños, 40, 30, 20, 10 personas o menos.

5 Comparación de cuatro modelos

El desarrollo en cascada tradicional, es decir, desde los requisitos hasta el diseño, desde el diseño hasta la codificación, desde la codificación hasta las pruebas, desde las pruebas hasta el envío, requiere lo mejor en cada etapa de desarrollo. Especialmente en la etapa inicial, cuanto más perfecto sea el diseño, menor será la pérdida de costos después de la presentación.

El desarrollo iterativo no requiere que las tareas en cada etapa sean las más perfectas, pero claramente sabe que aún hay muchas deficiencias, pero no lo mejora, sino que construye las funciones principales primero, con el más corto Completa un "producto imperfecto" con el menor pérdida en el menor tiempo hasta su presentación. Luego, en función de la información de los comentarios de los clientes o usuarios, mejoraremos gradualmente este "producto imperfecto".

El desarrollo en espiral es, en gran medida, una metodología impulsada por el riesgo, ya que primero se debe realizar una evaluación del riesgo antes de cada fase y, a menudo, antes de que ocurra el ciclo.

El desarrollo ágil, en comparación con el desarrollo iterativo, enfatiza el envío de software en un ciclo de desarrollo más corto, pero el ciclo de desarrollo ágil puede ser más corto y enfatiza más el alto grado de colaboración en el equipo. Los métodos ágiles a veces se confunden con métodos no planificados y disciplinados, cuando en realidad es más exacto decir que los métodos ágiles enfatizan la adaptabilidad en lugar de la previsibilidad.

Los enfoques adaptativos se centran en adaptarse rápidamente a los cambios en la realidad. Cuando las necesidades del proyecto cambian, el equipo debe adaptarse rápidamente. Puede ser difícil para el equipo describir exactamente cómo cambiará el futuro.

6 Pruebas durante el desarrollo de software

En el proceso de desarrollo de software descrito anteriormente, las pruebas son una parte importante. Especialmente para proyectos de mediana y gran escala, desde el comienzo del proyecto, es necesario formular un plan de prueba, probar los requisitos, diseñar pruebas y casos de prueba, ejecutar la prueba y finalmente resumir y analizar los resultados de la prueba. Cuanto antes se descubra un defecto de software, menos costoso será reparar el defecto de software.

La idea de TDD (Test Driven Development) es promover todo el desarrollo a través de pruebas.Antes de desarrollar el código, escriba primero el código de prueba. Una vez que esté claro desarrollar una determinada función, primero piense en cómo probar esta función y complete la escritura del código de prueba, y luego escriba el código relevante para cumplir con estos casos de prueba. Además, las actividades de prueba de software se ejecutan a lo largo de todo el ciclo de vida del desarrollo de software.

7 Propósito y principios de las pruebas de software

Definición de prueba: El proceso de operar o probar un sistema por medios manuales o automatizados para comprobar que cumple con los requisitos especificados o para aclarar la diferencia entre los resultados esperados y los reales.

El propósito de las pruebas de software: encontrar errores en el programa y garantizar la calidad final de los productos de software.

1. La prueba es la ejecución de un programa para encontrar errores.
2. Un caso de prueba exitoso consiste en encontrar errores no descubiertos hasta ahora
3. Una prueba exitosa es aquella que encuentra un error no descubierto hasta ahora.
4. Asegúrese de que el producto haga lo que promete o anuncia, y que las funciones a las que pueden acceder los usuarios estén claramente documentadas.
5. Asegúrese de que los productos cumplan con los requisitos de rendimiento y eficiencia.
6. Asegúrese de que el producto sea robusto y adaptable al entorno del usuario

Principios de las pruebas de software:

1. Una parte obligatoria de un caso de prueba es la definición de la salida o interfaz esperada
2. Los programadores deben evitar probar los programas que escriben
3. Las organizaciones que escriben software no deben probar el software que escriben
4. Los resultados de ejecución de cada prueba deben verificarse minuciosamente.
5. Los casos de prueba deben escribirse no solo para entradas válidas y esperadas, sino también para entradas no válidas e inesperadas.
6. Comprobar que el programa "no hace lo que se supone que debe hacer" es solo la mitad de la prueba, la otra mitad de la prueba es comprobar que el programa "hace lo que se supone que no debe hacer"
7. Se deben evitar los casos de prueba desechables a menos que el software en sí sea un software de un solo uso
8. Al planificar un esfuerzo de prueba, no se debe suponer tácitamente que no se encontrarán errores
9. La probabilidad de que una parte de un programa tenga más errores, proporcional al número de errores ya encontrados en esa parte

8 Capacidad de prueba del software

Una capacidad de prueba demasiado pobre del software hará que la prueba sea bastante difícil o incluso imposible. Esta situación a menudo es causada por un diseño de arquitectura de software extremadamente pobre y un trabajo de desarrollo de software extremadamente irregular.

1. Estrechamente acoplado. No puede probar sin instanciar la mayor parte del sistema.
2. Cohesión débil. Esta clase implementa demasiadas funciones, lo que hace que la prueba sea muy complicada.
3. redundancia. El mismo método se usa en varios lugares y cada lugar se prueba.

Una buena arquitectura de software debe estar débilmente acoplada y ser altamente cohesiva. Al tiempo que mejora la capacidad de prueba del software, también mejora la mantenibilidad y la capacidad de administración del software.

2. Diseño de casos de prueba

Un caso de prueba es un conjunto de entradas de prueba, condiciones de ejecución y resultados esperados diseñados para un propósito específico. Un caso de prueba es la entidad más pequeña para ejecutar. En pocas palabras, un caso de prueba es diseñar un escenario para que el programa de software pueda ejecutarse normalmente y lograr los resultados de ejecución diseñados por el programa en este escenario.

1 Prueba de caja negra y prueba de caja blanca

Pruebas de caja negra: conociendo las especificaciones de diseño funcional del producto, se pueden realizar pruebas para comprobar si cada función implementada cumple con los requisitos. Pruebas de caja blanca: al conocer el proceso de trabajo interno del producto, se pueden realizar pruebas para comprobar si cada operación interna cumple con los requisitos de especificación de diseño y si se han verificado todos los componentes internos.

Una buena estrategia de prueba es combinar estos dos elementos de prueba. Podemos diseñar una prueba bastante rigurosa usando un método de diseño de caso de prueba orientado a prueba de caja negra específico, y luego usar el método de prueba de caja blanca para verificar la estructura lógica del programa para complementar estos casos de prueba.

Los métodos de prueba de caja blanca incluyen cobertura de declaración, cobertura de decisión, cobertura de condición, cobertura de decisión/condición, cobertura de combinación de condición y cobertura de ruta. Los métodos de prueba de caja negra incluyen partición de clase de equivalencia, análisis de valor límite, análisis de diagrama causal, prueba de error, diagramas de estado y métodos de escenario.

2 Diseño de caso de prueba de caja blanca

Las pruebas de caja blanca se ocupan del grado en que los casos de prueba ejecutan o cubren la estructura lógica del programa (código fuente). Una prueba de caja blanca completa consiste en ejecutar todas las rutas del programa. Sin embargo, para un programa con bucles, una prueba de ruta completa no es práctica. Las características de las pruebas de caja blanca: pruebas de acuerdo con la especificación de diseño del software, inspección rigurosa de los detalles internos del programa, diseño de casos de prueba para condiciones específicas y pruebas de cobertura de la ruta lógica del software.

La cobertura de declaraciones es el requisito mínimo de cobertura estructural.La cobertura de declaraciones requiere diseñar suficientes casos de prueba para que cada declaración en el programa se ejecute al menos una vez. Los casos de prueba se pueden obtener del código fuente de forma muy intuitiva sin subdividir cada expresión de juicio. Dado que este método de prueba solo está dirigido a las declaraciones que existen explícitamente en la lógica del programa, no puede probar las condiciones ocultas y las posibles ramas lógicas implícitas. (faltan ramas lógicas ocultas)

La cobertura de decisiones requiere que se escriban suficientes casos de prueba para que cada juicio tenga al menos una salida que sea "verdadero" y "falso". La cobertura de decisiones tiene casi el doble de rutas de prueba que la cobertura de declaraciones y, por supuesto, tiene capacidades de prueba más sólidas que la cobertura de declaraciones. De manera similar, la cobertura de decisiones tiene la misma simplicidad que la cobertura de sentencias y los casos de prueba se pueden obtener sin subdividir cada decisión. La mayoría de las declaraciones de decisión a menudo se componen de múltiples condiciones lógicas (por ejemplo, la declaración de decisión contiene Y, O, CASO). Si solo juzga el resultado final completo e ignora el valor de cada condición, inevitablemente perderá parte de la ruta de prueba (Algunos valores condicionales en el juicio de combinaciones faltantes)

La cobertura de condiciones requiere el diseño de suficientes casos de prueba para que cada condición en la decisión pueda obtener varios resultados posibles, es decir, cada condición es verdadera al menos una vez y falsa una vez. Para lograr la cobertura condicional, se necesitan suficientes casos de prueba, pero la cobertura condicional no garantiza la cobertura de decisiones. La cobertura de condiciones solo puede garantizar que cada condición sea verdadera al menos una vez, independientemente de todos los resultados del juicio .

La cobertura de decisión/condición requiere el diseño de suficientes casos de prueba para que todos los posibles resultados de cada condición en la decisión aparezcan al menos una vez, y todos los posibles resultados de cada decisión en sí aparezcan al menos una vez. La cobertura de decisión/condición satisface el criterio de cobertura de decisión y el criterio de cobertura de condición, y compensa la deficiencia de los dos. La desventaja del criterio de cobertura de decisión/condición es que no tiene en cuenta la combinación de condiciones .

La cobertura de condiciones múltiples requiere el diseño de suficientes casos de prueba para que todas las combinaciones posibles de resultados de condiciones en cada decisión ocurran al menos una vez. Los criterios de cobertura de múltiples condiciones satisfacen los criterios de cobertura de decisión, cobertura de condición y cobertura de decisión/condición. La cobertura de decisión/condición cambiada requiere que se diseñen suficientes casos de prueba de modo que todos los resultados posibles de cada condición en una decisión ocurran al menos una vez, y todos los resultados posibles de cada decisión en sí ocurran al menos una vez. Y cada condición muestra que puede afectar el resultado del juicio de forma independiente. La desventaja es que el número de casos de prueba aumenta linealmente.

La cobertura de ruta requiere diseñar suficientes casos de prueba para cubrir todas las rutas posibles en el programa. Dado que la cobertura de ruta necesita probar todas las rutas posibles (incluidos bucles, combinaciones condicionales, selección de rama, etc.), es necesario diseñar una gran cantidad de casos de prueba complejos, lo que hace que la carga de trabajo aumente exponencialmente. En algunos casos, algunas rutas de ejecución son imposibles de ejecutar, lo que no solo reduce la eficiencia de la prueba, sino que también genera problemas para la resolución de problemas debido a la acumulación de una gran cantidad de resultados de prueba.

3 Diseño de caso de prueba de caja negra

(1) División de clase de equivalencia

La división de clases de equivalencia consiste en dividir todos los datos de entrada posibles, es decir, el dominio de entrada del programa en varias partes (subconjuntos), y luego seleccionar una pequeña cantidad de datos representativos de cada subconjunto como casos de prueba. Las clases de equivalencia se dividen en clases de equivalencia efectiva y clases de equivalencia no válida. Las clases de equivalencia efectiva se refieren al conjunto de datos de entrada que son razonables y significativos para la especificación del programa. Las clases de equivalencia no válida se refieren a No es razonable para la especificación del programa. una colección de datos de entrada que no tiene sentido. Al diseñar casos de prueba, se deben considerar ambas clases de equivalencia. Debido a que el software no solo debe recibir datos razonables, sino también ser capaz de resistir pruebas inesperadas, dichas pruebas pueden garantizar que el software tenga una mayor confiabilidad. La división de clases de equivalencia tiene los siguientes principios:

1. Cuando la condición de entrada estipula el rango de valores o el número de valores, se puede establecer una clase de equivalencia válida y dos clases de equivalencia no válida. Por ejemplo: el valor de entrada son las calificaciones de los estudiantes y el rango es de 0 a 100; la clase de equivalencia inferior a 0 y superior a 100 es una clase de equivalencia no válida, y la clase de equivalencia entre 0 y 100 es una clase de equivalencia válida.
2. Cuando una condición de entrada especifica un conjunto de valores de entrada o especifica una condición "debe ser", se puede establecer una clase de equivalencia válida y una clase de equivalencia no válida.
3. En el caso de que la condición de entrada sea una cantidad booleana, se puede determinar una clase de equivalencia válida y una clase de equivalencia no válida.
4. En el caso de que se especifique un conjunto de valores de datos de entrada (suponiendo n), y el programa trate cada valor de entrada por separado, se pueden establecer n clases de equivalencia efectivas y una clase de equivalencia no válida. Ejemplo: las condiciones de entrada indican que la formación académica puede ser de uno de los cuatro tipos: junior college, pregrado, maestría y doctorado, luego estos cuatro valores se toman como las cuatro clases de equivalencia efectivas, y cualquier formación académica distinta de las cuatro tipos de antecedentes educativos se utiliza como clase de equivalencia no válida.
5. En el caso de que se estipulen las reglas que deben cumplir los datos de entrada, se puede establecer una clase de equivalencia válida (conforme a las reglas) y varias clases de equivalencia inválidas (violando las reglas desde diferentes ángulos);
6. Si se sabe que cada elemento de la clase de equivalencia dividida se procesa de forma diferente en el programa, la clase de equivalencia debe dividirse en clases de equivalencia más pequeñas.

Una vez que se establece la clase de equivalencia, se puede establecer una tabla de clases de equivalencia para enumerar todas las condiciones de entrada de la clase de equivalencia dividida: clase de equivalencia válida, clase de equivalencia no válida y luego de la clase de equivalencia dividida de acuerdo con los siguientes casos de prueba de diseño de tres principios:

1. Especifique un número único para cada clase de equivalencia;
2. Diseñe un nuevo caso de prueba para que cubra la mayor cantidad posible de clases de equivalencia efectiva que no se han cubierto, y repita este paso hasta que se cubran todas las clases de equivalencia efectiva;
3. Diseñe un nuevo caso de prueba para que cubra solo una clase de equivalencia no válida que no se haya cubierto, y repita este paso hasta que se cubran todas las clases de equivalencia no válidas.

(2) Análisis de valor límite

El análisis de valor límite es un método de prueba de caja negra para probar el valor límite de entrada o salida. Por lo general, el método de análisis de valor límite se utiliza como complemento del método de partición de clases de equivalencia.En este caso, los casos de prueba provienen del límite de la clase de equivalencia. El análisis del valor límite no consiste en elegir aleatoriamente uno de una clase de equivalencia como representante, sino en hacer de cada límite de esta clase de equivalencia una condición de prueba. El análisis de valor límite considera no solo las condiciones de entrada, sino también los casos de prueba generados por el espacio de salida.

La experiencia laboral de pruebas a largo plazo nos dice que una gran cantidad de errores ocurren en el límite del rango de entrada o salida, en lugar de dentro del rango de entrada y salida. Por lo tanto, el diseño de casos de prueba para varios casos extremos puede detectar más errores. Para diseñar casos de prueba utilizando el método de análisis de valor límite, primero se deben identificar los casos límite. Por lo general, los límites de las clases de equivalencia de entrada y salida son los casos límite que deben probarse enfáticamente. Los valores que son exactamente iguales, apenas mayores o apenas menores que el límite deben seleccionarse como datos de prueba, en lugar de valores típicos o valores arbitrarios en la clase de equivalencia como datos de prueba.

(3) Diagrama causal

El diagrama de causa y efecto es un método para diseñar casos de prueba mediante el análisis de varias combinaciones de entradas mediante un método gráfico, que es adecuado para verificar varias combinaciones de condiciones de entrada del programa.

Tanto el método de división de clase de equivalencia como el método de análisis de valor límite se centran en considerar las condiciones de entrada, pero no consideran las diversas combinaciones de condiciones de entrada y las restricciones mutuas entre las condiciones de entrada. De esta forma, aunque se han probado los posibles errores de varias condiciones de entrada, se han ignorado los posibles errores de una combinación de múltiples condiciones de entrada. Si se deben considerar varias combinaciones de condiciones de entrada durante la prueba, el número de combinaciones posibles será astronómico, por lo que es necesario considerar el uso de un formulario adecuado para describir una combinación de varias condiciones y, en consecuencia, generar múltiples acciones para llevar a cabo casos de prueba. Diseño, que requiere el uso de diagramas causales (modelos lógicos).

(4) Prueba de error

La prueba de errores es un método de especulación de todos los posibles errores en el programa basado en la experiencia y la intuición, a fin de diseñar casos de prueba de manera específica.

Por ejemplo, si está probando un programa que ordena una lista lineal (como una matriz), puede especular que los siguientes elementos necesitan una prueba especial:

1. La tabla lineal de entrada es una tabla vacía;
2. La tabla contiene solo un elemento;
3. Todos los elementos de la tabla de entrada están ordenados;
4. La tabla de entrada se ordena en orden inverso;
5. Algunos o todos los elementos de la tabla de entrada son iguales.

4 Estrategia integral para el diseño de casos de prueba

Myers propone una estrategia integral utilizando varios métodos de prueba:

1. En cualquier caso, se debe utilizar el método de análisis de valor límite.La experiencia ha demostrado que el uso de este método para diseñar casos de prueba tiene la mayor capacidad para encontrar errores de programa.
2. Complemente algunos casos de prueba con el método de división de clases de equivalencia si es necesario.
3. Agregue algunos casos de prueba más por error de adivinación.
4. Verifique la cobertura lógica de los casos de prueba diseñados contra la lógica del programa. Si no se cumple el estándar de cobertura requerido, agregue suficientes casos de prueba.
5. Si la descripción de la función del programa contiene la combinación de condiciones de entrada, el método del diagrama de causa y efecto se puede utilizar desde el principio.

Pasos de diseño de casos de prueba: 1) Construir casos de prueba de función básica basados ​​en especificaciones de diseño; 2) Casos de prueba de valor límite; 3) Casos de prueba de transición de estado; 4) Casos de prueba de adivinación de errores; 5) Casos de prueba anormales; 6) Casos de prueba de rendimiento 7) Casos de prueba de estrés.

3. Tipos de pruebas de software

prueba de unidad

Las pruebas unitarias no prueban todo el programa, sino los módulos más pequeños que componen el programa. Las pruebas unitarias reducen la dificultad de la depuración (una vez que se encuentra un determinado error, sabemos en qué módulo específico se encuentra); las pruebas unitarias brindan la posibilidad de probar varios módulos al mismo tiempo e introduce la ingeniería paralela en las pruebas de software.

Cuando se diseñan casos de prueba para pruebas unitarias de módulos, se utilizan dos tipos de información: la especificación del módulo y el código fuente del módulo. Una especificación generalmente especifica los parámetros de entrada y salida de un bloque y la funcionalidad del bloque. Las pruebas unitarias generalmente están orientadas hacia las pruebas de caja blanca, por lo tanto, el proceso de diseño de casos de prueba para pruebas unitarias es el siguiente: use uno o más métodos de prueba de caja blanca para analizar la estructura lógica del módulo, y luego use el método de prueba de caja blanca. caja método de prueba para comparar las especificaciones del módulo para complementar los casos de prueba.

Pruebas de integración

Integración de arriba hacia abajo e integración de abajo hacia arriba

prueba de funcionamiento

El propósito de las pruebas funcionales es exponer errores e inconsistencias en el programa, no probar que el programa se ajusta a sus especificaciones externas.

Las pruebas funcionales son un tipo de pruebas de caja negra. Los pasos comunes de las pruebas funcionales son: subdividir los puntos de función de acuerdo con los requisitos, derivar los requisitos de prueba de acuerdo con los puntos de función y diseñar casos de prueba funcionales de acuerdo con los requisitos de prueba.

Prueba del sistema

El propósito de las pruebas del sistema es demostrar que el programa no puede lograr sus objetivos Hay 14 tipos de casos de prueba para las pruebas del sistema:

1. Prueba de capacidad: es para juzgar si cada capacidad (o función) mencionada en el documento de destino realmente se ha realizado.
2. Prueba de volumen: Pruebe el programa contra grandes volúmenes de datos. El propósito de las pruebas de capacidad es demostrar que el programa no puede manejar la capacidad de datos especificada en el documento de destino.
3. Prueba de fuerza: una prueba que somete un programa a una carga o fuerza alta. La llamada alta intensidad se refiere a la cantidad máxima de datos u operaciones alcanzadas en un intervalo de tiempo corto.
4. Pruebas de usabilidad: intentos de encontrar artefactos o problemas de usabilidad.
5. Pruebas de seguridad: el proceso de diseñar casos de prueba para superar las comprobaciones de seguridad del programa. Por ejemplo, podemos diseñar casos de prueba para eludir el mecanismo de protección de memoria del sistema operativo y destruir el mecanismo de seguridad de datos del sistema de administración de bases de datos.
6. Pruebas de rendimiento: muchos programas tienen objetivos específicos de rendimiento o eficiencia, que se caracterizan por el tiempo de respuesta y el rendimiento del programa en un entorno de carga y configuración específicos.
7. Prueba de almacenamiento:
8. Configurar prueba:
9. Pruebas de compatibilidad.
10. Prueba de instalación: el proceso de instalación de algunos tipos de sistemas de software es muy complicado, y probar el proceso de instalación es una parte importante de las pruebas del sistema. Esto es especialmente importante para los sistemas de instalación automatizados incluidos en los paquetes de software. Si el instalador falla, puede afectar la experiencia satisfactoria del usuario con el software.
11. Pruebas de confiabilidad: todos los tipos de pruebas tienen como objetivo mejorar la confiabilidad del software, pero si el objetivo del software contiene una descripción especial de la confiabilidad, se debe diseñar una prueba de confiabilidad especial.
12. Pruebas de capacidad de recuperación: el software, como los sistemas operativos, los sistemas de administración de bases de datos y los sistemas de teleprocesamiento, a menudo tienen objetivos de capacidad de recuperación que describen cómo se recupera el sistema de errores de programa, fallas de hardware y errores de datos. Uno de los objetivos de las pruebas del sistema es demostrar que estos mecanismos de recuperación no funcionan correctamente. Podemos programar errores intencionalmente en un sistema y determinar si el sistema puede recuperarse.
13. Prueba de aplicabilidad
14. Pruebas de documentación: compruebe la corrección de la documentación del usuario. La documentación del usuario debe ser objeto de una revisión de corrección y claridad. Cualquier ejemplo descrito en la documentación debe compilarse en casos de prueba y enviarse al programa.

4. Pruebas automatizadas

Pruebas automatizadas: pruebe programas con programas, reemplace el pensamiento con códigos y reemplace las pruebas manuales con scripts.

Prueba de humo: cuando salga una nueva versión, revise todas las funciones del software para ver si hay algún problema importante. Si la función puede ejecutarse normalmente y no afectará el proceso de prueba, entonces esta versión realmente puede comenzar a probar. Si la funcionalidad tiene problemas importantes o afecta el proceso de prueba, entonces esta versión no está calificada y no se requieren más pruebas. Por ejemplo, si obtiene una nueva versión de la aplicación QQ y ni siquiera puede iniciar sesión, entonces esta versión definitivamente no podrá continuar con la prueba. O bien, aparece un nuevo módulo en el juego, pero el nuevo módulo siempre falla, se congela y la prueba no puede continuar, por lo que el resultado de fumar no está calificado.

Prueba de regresión: Es para verificar si los errores encontrados en la versión anterior existen en la nueva versión y si se producen nuevos errores.

1 Ventajas de las pruebas automatizadas

1. Las pruebas de regresión son más convenientes y confiables . Dado que las operaciones del proceso comercial y los casos de prueba de la prueba de regresión están prediseñados, y los resultados esperados están completamente en manos del personal del proyecto, entregar la prueba de regresión a la computadora para la operación automática puede mejorar en gran medida la eficiencia de la prueba y acortar el tiempo. tiempo de prueba de regresión.
2. Ejecute pruebas cada vez más tediosas de forma rápida y eficiente.
3. Se pueden realizar algunas pruebas que serían difíciles o imposibles de hacer manualmente. Por ejemplo, pruebas simultáneas de un gran número de usuarios, etc.
4. Caracterizado por la consistencia y la repetibilidad .
5. Los scripts de prueba automatizados son totalmente reutilizables . Dado que las pruebas automatizadas generalmente se implementan en forma de secuencias de comandos, entre diferentes versiones, es posible que solo necesite realizar una pequeña cantidad de mantenimiento o incluso ninguna modificación, de modo que la misma secuencia de comandos de prueba se pueda usar para ejecutar el mismo caso de prueba en diferentes pruebas. versiones.

2 Desventajas de las pruebas automatizadas

1. Nunca será posible reemplazar por completo las pruebas manuales. Las pruebas automatizadas no pueden lograr la cobertura de las pruebas manuales, y no todos los casos de prueba son adecuados para convertirlos en casos de prueba automatizados.
2. No se puede garantizar la exactitud de las pruebas. El script de prueba en sí mismo también puede tener fallas.
3. Las pruebas manuales pueden encontrar muchos más defectos que las pruebas automatizadas. Las pruebas automatizadas son casi imposibles de encontrar nuevos defectos.
4. Las herramientas de prueba automatizadas están muertas, sin imaginación en sí mismas.
5. Las pruebas automatizadas deben tener una cierta formación técnica de desarrollo para los ingenieros de pruebas.

3 Cuándo introducir pruebas automatizadas

1. El ciclo del proyecto es largo y la versión del sistema es constante. Principalmente en pruebas de regresión.
2. Los requisitos cambian con poca frecuencia.
3. Los objetos de prueba en el sistema básicamente se pueden identificar normalmente y no hay grandes cantidades de controles de terceros.
4. Se requieren pruebas repetidas, como las pruebas de confiabilidad que requieren miles de pruebas del sistema.

4 Cuándo evitar las pruebas automatizadas

1. El ciclo del proyecto es corto y los requisitos cambian con frecuencia. La introducción de pruebas automatizadas cuando el ciclo del proyecto es corto no solo no permitirá recuperar el costo, sino que también prolongará el tiempo de lanzamiento del producto. Los cambios frecuentes en los requisitos harán que se modifique la lógica comercial de las funciones antiguas, lo que resultará en la necesidad de modificar los scripts de prueba correspondientes.
2. La versión del software aún no es estable.
3. La mayoría de los objetos no se reconocen y el mantenimiento de scripts es frecuente y difícil.

5 Diseño de casos de prueba automatizados

Durante el proceso de prueba del proyecto, el ingeniero de prueba primero analizará los requisitos de prueba, producirá un plan de prueba, escribirá y diseñará casos de prueba y diseñará y desarrollará guiones de prueba.

1. El alcance de los casos de prueba automatizados suele ser el proceso comercial central o una alta tasa de repetición. No es necesario cubrir todos los casos de prueba manual.
2. La selección de casos de prueba automatizados generalmente se basa en "positivo". La situación normal es "adelante" y la situación anormal es "reversa". Las pruebas de automatización funcional se utilizan principalmente para las pruebas de regresión. El propósito de las pruebas de regresión es garantizar que las funciones antiguas puedan funcionar normalmente después de que se agreguen funciones nuevas.
3. Los casos de prueba manuales no necesitan volver al origen, pero los casos de prueba automatizados a menudo son necesarios. El llamado regreso al origen significa que el caso de prueba ejecutado finalmente necesita restaurar su estado inicial antes de la ejecución. Por ejemplo, la función de agregar un usuario, debido a que el nombre de usuario es único, no hay problema en la primera ejecución, pero en la segunda ejecución, el programa tendrá un nombre de usuario duplicado y reportará un error; en este caso, es necesario agregar y eliminar esto al final de los pasos del usuario del caso de prueba automatizado.
4. A diferencia de los casos de prueba manuales, los casos de prueba automatizados no necesitan escribir los resultados esperados para cada paso.

5. Redacción de documentos de prueba y gestión de defectos.

Los documentos de prueba incluyen: documentos de plan de prueba, documentos de especificación de diseño de prueba, casos de prueba, informes de defectos de software, informes de estado.

El caso de prueba describe la tarea de prueba de un producto de software específico, reflejando el plan de prueba, el método, la tecnología y la estrategia. Los contenidos incluyen objetivos de prueba, entorno de prueba, datos de entrada, pasos de prueba, resultados esperados, guiones de prueba, etc., y documentos de formulario. Los casos de prueba generalmente incluyen casos de prueba de verificación y casos de prueba de falsificación; los casos de prueba de verificación se utilizan para verificar si el código se ejecuta como se esperaba y se obtienen los resultados esperados; los casos de prueba de falsificación verifican si el código maneja adecuadamente las excepciones y las condiciones de error.

El informe de defectos incluye: una breve descripción del problema/error, requisitos de configuración del entorno recurrente, entradas específicas para garantizar múltiples repeticiones precisas, comparación entre los resultados esperados y los resultados reales, prioridad y gravedad, impacto en los clientes, etc.

6. Herramientas de prueba de uso común

1 Prueba Funcional UFT

El principio de las pruebas automatizadas de UFT

1. Encapsule el objeto medido real y conviértalo en un objeto UFT y envíelo a la biblioteca de objetos.
2. Compare las propiedades de identificación de objetos en la biblioteca de objetos con las propiedades de identificación del objeto real bajo prueba en tiempo de ejecución.
3. Si los resultados de la comparación son consistentes, significa que el objeto se empareja correctamente y puede continuar realizando operaciones de seguimiento en el objeto real bajo prueba; si son inconsistentes, se informará un error que indica que el objeto no se puede reconocer .

modelo de objeto encapsulado

El objeto de paquete en UFT se divide en dos conceptos, objetos de prueba (objeto de prueba, TO) y objetos de tiempo de ejecución (objeto de tiempo de ejecución, RO). TO es el objeto que se agrega a la biblioteca de objetos, y RO es el objeto que realmente ejecuta el software bajo prueba. Todos son objetos encapsulados por UFT, y TO existe para identificar RO.

Por lo general, UFT agrega primero los objetos de prueba en la biblioteca de objetos y luego busca los objetos de prueba correspondientes en la biblioteca de objetos de acuerdo con el nombre del objeto llamado en el script cuando se ejecuta el software bajo prueba. , y finalmente operar en estos objetos de prueba que realmente se ejecutan.

GetTOProperty()
Significado básico: Obtener el valor de una propiedad de un objeto en la biblioteca de objetos.
Fórmula: ReturnValue = object.GetTOProperty("nombre de propiedad de encapsulación")

SetTOProperty()
Significado básico: establece el valor de una propiedad de un objeto en la biblioteca de objetos.
Fórmula: objeto.SetTOProperty "nombre de propiedad encapsulado" "valor de propiedad encapsulado"
Nota: La modificación de las propiedades del objeto en forma de código es temporal y solo es válida cuando se ejecuta el script. Una vez que el script termina de ejecutarse, los valores de propiedad en el objeto la biblioteca será restaurada.

El significado básico de GetROProperty()
: Obtener el valor de una propiedad de un objeto en tiempo de ejecución real.
Fórmula: ReturnValue = object.GetROProperty("nombre de propiedad de encapsulación")
Nota: Use el método GetROProperty para obtener dinámicamente información de confirmación durante la operación real y luego compárela con los datos de prueba esperados. Como la función de registro, después de enviar cierta información de registro, generalmente es necesario ir a la siguiente página de confirmación para verificar alguna información, por lo que puede usar GetROProperty para obtener dinámicamente cierta información de confirmación durante la operación real.

La solución a los objetos no reconocidos

1. Coloca objetos ficticios. No recomendado, el objeto virtual es muy frágil y difícil de mantener; incluso si el objeto no cambia, mientras el objeto cambie en la dirección de la interfaz, el objeto virtual no podrá ser reconocido.
2. Use coordenadas relativas con WSH para posicionar objetos.
3. Utilice DOM para crear tecnología de aplicaciones de interfaz. Se aplica solo a proyectos web.
4. Utilice la extensión personalizada SDK Customer de UFT para el desarrollo secundario a fin de permitir que UFT reconozca objetos. Dificultad alta.
5. Desarrolle y proporcione complementos exclusivos.
6. Encapsule algunos métodos de objetos no reconocidos en un dll y use UFT para llamarlos.

Restauración de escena y basada en datos

Aplicación de la tabla de datos basada en datos: realice la separación de los datos de prueba y el negocio de secuencias de comandos.
Recuperación de escenas: la recuperación de escenas puede tratar varios tipos de errores y realizar operaciones de recuperación.

2 LoadRunner de prueba de rendimiento

LoadRunner es una herramienta de prueba de carga automatizada para varias arquitecturas que predice el comportamiento del sistema y optimiza el rendimiento del sistema. El objeto de prueba de LoadRunner es el sistema de toda la empresa.Ayuda a los probadores a encontrar y descubrir problemas más rápido mediante la simulación del comportamiento operativo real del usuario y la supervisión del rendimiento en tiempo real.

1. Cree fácilmente usuarios virtuales. Virtual User Generator puede generar usuarios virtuales para simular el comportamiento de operaciones comerciales de usuarios reales en forma de usuarios virtuales. Primero registra el proceso comercial, luego lo convierte en un script de prueba y realiza operaciones parametrizadas (Data Wizard se conecta directamente al servidor de datos para obtener datos). El uso de usuarios virtuales puede generar decenas de miles de accesos de usuarios en diferentes sistemas operativos al mismo tiempo, lo que puede reducir en gran medida el hardware y los recursos humanos necesarios para las pruebas de carga.
2. Crea cargas realistas. Después de crear un usuario virtual, debe configurar el esquema de carga, la combinación de procesos comerciales y la cantidad de usuarios virtuales. El uso de Controller puede organizar rápidamente escenarios de prueba multiusuario.
3. Localización de problemas de rendimiento. LoadRunner incluye un monitor en tiempo real que puede observar el rendimiento operativo del sistema de la aplicación en cualquier momento durante el proceso de prueba de carga.
4. Analiza los resultados. Una vez que se completa la prueba, LoadRunner recopila y resume todos los datos de la prueba y proporciona herramientas avanzadas de análisis e informes para encontrar rápidamente problemas de rendimiento y realizar los ajustes correspondientes.