Лень писать это в соседнюю ветку на 100500 страниц, поэтому понапложу сущности без необходимости
Пара смешных людей рассказывают о том, как все подряд покрывается автоматическими тестами и прочей ерундой, и тесты на GUI пишутся на раз.
И тут у меня как раз возник момент.
Дано: рисуется в браузере график при помощи SVG. График рисуется generic-библиотекой. После того, как он отрисовался, среди прочего, делается следующее:
— берется текст, который будет заголовком графика, title
— берется нарисованый график, chart
— oldY = chart.Y
— chart.Y = chart.Y + title.height
— title.X = chart.X
— title.Y = oldY
— title.height, естественно, зависит от CSS, и, собственно, от того, как это отображается в браузере.
То есть, понятно, что график смещается вниз, и вверху рисуется заголовок.
Проблема 1. Firefox
В Safari и Chrome все правильно. В Firefox title смещается влево примерно на title.width/2.
Вопрос: как это определить автоматическими тестами, без тестирования человеком? Ну, учитывая, что автоматический тест будет использовать те же getWidth[1] и прочее, что и код
Проблема 2. Display: none -> Display: block/inline
Графики отображаются на панели, которая изначально скрыта.
— Если панель изначально раскрыта, то никаких проблем нет.
— Если панель скрыта, а потом раскрывается, то в зависимости от времени загрузки данных в график (среди прочего), те самые getWidth и прочая возвращают неправильные значения, из-за чего chart не смещается вниз, а title отображается в неправильной позиции.
Найдено тоже только при ручном тестировании. Какой автоматический тест это покроет?
здесь вам нужны не юнит-тесты, также из описания непонятна частота появления таких багов.
отловить такие проблемы автоматизированными тестами вполне реально, но требует усилий и каких-либо затрат. самый тупой вариант — через автосравнивалки скриншотов, подход вполне будет работать можно с использованием Sikuli. вопрос в стабильности решений и в цене разработки-поддержки по отношению к тестированию интерфейса руками.
Z>отловить такие проблемы автоматизированными тестами вполне реально, но требует усилий и каких-либо затрат. самый тупой вариант — через автосравнивалки скриншотов,
Ээээ. Сравнение каких скриншотов?
Z>вопрос в стабильности решений и в цене разработки-поддержки по отношению к тестированию интерфейса руками.
Здравствуйте, Mamut, Вы писали:
M>Лень писать это в соседнюю ветку на 100500 страниц, поэтому понапложу сущности без необходимости
Мне кажется вполне очевидным, что любое автоматизированное тестирование обязано тестировать полезную работу, которая от кода ожидается, вне зависимости от гранулярности тестирования (то есть и в тестировании самого мельчайшего модуля мы тестируем, что «при корректных данных на входе получаются корректные данные на выходе», а не что «внутренний цикл выполнится 84 раза»);
тестирование GUI — это, по сути, много разных типов тестирований, но два базовых (и сильно разных типа) — а) как оно выглядит и б) как оно себя ведёт;
тесты «как оно выглядит» раньше были менее важны (ну, грубо говоря в период когда почти любой интерфейс это была статичная «форма», раз и навсегда сляпанная в «дизайнере форм»), теперь всё по-другому, конечно;
естественно, тест «как оно выглядит» в идеале должен тестировать ээээ КАК ОНО ВЫГЛЯДИТ, а не значение внутренней переменной dom.get('blah').children('foo').innerHeight;
↑ естественно, единственный способ корректного тестирования «как оно выглядит» — это снятие и анализ скриншотов; поскольку это алгоритмически сложно (кроме простейшего случая «сравнение скриншота с образцом попиксельно», далеко не всегда уместного) — автоматизированное тестирование интерфейса подменяется либо ручным тестированием, либо тестированием внутреннего состояния объектов интерфейса;
но «алгоритмически сложно» не значит невозможно; потенциальные подходы довольно очевидны, и я подозреваю, что соответствующие инструменты вполне себе есть (я не могу сходу назвать таковых, но я и не искал, though, вот интересный ответ на SO).
Здравствуйте, Гест, Вы писали:
Г> ↑ естественно, единственный способ корректного тестирования «как оно выглядит» — это снятие и анализ скриншотов; поскольку это алгоритмически сложно (кроме простейшего случая «сравнение скриншота с образцом попиксельно», далеко не всегда уместного) — автоматизированное тестирование интерфейса подменяется либо ручным тестированием, либо тестированием внутреннего состояния объектов интерфейса;
Можно сравнивать DOM.
Ну и в общем случае можно провести сначала ручное тестирование, записав все действия и заскриншотив состояние после, а потом при автомтическом тестировании проигрывать действия пользователя и уже реально просто сравнивать скриншоты. В общем случае — так как все браузеры разные, придется пройти по разу для каждого браузера.
Так очень быстро можно отловить ошибки, которые возникнут после очередного обновления <вставьте имя своего любимого браузера>
Здравствуйте, Гест, Вы писали:
Г> Г> любое автоматизированное тестирование обязано тестировать полезную работу, которая от кода ожидается, вне зависимости от гранулярности тестирования (то есть и в тестировании самого мельчайшего модуля мы тестируем, что «при корректных данных на входе получаются корректные данные на выходе», а не что «внутренний цикл выполнится 84 раза»); Г> тестирование GUI — это, по сути, много разных типов тестирований, но два базовых (и сильно разных типа) — а) как оно выглядит и б) как оно себя ведёт; Г>
Правильнее говорить о проблемах с тз конечного потребителя
1. снижается продуктивность (юзер будет быстро уставать и делать невынужденные ошибки)
2. функционал недоступен (юзер не сможет нажать кнопку)
3. результаты некорректны (юзер примет неверное решение, вынужденная ошибка)
4. и тд, например данные юзера повреждаются, безопасность страдает (прямой или непрямой ущерб для юзера)
При этом само решение может быть в трёх случаях совершенно одинаковым, например, правка CSS. Более того, в зависимости от данных юзера 1 2 и 3 могут быть вообще одним и тем же багом с тз девелопера, который воспроизводится по разному. На одних данных результат трудно читать. На других — результаты не видны, на третьих — выглядят как корректные, но такими не являются.
Что бы накидать авто-тест, нужен ни много, ни мало, а эталонный dom/css процессор, который сможет сказать, что де результаты 1 отрендерились корректно и 2 видны должным образом и 3 кликабельны. Без этого можно сказать что "бокс есть, стиль установлен", что означает "есть ли проблема — а хрен его знает"
Что касается автоматизации, то надо учитывать, что затраты на создание авто-тестов много больше любых мануальных тестов, нужно и отладить и всё равно проверить вручную, действительно ли тест зеленый, когда все сильно, и действительно ли тест красный, когда всё плохо и наоборот.
Отсюда ясно, что автотестами покрывать функционал, который еще не устаканился, смысла не сильно много — завтра всё изменится, а тесты придется выбросить и писать новые.
Специфика UI в основном такая, что:
1 требования в большинстве "сделайте шоб всё было сильно, как на картинке, но по другому"
2 зависимость от чужого кода просто адская — svg, dom, css и тд, не говоря о либах
3 особенности os которые не позволяют использовать кое какие аспекты рендеринга
Ну собственно мы уперлись в более точную постановку задачи.
Например, предположим (так как в исходной постановке я этого не увидел, то могу предполагать то что мне удобно), что у нас есть задача прогонки так иногда называемых регресс-тестов (или просто функциональных), т.е. автоматизированы успешно проходящие тесты или тесты, которые когда либо выявляли ошибки, тогда у нас очевидным образом при создании теста могут оказаться скриншоты того как должны выглядеть наши контролы в том или ином состоянии (и возможно скриншоты типичных ошибок рендеринга). Если это так, то при прогоне мы можем делать скриншот (полный экрана, но лучше частичный некоторой области — вплоть до отдельного контрола) и сравнивать его с помощью встроенной функции или функции из внешней библиотеки сперва на ожидаемое значение, если изображения не совпали, то прогонять сравнение на скриншотах типичных ошибок для классификации текущего состояния или помечать ошибку как вновь найденное подозрительное состояние. Я что-то из питоновской либы PIL использовал вроде. C названием Image Grab (!?) и тулу Image Magic.
Sikuli, работающий через распознавание, должен вроде больше возможностей давать для такого рода анализа. Не помню так как давно на него смотрел умеет ли он текст распознавать. В любом случае можно даже подключить простую распознавалку.
Но детальнее говорить о такого рода тестах нужно при более детальной постановке задачи на тестирование и его автоматизацию. Так как порой проще руками прогнать тесты интерфейса.
Вариантов вообще множество на самом деле. Еще можно определять параметры текста и смотреть отобразился ли текст заданной ширины или что контрол отобразился с шириной х, а текст для данного заданного шрифта и его параметров должен быть y, а x<y (ну и позиционирование сюда добавить). Иногда такие баги по косвенным признакам можно отловить (например задание текста в контроле отличается от аналогичных или от состояния контрола в другой момент времени и тогда делать скрин и кидать ворнинг для ручной проверки).
Еще вариант просто делать скрины в заданный момент времени и отдавать потом просматривать глазами на выходе (это первый этап того что описано в самом начале для классификации ошибок).
Зависит от технологий которые используются, от ресурсов и желания. Давно гуём не занимался, потому мог что-то забыть или упустить или не знать о каких-то новинках.
Здравствуйте, Mamut, Вы писали:
M>В Safari и Chrome все правильно. В Firefox title смещается влево примерно на title.width/2.
M>Вопрос: как это определить автоматическими тестами, без тестирования человеком?
Это как раз просто, подобное я делал — делается эталонное изображение (может быть мокап), потом сравнивается с тем, что есть, если отличий больше некоего процента — алярм.
M>Найдено тоже только при ручном тестировании. Какой автоматический тест это покроет?
Тот который я описал. Правда нужно ли так делать для ГУЯ я не уверен, я делал такие тесты для рендерера.
M>>Вопрос: как это определить автоматическими тестами, без тестирования человеком?
MTD>Это как раз просто, подобное я делал — делается эталонное изображение (может быть мокап), потом сравнивается с тем, что есть, если отличий больше некоего процента — алярм.
У нас есть эталонное изображение, нарисованное дизайнером. Стоит ли говорить, что достичь этой эталонности в браузере невозможно? В одном браузере. Я даже не заикаюсь про три
Z>у нас очевидным образом при создании теста могут оказаться скриншоты того как должны выглядеть наши контролы в том или ином состоянии (и возможно скриншоты типичных ошибок рендеринга).
1. То, как контролы должны выглядеть, нарисовано дизайнером. Понятно, что в подавляющем большинстве случаев достичь этой эталонности невозможно
2. Я не знаю, что такое «типичные ошибки рендера». У меня в исходном сообщении две ошибки. Являются ли они типичными? Хз.
Z>Вариантов вообще множество на самом деле. Еще можно определять параметры текста и смотреть отобразился ли текст заданной ширины или что контрол отобразился с шириной х, а текст для данного заданного шрифта и его параметров должен быть y, а x<y (ну и позиционирование сюда добавить). Иногда такие баги по косвенным признакам можно отловить (например задание текста в контроле отличается от аналогичных или от состояния контрола в другой момент времени и тогда делать скрин и кидать ворнинг для ручной проверки).
Ну, это — да, возмжно. Но пока напишешь эти тесты, уже стопятьсот раз руками все прокликаешь
Здравствуйте, Mamut, Вы писали:
M>>>Вопрос: как это определить автоматическими тестами, без тестирования человеком?
MTD>>Это как раз просто, подобное я делал — делается эталонное изображение (может быть мокап), потом сравнивается с тем, что есть, если отличий больше некоего процента — алярм.
M>У нас есть эталонное изображение, нарисованное дизайнером. Стоит ли говорить, что достичь этой эталонности в браузере невозможно? В одном браузере. Я даже не заикаюсь про три
Если результат работы браузера стабилен, то почему нет? Смотрим вручную, аппрувим три скриншота из трех браузеров как "эталонные", и вперед. Пока картинка не меняется, тесты зеленые. Изменилась — смотрим вручную и по ситуации фиксим или аппрувим новые скриншоты. Возможно, будет слишком фраджильно, надо пробовать.
M>>У нас есть эталонное изображение, нарисованное дизайнером. Стоит ли говорить, что достичь этой эталонности в браузере невозможно? В одном браузере. Я даже не заикаюсь про три
v6>Если результат работы браузера стабилен, то почему нет?
Потому что браузер — это не фотошоп/Sketch/Zeplin
v6>Смотрим вручную, аппрувим три скриншота из трех браузеров как "эталонные", и вперед.
Что вперед? То есть мы в итоге все равно сделали ручное тестирование
Здравствуйте, Mamut, Вы писали:
v6>>Смотрим вручную, аппрувим три скриншота из трех браузеров как "эталонные", и вперед. M>Что вперед? То есть мы в итоге все равно сделали ручное тестирование
С такими автоматическими gold-тестами можно например спокойно делать рефакторинг, не проверяя каждый раз вручную не поломалось ли чего лишнего.
А в случаях когда вносятся патчи изменяющие результат — то в большинстве случаев меняется только малая часть тестовых case'ов, и нужно перепроверить вручную только их. Причём с возможностью получить/подсветить diff процесс сильно упрощается.
EP>С такими автоматическими gold-тестами можно например спокойно делать рефакторинг, не проверяя каждый раз вручную не поломалось ли чего лишнего.
У нас вот сейчас рефакторинг страницы вокруг собственно графиков. В принципе, чисто визуальный (по-моему, там даже структура кода не меняется). Как только это изменение будет завершено, при условии, что у нас есть авто-тест на графики, он тут же сломается, потому что график будет уже сильно и далеко не там, где надо.
Здравствуйте, Mamut, Вы писали:
M>>>У нас есть эталонное изображение, нарисованное дизайнером. Стоит ли говорить, что достичь этой эталонности в браузере невозможно? В одном браузере. Я даже не заикаюсь про три
v6>>Если результат работы браузера стабилен, то почему нет?
M>Потому что браузер — это не фотошоп/Sketch/Zeplin
v6>>Смотрим вручную, аппрувим три скриншота из трех браузеров как "эталонные", и вперед.
M>Что вперед? То есть мы в итоге все равно сделали ручное тестирование
Получили в довесок к ручном тестированию автоматические регрессионные тесты.
Это не так уж и мало и гораздо лучше, чем все время проверять руками или прозевать внесенный баг.
Здравствуйте, MTD, Вы писали:
M>>Найдено тоже только при ручном тестировании. Какой автоматический тест это покроет?
MTD>Тот который я описал. Правда нужно ли так делать для ГУЯ я не уверен, я делал такие тесты для рендерера.
С UI вся загвоздка. Во первых, динамики полно, во вторых, всякие градиентные заливки в моде, в третьих нюансы лайоута в зависимости от разных вещей, т.е. UI который для человека выглядит одинаково, с т.з. картинки будет совершенно разный набор пикселов. Кроме того, UI в норме меняется довольно часто. Подвинули кнопку — надо забейзлайнить все тесты на которых она видна.
Здравствуйте, Mamut, Вы писали:
EP>>С такими автоматическими gold-тестами можно например спокойно делать рефакторинг, не проверяя каждый раз вручную не поломалось ли чего лишнего. M>У нас вот сейчас рефакторинг страницы вокруг собственно графиков. В принципе, чисто визуальный (по-моему, там даже структура кода не меняется).
Рефакторинг по определению не меняет внешнее поведение. В твоём же случае по сути как раз поведение и меняется, пусть и только визуальное.
M>Как только это изменение будет завершено, при условии, что у нас есть авто-тест на графики, он тут же сломается, потому что график будет уже сильно и далеко не там, где надо.
Вот автоматический image diff как раз и поможет тебе быстро проверить туда ли уехал график, и не перекрыл ли он что-то лишнее, и не нарисовалась ли какая-нибудь клякса в абсолютно другом месте.
M>>У нас вот сейчас рефакторинг страницы вокруг собственно графиков. В принципе, чисто визуальный (по-моему, там даже структура кода не меняется).
EP>Рефакторинг по определению не меняет внешнее поведение. В твоём же случае по сути как раз поведение и меняется, пусть и только визуальное.
Поведение графика не меняется. Всех его родительских компонентов вплоть до чуть ли не 10-го уровня не меняется
M>>Как только это изменение будет завершено, при условии, что у нас есть авто-тест на графики, он тут же сломается, потому что график будет уже сильно и далеко не там, где надо.
EP>Вот автоматический image diff как раз и поможет тебе быстро проверить туда ли уехал график, и не перекрыл ли он что-то лишнее.
Скорее, он покажет, что изменился дизайн страницы, после чего — опять с начала. Открываем ручками в трех браузерах, ручками делаем «канонические скриншоты» и т.п.
Здравствуйте, Mamut, Вы писали:
M>>>У нас вот сейчас рефакторинг страницы вокруг собственно графиков. В принципе, чисто визуальный (по-моему, там даже структура кода не меняется). EP>>Рефакторинг по определению не меняет внешнее поведение. В твоём же случае по сути как раз поведение и меняется, пусть и только визуальное. M>Поведение графика не меняется. Всех его родительских компонентов вплоть до чуть ли не 10-го уровня не меняется
Какая разница у чего конкретно поменялось визуальное поведение, поменялось же?
M>>>Как только это изменение будет завершено, при условии, что у нас есть авто-тест на графики, он тут же сломается, потому что график будет уже сильно и далеко не там, где надо. EP>>Вот автоматический image diff как раз и поможет тебе быстро проверить туда ли уехал график, и не перекрыл ли он что-то лишнее. M>Скорее, он покажет, что изменился дизайн страницы, после чего — опять с начала. Открываем ручками в трех браузерах, ручками делаем «канонические скриншоты» и т.п.
Ты скриншоты ручками что-ли собрался делать?
Автоматический image diff на то и автоматический что он сам соберёт все скриншоты, выявит изменившиеся, сделает diff (попиксельный, либо с подсветкой изменённой области, либо ещё какой подходит по задаче), зашлёт в dashboard и даст кнопочку approve
Тут выше предложили делать исключительно ручками
EP>Автоматический image diff на то и автоматический что он сам соберёт все скриншоты, выявит изменившиеся, сделает diff (попиксельный, либо с подсветкой изменённой области, либо ещё какой подходит по задаче), зашлёт в dashboard и даст кнопочку approve
