Зачем используется фреймворк автоматизированного тестирования

Фреймворки для тестирования: личный опыт и новые методы

Привет, Хабр! Меня зовут Сергей Радченко, и мы с командой профессионально занимаемся тестированием уже несколько лет. Сегодня я посчитал количество автотестов, которые мы подготовили для веб-интерфейсов, десктопных приложений, API, систем двухфакторной авторизации и так далее (их оказалось более 5000). И мне захотелось рассказать о нашем опыте создания экосистемы для автоматизированного тестирования. В этом посте вы найдете описание полезных для комплексного тестирования фреймворков, а также исходный код некоторых дополнительных методов, которые мы дописали самостоятельно, чтобы написание тестов происходило быстрее, и тестирование приносило больше пользы.

Иногда кажется, что тесты — это очень просто. Нередко в инструментах инфраструктурного мониторинга предусмотрена возможность отслеживания доступности веб ресурсов по простым http-запросам: ответ пришел — значит сервис доступен, нет ответа или код ответа отличается от «200» — значит недоступен. Но таким способом не получается проверить что-то более специфичное, например, корректность работы системы авторизации или обнаружить проблемы с синхронной подгрузкой данных, ну и удостовериться, что все бизнес услуги предоставляются пользователям корректно.

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

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

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

Тесты проще писать на Python. Это факт

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

В качестве основы для написания тестов мы выбрали Python. Это достаточно простой и популярный на сегодняшний день язык программирования. В нем есть много полезных библиотек, и их количество продолжает расти. Поэтому готовить тестовые системы на Python достаточно просто.

Быстрый старт

Чтобы быстрее начинать работу по проекту, мы создали один базовый класс Python со всеми необходимыми методами и постоянно дополняем его новыми. Далее для тестирования конкретного сайта создаем классы-наследники. В них выносим общие данные, элементы и метод. Благодаря этому приступить к началу тестирования получается достаточно быстро.

Простота входа

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

Работа с разными окружениями

Учитывая, что тестированием мы занимаемся давно, у нас есть старый код, который написан на Python 2.7. Основная часть тестов была подготовлена для версии Python 3. Все они должны работать вместе на одной рабочей машине автоматизатора тестирования. Виртуальные окружения Python позволяют развернуть готовое окружения за несколько минут с использованием нескольких команд в консоли. Также несколько минут уходит на установку всех необходимых пакетов ещё одной консольной командой.

Браузерные тесты удобно запускать через Selenium

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

Исторически Selenium использует свой закрытый протокол для взаимодействия с браузером: запросы упаковываются в JSON и передаются через http. Но сейчас же во все основные браузеры внедрен протокол, позволяющий обращаться к ним напрямую: Remote Debugging Protocol для Firefox, Chrome DevTools Protocol для chromium. С помощью этих протоколов можно управлять браузерами на более низком уровне, например, отслеживать запросы. Эти возможности, должны появиться в Selenium версии 4, которая сейчас находится в разработке (очень ждём…).

Например, библиотека Selenium для Python включает в себя класс ActionChains. Он позволяет создавать цепочки действий с клавиатурой и мышью. Например, вы можете передвигать курсор на элемент разворачивающий список или меняющий свое состояние при наведении. Также можно имитировать нажатия на клавиши, что иногда требуется в некоторых поля ввода, когда стандартный метод send_keys из Selenium не работает.

