hogar › Instalación y configuración › Pruebas de productos de software. ¿Cómo verificar la funcionalidad de una función que usa otras funciones en ella? Pruebas relacionadas con cambios

Pruebas de productos de software. ¿Cómo verificar la funcionalidad de una función que usa otras funciones en ella? Pruebas relacionadas con cambios

Incluso si eres tan tolerante que puedes reiniciar el programa 18 veces después de una falla dentro de media hora y solo después de eso arrojar el monitor exactamente a la ventana, estarás de acuerdo en que trabajar con este programa sería más cómodo si no lo hiciera. caer”.

¿Cómo hacer que los casos de caída, congelamiento, falla en la realización de las acciones necesarias del programa desarrollado por usted se vuelvan muy raros?

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

Y esta herramienta se llama Pruebas de productos de software.

Según los sabios, las pruebas son una de las formas más establecidas para garantizar la calidad del desarrollo. software y se incluye en un conjunto de herramientas eficaces sistema moderno aseguramiento de la calidad del producto de software.

La calidad de un producto de software se caracteriza por un conjunto de propiedades que determinan cuán "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, el soporte ingenieros, 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. Así, la formulación del problema de asegurar la calidad del producto se traduce en la tarea de identificar a los stakeholders, sus criterios de calidad y luego encontrar la solución óptima que cumpla con estos criterios.

¿Cuándo y quién?

Según los desarrolladores experimentados, las pruebas de un producto de software deben llevarse a cabo desde el principio de su creación. Pero al mismo tiempo, los propios desarrolladores experimentados no deberían participar en las pruebas, ya que este no es un negocio real. Empleados especialmente capacitados, llamados probadores, deben probar el producto de software, porque incluso el desarrollador más experimentado no podrá ver su error, incluso utilizando los instrumentos ópticos más modernos.

Sin embargo, todos los desarrolladores están de acuerdo en que probar un producto de software en términos de clasificación por objetivos debe dividirse en dos clases:

Pruebas funcionales
Pruebas no funcionales

Pruebas funcionales

Se entiende por prueba funcional la verificación de la conformidad de un producto de software con los requisitos funcionales especificados en los términos de referencia 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, decidió realizar pruebas funcionales. Miras los términos de referencia, lees los requisitos funcionales y entiendes que al menos no están en el orden en que puedes probar. Te sorprenderá saber que hace mucho tiempo, otros ya notaron esta discrepancia y descubrieron cómo superarla.

Para realizar las pruebas funcionales, el personal del departamento de control técnico desarrolla un programa de documentos y un método 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 script 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 que solo sea comprensible para el desarrollador.

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

Pruebas de componentes (unidades). Pruebas de componentes individuales de un producto de software, enfocadas en sus detalles, propósito y características funcionales.
Pruebas de integración. Este tipo la prueba se lleva a cabo después de la prueba de 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 cualidades de un producto de software como, por ejemplo, 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, todos entienden que si, por ejemplo, el rendimiento del sistema no es suficiente, los usuarios tendrán que esperar medio día para obtener una respuesta a sus acciones, lo que puede conducir a su hibernación masiva.

Como su nombre lo indica, las pruebas no funcionales verifican que el producto de software cumpla con los requisitos no funcionales del términos de referencia a 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 de software integrado y cumplimiento en la era de Agile

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 (SW). Para algunas industrias, como la aviónica, la automotriz y la atención médica, el cumplimiento estricto de los estándares de calidad en el desarrollo de sistemas integrados complejos y sin problemas se está convirtiendo en una condición vital para llevar un producto al mercado. Tradicionalmente, las pruebas han desempeñado un papel importante en el desarrollo de sistemas integrados para industrias basadas en estándares. Sin embargo, en los últimos años, las prácticas establecidas y los procesos de prueba, su lugar y función en este tipo de proyectos han cambiado significativamente. Ha cambiado drásticamente todas las reglas del juego, y cuando las reglas del juego cambian, tienes que cambiar con ellas para poder ganar.

