Conceptos Básicos de Testeo

Pag. 1 de 31
 INDICE

1 Prefacio ...................................................................................................... 4
2 Introducción al Testeo .............................................................................. 4
3 Fundamentos de Testeo ........................................................................... 5
3.1 Definición ............................................................................................. 5
3.2 Asegurar Testeabilidad ........................................................................ 6
3.3 Principios de Testeo............................................................................. 6
3.4 Criterios de Entrada y Salida ............................................................... 7
3.5 Estrategias de Testeo .......................................................................... 7
3.5.1 Testeo estático.............................................................................. 7
3.5.2 Testeo Dinámico ........................................................................... 7
3.6 Técnicas de Testeo .............................................................................. 8
3.6.1 Testeo de Caja Negra ................................................................... 8
3.6.2 Testeo de Caja Blanca .................................................................. 8
3.7 Ciclo de vida de Testeo ........................................................................ 8
3.8 Que es Testeado.................................................................................. 9
3.9 El Equipo de Testeo ............................................................................. 9
4 El Proceso de Testeo .............................................................................. 10
4.1 Planificación de Testeos .................................................................... 11
4.1.1 El Plan Administrativo ................................................................. 11
4.1.2 Evaluación de Riesgos ............................................................... 11
4.1.3 Foco del Testeo .......................................................................... 12
4.1.4 Objetivos del Testeo ................................................................... 13
4.1.5 Estrategia de Testeo ................................................................... 14
4.1.6 Estrategia de Construcción ......................................................... 14
4.1.7 gestión de Defectos y Control de Cambios ................................. 15
5 Niveles de Testeo .................................................................................... 15
5.1 Modelo de Testeo .............................................................................. 16
5.2 Testeo Unitario ................................................................................... 16
5.3 Testeo de integración......................................................................... 17
5.4 Testeo de Sistema ............................................................................. 17
5.5 Testeo de integración de sistemas..................................................... 18
5.6 Testeo de aceptación ......................................................................... 19
5.7 Testeo de Operabilidad ...................................................................... 20
6 Tipos de Testeo ....................................................................................... 21
6.1 Testeo Funcional................................................................................ 21
6.1.1 Testeo de Control y auditorias .................................................... 21
6.1.2 Testeo de Conversión ................................................................. 22
6.1.3 Testeo de Procedimientos y documentación de usuario............. 22
6.1.4 Testeo de Manejo de Errores...................................................... 23
6.1.5 Testeo de Funciones .................................................................. 23
6.1.6 Testeo de Instalación .................................................................. 23
6.1.7 Testeo de interfaces ................................................................... 24
6.1.8 Testeo en Paralelo ...................................................................... 24
6.1.9 Testeo de regresión .................................................................... 25
6.1.10 Testeo de Flujo de Transacciones .............................................. 25
6.1.11 Testeo de Usabilidad .................................................................. 25

Pag. 2 de 31
6.2 Testeo Estructural .............................................................................. 26
6.2.1 Testeo de Recuperación y respaldo ........................................... 26
6.2.2 Testeo de contingencia ............................................................... 27
6.2.3 Testeo de flujo de trabajo............................................................ 27
6.2.4 Testeo Operacional..................................................................... 28
6.2.5 Testeo de Performance .............................................................. 28
6.2.6 Testeo de Seguridad ................................................................... 29
6.2.7 Testeo de Stress/Volumen .......................................................... 29
6.3 Relaciones entre tipos y niveles de testeo ......................................... 30

Pag. 3 de 31
1 Prefacio
Este documento pretende introducir los conceptos básicos de la metodología del ciclo de vida
completo de testeo, así como también las técnicas y procesos necesarios para el testeo de
aplicaciones.
El propósito del método de testeo es proveer una metodología estructurada y disciplinada para
ejecutar el testeo. Incluye la planificación de testeo, el gerenciamiento y control del proceso de
testeo, y las técnicas de testeo.

2 Introducción al Testeo

Este documento será una guía que contiene los conceptos básicos para testear en forma exitosa
un producto en desarrollo.
Un elemento critico en el desarrollo exitoso de cualquier aplicación de software es el testeo
efectivo. Incluye los requerimientos de testeo, el diseño, la documentación, y los procedimientos
operacionales, y es una parte inseparable del desarrollo de un producto. El Testeo es uno de los
caminos por los cuales el producto logra una alta calidad.

Pag. 4 de 31
3 Fundamentos de Testeo
El testeo es ejecutado para asegurar que se ha desarrollado un producto usable desde el punto
de vista del usuario final. Los objetivos primarios de testeo son:
• El sistema debe cumplir con las necesidades del usuario. “El sistema correcto ha sido
construido”
• Los requerimientos del usuario fueron construidos como estaban especificados “el
sistema ha sido construido correctamente”
Otros objetivos secundarios del testeo son:
• Inspirar confianza en el sistema a través del involucramiento del usuario
• Asegurar que el sistema trabajará eficientemente desde el punto de vista funcional y
desde el punto de vista de la performance
• Establecer exactamente que es lo que el sistema hace (y que no hace) para que el
usuario no reciba sorpresas al momento de la implementación
• Identificar áreas problemáticas donde los entregables del sistema no están de acuerdo
a las especificaciones
• Mejorar los procesos de desarrollo que causan error.
Logrando estos objetivos se asegurara que:
• Los riesgos son minimizados
• Un producto de alta calidad es entregado
• La habilidad para entregar aplicaciones de alta calidad es mejorada.

El propósito de un método de testeo es proveer un marco y un conjunto de disciplinas y

estrategias de testeo de una aplicación, logrando un proceso consistente y repetible.

3.1 Definición
El testeo es la búsqueda sistemática de defectos en los entregables de un proyecto. Es el proceso
de examinar la salida de un proceso bajo determinadas consideraciones, comparando los
resultados contra un grupo de expectativas predeterminadas, y trabajando sobre las diferencias
(generalmente llamados defectos).

A lo largo de las discusiones de los conceptos de testeo, se usaran muchos términos que son
fundamentales.
• Validación: el acto de asegurar conformidad con el requerimiento original. Un ejemplo es
la comparación de la respuesta de un sistema actual de una transacción on-line que fue
originalmente esperada, requerida y finalmente aprobada en el diseño externo.
• Verificación: Es el acto de chequear un producto de trabajo actual para asegurar que se
ejecuta como esta especificado por su predecesor. La comparación de el código de un
modulo contra su documento de especificaciones de diseño técnico es un ejemplo.

Pag. 5 de 31
 • Proceso: Una serie de acciones ejecutadas para lograr un resultado deseado que
