testomat.io управление авто тестамиСуществует несколько специфических трендов, наметившихся в том, как мы производим автоматизацию тестов на основе пользовательского интерфейса. Технологии ушли вперед, были созданы новые интерфейсы, и в результате, также были созданы и новые инструменты, для того, чтобы «парировать этот удар» и, таким образом автоматизация тестирования была изменена.
Эволюция
Давайте немного вернемся назад и посмотрим, как развивались инструменты и фреймворки по автоматизации тестирования.
- Главным в любом фреймворке автоматизации является процессор ядра системы.
- Традиционный набор инструментов записи и воспроизведения находится над этим ядром.
- Так как скрипты, сделанные с помощью record&playback, имели проблемы с устойчивостью и сложностью, поэтому это стало причиной того, что был добавлен новый слой – а именно самописные фреймворки
Что представляют собой эти фреймворки? Это фреймворки с написанием кастомизированных скриптов для выполнения усовершенствования записи и воспроизведения. Мы знаем эти фреймворки под разными названиями, но, в любом случае, чаще всего все выглядит следующим образом.
Я не собираюсь углубляться в специфику указанных выше фреймворков. Но очень важно заметить, что чаще всего, когда кто-либо собирается создать фреймворк, используя 4 указанных выше типа, в результате, получается гибридное решение - комбинация различных фреймворков.
Фреймворки работают и занимают заметное положение уже довольно длительный период времени, также существует большое количество инструментов и утилит для них. В любом случае, существовала необходимость написания тестов на новом языке. Необходимо было что-то, что было бы проще для не-кодеров (например для бизнес аналитиков), что-то что они могли бы читать, понимать и во что могли бы вносить свой вклад.
Это дало рост новому типу методологии и фреймворкам для создания автоматизированных тестов - BDD – Behavior Driven Development (Разработке, основанной на функционировании). На рынке существует много инструментов для BDD, а именно, Cucumber, JBehave, RSpec, Twist, и так далее.
Интересно заметить, что BDD находится наверху кастомизированных фреймворков. Таким образом, мы создаем слой на слое. Это важно потому, что мы не хотим повторно изобретать колесо. Вместо этого мы хотим повторно использовать то, что у нас уже есть (настолько, насколько это возможно), пока не достигнем точки, в которой новый дизайн и переписывание уже существующего станет необходимыми. Но это уже тема для отдельного разговора.
BDD фреймворки также используются уже довольно долго. Думая об этом, я задаюсь вопросом – ЧТО будет дальше?
Развитие пользовательских интерфейсов
Чтобы ответить на вопрос – “Что будет дальше?” нам необходимо понять природу развития пользовательских интерфейсов, которое имело место в последние пару десятилетий.
Как много из нас еще помнят ЭЛТ-мониторы, за которыми мы работали еще несколько лет назад? Сами по себе эти мониторы эти мониторы прошли через большие изменения за последние 2 десятилетия. Затем появились удивительные, тонкие, плоские панели LCD. Преимущества LCD по сравнению с ЭЛТ хорошо известны.
А как насчет первого поколения больших, громоздких ноутбуков, требующих мощного источника питания? Сравните их с теми, которые можно купить сегодня, изменились быстрота обработки, портативность, ресурс аккумулятора, и, конечно же, что важно в контексте нашей дискуссии, цвета и разрешение, которые доступны нам теперь. Затем появились планшетные ПК, старт которых не был так блистателен, как некоторые это пророчили, но, в любом случае, это подтверждает, что за короткий срок произошли значительные изменения, не так ли?
Последним поколением портативных компьютеров стали нетбуки – чрезвычайно портативные, довольно мощные, с большим ресурсом аккумулятора и с хорошими характеристиками пользовательского интерфейса.
Еще одна категория девайсов уже начала менять способ нашей работы.
Для примера приведу картинки ниже: женщина просматривает каталог наручных часов с помощью абсолютно отличающегося от привычных нам интерактивного интерфейса, который контролируется (позволяет просмотреть, увеличить, выбрать и так далее) с помощью движений рук.
Другой пример: человек на фото ниже редактирует изображения используя свои руки, вместо каких-либо девайсов в руке.
Еще пример: ребенок на фото рисует с помощью абсолютно нового интерактивного интерфейса, который контролируется (просмотр, увеличение, выбор и так далее) с помощью жестов рук.
Последний пример: человек на фото редактирует изображения используя свои руки, вместо использования каких-либо девайсов в руке.
Вы спросите, как это повлияет на конечного пользователя? Как это связано с автоматизацией тестирования?
Ну, ответ довольно прост. Эти изменения пользовательского интерфейса стали причиной настоящего бума в сфере программного обеспечения. Изменение или написание нового программного обеспечения стали новой вертикалью в разработке и тестировании программного обеспечения.
Посмотрите на смартфоны (iPhone, смартфоны на Android, и так далее). Сегодня эти девайсы умеют так много, что у вас просто безграничные возможности для разработки. Ими можно управлять, используя обычные кнопки, прикосновения или стилус.
Посмотрите, как изменился Интернет. На всех основных порталах, вы можете создать собственную страницу, которая будет настроена на основе ваших собственных предпочтений. И для выполнения всего этого нет необходимости производить значительные изменения конфигурации или привлекать системного администратора. Все это можно сделать с помощью нескольких движений мышки. Пример: на картинке ниже показана страничка Yahoo с виджетами, которые можно организовать в порядке предпочтений, таким образом, вы будете видеть именно то, что вы хотите увидеть.
Что будет дальше?
Сейчас весь мир движется в направлении предоставления контента или выполнения действий, основанных на «взаимодействии».
Если вы помните фильм “The Minority Report”, технологии, показанные там просто удивительны. В фильме, снятом в 1950 г., актеры работают с изображениями, видео, голосами, используя исключительно жесты. Эта технология была разработана лабораториями MIT (Массачусетского технологического института) специально для этого фильма, а после работы, которую проводили в последние несколько лет эта технология была показана в « TED talks» Джона Андеркоффлера. На самом деле он верит, что в ближайшие годы эта технология станет мейнстримом, который будут использовать все. Он называет эту технология “Пространственной операционной средой ”.
Проще говоря, я называю это “Технологией основанной на жестах”. Это будущее к которому мы уже очень близки!
А как это повлияет на автоматизацию тестирования? Я считаю, что основное влияние будет следующим:
- Естественно, мы будем разрабатывать программное обеспечение для работы с такими технологиями.
- Если мы разрабатываем программное обеспечение, это означает, что нам будет необходимо его тестировать.
- А это, в свою очередь, означает, что нам необходима будет автоматизация.
Нам уже сейчас необходимо задумываться о том, как мы - тестеры, будем производить тестирование в этой новой среде? Какие инструменты будут необходимы нам для эффективного тестирования? В конце-концов, давайте думать масштабно – почему мы не можем создать / написать автоматизированные тесты, используя такие же интерфейсы?
UDD – разработка основанная на пользовательском интерфейсе
Если пользователь системы может взаимодействовать с ней, используя жесты, почему мы, тестеры, не можем изменить способ написания тестов? Зачем нам полагаться на кодирование или написание тестов в формате BDD? Если изображение говорит тысячей слов, почему бы нам не поднять планку и не писать тесты, используя другой, интерактивный формат?
Я предполагаю, что UDD фреймворки будут включать следующие компоненты:
Некоторые из этих компонентов не требуют объяснений. В любом случае, существуют некоторые основные компоненты, о которых я хотел бы поговорить.
Плагин менеджер
Весь этот фреймворк будет построен на плагинах. В нем будет набор основных плагинов, создающих эту среду, а также различные другие плагины, разработанных и добавленных специалистами в зависимости от их потребностей, требований и видения.
Другим важным аспектом этой среды будет то, что необходимость добавления новых плагинов не будет означать необходимости перезагрузки всего фреймворка. Механизм ‘hot-deployment’ (быстрой перегруппировки) будет доступен для того, чтобы сделать возможным добавление новых плагинов в среду.
Примеры плагинов включают :
- Утилиты xPath
- Система записи – генерация кода на указанном языке
- Настроенные генераторы отчетов / анализ тенденции
- Генераторы данных тестов
- Планировщики / интеграция с системами непрерывной интеграции
- Язык / поддержка драйверов – Я верю, что основополагающий фреймворк должен легко изменяться нажатием кнопки (при условии, что все необходимые плагины доступны). Таким способом администратор сможет переходить, например, с Selenium к Sahi просто выбрав какой фреймворк использовать. Точно также должен быть доступен выбор языка для генерации кода.
- Интеграция с внешними инструментами и архивами данных – например: file diff / compare tools, и так далее.
Discovery
Для меня эта часть чрезвычайно важна и критична, ведь мы хотим быть уверены в том, что нам не нужно будет опять изобретать колесо. Мы хотели бы и далее использовать уже существующие фреймворки настолько широко, насколько это возможно и сделать переход к UDD максимально незаметным.
Этот компонент должен дать возможность декомпиляции существующей базы кодов и создания иерархии объектов пользовательского интерфейса, доступных в панели / хранилище. Пример: после запуска discovery tool против существующего исходного хранилища, объекты пользовательского интерфейса будут создаваться следующим образом:
Автор
Для создания новых объектов / скриптов тестов, автор теста будет использовать объекты пользовательского интерфейса с панели/ хранилища, и, ‘просто’ перетаскивать различные объекты пользовательского интерфейса для создания новых объектов/ скриптов тестов. Все ‘разумные’ реорганизации и реструктуризации кода будут производиться автоматически в бекэнде. Посмотрите на изображение ниже для дополнительной информации.
Примечание: в настоящий момент мы можем это сделать до определенной степени. Используя инструменты для обратного декодирования, мы можем создать диаграммы классов / UML диаграммы из существующего кода.
В контексте UDD, в настоящее время существуют модели объектов. Нам необходимо выполнить эти объекты на основе пользовательского интерфейса, при передвижении которых во фреймворке будут производиться соответствующие изменения в коде, без необходимости для пользователя выполнять это самостоятельно.
Это предлагает высший уровень, а также наглядное представление для людей, которые смотрят на эти тесты.
Вместе с тем, при необходимости добавления нового функционала в основание кода, автор теста может просто написать код именно для этого, а UDD фреймворк создаст подходящий объект пользовательского интерфейса из него, а также добавит его в хранилище для общего пользования.
Механизм исполнения
Механизм исполнения предоставляет довольно значительную гибкость в том, как должны проводиться тесты. Вот несколько разных мнений:
- Проводить тесты внутри UDD фреймворка
- Создать команду для набора тестов, которые пользователь желает произвести которые можно будет просто скопировать и вставить в командную строку и выполнить тесты напрямую, без необходимости беспокоиться/думать о том, какую команду необходимо запускать.
- Давать возможность выполнять тесты на той же машине, удаленных машинах, или с помощью желаемых комбинаций.
- Может приводиться в действие инструментами непрерывной интеграции.
Генератор отчетов
Мы привыкли видеть предустановленные, хотя и довольно понятные отчеты, сгенерированные различными фреймворками для тестирования (jUnit, nUnit, TestNG, и так далее.). Но, в любом случае, то чего определенно не хватает – возможность консолидировать отчеты по разным циклам и отправить в архив, создать анализ тенденций и графики различных типов, которые могут быть полезны для того, чтобы отследить состояние системы.
Должен быть предустановленный набор плагинов отчетов, который предложит этот механизм. Также, так-как эта архитектура основана на плагинах, специалисты смогут внести свою лепту, создав генераторы, соответствующие конкретным требованиям.
Как мы сможем прийти к этому?
Я поделился своим видением будущего автоматизации. Следующим важным вопросом будет то, что мы сможем сделать для того, чтобы подготовиться к этому будущему, каким бы оно не было? Если мы сможем отследить некоторые практики, при автоматизации тестов, мы будем готовы к будущему, каким бы оно не было.
- Тестовый код должен быть пригодным для промышленного применения!
- Используйте частные / защищенные поля / методы. Делайте их достоянием общественности только в случае, если это абсолютно необходимо.
- Импортируйте только те классы, которые вам действительно необходимы. Избегайте импорта abc.*
- Держите намерения проведения теста отдельно от внедрения.
- Используйте xPaths очень осторожно. НЕ используйте индексы.
- Не копируйте / вставляйте код из других источников не понимая его полностью.
- Держите данные по тестам отдельно от скриптов тестов.
- Дублирование кода не допускается
Но все правда, подписываюсь под каждым словом