1. Descripción general de las pruebas de software
1. Defectos de software
Defecto de software: también conocido como "Bug". Un problema, error o defecto funcional oculto en el software de la computadora o un programa que afecta su capacidad para funcionar correctamente.
Manifestaciones de defectos
El software no realiza los módulos funcionales requeridos por la especificación del producto; hay
errores en el software que la especificación del producto indica que no deben ocurrir;
el software realiza los requisitos funcionales no mencionados en la especificación del producto;
el software no realiza que aunque el la especificación del producto no menciona claramente y lo que debe lograr;
el software es difícil de entender, difícil de usar, lento para ejecutar y poco fácil de usar;
Causas de defectos de software
Requisitos poco claros;
estructura del sistema compleja;
consideración incompleta de la ruta lógica del programa o rango de datos;
asegurando una sincronización precisa del tiempo de diseño;
problemas sistémicos y de confiabilidad ocultos;
entorno operativo complejo del sistema;
muchos puertos de comunicación afectan el sistema Seguridad, aplicabilidad;
diseño del sistema técnico problemas de compatibilidad;
propiedades de los defectos
Id. de defecto: Id. único;
Tipo de defecto: Tipo de defecto;
Gravedad del defecto: se refiere al grado de impacto del fallo causado por el defecto en el producto de software;
Prioridad del defecto: se refiere a la urgencia con la que se debe reparar el defecto;
Estado del defecto : A través de un proceso de reparación de seguimiento Origen del defecto
: la etapa en la que se detecta por primera vez la falla o el evento causado por el defecto;
Fuente del defecto: la causa del defecto;
Causa raíz del defecto: de todos modos, la causa raíz del error;
2. Definición y principios de las pruebas de software
Definición: La prueba de software es el proceso de ejecutar un programa o sistema para encontrar errores.
en principio:
Las pruebas revelan la existencia de errores:
no es posible realizar pruebas exhaustivas;
probar lo antes posible;
grupos de defectos: (la regla del 80/20: alrededor del 80 % de los problemas se encuentran en el 20 % de los módulos); la
paradoja de los pesticidas; las
pruebas son contexto sensible
No hay falacias,
la prueba de software es un comportamiento riesgoso;
Al mismo tiempo, también preparé un video tutorial de prueba de software, que se encuentra al final del artículo. Si lo necesita, puede verlo directamente o hacer clic directamente en la pequeña tarjeta al final del artículo para obtener el documento informativo gratis
2. Proceso y estrategia de pruebas de software
1. Descripción general de la estrategia de pruebas de software
Una estrategia de prueba de software es una plantilla de prueba de software para el proceso de ingeniería de software, es decir, una serie de pasos en los que se colocan métodos de casos de prueba específicos:
Características de las pruebas de software.
La prueba comienza a nivel de módulo y luego se expande a toda la colección de sistemas basados en computadora; se
aplican diferentes técnicas de prueba en diferentes puntos en el tiempo;
las pruebas son administradas por desarrolladores y grupos de prueba independientes;
diferentes actividades durante la prueba y la depuración, pero la depuración debe ser capaz de adaptarse a cualquier estrategia de prueba;
Directrices de suficiencia de las pruebas de software
Hay un conjunto finito de pruebas suficientes para cualquier software;
si un sistema de software se prueba adecuadamente en un conjunto de datos de prueba, entonces algunos datos de prueba más deberían ser suficientes;
incluso si todos los componentes del software se prueban por completo, tampoco significa que la prueba de todo el software es suficiente;
incluso si la prueba del sistema de software como un todo es suficiente, no significa que cada componente del sistema de software haya sido completamente probado;
la idoneidad de las pruebas de software está relacionada con los requisitos y la implementación del software están relacionados:
cuanto más complejo es el software, más datos de prueba necesita;
cuanto más se prueba, menos crecimiento en adecuación puede obtener de pruebas adicionales;
2. Clasificación de las pruebas de software
etapas de desarrollo de software
1) Pruebas unitarias:
se refiere a la inspección y verificación de la unidad comprobable más pequeña en el software.Las pruebas unitarias necesitan diseñar casos de prueba basados en la estructura interna del software. Se pueden probar varios módulos de forma independiente.
2) Prueba de integración:
prueba de ensamblaje/prueba conjunta: ensamble todos los módulos en subsistemas o sistemas de acuerdo con los requisitos de diseño para la prueba de integración.
3) Prueba del sistema:
combine el software, el hardware de la computadora, los periféricos, la red y otros elementos confirmados para realizar varias pruebas de ensamblaje y pruebas de confirmación del sistema de información. La prueba del sistema es una prueba para todo el producto.
4) Pruebas de aceptación:
Pruebas de entrega: Asegúrese de que el software esté listo.
División de Tecnología de Pruebas
1) Pruebas de caja blanca:
pruebas estructurales/pruebas de caja transparente/pruebas basadas en lógica/pruebas basadas en código:
2) Pruebas de caja negra:
Pruebas funcionales: Pase la prueba de si cada función se puede usar normalmente. (datos de entrada/datos de salida)
3) Prueba de caja gris:
un método de prueba entre la prueba de caja blanca y la prueba de caja negra: no solo presta atención a la exactitud de la salida y la entrada, sino que también presta atención a la situación interna del programa.
Si el software bajo prueba realmente se ejecuta
1) Pruebas estáticas:
se refiere a comprobar la corrección del programa analizando o comprobando la sintaxis, la estructura, el proceso, la interfaz, etc. del programa fuente sin ejecutar el programa en sí.
Para pruebas de código: principalmente probar si el código cumple con los estándares y especificaciones correspondientes;
para pruebas de interfaz: principalmente probar si la interfaz real del software es consistente con la descripción en los requisitos;
para pruebas de documentos: principalmente probar si el usuario y el requisito descripción satisface las necesidades reales del usuario;
2) Método dinámico:
se refiere a verificar la diferencia entre el resultado de ejecución y el resultado esperado ejecutando el programa probado y analizando la eficiencia de ejecución, la corrección, la robustez y otras actuaciones.
División de Organización de Implementación de Pruebas
1) Prueba de revelador:
Prueba de verificación/prueba α
2) Pruebas de usuario:
pruebas beta
3) Pruebas de terceros
División del tipo de prueba
1) Prueba funcional:
pruebe principalmente el software de acuerdo con la especificación de requisitos del producto y verifique si las funciones del software cumplen con los requisitos, incluida la inspección de las funciones originales y si hay funciones redundantes o faltantes en el software.
2) Prueba de interfaz:
prueba principalmente la interfaz del sistema, si la interfaz de usuario es amigable, si el software es conveniente y fácil de usar, si el diseño del sistema es razonable, si la ubicación de la interfaz es correcta, etc.
3) Prueba de rendimiento:
principalmente para probar si el rendimiento del sistema satisface las necesidades del usuario, es decir, para verificar el estado de capacidad del sistema en condiciones de funcionamiento específicas. Las pruebas de rendimiento utilizan principalmente herramientas de prueba automatizadas para simular condiciones de carga normales, máximas y anormales para probar varios indicadores de rendimiento del sistema.
4) Prueba de fuerza:
obliga al sistema a ejecutarse con una configuración de recursos anormal. El propósito es encontrar errores causados por recursos insuficientes o contención de recursos.
5) Prueba de estrés:
principalmente en un entorno sobrecargado para probar si el sistema puede funcionar normalmente.
6) Prueba de seguridad:
prueba la capacidad del sistema para prevenir intrusiones ilegales.
7) Prueba de compatibilidad:
pruebe la compatibilidad de los productos de software en diferentes plataformas, diferentes herramientas de software o diferentes versiones de la misma herramienta de software.
8) Prueba de instalación:
verifique principalmente si el software se puede instalar correctamente, si la configuración del archivo de instalación es válida, si la instalación afecta a todo el sistema informático, si el software se puede desinstalar limpiamente al desinstalarlo y si todo el el sistema informático se ve afectado después de desinstalar el software.
9) Prueba de Documentación:
Comprueba principalmente la claridad y exactitud de la documentación interna o externa.
3. Modelo de proceso de prueba de software
modelo 3.1V
modelo de 3,2 W
modelo 3.3H
modelo 3.4X
4. Definición y características de los casos de prueba
4.1 Características de los casos de prueba
1. El caso de prueba es representativo: el caso de prueba puede representar y cubrir varios datos de entrada legales e ilegales, razonables e irrazonables, fronterizos y transfronterizos y límites, configuraciones ambientales y de operación, etc.
2. Los resultados de la prueba son determinables: se puede determinar la exactitud de los resultados de la ejecución de la prueba, y cada caso de prueba debe tener un resultado esperado claro; de lo contrario, será difícil juzgar si el sistema funciona normalmente.
3. Los resultados de la prueba se pueden reproducir: para los mismos casos de prueba, los resultados de ejecución del sistema deben ser los mismos.
4.2 Principios del diseño de casos de prueba
Usar varios métodos de diseño de casos de prueba para diseñar;
asegurar la exactitud de los datos del caso de prueba y el funcionamiento correcto;
asegurarse de que los casos de prueba sean representativos;
cada caso de prueba debe estar dirigido a un solo elemento de prueba;
asegurarse de que los resultados de la prueba estén bien determinados y sean reproducibles;
asegurarse de que la descripción del caso de prueba sea precisa, clara y específica;
el diseño del caso de prueba debe cumplir con los requisitos de tiempo, personal y financiamiento del proyecto;
4.3 Plantilla de caso de prueba
4.3.1 Elementos básicos de los casos de prueba
4.3.2 Casos de prueba funcional
4.3.3 Casos de prueba de rendimiento
1. Casos de prueba de rendimiento esperado
2. Casos de prueba de rendimiento de concurrencia de usuarios
3. Casos de prueba de rendimiento de grandes volúmenes de datos
4. Caso de prueba de resistencia a la fatiga
5. Cargar casos de prueba
4.3.4 Casos de prueba de compatibilidad
3. Pruebas de caja negra
1. Método de división de clases de equivalencia
1. División de clases de equivalencia efectiva: Las clases de equivalencia efectiva se refieren al conjunto de datos de entrada que es razonable y significativo para las especificaciones del programa. El conjunto de datos de clase de equivalencia efectiva incluye: comandos ingresados por el usuario final, indicaciones del sistema que interactúan con el usuario final, recibir el nombre del archivo de usuario relevante, proporcionar valores de inicialización y valores límite, proporcionar comandos de datos de salida formateados y proporcionar datos , datos repetidos en caso de falla, etc.
2. División de clases de equivalencia no válidas: las clases de equivalencia no válidas se refieren a conjuntos de datos de entrada que no son razonables ni tienen sentido para las especificaciones del software.
3. El método de división de clases de equivalencia
Dividir por intervalo
Dividir por valor numérico
Dividir por conjunto numérico Dividir
por restricción o planificación Dividir
por método de procesamiento
4. El principio de división de clases de equivalencia
1. En el caso del rango de valores o el número de valores especificados por las condiciones de entrada, se puede determinar una clase de equivalencia válida y dos clases de equivalencia no válidas 2.
En un conjunto de valores que especifican la datos de entrada (asumiendo que hay n valores), se pueden determinar n clases de equivalencia válidas y una clase de equivalencia no válida
3. En el caso de especificar las reglas que deben cumplir los datos de entrada, se puede determinar una clase de equivalencia válida y varias clases de equivalencia inválidas
4. Bajo la condición de que la condición de entrada estipule el conjunto de valores de entrada o estipule "cómo debe ser", se puede determinar una clase de equivalencia válida y una clase de equivalencia no válida 5. Cada elemento en la equivalencia
determinada la clase se procesa en el programa En el caso de diferentes métodos, la clase de equivalencia debe dividirse en clases de equivalencia más pequeñas;
5. Prueba de clase de equivalencia general débil: implementada mediante el uso de una variable de cada clase de equivalencia (intervalo) en un caso de prueba
6. Fuerte prueba de clase de equivalencia general: basada en múltiples suposiciones de defectos
7. Prueba de clase de equivalencia débilmente robusta:
8. Pruebas de clase de equivalencia fuertes y robustas:
9. Práctica de la unidad
2. Método del valor límite
2.1 Análisis del 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. La idea básica del análisis de valor límite es utilizar valores variables en el valor mínimo, ligeramente por encima del valor mínimo, valor normal, ligeramente por debajo del valor máximo y valor máximo.
2.2 Análisis de robustez
2.3 Prueba del peor de los casos
2.4 Práctica de la unidad
2.5 Pruebas aleatorias
2.6 Directrices para la prueba del valor límite
3. Método de la tabla de decisiones
3.1 Tabla de decisiones
3.2 Ejemplos
3.3 Directrices
4. Diagrama de causa y efecto
El diagrama de causa y efecto es un método para diseñar casos de prueba mediante el análisis gráfico de varias combinaciones de entradas. Es adecuado para verificar varias combinaciones de condiciones de entrada del programa.
5. Método de escena
6. Método experimental ortogonal
4. Pruebas de caja blanca (suplemento posterior)
Una pequeña explicación complementaria.
Finalmente, compilé un conjunto de documentos de entrevistas de prueba de software para usted. Hay 212 páginas en total. Debería ser muy útil para los amigos cambiar de trabajo para las entrevistas, ser promovidos y aumentar los salarios, deshacerse de las dificultades profesionales y mejorar sus habilidades. Espero que todos puedan tener un futuro brillante Kam. [Haga clic en la tarjeta pequeña al final del artículo para obtener un conjunto completo de materiales de prueba de software de forma gratuita]
Básicamente cubre todos los puntos técnicos centrales de las pruebas de software: teoría de pruebas, fundamentos de Linux, fundamentos de MySQL, pruebas web, pruebas de interfaz, pruebas de aplicaciones, herramientas de administración, relacionadas con Selenium, pruebas de rendimiento, red informática, principio de composición, estructura de datos y algoritmo, lógica. Preguntas, recursos humanos, mapas cerebrales técnicos, etc... la calidad es muy alta! ! ! ¡Más que suficiente para entrevistas técnicas!
Dónde ver el videotutorial:
https://www.bilibili.com/video/BV1hj411z71j/?spm_id_from=333.999.0.0&vd_source=74d0257ec7066cc4f9013524f0bb7013 