transforman una serie de entradas en un conjunto de salidas relevantes.
• Expectativas: Un conjunto de requerimientos o especificaciones que debe cumplir la
salida resultante de un proceso para que sean aceptables.
• Diferencias: Desviaciones en las salidas de un proceso comparándolas contra las salidas
esperadas. Estas diferencias generalmente son llamadas defectos.
El testeo es un proceso de verificación y/o validación de una salida contra un conjunto de
expectativas y observación de las diferencias.

3.2 Asegurar Testeabilidad

En el orden de poder evaluar si una salida alcanza o excede una expectativa dada, dicha
expectativa debe ser declarada en la terminología especifica de testeo. Esto significa que cuando
las características de una salida que esta siendo testeada es comparada contra las
características esperadas, estas podrán ser mapeadas en una forma clara y no ambigua.
El nivel requerido de detalle cuando se documenta y testean los requerimientos puede ser que
no este aun disponible. El proceso de especificación de requerimientos y diseño externo deberá
evolucionar hasta llegar al requerimiento funcional a partir de una colección de declaraciones
imprecisas de las necesidades del usuario. Se puede chequear la testeabilidad del requerimiento
o de la especificación del requerimiento asegurando que este sea:
• Especifico
• Medible
• Realizable o alcanzable
• Realista
• Oportuno
Estas especificaciones formaran parte de la base del criterio a utilizar al momento de testear el
sistema.

3.3 Principios de Testeo

A continuación se presentan algunos principios básicos de testeo:

• Un autor no debe ser el testeador final de su propio Producto de trabajo
• Un testeo exhaustivo es deseable pero esto NO es siempre practico
• Los resultados esperados deben ser documentados para cada testeo.
• Las condiciones validas e invalidas deben ser testeadas.
• Los resultados esperados e inesperados deben ser validados.
• Los casos de testeo podrán ser reusados.

Pag. 6 de 31
3.4 Criterios de Entrada y Salida

El concepto de establecer prerrequisitos (criterio de entrada) y post-condiciones (criterio de

salida) es extremadamente útil en todos los procesos, el testeo no es una excepción.
Los criterios de entrada son los factores que deben ser presentados, como mínimo, para ser
capaces de comenzar una actividad. En el testeo de integración, antes que un modulo pueda ser
integrado en un programa, debe ser compilado sin errores y el testeo unitario debe estar
finalizado. Si los criterios de entrada para la próxima fase han sido logrados, la próxima fase
puede comenzar aunque la fase actual se este ejecutando, esto se ve reflejado en las actividades
que se solapan en un cronograma. Los criterios de salida son esos factores que se deben
presentar para declarar una actividad como terminada. El criterio de salida debe ser
explícitamente expresado.

3.5 Estrategias de Testeo

Las estrategias de testeo se catalogan en dos grandes clases: testeo estático y dinámico.
Ambas son efectivas si son aplicadas en forma apropiada y pueden ser usadas a lo largo del
ciclo de vida de testeo.

3.5.1 Testeo estático

El testeo estático es una examinación detallada de las características de un producto de trabajo

contra un conjunto esperado de atributos, experiencias y estándares.
Descubrir las diferencias o defectos en etapas tempranas de un proyecto, esto resultara en
cambios menos caros y con consecuencias menores. En el ciclo de vida del desarrollo, el único
testeo usualmente disponible durante la fase de preconstrucción es el testeo estático.
Algunos ejemplos representativos de testeo estático son:
• Revisión de planes
• Inspecciones de diseño o código
• Inspecciones de planes de Testeo
• Revisión de casos de testeo.

3.5.2 Testeo Dinámico

El testeo dinámico es un proceso de verificación o validación operando sobre un producto de

trabajo y observando su comportamiento a entradas cambiantes. Cuando un modulo es testeado
en forma estática observando su código y documentación, se ejecuta también el testeo dinámico
analizando el comportamiento de la lógica y la respuesta a las entradas.
Algunos ejemplos representativos de testeo dinámico son:
• Confección de prototipos de aplicaciones

Pag. 7 de 31
 • Ejecución de casos de testeo bajo un sistema en funcionamiento
• Simulación de escenarios con usuarios finales reales para testear la usabilidad.
• Testeo en paralelo en un ambiente de producción

3.6 Técnicas de Testeo

Las técnicas mas comunes de testeo son el Testeo de Caja Negra, el Testeo de Caja Blanca.
Las técnicas de testeo que examinan el funcionamiento interno y los detalles de un producto de
trabajo son utilizados en la estrategia del testeo de caja blanca. La técnica que únicamente testea
como se comporta una unidad solamente examinando sus entradas y salidas corresponden al
testeo de caja negra.

3.6.1 Testeo de Caja Negra

En la estrategia de testeo de caja negra, los testeadores tienen una visión de salida del sistema,
brindándole mayor importancia a el “que esta hecho” y no el “como esta hecho”.

El testeo de caja negra es usado en todos los niveles de testeo. Para testear el sistema se
ingresan todas las combinaciones de entradas posibles y las salidas son examinadas, además,
para ejectutar un testeo adecuado del sistema se deben utilizar entradas validas e invalidas.

3.6.2 Testeo de Caja Blanca

En la estrategia de caja blanca, los testeadores tienen una visión interna del sistema, deben
testear el “como esta hecho” y no solo “que esta hecho”

El Testeo de Caja Blanca esta lógicamente orientado. Los testeadores deben probar la ejecución
de todos los posibles caminos de los flujos de control a través del programa.

Esta estrategia es esencialmente un método de testeo Unitario (algunas veces usado en el testeo
de Integración o en el testeo de Operabilidad) y es ejecutado siempre por personas con
habilidades técnicas.

3.7 Ciclo de vida de Testeo

El proceso de desarrollo de software es un método sistemático que evoluciona desde una vaga
declaración de un problema de negocios a una representación funcional concreta y detallada de
la solución del problema.
El proceso de desarrollo en si mismo esta dividido en un numero discreto de fases alineadas al
ciclo de vida representando las fases mas notorias. Al final de cada fase, se realiza una
inspección de un punto especifico para asegurar que la fase actual ha sido completada
apropiadamente y que el equipo de proyecto esta preparado para abordar la siguiente fase. El

Pag. 8 de 31
proceso usado para definir y construir un producto de software es el ciclo de vida de desarrollo
de aplicaciones. El proceso de testeo se alineara a estas fases. Las actividades de desarrollo y
testeo serán coordinadas de tal forma que se complementen unas a otras.
Cuando un producto de trabajo es creado por el desarrollador, debe ser testeado para asegurar
que cumple los requerimientos y especificaciones correspondientes a esa fase. Esta estrategia
de testeo minimiza los riesgos de entregar una solución propensa a errores o que no cumple las
necesidades del usuario final. En este documento, el testeo en cada fase del ciclo de vida del
desarrollo es referido como el ciclo de vida de testeo. Se testearan los productos de trabajo
internos que formen parte del proceso de desarrollo.
El testeo comienza con los requerimientos y sigue a lo largo del ciclo de vida de la aplicación.
Aún después que una aplicación ha sido puesta en producción, el testeo continua jugando un rol
importante en el proceso de mantenimiento. Mientras una aplicación esta en mantenimiento,
todos los cambios a la aplicación deben ser testeados para asegurar que continua cumpliendo
con la solución funcional para la cual fue diseñada originalmente, sin impactar al resto de la
aplicación o a los otros sistemas con los que interactúa. Cuando el ambiente cambia, la aplicación
debe ser retesteada en todas las áreas para asegurar que continua funcionando como era
esperado. A esto se le llama testeo de regresión.

