Probar la aplicación y solucionar problemas
Ahora que ya conocemos los cuellos de botella de rendimiento y algunas de las formas de mitigarlos, en esta unidad se describen técnicas de pruebas. Estas técnicas son una combinación de instrucciones, técnicas y métodos de detección para las pruebas de rendimiento y para las tareas de depuración general.
Usar el control Temporizador para obtener métricas
Cuando se trata de trabajar con conexiones de datos para recuperar o cargar datos, tener cifras concretas resulta útil. En Power Apps, se puede usar un control de Temporizador para capturar cuánto tarda la fórmula en ejecutarse. El siguiente escenario le muestra cómo hacerlo con los siguientes controles:
Botón
Temporizador
Etiqueta de texto
Supongamos que tiene un origen de datos llamado "Rastreo de entrenamiento", el control de Temporizador se llama Timer1 y el control Botón tiene una propiedad OnSelect establecida de la siguiente manera:
Collect(colWorkoutTracker, Filter('Workout tracker', Status = "Active"))
Para la configuración, modificamos primero la fórmula OnSelect del control de botón del siguiente modo:
Reset(Timer1); UpdateContext({StartTimer: true}); Refresh('Workout tracker'); ClearCollect(colWorkoutTracker, Filter('Workout tracker', Status = "Active")); UpdateContext({StartTimer: false})Esta fórmula comienza reiniciando el temporizador. Luego, actualiza una variable de contexto que usamos para iniciar/detener el temporizador a "verdadero". Después, crea la colección y establece la variable de contexto de nuevo en "falso".
Después, debe actualizar una propiedad en el control de Temporizador; establezca la propiedad Inicio en
StartTimer.Ahora, inserte un control Etiqueta de texto para mostrar el tiempo.
Para la propiedad Text del control Etiqueta, ponga la fórmula en
Timer1.Value.Ahora, obtenga una vista previa de la aplicación y seleccione Botón.
Al seleccionar el botón con la aplicación en modo de vista previa, se mostrará cuánto tiempo tardó en crearse la colección (en milisegundos).
Esta técnica funciona cuando se quiere saber exactamente cuánto tarda una consulta concreta. Estos datos se pueden registrar en otra colección y, luego, calcular el promedio de los números para determinar cuánto tarda. Este concepto es aplicable también al envío de datos. Recuerde probar esto no solo en el equipo local, sino también en todos los escenarios de los entornos del usuario.
Pruebas en el lugar en el que los usuarios empleen la aplicación
Esto es más un consejo que una técnica. Para la mayoría de los creadores de aplicaciones, el mejor lugar para ejecutarlas es en el equipo local que usan para crearlas. Las pruebas en ese equipo suelen ofrecer los mejores resultados, pero pueden no coincidir con la experiencia del usuario. Con bastante frecuencia, se olvidan de hacer pruebas del mismo modo que el usuario va a usar para ejecutar la aplicación. Por ejemplo, si vamos a crear una aplicación móvil que se ejecuta a través de una red de telefonía móvil, deberemos procurar que las pruebas incluyan ese aspecto. Tener en consideración el factor de forma más pequeño de los dispositivos móviles y la latencia de una conexión a Internet cambiante es algo que debe quedar reflejado en el diseño de la aplicación. El método de prueba de temporizador anterior es fantástico en este sentido. Compare el rendimiento de carga y de consulta de la aplicación entre su PC, el teléfono móvil a través de wifi y el teléfono móvil con datos móviles. Decida si está satisfecho con estos tres escenarios o si necesita optimizar la aplicación para su uso en redes más lentas.
Usar etiquetas para ayudar con las pruebas
Como la aplicación incorpora una lógica más compleja y más variables en segundo plano para facilitar dicha lógica, considere el uso de controles Etiqueta como parte del kit de herramientas de pruebas. El simple hecho de agregar una etiqueta a la pantalla que muestre el valor de la variable puede contribuir enormemente a entender por qué la aplicación hace o no hace algo. Esto se puede realizar durante las fases de creación y pruebas. Cuando la aplicación ya está publicada, se puede agregar a ella otra funcionalidad para ocultar y mostrar estas herramientas de solución de problemas.
Mientras está en Power Apps Studio, también puede seleccionar Archivo y Variables para ver todas las variables, sus valores, dónde se crearon y dónde se usan en la aplicación.
Otra forma de usar etiquetas durante el proceso de creación consiste en agregarlas a la pantalla de bienvenida donde se muestra manualmente un número de versión. Power Apps almacena en caché la aplicación para optimizar la experiencia. Al publicar la aplicación varias veces, como sucede al personalizar un formulario de SharePoint, puede ser difícil saber qué versión del formulario se está viendo, ya que podría tratarse de una versión en caché. Al incluir una etiqueta con v1 o v2 en la esquina, podremos comprobar la versión en todo momento.
Comparación entre aplicaciones de versión preliminar y aplicaciones publicadas
Con la funcionalidad de vista preliminar de Power Apps Studio, podemos obtener una información excelente sobre cómo se ejecutará la aplicación al publicarla. Sin embargo, a veces hay discrepancias debido a la memoria caché o a otras cosas que el PC local realiza y que son distintas a lo que hará la aplicación publicada. Recuerde probar siempre la aplicación una vez publicada, de manera que sea coherente con el modo en que el usuario va a utilizarla.
Observar la actividad de red de la aplicación
Ahora que ya conoce las pruebas que hay que realizar en la aplicación, conviene echar un vistazo al rendimiento y a las llamadas de red reales. Para ello, puede utilizar la función Monitor integrada. Esto le permitirá ver las llamadas de red individuales realizadas por la aplicación y consultar algunos detalles, como el tiempo que tarda cada llamada. Desde el punto de vista del rendimiento, esto puede ser beneficioso.
Para acceder a Monitor, puede seleccionar el icono Herramientas avanzadas, desde la barra de herramientas del lado izquierdo, o seleccionar el icono Comprobador de aplicaciones de la barra de comandos. Con ambas opciones, verá un vínculo a Abrir Monitor.
Tras seleccionar Abrir Monitor, se abrirá una sesión de Monitor en una pestaña independiente del navegador, con una lista de eventos en blanco y con el mensaje "Ha iniciado una nueva sesión de Monitor".
Monitor hará un seguimiento de las acciones de sus aplicaciones, incluido el rendimiento de la red, y creará los registros correspondientes. Puede usar esto para ver las llamadas al origen de datos, cuánto tardan y qué información se envía o se devuelve.
Un ejemplo de cómo usar esto consiste en averiguar si un rendimiento ralentizado (medido por el control de temporizador del ejemplo anterior) tiene su origen en la aplicación, en la red o en el origen de datos. Usted coloca la aplicación en modo vista previa y comienza a usarla como lo haría un usuario. En el siguiente ejemplo, usamos nuestro ejemplo con el botón y el control de temporizador para ver cuánto tiempo se tarda en obtener los datos de nuestro origen y crear la colección. Como puede ver, la información devuelta incluye marcas de tiempo, categoría, operación, resultado, información del resultado, estado, duración (en milisegundos), origen de datos y el control seleccionado (desde la aplicación).
En este caso, la mayor parte del tiempo se invirtió en esperar a que el origen de datos filtrara los datos y respondiera. Esto indica que la llamada no se puede agilizar cambiando la aplicación, sino que deberemos centrarnos en perfeccionar la consulta o en acelerar el origen de datos.
Monitor permite algunas funciones interesantes que no abarcamos completamente en este módulo. Busque un vínculo en la unidad de resumen si desea obtener más información al respecto. Todas las técnicas de las que hablamos pueden ayudarle a hacer pruebas en su aplicación y a solucionar problemas.