Subido por DANIEL PINEDA

DPSS U2 A1 DPR

Anuncio
PLANEACIÓN DIDÁCTICA DEL DOCENTE
Carrera: INGENIERÍA EN DESARROLLO DE SOFTWARE
Asignatura: Pruebas y Mantenimiento de Sistemas de Software
Nombre del Docente: MC RICARDO RODRÍGUEZ NIEVES
UNIDAD 2
PRUEBAS DE SOFTWARE.
Ciclo Escolar: 2020-2
Semestre: 8
Actividad 1
Pruebas del Software
Nombre del Alumno
Daniel Pineda de la Riva
Matrícula
ES162006588
Fecha de Entrega
Pachuca Hidalgo, a 9 de agosto del 2020
Bloque: 2
ACTIVIDAD 1 DE LA UNIDAD 2
“PRUEBAS DEL SOFTWARE”
TEMAS
2.1. Administración de procesos de pruebas de software.
2.1.1. Plan de pruebas de software.
2.1.2. Seguimiento del plan de pruebas.
PROPÓSITO
 Identificar los principales conceptos y fases relacionados con las pruebas de software.
DESARROLLO
1.- De acuerdo al concepto de Administración de procesos de pruebas, señala cuales son las etapas que lo conforman y detalla de manera breve
en que consiste:
Introducción
Las pruebas son una parte esencial del proceso de desarrollo, ya que verifican y validan que un programa, un subsistema o una aplicación realizan
las aplicaciones para las cuales fue diseñada, determinan si las unidades que están siendo probadas operan sin problemas de funcionamientos ni
efectos adversos sobre otros componentes del sistema.
Estas constituyen un método más para poder verificar y validar el software. Se puede definir la verificación como [IEEE, 1990] el proceso de
evaluación de un sistema o de uno de sus componentes para determinar si los productos de una fase dada satisfacen las condiciones impuestas al
comienzo de dicha fase.
Etapas:
ORGANIZACIÓN
¿Qué? ¿Quién? ¿Cuándo?  Evaluar
Consiste en tener claro quién, qué, y cuándo se va a evaluar. Quién va evaluar, qué técnica de prueba se va aplicar, y quién diseñará los casos de
pruebas, son temas que la fase de organización se encarga de poner en perspectiva.
PLANIFICACIÓN
¿Por qué? ¿Qué? ¿Dónde? ¿Cuándo?  Medir
Es el conjunto global de las tareas que aborda las cuestiones de por qué, qué, dónde y cuándo medir. El por qué se evalúa se debe a que
generalmente es necesario evaluar un requisito específico. Para el qué, debe probarse si se seleccionan los casos de pruebas necesarios. El dónde
probar, determina la documentación del componente de software y la configuración del hardware necesarios. El cuándo hacer la prueba, se
resuelve por el tipo de prueba a realizar: estática durante la programación del componente, o dinámica cuando ya el componente está terminado.
CREACIÓN
Diseñar  Scripts (Casos de prueba)
Es un proceso de captura de los pasos específicos para diseñar los casos de pruebas, de acuerdo con los requerimientos del software. Los casos
pruebas terminan convirtiéndose en scripts de prueba (manual o automatizada).
EJECUCIÓN
Aplicar  Pruebas (Scripts)
Consiste en aplicar las pruebas mediante el ensamblaje de secuencias de scripts, en una serie de pruebas.
PRESENTACIÓN DE INFORMES
Resultados  Pruebas
Analizan y comunican los distintos resultados del trabajo de comprobación. El informe determina el estado actual de las pruebas, así como el nivel
general de la calidad del componente o sistema.
2.- Revisando los conceptos de Prueba / Caso de Prueba / Escenario de prueba, señala en la siguiente tabla en que consiste cada concepto.
PRUEBA
Esté término prueba se utiliza, para designar
un conjunto de casos y procedimientos de
prueba (Myers, 2004). Las pruebas de un
sistema tienen como objetivo verificar la
funcionalidad del mismo, a través de sus
interfaces externas, y comprobar que dicha
funcionalidad sea la esperada en función de
los requisitos del sistema (Abran y Moore,
2004). En el contexto de desarrollo de
software, la acción de probar es una actividad
en la cual el sistema, o uno de sus
componentes, se ejecutan en escenarios
específicos. Los resultados que arroje esta
ejecución será la prueba que se registrará y
evaluará.
CASO DE PRUEBA
Se entiende como caso de prueba al conjunto
de pruebas de entrada que se aplican bajo
ciertos escenarios desarrollados para un
objetivo, tal como probar una ruta particular
de un programa o verificar el cumplimiento
con un requerimiento específico.
ESCENARIO DE PRUEBA
Son la configuración específica del software
que aborda un proceso de negocio en el
sistema de software. “Los escenarios son
descripciones de ejemplos de las sesiones de
interacción. Cada escenario abarca una o más
posibles interacciones” (Sommerville, 2011, p.
139).
Hay escenarios por tipos de usuario, por
ejemplo: escenario 1, usuario técnico- ,
escenario 2, usuario gerente de contabilidad.
También hay escenarios de acuerdo con los
tipos de pruebas que se realizarán; por
ejemplo, escenario 1, para pruebas
funcionales; el escenario 2, para pruebas de
integración.
3.- Una vez que diste lectura a la metodología RUP (Rational Unified Process), deberás construir un cuadro sinóptico donde organices los
elementos que componen la metodología.
El Rational Unified Process o Proceso Unificado de Racional. Es un proceso de ingeniería de software que suministra un enfoque para asignar
tareas y responsabilidades dentro de una organización de desarrollo. Su objetivo es asegurar la producción de software de alta y de mayor calidad
para satisfacer las necesidades de los usuarios que tienen un cumplimiento al final dentro de un límite de tiempo y presupuesto previsible. Es una
metodología de desarrollo iterativo que es enfocada hacia “diagramas de los casos de uso, y manejo de los riesgos y el manejo de la arquitectura”
como tal.
El RUP mejora la productividad del equipo ya que permite que cada miembro del grupo sin importar su responsabilidad específica pueda acceder
a la misma base de datos incluyendo sus conocimientos. Esto hace que todos compartan el mismo lenguaje, la misma visión y el mismo proceso
acerca de cómo desarrollar un software.
RUP
Metodoogía
Rol
Administrador
de pruebas
Analista de
pruebas
Diseñador de
pruebas
Ejecutor de
Pruebas
Responsabilidad
Responsable el
éxito o fracaso de
la prueba.
Identifica y define
las pruebas
requeridas
Define la estrategia
de pruebas y
asegura su puesta
en práctica
acertadamente
Responsable de
todas las
actividades de las
pruebas
1.- Plan de pruebas
1.- Casos de
pruebas
1.- Plan de
estrategia
2.- Resumen de
resultado de
pruebas
2.-Modelos de
análisis de carga
de trabajo
2.- Arquitectura de
Administración.
1.- Registro de
pruebas
3.- Lista de
problemas y
cambios de
requerimientos.
3.- Datos de
pruebas
3.- Configuración
del entorno de
pruebas
2.- Script de
pruebas
4.- Resultados de
pruebas
4.- Suite de
pruebas
Entregables
Plan de pruebas
Señala el enfoque, los recursos y el esquema de actividades, así como los elementos a probar, las características, el
personal responsable y los riesgos asociados.
Resumen de resultado de pruebas
Resume las actividades y resultados. También contiene una evaluación de los elementos de prueba correspondientes
contra los criterios de salida.
Lista de problemas y cambios de
requerimientos
Casos de pruebas
Entregables
Modelos de análisis de carga de trabajo
Contiene la problemática inherente y los cambios de requerimientos.
Detalla un conjunto de valores de entrada, condiciones previas de ejecución, resultados esperados y las condiciones
posteriores de ejecución desarrollado para un objetivo particular o condición de prueba,
Es la especificación que identifica las variables que afectan al rendimiento del sistema y cómo medir su efecto.
Datos de pruebas
Datos necesarios para ejecutar una prueba, así como lo que afecta o es afectado por el componente o sistema bajo
prueba.
Resultados de pruebas
Reporte de la ejecución de una prueba. Incluye salidas a las pantallas, cambios en los datos, informes y mensajes de
comunicación enviados.
Plan de estrategia
Arquitectura de automatización
Configuración del entorno de pruebas
Suite de pruebas
Registro de pruebas
Script de pruebas
Contiene la estrategia, el tipo y la técnica de prueba a usar.
Testware utilizado en pruebas automatizadas, tales como los scripts.
Documento que describe un proceso de pruebas para determinar la portabilidad de un producto de software.
Conjunto de varios casos para un componente o sistemas bajo prueba, donde la postcondición de una prueba se
utiliza a menudo como una condición previa para la siguiente.
Registro cronológico de los datos pertinentes sobre la ejecución de las pruebas.
Procedimiento de prueba automatizado.
4.- Menciona los pasos que se requieren para la elaboración de un Plan de pruebas.
1
2
Planificación de
la prueba
Diseño de casos
de prueba
3
4
Configuración
de los casos de
prueba
Ejecución de los
casos de
prueba
1. Planificación de la prueba
 Consiste en determinar qué, cómo, cuándo y con qué se va a evaluar.
 Depende del nivel de software.
 Se determina la técnica de prueba de software a utilizar, ya sea de caja blanca o negra.
 Depende de lo que se evaluará, el código o la interfaz del componente o sistema de software.
 Toca entonces diseñar los casos de pruebas.
 Con todo lo anterior, se establece una estrategia de plan de pruebas a aplicar.
