Pruebas de los programasThis is a featured page


Una vez que se ha concluido la codificación de los programas, es momento de probarlos. La etapa de prueba no es la primera instancia en la cual se encuentran defectos; ya que durante la revisión de los requerimientos y del diseño también se pueden descubrir problemas en las etapas tempranas del desarrollo. Pero la prueba se concentra en la búsqueda de defectos y hay diversas formas de hacer que los esfuerzos de la prueba sean más eficientes y efectivos.


Defectos y Fallas del Software

En una situación ideal, cada programa que produce un programador trabajaría de manera correcta cada vez que se pone en ejecución, lamentablemente este ideal no es la realidad. La diferencia entre el ideal y la situación real es el resultado de una variedad de factores. En primer lugar, podemos encontrar que la mayoría de los sistemas de software operan con grandes cantidades de estados y con fórmulas, actividades y algoritmos complejos. Además que se utilizan las herramientas disponibles para implementar una concepción del cliente para un sistema, cuando el cliente a veces no está seguro de lo que realmente necesita. Y como último factor esta el tamaño de un proyecto y el número de personas involucradas, lo cual agrega complejidad. Por tanto la presencia de defectos no sólo en una función del software sino también en las expectativas de clientes y usuarios.


¿Qué significa que el software ha fallado?

En general se interpreta que el software no hace lo que especifican los requerimientos. Por ejemplo la especificación puede establecer que el sistema debe responder a una consulta particular unicamente a los usuarios que están autorizados a ver los datos. Si el programa responde a un asurio que no autorizado, significa que el sistema ha fallado. La falla puede ser el resultado de alguna o varias de las siguientes razones:

  • La especificación puede ser érronea o puede haberse omitido algún requerimiento. Es decir que no enuncie exactamente lo que el cliente necesita o desea.
  • La especificación puede contener un requerimiento que es imposible de implementar con el hardware y el software que se tiene.
  • El diseño del sistema puede contener uno varios defectos.
  • Que el diseño del programa no sea el adecuado.
  • El código del programa puede estar errado.
Por lo tanto una falla es el resultado de uno o más defectos en algún aspecto del sistema. Y en el caso de los programas, a partir de la cantidad que se tenga de posibles defectos, se deben de verificar los componentes para asegurar que estén correctamente codificados.

El objetivo de probar un programa, es demostrar la existencia de un defecto. La prueba es destructiva, ya que la meta es descubrir defectos, una prueba se considera exitosa solamente cuando se descubre un defecto o cuando se produce una falla como resultado de los procedimientos de prueba.

La identificación de defectos es el proceso de determinar cuál o cuáles son los defectos que originan las fallas, y la correción de defectos o remoción es el proceso de efectuar cambios al sistema de manera que se eliminen los defectos. En el momento de llevar a cabo la codificación y la prueba de componentes se tiene la gran esperanza de que las especificaciones sean correctas. Y esto se puede lograr si se pusieron en práctica las técnicas de la Ingeniería de Software, para así asegurar que el diseño, tanto del sistema como de sus componentes, refleja los requermientos y conforma una base para una sólida implementación. Es totalmente posible que un defecto en el software sea el resultado de un descuido durante la etapa o actividad de desarrollo muy temprana.


Tipos de defectos

Después de codificar los componentes del programa, por lo general se procede a examinar el código para detectar los defectos y elimimarlos lo más pronto posible. Cuando estos defectos no son obvios , se prueban los programas para ver si pueden contener más defectos, creando condiciones especiales donde el código no responda como esté planeado. Un defecto algorítmico se produce cuando el algoritmo o la lógica de un componente de programa no producen la salida apropiada para una entrada dada, debido a que algo está mal en los pasos del procesamiento. La detección de defectos a veces es fácil, como cuando unicamente se lee el programa (la denominada prueba de escritorio) o al enviar datos de la entrada de cada una de las diferentes clases de datos que se espera el programa reciba durante su operación normal. Los defectos más comunes son:


  • Bifurcar antes o después de tiempo.
  • Probar para una condición erronéa.
  • Olvidar inicializar una variable o fijar las constantes de un bucle.
  • Comparar variables de tipos de datos inapropiados.
  • Olvidar la prueba para una condición particular (Por ejemplo considerar una división entre cero).
Mientras que se hace la búsqueda de defectos algorítmicos se puede hacer también la revisión de la sintaxis. Los defectos de computación y los de precisión ocurren cuando la implementación de una fórmula es errónea o no calcula el resultado con el grado requerido de exactitud. Cuando la documentación no concuerda con lo que el programa realmente hace, se dice que el programa tiene defectos de documentación.

