Вы находитесь на странице: 1из 52

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ АВТОНОМНОЕ

ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ
ВЫСШЕГО ОБРАЗОВАНИЯ
«НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ УНИВЕРСИТЕТ
«ВЫСШАЯ ШКОЛА ЭКОНОМИКИ»
Факультет Бизнеса и менеджмента

Черкасова Елизавета Романовна


АНАЛИЗ И АВТОМАТИЗАЦИЯ ПРОЦЕССА ТЕСТИРОВАНИЯ ПРОГРАММНОГО
ОБЕСПЕЧЕНИЯ
Выпускная квалификационная работа - БАКАЛАВРСКАЯ РАБОТА
по направлению подготовки Бизнес-информатика
образовательная программа «Бизнес-информатика»

Научный руководитель:
старший преподаватель, к.т.н.
Д. С. Проценко

Москва 2016
Оглавление
Введение....................................................................................................................................................3
Глава 1. Теоретические аспекты процесса тестирования.......................................................................6
1.1. Определение понятия тестирования ПО..................................................................................6
1.2. Классификация видов тестирования........................................................................................7
1.3. Методологии тестирования.....................................................................................................16
1.4. Процесс тестирования.............................................................................................................18
1.4.1. Разработка тест-кейсов....................................................................................................18
1.4.2. Выполнение тест-кейсов.................................................................................................23
1.4.3. Анализ результатов тестирования..................................................................................24
Глава 2. Описание и анализ процесса автоматизированного тестирования.......................................26
2.1. Описание процесса тестирования...........................................................................................26
2.2. Критерии эффективности процесса тестирования................................................................29
Глава 3. Автоматизация процесса тестирования...................................................................................33
3.1. Описание компании.................................................................................................................33
3.2. Расчёт экономической целесообразности введения автоматизированного тестирования. 33
3.3. Внедрение автоматизированных тестов.................................................................................36
Вывод.......................................................................................................................................................44
Список литературы.................................................................................................................................46
Приложение.............................................................................................................................................47

2
Введение

Основной пик интереса к тестированию программного обеспечения


пришелся на девяностые года в США. Быстрое развитие систем
автоматизированной разработки программного обеспечения и сетевых
технологий привело к увеличению производства на рынке программного
обеспечения. Усиление конкуренции между производителями программного
обеспечения требовало повышенного внимания к качеству продукции.
Поскольку ассортимент продукции сильно расширился, а цены стали
доступнее, потребители начали обращать большее внимание на качество
программного обеспечения. В настоящее время практически все области
жизни подвержены компьютеризации. Мало того, что компьютеры,
используются в повседневной жизни для обычных целей, они также
необходимы, когда речь идет о гораздо более значимых сферах, таких как
медицина, транспорт, строительство, безопасность и многие другие. Таким
образом, вопрос о качестве программного обеспечения становится особенно
важным, поскольку это не только вопрос комфорта, но и безопасности.
Осознавая вышеупомянутое, большое количество компаний по всему
миру начали инвестировать в повышение качества программного
обеспечения – начали создаваться отделы контроля качества и применяться
новые технологии, которые позволили компаниям увеличить свое
конкурентное преимущество, за счет повышения качества своих
программных продуктов.
Вскоре после этого тестирование программного обеспечения стало
неотъемлемой частью производства программного обеспечения.
Тестирование необходимо для того, чтобы понять, работает ли программа,
как ожидается и соответствует ли она предъявляемым к ней требованиям.
Своевременное выявление и исправление ошибок и недоработок имеет
огромное значение в процессе разработки программного продукта, поскольку
это уменьшает риски и при этом происходит снижение затрат на разработку
программного обеспечения. Благодаря тестированию, компании способны
поддерживать качество своих продуктов на очень высоком уровне. Часто
процесс тестирования ПО может быть автоматизирован, что в некоторых
случаях может положительно отразится на скорости и качестве тестирования,
это позволяет ещё больше снизить издержки компании и повысить качество
продукта.

3
В настоящий момент пристальное внимание уделяется процессам
тестирования, способам минимизировать издержки и автоматизировать
процесс тестирования. Сейчас существует достаточно большое количество
книг и статей на различные темы, будь то общие понятия в сфере
тестирования, или исследования узкой направленности.
Целью данного исследования является анализ эффективности
использования автоматизированного тестирования. Для достижения
поставленной цели были определены следующие задачи:
 Выявление теоретических основ тестирования, классификация и
описание его видов.
 Анализ и описание процесса тестирования, выявление критериев
корректно построенного процесса.
 Определение критериев эффективности процесса тестирования.
 Расчёт экономической целесообразности введения
автоматизированного тестирования.
 Внедрение автоматизированного тестирования.
Для достижения поставленных задач были выбраны такие
теоретические методы исследования как анализ, для решения задач,
связанных с анализом и описанием понятия и процесса тестирования, и
классификация, для описания видов тестирования. Для выполнения
практической части исследования использовались такие эмпирические
методы, как беседа, для сбора данных, необходимых для расчета
экономической целесообразности введения автоматизированного
тестирования в компании, и эксперимент, позволяющий на практике
определить эффективность внедрения автоматизированного тестирования.
Для данного исследования была использована литература
описывающая различные направления тестирования. Для решения
теоретических задач, таких как анализ процессов тестирования и его видов,
использовались фундаментальные, классические для области тестирования
книги, такие как «Ключевые процессы тестирования» автора Рекс Блэк,
«Software Testing» автора Ron Patton. Для решения задач, связанных с
автоматизированным тестированием, использовалась литература более узкой
направленности, такая как «Автоматизация процессов тестирования»
Винниченко И. В. При изучении экономических аспектов
автоматизированного тестирования и расчетах использовалась следующие
книги и статьи: Александр Хрущев «Эффективность использования
автоматических тестов в ИТ-проектах», Максим Черняк «Оценка
4
эффективности автоматизации тестирования» и «Автоматизированное
тестирование программного обеспечения» авторов Элфрид Дастин, Джефф
Рэшка, Джон Пол.
Структура работы обусловлена целью и задачами исследования. Работа
состоит из введения, трех глав и заключения.
В введении отражена актуальность работы, определена степень
научной проработанности темы, описаны цель, задачи и методы
исследования, дана характеристика основных источников информации.
В первой главе рассматривается понятие тестирования,
классифицируются виды тестирования, описываются методологии
тестирования. Так же описан процесс тестирования и выделены моменты,
которые требуют более пристального внимания при выполнении
тестирования. Во второй главе определены критерии и показатели
эффективности тестирования, раскрыто понятие автоматизированного
тестирования, описаны случаи, когда автоматизированное тестирование
целесообразно, и проанализированы достоинства и недостатки
автоматизированного тестирования. Третья глава посвящена
непосредственно автоматизированным тестам. В ней рассматривается
целесообразность автоматизированного тестирования, обосновывается выбор
инструмента реализации, приведены написанные автоматизированные тесты.
Заключение состоит из итогов исследования и окончательных выводов
по рассматриваемой теме, сформированных в процессе данного
исследования.
В приложении предоставлен полный исходный код решения по
автоматизации тестов.

5
Глава 1. Теоретические аспекты процесса тестирования

Данная глава посвящена решению таких задач, как выявление


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

1.1. Определение понятия тестирования ПО

Тестирование программного обеспечения - проверка соответствия


между реальным и ожидаемым поведением программы, осуществляемая на
конечном наборе тестов, выбранном определенным образом.
Тестирование – это одна из техник контроля качества, которая
включает в себя такие процессы, как проектирование тестов, выполнение
тестирования и анализ полученных результатов.
Общая схема тестирования (рисунок 1):

Рисунок 1. Общая схема тестирования.

На входе тестировщик получает программу, которую необходимо


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

6
для исправления ошибок в существующем продукте, любо для изменения
требований к еще только разрабатываемому продукту [1].
Тест (проверка) включает в себя выбранную определенным образом
искусственно созданную ситуацию и описание наблюдений, которые нужно
осуществить, для проверки программы на соответствие определенным
требованиям.
Тест может быть как коротким, так и длинным, например тест
производительности, проверяющий работоспособность системы при
длительной нагрузке.
Таким образом, в процессе тестирования тестировщик выполняет две
основные задачи.
Первой задачей является управление выполнением программы, а также
создание искусственных ситуаций, в которых и происходит проверка
поведения программы.
Вторая задача состоит в наблюдении за тем, как программа ведет себя в
различных созданных ситуациях, и в сравнении того, что он видит с тем, что
ожидается.
Если рассматривать задачи современного тестирования, то можно
прийти к заключению, что они заключаются не только в обнаружении
ошибок в программах, но и в выявлении причин, по которым они возникают.
Такой подход к процессу тестирования позволяет разработчикам выполнять
свою работу с максимальной эффективностью, устраняя обнаруженные
ошибки быстро и своевременно.

1.2. Классификация видов тестирования

При тестировании программного продукта применяется огромное


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

7
обеспечения» и интернет-ресурс, посвященный тестированию, «Про Тестинг
- Тестирование Программного Обеспечения».

