Depuración.Depuración es el nombre genérico dado a todas las acciones queacometemos para encontrar los errores en nuestras aplicaciones.Existen distintas técnicas para efectuar la depuración, dependiendodel entorno en el que desarrollemos y ejecutemos los procesos, asícomo del tipo de acceso permitido a los procesos en ejecución.Aunque los pasos principales se pueden resumir en:

Fijamos puntos de ruptura en lugares críticos del código.Monitorizamos las variables importantes para asegurarnos que susvalores son los correctos.Seguimos la secuencia de ejecución del código para validar el flujoy la lógica de negocio.

Evidentemente, todas estas opciones sólo serán válidas si podemosdisponer de nuestro entorno de desarrollo en los sistemas deexplotación, o bien si disponemos de funcionalidades de depuraciónremota. Ya que, en caso contrario, será imposible efectuar estasacciones, en cuyo caso deberemos utilizar técnicas de seguimientoque nos permitan introducir código para registrar eventosanalizables en tiempo de ejecución desde herramientas externas.

Para ello disponemos de las clases del sistemaSystem.Diagnostics.Trace y System.Diagnostics.Debug quenos permiten monitorizar los procesos mientras se están ejecutando,recolectando y analizando toda aquella información que nos parezcaoportuna desde la ventana de output (en depuración), cualquier log,archivo de texto o dispositivo que especifiquemos (en ejecución).Las fases habituales del proceso son:

Instrumentación: la adición de los rastreos en el código.Tracing: la ejecución de la aplicación y, por ende, la recolección de lainformación indicada.Análisis: la evaluación de la información recogida durante la ejecuciónpara identificar y evaluar los problemas.

Miembro Descripción

Assert Muestra un mensaje cuando una condición es falsa

Close Vacía el buffer de salida y cierra los listeners.

Fail Emite un determinado mensaje de error

Flush Vacía el buffer de salida

Indent Aumenta el nivel de sangría en una unidad

TraceError Escribe información a los listeners

Consideraciones para el uso de TraceCuando estemos escribiendo sentencias Trace o Debugdebemos tener presente cómo queremos que se muestre lasalida.

Escritura de línea completa:WriteLine o WriteLineIf.

Escritura parcial de línea:Write o WriteIf.

Verificar que se cumpla una condición:Assert.

Los switchs del Trace, que van en el archivo deconfiguración, nos permiten controlar el comportamiento delrastreo en ejecución.BooleanSwitch, activar o no el Trace.TraceSwitch , con varios niveles para indicar que mensajes seemiten.SourceSwitch con varios niveles, lo veremos más adelante.

