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
