hogar › Instalacion y configuracion › Pruebas de productos de software. ¿Cómo probar la funcionalidad de una función que utiliza otras funciones dentro de ella? Pruebas relacionadas con cambios

Pruebas de productos de software. ¿Cómo probar la funcionalidad de una función que utiliza otras funciones dentro de ella? Pruebas relacionadas con cambios

Incluso si es tan tolerante que puede reiniciar el programa 18 veces después de una falla en media hora y solo luego arrojar el monitor directamente a la ventana, estará de acuerdo en que trabajar con este programa sería más cómodo si no "fallara". ".

¿Cómo puede asegurarse de que los casos de fallas, bloqueos o fallas al realizar las acciones necesarias del programa que ha desarrollado sean muy raros?

La respuesta exacta a esta pregunta No. Pero a lo largo de los siglos, los científicos más sabios han pensado en este tema durante años y pudieron encontrar un remedio que, si no elimina todos los errores del programa, al menos crea la ilusión de una acción para eliminarlos.

Y este remedio se llama PRUEBAS producto de software .

Según los sabios, las pruebas son una de las formas más establecidas de garantizar la calidad del desarrollo. software y está incluido en el set medios eficaces sistema moderno asegurar la calidad del producto software.

La calidad de un producto de software se caracteriza por un conjunto de propiedades que determinan qué tan "bueno" es el producto desde el punto de vista de las partes interesadas, como el cliente del producto, el patrocinador, el usuario final, los desarrolladores y evaluadores del producto, los ingenieros de soporte, el departamento de marketing. , formación y personal de ventas. Cada uno de los participantes puede tener una idea diferente sobre el producto y qué tan bueno o malo es, es decir, qué tan alta es la calidad del producto. Por lo tanto, plantear el problema de garantizar la calidad del producto da como resultado la tarea de identificar las partes interesadas, sus criterios de calidad y luego encontrar la solución óptima que satisfaga estos criterios.

¿Cuándo y quién?

Según desarrolladores experimentados, las pruebas de un producto de software deben realizarse desde el principio de su creación. Pero al mismo tiempo, los propios desarrolladores experimentados no deberían participar en las pruebas, ya que no se trata de un asunto real. El producto de software debe ser probado por empleados especialmente capacitados llamados testers, porque ni siquiera el desarrollador más experimentado podrá ver su error, incluso utilizando los últimos instrumentos ópticos.

Sin embargo, todos los desarrolladores coinciden en que probar un producto de software desde el punto de vista de la clasificación por finalidad debe dividirse en dos clases:

Pruebas funcionales
Pruebas no funcionales

Pruebas funcionales

Las pruebas funcionales significan verificar el cumplimiento de un producto de software con los requisitos funcionales especificados en las especificaciones técnicas para la creación de este producto. En pocas palabras, las pruebas funcionales verifican si el producto de software realiza todas las funciones que debería.

Entonces, finalmente decidió realizar pruebas funcionales. Examinas las especificaciones técnicas, lees los requisitos funcionales y te das cuenta de que al menos no están en el orden en que se pueden realizar las pruebas. Le sorprenderá saber que hace bastante tiempo otros ya notaron esta discrepancia y descubrieron cómo superarla.

Para realizar pruebas funcionales, el personal del departamento de control técnico está desarrollando un programa documental y una metodología para probar la funcionalidad de la aplicación (API). El documento PMI contiene una lista de escenarios de prueba de productos de software (casos de prueba) con Descripción detallada pasos. Cada paso del escenario de prueba se caracteriza por las acciones del usuario (especialista en pruebas) y los resultados esperados: la respuesta del programa a estas acciones. El programa y la metodología de prueba deben simular el funcionamiento del producto de software en modo real. Esto significa que el escenario de prueba debe construirse sobre la base de un análisis de las operaciones que realizarán los futuros usuarios del sistema, y no ser una secuencia de manipulaciones compilada artificialmente, comprensible solo para el desarrollador.

Normalmente, las pruebas funcionales se llevan a cabo en dos niveles:

Pruebas de componentes (unitarios). Pruebas de componentes individuales de un producto de software, centradas en sus características específicas, finalidad y características funcionales.
Pruebas de integración. Este tipo las pruebas se llevan a cabo después de las pruebas de los componentes y tienen como objetivo identificar defectos en la interacción de varios subsistemas a nivel de flujos de control e intercambio de datos.

