JOSE PEREIRA 25.360.

871

SISTEMAS DE INFORMACION 1

TRABAJO. PRUEBAS DE SOFTWARE

PREGUNTAS:

1. LUEGO DE VER EL VIDEO DE UNA DEFICION DE LO QUE SON LAS PRUEBAS DE SOFTWARE

2. EXPLIQUE QUE SON LAS PRUEBAS DE UNIDAD

3. PROCEDIMIENTOS PARA REALIZAR LAS PRUEBAS DE UNIDAD

4. EXPLIQUE QUE SON LAS PRUEBAS DE INTEGRACION

5. TIPOS FORMALES DE INTEGRACION

6. PRUEBA DE CAJA BLANCA

7. PRUEBA DE RUTA BASICA

8. QUE ES UNA RUTA DE CAMINO INDEPENDIENTE

9. QUE ES LA COMPLEJIDAD CICLOMATICA Y COMO SE CALCULA

10. PRUEBA DE CAJA NEGRA

11. EN QUE CONSISTE EL METODO DE PARTICIONES EQUIVALENTES

12. DEBEN CREAR UNA TABLA EN INDICARAN QUE DIAGRAMAS UML SE UTILIZAN EN CADA

UNA DE SUS CUATRO FASES

RESPUESTAS:

1. Las pruebas de software son un conjunto de procesos con los que se pretende probar un
sistema o aplicación en diferentes momentos para comprobar su correcto funcionamiento.

2. Las pruebas unitarias consisten en aislar una parte del código y comprobar que funciona a la
perfección mediante pequeños tests que validan el comportamiento de un objeto y la lógica.
Suele realizarse durante la fase de desarrollo de aplicaciones de software o móviles,
normalmente las llevan a cabo los desarrolladores, aunque en la práctica, también pueden
realizarlas los responsables de QA.

3. El proceso de los tests unitarios puede realizarse de manera manual, aunque lo más común
es automatizar el procedimiento a través de herramientas. Hay muchas opciones disponibles,
que varían en función del lenguaje de programación que se esté utilizando, al utilizar estas
herramientas, se codifican los criterios en la prueba que verificarán si el código es o no correcto.

Para llevar a cabo buenas pruebas unitarias, deben estar estructuradas siguiendo las tres A’s
del Unit Testing. Se trata de un concepto fundamental respecto a este tipo de pruebas, que
describe un proceso compuesto de tres pasos.

 Arrange (organizar): es el primer paso de las pruebas unitarias. En esta parte se definen
los requisitos que debe cumplir el código.
 Act (actuar): es el paso intermedio de las pruebas, el momento de ejecutar el test que
dará lugar a los resultados que deberás analizar.
 Assert (afirmar): en el último paso, es el momento de comprobar si los resultados
obtenidos son los que se esperaban. Si es así, se valida y se sigue adelante. Si no, se
corrige el error hasta que desaparezca.

4. Son aquellas que se realizan en el ámbito del desarrollo de software una vez que se han
aprobado las pruebas unitarias y lo que prueban es que todos los elementos unitarios que
componen el software, funcionan juntos correctamente probándolos en grupo.

5. Tipos fundamentales de integración:

 Integración incremental: se combina el siguiente componente que se debe probar con el

conjunto de componentes que ya están probados y se va incrementando
progresivamente el número de componentes a probar.
 Integración no incremental: se prueba cada componente por separado y posteriormente
se integran todos de una vez realizando las pruebas pertinentes. Este tipo de integración
se denomina también Big-Bang.

6. Las pruebas de caja blanca se centran en los detalles procedimentales del software, por lo
que su diseño está fuertemente ligado al código fuente. El ingeniero de pruebas escoge distintos
 valores de entrada para examinar cada uno de los posibles flujos de ejecución del programa y
cerciorarse de que se devuelven los valores de salida adecuados. Al estar basadas en una
implementación concreta, si esta se modifica, por regla general las pruebas también deberán
rediseñarse.

Aunque las pruebas de caja blanca son aplicables a varios niveles (unidad, integración y
sistema), habitualmente se aplican a las unidades de software. Su cometido es comprobar los
flujos de ejecución dentro de cada unidad (función, clase, módulo, etc.) pero también pueden
probar los flujos entre unidades durante la integración, e incluso entre subsistemas, durante las
pruebas de sistema. Las principales técnicas de diseño de pruebas de caja blanca son:
 Pruebas de flujo de control
 Pruebas de flujo de datos
 Pruebas de bifurcación (branch testing)
 Pruebas de caminos básicos

7. Esta técnica permite al diseñador de casos de prueba obtener una medida de la complejidad
lógica de un diseño procedimental y usar esa medida como guía para la definición de un
conjunto básico diseño de casos de prueba de caminos de ejecución, 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.

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,
los pasos que se siguen para aplicar esta técnica son:
 Partir del diseño o del código fuente, se dibuja el grafo de flujo asociado.
 Se calcula la complejidad ciclomática del grafo.
 Se determina un conjunto básico de caminos independientes.
 Se preparan los casos de prueba que obliguen a la ejecución de cada camino del conjunto
básico.

Permite al diseñador de casos de prueba definir un conjunto básico de rutas de ejecución.

Los casos de prueba obtenidos tienen la garantía de ejecutar todo enunciado en el
programa, al menos una vez durante la prueba. Esta prueba lo que demuestra es el conjunto
de pasos base del programa, lo que quiere lograr es que cada sentencia de código se ejecute
mínimo una vez.

8. 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.

9. 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. Se calcula de la
siguiente manera, existen tres opciones:

 Restar las aristas menos los nodos y sumar 2:

V(G) = Aristas – Nodos + 2
 Sumar 1 al número de nodos predicados (aquellos de los que salen dos flechas)
V(G) = Nodos predicados + 1
 Contar el número de regiones (espacios «encerrados entre nodos y aristas», también se
tiene en cuenta el espacio «exterior» a todos los nodos y aristas)
V(G) = Regiones

10. Es una técnica de pruebas de software en la cual la funcionalidad se verifica sin tomar en
cuenta la estructura interna de código, detalles de implementación o escenarios de ejecución
internos en el software. Dichas pruebas son llevadas a cabo sobre la interfaz del software, es
decir, de la función, actuando sobre ella como una caja negra, proporcionando unas entradas y
estudiando las salidas para ver si concuerdan con las esperadas.

11. 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 las
clases de equivalencia.

El diseño de casos de prueba para la partición equivalente se basa en una 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.

 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.

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.
12.

FASES TIPOS DE DIAGRAMAS

 CASOS DE USO
ANALISIS  OBJETOS
 CLASES
 COMUNICACIÓN
DISEÑO  ESTRUCTURA COMPUESTA

PROGRAMACIÓN  OBJETOS

PRUEBAS  ESTRUCTURA COMUESTA