Тестирование приложений. Обеспечения Базовый курс (3е издание) Версия книги 15 от 31. 03. 2022
 Скачать 5.07 Mb.
|
|
3.2. Особенности автоматизированного тестирования 3.2.1. Необходимые знания и навыки Во множестве источников, посвящённых основам автоматизации тестирова- ния, можно встретить схемы наподобие представленной на рисунке 3.2.a — то есть автоматизация тестирования представляет собой сочетание программирования и тестирования в разных масштабах (в зависимости от проекта и конкретных задач). Рисунок 3.2.a — Сочетание программирования и тестирования в автоматизации тестирования Отсюда следует простой вывод, что специалист по автоматизации тестиро- вания должен сочетать в себе навыки и умения как программиста, так и тестиров- щика. Но этим перечень не заканчивается: умение администрировать операцион- ные системы, сети, различные серверы, умение работать с базами данных, пони- мание мобильных платформ и т.д. — всё это может пригодиться. Но даже если остановиться только на навыках программирования и тестиро- вания, в автоматизации тоже есть свои особенности — набор технологий. В клас- сическом ручном тестировании развитие происходит постепенно и эволюционно — проходят годы и даже десятилетия между появлением новых подходов, завоёвы- вающих популярность. В программировании прогресс идёт чуть быстрее, но и там специалистов выручает согласованность и схожесть технологий. В автоматизации тестирования ситуация выглядит иначе: десятки и сотни технологий и подходов (как заимствованных из смежных дисциплин, так и уникаль- ных) появляются и исчезают очень стремительно. Количество инструментальных средств автоматизации тестирования уже исчисляется тысячами и продолжает неуклонно расти. Потому к списку навыков тестировщика можно смело добавить крайне высо- кую обучаемость и способность в предельно сжатые сроки самостоятельно найти, изучить, понять и начать применять на практике совершенно новую информацию из, возможно, ранее абсолютно незнакомой области. Звучит немного пугающе, но одно можно гарантировать: скучно не будет точно. О нескольких наиболее распространённых технологиях мы поговорим в главе «Технологии автоматизации тестирования» {266} Автоматизация тестирования Програм- мирование Програм- мирование Тестиро- вание Тести- ро- вание Тестиро- вание Прог- рамми- рование Особенности тест-кейсов в автоматизации Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 262/298 3.2.2. Особенности тест-кейсов в автоматизации Часто (а в некоторых проектах и «как правило») автоматизации подвергаются тест-кейсы, изначально написанные простым человеческим языком (и, в принципе, пригодные для выполнения вручную) — т.е. обычные классические тест-кейсы, ко- торые мы уже рассматривали подробно в соответствующей главе {117} И всё же есть несколько важных моментов, которые стоит учитывать при раз- работке (или доработке) тест-кейсов, предназначенных для дальнейшей автомати- зации. Главная проблема состоит в том, что компьютер — это не человек, и соот- ветствующие тест-кейсы не могут оперировать «интуитивно понятными описани- ями», а специалисты по автоматизации совершенно справедливо не хотят тратить время на то, чтобы дополнить такие тест-кейсы необходимыми для выполнения ав- томатизации техническими подробностями, — у них хватает собственных задач. Отсюда следует список рекомендаций по подготовке тест-кейсов к автомати- зации и непосредственно самой автоматизации: • Ожидаемый результат в автоматизированных тест-кейсах должен быть опи- сан предельно чётко с указанием конкретных признаков его корректности. Сравните: Плохо Хорошо … 7. Загружается стандартная страница по- иска. … 7. Загружается страница поиска: title = «Search page», присутствует форма с по- лями «input type="text"», «input type="submit" value="Go!" », присутствует логотип «logo.jpg» и отсутствуют иные гра- фические элементы («img»). • Поскольку тест-кейс может быть автоматизирован с использованием различ- ных инструментальных средств, следует описывать его, избегая специфиче- ских для того или иного инструментального средства решений. Сравните: Плохо Хорошо 1. Кликнуть по ссылке «Search». 2. Использовать clickAndWait для синхро- низации тайминга. 1. Кликнуть по ссылке «Search». 2. Дождаться завершения загрузки стра- ницы. • В продолжение предыдущего пункта: тест-кейс может быть автоматизирован для выполнения под разными аппаратными и программными платформами, потому не стоит изначально прописывать в него что-то, характерное лишь для одной платформы. Сравните: Плохо Хорошо … 8. Отправить приложению сообщение WM_CLICK в любое из видимых окон. … 8. Передать фокус ввода любому из не свёрнутых окон приложения (если таких нет — развернуть любое из окон). 9. Проэмулировать событие «клик левой кнопкой мыши» для активного окна. • Одной из неожиданно проявляющихся проблем до сих пор является синхро- низация средства автоматизации и тестируемого приложения по времени: в случаях, когда для человека ситуация является понятной, средство автома- тизации тестирования может среагировать неверно, «не дождавшись» опре- делённого состояния тестируемого приложения. Это приводит к завершению неудачей тест-кейсов на корректно работающем приложении. Сравните: Особенности тест-кейсов в автоматизации Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 263/298 Плохо Хорошо 1. Кликнуть по ссылке «Expand data». 2. Выбрать из появившегося списка значе- ние «Unknown». 1. Кликнуть по ссылке «Expand data». 2. Дождаться завершения загрузки данных в список «Extended data» (select id="ex- tended_data" ): список перейдёт в состояние enabled. 3. Выбрать в списке «Extended data» значе- ние «Unknown». • Не стоит искушать специалиста по автоматизации на вписывание в код тест- кейса константных значений (т.н. «хардкодинг»). Если вы можете понятно описать словами значение и/или смысл некоей переменной, сделайте это. Сравните: Плохо Хорошо 1. Открыть http://application/. 1. Открыть главную страницу приложения. • По возможности следует использовать наиболее универсальные способы взаимодействия с тестируемым приложением. Это значительно сократит время поддержки тест-кейсов в случае, если изменится набор технологий, с помощью которых реализовано приложение. Сравните: Плохо Хорошо … 8. Передать в поле «Search» набор собы- тий WM_KEY_DOWN, {знак}, WM_KEY_UP, в результате чего в поле должен быть вве- дён поисковый запрос. … 8. Проэмулировать ввод значения поля «Search» с клавиатуры (не годится вставка значения из буфера или прямое присваи- вание значения!) • Автоматизированные тест-кейсы должны быть независимыми. Из любого правила бывают исключения, но в абсолютном большинстве случаев сле- дует предполагать, что мы не знаем, какие тест-кейсы будут выполнены до и после нашего тест-кейса. Сравните: Плохо Хорошо 1. Из файла, созданного предыдущим те- стом… 1. Перевести чек-бокс «Use stream buffer file » в состояние checked. 2. Активировать процесс передачи данных (кликнуть по кнопке «Start»). 3. Из файла буферизации прочитать… • Стоит помнить, что автоматизированный тест-кейс — это программа, и стоит учитывать хорошие практики программирования хотя бы на уровне отсут- ствия т.н. «магических значений», «хардкодинга» и тому подобного. Срав- ните: Плохо Хорошо if ($date_value == '2015.06.18') { … } if ($status = 42) { … } if ($date_value == date('Y.m.d')) { … } if (POWER_USER == $status) { … } «Хардкодинг» «Магическое значение» Ошибка в выражении (= вместо ==) Актуальные данные Осмысленная константа Ошибка исправлена, к тому же константа в сравнении нахо- дится слева от переменной Особенности тест-кейсов в автоматизации Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 264/298 • Стоит внимательно изучать документацию по используемому средству авто- матизации, чтобы избежать ситуации, когда из-за неверно выбранной ко- манды тест-кейс становится ложно положительным, т.е. успешно проходит в ситуации, когда приложение работает неверно. Так называемые ложно положительные тест-кейсы — едва ли не са- мое страшное, что бывает в автоматизации тестирования: они все- ляют в проектную команду ложную уверенность в том, что приложе- ние работает корректно, т.е. фактически прячут дефекты, вместо того, чтобы обнаруживать их. Поскольку для многих начинающих тестировщиков первым учебным сред- ством автоматизации тестирования является Selenium IDE 368 , приведём при- мер с его использованием. Допустим, в некотором шаге тест-кейса нужно было проверить, что чек-бокс с id=cb выбран (checked). По какой-то причине тестировщик выбрал неверную команду, и сейчас на этом шаге проверятся, что чек-бокс позволяет изменять своё состояние (enabled, editable), а не что он выбран. Плохо (неверная команда) Хорошо (верная команда) … … … verifyEditable id=cb … … … … … … verifyChecked id=cb … … … • И напоследок рассмотрим ошибку, которую по какой-то мистической причине совершает добрая половина начинающих автоматизаторов — это замена проверки действием и наоборот. Например, вместо проверки значения поля они изменяют значение. Или вместо изменения состояния чек-бокса прове- ряют его состояние. Здесь не будет примеров на «плохо/хорошо», т.к. хоро- шего варианта здесь нет — такого просто не должно быть, т.к. это — грубей- шая ошибка. Кратко подытожив рассмотренное, отметим, что тест-кейс, предназначенный для автоматизации, будет куда более похож на миниатюрное техническое задание по разработке небольшой программы, чем на описание корректного поведения те- стируемого приложения, понятное человеку. И ещё одна особенность автоматизированных тест-кейсов заслуживает от- дельного рассмотрения — это источники данных и способы их генерации. Для вы- полняемых вручную тест-кейсов эта проблема не столь актуальна, т.к. при выпол- нении 3–5–10 раз мы также вручную вполне можем подготовить нужное количество вариантов входных данных. Но если мы планируем выполнить тест-кейс 50–100– 500 раз с разными входными данными, вручную столько данных мы не подготовим. Источниками данных в такой ситуации могут стать: • Случайные величины: случайные числа, случайные символы, случайные элементы из некоторого набора и т.д. • Генерация (случайных) данных по алгоритму: случайные числа в заданном диапазоне, строки случайной длины из заданного диапазона из случайных символов из определённого набора (например, строка длиной от 10 до 100 символов, состоящая только из букв), файлы с увеличивающимся по некоему правилу размером (например, 10 КБ, 100 КБ, 1000 КБ и т.д.). 368 Selenium IDE. [ https://www.selenium.dev/selenium-ide/ ] Особенности тест-кейсов в автоматизации Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 265/298 • Получение данных из внешних источников: извлечение данных из базы дан- ных, обращение к некоему веб-сервису и т.д. • Собранные рабочие данные, т.е. данные, созданные реальными пользовате- лями в процессе их реальной работы (например, если бы мы захотели раз- работать собственный текстовый редактор, тысячи имеющихся у нас и наших коллег doc(x)-файлов были бы такими рабочими данными, на которых мы бы проводили тестирование). • Ручная генерация — да, она актуальная и для автоматизированных тест-кей- сов. Например, вручную создать по десять (да даже и по 50–100) корректных и некорректных e-mail-адресов получится куда быстрее, чем писать алгоритм их генерации. Применение некоторых из этих идей по генерации данных мы рассмотрим подробнее в следующей главе. Технологии автоматизации тестирования Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 266/298 3.2.3. Технологии автоматизации тестирования В данной главе мы рассмотрим несколько высокоуровневых технологий ав- томатизации тестирования, каждая из которых, в свою очередь, базируется на своём наборе технических решений (инструментальных средствах, языках про- граммирования, способах взаимодействия с тестируемым приложением и т.д.). Начнём с краткого обзора эволюции высокоуровневых технологий, при этом подчеркнув, что «старые» решения по-прежнему используются (или как компо- ненты «новых», или самостоятельно в отдельных случаях). Таблица 3.2.a — Эволюция высокоуровневых технологий автоматизации тестиро- вания № Подход Суть Преимущества Недостатки 1 Частные решения. Для решения каждой отдельной задачи пишется отдельная программа. Быстро, просто. Нет системности, много времени ухо- дит на поддержку. Почти невозможно повторное использо- вание. 2 Тестирование под управлением дан- ными {90} (DDT). Из тест-кейса вовне выносятся входные данные и ожидае- мые результаты. Один и тот же тест- кейс можно повто- рять многократно с разными данными. Логика тест-кейса по- прежнему строго определяется внутри, а потому для её изменения тест- кейс надо переписы- вать. 3 Тестирование под управлением ключе- выми словами {90} (KDT). Из тест-кейса вовне выносится описание его поведения. Концентрация на вы- сокоуровневых дей- ствиях. Данные и особенности поведе- ния хранятся вовне и могут быть изменены без изменения кода тест-кейса. Сложность выполне- ния низкоуровневых операций. 4 Использование фреймворков. Конструктор, позво- ляющий использо- вать остальные под- ходы. Мощность и гиб- кость. Относительная сложность (особенно — в создании фреймворка). 5 Запись и воспроиз- ведение (Record & Playback). Средство автомати- зации записывает действия тестиров- щика и может вос- произвести их, управляя тестируе- мым приложением. Простота, высокая скорость создания тест-кейсов. Крайне низкое каче- ство, линейность, не- поддерживаемость тест-кейсов. Требу- ется серьёзная дора- ботка полученного кода. Технологии автоматизации тестирования Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 267/298 6 Тестирование под управлением пове- дением {90} (BDT). Развитие идей тести- рования под управ- лением данными и ключевыми словами. Отличие — в концен- трации на бизнес- сценариях без вы- полнения мелких проверок. Высокое удобство проверки высоко- уровневых пользова- тельских сценариев. Такие тест-кейсы пропускают большое количество функцио- нальных и нефункци- ональных дефектов, а потому должны быть дополнены классическими бо- лее низкоуровне- выми тест-кейсами. На текущем этапе развития тестирования представленные в таблице 3.2.a технологии иерархически можно изобразить следующей схемой (см. рисунок 3.2.b): Рисунок 3.2.b — Иерархия технологий автоматизации тестирования Сейчас мы рассмотрим эти технологии подробнее и на примерах, но сначала стоит упомянуть один основополагающий подход, который находит применение практически в любой технологии автоматизации, — функциональную декомпози- цию. Функциональная декомпозиция Функциональная декомпозиция (functional decomposition 369 ) — процесс определения функции через её разделение на несколько низкоуровневых подфункций. Функциональная декомпозиция активно используется как в программирова- нии, так и в автоматизации тестирования с целью упрощения решения поставлен- ных задач и получения возможности повторного использования фрагментов кода для решения различных высокоуровневых задач. Рассмотрим пример (рисунок 3.2.c): легко заметить, что часть низкоуровне- вых действий (поиск и заполнение полей, поиск и нажатие кнопок) универсальна и может быть использована при решении других задач (например, регистрация, оформление заказа и т.д.). 369 Functional decomposition. The process of defining lower-level functions and sequencing relationships. [ «System Engineering Fundamentals », Defense Acquisition University Press] Использование фреймворков Запись и воспроизведение Тестирование под управлением данными Тестирование под управлением ключевыми словами Комбинация тестирование под управлением данными и ключевыми словами Тестирование под управлением поведением Технологии автоматизации тестирования Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 268/298 Рисунок 3.2.c — Пример функциональной декомпозиции в программировании и те- стировании Применение функциональной декомпозиции позволяет не только упростить процесс решения поставленных задач, но и избавиться от необходимости самосто- ятельной реализации действий на самом низком уровне, т.к. они, как правило, уже решены авторами соответствующих библиотек или фреймворков. Возвращаемся к технологиям автоматизации тестирования. Частные решения Иногда перед тестировщиком возникает уникальная (в том плане, что такой больше не будет) задача, для решения которой нет необходимости использовать мощные инструментальные средства, а достаточно написать небольшую про- грамму на любом из высокоуровневых языков программирования (Java, C#, PHP и т.д.) или даже воспользоваться возможностями командных файлов операционной системы или подобными тривиальными решениями. Ярчайшим примером такой задачи и её решения является автоматизация дымового тестирования нашего «Конвертера файлов» (код командных файлов для Windows и Linux приведён в соответствующем приложении {281} ). Также сюда можно отнести задачи вида: • Подготовить базу данных, наполнив её тестовыми данными (например, до- бавить в систему миллион пользователей со случайными именами). • Подготовить файловую систему (например, создать структуру каталогов и набор файлов для выполнения тест-кейсов). • Перезапустить набор серверов и/или привести их в требуемое состояние. Удобство частных решений состоит в том, что их можно реализовать быстро, просто, «вот прямо сейчас». Но у них есть и огромный недостаток — это «кустарные решения», которыми может воспользоваться всего пара человек. И при появлении новой задачи, даже очень похожей на ранее решённую, скорее всего, придётся всё автоматизировать заново. Более подробно преимущества и недостатки частных решений в автомати- зации тестирования показаны в таблице 3.2.b. Произвести авторизацию Ввести имя пользователя Ввести пароль Отправить данные Проверить результат Найти поле Запол- нить поле Найти поле Запол- нить поле Найти кнопку На- жать кнопку Найти над- пись Срав- нить над- пись Технологии автоматизации тестирования Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 269/298 Таблица 3.2.b — Преимущества и недостатки частных решений в автоматизации тестирования Преимущества Недостатки • Быстрота и простота реализации. • Возможность использования любых доступ- ных инструментов, которыми тестировщик умеет пользоваться. • Эффект от использования наступает неза- медлительно. • Возможность нахождения очень эффектив- ных решений в случае, когда основные ин- струменты, используемые на проекте для ав- томатизации тестирования, оказываются ма- лопригодными для выполнения данной от- дельной задачи. • Возможность быстрого создания и оценки прототипов перед применением более тяже- ловесных решений. • Отсутствие универсальности и, как след- ствие, невозможность или крайняя слож- ность повторного использования (адаптации для решения других задач). • Разрозненность и несогласованность реше- ний между собой (разные подходы, техноло- гии, инструменты, принципы решения). • Крайне высокая сложность развития, под- держки и сопровождения таких решений (чаще всего, кроме самого автора никто во- обще не понимает, что и зачем было сде- лано, и как оно работает). • Является признаком «кустарного производ- ства», не приветствуется в промышленной разработке программ. Тестирование под управлением данными (DDT) Обратите внимание, как много раз в командных файлах {281} повторяются строки, выполняющие одно и то же действие над набором файлов (и нам ещё по- везло, что файлов немного). Ведь куда логичнее было бы каким-то образом подго- товить список файлов и просто передать его на обработку. Это и будет тестирова- нием под управлением данными. В качестве примера приведём небольшой скрипт на PHP, который читает CSV-файл с тестовыми данными (именами сравниваемых файлов) и выполняет сравнение файлов. function compare_list_of_files($file_with_csv_data) { $data = file($file_with_csv_data); foreach ($data as $line) { $parsed = str_csv($line); if (md5_file($parsed[0]) === md5_file($parsed[1])) { file_put_contents('smoke_test.log', "OK! File '".$parsed[0]."' was processed correctly!\n"); } else { file_put_contents('smoke_test.log', "ERROR! File '".$parsed[0]."' was NOT processed correctly!\n"); } } } Пример CSV-файла (первые две строки): Test_ETALON/«Мелкий» эталон WIN1251.txt,OUT/«Мелкий» файл в WIN1251.txt Test_ETALON/«Средний» эталон CP866.txt,OUT/«Средний» файл CP866.txt Теперь нам достаточно подготовить CSV-файл с любым количеством имён сравниваемых файлов, а код тест-кейса не увеличится ни на байт. К другим типичным примерам использования тестирования под управлением данными относится: • Проверка авторизации и прав доступа на большом наборе имён пользовате- лей и паролей. Технологии автоматизации тестирования Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 270/298 • Многократное заполнение полей форм разными данными и проверка реак- ции приложения. • Выполнение тест-кейса на основе данных, полученных с помощью комбина- торных техник (пример таких данных представлен в соответствующем при- ложении {290} ). Данные для рассматриваемого подхода к организации тест-кейсов могут по- ступать из файлов, баз данных и иных внешних источников или даже генериро- ваться в процессе выполнения тест-кейса (см. описание источников данных для ав- томатизированного тестирования {264} ). Преимущества и недостатки тестирования под управлением данными пока- заны в таблице 3.2.c. Таблица 3.2.c — Преимущества и недостатки тестирования под управлением дан- ными Преимущества Недостатки • Устранение избыточности кода тест-кейсов. • Удобное хранение и понятный человеку фор- мат данных. • Возможность поручения генерации данных сотруднику, не имеющему навыков програм- мирования. • Возможность использования одного и того же набора данных для выполнения разных тест-кейсов. • Возможность повторного использования набора данных для решения новых задач. • Возможность использования одного и того же набора данных в одном и том же тест- кейсе, но реализованном под разными плат- формами. • При изменении логики поведения тест-кейса его код всё равно придётся переписывать. • При неудачно выбранном формате пред- ставления данных резко снижается их понят- ность для неподготовленного специалиста. • Необходимость использования технологий генерации данных. • Высокая сложность кода тест-кейса в случае сложных неоднородных данных. • Риск неверной работы тест-кейсов в случае, когда несколько тест-кейсов работают с од- ним и тем же набором данных, и он был из- менён таким образом, на который не были рассчитаны некоторые тест-кейсы. • Слабые возможности по сбору данных в слу- чае обнаружения дефектов. • Качество тест-кейса зависит от профессио- нализма сотрудника, реализующего код тест- кейса. Тестирование под управлением ключевыми словами Логическим развитием идеи о вынесении вовне тест-кейса данных является вынесение вовне тест-кейса команд (описания действий). Разовьём только что по- казанный пример, добавив в CSV-файл ключевые слова, являющиеся описанием выполняемой проверки: • moved — файл отсутствует в каталоге-источнике и присутствует в каталоге- приёмнике; • intact — файл присутствует в каталоге-источнике и отсутствует в каталоге- приёмнике; • equals — содержимое файлов идентично. function execute_test($scenario) { $data = file($scenario); foreach ($data as $line) { $parsed = str_csv($line); switch ($parsed[0]) { Технологии автоматизации тестирования Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 271/298 // Проверка перемещения файла case 'moved': if (is_file($parsed[1]))&&(!is_file($parsed[2])) { file_put_contents('smoke_test.log', "OK! '".$parsed[0]."' file was processed!\n"); } else { file_put_contents('smoke_test.log', "ERROR! '".$parsed[0]."' file was NOT processed!\n"); } break; // Проверка отсутствия перемещения файла case 'intact': if (!is_file($parsed[1]))||(is_file($parsed[2])) { file_put_contents('smoke_test.log', "OK! '".$parsed[0]."' file was processed!\n"); } else { file_put_contents('smoke_test.log', "ERROR! '".$parsed[0]."' file was NOT processed!\n"); } break; // Сравнение файлов case 'equals': if (md5_file($parsed[1]) === md5_file($parsed[2])) { file_put_contents('smoke_test.log', "OK! File '".$parsed[0]."' Was processed correctly!\n"); } else { file_put_contents('smoke_test.log', "ERROR! File '".$parsed[0]."' Was NOT processed correctly!\n"); } break; } } } Пример CSV-файла (первые пять строк): moved,IN/«Мелкий» эталон WIN1251.txt,OUT/«Мелкий» файл в WIN1251.txt moved,IN/«Средний» эталон CP866.txt,OUT/«Средний» файл CP866.txt intact,IN/Картинка.jpg,OUT/Картинка.jpg equals,Test_ETALON/«Мелкий» эталон WIN1251.txt,OUT/«Мелкий» файл в WIN1251.txt equals,Test_ETALON/«Средний» эталон CP866.txt,OUT/«Средний» файл CP866.txt Ярчайшим примером инструментального средства автоматизации тестиро- вания, идеально следующего идеологии тестирования под управлением ключе- выми словами, является Selenium IDE 368 , в котором каждая операция тест-кейса описывается в виде: Действие (ключевое слово) Необязательный параметр 1 Необязательный параметр 2 Тестирование под управлением ключевыми словами стало тем переломным моментом, начиная с которого стало возможным привлечение к автоматизации те- стирования нетехнических специалистов. Согласитесь, что нет необходимости в знаниях программирования и тому подобных технологий, чтобы наполнять подоб- ные только что показанному CSV-файлы или (что очень часто практикуется) XLSX- файлы. Технологии автоматизации тестирования Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 272/298 Вторым естественным преимуществом тестирования под управлением клю- чевыми словами (хотя она вполне характерна и для тестирования под управлением данными) стала возможность использования различных инструментов одними и теми же наборами команд и данных. Так, например, ничто не мешает нам взять показанные CSV-файлы и написать новую логику их обработки не на PHP, а на C#, Java, Python или даже с использованием специализированных средств автомати- зации тестирования. Преимущества и недостатки тестирования под управлением ключевыми сло- вами показаны в таблице 3.2.d. Таблица 3.2.d — Преимущества и недостатки тестирования под управлением клю- чевыми словами Преимущества Недостатки • Максимальное устранение избыточности кода тест-кейсов. • Возможность построения мини-фреймвор- ков, решающих широкий спектр задач. • Повышение уровня абстракции тест-кейсов и возможность их адаптации для работы с раз- ными техническими решениями. • Удобное хранение и понятный человеку фор- мат данных и команд тест-кейса. • Возможность поручения описания логики тест-кейса сотруднику, не имеющему навы- ков программирования. • Возможность повторного использования для решения новых задач. • Расширяемость (возможность добавления нового поведения тест-кейса на основе уже реализованного поведения). • Высокая сложность (и, возможно, длитель- ность) разработки. • Высокая вероятность наличия ошибок в коде тест-кейса. • Высокая сложность (или невозможность) вы- полнения низкоуровневых операций, если фреймворк не поддерживает соответствую- щие команды. • Эффект от использования данного подхода наступает далеко не сразу (сначала идёт длительный период разработки и отладки са- мих тест-кейсов и вспомогательной функцио- нальности). • Для реализации данного подхода требуется наличие высококвалифицированного персо- нала. • Необходимо обучить персонал языку ключе- вых слов, используемых в тест-кейсах. Использование фреймворков Фреймворки автоматизации тестирования представляют собой не что иное, как успешно развившиеся и ставшие популярными решения, объединяющие в себе лучшие стороны тестирования под управлением данными, ключевыми словами и возможности реализации частных решений на высоком уровне абстракции. Фреймворков автоматизации тестирования очень много, они очень разные, но их объединяет несколько общих черт: • высокая абстракция кода (нет необходимости описывать каждое элементар- ное действие) с сохранением возможности выполнения низкоуровневых дей- ствий; • универсальность и переносимость используемых подходов; • достаточно высокое качество реализации (для популярных фреймворков). Как правило, каждый фреймворк специализируется на своём виде тестиро- вания, уровне тестирования, наборе технологий. Существуют фреймворки для мо- дульного тестирования (например, семейство xUnit), тестирования веб-приложений (например, семейство Selenium), тестирования мобильных приложений, тестирова- ния производительности и т.д. Существуют бесплатные и платные фреймворки, оформленные в виде биб- лиотек на некотором языке программирования или в виде привычных приложений с графическим интерфейсом, узко- и широко специализированные и т.д. Технологии автоматизации тестирования Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 273/298 К сожалению, подробное описание даже одного фреймворка может по объёму быть сопоставимо со всем текстом данной книги. Но если вам ин- тересно, начните хотя бы с изучения Selenium WebDriver 370 Преимущества и недостатки фреймворков автоматизации тестирования по- казаны в таблице 3.2.e. Таблица 3.2.e — Преимущества и недостатки фреймворков автоматизации тести- рования Преимущества Недостатки • Широкое распространение. • Универсальность в рамках своего набора технологий. • Хорошая документация и большое сообще- ство специалистов, с которыми можно про- консультироваться. • Высокий уровень абстракции. • Наличие большого набора готовых решений и описаний соответствующих лучших практик применения того или иного фреймворка для решения тех или иных задач. • Требуется время на изучение фреймворка. • В случае написания собственного фрейм- ворка де-факто получается новый проект по разработке ПО. • Высокая сложность перехода на другой фреймворк. • В случае прекращения поддержки фрейм- ворка тест-кейсы рано или поздно придётся переписывать с использованием нового фреймворка. • Высокий риск выбора неподходящего фреймворка. Запись и воспроизведение (Record & Playback) Технология записи и воспроизведения (Record & Playback) стала актуальной с появлением достаточно сложных средств автоматизации, обеспечивающих глу- бокое взаимодействие с тестируемым приложением и операционной системой. Ис- пользование этой технологии, как правило, сводится к следующим основным ша- гам: 1. Тестировщик вручную выполняет тест-кейс, а средство автоматизации запи- сывает все его действия. 2. Результаты записи представляются в виде кода на высокоуровневом языке программирования (в некоторых средствах — специально разработанном). 3. Тестировщик редактирует полученный код. 4. Готовый код автоматизированного тест-кейса выполняется для проведения тестирования в автоматизированном режиме. Возможно, вам приходилось записывать макросы в офисных приложе- ниях. Это тоже технология записи и воспроизведения, только применён- ная для автоматизации решения офисных задач. Сама технология при достаточно высокой сложности внутренней реализации очень проста в использовании и по самой своей сути, потому часто применяется для обучения начинающих специалистов по автоматизации тестирования. Её ос- новные преимущества и недостатки показаны в таблице 3.2.f. 370 Selenium WebDriver Documentation [ https://www.selenium.dev/documentation/en/webdriver/ ] Технологии автоматизации тестирования Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 274/298 Таблица 3.2.f — Преимущества и недостатки технологии записи и воспроизведения Преимущества Недостатки • Предельная простота освоения (достаточно буквально нескольких минут, чтобы начать использовать данную технологию). • Быстрое создание «скелета тест-кейса» за счёт записи ключевых действий с тестируе- мым приложением. • Автоматический сбор технических данных о тестируемом приложении (идентификаторов и локаторов элементов, надписей, имён и т.д.). • Автоматизация рутинных действий (заполне- ния полей, нажатий на ссылки, кнопки и т.д.). • В отдельных случаях допускает использова- ние тестировщиками без навыков програм- мирования. • Линейность тест-кейсов: в записи не будет циклов, условий, вызовов функций и прочих характерных для программирования и авто- матизации явлений. • Запись лишних действий (как просто ошибоч- ных случайных действий тестировщика с те- стируемым приложением, так и (во многих случаях) переключений на другие приложе- ния и работы с ними). • Так называемый «хардкодинг», т.е. запись внутрь кода тест-кейса конкретных значений, что потребует ручной доработки для пере- вода тест-кейса на технологию тестирования под управлением данными. • Неудобные имена переменных, неудобное оформление кода тест-кейса, отсутствие комментариев и прочие недостатки, усложня- ющие поддержку и сопровождение тест- кейса в будущем. • Низкая надёжность самих тест-кейсов в силу отсутствия обработки исключений, проверки условий и т.д. Таким образом, технология записи и воспроизведения не является универ- сальным средством на все случаи жизни и не может заменить ручную работу по написанию кода автоматизированных тест-кейсов, но в отдельных ситуациях может сильно ускорить решение простых рутинных задач. Тестирование под управлением поведением Рассмотренные выше технологии автоматизации максимально сфокусиро- ваны на технических аспектах поведения приложения и обладают общим недостат- ком: с их помощью сложно проверять высокоуровневые пользовательские сцена- рии (а именно в них и заинтересованы заказчики и конечные пользователи). Этот недостаток призвано исправить тестирование под управлением поведением, в ко- тором акцент делается не на отдельных технических деталях, а на общей работо- способности приложения при решении типичных пользовательских задач. Такой подход не только упрощает выполнение целого класса проверок, но и облегчает взаимодействие между разработчиками, тестировщиками, бизнес-ана- литиками и заказчиком, т.к. в основе подхода лежит очень простая формула «given- when-then »: • Given («имея, предполагая, при условии») описывает начальную ситуацию, в которой находится пользователь в контексте работы с приложением. • When («когда») описывает набор действий пользователя в данной ситуации. • Then («тогда») описывает ожидаемое поведение приложения. Рассмотрим на примере нашего «Конвертера файлов»: • При условии, что приложение запущено. • Когда я помещаю во входной каталог файл поддерживаемого размера и формата. • Тогда файл перемещается в выходной каталог, а текст внутри файла пере- кодируется в UTF-8. Технологии автоматизации тестирования Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 275/298 Такой принцип описания проверок позволяет даже участникам проекта, не имеющим глубокой технической подготовки, принимать участие в разработке и ана- лизе тест-кейсов, а для специалистов по автоматизации упрощается создание кода автоматизированных тест-кейсов, т.к. такая форма является стандартной, единой и при этом предоставляет достаточно информации для написания высокоуровне- вых тест-кейсов. Существуют специальные технические решения (например, Behat, JBehave, NBehave, Cucumber) , упрощающие реализацию тестирования под управ- лением поведением. Преимущества и недостатки тестирования под управлением поведением по- казаны в таблице 3.2.g. Таблица 3.2.g — Преимущества и недостатки тестирования под управлением пове- дением Преимущества Недостатки • Фокусировка на потребностях конечных пользователей. • Упрощение сотрудничества между различ- ными специалистами. • Простота и скорость создания и анализа тест-кейсов (что, в свою очередь, повышает полезный эффект автоматизации и снижает накладные расходы). • Высокоуровневые поведенческие тест-кейсы пропускают много деталей, а потому могут не обнаружить часть проблем в приложении или не предоставить необходимой для пони- мания обнаруженной проблемы информа- ции. • В некоторых случаях информации, предо- ставленной в поведенческом тест-кейсе, не- достаточно для его непосредственной авто- матизации. К классическим технологиям автоматизации тестирования также можно отнести разработку под управлением тестированием (Test-driven Develop- ment, TDD) с её принципом «красный, зелёный, улучшенный» (Red-Green- Refactor), разработку под управлением поведением (Behavior-driven Devel- opment), модульное тестирование (Unit Testing) и т.д. Но эти технологии уже находятся на границе тестирования и разработки приложений, потому выходят за рамки данной книги. Автоматизация вне прямых задач тестирования Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 276/298 3.3. Автоматизация вне прямых задач тестирования На протяжении данного раздела мы рассматривали, как автоматизация мо- жет помочь в создании и выполнении тест-кейсов. Но все те же принципы можно перенести и на остальную работу тестировщика, в которой также бывают длитель- ные и утомительные задачи, рутинные задачи или задачи, требующие предельного внимания, но не связанные с интеллектуальной работой. Всё перечисленное также можно автоматизировать. Да, это требует технических знаний и первоначальных затрат сил и времени на реализацию, но в перспективе такой подход может экономить до нескольких ча- сов в день. К самым типичным решениям из данной области можно отнести: • Использование командных файлов для выполнения последовательностей операций — от копирования нескольких файлов из разных каталогов до раз- вёртывания тестового окружения. Даже в рамках многократно рассмотрен- ных примеров по тестированию «Конвертера файлов» запуск приложения че- рез командный файл, в котором указаны все необходимые параметры, из- бавляет от необходимости вводить их каждый раз вручную. • Генерация и оформление данных с использованием возможностей офисных приложений, баз данных, небольших программ на высокоуровневых языках программирования. Нет картины печальнее, чем тестировщик, руками нуме- рующий три сотни строк в таблице. • Подготовка и оформление технических разделов для отчётов. Можно тратить часы на скрупулёзное вычитывание журналов работы некоего средства ав- томатизации, а можно один раз написать скрипт, который будет за мгновение готовить документ с аккуратными таблицами и графиками, и останется только запускать этот скрипт и прикреплять результаты его работы к отчёту. • Управление своим рабочим местом: создание и проверка резервных копий, установка обновлений, очистка дисков от устаревших данных и т.д. и т.п. Ком- пьютер всё это может (и должен!) делать сам, без участия человека. • Сортировка и обработка почты. Даже раскладывание входящей корреспон- денции по подпапкам гарантированно занимает у вас несколько минут в день. Если предположить, что настройка специальных правил в вашем почтовом клиенте сэкономит вам полчаса в неделю, за год экономия составит при- мерно сутки. • Виртуализация как способ избавления от необходимости каждый раз уста- навливать и настраивать необходимый набор программ. Если у вас есть не- сколько заранее подготовленных виртуальных машин, их запуск займёт се- кунды. А в случае необходимости устранения сбоев разворачивание вирту- альной машины из резервной копии заменяет весь процесс установки и настройки с нуля операционной системы и всего необходимого программного обеспечения. Иными словами, автоматизация объективно облегчает жизнь любого ИТ-спе- циалиста, а также расширяет его кругозор, технические навыки и способствует про- фессиональному росту. |