Pruebas no funcionales

Las pruebas no funcionales evalúan las cualidades de un producto de software, como la ergonomía o el rendimiento.

Creo que la importancia de este tipo de pruebas es clara y no requiere justificación. Después de todo, todo el mundo entiende que si, por ejemplo, el rendimiento del sistema no es suficiente, los usuarios tendrán que esperar medio día para recibir una respuesta a sus acciones, lo que puede conducir a su hibernación masiva.

Como sugiere el nombre, las pruebas no funcionales verifican que un producto de software cumpla con los requisitos no funcionales de términos de referencia para su creación. Y, como en el caso de las pruebas funcionales, se desarrolla un programa y una metodología de prueba para las pruebas no funcionales.

Pruebas y cumplimiento de software integrado en la era ágil

El cumplimiento de los estándares de la industria no es algo que pueda descuidar o hacer más adelante; es una parte integral del proceso de desarrollo de software integrado (software). Para algunas industrias, como la aviónica, la automoción y la atención sanitaria, el cumplimiento estricto de los estándares de calidad en el desarrollo de sistemas integrados complejos y sin problemas es vital para llevar un producto al mercado. Tradicionalmente, las pruebas han desempeñado un papel importante en el desarrollo de sistemas integrados para industrias reguladas por estándares. Sin embargo, en los últimos años, las prácticas y procesos de prueba establecidos, su lugar y papel en dichos proyectos, han cambiado significativamente. Fue un cambio de juego, y cuando las reglas del juego cambian, tienes que cambiar con ellas para ganar.

Con el desarrollo constante de tecnologías nuevas y de vanguardia, las empresas necesitan ofrecer rápidamente al mercado productos que sean confiables, seguros, fáciles de usar y compatibles con otros sistemas, solo para evitar perderse en el mundo tecnológico que cambia rápidamente. En tal situación, el modelo tradicional en cascada, donde el proceso de desarrollo de software es estrictamente secuencial y las pruebas se realizan al final, se convierte en cosa del pasado. Los métodos DevOps y Agile se están volviendo cada vez más populares porque permiten a los ingenieros completar tareas que antes se sucedían simultáneamente.

Pruebas de rendimiento

Durante la fase de prueba de rendimiento, el primer paso es la prueba de carga, cuyo propósito es verificar si el sistema responderá adecuadamente a influencias externas en un modo cercano al funcionamiento de la vida real.

Además de las pruebas de carga, las pruebas se llevan a cabo en condiciones de hardware mínimo y carga máxima: pruebas de estrés, así como pruebas en condiciones de volúmenes máximos de información procesada: pruebas volumétricas.

Existe otro tipo de prueba: las pruebas de estabilidad y confiabilidad, que incluyen no solo pruebas a largo plazo de un producto de software en condiciones normales, sino también su capacidad para volver al funcionamiento normal después de cortos períodos de cargas estresantes.

Documentación para pruebas.

Como se mencionó anteriormente, las pruebas se llevan a cabo de acuerdo con el programa y la metodología de prueba, que se desarrolla de acuerdo con GOST 34.603-92.

Para realizar las pruebas, se desarrolla un caso de prueba, que debe contener datos suficientes para probar todos los modos de funcionamiento del producto de software. Normalmente, el cliente y el contratista crean conjuntamente un caso de prueba basándose en datos reales.

Para realizar todo tipo de pruebas de rendimiento, la mayoría de las veces se crea el llamado generador de datos, que permite modo automatico crear una cantidad suficiente de datos para lograr un resultado objetivo al evaluar el desempeño.

Durante las pruebas, se elabora un protocolo de prueba que contiene información sobre la finalización de todas las etapas y pasos de las pruebas y los comentarios recibidos durante las pruebas.

Si el resultado de la prueba es negativo, las deficiencias se corrigen y se vuelven a analizar.

Prueba exploratoria