3.8 Que es Testeado

En un sistema en desarrollo o en mantenimiento usualmente se testea lo siguiente:

• El funcionamiento de los procedimientos de la aplicación, manuales y automáticos en su
ambiente de operaciones para asegurar que opera como esta especificado.
• Las condiciones de excepciones (errores) que puedan ocurrir para asegurar que podrán
ser manejadas apropiadamente.
Los entregables internos de las fases de desarrollo para demostrar que estos se encuentran
alineados con los requerimientos originales.

3.9 El Equipo de Testeo

El hecho de desarrollar un sistema requiere que estén involucrados un grupo de individuos que
aporten variados recursos, habilidades, experiencias y puntos de vista del proceso. Cada uno
juega un rol necesario, y puede desempeñar mas de un rol, y los roles pueden cambiar a lo largo
del ciclo de vida del desarrollo.
Aparte de los roles de sponsor, usuario y desarrollador definido en el proceso de desarrollo de
aplicaciones, se encuentra también el testeador. Su rol se encarga de validar y verificar los
productos de trabajo internos y finales del sistema.

Pag. 9 de 31
Es fuertemente recomendable que el equipo de desarrollo y el sponsor participen en el proceso
de testing, ya que involucra al usuario en etapas tempranas del ciclo de vida del desarrollo
facilitando en cierta forma su aceptación.
Algunos beneficios son:
• Envuelve a los desarrolladores y usuarios en inspecciones de los entregables durante
fases tempranas del ciclo de vida del desarrollo sirviendo a los desarrolladores a ganar
un conocimiento del negocio.
• El testeo será mas minucioso y completo ya que los usuarios con un gran conocimiento
del negocio serán involucrados en el testeo funcional.
• El Testeo de aceptación funcional proveerá una validación formal de un sistema mas
completamente testeado.
• El usuario se familiarizará con los formularios y procedimientos a ser usados en el nuevo
sistema previo a su implementación.
• Los Usuarios que ganaron experiencia usando el sistema en el periodo de testing serán
capaces de entrenar a otros usuarios y “vender ” el nuevo sistema.

Es importante notar lo siguiente:

• El alcance de la participación de los usuarios dependerá de la naturaleza específica de
la aplicación del proyecto.
• El usuario estará envuelto en el testeo dinámico y lo realizará cuando el sistema este lo
suficientemente estable como para ejecutar el testeo sin interrupciones continuas.
• Cada usuario debe ser responsable de representar su organización específica y proveer
el conocimiento del producto para testear efectivamente la aplicación.
• El equipo de testeo es responsable de asegurarse que el sistema ejecuta
adecuadamente las especificaciones del sistema acordadas. Es responsabilidad del
grupo de testeo aceptar o rechazar el sistema basado en el criterio que fue documentado
y aprobado en el plan de testeo.

4 El Proceso de Testeo

El proceso básico de testeo consiste en cuatro pasos básicos, ellos son:

• Planificar los testeos
• Preparar los testeos
• Ejecutar los testeos
• Reportar los resultados
El testeo es un proceso iterativo. Estos pasos son seguidos en todos los niveles del proyecto y
repetidos para cada nivel de testeo requerido en el ciclo de vida de desarrollo

Pag. 10 de 31
El Testeo de la aplicación será abordado en etapas. Cada etapa representa un nivel conocido de
integración física y calidad. Estas etapas de integración son conocidas como niveles de testeo.
Los niveles de testeo usados en el ciclo de vida del desarrollo de aplicaciones son:
• Testeo Unitario
• Testeo de Integración
• Testeo de Sistema
• Testeo de Integración de Sistemas
• Testeo de Aceptación
• Testeo de Operabilidad.

La primer instancia de planes apunta al testeo de todo el proyecto a un alto nivel y es llamado el
Plan Maestro de Testeo. Los niveles sucesivos de Testeo serán manejados como un refinamiento
al Plan Maestro de Testeo para alcanzar las necesidades especificas de cada nivel de Testeo,
en el ciclo de vida de Testeo se le llama Planes detallados de Testeo. Los cuales se explican con
mas detalle en las siguientes secciones.

4.1 Planificación de Testeos

La planificación es en si misma un proceso. Ejecutando cada paso del proceso de planificación

se podrá asegurar que el plan esta construido sistemáticamente y completamente.
Documentando esos pasos se podrá asegurar que el plan en si mismo es testeable por otros que
deben aprobarlo.

4.1.1 El Plan Administrativo

Este plan hace referencia a la organización del equipo de testeo, los cronogramas de testeo y
los requerimientos de recursos. Estos planes deberán ser totalmente integrados en los
cronogramas del proyecto.

4.1.2 Evaluación de Riesgos

La evaluación de riesgos forma parte de la planificación porque el análisis de riesgos debe ganar
un entendimiento de las fuentes potenciales y causas de fallas y sus costos asociados. Midiendo
los riesgos anteriormente al testeo podrá ayudar de dos formas:
• Las aplicaciones de alto riesgo pueden ser identificadas y un testeo mas exhaustivo
podrá ser ejecutado.
• El análisis de riesgo podrá ayudar a prestar atención a los componentes críticos y/o áreas
a las cuales enfocar el testeo que son mas importantes para el punto de vista del sistema
o del usuario.

Pag. 11 de 31
El riesgo es el producto de la probabilidad de ocurrencia de un error y el costo y la consecuencia
de la falla.
Existen tres áreas claves que tienen una influencia significativa en un proyecto, ellos son:
• Tamaño del proyecto
• Experiencia con la tecnología
• Estructura del proyecto
El factor del riesgo/costo potencial, independientemente de un error particular, debe ser tomado
en consideración cuando se desarrolla una estrategia de testeo global y un plan de testeo para
un sistema en particular.
Una estrategia para la evaluación de riesgo puede ser:
• Listar que puede salir mal una vez que la aplicación fue implementada y la probabilidad
de ocurrencia.
• Determinar el costo de la falla. Por ejemplo perdida del negocio, perdida de imagen,
perdida de confianza en el sistema, riesgo de seguridad y riesgo financiero para cada
uno de los problemas.
• Determinar que nivel de confianza es requerido y cuales son los factores críticos de éxito
de una aplicación en desarrollo desde el punto de vista del testing.
Una estrategia y sus planes subsecuentes para administrar estos riesgos formaran parte básica
de la estrategia de testeo.
• Cuanto esfuerzo y costo serán puestos en el testeo.
• Cuando la perdida potencial excede el costo del testeo, el costo del testeo es justificado.

4.1.3 Foco del Testeo

El objetivo global del testeo es reducir los riesgos inherentes en los sistemas. La metodología
utilizada debe minimizar esos riesgos. Las áreas son identificadas para prestar especial atención
en riesgos específicos o problemas, donde el esfuerzo del testeo es enfocado y debe ser
manejado por la estrategia de testeo.
Es virtualmente imposible y económicamente inviable ejecutar testeos exhaustivos. Se debe
encontrar el equilibrio adecuado entre testear una aplicación y testearla por debajo de los
estándares de calidad, optimizando los recursos de testeo. Cuando los proyectos no tienen
recursos ilimitados, estos se deben utilizar de la mejor manera posible. Esto trae a luz una
pregunta importante: Que factores de riesgo son los mas importantes para:
• El usuario o el cliente
• El desarrollador desde una perspectiva del sistema
• El proveedor del servicio.
La respuesta esta en considerar las áreas de Foco y seleccionar las que minimizaran riesgos.
El Foco del Testeo puede ser definido como los atributos de un sistema que deben ser testeados
en el orden de asegurar que los requerimientos técnicos y funcionales sean logrados.

Pag. 12 de 31
Algunas de las áreas de foco comúnmente testeadas son:

• Auditabilidad
• Continuidad de procesamiento
• Correctitud
• Mantenibilidad
• Operabilidad
• Performance
• Portabilidad
• Confiabilidad
• Seguridad
• Usabilidad

Cada uno de los puntos de la lista de las áreas de foco comunes es un factor potencial que puede
impactar en el funcionamiento apropiado del sistema. El desafío del testeo efectivo esta en
identificar y priorizar esos riesgos que son importantes para minimizar y enfocar el testeo en esas
áreas.
Por Consiguiente es critico que una decisión en conjunto entre los usuarios y los desarrolladores
sea tomada apuntando a saber que es importante y que no.
Es importante notar que la correctitud es mas ampliamente un foco de testeo de alta prioridad
para la mayoría de las aplicaciones. Algunas consideraciones son:
• Que grado de correctitud es requerido
• Cuales son los riesgos en las funcionalidades que no son testeados exhaustivamente
• Que precio van a pagar los usuarios.
Esto significa que:
• El proceso de determinar las áreas de foco del testeo debe ser selectivo
• Las áreas de foco seleccionadas deben ser ordenadas en términos de prioridad.
El concepto de riesgo y evaluación de riesgos ayuda a tomar una decisión sobre que tanto testeo
hacer, o que tipos de testeo son necesarios a ser ejecutados, una decisión económica. La
economía del testeo y gestión de riesgos determina si los defectos son aceptables en el sistema
y cual es el nivel tolerable de defectos residuales. Esto significa que las decisiones de que será
mas o menos testeado esta basado en el juicio de los desarrolladores y usuarios,
fundamentándose objetivamente en razones económicas.

4.1.4 Objetivos del Testeo

Desde un punto de vista del testeo, los objetivos del testeo son una declaración de lo objetivos a
ser logrados para asegurar que los objetivos del sistema son alcanzados y que el sistema estará
en un nivel aceptable para el usuario.

Pag. 13 de 31
La pregunta es ¿que debe ser logrado?:
• Asegurar que el sistema esta en un nivel de calidad aceptable para las expectativas del
usuario y
• Que el desarrollador este consciente que ha alcanzado sus expectativas
El propósito de desarrollar los objetivos de testeo es definir el criterio de evaluación para saber
cuando el testeo esta completado. Los objetivos de testeo también asisten en medir la efectividad
de los procesos de testeo.
Los objetivos de testeo están basados en:
• Funciones de negocio
• Requerimientos técnicos
• Riesgos.
Los objetivos de testeo son definidos con varios niveles de detalle en varios niveles de testeo.

4.1.5 Estrategia de Testeo

La estrategia de testeo es una expresión a grandes rasgos de la mayoría de las actividades que
en conjunto logran los resultados globales deseados como esta expresado en los objetivos de
testeo. Por ejemplo si un área de foco es la performance (tiempo de respuesta de transacciones)
entonces una estrategia podrá ser un Testeo de Stress y de Volumen en el nivel de testeo de
Integración, antes que el sistema este en el nivel de testeo de sistema.
Como parte del moldeado de la estrategia, los riesgos, restricciones y descuidos deben ser
identificados. Estas consideraciones deben ser tenidas en cuenta en la estrategia. Esto es donde
el planificador puede introducir valor agregado al plan.
Todas las declaraciones de las estrategias están expresadas en términos de alto nivel de
componentes físicos y actividades, recursos, tipos y niveles de testeo, cronogramas y
actividades. El plan estratégico podrá ser especifico al sistema en desarrollo y podrá ser capaz
de ser refinado posteriormente en los planes Detallados para cada nivel de testeo.
Los planes estratégicos mostraran necesidades futuras en cuanto a recursos o cronogramas del
testeo (o desarrollo) y generalmente forzara algunos cambios. Afortunadamente, al detectar las
necesidades en esta etapa, el proyecto tendrá suficiente tiempo de respuesta.
Los planes detallados de Testeo deberán repetir el ejercicio de revisar y fijar los objetivos y
estrategias para cada nivel especifico de testeo. Estos objetivos y estrategias asociadas
(llamadas métodos en los niveles detallados) deberán corresponderse al conjunto de objetivos y
estrategias de su predecesor en el Plan Maestro de Testeo.

4.1.6 Estrategia de Construcción

Un conjunto de planes de testeo incluirán una lista de items a alto nivel para los cuales es
necesario ejecutar el testeo. Estas son las listas de Funciones de Negocio y Funciones

Pag. 14 de 31
Estructurales que serán cubiertas por las actividades de testeo. Se pueden considerar como
planes que servirán de guía en el diseño y la construcción de procesos.
La estrategia de construcción es el método por el cual los componentes del sistema serán
construidos, ensamblados y testeados. Esta guiado por los requerimientos globales del proyecto
tales como prioridades de usuario, cronogramas de desarrollo, entregas urgentes de
funcionalidades especificas, restricciones de recursos o cualquier factor donde exista una
necesidad de construir el sistema en pequeñas partes. Cada versión puede ser ensamblada y
testeada como una unidad separada aunque pueda haber dependencia de versiones previas.
Debe existir mucha coordinación entre los desarrolladores y los testeadores para tomar
decisiones tales como que versiones construir primero, como serán ensamblados los
componentes y como serán testeados para que puedan ser ensamblados en forma correcta con
las versiones ya existentes.

