Resumen Testing.

1.-Conceptos fundamentales del testeo de software

El objetivo de las pruebas es localizar y subsanar el mayor número de deficiencias
lo antes posible.
¿Qué aspectos debe contemplar una prueba bien definida?
Identificador = Código único de la prueba.
Valores de entrada = Descripción de los datos de entrada de un objeto de prueba.
Resultados esperados = Datos de salida que se espera se produzcan.
Precondiciones = Situación previa a la ejecución de la prueba o características de
un objeto de prueba antes de ejecutar un caso de prueba.
Postcondiciones = Características de un objeto de prueba tras la ejecución de la
prueba.
Dependencias = Relación u orden de dependencia entre casos de pruebas.
Acciones = Pasos a llevar a cabo para ejecutar la prueba.
Requisito vinculado = Relación de requisitos que se pretenden validar con la
ejecución de la prueba.

2.-Niveles de testing: la calidad en cada etapa del ciclo de vida

CICLO DE VIDA SOFTWARE: marco de referencia que define el enfoque general
del desarrollo software, indicando los procesos y actividades a realizar desde la
definición del producto software hasta su finalización de uso; así como los
entregables que se van a generar y entregar al cliente (ISO 12207).

Modelo en cascada(clásico)
El modelo en cascada es un proceso de desarrollo secuencial, en el que el
desarrollo de software se concibe como un conjunto de etapas que se ejecutan
una tras otra. Se le denomina así por las posiciones que ocupan las diferentes
fases que componen el proyecto, colocadas una encima de otra, y siguiendo un
flujo de ejecución de arriba hacia abajo, como una cascada.

-Definición de Requerimientos: En esta fase se hace un análisis de las

necesidades del cliente para determinar las características del software a
desarrollar, y se especifica todo lo que debe hacer el sistema sin entrar en detalles
técnicos. Hay que ser especialmente cuidadoso en esta primera fase, ya que en
este modelo no se pueden añadir nuevos requisitos en mitad del proceso de
desarrollo.

-Análisis y diseño del software: En esta etapa se describe la estructura interna del
software, y las relaciones entre las entidades que lo componen.
-Implementación y prueba de unidades: En esta fase se programan los requisitos
especificados haciendo uso de las estructuras de datos diseñadas en la fase
anterior. La programación es el proceso que lleva de la formulación de un
problema de computación, a un programa que se ejecute produciendo los pasos
necesarios para resolver dicho problema.
-Integración y prueba del sistema: Como su propio nombre indica, una vez se
termina la fase de implementación se verifica que todos los componentes del
sistema funcionen correctamente y cumplen con los requisitos.
-Operación y mantenimiento: Una vez se han desarrollado todas las
funcionalidades del software y se ha comprobado que funcionan correctamente, se
inicia la fase de instalación y mantenimiento. Se instala la aplicación en el sistema
y se comprueba que funcione correctamente en el entorno en que se va a utilizar.

Modelo iterativo (RUP, XP, etc.): Se planifica un proyecto en distintos bloques

temporales que se le denominan iteración. En una iteración se repite un
determinado proceso de trabajo que brinda un resultado más completo para un
producto final, de forma que quien lo utilice reciba beneficios de este proyecto de
manera creciente.
-Definición de requerimientos.
-Análisis y diseño del software.
-Implementación y prueba de unidades.
-Integración y prueba del sistema.
-Operación y mantenimiento.
y se vuelve a repetir
-Definición de requerimientos.
-Análisis y diseño del software.
-Implementación y prueba de unidades.
-Integración y prueba del sistema.
 -Operación y mantenimiento.

Modelo evolutivo espiral: Se utiliza con éxito en proyectos donde el coste de un

fallo es un gran riesgo, de ahí que su principal aportación sea considerar la gestión
de esos riesgos. Habitualmente tiene sentido aplicar este método en proyectos
grandes, largos, caros y complejos. el modelo en espiral consiste en seguir
ciclos crecientes de cuatro fases cada uno, que se van realizando siguiendo
una forma de espiral. En cada ciclo se pasa por dichas fases bien definidas,
como en el modelo de cascada, pero con capacidad de evolucionar su
complejidad con cada ciclo. Por tanto, se trata de un modelo evolutivo que,
conforme avancen los ciclos, aumentará el tiempo de ejecución, así como el
volumen de código fuente desarrollado y la complejidad de la gestión de riesgos y
de la planificación.
Las fases por las que pasa cada ciclo de la espiral son:

1. Planificación. Se determinan los objetivos y el alcance del ciclo que

comienza, tras un necesario ejercicio de investigación. Con cada iteración, se irá

incrementando el tamaño de software entregado y la funcionalidad cubierta.

2. Análisis de Riesgo. Se evalúa todo aquello que pueda afectar al proyecto

según el estado en que se encuentre y su grado de avance. Para ello, se

diseñarán los prototipos que deberán ser validados en el ciclo.

3. Implementación. Se desarrolla y valida el software según el alcance

acordado, el cual está íntimamente relacionado y condicionado con el análisis de

riesgos anterior.

4. Evaluación. Antes de proceder a realizar otra vuelta en la espiral, se debe

