32
• Проверки, требующие сверки больших объемов данных или
сложных математических операций
• Проверки, в которых присутствуют длительные по времени
тесты
Существует несколько подходов к АТ, которые выполняются на
уровне пользовательского интерфейса:
RecordPlayback (Запись и воспроизведение). Основан на записи и
последующем воспроизведении действий пользователя. Пользователю
необходимо запустить одно из средств автоматизации, а тестовые скрипты
будут созданы на основе его взаимодействия с тестируемым приложением.
Инструмент автоматизации запоминает все действия, производимые
тестировщиком, как эталонные. Затем средство автоматизации генерирует
скрипт, описывающий действия пользователя на одном из языков
программирования.
Тестирование заключается в воспроизведении записанных действий –
выполнении сгенерированного кода и сравнении результатов выполнения
теста с эталонными.
К недостаткам подхода можно отнести проблему актуализации набора
тестов, то есть при изменении функциональности программы тесты
необходимо перезаписывать заново. Так же данные тесты обладают
невысокой надежностью, так как не учитывают внештатные ситуации,
например, всплывающие окна.
Scripting (Написание сценария). Подход, при котором тестовые
скрипты создаются на языках, специально разработанных для автоматизация
тестирования ПО. В данном подходе разработкой скриптов занимаются
33
программисты высокого уровня, которые работают отдельно от
тестировщиков, непосредственно запускающих тесты.
К недостаткам можно отнести то, что при незначительном изменении в
ПО требуются сложные изменения в созданных скриптах, и поддержка
библиотеки тестирующих скриптов становится непреодолимой задачей.
Data Driven Testing (DDT, Тестирование управляемое данными).
Подход, при котором к некоторому набору тестов привязывается источник
тестовых данных, которые хранятся отдельно от скриптов, например, в
документе Excel, и этот набор тестов выполняется для каждой записи из
этого источника. Данный подход основывается на проверке ПО на различных
данных, хранимых в отдельном источнике. Использование независимого
инструмента для обработки данных делает тесты простыми в обслуживании
и дает возможность использовать их повторно. Если будут добавлены новые
тестовые сценарии, то источник может быть легко обновлен с новыми
данными без каких-либо изменений в коде существующих тестов. К
недостаткам можно отнести то, что требуется высокий уровень навыков,
кроме того оператору может потребоваться изучить скриптовый язык
программирования, изучение нового инструмента требует времени, а также,
что необходимо большое количество документации, относящейся к
управлению скриптами, тестовой инфраструктуре и результатам тестов.
KeywordDriven (Тестирование по ключевым словам). Основан на
визуальном представлении тестовых скриптов, когда каждому действию
пользователя, например, клик мышью или нажатие клавиш на клавиатуре,
ставятся в соответствие ключевые слова (keywords).
Данный подход связан с подходом RecordPlayback, потому что
наиболее простой способ создания Keyword Driven тестов – это их запись.
Подход позволяет повторно использовать тесты, так как большинство
34
действий и их ключевых слов подходят не только для использования в
пределах одного приложения, но могут использоваться для других
приложений, скрипты легко читаются.
К недостаткам можно отнести то, что разработка перевода ключевых
слов в действия может занять большое количество времени, также
потребуется большее количество документации для описания особенной
работы приложения, в частности для описания ключевых слов, которые
могут использоваться.
Условно, автоматизацию тестирования можно разбить на 3 уровня. [29]
Модульное тестирование (unit tests) – под авто-тестами на этом уровне
подразумеваются тести написанные самими разработчиками, направленные
на тестирование отдельных компонентов или модулей системы. Поиск
дефектов производиться на уровне классов, методов, функций. Один из
наиболее эффективных подходов к модульному тестированию - это
подготовка авто-тестов до начала основного этапа разработки программного
продукта. Такой подход называется разработка через тестирование (test-
driven development) или подход тестирования вначале (test first approach). При
использовании данного подхода создаются небольшие куски программного
кода, против которых запускаются тесты, написанные до начала
кодирования. Разработка ведется до тех пор пока все тесты не будут успешно
пройдены.
Тестирование через пользовательский интерфейс (GUI tests) – данный
уровень позволяет тестировать функциональность и пользовательский
интерфейс, выполняя операции вызывающие какие-либо действия
приложения, согласно его бизнес логике. Данный уровень тестирования
наиболее полно эмулирует будущие действия пользователя программного
обеспечения.
35
Функциональное тестирование (functional tests, API tests) – существует
множество программных продуктов, бизнес логика которых спрятана от
обычного пользователя, но которую критически важно протестировать. В
таком случае, для тестировщиков может быть реализован доступ к
функциональному слою, минуя пользовательский интерфейс.
В современном мире существует большое количество средств, которые
позволяют автоматизировать процесс тестирования программного продукта.
Но следует понимать, что не во всех случаях автоматизация тестирования
пойдет на пользу деятельности компании. Может оказаться так, что
деятельность по разработке и сопровождения автоматических тестов,
окажется намного дороже, чем деятельность ручных тестировщиков. [24]
Рисунок 4 – Стандартное соотношение авто-тестов согласно пирамиде
тестирования
36
Чтобы оценить целесообразность автоматизации тестирования, следует
принять во внимание несколько факторов:
- длительность проекта по времени.
- количество рутинных операций при тестировании продукта.
- оценить количество тестов, которые необходимо автоматизировать.
- оценить, как часто будет происходить выполнение
автоматизированных тестов.
Отдельно стоит рассмотреть цели автоматизации тестирования.
Основные задачи, которые решаются внедрением автоматизированного
тестирования - это снижение времени, нужного для тестирования и
повышение качества тестирования. Под снижением времени понимается, что
в единицу времени, возможно выполнение большего количество
автоматических тестов, и это число не зависит от количества тестировщиком
на проекте. Под повышением качества подразумевается, увеличение площади
покрытия, а также возможность выполнения тест-кейсов которые не
возможно выполнить ручным тестировщиком.
Из вышесказанного можно вывести определенные плюс и минусы
автоматизированного тестирования. [31]
К плюсам, стоит отнести:
• Повторяемость – авто-тесты всегда будет выполняться в точности
по одному и тому же сценарию. Фактически, в таких тестах
исключен «человеческий фактор».
• Снижение стоимость итерации тестирования.
37
• Скорость выполнения тестов – скорость выполнения авто-тестов
не зависит от «человеческого фактора» и количества
тестировщиков на проекте.
• Набор тестов ограничивается только лишь производительностью
системы, а не доступным количеством тестировщиков.
• Отчетность – единообразная отчетность, которая создается
программным обеспечением сразу же или ещё во время
прохождения тестов.
• Независимость от временных рамок – тесты могут выполняться в
любое время суток, быть любой продолжительность по времени.
• Реализация тестов невозможных для выполнения ручными
тестировщиками
К минусам, стоит отнести:
• Однообразие тестов – созданные тесты будут повторяться все
время однообразно. Данный момент является как плюсом, так и
минусом. Тестировщик в процессе выполнения теста может
обратить на какой-либо момент, упущенный ранее и найти
упущенную ранее ошибку.
• Плохо спроектированные тесты будут вызывать ложные
срабатывания и выдавать нестабильные результаты.
• Увеличенные затраты на разработку авто-тестов – разработка
авто-тестов требует более высокой квалификации от
тестировщика, что выливается в увеличенные затраты для
компании.
• Затраты на поддержку созданных авто-тестов – затраты на
поддержку увеличиваются тем более, чем чаще происходит
38
изменения тестируемого продукта. Данный момент стоит
учитывать при анализе целесообразности автоматизации
тестирования.
• Пропуск ошибок – авто-тест может легко пропустить дефект на
поиск которого он не был запрограммирован.
• Сложность анализа эффективности автоматического
тестирования.
• Не все тесты возможно автоматизировать.
Для удобства разработки, чтения и последующей поддержки авто-
тестов, структура тест скриптов должна быть по максимуму консистентна
структура ручного тестового случая - Precondition, Steps, Post Condition.
Рассмотрим подробнее структура тест скрипта:
- Precondition содержит в себе инициализацию приложения (как
пример, открытие страницы логина, вход под тестовым пользователем,
переход в необходимую часть приложения и подведение системы к
состоянию пригодному для тестирования). Также в этом блоке происходит
инициализация тестовых данных.
- Steps содержит в себе непосредственно тело теста. В этом же блоке
происходит занесение данных о результате теста, с обязательным
сохранением всех шагов, по которым проходил тест, и причин провала, если
они есть.
- Post Condition содержит в себе блок удаления, созданных в процессе
выполнения скрипта, ненужных тестовых данных и блок корректного
завершения работы приложения
В данном параграфе рассмотрены причины побуждающие внедрять
автоматизацию, основы автоматизации тестирования, плюс и минусы
39
автоматизации тестирования программного обеспечения. Можно сделать
вывод, что перед внедрением автоматизации тестирования требуется
произвести глубокий анализ тестовой библиотеки, тестируемого продукта и
финансовых возможностей заказчика, для выяснения целесообразности
внедрения автоматизации.
2.2 Критерии эффективности процесса автоматизированного
тестирования
Эффективность - это способность выполнять работу и достигать
необходимого и желаемого результата с наименьшей затратой времени и
усилий.
Процесс тестирования должен быть эффективен в первую очередь с
точки зрения компании, в которой он протекает. Относительно
автоматизации тестирования компанию могут заинтересовать следующие
параметры процесса тестирования:
- Время, необходимое для разработки авто-тестов
- Время, которое занимает один цикл тестирования
- Уровень навыков персонала, необходимый для разработки и
поддержания в работоспособном состоянии авто-тестов.
Изменением какого-либо из этих параметров, компания может менять
качество тестирования и финансовые затраты на него. Каждая компания
старается найти баланс между этими параметрами, для того чтобы
достигнуть оптимального уровня качества программного продукта, при
минимальных финансовых затратах. Следует заметить, что во время
автоматизации процесса тестирования измениться баланс этих параметров.
При полностью ручном тестирования временные затраты на процесс
40
тестирования достаточно большие, но при этом требуемая квалификация
тестировщиков относительно низкая. Однако уже при старте внедрения
автоматизации тестирования параметр требуемой квалификации возрастет,
также как и параметр времени необходимого для создания одного теста, но
при этом время выполнения одного теста, станет снижаться. [42]
Для того чтобы иметь возможность оценить эффективность внедрения
автоматизации тестирования имеет смысл зафиксировать показатель качества
программного продукта на каком-либо определенном уровне. Таким образом
численной оценкой эффективности станет являться величина инвестиций,
необходимых для обеспечения должного уровня качества программного
продукта.
Оценку целесообразности автоматизации процесса тестирования
возможно провести при помощи подсчета и сравнения финансовых затрат на
ручное и автоматизированное тестирование. Одной из главных проблем
данного подхода станет то, что автоматизация тестирования зависит от
параметров, которые на начальном этапе могут быть понятны лишь
примерно. Как пример, точное количество тестов, длинна жизненного цикла
ПО и т.п.
Следующая формула может быть использована для расчёта
инвестиций, необходимых для внедрения и эксплуатации
автоматизированных тестов за выделенный период (Ip) [41]:
Рисунок 5 – Формула расчета необходимых инвестиций для
автоматизации процесса тестирования
41
I0 – стартовые инвестиции, в которые входит покупка необходимого
оборудования, ПО и т.п.
C0 – стоимость разработки и отладки первоначальной библиотеки
авто-тестов, которая высчитывается как произведение времени,
необходимого для создания одного автоматизированного теста одним
тестировщиком (в часах), помноженное на стоимость его рабочего часа и на
общее количество тестов, которые предстоит автоматизировать.
k – общее количество планируемых тестовых циклов.
Ce – стоимость одного тестового цикла, которое рассчитывается как
среднее время подготовки к выполнению и непосредственно время
выполнения одного теста одним тестировщиком (в часах), помноженное на
стоимость его рабочего часа и на общее количество тестов. Ce может иметь
значение 0, когда возможно полностью автономное выполнение тестов, не
требующее вмешательства человека ни на стадии подготовки к выполнению
теста, ни во время исполнения теста.
Ca – цена анализа результатов одного тестового цикла, которая
рассчитывается как ожидаемый процент неудачных тестов, помноженный на
общее количество тестов, среднее время, требуемое на анализ причин
неудачного выполнения одного теста одним тестировщиком (в часах), и на
стоимость его рабочего часа.
Cm – цена поддержания авто-тестов в актуальном состоянии,
высчитывается как произведение ожидаемого коэффициента изменений
тестов для каждого цикла выполнения, времени, потраченного одним
тестировщиком на изменение одного скрипта (в часах), общего количества
скриптов и стоимости рабочего часа тестировщика. Данная переменная