Что такое регрессионное тестирование - LMS

Правительство Российской Федерации
Федеральное государственное автономное образовательное учреждение
высшего профессионального образования
Национальный исследовательский университет
«Высшая школа экономики»
Факультет информатики, математики и компьютерных наук
Кафедра прикладной математики и информатики
Стеклова Галина Сергеевна
Автоматизация регрессионного тестирования
Выпускная квалификационная работа по направлению
01.03.02 «Прикладная математика и информатика»
студента группы № 11ПМИ
Рецензент
Научный руководитель
к.э.н., доцент кафедры МЕРА
преподаватель кафедры ПМИ
Егоров Е. Е.
Пономаренко А. А.
Нижний Новгород
2015
Оглавление
Введение .........................................................................................................................................3
Тестирование программного обеспечения ..............................................................................3
Что такое регрессионное тестирование ...................................................................................4
Автоматизированное тестирование .........................................................................................5
Постановка задачи .........................................................................................................................6
Практическая часть .......................................................................................................................7
Ход работы .................................................................................................................................7
Структура приложения ..............................................................................................................9
Процесс регрессионного тестирования .................................................................................10
Ограничение ресурсов .........................................................................................................10
Ручное регрессионное тестирование проверки соответствия ..........................................11
Cucumber-инструмент .............................................................................................................14
Общие сведения....................................................................................................................14
История Cucumber ................................................................................................................15
Структура Cucumber ............................................................................................................16
Конфигурирование Cucumber .............................................................................................18
Файл с расширением .feаture ...............................................................................................19
Файл с расширением .rb.......................................................................................................20
Файл конфигурации .............................................................................................................21
Настраиваемые аргументы инструмента Cucumber..........................................................22
Алгоритм работы Cucumber по определению статуса теста ............................................24
Пояснение статусов тестов ..................................................................................................25
Инструкция по использования тестового сценария .............................................................27
Анализ полученных результатов ............................................................................................28
Применяемые метрики ........................................................................................................28
Количественный анализ.......................................................................................................30
Качественный анализ ...........................................................................................................33
Заключение...................................................................................................................................38
Список литературы ......................................................................................................................40
Приложение..................................................................................................................................42
Сценарий .rb файл (Приложение 1)........................................................................................42
Instruction for Performing of Automotive Regression Testing (Приложение 2) .....................44
2
Введение
Тестирование программного обеспечения
Тестирование программного обеспечения является неотъемлемой
частью процесса создания программного продукта. При применении любой
модели разработки программного обеспечения роль тестирования трудно
переоценить. Особенно высока значимость верификации продукта при
использовании
итеративной
методологии
разработки
программного
обеспечения (ПО), которая включает в себя все этапы жизненного цикла,
вплоть
до
внедрения
разрабатываемого
ПО
и
получения
реакции
пользователей.
Некачественное
тестирование
может
спровоцировать
резко
отрицательные отзывы о продукте и впоследствии сформировать негативное
впечатление от его использования.
Понимание
важности
процесса
тестирования
приводит
к
возникновению тенденций, направленных на применение промышленных
способов проверки качества программного обеспечения. Наиболее важным
направлением
здесь
является
внедрение
различных
систем
автоматизированного тестирования.
Автоматические тесты давно стали не инновацией, а в некотором роде
стандартом
при
разработке
корпоративного
ПО.
Их
использование
обеспечивает более высокое качество кода и, соответственно, программного
обеспечения в целом, помогая заметно повысить надежность системы.
3
Что такое регрессионное тестирование
Появление
первых
компьютеров
отразилось
на
программном
обеспечении. Программирование, в частности, невозможно без различного
рода ошибок, совершенных под влиянием человеческого или других
немаловажных факторов. Если процесс отладки программного продукта не
был значительной проблемой еще два десятилетия назад в виду его
примитивности, то сейчас ПО – это сложнейшая система, которая постоянно
подвергается изменениям. Несмотря на то, что изначально программа
отвечает большинству заявленным в спецификации требованиям, имеют
место модификации, внесенные в работу продукта для корректировки
обнаруженных дефектов на этапе его тестирования. В результате, такие
изменения могут привести к регрессии функциональной части приложения.
Таким образом, постоянное тестирование необходимо для того, чтобы
поддерживать высокий уровень качества ПО.
Регрессионное тестирование является исключительно ресурсоемкой и
дорогой (в рамках бизнес-проекта) деятельностью. Причина заключается в
том, что регрессионное тестирование должно быть выполнено даже после
незначительных изменений в коде программы. Таким образом, количество
выполняемых тестов постоянно растет.
4
Автоматизированное тестирование
Автоматизированное тестирование программного обеспечения – один
из
вариантов
верификации
продукта
на
стадии
его
разработки.
Автоматизация подразумевает под собой использование определенных
программных средств для выполнения тестов и отслеживания результатов
тестирования, что позволяет значительно упростить процесс тестирования и
сократить время на его проведение.
Как правило, автоматизирование тестирования влияет на весь бизнеспроцесс, является ресурсозатратной деятельностью как в финансовом
отношении, так и в плане временных затрат на разработку тестовых
сценариев с их дальнейшей поддержкой. Однако при внедрении автотестов
есть положительные моменты. Во-первых, исключен человеческий фактор,
поскольку однажды написанный скрипт будет выполняться однообразно.
Таким образом, тестировщик не сможет упустить шаги в тестах и ничего не
напутает в результатах. Во-вторых, предусмотрено хранение результатов
тестирования, что весьма полезно именно для регрессионного тестирования.
В-третьих, автоматические тесты частично выполняются независимо от
человека, т.е. без его вмешательства. Если речь идет о регрессионном
тестировании, которое является лидером по ресурсоемкости, во время
выполнения
тестов
инженер
может
заниматься
какой-либо
другой
немаловажной деятельностью.
Принятие решения о внедрении автоматизации тестирования должно
происходить после анализа всех ее нюансов, достоинств и недостатков.
5
Постановка задачи
В проекте несколько раз в течение жизненного цикла тестируемого
продукта
проводится
ручное
регрессионное
тестирование
такой
функциональности, как проверка соответствия конфигураций их идеальным
состояниям. Эта деятельность постепенно стала отнимать значительное
количество человеческих и временных ресурсов. В то же время, наряду с
регрессионным тестированием, в проекте выполняются и другие виды
тестирования, которые на данный момент уже имеют реализацию в качестве
автоматических
тестов.
Для
выполнения
этой
задачи
используется
инструмент для автоматического тестирования Cucumber.
Передо мной были поставлены задачи применения вышеуказанного
приложения для автоматизации регрессионного тестирования элементов
проверки соответствия в текущем проекте, анализа полученных результатов
и
оценки
целесообразности
перехода
тестирования к автоматическому.
6
от
ручного
регрессионного
Практическая часть
Ход работы
Одной
из
основных
функций
тестируемого
программного
обеспечения является возможность построения конфигураций для настройки
LTE-сетей. Конфигурации могут отличаться своим предназначением,
объемом и глубиной. Для того, чтобы конфигурации отвечали требованиям,
не содержали лишних объектов или, наоборот, включали в себя все
необходимые
элементы,
ПО
предусматривает проверку соответствия
построенных конфигураций их оракулам (эталонам).
Полная проверка соответствия основана на проверке отдельных
элементов, которые отвечают за различные типы и формы конфигураций.
Таких элементов в тестируемом продукте может быть несколько сотен на
одну версию. Каждый элемент имеет определенную постоянную структуру:
название, область применения, содержание сообщений, описание элемента,
шаги для корректировки конфигурации, код для ее построения. При запуске
проверки соответствия на корневом элементе, который в свою очередь также
является
частью
структуры,
происходит
обработка
и
отображение
сообщений, соответствующих данному элементу.
Задача тестировщика в этом случае заключается в максимально
возможном покрытии структуры элемента проверки соответствия, анализе
полученных
результатов,
определении
его
соответствия
ожидаемому
поведению. При этом, в случае регрессионных тестов, нет необходимости в
построении новых или изменении старых конфигураций, происходит
мониторинг текущего состояния программного продукта на возможное
косвенное влияние со стороны введения новых функций или их изменения,
исправления найденных ранее дефектов.
Мониторинг
текущего
состояния
программного
продукта
осуществлялся с помощью монотонных действий со стороны тестировщика с
7
данными
большого
объема,
поэтому
введение
автоматизации
этой
деятельности видится перспективной заменой ручного рутинного труда.
Для
принятия
решения
о
целесообразности
автоматизации
тестирования элементов соответствия в текущем проекте мною были
определены для выполнения следующие действия:
 исследование возможности автоматизации тестирования элементов
