Возможно не угадала с разделом, не смогла понять к какому разделу этот вопрос лучше прикрепить.
У меня разработан свой легонький фреймворк запуска тестов. В качестве языка описания тестов был выбран xml. Но спецы в области автоматизации сказали, что сейчас это не “модно”. Я в целом согласна, что xml язык перегружен и читабельность тестов из-за него падает. Но с другой стороны он очень структурированный язык, под него написано много удобных редакторов, которые выстраивают иерархическое дерево тестов, также можно прикрутить валидацию по xsd. Написать свой простенький синтаксический анализатор можно, но редакторов под такой специальный язык уже не будет, да и язык надо хорошо продумать. Подскажите, какой способ описания кто использует? Если какой-то свой формат, то какими редакторами пользуетесь? Удобно ли?
Наталья, дело в том, что большинство использует обычные языки программирования.
Вы используете свой DSL для тестов?
В таком случае, надо думать о том, чтобы формат описания был совместим с тем, что уже есть.
Например, заменить XML на YAML - выглядит более легковесно, а суть та же.
Другое дело, что общепринятых схем валидации данных и автодополнения, скорее всего, не будет.
Развитые редакторы найти реально только для хорошо известных и давно используемых форматов. Кроме XML, из таких знаю только JSON, но не рекомендую: редактировать гораздо неудобнее, чем даже XML.
Да, я имею ввиду шаги тестов, где я описываю, что необходимо нажать на такую кнопку, ввести следующее значение. Написан парсер, который из xml описания теста собирает java-объект и с ним работаем дальше.
Ок, спасибо, я поняла. Но мне бы было интересно услышать Ваши рассуждения, а как вам кажется удобнее? Вы используете обычный язык программирования? Я видела неплохой подход в кукумбере, но мне не нравится, что используются регулярные выражения для создания своего языка.
Наталья, думаю, дело в том, что мало конкретных входных данных в вопросе. Мне пока непонятно вот что:
Какие цели создания фреймворка, почему не устроили кодированные тесты.
Какой тип приложения: веб, десктоп? Может быть, фреймворк понадобился, т.к. используется какая-то специфическая технология?
Какие вообще варианты рассматривались и почему не подошли.
Кто конечный пользователь Вашего решения, каковы запросы.
Без этого - подходов и инструментов море, можно обсуждать бесконечно.
Приведу максимально капитанское рассуждение.
Первое, чему обычно учатся в автоматизации - писать тесты в виде кода.
Если тесты читают только автоматизаторы, на этом можно остановиться.
Главное - сохранить читаемость теста верхнего уровня. Он должен быть коротким и максимально понятным, и с помощью кода этого тоже можно добиться. На эту тему много сказано. Вот, например, Пирогов недавно писал.
Если можно писать “красивые” тестовые методы верхнего уровня, создание дополнительной прослойки в виде DSL уже может быть не нужно.
Когда тесты используются и дописываются внешними пользователями, берутся готовые решения в стиле BDD (чаще это Gherkin, т.к. под него есть решения на многих языках).
Также BDD - хороший способ дисциплинировать себя и команду, чтоб не превращать тесты в “кашу”. Всегда есть соблазн добавить в код какие-то условия, ветвления, в результате последовательный стиль “красивого” тестового метода легко испортить неумелыми руками. Когда есть четкий сценарий на Gherkin, сделать его нечитаемым уже сложнее.
Если возможностей Gherkin не хватает, можно посмотреть в сторону RobotFramework, там более богатые возможности (правда, обязательно идет привязка к питону).
Еще есть интересный концепт - Fit/FitNesse, но это сейчас не в тренде.
Почему лучше взять готовое решение? Ну ясно же, для уменьшения костов на поддержку своего. Должны быть веские причины, чтобы писать и поддерживать свою нотацию, когда есть широко распространенные и работающие. И с редакторами легче: Для Gherkin и Robot, например, есть редакторы в виде плагинов к различным IDE.
Если у собственного DSL есть какие-то уникальные фичи, без которых не обойтись - другое дело, но из примера этого не видно.
Почему не нравится задание фраз с помощью регулярных выражений - тоже не совсем понятно, это нормальная практика. Если бы было неудобно, этим бы не пользовались.
XML выглядит слишком технично. Поэтому вряд ли подойдет для внешних пользователей, де-факто его будут использовать автоматизаторы и разработчики. Соответственно, нужно что-то более легкое в восприятии (Gherkin, Robot, YAML).
Если уже есть наработанная база тестов, можно тупо взять YAML, т.к. легче переводить тесты из XML: суть та же, но выглядит менее устрашающе для непосвященных.
Если базы тестов нет, а есть пилотное решение, то стоит подумать о двух вещах. Во-первых, насколько нужны дополнительные затраты на поддержание своей нотации. Во-вторых, что хотят те, кто будет пользоваться. Ну, и простой вывод из этих двух факторов: если пишем что-то своё, делаем это с учетом всех пожеланий; если готовое, подбираем то, что максимально соответствует этим желаниям.
Мне кажется вашим тестам не хватает еще одного уровня абстракции. Вам будет
сложно поддерживать эти тесты и при малейшем изменения тестируемой
системы - они будут мгновенно “прогнивать”.
Мне тоже кажется, что лучше взять готовое решение у которого хорошее
комьюнити и которое хорошо развивается. Вам сразу станет на много легче.
Берете подключаете “готовую” функциональность и пользуетесь. Все легко
портируется и времени на мейнтейн фреймворка тратится на много меньше.
Fit/FitNesse лично мне не подошел, поскольку питоновский порт для тестов (сам
раннер) PyFit давно не мейнтейнится и у меня ушло много времени чтоб все
запустить и настроить.Покрутила, попробовала и оставила.
Из всего мне больше всего понравился RobotFramework. Он поддерживает Data-driven, Gherkin. Keyword-driven. Обалденный фреймворк с кучей библиотек - запуск параллельно, авто-генерация документации, целая гора редакторов в которых можно удобно писать тесты, отчеты-супер. Вы раз все надеплоили и забыли. Вам не надо проектировать эту всю огромную
систему и потом постоянно фиксить в ней баги и добавлять функциональность.
Тут дело не в том, что так модно, а так не модно - Огромное комьюнити писало готовые фрейворки, подумайте сколько вам нужно будет потратить сил и времени чтоб сделать примерно тоже самое. Просто запустить тесты это лишь маленькая часть работы. Для полной жизни авто-тестирования нужна целая “эко-система”.
Когда-то очень давно , когда я писала свои самые первые тесты и передо мной стали такие вопросы:
как “дать” возможность запускать тесты другим
как запускать тесты автоматически
где хранить результаты
Я тогда вообще не слышала ничего про Continuous Integration.
Не долго думая я написала на коленке за вечер сайтик - где можно выбрать тест и запустить.
Кривое, косое, но работающее))
Когда показала код программистам с меня долго смеялись). Кинули ссылку на TeamCity, а код моего сайтика сказали никому не показывать, удалить, а лучше сжечь)
Так что главное не бояться и сначала искать что-то готовое) Сейчас столько всего, что очень редко есть необходимость кастомизировать и дописывать свое.
Спасибо за ответ. Прошу прощения, но как этот скриншот оказался здесь, понятия не имею, удалить его не получилось((( Еще раз повторюсь, что мой тест выглядит примерно так: <test name="Вход клиента"> <action name="Вводим логин" type="setValue" element="LoginEdit" value="login1"/> <action name="Вводим пароль" type="setValue" element="PasswordEdit" value="password1"/> <action name="Нажимаем на кнопку войти" type="clickElement" element="LoginButton"/> </test>
Локаторы element описаны в отдельном файле.
Я понимаю, что готовое решение лучше, это проба пера для интереса, чтобы подключать и смотреть различные решения, но мы уже перешли на другую тему))) которая также на этом сайте уже озвучена. Мне интересно именно мнение относительно удобства, неважно какое приложение тетсируется. Удобно когда тесты написаны на “человекоподобном” языке, но нет специальных редакторов под него, на xml, или на программном коде? Также есть мнение, что если использовать человекоподобный язык, то можно функциональных тестеров “подсадить” писать тесты, но есть мнение, что какая разница какой структурированный язык использовать, все равно человек должен ему обучиться, а обучать можно любому. Как вы считаете?
Вы пишете список всех action-ов в каждом тесте, поэтому код самого теста становится тяжеловесным.
Я имела ввиду, чтоб Вы логику екшенов отделили от логики тестов.
На пайтоне это было б примерно так.
class LoginManager(object):
def _execute(self, args):
pass
def push_login_button(self):
self._execute("""<action name="Нажимаем на кнопку войти" type="clickElement" element="LoginButton">""")
def push_exit_button(self):
self._execute("""<action name="Нажимаем на кнопку выйти" type="clickElement" element="ExitButton">""")
Спасибо! Очень наглядно. А как все таки вы считаете, или может у вас был опыт. Если тесты пишутся на таком “человекоподобном” языке, функциональные тестировщики смогут писать тесты? Или это провальная практика?
Я тут немного поздно со своими мыслями (судя по датам), но вдруг…
Мы (когда обдумывали эту тему) пришли к следующему: будем писать тесты на понятном (более или менее) русском языке, а в качестве “велосипеда” использовать Robot Framework (собственно, он определяет общую логику построения тестов). Пока получается волшебно (тесты максимально приближены к бизнесу, автоматом получаются подробные актуальные пошаговые инструкции с картинками, есть связь с бизнес процессами и их “картами”, автоматические проверки входа и выхода и т.п.).
Надеемся постепенно “загнать” туда сам бизнес (методологов, которые регламенты и инструкции ваяют).
Тестим всего-лишь SAP.
Ни минуты не жалеем, продолжаем “изобретать” (пришлось “наконструлять” свое IDE, иначе все эти благости сложно достижимы), но движок не трогали - в итоге генерим роботовские файлы и запускаем robot-ом. Сейчас текущий challenge - тестировать САП в связке с внешней системой (точнее, в отвязке от оной. но с автоматической проверкой генерируемых САПом XML на соответствие ожиданиям внешней системы. Пока получается, но еще не вечер).
Могу поподробнее, если интересно. Где-то раньше я тут уже что-то про это писал, даже картинки прикладывал.
testomat.io управление авто тестами
