Pruebas y mantenimiento de sistemas de software

Unidad 2. Pruebas de software

Ingeniería en Desarrollo de Software

8º Semestre

Programa de la asignatura:
Pruebas y mantenimiento de sistemas de software

Unidad 2. Pruebas de sistemas de software

Actividad 1

AL12524075 Guillermo Duran García

Clave:
15144842

Universidad Abierta y a Distancia de México

UnADM
Pruebas y mantenimiento de sistemas de software
Unidad 2. Pruebas de software

Actividad 1. Pruebas de software

En esta actividad participarás en un foro donde identificarás elementos de la

administración del proceso de prueba de software. Para ello, tu Docente en línea te hará
llegar un caso de análisis, una vez que cuentes con él, sigue estos pasos:

1. Identifica en el caso los elementos de la administración del proceso de pruebas

de software.

2. Identifica los elementos del plan de pruebas.

3. Ingresa tu actividad en el foro y sigue el curso de participación que indique tu

Docente en línea.

4. Ingresa una segunda participación en el foro. Comenta la aportación de, por lo

menos, dos de tus compañeros. Sigue las instrucciones de tu Docente en línea.

5. Argumenta tu participación en el foro. Si consultaste alguna fuente para

sustentarla, debes citarla.

* Revisa la Rúbrica de participación en foros, para que consideres los criterios de

evaluación de esta actividad.
Pruebas y mantenimiento de sistemas de software
Unidad 2. Pruebas de software

INTRODUCCION

La presente actividad tiene como objeto conocer los conceptos relacionados con
las pruebas de software.

Un conjunto de actividades de pruebas suele orientase a comprobar determinados

aspectos de un sistema software (o de una parte de este). Existen varios tipos de
pruebas de Software en función del objetivo en que se centran.
En primer lugar, tenemos las Pruebas Software Funcionales. Típicamente
encontraremos el comportamiento del sistema, subsistema o componente software
descrito en especificaciones de requisitos o casos de uso, aunque también puede
no estar documentado (“que funcione como el sistema al que sustituye”). Es decir,
con las funciones establecemos “lo que el sistema hace”.
Estas pruebas se definen a partir de funciones o características (como decimos,
bien descritas en documentos o bien interpretadas por los probadores) y su
interoperabilidad con sistemas específicos, pudiendo ejecutarse en todos
los niveles de pruebas (componentes, integración, sistema, etc).
Se consideran Pruebas de Caja Negra (“black-box testing”) puesto que
valoramos el comportamiento externo del sistema. Las Pruebas de Seguridad o
las Pruebas de Interoperabilidad entre sistemas o componentes son casos
especializados de las pruebas funcionales.
En segundo lugar, figuran las Pruebas Software no Funcionales que incluyen las
pruebas de: Rendimiento, Carga, Estrés, Usabilidad, Mantenibilidad, Fiabilidad o
Portabilidad, entre otras. Por tanto se centran en características del software que
establecen “cómo trabaja el sistema “.
Estas pruebas también pueden ejecutarse en todos los niveles de pruebas. Las
características no funcionales del software se pueden medir de diversas maneras,
por ejemplo, por medio de tiempos de respuesta en el caso de pruebas de
rendimiento o por número máximo de sesiones en pruebas de estrés.
Puesto que las Pruebas software no Funcionales normalmente consideran el
comportamiento externo del sistema, en la mayoría de los casos se utilizan
técnicas de Pruebas de Caja Negra.
En tercer lugar, tenemos las Pruebas Software Estructurales. Nuevamente pueden
ejecutarse en todos los niveles de pruebas (componentes, integración, sistema,
etc.) y encajan muy bien si hemos utilizado técnicas de especificación de la
Pruebas y mantenimiento de sistemas de software
Unidad 2. Pruebas de software

estructura o arquitectura del Software. Es posible aplicar técnicas estáticas de

análisis de código.
Para expresar el alcance con un conjunto de pruebas (“test suite”) que ha cubierto
la estructura o arquitectura en cuestión, se utiliza el concepto
de Cobertura (“Coverage”), normalmente en forma de porcentaje.
Es especialmente habitual utilizar herramientas de apoyo para calcular la
cobertura del código en el caso de Pruebas de Componentes o en Pruebas de
Integración de Componentes (por ejemplo, trazando la jerarquía de llamadas entre
elementos). Puesto que indagamos en el comportamiento interno, estas pruebas
se denominan también Pruebas de Caja Blanca (“white-box testing”).
El cuarto tipo de pruebas que nos presenta el ISTQB son las pruebas derivadas de
la realización de cambios: las Pruebas Software de Regresión y las Re-pruebas.
Una vez que un defecto ha sido corregido, toca volver a probar el software para
confirmar que el defecto ha sido eliminado. Son pruebas repetidas o Re-Pruebas.
Las Pruebas de Regresión consisten en volver a probar un componente, tras
haber sido modificado, para descubrir cualquier defecto introducido, o no cubierto
previamente, como consecuencia de los cambios. Los defectos pueden
encontrarse tanto en el software que se ha cambiado como en algún otro
componente. Se ejecutan cuando se cambia el software o su entorno. El criterio
para decidir la extensión de estas Pruebas de Regresión está basado en el riesgo
de no encontrar defectos en el software que antes estaba funcionando
correctamente.
Las Pruebas de Regresión se realizan sobre un componente ya probado, para
verificar que no presenta nuevos defectos cuando se realiza una modificación
después de dichas pruebas.
Este tipo de pruebas software deben ser repetibles si han de usarse para pruebas
de confirmación (o aseguramiento) y regresión (como Sondas de Disponibilidad,
por ejemplo). Los conjuntos de pruebas de regresión (“Regression test suites“)
suelen ser bastante estables por lo que son muy buenos candidatos
para actividades de automatización de pruebas software.
Quizá ya no os sorprenda que estas pruebas también puedan ejecutarse en todos
los niveles de pruebas e incluyen casos de prueba de los tipos vistos
anteriormente: Pruebas Funcionales, No Funcionales y Estructurales.
Pruebas y mantenimiento de sistemas de software
Unidad 2. Pruebas de software