По объекту тестирования
 Функциональное тестирование. Функциональное тестирование на
сегодняшний день является одним из наиболее часто применяемых
видов тестирования. Задача такого тестирования - это установить на
сколько соответствует разработанное программное обеспечение (ПО)
требованиям заказчика с точки зрения функционала. Иначе говоря,
проведение функциональных тестов позволяет проверить способность
информационной системы решать задачи пользователей.
 Нефункциональное тестирование. Позволяет проверить соответствие
свойств программного обеспечения с поставленными
нефункциональными требованиями. Таким образом,
нефункциональное тестирование - это тестирование всех свойств
программы, не относящихся к функциональности системы. Такими
свойствами могут быть предъявленные характеристики с точки зрения
таких параметров как:
 Надежность (способность системы реагировать на
непредвиденные ситуации).
 Производительность (способность системы работать под
большими нагрузками).
 Удобство (исследование удобства работы пользователя с
приложением).
 Масштабируемость (возможность масштабировать приложение
как вертикально, так и горизонтально).
 Безопасность (исследование возможности нарушения работы
приложения и кражи пользовательских данных
злоумышленниками).
 Портируемость (возможность перенести приложение на
определенный набор платформ)
И много других качеств.
 Тестирование пользовательского интерфейса. Это тестирование
корректности отображения элементов пользовательского
интерфейса на различных устройствах, правильности
реагирования их на совершение пользователем различных
8
действий насколько и оценка того, насколько ожидаемо ведет
себя программа в целом. Такое тестирование дает возможность
оценить, насколько эффективно пользователь сможет работать с
приложением и насколько внешний вид приложения
соответствует утвержденным документам, созданными
дизайнерами. При проведении тестирования пользовательского
интерфейса основной задачей тестировщика является выявление
визуальных и структурных недостатков в графическом
интерфейсе приложения, проверке возможности и удобства
навигации в приложении и корректность обработки приложением
ввода данных с клавиатуры, мыши и других устройств ввода.
Тестирование пользовательского интерфейса необходимо для
того, чтобы убедиться в том, что интерфейс соответствует
утвержденным требованиям и стандартам, и гарантировать
возможность работы пользователя с графическим интерфейсом
приложения.
 Тестирование удобства использования. Это способ тестирования,
позволяющий оценить степень удобства использования
приложения, скорость обучения пользователей при работе с
программой, а также насколько пользователи разрабатываемого
продукта находят ее понятной и привлекательной в контексте
заданных условий. Такое тестирование необходимо для
обеспечения максимально положительного пользовательского
опыта при работе с приложением.
 Тестирование защищенности. Позволяет выявить главные
уязвимости программного обеспечения по отношению к
различным атакам со стороны злоумышленников. Компьютерные
системы довольно часто подвергаются кибер атакам с целью
нарушения работоспособности информационной системы либо
кражи конфиденциальных данных. Тестирование
безопасности дает возможность проанализировать реальную
реакцию и действенность защитных механизмов,
использованных в системе, при попытке проникновения. В
процессе тестирования безопасности тестировщик пытается
выполнять те же действия, которые выполнял бы настоящий
взломщик. При попытке тестировщиком взломать систему могут
использоваться любые средства: атаки системы при помощи
специальных утилит; попытки узнать логины и пароли с
помощью внешних средств; DDOS атаки; целенаправленная
9
генерация ошибок для обнаружения возможности проникновения
в систему в процессе её восстановления; использование
известных незакрытых уязвимостей системы.
 Инсталляционное тестирование. Под этим термином
подразумевают тестирование корректности установки
(инсталляции) определенного программного продукта. Такое
тестирование обычно происходит в искусственно созданных
средах с целью выявить степень готовности программного
обеспечения к эксплуатации. Основные причины проведения
таких тестов связаны с необходимостью проверить корректность
поведения программного продукта при автоматизированном
развертывании либо обновлении. Обеспечение правильной и
стабильной установки программного обеспечения является очень
важным фактором при создании программного продукта,
поскольку позволяет пользователям быстрее и с меньшими
усилиями начать использовать продукт, при этом обеспечивая
одинаково корректное поведение этого продукта во всех
протестированных программных средах.
 Конфигурационное тестирование. Конфигурационное
тестирование предназначено для оценки работоспособности
программного обеспечения при разнообразных конфигурациях
системы. В зависимости от типа тестируемого программного
продукта, конфигурационное тестирование может преследовать
разные цели. Обычно это либо определение оптимальной
конфигурации оборудования, обеспечивающего достаточные для
работы ПО параметры производительности, либо проверка
определенной конфигурации оборудования (или платформы,
включающей в себя помимо оборудования, стороннее ПО,
необходимое для работы программы) на совместимость с
тестируемым продуктом. Если речь идет о клиент-серверном
программном обеспечении, то конфигурационное тестирование
проводится отдельно для сервера и отдельно для клиента.
Обычно при тестировании совместимости сервера с
определенной конфигурацией стоит задача найти оптимальную
конфигурацию, поскольку важна стабильность работы и
производительность сервера. В то время как при тестировании
клиента, наоборот, пытаются выявить недостатки ПО при любых
конфигурациях и по возможности устранить их.

10
 Тестирование надежности и восстановления после сбоев
(стрессовое тестирование). Такой вид тестирования довольно
часто проводится для программного обеспечения, работающего с
ценными пользовательскими данными, бесперебойность работы
и скорость восстановления после сбоев которого критичны для
пользователя. Тестирование на отказ и восстановление
осуществляет проверку способности программы быстро и
успешно восстанавливаться после отказа оборудования, перебоев
сети или критических ошибок в самом программном
обеспечении. Это дает возможность оценить возможные
последствия отказа и время, необходимое для последующего
восстановления системы. На основе полученных в ходе
тестирования данных может быть оценена надежность системы в
целом, и, при условии неудовлетворительных показателей,
соответствующие меры, направленные на улучшение систем
восстановления, могут быть приняты
 Тестирование локализации. Тестирование локализации дает
возможность выяснить насколько хорошо приспособлен продукт
для населения определенных стран и насколько он соответствует
ее культурным особенностям. Обычно, рассматриваются
культурный и языковой нюансы, а именно перевод
пользовательского интерфейса, сопутствующей документации и
файлов на определенный язык, также тестируется правильность
форматов валют, чисел, времени и телефонных номеров.
 Нагрузочное тестирование. Нагрузочное тестирование позволяет
выявить максимальное количество однотипных задач, которые
программа может выполнять параллельно. Самая популярная
цель нагрузочного тестирования в контексте клиент-серверных
приложений - это оценить максимальное количество
пользователей, которые смогут одновременно пользоваться
услугами приложения.
 Тестирование стабильности. Тестирование стабильности
проверяет работоспособность приложения при длительном
использовании на средних нагрузках. В зависимости от типа
приложения, формируются определенные требования к
длительности его бесперебойной работы. Тестирование
стабильности стремится выявить такие недочеты приложения как
11
утечки памяти, наличие ярко выраженных скачков нагрузки и
прочие факторы, способные помешать работе приложения в
течение длительного периода времени.
 Объемное тестирование. Задачей объемного тестирования
поставлено выявление реакции приложения и оценка возможных
ухудшений в работе ПО при значительном увеличении
количества данных в базе данных приложения. Обычно в такое
тестирование входит:
 Замер времени выполнения операций, связанных с
получением или изменением данных БД при
определенной интенсивности запросов.
 Выявление зависимости увеличения времени
операций от объема данных в БД.
 Определение максимального количества
пользователей, которые имеют возможность
одновременно работать с приложением без заметных
задержек со стороны БД.

• Тестирование масштабируемости. Это вид тестирования


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

Тестирование, связанное с изменениями


 Санити является одним из видов тестирования, целью которого служит
доказательство работоспособности конкретной функции или модуля в
соответствии с техническими требованиями, заявленными заказчиком.
Санитарное тестирование довольно часто используется при проверке
какой-то части программы или приложения при внесении в нее
определенных изменений со стороны факторов окружающей среды.
Данный вид тестирования обычно выполняется в ручном режиме.
 Дымовое тестирование представляет собой короткий цикл тестов,
целью которых является подтверждение факта запуска и выполнения
12
функций устанавливаемого приложения после того как новый или
редактируемый код прошел сборку. По завершении тестирования
наиболее важных сегментов приложения предоставляется объективная
информация о присутствии или отсутствии дефектов в работе
тестируемых сегментов. По результатам дымового тестирования
принимается решение об отправке приложения на доработку или о
необходимости его последующего полного тестирования.
 Регрессионное тестирование – тестирование, направленное на
обнаружение ошибок в уже протестированных участках. Регрессионное
тестирование проверяет продукт на ошибки, которые могли появиться
в результате добавления нового участка программы или исправления
других ошибок. Цель данного вида тестирования – убедиться, что
обновление сборки или исправление ошибок не повлекло за собой
возникновения новых багов [3].

По уровню тестирования
 Модульное тестирование (Unit тесты). Заключается в проверке каждого
