Reportero.InformarEvento en UFT/QTP con ejemplo

¿Qué es Reporter.ReportEvent en UFT/QTP?

Reportero.ReportEvent es un método estándar incorporado UFT/QTP (ahora se vende como OpenTextMicro Focus UFT Una opción es escribir un mensaje personalizado y legible directamente en la ventana de resultados de la prueba. A diferencia de los veredictos automáticos de aprobado o reprobado que generan los puntos de control integrados, una llamada a ReportEvent permite al evaluador decidir exactamente qué se registra, cuándo y cómo debe etiquetarse.

Este HP QTP tutoriales demuestra el uso de la función Reportero.ReportEvent y Formato de resultadosEl tutorial te pide que crees un script corto, y completar ese ejercicio de scripting es la forma más rápida de ver cómo los informes personalizados actualizan el árbol de resultados en tiempo real.

Haga clic en aquí si el video no es accesible

Reporter.ReportEvent cobra especial importancia en la automatización, ya que un script suele ejecutarse sin supervisión, según una programación o dentro de una canalización de CI/CD. El archivo de resultados de la ejecución se convierte en el único registro de lo sucedido, por lo que un paso que falla silenciosamente o que se ejecuta sin explicación dificulta enormemente la depuración posterior. Añadir una llamada explícita a ReportEvent después de una acción crítica transforma el árbol de resultados en un registro de auditoría legible y paso a paso que un tester, desarrollador o gerente puede revisar sin necesidad de abrir el script.

Esto es diferente de un punto de control de objeto, que UFT genera automáticamente e informa usando su propio nombre de paso predeterminado. Reporter.ReportEvent en cambio le permite adjuntar un lenguaje con significado comercial, como "Confirmación de pedido mostrada" en lugar de un genérico "Paso de punto de control en objeto WebEdit", que es mucho más fácil de leer para una parte interesada no técnica en el informe final. El método funciona de la misma manera, ya sea que el script apunte a una página web, un Windows aplicación de escritorio o terminal de mainframe, ya que Reporter es un objeto global en lugar de una propiedad de un objeto de prueba en particular.

GuruDécada de 99 UFT/QTP La serie cubre este método justo después Declaraciones If, Else y Exists, porque la mayoría de las llamadas a Reporter.ReportEvent se encuentran dentro de un bloque condicional que decide si el resultado debe informarse como micPass o micFail.

Sintaxis de Reporter.ReportEvent y valores de EventStatus

Puedes usar Reportero.ReportEvent para informar sobre pasos de prueba personalizados en Micro Focus UFTÁrbol de resultados de la prueba. El método acepta tres argumentos obligatorios y un argumento opcional, en un orden fijo, como se muestra a continuación.

Reporter.ReportEvent EventStatus, ReportStepName, Details [, ImageFilePath]

Estado del evento Establece el icono y el color que se muestran para el paso y puede cambiar el estado general de la ejecución; Nombre del paso del informe es la etiqueta corta que aparece en el árbol de resultados de la prueba, generalmente escrita como el resultado esperado; Detalles Contiene la descripción más larga, normalmente el resultado real observado; y la opción Ruta del archivo de imagen Adjunta una captura de pantalla tomada anteriormente en el script a ese paso específico.

Cada constante también puede pasarse como su valor numérico en lugar de su nombre, por lo que Reportero.ReportEvent 1, “Paso”, “Detalle” se comporta exactamente como Reportero.ReportEvent micFail, “Paso”, “Detalle”Utilizar la constante con nombre facilita la lectura de un script que otro probador mantendrá posteriormente.

Un script suele anidar varias llamadas a ReportEvent dentro de una misma acción: una entrada micDone antes de que comience la acción, una entrada micPass o micFail para la comprobación de teclas y entradas micWarning adicionales para cualquier anomalía detectada durante el proceso.

• Cuando se ejecutan casos de prueba utilizando herramientas de automatización, puede resultar difícil para algunos usuarios comprender los resultados brutos de las pruebas. Puede utilizar results.xml para crear un archivo XSL que presente los resultados de la prueba de la forma que prefiera..
• También puede usar VBScript funciones de la biblioteca para guarda los resultados en un archivo xls o de texto. para informar desde fuera UFT.

Cómo usar Reporter.ReportEvent: Ejemplos prácticos

Una cosa es conocer la sintaxis; otra muy distinta es verla en un script real, lo que permite comprender las cuatro constantes de estado. El siguiente ejemplo incluye una comprobación dentro de una instrucción If…Then…Else, y luego informa si el resultado es positivo o negativo con Reporter.ReportEvent, de modo que el resultado aparece en el árbol de resultados justo donde el revisor espera verlo.

If Browser("Guru99 Demo").Page("Guru99 Demo").WebButton("Login").Exist(5) Then
    Reporter.ReportEvent micPass, "Login button check", "Login button was found on the page"
Else
    Reporter.ReportEvent micFail, "Login button check", "Login button was not found on the page"
End If

Esto refleja el patrón que se muestra en GuruDécada de 99 Sentencias condicionales de VBScript tutorial, donde un bloque If…Then…Else elige entre dos resultados; la única diferencia aquí es que cada rama también llama a Reporter.ReportEvent para registrar el resultado.

Usar micrófono Listo para un paso que es puramente informativo, y Advertencia de micrófono Cuando algo parece inusual pero no debería provocar que la ejecución falle por completo. El siguiente fragmento registra un paso de entrada de datos como completado, luego marca una respuesta lenta como advertencia y adjunta una captura de pantalla usando el argumento opcional ImageFilePath.

Reporter.ReportEvent micDone, "Enter search text", "Typed 'UFT tutorial' into the search box"
errorImage = "C:\Results\SearchDelay.png"
Browser("Guru99 Demo").CaptureBitmap errorImage, True
Reporter.ReportEvent micWarning, "Search response time", "Results took longer than 5 seconds to load", errorImage

Guardar Nombre del paso del informe corto y mantener Detalles Es importante que el análisis se centre en el resultado real. Un revisor que examine cientos de pasos registrados tras una ejecución nocturna fallida debería poder determinar qué ocurrió sin necesidad de abrir el script, y un patrón de nomenclatura coherente en cada acción agiliza considerablemente dicho análisis.

Los equipos que llaman a ReportEvent desde muchos scripts a menudo trasladan esta lógica a una función VBScript compartida, como LogStep(status, name, details), de modo que cada script produce un árbol de resultados coherente sin repetir el mismo bloque If…Then.

Propiedades del objeto Reporter: Filtro, Ruta del informe y Estado de ejecución

Reporter.ReportEvent no es el único miembro del objeto Reporter. Tres propiedades adicionales brindan un control adicional sobre lo que contienen los resultados y dónde UFT Los almacena y aparecen con frecuencia en los marcos de automatización de la producción.

Reporter.Filter acepta cuatro valores: 0 o rfEnableAll muestra todos los eventos y es el valor predeterminado; 1 o rfEnableErrorsAndWarnings oculta los pasos superados; 2 o rfEnableErrorsOnly oculta tanto los pasos superados como las advertencias; y 3 o rfDisableAll desactiva completamente el registro de resultados. Comprobar Reporter.RunStatus a mitad del script permite que una prueba ramifique su propia lógica, por ejemplo, omitirping los pasos restantes en una acción una vez que un paso anterior ya ha fallado.

Dado que ReportPath y RunStatus son de solo lectura, no se les puede asignar ningún valor; úselos para leer información sobre la ejecución actual, por ejemplo, para escribir la ruta de la carpeta de resultados en un archivo de registro al inicio de un script o para interrumpir una acción larga después de un fallo fatal. La lectura de estas propiedades añade una sobrecarga insignificante, por lo que es seguro comprobar Reporter.RunStatus después de cada paso importante en una larga suite de regresión sin que la ejecución se ralentice de forma perceptible.

Mejores prácticas para Reporter.ReportEvent en UFT

Algunos hábitos hacen que los informes personalizados sean útiles en lugar de generar ruido.

• Reserva micFail para fallos reales: Cada llamada a micFail cambia el estado de Reporter.RunStatus, por lo que usarlo para problemas estéticos oculta defectos reales más adelante en la misma ejecución.
• Escriba ReportStepName como un resultado esperado: El revisor debería comprender la comprobación solo con leer el nombre del paso, sin necesidad de leer la columna de Detalles.
• Capturar capturas de pantalla solo en caso de fallo: Pasar ImageFilePath en cada paso llena rápidamente la carpeta de resultados y ralentiza la ejecución sin apenas beneficio.
• Filtrar las ejecuciones ruidosas: Configure Reporter.Filter en rfEnableErrorsAndWarnings para las ejecuciones programadas o de CI, de modo que los pasos superados no oculten los fallos importantes.
• Centralizar la lógica: Envuelva las llamadas a Reporter.ReportEvent dentro de un objeto reutilizable. action o una biblioteca de funciones para que cada script del conjunto registre los resultados de la misma manera.
• Exportar para lectores no técnicos: Combine results.xml con un XSL personalizado cuando las partes interesadas fuera del equipo de control de calidad necesiten revisar los resultados sin abrir UFT.

Preguntas Frecuentes