¿Podemos garantizar que un programa nunca saldrá mal?

Tenemos un sistema aquí. Recientemente hay un cálculo incorrecto en uno de los números en el informe generado por el sistema. A lo largo de nuestra experiencia, nunca hemos encontrado ningún problema / error en este sistema durante algunos años.

Debido a que el escritor de este sistema ya se había ido, apenas podemos rastrear los programas. Pero hemos verificado los datos de entrada, la configuración y son correctos.

Ahora mi pregunta es, ¿un programa de computadora de repente saldrá mal sin ninguna razón lógica? Si golpeo la máquina del servidor, ¿uno de los números que calcula la computadora se convertirá en otro número y hará un cálculo incorrecto?

Estoy de acuerdo con que mi idea es bastante loca, pero solo quiero saber, ¿cómo podemos saber que el problema no es causado por el programa y la entrada, sino por algunos otros factores?

PD: Este sistema loco no tiene registro.

¡Yo diría que no!

En teoría, la respuesta es no, solo podemos evaluar: -

• cierto número limitado de ambientes.
• un número limitado de escalas de tiempo.
• un número limitado de casos de prueba.

Esto es considerablemente menor que el número total posible de entornos, tiempos y casos que el programa puede encontrar en su vida útil. También tenemos poco conocimiento del futuro si el programa hace frente a una inflación del 10,000%, ¿debería su programa hacer frente a una nueva arquitectura de 31 bits super duper?

La teoría está respaldada por la experiencia que personalmente he encontrado:

• Programas que se rompen cuando se mueven a una ubicación diferente. Comprobando "MAYO" cuando el mes era "MAI".
• Los programas que fallaron las pruebas en una nueva versión del compilador, un error en la versión anterior junto con un error en el programa produjo el resultado correcto.
• Programas que se rompen en una nueva versión del sistema operativo. Cuando Solaris aumentó el número predeterminado de entradas de directorio, el SMALLINT devuelto por ftok () siempre devolvió cero para el primer archivo en el directorio.
• programas que se rompieron porque era la primera vez que encontraban una combinación particular de insumos, que eran tanto válidos como inesperados y nunca habrían sido probados: tasas de interés negativas en depósitos, artículos de peso cero para enviar, artículos de tan bajo valor que No se pudo calcular el IVA, etc., etc.

En teoría, si comienza con un estado idéntico, el resultado será idéntico. En realidad, asegurar un estado inicial idéntico en el equipo de "tamaño de servidor" es prácticamente imposible.

Tomar variables no inicializadas. Mira este código:

  short i;

  if(i==-1)
  {
        //do something special
  }
  else
  {
        i=0;
        //do something else
  }

Esto producirá resultados inesperados una vez en 65536 ejecuciones. Y a menos que asegure que la memoria estará en el mismo estado antes de cada ejecución, iserá completamente aleatoria.

Hay cientos de formas similares para que aparezcan errores siguiendo elementos impredecibles del estado inicial que alguien olvidó anular, o casos límite que ocurren raramente: condiciones de carrera en un entorno de subprocesos múltiples, acceso de matriz fuera de los límites, disco IO en un sistema de archivos dañado y pronto.

Si puede probar que el programa está libre de errores, solo hay rayos cósmicos que pueden romperlo. Pero la prueba matemática de la corrección de algo más complejo que dos bucles anidados está más allá del alcance de los sistemas más grandes (y cuesta una pequeña fortuna), y para todo lo demás solo puede esperar.

Ahora mi pregunta es, ¿un programa de computadora de repente saldrá mal sin ninguna razón lógica?

Si tiene exactamente el mismo entorno informático, la entrada X de un programa siempre producirá el mismo resultado R. En la práctica, rara vez se ejecuta un solo programa de forma aislada. La aplicación más simple de hoy se ejecuta en un sistema operativo y comparte memoria con otros programas que pueden 'cargarse' en la memoria al mismo tiempo. Estos programas pueden alterar la memoria de una manera que hace que un determinado programa no funcione correctamente. Este es un problema famoso con variables de tipo 'puntero' por ejemplo. Por lo general, tales errores causan comportamientos anormales del sistema y no resultados de cálculo incorrectos.

En su caso, supongo que el problema puede ser (y generalmente no es) lo que he descrito anteriormente. El problema puede ser que:

• el programa usó los tipos de datos incorrectos para calcular el resultado, ese error solo se manifiesta cuando se usan valores especiales.
• el programa encontró un error en el cálculo (debido a una condición lógica) pero no manejó el error y aún así produjo el resultado. (por ejemplo, mezcla de flotante y aritmética de enteros)
• una regla de negocio o una condición lógica no se codificó correctamente, los datos ingresados ​​representan esta condición pero se utilizó el cálculo incorrecto. (por ejemplo, reste el monto del monto de la cuenta antes de verificar primero el monto en la cuenta).
• usando fórmulas que se aplican solo a cierto rango de números pero los datos contienen un rango diferente. (por ejemplo, calcular una tasa de interés basada en un rango de valores)

Debido a lo anterior y a muchas otras razones por las cuales las personas de software gastan tantos recursos en un intento de crear el software correcto, sin embargo, los errores de software aún ocurren, pero los errores son 'lógicos' y tienen una razón, es solo que la razón no es obvia para algunos sin una buena investigación. Por lo tanto, en general, el software probado es predecible y no produce resultados aleatorios. Debido a la complejidad de algunos programas y otros factores, incluso los programas probados pueden salir mal, pero cuando eso sucede, los errores son por una razón lógica.

Si golpeo la máquina del servidor, ¿uno de los números que calcula la computadora se convertirá en otro número y hará un cálculo incorrecto?

La respuesta es no en general, el software no es frágil en ese sentido.

Lo que puede hacer es aislar los casos en que se produce el error, encontrar la similitud entre estos conjuntos de datos que causan el error y encontrar la diferencia entre estos conjuntos y los otros conjuntos que producen el resultado correcto. Es posible que pueda identificar el conjunto específico de valores que causan el problema. Por ejemplo, puede encontrar que cada vez que una variable tiene un valor negativo, el resultado es incorrecto.

Información actualizada sobre errores de daños en la memoria: consulte Daños en la memoria

¿Pueden garantizar que un programa no tenga errores y que nunca salga mal? No, desafortunadamente no.

¿Puede demostrar que un programa tiene una cantidad suficientemente pequeña de errores que el costo de encontrarlos y solucionarlos excede con creces el beneficio de esa acción? Me parece que ya lo has hecho.

Parafraseando una vieja máxima estadística, todos los programas están equivocados, pero algunos programas son útiles.

Me inclino a decir que no , no puede probar que un programa nunca saldrá mal o proporcionará un resultado incorrecto, incluso si puede asumir una entrada perfecta.

Raku mencionó una prueba formal de corrección. Eso es algo a tener en cuenta, pero a menos que esté completamente equivocado, aún tendrá que asumir un entorno de ejecución perfecto. Entonces, con algo de tiempo y esfuerzo, tal vez pueda probar que el programa es correcto , pero eso no necesariamente prueba que siempre producirá los resultados correctos , incluso si se le da una entrada perfecta. El entorno de ejecución es importante. Y desconfiaría de suponer que la entrada siempre es perfecta.

Es por eso que, en ciertas situaciones de alta disponibilidad, se utilizan implementaciones y entornos de ejecución múltiples y completamente independientes, y los resultados se comparan para asegurarse de que estén dentro de un margen de error aceptable entre sí. En algunas situaciones, ese margen puede muy bien ser cero. Incluso en la década de 1960, esto se consideró lo suficientemente importante como para incluir conjuntos separados de hardware informático en naves espaciales. Incluso si una descarga estática errante, un rayo cósmico o lo que fuera que afectara a ambas computadoras simultáneamente, las probabilidades de que ambas se vean afectadas de la misma manera (particularmente si ambas siguen funcionando y producen resultados válidos) son minúsculas. Las probabilidades de que el mismo error se infiltre en dos implementaciones completamente separadas también son extremadamente pequeñas. Y así.

La mayoría de la informática (estándar) es determinista, creo.

Si es posible, configúrelo para hacer un lote de 1000 o 10000, etc., iteraciones con los mismos datos de entrada, y verifique que los resultados salgan iguales.

Asegúrese de que los valores actuales que entran en el cálculo causarían un desbordamiento o desbordamiento en cualquier lugar (si se trata de un sistema más antiguo, es posible que no haya sido utilizado durante tanto tiempo).

Y2K11 alguien?

A menos que pueda controlar cada bit de la máquina, y cada bit de impulso eléctrico que fluye a través de los circuitos, no puede garantizar con absoluta certeza que algo no saldrá mal con su programa. Los módulos de memoria fallan, las CPU pueden sobrecalentarse e introducir errores, los discos duros pueden codificar datos y las fuentes de alimentación pueden introducir ruido en el sistema. Cuanto más costoso sea el hardware, y cuanto más redundante sea el hardware, menos probable será que ocurran estas cosas, pero en algún momento el hardware puede fallar.

Luego tienes el sistema operativo, con errores que pueden ser utilizados por los medios más arcanos imaginables. Los compiladores también pueden tener errores oscuros que solo esperan convertir hábilmente su código prístino en errores difíciles de rastrear. Es una jungla allá afuera, y su software pobre es vulnerable a todo esto. ¡ESTAR ATENTO!

Y en mi experiencia, la mayoría de las veces, cada vez que hay un error en un cálculo, nunca tenemos que cavar tan lejos para encontrar al culpable. En términos generales, casi todos los errores que he visto en el mundo corporativo se encuentran fácilmente con las herramientas de depuración adecuadas y un poco de grasa.

En otras palabras, si bien el hardware y el sistema operativo pueden no ser perfectos, es probable que nunca tenga que preocuparse por ese nivel de detalle. Simplemente encuentre a alguien que sepa el idioma y que sea útil con un depurador, y profundice.

"Las explicaciones más simples son, en igualdad de condiciones, generalmente mejores que las más complejas". - Resumen de la navaja de Occam.

Sí, golpear un sistema podría doblar y / o mover partes lo suficiente como para causar un circuito abierto temporal (o posiblemente un cortocircuito, aunque probablemente sea menos probable).

La primera computadora que tuve fue una Altair 8080 con 256 Bytes de memoria. La entrada era de interruptores de consola y la salida era de unas pocas luces parpadeantes. Si no permite los rayos cósmicos y las fallas de hardware, creo que podría probar que algunos programas que ejecuté siempre producirían los mismos resultados.

Desde entonces no.

Las pruebas muestran la presencia, no la ausencia de errores (Edsger W. Dijkstra)

Si está tratando de demostrar que su programa funciona correctamente mediante pruebas, no funcionará.

Sin embargo, existen algunos enfoques en informática teórica en los que desarrolla una prueba formal del software que ha escrito. Dependiendo de la complejidad de su sistema, esto puede ser un proceso tedioso. Sin embargo, si su sistema funciona en un conjunto restringido de comandos, podría tener éxito con este enfoque.

Los entornos de hardware y software están en un estado constante de flujo. Las partes móviles, la electricidad, la temperatura, el polvo y los cambios en el código del sistema operativo son ejemplos.

Por lo tanto, no creo que sea probable o esperado que un programa de computadora siempre se comporte igual ya que el entorno siempre está cambiando.

El software puede ejecutarse durante mucho tiempo como se esperaba, pero eventualmente un pequeño cambio en el software del sistema operativo host cambiará, lo que afectaría el programa en cuestión o el hardware se valorará.

Estoy hablando de las computadoras actuales.

Ahora mi pregunta es, ¿un programa de computadora de repente saldrá mal sin ninguna razón lógica? Si golpeo la máquina del servidor, ¿uno de los números que calcula la computadora se convertirá en otro número y hará un cálculo incorrecto?

La respuesta a esa pregunta es incognoscible. Es imposible demostrar que algo siempre es cierto en el universo en el que vivimos. En cambio, hacemos suposiciones y demostramos que si las suposiciones son válidas, también se mantendrán algunas propiedades complicadas. Esto es lo que garantizan los programas formalmente verificados. Sin embargo, la mayoría de los programas no se verifican formalmente, sino que intentan generar confianza al proporcionar pruebas. Estas pruebas le dan la seguridad de que siempre que las pruebas hagan lo que fueron diseñadas para hacer y que las suposiciones que sostuvo, el programa que está utilizando funcionará al menos parte del tiempo.

Es apenas posible que el problema sea causado por la falla de RAM, pero esto es relativamente (muy) improbable. Ejecute una prueba de memoria, pero esté listo para revisar el código.