Санкт-Петербургский государственный электротехнический университет

«ЛЭТИ» им. В.И.Ульянова (Ленина)

(СПбГЭТУ «ЛЭТИ»)

Направление 09.04.02 – Информационные системы и

технологии
Программа Распределенные вычислительные
комплексы систем реального времени
Факультет ФКТИ
Кафедра АСОИУ

К защите допустить
Зав. кафедрой Цехановский В.В.

ВЫПУСКНАЯ КВАЛИФИКАЦИОННАЯ РАБОТА

МАГИСТРА

Тема: СОЗДАНИЕ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ

ТЕСТИРОВАНИЯ ВЕРСТКИ ВЕБ-САЙТА

Студент Дьяченко А.Д.

подпись

Руководитель Ильин В.П.

(Уч. степень, уч. звание) подпись

Консультанты Наконечнюк А.В.

(Уч. степень, уч. звание) подпись

Санкт-Петербург
2016
 ЗАДАНИЕ
НА ВЫПУСКНУЮ КВАЛИФИКАЦИОННУЮ РАБОТУ

Утверждаю
Зав. кафедрой АСОИУ
____________ Цехановский В.В.
«___»______________20___ г.

Студент Дьяченко А.Д. Группа 0373

Тема работы: Создание автоматизированной системы тестирования верстки

Место выполнения ВКР: место выполнения ВКР

Исходные данные (технические требования):
кратко указываются основные требования к ВКР

Содержание ВКР:
Кратко указывается основное содержание ВКР, перечисляются ее основные
разделы

Перечень отчетных материалов: текст ВКР, иллюстративный материал,

Дополнительные разделы: указывается наименование дополнительного

раздела

Дата выдачи задания Дата представления ВКР к защите

«___»______________20___ г. «___»______________20___ г.

Студент Дьяченко А.Д.

Руководитель Ильин В.П.

(Уч. степень, уч. звание)

Консультант Наконечнюк А.В.

 КАЛЕНДАРНЫЙ ПЛАН ВЫПОЛНЕНИЯ
ВЫПУСКНОЙ КВАЛИФИКАЦИОННОЙ РАБОТЫ

Утверждаю
Зав. кафедрой АСОИУ
____________ Цехановский В.В.
«___»______________20___ г.

Студент Дьяченко А.Д. Группа 0373

Тема работы: Создание автоматизированной системы тестирования верстки

№ Срок
Наименование работ
п/п выполнения
00.00 –
1 Обзор литературы по теме работы
00.00
00.00 –
2 Наименование раздела
00.00
00.00 –
3 Наименование раздела
00.00
00.00 –
4 Наименование раздела
00.00
00.00 –
5 Оформление пояснительной записки
00.00
6 Оформление иллюстративного материала

Студент Дьяченко А.Д.

Руководитель Ильин В.П.

Консультант Наконечнюк А.В.

(Уч. степень, уч. звание)
 РЕФЕРАТ

Пояснительная записка 00 стр., 00 рис., 00 табл., 00 ист., 00 прил.

ВЕРСТКА, АВТОМАТИЗИРОВАННОЕ ТЕСТИРОВАНИЕ, ВЕБ-
САЙТЫ, ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ, ОШИБКА, GUI
Объектом исследования является автоматизированная система
тестирования верстки веб-сайта.
Цель работы – разработка автоматизированной системы тестирования
верстки веб-сайта.
Данная работа содержит описание и анализ современных технологий
верстки веб-интерфейсов, современных подходов к автоматическому
тестированию сайтов и дальнейшее развитие этих подходов. В процессе
выполнения данной работы были классифицированы ошибки верстки
возникающие на страницах веб-сайтов, и методы их обнаружения,
разработана, протестирована и отлажена программа осуществляющая
автоматизированное тестирование страниц веб-сайта. Программа
реализована средствами Selenium Webdriver и JavaScript.
 ABSTRACT

Object of research is the automated system of testing website front-end.

The work purpose – development of the automated system of testing website front-
end.
This work contains the description and the analysis of modern technologies of
web-interfaces, web-site front-end, modern approaches to automatic testing of the
websites and further development of these approaches. In the course of
performance of this work the imposition errors appearing on pages of websites, and
methods of their detection have been classified, the program which is carrying out
the automated testing of pages of the website is developed, tested and debugged.
The program is realized by means of Selenium Webdriver and JavaScript.
 СОДЕРЖАНИЕ

Введение 8
1. Постановка задачи 13
2. Анализ современных технологий верстки веб-интерфейсов 14
2.1. HTML 14
2.2. CSS 14
2.3. Javascript 17
2.4. Фреймворк тестирования web-приложений Selenium
Webdriver 18
2.5. Основные понятия и методы Selenium Webdriver API 19
2.6. Типы локаторов 21
2.7. Ожидания 23
3. Анализ современных подходов к автоматическому
тестированию сайтов 26
3.1. Уровни тестирования 28
3.2. Основные подходы к автоматизации тестирования 28
3.3. GUI - автоматизация 28
3.4. Приложения 31
4. Классификация ошибок верстки и алгоритмы их обнаружения
33
5. Разработка основных программных модулей на основе
полученной информации 43
5.1. Схема работы программы 46
5.2. Сведение результатов в отчет 48
6. Тестирование и отладка программы 50
7. Составление бизнес-плана по коммерциализации результатов 52
НИР магистранта
7.1. Концепция экономического обоснования 52
7.2. Краткое техническое описание системы. 52
7.3. Определение длительности работ и создание календарного 53
плана.
7.4. Расчет основной и дополнительной заработной платы, 57
расходов на страховые взносы.
7.5. Расчет расходов на сырье и материалы. 58
7.6. Расчет затрат на содержание и эксплуатацию оборудования. 60
7.7. Определение себестоимости продукта. 63
7.8. Вывод. 63
8. Дальнейшее развитие 65
8.1. Тестирование Rich Internet Applications 65
8.2. Единовременный запуск в нескольких браузерах 65
8.3. Обратная связь и исключения 65
8.4. Самообучение 66
8.5. Обратная связь и исключения 66
Заключение 69

Список использованных источников 71

 ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ

В настоящей пояснительной записке применяют следующие термины с

соответствующими определениями:
CSS – формальный язык описания внешнего вида документа,
написанного с использованием языка разметки.
GUI – разновидность пользовательского интерфейса, в котором
элементы интерфейса (меню, кнопки, значки, списки и т. п.), представленные
пользователю на дисплее, исполнены в виде графических изображений.
HTML – стандартизированный язык разметки документов во
Всемирной паутине.
JavaScript – прототипно-ориентированный сценарный язык
программирования. Является реализацией языка ECMAScript
Браузер – прикладное программное обеспечение для просмотра веб-
страниц; содержания веб-документов,компьютерных файлов и их каталогов;
управления веб-приложениями; а также для решения других задач.
Верстка – создание структуры html-кода, размещающего элементы веб-
страницы (изображения, текст и т. д.) в окне браузера, согласно
разработанному макету, таким образом, чтобы элементы дизайна выглядели
аналогично макету.
Драйвер – компьютерное программное обеспечение, с помощью
которого другое программное обеспечение (операционная система) получает
доступ к аппаратному обеспечению некоторого устройства.
Тест-кейс – это набор условий, при которых тестировщик будет
определять, удовлетворяется ли заранее определённое требование.
 ВВЕДЕНИЕ

С начала 21 века, сеть Интернет стремительно развивается, проникая во

все сферы жизни, в частности в большинство сфер бизнеса. Количество
пользователей сети Интернет сейчас составляет около 3.5 миллиарда человек,
а количество зарегистрированных доменов в сети приближается к 300
миллионам и это число продолжает расти. Создание собственных сайтов
стало необходимым в большинстве сфер бизнеса; более того, многие
интернет-сервисы начали монетизацию своих услуг за счет рекламы,
платного контента и добровольных пожертвований, из наиболее
примечательных можно отметить крупные интернет-поисковики такие как
Яндекс и Google, видеохостинги Youtube и Vimeo, социальные сети
Facebook, Google+, Vkontakte.
Интернет-сервисы могут приносить огромную прибыль, что приводит к
огромной конкуренции в этой сфере, которая благодаря выходу на рынок
новых игроков продолжает расти с большой скоростью. Даже небольшие
ошибки, допущенные при разработке, могут привести к огромным
репутационным потерям, что ведет к оттоку пользователей в пользу
конкурентов и как следствие потере капитала и уходу с рынка.
Поэтому, как и во многих других областях, тестирование играет очень
важную роль и в процессе создания веб-сайтов и разработке интернет-
сервисов. Разработка большинства крупных сайтов требует привлечения
большого количества специалистов в разных областях, начиная с построения
бизнес-модели и маркетинга, и заканчивая командой поддержки и развития
проекта. Этим специалистам приходится решать огромное количество самых
разнообразных задач, таких как проектирование архитектуры сервиса, его
дизайна, управление данными сервиса, обеспечение его безопасности,
поддержка и тестирование, наполнение контентом и прочее. В данной работе
будет рассмотрена та часть работы, которая ложиться на плечи
тестировщиков, которые обеспечивают так называемое «счастье
пользователя».
Тестирование производится на различных этапах разработки, но в этой
работе будет рассмотрено тестирование интерфейса уже существующего
интернет-сервиса, с которым непосредственно взаимодействует
пользователь.
В зависимости от того, насколько тестировщик вовлечен в процесс
разработки, можно выделить два основных вида тестирования: ручное и
автоматизированное. В ходе выполнения ручного тестирования, тестировщик
выполняет действия, которые в будущем будет выполнять пользователь
сайта, то есть тестировщик должен работать с сайтом, без использования
программных средств путем моделирования действий пользователя.
Работа тестировщика заключается в слежке за корректностью работы
функционала сайта, за удобством работы с интерфейсом и за другими
факторами. Каждая независимая от других последовательность действий
тестировщика и выполняемых им в процессе проверок называется тест-
кейсом или тестовым сценарием. Например, таковым может быть сценарий
«Регистрация пользователя» :
1. Зайти на страницу регистрации
2. заполнить поля «логин», «email», «пароль»
3. нажать на кнопку «зарегистрироваться»
4. убедиться, что мы попали на страницу созданного профиля.