Los defectos por estrés o sobrecarga se producen cuando las estructuras del programa se llenan hasta sobrepasar su capacidad específica. De manera simillar, existen los defectos de capacidad o de límites que ocurren cuando el desempeño del sistema se vuelve inaceptable a medida que la actividad del sistema alcanza su límite específicado.

Otro tipo de defectos son lo de sincronización o de coordinación, los cuales se producen cuando el código que coordina dichos eventos es inadecuado. Los defectos de rendimiento o de desempeño ocurren cuando el sistema no opera a la velocidad prescrita por los requerimientos. Estos son los problemas de tiempo de diversa naturaleza; las restricciones de tiempo están puestas sobre le rendimiento del sistema, debido a los requerimientos del cliente más que por una necesidad de coordinación.

Es en las etapas de diseño y codificación donde se pone gran cuidado para asegurar que el sistema pueda recuperarse ante una variedad de fallas. Los defectos de recuperación pueden presentarse cuando se encuentra una falla y el sistema no se comporta comolo diseñadores desean que lo haga o como requiere el cliente.

También pueden producirse defectos del hardware y del software de sistemas, cuando el hardware suministrado y el software de sistemas no trabaja de acuerdo con las condiciones operativas y procedimientos documentados.

Los defectos de estándares y procedimientos no siempre afectan la corrida de los programas pero pueden fomentar un ambiente donde los defectos se creen a medida que el sistema es probado y modificado.


Aspectos de la Prueba

Existen muchos tipos de prueba que se hacen antes de poder entrgerale el sistema al cliente con la seguridad de que operará correctamente. Algunas de ellas dependen de qué es lo que se está probando: componentes, grupo de componentes, subsistemas o todo el sistema. Otras pruebas dependen de lo que se desea conocer ¿el sistema trabaja de acuerdo con el diseño?, ¿y con las expectativas de los usuarios?.


Organización de la Prueba

Cuando se desarrolla un sistema grande, la pruba por lo general involucra varios estadios, En primer lugar, cada componente de programa verifica en sí mismo, aislado de los demás componentes del sistema. Esta prueba conocida como prueba de módulo, prueba de componente o prueba unitaria, verifica que el componente funciona correctamente con lo tipos de entrada esperados a partir del estudio del diseño del componente.

La prueba unitaria se hace siempre que sea posible en un ambiente controlado, de modo que el equipo de prueba pueda ingresarle al componente que se está probando un conjunto predeterminado de datos, y observar que acciones y datos de salida se producen.

Una vez que le conjunto de componentes del sistema (o subsistema) ha superado la prueba unitaria, el paso siguiente es asegurar que las interfaces entre los componentes están definidas y se manejan correctamente. La prueba de integración es el proceso de verificar que los componentes del sistema trabajan conforme a lo descrito en las especificaciones de diseño del programa y del sistema.

Despues de asegurar que la información pasa entre los componentes de acuerdo eon el diseño, se prueba el sistema para asegurar que tiene la funcionalidad deseada. Una prueba funcional evalúa el sistema para determinar si las funciones descritas por la especificación de requerimientos son ejecutadas correctamente por el sistema integrado. El resultado es un sistema en funcionamiento.

Cabe recordar que lo requerimientos están documentados de dos formas distintas: una es en términos del cliente, y otra como un conjunto de requerimientos de hardware y software que pueden utilizar los desarrolladores. La prueba funcional compara el sistema en construcción, con las funciones descritas en la especificación de requerimientos de los desarrolladores. Más adelante una prueba de rendimiento compara el sistema con el resto de los requerimientos de software y de hardware. Cuando la prueba se lleva a cabo exitosamente en el ambiente real de trabajo del cliente, produce un sistema validado.

Cuando la prueba de rendimiento se concluye, los desarrolladores tienen la certeza de que el sistema funciona de acuerdo con su comprensión de la descripción del sistema. El siguiente paso es conferenciar con el cliente para tener la certeza de que le sistema trabaja de acuerdo con sus expectativas. La prueba de aceptación se hace en conjunto con el cliente; el sistema se comprueba contra la especificación de requerimientos del cliente. Al terminar la prueba de aceptación el sistema aceptado se instala en el ambiente en el que será utilizado y se ejecuta una última prueba de instalación para garantizar que funciona como debe hacerlo.


Actitudes frente al proceso de prueba