проверки соответствия тестируемого программного обеспечения,
 автоматизация
тестирования
элементов
проверки
соответствия
тестируемого программного обеспечения,
 запуск автоматических тестов для кампании элементов проверки
соответствия ранее протестированных вручную,
 сравнение и анализ полученных результатов,
 выводы
по
целесообразности/нецелесообразности
автоматизации
тестирования элементов проверки соответствия.
Тестируемое программное обеспечение было исследовано в течение
нескольких месяцев для написания текущей работы. Как правило,
календарный год – время разработки и тестирования одной версии продукта,
затем продукт уходит к пользователям. За этот период, согласно
итерационной модели разработки ПО, планируется выпуск 20 итераций
тестируемого программного продукта. Каждая итерация в какой-либо мере
отличается
от
предыдущей:
имеет
обновленный
функционал
либо
корректировку дефектов, найденных на предыдущем этапе жизненного
цикла. Порой даже самые незначительные изменения могу повлечь за собой
регрессию. Регрессионные тесты выполняются дважды за версию продукта.
8
Структура приложения
Тестируемый
программный
продукт
работает
с
телекоммуникационными сетями нового поколения. Имеет следующие
функции: конфигурация, настройка, изменение и оптимизация параметров
сетей беспроводного доступа.
Система представляет собой клиент-серверное приложение, схема
работы которого отображена на Рис. 1.
Представление
API
Приложение
данных
Плагины
данные
Клиент
Библиотеки сервера
Сервер приложения
Рис. 1 Схема клиент-серверного приложения
Клиентская часть реализует пользовательский интерфейс, формирует
запросы к серверу и обрабатывает ответы от него. Основой клиентской части
в тестируемом программном продукте является программная платформа
Microsoft Silverlight.
Серверная часть получает запрос от клиента, выполняет операции,
после этого формирует отчет и отправляет его клиенту. В текущем продукте
сервер написан на языке Java. При этом весь функционал ПО, используемые
плагины и библиотеки также находятся на стороне сервера. Основная работа
в процессе автоматического тестирования будет проходить с плагинами при
использовании библиотек сервера.
9
Процесс регрессионного тестирования
Ограничение ресурсов
Прежде, чем приступать к описанию процесса регрессионного
тестирования, следует обратить внимание, на что затрачиваются ресурсы во
время верификации элементов проверки соответствия.
Для
того,
чтобы
выполнить
регрессионное
тестирование,
тестировщику необходимо иметь файл с описанием конфигурации в формате
XML (созданный во время ручного тестирования элемента проверки
соответствия) и отчет с результатами проведения проверки соответствия на
текущей конфигурации. Отчет имеет удобную форму, в которой сообщается
о тестируемых объектах конфигурации и соответствующих им сообщениях
после проведения тестирования. Таким образом, задачей тестировщика
является запуск тестируемого приложения, загрузка файла конфигурации,
запуск
определенного
элемента
проверки
соответствия,
сравнение
полученных результатов с имеющимся отчетом и анализ этих данных.
По стандарту, установленному нашим проектом, на выполнение
ручного регрессионного тестирования одного элемента уделяется 0,5ч/ч
(человеко-час). Максимальное количество членов команды, которое может
быть задействовано в ручном регрессионном тестировании, ограничивается
общим количеством людей в команде, выделяемых для проведения данного
вида тестирования, и для нашего проекта составляет не более 4 человек.
10
Ручное регрессионное тестирование проверки соответствия
В начальной версии 2.0 тестируемого программного продукта не
производилось регрессионное тестирование проверки соответствия, т.к. не
было необходимых файлов с описанием конфигураций, участвующих в
процессе тестирования элементов проверки соответствия, и отчетов ее
выполнения. В течение года члены команды, в зависимости от своей
деятельности, выполняли обычное тестирование элементов проверки
соответствия. На один тест тестировщик, исходя из стандартов проекта,
может потратить 2,5ч/ч.
В следующей версии 2.1 тестируемого программного продукта не
только появились новые элементы проверки соответствия, но и образовалась
база из файлов и отчетов проведенных тестов на проверку соответствия в
предыдущей версии программного обеспечения.
В текущей версии 2.2 тестируемого приложения увеличилось
количество тестов для регрессионного тестирования, и также прибавились
новые элементы, структуры которых будут покрыты тестировщиками в
течение жизненного цикла этой версии.
Таким образом, можно сделать вывод о том, что количество тестов,
участвующих
в
регрессионном
тестировании
элементов
проверки
соответствия, с каждой версией становится все больше и больше, а значит
количество времени, затрачиваемое на данную деятельность, также растет.
Приведенная схема на Рис. 2 отображает, какое количество времени
тратится на тестирование элементов проверки соответствия и их ручное
регрессионное тестирование при идеальных условиях, выполняемое один раз
для различных версий продукта. (Прим.: Как уже было сказано, ручное
регрессионное элементов проверки соответствия выполняется дважды за
жизненный цикл продукта.) Под идеальными условиями подразумевается
трудовая
деятельность
в
течение
11
8
часов
в
день
(нормальная
продолжительность
рабочего
времени
человека1)
с
минимальной
производительностью.
v2.1
v2.0
v2.2
300 new
elements
300 elements
for regression
200 new
elements
500 elements
for regression
100 new
elements
600h=75md
150h=18,75md
400h=50md
250h=31,25md
200h=25md
Рис. 2 Ресурсы, требуемые для ручного регрессионного тестирования
в различных версиях продукта
Как показывает схема, если в версии продукта 2.1 регрессионное
тестирование элементов проверки соответствия занимало не более 37 дней
рабочего времени (md, “man-days”; единица измерения производительности
трудящегося) инженера по тестированию в год, то для версии продукта 2.2
это заняло бы более 60 рабочих дней в год при его обычном выполнении
дважды за версию одним человеком и в три раза меньше в условиях работы
трех членов команды. Несмотря на то, что регрессионное тестирование
является одним из самых важных видов тестирования любого программного
продукта, проект не может позволить себе затрачивать столь значительные
ресурсы. Это также стало одной из причин проявления интереса к
Трудовой кодекс Российской Федерации [Электронный ресурс]: [федеральный закон: от 30.12.2001 г.
№197-ФЗ, в ред. от 28.12.2013 N 421-ФЗ]. – Режим доступа: www.consultant.ru (дата обращения: 21.01.2015).
1
12
автоматизации
регрессионного
тестирования
соответствия.
13
элементов
проверки
Cucumber-инструмент
Общие сведения
В качестве инструмента для автоматизированного регрессионного
тестирования был выбран Cucumber.
Cucumber – приложение, широко используемое для тестирования
программного обеспечения, выполняющее приемочное тестирование в стиле
BDD (Behaviour-Driven Development) процесса. Это означает, что во время
тестирования инструмент фокусируются не на тестах, а на спецификациях
поведения объектов, с которыми он работает; также существует связь кода с
требованиями, которые записываются с помощью обычных фраз, тем самым
рождается специфичный для предметной области язык (DSL) и улучшается
общение с пользователем.
Другими
словами,
позволяет
Cucumber
описывать
ожидаемое
поведение приложения обычным текстом. Текст написан на предметноориентированном языке. Cucumber может работать с Ruby, Jаvа, .NET, Flex, а
также с веб-приложениями, написанными на любом языке.
Cucumber способен автоматически сохранять отчёты в заданном
пользователем формате. Для использования Cucumber как инструмента
тестирования
в
нашем
проекте
потребовалось
специфичные для тестируемого приложения.
14
добавить
функции,
История Cucumber
Cucumber
–
свободно
распространяемое
приложение,
является
переписанным Аслаком Хеллесойем вариантом RSpecStoryRunner Дэна
Норта.
В апреле 2008 Аслак Хеллесой начал развивать проект Cucumber,
чтобы устранить внутренние дефекты дизайна и проблемы удобства
использования проекта RSpecStoryRunner. Затем к проекту присоединились
Джозеф Уилк и Бен Мэбей. После этого, в октябре 2009, к проекту
присоединились Майк Сассак и Грегори Хнатик, создавшие самый быстрый
парсер для Cucumber.
Язык Gherkin, который используется в Cucumber, был создан Дэном
Нортом, Крисом Маттсом, Лиз Ког и Дэвидом Келимски.
На данный момент Cucumber только набирает популярность в качестве
приложения для автоматизированного тестирования.
15
Структура Cucumber
Рис. 3 Структура Cucumber
Тестирование с использование программы Cucumber происходит как с
помощью встроенных функций Cucumber, так и с помощью дополнительных
функций,
которые
были
получены
от
разработчиков
тестируемого
программного продукта.
Также есть 4 внешние составляющие.
Данные – файлы формата XML, описывающие конфигурации для
тестирования элементов проверки соответствия.
Файл конфигурации с указанием путей
к директориям, где
располагаются плагины и библиотеки сервера тестируемого ПО.
Настраиваемые аргументы JVM для корректной работы инструмента
Cucumber на базе используемой машины.
16
Файл CucumberRunner, где описаны пути к внутренним директориям
проекта автоматизации, содержащим .rb и .feature файлы, необходимыми для
выполнения автоматического тестирования.
17
Конфигурирование Cucumber
Для корректного выполнения автоматических тестов Cucumber должен
быть
правильно
настроен.
Настройка
происходит
путём
изменения
следующих файлов (описанных выше):
 файл CucumberRunner.mwe2,
 файл с расширением .feаture,
 файл с расширением .rb,
 файл конфигурации,
 аргументы виртуальной Java-машины (JVM),
