Комментарии 16
Самые изощрённые умы даже реализуют [...] интерактивную модель солнечной системы.
Ну спасибо-спасибо, польстили))
Вообще тема очень интересная, неоднократно задумывался над этим вопросом сам и получал его от окружающих.
В нужный момент делаем снимки окон и сравниваем их попиксельно.
Меня всегда… смущал этот метод. В разных браузерах, в разных версиях одного браузера, зависимо от железа машини и настроек в одной версии одного браузера будет разная картинка.
Ну например Хром 26-й версии. На разных видеокартах может быть разный результат, т.к. по разному работает сглаживание. Всё-таки попиксельное сравнение очень ненадёжный метод.
Ещё более интересно как тестить анимации. Ну, например, передвигающийся по клику шарик. Как знать, что он передвигается плавно? С правильной скоростью, а не в три раза быстрее (а у меня был такой баг, что в Опере оно двигалось в два раза медленнее, чем в остальных браузерах!). Что, если движение не останавливается, а происходит непрерырвно, как в модели Солнечной системы?
Лично я пока решил, что подобные вещи стоит тестировать написанием «функциональных тестов» — просто создаём пару десятков примеров, которые покрывают большинство случаев и проверяем их вручную. Один такой пример может тестировать сразу несколько кусков. Например, отрисовку фигуры, плавное перемещение и клики по холсту.
Тема очень интересна и интересно, что вы думаете по этому поводу.
В общем-то в сравнении скриншотов меньше магии чем кажется. В рамках одного браузера в фиксированном окружении процесс вполне детерминированный и одинаковые скриншоты стабильно совпадают. При этом, конечно, сравнивать скриншоты, сделанные в разных браузерах, так просто не удастся, но и не очень нужно.
Обычно достаточно сравнения старой и новой версии в рамках одного браузера, при этом можно провести такое сравнение отдельно для каждого браузера.
Обычно достаточно сравнения старой и новой версии в рамках одного браузера, при этом можно провести такое сравнение отдельно для каждого браузера.
Меня больше смущают остальные вопросы)
Из остальных вопросов остается только «анимация».
Мы пошли по пути аналогичному вашему, т.е. все те же странички с примерами использования API Яндекс.Карт и просмотр их глазами.
По сути, изначально все именно так и тестировалось, но просмотр перед каждым релизом сотен страниц с примерами, во всех поддерживаемых браузерах, занимал огромное количество времени. Поэтому ту часть проверок, где нет анимации (а ее в API Яндекс.Карт не так уж и много) мы автоматизировали по описанной методике. Там же где есть анимация и в случае с проверкой новой функциональности от рук и глаз не отказаться.
Мы пошли по пути аналогичному вашему, т.е. все те же странички с примерами использования API Яндекс.Карт и просмотр их глазами.
По сути, изначально все именно так и тестировалось, но просмотр перед каждым релизом сотен страниц с примерами, во всех поддерживаемых браузерах, занимал огромное количество времени. Поэтому ту часть проверок, где нет анимации (а ее в API Яндекс.Карт не так уж и много) мы автоматизировали по описанной методике. Там же где есть анимация и в случае с проверкой новой функциональности от рук и глаз не отказаться.
Для движения одного элемента вроде легко относительно реализовать автоматическое тестирование через сравнение скриншотов. При сравнении выделяем прямоугольные области различий, вычисляем дельты по координатам центра или другой опорной точки и сравниваем их с ожидаемыми. Сложнее, если объектов много, да ещё они однотипные, типа как шары в биллиарде.
<img src="http://cho.justos.org:9119/counter.gif"/>Несмотря на то, что HTML5
Достаточно сравнить внешний вид стабильной версии интерфейса с тестируемой.
А как добавляются, например, новые элементы интерфейса в этом случае?
Конкретно в нашем решении, на страничке с отчетом отображаются скриншоты тестинга, продкашена и изображение с наложение первого на второе, где разница подсвечивается красным цветом. Если меняется внешний вид интерфейса (изменили шрифт в метке или изменили цвет текста), то приходится глазами проанализировать изображение с подсветкой разницы. Происходит это крайне редко и затрачивает секунды времени.
Тут надо отметить, что необходимо стараться проверять интерфейс по частям, тем самым мы минимизируем зависимость тестовых страниц от нетестируемых элементов.
Объясню на примере: вам необходимо протестировать возможность смены кругом цвета. Можно добавить на тестируемую страницу кнопку, при нажатии на которую круг изменит цвет, а можно повесить все ту же смену цвета на клик по самому кругу. Мы выбираем первый вариант. А потом у кнопок меняется шрифт и при сравнении скриншотов тест сообщит об ошибке. Поэтому надо было выбрать второй вариант, тогда бы у нас упали только те тесты, где проверялись кнопки. Если проверяем круг, и можно обойтись без использования сторонних объектов, то лучше обходиться без них.
Тут надо отметить, что необходимо стараться проверять интерфейс по частям, тем самым мы минимизируем зависимость тестовых страниц от нетестируемых элементов.
Объясню на примере: вам необходимо протестировать возможность смены кругом цвета. Можно добавить на тестируемую страницу кнопку, при нажатии на которую круг изменит цвет, а можно повесить все ту же смену цвета на клик по самому кругу. Мы выбираем первый вариант. А потом у кнопок меняется шрифт и при сравнении скриншотов тест сообщит об ошибке. Поэтому надо было выбрать второй вариант, тогда бы у нас упали только те тесты, где проверялись кнопки. Если проверяем круг, и можно обойтись без использования сторонних объектов, то лучше обходиться без них.
я правильно понимаю, что это текстовая версия доклада с SQA Days 12?
www.youtube.com/watch?v=aLUXFcYKq2Y&feature=youtu.be
www.youtube.com/watch?v=aLUXFcYKq2Y&feature=youtu.be
Sikuli пробовали, впечатления положительные, к сожалению, конкретно в нашем случае инструмент не очень подходит, потому-что в тестах графики на картах нет каких-то шаблонных изображений, полигоны перемещаются (под ними меняется фон), меняют форму и цвет.
Sikuli планируем использовать, но в других проектах, к примеру есть мысли попробовать данный инструмент в тестах мобильных приложений для подсчета одинаковых элементов на экране.
Sikuli планируем использовать, но в других проектах, к примеру есть мысли попробовать данный инструмент в тестах мобильных приложений для подсчета одинаковых элементов на экране.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Тестирование приложений на Canvas: рецепты на примере тестирования API Яндекс.Карт