Xamarin Test Cloud que es

Los usuarios móviles están quizás entre los consumidores más exigentes de software hoy en día, y esperan que las aplicaciones móviles sean sensibles, libres de errores y de bajo costo. Las aplicaciones que no cumplan con esta expectativa se desinstalarán rápidamente y se le asignará una calificación muy baja.

La forma más efectiva de validar el comportamiento de una aplicación es ejecutándola y usándola. Si se comporta como se esperaba, sin fallar o devolver resultados incorrectos, entonces la aplicación está en buena forma y puede ser liberada a los usuarios sin preocuparse de que causará frustración o será inutilizable. Este proceso, de probar la interfaz de usuario mediante el uso de una aplicación y la interacción con ella, se conoce como prueba de aceptación de la interfaz de usuario.

Tradicionalmente, sin embargo, la aceptación de interfaz de usuario ha sido extremadamente caro debido a su naturaleza manual. Históricamente ha requerido mucha mano de obra para desplegar la aplicación y luego usarla, verificando que se comporta correctamente. Multiplicar que por cada construcción que necesita pruebas, así como cada dispositivo y sistema operativo en el que se necesita la prueba, y el costo puede dispararse exponencialmente, lo que significa que las pruebas de aceptación de la interfaz de usuario ha estado fuera del alcance de casi todas las organizaciones, .

Xamarin Test Cloud es una solución basada en la nube que proporciona herramientas que admiten pruebas automatizadas de aceptación de la interfaz de usuario de aplicaciones móviles a través de cientos de dispositivos diferentes. Esto permite a cualquier persona asegurarse de que su aplicación se realiza correctamente y eficientemente a través de una variedad de dispositivos con el mínimo esfuerzo. Además, debido a que se basa en la nube, los esfuerzos de mantenimiento y adquisición se eliminan del consumidor de prueba, que puede centrarse en comprobar que la aplicación funciona correctamente.

El ecosistema Xamarin Test Cloud consta de las siguientes partes:

  • Xamarin.UITest – Este es un marco que permite que las pruebas se escriban en C # utilizando la popular biblioteca de pruebas de NUnit. Este marco es adecuado para los equipos que ya están capacitados para escribir pruebas NUnit y / o desarrollar sus aplicaciones móviles con Xamarin.
  • Test Cloud – Test Cloud es un servicio basado en la nube que consiste en miles de dispositivos móviles físicos. Los usuarios suben sus aplicacionesy pruebas a Test Cloud, que instalará las aplicaciones en los dispositivos y ejecutará las pruebas. Cuando se completan las pruebas, Test Cloud, los resultados se ponen a disposición de los usuarios a través de un fácil de usar e informativo basado en front-end para web.

 

  • Xamarin Test Recorder – Esta herramienta, todavía en desarrollo, puede simplificar la creación de pruebas y es ideal para alguien que es nuevo en Xamarin.UITest y no está familiarizado con las API. Los probadores pueden iniciar Test Recorder, conectarlo al dispositivo, simulador o emulador, y luego empezar a usar la aplicación para móviles. Test Recorder capturará las interacciones entre el usuario y la aplicación móvil y emitirá un Xamarin.UITest en C # para ese escenario.

El sistema Xamarin Test Cloud proporciona las bibliotecas y herramientas que permiten a los equipos crear pruebas automatizadas, ejecutarlas en una multitud de dispositivos y validar que el comportamiento es correcto. La aplicación móvil y las pruebas se suben a Xamarin Test Cloud, que instalará la aplicación y ejecutará las pruebas en cientos de dispositivos físicos. Esto se conoce como una prueba de ejecución . Cuando se complete la prueba, Test Cloud enviará una notificación con los resultados de la prueba. Este flujo de trabajo se puede ver en el siguiente diagrama:

La ejecución de prueba puede realizarse manualmente por un usuario o como parte de un flujo de trabajo de Integración continua (CI) que envía automáticamente nuevas compilaciones de aplicaciones a Xamarin Test Cloud cuando se comprueban los cambios de código:

 

