Comments 17
Спасибо за статью.
Каким образом вы перезапускаете тесты, чтоб исключить случайности? Если автоматически, то как с этим работает CI? Если автоматически, то как отслеживаете, какие тесты часто падают случайно и что с ними делаете?
Кто первый работает с результатами screenshot-based тестов: разработчики, тестировщики, автотестеры?
Какова вероятность ложного срабатывания отдельного теста? Сколько тестов всего? Сколько тестов ложно срабатывают в каждой сборке? Сколько времени ежедневно тратится на поддержку системы в контексте ложных срабатываний?
Каким образом вы перезапускаете тесты, чтоб исключить случайности? Если автоматически, то как с этим работает CI? Если автоматически, то как отслеживаете, какие тесты часто падают случайно и что с ними делаете?
Кто первый работает с результатами screenshot-based тестов: разработчики, тестировщики, автотестеры?
Какова вероятность ложного срабатывания отдельного теста? Сколько тестов всего? Сколько тестов ложно срабатывают в каждой сборке? Сколько времени ежедневно тратится на поддержку системы в контексте ложных срабатываний?
Каким образом вы перезапускаете тесты, чтоб исключить случайности? Если автоматически, то как с этим работает CI? Если автоматически, то как отслеживаете, какие тесты часто падают случайно и что с ними делаете?
После выполнения сценария понятно, есть ошибка или нет. Если есть ошибка, не завершая теста, мы выполняем сценарий заново с помощью механизма рул в junit. Отчет содержит ошибку, если она воспроизвелась заданное нами число раз. Соответственно, CI про это ничего не знает. Через некоторое время использования таких тестов приходит знание, какие колдунщики стабильны, а какие нет. Могу привести примеры нестабильных колдунщиков: время [который час], панорамы [панорама москвы], игры [игры онлайн]. Это либо анимация, либо сильно случайные данные. Срабатывания этих тестов однотипны и легко отличимы от реальных проблем.
Кто первый работает с результатами screenshot-based тестов: разработчики, тестировщики, автотестеры?
Удалось передать эксплуатацию тестов ручным тестировщикам (в большей степени) и разработчикам (в меньшей степени). Есть довольно прозрачный механизм запуска тестов и получения отчета в понятном стороннему от автоматизации человеку виде. От автоматизаторов теперь зависит добавление новой функциональности и поддержка тестовых сценариев (локаторы изменились, запросы протухли) — но и тут большая помощь идет от ручных тестировщиков. Мы дали им возможность редактировать и добавлять сценарии отдельно от кода.
Какова вероятность ложного срабатывания отдельного теста? Сколько тестов всего? Сколько тестов ложно срабатывают в каждой сборке? Сколько времени ежедневно тратится на поддержку системы в контексте ложных срабатываний?
Вероятность распределена неравномерно по тесткейсам. Есть тесткейсы, которые никогда не давали ложного срабатывания. Есть тесткейсы, которые почти всегда дают срабатывание (писал об этом выше, про нестабильные колдунщики). Для домена ru сейчас используетсяя около 700 тесткейсов. Скажем так, «срабатывает» около 10% тестов из запуска в нормальных условиях. Нормальные условия — это когда не меняют глобальные библиотеки стилей.
Про поддержку. Профит в том, что код практически не деградирует, иногда ему нужно добавлять новую функциональность. А вот тесткейсы естественно деградируют. Но практика показывает, что времени нужно немного. Бывают недели, когда вообще ничего не правим. Но хотел бы отметить, что нам главное не время на поддержку, а приносимая польза. Лучше сложнее поддержка, но больше экономии времени ручным тестировщикам (в разумных пределах, конечно).
Есть наша статистика, которую посчитали при запуске тестов в эксплуатацию: после появления тестов, время тестирования поисковой выдачи в одном браузере/домене сократилось с 90 минут до 46 (из которых 8 уходило на анализ отчета автотестов). Экономию в 44 минуты на каждый браузер/домен нужно умножить на число поддерживаемых конфигураций.
UFO just landed and posted this here
Очень удивился, почему тестовую среду проводите в субботу. Я думал это традиция такая будет: «тестовые среды с Яндексом».
p.s. Конечно, понятно, что удобство для людей важнее игры слов в названии мероприятия и календаре ;)
p.s. Конечно, понятно, что удобство для людей важнее игры слов в названии мероприятия и календаре ;)
О я такую же штуку замутил, когда надо было большой и отвественный модуль полностью переписать. Скриншоты генерил в phantom.js Командой написали кучу тестов, которые охватывают всю функциональность, включая драг-дроп. На питоне написал сравнивалку скриншотов. Скрипт находил разные файлы, подсвечивал разницу и складывал в отдельную папку. В результате прогона создавалось несколько сотен скриншотов. После рефакторинга скриншоты с подсвеченой разницей отлично помогли найти регрессии и ручное тестирование выявило минимум ошибок.
А в опенсорс не хотите выложить?
Легко, только надо немного времени, чтоб адекватную инструкцию написать.
Да выкладывайте, там разберемся :)
Хорошо что на Python!
Можно прикрутить к Robot Framework. У него есть встроенная библиотека ScreenshotLibrary, которая позволяет по ходу выполнения теста делать скриншоты.
Так что ждем ссылочку с нетерпением, а то утомились уже вручную скриншоты просматривать и анализировать.
Можно прикрутить к Robot Framework. У него есть встроенная библиотека ScreenshotLibrary, которая позволяет по ходу выполнения теста делать скриншоты.
Так что ждем ссылочку с нетерпением, а то утомились уже вручную скриншоты просматривать и анализировать.
Присоединяюсь :)
Написал пост на тему своей реализации. Таки извиняюсь, что дезинформировал вас — Питон был использован в другом проекте, а тут я обошелся готовыми средствами.
Интересно, может быть использовали какой-то умный алгоритм сравнения скриншотов? Понятно, что реальный браузер — зачастую самое медленное звено тестов, но и оптимизация сравнения больших скриншотов видится полезной.
извините за выражение, но sikuli
А у вас получилось использовать Сикули с пользой?
Если вы предлагаете использовать Sikuli IDE, то это видится неприемлемым. Как и популярная в свое время Selenium IDE.
Если использовать обвязку для webdriver, то я не совсем понимаю, как подружить sikuli с Selenium Grid, ведь фактически машина, на которой выполняется тест, и машина, на которой запущен используемый браузер, — это разные машины. А без грида мы получим неприемлемое время выполнения полного набора тестов.
В общем, хочется больше подробностей, как вы видите sikuli в качестве альтернативы описанному решению.
Если использовать обвязку для webdriver, то я не совсем понимаю, как подружить sikuli с Selenium Grid, ведь фактически машина, на которой выполняется тест, и машина, на которой запущен используемый браузер, — это разные машины. А без грида мы получим неприемлемое время выполнения полного набора тестов.
В общем, хочется больше подробностей, как вы видите sikuli в качестве альтернативы описанному решению.
Sign up to leave a comment.
Как мы тестируем поиск в Яндексе. Screenshot-based тестирование блоков результатов