Compartir a través de

Monitor de modo de usuario

El Monitor de modo de usuario permite a las pruebas obtener más contexto sobre la ejecución del "proceso sometido a prueba" con el fin de obtener más contexto para investigar errores de prueba o para habilitar una mejor comprobación a partir de pruebas existentes. La implementación actual del Monitor de modo de usuario proporciona una implementación básica, con más personalización y configuración en versiones posteriores.

Introducción

El Monitor de modo de usuario (UMM) usa la API de Windows de bajo nivel para recibir notificaciones de todos los eventos de "depurador" que se originan en un proceso determinado: inicio y detención del subproceso, carga del módulo, bloqueos y excepciones controladas por nombrar solo unos pocos. Al recibir un evento del depurador, el código UMM puede realizar una de varias acciones, incluidos los comentarios de registro, los errores de registro (con el fin de producir un error en una prueba) o incluso tomar un minivolcado del proceso sometido a prueba.

Habilitación del Monitor de modo de usuario

Para habilitar UMM para un caso de prueba determinado, debe proporcionar dos partes de configuración:

  1. La prueba debe marcarse con el valor de metadatos "ProcessUnderTest". Esto permite al UMM identificar el proceso que se está probando.
  2. La línea de comandos Te.exe debe incluir "/userModeMonitor" para activar la funcionalidad UMM.

Se deben tener en cuenta los siguientes puntos al usar el código UMM;

  1. Si hay varias instancias del proceso con nombre en ejecución de prueba, se usará la instancia que se detecta primero.
  2. El usuario que ejecuta la automatización de pruebas debe tener el permiso suficiente para recibir eventos del depurador del proceso sometido a prueba.
  3. El código UMM se "asociará" al proceso sometido a prueba después de que se hayan ejecutado todos los accesorios de instalación y "desasociar" antes de que se ejecuten los accesorios de limpieza. Esto permite que los accesorios de configuración de una prueba inicien el proceso sometido a prueba y realicen cualquier inicialización necesaria para prepararse para la prueba.

Monitor de modo de usuario admitido "Acciones"

El Monitor de modo de usuario tiene un conjunto de "Acciones" que puede tomar cuando se produce un evento de depurador determinado en el proceso supervisado. En la implementación actual, un evento determinado solo invocará su acción predeterminada; actualmente no hay compatibilidad con la configuración.

Acción Descripción
LogComment Agrega un comentario al registro, con información contextual del evento.
LogError Registra un error en el registro, que producirá un error en la prueba actual.
Minivolcado Escribe un minivolcado y lo guarda en el registro.
Ignore No hace nada.

Monitor de modo de usuario admitido "Eventos"

El Monitor de modo de usuario muestra "eventos" que pueden aplicar una de las "acciones" enumeradas anteriormente. En la tabla siguiente se muestra la lista actual de eventos notificados, junto con la acción predeterminada que se realizará cuando se reciba el evento.

Evento Acción predeterminada (acción predeterminada de segunda oportunidad)
Crear subproceso Ignore
Salir del subproceso Ignore
Crear proceso Ignore
Proceso de salida LogError
Carga del módulo LogComment
Descarga del módulo Ignore
Error de sistema Ignore
Punto de interrupción inicial LogError
Carga inicial del módulo Ignore
Salida de depuración LogComment
Infracción de acceso LogError (LogError)
Error de aserción LogError (LogError)
Bloqueo de la aplicación LogError (LogError)
Excepción de instrucción break LogError
Interrupción de la excepción de instrucción continue Ignore
Excepción eh de C++ LogError (LogError)
Excepción CLR LogError (LogError)
Excepción de notificación clR LogError (Omitir)
Control-LogError excepción LogError
Control-LogError excepción continuar Ignore
Excepción de Control-C LogError
Excepción control-C continue Ignore
Datos mal alineados LogError (LogError)
Excepción de comando del depurador Ignore
Infracción de página de protección LogError (LogError)
Instrucción no válida LogError (LogError)
Error de E/S en la página LogError (LogError)
División de enteros por cero LogError (LogError)
Desbordamiento entero LogError (LogError)
Manipulador no válido LogError
Continuar con el identificador no válido LogError
Secuencia de bloqueo no válida LogError (LogError)
Llamada del sistema no válida LogError (LogError)
Puerto desconectado LogError (LogError)
Bloqueo del servicio LogError (LogError)
Excepción de paso único LogError
Continuación de la excepción de paso único Ignore
Desbordamiento de búfer de pila LogError (LogError)
Stack Overflow LogError (LogError)
Detención del comprobador LogError (LogError)
Excepción de Visual C++ Omitir (Omitir)
Depurador de reactivación LogError (LogError)
Punto de interrupción WOW64 LogError (Omitir)
Excepción de paso único wow64 LogError (Omitir)
Otra excepción LogError (LogError)

