Es importante considerar, que la etapa de prueba no es la primera instancia en que se localizan
defectos también las revisiones de requerimientos y diseño contribuyen a descubrir los problemas
en instancias tempranas del desarrollo.
Existen muchos tipos de pruebas:
- prueba unitaria: es una forma de comprobar el correcto funcionamiento de una
unidad de código. Por ejemplo, en diseño estructurado o en diseño funcional una
función o un procedimiento, en diseño orientado a objetos una clase
- prueba de integración: Pruebas integrales o pruebas de integración son aquellas que
se realizan en el ámbito del desarrollo de software una vez que se han aprobado
las pruebas unitarias y lo que prueban es que todos los elementos unitarios que
componen el software, funcionan juntos correctamente probándolos en grupo.
- prueba de función: es una prueba de tipo caja negra basada en la ejecución,
revisión y retroalimentación de las funcionalidades previamente diseñadas para
el software.
- prueba de desempeño: son las pruebas que se realizan, desde una perspectiva, para
determinar lo rápido que realiza una tarea un sistema en condiciones
particulares de trabajo
- prueba de aceptación: las pruebas de aceptación pertenecen a las últimas etapas
previas a la liberación en firme de versiones nuevas a fin de determinar si
cumplen con las necesidades y/o requerimientos de las empresas y sus usuarios.
- prueba de instalación: pueden buscar errores que se produzcan en el proceso de instalación y que afecten la percepción y la capacidad del usuario para utilizar el software instalado
Defectos y Fallas del software
Por lo general se interpreta que el software no hace lo que especifican los requerimientos. La falla puede
ser el resultado de alguna de varias razones:
- La especificación puede ser errónea o puede haberse omitido algún requerimiento.
- La especificación puede contener un requerimiento que es imposible de implementar con el software y el hardware prescrito.
- El diseño del sistema puede contener un defecto.
- El diseño del programa puede contener un defecto.
- El código del programa puede estar errado.
Una falla es el resultado de uno o más defectos en algunos
aspectos del sistema.
- Muchos programadores consideran que la prueba es una comprobación de que sus programas operan correctamente.
- La idea de demostración de exactitud es realmente lo inverso de lo que entraña la prueba.
- Se prueba un programa para demostrar la existencia de un defecto
Tipos de Defectos
Defectos Algorítmicos: Se produce cuando el algoritmo o la lógica de un componente no
producen la salida apropiada para una entrada dada, debido a que
algo esta mal en los pasos del procesamiento.
Defectos de Sintaxis: Se realiza mientras se buscan defectos algorítmicos. En este caso, se desea asegurar que se han utilizado
apropiadamente las estructuras del lenguaje de programación.
Defectos de computación y de precisión: Ocurre cuando la implementación de una fórmula es errónea o no calcula el resultado con el grado
requerido de exactitud. Ej.: Mezcla de flotantes y enteros resultado inesperado.
Defectos de Documentación: Es cuando la documentación no corresponde con lo que el programa realmente hace. Se tiende a confiar
en la documentación al pasar de una etapa a otra y al modificar.
Defectos de sincronización o de coordinación: Al desarrollar sistemas de tiempo real, una consideración critica es la coordinación de los varios procesos que se ejecutan simultáneamente o una secuencia rigurosa definida. El defecto se produce cuando el código que coordina dichos eventos es inadecuado.
Aspecto de la prueba
¿Quién realiza las pruebas?
Muchas veces se manifiestan dificultades para separar los sentimientos personales
del proceso de prueba. Por lo tanto, a menudo se utiliza un equipo de prueba
independiente.
Es claro que nadie entrega su código para la prueba sino piensa que el código a
sido realizado de acuerdo con la especificación, pero se puede estar demasiado
apegado al código como para ser realmente objetivos y reconocer algunos de
los defectos más sutiles.
La visión de los objetos de prueba
Al probar un componente, un grupo de componentes, un
subsistema o un sistema, la propia visión del objeto de prueba puede
afectar la forma que se lleva acabo la prueba. Si el objeto de prueba se ve desde afuera, como una “caja negra” o
“caja cerrada” , cuyo contenido se desconoce, las pruebas consisten
en alimentar la caja negra con entradas y anotar cuales son las
salidas que se producen.
La desventaja de utilizar la prueba de caja negra en un componente, es que no
se pueden seleccionar los casos de prueba más significativos porque no se tiene
un conocimiento acabado del procesamiento.
Para superar este problema el objeto de prueba puede verse como una “caja
abierta”, “caja de cristal”, “caja blanca” o “caja transparente”, luego; se puede
utilizar la estructura interna del objeto de prueba, para probar las diferentes
maneras.
Prueba Unitaria
El proceso es similar al que se utiliza, cuando se prueba un programa asignado
como tarea en la universidad:
1. Se examina el código, leyendo minuciosamente, tratando de localizar defectos en
los algoritmos, los datos y la sintaxis.
2. Comparar el código con las especificaciones y con el diseño hasta tener la certeza
de considerar todos los casos relevantes.
3. Finalmente se desarrollan los casos de prueba para demostrar que las entradas se
convierten realmente en las salidas esperadas.
El examen del código: El proceso de revisión del código es similar al de la revisión de
requerimientos y diseño. Se conforma un equipo, integrado por el
mismo programador y tres o cuatro expertos técnicos.
Recorridos de código: Se presenta el código y la documentación correspondiente al equipo
de revisión y el equipo comenta sobre su exactitud.
Inspección de código: Este método fue presentado por Fagan (1976) en IBM. Es similar a una recorrida pero más formal.
El equipo revisa el código y la documentación contra una lista de puntos de interés preparados.
Éxito de las revisiones de código: Puede sentirse incomodidad al tener a un grupo revisando el código
propio
test case (Casos de Prueba):
- Un buen test case es aquel que tiene una alta probabilidad de encontrar un defecto no descubierto, no aquel en que el programa funciona correctamente.
- Un buen test case no es redundante, ni muy simple, ni muy complejo idealmente, el mejor de su clase.
- Un exitoso test case es aquel que descubre un defecto no descubierto.
- El diseño de test cases es muy difícil.
- El Testing no puede mostrar la ausencia de defectos, sólo puede mostrar que los defectos están presentes.
Prueba de Integración
Integración Ascendente (bottom – up): Cuando se usa este método, se prueba primero en forma individual
cada componente al nivel más bajo de la jerarquía del sistema. Luego
los próximos componentes que se prueban son lo que llaman a los
ya probados.
Integración Descendente (Top – Down): El componente principal se prueba aisladamente, después todos los
componentes llamados por el componente se combinan y se
prueban como una unidad mayor. Este enfoque se vuelve a aplicar
hasta que todos los componentes estén incorporados. En la prueba descendente no se necesitan programas controladores.
Por otro lado la escritura de los talones puede ser difícil, porque estos
deben permitir probar todas las posibles condiciones.
Integración Big - Bang: Cuando todos los componentes se prueban por separado, existe la
tentación de mezclarlos juntos como un sistema final y ver si
funciona la primera vez. Muchos programadores usan este enfoque para sistemas pequeños,
pero no es práctico para los grandes.
Integración Intercalada: El sistema de se como tres capas, al igual que un
sandwich: en el medio la capa objetivo, los niveles
por encima del objetivo y los niveles por debajo del
objetivo. Este enfoque permite utilizar el enfoque bottom - up para
verificar lo correcto de los utilitarios al principio de la
prueba. Por lo tanto no se necesita escribir talones para
los utilitarios porque están disponibles.
