Resumen Java Tema Pruebas y Calidad del Software

Las pruebas buscan errores y verifican que el programa cumple lo esperado y lo hace bien.
Son costosas en tiempo y recursos.

Hay que probar:
    Que haga lo esperado y no haga cosas inesperadas.
    Se buscan Situaciones anormales y fallos.
    Entradas de datos correctas e incorrectas.
    Probar primero partes pequeñas y luego las grandes.
   
Hay que documentar los casos de prueba, que parámetros recibe, qué debería devolver y que devuelve en cada caso.
Debería realizarlas automáticamente una aplicación o un usuario ajeno, no el propio programador.
Cada vez que se corrige un fallo hay que volver a probarlo todo.

-VERIFICACIÓN: Cumple la especificación?
-VALIDACIÓN: Cubre la necesidad del cliente?


INSPECCIÓN DE SOFTWARE: Análisis técnico del código, las especificaciones y los diagramas para comprobar que sea lo estipulado.
    Puede hacerse en todas las fases del desarrollo, y en partes incompletas al ser estático.
    (errores de compilación, código no alcanzable, variables no inicializadas o sin uso, bucles infinitos)
   
PRUEBAS DE SOFTWARE: Ejecutar el programa con datos ficticios y analizar las salidas.
    Solo pueden hacerse trás la fase de construcción y requieren planificación porque es dinámico.
   
    -De Integración:
        Sistema/Subsistema = funcionan juntos el sistema y componentes?
            *Tienen que ser incremental, se añade algo, se prueba, y repetir todo el proceso.
            Descendente>    1º estructura, luego los componentes
            Ascendente>        1º las funcionalidades pequeñas y luego se agrupan
           
        Rendimiento = fiabilidad y respuesta ante la carga de trabajo, buscar sobrecargas
        Entrega y aceptación = cumple los casos de uso y requerimientos?
            Los resultados a las entradas son los esperados?
            Forzar todos los errores y desbordamientos
           
       
    -Unitarias o de componentes, son correctos y funcionan cada clase o cada módulo?
        Descendente>    el control es el programa principal, se crean módulos colaboradores falsos, probar y sustituir por el real.
        Ascendente>        crear un monitor de prueba para examinar los módulos de nivel mas bajo, probar y sustituir por el módulo superior real, y volver a probar (regresión)
       
    -De Sistemas Ori.Obj: es correcto y útil el esquema de clases? Probar: todos los atributos y métodos de cada clase.
        Clases>    comprobar que hacen lo definido.
            *Basadas en escenarios =    probar los casos de uso mas comunes, después los menos, y luego los excepcionales.
            *Basadas en Subprocesos =    en cadenas de eventos.
           
       
   
DOCUMENTACION:
Para la organización y mantenimiento del código hay que documentarlo, indicando información sobre las funcionalidades, parámetros y resultados.
Precediendo de  /** COMENTARIO */  las clases, interfaces, métodos o atributos, con la herramienta (javadoc *.java -private –d javadoc) generamos la documentación en html automáticamente. Son heredables.
    -Etiquetas: @param, @return, @throws, @exception, @author, @version.