- Diferenciar entre una especificación de diseño de pruebas, una especificación de caso de prueba y una especificación de procedimiento de prueba (K2).
- Comparar los términos condición de prueba, caso de prueba y procedimiento de prueba (K2).
- Evaluar la calidad de los casos de prueba en términos de trazabilidad clara de los requisitos y resultados esperados (K2).
- Traducir casos de prueba en una especificación de procedimiento de prueba bien estructurada a un nivel de detalle relevante para el conocimiento de los probadores (K3).
Antecedentes.
El proceso de desarrollo de pruebas que se describe en esta sección puede llevarse a cabo de varias maneras, desde muy informal, con poca o ninguna documentación, hasta muy formal (según se describe a continuación). El nivel de formalidad dependerá del contexto de las pruebas, incluyendo la madurez de las pruebas y de los procesos de desarrollo, las limitaciones de tiempo, los requisitos de seguridad o normativos y las personas implicadas.
Durante el análisis de pruebas, se analiza la documentación básica de las pruebas para determinar el objeto de las pruebas, es decir, para identificar las condiciones de prueba.
Por condición de prueba se entiende un elemento o evento que debería ser verificado por uno o más casos de prueba (por ejemplo, una función, transacción, características, atributo de calidad o elemento estructural).
Durante el diseño de pruebas, se crean y especifican los casos de prueba y los datos de prueba. Un caso de prueba consta de una serie de valores de entrada, precondiciones de ejecución, resultados esperados y condiciones de ejecución cuyo desarrollo tiene por objeto cubrir uno o varios objetivos de pruebas o post condiciones de prueba específicos. La "Norma para la documentación de prueba de software" (IEE STD 829-1998) describe el contenido de las especificaciones de diseño de pruebas (incluyendo condiciones de prueba) y las especificaciones de los casos de prueba.
Los resultados esperados deben presentarse como parte de la especificación de un caso de prueba y deben incluir los valores de salida, las modificaciones a los datos y sentencias, además de cualquier otra consecuencia de la prueba. Si no se han definido los resultados esperados, se podrá interpretar como correcto un resultado plausible pero erróneo.
Idealmente la ejecución de la prueba se desarrolla, implementa, priorizan y organizan los casos de prueba en la especificación de procedimiento de prueba (IEEE STD 829-1998) . El procedimiento de prueba especifica la secuencia de acciones necesarias para ejecutar una prueba. si las pruebas se ejecutan utilizando una herramienta de ejecución de pruebas, la secuencia de acciones se especifica en un guión de prueba (que es un procedimiento de prueba automatizado).
Los distintos procedimeintos de prueba y guiones de prueba automatizados conforman más tarde un calendario de ejecución de pruebas que establece el orden en el que deben ejecutarse los distintos procedimiento de prueba, y posiblemente también los guiones de prueba. El calendario de ejecución de pruebas tendrá en cuenta factores como las pruebas de regresión, la priorización y las dependencias técnicas y lógicas.
Obtención de casos de pruebas a partir de requisitos.
- El diseño de casos de pruebas debe ser un proceso controlado.
- Los casos de prueba pueden ser creados formal o informalmente, dependiendo de las características del proyecto y la madurez del proceso en uso.
Trazabilidad.
- Las pruebas deben ser trazables: ¿Qué casos de prueba han sido incluidos en el catálogo de pruebas, basados en qué requisitos?
- Las consecuencias de los cambios en los requisitos sobre las pruebas a realizar pueden ser identificadas directamente.
- La trazabilidad :
- Ayuda a determinar la cobertura de requisitos.
- Permite establecer la calidad de los casos de prueba en base a :
- a).- Trazas claros respecto de requisitos.
- b).- Resultados esperados
Definiciones.
- Objeto de prueba ("test object"):
- Condición de prueba ("test condition"):
- Criterios de prueba ("test criteria"):
- Calendario de ejecución de prueba ("test execution schelude"):
- Especificación de diseño de prueba.
- Especificación de casos de prueba.
Descripción de un caso de prueba según el estándar IEEE 829
Combinación de casos de pruebas.- Precondiciones ("precondition"): situación previa a la ejecución de pruebas o características de un objeto de pruebas antes de llevar a la práctica (ejecución) un caso de prueba.
- Valores de entrada ("input values"): descripción de los datos de entrada de un objeto de pruebas.
- Resultados esperados ("expected results"): datos de salida que se espera que produzca un objeto de prueba.
- Poscondiones ("post condition"): características de un objeto de prueba tras la ejecución de pruebas, descripción de su situación tras la ejecución de las pruebas.
- Dependencias ("dependencies"): orden de ejecución de casos de pruebas , razón de las dependencias.
- Identificador distinguible ("distict identification"): Identificador o código con el objeto de vincular, por ejemplo, un informe de errores al caso de prueba en el cual ha sido detectado.
- Requisitos ("requirements"): características del objeto de pruebas que el caso de prueba debe evaluar.
- Los casos de prueba se pueden combinar en juegos de pruebas ("test suits") y escenarios de pruebas.
- Una especificación de procedimiento de prueba define la secuencia de acciones para la ejecución de un caso de prueba individual o un juego de pruebas. Es un script (guión) o "guión cinematográfico" para la prueba describiendo paso a paso, tratamiento o actividades necesarias para la ejecución de la prueba.
- Los juegos de prueba pueden ser codificados y ejecutados de forma automática con el uso de herramientas apropiadas.
- El plan de prueba (dinámico) establece la secuencia de las pruebas planificadas, quién debe realizarlas y cuando. Se deben considerar las restricciones como las prioridades, la disponibilidad de recursos, la infraestructura de pruebas, etc.
- El calendario de ejecución de prueba define el orden de la ejecución de los procedimientos de prueba y automatización de scripts de prueba utilizando para la asignación de prioridad, pruebas de regresión, etc.
27 Expected results are:
a) only important in system testing
b) only used in component testing
c) never specified in advance
d) most useful when specified in advance-->OK
e) derived from the code
27 Los resultados esperados son :
a) sólo es importante en las pruebas del sistema
b ) sólo se utiliza en las pruebas de componentes
c) no se especifica de antemano
d ) Es más útil cuando se especifica de antemano-->OK
e) derivado a partir del código
34 What statement about expected outcomes is FALSE:
a) expected outcomes are defined by the software’s behavior-->NOK
b) expected outcomes are derived from a specification, not from the code
c) expected outcomes include outputs to a screen and changes to files and databases
d) expected outcomes should be predicted before a test is run
e) expected outcomes may include timing constraints such as response times
34 ¿Cuál declaración sobre los resultados esperados es FALSA :
a) los resultados esperados se definen por el comportamiento del software-->NOK
b) los resultados esperados se derivan de una especificación, no desde el código-->OK
c ) los resultados esperados incluyen salidas a una pantalla y cambios en los archivos y bases de datos-->OK
d ) los resultados previstos deben ser predichos antes de ejecutar una prueba-->OK
e) los resultados esperados pueden incluir limitaciones de tiempo , tales como los tiempos de
respuesta-->OK
37 Which of the following is NOT included in the Test Plan document of the Test
Documentation Standard:
a) Test items (i.e. software versions)
b) What is not to be tested
c) Test environments
d) Quality plans-->OK
e) Schedules and deadlines
37 ¿Cuál de los siguientes actividades, NO se incluye en el documento del Plan de prueba de la documentación estándar del Prueba.
a) Elementos de prueba ( es decir, versiones de software )
b ) Que no puede ser testeado
c ) Los entornos de prueba
d ) Planes de Calidad-->OK
e) Los horarios y plazos
No hay comentarios:
Publicar un comentario