4.1.7 gestión de Defectos y Control de Cambios

El proceso de gestión de Defectos es el proceso por el cual los problemas (reportes de defectos)
son controlados y se les realiza el seguimiento en un proyecto de desarrollo. Esta es una
herramienta clave para los testeadores. Es aconsejable que el mismo sistema de gestión de
Defectos sea utilizado en todo el proyecto. Es recomendable también que un mismo sistema sea
usado para capturar, almacenar y reportar el estado de los defectos. La cantidad de detalle se
vuelve enorme aun en pequeños proyectos.
El proceso de Control de Cambios o gestión de Cambios es similar al de gestión de defectos,
pero se efectúa para los requerimientos validos y reconocidos. En este caso es también
aconsejable, si la cantidad de cambios es muy grande, utilizar un sistema automático de gestión
de cambios. Los Planes de testeo pueden incluir la provisión y uso de los sistemas de gestión de
Defectos y Cambios.

5 Niveles de Testeo

Cada nivel completado representa un hito en el plan del proyecto y cada etapa representa un
nivel conocido de integración y calidad. Estas etapas de integración son conocidas como niveles
de testeo. Los niveles de Testeo utilizados en el desarrollo de aplicaciones son:

• Testeo Unitario
• Testeo de integración
• Testeo de Sistema
• Testeo de integración de Sistemas
• Testeo de Aceptación
• Testeo de Operabilidad

Pag. 15 de 31
En el Ciclo de vida del testeo, el testeo de requerimientos y el testeo del diseño son usados en
niveles diferentes a los mencionados anteriormente.

5.1 Modelo de Testeo

Para cada uno de los niveles, los siguientes atributos deberán ser cubiertos:
• Objetivos
• Cuando ejecutar los testeos
• Entradas/Salidas
• Quien ejecuta los testeos
• métodos
• Herramientas
• Prerrequisitos de Educacion/Entrenamiento

5.2 Testeo Unitario

El nivel de testeo Unitario es el testeo inicial de un código perteneciente a un modulo que ha sido
cambiado o creado. Verifica las especificaciones de programas de la lógica interna de programa
o modulo y valida la lógica.

Objetivos • Testear la función de un programa o unidad de

código.

• Testear la lógica interna

• Verificar el diseño interno

• Testear los diferentes caminos lógicos

• Testear condiciones de excepción y manejo

de errores

Entradas • Diseño Interno de la Aplicación

• Plan Maestro de Testeo

• Plan de Testeo Unitario

Salidas • Reporte de Testeo Unitario

Ejecutante • Desarrollador

métodos • Técnicas de Testeo de Caja Blanca

Herramientas • Debug

Pag. 16 de 31
 • Analizadores de código

Educación • Metodología de Testeo

• Uso efectivo de herramientas

5.3 Testeo de integración

Los niveles de testeo de integración verifican la ejecución apropiada de los componentes y no
requieren que la aplicación bajo testeo interactúe con otras aplicaciones. La comunicación entre
módulos del subsistema es testeado en un ambiente controlado y aislado del proyecto.

Objetivos • Verificar apropiadamente las interfaces entre

módulos y subsistemas

Cuando • Después que los módulos son testeados

unitariamente

Entrada • Diseño interno y externo de la aplicación

• Plan Maestro de Testeo

• Plan de Testeo de integración

Salida • Reporte de Testeo de integración

Ejecutante • Desarrolladores

métodos • Técnicas de caja blanca y caja negra

• gestión de configuración / Problemas

Herramientas • Debug

• Analizadores de código

Educación • Metodología de Testeo

• Uso efectivo de herramientas

5.4 Testeo de Sistema

Verifica la ejecución apropiada de los componentes de la aplicación en su totalidad incluyendo
las interfaces a otras aplicaciones. Los testeos estructurales y funcionales son ejecutados para
verificar la funcionalidad del sistema y la solidez operacional.
Objetivos • Verificar que los componentes del sistema
ejecutan las controles de función

• Ejecutar el testeo entre sistemas

Pag. 17 de 31
 • Demostrar que el sistema se ejecuta tanto
funcional como operacionalmente como
estaba especificado

• Ejecutar los tipos apropiados de testeos

relacionados a Flujo de Transacciones,
Instalación, Confiabilidad, regresión, etc.

Cuando • Después del testeo de Integración

Entradas • Requerimientos detallados y diseño externo

de la aplicación

• Plan Maestro de Testeo

• Plan de Testeo de Sistemas

Salidas • Reporte de Testeo de Sistemas

Ejecutante • Equipo de Desarrollo y Usuarios

métodos • gestión de Problemas/Configuración

Educación • Metodología de Testeo

• Uso efectivo de herramientas

5.5 Testeo de integración de sistemas

Es un nivel de testeo que verifica la integración de todas las aplicaciones, incluyendo las
interfaces internas y externas a la organización, con su hardware, software y componentes de la
infraestructura en un ambiente similar al de producción.

Objetivos • Testear la coexistencia de productos y

aplicaciones que serán ejecutadas en
conjunto en el ambiente similar al de
producción (hardware, software, redes)

• Asegurar que el sistema funciona junto a todos

los componentes de su ambiente como un
sistema en su totalidad.

• Asegurar que las versiones del sistema

puedan ser implementados en el ambiente
actual.

Cuando • Después del testeo de Sistema

Pag. 18 de 31
 Input • Estrategia de testeo

• Plan Maestro de Testeo

• Plan de Testeo de integración de sistemas

Salidas • Reporte de Testeo de integración de Sistemas

Ejecutantes • Testeadores del Sistema

métodos • Técnicas de caja blanca y caja negra

• gestión de Problemas/Configuraciones

Educación • Metodología de Testeo

• Uso efectivo de herramientas

5.6 Testeo de aceptación

Verificar que el sistema alcanza los requerimientos de usuario especificados. Simula el ambiente
de usuario y enfatiza la seguridad, los testeos de documentación y de regresión podrán demostrar
que el sistema se ejecuta como es esperado por el sponsor y por un usuario final de forma tal
que puedan aceptar el sistema.

Objetivos • Verificar que el sistema alcanza los

requerimientos de usuario

Cuando • Después del Testeo de Sistema

Entradas • Necesidades de negocio y requerimientos

detallados

• Plan Maestro de Testeo

• Plan de Testeo de aceptación

salidas • Reporte de Testeo de aceptación

Ejecutante • Usuarios

métodos • Técnicas de caja negra

• gestión de Configuracion/Problemas

Educación • Metodología de Testeo

• Uso efectivo de herramientas

• Conocimiento del Producto