Ejemplo

Para ilustrar el uso de la funcionalidad de UMM, echemos un vistazo a un ejemplo (ligeramente contrived) de una prueba que automatiza "MSPaint":

namespace UserModeMonitorExample
{
    using System;
    using System.Diagnostics;
    using System.Threading;
    using Microsoft.VisualStudio.TestTools.UnitTesting;
    using WEX.Logging.Interop;
    using WEX.TestExecution;

    [TestClass]
    public class BasicExample
    {
        [TestInitialize]
        public void TestInitialize()
        {
            Process[] runningPaintInstances = Process.GetProcessesByName("mspaint.exe");

            Verify.IsTrue(runningPaintInstances.Length == 0, "There are no running instances of mspaint.exe");

            this.mspaintUnderTest = Process.Start("mspaint.exe");
        }

        [TestCleanup]
        public void TestCleanup()
        {
            // Close the 'mspaint under test' - if it's already gone, this will throw, but that's no big deal.
            this.mspaintUnderTest.CloseMainWindow();
        }

        [TestMethod]
        [TestProperty("ProcessUnderTest", "mspaint.exe")]
        [TestProperty("Description", "Shows how a test can be failed if the UI is closed from underneath the test.")]
        public void SimpleInteraction()
        {
            Log.Comment("If the 'user mode monitor' is enabled and mspaint.exe is closed,");
            Log.Comment("then this test will be failed.");
            Log.Comment("Sleeping for 5 seconds");

            Thread.Sleep(TimeSpan.FromSeconds(5));
        }

        private Process mspaintUnderTest;
    }
}

Este es un desglose rápido de la estructura de la prueba:

  • La prueba "SimpleInteraction" representa una prueba que interactúa con una aplicación basada en la interfaz de usuario; en este caso, es "MSPaint.exe". Observe que los metadatos "ProcessUnderTest" se han aplicado para señalar que esta prueba está probando el proceso de "mspaint.exe".
  • La prueba tiene un accesorio de instalación que garantiza que no se ejecutan instancias preexistentes e inicia una única instancia para probar.
  • La prueba también tiene un accesorio de limpieza que cierra la instancia que se inició en el accesorio de instalación.

La "prueba" es muy sencilla, echemos un vistazo a los posibles resultados:

  1. La prueba se ejecuta sin problemas. Este es el mejor resultado posible.
  2. Sin UMM habilitado, un usuario cierra la instancia de MSPaint durante la ejecución. En este caso, se superará la prueba, pero se producirá un error en la limpieza con una excepción "InvalidOperationException".
  3. Con UMM habilitado, un usuario cierra la instancia de MSPaint durante la ejecución. En este caso, el código UMM registrará un error que muestra que el proceso cerró la prueba. Se produce un error en la limpieza como en el caso (2).

Con UMM habilitado, el comportamiento errante se notifica inmediatamente y afecta directamente al resultado de la prueba. Se trata de un patrón de prueba mucho mejor, ya que los errores se notifican lo antes posible y se proporciona contexto adicional para ayudar a depurar o comprender los errores de prueba.