Como profesional de control de calidad , crear un nuevo usuario para la prueba del producto puede parecer una tarea sencilla: solo complete el formulario de registro y estará listo para comenzar. Sin embargo, ¿qué sucede si necesita evaluar a un usuario con un historial de mensajes de un año o evaluar cómo funciona una función de servicio de video para un grupo de prueba A/B en particular? Estas situaciones pueden convertirse rápidamente en tediosas y lentas cuando se crean usuarios manualmente.
En este artículo, compartiremos nuestro viaje de desarrollo de una herramienta que automatice completamente ese proceso. ¡Vamos a sumergirnos!
Presentamos nuestra herramienta de gestión de usuarios
En Social Discovery Group, brindamos servicios en línea que conectan a personas de todo el mundo. Nuestros productos permiten a los usuarios comunicarse a través de chat y video, y compartir contenido multimedia. A medida que nuestros productos evolucionaron, comenzamos a encontrar escenarios de prueba cada vez más complejos. Por ejemplo, necesitábamos examinar el perfil de un usuario con una suscripción vencida o analizar la funcionalidad de una lista de contactos con más de 30 entradas.
Para generar un usuario "rico en historia", tuvimos que ejecutar múltiples consultas API, enviar mensajes a RabbitMQ y ejecutar scripts SQL. Como estos pasos ya estaban incorporados en nuestras pruebas automatizadas, el equipo de control de calidad manual nos pedía con frecuencia que realizáramos una prueba automatizada para crear el usuario necesario. Con el tiempo, la creación de un solo usuario comenzó a llevar más tiempo que la prueba en sí. Por lo tanto, decidimos encontrar una manera de empoderar a cualquier empleado para que maneje el proceso de creación de usuarios de forma independiente.
Nuestra automatización de pruebas está escrita en C#. Utilizamos activamente llamadas API a nuestros recursos de aplicaciones en pruebas automatizadas. Por ejemplo, utilizamos el siguiente método para el registro de clientes:
var client = new Client(); RegisterClient(client, param1, param2, param3);
Después de analizar nuestro marco, llegamos a la conclusión de que la solución más fácil para crear los usuarios necesarios para las pruebas sería desarrollar una aplicación de formularios web ASP.NET utilizando nuestros métodos. Imaginamos un sitio web que los evaluadores de control de calidad podrían usar para crear fácilmente los usuarios requeridos.
Esto es lo que hicimos:
Primero, agregamos una página para la creación de usuarios. Los evaluadores podían seleccionar parámetros adicionales y configurar al usuario según sus preferencias, ya sea como un usuario nuevo o con un largo historial de chats.
Así es como se veía el proceso:
Aquí está el código de la página, incluido el elemento de salida.
<%@ Page Language = "C#" AutoEventWireup = "true" CodeBehind = "WebForm1.aspx.cs"
Inherits = "Habrl.Pages.Registration.RegistrationForm1" %> <!DOCTYPE html> <html xmlns = "http://www.w3.org/1999/xhtml" > <head runat = "server" > <title></title> </head> <body> <form id = "registration" runat = "server" > <div> <div> <label>Client type:</label> <asp:DropDownList ID = "clientType" runat = "server" AutoPostBack = "true"
CssClass = "select" OnSelectedIndexChanged = "clientType_OnSelectedIndexChanged" > <asp:ListItem value = "regularClient" Selected = "True" >Regular client</asp:ListItem> <asp:ListItem value = "clientWithChatHistory" >Client with chat history</asp:ListItem> <asp:ListItem value = "inactiveClient" >Inactive Client</asp:ListItem> </asp:DropDownList> </div> <div id = "usersCountDiv" runat = "server" > <label>How much clients we should register:</label> <asp:TextBox ID = "clientsCount" runat = "server" CssClass = "input"
Text = "1" ></asp:TextBox> <div class = "errorMsg" > <asp:RequiredFieldValidator Display = "Dynamic" runat = "server"
ControlToValidate = "usersCount" ErrorMessage = "Define clients count!" ></asp:RequiredFieldValidator> <asp:RangeValidator Display = "Dynamic" runat = "server"
ControlToValidate = "clientsCount" Type = "Integer" MinimumValue = "1" MaximumValue = "30"
ErrorMessage = "We can create from 1 till 30 clients at once!" ></asp:RangeValidator> </div> </div> <div> <asp:Button CssClass = "MyButton separateButton" ID = "SubmitButton" runat = "server"
text = "Register" OnClick = "OnRegisterButtonClick" ></asp:Button> </div> </div> </form> <div runat = "server" id = "result" ></div> </body> </html>
Aquí está la implementación lógica:
public partial class RegistrationForm : System . Web . UI . Page
{ int _clientsCount; string _clientType; protected void Page_Load ( object sender, EventArgs e )
{ _clientsCount = int.Parse(clientsCount.Text); _clientType = clientType.SelectedValue; } protected void OnRegisterButtonClick ( object sender, EventArgs e )
{ var clients = new ConcurrentBag<Client>(); Parallel.For( 0 , _clientsCount, _ =>
{ var client = new Client(); RegisterClient(client, _clientType); clients.Add(client); }); result.InnerHtml = GenerateTableViewForClientsEnumerable(clients); } }
Al registrarse, recibimos la siguiente tabla:
El método RegisterClient utilizado en UMT es idéntico al utilizado en nuestras autopruebas. Esto significa que cada vez que introducimos una nueva funcionalidad en nuestros productos, nuestras pruebas automáticas se actualizan automáticamente y esos cambios también se reflejan en UMT. UMT esencialmente sirve como una implementación de front-end sobre nuestros contratos, que proporcionan el código de autoprueba subyacente.
Gracias a UMT, todo el equipo ahora puede crear fácilmente el perfil de usuario requerido en cualquiera de nuestros numerosos entornos de prueba con solo un par de clics. El equipo de control de calidad manual puede generar incluso los perfiles de usuario más complejos de forma independiente, sin necesidad de que el equipo de automatización participe. Para nuestra sorpresa, el equipo de desarrollo también comenzó a aprovechar UMT para sus fines.
Desarrollo y Mejora
Después de que lanzamos UMT, comenzamos a recibir solicitudes de nuevas funciones. Agregamos páginas para la administración de usuarios (incluida la emulación de estado en línea y la mensajería) y la administración de pagos. Más tarde, el equipo móvil se acercó a nosotros con una preocupación: crear un usuario de UMT en dispositivos móviles requería mucho tiempo y esfuerzo para ingresar los detalles del correo electrónico y la contraseña. En respuesta, agregamos una característica pequeña pero útil a UMT: la generación de códigos QR con enlaces de inicio de sesión y enlaces profundos para aplicaciones móviles.
A medida que continuamos desarrollando UMT, realizamos dos rediseños importantes y agregamos un menú en forma de árbol al sitio. Como resultado, la página de registro de usuario original ha sufrido una transformación significativa y ahora se ve completamente diferente.
En el transcurso de los cinco años y medio de existencia de UMT, ampliamos la herramienta mucho más allá de su propósito original de facilitar las pruebas de productos. Agregamos secciones para automatizar las actividades de DevOps, como reiniciar servicios y servidores, configurar, limpiar y vincular entornos de prueba, y proporcionar información estadística, así como una base de conocimiento y más. En la siguiente sección, echaré un vistazo más de cerca a algunas de estas características.
Autorización
Después de un tiempo, decidimos restringir el acceso a UMT para ciertos empleados (por ejemplo, aquellos en período de prueba). Para ello, agregamos una base de datos y una tabla con roles y usuarios, implementamos autenticación de dominio y asignamos permisos. Con este sistema implementado, podemos identificar la sesión del usuario y darle acceso a funciones específicas según sus derechos. También agregamos la autorización de Google a UMT, dado el uso de los servicios de Google por parte de nuestra empresa.
Servicios y entorno de prueba
Como UMT se convirtió en una herramienta popular entre el equipo, nuestro equipo de control de calidad quería administrar servicios y bancos de pruebas a través de UMT en lugar de depender de varios scripts y herramientas como Ansible. Agregamos la capacidad de reiniciar los servicios de Docker y Windows, IIS y los nodos web, y editar las configuraciones de esos servicios. También incluimos una función para configurar estos servicios y compararlos entre bancos de pruebas.
TestRail y Jenkins
La automatización de pruebas es una parte crucial de nuestro trabajo y, a menudo, tenemos más de diez pruebas en curso en un momento dado. Sin embargo, puede ser un desafío ubicar una ejecución en particular entre muchas otras en Jenkins o verificar su posición en la cola. Para abordar este problema, desarrollamos una página en UMT que muestra datos sobre todas las ejecuciones actuales y las que están en cola. Esta página sondea todas nuestras instancias de Jenkins para recopilar información sobre trabajos en ejecución, que luego se presenta en tablas para una fácil referencia.
Además, UMT ofrece una página separada para crear TestPlans con TestRuns habilitados en TestRail. Con solo unos pocos clics, los usuarios pueden elegir entre varios TestPlans básicos con escenarios de prueba.
UMT también ha demostrado ser útil para analizar pruebas automáticas fallidas o investigar el comportamiento anómalo del usuario. Anteriormente, estas tareas requerían abrir manualmente Fiddler para consultas API o conectarse a la base de datos para ejecutar consultas SQL. Sin embargo, con UMT, las páginas dedicadas brindan información técnica completa sobre los usuarios creados en el banco de pruebas, lo que hace que la resolución de problemas sea más rápida y eficiente.
Hoy, UMT es un proyecto completo que continúa evolucionando a medida que el departamento de automatización de pruebas recibe nuevas tareas para agregar funcionalidad o corregir errores. Las tareas priorizadas se incluyen en el sprint. UMT sigue siendo una herramienta esencial para nuestro personal, ahorrándoles tiempo y esfuerzo al recopilar muchas actividades rutinarias en un solo lugar. Ya no es necesario tomar notas, guardar consultas de API en Fiddler o Postman, o abrir SQL Studio para realizar rutinas de base de datos. Entonces, si su empresa enfrenta desafíos similares, ahora sabe qué hacer.
Escrito por Pavel Yasonau, jefe de equipo de automatización de control de calidad en Social Discovery Group