а также с помощью добавления необходимых пользовательских файлов в
соответствующие директории.
18
Файл с расширением .feаture
Feature-файл
является
неотъемлемой
частью
Cucumber.
Файл
используется для записи шагов тестирования на понятном для пользователя
языке. Все feature-файлы имеют расширение .feature.
Описанный сценарий впоследствии будет отображаться в html отчете,
который автоматически генерируется инструментом для тестирования:
Given I have an <consElementId> specified
When I load version <conf> with <model>
Then I run all elements on the <confElementId> with <fix>
Then I can receive a <severity> and <nbMsg> MESAND <nbAutoMsg>
describe in <msg1> MESAND <msg2> MESAND <msg3> MESAND <msg4>
MESAND <auMsg1> MESAND <auMsg2>
Затем должны быть указаны необходимые атрибуты:
| conf | model | confElementId | consElementId | severity | nbMsg | msg1 | msg2 |
msg3 | msg4 | nbAutoMsg | auMsg1 | auMsg2 |
19
Файл с расширением .rb
Файл с расширением .rb также является одним из основных файлов для
тестирования с помощью инструмента Cucumber. Он представляет собой
пошаговое описание сценария тестирования на языке Ruby.
Одному .rb файлу может соответствовать несколько .feature файлов, в
то время как одному .feature файлу может соответствовать только один .rb
файл. Именно первая особенность подходит для реализации автоматического
регрессионного тестирования элементов проверки соответствия, поскольку,
как правило, количество feature-файлов равно либо больше, чем самих
элементов проверки соответствия.
Пример:
When /^I load version (.*) with (.*)$/ do | conf, model|
@confpath = "data/dir/confs/" + conf
@conf = Cucumber::Conf.new(@consElementSession.getServiceDirectory())
@conf.openConf(@confpath)
end
20
Файл конфигурации
В файле конфигурации указывается путь к библиотекам и плагинам
тестируемого приложения.
Пример:
<JаrDirectory> C:\Program Files\program\jars</JаrDirectory>
<PluginDirectory> C:\Program Files\program\plugins</PluginDirectory>
21
Настраиваемые аргументы инструмента Cucumber
Файл
аргументы
CucumberRunner.mwe2
для
настройки
и
содержит
корректной
специализированные
работы
инструмента
для
тестирования Cucmber. Обязательной частью данной файла является наличие
указанных путей к директориям проекта, где располагаются .feature и .rb
файлы. Кроме того, очень часто в нем указываются настройки для
виртуальной
Java-машины,
на
которой
запускается
Cucumber.
Для
корректных результатов значения аргументов JVM Cucumber’a должны
точно соответствовать настройкам JVM приложения.
Также тут указываются значения других необходимых аргументов.
Наиболее часто используемые настраиваемы аргументы JVM – это
Xmx и XX:MаxPermSize.
Xmx{число}m – максимальное количество оперативной памяти,
выделяемой под виртуальную машину Java, в мегабайтах. Вместо {число}
указывается любое требуемое число, исходя из суммарного количества
оперативной памяти на компьютере.
Пример записи: -Xmx1500m
XX:MaxPermSize={число}m
–
количество
памяти
Permanent
Generation (сокр. PermGen), выделяемой под виртуальную машину Java, в
мегабайтах. В этой памяти хранится исполняемый код программы. Если
выдаётся
ошибка
OutOfMemory:PermGenSpace, необходимо
увеличить
выделение PermGen. Вместо {число} указывается любое требуемое число.
Слишком большое число указывать не рекомендуется, так как исполняемый
код занимает немного места, а излишнее выделение PermGen зачастую
приводит к задержкам в работе инструмента для тестирования.
Пример записи: -XX:MaxPermSize=150m
Здесь очень важно найти баланс между установленными значениями
аргументов для JVM и техническими возможностями машины. Слишком
маленькие значения могут сделать процесс тестирования медленным. А
22
слишком большие значения аргументов окажут неблагоприятное влияние на
работу компьютера, поскольку значительное количество оперативной памяти
будет занимать работа инструмента для тестирования.
23
Алгоритм работы Cucumber по определению статуса теста
Выполнение
сценария
Чтение первого
шага
Соответствует ли
шаг сценария
шагу в коде?
Нет
Да
Чтение
следующего шага
Выполнение кода
по текущему
шагу
Есть ли
исключения?
Да
Исключения
ожидаются?
Нет
Да
Есть ли еще шаги
в сценарии?
Да
Нет
Нет
PASSED
FAILED
Pending
Undefined
Scenario
Scenario
Рис. 4 Алгоритм определения статуса теста
24
Пояснение статусов тестов
Во время определения статуса теста Cucumber не просто решает,
насколько удачно выполнился тест, но работает с исключениями в случае
неудачного выполнения тестирования. Если сценарий шаг за шагом не
вызывает никаких исключений, тест однозначно получает статус “PASSED”,
и продолжает свое выполнение. В другом случае тест может иметь статус
“FAILED”, “PENDING SCENARIO” или “UNDEFINED SCENARIO”. Эта
особенность Cucumber, как инструмента для внедрения автоматизации
тестирования
в
проекте,
помогает
тестировщику,
как
разработчику
автоматического сценария, отследить прогресс выполнения тестирования.
PASSED – статус для успешно пройденного теста, при условии что
все шаги сценария в .feature файле соответствуют шагам кода в .rb файле и
были полностью выполнены.
FAILED – статус для неудачно пройденного теста, при условии что
все шаги сценария в .feature файле соответствуют шагам кода в .rb файле и
были полностью выполнены, учитывая отсутствие ожидаемых исключений,
которые могут быть выполнены дальше по коду сценария.
PENDING SCENARIO – статус для теста, для которого определены
шаги как в сценарии – .feature файле, так и в коде – .rb файле, но по ходу
выполнения
были
объявлены
возможные
исключения.
Исключения
необходимы в том случае, когда для дальнейшего выполнения сценария
нужны дополнительные параметры, которые будут получены в другой части
кода, за которую отвечает иной раздел сценария .feature или .rb файла. При
отсутствии объявленных исключений там, где они нужны, выполнение
сценария будет прекращено.
UNDEFINED SCENARIO – статус для теста, который показывает, что
существует несоответствие сценариев, описанных в .feature и .rb файле. Этот
статус полезен для инженера по тестированию во время разработки
25
автоматического сценария, чтобы показать, какие шаги были пропущены в
том или ином файле.
Все статусы, полученные в результате автоматического тестирования,
место в файле с кодом или сценарием, и возможное решение возникшей
проблемы, будут отображены в html-отчете, который будет сгенерирован
программой Cucumber во время выполнения тестирования.
26
Инструкция по использования тестового сценария
В нашем проекте, занимающимся тестированием вышеописанного
программного продукта, используемого для настройки и конфигурации
коммуникационных сетей, для каждого вида тестирования существует
определенная документационная база, подробно описывающая сам процесс
тестирования.
Ручное регрессионное тестирование элементов проверки соответствия
не является исключением: все шаги, которые должен выполнить инженер по
тестированию
для
получения
инструкцией.
Поскольку
результата,
автоматическое
также
строго
регрессионное
закреплены
тестирование
элементов проверки соответствия значительно отличается от ручного по роду
деятельности, было решено создать документ (описывающий техническую
сторону тестирования), который будет помогать тестировщику во время
выполнения тестирования. Поскольку разработанный автоматический скрипт
гипотетически может быть использован глобально внутри межнационального
проекта, язык инструкции – английский. Подробный текст инструкции может
быть найден в Приложении 2.
27
Анализ полученных результатов
Применяемые метрики
Как и любая деятельность прогресс тестирования оценивается
определенными метриками, которые отображают временные, человеческие и
финансовые ресурсы, затраченные на ту или иную активность. Также
метрики показывают производительность одного сотрудника и команды в
целом.
Для анализа полученных результатов использовались следующие
метрики.
Производительность выполнения тестовых сценариев ручным
способом (кол-во/час)
, где
ТР – производительность ручного тестирования,
NT – количество выполненных тестовых сценариев,
Тm – время, затраченное на выполнение всех ручных тестовых сценариев.
Производительность
выполнения
тестовых
сценариев
автоматическим способом (кол-во/час)
, где
АТР – производительность автоматического тестирования,
NАT – количество выполненных автоматических тестовых сценариев,
Тa – время, затраченное на выполнение всех автоматических тестовых
сценариев.
Таким
образом,
при
переходе
от
ручного
тестирования
автоматическому производительность тестирования изменится в
28
раз.
к
Выигрыш
перехода
от
ручного
вида
тестирования
к
автоматическому (ч)
, где
n – количество выполненных автоматических тестов,
tm – время, затрачиваемое на выполнение одного теста ручным способом,
ta – время, затрачиваемое на выполнение одного теста автоматическим
способом,
tap – время, затрачиваемое на подготовку к автоматическому тестированию.
29
Количественный анализ
Расчет
разницы
между
ручным
и
автоматическим
тестированием по времени
Анализ
работы
применяемого
инструмента
для
тестирования
Cucumber показал, что на выполнение теста на один элемент проверки
соответствия тратится от 0,5 до 1,5 минут в зависимости от конфигурации.
Автоматическое
тестирование
всех
имеющихся
элементов
проверки
соответствия в версии продукта 2.1 занимает 7,5 часов, то есть около одного
рабочего дня одного члена команды (Рис. 5).
v2.1
v2.2
v2.3
300 elements
for regression
500 elements
for regression
600 elements
for regression
450mn=7,5h
750mn=12,5h
900mn=15h
1person -> ~1,5d
1person -> ~2d
1person -> ~1d
Рис. 5 Затраты ресурсов на автоматическое регрессионное
тестирование
Также стоит отметить, что на разработку, отладку и тестирование
автоматических скриптов было затрачено около 27 рабочих дней. Однако
необходимо учесть, что автоматический скрипт оказался универсальным для
различных версий продукта. Кроме того, вероятность внедрения новых
30
методов работы в программном продукте крайне мала, поэтому дальнейших
ресурсов на обслуживание данного тестового сценария не требуется.
Здесь же отметим, что при выполнении автоматических тестов,
необходимо около трех дней на подготовку к тестированию, сбор и
обработку информации, анализ отчетов.
Таким образом, учитывая все действия, совершенные для первого
использования автоматического скрипта для регрессионного тестирования
элементов проверки соответствия версии 2.1 программного продукта (с
учетом того, что первое регрессионное тестирование элементов проверки
соответствия выполнялось вручную), выигрыша во времени не было из-за
траты значительного количества времени на разработку, отладку и
тестирование автоматического сценария.
Однако
уже
автоматического
для
версии
регрессионного
2.2
программного
тестирования
продукта
элементов
для
проверки
соответствия нам необходимо на 50 дней меньше времени, чем для
выполнения аналогичного ручного тестирования, при условии выполнения
тестов одним человеком.
Поскольку
уже
известно
количество
элементов
проверки
соответствия, для которых будет проведено регрессионное тестирование для
ПО версии 2.3, можно рассчитать затраты временных ресурсов для данного
вида деятельности команды. В итоге, количество дней, высвобожденных
после внедрения автоматического тестирования для 2.3 релиза, составляет 65
рабочих дней при условии выполнения регрессионного тестирования 1
человеком дважды за жизненный цикл этой версии программного продукта.
Для версии продукта 2.k это значение составляет
.
Текущая и спрогнозированная тенденция прироста времени после
внедрения автоматического тестирования отображена на графике на Рис. 5.
31
Рис. 5 Тенденция прироста времени (в днях) после внедрения
автоматизированного тестирования
Расчет
разницы
между
ручным
и
автоматическим
тестированием по производительности
Если говорить о производительности, то регрессионное тестирование
500 элементов проверки соответствия версии 2.2 ПО занимало бы 31 день,
производительность ручного тестирования составила 16 тестов в день.
Аналогичная
регрессионного
метрика
для
тестирования
производительности
элементов
проверки
автоматизированного
соответствия
дает
результат в 111 тестов в день. Из этих данных полагаем, что при переходе от
ручного регрессионного тестирования элементов проверки соответствия к
автоматическому производительность команды относительно данного вида
деятельность увеличится почти в 7 раз. Таким образом, автоматизация
тестирования значительно повышает уровень производительности команды и
благоприятно сказывается на временных и человеческих затратах при
проведении регрессионного тестирования элементов проверки соответствия.
32
Качественный анализ
Основой качественного анализа является анализ преимуществ и
недостатков автоматического тестирования, применимых к текущему
проекту.
Во-первых,
Cucumber,
как
инструмент
для
проведения
автоматического тестирования, удобен и прост в своем использовании. Он
позволяет обычными, прямолинейными предложениями задавать сценарий
выполнения
теста.
Тестировщику
необходимо
создать
понятный
односложный скрипт, задать аргументы для внутренних функций, тем самым
подготовив авто-тест к воспроизведению. Также простота в использовании
сказывается на отсутствии необходимости обучать каждого члена тесткоманды работать со специфичным языком, объяснять тонкости тестовой
программы.
Во-вторых, создав однажды такой сценарий, сотруднику не придется
каждый раз тратить время на его обслуживание: от версии к версии методы,
отвечающие
за
проверку
соответствия,
остаются
неизменными
(проанализирована применимость полученных автоматических тестов на 3
предыдущих релизах). В этом случае определенно прослеживается такое
преимущество автоматического тестирования как снижение трудоемкости,
поскольку всё, что необходимо сделать тестировщику – это поместить
требуемые файлы, отражающие конфигурацию, в соответствующие им
директории.
В-третьих, следует обратить внимание на человеческий фактор.
Значительное различие машины и человека состоит в том, что человек не
может работать идеально на протяжении всего рабочего дня: внешние и
внутренние раздражители влияют на состояние тестировщика; к тому же
деятельность человека многогранна, и из-за многозадачности человек может
упустить
какие-либо
дефекты
продукта.
33
Поскольку
внимательность
компьютера не падает по причине усталости, при большом объеме
монотонной работы, автоматизация является наилучшей альтернативой.
В-четвертых, инструмент для автоматического тестирования имеет
возможность автоматического формирования и сохранения отчетов о
результатах тестирования. При ручном тестировании сотруднику приходится
самостоятельно составлять эти отчеты в виду их дальнейшей необходимости
при регрессионном тестировании. Когда речь идет о значительном
количестве тестов, время на ручное тестирование увеличивается за счет
ручной генерации отчетов.
Также в качестве преимущества следует отметить, что Cucumber
помогает отследить мелкие недочеты, касающиеся содержания ошибок
соответствующих элементов. В эту категорию входят орфографические,
пунктуационные ошибки и дефекты, связанные с формированием списка
ошибок (их непостоянное месторасположение в массиве). Не всегда
тестировщик может обратить внимание на такие недостатки, особенно после
нескольких часов монотонной деятельности.
Следующее преимущество является исключительной особенностью
тестируемого продукта. Бывают случаи, когда разработчики в силу
человеческого фактора не учитывают изменения в модели некоторых
элементов
при
составлении
соответствующей
документации.
При
автоматическом тестировании неучтенные элементы могут быть с легкостью
выявлены, что довольно трудоемко при ручном тестировании.
Одним из недостатков автоматического тестирования является риск
пропуска определенного вида дефектов.
Однако, как показывает анализ
Таблицы 1 обнаруженных дефектов, инструмент для автоматического
тестирования отслеживает все важные недостатки, что также является
весомым
преимуществом
в
пользу
Результаты представлены в таблице:
34
автоматического
тестирования.
Таб. 1 Количество обнаруженных дефектов
Sum of bugs
Sum of passed
Sum of failed
manual
490
auto
491
major
minor
10
10
5
9
9
-
По классификации дефектов тестирования, а именно по Градации
Серьезности дефекта (Severity), существуют major и minor дефекты,
«значительный» и «незначительный» соответственно. Существуют и другие
уровни
значимости
дефектов:
blocker –
«блокирующие»,
critical –
«критичные» и trivial – «тривиальные». В процессе ручного тестирования
дефекты таких уровней не были обнаружены, поэтому не участвуют в
анализе. Они характеризуют влияние дефекта на работоспособность
приложения в определенной мере. Таким образом, при обнаружении дефекта
ранга major тест получает статус failed. Текущий статус говорит о том, что
объект тестирования не отвечает заявленным требованиям. Поскольку
дефект типа minor незначительно влияет на программное обеспечение, тест
получает статус passed.
Действительно, Cucumber не покрывает часть элемента проверки
соответствия. В данную категорию входят область применения элемента, его
описание, шаги для корректировки конфигурации. Как правило, ошибки,
относящиеся именно к этим частям структуры, получают уровень minor. Для
объективности результатов был проведен анализ количества обнаруженных
ошибок, относящихся к различным элементам проверки соответствия, что
также отображено в таблице. Поскольку их число незначительно и
составляет лишь 1% от общего числа, было принято решение о допустимости
этого процента ошибок уровня minor.
35
Другим недостатком автоматического тестирования является то, что
инструмент для тестирования не может отследить ошибки, связанные с
внешним оформлением программного обеспечения (GUI), сопутствующие
ошибки функционала ядра (такие как неточности в позиционировании окон,
ошибки форм и т.п.). Также упускается проверка дружественности
интерфейса
(usability):
дружелюбность,
автоматизированный
цветовую
разрабатываемого
гамму,
продукта,
это,
тест
красоту
не
и
несомненно,
может
оценить
стиль
интерфейса
является
недостатком
автоматизации; с другой стороны, при ручном тестировании мнение
тестировщика в данном вопросе может быть субъективным и не отражать
реального состояния дел.
Более того такие важные нюансы учитываются во время других видов
ручного тестирования, поэтому это так же не является существенным
недостатком,
влияющим
на
принятие
решения
о
недопустимости
автоматизации. Хочется отметить, что 100-процентная автоматизация не
является совершенной альтернативой ручному тестированию. Дефекты,
которые были найдены при ручном тестировании и являются косвенными по
отношению к элементам проверки соответствия, также могут оказать
влияние на статус соответствующего теста. Именно такую картину отражает
таблица: при ручном тестировании было обнаружено 10 недочетов типа
major, 2 из которых относятся к функциональной части программного
обеспечения и не могут быть замечены инструментом Cucumber. Так как их
количество невелико, то, принимая во внимание очевидные выгоды
автоматизированного тестирования, здесь также было принято решение о
допустимости
данного
процента
ошибок
при
автоматизированном
регрессионном тестировании элементов проверки соответствия.
Ко всему прочему следует отметить, что автоматическое тестирование
не является бесконтрольным процессом, и каждый раз тестировщиком
проводится анализ отчетов, полученных при выполнении автоматических
тестов.
36
В процессе анализа полученных результатов было выявлено, что
преимущества
при
автоматизации
регрессионного
тестирования
для
текущего проекта существенно перевешивают недостатки. Таким образом,
можно
сделать
вывод,
что
риск
внедрения
автоматических
тестов
минимальный в виду его ощутимой эффективности. Даже при наличии
упущений значительных (major) дефектов, доля обнаруженных недочетов
остается несоизмеримо большой.
Как уже было отмечено, автоматическое тестирование имеет свои
преимущества и недостатки и не служит панацеей в погоне за выигрышем во
времени.
37
Заключение
В ходе работы было установлено что, внедрение автоматического
тестирования для регрессионных тестов элементов проверки соответствия
значительно повышает производительность команды, начиная со второй
версии тестируемого программного продукта, и освобождает ресурсы без
потери качества тестирования. Освобожденные ресурсы могут быть
направлены на решение других немаловажных задач проекта.
Также для автоматизации регрессионного тестирования элементов
проверки соответствия были определены дальнейшие перспективы развития.
Запускаемый
тестовый
сценарий
может
быть
применен
для
автоматизации другой – параллельно разрабатываемой – версии продукта.
Используемый
скрипт
может
быть
оформлен
как
универсальный
посредством некоторых изменений в его коде. Таким образом, существует
возможность его применения на объектах не только разных версий, но и
разных доменов коммуникационных сетей: WCDMA, LTE и SmallCell.
Текущая
загруженность
тестировщика
позволяет
проводить
регрессионное тестирование проверки соответствия в несколько раз чаще,
что позволит более тщательно следить за развитием функционала
программного обеспечения и наличием сопутствующей регрессии. Здесь
необходимо обратить внимание на такое понятие как «стоимость ошибки»:
чем позже обнаружен дефект, тем он «дороже». Если недочет, обнаруженный
тестировщиком,
может
быть исправлен,
то
недочет,
обнаруженный
пользователем после официальной публикации приложения, останется до
выхода следующей версии программного продукта, оказывая негативное
влияние как на репутацию продукта, так и на репутацию команды
тестировщиков.
Разработанный автоматический тест используется глобально внутри
межнационального проекта и для других аналогичных программных
продуктов заказчика.
38
В ходе работы над внедрение автоматизации регрессионного
тестирования
в
текущем
проекте
были
достигнуты
следующие
индивидуальные результаты:
 знакомство с инструментом для автоматизированного тестирования