La anatomía del marco de la nube de la prueba

Las interacciones automatizadas con una aplicación móvil requieren algún tipo de biblioteca de automatización que simule la acción de un usuario y permita que la prueba compruebe el estado de la interfaz de usuario para probar que la aplicación funciona correctamente. Tanto Android como iOS tienen sus propios marcos de automatización de UI propietarios. Estos dos conjuntos muy diferentes de API de prueba resultarían desafiantes para un probador que quiere escribir pruebas de plataforma cruzada. Para ayudar a resolver la preocupación, se instalarán uno o dos componentes auxiliares en el dispositivo móvil junto con la aplicación:

  • Xamarin Test Cloud Agent – Este es un servidor HTTP ligero que interactúa con las pruebas a través de JSON a través de HTTP. El Xamarin Test Cloud Agent es un intermediario que tomará las consultas (y en algunos casos, acciones) de las pruebas y las realizará en la aplicación que está siendo probada. El Xamarin Test Cloud Agent es necesario para las aplicaciones de Android y iOS, y tiene un papel ligeramente diferente en cada plataforma.

 

  • DeviceAgent – Se instala sólo las aplicaciones iOS que se construyen con Xcode 8. Lógicamente es muy similar a t Xamarin Test Cloud Agent – es responsable de realizar gestos y consultas avanzadas en las vistas de iOS, pero lo hace utilizando un conjunto diferente de API de prueba.

Xamarin Test Cloud Agent en Android

En Android, el Agente de Cloud Test de Xamarin es responsable de usar las API de automatización de Android para controlar la interfaz de usuario y localizar las vistas para que una prueba pueda interactuar con ellas. Se incluye en un APK separado y se ejecuta como una aplicación independiente, que tiene permiso para automatizar la aplicación bajo prueba. Esto es posible, porque cuando la prueba se implementa en el dispositivo móvil, UITest firmarán ambos paquetes de aplicaciones con la misma clave.

Xamarin Test Cloud Agent en iOS

Cloud Agent de prueba tiene un papel ligeramente diferente en las aplicaciones de iOS; por sí mismo, no automatiza la aplicación que se está probando. En su lugar, el Agente de la nube de prueba interrogará la ventana activa y recuperará información sobre las vistas para el usuario. La información de vista se devuelve al script de prueba. A continuación, el script de prueba automatizará la aplicación iOS con la ayuda de otro componente denominado DeviceAgent . El DeviceAgent simulará los gestos y las acciones para la prueba (usando la API de automatización proveer con Xcode 8) y si es necesario devolver el resultado de esas interacciones a la prueba:

El agente Xamarin Test Cloud está disponible a través de un paquete NuGet y debe incluirse en el paquete de aplicaciones antes de que se pueda ejecutar una prueba. El agente Xamarin Test Cloud sólo debe incluirse en las compilaciones de depuración de la aplicación. Apple rechazará las aplicaciones que se envíen con el Agente de Cloud de Prueba de Xamarin vinculado al Paquete de aplicaciones.

Las versiones más recientes de Calabash y UITest soportan pruebas con Xcode 7 y Xcode 8. El verison de Xcode usado para construir la aplicación determinará qué API de automatización nativa se usa para automatizar la aplicación. El Marco de pruebas y compatibilidad con iOS para Calabash está determinado por la versión de Xcode que se utiliza. Vea la tabla abajo:

VERSIÓN DE IOS LOCAL CON XCODE 7 LOCAL CON XCODE 8
iOS7 UIAutomation n / A
IOS 8 UIAutomation n / A
IOS 9 UIAutomation DeviceAgent
IOS 10 n / A DeviceAgent

Por ejemplo, un Mac con Xcode 8 instalado podrá probar en dispositivos que ejecutan iOS 10 o iOS 9 usando DeviceAgent, pero no podría probar en iOS 8 o inferior.

El paquete NuGet de Agente de la nube de prueba de Xamarin es solo para aplicaciones Xamarin.iOS; No está disponible (o requerido) para las aplicaciones de Xamarin.Android.