Pruebas exploratorias (las pruebas ad hoc son un subtipo de pruebas funcionales. Se utilizan en proyectos de rápido crecimiento con métodos de desarrollo flexibles, donde no existen documentación ni requisitos claros. Las pruebas exploratorias son las mayores acrobacias aéreas en las pruebas de software. Las pruebas cualitativas están disponibles para especialistas altamente calificados y depende casi por completo del ejecutante, su experiencia, conocimiento (tanto en el área temática como en los métodos de prueba) y la capacidad de llegar rápidamente a la esencia.

Pruebas de estrés

La prueba de carga es el proceso de analizar el rendimiento del sistema bajo prueba bajo carga. El propósito de las pruebas de carga es determinar la capacidad de la aplicación para soportar cargas externas. Normalmente, las pruebas se llevan a cabo en varias etapas.

1. Generar scripts de prueba

Para un análisis eficaz, los escenarios deben ser lo más parecidos posible a los casos de uso reales. Es importante comprender que siempre son posibles excepciones y que incluso el plan de prueba más detallado puede no cubrir un solo caso.

2. Desarrollo de una configuración de prueba.

Al tener escenarios de prueba, es importante distribuir el orden de carga creciente. Para un análisis exitoso, es necesario identificar criterios de evaluación del desempeño (velocidad de respuesta, tiempo de procesamiento de solicitudes, etc.).

3. Realización de una prueba de prueba.

Al realizar pruebas, es importante monitorear oportunamente la ejecución de los escenarios y la respuesta del sistema bajo prueba. Emular cargas elevadas requiere una infraestructura de hardware y software seria. En algunos casos, se utilizan métodos de modelado matemático para reducir el costo del trabajo. Los datos obtenidos con cargas bajas se toman como base y son aproximados. Cuanto mayor sea el nivel de carga simulada, menor será la precisión de la estimación. Sin embargo, este método reduce significativamente los costos.

Automatización de pruebas

La característica principal de las pruebas automatizadas es la capacidad de realizar rápidamente pruebas de regresión. Las principales ventajas de la automatización (según un informe de Worksoft) son una mayor eficiencia del personal, una detección más temprana de defectos y más. alta calidad Procesos de negocios. Estas ventajas se ven compensadas por una desventaja importante: el alto costo: debido al alto costo de implementar y respaldar la automatización de pruebas, alrededor del 50% de las empresas todavía utilizan principalmente pruebas manuales.

Pruebas de usabilidad

Cualquier aplicación se crea para ser utilizada. La facilidad de uso es un indicador de calidad importante de un programa. La industria de TI conoce muchos ejemplos de proyectos que despegan después de una solución exitosa de usabilidad. Cuanto más amplia sea la audiencia, más importante será el factor de usabilidad. Las pruebas de usabilidad implican un análisis detallado del comportamiento del usuario. Para evaluar la ergonomía, es importante tener datos no sólo sobre la velocidad con la que se completa una tarea empresarial, sino también sobre las emociones, las expresiones faciales y el timbre de voz del usuario.

Pruebas de configuración

Las pruebas de configuración brindan confianza en que la aplicación funcionará en diferentes plataformas y, por lo tanto, para la cantidad máxima de usuarios. Para aplicaciones WEB, generalmente se eligen las pruebas entre navegadores. Para aplicaciones de Windows: pruebas en varios sistemas operativos y tamaños de bits (x86, x64). Un componente importante de las pruebas de configuración es la infraestructura de pruebas: para realizar pruebas, es necesario mantener constantemente una flota de máquinas de prueba. Su número varía de 5 a varias docenas.

Pruebas de integración

Si su proyecto tiene más de un componente, necesita pruebas de integración. Con una arquitectura de aplicación compleja, una condición necesaria para garantizar la calidad es comprobar la interacción de las partes del programa. Las pruebas se logran mediante el desarrollo y la realización de casos "de un extremo a otro". Las pruebas de integración se llevan a cabo después de las pruebas de componentes. Por tanto, es muy importante tener en cuenta la experiencia en pruebas de componentes, respetando la orientación empresarial de los casos de prueba.

Pruebas de estrés

Cada sistema tiene un límite. funcionamiento normal. Cuando se excede el límite, el sistema entra en un estado de estrés y cambia significativamente su comportamiento. Las pruebas de estrés prueban el funcionamiento de una aplicación en condiciones que exceden los límites de funcionamiento normal. Esto es especialmente importante para los programas "críticos": software bancario, programas de la industria de la aviación, medicina. Las pruebas de estrés se llevan a cabo no sólo en la etapa de desarrollo del software, sino también durante todo el ciclo operativo para obtener y procesar datos del comportamiento del sistema durante un largo período de tiempo.

Supongamos que hay una función de obtención de datos., que devuelve un mapa de información sobre el ID de usuario que pasó. Ahora bien, esta función utiliza 3 funciones fuente-a, fuente-b y fuente-c para producir tres tipos diferentes de mapas. Ahora combinaremos todos estos mapas en uno solo y regresaremos de get-data.

Cuando pruebo obtener datos¿Debo verificar la disponibilidad de datos para las claves? ¿Tiene sentido que esta función falle las pruebas unitarias si falla una de fuente-a, fuente-b y fuente-c? Si el trabajo de esa función es unir datos, y lo hace, debería ser suficiente, ¿verdad?

2 respuestas

Supongamos que hay una función de obtención de datos que devuelve un mapa de información sobre el ID de usuario al que se le pasó.

Excelente. Entonces deberías comprobarlo. Para una identificación determinada, ¿estás devolviendo los datos correctos?

ahora esta función usa 3 funciones fuente-a, fuente-b y fuente-c para producir tres tipos diferentes de mapas.

¿Qué detalle de implementación debería ignorar en la prueba? Todo lo que está probando es que su unidad de trabajo (este método) hace lo que se supone que debe hacer (tomar una identificación y devolver datos XYZ para esa identificación). Cómo este método realmente no importa; después de todo, el beneficio clave de esta prueba unitaria es que puedes refactorizar la implementación del método y la prueba comprobará que lo hiciste correctamente.

Sin embargo, probablemente tendrás que burlarte de las fuentes de datos, por lo que en algún momento la prueba probablemente necesitará saber cómo funciona este código. Aquí es necesario equilibrar tres objetivos en competencia: hacer que la prueba sea aislada (burlándose de los datos) y, al mismo tiempo, hacer que la prueba se centre en los requisitos y el pragmatismo.

Después de todo, este es un código importante. Hay pruebas para respaldar el código real, lo que requiere mucho tiempo y la molestia de verificar el pulido no es tan útil como las pruebas. haciendo .

En las pruebas unitarias, solo debe probar la funcionalidad de una clase; si sus métodos fuente-a, fuente-b y fuente-c llaman a otras clases, debe burlarse de ellas (deben probarse unitariamente en sus clases).

En las pruebas de integración, está probando el comportamiento de múltiples clases que interactúan entre ellas, esto significa que su función get-data debe verificar que los datos que se están recuperando sean correctos (fuente-a, fuente-b y fuente-c son correctos y los datos están conectados correctamente).

Las pruebas unitarias son más simples y enfocadas y deben ser escritas por desarrolladores. Las pruebas de integración suelen quedar obsoletas con relativa rapidez (si las hay). componente interno ha sido cambiado), haciéndolos más difíciles de realizar. Debe ser creado por un perfil de control de calidad.