Pag. 19 de 31
5.7 Testeo de Operabilidad
Verifica que la aplicación puede operar en el ambiente de producción. Es ejecutado en forma
posterior o concurrente con el Testeo de aceptación

Objetivos • Asegurar que el producto puede operar en el

ambiente de producción

• Asegurar que el producto alcanza un nivel

aceptable de servicio según el acuerdo de
nivel de servicio

• Asegurar que el producto opera como esta

declarado en los Estándares de Operaciones

• Asegurar que el sistema puede ser

recuperado.

Cuando • En forma concurrente o posterior a que el

Testeo de aceptación sea completado

Entradas • Plan de Testeo de aceptación

• El Usuario aprueba el Testeo de aceptación

• Plan de Testeo de Operabilidad

• Estándares de Operaciones

Salidas • Reporte de Testeo de Operabilidad

Ejecutante • Grupo de Operaciones

métodos • gestión de Problemas/Cambios

Herramientas • Herramientas de monitoreo de performance

Educación • Uso efectivo de herramientas

• Conocimiento del Producto

Pag. 20 de 31
6 Tipos de Testeo
Los distintos tipos de testeo serán ejecutados en forma aislada o combinados con otros casos.
serán ejecutados en los distintos niveles de testeo. El éxito de los procesos de testeo depende
de:
• Seleccionar los tipos de testeo necesarios para lograr los objetivos
• Determinar las etapas o niveles de testeo para los cuales estos tipos de testeo sean mas
efectivamente usados (Un tipo de testeo puede figurar en mas de un nivel)
• Desarrollar las condiciones de testeo para lograr los criterios de evaluación.
• Crear los scripts y los datos de testeo requeridos para ejecutar el testeo.
• Administrar las soluciones de defectos y el retrabajo.

Los tipos de testeo son ampliamente clasificados en

• Testeo funcional
• Testeo Estructural

6.1 Testeo Funcional

El propósito del testeo funcional es asegurar que los requerimientos funcionales del usuario y las
especificaciones son alcanzadas. Las condiciones de testeo son generadas para evaluar la
correctitud de la aplicación. Las siguientes son algunas de las categorías ordenadas
alfabéticamente:

• Testeo de Control y auditorias

• Testeo de Conversión
• Testeo de Procedimientos y documentación
• Testeo de manejo de errores
• Testeo de Requerimientos/Funcionalidad
• Testeo de Inerfaces/InterSistemas
• Testeo de Instalación
• Testeo en paralelo
• Testeo de regresión
• Testeo de flujo de transacciones
• Testeo de Usabilidad

6.1.1 Testeo de Control y auditorias

Verifica la adecuación y efectividad de los controles y asegura la capacidad de proveer

completitud de resultados de procesamiento de datos.

Pag. 21 de 31
Este tipo de testeos será llevado a cabo como parte del Testo de sistema una vez que las
funcionalidades primarias de la aplicación se encuentran estables.

Objetivos

• Los datos de seguimiento son exactos y completos.

• Las transacciones son autorizadas

• La información de seguimiento de datos es producida y mantenida cada vez que es

necesario.

6.1.2 Testeo de Conversión

El testeo de Conversión verifica la compatibilidad de los programas convertidos, datos y

procedimientos con aquellos sistemas existentes que están siendo convertidos o reemplazados.
Muchos de los programas que son desarrollados para propósitos de conversión no son
totalmente nuevos. Ellos son generalmente mejoras o reemplazos para sistemas viejos,
deficientes o ejecutados en forma manual. La conversión puede abarcar archivos, bases de
datos, pantallas, formatos de reportes, etc.
El testeo de conversión pueden comenzar con el testeo Unitario.

Objetivos
• Los programas nuevos son compatibles con los programas viejos.
• Los procedimientos de conversión para documentación, operación, interfaces de usuario,
etc...
• Los archivos y formatos de datos convertidos son compatibles con el nuevo sistema
• Los nuevos programas son compatibles con las nuevas bases de datos
• La nueva funcionalidad cumple con los requerimientos
• Las funciones que no han sido cambiadas continúan ejecutándose como antes
• Las funciones estructurales se ejecutan como estaba especificado

6.1.3 Testeo de Procedimientos y documentación de usuario

La documentación de Usuario y los procedimientos de testeo aseguran que la interfaz entre el

sistema y las personas funciona y es usable. El testeo de documentación es generalmente hecho
como parte de un procedimiento de testeo que verifica que las guías de instrucción son de ayuda
y correctas. Este tipo de testeo es normalmente llevado a cabo en la ultima etapa del Testeo de
Sistema. Las personas que utilizaran la documentación y procedimientos son las que deben
conducir y ejecutar estos testeos.

Pag. 22 de 31
Objetivos
• Los Procedimientos de Usuario/Operacionales son documentados, completados y
corregidos y son fáciles de usar.
• Las responsabilidades de las personas están apropiadamente asignadas, entendidas y
coordinadas.

6.1.4 Testeo de Manejo de Errores

El manejo de errores es la funcionalidad del sistema para detectar y responder a condiciones de

excepción (tales como una entrada errónea). La completitud de la capacidad del manejo de
errores de una aplicación es generalmente la clave para la usabilidad del sistema. Asegura que
las transacciones incorrectas serán apropiadamente procesadas y que el sistema terminara en
una forma controlable y predecible en caso de una falla trágica.

Nota: Los testeos de manejo de errores deben ser incluidos en todos los niveles de testeo.
Objetivos
• Todos los errores razonables esperados pueden ser detectados por el sistema
• El sistema puede manejar adecuadamente las condiciones de error y asegurar la
continuidad de procesamiento.

6.1.5 Testeo de Funciones

Verifica en cada etapa del desarrollo que cada función de negocio opera cono esta declarado en
los requerimientos y como esta especificado en los documentos del diseño interno y externo. El
testeo Funcional es usualmente completado en el Testeo de Sistema.
Objetivos
• El sistema alcanza los requerimientos establecidos.
• El sistema ejecuta sus funciones consistentemente y acertadamente
• La aplicación procesa la información de acuerdo con los estándares de la organización,
políticas y procedimientos.

6.1.6 Testeo de Instalación

Cualquier aplicación que sea instalada y ejecutada en un ambiente remoto requiere testeo de
instalación. Es necesario si la instalación es compleja, critica, debe ser completada en una
ventana de tiempo pequeña, o de gran volumen. Deben ser ejecutados por aquellos que
ejecutaran la instalación.
El Testeo de Instalación es hecho después de terminar con el Testeo de sistema, o en paralelo
con el testeo de aceptación.

Pag. 23 de 31
Objetivos
• Todos los componentes requeridos están en el paquete de instalación
• El procedimiento de instalación es amigable y fácil de usar
• La documentación de instalación esta correcta y completa

6.1.7 Testeo de interfaces

