Создать нового пользователя для теста продукта — простая задача для любого qa: необходимо просто прокликать форму регистрации. Но что, если протестировать нужно юзера с годовой историей переписок? Или проверить, как работают фишки видеосервисов на тех, кто попал в конкретную группу A\B тестинга? Ниже — история о том, как мы устали создавать таких пользователей вручную и разработали тулу, которая делает это за нас.
Рождение UMT
Social Discovery Ventures создает сервисы для общения в интернете. В них люди знакомятся, общаются в чатах, делают звонки и обмениваются разным медиа-контентом. С развитием этих сервисов стало появляться все больше сложных кейсов для теста. Например, проверить профиль с истекшей подпиской или функционал списка контактов пользователя, в котором более 30 записей.
Чтобы получить пользователя “с историей”, необходимо было сделать несколько api-запросов, прокинуть сообщение в rabbitMQ и даже выполнить sql скрипты. Все эти действия уже были написаны в наших автотестах, поэтому отдел manual qa стал чаще обращаться к нам, чтобы запустить автотест для подготовки именно такого пользователя. Сложилась ситуация, в которой создание юзера стало занимать гораздо больше времени, чем само тестирование. Тогда мы задумались, как дать возможность любому сотруднику справляться с этой задачей самостоятельно.
Наша автоматизация написана на c# (про нее и то, как мы ускоряли автотесты, можно прочитать здесь). В автотестах мы активно используем api-вызовы к ресурсам нашего приложения. Например, такой метод для регистрации клиента:
var client = new Client(); RegisterClient(client, param1, param2, param3);Проанализировав наш фреймворк, на тот момент мы подумали, что самым простым решением будет создать ASP.NET Web Forms приложение, использующее вызовы к нашим методам. Мы видели решение как веб-сайт, где qa сможет сам создавать себе необходимых пользователей для тестирования.
В итоге мы:
-
Создали новый ASP.NET Web Forms проект, который назвали незамысловато: User Management Tool (UMT).
-
Добавили основной проект с автотестами как submodule в GIT.
-
Настроили сборку и деплой UMT на один из наших серверов (на основе IIS webserver) через один из автотестовых Jenkins.
-
Прописали dns и начали развивать функционал.
Первой мы добавили страницу с созданием пользователей. Тестировщик мог выбирать дополнительные параметры и конфигурировать пользователя по своему желанию: как нового, так и с большой историей чатов. Процесс следующий:
-
Создать страницу aspx и добавить в нее необходимые элементы для конфигурации пользователя (возраст, пол, имя, страна…).
-
Добавить элемент, где будет отображен результат.
-
Реализовать логику вызова нужных функций при нажатии на action-кнопку.
Код страницы вместе с элементом вывода результата:
<%@ 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> Реализация логики:
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); } }После регистрации мы увидим такую таблицу:
RegisterClient — тот самый метод из наших автотестов. При добавлении функционала в продукты мы дорабатываем автотесты и изменения автоматически попадают в UMT. Таким образом, он всегда остается актуальным и нет необходимости его дополнительно обновлять. В некотором роде, UMT — это реализация front-end над контрактами, который предоставляет код автотестов.
В итоге, у всей команды появился инструмент, позволяющий в пару кликов создать нужного пользователя на любом из наших многочисленных тестовых окружений. Команда manual qa смогла сама генерировать сложного пользователя, а автоматизаторы не отвлекались на такие просьбы. Неожиданно для нас, UMT стала использовать и разработка.
Развитие и доработка
Почти сразу мы начали получать запросы на внедрение новых функций. Мы добавили страницы по управлению пользователем (эмуляция онлайновости, рассылка сообщений) и по работе с платежной системой. Однажды мы услышали от мобильной команды, что при создании юзера в UMT коллеги тратят много времени на рутинный ввод email и password на мобильных устройствах. Тут же родилась одна из самых маленьких, но полезных доработок UMT — генерация QR-кода с ссылкой для авторизации на сайте и QR-кода с deeplink для мобильных приложений.
Наполнение функционалом побудило нас провести два редизайна и добавить древовидное меню сайта. К настоящему моменту самая первая страница — регистрация пользователей — изменилась до неузнаваемости и выглядит так:
За 5 с половиной лет существования UMT в него были добавлены не только IT-активности, относящиеся непосредственно к тестированию продукта. Теперь у нас есть разделы, автоматизирующие DevOps-активности: рестарты сервисов и серверов, конфигурация, очистка и связь тестовых окружений, различная статистическая информация, база знаний и многое другое. Чуть подробнее расскажу о некоторых из них.
Авторизация
Со временем мы захотели ограничивать часть функционала UMT для некоторых сотрудников (например, для человека на испытательном сроке). Для этого мы добавили базу данных, завели таблицу с ролями и пользователями, а после — ввели доменную аутентификацию и назначили права. Теперь, когда пользователь залогинился, мы знаем его сессию и в зависимости от его прав даем доступ к тому или иному функционалу. Позже, мы добавили к UMT google-авторизацию, так как в компании используем сервисы google.
Сервисы и тестовые стенды
UMT стал популярным продуктом у команды и qa захотели управлять сервисами на стендах и самими стендами через него, а не используя разрозненные скрипты и другие инструменты (ansible). Таким образом, мы добавили возможность рестарта docker\windows сервисов, IIS, web-ноды, редактирование конфигов этих сервисов и их сравнение на разных стендах.
TestRail и Jenkins
Мы активно используем автоматизацию тестирования: в данный момент времени у нас может выполняться 10 и более тестовых запусков. Бывает неудобно искать свой запуск в Jenkins, выбирая его из множества остальных или смотреть, какое место он занимает в очереди. Поэтому в UMT была добавлена страница с данными обо всех текущих запусках и тех, что находятся в очереди. При загрузке этой страницы мы опрашиваем все наши Jenkins о запущенных jobs, собираем о них информацию и выводим ее в таблицы.
На отдельной странице в UMT есть возможность создавать различные TestPlan с включенными TestRuns в TestRail. В UMT это делается нажатием всего пары кнопок, где можно выбрать один из нескольких базовых тестпланов с тесткейсами.
UMT оказался полезен при разборе упавших автотестов или исследовании аномального поведения пользователей. Вручную при разборе пришлось бы открывать fiddler для api запросов или подключиться к БД для выполнения SQL. UMT предлагает на специальных страницах получить полную техническую информацию о пользователе, созданном на тестовом стенде. Это здорово экономит время при поиске возникающих проблем.
Сейчас UMT развивается как полноценный проект: отдел автоматизации тестирования все время получает задачи на добавление нового функционала (или фикс багов, мы ведь тоже разработка). Они приоритезируются и включаются в спринт. UMT здорово экономит время нашим сотрудникам, так как большое количество разнородных рутинных активностей собрано в одном месте. Больше не нужно делать заметки, сохранять api запросы в fiddler/postman, а для выполнения рутинных задач с БД — открывать SQL Studio. Если в вашей компании есть похожие проблемы — теперь вы знаете, что делать.
ссылка на оригинал статьи https://habr.com/ru/company/sdventures/blog/692798/
Добавить комментарий