5
Evaluación y
cierre
2. Diseño de casos de prueba
 Es un documento que refleja las expectativas de los usuarios. Permite verificar tales expectativas y validarlas. Describe
detalladamente el cómo se llevará a cabo la prueba.
 Elementos que debe cubrir el caso de prueba:
 Caso de uso
 Requerimientos suplementarios
 Requerimientos de configuración.
 Requerimientos de seguridad
 Requerimientos de instalación
3. Configuración de los casos de prueba
 Para llevar a cabo las pruebas se debe configurar, ya sea de forma manual o automatizada a través de un script, un archivo de
órdenes o de procesamiento por lotes.
 Scripts manuales
 Scripts automatizados
4. Ejecución de los casos de prueba
 La ejecución de los casos de pruebas se llevará a cabo por el personal designado para ello y en las fechas que se haya acordado,
según la planificación, y con las herramientas seleccionadas, ya sea de forma manual o automatizada.
 Criterios de evaluación que se deben considerar en la ejecución de los casos de prueba:
 Pruebas unitarias
 Pruebas de sistema
 Pruebas de integración
 Pruebas de regresión
 Pruebas funcionales
 Pruebas de usabilidad
 Pruebas de seguridad
 Pruebas de configuración
 Pruebas de aceptación
 Elementos básicos del Reporte de Pruebas:
 Encabezado: Fecha, correspondiente a, responsable de la verificación.
 Índice
 Resultados de pruebas del sistema: Sistema, requerimientos funcionales, requerimientos no funcionales, planilla resumen