Cucumber,
 получение опыта автоматизации тестирования,
 улучшение навыков написания тестовых сценариев на языке Ruby,
 получение
опыта
анализа
результатов
автоматизированного
тестирования и оценки целесообразности его применения.
39
Список литературы
1. Bertolino, A. Software Testing Research: Achievements, Challenges,
Dreams / A. Bertolino // Future of Software Engineering. – 2007. – pp. 83105.
2. Fewster, M. / Common Mistakes in Test Automation / M. Fewster // Grove
Consultants. – 2001. – pp. 1-7.
3. Gulechha, L. / Software Testing Metrics / L. Gulechha // Cognizant
Technology Solutions Collection. – 2008. – pp. 1-17.
4. Hartmann, J. / 30 Years of Regression Testing: Past, Present and Future / J.
Hartmann // PNSQC. – 2012. – pp. 1-8.
5. Lin, X. / Regression Testing in Research and Practice / X. Lin // University
of Nebraska Collection. – 2003. – pp. 1-6.
6. Ludewig, J. / Software Engineering in the year 2000 minus and plus ten / J.
Ludewig // Informatics: 10 years back, 10 years ahead. – 2001. – pp. 102 111.
7. Pettichord, B. / Seven Steps to Test Automation Success / B. Pettichord //
STAR West. – 2001. – pp. 1-17.
8. Economic Perspectives in Test Automation: Balancing Automated and
Manual Testing with Opportunity Cost / R. Ramler [et la] // AST. – 2006. –
pp. 85-91.
9. Walia, M. / Realizin Efficiency & Effectiveness in Software Testing through
a Comprehensive Metrics Model / M. Walia // Building Tomorrow’s
Enterprise. – 2012. – pp. 1-24.
10. Wynne, M. The Cucumber Book / M. Wynne, A. Hellesoy. – The
Pragmatic Bookshelf, 2012. – 328 pp.
11.Трудовой кодекс Российской Федерации [Электронный ресурс]:
[федеральный закон: от 30.12.2001 г. №197-ФЗ, в ред. от от 28.12.2013
N 421-ФЗ]. – Режим доступа:
21.01.2015).
40
www.consultant.ru (дата обращения:
12. Винниченко,
И.
Автоматизация
процессов
тестирования
/
И.
Винниченко. – СПб.: питерб 2005. – 203с. – ISBN 5-469-00798-7.
13. Дастин,
Э.
Автоматизированное
тестирование
программного
обеспечения. Внедрение, управление и эксплуатация / Э. Дастин, Д.
Рэшка, Д. Пол; пер. с англ. Е. Молодцова, М. Павлов. – М.: ЛОРИ,
2003. – 589с. – ISBN 5-85582-186-2.
14. Котляров, В. П. Основы тестирования программного обеспечения:
учебное пособие / В.П. Котляров, Т.В. Коликова. – М.: Интернет-Ун-т
Информ. Технологий, 2006. — 288с. – ISBN 5-94774-406-4.
41
Приложение
Сценарий .rb файл (Приложение 1)
Сценарий
–
файл
с
расширением
.rb,
применяемый
для
автоматизированного регрессионного тестирования элементов проверки
соответствия в текущем проекте.
# encoding: utf-8
begin require 'rspec/expectations'; rescue LoadErr; require
'spec/expectations'; end
require 'cucumber/formatter/unicode'
require 'Conf'
require 'ConsElementSession'
require 'ConsElement'
Given /^I have an (.*) specified$/ do |ConsElementId|
@ConsElementSession = Cucumber::ConsElementSession.new()
@ConsElementSession.enableListingOrderInsensitiveness()
@ConsElementId = ConsElementId
end
When /^I load version (.*) with (.*)$/ do |Conf,Model|
@Confpath = "data/dir/Confs/" + Conf
@Conf = Cucumber::Conf.new(@ConsElementSession.getServiceDirectory())
@Conf.openConf(@Confpath)
end
Then /^I run all ConsElements on the (.*) with (.*)$/ do |@ConfElementId,
@Fix|
@etap =
@ConsElementSession.runOneConsElement(false,@ConfElementId,@ConsElementId)
end
Then /^I can receive a (.*) and (.*) MESAND (.*) describe in (.*) MESAND
(.*) MESAND (.*) MESAND (.*) MESAND (.*) MESAND (.*)$/ do
|Severity,nbMsg,nbAuMsg,Msg1,Msg2,Msg3,Msg4,AuMsg1,AuMsg2|
Msgs = Array.new
for i in 1..nbMsg.to_i() do
Msgs.push(eval("Msg"+i.to_s()))
end
@ConsElementSession.runOneConsElement(false,@ConfElementId,@ConsElementId)
if (Severity == "WARN" )
@ConsElementSession.ConsElementMsgs("WARN", Msgs)
if (@Fix=="true")
@ConsElementSession.runOneConsElement(@Fix,@ConfElementId,@ConsElementId)
if (nbAuMsg != "0")
@ConsElementSession.runOneConsElement(false,@ConfElementId,@ConsElementId)
AuMsgs = Array.new
for i in 1..nbAuMsg.to_i() do
AuMsgs.push(eval("AuMsg"+i.to_s()))
42
end
@ConsElementSession.ConsElementMsgs("WARN", AuMsgs)
else
@ConsElementSession.runOneConsElement(false,@ConfElementId,@ConsElementId)
@ConsElementSession.failWithWarns(@ConfElementId)
end
end
elsif (Severity == "ERR")
@ConsElementSession.ConsElementMsgs("ERR", Msgs)
if (@Fix=="true")
@ConsElementSession.runOneConsElement(@Fix,@ConfElementId,@ConsElementId)
if (nbAuMsg != "0")
@ConsElementSession.runOneConsElement(false,@ConfElementId,@ConsElementId)
AuMsgs =Array.new
for i in 1..nbAuMsg.to_i() do
AuMsgs.push(eval("AuMsg"+i.to_s()))
end
@ConsElementSession.ConsElementMsgs("ERR", AuMsgs)
else
@ConsElementSession.runOneConsElement(false,@ConfElementId,@ConsElementId)
@ConsElementSession.failWithErrs(@ConfElementId)
end
end
elsif (Severity == "INFO")
@ConsElementSession.ConsElementMsgs("INFO", Msgs)
if (@Fix=="true")
@ConsElementSession.runOneConsElement(@Fix,@ConfElementId,@ConsElementId)
if (nbAuMsg != "0")
@ConsElementSession.runOneConsElement(false,@ConfElementId,@ConsElementId)
AuMsgs = Array.new
for i in 1..nbAuMsg.to_i() do
AuMsgs.push(eval("AuMsg"+i.to_s()))
end
@ConsElementSession.ConsElementMsgs("INFO", AuMsgs)
else
@ConsElementSession.runOneConsElement(false,@ConfElementId,@ConsElementId)
@ConsElementSession.failWithInfos(@ConfElementId)
end
end
else
@ConsElementSession.failWithWarns(@ConfElementId)
@ConsElementSession.failWithErrs(@ConfElementId)
@ConsElementSession.failWithInfos(@ConfElementId)
end
end
43
Instruction for Performing of Automotive Regression Testing
(Приложение 2)
1. Prepare folders with .feature files and configuration files (XML) remained
from regression testing of previous version.
2. (Optional) Make required changes in .rb and/or .feature files. The possible
changes:
- formats of .feature and/or .rb files were changed;
- @confpath in .rb file should contain the valid configurations location.
3. Add .feature files and configuration files (XML) to the appropriate folders of
test-project.
4. (Optional) Archive configuration file to ZIP because of size.
5. Launch Cucumber tool of the latest version.
6. Configure Cucumber tool with appropriate jars, plugins, paths to mentioned
files, JVM arguments.
7. Run CucumberRunner.mwe2.
8. Save report with testing result after test completion.
44