Es importante tener en cuenta que cuando se está desarrollando un sistema para clientes, a éstos no les interesa saber que el sistema funciona correctamente bajo ciertas condiciones, sino que les interesa estar seguros del funcionamiento correcto del sistema bajo todas las condiciones. De este modo, la meta del desarrollador debe ser la eliminación de tantos defectos como sea posible, sin importar dónde se han producido o quién los ha originado. El sentirse mal o herido el ego no tiene algún lugar en el descubrimiento de defectos en el proceso de desarrollo. De aquí que muchos ingenieros de software adopten un actitud conocida como programación no egoísta, donde los programas se consideran como componentes de un sistema mayor, no una propiedad de aquellos que los han escrito. Cuando se descubre un defecto o se produce una falla, al equipo de desarrollo no egoísta le concierne corregir el defecto y no reprocharle a un desrrollador en particular.



¿Quién realiza las pruebas?

Aun cuando el sistema esté desarrollado con un enfoque no egoísta, muchas veces se manifiestan dificultades para separar los sentimientos personales del proceso de prueba. Po lo tanto a menudo se utiliza un equipo de prueba independiente par aprobar el sistema. De esta forma se evita el conflicto entre la responsabilidad personal por los defectos y la necesidad de descubrir tantos defectos como sea posible.

Adicionalmente varios factores justofican en equipo independiente de prueba. Un equipo de prueba inependiente puede participar en la revisión de los componentes a través del desarrollo. El euipo puede ser parte de las revisiones de los requerimientos y del diseño, pude probar los componentes individuales y puede probar el sistema a medida que se integra y se presenta a los clientes.


Las visiones de los objetos de prueba

Al probar un componente, un grupo de componetes , un subsistema o un sistema, la propia visión del objeto de prueba; puede afectar la forma en que se lleve a cabo la prueba.

Si el objeto de prueba se ve desdes afuera, como una caja cerrada o una caja negra, cuyo contenido se desconoce, las pruebas consisten en alimentar la caja negra con entradas y anotar cuáles son las salidas que se producen. En este caso el objetivo de la prueba es asegurar qu e se ha ingresado toda clase de entrada y que la salida en cada caso se corresponde con la salida esperada.

Esta tipo de pruebas tien ventajas y desventajas, La ventaja más evidente es que una caja cerrada está libre de las restricciones impuestas por la estructura interna o la lógica del objeto de prueba, sin embargo de esta manera no siempre es posible ejecutar una prueba completa.

Pero para superar esto el objeto de prueba puede verse en cambio como una caja abierta o también denominada caja de cristal o caja blanca o transparente; luego, se puede utilizar la estrucutura del objeto de prueba para probar las diferentes maneras. Por ejemplo, se pueden inventar casos de prueba que ejecuten todas las instrucciones o todos los caminos que existen en el interior del componente o de los componentes, para asegurar que el objeto de prueba está trabajando correctamente; pero en ocasiones resulta poco práctico adoptar este tipo de enfoque.

En general la selección de una filosofía depende de muchos factores como son :

  • el número de caminos lógicos posibles
  • la naturaleza de los datos de entrada
  • la cantidad de cómputo involucrado
  • la complejidad de los algoritmos

Planificación de la Prueba

Un cuidadoso plan de prueba ayuda a diseñar y organizar las pruebas con el fin de asegurar que se pruebe en forma apropiada y directa. Cada paso del proceso de prueba debe ser planeado. De hecho el proceso de prueba tiene su propio ciclo de vida dentro del ciclo de desarrollo, y se puede llevar a cabo en paralelo con muchas de losa otras actividades del desarrollo. Se deben de planear en particular, los siguientes casos de prueba:

  1. Determinación de los objetivos.
  2. Diseño de los casos de prueba.
  3. Preparación escrita de los casos de prueba.
  4. Verificación de los casos de prueba.
  5. Ejecución de las pruebas.
  6. Evaluación de los resultados.
El objetivo de la prueba indica qué clases de casos de prueba se deben generar. Es más, el diseño de caso de prueba es clave para la prueba exitosa. Por consiguiente, la ejecución de una prueba comienza con la revisión de los casos de prueba para verificar que son correctos, factibles, que proporcionan el grado de cobertura deseado y demuestran la funcionalidad deseada. Una vez realizados estos controles se pueden efectuar las pruebas.



Fuente:
LAWRENCE Pfleeger, Ingeniería de Software Teoría y Práctica, 1a. ed, Brasil 2002, Prentice Hall.


















angiejolie
angiejolie
Latest page update: made by angiejolie , Nov 28 2008, 5:58 PM EST (about this update About This Update angiejolie Edited by angiejolie

490 words added

view changes

- complete history)
Keyword tags: None
More Info: links to this page

Anonymous  (Get credit for your thread)


There are no threads for this page.  Be the first to start a new thread.