¿Cómo puede asegurarse de que los casos de fallas, bloqueos o fallas al realizar las acciones necesarias del programa que ha desarrollado sean muy raros?

No hay una respuesta exacta a esta pregunta. Pero a lo largo de los siglos, los científicos más sabios han pensado en este tema durante años y pudieron encontrar un remedio que, si no elimina todos los errores del programa, al menos crea la ilusión de una acción para eliminarlos.

Y este remedio se llama PRUEBA del producto de software.

Según los sabios, las pruebas son una de las formas más establecidas de garantizar la calidad del desarrollo de software y forman parte del conjunto de herramientas eficaces de un sistema moderno de garantía de calidad de los productos de software.

¿Cuándo y quién?

Sin embargo, todos los desarrolladores coinciden en que probar un producto de software desde el punto de vista de la clasificación por finalidad debe dividirse en dos clases:

Pruebas funcionales
Pruebas no funcionales

Pruebas funcionales

Para realizar pruebas funcionales, el personal del departamento de control técnico está desarrollando un programa documental y una metodología para probar la funcionalidad de la aplicación (API). El documento PMI contiene una lista de escenarios de prueba de productos de software (casos de prueba) con una descripción detallada de los pasos. Cada paso del escenario de prueba se caracteriza por las acciones del usuario (especialista en pruebas) y los resultados esperados: la respuesta del programa a estas acciones. El programa y la metodología de prueba deben simular el funcionamiento del producto de software en modo real. Esto significa que el escenario de prueba debe construirse sobre la base de un análisis de las operaciones que realizarán los futuros usuarios del sistema, y no ser una secuencia de manipulaciones compilada artificialmente, comprensible solo para el desarrollador.

