Prólogo:
Hola a todos, soy Yifei, las flores son similares todos los años y las preguntas son diferentes todos los años. Estamos a principios de febrero de 2020, y quedan 1,2 meses en las temporadas de oro, tres y plata para encontrar un trabajo cada año. En estos días, he examinado materiales y libros, y he recopilado la clasificación de pruebas de software y el contenido del ciclo de pruebas de software para Personalmente creo que lo que he resumido es más detallado, y espero que todos puedan criticarme y corregirme. Espero que el compartir de hoy pueda ayudar a los amigos.
Clasificación de las pruebas de software:
1. Tecnología de prueba de prensa
1. Prueba de caja negra
1.1. Definición
En la prueba de interfaz del programa, solo verifica si la función del programa se usa normalmente de acuerdo con la especificación. También se llama prueba funcional o prueba basada en datos. Se prueba para detectar si cada función se puede utilizar normalmente. En la prueba, el programa se considera una caja negra que no se puede abrir. La interfaz del programa se prueba sin tener en cuenta la estructura interna y las características internas del programa. Solo verifica si las funciones del programa se utilizan normalmente de acuerdo con la especificación de requisitos. Si el programa puede recibir correctamente los datos de entrada y generar información de salida correcta. La prueba de caja negra se centra en la estructura externa del programa, sin considerar la estructura lógica interna, y prueba principalmente la interfaz y las funciones del software.
1.2 Ventajas y desventajas de las pruebas de caja negra
Ventajas: a. Fácil de implementar, no es necesario prestar atención a la implementación interna del programa; b. Más cerca de la perspectiva del usuario;
Desventajas: a. La cobertura de la prueba es baja, generalmente solo cubre el 40% del código; b. Para la prueba automatizada de la caja negra, la tasa de reutilización es baja y el costo de mantenimiento es alto.
1.3 Contenido de la prueba principal de la prueba de caja negra
Si hay funciones incorrectas o faltantes;
En la interfaz, ¿se puede aceptar correctamente la entrada? ¿Puede generar el resultado correcto?
¿Hay errores de estructura de datos o errores de acceso a información externa?
¿Puede el rendimiento cumplir con los requisitos?
1.4 Principales métodos de diseño de las pruebas de caja negra
Análisis de proceso
División de clases de equivalencia
Análisis de valor límite
Especulación incorrecta
Diagrama de causalidad
Análisis experimental ortogonal
Diagrama de transición de estado
Análisis de proceso
2. Prueba de caja blanca
2.1. Definición
Para comprender completamente la estructura del programa y el proceso de procesamiento, prueba el programa de acuerdo con la lógica interna del programa para verificar si cada ruta en el programa funciona correctamente de acuerdo con los requisitos predeterminados. También conocido como prueba estructural o prueba impulsada por lógica.
2.2. Principales unidades lógicas
Declaración, condición, combinación de condiciones, rama, ruta
2.3 Ventajas y desventajas de las pruebas de caja blanca
ventaja:
a. Obligar a los evaluadores a pensar detenidamente sobre la implementación del software y comprender los principios
b. Puede detectar todas las ramas y rutas del código.
c. Revelar los problemas ocultos en el código
d. Pruebe el código más a fondo
Desventajas:
a. El costo es un poco alto y requiere que los evaluadores tengan capacidad de programación
b. No se pueden detectar rutas faltantes y errores de sensibilidad de datos en el código.
c. No se puede verificar directamente la exactitud de los requisitos
3. Prueba de caja gris
La prueba entre la prueba de caja negra y la prueba de caja blanca no solo debe prestar atención a la corrección de la salida a la entrada, como las pruebas de caja negra, sino también al rendimiento del contenido. Sin embargo, esta atención no es tan detallada y completa como la prueba de caja blanca. Juzgue el estado operativo interno a través de algunos fenómenos, eventos y signos representativos.
2. Según el método de prueba
1. Prueba estática
1.1. Definición
La prueba estática significa que no necesita ejecutar el programa bajo prueba, sino revisando los documentos o códigos del software, midiendo la complejidad estática del programa, verificando si el software cumple con los estándares de programación, para encontrar las deficiencias del programa escrito. y reducir la probabilidad de errores
1.2. El formulario incluye la inspección mutua por parte de los programadores, la búsqueda de la organización del grupo y la revisión de la reunión de revisión formal.
2. Prueba dinámica
La prueba dinámica se refiere a verificar la diferencia entre el resultado de ejecución y el resultado esperado ejecutando el programa bajo prueba y analizando la eficiencia de ejecución, corrección y robustez, etc. Es decir, el rendimiento del programa se evalúa mediante la situación de ejecución real.
Según el método de ejecución de la prueba
1. Prueba manual
El comportamiento de un probador dedicado desde la perspectiva del usuario para verificar si el software cumple con los requisitos de diseño.
Es más adecuado para pruebas en profundidad y pruebas que enfatizan el juicio subjetivo. Por ejemplo: pruebas colaborativas y pruebas exploratorias
2. Pruebas automatizadas
Utilice un software de herramienta de prueba independiente para controlar la ejecución automatizada de pruebas y verificar automáticamente las expectativas y los resultados.
3. La diferencia entre la prueba manual y la prueba automatizada
Según las características de calidad del software
1. Prueba funcional
De acuerdo con las características del producto, la descripción de la operación y el programa de usuario, pruebe las características y el comportamiento operativo de un producto para determinar que cumplen con los requisitos de diseño. Los principales problemas son errores u omisiones funcionales, problemas de interfaz, errores de rendimiento, errores de datos y de acceso, errores de inicialización y terminación. El error de rendimiento aquí se refiere al problema de rendimiento del propio software.
Las principales herramientas para las pruebas de automatización funcional: QTP (basado en palabras clave), silkTest, robot Rational, selenium (código abierto para aplicaciones web), Watir, sikuli (basado en capturas de pantalla)
2. Prueba de rendimiento
Verificar que el desempeño del sistema de software pueda cumplir con los indicadores de desempeño requeridos por la demanda. Las pruebas de rendimiento generalmente se dividen en pruebas de carga, pruebas de estrés y pruebas de estabilidad. Los indicadores de rendimiento incluyen el número de usuarios concurrentes (VU), transacciones por segundo (TPS), tiempo de respuesta del sistema y rendimiento del dispositivo.
Herramientas de prueba de rendimiento: loadrunner, silkperformer, Jmeter, WebLoad, etc.
El enfoque de las pruebas de rendimiento de aplicaciones web: evaluación de rendimiento estático. Al desarrollar aplicaciones web, realice un análisis estático en las páginas de la aplicación web basándose en una serie de mejores prácticas para la optimización del rendimiento de la página web y proporcione métodos de análisis de rendimiento para los resultados de la evaluación. Hay dos estándares / herramientas de juicio principales en la industria, YSlow y PageSpeed, los cuales son complementos del navegador.
La gestión del rendimiento de las aplicaciones (APM) es principalmente para proporcionar un seguimiento en tiempo real del sistema para lograr la gestión del rendimiento, soluciones de gestión de fallos.
3. Prueba de seguridad
Pruebe los productos de software para asegurarse de que el software cumple con los requisitos de seguridad y los estándares de calidad del producto. La prueba de penetración es una prueba que evalúa la seguridad del sistema simulando ataques maliciosos en el sistema de software, es una prueba de ataque que obtiene la autorización de un usuario.
Proyecto de seguridad de aplicaciones web abiertas OWASP: http://www.owasp.org
Herramientas de prueba de seguridad: herramienta de escaneo de vulnerabilidades de Appscan para aplicaciones web, Webinspect, herramienta de escaneo de vulnerabilidades de Nessus para hosts de servidor, herramienta de rastreo de puertos Nmap, marco de ataque MetaSploit, Fortify para pruebas de caja blanca
4. Prueba de compatibilidad
La compatibilidad del software en sí es compatible con las funciones y los datos de la versión histórica; la compatibilidad de diferentes plataformas puede ejecutarse en múltiples plataformas y se debe considerar la verificación de múltiples plataformas; la compatibilidad del software con el equipo en ejecución es diferente para diferentes equipos Rendimiento del software; interoperabilidad del software, diferentes software del mismo fabricante pueden tener interoperabilidad en el mismo dispositivo. Para aplicaciones web, compatibilidad entre diferentes navegadores, como IE, FireFox, Chrome, Opera, etc .; diferentes sistemas operativos, como windows & Linux; diferentes marcas de ordenadores como HP, etc. Para aplicaciones, mini programas y cuentas oficiales, también hay marcas de teléfonos móviles, sistema Android e IOS, etc.
Herramientas de prueba de compatibilidad: BrowserShots, BrowserSandbox
otro
1. Prueba de regresión
Después de que se modifica la función del software, el software se vuelve a probar para confirmar que la modificación no introduce nuevos errores ni causa errores en otras partes. Es más adecuado para pruebas automatizadas. Las pruebas de regresión se pueden realizar en módulos.
2. Prueba de aventura
Se usa para confirmar que los cambios en el código funcionarán como se esperaba y no interrumpirán la estabilidad de toda la versión. Verificación de un proceso empresarial clave para todo el proceso.
3. Prueba del mono
Utilice algunas formas extrañas y aleatorias de operar el software para probar la solidez y estabilidad del sistema. El SDK de Andriod tiene una interfaz de prueba de mono.
4. Prueba A / B
Se utiliza en la industria de Internet para proporcionar dos versiones de la página para que los usuarios utilicen y registren datos relevantes del comportamiento del usuario para determinar un plan de prueba diseñado de manera más óptima. Puntos de implementación: se implementan múltiples programas en paralelo, y el número de usuarios alcanza un cierto orden de magnitud; solo se cambia una variable por cada cambio; la supervivencia del más apto se lleva a cabo de acuerdo con ciertas reglas
Las tendencias y capacidades de las pruebas también cambian constantemente. Ahora se pide a los probadores que hagan cosas más técnicas y orientadas al proceso. Las pruebas ahora no solo se limitan a encontrar errores, sino que también tienen un alcance de trabajo más amplio, son requeridas y asignadas para trabajar desde el inicio del proyecto o incluso cuando los requisitos no se han determinado oficialmente.
Las pruebas también están estandarizadas. Al igual que el desarrollo de software tiene un ciclo de vida, las pruebas también tienen su propio ciclo de vida.
Preste atención a la cuenta pública de WeChat: Programa Yuanyifei, los siguientes recursos son suyos, ¡guau!
¿Qué es el ciclo de vida?
El término simple "ciclo de vida" se refiere a una serie de cambios de una forma (estado) a otra forma (estado). Estos cambios pueden ocurrir en cosas tangibles o intangibles. Cada entidad tiene un ciclo de vida, desde el principio hasta la muerte / final.
¿Qué es el ciclo de vida de las pruebas de software?
Se refiere al proceso de prueba, que es una serie de pasos específicos que se ejecutan en un orden determinado para garantizar que la calidad del producto cumpla con los requisitos. En el proceso STLC, cada actividad se ejecuta de acuerdo con el sistema planificado. Cada etapa tiene diferentes objetivos y entregables. Cada organización en STLC tiene diferentes etapas, pero los conceptos básicos son los mismos.
Las siguientes son las 8 etapas de las pruebas de software:
1. La etapa de la demanda
2. Etapa de planificación
3. Fase de análisis
4. Fase de diseño
5. Fase de ejecución
6. Fase de ejecución
7. Etapa de resumen
8. Fase final
1. Etapa de requisitos:
En esta etapa, es la etapa de análisis y aprendizaje de las necesidades. Haga una lluvia de ideas con otros equipos e intente averiguar si los requisitos son mensurables. Esta etapa ayuda a identificar el alcance de la prueba. Si alguna función no es comprobable, comuníquese a tiempo y haga planes de estrategias de mitigación (reducción de riesgos).
2. Etapa de planificación:
en el escenario real, el plan de prueba es el primer paso del proceso de prueba. En esta etapa identificamos qué actividades y recursos pueden coincidir con los objetivos de la prueba. También trabajamos arduamente para identificar indicadores de prueba, métodos de prueba y cómo rastrear estos indicadores.
¿Cuál es la base del plan? ¿Solo hay demanda?
La respuesta es no. La demanda es solo una base, pero hay otros dos factores que afectan el plan de prueba. son:
3. Fase de análisis: se
prueba la definición de STLC "QUÉ". Generalmente, utilizamos documentos de requisitos, riesgos de productos y otras bases de prueba para identificar las condiciones de prueba. Las condiciones de prueba deben ser trazables a los requisitos. Hay muchos factores que pueden afectar la identificación de las condiciones de la prueba:
-
Nivel y profundidad de las pruebas
-
Complejidad del producto
-
Riesgos de productos y proyectos
-
El ciclo de vida del desarrollo de software está involucrado
-
Gestión de pruebas
-
El conocimiento y las habilidades del equipo.
-
Disponibilidad de partes interesadas relevantes
Debemos esforzarnos por anotar las condiciones de prueba de una manera muy detallada. Por ejemplo, para un sitio web de comercio electrónico, tiene una condición de prueba de "Los usuarios deberían poder pagar". O puede describirlo en detalle como "Los usuarios deberían poder pagar con tarjeta de crédito, WeChat, Alipay, etc.". El mayor beneficio de escribir las condiciones de prueba detalladas es mejorar la cobertura de la prueba, porque los casos de prueba se escriben a través de estas condiciones de prueba y estos detalles desencadenan la escritura de más casos de prueba. Al mismo tiempo, también puede distinguir los criterios para salir de la prueba, como qué condiciones determinan la finalización de la prueba.
4. Fase de diseño:
esta fase tiene "CÓMO" para probar. Incluyendo las siguientes tareas:
-
Condiciones de prueba detalladas. Condiciones de prueba divididas para proporcionar cobertura para múltiples subcondiciones.
-
Identificar y obtener datos de prueba
-
Identificar y construir un entorno de prueba
-
Cree indicadores de seguimiento de la demanda
-
Cree métricas de cobertura de prueba
5. Fase de implementación:
la tarea principal de esta fase es crear casos de prueba detallados. La prioridad de los casos de prueba y qué casos de uso se convertirán en parte de la prueba de regresión. Antes de decidir finalmente sobre los casos de prueba, es muy importante revisar la exactitud de los casos de prueba. Al mismo tiempo, no olvide firmar (firma, por ejemplo, el informe de prueba final antes del lanzamiento de la nueva versión debe enviar un informe de aprobación) caso de prueba antes de que comience la ejecución real. Si su proyecto está diseñado para ser automatizado, identifique qué casos de uso son adecuados para la automatización y prepare scripts de prueba. No olvide revisar.
6. Etapa de ejecución:
Desde el nombre, esta etapa es la etapa de ejecución real de STLC. Pero antes de implementarlo, asegúrese de que sus estándares coincidan con sus necesidades. Ejecute el caso de prueba e informe del error si hay alguna discrepancia. Al mismo tiempo, complete los indicadores de seguimiento para seguir su progreso.
7. Etapa de resumen:
esta etapa se centra en los estándares e informes de inspección. Dependiendo de su proyecto y las opciones de las partes interesadas, puede decidir si publicar un informe diario o semanal, etc. Hay diferentes tipos de informes (informes diarios, informes semanales) que puedes enviar, pero el caso es que el contenido del informe varía según la persona a la que envíes. Si el director del proyecto pertenece al ámbito de las pruebas, entonces está más interesado en los aspectos técnicos, por lo que debe incluir los aspectos técnicos en el informe (el número de pasadas, el número de fallas, el número de errores, el número de errores graves, etc.) en el informe. Pero si informa a las partes interesadas de nivel superior, es posible que no estén interesados en los aspectos técnicos, y puede enviarles algunos relacionados con el riesgo, como reducir la ocurrencia de riesgos a través de pruebas.
8. Fase final: las
tareas de esta fase incluyen:
- Verifique la finalización de la prueba. Si todos los casos de uso se implementan o se mitigan intencionalmente. Compruebe si todavía hay errores de S1 activos.
- Experimente la reunión de resumen y la redacción de documentos relacionados. Incluyendo lo que se hace bien, lo que se necesita mejorar y cómo mejorar
Lo que necesita saber sobre el ciclo de vida de las pruebas de software:
a. Definición y planificación del problema: discutir las necesidades generales
b. Análisis de la demanda: análisis detallado, especificaciones de la demanda (redactadas por el gerente de producto), reunión de revisión de la demanda.
c. Diseño de software
Esquema de diseño: el diseño de la arquitectura principal, expresando la función de cada módulo.
Análisis detallado del diseño en profundidad de cada módulo en el diseño del esquema
d. Codificación del software
e. Prueba unitaria
f. Prueba de integración
g. Prueba del sistema: consulte la prueba de requisitos en la especificación
h. Prueba de aceptación-prueba de aceptación del usuario
i. Operación y mantenimiento: corrección de errores y mejora del mantenimiento, como actualizaciones de versión (corregir errores o agregar nuevas funciones)
j. Modelo de ciclo de vida del software
k. Modelo de desarrollo ágil
m. Modelo de cascada
modelo nV
o. Modelo en espiral
modelo pW
Aquí recomiendo un grupo de intercambio de pruebas de software que creé por mí mismo, qq: 642830685, preguntas de la entrevista de prueba e información de la industria de prueba.También puede intercambiar tecnología activamente en el grupo, y los líderes de la industria responderán sus preguntas. Te espero en el viento y la lluvia.
Escrito al final:
La gente a menudo dice en nuestros oídos: "No tienes que pagar por ello" y "Pierdes si hablas en serio". Pero si no lo afrontas en serio en tu vida, ¿quién te tomará en serio? Solo aquellos que son serios en todo serán favorecidos por el cielo. Toma en serio la carrera que elegiste y dedícate de todo corazón. Esta es la única manera de que todo el mundo triunfe. Solo si te apegas al final, verás las flores florecer detrás de ti después de haber sido regadas por el sudor. "En serio, conviértete en un mejor yo, y la vida nunca te decepcionará".
En el futuro, se agradecerá a sí mismo por luchar hoy, tomará cada paso en serio y creerá que eventualmente llegará al lugar al que desea llegar. Amigos que hayan terminado de leer el artículo, no se olviden de levantar su linda manita y me gusta tres veces consecutivas. Su me gusta es la motivación inagotable para que yo escriba más.
