EDICION: Renny Centeno
DISEﾃ前: Ana Fernﾃ｡ndez
Nﾃｺcleo De Monagas Curso especialidad de grado Universidad De Oriente
Editorial Como siempre desde las oficinas de java conocimiento nos esforzamos por ofrecer a nuestros queridos lectores la mejor y variada información relacionada con el campo de ciencias de la computación, no es fácil mantenerse a la vanguardia en un mundo tan cambiante como el de hoy en día. Esta semana ha sido difícil para los miembros de la revista, pero nos caracterizamos por dejar el todo por el todo y en esta edición no será la excepción, esta semana nos enfocamos en un tema sumamente importante para todo aquel que se esté iniciando en el mundo de los sistemas informáticos o incluso para aquellos que ya están familiarizados pero desean aprender un par de cositas que no están de más, lo que abarcaremos esta semana serán las técnicas para detectar y disminuir los errores que se podrían presentar en un sistema informático, los casos de prueba. Es que resultaría casi imposible diseñar y desarrollar un sistema y que este no presente ningún tipo de inconveniente, QUE ESTE PREFECTO DESDE SUS INICIOS RESULTA DIFICIL DE ALCANZAR, PARA ELLO NACEN LOS CASOS DE PRUEBA, SON VARIOS LOS QUE DISPONEMOS PERO LO MAS SIFNIFICATIVOS SON LOS CASOS DE PRUEBA DE CAJA BLANCA Y CAJA NEGRA, con la caja blanca se busca estudiar cada camino y componente interno del sistema buscando disminuir en gran medida los errores, en cambio con la caja negra se ignora la estructura interna o de control y nos enfocamos más en los requisitos y salidas que necesita el sistema, ambos poseen sus utilidades y son cruciales para mejorar el rendimiento de nuestro sistema informático, esperamos que esta edición sea de tu agrado y logres sacar provecho de este conocimiento.
Contenido
Introduccion…………………………………………………………5 Casos de prueba y su importancia………………………………6 Como crear tu propio caso de prueba manual………………….7 Prueba de caja blanca…………………………………………………….9 Prueba de caja negra………………………………………………………..12 Referencias bibliograficas…………………………………………………..19
Introducción Desde que aparecieron los primeros inventos novedosos aquello que llamamos tecnología la cual nos facilita enormemente la vida con su variedad de aplicaciones, surgió la necesidad de corregir cualquier detalle o defecto que estos podrían tener y que evitaría que realizaran su labor de manera eficaz y eficiente, sabemos que no todo es perfecto y mucho menos cuando es algo que no lleva mucho tiempo de creado, el no corregir
cualquier
falla
podría traer consecuencias que van desde lo más jovial hasta las más lamentables. Los sistemas informáticos no escapan de esta realidad, no son
más
que
tecnología
aplicada que está presente para hacer nuestro día a día mucho menos laborioso, como entidades
creadas
por
el
hombre no están exceptas de errores, se puede presentar desde un molesto bug hasta una falla general del sistema que frustre su funcionamiento (destacando que se pueden presentar estas fallas desde la fase de creación hasta la de implementación) Para prevenir o en su efecto solucionar con la falla existen diversos métodos y técnicas llamados casos de prueba, mediante estos métodos se busca analizar el sistema y todas sus facetas como procedimientos y entradas para detectar y acabar con cualquier anomalía.
Casos de prueba y su importancia En un proyecto de desarrollo de software los errores (bugs en inglés) pueden presentarse en cualquiera de las etapas del ciclo de vida del software
programa o verificar el cumplimiento con un requerimiento en específico. Nada tiene mayor efecto en la satisfacción del usuario final con respecto al software que una vista clara de lo que espera, éstas
Aun cuando se intente detectarlos después
de cada fase utilizando técnicas como la inspección, algunos errores permanecen sin ser descubiertos, Por lo tanto es muy probable que el código final contenga errores de requerimientos y diseño, adicionales a los introducidos en la codificación
expectativas deben ser verificadas y validadas. Los casos de pruebas reflejan los requerimientos que serán verificados. Esta verificación deberá ser realizada de diferentes maneras y por diferentes probadores. Si no se tiene la capacidad para verificar todos los requerimientos, es importante para el éxito del proyecto seleccionar los requerimientos más apropiados o críticos para la prueba. Los requerimientos que se elijan para verificar deberán estar balanceados entre el costo, riesgo y la necesidad de tener los requerimientos verificados.
Las pruebas de software son una parte importante pero muy costosa del proceso de desarrollo de software Un caso de prueba es una serie de pruebas de entrada, condiciones de ejecución y resultados esperados desarrollados para un objetivo en particular, tal como ejecutar una ruta particular de un
6
Como crear un caso de prueba manual Puede crear casos de prueba manuales utilizando Microsoft Test Manager que tienen pasos de prueba de acción y validación. Asimismo, varios casos de prueba pueden compartir un conjunto de pasos de prueba comunes, denominados pasos compartidos. Esto simplifica el mantenimiento de los pasos de prueba en caso de cambiar la aplicación sometida a prueba
Si desea ejecutar un caso de prueba manual varias veces con datos diferentes, no es necesario crear varias copias del caso de prueba. Puede agregar parámetros para las acciones o los resultados esperados en cualquier paso de prueba del caso de prueba. A continuación, puede agregar varios conjuntos de valores para los parámetros que desea usar en la prueba. Cada conjunto de valores para los
Requisitos:
Visual Studio Ultimate Visual Studio Premium Visual Studio Test Professional
Cualquier caso de prueba que se cree está asociado al proyecto de equipo y se puede agregar a varios conjuntos de pruebas en los mismos planes de pruebas u otros diferentes. Cuando se ejecutan estos casos de prueba, se puede marcar qué pasos de prueba se realizan sin errores y cuáles con errores. Se puede crear un error a partir de un caso de prueba con errores. Este error incluye automáticamente los pasos de prueba y otro tipo de información recopilada.
parámetros se ejecuta como una iteración individual de la prueba. Se puede crear un caso de prueba manual desde un plan de pruebas seleccionando un conjunto, tal y como se muestra en la siguiente ilustración.
7
Si el conjunto de pruebas se creó mediante la adición de un requisito al plan de pruebas, los casos de prueba nuevos o existentes que se agreguen a dicho conjunto se vincularán automáticamente al requisito.
A continuación, se pueden agregar los detalles del caso de prueba, tal y como se indica en la ilustración siguiente.
Puede agregar los pasos de prueba copiando y pegando desde Microsoft Excel y Microsoft Word. Seleccione los pasos en su documento de Microsoft Excel o Microsoft Word, haga clic con el botón secundario en un paso existente o Elija aquí para agregar un paso y, a continuación, elija Pegar.
8
Pruebas de caja blanca La prueba de caja blanca se basa en el diseño de casos de prueba que usa la estructura de control del diseño procedimental para derivarlos. Mediante la prueba de la caja blanca el ingeniero del software puede obtener casos de prueba que:
Prueba camino básico La prueba del camino básico es una técnica de prueba de la Caja Blanca propuesta por Tom McCabe. Esta técnica permite obtener una medida de la complejidad lógica de un diseño y usar esta medida como guía para la definición de un conjunto básico.
1. Garanticen que se ejerciten por lo menos una vez todos los caminos independientes de cada módulo, programa o método.
La idea es derivar casos de prueba a partir de un conjunto dado de caminos independientes por los cuales puede circular el flujo de control. Para obtener dicho conjunto de caminos independientes se construye el Grafo de Flujo asociado y se calcula su complejidad ciclomática.
2. Ejerciten todas las decisiones lógicas en las vertientes verdadera y falsa. 3. Ejecuten todos los bucles en sus límites operacionales. 4. Ejerciten las estructuras internas de datos para asegurar su validez. Es por ello que se considera a la prueba de Caja Blanca como uno de los tipos de pruebas más importantes que se le aplican a los software, logrando como resultado que disminuya en un gran porciento el número de errores existentes en los sistemas y por ende una mayor calidad y confiabilidad.
Los pasos que se siguen para aplicar esta técnica son: 1. A partir del diseño o del código fuente, se dibuja el grafo de flujo asociado. 2. Se calcula la complejidad ciclomática del grafo. 3. Se determina un conjunto básico de caminos independientes.
9
4. Se preparan los casos de prueba que obliguen a la ejecución de cada camino del conjunto básico. Los casos de prueba derivados del conjunto básico garantizan que durante la prueba se ejecuta por lo menos una vez cada sentencia del programa. Notación de Grafo de Flujo Para aplicar la técnica del camino básico se debe introducir una sencilla notación para la representación del flujo de control, el cual puede representarse por un Grafo de Flujo. Cada nodo del grafo corresponde a una o más sentencias de código fuente. Todo segmento de código de cualquier programa se puede traducir a un Grafo de Flujo. Para construir el grafo se debe tener en cuenta la notación para las instrucciones. Un Grafo de Flujo está formado por 3 componentes fundamentales que ayudan a su elaboración, comprensión y nos brinda información para confirmar que el trabajo se está haciendo adecuadamente. Los componentes son: Nodo Cada círculo representado se denomina nodo del Grafo de Flujo, el cual representa una o más secuencias procedimentales. Un solo nodo puede corresponder a una secuencia de procesos o a una sentencia de decisión. Puede ser también que hallan nodos que no se asocien, se utilizan principalmente al inicio y final del grafo.
Aristas Las flechas del grafo se denominan aristas y representan el flujo de control, son análogas a las representadas en un diagrama de flujo. Una arista debe terminar en un nodo, incluso aunque el nodo no represente ninguna sentencia procedimental. Regiones Las regiones son las áreas delimitadas por las aristas y nodos. También se incluye el área exterior del grafo, contando como una región más. Las regiones se enumeran. La cantidad de regiones es equivalente a la cantidad de caminos independientes del conjunto básico de un programa. Cualquier representación del diseño procedimental se puede traducir a un grafo de flujo. Cuando en un diseño se encuentran condiciones compuestas (uno o más operadores AND, NAND, NOR lógicos en una sentencia condicional), la generación del grafo de flujo se hace un poco más complicada.
10
adecuadamente establecidas, con el fin de comprobar cada camino.
Complejidad Ciclomática La complejidad ciclomática es una métrica de software extremadamente útil pues proporciona una medición cuantitativa de la complejidad lógica de un programa. El valor calculado como complejidad ciclomática define el número de caminos independientes del conjunto básico de un programa y nos da un límite superior para el número de pruebas que se deben realizar para asegurar que se ejecute cada sentencia al menos una vez. Un camino independiente es cualquier camino del programa que introduce por lo menos un nuevo conjunto de sentencias de procesamiento o una nueva condición. El camino independiente se debe mover por lo menos por una arista que no haya sido recorrida anteriormente
Casos de prueba para cada camino. Camino 1: 1-2-3-5-6. Escoger algún X y Y tales que cumpla X >= 0 AND Y >= 0. X = 10 AND Y = 20. Camino 2: 1-2-4-6. Escoger algún X tal que se cumpla X < 0. X = -15. Luego de confeccionar los casos de prueba se ejecutan cada uno de estos y se comparan los resultados con los esperados. Una vez terminados todos los casos de prueba, se estará seguro de que todas las sentencias del programa se han ejecutado por lo menos una vez. Es importante considerar que algunos caminos no se pueden probar de forma aislada. O sea, la combinación de datos requeridos para recorrer el camino no se puede obtener con el flujo normal del programa. En tales casos, estos caminos se prueban como parte de otra prueba de camino.
Derivación de casos de prueba Luego de tener elaborados los Grafos de Flujos y los caminos a recorrer, se preparan los casos de prueba que forzarán la ejecución de cada uno de esos caminos. Se escogen los datos de forma que las condiciones de los nodos predicados estén
11
Prueba de caja negra Estas pruebas permiten obtener un conjunto de condiciones de entrada que ejerciten completamente todos los requisitos funcionales de un programa. En ellas se ignora la estructura de control, concentrándose en los requisitos funcionales del sistema y ejercitándolos. La prueba de Caja Negra no es una alternativa a las técnicas de prueba de la Caja Blanca, sino un enfoque complementario que intenta descubrir diferentes tipos de errores a los encontrados en los métodos de la Caja Blanca. Muchos autores consideran que estas pruebas permiten encontrar:
ejecución de los estos casos y que permitan que el sistema se ejecute en todas sus variantes, pueden ser datos válidos o inválidos para el programa según si lo que se desea es hallar un error o probar una funcionalidad. Los datos se escogen atendiendo a las especificaciones del problema, sin importar los detalles internos del programa, a fin de verificar que el programa corra bien. Para desarrollar la prueba de caja negra existen varias técnicas, entre ellas están: 1. Técnica de la Partición de Equivalencia: esta técnica divide el campo de entrada en clases de datos que tienden a ejercitar determinadas funciones del software.
1. Funciones incorrectas o ausentes. 2. Errores de interfaz. 3. Errores en estructura s de datos o en accesos a las Bases de Datos externas.
2. Técnica del Análisis de Valores Límites: esta Técnica prueba la habilidad del programa para manejar datos que se encuentran en
4. Errores de rendimiento. los límites aceptables. 5. Errores de terminación.
inicialización
y 3. Técnica de Grafos de CausaEfecto: es una técnica que permite al encargado de la prueba validar complejos conjuntos de acciones y condiciones.
Para preparar los casos de pruebas hacen falta un número de datos que ayuden a la
12
Dentro del método de Caja Negra la técnica de la Partición de Equivalencia es una de las más efectivas pues permite examinar los valores válidos e inválidos de las entradas existentes en el software, descubre de forma inmediata una clase de errores que, de otro modo, requerirían la ejecución de muchos casos antes de detectar el error genérico. La partición equivalente se dirige a la definición de casos de pruebas que descubran clases de errores, reduciendo así en número de clases de prueba que hay que desarrollar.
evaluación de las clases de equivalencia para una condición de entrada. Una clase de equivalencia representa un conjunto de estados válidos o inválidos para condiciones de entrada. Regularmente, una condición de entrada es un valor numérico específico, un rango de valores, un conjunto de valores relacionados o una condición lógica. Las clases de equivalencia se pueden definir de acuerdo con las siguientes directrices: Si un parámetro de entrada debe estar comprendido en un cierto rango, aparecen 3 clases de equivalencia: por debajo, en y por encima del rango.
Partición equivalente Una partición equivalente es una técnica de prueba de Caja Negra que divide el dominio de entrada de un programa en clases de datos de los que se pueden derivar casos de prueba. El diseño de estos casos de prueba para la partición equivalente se basa en la evaluación de
Si una entrada requiere un valor concreto, aparecen 3 clases de equivalencia: por debajo, en y por encima del rango. Si una entrada requiere un valor de entre los de un conjunto, aparecen 2 clases de equivalencia: en el conjunto o fuera de él. Si una entrada es booleana, hay 2 clases: si o no. Los mismos criterios se aplican a las salidas esperadas: hay que intentar generar resultados en todas y cada una de las clases.
las clases de equivalencia. El diseño de casos de prueba para la partición equivalente se basa en una
13
Aplicando estas directrices se ejecutan casos de pruebas para cada elemento de datos del campo de entrada a desarrollar. Los casos se seleccionan de forma que ejerciten el mayor número de atributos de cada clase de equivalencia a la vez.
definir los casos de pruebas, pero para ello antes se debe haber asignado un identificador único a cada clase de equivalencia.
Para aplicar esta técnica de prueba se tienen en cuenta los siguientes pasos:
1. Escribir un nuevo caso de cubra tantas clases de equivalencia válidas no cubiertas como sea posible hasta que todas las clases de equivalencia hayan sido cubiertas por casos de prueba.
Primero se deben identificar las clases de equivalencia lo cual se hace tomando
Cada condición de entrada y aplicándole las directrices antes expuestas. Para definir las clases de equivalencia hace falta tener en cuenta un conjunto de reglas: Si una condición de entrada especifica un rango, entonces se confeccionan una clase de equivalencia válida y 2 inválidas. Si una condición de entrada especifica la cantidad de valores, identificar una clase de equivalencia válida y dos inválidas. Si una condición de entrada especifica un conjunto de valores de entrada y existen razones para creer que el programa trata en forma diferente a cada uno de ellos, identificar una clase válida para cada uno de ellos y una clase inválida. Si una condición de entrada especifica una situación de tipo “debe ser”, identificar una clase válida y una inválida. Si existe una razón para creer que el programa no trata de forma idéntica ciertos elementos pertenecientes a una clase, dividirla en clases de equivalencia menores.
Luego entonces se pueden definir los casos teniendo en cuenta lo siguiente:
2. Escribir un nuevo caso de prueba que cubra una y solo una clase de equivalencia inválida hasta que todas las clases de equivalencias inválidas hayan sido cubiertas por casos de pruebas. Con la aplicación de esa técnica se obtiene un conjunto de pruebas que reduce el número de casos de pruebas y nos dicen algo sobre la presencia o ausencia de errores. A menudo se plantea que las pruebas a los software nunca terminan, simplemente se transfiere del desarrollador al cliente. Cada vez que el cliente usa el programa está llevando a cabo una prueba. Aplicando el diseño de casos de pruebas al software en cuestión se puede conseguir una prueba más completa y descubrir y corregir el mayor número de errores antes de que comiencen las “pruebas del cliente”.
Luego de tener las clases válidas e inválidas definidas, se procede a
14
pueden ser grabados con una herramienta de automatización de pruebas.
Procedimientos de prueba Un procedimiento de prueba específica como realizar uno o varios casos de prueba o parte de estos. Por ejemplo un procedimiento de prueba puede ser una instrucción para un individuo sobre cómo ha de realizar un caso de prueba manualmente, o puede ser una especificaron de cómo interaccionar manualmente con una herramienta de automatización de pruebas para crear componentes ejecutables de pruebas.
Los componentes de pruebas se utilizan para probar los componentes en el modelo de implementación proporcionando entradas de prueba, controlando y monitorizando la ejecución de los componentes a probar y, posiblemente informando de los resultados de las pruebas. Plan de Prueba El propósito del plan de pruebas es dejar de forma explicita el alcance, el enfoque, los recursos requeridos, el calendario, los responsables y el manejo de riesgos de un proceso de pruebas.
El cómo llevar a cabo un caso de prueba puede ser especificado por un procedimiento de prueba pero es a menudo útil reutilizar un procedimiento de prueba para varios casos de prueba y reutilizar varios procedimientos de prueba para varios casos de prueba. Componentes de prueba Un componente de prueba automatiza uno o varios procedimientos de prueba o parte de ellos. Los componentes de pruebas pueden ser desarrollados utilizando lenguaje de guiones o un lenguaje de programación o
15
Está constituido por un conjunto de pruebas. Cada prueba debe:
Dejar claro qué tipo de propiedades se quieren probar (corrección, robustez, fiabilidad, amigabilidad,...).
Dejar claro cómo se mide el resultado.
Especificar en qué consiste la prueba (hasta el último detalle de cómo se ejecuta).
Definir cual es el resultado que se espera (identificación, tolerancia,...). ¿Cómo se decide que el resultado es acorde con lo esperado?
prueba, el personal responsable y los riesgos. Una estrategia de prueba propone movernos hacia afuera en una espiral, de manera que primero se prueban las unidades más pequeñas del diseño del software (clases o módulos) y después como se integran los componentes en los cuales están contenidas estas unidades. RUP propone definir casos de prueba de integración para verificar que los componentes interaccionan entre sí de forma apropiada.
Las pruebas carecen de utilidad, tanto, sí no se sabe exactamente lo que se quiere probar, sí no se está claro cómo se prueba, o si el análisis del resultado se hace a simple vista. Estas mismas ideas se suelen agrupar diciendo que un caso de prueba consta de 3 bloques de información: 1. El propósito de la prueba. 2. Los pasos de ejecución de la prueba.
A partir de un caso de uso se pueden realizar pruebas de caja negra, obteniéndose varios casos de prueba que permiten:
3. El resultado que se espera. Todos y cada uno de esos puntos deben quedar perfectamente documentados. El plan de pruebas señala el enfoque, los recursos y el esquema de actividades de prueba, así como los elementos a probar, las características, las actividades de
16
Verificar el resultado de la interacción entre los actores y el sistema.
Comprobar que se satisfagan las precondiciones y poscondiciones del caso de uso.
Comprobar que se siga la secuencia de acciones especificado por el caso de uso.
Evaluación de prueba Una evaluación de prueba es una evaluación de los resultados de los esfuerzos de prueba, tales como la cobertura del caso de prueba, la cobertura del código y el estado de los defectos
También se pueden realizar pruebas de caja blanca a partir de la realización de un caso de prueba que permiten obtener casos de prueba en los que se verifica la integración ante los componentes que implementan dicho caso de uso. Defecto Un defecto es una anomalía del sistema, como por ejemplo un síntoma de una fallo software o un problema descubierto en una revisión. Un defecto puede ser utilizado para localizar cualquier cosa que los desarrolladores necesitan registrar como síntoma de un problema en el sistema que ellos necesitan controlar y resolver.
.
17
Bibliografía Contenido: Microsoft.com, Cómo: Crear un caso de prueba manual, 2015 https://msdn.microsoft.com/es-es/library/vstudio/dd286659%28v=vs.110%29.aspx [consulta: jueves, 09 de abril del 2015, hora: 14:15] Ecured,
Pruebas
de
caja
blanca,
2015,
http://www.ecured.cu/index.php/Pruebas_de_caja_blanca [consulta: jueves, 09 de abril del 2015, hora: 14:15] Ecured,
Pruebas
de
caja
negra,
2015,
http://www.ecured.cu/index.php/Pruebas_de_caja_negra [consulta: jueves, 09 de abril del 2015, hora: 15:15] TELLO,
Rodriguez,
Importancia
de
las
pruebas
de
software,
2011,
http://www.tamps.cinvestav.mx/~ertello/swe/swTestingTecZacatecas.pdf [consulta: jueves, 09 de abril del 2015, hora: 16:17]
Imágenes: http://identidadgeek.com,
Software,
S.F.,
recuperado
de:
http://identidadgeek.com/category/software/ ORE, Alexander, UNIT TESTING - PRUEBAS UNITARIAS - CAP 1, 2011, recuperado de: http://www.calidadysoftware.com/testing/pruebas_unitarias1.php ROMAY,
Alfonzo,
Complejidad
innecesaria
en
las
organizaciones,2014,
recuperado de: http://www.scalabble.com/2014/05/complejidad-innecesaria/
18
www.muycanal.com, La complejidad de elegir un software empresarial adecuado, 2011, recuperado de: http://www.muycanal.com/2011/06/15/software-empresarialadecuad-empresas Ecured,
Pruebas
de
caja
negra,
2015,
recuperado
de:
recuperado
de:
http://www.ecured.cu/index.php/Pruebas_de_caja_negra LOPEZ,
Alex,
Periodo
de
prueba,
2014,
http://alaboralista.com/periodo-de-prueba/ androideity.com, Componentes de una aplicaci贸n Android, 2011, recuperado de: http://androideity.com/2011/07/05/componentes-de-una-aplicacion-android/ www.catlab.com.ar,Validacion de los sistemas inform谩ticos, 2011, recuperado de: http://www.catlab.com.ar/notas.php?idm=1419&accion1=notas&PHPSESSID=25d db8ccac6a586bebdaac642ca3a248 rupproceso.blogspot.com,
RUP,
2011,
recuperado
de:
http://rupproceso.blogspot.com/ brightphone-web.sharepoint.com, Lista de precios, S.F. , recuperado de: https://brightphone-web.sharepoint.com/Pages/Inicio.aspx
19
UN POCO DE HUMOR