Normalmente, las pruebas funcionales se llevan a cabo en dos niveles:

Pruebas de componentes (unitarios). Pruebas de componentes individuales de un producto de software, centradas en sus características específicas, finalidad y características funcionales.
Pruebas de integración. Este tipo de prueba se lleva a cabo después de la prueba de los componentes y tiene como objetivo identificar defectos en la interacción de varios subsistemas a nivel de flujos de control e intercambio de datos.

Pruebas no funcionales

Las pruebas no funcionales evalúan las cualidades de un producto de software, como la ergonomía o el rendimiento.

Como sugiere el nombre, las pruebas no funcionales verifican el cumplimiento de un producto de software con los requisitos no funcionales de las especificaciones técnicas para su creación. Y, como en el caso de las pruebas funcionales, se desarrolla un programa y una metodología de prueba para las pruebas no funcionales.

Pruebas y cumplimiento de software integrado en la era ágil

Pruebas de rendimiento

Documentación para pruebas.

Como se mencionó anteriormente, las pruebas se llevan a cabo de acuerdo con el programa y la metodología de prueba, que se desarrolla de acuerdo con GOST 34.603-92.

Para realizar todo tipo de pruebas de rendimiento, la mayoría de las veces se crea el llamado generador de datos, que le permite crear automáticamente una cantidad suficiente de datos para lograr un resultado objetivo al evaluar el rendimiento.

Durante las pruebas, se elabora un protocolo de prueba que contiene información sobre la finalización de todas las etapas y pasos de las pruebas y los comentarios recibidos durante las pruebas.

Si el resultado de la prueba es negativo, las deficiencias se corrigen y se vuelven a analizar.

Prueba exploratoria

Pruebas de estrés

1. Generar scripts de prueba

2. Desarrollo de una configuración de prueba.

3. Realización de una prueba de prueba.

Automatización de pruebas

La característica principal de las pruebas automatizadas es la capacidad de realizar rápidamente pruebas de regresión. Las principales ventajas de la automatización (según un informe de Worksoft) son una mayor eficiencia del personal, una detección más temprana de defectos y una mayor calidad de los procesos comerciales. Estas ventajas se ven compensadas por una desventaja importante: el alto costo: debido al alto costo de implementar y respaldar la automatización de pruebas, alrededor del 50% de las empresas todavía utilizan principalmente pruebas manuales.

Pruebas de usabilidad

Pruebas de configuración

Las pruebas de configuración brindan confianza en que la aplicación funcionará en diferentes plataformas y, por lo tanto, para la cantidad máxima de usuarios. Para aplicaciones WEB, generalmente se eligen las pruebas entre navegadores. Para aplicaciones de Windows: pruebas en varios sistemas operativos y velocidades de bits (x86, x64). Un componente importante de las pruebas de configuración es la infraestructura de pruebas: para realizar pruebas, es necesario mantener constantemente una flota de máquinas de prueba. Su número varía de 5 a varias docenas.

Pruebas de integración

Pruebas de estrés

Cualquier sistema tiene un límite para su funcionamiento normal. Cuando se excede el límite, el sistema entra en un estado de estrés y cambia significativamente su comportamiento. Las pruebas de estrés prueban el funcionamiento de una aplicación en condiciones que exceden los límites de funcionamiento normal. Esto es especialmente importante para los programas "críticos": software bancario, programas de la industria de la aviación, medicina. Las pruebas de estrés se llevan a cabo no sólo en la etapa de desarrollo del software, sino también durante todo el ciclo operativo para obtener y procesar datos del comportamiento del sistema durante un largo período de tiempo.

