Pruebas y mantenimiento del sistema

1. Pruebas del sistema

  1. Objetivo de la prueba: la prueba es el proceso de ejecutar un programa para encontrar errores
  2. Principios de prueba:
    1. Prueba temprano y constantemente
    2. Los programadores evitan probar los programas diseñados por ellos mismos; el trabajo de prueba debe ser evitado por la persona o el grupo que desarrolló originalmente el software (excepto para las pruebas unitarias)
    3. Incluya no solo condiciones de entrada razonables y efectivas, sino también condiciones de entrada no razonables y no válidas
    4. No solo para determinar los datos de entrada, sino también para determinar los resultados de salida de la función del sistema.
    5. No solo para detectar si el programa hace lo que debe hacer, sino también si hace lo que no debe hacer
    6. Las pruebas de regresión deben realizarse después de la modificación.
    7. El número de errores que no se han encontrado es proporcional al número de errores que ha encontrado el programa
  1. Actividad de prueba básica:
    1. Elabore un plan de prueba, elabore un plan para la prueba del sistema. Al elaborar un plan de prueba, considere completamente el tiempo de desarrollo y el progreso de todo el proyecto, así como algunos factores humanos y condiciones objetivas, para que el plan de prueba sea factible. El contenido del plan de prueba incluye principalmente: contenido de la prueba, horario, entorno y condiciones de prueba, arreglos de entrenamiento de prueba, etc.
    2. Prepare el esquema de prueba, que es la base para la prueba. Estipula de forma clara y exhaustiva los elementos básicos de la prueba y los estándares de finalización de la prueba que deben completarse para cada función o característica del sistema en la prueba.
    3. Diseñar y generar casos de prueba, de acuerdo con el esquema de prueba, diseñar y generar casos de prueba. Al probar casos de uso, las técnicas de diseño de casos de prueba presentadas anteriormente se pueden usar de manera integral para generar documentación de diseño de prueba, que incluye principalmente: elementos probados, datos de entrada, proceso de prueba, resultados de salida esperados, etc.
    4. Ejecute las pruebas del sistema, implemente las pruebas y la fase de implementación de las pruebas se compone de una serie de ciclos de prueba. En cada ciclo de prueba, los evaluadores y los desarrolladores realizarán una prueba completa del software o equipo bajo prueba de acuerdo con el esquema de prueba preprogramado y los casos de prueba preparados.
    5. Gestión de defectos y corrección de errores, generar informe de prueba; una vez completada la prueba, se debe formar un informe de prueba correspondiente, que resume principalmente la prueba, enumera la conclusión de la prueba y señala defectos y errores
  1. División de las fases de prueba:
    1. prueba de unidad:
      1. Concepto: La prueba del módulo es probar cada módulo de software más pequeño y verificar la descripción de la función de cada módulo del programa para garantizar que pueda funcionar normalmente.
      2. Sujeto de prueba: las pruebas unitarias son ejecutadas por el desarrollador
      3. Contenido de prueba: prueba de interfaz de módulo, prueba de estructura de datos local, prueba de ruta, prueba de manejo de errores, prueba de límite (prueba de módulo, función de módulo, rendimiento, interfaz, etc.)
    1. Pruebas de integración:
      1. Concepto: Sobre la base de las pruebas unitarias, se requiere ensamblar todos los módulos de acuerdo con los requisitos de la especificación de diseño general y la especificación de diseño detallada. Su finalidad es verificar las interfaces y funciones de intercambio de los módulos que componen el sistema software (interfaces entre módulos)
      2. Preguntas a tener en cuenta durante el montaje: Al conectar los módulos entre sí, ¿se perderán los datos que pasan a través de la interfaz del módulo?
      3. Si la función de un módulo afectará la función de otro módulo y causará efectos adversos; si la combinación de varias subfunciones puede lograr la función principal esperada; si hay un problema con la estructura de datos global; si los errores de un solo el módulo se magnificará cuando se acumule, hasta un punto inaceptable;
      4. La forma en que se ensamblan los módulos:
        1. Método de ensamblaje único: si hay un error, no se puede encontrar el motivo y será difícil verificar y corregir el error
        2. Ensamblaje de arriba hacia abajo: los principales puntos de control y juicio se verifican antes en el proceso de prueba, la viabilidad funcional se encuentra y confirma antes, y se mejora la información sobre el éxito del desarrollador y el usuario. Desventajas: conducen a pruebas de regresión excesivas;
        3. Método de valor agregado de abajo hacia arriba: las partes que son propensas a problemas se pueden encontrar y resolver temprano; desventajas: no se puede acceder al control de las partes principales hasta el final; se pueden implementar pruebas paralelas de múltiples módulos para mejorar la eficiencia de la prueba ;
        4. Método mixto de valor añadido
      1. Prueba de humo: originada en la industria del hardware, encender el dispositivo directamente después de que se haya realizado un cambio o reparación en una pieza de hardware o un componente de hardware. Si no hay humo, el componente ha pasado la prueba.
    1. Prueba del sistema:
      1. Concepto: Prueba del sistema en un entorno real para verificar si los elementos completos de configuración del software se pueden conectar correctamente al sistema. Combine el software con el hardware, los periféricos, el software de soporte, los datos y el personal de todo el sistema, y ​​ejecute la prueba en el entorno operativo real según la especificación de requisitos. Compruebe si hay algún lugar que no cumpla con el manual del sistema.
      2. El proceso de prueba del sistema se divide en tres fases: planificación y preparación, ejecución, reelaboración y prueba de regresión:
        1. Contenido: las pruebas del sistema generalmente necesitan completar pruebas funcionales, pruebas de rendimiento, pruebas de recuperación, pruebas de seguridad, pruebas de resistencia y otras pruebas restrictivas;
      1. Tres pruebas de rendimiento:
        1. Prueba de carga: determina el rendimiento del sistema bajo varias cargas de trabajo, el objetivo es probar los cambios en varios indicadores de rendimiento del sistema cuando la carga aumenta gradualmente
        2. Prueba de estrés: una prueba para obtener el máximo nivel de servicio que un sistema puede proporcionar mediante la identificación de cuellos de botella o puntos de rendimiento inaceptables de un sistema.
        3. Prueba de fuerza: examina el funcionamiento del sistema de software cuando los recursos del sistema son particularmente bajos
        4. Prueba de concurrencia: La prueba de concurrencia, también conocida como prueba de capacidad, se utiliza principalmente para determinar la cantidad máxima de usuarios en línea simultáneos que el sistema puede manejar.
    1. Prueba de confirmación:
      1. Concepto: Pruebas de conformidad, utilizadas para verificar la consistencia del software y los requisitos del usuario.
      2. Las pruebas de confirmación incluyen: pruebas de confirmación internas, pruebas alfa, pruebas beta y pruebas de aceptación.
  1. Pruebas estáticas frente a pruebas dinámicas
    1. La prueba estática es un programa que no ejecuta pruebas de software, sino que utiliza la detección manual y el análisis por computadora para ayudar al análisis estático a probar el programa. Los métodos de prueba estática incluyen principalmente la inspección en la recepción, el recorrido del código y la revisión del código.
    2. Las pruebas dinámicas se dividen en pruebas de caja negra, pruebas de caja blanca y pruebas de caja gris. Las pruebas de caja blanca también se denominan pruebas estructurales, las pruebas de caja negra también se denominan pruebas funcionales y las pruebas de caja gris son una combinación de las dos;
  1. Método de prueba estática:
    1. Inspección de escritorio: los programadores verifican sus propios programas. Después de compilar el programa y antes del diseño de la prueba unitaria, el programador analiza e inspecciona el código fuente y complementa los documentos relevantes para encontrar errores en el programa.
    2. Revisión de código: La revisión de código es un proceso de análisis estático del programa por parte de un equipo de revisión compuesto por varios programadores y probadores a través de lectura, discusión y disputa. El proceso de revisión del código se puede dividir en dos pasos: Paso 1: el líder del equipo distribuye las especificaciones de diseño, los diagramas de flujo de control, los textos del programa y los requisitos, especificaciones, etc. relacionados a los miembros del equipo con anticipación como base para la revisión.
    3. Recorrido del código: el recorrido del código es básicamente lo mismo que la revisión del código, y el proceso también se divide en dos pasos: Paso 1: envíe los materiales a cada miembro del equipo del recorrido, permítales estudiar el programa cuidadosamente, y luego celebrar una reunión. Paso 2: El programa de la reunión es diferente al de la revisión del código. En lugar de simplemente leer el programa y compararlo con la lista de verificación del programa, permite que los participantes "actúen" como computadoras. Es decir, en primer lugar, los miembros del equipo de prueba preparan un lote de casos de prueba representativos para que se pruebe el programa y los envían al equipo de guía. El equipo de recorrido realiza una reunión, desempeña colectivamente el papel de la computadora, permite que los casos de prueba se ejecuten a lo largo de la lógica del programa y registra los rastros del programa en cualquier momento para su análisis y discusión.
    4. La prueba estática se realiza análisis estático, el análisis estático incluye:
      1. Análisis de flujo de control: ¿Hay declaraciones no utilizadas, declaraciones inalcanzables, llamadas a subrutinas que no existen?
      2. Análisis de flujo de datos: hacer referencia a variables indefinidas, reasignar variables no utilizadas previamente
      3. Análisis de interfaz: consistencia de interfaz entre módulos, consistencia de interfaz entre subrutinas y funciones, y consistencia en el número, orden y tipo de parámetros formales y reales de la función
      4. Análisis de expresiones: falta de coincidencia entre paréntesis, referencia de matriz fuera de los límites, divisor por 0, etc.
  1. Método de prueba dinámico:
    1. Pruebas de caja blanca (pruebas estructurales)
      1. Concepto: Diseñar casos de prueba de acuerdo con la estructura y lógica internas, y rutas y procesos de programas de prueba. Se utiliza principalmente en la fase de pruebas unitarias.
      2. Cobertura de la declaración:
      3. cobertura de juicio
      4. Anulaciones de condición:
      5. Sentencia, condición de cobertura:
      6. Anulaciones de combinación de condiciones:
      7. Cobertura de ruta:
      8. prueba de ruta básica
      9. Cobertura de bucle:
    1. Pruebas de caja negra (pruebas funcionales):
      1. Concepto: en función de las especificaciones del producto, Heihe Test lleva a cabo actividades de verificación para funciones y características específicas del producto desde la perspectiva del usuario, confirma si cada función está completamente implementada y si los usuarios pueden usar estas funciones normalmente. Se utiliza principalmente para pruebas de integración. , prueba de confirmación y fase de prueba del sistema.
      2. Ver errores de descubrimiento: funcionalidad incorrecta o faltante; errores de interfaz; errores de acceso a la base de datos; errores de rendimiento; errores de inicialización y terminación, etc.
      3. método:
        1. Método de división de clases de equivalencia:
        2. Análisis de valor límite:
        3. Suposición equivocada:
        4. Tabla de decisión: Es la más adecuada para describir las diferentes acciones a realizar en la situación compleja formada por la combinación de múltiples valores de condiciones lógicas.
        5. Tabla de causa y efecto: diseñar casos de prueba de acuerdo con la relación causal entre las condiciones de entrada y los resultados de salida;
  1. Pruebas orientadas a objetos:
    1. Capa de algoritmo (prueba unitaria): incluye prueba de división de clase de equivalencia, prueba de función combinada (prueba basada en tabla de decisión), prueba de función recursiva y prueba de mensaje polimórfico (nivel de método)
    2. Capa de clase (prueba de módulo): incluye prueba de límite invariable, prueba de clase modal y prueba de clase no modal
    3. Capa de plantilla, capa de árbol de clases (pruebas de integración): incluidas pruebas de servicios polimórficos y pruebas de aplanamiento
    4. Capa del sistema, prueba del sistema
  1. Automatización de pruebas:
    1. Ventajas: Mejore la velocidad de ejecución de la prueba; mejore la eficiencia operativa; garantice la precisión de los resultados de la prueba; ejecute scripts de prueba continuamente; simule la situación restringida en el entorno real
    2. Desventajas: no hay garantía de que todas las actividades de prueba se puedan completar automáticamente; no hay garantía de reducir los costos de mano de obra; generalmente no está disponible de forma gratuita; no hay garantía de reducir las herramientas de prueba
  1. La diferencia entre verificación y confirmación.
    1. La verificación es el proceso mediante el cual el producto en una determinada etapa del ciclo de desarrollo del software cumple con los requisitos establecidos en la etapa anterior
    2. La validación es el proceso de evaluación del software al final del proceso de desarrollo de software para determinar si cumple con los requisitos del software.
    3. La prueba se refiere al proceso de descubrir conscientemente errores de diseño y errores de codificación en el programa mediante la ejecución del programa, y ​​la prueba es uno de los medios de verificación y confirmación.

