Сложности взаимодействия пользователя и приложений

Фактор условий

Рано или поздно сложность разработки приложений, многообразие способов взаимодействия с пользователем, скорость изменения технологий приводят к необходимости все более тщательной проверки функционирования приложения в различных условиях. Внешне простое приложение на экране телефона часто содержит большое количество строк программного кода и бизнес-логики, схем взаимодействия с внешней средой. Сегодня, во времена «облачной революции» в Сети, мы все чаще работаем с сервисами, которые предоставляют нам определенную услугу. То же простое приложение может использовать не один сервис, а несколько и даже из разных мест. Например, заявка на отпуск может вызывать сервисы для получения персональной информации о сотруднике, о его руководителе, об остатке дней отпуска, о проверке возможности зарезервировать дни отпуска - это все частные сервисы, выраженные функциями в системе SAP HCM, но работающие как сервисы.

Фактор «многопользования»

Есть и другое приложение, которое отвечает за согласование заявки на отпуск. Разумно предположить, что это приложение использует сервис для получения персональной информации о сотруднике. Тот же самый, что и заявка на отпуск. Мы реализовали сервис один раз, а уже окупили его разработку двумя потребителями сервиса. Два приложения успешно получают информацию из одного сервиса, но однажды появляется третье приложение, которому необходим расширенный набор данных о сотруднике. Например, вывести его пол или возраст. Простейшая задача добавления поля в выгрузку данных может стать кошмаром в большой системе. Все дело в том, что приложения разрабатываются в различное время, на разных уровнях систем, разными людьми, возможно с разными подходами и технологиями. И это изменение структуры данных, которую отдает сервис, одним приложением может обработаться корректно, а второе приложение перестанет работать.

Необходимость алгоритмизации тестирования

С ростом инфраструктуры растет количество сервисов и потребителей. Любое незначительное изменение может остановить большую часть системы, что неприемлемо для современного бизнеса. Человек уже не в состоянии отследить все множество взаимосвязей и протестировать каждую связь, каждое звено в случае любого изменения сервиса или приложения. На помощь приходят современные методики и технологии. Если мы можем алгоритмизировать процесс тестирования каждого конкретного случая, то такой процесс можно запрограммировать на автоматизированное тестирование компьютером. Компьютер может инициировать процесс, вставить необходимые данные, произвести вызовы сервисов, получить результат и проверить его на совпадение с эталоном.

Необходимость универсализации платформы

Другая часть приложения обычно отвечает за взаимодействие с пользователем. В приложении есть табличная форма заявки на отпуск, несколько кнопочек, включая кнопочку «Создать». На одном телефоне, где программист тестировал приложение, все работает отлично. На телефоне соседа табличка заезжает за поля экрана, кнопочку не видно. На компьютере кнопочка «Создать» не реагирует на нажатие, а у Ивана при нажатии на кнопку «Обновить» приложение завершает свою работу.

Как проблема решается

Концепт

Ситуации, связанные с взаимодействием с пользователем, необходимо тестировать. Тестировать на различных платформах, разрешениях экранов, различных версиях браузеров и операционных систем. Такое многообразие вариантов потребует огромных ресурсов, которыми мало кто из разработчиков располагает. Для упрощения жизни тестировщиков появились серверы непрерывного тестирования, в задачу которых входит автоматизированное тестирование одного и того же приложения в различных средах. Такой сервер по заранее определенному сценарию запускает приложение в отдельной среде (нужная версия браузера, нужное разрешение, нужная операционная система), запускает все сценарии тестирования и записывает результаты в протокол. Разработчик уже работает с итоговым протоколом, где отражены ошибки, возникшие в конкретной среде. Локализация такой ошибки, исправление и перезапуск полного цикла тестирования экономит весомое количество времени, а значит и денег. Несомненно, что такое тестирование существенно повышает качество продукта, с которым будет работать конечный пользователь.