Entre todos los tipos, las pruebas funcionales ocupan legítimamente una posición de liderazgo, ya que, en primer lugar, el programa debe funcionar correctamente; de lo contrario, la facilidad de uso, la seguridad y la velocidad suficiente no servirán de nada. Además de dominar diversas técnicas de prueba, cada especialista debe saber cómo realizar una prueba correctamente para obtener el resultado más eficaz.

Pruebas funcionales: ¿hacia dónde dirigir los principales esfuerzos?

Para pruebas de unidades y sistemas;

Para marcar la casilla “blanca” o “negra”;

Para pruebas manuales y automatización;

Para probar nuevas funciones o;

Para pruebas “negativas” o “positivas”.

Entre todas estas áreas de actividad, es importante encontrar el camino correcto, que será el “medio”, para poder equilibrar los esfuerzos, aprovechando al máximo las ventajas de cada una de las áreas.

Se lleva a cabo la verificación del software. diferentes caminos, uno de los cuales son las pruebas de caja negra o basadas en datos.

En este caso, el programa se presenta desde el punto de vista de una "caja negra" y la prueba se lleva a cabo para determinar las circunstancias en las que el comportamiento del programa no cumplirá con la especificación. Todos los errores se identifican mediante la gestión de datos, que se realiza mediante pruebas exhaustivas, es decir, utilizando todos los medios posibles.

Si para un programa la ejecución de un comando depende de los eventos que lo preceden, entonces será necesario verificar todas las secuencias posibles. Es bastante obvio que en la mayoría de los casos es simplemente imposible realizar pruebas exhaustivas, por lo que más a menudo se elige una opción aceptable o razonable que se limita a ejecutar el programa en un pequeño subconjunto de todos los datos de entrada. Esta opción garantiza totalmente que no se produzcan desviaciones de las especificaciones.

Las pruebas funcionales implican elegir la prueba adecuada. Al mismo tiempo, se acostumbra distinguir entre los siguientes métodos de generación de grupos para ellos:

Análisis de valor límite;

Partición equivalente;

Suposición de error;

Análisis de conexiones entre causas y efectos.

Puedes considerar cada uno de ellos por separado.

Análisis de valor límite. Se suele entender por valores límite aquellos situados en los límites de las clases de equivalencia. En esos lugares lo más probable es que encuentre un error. El uso de este método requiere cierta creatividad por parte del especialista, así como especialización en el problema específico que se está considerando.

Partición equivalente. Todos los conjuntos posibles de parámetros de entrada se dividen en varias clases de equivalencia. Los datos se combinan según el principio de detección de errores similares. Generalmente se acepta que si un conjunto de una clase muestra un error, los equivalentes también lo indicarán. Pruebas funcionales por este método se lleva a cabo en dos etapas: en la primera se identifican las clases de equivalencia y en la segunda ya se forman pruebas especiales.

Análisis de relaciones de causa y efecto. El sistema puede seleccionar pruebas con alto rendimiento mediante la realización de dichas comprobaciones. En este caso, se toma como causa una condición de entrada separada y se considera la condición de salida como efecto. El método se basa en la idea de atribuir todo tipo de causas a determinadas consecuencias, es decir, en aclarar esas mismas relaciones causa-efecto. Las pruebas de un producto de software se llevan a cabo en varias etapas, lo que da como resultado una lista de causas y consecuencias consiguientes.

desviaciones involuntarias de los desarrolladores de los estándares de trabajo o planes de implementación;
las especificaciones de los requisitos funcionales y de interfaz se realizan sin cumplir con los estándares de desarrollo, lo que conduce a la interrupción del funcionamiento de los programas;
organización del proceso de desarrollo: gestión imperfecta o insuficiente de los recursos del director del proyecto (humanos, técnicos, software, etc.) y cuestiones de prueba e integración de los elementos del proyecto.

Veamos el proceso de prueba basado en las recomendaciones de la norma ISO/IEC 12207 y describamos los tipos de errores que se detectan en cada proceso del ciclo de vida.

Proceso de desarrollo de requisitos. Al determinar el concepto inicial del sistema y los requisitos iniciales del sistema, los analistas cometen errores de especificación. nivel superior sistemas y construcción de un modelo conceptual del área temática.

Los errores típicos en este proceso son:

insuficiencia de la especificación de requisitos para los usuarios finales; - especificación incorrecta de la interacción del software con el entorno operativo o con los usuarios;
incumplimiento de los requisitos del cliente para propiedades de software individuales y generales;
descripción incorrecta de características funcionales;
falta de disponibilidad de herramientas para todos los aspectos de la implementación de los requisitos del cliente, etc.

Proceso de diseño.Pueden ocurrir errores en el diseño de componentes al describir algoritmos, lógica de control, estructuras de datos, interfaces, lógica de modelado de flujo de datos, formatos de entrada-salida, etc. Estos errores se basan en defectos en las especificaciones de los analistas y fallas de diseño. Estos incluyen errores relacionados con:

con la definición de la interfaz del usuario con el entorno;
con una descripción de las funciones (insuficiencia de las metas y objetivos de los componentes, que se descubre al verificar un conjunto de componentes);
con la definición del proceso de procesamiento de información y la interacción entre procesos (el resultado de una determinación incorrecta de las relaciones entre componentes y procesos);
con especificación incorrecta de datos y sus estructuras al describir componentes individuales y el software en su conjunto;
con descripción incorrecta de los algoritmos del módulo;
con determinación de las condiciones de ocurrencia posibles errores en un programa;
en violación de los estándares y tecnologías adoptadas para el proyecto.

Etapa de codificación.En esta etapa surgen errores que son consecuencia de defectos de diseño, errores de programadores y gerentes durante el desarrollo y depuración del sistema. Las causas de los errores son:

falta de control sobre los valores de los parámetros de entrada, índices de matriz, parámetros de bucle, resultados de salida, división por 0, etc.;
manejo incorrecto de situaciones irregulares al analizar códigos de retorno de subrutinas llamadas, funciones, etc.;
violación de los estándares de codificación (malos comentarios, comentarios irracionales) asignación de módulos y componente, etc.);
el uso de un nombre para designar diferentes objetos o diferentes nombres de un objeto, mnemónicos de nombres deficientes; - cambios inconsistentes en el programa por parte de diferentes desarrolladores, etc.

Proceso de prueba.En este proceso, los programadores y probadores cometen errores al realizar tecnología de ensamblaje y prueba, seleccionar conjuntos de prueba y escenarios de prueba, etc. Las fallas en el software causadas por este tipo de errores deben identificarse, eliminarse y no afectar las estadísticas de los componentes y Errores de software en general.

Proceso de mantenimiento.Durante el proceso de mantenimiento se descubren errores causados por deficiencias y defectos en la documentación operativa, indicadores insuficientes de modificabilidad y legibilidad, así como por la incompetencia de las personas responsables del mantenimiento y/o mejora del software. Dependiendo de la naturaleza de los cambios que se realicen, en esta etapa pueden ocurrir casi todos los errores similares a los errores enumerados anteriormente en las etapas anteriores.

Todos los errores que ocurren en los programas generalmente se dividen en las siguientes clases [7.12]:

errores lógicos y funcionales;
errores de cálculo y tiempo de ejecución;
errores de entrada/salida y manipulación de datos;
errores de interfaz;
errores de volumen de datos, etc.

Errores lógicos son la causa de la violación de la lógica del algoritmo, la inconsistencia interna de variables y operadores, así como las reglas de programación. Los errores funcionales son consecuencia de funciones definidas incorrectamente, violación del orden de su aplicación o falta de integridad de su implementación, etc.

Errores de cálculo surgen debido a la inexactitud de los datos de origen y las fórmulas implementadas, errores de método, aplicación incorrecta de operaciones de cálculo u operandos. Los errores de tiempo de ejecución están asociados con la imposibilidad de proporcionar la velocidad de procesamiento de solicitudes requerida o el tiempo de recuperación del programa.

errores de E/S y la manipulación de datos son consecuencia de una mala preparación de los datos para la ejecución del programa, fallas al ingresarlos en las bases de datos o al recuperarlos de ellas.

Errores de interfaz se refieren a errores en la relación de elementos individuales entre sí, que se manifiesta durante la transferencia de datos entre ellos, así como durante la interacción con el entorno operativo.

Errores de volumen se relacionan con datos y son consecuencia del hecho de que los métodos de acceso implementados y los tamaños de las bases de datos no satisfacen los volúmenes reales de información del sistema o la intensidad de su procesamiento.

