El objetivo del plan de prueba es comunicar la intención de las tareas de prueba. Es crítico que este documento se cree
tan pronto como sea posible. La generación de este artefacto en una de las primeras iteraciones de la fase de
elaboración no sería demasiado pronto. Puede ser deseable desarrollar el plan de prueba iterativamente, añadiendo
secciones a medida que la información esté disponible.
Hay que tener cuidado de comunicar claramente el ámbito de la prueba, los requisitos de la prueba, las estrategias de
la prueba y los recursos necesarios. Esta información identifica el objetivo y los límites del esfuerzo de prueba, qué
se probará, cómo se probará y qué recursos son necesarios para la prueba. Indicar claramente esta información acelerará
la revisión, comentarios y aprobación del esfuerzo de prueba.
Al inicio del proyecto, se debería crear un plan de prueba que identifique las pruebas globales previstas para el
proyecto, denominado "Plan de prueba maestro". A medida que se planea cada iteración, se crea un "Plan de prueba de
iteración" más preciso (o varios planes de prueba, organizados por tipo de prueba), que contiene sólo los datos
(requisitos de prueba, estrategias de prueba, recursos, etc.) que pertenecen a la iteración. De forma alternativa, esta
información se puede incluir en el Plan
de iteración, si no complica demasiado la gestión o el uso del plan de iteración.
A continuación se muestran algunas directrices para identificar y comunicar mejor los requisitos de prueba, los riesgos
de la prueba, las prioridades y las estrategias de prueba.
Los requisitos para la prueba identifican qué se probará. Son el destino específico de una prueba. Existen unas cuantas
normas generales a aplicar cuando se deriven requisitos para la prueba:
-
El requisito para la prueba debe ser un comportamiento observable y medible. Si el requisito para la prueba no se
puede observar ni medir, no se puede valorar para determinar si se ha satisfecho el requisito.
-
No existe una relación de uno a uno entre cada caso de uso o requisito suplementario de un sistema y un requisito
de prueba. Los casos de uso a menudo tendrán más de un requisito que se debe probar, mientras que algunos
requisitos suplementarios derivarán uno o más requisitos para probar y otros no derivarán ninguno (como los
requisitos de marketing o de embalaje).
Los requisitos de prueba se pueden derivar de cualquier origen, incluyendo casos de uso, modelos de caso de uso,
especificaciones suplementarias, requisitos de diseño, clases de negocio, entrevistas con usuarios y el documento de
arquitectura de software. Todos estos deben revisarse para recopilar la información que se utiliza para identificar los
requisitos para la prueba.
Los requisitos funcionales de la prueba, como su nombre indica, se derivan de las descripciones de los comportamientos
funcionales del destino de la prueba. Como mínimo, cada caso de uso debe derivar un requisito para la prueba. Una lista
más detallada de requisitos para prueba incluiría como mínimo un requisito de prueba para cada flujo de sucesos del
caso de uso.
Los requisitos de rendimiento para la prueba se derivan de los comportamientos de rendimiento especificados del destino
de la prueba. Habitualmente, el rendimiento se indica como medida de tiempo de respuesta y/o utilización de recursos,
tal como se mide debajo de diferentes condiciones, que incluyen
-
diferentes cargas de trabajo y/o condiciones de sistema
-
diferentes casos de uso
-
diferentes configuraciones
Los requisitos de rendimiento se describen en las especificaciones suplementarias. Revise estos materiales, , dedicando
una atención especial a las sentencias que incluyen lo siguiente:
-
sentencias de tiempo, como tiempo de respuesta o perfiles de tiempo
-
sentencias que indiquen qué número de sucesos o casos de uso ocurren en un periodo de tiempo indicado
-
sentencias que comparan el comportamiento de uno elemento con otro
-
sentencias que comparan el comportamiento de la aplicación en una configuración con el de otra
-
fiabilidad operativa (tiempo medio de anomalía o MTTF) durante un periodo de tiempo
-
configuraciones o restricciones
Debe derivar como mínimo un requisito para probar para cada sentencia en la especificación que refleja información como
la que se lista arriba.
Los requisitos de fiabilidad para las pruebas se derivan de varias fuentes, habitualmente descritas en especificaciones
suplementarias, directrices de interfaz de usuario, directrices de diseño y directrices de programación.
Revise estos productos de trabajo y dedique una atención especial a las sentencias que incluyen lo siguiente:
-
sentencias de fiabilidad o resistencia a anomalías, errores de tiempo de ejecución (como fugas de memoria)
-
sentencias que indican la integridad del código y de la estructura (cumplimiento del lenguaje y la sintaxis)
-
sentencias referentes a la utilización de recursos
Debe derivar como mínimo un requisito para la prueba a partir de cada sentencia de los productos de trabajo que refleja
información como la que se lista arriba.
Unas pruebas satisfactorias requieren que el esfuerzo de prueba equilibre satisfactoriamente los factores como las
restricciones de recursos y los riesgos. Para cumplir esto, el esfuerzo de prueba debe tener prioridad para que el caso
de uso más importante, significativo o el más arriesgado o los componentes se prueben primero. Para dar prioridad al
esfuerzo de prueba, una valoración de riesgo y un perfil operativo se efectúan y se utilizan como base para establecer
la prioridad de la prueba.
En las secciones siguientes se describe cómo determinar la prioridad de las pruebas.
Identificar los requisitos para las pruebas es sólo una parte de la identificación que se probará. Dar prioridad a lo
que se probará y en qué orden también debería realizarse. Este paso se efectúa por diferentes motivos, que incluyen los
siguientes:
-
asegúrese de que los esfuerzos de prueba se centran en los requisitos más apropiados para la prueba
-
garantizar que los requisitos más críticos, significativos o arriesgados para la prueba se solucionen cuanto antes
-
asegúrese de que se prueban las dependencias como secuencia o datos
Existen tres pasos para valorar el riesgo y establecer las prioridades de la prueba:
A continuación se proporcionan las directrices para cada uno de estos tres pasos:
El establecimiento de la prioridad de la prueba empieza con la valoración del riesgo. Los casos de uso o componentes
que implican el mayor riesgo debido a errores o que tienen una alta probabilidad de error deben estar entre los
primeros casos de uso probados.
Empiece por la identificación y la descripción de los indicadores de magnitud de riesgo que se utilizarán, como por
ejemplo:
-
H - alto riesgo, no tolerable. Exposición externa grave. La empresa sufrirá grandes pérdidas financieras, de
fiabilidad o una pérdida de reputación irrecuperable.
-
M - riesgo medio, tolerable pero no deseable. Exposición externa mínima, la empresa puede sufrir económicamente,
pero existe una fiabilidad limitada o pérdida de reputación.
-
L - bajo riesgo, tolerable. Exposición reducida o no externa, la empresa tiene pocas pérdidas o no tiene pérdidas
económicas o de fiabilidad. La reputación de la empresa no se ve afectada.
Después de identificar los indicadores de magnitud de riesgo, lista cada caso de uso o componente en el destino de la
prueba. Para cada caso de uso o componente de la lista, identifique un indicador de magnitud de riesgo y justifique (en
una sentencia breve) el valor que ha seleccionado.
Existen tres perspectivas que se pueden utilizar para valorar el riesgo:
-
Efecto - el impacto o consecuencia de casos de uso especificados (requisitos, etc.) errores
-
Causa - empieza con un resultado indeseable provocado por el error de un caso de uso y examina
las causas posibles
-
Probabilidad - la probabilidad de error de un caso de uso.
Seleccione una perspectiva, identifique un indicador de magnitud de riesgo y justifique la selección. No es necesario
identificar un indicador para cada perspectiva de riesgo. Sin embargo, se sugiere que, si se ha identificado un
indicador bajo, intente evaluar el elemento desde una perspectiva de riesgo diferente para garantizar que el elemento
es realmente de bajo riesgo.
A continuación se muestran más detalles de la valoración de riesgo desde estas tres perspectivas.
Para valorar el riesgo por Efecto, identifique una condición, suceso o acción e intente determinar su impacto. Haga una
pregunta:
"¿Qué pasaría si ___________?"
Por ejemplo:
-
"¿Qué ocurriría si mientras instalo el nuevo software, el sistema se queda sin espacio en disco?"
-
"¿Qué ocurriría si la conexión a Internet se pierde durante una transacción de consulta?"
-
"¿Qué ocurriría si la conexión a Internet se pierde durante una transacción de compra?"
-
"¿Qué ocurriría si el usuario entra un valor inesperado?"
A continuación se muestra una matriz de justificación de estos elementos:
Descripción
|
Factor de mitigación de riesgo
|
Justificación
|
Espacio en disco insuficiente durante la instalación
|
H
|
Instalar el software proporciona al usuario la primera impresión del producto. Cualquier resultado no
deseado, como los que se listan a continuación, degradaría el sistema del usuario, el software
instalado, y comunicaría una impresión negativa al usuario:
-
el software está parcialmente instalado (algunos archivos, algunas entradas de registro, que
dejan el software instalado en una condición inestable
-
la instalación se detiene dejando en sistema en estado inestable
|
se ha perdido la conexión a Internet durante la consulta
|
L
|
No hay daños resultantes de la pérdida de la conexión en los datos o la base de datos. Se reconoce que
una conexión perdida puede comunicar una impresión negativa al usuario.
|
se ha perdido la conexión a Internet durante la compra
|
H
|
Cualquier conexión o transacción perdida que provoquen los resultados que se listan a continuación son
inaceptables, ya que aumentan los costes y reducen los beneficios:
-
base de datos dañada
-
orden parcial
-
datos o orden perdido
-
múltiples órdenes (replicados)
|
Valor entrado inesperado
|
H
|
Cualquier transacción que provoque los resultados que se listan a continuación es inaceptable:
-
base de datos dañada
-
datos incorrectos
|
Valorar el riesgo por Causa es lo contrario de valorarlo por Efecto. Empiece indicando un suceso o condición no
deseable, e identifique el conjunto de sucesos que habrían permitido que la condición existiera. Pregunte algo parecido
a:
"¿Podría suceder que ___________?
Por ejemplo:
-
"¿Cómo podrían estar en el sistema sólo algunos archivos y no todas las entradas de registro que se hacen?"
-
"¿Cómo podría no reflejarse adecuadamente una transacción en la base de datos central?
-
"¿Cómo podría la sentencia de ciclo de facturación reflejar sólo algunos registros de la base de datos que cumplen
los criterios deseados?"
A continuación se muestra una matriz de justificación de estos elementos:
Descripción
|
Factor de mitigación de riesgo
|
Justificación
|
Archivos que faltan / de aplicación y entradas de registro
|
H
|
Hace que la aplicación (y, potencialmente, el sistema) sea inutilizable. La instalación es la primera
vista de la aplicación por parte de los usuarios. Si la instalación falla, por cualquier motivo, el
usuario ve el software desfavorablemente.
Las posibles causas de esta condición incluyen:
-
el proceso de instalación no ha instalado todos los archivos ni ha actualizado el registro
correctamente
-
el proceso de instalación se ha detenido por la intervención de un usuario (cancelar o salir)
-
el proceso de instalación se ha detenido por la intervención del software / hardware (espacio
en disco insuficiente, configuración no soportada, etc.)
-
el proceso de instalación se ha detenido por condiciones desconocidas
-
los archivos /entradas de registro del usuario suprimidos
De estas causas, sólo la última no se puede detectar y gestionar en el proceso de instalación.
|
orden parcial
|
H
|
Los pedidos parciales no se pueden completar, lo que resulta en la pérdida de ingresos y de clientes.
Las posibles causas incluyen:
-
Conexión a Internet perdida debido a la acción del usuario (desconectar módem, apagar PC, etc.)
-
conexión a Internet perdida debido a IP
-
conexión a Internet perdida debido a la acción de un empleado (desconectar módem, apagar la
alimentación de los servidores, etc.)
|
Datos / base de datos dañados
|
H
|
Los datos dañados no se tolerarán por ningún motivo.
Las posibles causas incluyen:
-
La transacción que escribe en la base de datos no se ha completado / cometido por la
intervención del usuario
-
La transacción que escribe en la base de datos no se ha completado / cometido por la pérdida de
la conexión a Internet
-
El usuario ha entrado datos no válidos en la transacción
-
Métodos / programas de utilidad de acceso a la base de datos
-
La base de datos no se ha rellenado correctamente (cuando se creaban las instancias iniciales)
|
Pedidos replicados
|
H
|
Los pedidos replicados aumentan los gastos generales consumidos por la empresa y reducen los beneficios
a través de los costes asociados con el envío, gestión y reabastecimiento.
Las posibles causas incluyen:
-
La transacción que escribe el pedido en la base de datos replicada debido a la intervención del
usuario, el usuario entra dos veces el pedido - sin confirmación de entrada
-
La transacción que escribe el pedido en la base de datos replicada sin la intervención del
usuario, (proceso de recuperación de la conexión a Internet perdida, restauración de la base de
datos)
|
Datos inapropiados para un pedido
|
H
|
Todos los pedidos que no se pueden completar o que provocan gastos adicionales no son aceptables.
Las posibles causas incluyen:
-
La transacción del pedido no se ha completado / cometido por la intervención del usuario
-
La transacción del pedido no se ha completado / cometido por la pérdida de la conexión a
Internet
-
El usuario ha entrado datos no válidos
|
Número incorrecto de registros reflejado en la sentencia
|
H
|
Las decisiones empresariales y las cuentas recibibles dependen de la precisión de estos informes.
Las posibles causas incluyen:
-
Criterios de búsqueda /selección incorrectos
-
Sentencias SQL incorrectas
-
Datos dañados en la base de datos
-
Datos incorrectos en la base de datos
|
Valorar el riesgo por Probabilidad es determinar la probabilidad de que un caso de uso (o un componente que implemente
un caso de uso) falle. La probabilidad suele basarse en los factores externos como:
-
Índices de error
-
Índice de cambio
-
Complejidad
-
Origen / Originador
Debe tenerse en cuenta que, al utilizar esta perspectiva de riesgo, los indicadores de magnitud de riesgo están
relacionados con la probabilidad de un error, no con el efecto o el impacto que tiene en la organización tal como se
utilizaba para valorar el riesgo por Efecto y Causa.
Las correlaciones entre estos factores y la probabilidad de un error existen, tal como se identifican a continuación:
Factor externo
|
Probabilidad
|
Tasa de descubrimiento de errores
|
La probabilidad de anomalía aumenta a medida que aumentan los índices de descubrimiento de anomalías.
Los defectos tienden a congregarse y, por lo tanto, el índice de descubrimiento de los defectos
(densidad) aumenta en un caso de uso o componente, la probabilidad de encontrar otro defecto también
aumenta. Los índices de descubrimiento y de densidad de los releases anteriores también deben
considerarse al valorar el riesgo utilizando este factor, ya que los índices de descubrimiento elevados
anteriores y las densidades indican una alta probabilidad de anomalías adicionales.
|
Índice de cambio
|
La probabilidad de anomalía aumenta a medida que aumenta el índice de cambio en el caso de uso o en el
componente. Por lo tanto, a medida que aumenta el número de cambios, también aumenta la probabilidad de
que se haya introducido un defecto. Cada vez que se realiza un cambio en el código, existe el riego de
"inyectar" otro defecto.
|
Complejidad
|
La probabilidad de anomalía aumenta a medida que aumenta la complejidad del caso de uso o del
componente.
|
Origen / Originador
|
El conocimiento y experiencia de dónde y quién ha originado el código puede aumentar o reducir la
probabilidad de una anomalía.
La utilización de componentes de terceros habitualmente reduce la probabilidad de anomalía. Sin
embargo, esto sólo es cierto si el componente de terceros se ha certificado (cumple sus requisitos, a
través de pruebas formales o experiencia).
La probabilidad de error suele disminuir con el aumento del conocimiento y las habilidades del
implementador. No obstante, factores tales como la utilización de nuevas herramientas, tecnologías o
actuar en múltiples roles puede aumentar la probabilidad de una anomalía incluso con los mejores
miembros del equipo.
|
Por ejemplo:
-
Instalación del nuevo software
-
"Históricamente hemos encontrado muchos defectos en los componentes que se utilizan para implementar los casos de
uso 1, 10 y 12, y nuestros clientes nos han solicitado muchos cambios en los casos de uso 14 y 19".
A continuación se muestra una matriz de justificación de estos elementos:
Descripción
|
Factor de mitigación de riesgo
|
Justificación
|
Instalación de nuevo software
|
H
|
Estamos escribiendo nuestro propio programa de utilidad de instalación.
Representa el uso de la aplicación inutilizable. La instalación es la primera vista de la
aplicación por parte de los usuarios. Si la instalación falla, por cualquier motivo, el usuario ve
el software desfavorablemente.
|
Instalación de nuevo software
|
L
|
Estamos utilizando un programa de utilidad de instalación comercialmente satisfactorio.
Mientras que la instalación anómala hace que la aplicación sea inutilizable, el programa de
utilidad de instalación seleccionado es de un proveedor que ha alcanzado el número uno del mercado
con su producto y se comercializa desde hace más de cuatro años. Nuestra evaluación indica que el
producto cumple nuestras necesidades y que los clientes están satisfechos con su producto, el
proveedor y el nivel de servicio y de soporte.
|
Índices de descubrimiento de anomalías elevado / densidades de defectos en los casos de uso 1, 10, 12.
|
H
|
Debido a los elevados índices de descubrimiento de anomalías anteriores y de densidad de defectos, los
casos de uso 1, 10 y 12 se consideran de alto riesgo.
|
Solicitudes de cambio en los casos de uso 14 y 19.
|
H
|
Un elevado número de cambios a estos casos de uso aumenta la probabilidad de inyectar defectos en el
código.
|
El paso siguiente en la valoración del riesgo y el establecimiento de la prioridad de prueba es determinar el perfil
operativo del destino de la prueba.
Empiece por la identificación y la descripción de los indicadores de magnitud de perfil operativo que se utilizarán,
como por ejemplo:
-
H - se utiliza con mucha frecuencia, muchas veces por periodo o por muchos actores o casos de uso.
-
M - se utiliza con bastante frecuencia, varias veces por periodo o por varios actores o casos de uso.
-
L - se utiliza con poca frecuencia o por pocos actores o casos de uso.
El indicador del perfil operativo que seleccione debe basarse en la frecuencia de ejecución de un caso de uso o
componente, incluyendo:
-
el número de veces que UN actor (o caso de uso) ejecuta el caso de uso (o componente) en un periodo determinado de
tiempo
-
el número de ACTORES (o casos de uso) que ejecutan el caso de uso (o componente)
Habitualmente, cuanto más se utilice un caso de uso o componente, más elevado será el indicador de perfil operativo.
Después de identificar los indicadores de magnitud de perfil operativo, liste cada caso de uso o componente en el
destino de la prueba. Determine un indicador de perfil operativo para cada elemento de la lista e indique una
justificación para el valor del indicador. La información del documento de análisis de carga de trabajo (Consulte el
apartado Producto de trabajo: Documento de análisis de carga de trabajo) se
puede utilizar para esta valoración.
Ejemplos:
-
Instalación de nuevo software
-
Solicitud de elementos desde el catálogo en línea
-
Clientes que consultan sobre su pedido en línea después de efectuar el pedido
-
Diálogo de selección de elementos
Descripción
|
Factor del perfil operativo
|
Justificación
|
Instalación de nuevo software
|
H
|
Efectuado una vez (habitualmente), pero por muchos usuarios. Sin instalación, sin embargo, la
aplicación no es utilizable.
|
Solicitud de elementos desde el catálogo
|
H
|
Este es el caso de uso más habitual ejecutado por los usuarios.
|
Clientes que consultan sobre pedidos
|
L
|
Pocos clientes consultan sobre sus pedidos después de haberlos efectuado
|
Diálogo de selección de elementos
|
H
|
Este diálogo los utilizan los clientes para enviar pedidos y los asistentes de inventario para
reabastecer las existencias.
|
El último paso en la valoración del riesgo y el establecimiento de la prioridad de prueba es establecer la prioridad de
prueba.
Empiece por la identificación y la descripción de los indicadores de magnitud de prioridad de prueba que se utilizarán,
como por ejemplo:
-
H - se debe probar
-
M - se debe probar, se probará sólo después de que se prueben todos los elementos H
-
L - se puede probar, pero no hasta que todos los elementos H y M se hayan probado
Después de identificar los indicadores de magnitud de prioridad de prueba que se utilizarán, liste cada caso de uso o
componente en el destino de la prueba. Determine un indicador de prioridad de prueba para cada elemento de la lista e
indique su justificación. A continuación se muestran algunas directrices para determinar un indicador de prioridad de
prueba.
Tenga en cuenta lo siguiente cuando determine los indicadores de prioridad de prueba para cada elemento:
-
el valor indicador de magnitud de riesgo que ha identificado anteriormente
-
el valor de magnitud de perfil operativo que ha identificado anteriormente
-
las descripciones de actor (¿los actores tienen experiencia?, ¿se toleran soluciones provisionales?, etc.)
-
obligaciones contractuales (¿será aceptable el destino de la prueba si el caso de uso o componente no se entrega?)
Las estrategias para establecer una prioridad de prueba incluyen:
-
Utilice el valor de factor valorado más alto (riesgo, perfil operativo, etc.) para cada elemento como prioridad
global.
-
Identifique un factor valorado (riesgo, perfil operativo, otros) como el más significativo y utilice el valor de
este factor como la prioridad.
-
Utilice una combinación de factores valorados para identificar la prioridad.
-
Utilice un esquema de ponderación donde los factores individuales se ponderan, y sus valores y la prioridad
calculada basadas en la ponderación.
Ejemplos:
-
Instalación de nuevo software
-
Solicitud de elementos desde el catálogo en línea
-
Clientes que consultan sobre su pedido en línea después de efectuar el pedido
-
Diálogo de selección de elementos
La prioridad cuando el valor valorado más elevado se utiliza para determinar la prioridad:
Elemento
|
Riesgo
|
Perfil operativo
|
Actor
|
Contrato
|
Prioridad
|
Instalación de nuevo software
|
H
|
H
|
L
|
H
|
H
|
Solicitud de elementos desde el catálogo
|
H
|
H
|
H
|
H
|
H
|
Consultas de los clientes
|
L
|
L
|
L
|
L
|
L
|
Diálogo de selección de elementos
|
L
|
H
|
L
|
L
|
H
|
La prioridad cuando el valor valorado más elevado para un factor (Riesgo) se utiliza para determinar la prioridad:
Elemento
|
Riesgo
|
Perfil operativo
|
Actor
|
Contrato
|
Prioridad
|
Instalación de nuevo software
|
H
|
H
|
L
|
H
|
H
|
Solicitud de elementos desde el catálogo
|
H
|
H
|
H
|
H
|
H
|
Consultas de los clientes
|
L
|
L
|
L
|
L
|
L
|
Diálogo de selección de elementos
|
L
|
H
|
L
|
L
|
L
|
Prioridad cuando un valor de ponderación se utiliza para calcular la prioridad:
(Nota: en la matriz siguiente, H = 5, M = 3 y L = 1. Un valor ponderado total superior a 30 es de elemento de prueba de
alta prioridad, valores entre 20 y 30 inclusive, son de prioridad media y valores inferiores a 20 son de baja
prioridad).
Elemento
|
Riesgo (x 3)
|
Perfil operativo (x 2)
|
Actor (x 1)
|
Contrato (x 3)
|
Valor ponderado
|
Prioridad
|
Instalación de nuevo software
|
5 (15)
|
5 (10)
|
1 (1)
|
5 (15)
|
41
|
H (2)
|
Solicitud de elementos desde el catálogo
|
5 (15)
|
5 (10)
|
5 (5)
|
5 (15)
|
45
|
H (1)
|
Consultas de los clientes
|
1 (3)
|
1 (2)
|
1 (1)
|
1 (3)
|
9
|
L (4)
|
Diálogo de selección de elementos
|
1 (3)
|
5 (10)
|
1 (1)
|
1 (3)
|
17
|
L (3)
|
La estrategia de prueba describe el enfoque general y los objetivos de un esfuerzo de prueba específico.
Una buena estrategia de prueba debe contener lo siguiente:
Indicar claramente el tipo de prueba que se está implementando y el objetivo de la prueba. Indicando explícitamente
esta información se reduce la confusión y se minimizan los malentendidos (especialmente porque algunas pruebas pueden
resultar muy similares). El objetivo debe indicar claramente porqué la prueba se está ejecutando.
Ejemplos:
"Prueba funcional. La prueba funcional se centra en la ejecución de los casos de uso siguientes implementados en el
destino de la prueba, de la interfaz de usuario."
"Prueba de rendimiento. La prueba de rendimiento para el sistema se centrará en la medida del tiempo de respuesta
para los casos de uso 2, 4 y 8 - 10. Para estas pruebas, una carga de trabajo de un actor, ejecutando estos casos
de uso sin utilizar ninguna otra carga de trabajo en el sistema de prueba."
"Prueba de configuración. Las pruebas de configuración se implementarán para identificar y evaluar el
comportamiento del destino de la prueba en tres configuraciones diferentes, comparando las características de
rendimiento para la configuración del estándar de comparación.
Indique claramente el estadio en que se ejecutará la prueba. A continuación se identifican los estadios en que se
ejecutan las pruebas habituales:
|
Estadio de prueba
|
Tipo de pruebas
|
Unidad
|
Integración
|
Sistema
|
Aceptación
|
Pruebas funcionales
(Configuración, Función, Instalación, Seguridad, Volumen)
|
X
|
X
|
X
|
X
|
Pruebas de rendimiento
(perfiles de rendimiento de componentes individuales)
|
X
|
X
|
(X)
opcional o cuando las pruebas de rendimiento del sistema descubren defectos
|
|
Pruebas de rendimiento
(Carga, Tensión, Contienda)
|
|
|
X
|
X
|
Fiabilidad
(Integridad, Estructura)
|
X
|
X
|
(X)
opcional o cuando otras pruebas descubren defectos
|
|
La técnica debe describir cómo se implementará y se ejecutará la prueba. Incluya qué se probará, las acciones
principales a desarrollar durante la ejecución de la prueba, y los métodos utilizados para evaluar los resultados.
Ejemplo:
Prueba funcional:
-
Para cada flujo de sucesos del caso de uso, se identificará un conjunto representativo de transacciones, cada
una representando las acciones desempeñadas por el actor cuando se ejecuta el caso de uso.
-
Un mínimo de dos casos de prueba se desarrollarán para cada transacción; un caso de prueba para reflejar la
condición positiva y una para reflejar la negativa (inaceptable).
-
En la primera iteración, los casos de uso 1 - 4, y 12 se probarán, del modo siguiente:
-
Caso de uso 1:
-
El caso de uso 1 empieza con el actor ya registrado en la aplicación y en la ventana principal,
y termina cuando el usuario ha especificado GUARDAR.
-
Cada caso de prueba se implementará y ejecutará mediante Rational Robot.
-
La verificación y valoración de la ejecución de cada caso de prueba se realizará utilizando los
métodos siguientes:
-
Ejecución del script de prueba (¿cada script de prueba se ha ejecutado
satisfactoriamente y tal como se deseaba?)
-
La existencia de ventana, o métodos de verificación de datos de objeto (implementados
en los scripts de prueba) se utilizarán para verificar qué ventanas clave se muestran y
qué datos especificados se capturan / muestran en el destino de la prueba durante la
ejecución de la prueba.
-
La base de datos destino de la prueba (con Microsoft Access) se examinará antes de la
prueba y después de esta para verificar que los cambios que se han ejecutado durante la
prueba se reflejan con precisión en los datos.
Prueba de rendimiento:
-
Para cada caso de uso, un conjunto representativo de transacciones, tal como se identifican en el documento de
análisis de carga de trabajo se implementará y se ejecutará utilizando Rational Suite PerformanceStudio (vu
scripts) y Rational Robot (scripts GUI).
-
Como mínimo tres cargas de trabajo se reflejarán en los scripts de prueba y las planificaciones de ejecución de
prueba incluyendo lo siguiente:
-
Carga de trabajo destacada: 750 usuarios (15 % gestores, 50 % ventas, 35 % marketing)
-
Carga de trabajo punta: 350 usuarios (10 % gestores, 60 % ventas, 30 % marketing)
-
Carga de trabajo nominal: 150 usuarios (2 % gestores, 75% ventas, 23 % marketing)
-
Los scripts de prueba que se utilizan para ejecutar cada transacción incluirán los temporizadores apropiados
para capturar los tiempos de respuesta, como tiempo de transacción total (tal como se define en el documento de
análisis de carga de trabajo) y la tarea de transacción clave o los tiempos de proceso.
-
Los scripts de prueba ejecutarán las cargas de trabajo durante una hora (a menos que se indique lo contrario en
el documento de análisis de carga de trabajo).
-
La verificación y valoración de la ejecución de cada ejecución de prueba (de una carga de trabajo) incluirá:
-
La ejecución de prueba se supervisará mediante histogramas de estado (para verificar que la prueba y
las cargas de trabajo se están ejecutando según se esperaba y deseaba)
-
Ejecución del script de prueba (¿cada script de prueba se ha ejecutado satisfactoriamente y tal como se
deseaba?)
-
Captura y evaluación de los tiempos de respuesta identificados utilizando los informes siguientes:
-
Percentil de rendimiento
-
Tiempo de respuesta
Los criterios de terminación se indican con dos objetivos:
-
identificar la calidad aceptable del producto
-
identificar cuando se ha implementado satisfactoriamente el esfuerzo de prueba
Una sentencia clara de los criterios de terminación debe incluir los elementos siguientes:
-
función, comportamiento o condición que se mide
-
método de medición
-
criterios o grado de conformidad con las mediciones
Ejemplo 1
-
Todos los casos de prueba se han ejecutado
-
Todos los defectos identificados se han dirigido a una resolución acordada
-
Todos los casos de prueba planificados se han vuelto a ejecutar y todos los defectos conocidos se han solucionado
según lo acordado, y no se han descubierto nuevos defectos
Ejemplo 2
-
Todos los casos de prueba de alta prioridad se han ejecutado.
-
Todos los defectos identificados se han dirigido a una resolución acordada.
-
Todos los defectos de Gravedad 1 ó 2 se han resuelto (estado = corregido o pospuesto).
-
Todos los casos de prueba de alta prioridad se han vuelto a ejecutar y todos los defectos conocidos se han
solucionado según lo acordado, y no se han descubierto nuevos defectos.
Ejemplo 3
-
Todos los casos de prueba planificados se han ejecutado.
-
Todos los defectos identificados se han dirigido a una resolución acordada.
-
Todos los defectos de Gravedad 1 ó 2 se han resuelto (estado = verificado o pospuesto).
-
Todos los casos de prueba de alta prioridad se han vuelto a ejecutar y todos los defectos conocidos se han
solucionado según lo acordado, y no se han descubierto nuevos defectos.
En esta sección se deben identificar las influencias o dependencias que pueden impactar o influenciar el esfuerzo de
prueba descrito en la estrategia de prueba. Las influencias pueden incluir:
-
recursos humanos (como disponibilidad o necesidad de que los recursos que no son de prueba den soporte / participen
en la prueba)
-
restricciones, (como limitaciones de equipamiento o disponibilidad, o la necesidad / falta de equipamiento
especial)
-
requisitos especiales, como la planificación de prueba o el acceso a los sistemas
Ejemplos:
-
Las bases de datos de prueba requerirán el soporte de un diseñador / administrador de bases de datos para crear,
actualizar y renovar los datos de prueba.
-
Las pruebas de rendimiento del sistema utilizará los servidores en la red existente (que da soporte al tráfico que
no es de prueba). Las pruebas deberán planificarse posteriormente para garantizar que no hay tráfico que no sea de
prueba en la red.
-
El destino de la prueba debe sincronizar el sistema heredado (o la sincronización simulada) para que se implemente
y se ejecute la prueba funcional completa
|