Las aplicaciones de un sistema a menudo están interconectadas por medio de interfaces con
otras aplicaciones. Frecuentemente existen múltiples aplicaciones envueltas en una
implementación de un proyecto simple. El testeo de interfaces o inter sistemas es aun mas
complejo si la aplicación opera en diferentes plataformas en diferentes sitios o utiliza diferentes
lenguajes.
El testeo de interfaces es típicamente llevado a cabo durante el Testeo de sistemas donde todos
los componentes están disponibles y trabajando.

Objetivos
• Los parámetros apropiados y datos son correctamente pasados entre aplicaciones
• Las aplicaciones acuerdan el formato y secuencia de datos que son pasados.
• El tiempo apropiado y la coordinación de funciones existe entre las aplicaciones y los
cronogramas del proyecto deben reflejarlo.
• La documentación de interfaces para los diversos sistemas esta completa y correcta.
• Las implicaciones son claramente definidas si las interfaces de aplicaciones están
retrasadas no disponibles o han sido canceladas.

6.1.8 Testeo en Paralelo

El testeo en paralelo compara los resultados de procesar los mismos datos en sistemas viejos y
nuevos.
El testeo en paralelo es útil cuando una nueva aplicación reemplaza un sistema existente, cuando
la misma entrada es utilizada en ambos, y la salida es similar. Es también útil cuando se esta
cambiando de un sistema manual a un sistema automático.
El testeo en paralelo es ejecutado usando los mismos datos entre los sistemas viejos y nuevos,
las salidas son comparadas y cuando las diferencias son explicadas y aceptadas el sistema viejo
es descontinuado.

Objetivos
• El sistema nuevo da la consistencia de los resultados al igual que el viejo sistema (en las
situaciones en las que el viejo sistema operaba en forma correcta).
• Se da la ocurrencia de las diferencias esperadas (en esas circunstancias donde el
sistema viejo era insatisfactorio).

Pag. 24 de 31
6.1.9 Testeo de regresión

El testeo de regresión verifica que los cambios no solicitados sean introducidos a alguna parte
del sistema como resultado de hacer cambios en otra parte del sistema.
El testeo de regresión será utilizado por el desarrollador durante el testeo Unitario, si es utilizado
en conjunto con la disciplina de gestión de cambios, ayudara a prevenir que los cambios de
código se pierdan o sean sobrescritos por cambios subsiguientes. Un ultimo testeo de regresión
deberá ser ejecutado al final del testeo de Sistemas, una vez que la funcionalidad esta estable y
que no se esperan cambios posteriores.

Objetivo
• El sistema continua funcionando en forma correcta luego que los cambios son hechos.
• Los cambios posteriores no afectan funcionalidades previas del sistema.

6.1.10 Testeo de Flujo de Transacciones

El testeo del flujo de transacciones puede ser definido como el testeo del flujo de una transacción
desde el momento que ingresa al sistema hasta que esta completamente procesada generando
la salida correspondiente. No debe limitarse a testear una sola aplicación, especialmente si el
proceso de punta a punta esta formado por mas de una aplicación. Si cualquier componente en
un flujo de procesos cambia, es necesario asegurar que el resto de los procesos también
funcionan en forma adecuada completando de esta forma el flujo de procesos.
El testeo de Flujo de transacciones debe comenzar una vez que el testeo de sistema ha avanzado
hasta el punto que la aplicación se encuentra estable y es capaz de procesar transacciones
desde el comienzo hasta el final.

Objetivos
• La transacción esta correctamente procesada desde el tiempo que ingresa al sistema
hasta el momento que se espera su salida.
• Todas las salidas de los sistemas o subsistemas, las cuales son entradas de otros
sistemas o subsistemas son procesadas correctamente.
• Las interfaces pueden manejar situaciones inesperadas sin causar ruptura de servicios.

6.1.11 Testeo de Usabilidad

El propósito del testeo de usabilidad es asegurar que el producto final es usable en el ambiente
practico del día a día. Mientras que el testeo funcional busca la exactitud del producto, este tipo
de testeos busca la simplicidad y la amigabilidad del producto.

Pag. 25 de 31
El testeo de usabilidad será normalmente ejecutado como parte del testeo funcional durante el
testeo de Sistema y el Testeo de Aceptación.

Objetivos
• El sistema es fácil de operar desde el punto de vista de un usuario.
• Las pantallas y salidas están claras, concisas y fáciles de usar; la ayuda es entendible,
y describe acertadamente el proceso, expresandolo en un lenguaje simple.
• Los procesos de entrada y salida son intuitivos.

6.2 Testeo Estructural

El propósito del testeo estructural es asegurar que las funcionalidades técnicas del sistema
funcionan en forma correcta. Es diseñado para verificar que el sistema esta firme
estructuralmente y puede ejecutar las tareas propuestas.
Su objetivo es asegurar que la tecnología ha sido usada apropiadamente y que cuando las partes
que componen el sistema son integradas, se ejecutan como una unidad consistente. Los testeos
no pretenden verificar la correcta funcionalidad del sistema, mas bien que el sistema esta
técnicamente sólido.

Las categorías cubiertas en las siguientes subsecciones son:

• Testeo de Recuperación y respaldo
• Testeo de contingencia
• Testeo de flujo de trabajo
• Testeo Operacional
• Testeo de Performance
• Testeo de Seguridad
• Testeo de Stress/Volumen

6.2.1 Testeo de Recuperación y respaldo

La recuperación es la habilidad de las aplicaciones de ser reiniciadas después de una falla. El

proceso usualmente implica respaldar hasta un punto en el ciclo de procesamiento donde la
integridad del sistema esta asegurada y por lo tanto se pueden reprocesar las transacciones mas
allá del punto de falla. Los factores que impactan el proceso de recuperación son: la naturaleza
de la aplicación, el volumen de transacciones, el diseño interno de la aplicación soporta un
proceso de reinicio, las habilidades de la gente involucrada en el proceso de recuperacion, la
documentación y las herramientas provistas.

El testeo de recuperación y de respaldo será ejecutado como parte del Testeo del sistema y
verificado durante el Testeo de Operabilidad donde quiera que la continuidad del procesamiento

Pag. 26 de 31
sea un requerimiento critico para la aplicación. El riesgo de falla y la perdida potencial debido a
la incapacidad de recuperar una aplicación serán los que guiaran la magnitud del testeo
requerido.

Objetivos

• El sistema puede continuar operando después de una falla

• Todos los datos necesarios para restaurar el sistema son salvados.

• Los datos respaldados son accesibles y pueden ser restaurados

• Las personas responsables para conducir la recuperación están adecuadamente

entrenados.

6.2.2 Testeo de contingencia