Con tecnologías nuevas y de vanguardia en constante evolución, las empresas necesitan lanzar rápidamente productos al mercado que sean confiables, seguros, fáciles de usar e interoperables, solo para no perderse en el ritmo acelerado. mundo de la tecnología. En tal situación, el modelo de cascada tradicional, donde el proceso de desarrollo de software es estrictamente secuencial y las pruebas se realizan al final, se está convirtiendo en una cosa del pasado. Los métodos DevOps y Agile están ganando popularidad, ya que permiten a los ingenieros realizar tareas que solían seguirse al mismo tiempo.

Pruebas de rendimiento

Durante la fase de prueba de rendimiento, en primer lugar, se lleva a cabo la prueba de carga, cuyo objetivo es comprobar si el sistema responderá adecuadamente a las influencias externas en un modo cercano al modo de funcionamiento real.

Además de las pruebas de carga, se realizan pruebas en condiciones de mínimo hardware y máxima carga - stress testing, así como pruebas en condiciones de máximos volúmenes de información procesada - volumen testing.

Existe otro tipo de prueba: la prueba de estabilidad y confiabilidad, que incluye no solo una prueba a largo plazo de un producto de software en condiciones normales, sino también su capacidad para volver a funcionar normalmente después de períodos cortos de carga de estrés.

Documentación para la prueba

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

Desarrollado para pruebas caso de prueba, que debe contener suficientes datos para comprobar todos los modos de funcionamiento del producto de software. Por lo general, el cliente y el contratista crean conjuntamente un caso de prueba basado en datos reales.

Para realizar todo tipo de pruebas de rendimiento, lo más frecuente es crear un llamado generador de datos, que le permite modo automatico crear suficientes datos para lograr un resultado objetivo al evaluar el desempeño.

Durante la prueba, se elabora un protocolo de prueba, donde se ingresa información sobre el paso de todas las etapas y pasos de la prueba y los comentarios recibidos durante las pruebas.

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

Prueba exploratoria

Pruebas exploratorias (las pruebas ad hoc son una subespecie de las pruebas funcionales. Se utilizan en proyectos de rápido crecimiento con métodos de desarrollo flexibles, donde no hay documentación ni requisitos claros. Las pruebas exploratorias son el pináculo de las pruebas de software. Hay pruebas de alta calidad disponibles a especialistas altamente calificados y depende casi por completo del ejecutante, su experiencia, conocimiento (tanto en el área temática como en métodos de prueba), la capacidad de penetrar rápidamente en la esencia.

Pruebas de estrés

La prueba de carga es el proceso de analizar el rendimiento del sistema bajo prueba bajo la influencia de las cargas. El objetivo de las pruebas de carga es determinar la capacidad de una aplicación para soportar cargas externas. Por lo general, las pruebas se llevan a cabo en varias etapas.

1. Generación de scripts de prueba

Para un análisis efectivo, los escenarios deben estar lo más cerca posible de los casos de uso reales. Es importante comprender que las excepciones siempre son posibles, e 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 resaltar los criterios para evaluar el desempeño (velocidad de respuesta, tiempo de procesamiento de solicitudes, etc.).

3. Realización de una prueba de funcionamiento

Al realizar pruebas, es importante monitorear la ejecución de scripts y la respuesta del sistema bajo prueba de manera oportuna. Para emular cargas elevadas, se 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 a bajas cargas se toman como base y se aproximan. 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 el 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 contrarrestadas por una desventaja significativa: alto costo: debido al alto costo de implementar y mantener la automatización de pruebas, alrededor del 50 % de las empresas aún utilizan principalmente pruebas manuales.

Pruebas de usabilidad

Cada aplicación está diseñada para ser utilizada. La facilidad de uso es un indicador de calidad importante del programa. La industria de TI conoce muchos ejemplos de proyectos que despegan después de una solución de usabilidad exitosa. 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 solo sobre la velocidad de completar una tarea comercial, 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 dan confianza de que la aplicación funcionará en diferentes plataformas, lo que significa para la mayor cantidad de usuarios. Para las aplicaciones WEB, generalmente se elige la prueba de compatibilidad entre navegadores. Para aplicaciones de Windows: pruebas en varios sistemas operativos y bitness (x86, x64). Un componente importante de las pruebas de configuración es la infraestructura de prueba: para las pruebas, debe 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 entre las partes del programa. La prueba se logra mediante el desarrollo y la realización de casos "a través". Las pruebas de integración se llevan a cabo después de las pruebas de los componentes. Por lo tanto, es muy importante tener en cuenta la experiencia de las pruebas de componentes, respetando la orientación comercial de los casos de prueba.

pruebas de estrés

Todo 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 comprueban el rendimiento de la aplicación en condiciones de superar 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 y medicina. Las pruebas de estrés se realizan no solo en la etapa de desarrollo del software, sino también a lo largo de todo el ciclo de operación con el fin de obtener y procesar datos sobre el 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 esta función usa las 3 funciones source-a , source-b y source-c para obtener tres tipos diferentes de mapas. Ahora combinaremos todos estos mapas en un solo mapa y regresaremos de get-data.

Cuando pruebo get-data, ¿debo verificar la existencia de datos para las claves? ¿Tiene sentido que esta función falle las pruebas unitarias si falla una de source-a , source-b y source-c? Si el trabajo de la función thats es unir los datos, y lo hace, eso debería ser suficiente, ¿no?

2 respuestas

Supongamos que hay una función de obtención de datos que devuelve un mapa de información sobre la identificación del usuario que se pasó.

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

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

¿Qué detalle de implementación debe ignorar en una 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 los 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 puede refactorizar la implementación del método y la prueba verificará que lo hizo bien.

Sin embargo, probablemente tendrá que simular fuentes de datos, por lo que en algún momento la prueba probablemente necesitará saber cómo funciona este código. Aquí debe equilibrar tres objetivos en competencia: hacer que la prueba sea aislada (simulando los datos), 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 hacer una copia de seguridad del código real, gastar mucho tiempo y la molestia de revisar 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 source-a, source-b y source-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, lo que significa que su función de obtención de datos debe verificar que los datos que se están recuperando sean correctos (fuente-a, fuente-b y fuente-c son correctos y los datos se unen correctamente).

Las pruebas unitarias son más simples y más enfocadas, y deben ser creadas por desarrolladores. Las pruebas de integración generalmente se vuelven obsoletas con relativa rapidez (si las hay). componente interno se ha cambiado), por lo que son más difíciles de realizar. Debe ser creado por un perfil de control de calidad.