[C#]

BooleanSwitch dataSwitch =

new BooleanSwitch("Data", "DataAccess module");

TraceSwitch generalSwitch =

new TraceSwitch("General", "Entire application");

[VB]

Dim dataSwitch As New BooleanSwitch ("Data", "DataAccess

module")

Dim generalSwitch As New TraceSwitch ("General", "Entire

application")

Creación de un SwitchPara utilizar un Switch para Trace, primero deberemoscrearlo en el código y añadir, después, en el archivo deconfiguración los valores requeridos para el funcionamientodeseado. De esta forma, no será necesario modificar el fuenteni recompilar para cambiar el funcionamiento.

<system.diagnostics>

<switches>

<add name=“dataSwitch" value="0" />

<add name=“generalSwitch" value="0" />

</switches>

</system.diagnostics>

Configuración del SwitchCuando compilamos nuestra aplicación debemos decidir siqueremos que las sentencias de Debug y Trace estén o noincluidas, debiendo seleccionar las correspondientes opcionesde compilación, en función del tipo de la misma, en la ventanade propiedades, en caso contrario, no se incluirán.Una vez desplegada la aplicación, podremos activar odesactivar la salida, o modificar el comportamiento de lamisma, mediante el archivo de configuración y el reinicio de laaplicación o el uso del método Refresh de la clase Trace.

Trace ListenersLos listeners vienen a ser delegados encargados de recibir losmensajes que nuestra aplicación genere y emitirlos hacia eldispositivo de salida correspondiente.Hay listeners definidos para las clases Debug, Trace yTraceSource, todos ellos con la posibilidad de enviar losmensajes a distintos dispositivos de salida.Los predefinidos del sistema son:DefaultTraceListener el cual envía los mensajes hacia losmétodos OutputDebugString y Debugger.Log , lo que setraduce en la ventana de salida en Visual Studio. Este es el únicoque se incluye automáticamente en todas las colecciones delisteners.TextWriterTraceListener envía la salida hacia una instancia dela clase TextWriter o cualquier clase de tipo Stream (archivos,consola, …).EventLogTraceListener redirecciona la salida hacia un log deeventos.ConsoleTraceListener envía la salida hacia la salida estándar(Console.Out) o (Console.Error)

[C#]

Trace.Listeners.Add(new TextWriterTraceListener(Console.Out));

[VB

Trace.Listeners.Add(New TextWriterTraceListener(Console.Out))

DelimitedListTraceListener envía la salida hacia un textwriter, como un stream writer o hacia un stream, como un filestream. El formato de salida del trace es el de un textodelimitado.XmlWriterTraceListener envía la salida con formato de datosXML hacia un text o un stream writer.

Las clases Debug y Trace disponen de una colección delisteners en la que el sistema coloca, por defecto, unDefaultTraceListener, para usar cualquier otro, lo habremosde añadir a esta colección.Todos los listeners recibirán el mismo mensaje y seencargarán de re-enviarlo cada uno al dispositivo especificado.

[C#]

static TraceSource ts = new TraceSource("TraceTest");

[VB]

Private Shared ts As New TraceSource("TraceTest“)

Además de las clases ya vistas, el sistema nos suministra laclase TraceSource, la cual amplía las funcionalidadesdisponibles con un mayor nivel de detalle, muy útil en lasaplicaciones por capas características del entorno .NET.Algunas de las funcionalidades específicas de esta clase son:

Se puede utilizar esta clase para diferenciar los orígenes y destinosde los mensajes de Trace.Switches, se usan de una forma similar a la clase Trace, siendo elSourceSwitch el más común.Se dispone del acceso a los mismos listeners que las otras clases.Se pueden añadir filtros a los listeners, con los cuales determinarque eventos se desean procesar,de resultas podremos enviar lasalida de cada tipo de evento a un dispositivo diferente.

Recomendaciones practicas:Asegurémonos de que la parametrización de las trazas ydepuración son configurables desde fuera del código.Suministremos siempre un método para desactivartotalmente estas funcionalidades.Para grandes proyectos es recomendable el uso de la claseTraceSource en lugar de la Trace, por la funcionalidad dediferenciar orígenes y destinos de los mensajes.Desactivemos la traza y control de errores, sobre todo enaplicaciones en ASP.NET, antes del pase a explotación de lasaplicaciones, para evitar revelar información interna aterceros.Incluyamos siempre información complementaria, como lafecha y hora, en los mensajes de traza, para facilitar elseguimiento y análisis.Asegurémonos de que el código asociado a la traza nomodifica la información de las variables de la aplicación.

Perfilado (profiling) de aplicaciones.Se conoce como perfilado o remate de aplicaciones al procesomediante el cual, una vez completado el desarrollo,rematamos temas de rendimiento, uso de recursos yoptimización de código y bucles.Para ello nos centraremos en:

Mejorar el uso de memoria de la aplicación.Optimizar aquél código que se usa con mayor frecuencia.Obtener información visual de la aplicación para detectar lospuntos de conflicto.Optimizar los bucles.

Las herramientas que, a tal fin, nos proporciona Microsoftson:CLR Profiler: descarga gratuita que nos permite perfilar las

aplicaciones mediante el acceso al uso de memoria y del GarbageCollector.

Performance Explorer: parte del IDE de Visual Studio 2008.

CLR Profiler.

Es una herramienta que permite que los desarrolladorestengan una visión del uso que realiza su aplicación de lamemoria y del proceso de recolección de basura.

Es una herramienta muy útil, que se ejecuta desde fuera delIDE de Visual Studio, como aplicación de ventana o línea decomandos, pero muy pesada, puede hacer que una aplicacióncorra hasta 100 veces más lenta de lo habitual.

La información recogida, de aplicaciones Windows Forms,ASP.NET o servicios de Windows, se almacena en logs quepueden ser posteriormente analizados desde las múltiplesvistas de las que dispone la propia herramienta.

Instrumentación.Son los mecanismos utilizados para generar informaciónsobre el estado del sistema, tanto en cuanto al hardwarecomo al software.Nos da la habilidad de monitorizar o medir el rendimiento deuna aplicación y diagnosticar errores, una vez puesta enexplotación, lo cual, sobre todo en aplicaciones distribuidas,puede llegar a ser bastante complicado.

Pasos:Se debe planificar cuidadosamente la instrumentación en lafase de diseño : qué, cuándo, dónde y porqué deberá sermedido.Habrá que decidir cuáles son los requerimientos demonitorización y soporte.Se deberá establecer una política de instrumentaciónadecuada.

Tecnologías para la Instrumentación en Visual Studio 2008.

Tecnología Descripción

Traza de código Nos permite controlar las aplicaciones en ejecución.

Contadores de rendimiento

Son componentes de las aplicaciones, servicios y dispositivos que nos permiten publicar, capturar y analizar los datos de rendimiento.

Registro de eventos

Son una herramienta que nos proveen de un lugar centralizado en el que registrar eventos de 3 categorías: aplicación, sistema y seguridad.

Windows Management Instrumentation(WMI)

Juego de componentes de System.Management para gestionar aplicaciones distribuidas. Queda fuera del ámbito de este curso.

Bloques de aplicación

Para registro de eventos e instrumentación, componente de las guías y prácticas de la librería Microsoft para empresas. Fuera del ámbito de este curso.

Registro de eventos (logging).

El componente EventLog nos permite registrar los eventosque se produzcan durante el ciclo de vida de nuestrasaplicaciones, para poder visualizarlos y analizarlos mediantela herramienta Event Log Viewer de los sistemas operativosWindows o mediante el Server Explorer de Visual Studio2008.

Podemos utilizar los logs predefinidos delsistema, System, Security y Application, o crear losnuestros propios, con CreateEventSource, para registrar loseventos de las categoríasErrors, Warnings, Information, Succes Audits y FailureAudits.

Un componente EventLog sólo puede registrar los eventos enun único registro a la vez.

Registro de eventos (logging).

Guías para el registro de eventos.

Guía Motivo

Registrar sólo información esencial.

Consume recursos del sistema, como espacio en disco y tiempo de procesador

Situar los registros en el código gestor de errores en vez de en el flujo principal del código de la aplicación

Para evitar una reducción en el rendimiento

Utilizar el registro de eventos para identificar y resolver problemas de recursos, como las carencias de memoria.

Registrar los eventos del tipo identificación de usuarios, accesos a base de datos y transferencias de archivos.

[C#]

if (!EventLog.SourceExists("MyApp1"))

EventLog.CreateEventSource("MyApp1", "Application");

EventLog1.Source = "MyApp1";

EventLog1.WriteEntry("Ejemplo de evento registrado.");

[VB]

If Not EventLog.SourceExists("MyApp1") Then

EventLog.CreateEventSource("MyApp1", "Application")

End If

EventLog1.Source = "MyApp1"

EventLog1.WriteEntry("Ejemplo de evento registrado.")

Cómo efectuar el registro de eventos (logging).Crear una instancia de registro de eventos:

Localizar el registro deseado en Server Explorer.Arrastrar un componente Event Log desde la pestañacomponentes de la caja de herramientas.Crear una instancia por código.

Para escribir una entrada en un registro de eventos:

Acceso a los registros de eventos desde código.El usuario bajo el que esté corriendo la aplicación condicionael acceso que la misma tenga a los registros de eventos:

Las cuentas de usuarios de Windows tienen acceso, pordefecto, a los registros de eventos.Las cuentas de usuario de ASP.NET no pueden crearcategorías, pero si añadir a los registros existentes.

Registro Cuenta Read Write Clear

Application LocalSystem X X X

Administrator X X X

ServerOp X X X

Usuarios X X

Security LocalSystem X X X

Administrator X X

Usuarios

System LocalSystem X X X

Administrator X X X

ServerOp X X

Usuarios X

Pruebas de software.A estas alturas no debería ser necesario recalcar laimportancia de las pruebas que hemos de realizar sobre todoel software que desarrollemos, ya que dichas pruebas soncada día más necesarias dada la creciente complejidad de losproyectos que se implantan.Los objetivos de las pruebas de software son:

Localizar y solucionar los errores antes del pase aexplotación.Verificar que se cumplan los requerimientos del proyecto.Reducir futuros costes a la compañía debidos a errores enel código.

Las consecuencias realizar pruebas inadecuadas son:Incremento de los costes para la compañía.Daños en la reputación de la empresa.Vulnerabilidades de seguridad en el software.Retrasos en la entrega del proyecto.

Tipos de software de prueba.

Tipo Descripción

Unitario Se usan casos de prueba para validar elementos individuales de código, típico de desarrollador.

Integración Se prueban funcionalidades completas para verificar que trabajan conjuntamente.

Carga O de rendimiento, utiliza grandes paquetes de datos o ejecuciones para validar el comportamiento bajo cargas extremas.

Regresión Se repiten ciclos ya probados, de forma automatizada, para validar los cambios efectuados.

Aceptación Valida el desarrollo contra los requerimientos iniciales para validar el correcto desarrollo de la funcionalidad.

Sistema Utiliza sistemas black-box para validar las aplicaciones desde el punto de vista de las especificaciones de sistema.

Punta a punta

Se utilizan escenarios del mundo real para validar las aplicaciones completas, similar al tipo Sistema.

Tipos de software de prueba.

Black-Box:

Son los tipos de pruebas en las que se prueban lasfuncionalidades a ciegas del código desarrollado. Se aplica atodos los niveles del desarrollo, unitario, integración,sistema y aceptación.

White-Box:

En cambio, se basa precisamente en el conocimiento deldesarrollo realizado y la prueba de la estructura interna delmismo. Se aplica en algunos de los niveles del desarrollo:unitario, integración y sistema, aunque lo normal esaplicarlo al nivel de prueba unitaria.

Herramientas de prueba de Visual Studio y Team System

Herramienta Descripción VS TS

Object Test Bench

Pruebas sencillas a nivel de objeto. X X

Unit Testing Para validar métodos específicos. X X

Code Analysis Análisis del cumplimiento de reglasde diseño y programación.

- X

Code Metrics Actúa sobre áreas complejas. - X

Code Coverage Controla la ejecución de cada línea. - X

Load Testing Simulación de muchas operaciones. - X

Manual Testing Realizado por una persona al no poder lanzar procesos automáticos.

- X

Web Testing Serie de peticiones http para validar rendimiento de las aplicaciones ASP.NET

- X

Buenas prácticas en pruebas de software:No crear dependencias entre diferentes pruebas, que nodependan unas de otras en cuanto al orden de ejecución.Generar y ejecutar código de inicialización de las pruebas,para asegurar un escenario limpio y volver a ejecutar en elcaso de error en anterior ejecución.Preparar los ciclos de pruebas antes de iniciar el desarrollodel software propiamente dicho.Se debe crear, al menos, una clase de pruebas para cadaclase del código a probar, esto simplifica el proceso yfacilita el saber dónde colocar cada prueba.Utilice Visual Studio para generar el proyecto inicial depruebas, lo cual reducirá significativamente el número depasos necesarios para prepara el proyecto de pruebas yasociarlo al proyecto de desarrollo.Evítese la creación de pruebas dependientes de rutasconcretas y mucho menos a otras máquinas.

Buenas prácticas en pruebas de software:Se deben crear falsos objetos para las pruebas deinterfaces, los cuales nos permitirán validar que las APIscumplan con los requerimientos.Se debe verificar que todos las pruebas se ejecutancorrectamente antes de pasar a la creación de un nuevociclo de pruebas, así nos aseguraremos de solucionar losproblemas que hayamos descubierto en el código, en elmomento en que los hayamos detectado.Debemos generar el máximo número de ciclos de pruebasautomáticos posible. Asegurémonos de que no hayposibilidades de ejecución desatendida de pruebas antes deforzar una ejecución manual. Nos aseguraremos de unaspruebas imparciales y que no dependerán del estado deatención del ejecutante.