Ejecución de pruebas en Xamarin Test Cloud

Ejecución de pruebas en Xamarin Test Cloud es conceptualmente similar a ejecutar pruebas localmente, excepto que Xamarin Test Cloud alberga las pruebas y las ejecutará en dispositivos seleccionados:

Para facilitar esto, las pruebas se cargan junto con la aplicación cuando se envía a Xamarin Test Cloud para pruebas. Xamarin Test Cloud reiniciará el dispositivo en un estado limpio, instalará la aplicación y ejecutará las pruebas.

Limitaciones

Las pruebas que se envían a Xamarin Test Cloud se añaden a una cola y se ejecutarán cuando los dispositivos estén disponibles. Una vez que ha comenzado una prueba, están sujetos a las siguientes limitaciones de tiempo en un dispositivo:

  • Las pruebas para una suscripción pagada se limitan a 360 minutos.
  • Las pruebas de una cuenta de prueba están limitadas a 90 minutos.
  • Las pruebas para una cuenta de la Universidad Xamarin están limitadas a 30 minutos.
  • Los Xamarin.UITests individuales no pueden exceder de 30 minutos cada uno.
  • Los pasos de Calabash individuales no pueden exceder de 10 minutos cada uno.
  • Las cuentas de la prueba y de la universidad se limitan a 10 funcionamientos de prueba por día.

ℹ Los tiempos anteriores no incluyen la espera de que un determinado dispositivo esté disponible, los dispositivos muy utilizados pueden requerir una larga espera.

No es posible realizar una prueba en Xamarin Test Cloud para realizar, simular / emular o controlar lo siguiente:

  • Regulación de la red
  • Inicio de la aplicación en la orientación específica del dispositivo
  • VPN en la red corporativa en lugar de abrir puertos al firewall
  • Integración con otras aplicaciones instaladas en el dispositivo

Xamarin Test Cloud no puede admitir las siguientes características de hardware:

  • Bluetooth
  • Aceleración WiFi
  • Cámara
  • Físicamente girando el dispositivo
  • Simulación de diferentes condiciones de la batería

Traducido al español de la documentación oficial

https://developer.xamarin.com/guides/testcloud/introduction-to-test-cloud/#The_Anatomy_of_the_Test_Cloud_Framework

Una aplicación de Azure IOT y Mobile de ejemplo

Hoy me puse depurar el proyecto MyDriving de Microsoft una serie de aplicaciones que demuestran el diseño e implementación de una solución completa de Internet de Cosas (IoT) que recopila la telemetría de los dispositivos, procesa esos datos en la nube y aplica el aprendizaje de la máquina para proporcionar una respuesta adaptativa. La demostración registra datos sobre viajes en automóvil utilizando tanto un teléfono móvil como un adaptador de Diagnóstico a bordo (OBD) que recopila información del sistema de control de su vehículo. El backend Azure utiliza estos datos para proporcionar retroalimentación sobre su estilo de conducción en comparación con otros usuarios.

Repositorio en

https://github.com/lawebdeprogramador/MyDriving

Trabajar con OAuth2 y OpenID desde una aplicación Xamarin utilizando IdentityServer3