отдельного модуля (самобытного элемента системы) путем запуска
автоматизированных тестов в искусственной среде. Реализации таких
тестов часто используют различные заглушки и драйверы для
имитации работы реальной системы. Модульное автоматизированное
тестирование - это самая первая возможность запустить и проверить
исходный код. Создание Unit тестов для всех модулей системы
позволяет очень быстро выявлять ошибки в коде, которые могут
появиться в ходе разработки.
 Интеграционное тестирование. Это тестирование отдельных модулей
системы на предмет корректного взаимодействия. Основная цель
интеграционного тестирования - найти дефекты и выявить
некорректное поведение, связанное с ошибками в интерпретации или
реализации взаимодействия между модулями.
 Системное тестирование. Это тестирование программы в целом, такое
тестирование проверяет соответствие программы заявленным
требованиям.
 Приемочное тестирование. Это комплексное тестирование,
определяющее фактический уровень готовности системы к
эксплуатации конечными пользователями. Тестирование проводится на

13
основании набора тестовых сценариев, покрывающих основные
бизнес-операции системы [2].

По исполнению кода
 Статическое тестирование. Это выявление артефактов, появляющихся
в процессе разработки программного продукта путем анализа
исходных файлов, таких как документация или программный код.
Такое тестирование проводится без непосредственного запуска кода,
качество исходных файлов и их соответствие требованиям
оцениваются вручную, либо с использованием вспомогательных
инструментов. Статическое тестирование должно проводиться до
динамического тестирования, таким образом, ошибки, обнаруженные
на этапе статического тестирования, обойдутся дешевле. С точки
зрения исходного кода, статическое тестирование выражается в
ревизии кода. Обычно ревизия кода отдельных файлов производится
после каждого изменения этих файлов программистом, сама же
ревизия может проводиться как другим программистом, так и ведущим
разработчиком, либо отдельным работником, занимающимся ревизией
кода. Использование статического тестирования дает возможность
поддерживать качество программного обеспечения на всех стадиях
разработки и уменьшает время разработки продукта.
 Динамическое тестирование. В отличии от статического тестирования,
такой вид тестирования предполагает запуск исходного кода
приложения. Таким образом, динамическое тестирование содержит в
себе множество других типов тестирования, которые уже были
описаны выше. Динамическое тестирование позволяет выявить ошибки
в поведении программы с помощью анализа результатов ее
выполнения. Получается, что почти все существующие типы
тестирования соответствуют классу динамического тестирования [1].

По субъекту тестирования
 Альфа-тестирование. Это тестирование проводится для самых ранних
версий компьютерного программного обеспечения (или аппаратного
устройства). Альфа-тестирование почти всегда проводится самими
разработчиками ПО. В процессе альфа-тестирования разработчики
приложения находят и исправляют ошибки и проблемы, имеющиеся в
14
программе. Обычно, во время Альфа-тестирования происходит
имитация работы с программой штатными разработчиками, реже имеет
место реальная работа как потенциальных пользователей, так и
заказчиков с продуктом. Как правило, альфа-тестирование проводится
на самом раннем этапе разработки ПО, однако в отдельных случаях
может быть применено для законченного или близкого к завершению
продукта, например, в качестве приёмочного тестирования.
 Бета-тестирование. Тестирование продукта, по-прежнему
находящегося в стадии разработки. При бета-тестировании этот
продукт предоставляется для некоторого количества пользователей,
для того чтобы изучить и сообщить о возникающих проблемах, с
которыми сталкиваются пользователи. Такое тестирование необходимо
чтобы найти ошибки, которые разработчики могли пропустить.
Обычно бета-тестирование проводится в две фазы: закрытый бета-тест
и открытое бета-тестирование. Закрытый бета-тест - это тестирование
на строго ограниченном кругу избранных пользователей. Такими
пользователями могут выступать знакомые разработчиков, либо их
коллеги, не связанные напрямую с разработкой тестируемого продукта.
Открытое бета-тестирование заключается в создании и размещении в
открытом доступе публичной бета-версии. В данном случае любой
пользователь может выступать бета-тестером. Обратная связь от таких
бета-тестеров осуществляется с помощью отзывов на сайте и
встроенных в программу систем аналитики и логирования
пользовательских действий, эти системы необходимы для анализа
поведения пользователей и обнаружения трудностей и ошибок, с
которыми они сталкиваются [2].

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

По степени автоматизации
 Ручное тестирование. Ручное тестирование проводится без
использования дополнительных программных средств, оно позволяет
проверить программу или сайт с помощью имитации действий
пользователя. В этой модели тестировщик выступает в качестве
пользователя, следуя определенным сценариям, параллельно
анализируя вывод программы и ее поведение в целом.
 Автоматизированное тестирование. Такое тестирование позволяет за
счет использования дополнительного программного обеспечения для
автоматизации тестов значительно ускорить процесс тестирования.
Такое дополнительное ПО позволяет контролировать и управлять
выполнением тестов и сравнивать ожидаемый и фактический
результаты работы программы. Более подробно будет рассмотрено
позже [2].

1.3. Методологии тестирования

Существуют различные методологии динамического тестирования ПО.


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

 Метод черного ящика

 Метод белого ящика

 Метод серого ящика

16
Метод черного ящика.

Впервые термин «черный ящик» упоминается психиатром У. Р. Эшби в


книге "Введение в кибернетику" в 1959 г. Он писал, что метод черного ящика
позволяет изучать поведение системы абстрагируясь от ее внутреннего
устройства.

В области тестирования метод черного ящика - это техника


тестирования, которая основана на работе с внешними интерфейсами
программного обеспечения, без знания внутреннего устройства системы [4].

Данный метод назван “Черным ящиком”, поскольку в этом методе


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

 Ошибки интерфейса.

 Недостающие или неправильно реализованные функции.

 Недостаточная производительность или ошибки поведения системы.

 Некорректные структуры данных или плохая организация доступа к


внешним базам данных.

Таким образом, поскольку тестировщик не имеет никакого


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

Метод белого ящика.

Как можно догадаться из названия, этот метод тестирования


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

17
То есть в данном случае тестировщику известны все аспекты
реализации тестируемого программного обеспечения. Этот метод позволяет
протестировать не только корректность реакции программы на определенный
ввод (как в случае с черным ящиком), но и правильную работу отдельных
модулей и функций, основываясь на знании кода, который будет
обрабатывать этот ввод. Знание особенностей реализации тестируемой
программы – обязательное требование к тестировщику для успешного
применения этой техники. Тестирование методом белого ящика позволяет
углубиться во внутренне устройство ПО, за пределы его внешних
интерфейсов.

Метод серого ящика.

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


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

1.4. Процесс тестирования

Тестирование представляет собой процесс проверки того, насколько


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

18
После прогона всех тестов анализируется результат, в результате чего можно
выявить ошибки в программе.
Процесс тестирования схематично показан на рисунке 2.

Рисунок 2. Процесс тестирования.

1.4.1. Разработка тест-кейсов

Тест-кейс (тестовый случай) – это минимальный элемент тестирования


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

Атрибуты тест-кейса.
Тест-кейс должен включать в себя:

19
 Уникальный идентификатор тест-кейса. Этот идентификатор
необходим для удобства организации и навигации по тестовым
наборам.
 Название. В названии должна отражаться основная идея тест-кейса,
цель данной проверки.
 Предусловия. Список шагов, не имеющих прямого отношения к
проверяемому функционалу, которые необходимо выполнить до начала
теста. Например, для тест-кейса «Заказ товара» предусловием может
быть шаг «авторизоваться на сайте», если на данном сайте заказать
товар может только авторизованный пользователь.
 Шаги. Описание последовательности действий, которая должна
привести к ожидаемому результату.
 Ожидаемый результат. Поведение системы, предусмотренное
требованиями. Один тест-кейс проверяет одну конкретную функцию,
поэтому ожидаемый результат может быть только один.
 Статус кейса. Проставляется в соответствии с тем, соответствует ли
фактический результат ожидаемому. Тест-кейс может иметь один из
трех статусов:
• Положительный, если фактический результат совпадает с
ожидаемым результатом.
• Отрицательный, если фактический результат не совпадает с
ожидаемым результатом. Если статус кейса отрицательный-найдена
ошибка.
• Выполнение теста блокировано, если после одного из шагов
продолжение теста невозможно. В этом случае так же, найдена
ошибка.
 История редактирования. Дает возможность узнать, кем и когда был
изменен тест-кейс. Это удобно, поскольку позволяет более эффективно
редактировать тест-кейсы.

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

20
 Тест является хорошим в случае, когда он может обеспечить высокую
вероятность обнаружения ошибки. Показать, что в программе
полностью отсутствуют ошибки невозможно, поэтому процесс
тестирования должен быть направлен на выявление прежде не
найденных ошибок.
 Четкие, однозначные формулировки шагов. Описание шагов для
прохождения тест-кейса должно содержать всю необходимую
информацию, но при этом тест-кейс не должен быть слишком
детализирован. Например, если тест-кейс содержит такие шаги, как
авторизация, в описании необходимо указывать логин и пароль, но не
нужно указывать в каком углу экрана находится окно авторизации.
 Отсутствие зависимостей тест-кейсов. Если тесты связанны между