Изначально за основу для разработки тестов был взят wrapper (https://pypi.org/project/seleniumwrapper/). Мы предполагали, что его методов будет достаточно для написания любых сценариев. Но в процессе работы возможностей wrapper стало не хватать: во многих местах появилось дублирование кода, было много провалов, которые приходилось обходить костылями. Для решения этих проблем мы начали добавлять свои методы такие как:

• переключение между вкладками,
• ожидание исчезновения элемента со страницы,
• имитация нажатий клавиш и использование ActionChains,
• ожидание скачанного файла
• и так далее

Вот некоторые примеры этих методов в коде:

class Page(SeleniumWrapper): def switch_to_window(self, title_name, close_others=False): windows = self.window_handles windows_title = <> for window in windows: self.switch_to.window(window) windows_title[self.title] = window for window in windows_title: if re.search(title_name, window): self.switch_to.window(windows_title[window]) break if close_others: self.close_all_other_windows() def get_current_window_index(self): return self.window_handles.index(self.current_window_handle) def switch_to_next_window(self): current_index = self.get_current_window_index() self.switch_to.window(self.window_handles[current_index + 1]) def switch_to_previous_window(self): current_index = self.get_current_window_index() self.switch_to.window(self.window_handles[current_index - 1]) def close_all_other_windows(self): windows = self.window_handles current_window = self.current_window_handle for window in windows: if window != current_window: self.switch_to.window(window) self.close() self.switch_to.window(current_window) def is_xpath_present(self, xpath, eager=False, timeout=1, presleep=0): time.sleep(presleep) self.silent = True elements = self.xpath(xpath, eager=eager, timeout=timeout) self.silent = False if eager: return elements if not elements: return [] if elements.is_displayed(): return True return [] @_wait_until def wait_for_not_displayed(self, xpath):мента. """ assert not bool(self.is_xpath_present(xpath)), f'Элемент не исчез' return True def press_keys(self, keys): """ Ввод символов нажатиями на клавиши :param keys: Строка символов для ввода """ for key in keys: ActionChains(self).key_down(key).key_up(key).perform() time.sleep(0.01) def press_backspaces(self, count=20): keys = [Keys.BACKSPACE for _ in range(count)] self.press_keys(keys) def get_downloaded_file_names(self): if settings.run_local: return [] response = requests.get(self.download_url) result = re.findall(r'>(.*?)', response.text) print(f'Downloaded response: ') print(f'Downloaded result: ') return result @_wait_until def wait_for_downloaded_file(self, filename): assert not settings.run_local, 'Can not check downloaded file on local running' assert filename in self.get_downloaded_file_names(), f"Файл не скачан" return True @_wait_until def wait_for_downloaded_file_by_substring(self, filename_part): assert not settings.run_local, 'Can not check downloaded file on local running' matches = [filename for filename in self.get_downloaded_file_names() if filename_part in filename] assert len(matches) > 0, f'Нет файла содержащего `` в названии' return True 

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

Это очень важно в реальных тестах. Например, чтобы начать вводить в поле ввода данные, нужно сперва дождаться появления элемента на странице, затем проверить его видимость, доступность для ввода, и только после этого начать вводить данные. Если использовать чистый Selenium, то придется в каждом тесте прописывать эти действия, удобнее вынести это всё в отдельный метод и просто его использовать.

А вот и исходный код метода:

 def send_keys(self, xpath, value, name="", timeout=None, wait_interactable=True, postsleep=0): timeout = timeout or self.timeout element = self.xpath(xpath, name, timeout=timeout) if wait_interactable: self.can_click(xpath, timeout=timeout) try: element.send_keys(value) except WebDriverException: message = f"В поле ввода ``не удалось ввести значение `` за `` секунд" raise WebDriverException(message) time.sleep(postsleep) def click(self, xpath_or_dict="", name="", timeout=None, presleep=0, postsleep=0, ignored_exceptions=None): xpath, name = Page.get_xpath_and_name(xpath_or_dict, name) timeout = timeout or self.timeout ignored_exceptions = ignored_exceptions or tuple() # Сначала ждем появления элемента element = self.xpath(xpath_or_dict, timeout=timeout) time.sleep(presleep) errors = list() end_time = time.time() + timeout while time.time() < end_time: try: element.click(timeout=timeout / 10) break except ignored_exceptions: continue except InvalidSessionIdException: message = "Потеряно соединение с браузером. Возможно браузер был закрыт или аварийно завершил работу" raise InvalidSessionIdException(message) except StaleElementReferenceException as e: element = self.xpath(xpath_or_dict, timeout=timeout) errors.append(e) continue except WebDriverException as e: errors.append(e) continue else: if errors: message = f"Не удалось выполнить клик по элементу `` в течение секунд(ы)\n" raise TimeoutException(message) time.sleep(postsleep) 

Распознавание изображений с PyAutoGUI

PyAutoGUI — это хороший и простой фреймворк для написания несложных тестов под десктоп. Он позволяет управлять клавиатурой и мышью, то есть имитировать нажатия на клавиши, двигать курсором и производить клики. Кроме этого PyAutoGUI умеет находить координаты на экране по референсному скриншоту. Поиска по пиксельному совпадению обычно бывает достаточно, потому что тесты обычно гоняются на одном и том же окружении, с одним разрешением и на изолированных экранах.

С одной стороны, чтобы прогнать тест, нужно всего лишь сделать скриншот и использовать его. Но с другой стороны изменение шрифта, размеров элементов требует новых и новых скриншотов.

Мы решили эту проблему, реализовав поиск элемента по нескольким эталонным скриншотам, был добавлен метод, который в течение указанного промежутка времени ищет и по очереди сопоставляет каждый из эталонных скриншотов с тем, что сейчас отображено на экране. Если за один проход нужные элементы не были обнаружены, метод делает повторные попытки, пока не найдет совпадение или не превысит отведенный лимит времени.

class RecognitionClient(abc.ABC): def __init__(self, project_dir): self.project_dir = Path(project_dir) self.process = None self.wait_time = 25 def _find_image_path(self, img_file): parent_img_path = self.project_dir.parent.joinpath('img', img_file) if parent_img_path.is_file(): return str(parent_img_path) img_path = self.project_dir.joinpath('img', img_file) if img_path.is_file(): return str(img_path) return ImageNotRecognized(f'Not found image file: ') @sleeper def find_one_of(self, *imgs, wait_time=None, confidence=0.9, raise_errors=True): """ Поиск координат одного скрина из списка. """ wait_time = wait_time or self.wait_time timeout = time.time() + wait_time while time.time() < timeout: for img in imgs: position = self.find_screen(img, wait_time=0.1, raise_errors=False, confidence=confidence) if position: return position else: if raise_errors: for img in imgs: img_path = self._find_image_path(img) with open(img_path, "rb") as image_file: img_obj = image_file.read() allure.attach(img, img_obj, type=AttachmentType.PNG) raise ImageNotRecognized(f"Images not recognized: ") 

Запуск тестов с PyTest

PyTest — действительно мощный фреймворк для тестирования. Он имеет массу возможностей и расширений в виде пакетов. С его помощью можно реализовать автоматический перезапуск тестов, визуализацию отчетов и многое другое.

Для нас PyTest — это способ избежать необходимости писать кучу однотипного кода для каждого теста, потому что обычно дополнительный код в этой экосистеме или полностью отсутствует, или связан с объявлением новой фикстуры.

К тому же в PyTest есть несколько дополнительных пакетов, которые расширяют его функциональность. Мы используем Allure и Rerunfailures.

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

пример — скриншот отчета

Изначально мы использовали allure.step из самой библиотеки, но затем появилась необходимость делать скриншоты для каждого шага браузера. Если делать один скриншот в конце шага, то в случае провала тест просто не дойдет до этого места, а в проваленных тестах скриншот с места провала невероятно важен для понимания проблемы.

Первым решением было оборачивание кода внутри теста в блок try. В итоге это привело к увеличению количества строк кода теста и повсеместному дублированию. Тогда мы решили сделать свой класс наследник StepContext. Сначала решение показалось удобным, но внутри класса получилось много лишних строк и условных блоков. На текущий момент мы перешли к варианту использования декоратора contextmanager из библиотеки contextlib и реализовали обращение к глобальному объекту браузера. А поскольку декоратор преобразует генератор в дескриптор его можно использовать в блоке with.

@contextmanager def allure_step(name, wait_time: int = None): from web.register import pages with allure.step(name): try: if wait_time: pages.browser.wait_time = wait_time yield pages.browser.wait_time = settings.wait_time make_screen('screen') except Exception: make_screen('error') raise

from utils.allure import allure_step def test_1(pages): with allure_step('Шаг 1. Загрузка главной страницы', 50): pages.main_page.open() 

Кроме этого мы используем библиотеку Rerunfailures, которая обеспечивает удобный перезапуск тестов при провале. Этот набор методов позволяет настраивать количество перезапусков, интервал ожидания перед перезапуском после провала. В общем — полезная штука для тестировщика, у которого действительно много работы.

Изоляция тестов с Selenoid

Тесты необходимо запускать изолированно друг от друга, чтобы результат выполнения предыдущего никак не влиял на следующий. Тесты надо прогонять на разных браузерах различных версий. И для этого идеально подходит Selenoid в связке с Selenoid GGR и Selenoid UI.

Когда у нас идут большие проекты тестирования, на одной машине мы разворачиваем Selenoid GGR, а на нескольких других — ноды. Все запросы изначально отправляются в GGR, который создает сессию на свободной ноде, и мы можем использовать её для тестирования.

Для каждого теста поднимается свой контейнер с нужной версией браузера, а после завершения теста, контейнер гасится. Когда возникает необходимость посмотреть, как работает тест или проверить работу ресурса через браузер на сервере, можно использовать Selenoid UI, создать сессию и работать с окружением через VNC как с обычным браузером.

Запуск тестов через Jenkins

Вообще Jenkins создавался (и используется) для CI/CD. Но мы применяем его как систему для запуска тестов, используя те же плюсы, которые эта платформа дает при деплое приложений.

Для каждого теста или группы тестов создается отдельный проект. В его настройках мы прописываем периодичность запуска тестов, выбираем необходимые параметры через переменные окружения и создаем скрипт запуска теста. Скрипт определяет, на каком окружении и какой тест нужно запускать. После этого Jenkins прогоняет тест, специальный скрипт собирает метрики и отправляет их в систему мониторинга.

На стенде, где установлен Jenkins, может быть создано несколько окружений Python и размещены разные репозитории с тестами. Тесты обычно берутся с локального диска стенда, а не из Git, потому что одновременно работают десятки проектов, и каждый раз делать Pull оказывается накладно с точки зрения ресурсов. Впрочем, сами тесты могут не меняться месяцами, а иногда и годами, так что это не очень страшно. )

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

Создание проектов мы автоматизировали через отдельный скрипт. На основе шаблона скрипт создает проект почти со всеми необходимыми настройками, чтобы свести к минимуму ввод дополнительных параметров.

Заключение

Надеюсь, эта подборка тестовых фреймворков и методов оказалась полезной. В следующем посте я расскажу о практике написания некоторых тестов на Python. А если у вас есть другой опыт работы с тестовыми окружениями, пожалуйста, поделитесь им в комментариях.

Зачем нужно автоматизировать?

С автоматизацией тестирования, как и со многими другими узконаправленными IT - дисциплинами, связано много неверных представлений. Для того, чтобы избежать неэффективного применения автоматизации, следует обходить ее недостатки и максимально использовать преимущества. Далее мы перечислим и дадим небольшое описание для основных нюансов автоматизации и дадим ответ на основной вопрос данной статьи – когда автоматизацию всетаки стоит применять.

Преимущества автоматизации тестирования:

• Повторяемость – все написанные тесты всегда будут выполняться однообразно, то есть исключен «человеческий фактор». Тестировщик не пропустит тест по неосторожности и ничего не напутает в результатах.
• Быстрое выполнение – автоматизированному скрипту не нужно сверяться с инструкциями и документациями, это сильно экономит время выполнения.
• Меньшие затраты на поддержку – когда автоматические скрипты уже написаны, на их поддержку и анализ результатов требуется, как правило, меньшее время чем на проведение того же объема тестирования вручную.
• Отчеты – автоматически рассылаемые и сохраняемые отчеты о результатах тестирования.
• Выполнение без вмешательства – во время выполнения тестов инженер-тестировщик может заниматься другими полезными делами, или тесты могут выполняться в нерабочее время (этот метод предпочтительнее, так как нагрузка на локальные сети ночью снижена).

Недостатки автоматизации тестирования (их тоже немало):

• Повторяемость – все написанные тесты всегда будут выполняться однообразно. Это одновременно является и недостатком, так как тестировщик, выполняя тест вручную, может обратить внимание на некоторые детали и, проведя несколько дополнительных операций, найти дефект. Скрипт этого сделать не может.
• Затраты на поддержку – несмотря на то, что в случае автоматизированных тестов они меньше, чем затраты на ручное тестирование того же функционала – они все же есть. Чем чаще изменяется приложение, тем они выше.
• Большие затраты на разработку – разработка автоматизированных тестов это сложный процесс, так как фактически идет разработка приложения, которое тестирует другое приложение. В сложных автоматизированных тестах также есть фреймворки, утилиты, библиотеки и прочее. Естественно, все это нужно тестировать и отлаживать, а это требует времени.
• Стоимость инструмента для автоматизации – в случае если используется лицензионное ПО, его стоимость может быть достаточно высока. Свободно распространяемые инструменты как правило отличаются более скромным функционалом и меньшим удобством работы.
• Пропуск мелких ошибок - автоматический скрипт может пропускать мелкие ошибки на проверку которых он не запрограммирован. Это могут быть неточности в позиционировании окон, ошибки в надписях, которые не проверяются, ошибки контролов и форм с которыми не осуществляется взаимодействие во время выполнения скрипта.

Для того чтобы принять решение о целесообразности автоматизации приложения нужно ответить на вопрос «перевешивают ли в нашем случае преимущества?» - хотя бы для некоторой функциональности нашего приложения. Если вы не можете найти таких частей, либо недостатки в вашем случае неприемлемы – от автоматизации стоит воздержаться.

При принятии решения стоит помнить, что альтернатива – это ручное тестирование, у которого есть свои недостатки.

В поиске эффективных мест для автоматизации вам может помочь глава "Что необходимо автоматизировать".

9 фреймворков автоматизированного тестирования

Если вы подумали о том, чтобы создать свой собственный фреймворк автоматизированного тестирования, подумайте еще раз. Другими словами, вы поступите правильно, обратив внимание на один или несколько доступных вариантов с открытым исходным кодом.

Фреймворк – это набор инструментов для ускоренной разработки сайта, нацелен на решение определенных задач. Говоря простыми словами, framework – это каркас, который состоит из множества различных библиотек, которые облегчают разработку программного продукта или сайта.

То есть фреймворк это набор из нескольких библиотек. В большинстве случаев, нет необходимости в создании “уникального” фреймворка, который будет подходить под вашу среду разработки. Вам просто нужен такой фреймворк, который помог бы Вам автоматизировать некий процесс.

Фреймворк должен быть:

• С возможностью повторного использования;
• С возможностью внесения изменений;
• Стабильным.

Существуют такие команды разработчиков, которые используют эти качества до предела, создавая уже свои собственные, сложные фреймворки автоматизированного тестирования. И знаете, это сводит меня с ума, потому что они могли бы легко использовать уже существующие инструменты и библиотеки с открытым исходным кодом, соответствующие их требованиям. Соответственно, не было бы необходимости в написнаии кода СОВСЕМ, что, в большинстве случаев, привело бы к лучшему результату.
Другая область, о которой большинство людей забывают подумать, будучи в поисках фреймворка автоматизированного тестирования, – это способность тестировать API. Я по большей части сторонник функционального тестирования за пределами пользовательского интерфейса (UI). И поскольку интеграционные тесты обходят пользовательский интерфейс, они, как правило, быстрее и надежнее, чем тесты GUI.

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

Serenity

Это фреймворк с открытым исходным кодом для написания функциональных тестов, в который из встроена система генерации отчетов о выполненных тестах. Serenity поддерживает интеграцию с другими популярными фреймворками, например: JUnit, Cucumber, JBehave, Rest-Assured, Selenium.
Serenity работает по принципу оболочки для других инструментов. Данный инструмент помогает упростить процесс написания тестов с использованием Selenium. Serenity также предлагает множество встроенных функций, таких как управление WebDriver, управление состоянием между этапами, создание скриншотов, запуск параллельных тестов, упрощение Jira интеграции без необходимости написания ни одной строки кода.
Serenity создает очень подробные динамические отчеты. Их можно использовать не только для просмотра результатов теста, но и включать в документацию приложения.

Фреймворк также имеет дополнительный метод c аннотацией @Step. При правильном использовании данный метод дает возможность улучшить тесты, сделав их поддерживаемыми, с возможностью внесения изменений в дальнейшем.
Недавно была добавлена возможность интеграции фреймворка с REST Assured, популярной библиотекой Java с открытым исходным кодом для тестирования API RESTful. Он создает еще одну оболочку поверх REST Assured, которая позволяет тестам Serenity Selenium работать беспрепятственно.

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

Cypress

По сравнению с большинством других инструментов в этом списке, Cypress – это более ориентированный на разработчиков фреймворк автоматизации тестирования, придерживающихся TDD. Одним из его базовых принципов является упрощение процесса сквозного тестирования, делая его приятным и простым.
Его архитектура отличается от архитектуры Selenium; в то время как Selenium WebDriver работает на фоне, вне браузера, Cypress – работает прямо в браузере.
Данный подход обеспечивает согласованность результатов и дает вам доступ к каждому объекту, не требуя от вас обработки сериализации объектов или сквозных протоколов. Фактически, вы запускаете свое приложение в Cypress.
Таким образом, фреймворк может немедленно уведомлять вас обо всех вещах, происходящих внутри браузера, так что у вас есть доступ к каждому элементу объектной модели документа (DOM).
Cypress также упрощает процесс отладки приложения и разработчик может более свободно использовать другие инструменты на протяжении всего процесса разработки.

Robot Framework

При выборе Python для автоматизации тестирования, вы не ошибётесь, если выберете Robot Framework. Этот продукт, разработанный специально для тестировщиков, использует подход, основанный на ключевых словах. Данный подход упрощает процесс создания тестов и улучшает их читабельность. Фреймворк Robot включает множество библиотек и других инструментов, которые вы можете свободно использовать. Несмотря на то, что данный фреймворк создан под Python, вы можете пользоваться Java и IronPython (.NET).
Хотя библиотека Selenium WebDriver самая используемая внешняя тестовая библиотека, Robot Framework может тестировать другие объекты, кроме сайтов, такие как FTP, MongoDB, Android и Appium. В дополнение ко всем этим фишкам, наличие нескольких видов API делает его очень мощным и легко расширяемым средством автоматизации.
Тестирование на основе ключевых слов, являющееся основой Robot Framework отлично подходит для тех тестировщиков, которые уже работали с другими инструментами, основанными на этом же подходе. Опыт, безусловно, даст преимущество в работе с фреймворком.
Если ваша команда в основном состоит из тестировщиков, Robot Framework – отличный вариант.

RedwoodHQ

RedwoodHQ использует немного другой подход, если сравнивать его с другими инструментами в этом списке. Он создает интерфейс веб-сайта, который позволяет нескольким тестировщикам работать вместе и запускать тесты из одного доступного местоположения.

Вы можете писать тесты на Java / Groovy, Python и C # для тестирования веб-приложений с помощью Selenium, API или баз данных, используя их интегрированную веб-среду разработки, которая также включает встроенную Git интеграцию.
В RedwoodHQ есть ключевые слова, которые Вы можете использовать для быстрого создания и изменения тестов. Чтобы создать тестовый сценарий, просто найдите действие, которое вы хотите выполнить, перетащите его в тест кейс и введите ожидаемые значения параметров.
Встроенная интегрированная среда разработки даст Вам возможность как создавать и изменять тест кейсы и действия, так и запускать сами тесты. Вы также можете запускать параллельные тесты и просматривать историю всех предыдущих тестов.
RedwoodHQ удобен для тестирования и имеет множество встроенных функций, которые вы можете использовать для выполнения автоматизированного тестирования.

Sahi

Разработанный для тестирования веб-приложений, Sahi предлагает как версию с открытым исходным кодом, так и профессиональную версию. Он работает как прокси-сервер, который можно использовать в браузере. С панели инструментов Sahi вы можете запустить браузер, который хотите протестировать.

Sahi обеспечивает запись ошибки и создание скриншотов при любом взаимодействии с приложением. Например, когда вы наводите курсор на любой элемент в браузере Sahi, он показывает вам все действия, которые можно выполнить с помощью этого элемента.
Вы также можете использовать контроллер для воспроизведения сценария. Функция записи и воспроизведения Sahi упрощает работу с автоматизацией тестирования простых HTML приложений. Но не полагайтесь полностью на запись и воспроизведение; этот подход не лучший выход в создании удобных и надежных автоматизированны тестов. Данная функция отлично подойдет для создания первоначального теста, но нужно немного поработать над его усовершенствованием, чтобы сделать его надежным и поддерживаемым.

Gauge

Gauge – это один из новейших инструментов автоматизации тестирования с открытым исходным кодом для Mac, Windows, и Linux, разработанный компанией ThoughtWorks— той же компанией, создавшей когда-то Selenium.
Приверженцы разработки через тестирование и на основе описания поведения оценят по достоинству фишку данного фреймворка создания динамической документации.
Все тесты описываются в виде spec-файлов в формате markdown, а реализация step’ов возможна на ЯП: Java, C# , Ruby, JavaScript, Python и Go.
Gauge довольно молодой фреймворк, который все еще находится на стадии beta-разработки, но если Ваша команда не желает отставать от передовых технологий, Вы можете попробовать и ощутить на себе все прелести данного фреймворка.

Galen Framework

Если все ваши силы в автоматизации направлены на UX или тестирование макета, Galen Framework может идеально вам подойти. Созданный специально для тестирования пользовательского интерфейса (UX), Galen имеет специфический синтаксис и правила, которым необходимо следовать для описания тестов и тестирования макета вашего приложения. Фреймворк также позволяет вам определить размер окна, затем запускает тесты, чтобы проверить макет приложения на соответствие требованиям.

Тесты данного инструмента также создают детализированные HTML отчеты со скриншотами, в отчеты также включаются изображения для сравнения. Вы можете писать тесты в простом текстовом файле, используя синтаксис фреймворка, JavaScript, или Java.

Citrus Framework

Citrus это фреймворк с открытым исходным кодом, который поможет Вам автоматизировать тесты для практически любого протокола обмена сообщениями или формата данных. Если тестовый поток подразумевает взаимодействие приложения с другими сервисами, тогда инструменты функционального тестирования, как Selenium, не помогут.
Citrus подходит для тестирования интеграции обмена сообщениями при использовании любой из технологии передачи сообщений: HTTP, REST SOAP или JMS.

Citrus также интегрирован с Selenium. Это удобно в случае, если Вам нужно работать с пользовательским интерфейсом, а затем переключиться на фоновые процессы. Например, скажем, вам нужно нажать кнопку «отправить письмо» и проверить, что письмо было получено. Citrus может получить это электронное письмо или JMS сообщение, введенное через пользовательский интерфейс, и сравнить результаты. И это все в одном тесте.
Таким образом, Citrus – это фреймворк, способный обеспечить сквозное тестовое покрытие, которое не способен обеспечить ни один инструмент GUI тестирования.

Karate-DSL

Если Вы уже пользуетесь Cucumber и Вам также нужно тестировать REST API, Karate-DSL может быть идеальным кандидатом для Вас. Данному фреймворку уже больше года и все больше и больше людей используют его для тестирования API.
Так как сам инструмент построен как бы “поверх” Cucumber-JVM, Вы можете запускать тесты, просматривать отчеты, использовать весь функционал инструмента так же, как и в случае с любым стандартным проектом на Java.

Время выбирать!

Это довольно короткий список фреймворков автоматизации тестирования с открытым исходным кодом из большого множества. С этого момента стоит задуматься над выбором наиболее подходящего для вас фреймворка.

Перед тем, как написать первую строчку кода своего фреймворка, убедитесь, что не существует соответствующего Вашим требованиям библиотеки или фреймворка. Не тратьте свое время напрасно, пытаясь заново изобрести колесо; хотя бы пройдитесь по этим фреймворкам. Если автоматизация тестирования – это то, к чему вы сейчас стремитесь, приглашаем вас к нам на Курсы Автоматизации тестирования ПО.

Фреймворк автоматизированного тестирования

Фреймворк автоматизированного тестирования (англ. Test automation framework) - это набор предположений, концепций и инструментов, которые обеспечивают поддержку для автоматизированного тестирования программного обеспечения. Основным преимуществом такой структуры является низкая стоимость обслуживания.

Если есть изменения в любом тест-кейсе, то необходимо обновить только тестовый файл тест-кейса, а сценарий драйверов и сценарий запуска останется прежним. В идеале, нет необходимости обновлять скрипты в случае внесения изменений в приложение.

Выбор правильной техники фреймворка/сценариев помогает для снижения затрат. Расходы, связанные с тестовыми сценариями обусловлены разработкой и поддержкой усилий. Подход к сценариям, используемый при автоматизации тестирования отображается на затратах.

Различные техники фреймворков/сценариев

• Линейный (англ. Linear)
• Структурированный (англ. Structured)
• Движимый данными (англ. Data-driven)
• Движимый ключевым словом (англ. Keyword-driven)
• Гибридный (англ. Hybrid) (два или более из этих шаблонов используются)

Функции фреймворка автоматизированного тестирования

• определение формата, который отображает ожидания;
• создание механизма для подключения или выполнения в тестируемого приложения;
• выполнение тестов;
• отчетность о результатах.