Автоматизированное тестирование же состоит в написании автотестов

– программ, заточенных на выполнение заложенных в них изначально
тесткейсов и только их. Это отдельная дисциплина предмета тестирования.
Значительная часть эффективности работы отдела тестирования зависит от
того, какие задачи отданы для автоматизации и как эта автоматизация была

10
осуществлена. Автоматизация может как принести огромное облегчение всем
тестировщикам, так и завалить работу всего отдела.
Автоматизировать можно сотни вещей. Вот наиболее часто
встречающиеся виды автоматизации:
 Инструменты для помощи в черноящичном и сероящичном
тестировании.
 Программы для регрессивного тестирования
 Программы для тестирования скорости и надежности
 Прочие программы, для которых ручной подход совмещается с
автоматизированным

Таким образом, после запуска теста, тестировщик получает данные о

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

11
состоящих из большого количества шагов может занять неприемлемо много
времени из-за возникновения неожиданных сбоев или технических проблем.
Также в большинства случаев, тратится много времени на поддержку
автотестов при необходимости часто вносить в них изменения вслед за
изменениями в тестируемой функциональности.

Поскольку не каждая компания может позволить себе большой штат

тестировщиков, появилось большое количество проектов, целью которых
является полностью автоматическое тестирование как в виде генерации
обычных юнит-тестов, так и в виде моделирования взаимодействия
пользователя с интерфейсом веб-сайтов. Несмотря на то, что это два разных
подхода, в данной работе они оба будут исследованы с целью наибольшей
надежности тестирования. Идея моделирования взаимодействия
пользователя с интерфейсом заключается в том, чтобы из действий и
проверок выполняемых тестировщиком вручную, в автоматическом режиме
моделировалось как можно большее количество данных действий.
Представим себе, что мы имеем такую программу, которая работает без
помощи оператора. Допустим подобная программа не найдет все ошибки на
сайте, но при анализе полученных данных человеком можно отыскать
наиболее повторяемые и типовые ошибки. Тогда при наличии достаточных
вычислительных мощностей (что как правило не является проблемой для
крупной компании), мы сможем сократить объем ручного и
автоматизированного тестирования, что, как следствие, уменьшит и
денежные затраты на весь процесс тестирования. Автоматическое
тестирование по сравнению с автоматизированным тестированием обладает
теми же недостатками, что и автоматизированное тестирование по
сравнению с ручным (высокая сложность разработки, из-за чего приходится
привлекать более высокооплачиваемых специалистов, и маленькое
разнообразие и специфичность), но и теми же достоинствами (на больших
временных отрезках прибыль будет больше, при наличии соответствующей
12
поддержки). Как правило, целью создания таких программ является не поиск
всех ошибок на веб-сайте, а предоставление информации о некоторых
ошибках, так как существует большое количество ошибок, которые сложно
протестировать в автоматическом режиме. Существует значительное
количество проектов, созданных для предоставления автоматического
тестирования веб-сервисов, каждый из которых делает упор на какой-либо
определенный класс ошибок. В большинстве данных сервисов, обращается
внимание на тестирование функциональной части сайта, а ошибкам,
связанным с отображением страницы, внимания уделяется недостаточно.

Задачи программирования, связанные с созданием внешнего вида

одной веб-страницы, называются версткой страницы. Как раз тестированию
корректности верстки и посвящена эта работа. Также под термином вёрстка
понимается и сама веб-страница с точки зрения её внутренней структуры.
Поскольку существует огромное количество языков и библиотек с
использованием которых пишутся веб-сайты, их верстка остается слабо
формализованной, несмотря на то что большая часть языков и библиотек
сопровождается хорошо составленной документацией, учебниками и онлайн-
пособиями. Это происходит по следующим причинам: Во-первых, задачи
стоящие перед программистами могут быть очень разными, из-за этого
крайне сложно или невозможно придерживаться единого стандарта. Также,
обычно при решении новых задач, далеко не всегда программисты изучают
новые методы их решения, что приводит к росту числа допускаемых ошибок.
Кроме того, обнаружению ошибок верстки не всегда уделяют достаточно
внимания, как ручному, так и автоматическому, из-за чего даже может
отсутствовать классификация встречающихся ошибок и формализация их
критериев, не говоря уже об их статистике обнаружений или их описания.
Во-вторых, программисты обычно не используют одни и те же подходы для
написания кода, это связано с тем, что при обучении, у каждого
программиста складываются свои методы и способы решения задач, и
13
поэтому маловероятно что все программисты работающие над одним
проектом будут пользоваться одними и теми же методами. В сети интернет
есть множество советов относительно применения тех или иных приемов, но
так как стандартов обязательных для выполнения во всех случаях не
существует, множество задач, которые ставятся программистам, настолько
разнообразно, что совершенно не представляется возможным предусмотреть
стандарт на все случаи.

14
 1. Постановка задачи

Целью данной работы является создание программы, в

автоматическом режиме выявляющей ошибки верстки на заданной веб-
странице. Для ее решения были поставлены следующие задачи:
 Анализ современных технологий верстки веб-интерфейсов
 Анализ современных подходов к автоматическому тестированию
сайтов
 Классификация видов ошибок верстки
 Разработка основных программных модулей на основе
полученной информации
 Тестирование и отладка всей программы в целом

15
 2. Анализ современных технологий верстки веб-интерфейсов

2.1 HTML
HTML (HyperText Markup Language) является языком гипертекстовой
разметки, который используется для создания (структурирования и
представляния) веб-страниц.
Данный язык разрабатывался в ЦЕРН ученым Тимом Бернерсом-Ли в
1986-1991 годах как язык для обмена различной документацией между
людьми, не обладающими навыками верстки документов, так как с помощью
HTML относительно легко создать простой но легко читаемый и
оформленный документ. Изначально HTML планировалось использовать для
работы с документами без привязки к различным средствам отображения,
текст с данной разметкой должен был воспроизводиться на различном и
сильно отличающемся оборудовании без искажения структуры и стиля,
однако на данный момент из-за потребностей в графическом оформлении и
мультимедиа, поддержка любых платформ представляется слабо возможной.
Код на языке HTML состоит из элементов, построенных на основе
тегов, которые описывают структуру HTML-документа. Существуют
открывающие и закрывающие теги, между которыми обычно располагается
содержимое элемента состоящее из других тегов, причем некоторые
элементы могут состоять только из открывающего тега, такие как тег
переноса строки <br>. Например, в следующей строке есть открывающий тег
<p> который указывает что в данном месте документа начинается новый
абзац, одиночный тег <br> который переносит весь последующий текст на
новую строку и закрывающий тег </p> указывающий конец абзаца.
<p>Язык HTML соответствует<br>международному
стандарту ISO 8879.</p>
Пример вывода

16
 Элементы могут иметь различные атрибуты, определяющие их
свойства (например тег <a href="http://www.example.com">Здесь элемент

содержит атрибут href, то есть гиперссылку.</a>) привязывающий к объекту

гиперссылку.
Браузер интерпретирует HTML-код, последовательно выстраивая его
структуру и отображая её в виде веб-страницы. Стоит учитывать, что HTML-
код обрабатывается браузером последовательно начиная с первой строчки
документа, в связи с чем CSS-элементы и различные стили как правило
описываются в начале документа.
На данный момент разработан HTML пятой версии, в котором реализовано
значительное количество нового синтаксиса с целью облегчить создание и
отображение графических, мультимедийных объектов без использования
сторонних API.

2.2 CSS
CSS – формальный язык описания внешнего вида документа,
написанного с использованием языка разметки. Обычно CSS используется
для оформления внешнего вида веб-страниц страниц, написанных с
помощью языка HTML, но также может применяться к любым XML-
документам. Язык разрабатывался для удобного разделения описания
логической структуры документа построенного с помощью HTML или
другого языка разметки. Данное разделение обеспечивает большую гибкость
управления отображением документа и уменьшает повторяемость в
структуре документа. Кроме того, становится возможным отображать один
документ в различных стилях без непосредственного редактирования текста.
Правила CSS пишутся на формальном языке CSS и размещаются в
таблицах стилей, которые могут находиться как в самом веб-документе, так и
в отдельных файлах формата .css. В файле .css содержится только набор
правил CSS.

17
 Таблицы стилей могут быть подключены к веб-документу следующими
способами :
Когда таблица стилей находится в отдельном файле, она подключается
к веб-странице с помощью тега <link> внутри HTML-тега <head>, который
предназначен для хранения различных элементов, используемых браузером
при работе с данными.
С использованием внутреннего стиля. Внутренний стиль является по
существу расширением для одиночного тега используемого на веб-странице.
Для определения стиля используется параметр тега style, а его атрибуты
указываются с помощью языка таблицы стилей. Внутренние стили
рекомендуется применять на сайте ограниченно или вообще отказаться от их
использования. Дело в том, что добавление таких стилей увеличивает общий
объем файлов, что ведет к повышению времени их загрузки в браузере, и
усложняет редактирование документов для разработчиков.

Код написанный на CSS является списком правил, расположенных друг