requerimientos no funcionales, interacción en la integración y evaluación.
5. Evaluación y cierre
 Se centra en el reporte final de pruebas de software.
 Este reporte es generado después de que las pruebas de regresión se han aplicado.
 Verifican y validan que los errores encontrados en las diferentes pruebas aplicadas en las diferentes fases de desarrollo del
software se hayan corregido, cerrando efectivamente el proceso de prueba, y liberando al sistema de software para su
implantación.
 Éste último reporte tiene que estar firmado por el cliente, lo que significa que da su visto bueno de que el sistema se entregó en
condiciones óptimas, y con un grado de aceptación de todas las pruebas aplicadas al software.
 Se genera un documento evaluación de las pruebas en general, tiempos, aplicaciones, resultados y lecciones aprendidas.
 Introducción
 Requerimientos de pruebas
 Estrategia de pruebas
 Casos de prueba
 Resultados
5.- Realiza una investigación donde señales nombre y una breve explicación de 3 aplicaciones o herramientas utilizadas para pentesters.
Realizar pruebas de penetración es una tarea compleja, involucra un proceso en donde se realizan distintos tipos de tareas que identifican, en una
infraestructura objetivo, las vulnerabilidades que podrían explotarse y los daños que podría causar un atacante. En otras palabras, se realiza un
proceso de hacking ético para identificar qué incidentes podrían ocurrir antes de que sucedan y, posteriormente, reparar o mejorar el sistema, de
tal forma que se eviten estos ataques.
No.
Nombre de la APP
o Herramienta
Explicación breve de la herramienta.
1
NMAP
En un proceso completo de pruebas de penetración, existen instancias previas a ejecutar esta herramienta pero,
para dar los primeros pasos, probablemente sea la mejor forma de comenzar. Nmap es una herramienta de
escaneo de redes que permite identificar qué servicios se están ejecutando en un dispositivo remoto, así como la
identificación de equipos activos, sistemas operativos en el equipo remoto, existencia de filtros o firewalls, entre
otros.
En palabras sencillas, cuando se va a atacar un servidor o dispositivo, el atacante podrá realizar distintas
arremetidas en función del servicio: no es lo mismo dañar un servidor web, un servidor de base de datos o un
router perimetral. Por lo tanto, en cualquier despliegue, el primer paso será identificar los servicios en la
infraestructura, para decidir cómo avanzar y, considerando que en una prueba de penetración se “imitan” los
pasos de un atacante, también se iniciará de la misma manera.
2
NESSUS
Nmap es una herramienta de línea de comandos (existen algunas interfaces gráficas pero, personalmente, no las
recomiendo, aunque es una cuestión de gustos) donde se debe indicar cuál será el o los objetivos y la serie de
parámetros que afectarán la forma en que se ejecuten las pruebas y los resultados que se obtienen. Puede
instalarse tanto en Linux, Windows, Mac u otros sistemas operativos.
Una vez que se tienen identificados los servicios que se están ejecutando, se puede comenzar el uso de las
herramientas que sirven para identificar vulnerabilidades en los servicios. En este campo, la mejor herramienta
para introducirse en este mundo es Nessus, otra aplicación gratuita (solo para uso hogareño, suficiente para los
fines de este artículo; en el caso de fines profesionales es necesario usar la versión de pago) que, por su base de
datos y su facilidad de uso, es la preferida en este aspecto.
Aunque posee una línea de comandos, considero que su interfaz gráfica, muy completa e intuitiva, es una forma
sencilla de comenzar a probar esta herramienta.
Nessus posee una extensa base de datos de vulnerabilidades conocidas en distintos servicios y, por cada una de
éstas, posee plugins que se ejecutan para identificar si la vulnerabilidad existe (o no) en determinado equipo
objetivo. En resumen, al ejecutarse Nessus sin parámetros específicos, se probarán miles de vulnerabilidades y se
obtendrá como resultado un listado de las vulnerabilidades que fueron identificadas.
3
DVL – DVWA
La lógica de Nessus es similar a Nmap: hay que indicar el objetivo, en este caso la o las direcciones IP y los
parámetros. Estos permiten limitar el campo de búsqueda, especialmente si en una etapa anterior se identificaron
los servicios: no tiene sentido buscar vulnerabilidades conocidas en Linux en un equipo que tiene instalado
Windows.
Para probar las tres herramientas anteriores, es necesario definir un sistema objetivo, un sistema en el que se
harán las pruebas. Una pésima costumbre de quienes inician en este ámbito es realizar sus primeros pasos y
pruebas en sistemas públicos de Internet, en un entorno real. Esto podría acarrear problemas legales y no es la
forma correcta (ni ética) de realizarlo. Para aprender a usar estas herramientas, se debe utilizar un entorno de
pruebas, es decir, un escenario de investigación en donde uno pueda tener acercamientos sin riesgos de afectar
algún entorno en producción.
Para ello, existen dos herramientas excelentes: Damn Vulnerable Linuxy (DVL) y Damn Vulnerable Web Application
(DVWA). Aunque el primero está descontinuado, aún se puede conseguir en Internet para hacer los primeros
pasos y primeras pruebas. Se trata de un sistema operativo y una aplicación web que poseen todo tipo de
vulnerabilidades, de tal forma que, la persona que los utiliza, puede intentar explotarlas y experimentar.
También es posible “construir” nuestro propio sistema de pruebas: tan solo instala cualquier sistema operativo
(desactiva las actualizaciones o instala una versión antigua) y sobre él comienza a instalar servicios en versiones
anteriores a la última. De esta forma, tendrás tu propio sistema vulnerable para hacer pruebas. Este entorno es el
correcto para dar tus primeros pasos en Penetration Testing.
FUENTES DE CONSULTA

Bohem, B., Brown J., Kaspar, H., Lipow M., McLeod G. y Merritt, M. (1978). Characteristics of Software Quality (tomo 1). Cleveland: TRW
Systems and Energy.

Calero, C. et. ál. (2010). Calidad del producto y proceso software. Madrid: RA-MA.

Fowler, M. (2000). UML Distilled, 2a. ed. Boston, MA: Addison Wesley Longman.

Gutiérrez, R. Escalona, C., Mejías, R. y Torres, J. (2006). Generation of Test Cases from Functional Requirements: a Survey. Recuperado de:
http://www.academia.edu/download/48856956/Generation_of_test_cases_from_functional20160915-30060-sybi48.pdf

León, L. (2007). La industria de prueba de software en México. Buenas oportunidades si nos especializamos y crecemos. Recuperado de:
https://sg.com.mx/content/view/369
Descargar