casos de pruebas
TRANSCRIPT
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)
5/12/2018 Casos de pruebas - slidepdf.com
http://slidepdf.com/reader/full/casos-de-pruebas-55a35b4153d15 2/9
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
5/12/2018 Casos de pruebas - slidepdf.com
http://slidepdf.com/reader/full/casos-de-pruebas-55a35b4153d15 3/9
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.
5/12/2018 Casos de pruebas - slidepdf.com
http://slidepdf.com/reader/full/casos-de-pruebas-55a35b4153d15 4/9
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
5/12/2018 Casos de pruebas - slidepdf.com
http://slidepdf.com/reader/full/casos-de-pruebas-55a35b4153d15 5/9
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)
5/12/2018 Casos de pruebas - slidepdf.com
http://slidepdf.com/reader/full/casos-de-pruebas-55a35b4153d15 6/9
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
5/12/2018 Casos de pruebas - slidepdf.com
http://slidepdf.com/reader/full/casos-de-pruebas-55a35b4153d15 7/9
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ó.
5/12/2018 Casos de pruebas - slidepdf.com
http://slidepdf.com/reader/full/casos-de-pruebas-55a35b4153d15 8/9
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.
5/12/2018 Casos de pruebas - slidepdf.com
http://slidepdf.com/reader/full/casos-de-pruebas-55a35b4153d15 9/9
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).