2. Pruebas de evolución del sistema heredado

  1. Estrategia de transformación (alto nivel, alto valor): sobre la base del sistema heredado, agregar nuevas funciones o realizar mejoras
  2. Estrategia de integración (alto nivel, bajo valor): Hay islas de información aisladas, y las islas de información se abren a través de la integración.
  3. Estrategia de eliminación (nivel bajo, valor bajo)
  4. Estrategia de integración (bajo nivel, alto valor): Vuelva a desarrollar el sistema de una manera que sea totalmente compatible con el modelo funcional y el modelo de datos del sistema heredado.

3. Prueba de conversión de sistema nuevo y antiguo

  1. Conversión directa [alto riesgo, bajo costo]
  2. Conversión paralela [bajo riesgo, alto costo]: los sistemas antiguo y nuevo funcionan en paralelo durante un período de tiempo
  3. Conversión segmentada [plan de compromiso]: los nuevos sistemas se lanzan por región y los nuevos sistemas se lanzan por sistemas moleculares en etapas

4. Operación y mantenimiento del sistema

  1. Factores que afectan la mantenibilidad
    1. Comprensibilidad: es la facilidad de comprender lo que hace el software y cómo funciona mediante la lectura del código fuente y la documentación asociada.
    2. Modificabilidad: se refiere a la facilidad con la que se puede modificar el software.
    3. Capacidad de prueba: se refiere a la facilidad con la que se puede verificar que un programa de software es correcto
    4. Finalmente: el software con buena capacidad de prueba generalmente significa que el diseño del software es simple y la complejidad es baja. Porque cuanto mayor es la complejidad del software, más difícil es probarlo.
    5. Confiabilidad: Cuanto mayor sea la confiabilidad de un software, menor será la probabilidad de que necesite mantenimiento
    6. Portabilidad: se refiere a la facilidad con la que el software puede trasladarse desde un entorno para ejecutarse correctamente en un entorno nuevo. El cambio del entorno operativo del software es una situación común de mantenimiento de software, y el software con buena portabilidad reducirá la probabilidad de mantenimiento.
  1. Categorías de mantenimiento de software:
    1. Mantenimiento correctivo: identificación y corrección de errores de software (errores no encontrados durante la fase de prueba)
    2. Mantenimiento adaptativo: posibles cambios en el entorno externo (nueva configuración de hardware y software), entorno de datos (base de datos, formato de datos, medio de almacenamiento de datos). El proceso de modificar el software para adaptarlo a dichos cambios se denomina mantenimiento adaptativo.
    3. Mantenimiento de mejoras: mejorar el rendimiento o agregar funcionalidad
    4. Mantenimiento preventivo: Para el futuro, la mantenibilidad y la confiabilidad del sistema se mejoran de antemano. Como cambiar la función de informe especial a una función de generación de informe general para adaptarse a los cambios en el formato del informe en el futuro

Supongo que te gusta

Origin blog.csdn.net/qq_25580555/article/details/129669536
Recomendado
Clasificación