собой, становится проблематичным изменение, дополнение или
удаление конкретного тест-кейса, появляется необходимость изменять
связанные с ним тесты. Более того, взаимосвязанные тесты обладают
конкретный сценарием от перехода одного теста к другому. Это
приведет к тому что не все сценарии перехода от одного теста к
другому будут протестированы и появляется вероятность пропустить
баг.
 Ожидаемый результат необходимо прогнозировать заранее и
прописывать его в тест-кейсе. Если ожидаемый результат не
определить заранее, может возникнуть ситуация, когда тестировщик
видит то, что он хочет увидеть. При заранее определенном результате
тестировщику необходимо только сравнить ожидаемый результат с
фактическим.
 Необходимо уделять внимание не только тестам, которые проверяют
правильные данные, но и тем тестам, которые проверяют работу
программы при неправильных, непредусмотренных данных. Большое
количество ошибок связано именно с теми действиями пользователя,
которые не предусмотрены программой.
 Также необходимо проверять, не делает ли программа то, чего не
должна. Нужно производить проверку на нежелательные побочные
эффекты.

В таблице 1 приведен пример тест-кейса, отвечающего


вышеописанным требованиям.
Таблица 1. Пример тест-кейса.

21
Тест PGU-1: ВСВ. Избранные услуги

Описание теста: цель, сценарий и исходное состояние программы:

Проверка работы функциональности "Избранные услуги"


Execution
#: Шаги: Ожидаемая реакция:
Status:
Авторизоваться на
1 Авторизация прошла успешно. Пройден
портале.
Перейти в версию для
Открылась главная страница
слабовидящих, кликнув на
2 портала в версии для Пройден
соответствующую иконку в
слабовидящих.
левом верхнем углу.
Перейти в каталог услуг,
Карточка услуги открыта
3 открыть любую карточку Пройден
успешно.
услуги.
Попап "Услуга успешно
Нажимаем "Добавить добавлена в избранные. Вы
4 Пройден
услугу" внизу страницы. можете перейти к ней из
Личного кабинета".
Шаги выполнены успешно,
Повторяем шаги 3-4
5 результаты соответствуют Пройден
несколько раз.
ожидаемым.
По умолчанию открывается
раздел "Мои услуги".
Переходим в Личный Отображается
6 Пройден
кабинет. пронумерованный список
добавленных услуг в порядке их
добавления.
Проверяем переход на
7 карточку услуги из списка Переход происходи корректно. Пройден
избранных услуг.
Переходим обратно в ЛК.
Появилась кнопка "Удалить"
8 Отмечаем галочкой любую Пройден
внизу страницы.
услугу.
Попап "Услуга успешно удалена
Нажимаем кнопку
9 из избранных.". Услуга пропала Пройден
"Удалить"
из списка избранных услуг.
Поочерёдно удаляем
10 Удаление прошло корректно. Пройден
остальные услуги.
Execution type: Вручную
Estimated exec.
10.00
duration (min):
Приоритет: Medium

Execution
 
Details
Версия (сборка) 3.0.111/2.10.31
Тестировщик elizaveta.cherkasova@rtlabs.ru

22
Execution Result: Пройден

Execution Mode: Вручную

Данный тест-кейс содержит следующие обязательные атрибуты:


 Уникальный идентификатор тест-кейса: PGU-1
 Название: ВСВ. Избранные услуги
 Предусловия: в данном тест-кейсе предусловием является авторизация
на портале. Непосредственно к тесту авторизация не относится
(авторизацию на портале проверяет отдельный тест-кейс), но без
авторизации данная проверка невозможна.
 Шаги.
 Ожидаемый результат.
 Статус кейса.
 История редактирования: в тест-кейсе указана информация о том, кто
проходил тест, в какое время и в рамках какой сборки.
Данный тест-кейс отвечает требованиям, изложенным выше. Шаги
сформулированы однозначно, содержат необходимую, но не лишнюю
информацию, ожидаемый результат четкий и однозначный.

1.4.2. Выполнение тест-кейсов

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


проведения тестирования программы специалистом, который не является ее
автором. Категорически неприемлемо тестирование продукта
программистом, создавшим его. Это правило должно быть применимо ко
всем, без исключения, формам тестирования, например, как к тестированию
целой системы, так и к тестированию отдельных модулей, а также внешних
функций. Несомненно, при проведении процесса тестирования не автором
программы, он становится более точным и эффективным.
Если рассматривать суть процесса тестирования, то становится
очевидным, что это процесс деструктивный. С этой его особенностью и
связывают представление о тестировании как о сложной работе.
Исключительно трудной эта работа представляется для программиста,
создавшего продукт, так как проектирование, разработка и написание
программы является процессом конструктивным, в отличие от тестирования,
23
в процессе которого специалисту необходим настрой на деструктивный образ
мышления. Исходя из этой особенности тестирования, приступать к
тщательному и беспристрастному выявлению ошибок сразу же по
завершению создания программы представляется трудновыполнимым для ее
автора.
Например, содержащиеся в модуле дефекты, которые являются
следствием ошибок перевода (такие как, к примеру, неверная интерпретация
спецификации), с высокой долей вероятности будут присутствовать и в
тестах, так как оба процесса будут выполняться одним и тем же
специалистом. Также могут обнаружиться в тестах и ошибки, сделанные при
понимании и сопряжении других модулей.
Однако, не следует делать однозначный вывод, что тестирование
программы специалистом ее создавшим невозможно. Большое количество
программистов справляются с этой задачей вполне успешно. Но, исходя из
вышесказанного, можно прийти к заключению, что выполнение
тестирования другим специалистом, не являющимся ее автором, гораздо
эффективнее и плодотворнее. Поэтому и создаются группы тестировщиков,
специально для проведения процесса тестирования с наиболее
оптимальными результатами.
Принятие решения о сроках остановки тестирования является одной из
сложных проблем при проведении тестирования. Это происходит, потому
что невозможно провести процесс испытания всех входных значений или,
другими словами, исчерпывающее тестирование. Следовательно, при
процессе тестирования техническая сторона проводимых действий входит в
противоречие с экономической выгодой, так как возникает вопрос выбора
оптимального конечного количества тестов, которое дает максимально
возможный результат (вероятность обнаружения ошибок) при определенных
затратах.
Существует довольно много примеров, когда написанные тесты были
малоэффективны, так как их способность обнаружения новых ошибок была
крайне низкой. В то же время, хорошие тесты, обнаруживающие ошибки с
высокой точностью, могли остаться без внимания специалистов.
Таким образом, принимая решение о количестве времени и
проводимых тестов с программой, всегда необходимо принимать во
внимание уровень риска, как технического, так и бизнес риска, для отдельно
взятого продукта и для всего проекта. Более того, нужно учитывать тот факт,
что проект обычно имеет ограничения по времени и бюджету.
24
1.4.3. Анализ результатов тестирования

Несмотря на существование различных видов тестирования, процессы


тестирования достаточно схожи. Разработкой и анализом тестов может
заниматься только тестировщик. За выполнение тест-кейсов так же отвечает
тестировщик, однако выполнение этих тестов может производиться как
вручную, так и в автоматизированном режиме.
По результатам выполнения каждого теста, ему присваивается статус
(положительный, отрицательный, блокирован). Если тест получает
отрицательный статус, то в зависимости от методологии тестирования
тестировщик может проводить дополнительную работу для выявления
конкретной ошибки, которая была причиной некорректного поведения
программы [4].
При использовании методологии черного ящика, анализ результатов
теста сводится к выявлению общих закономерностей, ведущих к появлению
ошибки. Однако когда используется белый или серый ящики, тестировщик
может проводить гораздо более глубокий анализ причин возникновения
ошибки. В зависимости от доступных тестировщику данных (база данных,
исходный код программы, логи и т.п.), он способен с некоторой точностью
определить источник некорректного поведения программы.
После того, как максимально точно выявлена причина нежелательного
поведения, тестировщик должен описать её вместе со способом
воспроизведения ошибки для дальнейшей передачи этой информации
разработчикам. Когда источник ошибки точно определен и хорошо описан,
разработчикам гораздо проще исправить эту ошибку.

25
Глава 2. Описание и анализ процесса автоматизированного тестирования

Данная глава посвящена описанию автоматизированного тестирования,


его типам, выявлению достоинств и недостатков в автоматизации
тестирования.
Более того в этой главе определены критерии эффективности процесса
тестирования, описаны формулы для расчёт экономической
целесообразности введения автоматизированного тестирования.

2.1. Описание процесса тестирования

Автоматизированное тестирование представляет собой процесс


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

Выбор тестов для автоматизации.


