Comparación de los términos de condiciones de prueba, casos de prueba y procedimiento de prueba (K)

3 casos de prueba de escritura: (K3)

a) mostrando una clara trazabilidad de los requisitos; b) que contiene un Resultado Esperado.

Traducir casos de prueba en un procedimiento de pruebas bien estructurado a un nivel de detalle relevante para el conocimiento de los testers. (K3)

5 Escribir un programa de ejecución de prueba para un determinado conjunto de casos de prueba, teniendo en cuenta priorización, y técnicos y lógicos dependencias. (K3) 4.1.1 Introducción

Antes de que realmente puede ejecutar una prueba, tenemos que saber lo que estamos tratando de probar, las entradas, los resultados que debe ser producido por esas entradas, y la forma en que realmente se preparan para ejecutar las pruebas.

En esta sección estamos ante tres cosas: las condiciones de prueba, casos de prueba y procedimientos de prueba (o scripts) que se describen en las siguientes secciones. Cada una se especifica en su propio documento, de acuerdo con la Documentación estándar de Prueba [IEEE829].

Condiciones de la prueba se documentan en un diseño de la Norma de prueba. Vamos a ver cómo elegir la prueba condiciones y dar prioridad a ellos.

Los casos de prueba se documentan en un caso de la Norma de prueba. Vamos a ver cómo para escribir un buen caso de prueba, mostrando trazabilidad clara a la base de pruebas (por ejemplo, la especificación de requisitos), así como a las condiciones de prueba.

Los procedimientos de prueba están documentados (como se puede esperar) en un procedimiento de prueba Especifico (también conocido como un script de prueba o un script de prueba manual). Vamos a ver la forma de traducir los casos de prueba en los procedimientos de prueba relevantes para el conocimiento del testers, de la que se ejecuta la prueba, y vamos a buscar la forma de producir un calendario de ejecución de pruebas, usando el establecimiento de prioridades y técnica y lógica dependencias.

En esta sección, busque las definiciones de los términos del glosario: caso de prueba, caso de prueba especifico, las condiciones de prueba, datos de prueba, procedimiento de prueba especifico, escritura de la prueba y la trazabilidad.

4.1.2 La formalidad de la documentación de prueba

La prueba puede realizarse con diversos grados de formalidad. prueba muy formal tendría una extensa documentación que está bien controlada, y se esperaría el detalle documentado de las pruebas que incluyen la entrada exacta y específica y el resultado esperado de la prueba. Muy informal prueba que no tiene documentación en absoluto, o sólo las notas mantenidas por los testers individuales, pero todavía esperaría que el testers tiene en sus mentes y señala una idea de lo que pretendían poner a prueba y lo que espera que el resultado sea. La mayoría de la gente está probablemente en algún lugar ¡entre! El nivel adecuado de formalidad para usted depende de su contexto:

una aplicación comercial crítica para la seguridad tiene necesidades muy diferentes que una que solo se solicitud para ser utilizado por sólo unas pocas personas por un corto tiempo. El nivel de formalidad también se ve influida por su organización, su cultura, las personas que trabajan allí, el grado de madurez del proceso de desarrollo, el grado de madurez del proceso de prueba, etc. La rigurosidad de la documentación de prueba puede También dependerá de sus limitaciones de tiempo; bajo presión de tiempo excesivo, mantener una buena documentación puede verse comprometida.

En este capítulo vamos a describir un estilo de documentación bastante formal. Si esto no es apropiado para usted, es posible adoptar un enfoque menos formal, pero debe ser conscientes de cómo aumentar la formalidad si es necesario.

4.1.3 Análisis de Prueba: Identificación de las condiciones de prueba

Análisis de la prueba es el proceso de observar algo que se puede utilizar para derivar información de la prueba. Esta base de las pruebas se denomina la "base de pruebas '. Podría ser un requisito del sistema, una especificación técnica, el propio código (por estructural prueba), o un proceso de negocio. A veces las pruebas se pueden basar en el conocimiento experimentado del usuario del sistema, que no puede ser documentado. La base de pruebas incluye cualesquiera que sean las pruebas. Esto también se discutió en el Capítulo 1.

Desde una perspectiva de pruebas, nos fijamos en la base de pruebas con el fin de ver qué podría ser probado, éstas son las condiciones de prueba. una condición de prueba es simplemente algo que hemos podido probar. Si estamos buscando para medir la cobertura de código decisiones (ramas), entonces la base de pruebas serían el propio código, y la lista de la prueba de las condiciones serían los resultados de la decisión (verdaderos y falsos). Si nosotros tenemos una especificación de requisitos, la tabla de contenido puede ser nuestra lista inicial de condiciones de prueba.

Una buena manera de entender mejor los requisitos es tratar de definir las pruebas para que cumplan con esos requisitos, como ha señalado [Hetzel, 1988].

Por ejemplo, si estamos probando un sistema de gestión de clientes y comercialización para una empresa de telefonía móvil, podríamos tener condiciones de prueba que están relacionados con una campaña de marketing, tales como la edad del cliente (pre-adolescente, joven adulto, maduro), sexo, código postal o el código postal, y la preferencia de compra (pago por uso o contrato). Una campaña de publicidad en particular podría ser dirigido a clientes adolescentes varones en el medio oeste de los EE.UU. en pago por uso, por ejemplo.

expertos en pruebas utilizan diferentes nombres para representar la idea básica de "una lista de cosas que podíamos probar '. Por ejemplo, Marick se refiere a los requisitos de prueba '' como cosas que deben ser probadas. Aunque no se pretende dar a entender que todo debe ser probado, se interpreta fácilmente de esta manera. [Marick, 1994] En contraste, Hutcheson habla de la "objetos de la pruba 'como una lista de cosas que podrían ser probadas [Hutcheson, 2003]; Craig habla sobre como amplias categorías 'objetivos' de prueba de cosas para probar y '' inventarios de prueba como la lista actual de las cosas que necesitan ser probado [Craig, 2002]. Estos autores se refieren a todo lo que el glosario ISTQB pide una condición de prueba.

En la identificación de las condiciones de prueba, queremos 'lanzar la red' para identificar tantos como podamos, y luego vamos a empezar a ser selectivo sobre cuáles llevar adelante para desarrollar con más detalle y combinar en los casos de prueba. Podríamos llamarlos 'posibilidades' de prueba.

En el capítulo 1 se explicó que las pruebas de todo lo que se conoce como exhaustiva las pruebas (que se define como el ejercicio de todas las combinaciones de insumos y las condiciones previas) y hemos demostrado que este es un objetivo práctico. Por lo tanto, ya que no puede ser probado todo, tenemos que seleccionar un subconjunto de todas las pruebas posibles. En la práctica, el subconjunto que seleccione puede ser un subconjunto muy pequeño y, sin embargo, tiene que tener una alta probabilidad de encontrar la mayor parte de los defectos en un sistema. Necesitamos un proceso inteligente para guiar nuestra selección; técnicas de prueba (es decir, diseño de pruebas técnicas) son tales procesos de pensamiento.

Una técnica de prueba ayuda a seleccionar un buen conjunto de pruebas a partir del número total de todas las pruebas posibles para un sistema dado. Diferentes técnicas ofrecen diferentes maneras de mirar el software bajo prueba, posiblemente supuestos hechos desafiantes sobre ello. Cada técnica proporciona un conjunto de reglas o directrices para el testers a seguir en la identificación de las condiciones de prueba y casos de prueba. Las técnicas se describen en detalle más adelante en este capítulo.

Las condiciones de pruebas que son elegidas dependerán de la estrategia de prueba o enfoque detallado de las pruebas. Por ejemplo, podrían estar basados en el riesgo, modelos del sistema, las posibles averías, los requisitos de cumplimiento, el asesoramiento de expertos o heurística.

La palabra 'heurística' viene de la misma raíz griega como Eureka, lo que significa 'Encuentro'. Una heurística es una manera de dirigir su atención, una regla de sentido común útil en la solución de un problema.

Condiciones de prueba deben ser capaces de vincularse de nuevo a sus fuentes en la prueba Base, esto se llama trazabilidad.

La trazabilidad puede ser horizontal a través de toda la documentación de prueba para una prueba del nivel de prueba determinado (por ejemplo, sistema, a partir de las condiciones de prueba a través de casos de prueba para scripts de prueba) o vertical a través de las capas de la documentación de desarrollo (por ejemplo, de los requisitos a los componentes).

¿Por qué es importante la trazabilidad? Considere estos ejemplos:

Ahora campos tienen diferentes rangos que se pueden introducir. ¿Qué pruebas fueron mirando esos límites? Ahora necesitan ser cambiadas. ¿Cuántas pruebas en realidad será afectado por este cambio en los requisitos? Estas preguntas se pueden responder fácilmente si los requisitos se pueden rastrear fácilmente a las pruebas.

• Un conjunto de pruebas que ha corrido bien en el pasado ha empezado a tener serios problemas. ¿Qué funcionalidad hacen estas pruebas en realidad ejercen? Trazabilidad entre las pruebas y el requisito de que se están probando permite que las funciones o características afectadas para identificar con mayor facilidad.

• Antes de la entrega de un nuevo lanzamiento, queremos saber si tenemos o no probado todos los requisitos especificados en la especificación de requisitos. ¿Nosotros tenemos la lista de las pruebas que han pasado, se puso a prueba todos los requisitos?

Después de haber identificado una lista de condiciones de prueba, es importante dar prioridad a ellos, de modo que se identifican las condiciones de pruebas más importantes (antes de una gran cantidad de tiempo es gastado en el diseño de casos de prueba basados en ellos). ¡Es una buena idea para tratar de pensar del doble de las condiciones de prueba como sea necesario a continuación, se puede tirar a la basura los menos los más importantes, y usted tendrá un mejor conjunto de condiciones de prueba!

Tenga en cuenta que pasar algún tiempo adicional ahora, mientras que la identificación de las condiciones de prueba, no toma mucho tiempo, ya que sólo enumerando las cosas que podíamos probar. Esto es una buena inversión de nuestro tiempo ¡que no queremos pasar tiempo implementar pobres pruebas!

Las condiciones de prueba se pueden identificar por los datos de prueba, así como para las entradas de prueba y los resultados de las pruebas, por ejemplo, diferentes tipos de registro, diferente distribución de tipos de registros dentro de un archivo o base de datos, diferentes tamaños de los registros o campos de una grabar. Los datos de prueba deben ser diseñados para representar los tipos más importantes de los datos, es decir, las condiciones de los datos más importantes.

Condiciones de la prueba se documentan en el documento IEEE 829 llama una prueba Especificaciones de Diseño, se muestra a continuación. (Este documento podría haber sido llamado Condición de prueba Especificación, ya que los contenidos se hace referencia en la norma son en realidad probar condiciones).

IEEE 829 STANDARD: ESPECIFICACIONES DEL MODELO DE DISEÑO DE