¿Cómo hacer que los casos de caída, congelamiento, falla en la realización de las acciones necesarias del programa desarrollado por usted se vuelvan muy raros?

Y esta herramienta se llama Pruebas de productos de software.

Según los sabios, las pruebas son una de las formas más establecidas para garantizar la calidad del desarrollo de software y se incluyen en el conjunto de herramientas efectivas de un sistema moderno de garantía de calidad de software.

¿Cuándo y quién?

Sin embargo, todos los desarrolladores están de acuerdo en que probar un producto de software en términos de clasificación por objetivos debe dividirse en dos clases:

Pruebas funcionales
Pruebas no funcionales

Pruebas funcionales

Para realizar las pruebas funcionales, el personal del departamento de control técnico desarrolla un programa de documentos y un método 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 script 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 que solo sea comprensible para el desarrollador.

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

Pruebas de componentes (unidades). Pruebas de componentes individuales de un producto de software, enfocadas en sus detalles, propósito y características funcionales.
Pruebas de integración. Este tipo de prueba se lleva a cabo después de la prueba de 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 cualidades de un producto de software como, por ejemplo, la ergonomía o el rendimiento.

Como su nombre lo indica, las pruebas no funcionales verifican el cumplimiento de un producto de software con los requisitos no funcionales de los 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 de software integrado y cumplimiento en la era de Agile

Pruebas de rendimiento

Documentación para la prueba

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

Para las pruebas, se desarrolla un caso de prueba, que debe contener suficientes datos para probar todos los modos de operación del producto de software. Por lo general, el cliente y el contratista crean conjuntamente un caso de prueba basado en datos reales.

Para realizar todo tipo de pruebas de rendimiento, lo más frecuente es crear un 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 la prueba, se elabora un protocolo de prueba, donde se ingresa información sobre el paso de todas las etapas y pasos de la prueba y los comentarios recibidos durante las pruebas.

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

Prueba exploratoria

Pruebas de estrés

1. Generación de scripts de prueba

2. Desarrollo de una configuración de prueba

3. Realización de una prueba de funcionamiento

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 el informe de la empresa 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 contrarrestadas por una desventaja significativa: alto costo: debido al alto costo de implementar y mantener la automatización de pruebas, alrededor del 50 % de las empresas aún utilizan principalmente pruebas manuales.

Pruebas de usabilidad

Pruebas de configuración

Pruebas de integración

pruebas de estrés

Cualquier sistema tiene un límite de 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 comprueban el rendimiento de la aplicación en condiciones de superar 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 y medicina. Las pruebas de estrés se realizan no solo en la etapa de desarrollo del software, sino también a lo largo de todo el ciclo de operación con el fin de obtener y procesar datos sobre el comportamiento del sistema durante un largo período de tiempo.

Entre todos los tipos de pruebas funcionales, ocupa legítimamente una posición de liderazgo, ya que el programa debe funcionar correctamente en primer lugar, de lo contrario, la facilidad de uso, la seguridad y la velocidad suficiente no tendrán ningún sentido. Además de dominar varias técnicas de prueba, cada especialista debe comprender cómo probar correctamente para obtener el resultado más efectivo.

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 una nueva funcionalidad o;

En pruebas "negativas" o "positivas".

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

La verificación del software se lleva a cabo diferentes caminos, una de las cuales es la prueba de caja negra o basada en datos.

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

Si para un programa la ejecución de un comando depende de los eventos que lo preceden, entonces se requerirá una verificación de todas las secuencias posibles. Es bastante obvio que para la mayoría de los casos es simplemente imposible realizar pruebas exhaustivas, por lo que con mayor frecuencia eligen 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 completamente la ausencia de desviaciones de las especificaciones.

Las pruebas funcionales implican la elección correcta de la prueba. Al mismo tiempo, se acostumbra distinguir entre tales métodos de formación de conjuntos para ellos:

análisis de valor límite;

partición equivalente;

Suposición de error;

Análisis de relaciones entre causas y efectos.

Puedes considerar cada uno de ellos por separado.

Análisis de valores límite. Los valores límite suelen entenderse como aquellos situados en los límites de las clases de equivalencia. En tales lugares, es más probable encontrar un error. El uso de tal método requiere cierta creatividad por parte del especialista, así como especialización en este problema particular en consideración.

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 detecta 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 seleccionan las clases de equivalencia, y en la segunda, ya se forman las pruebas especiales.

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

desviación involuntaria de los desarrolladores de los estándares de trabajo o planes de implementación;
las especificaciones de los requisitos funcionales y de interfaz se ejecutan sin observar los estándares de desarrollo, lo que conduce a una interrupción en el funcionamiento de los programas;
organización del proceso de desarrollo: gestión imperfecta o insuficiente por parte del director del proyecto de los recursos (humanos, técnicos, software, etc.) y problemas de prueba e integración de los elementos del proyecto.

Consideremos el proceso de prueba según las recomendaciones del estándar ISO/IEC 12207 y enumeremos los tipos de errores que se encuentran en cada proceso del ciclo de vida.

Proceso de desarrollo de requisitos. Al determinar el concepto inicial del sistema y los requisitos iniciales para el sistema, los errores del analista ocurren durante la especificación. nivel superior sistemas y construir un modelo conceptual del área temática.

Los errores típicos de 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;
discrepancia entre los requisitos del cliente para propiedades de software individuales y generales;
descripción incorrecta de las características funcionales;
falta 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 para modelar flujos de datos, formatos de entrada-salida, etc. Estos errores se basan en defectos en las especificaciones de los analistas y fallas en los diseñadores. Estos incluyen errores relacionados con:

con la definición de la interfaz del usuario con el entorno;
con una descripción de las funciones (inadecuación de las metas y objetivos de los componentes que se detectan al verificar el complejo de componentes);
con la definición del proceso de procesamiento de la información y la interacción entre procesos (resultado de una definición incorrecta de las relaciones entre componentes y procesos);
con asignación incorrecta de datos y sus estructuras en la descripción de componentes individuales y el PS en su conjunto;
con descripción incorrecta de los algoritmos del módulo;
con la definición de las condiciones para la ocurrencia de posibles errores en el programa;
en violación de las normas y tecnologías adoptadas para el proyecto.

Etapa de codificación.En esta etapa ocurren errores que son el resultado de defectos de diseño, errores de los programadores y administradores en el proceso de 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, irracional asignación de módulos y componente, etc.);
el uso del mismo nombre para denotar diferentes objetos o diferentes nombres del mismo objeto, mala mnemotécnica de nombres; - cambios incoherentes en el programa por parte de diferentes desarrolladores, etc.

Proceso de prueba.En este proceso, los programadores y probadores cometen errores cuando realizan ensamblaje y prueba de tecnología, seleccionan conjuntos de pruebas y escenarios de prueba, etc. Las fallas de software causadas por tales errores deben detectarse, eliminarse y no reflejarse en las estadísticas de errores de componentes y software. en general.

Proceso de mantenimiento.Durante el proceso de mantenimiento, se encuentran errores que son causados por deficiencias y defectos en la documentación operativa, indicadores insuficientes de modificabilidad y legibilidad, así como la incompetencia de las personas responsables de mantener y/o mejorar el 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 se suelen dividir en las siguientes clases [7.12]:

errores lógicos y funcionales;
errores de cálculo y tiempo de ejecución;
errores de E/S 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 el resultado 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 inexactitudes en los datos de origen y 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 relacionados con la falta de proporcionar la velocidad de procesamiento de consultas requerida o el tiempo de recuperación del programa.

errores de E/S y la manipulación de datos son el resultado de una preparación deficiente de los datos para la ejecución del programa, fallas al ingresarlos a la base de datos o al recuperarlos de ella.

Errores de interfaz se relacionan con errores en la interconexión de elementos individuales entre sí, que se manifiesta al transferir datos entre ellos, así como al interactuar con el entorno de funcionamiento.

Errores de volumen se refieren a datos y son consecuencia 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 ni la intensidad de su procesamiento.

Las principales clases de errores dadas son características de diferentes tipos de componentes de software y se manifiestan en los programas de diferentes maneras. Entonces, cuando se trabaja con una base de datos, hay errores en la presentación y manipulación de los datos, errores lógicos en la tarea de aplicar procedimientos de procesamiento de datos, etc. Predominan los errores de cálculo en los programas de carácter computacional, y los errores lógicos y funcionales en los programas de control y procesamiento. 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 alcance son comunes a 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 apoyo al desarrollo de software (tecnologías CASE, métodos orientados a objetos y herramientas de diseño de modelos y programas), se lleva a cabo un diseño de este tipo en el que el software está protegido de los errores más comunes y, por lo tanto, evita la aparición de defectos de software.

Vincular un error a una falla.La presencia de un error en el programa, por regla general, conduce a la falla del software durante su funcionamiento. Para analizar las relaciones causa-efecto “error-falla”, 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 resultado 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 la detección de defectos en cada etapa de desarrollo;
comparación de defectos y fallas en software para desarrollar un sistema de interconexiones y métodos para localización, recopilación y análisis de información sobre fallas y defectos;
desarrollo de enfoques para la documentación del software y los procesos de prueba.

El objetivo final de la causalidad error-falla es definir métodos y herramientas para probar y detectar errores de ciertas clases, así como criterios para probar la finalización de un conjunto de conjuntos de datos; en la determinación de formas de mejorar la organización del proceso de desarrollo, prueba y mantenimiento de software.

Damos la siguiente clasificación de tipos de fallas:

hardware, en el que el software de todo el sistema no está operativo;
informativo, causado por errores en los datos de entrada y transmisión de datos a través de canales de comunicación, así como cuando fallan los dispositivos de entrada (consecuencia de fallas de hardware);
ergonómico, causado por errores del operador al interactuar con la máquina (esta falla es una falla secundaria que puede conducir a fallas de información o funcionales);
software, si hay errores en los componentes, etc.

Algunos errores pueden deberse a fallas en la definición de requisitos, el diseño, la generación de código de salida o la documentación. Por otro lado, se generan durante el desarrollo del programa o durante el desarrollo de interfaces para 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. Por regla general, se descubren durante la ejecución o el mantenimiento del software en los puntos más inesperados y diversos del mismo.

Algunos errores en el programa pueden ser el resultado de fallas en la definición de requisitos, diseño, generación de código o documentación. Por otro lado, se generan errores 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 la aparición de errores es un malentendido 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 como sugiere 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 su aclaración.

El equipo de diseño 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 los valores de las variables de estos operadores están configurados incorrectamente).

Populares en la categoría: