fbpx
Магия автоматизации тестирования

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

Для тестирования подобных проблем можно воспользоваться возможностью Selenium снимать изображение экрана в момент работы с приложением. Для реализации понадобится “эталонная” база данных, которая содержит необходимые данные для работы всех страниц приложения. Ее стоит продумать очень тщательно и включить как можно больше примеров реальных данных, которые влияют на отображение вашего приложения в браузере. Вторым шагом нужно построить карту вашего сайта, чтобы понять какие страницы есть на нем и как к ним можно доступиться. У карт сайта есть еще одно очень полезное свойство – они позволяют освежить видение приложение, вспомнить основные функции и потоки управления. Когда у вас есть карта сайта, нужно написать автоматизированный скрипт на Selenium, который будет на каждом важном переходе сохранять изображение экрана под определенным именем в файловую систему. Я рекомендую для этого использовать режим RC, потому что вы получаете возможность легко осуществлять файловые операции с помощью функций языка программирования. Какой язык выбрать – дело ваше, но это необязательно должен быть язык, на котором написано само приложение.

В результате выполнения указанных шагов вы получите набор картинок. Обязательно просмотрите их вручную. Обратите внимание на неожиданные элементы, они могут появиться из-за специфики браузера или других внешних факторов. Поправьте окружение, чтобы избежать появления нежелательных эффектов. В итоге, вы получили шаблон отображения вашего сайта. Сохраните его в системе контроля версий вместе с Selenium сценариями. Теперь после любого изменения в коде вашего приложения, вы можете запустить сценарии снова и сравнить полученные картинки с имеющимся шаблоном. Те картинки, которые расходятся с шаблоном требуют ручного анализа, в результате которого будет найдена проблема или же обновлен шаблон. Этот процесс очень легко автоматизировать и запускать в нужные моменты (завершение задачи, подготовка к концу итерации, подготовка к релизу и другие). Что это вам дает? Это дает вам возможность быстро понять на чем нужно сосредоточить внимание. Если ваше приложение имеет более 100 страниц, то вероятность изменений во всех страницах очень мала (когда были глобальные изменения в дизайне или функциональности). Обычно изменения будут касаться малого количества страниц, что сильно экономит ваше время.

Я описал только базовое решение. Его можно расширять дальше, делая все более полезным и удобным. К примеру, вместо полного сравнения картинок можно выделять и конфигурировать определенные регионы, представляющие интерес. Это даст возможность избежать проблем с рекламой, баннерами и прочими динамическими элементами. Также можно добавить работу со всеми поддерживаемыми браузерами, что позволит добиваться одинакового отображения в каждом из них. Чтобы не писать все с нуля, можно воспользоваться одним из существующих решений, к примеру СSS Test на Python.

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

В работе с изображениями можно пойти дальше. Для этого нужно получить изображения экрана при различных настройках стилей отображения (прозрачный текст, разный цвет фона, четкие границы для картинок и т.д.) и проводить автоматический анализ. Благодаря этому анализу можно разложить картинку на составные части, выделив границы элементов, текст, картинки, элементы управления браузера. Michael Tamm разработал собственную библиотеку Fighting Layout Bugs для подобного анализа. Подробнее об использовании библиотеки и побудивших причинах ее написания он рассказал на конференции QCon. Исходные файлы библиотеки доступны и это хорошая стартовая точка, с возможностью внесения своих специфических изменений.

Как видите, автоматизированное тестирование отображения вашего сайте – это не миф, а доступная реальность. Качество и отдача от такого тестирование – это уже дело ваших рук и умений! Магия только начинается…

Обсуждение (
Warning: A non-numeric value encountered in /sata1/home/users/xpinjecti/www/www.xpinjection.com/wp-includes/pomo/plural-forms.php on line 280

Warning: A non-numeric value encountered in /sata1/home/users/xpinjecti/www/www.xpinjection.com/wp-includes/pomo/plural-forms.php on line 280

Warning: A non-numeric value encountered in /sata1/home/users/xpinjecti/www/www.xpinjection.com/wp-includes/pomo/plural-forms.php on line 280

Warning: A non-numeric value encountered in /sata1/home/users/xpinjecti/www/www.xpinjection.com/wp-includes/pomo/plural-forms.php on line 280

Warning: A non-numeric value encountered in /sata1/home/users/xpinjecti/www/www.xpinjection.com/wp-includes/pomo/plural-forms.php on line 280

Warning: A non-numeric value encountered in /sata1/home/users/xpinjecti/www/www.xpinjection.com/wp-includes/pomo/plural-forms.php on line 280
0)

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

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

принять