OAuth2 es un protocolo abierto que permite la autorización segura en un método simple y estándar de aplicaciones web, móviles y de escritorio . OpenID Connect es una capa de identidad simple en la parte superior del protocolo OAuth2 .
En cierto modo, OAuth2 es un protocolo para construir,
Lo que es exactamente lo que hace OpenID Connect. OIDC es más estricto que el protocolo OAuth2, que, gracias a ese rigor, lo abre a otros escenarios, como la autenticación. En estos días, la mayoría de las aplicaciones utilizan OIDC en lugar de OAuth2, ya que requieren iniciar sesión en una aplicación cliente o en información relacionada con la identidad, ambas provistas por OIDC.
¿Por qué de repente necesitamos todas estos antecedentes? La autenticación de formularios podría funcionar cuando se está creando una aplicación ASP.NET estándar de n niveles o incluso una aplicación basada en servicios que se ejecute en el mismo contexto. Pero en estos días, la mayoría de las aplicaciones modernas están basadas en API, con una API completamente separada de cualquier cliente que lo consuma (esto es realmente una de las restricciones fundamentales impuestas por una arquitectura basada en REST).
La aplicación cliente que consume esa API puede ser una aplicación ASP.NET MVC, que consume la API del servidor, pero también podría ser una aplicación móvil o una aplicación basada en JavaScript (por ejemplo, Angular). En este caso, la API Se consume desde un dispositivo cliente. La autenticación de formularios, obviamente, no es adecuada para esos escenarios. Pero … el envío de un string de nombre de usuario / contraseña en cada HttpRequest a tu API realmente no es algo que quieras hacer.
Los tokens representan el consentimiento, por ejemplo: concedido por el usuario, a la aplicación cliente, para acceder a una API — normalmente a través de ámbitos, en la jerga OAuth2.
Su aplicación cliente debería — de alguna manera — obtener un token. Ese símbolo se puede utilizar en el cliente, o se puede pasar a la API, que se utiliza en ese nivel para autorizar el acceso. Hace un tiempo, la gente escribía “servicios simbólicos” para eso. Típicamente: una llamada a un punto de inicio auto-creado / de inicio de sesión, que aceptaría su nombre de usuario / contraseña y devolvería un Token Web JSON.
Pero simplemente enviar su nombre de usuario / contraseña a una acción auto-creada en una API y obtener un token a cambio no es un buen ajuste para muchas aplicaciones, ni una buena idea. Aún así, es necesario que comparta su nombre de usuario / contraseña con esa API, que podría estar bien para su propia aplicación de confianza (aunque no soy un gran fans), pero es una muy mala idea para aplicaciones de terceros, incluidas otras aplicaciones. Que podría vivir en su empresa. Por otra parte, una vez que comenzamos a crear extremos como estos nosotros mismos, estamos esencialmente reinventando la rueda. Tenemos que implementar la expiración nosotros mismos. Tenemos que implementar la validación de token. Tenemos que implementar el cierre de sesión. Es posible que desee implementar soporte de token de referencia. Necesitaremos separar identidad y acceso, y así sucesivamente. En resumen, los errores son casi inevitables.
Introduzca el protocolo OAuth2. El protocolo OAuth2 define una forma de obtener de forma segura un tipo específico de token (“obtener autorización”) : un token de acceso. Lo hace a través de uno de los diferentes flujos / subvenciones como se define en el RFC. Es su responsabilidad elegir el flujo correcto, dependiendo del tipo de aplicación que esté construyendo.
Este tipo de token se utiliza para autorizar el acceso a esa API. Por supuesto, sigue siendo la API que elige si el consentimiento que contiene el token de acceso es suficiente para permitir el acceso. Por lo tanto, su aplicación cliente debe obtener un token de acceso de un servicio de token de seguridad (como IdentityServer) a través de una concesión / flujo específico y pasar ese token de acceso en cada llamada a la API.
Sin embargo, los clientes de acceso OAuth2 no deben utilizarse para la autenticación: el protocolo no es lo suficientemente estricto para permitirlo de forma segura. Sin embargo, OIDC, construido sobre OAuth2, define un nuevo tipo de token: un token de identidad. Y que se puede utilizar para la autenticación.
El ejemplo arquetípico es una aplicación ASP.NET MVC que llama a una API a través de una instancia de HttpClient. Utiliza el token de identidad para iniciar sesión en la aplicación ASP.NET MVC y utiliza el token de acceso para acceder a la API.
En este caso, esa aplicación cliente es un cliente Xamarin. Pero … no hay ningún uso real para iniciar sesión en un cliente de este tipo. Los clientes móviles (Xamarin, iOS nativo, Android, Windows Phone, …) se despliegan en un teléfono, un dispositivo que no es de confianza. No podemos no entregamos código dependiendo de la identidad del usuario: el código ya está presente en el dispositivo cliente. El mismo principio es válido para clientes basados ​​en JavaScript, como un cliente Angular. Esto es contrario a lo que podemos hacer con una tecnología de servidor, por ejemplo: una aplicación ASP.NET MVC. En esos tipos de aplicaciones, podemos bloquear eficazmente el acceso a partes del código — nunca se ejecutarán, los resultados nunca se servirán a su navegador. Para los clientes móviles, normalmente necesitamos fichas de acceso más de lo que necesitamos fichas de identidad.
Sin embargo, los tokens de identidad también se utilizan para que estos tipos de clientes obtengan información relacionada con la identidad del token (alternativamente, también puede utilizar el punto final de UserInfo). Por lo tanto, aunque realmente no estamos iniciando sesión en el cliente como lo haríamos en un cliente ASP.NET MVC, OpenID Connect tiene sentido ya que permite el acceso a la información relacionada con la identidad, ya sea directamente contenida en un token de identidad o por Utilizando un token de acceso que contiene ámbitos de identidad para acceder al punto final UserInfo. Junto a eso — quizás aún más importante -, OIDC es más estricto que OAuth2 (como se mencionó anteriormente), lo que significa que añade características de seguridad adicionales (entonces, por ejemplo) — Yo aconsejaría utilizar siempre OIDC, incluso si no Necesitan fichas de identidad.
Ahora, ¿cómo encaja IdentityServer en esta historia? Si usted lee a través de los RFC, notará que hay una gran cantidad de implementación que tiene que suceder a nivel de servidor. Esto no es algo que usted normalmente quiere hacer usted mismo: Dominick Baier y Brock Allen han hecho esto por nosotros. IdentityServer implementa los estándares OAuth2 y OIDC, entre otros. Lo que nosotros, como desarrolladores de las aplicaciones cliente y API tenemos que manejar es la parte del cliente de los estándares y asegurando que nuestra API pueda trabajar con esos tokens.
Hay un gran tutorial sobre cómo configurar IdentityServer en la documentación , en caso de que no lo haya hecho antes. El tutorial también contiene un ejemplo sobre cómo proteger su API.
Uff, hasta ahora para ese curso acelerado — he cortado algunas esquinas aquí y allá, pero esta es la esencia de la misma. En la aplicación de ejemplo.
La Aplicación de Ejemplo de Xamarin Forms
Como sabemos ahora, es importante utilizar el flujo correcto para el tipo de aplicación que va a construir. No utilizar el flujo correcto podría abrirse a riesgos que no desea; Por ejemplo: un flujo de credenciales de cliente, que se basa en un secreto de cliente, no debe utilizarse de las aplicaciones que se ejecutan en el cliente: no tienen medios de almacenar con seguridad ese secreto, haciendo que el secreto esencialmente inútil.
El flujo aconsejado para una aplicación móvil (nativa) es el flujo implícito, de acuerdo con la especificación actual, aunque también puede utilizar el flujo de código de autorización o el flujo híbrido. Hay bastante discusión sobre esto que está sucediendo actualmente, y esta postura podría cambiar en el futuro (cercano) (probablemente favoreciendo el flujo híbrido). Al igual que con todas las cosas relacionadas con la seguridad: el trabajo nunca es realmente terminado (que es, incidentalmente, bastante buenas noticias para mi seguridad laboral ;-)).
De todos modos, he implementado esto utilizando el flujo implícito, pero los otros flujos se implementaría de la misma manera.
Este es un flujo basado en la redirección, por lo que necesitaremos usar un WebView en nuestra aplicación Xamarin Forms. La idea general es que utilizaremos ese WebView para navegar hasta el punto final de autorización en el nivel de Identity Server, pasando los tipos de ámbitos y respuestas que necesitamos. En la página LoginView.xaml, hay una WebView oculta:
codigo
public void StartFlow(string responseType, string scope)
{
var authorizeRequest =
new AuthorizeRequest(“https://localhost:44333/core/connect/authorize”);

// dictionary with values for the authorize request
var dic = new Dictionary<string, string>();
dic.Add(“client_id”, “implicitclient”);
dic.Add(“response_type”, responseType);
dic.Add(“scope”, scope);
dic.Add(“redirect_uri”, “https://xamarin-oidc-sample/redirect”);
dic.Add(“nonce”, Guid.NewGuid().ToString(“N”));

// add CSRF token to protect against cross-site request forgery attacks.
_currentCSRFToken = Guid.NewGuid().ToString(“N”);
dic.Add(“state”, _currentCSRFToken);

var authorizeUri = authorizeRequest.Create(dic);

wvLogin.Source = authorizeUri;
wvLogin.IsVisible = true;
}
El código es de la muestra en el proyecto IdentityServer3.Samples, pero el proyecto autónomo también contiene código)
Como estamos trabajando con OIDC, debemos incluir un token en esa solicitud. Para protegernos de los ataques CSRF, debemos incluir un token CSRF, que es esencialmente un valor aleatorio, no adivinable, que se devolverá al cliente. Una vez que se ha recuperado, tenemos que comprobar que coincide con el valor que enviamos en la solicitud inicial.
Por lo tanto, lo primero que debe hacer: crear el URI en el punto final de autorización en el nivel IdentityServer. He utilizado el paquete IdentityModel para esto, lo que ayuda mucho con la creación de los URIs correctos y el análisis de los resultados. El método StartFlow contiene el código para crear el URI y navegar el WebView a ese URI.

Los botones de la muestra llaman a ese método, pasando en response_type & scopes. Por ejemplo, esta pieza de código pedirá un token de identidad y un token de acceso:
Private void GetIdTokenAndAccessToken (object sender, EventArgs e)
{
// al preguntar a ambos, podemos pedir ámbitos relacionados con la identidad
// así como ámbitos de recursos
StartFlow (“id_token token”, “openid profile read write”);
}
Una vez que el URI de WebView esté configurado con el URI que acabamos de crear, mostrará la página de inicio de sesión de IdentityServer, donde tendrá que proporcionar sus credenciales (alice / alice para el ejemplo de IdentityServer3.Samples, Kevin / secreto para el ejemplo independiente).
A continuación se analizan los tokens una vez que se redirigen. Estos tokens se incluyen en el URI y podemos analizarlos captando el evento Navigated del WebView y comprobando si el URI comienza con el URI de redirección que pasamos al crear el URI de autorización. AuthorizeResponse también forma parte del paquete IdentityModel. No olvide comprobar el token CSRF para protegerse contra ataques CSRF.
private void WvLogin_Navigating(object sender, WebNavigatingEventArgs e)
{
if (e.Url.Contains(“https://xamarin-oidc-sample/redirect”))
{
wvLogin.IsVisible = false;

// parse response
_authResponse = new AuthorizeResponse(e.Url);

// CSRF check
var state = _authResponse.Values[“state”];
if (state != _currentCSRFToken)
{
txtResult.Text = “CSRF token doesn’t match”;
return;
}

string decodedTokens = “”;
// decode tokens
if (!string.IsNullOrWhiteSpace(_authResponse.IdentityToken))
{
decodedTokens += “Identity token \r\n”;
decodedTokens += DecodeToken(_authResponse.IdentityToken) + “\r\n”;
}

if (!string.IsNullOrWhiteSpace(_authResponse.AccessToken))
{
decodedTokens += “Access token \r\n”;
decodedTokens += DecodeToken(_authResponse.AccessToken);
}

txtResult.Text = decodedTokens;
}
}
Y eso es todo lo que hay. A partir de este momento, usted tiene el token (s) que usted pidió, que contiene los ámbitos demandados. Puede utilizar el token de identidad para obtener información relacionada con la identidad y puede utilizar el token de acceso para acceder a su API.

Eso es todo por ahora, feliz Codificación!
Fuente y repositorio
Articulo original,
IdentityModel/IdentityModel.OidcClient2
IdentityModel.OidcClient2 – Certified C#/NetStandard OpenID Connect Client Library for native mobile/desktop…github.com
https://www.kevindockx.com/working-with-oauth2-and-openid-connect-from-a-xamarin-forms-application-using-identityserver3/