Casos de pruebas

5/12/2018 Casos de pruebas - slidepdf.com

http://slidepdf.com/reader/full/casos-de-pruebas-55a35b4153d15 1/9

2. DISEÑO DE CASO DE PRUEBA

2.1 CONCEPTO

Según la IEEE, estándar 610 define un caso de prueba como “Conjunto de entrada de

prueba, condición de ejecución, y resultado esperado desarrollados para un objetivo en

particular, como el ejercicio de una ruta de programa en particular o para verificar el

cumplimiento de un requisito específico, y como documentación que especifique las

entradas, los resultados previos, y un conjunto de condiciones de ejecuciones de un

elemento de prueba”. A partir de esta definición, se puede deducir acerca de los casos de

pruebas:

Los casos de prueba se utilizan para la ejecución de una prueba en un producto de

software.

Los casos de prueba se compone de entradas de usuario que se proporcionan a laaplicación y el procedimiento para la ejecución del caso de prueba durante la

prueba. Prueba de detalle de los casos los resultados esperados desde el software cuando la

prueba se ejecuta con los insumos especificados por el usuario.

Los casos de prueba son específicos de un artefacto de código de software o una

clase de artefactos de código de software.

Los casos de prueba de facilitar y asegurar el cumplimiento de los artefactos decódigo de software con un requisito específico.

Los casos de prueba están documentados.

La práctica habitual es el de documentar los casos de prueba en una hoja de cálculo como

Microsoft Excel o en una herramienta como TestPal. (Esta herramienta está disponible

como descarga gratuita desde la Web de descarga de Valor Agregado en el Centro de

Recursos www.jrosspub.com). La práctica general es el de documentar los casos de

prueba para un componente de software (artefacto de código de software) en un

documento. (Ver figura 2.1)



Figura 2.1 Formato de definición casos de prueba.

Una tabla de condiciones es otra manera de describir los casos de prueba. Una tabla de

condiciones se describe el comportamiento del sistema para diferentes combinaciones de

insumos. Por ejemplo, en una pantalla de registro, el usuario introduce un nombre de

usuario y una contraseña y haga clic ya sea en el botón Aceptar o el botón Cancelar.

Cuando el botón se hace clic en Cancelar, el diario de la acción debe ser cancelada, pero

cuando el usuario hace clic en el botón Aceptar, el sistema se comporta como se describeen la Figura 2.2.

Figura 2.2 Tabla de condición para una pantalla de registro



El diseño de casos de prueba es muy importante en las pruebas de software. Diseñados

adecuadamente los casos de prueba pueden descubrir todos los defectos y mal diseñado los

casos de prueba, dejando defectos residuales en el producto de software.

2.2 OBJETIVOS

El objetivo del diseño de casos de prueba es descubrir todos los defectos que acechan en el

software y para poner a prueba todo el software completo, con la minimización de la

restricción quede esfuerzo y tiempo.

Los casos de prueba deben derivarse de los artefactos de software de información. En la

siguiente figura se mostrara la lista de artefactos que ayudan la obtención de un caso de

prueba. (Ver figura 2.3)

Figura 2.3 Información de los artefactos del software que asisten en derivados de caso

de pruebas

El número de casos de prueba para ser diseñado y documentado es bastante grande.

Considere las siguientes implicaciones en el diseño de casos de prueba:

Por cada entrada de datos numérico (incluido los datos de tipo fecha), cinco casos

de pruebas, usando el particionamiento y técnica de análisis del valor limite.

Verificar que el tamaño debe ser realizada por todo los datos no numéricos, uno por

cada elemento.

Todos los datos no numéricos deben ser evaluados para verificar que han sido

introducido y que la área de entrada no se deja en blanco.

Las pruebas de lógica es necesaria para comprobar la presencia de datos no validos,

como dos puntos decimales en tipo numérico, numérico y caracteres especiales en el

campo de nombre, etc.



Por lo tanto, el caso de prueba para establecer incluso una unidad de complejidad

moderada es enorme.

Los proyectos modernos son de gran tamaño, y el esfuerzo requerido para

preparar exhaustivamente un conjunto de caso de prueba sea muy amplio. Por esta razón, es

común para preparar los casos de prueba donde se espera que el probador no pueda

entender intuitivamente los casos de prueba en si mismo. Según las guías de pruebas es de

uso general para los siguientes tipos de pruebas de software:

Prueba GUI.

Prueba de navegación (entorno web).

Prueba negativas.

Prueba de carga.