Las principales clases de errores indicadas son características de diferentes tipos de componentes de software y se manifiestan en los programas de diferentes maneras. Así, al trabajar con una base de datos se producen errores en la presentación y manipulación de los datos, errores lógicos en la especificación de procedimientos de procesamiento de datos aplicados, etc. En los programas computacionales predominan los errores computacionales, y en los programas de control y procesamiento predominan los errores lógicos y funcionales. El software, que consta de muchos programas diversos que implementan diferentes funciones, puede contener errores diferentes tipos. Los errores de interfaz y las violaciones de volumen son típicos de cualquier tipo de sistema.

Analizar los tipos de errores en los programas es un requisito previo para crear planes de prueba y métodos de prueba para garantizar la corrección del software.

En la etapa actual de desarrollo de herramientas de soporte al desarrollo de software (tecnologías CASE, métodos orientados a objetos y herramientas para el diseño de modelos y programas), se realiza un diseño en el que se protege el software de los errores más comunes y con ello se previene la aparición de defectos de software.

Relación entre error y fracaso.La presencia de un error en un programa, por regla general, provoca un fallo del software durante su funcionamiento. Para analizar las relaciones causa-efecto del “error-fallo”, se realizan las siguientes acciones:

identificación de fallas en tecnologías de diseño y programación;
la relación entre fallas en el proceso de diseño y errores humanos;
clasificación de fallas, fallas y posibles errores, así como defectos en cada etapa de desarrollo; - comparación de errores humanos cometidos en un determinado proceso de desarrollo y defectos en el objeto, como consecuencia de errores en la especificación del proyecto, modelos de programa;
verificación y protección contra errores en todas las etapas del ciclo de vida, así como detección de defectos en cada etapa de desarrollo;
comparación de defectos y fallos en software para desarrollar un sistema de interconexiones y métodos para localizar, recopilar y analizar información sobre fallos y defectos;
desarrollo de enfoques para los procesos de documentación y prueba de software.

El objetivo final de la causalidad de errores y fallas es definir métodos y medios para probar y detectar errores de ciertas clases, así como criterios para completar las pruebas en múltiples conjuntos de datos; en la identificación de formas de mejorar la organización del proceso de desarrollo, prueba y mantenimiento de software.

A continuación se presenta la siguiente clasificación de tipos de fallas:

hardware, en el que el software de todo el sistema no funciona;
informativo, causado por errores en los datos de entrada y la transmisión de datos a través de canales de comunicación, así como por fallas de los dispositivos de entrada (como consecuencia de fallas de hardware);
ergonómico, causado por errores del operador durante su interacción con la máquina (este fallo es un fallo secundario y puede provocar fallos de información o funcionales);
software, si hay errores en componentes, etc.

Algunos errores pueden ser el resultado de deficiencias en la definición de requisitos, el diseño, la generación del código de salida o la documentación. Por otro lado, se generan durante el desarrollo de un programa o durante el desarrollo de interfaces de elementos individuales del programa (violación del orden de los parámetros, menos o más parámetros, etc.).

Fuentes de errores.Se pueden generar errores durante el desarrollo del proyecto, componentes, código y documentación. Como regla general, se descubren durante la ejecución o el mantenimiento del software en los puntos más inesperados y diferentes.

Algunos errores en un programa pueden ser el resultado de deficiencias en la definición de requisitos, el diseño, la generación de código o la documentación. Por otro lado, los errores se generan durante el desarrollo de un programa o de las interfaces de sus elementos (por ejemplo, cuando se viola el orden de configuración de los parámetros de comunicación - menos o más de lo requerido, etc.).

El motivo de los errores es la falta de comprensión de los requisitos del cliente; especificación inexacta de los requisitos en los documentos del proyecto, etc. Esto lleva al hecho de que se implementan algunas funciones del sistema que no funcionarán según lo propuesto por el cliente. En este sentido, se lleva a cabo una discusión conjunta entre el cliente y el desarrollador de algunos detalles de los requisitos para aclararlos.

El equipo de desarrollo del sistema también puede cambiar la sintaxis y la semántica de la descripción del sistema. Sin embargo, es posible que no se detecten algunos errores (por ejemplo, los índices o valores variables de estas declaraciones están configurados incorrectamente).

Popular en la categoría: