Algoritmos genéricos en pseudocódigo. Verificación funcional y total frente a errores (testing). (CU00233A)

Codificación aprenderaprogramar.com: CU00233A

También: “Obtener potencialidad implica que el programa sea capaz de resolver el mayor número de casos y variantes posibles. El programa hay que abrirlo y no cerrarlo”. Sobre esta idea se ha estado incidiendo de forma directa o indirecta a lo largo de todo el curso. El concepto de programación genérica se reforzó, una vez más, cuando se introdujo la idea de módulo genérico. El uso de algoritmos genéricos, entendidos éstos como aquellos que admiten un amplio rango de valores o datos de entrada y, en función de éstos, dan lugar a unos resultados, es positivo desde todos los puntos de vista excepto, quizás, el de lograr la verificación del algoritmo.

Hasta ahora hemos estado viendo procesos de verificación basados en unos determinados datos de entrada y unos determinados datos de salida. Considérese ahora que se tenga que probar una situación con infinitas posibilidades de resultados. Esto nos lleva a que no podamos realizar la verificación total del algoritmo, entendida ésta como la prueba de que para cualquiera de los datos de entrada el resultado del algoritmo es siempre correcto. Pero no sólo el caso de posibilidades infinitas, como podría ser el conjunto de números reales o enteros, nos lleva a esta situación. Bastará el hecho de que el número de pruebas sea elevado para que realizar una verificación total sea inviable o inoportuno, ya que incluso utilizando un ordenador para probar el algoritmo el tiempo requerido es excesivo. Por otro lado, la verificación total no es un objetivo que haya que buscar como si del Santo Grial se tratara. Es una posibilidad que en algunas ocasiones nos puede interesar mientras que en otras carece de sentido. ¿Cómo proceder entonces a verificar un algoritmo genérico? En general, realizando cierto número de pruebas para las que los resultados esperables son conocidos (o al menos se conoce el entorno aproximado en que deben estar). El número de pruebas a realizar se establecerá:

a) En cantidad suficiente para abarcar un rango amplio de valores de entrada, incluyendo valores especiales (como el cero, un máximo, un mínimo, etc.). Obviamente si el programa está enfocado a no procesarse ante ciertos valores de entrada no admisibles, dichos valores no habrá que probarlos porque no tiene sentido.

b) De acuerdo con la experiencia del programador.

Cada prueba se desarrolla con alguna de las técnicas de verificación que hemos visto. La verificación de un algoritmo genérico mediante un número limitado de pruebas la denominamos verificación funcional en contraposición a la verificación total. La verificación funcional no asegura que el algoritmo vaya a funcionar en cualquier circunstancia, pero sí puede determinar que el resultado esperable es correcto con alto grado de probabilidad para un rango de valores dado.

Veamos un ejemplo. En primer lugar definiremos un algoritmo genérico a partir del ejemplo que veníamos usando:

No genérico <-------------------------------------> Genérico

Se supone que todas las variables están definidas como de tipo entero. ¿Cómo enfocar la prueba de este algoritmo? Trataremos de realizar pruebas con datos representativos del conjunto de posibilidades que se pueden presentar. El proceso es similar al que se usa en estrategias de resolución para problemas con resolución intuida pero método paso a paso a determinar. Los “casos” a probar serán los necesarios o los que creamos necesarios buscando representatividad de situaciones, circunstancias especiales conocidas y sencillez.

Estos términos debemos ya conocerlos, por lo que omitimos su explicación. Vamos a pasar a realizar una elección de casos para el ejemplo que nos ocupa.

¿Son muchos o pocos casos y están bien o mal elegidos? Depende del programador al que se le pregunte. Dados dos programadores enfrentados al mismo problema lo más probable es que:

· El número de casos varíe.

· Los casos para uno representativos pueden no serlo tanto para el otro.

· Si tienen un mínimo de experiencia, llegarán ambos a una verificación igual de buena.

Cada uno de los casos será verificado a través de alguna de las técnicas estudiadas. Si durante las verificaciones se constata algún problema o no hay entera satisfacción, se puede ampliar el número de casos. Veamos lo que serían las verificaciones de los casos planteados con tablas de variables.

CASO 1

CASO 2

CASO 3

CASO 4

CASO 5

CASO 6

CASO 7

Hay que tener en cuenta que los resultados de las pruebas son interpretables sólo en función de los objetivos planteados para el programa y de la existencia de errores que puedan impedir su ejecución.

Hay tres situaciones posibles:

a) El programa se ejecuta y el resultado es conforme.

b) El programa se ejecuta pero el resultado es no conforme.

c) El programa no se ejecuta (da error).

Hablaremos de los tipos de errores y su gestión más adelante. En este momento nos estamos centrando en los posibles fallos en el diseño del algoritmo y no en los que puedan aparecer en conjunto al ejecutar el programa. El diseño es no satisfactorio cuando da lugar a resultados no deseados o cuando da lugar a una imposibilidad de ejecución porque, por ejemplo, produzca indeterminaciones matemáticas, la asignación de un valor a una variable que no coincide con el tipo declarado, etc.

De las verificaciones realizadas sobre el doble anidamiento se desprende que parecen no existir problemas para la ejecución (no hay indeterminaciones matemáticas, todos los números son enteros...) pero ¿El diseño es o no satisfactorio? Para responder a esta pregunta primero tendremos que responder: ¿Cuál era el objetivo del algoritmo? Si la verificación trataba simplemente de comprobar que el programa admite un amplio rango de valores de entrada, sin importar el resultado, podemos decir que el diseño es satisfactorio. Si el objetivo era obtener un resultado cualquiera pero siempre positivo, el caso 3 pone de manifiesto que el diseño del algoritmo no es satisfactorio. Si fuera así habría que proceder al rediseño, bien modificando la estructura actual o bien olvidando ésta y creando una nueva.

Una pregunta que podemos hacernos es: ¿Es posible que se produzcan situaciones a > b o     m > n? Esto depende del proceso de entrada de datos. Si lo consideramos “aleatorio” (por ejemplo al antojo del usuario) obviamente la situación sí es posible. La consecuencia sería que el bucle no se llega a ejecutar con lo cual A no modifica su valor previo ni se muestra valor alguno (ver “Uso y mal uso de la instrucción Desde ... Siguiente”). Habrá que responder a la pregunta: ¿Es esto aceptable en nuestro programa? Puede que lo sea o puede que no. Habrá que estudiar las implicaciones que se derivan de ello en un contexto dado.

La representación sería para por ejemplo a = 3   b = 1   m = 4   n = 2  (caso 8)

CASO 8