CASO DE ESTUDIO
Recorrido virtual
En una empresa de desarrollo web se ha solicitado elaborar un proyecto que debe
montarse en una página web el cual consiste en desarrollar un recorrido virtual de
un museo
El recorrido virtual debe realizarse modelando las instalaciones del museo en un
software de modelado, posteriormente agregar las texturas a los modelos y luego
darle animación usando un motor de videojuegos como unity
El equipo de desarrollo está conformado por dos desarrolladores, el modelo de
desarrollo que se usará deberá ser ágil como XP o DRA, y el tiempo de desarrollo
es de tres meses

DESARROLLO

1. Elige tres tipos de pruebas que usarías para garantizar la calidad y éxito de
proyecto, para estas pruebas debes mencionar el tipo de prueba, quién la
ejecutará, las características de la prueba y el momento del ciclo de desarrollo en
el que se ejecutará
2. Redacta tres preguntas con sus respectivas respuestas que nos ayuden a
entender mejor el porqué de la importancia del plan de pruebas en un proyecto de
desarrollo de software
Pruebas y mantenimiento de sistemas de software
Unidad 2. Pruebas de software

TIPO DE PRUEBAS

Prueba Funcional

Id Caso De Descripción Área Funciona/ Estado

Prueba Sub Proceso
P001 Ventas Verificar que se genere Base de Datos de Concluido
el archivo de ventas las ventas
P002 Logística Verificar que se graben Verificar base de Concluido
los datos de los lugares datos de los
que se recorren lugares a visitar
P003 Recorrido Verificar los lugares que Base de datos de Concluido
se recorren las personas que
realizan el
recorrido
Pruebas y mantenimiento de sistemas de software
Unidad 2. Pruebas de software

Prueba No Funcional

Id Caso De Descripción Área Funciona/ Sub Estado

Prueba Proceso
P001 Configuración Verificar que es capaz Portabilidad, y diversas Concluido
de ejecutarse en plataformas
diferentes versiones o
configuraciones de los
entornos (hardware y
software), por ejemplo,
diversos navegadores
de Internet (browser) o
versiones de estos.
P002 Volumen Determinar los límites Verificar la capacidad del Concluido
de la transformación y sistema o para manejar
la carga del sistema o un gran volumen de
módulo datos como entrada y de
salida o residente en la
base de datos del
módulo
P003 Carga Tiene como objetivo Consultas grandes a una Concluido
evaluar la respuesta de base de datos o un gran
un sistema complejo o número recurrente para
módulo bajo una comprobar el nivel de los
pesada carga de los usuarios de
datos, la repetición de escalabilidad, es decir, el
ciertas acciones de los momento en que el
datos de entrada, los tiempo de respuesta se
grandes valores empieza a degradar, es
numéricos. decir los sistemas /
módulos comienzan a
fallar.
Pruebas y mantenimiento de sistemas de software
Unidad 2. Pruebas de software

Pruebas Estructurales

Id Caso De Prueba Descripción Área Funciona/ Sub Estado

Proceso
P001 Cobertura de Por segmento se El número de Concluido
segmentos entiende una sentencias de un
secuencia de programa.
sentencias sin puntos
de decisión. Como el
ordenador está
obligado a ejecutarlas
una tras otra, es lo
mismo decir que se
han ejecutado todas
las sentencias o todos
los segmentos.
P002 Cobertura de La cobertura de Desde el punto de Concluido
ramas segmentos que es vista de la lógica del
presencia de programa
segmentos
opcionales.
P003 Cobertura de Para afrontar esta Condicion1 = TRUE y Concluido
condición/decisión problemática se define Condicion2 = FALSE
un criterio de cobertura Prueba 2: Condicion1
de condición/decisión = FALSE y
que trocea las Condicion2 = TRUE
expresiones booleanas Prueba 3: Condicion1
complejas en sus = FALSE y
componentes e intenta Condicion2 = FALSE
cubrir todos los Prueba 4: Condicion1
posibles valores de = TRUE y Condicion2
cada uno de ellos. = TRUE Bastan las
pruebas 2 y 3 para
tener cubiertas todas
las ramas
Pruebas y mantenimiento de sistemas de software
Unidad 2. Pruebas de software

PREGUNTAS

Por qué las pruebas funcionales son importantes para el desarrollo de un proyecto

Porque abarcan en su mayoría los requerimientos y solicitudes realizadas por los

usuarios, por lo que mediante estas podemos determinar si lo que se está
construyendo cumple con los niveles de aceptación descritos por el cliente.

Beneficios que tienen este tipo de pruebas

la mitigación del riesgo de aparición de fallos en producción, el cumplimiento de

los objetivos de los proyectos en términos de calidad y resultados esperados
principalmente, pero también de plazos y costos.

Que podemos evitar

Además, la identificación temprana de riesgos y desviaciones asociadas a la

calidad, permiten evitar problemas con proveedores, mayores costos para el
cliente y finalmente generar confianza en el producto o sistema bajo test.

BIBLIOGRAFIA

http://www.pmoinformatica.com/2016/01/elaborar-plan-pruebas-software.html
http://scrum-qa.blogspot.com/2013/03/pruebas-de-estructuraarquitectura-de.html
http://software-byzha.blogspot.com/p/pruebas-estructurales-funcionales-y_12.html
https://www.panel.es/blog/software-qa-cuales-son-los-tipos-de-pruebas-software/