Algunas aplicaciones son tan cruciales que se deben tomar precauciones especiales para
minimizar los efectos de las situaciones problemáticas y acelerar el proceso de recuperación.
Esto es llamado Contingencia. Usualmente cada aplicación es calificada por sus usuarios en
términos de importancia para la compañía, los planes de contingencia son delineados de acuerdo
a esta importancia. En algunos casos cuando la aplicación no es de mayor importancia, no
existen planes de contingencia; en otros casos, se deben tomar medidas más extremas.

Los testeos de contingencia deben verificar que una aplicación y sus bases de datos, redes y
procesos operativos puedan ser migrados sin inconvenientes a otro sitio.

El testeo de contingencia es un ejercicio especializado normalmente conducido por el grupo de

operaciones. No existe una fase recomendada sobre la cual ejecutar este tipo de testeo, en caso
de aplicaciones altamente importantes se ejecutara después del testeo de Sistemas y
probablemente concurrente con el Testeo de Operabilidad.

Objetivos

• El sistema puede ser restaurado de acuerdo a los requerimientos prescritos

• Todos los datos son recuperables bajo las condiciones de contingencia prescritas

• Todos los procesos, instrucciones y procedimientos funcionan correctamente en las

condiciones de contingencia.

• Cuando las condiciones normales regresan, el sistema y todos sus datos y procesos pueden
ser restaurados.

6.2.3 Testeo de flujo de trabajo

Pag. 27 de 31
Este testeo es usualmente hecho como parte del testeo operacional. El testeo de flujo de trabajo
comienza en etapas tempranas y continua a través de todos los niveles de testing. La
conformidad a los estándares es chequeada en los testeos de aceptación y de Operabilidad

Objetivos

• Cada programa puede manejar los parámetros esperados de entrada

• Los programas están generando las salidas requeridas

• Los trabajos son secuenciados y versionados apropiadamente

• Los formatos de archivos son consistentes con los programas para asegurar que los
programas puedan dialogar unos con otros.

• El sistema es compatible con el ambiente operacional.

6.2.4 Testeo Operacional

Todos los productos que se encuentran en producción deben funcionar de acuerdo a los
requerimientos del usuario. Sin embargo, la performance de un producto no esta limitada
exclusivamente a sus características funcionales. El testeo de Operabilidad es el punto final
donde el comportamiento de un sistema operacional es testeado, es responsabilidad de los
desarrolladores considerar y testear los factores operacionales durante la fase de construcción.

Objetivos

• Todos los módulos y programas están disponibles y operacionales

• Todos los procedimientos funcionan correctamente,

• La documentación operacional representa correctamente la aplicación, esta clara, es concisa

y completa.

• Todas las funciones de procesamiento por lote pueden ser completadas en una ventana de
tiempo aceptables.

6.2.5 Testeo de Performance

Es diseñado para testear si el sistema logra el nivel deseado de performance en un ambiente de

producción. Las consideraciones de Performance pueden estar relacionadas a tiempo de
respuestas, tiempos de vuelta atrás, problemas de diseño técnicos, etc.

El testeo de Performance puede ser conducido usando un sistema en producción, un ambiente

simulado o un prototipo.

La atención a los problemas de performance (ej: tiempo de respuesta o disponibilidad) comienza

durante la fase de diseño, en este momento el criterio debe ser establecido.

Pag. 28 de 31
Objetivos

• El sistema se ejecuta como es requerido (tiempo de respuesta, disponibilidad, etc)

6.2.6 Testeo de Seguridad

La seguridad en una aplicación de un sistema es requerida para asegurar la protección de la

información confidencial de un sistema y que en otros sistemas afectados sea protegida contra
la perdida, corrupción o desuso; por acciones intencionales o accidentales. El monto de testeo
necesario depende de la estimación de riesgos de las consecuencias de una brecha en la
seguridad. Los testeos se deben enfocar, y ser limitados en esas características de seguridad
desarrolladas como parte del sistema, pero deben incluir funciones de seguridad previamente
implementadas pero necesarios para testear completamente el sistema.

Los testeos de seguridad pueden comenzar en cualquier momento durante el testeo del Sistema
y ser completados en el testeo de Operabilidad.

Objetivos

• Las características de seguridad no pueden ser pasadas por alto, alteradas o desbaratadas

• Los riesgos de seguridad son identificados apropiadamente y aceptados, y los planes de

contingencia deben ser testeados.

• La seguridad provista por el sistema funciona correctamente.

6.2.7 Testeo de Stress/Volumen

Es definido como el procesamiento de un gran numero de transacciones a través del sistema en

un periodo definido de tiempo. Es hecho para medir las características de performance del
sistema bajo condiciones pico de cargas.

Los factores de Stress pueden aplicar a diferentes aspectos del sistema tales como
transacciones de entrada, líneas de reportes, tablas internas, comunicaciones, capacidad de
procesamiento computacional, rendimiento, espacio en disco, Entradas/Salidas, etc.

El testeo de stress no debe comenzar hasta que las funciones del sistema sean completamente
testeadas y estables. La necesidad del testeo de Stress debe ser identificada en la fase de diseño
y debe comenzar tan pronto como las unidades del sistema estén operacionalmente estables y
disponibles.

No es necesario tener todas las funcionalidades totalmente testeadas en el orden de comenzar

el Testeo de Stress. La razón por la cual es comenzado temprano es que cualquier defecto del
diseño puede ser rectificado antes de que el sistema finalice la etapa de construcción.

Pag. 29 de 31
Objetivos

• El sistema en producción puede procesar grandes volúmenes de transacciones en el marco

de tiempo esperado.

• La arquitectura y construcción del sistema es capaz de procesar grandes volúmenes de

datos.

• El Hardware/Software son adecuados a procesar el volumen requerido

• El sistema tiene recursos adecuados para manejar el tiempo de vuelta atrás.

• Las funciones de soporte de reporte de procesamiento (ej servicios de impresión) pueden

manejar los volúmenes de datos de salida por el sistema.

6.3 Relaciones entre tipos y niveles de testeo

El diagrama a continuación ilustra las relaciones entre los niveles de testeo y los tipos de testeo.
Los nivele de testeo están en las columnas y los tipos están en las filas de la tabla. La tabla sugiere
los niveles donde cada tipo de testeo podrá ser ejecutado. Obviamente cada proyecto tiene
diferentes características que deberán ser consideradas en el proceso de testeo.

Niveles Unitario Integración Sistema Integración Aceptación Operabilidad

de
sistemas
Tipos
Control y Auditorias
Conversión
Proc y Doc de
trabajo
Manejo de errores
función
Instalación
Interfaces
En Paralelo
regresión
Flujo de
Transacciones
Usabilidad
Recuperación y
Respaldo
Contingencia

Pag. 30 de 31
Flujo de Trabajo
Operacional
Performance
Seguridad
Stress/Volumen

-FIN DEL DOCUMENTO-

Pag. 31 de 31