SAPUI5 основан на «китах Интернета» в лице HTML структуры, CSS разметки, JavaScript кода. Приложения, которые мы видим на экранах, созданы с помощью этих элементов статически (в момент разработки приложения) или динамически (в момент выполнения приложения у пользователя). Когда мы нажимаем на кнопочку «Создать», то открывается новое окно. Мы заполняем его информацией и отправляем на сервер для создания записи в базе данных. Это уже целый процесс, где задействованы элементы экрана, коды для формирования запроса серверу и анализа результата. Так как все формализовано, то мы можем проверить работу процесса автоматизировано с помощью специальных инструментов.

Простой пример теста

Рассмотрим работу кнопки «Создать». По нажатию на кнопку происходит обращение к серверу (в общем случае) с запросом формы для окна создания новой записи. Сервер обрабатывает запрос и присылает необходимые поля, их оформление для визуализации на экране. Для пользователя это просто смена картинки, для автоматизированного теста это многоступенчатый процесс, который нужно проверить в нескольких ракурсах:

• После нажатия на кнопку сформировался ли запрос к серверу?
• Сервер вернул положительный ответ или ошибку?
• Положительный ответ сервера, это страница с формой для ввода данных или что-то другое?
• Форма для ввода данных содержит поля, которые мы ожидали или другие?
• Форма для ввода данных осуществляет проверку на формат вводимых данных?

Рассмотрен пример простейших тестов, которые должна выполнить система автоматизированного тестирования для проверки одной пользовательской операции «Создать». Если перемножить количество операций на вариативность сред для выполнения приложения и на возможные ракурсы, то мы поймём, что без автоматизации не обойтись.

Сегодня хорошей практикой среди программистов считается разделение объектов тестирования на уровни. Прежде чем обратиться к уровням, следует вспомнить про MVC архитектуру построения веб-решений. Это Модель – Представление – Контроллер подход (Model View Controller), когда модель отвечает за данные, контроллер за управление данными, а представление визуализирует эти отношения.

Виды тестирования

Unit-тестирование

К самому низкому уровню относится Unit-тестирование или компонентное тестирование, которое проверяет работоспособность Модели. Задача компонентного тестирования заключается в проверке всех возможных комбинаций взаимодействия с Моделью. Например, для Модели Пользователь нужно проверить, что ее нельзя сохранить без адреса электронной почты, что поле «Имя» не может быть короче двух символов, а в поле «Дата Рождения» нельзя записать буквы. Из моей практики такие простейшие проверки сокращают существенное количество ошибок в сложных системах.

Функциональное тестирование

Функциональное тестирование проверяет работу контроллера – объекта системы, который является промежуточным звеном между Моделью и Представлением. С одной стороны, Контроллер создает объекты Модели, вызывает их методы, меняет содержимое, а с другой он должен коммуницировать с Представлением, которое показывает эти Модели на экране пользователя. Протестировать контроллер нужно на параметры, которые подаются на входе. Например, что пользователь ввел корректные данные, и система смогла создать новую Модель (запись в базе данных). Или в случае возникновении ошибки при изменении Модели, система выдала сообщение об ошибке, и Модель не сохранилась. Если в контроллере реализована проверка полномочий доступа к объектам, то такие вещи тоже проверяются тестами, чтобы быть уверенными в целостности системы безопасности. Из моей практики порядка 60-70% тестов приходится на Контроллеры, так как большая часть бизнес-логики приложений заложена именно в них.

Интеграционное тестирование

Интеграционное тестирование замыкает цикл автоматизированного тестирования и является самым верхнеуровневым. При интеграционном автоматизированном тестировании система воспроизводит все возможные действия человека: нажимает на кнопочки, открывает страницы, вводит верные и неверные данные в поля. Тесты должны покрывать возможные комбинации операций и отслеживать реакцию системы на положительный и отрицательный результат.

Ситуационная модель и организация процесса тестирования

Представьте сложную систему с десятками страниц, множеством полей, кнопочек, переходов. Когда реализуется новая функция в такой системе, то она может затронуть уже существующий функционал. Простейшее увеличение длинны пароля может привести к краху. На курсах по программированию учат, что такие переменные нужно параметризировать, создавать справочник констант, где одним движением можно изменить длину переменной сразу во всех местах кода. Но