INGENIERIA DE SOFTWARE

FASE DESARROLLO ACTIVIDAD DE PRUEBAS DE CODIFICACIÓN
Introducción:
El objetivo de la prueba de software (tanto del código como de la especificación) es demostrar la presencia de errores (con el fin de conseguir su eliminación posterior) pero que no permiten demostrar su ausencia.
Una prueba en concreto consiste en someter al producto de software (o a una parte del mismo) a una evaluaciónpara conocer si se comporta de acuerdo con una especificación tomada como referencia.
PROCESO DE PRUEBAS
En general la fase de planificación de cualquier etapa de prueba requiere las siguientes
ACTIVIDADES:
1. Designación del responsable de la etapa.
2. Identificación de los participantes en la etapa y sus roles.
3. Identificación y planificación de los recursos requeridos.
4.Estimación del tiempo y esfuerzo requerido.
5. Documentación del alcance de las pruebas.
6. Documentación de la filosofía de diseño de los casos de prueba.
7. Generación disciplinada y sistemática de casos de prueba, según la filosofía adoptada.
8. Documentación de los casos de prueba.
Para cada caso de prueba la documentación debe incluir:
(a) Justificación de su inclusión.
(b) Datos deentrada e indicaciones de cómo correr el caso.
(c) Configuración requerida para la prueba.
(d) Resultados esperados.
(e) (En ejecución se agrega) Resultados obtenidos.
(f) (En ejecución se agrega) Tipo de defecto hallado. Esto puede constar de una indicación de superada o cómo mínimo una indicación de la severidad de la falla (falla grave, seria o menor), una descripción de la falla y unaidentificación tentativa de la etapa del desarrollo a que se atribuye (Análisis, Diseño, Codificación, etc).
9. Criterio de culminación de las pruebas.
El proceso de prueba de un software orientado por objetos
Consta de las siguientes etapas
Inspección del análisis (verifica si se cometieron errores o falla en la etapa de análisis).
2. Inspección del diseño (debe ser completo yeficiente).
3. Inspección del código (observar el entendimiento y facilidad del código).
4. Pruebas unitarias (probar cada método de las clases implementadas por separado).
5. Pruebas de integración (probar todas las clases, verificando que compaginen entre sí).
6. Pruebas de validación de requerimientos (verificar que cumple con todos los reques exigidos por el cliente).
7. Pruebas de sistema(ejecutar el programa para verificar si cumple con los requisitos exigidos).
A) Una descripción de la prueba. La descripción debe indicar el propósito de la prueba (para qué se hace), el componente de software sobre el que se realiza (podría ser un módulo, subsistema o el sistema completo), los datos de prueba que se van a entregar y los resultados esperados.
B) Una ejecución de la prueba. Sise dispone de una descripción ejecutable del sistema (por ejemplo, código) la ejecución de la prueba implica la ejecución de ese módulo en un entorno controlado. Posiblemente, ni el sistema final ni el resto del producto están disponibles y deberán ser simulados. Esta situación obliga a disponer de un entorno específico (conjunto de herramientas que simulen a efectos de la validación el entornode ejecución del producto de software) para la ejecución de las pruebas.
C) Una valoración de los resultados obtenidos.
Una vez obtenidos los resultados de la prueba, éstos deben compararse con otros considerados como referencia.
En muchos casos, esta referencia es una especificación a partir de la cual se ha generado el programa.
En otros casos son heurísticos que los diseñadores hanseleccionado.
Intuitivamente, podemos decir que cuantas más pruebas se realicen mayor será nuestra confianza en el producto. Cada prueba debe cubrir un aspecto concreto y una secuencia de pruebas nos da la cobertura del producto conseguida
Desde el punto de vista técnico, las pruebas se enmarcan en la revisión del diseño y del código.
Los métodos más conocidos son los siguientes:
A) Inspección...