CC BY
162
_НАУЧНОЕ ПЕРИОДИЧЕСКОЕ ИЗДАНИЕ «CETERIS PARIBUS» №10/2016 ISSN 2411-717Х_
ТЕХНИЧЕСКИЕ НАУКИ
УДК 004.8
Артюхова Антонина Сергеевна
Аспирант ЮФУ, г.Таганрог, РФ E-mail: antonina1992@gmail.com
ПРОБЛЕМЫ АВТОМАТИЗАЦИИ ТЕСТИРОВАНИЯ И ПОДХОДЫ К ИХ РЕШЕНИЮ
Аннотация
В статье рассматриваются основные проблемы автоматизации тестирования и подходы к их решению. В зависимости от области применения необходима адаптация процесса тестирования. С этой целью предлагается использовать генетические алгоритмы. Все проекты уникальны, соответственно их тестирование представляет собой сложную неформализованную задачу, а для решения таких задач успешно применяются генетические алгоритмы.
Ключевые слова
Эволюционные вычисления, генетический алгоритм, верификация, тестирование.
Проблемы автоматизации тестирования. Верификация (или тестирование) программного обеспечения является важным навыком для оценки качества программного продукта. Верификация представляет собой процесс анализа программного объекта для обнаружения различий между существующим и необходимым состоянием (то есть, ошибки) и оценивания особенностей программного объекта [2]. Тестирование программного обеспечения является деятельностью, которая должна производиться в течение всего процесса разработки [2].
Основными целями тестирования можно назвать следующие:
• продемонстрировать разработчикам и заказчикам, что программа соответствует требованиям;
• выявить ситуации, в которых поведение программы является неправильным, нежелательным или не соответствующим спецификации [4].
Как известно одна из статей расходов при разработке программного обеспечения будет связана с его тестированием. Тестирование призвано выявлять сбои, то есть обнаруживать слабые места в программном продукте для их дальнейшего удаления или исправления [2], однако нахождение подобных неисправностей может занять много времени и не поддается прогнозированию.
Для упрощения процесса тестирования и сокращения временных затрат на этапе контроля качества в процессе разработки программного обеспечения часто применяют так называемое автоматизированное тестирование. Сокращение затрат достигается путем использования программных средств для выполнения тестов и проверки результатов их выполнения. Активное развитие автоматизированного тестирования началось с 1980-х, хотя отдельные попытки осуществлялись и ранее.
К автоматизации тестирования существуют два ключевых подхода:
• тестирование на уровне кода;
• тестирование пользовательского интерфейса.
Тестирование на уровне кода или как его еще называют тестирование «белого» ящика (или «стеклянного» ящика). Его характерной особенностью является то, что при тестировании учитывается внутренний механизм тестируемой системы или компонента. Используя методы тестирования белого ящика, тестировщики (обычно это разработчики, создающие код) проверяют, что код делает именно то, для чего он предназначался, на низком структурном уровне. Также тестирование на уровне кода называют модульным или юнит-тестированием. Модульное тестирование - это тестирование отдельных аппаратных или программных модулей или групп связанных модулей [2].
_НАУЧНОЕ ПЕРИОДИЧЕСКОЕ ИЗДАНИЕ «CETERIS PARIBUS» №10/2016 ISSN 2411-717Х_
Тестирование пользовательского интерфейса обычно производится с применением методов тестирования черного ящика. Тестировщики проверяют высокоуровневое проектирование и пользовательские требования спецификации для планирования тестов, чтобы убедиться, что код делает, то для чего он предназначался.
Как и у любого другого этапа разработки программного обеспечения у этапа тестирования есть свои характерные проблемы. Актуальность необходимости решения этих проблем объясняется, прежде всего, популярностью «гибких» (англ. agile) методологий разработки программного обеспечения.
Среди проблем автоматизированного тестирования можно выделить, прежде всего, его трудоемкость: несмотря на то, что оно дает возможность избежать части рутинных операций и повысить скорость выполнения тестов, обновление тестов может потребовать огромных ресурсов.
То есть второй большой проблемой автоматизации тестирования является поддержка тестов в актуальном состоянии. Обновления тестов могут понадобиться как в случае изменения функционала, так и в случае изменения самих входных данных теста. Это характерно для обоих видов автоматизации. При реорганизации кода часто возникает необходимость обновить также юнит-тесты, а обновление кода собственно тестов, возможно, будет сравнимо по времени с изменением основного кода. Кроме того, в случае изменения интерфейса приложения возникает необходимость вновь переписать тесты, связанные с обновленными окнами, что при большом числе тестов может потребовать значительных ресурсов.
Также сложность представляет собой и сама процедура отбора тестов для автоматизации, поскольку далеко не все ситуации легко поддаются автоматизации.
А все выше перечисленные моменты неизменно отражаются на стоимости конечного продукта, что также может представлять собой еще одну проблему.
Кроме того необходимо помнить, что как бы не были хороши автоматические тесты они никогда не смогут целиком заменить ручное тестирование. Автоматизация всех сценариев является очень дорогостоящим мероприятием, по этой причине автоматическое тестирование является скорее дополнением для ручного тестирования. Одним из лучших вариантом для применения автоматических тестов является регрессионное тестирование.
Рисунок - График зависимости затрат и работоспособности
GUI-автоматизация. Самым популярным видом автоматизации является, пожалуй, тестирование приложений через графический интерфейс пользователя (англ. GUI). Своей популярностью этот способ тестирования обязан двум моментам: 1) приложение тестируется таким же образом, каким оно будет использоваться человеком; 2) появляется возможность протестировать приложение при отсутствии доступа к его исходному коду.
В настоящее время существует уже 4 поколения техник и инструментов GUI-автоматизации:
_НАУЧНОЕ ПЕРИОДИЧЕСКОЕ ИЗДАНИЕ «CETERIS PARIBUS» №10/2016 ISSN 2411-717Х_
• Утилиты записи и воспроизведения (англ. capture/playback tools), записывающие шаги тестировщика при ручном тестировании. Они позволяют проводить тесты без непосредственного участия человека в течение длительного времени, повышая продуктивность и устраняя рутинное повторение однообразных действий во время ручного тестирования. Однако даже небольшая перемена в тестируемом ПО потребует перезаписи ручных тестов. По этой причине первое поколение инструментов не эффективно и не масштабируемо.
• Написание сценария (англ. scripting) представляет собой один из видов программирования на специально разработанных для автоматизации тестирования ПО языках, позволяет избежать некоторых сложностей инструментов записи и воспроизведения. Однако разработкой занимаются программисты высокого уровня, работающие отдельно от тестировщиков, непосредственно запускающих тесты. Кроме того скрипты подходят преимущественно для тестирования GUI и не могут быть внедренными, пакетными или же иным способом объединены в систему. В конечном итоге, обновление тестируемого ПО, как правило, приведет к обновлениям соответствующих скриптов, и поддержка все увеличивающейся библиотеки тестирующих скриптов может превратиться в непреодолимую проблему.
• Управляемое данными тестирование (англ. Data-driven testing) — это используемая в автоматизации тестирования методология. Ее характерная черта заключается в том, что тестовые скрипты выполняются и верифицируются на основе данных, которые хранятся в центральном хранилище данных или базе данных. В качестве базы данных могут выступать ODBC-ресурсы, csv или xls файлы и т. д. Управляемое данными тестирование заключается в объединении ряда взаимодействующих тестовых скриптов и их источников данных во Фреймворк, используемый в методологии. В этом Фреймворке переменные используются как для входных значений, так и для выходных проверочных значений: в тестовом скрипте обычно закодированы навигация по приложению, чтение источников данных, ведение логов тестирования. Следовательно, логика, выполняющаяся в скрипте, тоже зависит от данных.
• Тестирование по ключевым словам (англ. Keyword-based) автоматизация заключается в проведении создания тест-кейсов в два шага: планирование и реализация. В данном случае окончательный вид теста это не программный код, а описание порядка действий с их условиями. При этом за непосредственную реализацию ключевых слов (действий) отвечает Фреймворк, а для создателя тестов достаточно иметь представление обо всём множестве возможных действий, реализованных во Фреймворке. Таким образом, тесты могут создавать люди, не владеющие навыками программирования.
Среди сложностей GUI-автоматизации можно назвать то, что до сих пор не существует универсального способа автоматизации пользовательского интерфейса, потому что каждый проект уникален.
Решение с помощью «Гибкого» тестирования. Под «гибким» тестированием понимается тестирование, ориентированное на бизнес (то есть на заказчика). В данном случае тесты определяют желаемые для бизнес-экспертов средства и функциональность.
Автоматизация тестов - это основная практика гибкой методологии. Гибкие проекты сильно зависимы от автоматизации. Написание кода по принципу «сначала тесты» позволяет программистам лучше понять требования и проектировать код в соответствии с ними. Таким образом «гибкие» тесты представляют собой тесты, написанные с применением технологии Разработка через тестирование (англ. Test-Driven-Development или сокр. TDD). Автор данной технологии Кент Бек представлял процесс тестирования как цикл со следующими итерациями: на первом шаге пишется тест, который покрывает необходимое изменение, на втором шаге пишется код, позволяющий пройти тест, третий шаг представляет собой рефакторинг кода. Для осуществления тестирования им совместно с Эрихом Гамма был разработан Фреймворк JUnit. В настоящее время эта технология активно развивается и уже существует порт JUnit под .NET - Nunit и многие другие популярные решения. Однако у данного подхода существует множество сложностей, в том числе:
• не существует способа автоматического тестирования GUI;
• не существует способа автоматического тестирования распределенных объектов;
• TDD нельзя использовать для разработки схемы базы данных;
• отсутствует необходимость в тестировании кода, написанного сторонними разработчиками или кода, генерируемого внешними инструментами автоматизации разработки;
_НАУЧНОЕ ПЕРИОДИЧЕСКОЕ ИЗДАНИЕ «CETERIS PARIBUS» №10/2016 ISSN 2411-717Х_
• TDD нельзя использовать для разработки компилятора/интерпретатора языка программирования [3].
Решение с помощью GRID-технологий. В последнее время существует значительный интерес к
GRID-технологиям, который способствовал их быстрому развитию и появлению различных GRID-решений. Разработкой системы распределенной unit-тестирования с применением GRID-технологий занимаются наши соотечественники Д. В. Кадашев, А. А. Кузнецов и некоторые другие.
Суть GRID-технологии [Foster, Kesselman, 1999] состоит в том, что обычные компьютеры, объединенные в обычную сеть, превращаются с помощью программного обеспечения в единый вычислительный ресурс, способный решать сложные вычислительные задачи. Таким образом, GRID-системы представляют собой неоднородный вычислительный ресурс с некоторым количеством серверов управления.
В данном подходе тест представляет собой специальным образом организованный программный компонент, созданный исключительно в целях контроля корректности работы другого программного компонента. Исполнение тестов при модификации программных компонентов имеет большое значение для поддержки работоспособности разрабатываемой программной системы и называется unit-тестированием [1].
Этот подход наследует черты TDD, в частности он опирается на JUnit. Однако у него существуют определенные недостатки, связанные, прежде всего, с недостатками GRID-технологий. Назовем некоторые из них:
• GRID не является лучшим решением для диалоговой обработки запросов реального времени. OLTP -вертикально масштабируемые системы, являются более подходящими;
• Средства разработки программных средств GRID нуждаются в усовершенствовании (необходимо улучшить интеграцию Веб-сервисов с инструментами их разработки).
Решение с помощью генетических алгоритмов. Процесс тестирования представляет собой выполнение определенного множества тестов и анализ их результатов. В данном случае, тест представляет собой последовательные обращения к тестируемому программному продукту, а результатом выполнения теста является заключение о том, корректно он отработал или в ходе выполнения были обнаружены ошибки. Главный показатель тестового набора, который и определяет качество тестирования - это класс возможных ситуаций в программе покрываемых этим тестовым набором.
Количественную оценку качества тестирования производят с применением критериев тестового покрытия [6]. Критерии тестового покрытия должны быть нацелены на обнаружение ошибок. Критерий покрытия измеряет долю классов ситуаций, представители которых попали в тестовый набор. Чем больше уровень тестового покрытия, тем больше классов ситуаций покрыто, тем больше ошибок можно обнаружить. Чтобы добиться качественного тестирования необходимо построить тестовый набор, удовлетворяющий определенному критерию полноты. Такие критерии полноты называются критериями тестового покрытия [2, 6, 7]. При этом определяется и числовая метрика тестового покрытия — доля покрытых классов ситуаций среди всех возможных. Критерий полноты может использовать различные значения метрики, например, он может требовать, чтобы полный тестовый набор всегда покрывал 100% выделенных классов ситуаций, или же считать достаточным покрытие 85% классов ситуаций (или другое пороговое значение).
При разработке программного обеспечения, есть расходы, связанные с тестирования наших программ. Мы должны выписать план тестирования и наши тестовые случаи, мы должны настроить необходимое оборудование, мы должны систематически выполнять тесты, мы должны следить за проблемами, которые были выявлены, и мы должны удалить большинство неисправностей, которые мы нашли. А создание полного тестового набора для больших программных продуктов является очень трудоемкой задачей. Автоматизация этого процесса позволяет сократить расходы на тестирование. В общем случае оптимизация или поиск наилучшего значения (набора параметров) некоторой заданной целевой функции является достаточно сложной задачей. Существует несколько подходов к автоматической генерации тестов. Например, во многих случая хорошие результаты дает подход, основанный на применении эволюционных вычислений и в частности генетических алгоритмов.
_НАУЧНОЕ ПЕРИОДИЧЕСКОЕ ИЗДАНИЕ «CETERIS PARIBUS» №10/2016 ISSN 2411-717Х_
Термин «эволюционные вычисления» в Искусственном интеллекте подразумевает использование для решения разнообразных задач проектирования, оптимизации, прогнозирования и управления совокупности алгоритмических, программных, аппаратных средств и приближенных эвристических методов, основанных на имитации механизмов эволюции для синтеза структур обработки данных, а также на статистическом подходе к исследованию ситуаций и итерационном приближении к искомому решению [5, 8]. Одной из разновидностей эволюционных вычислений является генетический алгоритм, упор в котором идет на применении оператора «скрещивания».
Однако, эффективность подходов, основанных на применении генетических алгоритмов, сильно зависит от выбранного критерия полноты. Необходим анализ эффективности некоторых известных критериев полноты тестовых наборов при применении генетических алгоритмов для генерации тестов.
Заключение. Безусловно, автор не спорит с тем, что автоматические тесты не смогут никогда в полной мере заменить людей. И они также обладают рядом недостатков. В том числе трудоемкость и сложность автоматизации некоторых тестовых сценариев. Необходимость постоянной поддержки автоматизированных тестов в актуальном состоянии. Все это повлечет за собой увеличение стоимости конечного продукта.
Но у автоматизации тестирования существует также и множество достоинств. В том числе скорость и точность в сравнении с ручным тестированием. Таким образом, данный вид тестирования позволяет повысить качество продукта. Особенно это становится очевидно на больших проектах, там применение автоматизации тестирования более чем оправдано, и скорее всего приведет даже к некоторой экономии ресурсов. Ведь как уже говорилось, тестирование является неотъемлемой частью всех стадий разработки программного продукта.
Однако все же многое зависит и от самих тестировщиков. Ведь в процессе автоматизации тестов нужно не меньше усилий и знаний чем в процессе создания любого другого программного обеспечения. По этой причине программисты и тестировщики ищут наиболее оптимальный подход для решения проблем. Рассматриваемые в данной статье подходы служат тому доказательством. Они различаются и по своей технике и по методической основе.
В статье рассмотрены достоинства и недостатки таких подходов как GUI-автоматизация, «гибкое» тестирование, GRID-технологии. Но наиболее перспективным на наш взгляд является все же решения с применением эволюционных вычислений и в особенности генетических алгоритмов. Поскольку каждый проект по-своему уникален, то тестирование в данном случае представляет собой сложную неформализованную задачу. А как известно, для решения таких задач успешно применяются генетические алгоритмы.
Исследование выполнено при финансовой поддержке грантов РФФИ (проекты №№ 16-07-00335, 1607-00336) в Южном федеральном университете.
Список использованной литературы:
1. Кадашев Д. В., Кузнецов А. А. Система распределенного unit-тестирования «Testing GRID». // Вестник НГУ. Том 5, выпуск 1 - 2007. С.20-27.
2. Williams L. A (Partial) Introduction to Software Engineering Practices and Methods, 20102011 (Seventh Edition).: https://online.ist.psu.edu/sites/ist4i2/files/williamstext.pdf
3. Кент Бек. Экстремальное программирование: разработка через тестирование. Библиотека программиста. - СПб.: Питер, 2003. - 224с.
4. Майерс Г., Баджетт Т., Сандлер К. Искусство тестирования программ, 3-е издание — М.: «Диалектика», 2012. — 272 с.
5. Курейчик В.М., Родзин С.И. Компьютерный синтез программных агентов и артефактов // Программные продукты и системы. 2004. № 1. С. 23-27.
6. Zhu H., Hall P. A. V., May J. H. R. Software Unit Test Coverage and Adequacy. ACM Computing Surveys, 29(4):366-427, Dec. 1997.
_НАУЧНОЕ ПЕРИОДИЧЕСКОЕ ИЗДАНИЕ «CETERIS PARIBUS» №10/2016 ISSN 2411-717Х_
7. IEEE Guide to Software Engineering Body of Knowledge, SWEBOK, 2004.
8. Rodzin S., Rodzina L. Theory of Bioinspired Search for Optimal Solutions and its Application for the Processing of Problem-Oriented Knowledge // В сборнике: 8th IEEE International Conference on Application of Information and Communication Technologies, AICT 2014 - Conference Proceedings 8. 2014. С. 7035930
© Артюхова А.С., 2016
