1. 17.8 El arte de la depuración
1.1. 17.8.1
1.1.1. Ocurre en consecuencia de una prueba
1.1.2. Se ejecuta un caso de prueba y se analizan los resultados para encontrar una falta de correspondencia entre el rendimiento esperado y el real.
1.1.3. El proceso de depuración dará como resultado que: 1) la causa se encontrará y corregirá 2) la causa no se encontrará. En este caso, se puede asumir una causa, diseñar un caso de prueba para auxiliarse en la validación de dicha suposición y trabajar hacia la corrección del error en forma iterativa.
1.1.4. ¿Por qué es tan difícil la depuración?
1.1.4.1. El síntoma y la causa pueden ser geográficamente remotos.
1.1.4.2. El síntoma puede desaparecer (temporalmente) cuando se corrige otro error.
1.1.4.3. El síntoma en realidad puede no ser causado por errores (por ejemplo, imprecisiones de redondeo
1.1.4.4. 4. El síntoma puede ser causado por un error humano que no se rastrea con facilidad.
1.1.4.5. 5. El síntoma puede ser resultado de problemas de temporización más que de problemas de procesamiento
1.1.4.6. Puede ser difícil reproducir con precisión las condiciones de entrada (por ejemplo, una aplicación en tiempo real en la que el orden de la entrada esté indeterminado).
1.1.4.7. Puede ser difícil reproducir con precisión las condiciones de entrada (por ejemplo, una aplicación en tiempo real en la que el orden de la entrada esté indeterminado).
1.1.4.8. El síntoma puede deberse a causas que se distribuyen a través de algunas tareas que corren en diferentes procesadores
1.2. 17.8.2
1.2.1. Algunas personas son mejores que otras en el proceso de depuración
1.3. 17.8.3
1.3.1. El objetivo de la depuración es encontrar y corregir la causa de un error o defecto de software.
1.3.2. Tácticas de depuración
1.3.2.1. fuerza bruta
1.3.2.1.1. se aplican cuando todo lo demás falla.
1.3.2.2. vuelta atrás
1.3.2.2.1. comenzar en el sitio donde se descubrió un síntoma, el código fuente se rastrea hacia atrás hasta que encontrar la causa.
1.3.2.3. eliminación de la causa
1.3.2.3.1. se manifiesta mediante inducción o deducción, e introduce el concepto de partición binaria
1.3.3. depuración automatizada
1.4. 17.8.4
1.4.1. ¿La causa del error se reproduce en otra parte del programa?
1.4.2. ¿Qué siguiente error puede introducirse con la corrección que está a punto de realizar?
1.4.3. ¿Qué debió hacerse para evitar este error desde el principio?
2. 17.7 Pruebas del sistema
2.1. Anticipar problemas
2.1.1. Participar en planeacion y diseno de pruebas del sistema para garantizar que el sistema se prueba correctamente
2.1.2. Registrar resultados de las pruebas como evidencia
2.1.3. Realziar pruebas que simulen los datos malos o posibles errores
2.1.4. Rutas de manejo de error que prueben toda la info que viene de otros elementos del sistema
2.2. La recuperacion es un tipo de prueba que forza al software a fallar en varias formas y que verifica que se recupere de forma adecuada
2.2.1. Muchos sistemas basados en computadora deben recuperarse de fallas y reanudar el procesamiento con poco o ningún tiempo de inactividad. En algunos casos, un sistema debe ser tolerante a las fallas, es decir, las fallas del procesamiento no deben causar el cese del funcionamiento del sistema global.
2.2.2. En otros casos, la falla de un sistema debe corregirse dentro de un periodo de tiempo específico u ocurrirán severos daños económicos.
2.2.3. La recuperación es una prueba del sistema que fuerza al software a fallar en varias formas y que verifica que la recuperación se realice de manera adecuada.
2.2.4. Si la recuperación es automática (realizada por el sistema en sí), se evalúa el reinicio, los mecanismos de puntos de verificación, la recuperación de datos y la reanudación para correcciones.
2.2.5. Si la recuperación requiere intervención humana, se evalúa el tiempo medio de reparación (TMR) para determinar si está dentro de límites aceptables.
2.3. Pruebas de Seguridad
2.3.1. Cualquier sistema basado en computadora que gestione información sensible o cause acciones que puedan dañar (o beneficiar) de manera inadecuada a individuos es un blanco de penetración inadecuada o ilegal.
2.3.2. La penetración abarca un amplio rango de actividades: hackers que intentan penetrar en los sistemas por deporte, empleados resentidos que intentan penetrar por venganza, individuos deshonestos que intentan penetrar para obtener ganancia personal ilícita.
2.3.3. La prueba de seguridad intenta verificar que los mecanismos de protección que se construyen en un sistema en realidad lo protegerán de cualquier penetración impropia.
2.3.4. “La seguridad del sistema debe, desde luego, probarse para ser invulnerable ante ataques frontales; pero también debe probarse su invulnerabilidad contra ataques laterales y traseros.”
2.4. Pruebas de Esfuerzo
2.4.1. Los primeros pasos de la prueba del software dieron como resultado una evaluación extensa de las funciones y el rendimiento normales del programa. Las pruebas de esfuerzo se diseñan para enfrentar los programas con situaciones anormales. En esencia, la persona que realiza las pruebas de esfuerzo pregunta: “¿cuánto podemos doblar esto antes de que se rompa?”.
2.4.2. La prueba de esfuerzo ejecuta un sistema en forma que demanda recursos en cantidad, frecuencia o volumen anormales.
2.4.3. Por ejemplo, pueden:
2.4.3.1. 1) diseñarse pruebas especiales que generen diez interrupciones por segundo, cuando una o dos es la tasa promedio
2.4.3.2. 2) aumentarse las tasas de entrada de datos en un orden de magnitud para determinar cómo responderán las funciones de entrada
2.4.3.3. 3) ejecutarse casos de prueba que requieran memoria máxima y otros recursos
2.4.3.4. 4) diseñarse casos de prueba que puedan causar thrashing (que es un quebranto del sistema por hiperpaginación) en un sistema operativo virtual
2.4.3.5. 5) crearse casos de prueba que puedan causar búsqueda excesiva por datos residentes en disco. En esencia, la persona que realiza la prueba intenta romper el programa
2.4.4. Pruebas de Rendimiento
2.4.4.1. Las pruebas de rendimiento con frecuencia se aparean con las pruebas de esfuerzo y por lo general requieren instrumentación de hardware y de software, es decir, con frecuencia es necesario medir la utilización de los recursos (por ejemplo, ciclos del procesador) en forma meticulosa.
2.4.4.2. La instrumentación externa puede monitorear intervalos de ejecución y eventos de registro (por ejemplo, interrupciones) conforme ocurren, y los muestreos del estado de la máquina de manera regular. Con la instrumentación de un sistema, la persona que realiza la prueba puede descubrir situaciones que conduzcan a degradación y posibles fallas del sistema.
2.4.5. Pruebas de Despliegue
2.4.5.1. En muchos casos, el software debe ejecutarse en varias plataformas y bajo más de un entorno de sistema operativo. La prueba de despliegue, en ocasiones llamada prueba de configuración, ejercita el software en cada entorno en el que debe operar.
3. 17.6 Pruebas de validación
3.1. Comienzan al terminarse las pruebas de integración, cuando e software está completamente ensamblado como un paquete y los errores de interfaz se descubrieron corrigieron.
3.2. La validación es exitosa cuando el software funciona en una forma que cumpla con las expectativas razonables del cliente.
3.3. Criterios de pruebas de validación
3.3.1. La validación del software se logra a través de una serie de pruebas que demuestran conformidad con los requerimientos
3.3.2. Se diseñan casos de prueba para garantizar que: se satisfacen todos los requerimientos de funcionamiento, se logran todas las características de comportamiento, todo el contenido es preciso y se presenta de manera adecuada, se logran todos los requerimientos de rendimiento, la documentación es correcta, etc
3.4. Revisión de la configuración
3.4.1. Su intención es garantizar que todos los elementos de la configuración del software se desarrollaron de manera adecuada, y que se cataloga y se tiene el detalle necesario para reforzar las actividades de apoyo.
3.5. Pruebas alfa y beta
3.5.1. La prueba alfa se lleva a cabo en el sitio del desarrollador por un grupo representativo de usuarios finales. El software se usa en un escenario natural con el desarrollador “mirando sobre el hombro” de los usuarios y registrando los errores y problemas de uso. Las pruebas alfa se realizan en un ambiente controlado.
3.5.2. La prueba beta se realiza en uno o más sitios del usuario final. A diferencia de la prueba alfa, por lo general el desarrollador no está presente. Por tanto, la prueba beta es una aplicación “en vivo” del software en un ambiente que no puede controlar el desarrollador.
4. 17.1 Un enfoque estratégico para la prueba de software
4.1. 17.1.1
4.1.1. La verificación contesta a la pregunta: ¿Construimos el producto correctamente?
4.1.2. La validación responode a la pregunta: ¿Construimos el producto correcto?
4.1.3. Las pruebas no deben verse como una red de seguridad. La calidad se incorpora en el software a lo largo de todo el proceso de ingeniería del software. La adecuada aplicación de métodos y herramientas conducen a la calidad que se confirma durante las pruebas.
4.2. 17.1.2
4.2.1. Usualmente el desarrolador actuará con cuidado, y diseñará y ejecutará pruebas que demostrarán que el programa funciona, en lugar de descubrir errores. Desafortunadamente, los errores estarán presentes. Y si el ingeniero de software no los encuentra, eventualmente, el cliente lo hará.
4.2.2. Interpretaciones incorrectas
4.2.2.1. Que el desarrollador de software no debe hacer pruebas en absoluto
4.2.2.2. Que el software debe “ponerse tras una pared” que lo separe de los extraños que lo probarán sin misericordia
4.2.2.3. Que quienes realicen las pruebas deben involucrarse con el proyecto sólo cuando los pasos de las pruebas estén por comenzar
4.2.3. Grupo de Prueba Independiente (GPI)
4.2.3.1. El desarrollador y el GPI deben trabajar de manera cercana para que el desarollador pueda arreglar los errores que se descubran
4.2.3.2. El GPI es parte del equipo del proyecto, pero puede reportar a la organización de aseguramiento de calidad del software para lograr un mayor grado de independencia.
4.3. 17.1.3
4.3.1. Para poder hacer una buena prueba de software es necesario establecerla por pasos los cuales tienen cada uno de ellos su propio proposito. Lo primero que hay que hacer es probar por unidad, osea por funcionalidades especificas. Despues es necesario probar la integracoion de todas esas unidades. Y al final, ver que el sistema cumpla con su proposito inicial
4.4. 17.1.4
4.4.1. Para poder contestar a la pregunta de ¿Cuando hay que dejar de realizar pruebas?, hay varias maneras de ver a la contestacion. La primera es que es que una vez dado por visto bueno las pruebas ya pasan directamente al consumidor, otra es aplicar un modelo de tecnicas estadisticas llamado kel00, el cual ejecuta serie de pruebas derivadas de una muestra estadística de todas las posibles ejecuciones de programa por parte de todos los usuarios de un población objetivo. Por lo que realmente no hay una respuesta en concreto
5. 17.5 Estrategias de prueba para webapps
5.1. La estrategia para probar webapps adopta los principios básicos para todas las pruebas de software y aplica una estrategia y tácticas que se usan para sistemas orientados a objetos.
5.2. Los siguientes pasos resumen el enfoque:
5.2.1. El modelo de contenido para la webapp se revisa para descubrir errores.
5.2.2. El modelo de interfaz se revisa para garantizar que todos los casos de uso pueden adecuarse.
5.2.3. El modelo de diseño para la webapp se revisa para descubrir errores de navegación.
5.2.4. La interfaz de usuario se prueba para descubrir errores en los mecanismos de presentación y/o navegación.
5.2.5. A cada componente funcional se le aplica una prueba de unidad.
5.2.6. Se prueba la navegación a lo largo de toda la arquitectura.
5.2.7. La webapp se implementa en varias configuraciones ambientales diferentes y se prueba en su compatibilidad con cada configuración.
5.2.8. Las pruebas de seguridad se realizan con la intención de explotar vulnerabilidades en la webapp o dentro de su ambiente.
5.2.9. Se realizan pruebas de rendimiento.
5.2.10. La webapp se prueba mediante una población de usuarios finales controlada y monitoreada. Los resultados de su interacción con el sistema se evalúan por errores de contenido y navegación, preocupaciones de facilidad de uso, preocupaciones de compatibilidad, así como confiabilidad y rendimiento de la webapp.
6. 17.2 Aspectos estratégicos
6.1. Los que prueban el software deben de:
6.1.1. Especificar los requerimientos de forma cuantificable antes de comenzar con las pruebas
6.1.2. Establecer claramente los objetivos de las pruebas
6.1.3. Entender a todo tipo de usuarios y desarrollar un perfil para cada uno
6.1.4. Desarrollar el plan de prueba enfatizando las pruebas de ciclo rapido
6.1.5. Construir un software robusto diseñado para probarse a si mismo
6.1.6. Realizar revisiones tecnicas para valorar la estrategia y los casos de prueba
6.1.7. Desarrollar un enfoque de mejora continua para el proceso de prueba
7. 17.4 Estrategias de prueba para software orientado a objeto
7.1. Prueba de Unidad en el Contexto OO
7.1.1. Cuando se considera software orientado a objeto, el concepto de unidad cambia. La encapsulación determina la definición de clases y objetos.
7.1.2. Esto significa que cada clase y cada instancia de una clase empaqueta los atributos (datos) y las operaciones que manipulan estos datos.
7.2. Prueba de Integración en el Contexto de OO
7.2.1. Existen dos estrategias diferentes para la prueba de integración de los sistemas OO.
7.2.1.1. La primera, la prueba basada en hebra, integra el conjunto de clases requeridas para responder a una entrada o evento para el sistema. Cada hebra se integra y prueba de manera individual. La prueba de regresión se aplica para asegurar que no ocurran efectos colaterales.
7.2.1.2. El segundo enfoque de integración, la prueba basada en uso, comienza la construcción del sistema al probar dichas clases (llamadas clases independientes) que usan muy pocas clases servidor (si es que usan alguna).
8. 17.3 Estrategias de prueba para software convencional
8.1. Prueba de unidad
8.1.1. enfoca los esfuerzos de verificación en la unidad más pequeña del diseño de sw: componente o módulo de sw
8.1.2. Consideraciones de las pruebas de unidad
8.1.2.1. La interfaz del módulo se prueba para garantizar que la info. fluya hacia y desde la unidad de sw. que se está probando.
8.1.2.2. Las estructuras de datos locales se examinan para asegurar la integridad de datos en todos los pasos del algoritmo
8.1.2.3. Las condiciones de frontera se prueban para asegurar que el módulo opera adecuadamente en las fronteras para limitar el procesamiento
8.1.2.4. Se ejercitan todas las rutas independientes para asegurar que todos los estatutos en un módulo se ejecuten al menos una vez
8.1.2.5. Se ponen a prueba todas las rutas para el manejo de errores
8.1.3. Procedimientos de prueba de unidad
8.1.3.1. El diseño de las pruebas de unidad puede ocurrir antes de comenzar la codificación o después de generar el código fuente
8.1.3.1.1. Proporciona una guía para establecer casos de prueba que es probable que descubran errores.
8.2. Pruebas de integración
8.2.1. Integración descendente
8.2.1.1. Es un enfoque incremental a la construcción de la arquitectura de software
8.2.2. Integración ascendente
8.2.2.1. Comienza la construcción y la prueba con módulos atómicos (componentes en los niveles inferiores dentro de la estructura del programa)
8.2.3. Prueba de regresión
8.2.3.1. Cada que se agrega un nuevo módulo como parte de las pruebas de integración, el software cambia
8.2.4. Prueba de humo
8.2.4.1. Se usa cuando se desarrolla software de producto. Se diseña como un mecanismo de ritmo para proyectos críticos en el tiempo, pues valora el proyecto de manera frecuente
8.2.5. Opciones estratégicas
8.2.5.1. La selección de una estrategia de integración depende de las características del sw y del calendario del proyecto
8.2.6. Productos de trabajo de las pruebas de integración
8.2.6.1. Especificación de pruebas
8.2.6.1.1. Plan global para integración del software y una descripción de las pruebas específicas
8.2.6.2. Reporte de prueba
8.2.6.2.1. Se registra una historia de resultados, problemas o peculiaridades de pruebas reales