за другом. Каждое правило из таблицы стилей состоит из двух частей –
селектора и блока объявлений. Обычно правила записываются в следующем
формате :
Селектор {
свойство1: значение1;
свойство 2: значение 2;
...
}
Селектор в левой части, определяет на какие части документа
действует правило, блок объявлений в правой части, состоит из одного или
более объявлений каждое из которых является сочетанием свойства CSS и
значения и задает элементам из набора свойства, например шрифт, его
размер, цвет, отображение границ ячеек в таблице, расположение на
странице и.т.д.
18
 Так как CSS применяется к HTML-документам на принципах
наследования и каскадирования, необходимо учитывать это при верстке
документа, так как при конфликте значений правил могут возникнуть
ошибки отображения. Для разрешения конфликта стилей используются
правила приоритета.

2.3 Javascript
JavaScript — прототипно-ориентированный сценарный язык
программирования.
Javascript используется для программного доступа к объектам
приложений и применяется в браузерах как язык сценариев для
интерактивных веб-страниц.
Структурно JavaScript можно представить в виде трех частей :
Ядро – это основа для построения скриптовых языков
Объектная модель браузера - часть языка, являющаяся прослойкой
между ядром и объектной моделью документа, предназначенная для
управления окнами браузера и их взаимодействия
Объектная модель документа – интерфейс программирования
приложений для XML-документов, в котором они могут быть представлены в
виде дерева объектов обладающих некими свойствами.
Синтаксис языка Javascript во многом похож на C и Java. Благодаря
поддержке императивного, объектно-ориентированного и функционального
стиля программирования он является удобным инструментом для веб-
разработчика при разработке логики интерфейса динамических страниц.
В настоящее время JavaScript широко используется в подходе к
построению интерактивных интерфейсов веб-сайтов под названием AJAX.
Данный подход позволяет обновлять данные веб-страницы без её полной
перезагрузки, за счет чего работа с сайтом становится значительно быстрее
чем без его применения.
19
 JavaScript поддерживается в современных версиях большинства
браузеров.

2.4 Фреймворк тестирования web-приложений Selenium Webdriver

Selenium Webdriver, или просто Webdriver – это драйвер браузера, то
есть не имеющая пользовательского интерфейса программная библиотека,
которая позволяет различным другим программам взаимодействовать с
браузером, управлять его поведением, получать от браузера какие-то данные
и заставлять браузер выполнять какие-то команды.

По назначению Selenium WebDriver представляет собой драйвер браузера, то

есть программную библиотеку, которая позволяет разрабатывать программы,
управляющие поведением браузера.
По своей сущности Selenium WebDriver представляет собой:
 спецификацию программного интерфейса для управления
браузером,
 референсные реализации этого интерфейса для нескольких
браузеров,
 набор клиентских библиотек для этого интерфейса на нескольких
языках программирования.

Фреймворк Selenium является популярным инструментом

автоматизированного тестирования ввиду того что в специальной среде
Selenium IDE включенной в фреймворк есть возможность описывать
тестовые сценарии, воспроизводить предполагаемые действия пользователя
через расширения браузера и работать с браузером посредством кода на
различных языках программирования. Код выполняет работу в браузере
посредством компонента Selenium Webdriver. Дла каждого браузера
существуют различные модули-драйвера, запускающие и контролирующие
приложение.

20
 Selenium Webdriver поддерживает различные языки программирования,
такие как Java, C#, Python и Ruby, Perl и PHP.

2.5 Основные понятия и методы Selenium Webdriver API

 Webdriver - самая важная сущность, управляющая браузером.

Основной ход скрипта/теста строится именно вокруг экземпляра этой
сущности.
 Webelement - вторая важная сущность, представляющая собой
абстракцию над веб элементом (кнопки, ссылки, инпута и др.).
Webelement инкапсулирует методы для взаимодействия пользователя
с элементами и получения их текщего статуса.
 By - абстракция над локатором веб элемента. Этот класс
инкапсулирует информацию о селекторе(например, CSS), а также сам
локатор элемента, то есть всю информацию, необходимую для
нахождения нужного элемента на странице.

Сам процесс взаимодействия с браузером через Webdriver API

довольно прост:

1. Нужно создать Webdriver:

WebDriver driver = new ChromeDriver();

При выполнении этой команды будет запущен Chrome, при условии,

что он установлен в директорию по умолчанию и путь к ChromeDriver
сохранен в системной переменной PATH.

2. Необходимо открыть тестируемое приложение (AUT), перейдя по url:

driver.get("http://mycompany.site.com");

После этого, в браузере должен открыться указанный URL.

Далее следуют действия по нахождению элементов на странице и
взаимодействию с ними:

By elementLocator = By.id("#element_id");

WebElement element = driver.findElement(elementLocator));

21
Или более кратко:

WebElement element = driver.findElement(By.id("#element_id")));

3. После нахождения элемента, кликнем по нему:

element.click();

Далее следует совокупность похожих действий, как того требует

сценарий.
В конце теста (часто также и в середине) должна быть какая-то
проверка, которая и определит в конечном счете результат выполнения теста:

assertEquals("Webpage expected title", driver.getTitle());

Проверки может и не быть, если цель вашего скрипта - не тест, а

выполнение какой-то рутины.
4. После теста надо закрыть браузер:

driver.quit();

Следует отметить, что для поиска элементов доступно два метода:

4.1 Первый - найдет только первый элемент, удовлетворяющий
локатору:

WebElement element = driver.findElement(By.id("#element_id")));

4.2 Второй - вернет весь список элементов, удовлетворяющих

запросу:

List<WebElement> elements = driver.findElements(By.name("elements_name"))

22
 2.6 Типы локаторов

Поскольку Webdriver – это инструмент для автоматизации веб приложений,

то большая часть работы с ним — это работа с веб
элементами(WebElements). WebElements – ни что иное, как DOM объекты,
находящиеся на веб странице. А для того, чтобы осуществлять какие-то
действия над DOM объектами / веб элементами необходимо их точным
образом определить(найти).

WebElement element = driver.findElement(By.<Selector>);

Таким образом в Webdriver определяется нужный элемент. By – класс,

содержащий статические методы для идентификации элементов:

1. By.id
Пример:

<div id=”element”>

<p>some content</p>

</div>
Поиск элемента:

WebElement element = driver.findElement(By.id(“element_id”));

2. By.name

Пример:

<div name=”element”>

<p>some content</p>

</div>

Поиск элемента:

WebElement element = driver.findElement(By.name(“element_name”));

3. By.className

23
Пример:

<img class=”logo”>
Поиск элемента:

WebElement element = driver.findElement(By.className(“element_class”));

4. By.TagName

Пример:

<div>

<a class=”logo” ref=”…”>…</a>

<a class=”support” ref=”…”>…</a>

</div>

Поиск элемента:

List<WebElement> elements = driver.findElements(By.tagName(“a”));

5. By.LinkText

Пример:

<div>

<a ref=”…”>text</a>

<a ref=”…”>Another text</a>

</div>

Поиск элемента:

WebElement element = driver.findElement(By.linkText(“text”));

6. By.PartialLinkText

24
Поиск элемента:

WebElement element = driver.findElement(By.partialLinkText(“text”));

7. By.cssSelector

<div class=’main’>

<p>text</p>

<p>Another text</p>

</div>

Поиск элемента:

WebElement element=driver.FindElement(By.cssSelector(“div.main”));

8. By.Xpath

<div class=’main’>

<p>text</p>

<p>Another text</p>

</div>

Поиск элемента:

WebElement element = driver.findElement(By.xpath(“//div[@class=’main’]”));

2.7 Ожидания
Ожидания – непременный атрибут любых UI тестов для динамических
приложений. Нужны они для синхронизации работы AUT и тестового
скрипта. Скрипт выполняется намного быстрее реакции приложения на
команды, поэтому часто в скриптах необходимо дожидаться определенного
состояния приложения для дальнейшего с ним взамодействия.
25
Самый просто пример - переход по ссылке и нажатие кнопки:

driver.get("http://google.com");

driver.findElement(By.id("element_id")).click();

В данном случае необходимо дождаться пока не появится кнопка с id =

element_id и только потом совершать действия над ней. Для этого и
существуют ожидания.

Ожидания бывают:

1. Неявные ожидания - Implicit Waits - конфигурируют экземпляр

WebDriver делать многократные попытки найти элемент (элементы)
на странице в течении заданного периода времени, если элемент не
найден сразу. Tолько по истечении этого времени WebDriver бросит
ElementNotFoundException.

WebDriver driver = new FirefoxDriver();

driver.manage().timeouts().implicitlyWait(10, TimeUnit.SECONDS);

driver.get("http://some_url");

WebElement dynamicElement = driver.findElement(By.id("dynamicElement_id"));

Неявные ожидания обычно настраиваются сразу после создания

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

driver.manage().timeouts().pageLoadTimeout(10, TimeUnit.SECONDS);

А также неявное ожидание отработки скриптов:

driver.manage().timeouts().setScriptTimeout(10, TimeUnit.SECONDS);

26
2. Явные ожидания - Explicit Waits - это код, который ждет наступления
какого-то события (чаще всего на AUT), прежде чем продолжит
выполнение команд скрипта. Такое ожидание срабатывает один раз в
указанном месте.

Самым худшим вариантом является

использование Thread.sleep(1000), в случае с которым скрипт просто
будет ждать определенное количество времени. Это не гарантирует
наступление нужного события либо будет слишком избыточным и
увеличит время выполнения теста.
Более предпочтительно использовать WebDriverWait и
ExpectedCondition:

WebDriver driver = new FirefoxDriver();

driver.get("http://some_url");

WebElement dynamicElement = (new WebDriverWait(driver, 10))

.until(ExpectedConditions.presenceOfElementLocated(By.id("dynamicElement_id"

)));

В данном случае скрипт будет ждать элемента c id =

dynamicElement_id в течении 10 секунд, но продолжит выполнение,
как только элемент будет найден. При этом WebDriverWait класс
выступает в роли конфигурации ожидания - задаем, как долго ждать
события и как часто проверять его наступление. ExpectedConditions -
статический класс, содержащий часто используемые условия для
ожидания.

27
 3. Анализ современных подходов к автоматическому тестированию

сайтов

Неотъемлемой частью жизненного цикла разработки Web-приложений

является обеспечение их корректной работы в наборе поддерживаемых
браузеров. Для обеспечения совместимости приложений с различными
браузерами Web-разработчики традиционно используют экстенсивное
регрессионное тестирование, но такой подход является очень затратным с
точки зрения времени и ресурсов. Альтернативный подход заключается в
создании нескольких наборов полностью автоматизированных тестов для
выполнения в ряде браузеров.
Наборы полностью автоматизированных тестов можно создавать и
выполнять в рамках запланированного процесса сборки или в рамках
конвейера сборки. В любом случае этот подход позволяет выявлять
проблемы на ранних стадиях и получать быструю обратную связь. К моменту
сборки вы будете уверены в работоспособности кода приложения, что может
значительно снизить или даже полностью устранить необходимость в
регрессионном тестировании.
Существующие на сегодня методы тестирования программного
обеспечения не позволяют однозначно и полностью выявить все дефекты и
установить корректность функционирования анализируемой программы,
поэтому все существующие методы тестирования действуют в рамках
формального процесса проверки исследуемого или разрабатываемого
программного обеспечения.
Такой процесс формальной проверки, или верификации, может
доказать, что дефекты отсутствуют с точки зрения используемого метода. (То
есть нет никакой возможности точно установить или гарантировать
отсутствие дефектов в программном продукте с учётом человеческого

28
фактора, присутствующего на всех этапах жизненного цикла программного
обеспечения.)
Существует множество подходов к решению задачи тестирования и
верификации программного обеспечения, но эффективное тестирование
сложных программных продуктов — это процесс в высшей степени
творческий, не сводящийся к следованию строгим и чётким процедурам или
созданию таковых.
Качество программного обеспечения можно определить, как
совокупную характеристику исследуемого ПО с учётом следующих
составляющих:
 надёжность,
 сопровождаемость,
 практичность,
 эффективность,
 мобильность,
 функциональность.

Состав и содержание документации, сопутствующей процессу

тестирования, определяется стандартом IEEE 829-1998.
Классификация видов тестирования
Существуют различные признаки, по которым производится
классификация видов тестирования. Обычно выделяют данные признаки:
 По объекту тестирования
 По знанию системы
 По степени автоматизации
 По степени изолированности компонентов
 По признаку позитивности сценариев
 По степени подготовленности к тестированию

29
 3.1 Уровни тестирования

 Модульное тестирование — тестируется минимально возможный

для тестирования компонент, например, отдельный класс или
функция. Часто модульное тестирование
осуществляется разработчиками программного обеспечения.
 Интеграционное тестирование — тестируются интерфейсы
между компонентами, подсистемами или системами. При
наличии резерва времени на данной стадии тестирование ведётся
итерационно, с постепенным подключением последующих
подсистем.
 Системное тестирование — тестируется интегрированная
система на её соответствие требованиям.

3.2 Основные подходы к автоматизации тестирования:

Существуют два основных подходы к автоматизации тестирования:
на уровне кода и тестирование пользовательского интерфейса (в
частности, GUI-тестирование). К первому типу относится, в
частности, модульное тестирование. Ко второму — имитация
действий пользователя с помощью специальных тестовых фреймворков.
В данной работе будут рассматриваться оба подхода в связи с
необходимостью перекрыть минусы данных подходов.

3.3 GUI-автоматизация
Наиболее распространенной формой автоматизации является
тестирование приложений через графический пользовательский
интерфейс (англ. GUI). Есть два фактора из-за которых это один из наиболее
используемых методов тестирования: во-первых, приложение тестируется

30
таким же образом, которым будет использовано конечным клиентом, что
позволяет в некоторой степени уменьшить количество тестов, во-вторых,
можно тестировать приложение, без доступа к его исходному коду, что
впрочем для данной работы является несущественным плюсом и
рассматриваться не будет, поскольку считается что при внедрении системы у
тестировщика будет доступ к исходникам.
GUI-автоматизация развивалась в течение 4 поколений инструментов и
техник:
 Утилиты записи и воспроизведения записывают действия
тестировщика во время ручного тестирования. Они позволяют
проводить тесты без непосредственного участия оператора, в
течение длительного временного отрезка значительно увеличивая
продуктивность и уменьшая количество рутинной работы при
ручном тестировании. Однако, любое внесение изменений в
тестируемый продукт потребует повторного написания ручных
тестов. По этим причинам, первое поколение инструментов не
считается достаточно эффективным.
 Написание сценария. Форма программирования на языках,
специально разработанных для автоматизации тестирования
ПО — смягчает многие проблемы инструментов записи и
воспроизведения. Но обычно разработкой занимаются
программисты высокого уровня, которые обычно работают
отдельно от тестировщиков, непосредственно запускающих
тесты. К тому же скрипты более всего подходят для тестирования
GUI и не могут быть внедренными или вообще каким-либо
образом объединены в систему. Кроме того, изменения в
тестируемом программном обеспечении требуют сложных и
глобальных изменений в соответствующих скриптах, и
поддержка увеличивающейся библиотеки тестирующих скриптов

31
 становится в конце концов непреодолимой задачей, на которую
тратится больше ресурсов, чем их освобождается.
 Управляемое данными тестирование — методология,
используемая в автоматизации тестирования. Особенностью
является то, что тестовые скрипты выполняются и
верифицируются на основе данных, которые хранятся в
центральном хранилище данных или базе данных. Управляемое
данными тестирование — это объединение нескольких
взаимодействующих тестовых скриптов и их источников данных
во фреймворк, используемый в методологии. В этом фреймворке
переменные используются для входных значений, и для
выходных проверочных значений: в тестовом скрипте обычно
закодированы навигация по приложению, чтение источников
данных, ведение логов тестирования. Следовательно, логика,
которая будет выполнена в скрипте, также зависит от данных.
 Тестирование по ключевым словам - автоматизация
подразумевает разделение процесса создания тестов на 2 этапа:
планирования и реализации. В этом случае конечный тест
представляет собой не программный код, а описание
последовательности действий с их параметрами (например,
«завести в базе данных пользователя с логином XXX и паролем
YYY»). При этом фреймворк отвечает за непосредственную
реализацию действий, а дизайнеру тестов достаточно иметь
представление о наборе действий, реализованных во фреймворке.
Это даёт возможность создавать тесты людям, не имеющим
навыков программирования.

Одной из главных проблем автоматизированного тестирования

является его трудоемкость: несмотря на то, что оно позволяет устранить

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

3.4 Приложения
Для автоматизации тестирования существует большое количество
приложений. Наиболее популярные из них по итогам 2015 года:
 HP LoadRunner, HP QuickTest Professional, HP Quality Center
 Segue SilkPerformer
 IBM Rational FunctionalTester, IBM Rational PerformanceTester,
IBM Rational TestStudio
 TestComplete

Использование этих инструментов помогает тестировщикам

автоматизировать следующие задачи:
 установка продукта
 создание тестовых данных
 GUI взаимодействие
 определение проблемы

Однако автоматические тесты не могут полностью заменить ручное

тестирование. Автоматизация всех испытаний —дорогой процесс, и потому
автоматическое тестирование является лишь дополнением ручного
тестирования. Наилучший вариант использования автоматических тестов —
регрессионное тестирование.

33
Инструменты используемые для тестирования ПО:
 JUnit — тестирование приложений для Java
 TestNG — тестирование приложений для Java
 NUnit — порт JUnit под .NET
 Selenium — тестирование приложений HTML; поддерживает
браузеры Internet Explorer, Mozilla Firefox, Opera, Google
Chrome, Safari.
 TOSCA Testsuite — тестирование
приложений HTML, .NET, Java, SAP
 UniTESK — тестирование приложений на Java, Си.

34
 4. Классификация ошибок вёрстки и алгоритмы их обнаружения

В данном разделе будут описаны типичные ошибки верстки и

разработка критериев по которым они будут находиться.
Веб-страница рассматривается браузером как набор прямоугольных
блоков. Каждый блок имеет набор свойств :
 Размер
 Координаты
 Css-стили примененные к блоку

Имеет смысл рассматривать только результирующие значения стилей,

так как браузер самостоятельно преобразует их значения, к примеру
значения, указанные в процентах браузер преобразует в конкретное
количество пикселей.

Необходимо определить значимость ошибок для каждого их вида, так

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

В данной работе будут рассмотрены различные ошибки которые можно

найти не только при анализе исходного кода HTML или CSS по следующим
причинам :

35
  Поиск ошибок в исходном коде не настолько универсален как
симуляция работы пользователя в браузере
 Зачастую логика работы браузера с элементами выполняется при
помощи кода javascript
 Невозможно получить результат, который будет понятен
человеку не знающему детали построения верстки сайта.

Неправильно вложенные друг в друга теги.

Это одна из наиболее распространенных ошибок возникаемых в случае
невнимательности верстальщика. Суть ошибки состоит в том, что тег
который должен полностью быть вложен в родительский, закрывается вне
родительского тега что приводит к ошибке. Протестировать данную ошибку
можно следующим способом : при проходе дерева тегов, все открывающие
теги добавляются в стек, а при попадании на закрывающий тег происходит
проверка лежит ли на вершине стека такой же открывающий. Если да, то этот
тег убирается с вершины стека и проход продожается дальше, если нет, то в
отчет идет сообщение об ошибке.

Названия файлов на кириллице

По всем стандартам, все названия файлов должны быть на английском
языке, так как далеко не во всех случаях браузер может правильно
интерпретировать кириллицу, что приводит к таким ошибкам как
отсутствующее изображение или не открывающаяся ссылка на файл.
Чтобы найти данную ошибку, необходимо провести поиск на
присутствие символов кириллицы, во всех тегах, используемых для ссылок
на файлы, таких как <a></a> <img> и других.
Флагом для данного состояния будет «false_filename»

Нерабочие гиперссылки

36
 Иногда бывает так, что некоторые страницы на сайте удаляются, либо
переносятся, но при этом на других страницах могут остаться ссылки
ведущие на эти страницы. Как правило после удаления какой-либо страницы
либо файла должна быть создана ссылка перенаправляющая на актуальную
версию страницы, либо её страницу-родителя. В тех случаях когда это не
сделано, пользователь попадает на страницу с ошибкой 404.
Для обнаружения этой ошибки, достаточно клика на каждую
гиперссылку на странице после перехода по которой браузер выводит
ошибку 404.
Флагом для данного состояния будет «false_link»

Отсутствие описания к картинкам.

Данная ошибка не является критичной, так как пользователь не может
её заметить, однако для каждой картинки выложенной на сайте, необходимо
указывать её описание, данное действие необходимо для лучшего SEO-
продвижения сайта и индексации страниц поисковыми роботами.
В случае если описание к картинкам отсутствует, продвижение сайта
затрудняется.
Для обнаружения данной ошибки, необходимо проверить является ли
пустым атрибут alt= « » в теге <img>
Флагом для данного состояния будет «empty_alt»

Выпадение элементов детей за пределы родительских элементов.

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

37
  пропадание элемента за границей родителя либо за другим
блоком

Примеры данных ошибок приведены на рисунках 1-3.

Рисунок 1.

Рисунок 2.

Рисунок 3.

38
 Чтобы обнаружить ошибки этого рода, необходимо сделать проход по
всему дереву HTML-тегов страницы и для каждого блока имеющего блок-
дитя провести проверку на вложенность блока-дитя в блок-родитель по
координатам. Блоки которые не отображаются или имеют стиль display:none
должны игнорироваться, ввиду того что пользователь не может их увидеть.
Однако есть определенные исключения, когда данное поведение
блоков не ошибочное.
1. Когда блок располагается на странице, не влияя на расположение
других блоков. Эти блоки определяются CCS-стилем position со
значением absolute или fixed. Как правило такие блоки являются
элементами функционала, например, меню навигации по сайту в
верхнем или боковом блоке по краю страницы.
2. Когда блок-родитель имеет полосы для прокрутки содержимого внутри
блока, в этом случае любое его дитя становится доступным. Эти блоки
определяются CCS-стилем overflow со значением scroll или auto.
3. Когда ни один элемент в блоке не имеет видимых признаков, а именно:
 Монохромный фон отличный от белого (background-color)
 Фоновое изображение (background-image)
 Цветная рамка вокруг элемента отличная от цвета фона страницы
(border-color)
 Тень вокруг элемента (box-shadow)
4. Когда размер блока-родителя вычисляется браузером самостоятельно
по размеру его содержимого. В отдельных случаях блок-дитя может
выехать за границы родителя, но это не является ошибкой так как
браузер при отображении строчных элементов учитывает размеры всех
строчных тегов, вложенных в него.

Также есть некоторые не классифицируемые состояния, которые стоит

рассмотреть, чтобы назначить для них отдельные флаги.

39
 Иногда для некоторых элементов намеренно задается отрицательный
отступ, выдвигающий их за пределы границ родителя. Данное состояние
следует считать не поддающимся классификации потому как иногда этот
метод приводит к появлению ошибок в виде накладывания блока-ребенка на
другие элементы. Отрицательный отступ задается отрицательным значением
свойства margin, либо свойств top, bottom, left, right при одновременно
заданном свойстве position:relative. Этому состоянию присвоим флаг
«margin_negative_pos»
Для данного типа ошибок необходимо рассмотреть стиль
overflow:hidden. Этот стиль скрывает с экрана все фрагменты детей
вышедшие за границы родительского элемента, что часто используется в
блоках с контентом в виде прокручивающегося слайдера, управляемым через
Javascriprt вместо полосы прокрутки пользователя. В этом случае дитя
выезжает за границы родителя, но при этом части за границами родителя
остаются невидимыми. В некоторых случаях верстальщики добавляют этот
стиль всем элементам страницы чтобы перестраховаться, поскольку
неотображаемые элементы вне границ родителя не так заметны как
накладывающиеся друг на друга. Этому состоянию присвоим флаг
«hidden_overflow».
Данная ошибка определяется по тому, насколько сильно блок-дитя
выходит за границы блока-родителя, следовательно, имеет смысл
рассматривать максимальное значение на четырех координатах, на которое
выезжает блок-дитя.

Смещение блоков из ряда элементов.

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

40
элементы перемещаются во второй ряд что может вызвать дальнейшие
ошибки верстки. Пример данной ошибки приведен на рисунке 4.

Рисунок 4.

Чтобы обнаружить данную ошибку, необходимо сначала задать

наибольшее разрешение окна браузера чтобы все элементы, которые должны
быть выстроены в ряд корректно отобразились. После этого надо уменьшать
размер окна браузера и после каждого уменьшения производить действия на
странице. Если после очередного уменьшения окна браузера какие-либо
элементы ряда сдвинулись, то можно определить ошибку.
Однако нет смысла искать ошибку в маленьком наборе элементов,
потому что при использовании очень маленького разрешения окна браузера,
не всегда возможно корректно отобразить элементы в одном ряду, и в этом
случае как раз правильно сдвинуть 1-2 элемента на второй ряд, особенно это
касается случая когда выровненные блоки имеют большой размер.
В некоторых случаях ряд элементов сформирован с помощью свойства
display:inline, такой ряд автоматически подстраивается под размер окна, что
не считается ошибкой.

41
 Также в этот вид ошибок можно включить наложение блоков друг на
друга. Обычно эта ошибка заключается в наложении одного элемента-
ребенка на другой подобный элемент. Эти ошибки находятся таким же
образом : необходимо провести проверку координат отображаемых блоков на
пересечение с соседними блоками. При этом, достаточно проверять пары
блоков находящихся в одном родителе, так как проверка всех пар блоков
будет избыточной.
Пример данной ошибки приведен на рисунках 5-6.

Рисунок 5.

Рисунок 6.
Неправильно расположенные слои
В случае заранее задуманного пересечения блоков необходимо заранее
продумать каким образом они будут накладываться друг на друга. Это может

42
привести к ошибке когда подобных блоков на странице несколько, либо
когда на странице есть баннеры которые могут закрывать какой-либо
функциональный элемент. Как правило подобная ошибка возникает когда
версткой занималось несколько людей которые не согласовывали свою
работу друг с другом.
Несмотря на то что зафиксировать данную ошибку достаточно сложно
из-за отсутствия её признаков в верстке страницы, можно выявлять её на
основе действий пользователя, предполагая, что элементы, появляющиеся в
результате его действий должны располагаться на верхнем слое.
Для этого надо сначала выполнить все возможные действия на
странице, после чего провести их еще раз и выяснить какие из них
невозможно выполнить повторно. К сожалению, при данной проверке
невозможно зафиксировать наложение слоев на блоки с нефункциональными
элементами, однако даже такой тест может значительно облегчить поиск
ошибок.

43
 5. Разработка основных программных модулей на основе полученной
информации

В данной работе была реализована программа, выполняющая

автоматизированную проверку верстки сайта.
Из описанных выше проверок были реализованы проверки следующих
ошибок из вышеперечисленных: Названия файлов на кириллице, Нерабочие
гиперссылки, Отсутствие описания к картинкам, Выпадение элементов детей
за пределы родительских элементов.
Причина выбора именно этих проверок обусловлена тем, что эти
ошибки являются более распространенными и критичными, либо потому что
проверки, не вошедшие в программу, являются избыточными либо не
дающими точного результата.
Используемые инструменты:
Selenium webdriver 2.0 c использованием Javascript
Selenium webdriver 2.0 был выбран в связи с тем, что это объектно-
ориентированный API, поддерживающий большее количество браузеров и
лучше решающий проблемы тестирования современных веб-приложений,
имеющий возможность проводить как функциональные, так и графические
тесты.
Основная причина выбора Selenium 2.0 заключается в наличии
WebDriver API – удобного для работы и простого в освоении программного
интерфейса. Данный инструмент создавался с целью повышения читаемости
и упрощения поддержки тестов. Так как WebDriver API не привязан ни к
каким тестовым фреймворкам, это позволяет использовать любые
фреймворки модульного тестирования. Кроме того, поведение WebDriver не
отличается от обычных библиотек, благодаря чему он полностью
самодостаточен.

44
 Для написания тестов используется javascript по той причине, что код
javascript может быть запущен непосредственно в браузере, что дает большое
преимущество в быстродействии.
JavaScript можно использовать как в параметрах специальных команд,
которые принимают на вход фрагмент JavaScript, так и с “обычными”
параметрами.
Часто нужно внутри фрагмента JavaScript получить доступ к значению
некоторой переменной Selenium. Все переменные, создаваемые тестовым
сценарием, сохраняются в ассоциативный массив JavaScript, который
называется storedVars. В ассоциативном массиве используются строковые
индексы, а не последовательные числовые. Для того чтобы получить доступ
к переменной или изменить её значение из фрагмента JavaScript, вам следует
обращаться к ней, как кstoredVars[‘ИмяВашейПеременной’].
В Selenium есть несколько команд, принимающих в качестве параметра
фрагмент JavaScript: assertEval, verifyEval,storeEval и waitForEval.
Параметр не требует специального синтаксиса. Достаточно просто поместить
фрагмент JavaScript в подходящее поле, обычно это поле Цель (так как эти
команды как правило имеют один параметр).
В примере ниже показано использование фрагмента JavaScript для
вычисления значения числового выражения:

Использование JavaScript в “обычных” параметрах

JavaScript также может применяться в генерации значений для
параметров, которые вообще говоря не принимают код на языке JavaScript. В
этом случае необходимо использовать специальный синтаксис – фрагмент
JavaScript должен быть помещен в фигурные скобки, перед которыми должна
быть приписка javascript, вот так: javascript {*этоВашКод*}. Ниже приведен
45
пример, в котором у второго параметра команды type значение генерируется
JavaScript-кодом:

В Selenium существует команда для отображения текста в поле вывода

данных вашего теста. Это может пригодиться для отслеживания хода
выполнения тестов. Команда echo также будет полезна для обеспечения
контекста выводимым результатам тестирования, позволяющего быстрее
найти расположение дефекта на странице. И, наконец, с помощью оператора
echo можно выводить содержимое переменных Selenium.

Основные команды и операции Webdriver

Открытие страниц
Для открытия страниц в Webdriver используется метод “get”:

WebDriver будет дожидаться полной загрузки страницы (то есть

момента, когда сработает событие “onload”), перед тем как вернуть
управление обратно в ваш тестовый сценарий.

Взаимодействие со страницей
Возможность только лишь попасть на нужную страницу сама по себе
не очень ценна. Наибольшую важность имеет возможность взаимодействия
со страницей, а точнее, с HTML-элементами этой страницы. Прежде всего,
нужно найти интересующий вас элемент. WebDriver предоставляет
несколько способ поиска элементов. Например, если у вас есть элемент,
определенный в HTML коде следующим образом:

46
 то можно найти его любым из приведенных ниже способов:

Для ввода текста в поле ввода используется метод SendKeys

Имитация нажатия стрелок выполняется использованием класса Keys

5.1 Схема работы программы:

1. Инициализация

В начале, происходит инициализация программы, открывается окно

браузера, которому задаются размеры 1920x1080 px, после чего программе
дается список страниц для тестирования, которые открывает браузер.

2. Построение рабочей модели

После конфигурации используемых при тестировании разрешений окна

браузера, запускается скрипт, инициализирующий дерево элементов, для
каждого разрешения браузера происходит обход HTML-кода, сохранение
снимка страницы и сохранение построенного дерева в виде компонентов
JavaBeans. Таким образом создается модель страницы с которой
продолжается дальнейшая работа.

3. Поиск ошибок.

Для каждого типа ошибок, создается отдельный модуль, который

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

4. Объединение аналогичных наборов ошибок в кластеры.

Поскольку наборы ошибок как правило идентичны, имеет смысл

обьединять их в общий набор ошибок разделенных по типам, например
набор содержащий выпадающие во второй ряд блоки или набор содержащий
ошибки с названиями файлов на кириллице.
 Условия объединения наборов будут следующие :
 Одинаковый тип проверки
 Одинаковые неклассифицируемые состояния
 Совпадающие имена тегов
 Одинаковое количество элементов

Также необходимо учитывать следующие моменты :

Одинаковые классы CSS. Как правило для одного типа элементов
используется отдельный CSS-класс, что позволяет сгруппировать наборы по
типу элементов. Стоит заметить, что внутри элемента может находиться
несколько разных классов, поэтому необходимо проводить проверку на
совпадение хотя бы одного класса и типа элемента, при этом проверка
каждого элемента будет избыточна. Для решения данной проблемы стоит
указать несколько типов элементов в которых более вероятна типовая
ошибка, например табличные элементы.
Совпадающие селекторы. Так как в процессе создания дерева для
каждой ветви создается код описывающий её вида : div[1]/div[2]/table/span,
48
мы можем провести сравнение по данному коду на последовательное
совпадение элементов. Смысл заключается в том, что при нахожднии ошибки
в элементе построенном по шаблону, есть значительная вероятность что
ошибка может проявиться и в других элементах использующих тот же
шаблон. Однако не стоит пытаться выделить набор в котором полностью
совпадают все элементы, так как полностью совпадающие элементы на
одной странице достаточно редкие, достаточно частичного совпадения
шаблона.
Объединение наборов ведущих себя похожим образом и имеющих
похожие меры ошибок для разных разрешений окна браузера.

5.2 Сведение результатов в отчет.

Полученные кластеры сохраняются на диск в виде файла html вместе с
файлами Javascript и CSS, которые обеспечивают функциональность файла.

 Количестве запущенных тестов

 По каждому тесту:
o его название

o название набора

o результат

o время выполнения

o сообщение об ошибке, если тест упал

 Количество успешно выполненных тестов

 Количество упавших тестов
 Время выполнения всех тестов
 Дата и время запуска

Генератор отчетов создавался с использованием стандартных средств

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

49
 1. Снимок страницы
2. Список тестов
3. Список найденных ошибок, для удобства можно группировать
их по типу, воспроизводимые в данном разрешении ошибки
помечаются красным, невоспроизводимые зеленым.
4. При наведении указателя мыши на ошибку, соответствующая
ей область на странице помечается синим, при клике по ней
снимок прокручивается до места с ошибкой.
5. Внизу левого блока выводится прочая информация о тесте,
количество запущенных тестов, количество выполненных
тестов, время выполнения тестов, время запуска тестов.

Также в папке с отчетом создается файл оглавления, со списком всех

созданных отчетов в котором указывается количество найденных ошибок и
краткая информация о них.

50
 6. Тестирование и отладка всей программы в целом

Среднее время для тестирования одной страницы составило примерно

30 секунд, для страниц с небольшим количеством элементов тест длился от 5
до 20 секунд, для больших страниц с большим количеством контента и
сложной структурой продолжительность теста составляла от 30 секунд, до
полутора минут.
Так как наличие большой вычислительной мощности для программы
не требуется, тестирование проводилось на домашнем копьютере, в случае
использования более мощной вычислительной системы, возможно добиться
лучшего быстродействия, но учитывая цели с которой создавалась
программа, это не является минусом.
Было замечено что при постоянном использовании программы, не
требуется детальное изучение отчета после каждого запуска, так как при
проведении тестирования после каждого измененения на странице которая
была успешно протестирована ранее, обычно достаточно одного взгляда на
отчет чтобы убедиться что изменения не вызвали новые ошибки
Тестирование программы проводилось двумя методами:
 Тестирование большого количества однотипных страниц
 Тестирование небольшого количества страниц с разнообразной
структурой

Необходимо ввести критерии, по которым будет определяться точность

и полнота охвата тестов.
Идеальным случаем будет когда программа нашла все ошибки на
странице и не было ни одного ложного срабатывания
Несколько худшим случаем будет, когда найдены все ошибки, но с
небольшим количеством ложных срабатываний.
Если программа не нашла ошибок, то это хороший показатель, так как
это означает что их нет.
51
 Неудовлетворительным результатом будет случай, когда количество
всех ошибок на странице превышает количество найденных ошибок.
Если количество найденных ошибок превышает количество настоящих
ошибок на странице, то необходима доработка алгоритма обнаружения
ошибок.
В тестировании есть понятия точности и полноты теста, вычисляются
они следующим образом :
Точность тестирования = Количество найденных программой ошибок *
100% / Найденные ошибки
Полнота тестирования = Количество найденных программой ошибок *
100% / Количество всех ошибок на странице

1. Для первого метода тестирования на вход подается список

страниц, содержащий около тысячи различных ссылок.

Хорошим примером подобных страниц являются страницы поискового

веб-сервиса, такого как Google или Yandex или страницы интернет-магазина.
Тестирование такого количества страниц занимает несколько часов,
однако так как нет необходимости проводить тестирование последовательно,
можно распараллелить данный процесс, что уменьшит время теста до
нескольких десятков минут. После проведения тестирования тестировщик
должен открыть отчет и просмотреть оглавление, в котором все страницы
собраны в группы по результатам тестирования. Ввиду удобной структуры
отчета, тестировщику достаточно просмотреть один отчет для каждой
группы, так как подобные страницы отличаются только данными, но не
версткой. Если же данные наполняющие страницу порождают ошибки
верстки, то тестирование даст отличающиеся от других результаты.

2. Для второго метода тестирования на вход подается список

страниц содержащий пару десятков различных ссылок. Для
проведения тестирования программы были выбраны страницы

52
 таких сервисов как Youtube, Yandex, Adultmult и прочие.
Результаты тестирования приведены на графике.

7. Составление бизнес-плана по коммерциализации

результатов НИР магистранта

7.1 Концепция экономического обоснования.

Для выпускной квалификационной работы была поставлена тема
"Разработка автоматизированной системы тестирования верстки", которая
служит для обеспечения и облегчения тестирования веб-сайтов.
Выпускная работа посвящена разработке автоматизированной системы
тестирования верстки, а именно:
Применение автоматизированной системы тестирования верстки
позволяет получить значительный выигрыш ресурсов для отдела
тестирования, так как у автоматизированных тестов есть значительные
преимущества : повторяемость, быстрое выполнение, меньшие затраты на
поддержку, выполнение без вмешательства и.т.д.

7.2 Краткое техническое описание системы.

Система выполняется пошагово следующим образом :
1. Открытие тестируемой страницы в новой вкладке браузера

53
 2. Изменение размеров окна браузера и обход HTML-тегов
формирующих страницу с последующим сохранением данных о
измененных свойствах тегов.
3. Из полученных данных формируется структура в виде дерева,
содержащая состояния элементов при различных размерах окна
браузера. Выполняется поиск багов верстки.
4. Кластеризация багов по типам.
5. Формирование отчета по предыдущим пунктам.
6. Формируется файл оглавления для отчета.

Функциональные требования:
 Анализ тестируемой страницы
 Поиск ошибок на странице
 Типизация найденых ошибок
 Формирование отчета о пройденных тестах

7.3 Определение длительности работ и создание календарного плана.

Для расчета затрат на этапе проектирования, необходимо, в первую
очередь, составить календарный план работ и определить длительности
каждой работы. В данной работе для определения длительности работ будет
использоваться расчетный метод с использованием экспертных оценок по
формуле:
3t min  2t max
t оj 
5 , (1)

t оj
где - ожидаемая длительность j-й работы; t min и t max - наименьшая и
наибольшая по мнению эксперта длительность работы.
При этом результаты расчетов удобно свести в таблицу 1.
Таблица 1 - Длительность этапа разработки.

54
 Длительность работы,
чел./дни
№ Наименование работы

1 Разработка ТЗ 5 10 7
2 Изучение литературы 6 12 8,4
Анализ современных
3 технологий верстки веб- 3 8 5
интерфейсов
Анализ современных подходов
4 к автоматическому 4 9 6
тестированию сайтов
Разработка методов решения
5 18 26 21,2
задачи
Классификация ошибок
6 3 8 5
верстки
Разработка основных
7 25 40 31
программных модулей
Тестирование и отладка всей
8 10 13 11,2
программы в целом
Составление технической
9 5 9 6,6
документации
Составление техническо-
10 2 4 2,8
экономического обоснования

11 Сдача проекта 1 1 1

ИТО 140
82 105,2
ГО

Исходя из длительности этапов разработки, можем построить

ленточный график трудоемкости проекта, приведенные на рисунке 1.

55
Рисунок 1 – Ленточный график трудоемкости проекта

Все расчеты сведем в таблицу 2.

Таблица 2
№ Этапы и Исполнитель
содержание Трудоемк., Ставка,
выполняемых t o , ед.t руб./ед.t
работ
Инженер 4 1600
1 Разработка ТЗ
Руководитель 3 2650

2 Изучение
литературы Инженер 8,4 1600

56
 Анализ
современных
3 технологий
верстки веб-
интерфейсов Инженер 5 1600
Анализ
Инженер 4 1600
современных
4 подходов к
автоматическому
тестированию
сайтов Руководитель 2 2650
Разработка
5 методов решения
задачи Инженер 21,2 1600
6 Классификация Инженер 1 1600
ошибок верстки Руководитель 4
Разработка
7 основных
программных
модулей Инженер 31 1600
Тестирование и
8 отладка всей
программы в
целом Инженер 11,2 1600
Составление
9 Инженер 5,6 1600
технической
документации Руководитель 1 2650
Составление
10 технико-
экономического
обоснования. Инженер 2,8 1600
11 Сдача проекта Инженер 1 1600

Инженер 95,2
Общая трудоемкость
Руководитель 10

57
7.4 Расчет основной и дополнительной заработной платы, расходов на
страховые взносы.
По данным таблицы можно определить расходы на заработную плату
исполнителей и отчислений на страховые взносы на обязательное
социальное, пенсионное и медицинское страхование.
Заработную плату инженера принимаем 32000 р.
р

Заработную плату руководителя 52000р.

р

Расходы на основную заработную плату исполнителей определяются

по формуле:
k
Зосн. з / пл  Ti  Ci  (3  2  4  1) * 2176,2  (4  8.4  5  4  21.2  1  31  11.2  5,6  2.8  1) *1523.8 
i 1

 21762  145065,76  166827,76

где Зосн. з / пл - расходы на основную заработную плату исполнителей (руб.); k –

количество исполнителей; Ti - время, затраченное i-м исполнителем на

проведение исследования (дни или часы); Ci - ставка i-го исполнителя

(руб./день).
Расходы на дополнительную заработную плату исполнителей
определяются по формуле:
Н доп 12
Здоп. з / пл  Зосн. з / пл   166827,76 *  20019,33 ,
100 100

где Здоп..з / пл - расходы на дополнительную заработную плату исполнителей

(руб.); Зосн. з / пл - расходы на основную заработную плату исполнителей (руб.);

Н доп - норматив дополнительной заработной платы (%). При выполнении

58
расчетов в ВКР норматив дополнительной заработной платы принимаем
равным 12%.
Отчисления на страховые взносы на обязательное социальное,
пенсионное и медицинское страхование с основной и дополнительной
заработной платы исполнителей определяются по формуле:
Н соц
Зсоц  Зосн. з / пл  Здоп..з / пл  
30
 (166827,76  20019,33) *  56054,13 ,
100 1000

где Зсоц - отчисления на социальные нужды с заработной платы (руб.); Зосн. з / пл

- расходы на основную заработную плату исполнителей (руб.); Здоп..з / пл -

расходы на дополнительную заработную плату исполнителей (руб.); Н соц -

норматив отчислений на страховые взносы на обязательное социальное,
пенсионное и медицинское страхование (%), равный 30%.

7.5 Расчет расходов на сырье и материалы.

Далее проведем расчет потребностей в ресурсах, а именно затраты на
сырье и материалы, вычисляемые по формуле:
L
Н т. з
ЗМ   Gl Ц l (1  ),
l 1 100

где ЗМ – затраты на сырье и материалы (руб.); l – индекс вида сырья или

материала; Gl – норма расхода l-того материала на единицу продукции (ед.);

Ц l – цена приобретения единицы l-го материала (руб./ед.); Н т.з – норма

транспортно-заготовительных расходов (%).
При выполнении расчетов в ВКР норму транспортно-заготовительных
расходов ( Н т.з ) принимаем равной 10%.
Затраты на сырье и материалы оформлены в таблицу 3.
Таблица 3 - Затраты на сырье и материалы

Тип Норма Цена за Сумма на

Изделие
(профиль, расхода на единицу, изделие,

59
 сорт, марка, изделие, ед. руб. руб.
размер)

Бумага для
А4 2 пачки 240 528
принтера

Карандаш
Пишушие
автоматичес
принадлеж 4 штуки 25 110
кий, ручка
ности
синяя

Картридж Картридж
HP
ч/б для
CF280A 1 штука 1200 1320
лазерного (80A)
принтера

Итого 1958

Услуги сторонних организаций:

Таблица 4
№ Наименование Ед.изм. Кол-во Цена Сумма
работы
(услуги)
1 Интернет усл. 3 450 1350
Итого НДС: 175,5
Всего (с 1350
учетом НДС)

Покупные и комплектующие материалы в данной работе не

используются.

60
7.6 Расчет затрат на содержание и эксплуатацию оборудования.
Затраты на содержание и эксплуатацию оборудования определяются из
расчета на 1 час работы оборудования с учетом стоимости и
производительности оборудования:
m
З эо   Ciмч  t iм ,
i 1

где Зэо - затраты на содержание и эксплуатацию оборудования (руб.); Ciмч -

расчетная себестоимость одного машино-часа работы оборудования на i-й
технологической операции (руб./м-ч); tiм - количество машино-часов,
затрачиваемых на выполнение i-й технологической операции (м-ч).
Для расчета стоимости машино-часа работы оборудования, необходимо
рассчитать годовую стоимость эксплуатации и эффективный фонд рабочего
времени, при этом годовая стоимость включает в себя стоимость
электроэнергии, технического обслуживания и амортизационных
отчислений.
 Стоимость электроэнергии:
Сээ  М * Kз * Fээ * СкВтч
где M – мощность ЭВМ (0.1 кВт); kз – коэффициент загрузки (0.8);
CкВт.ч – стоимость 1 кВт час электроэнергии (2,37руб.); Fэф – эффективный
фонд рабочего времени, рассчитывается по формуле:
f
Fэф  Д ном * d * (1  )
100
где Дном= 247 – номинальное число рабочих дней в году; d = 8 –
продолжительность рабочего дня [час]; f = 2% - планируемый процент
времени на ремонт ЭВМ.
При данных значениях эффективный фонд составляет:
2
Fэф  247 * 8 * (1  )  1937[час]
100

Тогда стоимость электроэнергии за год составит:

61
 СЭЭ  0,1 * 0,8 *1937 * 2,37  368[ руб ]

 Техническое обслуживание и ремонт

Техническое обслуживание и текущий ремонт составляют 2.5% от
стоимости оборудования. В нашем случае стоимость компьютера составляет:
Cобор  35000[ руб ]
Тогда затраты на техническое обслуживание и ремонт составляют:
СТО  2,5% * Собор  0,025 * 35000  875[ руб ]

 Амортизационные отчисления по основному средству i за год

определяются как:
H ai
Аi  Ц п.н.i  ,
100

где Аi – амортизационные отчисления за год по i-му основному средству

(руб.); Ц п.н.i – первоначальная стоимость i-го основного средства (руб.);

H ai – годовая норма амортизации i-го основного средства (%),

рассчитывается по формуле:
Собор  С ликв
Н ai  * 100% ,
Т норм * Собор
где Сликв – ликвидационная стоимость, составляет 5% от стоимости
оборудования:
C ликв  0,05 * 35000  1750[ руб ]
Тнорм – нормативный срок службы (от 3 до 10 лет).
Примем Тнорм= 5 [лет].
Подставив указанные значения в формулу, получим:
35000  1750
Н ai  *100%  19%
5 * 35000
Тогда амортизационные отчисления за год составят:
19
Аi  35000 *  6650[ руб ]
100%

62
 Величина амортизационных отчислений по i-му основному средству,
используемому при работе над ВКР, определяется по формуле:
TiBKP 2.6
АiBKP  Аi   6650 *  1441[ руб ] ,
12 12

где АiBKP - амортизационные отчисления по i-му основному средству,

используемому в работе над ВКР (руб.); Аi – амортизационные отчисления за
год по i-му основному средству (руб.); TiBKP – время, в течение которого
студент использует i-ое основное средство (мес.).

 Суммарные годовые эксплуатационные затраты:

CЭ  СЭЭ  СТО  Аi  875  1750  6650  6818[ руб ]
 Стоимость одного часа рабочего времени:
CЭ 6818
Сiмч    3,51[ руб ],
Fэф 1937
Общее количество машино-часов, затрачиваемых на выполнение
проекта:
t м  101,4 * 8  811,2 [м-ч]

Тогда общие затраты на содержание и эксплуатацию оборудования:

З эо  3,51 * 811.2  2847,31 [руб]

В перечень накладных расходов входят (затраты, связанные с

производством продукции, оказанием услуг):
 амортизационные отчисления на полное восстановление
основных средств, нематериальных активов по нормам,
утвержденным в установленном порядке;

 затраты на приобретение канцелярских принадлежностей,

периодических изданий и соответствующей литературы,
необходимых для выполнения ВКР, а также на оплату
типографских и переплетных работ;

 прочие затраты, включая оплату услуг сторонних организаций;

63
 Процент накладных расходов по данным предприятия – 15%

Накладные расходы рассчитываются по формуле:

рублей

7.7 Определение себестоимость продукта.

Для расчета совокупной величины затрат, связанных с выполнением
проекта, все приведенные расчеты сводятся в таблицу 4.
Таблица 4 - Смета затрат на ВКР
№
Наименование статьи Сумма, руб
п/п

1. Расходы на оплату труда 186847,09

2. Отчисления на социальные нужды 56054,13

3. Материалы 1958

4. Затраты по работам, выполняемым сторонними 1350

организациями

5. Расходы на содержание и эксплуатацию 2640,2

оборудования

6. Амортизационные отчисления 6818

7. Накладные расходы

8. Спецоборудование -

ИТОГО затрат 283694,48 руб.

7.8 Вывод.

64
 В ходе выполнения расчетов выяснилось, что себестоимость продукта
составляет 283694,48 рублей. При этом основная часть расходов приходится
на основную заработную плату разработчиков.

В данной дипломной работе проведена работа по созданию

автоматизированной системы тестирования верстки. Были рассмотрены
различные способы верстки веб-интерфейсов и автоматизации их
тестирования, а также аналогичные готовые разработки различных фирм.
Для описания системы использовался инструментарий Selenium webdriver.
Работа по созданию программного обеспечения проводилась на базе веб
студии ООО «Квант». В рамках выпускной квалификационной работы была
разработана система автоматизированного тестирования верстки

65
 8. Дальнейшее развитие
8.1. Тестирование Rich Internet Applications
В разделе 3.3. данной работы обсуждалось тестирование Rich Internet
Applications – сложных сайтов, богатых клиентской логикой. С
уверенностью можно сказать, что доля подобных сайтов такого типа в
будущем будет только расти. Без умения тестировать такие сайты
представленная программа потеряет свою эффективность, поэтому
дальнейшее развитие в данном направлении необходимо.

8.2. Единовременный запуск в нескольких браузерах

Сейчас при каждом запуске необходимо явно указывать браузер, в
котором будет проходит тестирования, но верстку следует тестировать во
всех браузерах, потому как в разных браузерах верстка может отображаться с
существенными различиями ввиду их архитектуры. На данный момент,
приходится отдельно запускать наиболее распространенные браузеры, для
десктопных и мобильных платформ, проводить тестирование в каждом из
них, и анализировать отчет для каждого браузера отдельно. В дальнейшем
планируется дополнить дизайн и логику создания отчета для устранения
данной проблемы, так как просматривать единый отчет значительно быстрее
чем несколько. Кроме того, придется продумать и дополнить алгоритмы
кластеризации идентичных ошибок, так как в разных браузерах из-за
различного отображения отдельных элементов страницы, их размеры могут
отличаться что порождает проблемы с определением релевантности ошибки
и вынуждает улучшать алгоритмы кластеризации, а XPath-селекторы могут
различаться даже для одного и того же элемента. Также на многих сайтах
используются различные версии для различных устройств, на данный момент
практически у каждого крупного сервиса есть мобильная версия, или
специально «облегченная» версия для устройств с плохой скоростью обмена

66
данных через интернет. В дальнейшем планируется доработать алгоритмы
кластеризации и идентификации ошибок с целью избежать данной
проблемы.
8.3. Обратная связь и исключения
Так как программу планируется использовать на больших массивах
похожих страниц, можно увеличить её эффективность, реализовав
возможность добавлять исключения как для ложноположительных
срабатываний, так и для ложноотрицательных. Внедрение данного
функционала подразумевает внесение некоторых изменении в архитектуру,
так как в этом случае требуется постоянное хранилище для накопленных
исключений.
Необходимо рассмотреть два случая: добавление исключения для
одной ошибки или добавление исключения сразу для всего кластера. Во
втором случае действие исключения распространяется как на все ошибки уже
находящиеся в кластере, так и на все ошибки, которые попадут в него при
следующих запусках. В первом же случае нужно решить что делать с
похожими ошибками которые будут найдены в дальнейших запусках, но
которые не будут полностью совпадать. На этот вопрос невозможно ответить
без проведения полного исследования, можно лишь предположить что
принятие решения должно быть похожим на процесс кластеризации ошибок,
но с дополнительными и более жесткими критериями, чтобы избежать
кластеризации ошибок разного рода.
8.4. Самообучение
Создав работающую систему обратной связи, можно разработать
подобие системы автоматического обучения программы с помощью
элементов искусственного интеллекта. В ходе работы тестировщиков, будет
создаваться и пополняться обучающее множество, в котором будет
содержаться информация о положительных и ложноотрицательных
срабатываниях программы. После чего система, вероятно, станет способна
классифицировать состояния элементов на ошибочные и ожидаемые со
67
значительно большей точностью, нежели текущая жестко
детерминированная реализация, благодаря отладке на обучающем
множестве. Для этих целей представляется возможным использование
нейронной сети, по той причине, что входные данные классификатора
ошибок представляют собой однородные наборы свойств элементов, и целью
является выявление их неверных комбинаций.
Однако, это является непростой задачей, и даже не являясь экспертом в
данной области, можно утверждать, что затраты будет сложно окупить, так
как для реализации потребуется огромное количество времени,
следовательно, создание подобного проекта для нужд одной компании вряд
ли будет рентабельным. Тем не менее, у данного проекта есть потенциал для
развития как отдельного программного продукта.

68
 Заключение

В рамках данной дипломной работы были получены следующие

результаты:

 Произведен анализ и формализация знаний предметной области,

собраны и проанализированы методы верстки веб-интерфейсов,
современных технологий автоматизации тестирования.
 Рассмотрены различные сервисы для поиска ошибок на сайтах.
 Проведен анализ распространенных ошибок верстки,
разработаны формальные критерии определения ошибок и
алгоритмы для их обнаружения.
 На основе полученных знаний произведена реализация
инструмента для автоматизированного тестирования верстки
статических веб-страниц.
 Произведено тестирование и отладка разработанной программы.
 Доказана эффективность подходов и методов, использованных
при разработке программы.

По полученным результатам можно определить следующие

направления дальнейшего развития программы :
 Разработка и реализация описанных, но не реализованных на
данное время проверок.
 Поддержка мобильных браузеров.

69
  Разработка системы обратной связи для сбора статистики о
ложных срабатываниях и улучшение точности при проведении
регрессионного тестирования.
 Увеличение количества видов определяемых ошибок.
 Оптимизация работы программы при тестировании сложных
страниц.

Внедрение разработанной системы привело к следующим результатам:

 Значительно снизилось количество рутинной работы
выполняемой тестировщиком
 Уменьшилось количество ошибок при тестировании.
 Тесты могут выполнять все заинтересованные лица, как
заказчики, так и коллеги из других отделов.
 Трудозатраты немного уменьшились в меньшую сторону,
несмотря на то что в целом выигрыш в человеко-часах
незначителен, из-за необходимости поддержки и развития
проекта, в целом, выросла удовлетворенность работой, теперь
приходится значительно меньше времени уделять однообразной
работе в течении длительного времени, что положительно
сказывается на количестве пропущенных ошибок ввиду
меньшего уставания сотрудников.

70
Список литературы.

1. Роман Савин - Тестирование DOT COM

2. Whois, Domain Counts & Internet Statistics,
http://www.whois.sc/internet-statistics/
3. http://selenium2.ru/
4. http://www.seleniumhq.org/
5. СайтРепорт, http://sitereport.ru
6. W3C, The web standards model - HTML CSS and JavaScript
https://www.w3.org/wiki/The_web_standards_model_-
_HTML_CSS_and_JavaScript
7. https://www.w3.org/html/
8. http://www.w3schools.com/css/
9. https://webref.ru/css
10. Автоматизация процессов тестирования И. Винниченко

71