achugr Jun 11 2013 at 16:27

Эксперимент в Яндексе: как роботы помогают тестировать сервисы

7 min

26K

Яндекс corporate blogIT systems testing*Website development*

+67

Comments 28

FreemindMike Jun 11 2013 at 18:18

Спасибо, интересно было почитать.
А сколько по времени делали робота?

achugr Jun 11 2013 at 18:50

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

UFO just landed and posted this here

achugr Jun 11 2013 at 19:22

Действительно, внешнее сходство есть.

shebanoff Jun 11 2013 at 21:08

А я то думал, что это и есть миньон из мультика, пока комментарий не прочитал :)

monolithed Jun 11 2013 at 19:09

Планируете ли вы развивать этот «эксперимент» в открытом сообществе?

achugr Jun 11 2013 at 19:19

Очень не хочется обещать и не выполнить! Планы такие есть, да.

mecommayou Jun 11 2013 at 23:02

Julles Jun 11 2013 at 21:19

А в чем состоит самообучаемость робота? Я так понимаю, именно в этом состоит различие между автотестами и роботом. Или же разница сводится лишь к тому, что вам не надо жестко прописывать страницы/формы в сценариях, он способен сам их находить и обрабатывать?

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

achugr Jun 11 2013 at 22:39

У робота самообучаемости нет. Да, универсальность заключается в том, что роботестер самостоятельно выбирает способ взаимодействия с формой и генерирует тестовые сценарии без участия человека. Планируем добавить supervised-методы обучения, например, для классификации страниц с ошибками. Unsupervised-методы для обнаружения ошибок — интересная тема, но к роботу в данный момент отношения не имеет.

monolithed Jun 11 2013 at 23:01

А могли бы рассказать, а лучше и привести пример лога?
Интересно какие данные вы получаете на выходе и как в дальшем их обрабатываете.

achugr Jun 12 2013 at 00:50

Результат работы робота — сообщения об ошибках. Лог мы используем только для отладки.
Роботестер выполняет тест-кейс, а потом собирает со страницы различную информацию (текст со страницы, ссылки, текст алертов(если они появились) и отдает эту информацию в JUnit-тесты. JUnit-отчеты нам не совсем подходят, поэтому мы строим из них свои, «красивые» отчеты. Их смотрит тестировщик и пишет баг-репорты. В «красивых» отчетах можно применять фильтры по типу ошибок и склеивать похожие сообщения об ошибках в группы.

iSeiryu Jun 12 2013 at 01:32

Бедные тестировщики потеряют свои рабочие места :(

spacediver Jun 12 2013 at 02:14

богатые (=квалифицированные) — не потеряют ;)

achugr Jun 12 2013 at 10:33

Вы правы! Например, с бизнес-логикой даже человеку бывает непросто разобраться.

achugr Jun 12 2013 at 13:53

Не потяреют. Наоборот, мы планируем улучшить жизнь тестировщиков, отдав рутинную работу роботестеру.

david_mz Jun 12 2013 at 13:08

С формами вроде бы напрашивается решение встроить доп. семантику в сам HTML-код. Например, [input … name=«address» data-ya-type=«geo-cityname-destination»]. Ну или что-то вроде. Ведь и робот и тестируемые страницы у вас под контролем.

achugr Jun 12 2013 at 13:49

Хорошая мысль, мы думаем сделать что-то вроде «микроразметки для тестирования». Конечно, непросто внедрить общий формат в большой компании и добавить такую разметку в уже существующие интерфейсы.

marshinov Jun 12 2013 at 14:19

Все бы хорошо, только вот заставить всех писать такую разметку очень сложно.
Можно пойти с другой стороны и парсить label'ы и placeholder'ы. А дальше по набору эвристик определять тип поля. Дополнительно можно попробовать парсить .error, .validate — поля. Взять наиболее популярные фреймворки, посмотреть, какого вида валидацию они используют и при неправильном вводе смотреть, что вернула валидация. Вот тут масса простора для самообучения робота, хотя и возникает необходимость работы с естественными языкам.

achugr Jun 13 2013 at 17:31

Да, мы используем label, placeholder, name — все что может содержать текст, несущий информацию о типе поля ввода. Парсить валидацию — это интересно! Кстати, в одной статье про краулинг deep web описан примерно такой способ: робот заполняет форму, отправляет ее и смотрит какой контент пришел в ответ. Так он делает много раз. Если очередной вариант заполнения практически не изменяет контент ответа, значит форма была заполнена некорректно.

danpetruk Jun 12 2013 at 14:14

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

achugr Jun 12 2013 at 14:31

У нас есть желание сделать этот проект открытым, но в данный момент мы не готовы говорить об этом. Причину описывал выше.

greck Jun 12 2013 at 14:20

Очень интересно!

Интеграционные тесты (цель которых — иметь большое покрытие и, грубо говоря, отлавливать 404) в UI действительно могут быть автоматизированы влоть до автогенерации множества сценариев.

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

Ну и, конечно, как уже сказали, можно заставить разработчиков давать подсказки роботу через семантику HTML. Семантика кнопок Вперед, Назад, Расширенные настроки, например, позволит роботу не гулять по циклу в длиных визардах, а веса у ссылок и значений позволят в первую очередь покрывать типичные сценарии).

Разработчикам больше работы, зато тестеры будут заниматься только функциональными тестами бизнес логики.