Для того, чтобы определить, что именно нужно автоматизировать,
необходимо сначала оценить целесообразность автоматизации тестирования
в условиях проекта. Если автоматизация целесообразна, то, принимая во
внимание требования к объекту тестирования, необходимо разработать план,
согласно которому автоматизированные тесты будут создаваться. При
разработке подобного документа, необходимо четко понимать, что нужно
26
автоматизировать и как именно это реализовать. Автоматизация
тестирования обычно позволяет ускорить и удешевить процесс тестирования,
однако существуют условия, в которых автоматизация особенно эффективна:
 Функциональность, которая используется довольно часто и в которой
риски от ошибок достаточно высоки. Автоматизация проверки
критической функциональности поможет быстрее находить ошибки,
следовательно, быстрее их решать.
 Рутинные операции, например проверка форм, в которых необходимо
заполнять большое количество полей.
 Труднодоступные места в системе, такие как запись в базу данных,
бекэнд процессы, логирование.
 Валидационные сообщения (проверка появления валидации при
некорректном заполнении поля)
 Проверка корректного поиска данных
 Проверки, требующие точных математических расчетов
 Длинные end-to-end сценарии
И многое другое, в зависимости от инструментов тестирования и
требований к системе.
Можно выделить три основных вида автоматического тестирования:
модульное тестирование (unit test), тестирование API и GUI тесты.
 Модульное тестирование является самым низким уровнем
автоматизированного тестирования. Поиск ошибок осуществляется на
уровне функций, методов, процедур. Данные тесты обычно пишутся
разработчиками.
 Тестирование API осуществляет проверку взаимодействия нескольких
модулей между собой, или проверяет взаимодействие со сторонними
сервисами.
 GUI тесты - тестирование через графический пользовательский
интерфейс. С помощью имитации действий пользователя проверяются
такие аспекты, как надлежащее функционирование кнопок и полей,
правильное появление диагностических сообщений об ошибках и
корректная работа приложения в целом. Написанием GUI тестов чаще
всего занимаются тестировщики.
Сегодня существует множество средств, позволяющих
автоматизировать тестирование программного продукта. Однако
автоматизация тестирования не всегда востребована, ведь в конечном итоге
27
может оказаться что разработка и сопровождение систем
автоматизированного тестирования обойдется компании дороже, чем труд
ручных тестировщиков.
При анализе целесообразности создания систем автоматизированного
тестирования важно оценить:
 насколько сложно эту работу выполнять “руками”
 как часто будут выполняться эти тесты
 необходимо ли увеличивать скорость выполнения тестов
 если тесты нужно автоматизировать, то нужно ли это делать со всеми
тестами, или достаточно автоматизировать лишь некоторые из них.

Основные задачи, которые решаются внедрением автоматизированного


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

28
 Повышение трудозатрат на актуализацию автотестов при изменениях в
системе
 Риск появления ошибок в самом автотесте
 Не все тесты возможно автоматизировать

2.2. Критерии эффективности процесса тестирования

Процесс тестирования должен быть эффективен в первую очередь с


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

29
Оценка целесообразности автоматизации тестирования производится с
помощью подсчета затрат на ручное и автоматизированное тестирование и
их сравнение [5], [6]. Точно посчитать финансовую целесообразность
автоматизации тестов обычно невозможно, поскольку она зависит от
параметров, которые в процессе разработки продукта могут быть лишь
примерно понятно (например, планируемая длина жизненного цикла системы
или точный список тестов, подлежащих автоматизации).
Для расчёта инвестиций, необходимых для внедрения и эксплуатации
автоматизированных тестов за выделенный период (Ip), используется
следующая формула:

I0 - Оценка стартовых инвестиции, которые состоят из затрат на


лицензии необходимого программного обеспечения для разработки
автотестов, стоимости дополнительных аппаратных средств и.т.п.
C0 - Оценка стоимости разработки и отладки библиотеки
автоматических тестов, которая рассчитывается как произведение среднего
времени, нужного для написания одного автоматизированного теста одним
разработчиком тестов (в часах), умноженное на цену его рабочего часа и на
общее количество тестов, которые предстоит автоматизировать.
k - Это количество планируемых прогонов тестов (циклов
тестирования) за всё оставшееся время жизненного цикла продукта.
Ce - Оценка стоимости одного прогона всех автоматизированных
тестов, которая рассчитывается как время, необходимое для подготовки к
выполнению тестирования, сложенное с средним временем выполнения
одного теста одним тестировщиком, умножено на цену рабочего часа и на
общее количество тестов. В нашем случае эта переменная принята за 0,
поскольку подготовка к циклу тестирования не требуется, а само
тестирование не требует дополнительного контроля со стороны работника и
происходит полностью автономно.
Ca - Оценка затрат на анализ результатов одной итерации цикла
автоматизированного тестирования, которая вычисляется как оценка доли
отрицательных тестов, умноженная на количество тестов, на среднее время,
30
необходимое для анализа причин отрицательной оценки одного теста одним
тестировщиком, и на цену одного рабочего часа тестировщика.
Cm - Оценка стоимости поддержания автоматизированных тестов в
рабочем и актуальном состоянии. Рассчитывается как вероятность появления
необходимости изменения одного теста между циклами тестирования,
умноженная на количество тестов, на среднее время, необходимое для
актуализации одного теста и на цену одного рабочего часа тестировщика.

Оценка стоимости ручного тестирования (Gp) представлена в


следующей формуле:

G0 - Оценка стоимости разработки базы тест-кейсов для ручного


тестирования.
k - Это количество планируемых прогонов тестов (циклов
тестирования) за всё оставшееся время жизненного цикла продукта.
Ge - Оценка стоимости однократного выполнения цикла ручного
тестирования, которая рассчитывается как среднее время, затрачиваемое на
подготовку к тестированию плюс среднее время, нужное для выполнения
одного тест-кейса одним тестировщиком, умноженное на суммарное
количество кейсов и на цену одного рабочего часа тестировщика.
Ga - Оценка стоимости анализа результатов для одного прогона цикла
ручного тестирования. Вычисляется как оценка средней доли отрицательных
тестов в прогоне, умноженная на количество тестов, на среднее время,
необходимое для анализа причин отрицательной оценки одного теста одним
тестировщиком, и на цену одного рабочего часа тестировщика;
Gm - Оценка стоимости поддержания ручных тестов в актуальном
состоянии. Рассчитывается как вероятность появления необходимости
изменения одного теста между циклами тестирования, умноженная на
количество тестов, на среднее время, необходимое для актуализации одного
теста и на цену одного рабочего часа тестировщика [7].

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

32
Глава 3. Автоматизация процесса тестирования

В этой главе на конкретном примере будет проверяться гипотеза о


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

3.1. Описание компании

Для данного исследования мною была выбрана компания АО «РТ


Лабс». РТ Лабс является дочерней компанией ОАО «Ростелеком», который в
свою очередь представляет собой единственного исполнителя работ в
Российской Федерации по развитию электронного правительства. Будучи
подрядчиком «Ростелекома» в области развития электронного правительства
и национальной облачной платформы, компания РТ Лабс обеспечивает
развитие и поддержку портала государственных услуг
https://www.gosuslugi.ru/. В компании РТ Лабс есть большой отдел
тестирования, состоящий из 25 специалистов. В отделе есть -------,
занимающиеся статическим тестированием, тестированием документации,
есть ---- занимающийся динамическим тестированием сайта. Каждую неделю
в продуктивную среду выпускаеются исправления и улучшения сайта. Перед
выпуском релиза в продуктив, на тестовой среде проводится регрессионное
тестирование, для того, чтобы убедиться, что основной функционал сайта не
поврежден и в продуктив выйдет корректный релиз.
На данный момент регрессионное тестирование состоит из 220
проверок, и ни один тест не автоматизирован.

3.2. Расчёт экономической целесообразности введения


автоматизированного тестирования
Для проверки гипотезы о целесообразности автоматизации процесса
тестирования в компании необходимо посчитать затраты на ручное
тестирование и затраты на автоматизацию. Расчеты будут производится
исходя из данных, полученных в ходе опроса работников отдела
тестирования в компании РТ Лабс. При опросе было выявлено, что
регрессионное тестирование, которое проводится каждую неделю, занимает
большое количество времени у тестировщиков и именно этот вид
33
тестирования специалисты данного отдела хотели бы автоматизировать. Для
расчета целесообразности автоматизации используются формулы, описанные
во второй главе. В ходе опроса были получены данные, необходимые для
подсчетов.
 Оплата тестировщика, занимающегося автоматизацией, оценивается в
600 рублей в час, в то время как оплата ручного тестировщика
составляет 500 рублей в час.
 Данный проект рассчитан как минимум еще на три года. Регрессионное
тестирование проводится каждую неделю, но часто случается так, что
после исправления критичных ошибок, найденных при тестировании,
проверки необходимо выполнять заново. И того, примерно 1.5 прогона
в неделю. При тестировании используется 220 тестов.
 На подготовку к циклу у ведущего тестировщика обычно уходит
порядка 45 минут, преимущественно это время тратится на
распределение задач между тестировщиками и другие
организационные задачи. Среднее время, необходимое одному
тестировщику на выполнение одного тест-кейса, составляет 10 минут.
 При каждом прогоне примерно 5% тестов имеют отрицательные