prestar atención a lo que sucedió en la vuelta anterior. Se debe analizar en detalle

si los riesgos detectados anteriormente ya tuvieron solución. Básicamente, esta

fase servirá para determinar el avance del proyecto y dar pistas de hacia dónde

debe enfocarse la próxima iteración.

Modelos Agiles (Scrum): Es un proceso en el que se aplican de manera regular un
conjunto de buenas prácticas para trabajar colaborativamente, en equipo y obtener
el mejor resultado posible de proyectos, caracterizado por: 1

 Adoptar una estrategia de desarrollo incremental, en lugar de la

planificación y ejecución completa del producto.
 Basar la calidad del resultado más en el conocimiento tácito de las
personas en equipos auto organizados, que en la calidad de los procesos
empleados.
 Solapar las diferentes fases del desarrollo, en lugar de realizar una tras otra
en un ciclo secuencial o en cascada.

Pruebas a través del ciclo de vida: Modelo-V

El lado izquierdo de la V representa la descomposición de las necesidades, y la

creación de las especificaciones del sistema. El lado derecho de la V representa la
integración de las piezas y su verificación. V significa «Verificación y validación».
Es muy similar al modelo de la cascada clásico ya que es muy rígido y contiene
una gran cantidad de iteraciones.
Minimización de los riesgos del proyecto
Mejora la transparencia del proyecto y control del proyecto, especificando los
enfoques estandarizados, describe los resultados correspondientes y funciones de
responsabilidad. Permite una detección temprana de las desviaciones y los
riesgos y mejora la gestión de procesos, reduciendo así los riesgos del proyecto.
Mejora y Garantía de Calidad
Como un modelo de proceso estándar, asegura que los resultados que se
proporcionan sean completos y contengan la calidad deseada. Los resultados
provisionales definidos se pueden comprobar en una fase temprana. La
uniformidad en el contenido del producto mejora la legibilidad, comprensibilidad y
verificabilidad.
Reducción de los gastos totales durante todo el proyecto y sistema de Ciclo
de Vida
El esfuerzo para el desarrollo, producción, operación y mantenimiento de un
sistema puede ser calculado, estimado y controlado de manera transparente
mediante la aplicación de un modelo de procesos estandarizados. Reduciendo la
dependencia en los proveedores y el esfuerzo para las siguientes actividades y
proyectos.
Mejora de la comunicación entre todos los inversionistas
La descripción estandarizada y uniforme de todos los elementos pertinentes y
términos es la base para la comprensión mutua entre todos los inversionistas. De
este modo, se reduce la pérdida por fricción entre el usuario, comprador,
proveedor y desarrollador.

Técnicas de Testing: métodos para generar un caso de prueba

Técnicas Estáticas de testing:

Revisiones
Análisis del flujo de control
Análisis del flujo de datos
Métricas compilador /analizador
Técnicas dinámicas de testing:

CAJA NEGRA: Clases de equivalencia.

Análisis de valores límite.
Pruebas de casos de uso.
Tablas de decisión, de transición de estado.

TECNICAS BASADAS EN LA EXPERIENCIA

La técnica de caja negra también se denomina prueba funcional o prueba

orientada a la especificación

Prueba sin éxito salida SI

Entrada  caja negra ¿cumple expectativas? 
Prueba con éxito NO

Métodos de caja negra:

Partición de equivalencias o clases de equivalencia
Análisis de valores límite
Pruebas de casos de uso
Tablas de decisión, de transición de estado
CAJA BLANCA:
Cobertura de sentencias
Cobertura de decisión
Cobertura de condición (simple y múltiple).
Cobertura de caminos

El tester conoce la estructura interna del código, i.e., la jerarquía de componentes,

flujo de control y datos, etc.
Los casos de prueba son seleccionados en base a la estructura del código.
¡La estructura del trabajo es el foco de atención!

La técnica de caja blanca también es conocida como prueba basada en la

estructura o prueba basada en el flujo de control.
Los métodos de caja blanca requieren el apoyo de herramientas, lo que asegura
la calidad de las pruebas e incrementa su eficiencia

Dada la complejidad de las mediciones necesarias para las pruebas de caja

blanca, la ejecución manual implica: consumo de tiempo y recursos, dificultad en
la implementación y propensión a errores.

Método: Cobertura de Sentencias

C0 = 100% * (nº sentencias ejecutadas / nº total sentencias)

Método: Cobertura de Decisión

C1 = 100% * (nº decisiones ejecutadas / nº total decisiones)

Método: Cobertura de Condición

Tipos:

Cobertura de condición simple

Cobertura de condición múltiple
Método: Cobertura de Condición SIMPLE
Cada subcondición atómica de una sentencia condicional tiene que tomar, al
menos una vez, los valores verdaderos ("true") y falso ("false").

Método: Cobertura de Condición MÚLTIPLE

Todas las combinaciones que pueden ser creadas utilizando permutaciones de las
subcondiciones atómicas deben formar parte de las pruebas.

Método: Cobertura de Camino

Objetivo: alcanzar un porcentaje definido de cobertura de camino (CC):

CC = 100% * (nº caminos cubiertos / nº total caminos)