Prueba de estrés.

Prueba paralelo y concurrente.

Las organizaciones utilizan estas directrices para evitar tener que preparar los casos de

prueba exhaustiva. Las pruebas de integración, pruebas del sistema, y las pruebas de

aceptación que normalmente se llevan a cabo contra los casos de prueba.

2.3 TECNICAS DE PRUEBAS

Describimos una serie de técnicas de pruebas que el Analista de Pruebas puede emplear enel diseño y desarrollo de casos de pruebas efectivas.

Las técnicas de pruebas están organizadas en:

2.3.1 TECNICAS DE PRUEBAS GENERALES:

2.3.1.1 PRUEBA POSITIVA

Prueba de positivo en las pruebas del software tal como se especifica y no trata de acciones

que no se espera de un usuario sincera, para asegurarse de que todas las funciones

definidas es el esperado. No está diseñado para descubrir defectos en el software.

La prueba positiva se realiza principalmente durante los clientes y usuarios finales las

pruebas de aceptación, pruebas funcionales y pruebas de extremo a extremo. Se lleva a

cabo sobre la base de casos de prueba diseñados para demostrar que el producto de



software está trabajando según lo previsto. Este tipo de pruebas se utiliza justo antes de la

entrega de un producto a los clientes, para asegurar que el producto está funcionando.

2.3.1.2 PRUEBA NEGATIVA

La prueba negativo implica el uso del software de una manera en la que no se espera que

sea utilizado, lo que revela todos los otros defectos ocultos no relacionados directamente

con la funcionalidad definida en el software. Esto es para asegurar que incluso el

uso malicioso no afectará el software o la integridad de los datos.

Con el advenimiento de sistemas de eventos activados por software, las pruebas

negativas se han convertido en muy importante. Cada control en la pantalla, como un

cuadro de texto, cuadro combinado, cuadro de lista, etc., tiene un gran número de eventos

asociados. Por ejemplo, haga clic, doble clic, cambiar, ratón arriba, ratón abajo, tiene elfoco, perdido el foco, presione la tecla, tecla, tecla, etc. están asociados con un cuadro

combinado. Se tiene mucho cuidado en el código de control para que la acción del

usuario de la activación de un evento es validado por un segmento de código y los

fracasos se previenen.

Las pruebas negativas desentierra prueba deficiencias en el software centrado en el manejo

de errores y facilita la mejora del software para que las fallas inesperadas no se producen

en las instalaciones del cliente. Recomiendo llevar a cabo esta prueba en todos losproductos de software, ya sea en el escenario del proyecto o producto escenario.

2.3.1.3 PRUEBA DE CAJA NEGRA

En las pruebas de caja negra, el software es tratado como un "caja negra", y su lógica

interna para el procesamiento de los datos no se considera. Un conjunto de entradas se

introduce en el software y los productos entregados por el software se comparan con los

resultados esperados. Para utilizar esta técnica, el auditor considera que la funcionalidad

del software y administra la prueba. La prueba de caja negra es representada de la siguiente

manera. (Ver figura 2.4)



Figura 2.4 La prueba de caja negra

La prueba de caja negra normalmente se lleva a cabo desde la interfaz de usuario o la línea

de comandos. El programa se invoca, y los insumos necesarios se dan en el software para

que los procesos de los datos de prueba y las entradas del usuario para generar

resultados que se pueden comparar con los resultados esperados. Esto determina si

el software funcionaba correctamente.

La eficacia de las pruebas de caja negra depende del cuidado con que los casos de

prueba y datos de prueba están diseñados. Si los casos de prueba se completan, la prueba es

exhaustiva y tiene una mejor oportunidad de detectar anomalías en el software.

2.3.1.4 PRUEBA DE CAJA BLANCA

La prueba de caja blanca considera las declaraciones de lógica interna y el programa

del software. Se trata de pasar a través de cada línea de código y de todas las ramas en elcódigo. Para utilizar esta técnica, el auditor debe tener conocimiento en el lenguaje de

programación de software y debe entender la estructura del programa. La prueba de caja

blanca se asegura de que todas las declaraciones de los programas y todas las estructuras de

control se ponen a prueba al menos una vez. La prueba de caja blanca es representada de la

siguiente manera. (Ver figura 2.4)

Figura 2.4 La prueba de caja blanca



La prueba de caja blanca puede llevarse a cabo desde la línea de comandos, la interfaz de

usuario, o desde el programa. Si la prueba se lleva a cabo desde la línea de comandos o la

interfaz de usuario, la exhaustividad de la prueba depende de los casos de prueba para

recorrer a través de cada ruta en el software. La otra forma es la realización de pruebas de

caja blanca con el entorno de desarrollo interactivo (IDE) o un depurador de lenguaje

específico. Esta herramienta ha facilitado para realizar lo siguiente:

Paso a través de cada línea de código.

Establecer puntos de interrupción en el código en la ejecución espera a que

el probador para reanudar la ejecución.

Establecer el valor inicial o cambiar el valor de las variables o constantes, sin la

necesidad de cambiar el programa.

Recorrer a través de todos los caminos de las estructuras de control de configurar

dinámicamente los valores de la variable de control.

Detener la ejecución en cualquier punto en el programa y continuar con las

pruebas desde el principio o en cualquier parte del programa.

Mover la ejecución de cualquier punto a cualquier otro punto en el programa.

2.3.1.5 ADIVINAR ERRORES

Como es generalmente aceptado que las pruebas exhaustivas de todos los escenariosposibles no es práctico, las organizaciones tratan de garantizar un producto libre de

defectos de diseño de casos de prueba para estos casos, si los defectos son posibles. Por lo

general, una guía para adivinar el error se ha desarrollado. En esta técnica, el diseñador

de caso de prueba utiliza la experiencia, la intuición y el sentido común para diseñar casos

de prueba que puedan detectar errores.

Como su propio nombre indica, hay una cierta cantidad de errores por

adivinar involucrados, lo que significa que los ingenieros de software son propensos a

cometer errores. Usando esta técnica sin duda requiere de muchos años de experiencia en el

desarrollo y pruebas de software.

Algunos ejemplos de áreas en un campo de fecha en que los errores pueden ocurrir

incluyen una fecha no válida como el 30 de febrero entró en un conjunto de 13 meses o un

año malo como el 9999 entró.



2.3.1.6. PRUEBA DE SOFTWARE AUTOMATIZADO

Aunque estrictamente hablando no es una técnica de prueba, las pruebas automatizadas

se incluyen en este apartado, ya que puede proporcionar una solución de pruebas eficaces.

Una ventaja importante en esta prueba es su capacidad para operar sin supervisión (por

ejemplo, para ejecutar durante la noche o el fin de semana), que proporciona ganancias

significativas en productividad para la tarea de comprobación. Las herramientas

automatizadas también pueden generar una confianza adicional en la automatización,

permitiendo más pruebas para ser ejecutado en el momento mismo que el dado

por una prueba manual equivalente.

2.3.2 TECNICAS DE PRUEBAS FUNCIONALES:

2.3.2.1 EQUIVALENCIA DE PARTICIONAMIENTOEl espacio de entrada se divide en entradas válidas y entradas no validas. Un ejemplo

ilustrará esta técnica. (Ver figura 2.5)

Figura 2.5 Equivalencia de particionamiento

En una aplicación de los recursos humanos, la edad del empleado puede ser de un

mínimo de 16 (edad laboral mínima) y un máximo de 65 (la edad de jubilación). La

partición de valores válidos es de entre 16 y 65 años. Hay dos particiones de datos

inválidos uno por debajo de 16 y otro de 65 años. Por lo tanto, hay tres particiones en este

caso - un válido y dos inválidos. Un caso de prueba se puede diseñar para cada partición, lo

que resulta en tres casos de prueba.



2.3.2.2 ANALISIS DEL VALOR LÍMITE

Mostrando con el ejemplo de las particiones (ver figura 2.6) hay dos límites: la edad

mínima para el empleo y la edad máxima para el empleo (edad de jubilación)

Figura 2.6 Análisis del valor límite

Estos dos límites: 16 y 65 deben ser aceptadas, y todos los valores por debajo de

16 y mayores de 65 debe ser rechazada. Por lo tanto, los casos de prueba están diseñados,

que combinan las técnicas de partición de equivalencia y análisis del valor límite. En este

ejemplo, hay cinco casos de prueba:

Un valor entre 16 y 65 - valor válido.

Un valor en el límite inferior de 16 - valor válido.

Un valor justo por debajo del límite inferior (es decir, menos de 16) - valor no

válido (por lo general este valor se le daría como un día menos de 16). Un valor en el límite superior de 65 un valor válido.

Un valor justo por encima del límite superior (es decir, mayor que 65) - valor no

válido (por lo general este valor se le daría como 65 años y 1 día).

Documents

Casos de pruebas