результаты. На определение источника ошибки для каждого теста у
ручного тестировщика уходит около 10 минут, в то время как при
автоматизированном тестировании анализ ошибки занимает 15 минут.
При ручном тестировании тестировщик сразу видит, где именно и при
каких входных данных произошла ошибка, а при автоматизированном
тестировании эту информацию необходимо искать коде.
 Вероятность появления необходимости изменения одного теста между
циклами тестирования оценена в 3%, Среднее время, необходимое для
актуализации одного теста около 6 минут. Для актуализации
автоматизированного теста потребуется 30 минут.
 Автоматизация одного теста оценивается в 3 часа

Учитывая информацию, полученную в ходе опроса специалистов


отдела тестирования, можно произвести расчет затрат на ручное и
автоматизированное тестирование.
Формула для расчета затрат на автоматизированное тестирование

34
Начальные инвестиции в данном случае равны нолю, поскольку
используется бесплатный стек технологий (IDE, Фреймфорки и прочее) и
отсутствует необходимость вкладываться в дополнительное оборудование.
Стоимость разработки автоматизированных тестов равна 396 000
рублей (220 тестов * 3 часа * 600 руб/час).
Планируемое количество циклов тестирования - 234 раз
(3года*52недели*1.5раза)
Оценка стоимости однократного выполнения цикла
автоматизированного тестирования равна нулю, поскольку подготовка к
циклу тестирования не требуется, а само тестирование не нуждается в
дополнительном контроле со стороны работника и происходит полностью
автономно.
Оценка стоимости анализа результатов выполненного цикла
автоматизированного тестирования равна 1 650 рублей (220тестов * 0.05 *
0.25часа * 600руб/час)
Оценка стоимости поддержания автоматизированных тестов в рабочем
и актуальном состоянии равна 1 980 рублей (220тестов * 0.03 * 0.5часа *
600руб/час).
Таким образом, итоговая стоимость внедрения и эксплуатации системы
автоматизированных тестов равна:
0 + 396 000 + 234 * (0 + 1 650 + 1 980) = 1 245 420 рублей.

Формула для расчет затрат на ручное тестирование:

Оценка стоимости разработки базы тест-кейсов для ручного


тестирования равна нулю, поскольку компания уже обладает базой тест-
кейсов
Оценка стоимости однократного выполнения цикла ручного
тестирования равна 19 075 рублей (0.75 + 220 тестов* 0.17) * 500руб/час.
Оценка стоимости анализа результатов для одного прогона цикла
ручного тестирования равна 935 рублей (220 * 0.05 * 0.17 * 500).

35
Оценка стоимости поддержания ручных тестов в актуальном состоянии
равна 330 рублей (220 * 0.03 * 0.1 * 500) .
Итоговая стоимость затрат на ручное тестирование равна:
0 + 234 * (19 075 + 935 + 330) = 4 759 560 рублей.
Следовательно, можно прийти к заключению, что на данном проекте
автоматизация целесообразна. Далее будут разработаны два
автоматизированных теста для проверки данной гипотезы на реальных
данных.

3.3. Внедрение автоматизированных тестов


Автоматизация функциональных тестов веб-приложений обычно
происходит с помощью специальных программных фреймворков,
позволяющих симулировать поведение реальных пользователей из
программной среды. Эти фреймворки обычно состоят из 2-х частей:
программы или надстройки над браузером, которая позволяет управлять
браузером и выполнять команды внутри него и программного API,
предоставляющего удобные функции для контролирования этой программы.
Ниже описаны основные функции, которые предоставляют подобные
фреймворки.
 Общие функции браузера (Открытие новой вкладки или окна и
контролирование их размеров).
 Навигация между веб страницами.
 Поиск веб элемента на странице с указанными параметрами.
 Функции ожидания определенных событий (например ожидание
полной загрузки страницы или появления на ней определенного
элемента).
 Симуляция действий пользователя, таких как нажатие кнопки мыши на
определенный элемент или ввод последовательности символов с
клавиатуры.
 Для более сложных действий предоставляется возможность исполнять
JavaScript команды на странице.
Автоматизировать ф тесты можно с помощью различных программных
фреймворков. Есть большое кол-во инструментов для автоматизации функц
тестирования основные из которых Selenium WebDriver, Watij HtmlUnit
Jamaleon.
36
Мною был выбран Selenium WebDriver, поскольку он в отличие от
других фреймровков позволяет выбрать язык программирования для
реализации тестов (большинство остальных фреймворков позволяют
использовать только Java), способен работать со всеми браузерами и
обладает максимально богатым функционалом с точки зрения
функционально тестирования. Из предоставляемых Selenium WebDriver
возможных языков программирования для реализации тестов (Java, C#, Ruby,
Python) был выбран C#, поскольку на момент написания данной работы
мною был накоплен больший опыт использования этого языка чем других.
При практическом применении автоматизированных функциональных
тестов очень быстро обнаруживается что тестирование каждого отдельного
веб приложения обладает своей спецификой. Это подталкивает к созданию
дополнительного программного слоя между фреймворком для тестирования
и самими автотестами. Такой подход позволяет минимизировать количество
повторяющегося кода путем вынесения его в функции этого слоя, что
положительно сказывается на скорости создания автотестов, понижает
вероятность возникновения ошибок и улучшает удобочитаемость кода.
Обычно такие промежуточные API содержат утилиты и классы,
позволяющие оперировать более высокоуровневыми сущностями,
существующими в контексте конкретного веб приложения. Часто в
автотестах может понадобиться протестировать функционал, для которого
необходимо авторизоваться, найти типичный для всех страниц приложения
элемент, сделать прямой запрос к базе данных чтобы сверить данные с
представленными на сайте и т.д. Такие действия будут регулярно
выполняться из автотестов, при этом если не вынести их в отдельное API они
будут только загромождать код, поскольку занимают много места и не имеют
прямого отношения к конкретному тест кейсу.

Ниже представлены реальные тест-кейсы для тестирования сайта


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

37
проверка на корректную работу поиска на странице технческой поддержки в
личном кабинете пользователя.
Тест PGU-174: ФОС

Execution
#: Шаги: Ожидаемая реакция:
Status:

Отправка обращения. Переход в ЛК по кнопке Вернуться к


1 Отображается список Пройден
списку 

2 Отображение данных на вкладке ЛК - Техподдержка     Данные отображаются Пройден

3 Создание нового сообщения с вкладки ЛК - Техподдержка Сообщение создано Пройден

Повторное сообщение
4 Отправка второго сообщение по ранее созданному.  Пройден
отправлено

Поиск работает
5 Проверка поиска на вкладке ЛК - Техподдержка     Пройден
корректно

Execution type: Вручную

Estimated exec.
10.00
duration (min):

Приоритет: Medium

Execution Details  

Версия (сборка) Тестовая сборка

Тестировщик elizaveta.cherkasova

Execution Result: Пройден

Execution Mode: Вручную

Этот тест проверяет работоспособность всех вкладок на странице


«Лента уведомлений» в личном кабинете пользователя, работоспособность
фильтра и поиска на странице ленты уведомлений.
Тест PGU-176: ФЛ ЛК - Лента уведомлений

Execution
#: Шаги: Ожидаемая реакция:
Status:

Вкладки работают
Работоспособность вкладок, отображение верной корректно,
1 Пройден
информации на каждой из них.  отображается верная
информация

Отображаются
2 Отображение Заявок, черновиков. Пройден
корректно

Поиск и фильтр
3 Работоспособность поиска, фильтра. Пройден
работают корректно

38
Execution type: Вручную

Estimated exec.
10.00
duration (min):

Приоритет: Medium

Execution
 
Details

Версия (сборка) Тестовая сборка

Тестировщик elizaveta.cherkasova

Execution Result: Пройден

Execution Mode: Вручную

Далее представлена реализация описанных выше тестов.


Тест, который проверяет отправку сообщения в службу поддержки и
отображение данного сообщения в ЛК пользователя.
 Переход на страницу «Лента уведомлений», вкладка «Техподдержка»
WebDriver.Chrome.NavigateToUrl("http://lk-dev.test.gosuslugi.ru/notifications?
type=FEEDBACK");
 Ожидание появления элемента «Создать новое сообщение» и
последующее нажатие на него
WebDriver.Chrome.WaitUntilElementVisible(By.CssSelector("#content>div.ng-
scope>div>ng-include>div>fieldset>ul>li.feedback-button.ng-
scope>a")).SafeClick();
 Заполнение формы обратной связи
WebDriver.Chrome.WaitUntilElementVisible(By.Id("_epgu_el2")).SafeClick();
WebDriver.Chrome.WaitUntilElementVisible(By.XPath("//*[@id=\"feedbackFor
m\"]/div/div/div/div[2]/ul/li[4]")).SafeClick();
WebDriver.Chrome.WaitUntilElementVisible(By.XPath("//*[@id=\"feedbackFor
m\"]/div/div/ng-include/epgu-input[1]/div/textarea")).SendKeys("TEST");
WebDriver.Chrome.WaitUntilElementVisible(By.XPath("//*[@id=\"feedbackFor
m\"]/div/div/ng-include/epgu-input[1]/div/textarea")).Submit();
 Фиксация время отправки сообщения
DateTime time = DateTime.Now;

39
 Ожидание появления элемента «Вернуться к списку» и последующее
нажатие на него
WebDriver.Chrome.WaitUntilElementVisible(By.XPath("//*[@id=\"content\"]/div
[2]/div/div/div/div[4]/a")).SafeClick();
 Ожидание появления сообщения с совпадающим временем отправки и
последующее нажатие на него
WebDriver.Chrome.RefreshUntil(_ => _.FindElements(By.ClassName("advice-
datetime")).Any(a => a.Text.Equals(time.ToString("dd.MM.yyyy HH:mm"))));
WebDriver.Chrome.FindElements(By.ClassName("advice-datetime")).First(_ =>
_.Text.Equals(time.ToString("dd.MM.yyyy HH:mm"))).SafeClick();
 Создание уникального сообщения для отправки дополнительного
сообщения
Guid guid = Guid.N
 Отправка дополнительного сообщения
WebDriver.Chrome.WaitUntilElementVisible(By.XPath("//*[@id=\"content\"]/div
[2]/div/ng-include/ng-
include/div/div[2]/form/div/div[1]/div[1]/textarea")).SendKeys(guid.ToString());
WebDriver.Chrome.WaitUntilElementVisible(By.XPath("//*[@id=\"content\"]/div
[2]/div/ng-include/ng-
include/div/div[2]/form/div/div[1]/div[1]/textarea")).Submit();
 Ожидание отображения отправленного сообщения в окне переписки
WebDriver.Chrome.WaitUntilElementVisible(By.ClassName("event-text"));
 Проверка совпадения текста сообщения с отправленным ранее
Assert.IsTrue(WebDriver.Chrome.FindElements(By.ClassName("event-
text")).Any(_ => _.Text == guid.ToString()), "No message recieved");}

Тест, который проверяет функцию поиска на странице техподдержки.


 Переход на страницу «Лента уведомлений», вкладка «Техподдержка»
WebDriver.Chrome.NavigateToUrl("http://lk- dev.test.gosuslugi.ru/notifications?
type=FEEDBACK");
 Ввод определенного текста в поле фильтрации сообщений
40
string searchText = "отзыв";
WebDriver.Chrome.WaitUntilElementVisible(By.XPath("//*[@id=\"content\"]/div
[2]/div/ng-include/div/fieldset/ul/li[1]/dl[2]/dd/input")).SendKeys(searchText);
 Ожидание пока все отсортированные сообщения не будут содержать
введенный в фильтр текст
WebDriver.Chrome.WaitUntil(_ =>
_.FindElements(By.ClassName("highlighted")).All(a => a.Text == searchText));}

Тест, который проверяет работоспособность всех вкладок Личного


кабинета
 Переход на страницу «Лента уведомлений», вкладка «Все»
WebDriver.Chrome.NavigateToUrl("http://lk-dev.test.gosuslugi.ru/notifications?
type=all");
WebDriver.Chrome.WaitUntilElementExists(By.ClassName("advice-item"));
 Поочередный переход на все вкладки на странице «Лента
уведомлений»
WebDriver.Chrome.NavigateToUrl("http://lk-dev.test.gosuslugi.ru/notifications?
type=PAYMENT");
WebDriver.Chrome.WaitUntilElementExists(By.ClassName("advice-item"));
WebDriver.Chrome.NavigateToUrl("http://lk-dev.test.gosuslugi.ru/notifications?
type=ORDER");
WebDriver.Chrome.WaitUntilElementExists(By.ClassName("advice-item"));
WebDriver.Chrome.NavigateToUrl("http://lk-dev.test.gosuslugi.ru/notifications?
type=DRAFT");
WebDriver.Chrome.WaitUntilElementExists(By.ClassName("advice-item"));
WebDriver.Chrome.NavigateToUrl("http://lk-dev.test.gosuslugi.ru/notifications?
type=FEEDBACK");
WebDriver.Chrome.WaitUntilElementExists(By.ClassName("advice-item"));");
 Переход на вкладку «Все» и ввод в поле фильтрации определенного
текста

41
WebDriver.Chrome.NavigateToUrl("http://lk-dev.test.gosuslugi.ru/notifications?
type=all
WebDriver.Chrome.WaitUntilElementVisible(By.XPath("//*[@id=\"content\"]/div
[2]/div/ng-include/div/fieldset/ul/li/dl[2]/dd/input")).SendKeys("35");
 Ожидание появления результатов фильтрации
WebDriver.Chrome.WaitUntilElementExists(By.ClassName("advice-item"));
 Проверка правильности фильтрации сообщений
Assert.IsTrue(WebDriver.Chrome.FindElements(By.ClassName("highlighted")).A
ll(_ => _.Text == "35"));
 Очистка поля фильтрации
WebDriver.Chrome.WaitUntilElementVisible(By.XPath("//*[@id=\"content\"]/div
[2]/div/ng-include/div/fieldset/ul/li/dl[2]/dd/input")).Clear();
 Фильтрация сообщений по дате
WebDriver.Chrome.WaitUntilElementVisible(By.XPath("//*[@id=\"_epgu_el1\"]/
div[1]")).SafeClick();
WebDriver.Chrome.WaitUntilElementVisible(By.XPath("//*[@id=\"content\"]/div
[2]/div/ng-include/div/fieldset/ul/li/dl[1]/dd/div/div[2]/ul/li[5]")).SafeClick();
WebDriver.Chrome.WaitUntilElementExists(By.ClassName("advice-datetime"));
 Проверка соответствия даты на всех элементах с датой фильтрации
Assert.IsTrue(WebDriver.Chrome.FindElements(By.ClassName("advice-
datetime")).All(_ => (DateTime.Now - DateTime.Parse(_.Text)).Duration().Days
== 0));
После того как были автоматизированы несколько тестов, описанных
выше, можно сделать вывод о целесообразности автоматизации в контексте
компании РТ Лабс.
Разработка автоматизированных тестов состояла из двух этапов:
разработка промежуточного слоя между фреймворком для тестирования и
самими авто тестами, и разработка автоматизированных тестов. На первый
этап ушло около 16 часов рабочего времени, а на второй около 8. При этом
было разработано 2 масштабных теста.
При расчете затрат на автоматизированное тестирование по данной
формуле

42
Используя вышеописанные формулы можно рассчитать величину
вложений, нужных для реализации автоматизированного и ручного
тестирований.
Для автоматизированного тестирования необходимы затраты в 22 122
рублей.
Для ручного тестирования - 43 269 рублей.
Таким образом, автоматизировав всего 2 теста, была получена выгода
почти в два раза, при этом, можно ожидать, что последующая автоматизация
тестирования приведет к еще большей разнице в эффективности, поскольку
этап разработки промежуточного слоя уже пройден (хотя, однозначно по
нему потребуются доработки при использовании в реальной компании).
Такая большая разница в эффективности очень показательна, однако
нужно понимать, что в зависимости от конкретного проекта и
рассматриваемого типа тестирования улучшение эффективности за счет
автоматизации может меняться, и в ряде случаев автоматизация может
оказаться нецелесообразной.

43
Заключение

Сегодня тестирование является неотъемлемой частью процесса


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

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

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

1. Джек Фолк, Сэм Канер, Енг. Кек Нгуен. Тестирование программного


обеспечения. Издательство ДиаСофт, 2001.
2. Савин Роман. Тестирование DOT COM. Издательство Дело, 2007.
3. Виды Тестирования [Электронный ресурс]/ Про Тестинг - Тестирование
Программного Обеспечения. URL:
http://www.protesting.ru/testing/types/sanity.html
4. Certifying Software Testers Worldwide [Электронный ресурс]/ URL:
http://www.istqb.org/
5. Александр Хрущев. Эффективность использования автоматических
тестов в ИТ-проектах. Доклад на конференции CEE-SECR 2009, октябрь
2009.
6. Оценка эффективности автоматизации тестирования [Электронный
ресурс]/ Технологии качества. URL: http://a1qa.ru/blog/otsenka-
effektivnosti-avtomatizatsii-testirovaniya/
7. Гребенюк В. М. Oценка целесообразности внедрения
автоматизированного тестирования. Институт Государственного
управления, права и инновационных технологий (ИГУПИТ). Интернет-
журнал «НАУКОВЕДЕНИЕ» №1 2013
8. Джефф Рэшка, Элфрид Дастин, Джон Пол. Автоматизированное
тестирование программного обеспечения. Внедрение, управление,
эксплуатация. Издательство Лори, 2012.
9. Ron Patton. Software Testing. 2005.
10. Винниченко И.В. Автоматизация процессов тестирования. Издательство
Питер, 2005.
11. Рекс Блек. Ключевые процессы тестирования - М.: Издательство Лори,
2014. – 544 с.
12. Сертификация программного обеспечения (ПО) [Электронный ресурс]/
Национальная сертификационная палата. URL:
http://www.nspru.ru/sertsoftware/
13. Автоматизированное тестирование [Электронный ресурс]/ GitHub. URL:
https://gist.github.com/codedokode/a455bde7d0748c0a351a
14. Основные положения тестирования [Электронный ресурс]/ Интересные
публикации / Хабрахабр. URL: https://habrahabr.ru/post/110307/
15. Что такое Конфигурационное тестирование [Электронный ресурс]/
software-testing. URL: http://software-testing.org/testing/chto-takoe-
konfiguracionnoe-testirovanie-configuration-testing.html
46
16. Автоматизация тестирования [Электронный ресурс]/ Перфоманс Лаб.
URL: http://www.performance-lab.ru/avtomatizacija-testirovanija

47
Приложение

Приложение 1. Исходный код решения по автоматизации тестов.

using OpenQA.Selenium;
using OpenQA.Selenium.Chrome;
using OpenQA.Selenium.Support.UI;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace UnitTestProject {
public static class WebDriver {
public static event Action<IWebDriver> OnDocumentReady;

public static IWebDriver Chrome {


get
{
if (ChromeInstance == null) {
ChromeInstance = new ChromeDriver(@"..\..\Drivers\");
ChromeInstance.Manage().Window.Maximize();
}
return ChromeInstance;
}
}
private static IWebDriver ChromeInstance;

public static void WaitUntil(this IWebDriver driver, Func<IWebDriver, bool> condition, int
timeout = 15) {
var webDriverWait = new WebDriverWait(driver, new TimeSpan(0, 0, timeout));
webDriverWait.Until(condition);
}

public static IWebElement WaitUntilElementVisible(this IWebDriver driver, By path, int


timeout = 15) {
var webDriverWait = new WebDriverWait(driver, new TimeSpan(0, 0, timeout));
return
webDriverWait.Until<IWebElement>(ExpectedConditions.ElementIsVisible(path));
}

public static IWebElement WaitUntilElementExists(this IWebDriver driver, By path, int


timeout = 15) {
var webDriverWait = new WebDriverWait(driver, new TimeSpan(0, 0, timeout));
48
return webDriverWait.Until<IWebElement>(ExpectedConditions.ElementExists(path));
}

public static void WaitUntilDocumentReady(this IWebDriver driver, int timeout = 15) {


var webDriverWait = new WebDriverWait(driver, new TimeSpan(0, 0, timeout));
webDriverWait.Until(_ => _.DocumentReady());
if (OnDocumentReady != null)
OnDocumentReady(driver);
}

public static void RefreshUntil(this IWebDriver driver, Func<IWebDriver, bool> condition,


int timeout = 15) {
while (!condition(driver)) {
driver.Refresh();
driver.WaitUntilDocumentReady();
}
}

public static bool DocumentReady(this IWebDriver driver) {


return ((IJavaScriptExecutor)driver).ExecuteScript("return
document.readyState").Equals("complete");
}

public static void NavigateToUrl(this IWebDriver driver, string url) {


driver.Navigate().GoToUrl(url);
}

public static void Refresh(this IWebDriver driver) {


driver.Navigate().Refresh();
}

public static void SafeClick(this IWebElement element) {


Application.DisableTopBar(Chrome);
element.Click();
}
}
}

using OpenQA.Selenium;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using Newtonsoft.Json.Linq;

49
using OpenQA.Selenium.Support.UI;

namespace UnitTestProject {
public static class Application {

public static void RequiresAuthentication() {


if (!IsAuthenticated())
Authenticate();
}

public static void DisableTopBar(IWebDriver driver) {


driver.WaitUntilElementVisible(By.CssSelector("body>iframe"));
((IJavaScriptExecutor)WebDriver.Chrome).ExecuteScript(
"var bar = document.querySelector(\"body>iframe\");" +
"bar.style.pointerEvents = \"none\";"
);
}

public static void EnableTopBar() {


WebDriver.Chrome.WaitUntilElementVisible(By.CssSelector("body>iframe"));
((IJavaScriptExecutor)WebDriver.Chrome).ExecuteScript(
"var bar = document.querySelector(\"body>iframe\");" +
"bar.style.pointerEvents = \"auto\";"
);
}

private static void Authenticate() {


WebDriver.Chrome.NavigateToUrl("http://beta-dev.test.gosuslugi.ru/");
WebDriver.Chrome.NavigateToUrl("http://beta-dev.test.gosuslugi.ru/auth/esia/?
redirectPage=/");
WebDriver.Chrome.WaitUntilDocumentReady();

WebDriver.Chrome.FindElement(By.CssSelector("#mobileOrEmail")).SendKeys("fedora@mail
forspam.com");

WebDriver.Chrome.FindElement(By.CssSelector("#password")).SendKeys("1234567890");
WebDriver.Chrome.FindElement(By.CssSelector("#authnFrm>div.content-box.login-
slils-box>div.data-form.flt-lbl-form>div.line-btns>button")).Click();
WebDriver.Chrome.WaitUntilDocumentReady();
}

private static bool IsAuthenticated() {


var currentUrl = WebDriver.Chrome.Url;
WebDriver.Chrome.NavigateToUrl("http://beta-dev.test.gosuslugi.ru/user");
WebDriver.Chrome.WaitUntilDocumentReady();

50
var user =
JObject.Parse(WebDriver.Chrome.FindElement(By.CssSelector("body>pre")).Text);
var result = user["error"].Value<int>("errorCode") == 0;
if (result) {
WebDriver.Chrome.NavigateToUrl(currentUrl);
WebDriver.Chrome.WaitUntilDocumentReady();
}
return result;
}
}
}

using System;
using System.Linq;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using OpenQA.Selenium;
using OpenQA.Selenium.Chrome;
using OpenQA.Selenium.Support.UI;

namespace UnitTestProject {

[TestClass]
public class AcctountTests {

[TestMethod]
public void Account_Support() {
Application.RequiresAuthentication();

// Переход на страницу техподдержки


WebDriver.Chrome.NavigateToUrl("http://lk-dev.test.gosuslugi.ru/notifications?
type=FEEDBACK");

// Переход на форму обратной связи


WebDriver.Chrome.WaitUntilElementVisible(By.CssSelector("#content>div.ng-
scope>div>ng-include>div>fieldset>ul>li.feedback-button.ng-scope>a")).SafeClick();

// Заполнение формы
WebDriver.Chrome.WaitUntilElementVisible(By.Id("_epgu_el2")).SafeClick();

WebDriver.Chrome.WaitUntilElementVisible(By.XPath("//*[@id=\"feedbackForm\"]/div/div/di
v/div[2]/ul/li[4]")).SafeClick();

WebDriver.Chrome.WaitUntilElementVisible(By.XPath("//*[@id=\"feedbackForm\"]/div/div/ng
-include/epgu-input[1]/div/textarea")).SendKeys("TEST");

51
WebDriver.Chrome.WaitUntilElementVisible(By.XPath("//*[@id=\"feedbackForm\"]/div/div/ng
-include/epgu-input[1]/div/textarea")).Submit();

// Фиксируем время отправки формы


DateTime time = DateTime.Now;

// Возврат на страницу техподдержки

WebDriver.Chrome.WaitUntilElementVisible(By.XPath("//*[@id=\"content\"]/div[2]/div/div/di
v/div[4]/a")).SafeClick();

WebDriver.Chrome.RefreshUntil(_ => _.FindElements(By.ClassName("advice-


datetime")).Any(a => a.Text.Equals(time.ToString("dd.MM.yyyy HH:mm"))));
WebDriver.Chrome.FindElements(By.ClassName("advice-
datetime")).First(_=>_.Text.Equals(time.ToString("dd.MM.yyyy HH:mm"))).SafeClick();

Guid guid = Guid.NewGuid();

WebDriver.Chrome.WaitUntilElementVisible(By.XPath("//*[@id=\"content\"]/div[2]/div/ng-
include/ng-include/div/div[2]/form/div/div[1]/div[1]/textarea")).SendKeys(guid.ToString());

WebDriver.Chrome.WaitUntilElementVisible(By.XPath("//*[@id=\"content\"]/div[2]/div/ng-
include/ng-include/div/div[2]/form/div/div[1]/div[1]/textarea")).Submit();

WebDriver.Chrome.WaitUntilElementVisible(By.ClassName("event-text"));
Assert.IsTrue(WebDriver.Chrome.FindElements(By.ClassName("event-text")).Any(_ =>
_.Text == guid.ToString()), "No message recieved");
}

[TestMethod]
public void Account_Support_Search() {
Application.RequiresAuthentication();
WebDriver.Chrome.NavigateToUrl("http://lk-dev.test.gosuslugi.ru/notifications?
type=FEEDBACK");
string searchText = "отзыв";

WebDriver.Chrome.WaitUntilElementVisible(By.XPath("//*[@id=\"content\"]/div[2]/div/ng-
include/div/fieldset/ul/li[1]/dl[2]/dd/input")).SendKeys(searchText);
WebDriver.Chrome.WaitUntil(_ => _.FindElements(By.ClassName("highlighted")).All(a
=> a.Text == searchText));
}
}
}

52