Содержание к диссертации
Введение
Глава 1. Анализ тенденций развития систем автоматизированного тестирования 13
1.1 Модель изменения сложности программного обеспечения .13
1.2 Анализ современных тенденций в организации тестирования программных комплексов .21
1.3 Типовая архитектура системы автоматизированного тестирования 26
1.4 Интеллектуализация системы поддержки автоматизированного тестирования 34
1.5 Выводы 41
Глава 2. Теоретические основы построения интеллектуального модуля поддержки системы автоматизированного тестирования ПО 43
2.1 Модифицированная типовая архитектура системы автоматизированного тестирования 45
2.2 Модификация продукционной модели базы знаний .49
2.3 Принципы построения и поддержки базы знаний .57
2.4 Методика формализации знаний о предметной области .62
2.5 Выводы .78
Глава 3. Практическая реализация и оценка эффективности разработанных методов .80
3.1 Применение интеллектуальных модуля поддержки систем автоматизированного тестирования .80
3.2 Принципы работы интеллектуального модуля 84
3.2.1 Инициация процесса анализа .84
3.2.2 Автоматизация формирования базы фактов .87
3.3 Обоснование выбора программно-аппаратной платформы 91
3.4 Результаты внедрения пилотной системы 92
3.5 Выводы .100
Заключение .102
Список сокращений и условных обозначений 105
Термины и определения .106
Библиографический список .107
Основные публикации по теме диссертации .118
Приложения .121
- Анализ современных тенденций в организации тестирования программных комплексов
- Модификация продукционной модели базы знаний
- Автоматизация формирования базы фактов
- Результаты внедрения пилотной системы
Введение к работе
Актуальность работы. За последние десятилетия наблюдается бурный рост информационных технологий во всех сферах жизни человеческого общества в предметной области разработки программного обеспечения (в частности). Рост вычислительной мощности, а также развитие технологий хранения данных привели к тому, что современные программные продукты совмещают огромное количество функций и значительно увеличились в размерах. При этом, можно отметить экспоненциальный рост сложности всех классов программного обеспечения (ПО).
Помимо роста сложности программных комплексов нужно отметить тенденцию на сокращение длительности цикла разработки. Применение гибкой (agile) вместо каскадной (waterfall) модели разработки потребовало повышения степени автоматизации тестирования для сохранения качества разрабатываемого ПО. Это привело к рождению нового класса систем – систем автоматизированного тестирования.
По мере дальнейшего роста сложности программных комплексов растет сложность систем автоматизации тестирования. Вследствие этого увеличивается количество отказов, вызванных сбоями системы автоматизации тестирования. В результате центр приложения усилий смещается от разработки программного продукта и тестов для него в сторону поддержки системы автоматизированного тестирования. На данный момент поддержке автоматизированного тестирования уделяется недостаточно времени в исследованиях. В конечном итоге это приводит к неэффективному расходованию ресурсов. Применение системы интеллектуальной поддержки автоматизированного тестирования, которая возьмет на себя ряд функций, ранее выполняемых персоналом, позволит повысить как качество тестирования, так и эффективность использования ресурсов.
Так как создание ПО – одна из высокотехнологичных специализаций
России в международном разделении труда, то разработка нового класса систем
интеллектуальной поддержки автоматизированного тестирования программных комплексов (СИП АТПК), являющихся подобием САПР, позволяет получить преимущество в конкурентной борьбе на данном сегменте рынке.
Данная работа дополняет труды в области искусственного интеллекта и систем автоматизации принятия решения таких ученых как Н. Винера, К. Шеннона, А. Тюринга, C. Рассела, М. Минского, Д.А. Поспелова, М.Г. Гаазе-Рапопорта, Д.Э. Попова, Т.А. Гавриловой, А.П. Еремеева и В.Н. Вагина, А.А. Бобцова, Р.И. Сольницева, В.М. Курейчика, Я.Е. Львовича, В.Н Кучуганова и других.
Кроме того, использовались труды Д.А. Поспелова, М. Мэскона, М. Мински в области ситуационного подхода, а также труды П.В Мисевича в областях сценарно-ситуационного, логистического подходов, а также их комбинаций.
Использовались работы в области проектирования САПР таких ученых как П.Д. Басалин, П. Джексон, А.П. Частиков и других.
Научная проблема диссертационной работы: обеспечение автоматизированного тестирования и сопровождение инструментариев поддержки для повышения эффективности и качества тестирования.
Цель и задачи исследования. Цель исследования – повышение эффективности процессов поддержки автоматизированного тестирования ПО за счет внедрения интеллектуального модуля поддержки работы системы автоматизации тестирования (САТ) программного обеспечения. Данная цель достигается решением следующих задач:
-
Анализ состояния работ в области автоматизации процесса тестирования ПО и выявление недостатков существующих подходов к построению систем автоматизированного тестирования.
-
Модификация типовой архитектуры систем автоматизации тестирования путем внедрения модуля интеллектуальной поддержки.
-
Разработка модифицированной продукционной модели информационного обеспечения интеллектуальной системы для ее адаптации к предметной области автоматизированного тестирования ПО.
-
Выработка принципов поддержки интеллектуального модуля на протяжении всего жизненного цикла данного модуля.
-
Разработка инструментариев для реализации интеллектуальной поддержки автоматизированного тестирования. Диссертация на соискание ученой степени кандидата технических наук
соответствует пунктам 4, 9 и 10 паспорта специальности 05.13.01 «Системный анализ, управление и обработка информации (в науке и промышленности)» номенклатуры специальностей научных работников: Разработка методов и алгоритмов решения задач системного анализа, оптимизации, управления, принятия решений и обработки информации; разработка проблемно-ориентированных систем управления, принятия решений и оптимизации технических объектов; методы и алгоритмы интеллектуальной поддержки при принятии управленческих решений в технических системах.
Объект исследования – система автоматизированного тестирования программных комплексов, выполняемых на гетерогенных вычислительных системах.
Предмет исследования – инструментарий поддержки процесса автоматизированного тестирования программных комплексов.
Область применения. Методы и подходы, разработанные в рамках данной работы, применимы для модификации существующих или разрабатываемых систем автоматизированного тестирования. Результаты анализа предметной области могут быть использованы на различных этапах проектирования систем автоматизации разработки ПО для обоснования технических решений.
Теоретическую и методологическую основу исследования составляют сценарный, ситуационные и логистические подходы к вопросу исследования
предметной области и поддержки автоматизированных систем в течение жизненного цикла.
Методы исследования. В работе используется: системный подход, аппарат графов, аппарат баз данных, концептуальная модель «сущность-связь», методы искусственного интеллекта, в частности продукционные системы, методы инженерии знаний, процедуры поддержки продукционной базы знаний (БЗ) и алгоритмы работы интерпретаторов продукционной БЗ.
Научная новизна:
В диссертации получены следующие результаты, характеризующиеся научной новизной.
Предложена модифицированная архитектура систем автоматизированного тестирования ПО, предназначенная для построения данного класса систем и позволяющая автоматизировать значительную часть операций по поддержке работы подобных систем и отличающаяся от других наличием модуля интеллектуальной поддержки
Разработана модифицированная продукционная модель и способ ее построения. Данная модель, а также способ ее построения предназначены для описания процессов в предметной области функционирования СИП АТПК, позволяют формализовать информационное обеспечение работы данного класса АС и отличаются от аналогов ориентацией на поддержку всех этапов ЖЦ данного класса систем.
Сформулированы принципы поддержки системы баз знаний в предметной области работы систем автоматизированного тестирования. Данные принципы формализуют построение и модификацию подобных систем, позволяют решать проблемы избыточности и связности сценариев на всех этапах жизненного цикла, и отличаются от существующих ориентированностью на предотвращение возникновения дефектных или неэффективных сценариев.
Достоверность и обоснованность результатов исследования
обеспечивается сравнением разработанных аналитических моделей и
алгоритмов с результатами экспериментальных исследований и опубликованными материалами других исследователей, а также внедрением полученных результатов. Воспроизводимость экспериментов обеспечивается использованием в них синтезированной тестовой базы знаний и свободно распространяемого программного обеспечения.
Практическая ценность работы заключается в следующем:
- предложена модифицированная архитектура систем
автоматизированного тестирования, отличающаяся от существующих наличием
модуля интеллектуальной поддержки, построенном с использованием
модифицированной продукционной модели;
сформулированных принципы поддержки продукционной базы знаний, ориентированные на ее поддержу на всех этапах жизненного цикла;
разработана структура интеллектуального модуля и интерфейсы взаимодействия с другими элементами системы автоматизированного тестирования, что позволило создать инструментарий – скелетную оболочку интеллектуального модуля поддержки автоматизированного тестирования;
- применение модифицированной системы автоматизации тестирования
привело к тому что, 92% инфраструктурных проблем стали детектироваться в
автоматическом режиме, что позволило достичь следующих результатов:
время, затрачиваемое инженерами по тестированию и администраторами на
поддержку процесса тестирования, сократилось на 65%; повысилась
эффективность использования тестовой инфраструктуры на 9%; сократилось
время необходимое для получения достоверных тестовых результатов в 2,5
раза.
Сведение о внедрении результатов. Результаты диссертационного исследования внедрены в: АО «Интел А/О», в учебном процессе кафедры "Вычислительные системы и технологии" Нижегородского государственного технического университета им. Р.Е. Алексеева. Разработанные алгоритмы, реализованы в системе CLIPS и защищены в качестве объектов интеллектуальной собственности.
Апробация результатов исследования. Результаты исследований докладывались на всероссийских и международных научных конференциях, в том числе на IX, X, XII, XIII международной научно-технической конференции «Информационные системы и технологии» (ИСТ), XIII Международной научно-практической конференции студентов, аспирантов и молодых ученых «Молодежь и современные информационные технологии» МСИТ-2015, XV Всероссийской научной конференции «Нейрокомпьютеры и их применение», ХII Международная научно-техническая конференция «Перспективные технологии в средствах передачи информации» (ПТСПИ-2017).
Положения, выносимые на защиту:
Модифицированная архитектура систем автоматизированного тестирования, отличающаяся от существующих наличием модуля интеллектуальной поддержки, построенном с использованием продукционной модели
Модифицированная продукционная модель описания процессов в предметной области функционирования СИП АТПК и способ ее построения.
Принципы поддержки продукционной базы баз знаний в данной предметной области на всех этапах жизненного цикла.
Структура интеллектуального модуля и интерфейсы взаимодействия с другими элементами системы автоматизированного тестирования, что позволило создать инструментарий - скелетную оболочку для его построения
Личный вклад автора заключается в развитии типовой архитектуры систем автоматизированного тестирования через включение в ее состав модуля интеллектуальной поддержки, модификации продукционной модели описания процессов в предметной области функционирования системы автоматизированного тестирования и в разработке принципов поддержки базы знаний СИП АТПК на всех этапах жизненного цикла.
Публикация результатов исследования. Результаты диссертационного исследования опубликованы в 12 печатных работах, из них 3 статьи в рецензируемых научных изданиях, которые рекомендованы ВАК.
Объем и структура работы. Диссертационная работа изложена на 141 страницах, состоит из введения, трех глав, содержащих 29 рисунков, 16 формул и 14 таблиц, заключения, а также приложений. Библиографический список включает 100 наименований.
Анализ современных тенденций в организации тестирования программных комплексов
Развитие индустрии разработки программного обеспечения происходило совместно с развитием подходов к тестированию ПО. При этом развивались как методы тестирования, так и взгляды на тестирование в целом [57][58][59]. В данной главе рассматриваются различные векторы развития в области тестирования программного обеспечения
Одним из основополагающих факторов, определяющих результат деятельности является целеполагание. За время существования тестирования произошло несколько изменений в определении целей тестирования, что значительно повлияло на развитие данной области:
На начальном этапе целью тестирования являлось доказательство работоспособности программного обеспечения. Тестированием занимался разработчик и тестирование было лишь частью процесса отладки. Процесс тестирования строился как демонстрация того, что продукт корректно выполняет заложенные функции. Недостатком такого подхода является то, что в реальной жизни окружение продукта не идеально (возможен ввод ошибочных данных, требуемые ресурсы могут оказаться недоступны, характеристики окружения могут не соответствовать ожиданиям). Однако, поведение продукта не проверялось для подобных случаев. Как следствие, работоспособность программного комплекса не гарантировалась в нештатных ситуациях. По мере развития индустрии разработки программного обеспечения и обособления ролей: разработчик, инженер по тестированию, -произошли изменения в целях тестирования. На данном этапе на первый план выходит поиск уязвимостей, при котором целью ставится поиск всех возможных ошибок в программном обеспечении. Данный подход несет в себе ряд противоречий:
Процесс тестирования при таком подходе бесконечен, так как исправление одной ошибки может породить новые. Не существует критерия прекращения тестирования. о Количество известных ошибок в продукте мало говорит о состоянии продукта. Отсутствие известных ошибок может говорить, как о высоком качестве продукта, так и о низком качестве тестирования. о Противопоставление разработчика программного обеспечения, целью которого являлась минимизация ошибок в программе, и инженера по тестированию, ориентированного на поиск ошибок, нередко приводило к конфликтам между отделами разработки и тестирования. Конфликты негативно сказывались на общем процессе разработки и качестве финального продукта. о Истинной целью разработки является получение качественного продукта, а не поиск недостатков в нем. Следование данному подходу противоречит общей цели процесса разработки программного обеспечения. Решение данных противоречий обусловило переход на третий этап. На современном этапе развития тестирования программного обеспечения целью является обеспечение качества продукта. Это многогранный процесс, управляющий качеством продукта, который подразумевает формализацию всех этапов разработки, тестирования, выпуска и эксплуатации. Под качеством программного обеспечения подразумевается:
Степень, в которой программное обеспечение обладает требуемой комбинацией свойств. [60].
Совокупность характеристик программного обеспечения, относящихся к его способности удовлетворять установленные и предполагаемые потребности. [61].
Обеспечение качества подразумевает под собой выработку определенных метрик качества, процедур их измерения, формализацию процессов разработки, тестирования и поддержки [62]. Современный подход к целям тестирования внес предсказуемость в процессы обеспечения качества, разрабатываемого ПО. При этом выросли требования к процессу тестирования, что повлекло за собой бурный рост объемов тестирования. При этом выросли количество тестов, а также количество программно-аппаратных конфигураций, на которых требуется их исполнение.
Изменение целей тестирования меняли методы тестирования и подходы к тестированию в целом. На начальных этапах целью было доказательство работоспособности программы. При этом логичным является желание достичь полного покрытия кода, так как в таком случае достигалась гарантия работоспособности. Но по мере роста сложности программного обеспечения начали ярко проявляться недостатки такого подхода [63]:
Количество ресурсов, требуемых для увеличения покрытия на 1% растет экспоненциально по мере приближения к 100%. И достижение 100% покрытия невозможно при разумных затратах.
Не только достижение полного покрытия, но и его измерение, для сложного программного обеспечения является нетривиальной задачей [64]. о Упрощенные формы (покрытие по функциям или строкам кода) не дают адекватной оценки, так как не учитывают все возможные пути исполнения.
Покрытие по путям исполнения или покрытие по условиям для сложных программных комплексов требуют покрытия огромного количества случаев. Часть из них невозможно покрыть в принципе из-за особенностей окружения. При этом определение общего количества и выделение значимых само по себе является нетривиальной задачей. Написание тестов для каждого из путей исполнения или условий настолько трудоемкая задача, что никогда не предпринималось подобных попыток для сколько ни будь сложных программных комплексов, даже в таких критичных областях как программное обеспечение для космоса или атомных объектов.
Чаще всего при оценке покрытия учитываются ожидаемые ситуации. При этом по мере роста гетерогенности окружения и скорости его изменения невозможно предугадать все возможные ситуации. В результате достижение полного покрытия в изменяющейся среде невозможно в принципе. Таким образом произошел уход от максимизации покрытия как средства достижения заданного качества продукта. Покрытие тестами становится одним из параметров при оценке текущего качества продукта.
Ориентация на качество продукта как единственной цели [63], привела к разнонаправленным изменениям в организации команд, участвующих в разработке программного обеспечения:
Усложнение среды и рост количества экспертиз, необходимых для разработки программного обеспечения и его поддержки на всех этапах жизненного цикла привел к дифференциации ролей [64]:
разработчики,
инженеры по тестированию, о инженеры по поддержке. Разбиение по ролям позволило фокусироваться на ограниченной области знаний.
С другой стороны, минимизация расходов на исправление ошибок за счет переноса тестирования на более ранние этапы [65] привело к появлению новых подходов к тестированию:
- смешение процесса тестирования с процессом разработки (Test Driven Development, разработка тестов до начала написания продукта - чаще всего такие тесты подготавливаются
разработчиками) [66].
- Внедрение процедур, обеспечивающих предупреждение дефектов [67] [68] следования формальным правилам, инспекции кода с привлечением инженеров по тестированию, что приводит к их вовлечению в процесс разработки.
- Внедрение принципов экстремального программирования [69] [70] [71], в частности «принцип непрерывной интеграции», при котором каждое изменение в продукте сопровождается построением продукта и исполнением, а при необходимости исправлением/написанием набора автоматизированных тестов, а также парное программирование, когда процесс написания программы совмещен с процессом инспекции/тестирования. Все перечисленные выше тенденции подразумевают наличие большого количества тестов. Кроме того, необходимым условием является возможность их исполнения и получения статуса о состоянии продукта в ограниченное время. С учетом тенденции на сокращение времени цикла разработки, единственным способом удовлетворить указанные требования является автоматизация тестов и процесса тестирования [1].
Модификация продукционной модели базы знаний
Продукционная модель баз знаний является гибким инструментом, позволяющим эффективно строить экспертные системы для различных областей. Особенности этой модели, также как и особенности предметной области, требуют модификация общей модели для заданной предметной области. В данной главе рассматриваются модификации базовой модели продукционной базы знаний для работы в предметной области поддержки автоматизированного тестирования программных комплексов.
Как говорилось в главе 1, базовый формат правил продукционной модели имеет следующий вид.
(k) ЕСЛИ Ai и Aj . . . ТО Bl (2.1)
Где:
k - идентификатор правила,
А - множество допустимых условий,
В - множество допустимых действий.
В процессе модификации продукционной модели к предметной области автоматизированного тестирования была проанализирована статистика исполнения тестов в системе автоматизированного тестирования (см главу 3). В результате были выделены:
множество объектов в предметной области (данное множество отображается в базе знаний через состояния объектов) - сборка продукта, сборка тестов, тестовые устройства, тестовая задача и т. д.;
множество возможных состояний объектов в предметной области отображается на множество условий (А) - для тестовой задачи это: не запущен, в очереди на исполнение, исполняется, завершил исполнение;
множество операций, приводящих объекты в определенное состояние, отображается на множество допустимых действий - для тестовой задачи это: перезапуск, перезапуск на другом тестовом устройстве, отправка уведомления разработчику теста и т.д.
Наряду с достоинствами, у продукционных систем есть ряд недостатков. К недостаткам продукционной модели можно отнести наличие конфликтов двух типов [40] [41]:
Формальные конфликты, которые возникают, когда в процессе жизненного цикла в базе знаний возникают несколько правил с одинаковыми левыми частями, но разными правыми.
Конфликты, возникающие при интеграции проектов высокого уровня сложности, когда существует несколько различных подходов к решению одной и той же задачи.
Оба типа конфликтов вносят неоднозначность в процесс принятия решения. В случае конфликтов первого типа можно ввести в рассмотрение дополнительный параметр объекта, тем самым дифференцировав два состояния и правила. Но в реальных системах не всегда можно получить достаточную детализацию состояния объекта. В результате одни и те же «симптомы» могут описывать различные «реальные» состояния объекта и требовать различные действия. Поэтому невозможно гарантировать отсутствие формальных конфликтов в базе знаний. Несмотря на то, что возникновение конфликтов альтернативных решений маловероятно, так как в рассматриваемом случае предметная область достаточно ограничена, при этом за счет разбиения всей предметной области на фрагменты, соответствующие типовым задачам, достигается уменьшение вероятности возникновения подобных конфликтов, но исключить их возникновение нельзя.
Таким образом, наличие конфликтов обоих видов являются неотъемлемым свойством продукционной модели баз знаний. А так как конфликты могут возникать на протяжении всего жизненного цикла продукционной системы, что обусловлено тем, что ожидается появление новых знаний о предметной области в процессе работы СИП, то требуется формализовать и автоматизировать средства разрешения подобных ситуаций. В обоих случаях возникает более одного правила с одинаковыми левыми частями. Необходимо разработать механизм приоритезации подобных правил и выполнения одного из них. Возможны различные подходы к порядку перебора:
применять случайное правило с использованием генератора псевдослучайных чисел - наиболее простой способ с точки зрения реализации, но наименее эффективный, так как не предсказуем и не позволяет строить оптимальные сценарии,
применять последнее правило позволившее достичь результата - такой подход хорошо работает для двух правил и показывает неудовлетворительные результаты с точки зрения оптимальности сценария при большем количестве альтернативных правил,
применять правила в соответствии с предопределенным приоритетом -хорошо работает в статическом окружении, но быстро меняющаяся среда требует постоянного изменения приоритетов для сохранения оптимальности сценариев,
применять правила в соответствии с частотой их успешного срабатывания за предыдущий период - наиболее гибкая и хорошо формализуемая система приоритетов.
В данной работе предлагается уменьшить нагрузку на экспертную систему за счет сокращения числа применяемых правил. Для этого вводится два уровня приоритетов. Экспертный коэффициент (Mf) - задается администратором БЗ, на этапе наполнения базы знаний на основе предыдущего опыта использования САТПК. Так как количество правил в каждом фрагменте базы знаний не превышает тридцати, администратор базы знаний может задать приоритеты вручную.
Мf = X (2.2)
Данный коэффициент используется, когда несколько правил имеют одинаковый приоритет. Это особенно актуально на начальном этапе работы СИП, когда не достаточно данных для использования статистических критериев. Но и в процессе жизненного цикла подобных систем могут возникать ситуации, когда несколько правил имеют одинаковую частоту применения.
Кроме того, предлагается ввести статистический коэффициент вычисляемый как частота активации правила приведшая к успешному результату.
Мh = C/T (2.3)
Где:
C – количество исполнений правила за истекший период, приводившее к успешному результату;
T – длительность периода подсчета частоты.
Выбор оптимальной длительности периода важно, так как в изменяющейся среде наиболее часто встречающиеся проблемы так же изменяются. На основании анализа статистики длительность периода выбрана 7 дней.
При этом требуется сократить число шагов для достижения желаемого результата. Это означает что правило, которое мгновенно приводит к желаемому результату должно вызываться в первую очередь. Правило, которое требует дополнительных проверок для достижения результата менее приоритетно. Для автоматической оценки правил вводится дополнительный коэффициент, описывающий количество правил, вызванных после текущего до достижения результата. В результате данный приоритет принимает вид:
Мh = F/T 1/N (2.4) где N - количество правил, активированных после текущего до достижения цели за прошедший период.
Количество приоритетов может быть расширено для более эффективного управления БЗ.
Предметная область системы автоматизированного тестирования является достаточной сложной. Большое количество параметров и состояний может привести к сложностям в построении и поддержке сценариев в базе знаний. Возможно 2 пути сбора данных для работы сценария:
Сбор всех данных, который могут потребоваться при работе сценария. Первичный сбор данных перед стартом сценария может занять значительное время, за это время, либо будет простаивать тестовое устройство, либо могут возникнуть отказы следующих тестовых задач. В обоих случаях происходит значительная потеря машинного времени, а также времени персонала, затрачиваемого на перезапуск тестовых задач. При этом большая часть собранных данных не будет использована, так как в оптимальном сценарии обходится минимальная часть веток дерева сценария.
Автоматизация формирования базы фактов
Система CLIPS для своей работы требует предоставления входных данных в определенном формате. Для наиболее эффективной работы продукционной системы все данные сохраняются в базе фактов, которая представляет из себя формализованную информацию о состоянии анализируемого объекта.
Источником исходных данных выступают:
Тесты:
- информация о состоянии тестовой задачи;
- отчеты с результатами тестирования в виде текстовых файлов;
- текстовые отчеты о состоянии тестов в системе непрерывной интеграции;
- информация о состоянии тестовой задачи в базе данных.
Информация о тестовом окружении, влияющем на процесс тестирования:
- текстовые отчеты о состоянии ОС, программного и аппаратного обеспечения на тестовых устройствах;
- текстовые отчеты о состоянии эмуляторов;
- информация о состоянии сетевой инфраструктуры, в виде текстовых отчетов исполняемых команд. При этом процесс обработки исходных данных разбивается на ряд этапов:
Получение текстовой информации посредством запуска команды, которая либо читает заранее сформированный файл отчета, либо формирует его, запуская соответствующее приложение. На момент разработки модуля интеллектуальной поддержки САТПК уже была разработана и внедрена. Данная система имеет средства генерации и сбора файлов отчетов.
Разбор нормализованного файла отчета, и генерация фактов на основании данных из него.
Чаще всего информация о состоянии объекта контроля представляется в текстовом виде: файлы тестовых отчетов, вывод различных служебных утилит. При этом из-за гетерогенности тестовой инфраструктуры и разнообразия используемых технологий файлы отчетов не стандартизированы. На первом этапе анализа осуществляется сбор всей возможной информации (файлы тестовых отчетов, информация из ОС, сети и т.д.), сохранение ее в отдельную папку на сетевом диске, соответствующую тесту (осуществляется СНИ). САТПК содержит средства генерации и сбора файлов отчетов. Кроме того, информация о статусе тестов сохраняется в базе данных MySQL.
Используются Python скрипт, который анализирует все возможные входные данные;
файлы отчетов в заданной директории;
информация из базы данных MySQL;
вывод выполненных команд; и генерирует один файл с новым фактом. Скрипт разбит на несколько модулей, в каждом из которых реализован разбор одного из типа файла отчета, или запуск и анализ утилиты для получения данных об объекте (Рисунок 3.5).
Каждый файл содержит набор шаблонов и команд:
команда:
- либо находящая и отображающая содержимое файла отчета по шаблону; о либо исполняющая системную утилиту и отображающая ее вывод;
шаблон для анализа текстовых данных - регулярное выражение, определяющее состояние одного из параметров дескриптора ситуации.
В результате работы скриптов формируется файл, содержащий факт об объекте анализа. Ниже представлен пример факта для тестовой инфраструктуры, созданный с использованием шаблона, введенного в главе 2. Для активации правила в продукционной базе, каждый факт должен быть уникален. Для этого введены дополнительные поля:
сетевое имя (hostname);
время в формате секунды с 01.01.1970 года (time).
В результате шаблон факта примет вид:
(deftemplate device-mon
(slot hostname (type STRING))
(slot time (type NUMBER))
(multislot repair (default unknown)) (multislot tests_executing (default unknown)) (multislot test_result (default unknown)) (multislot test_fail (default unknown)) (multislot ci_available (default unknown)) (multislot ci_config (default unknown)) (multislot network (default unknown)))
А пример ( device-mon (hostname (time (tests_executing (test_result (test_fail (ci_available (ci_config (network )
факта примет вид:
“host123”) ;
1477115329) ;
true) ;
available) ;
share_unavailable) ;
active) ;
configured) ;
available) ;
идентификатор дескриптора ; сетевое имя устройства ; дата/время сбора факта ; корректирующее действие ; тесты исполняются ; тестовые отчеты доступны ; причина тестовых ошибок ; доступность агента СНИ ; конфигурация агента СНИ ; доступность устройства ; по сети имя шаблона сетевое имя устройства дата/время сбора факта тесты исполняются тестовые отчеты доступны недоступен сетевой диск СНИ агент активен конфигурация СНИ агента верна устройство доступно по сети
Результатом работы сценария является срока, соответствующая имени скрипта. Данный скрипт запускается и выполняет заданное корректирующее действие используя текстовый файл фактов.
Результаты внедрения пилотной системы
В данной работе используется интегральный критерий эффективности системы интеллектуальной поддержки аккумулирующий несколько частных параметров. Единицей измерения работы является тестовый цикл - полный набор тестов, которые необходимо выполнить, для получения информации о качестве продукта. Каждый частный параметр измеряется для одного тестового цикла. Рассматриваются следующие параметры:
Доля отказов, выявленных автоматическом режиме (Qвыявл).
Доля отказов, исправленных в автоматическом режиме (Qисправ).
Время необходимое для получения информации о качестве продукта -полное время тестового цикла (Tцикла).
Время затрачиваемое персоналом на анализ одного тестового цикла (Tперс)
Доля оборудования, выведенного из тестирования из-за отказов (Qобор)
Критерий эффективности выражается в виде формулы (9). Уменьшение значения данного критерия говорит о росте эффективности интеллектуальной поддержки.
Пилотная версия интеллектуального модуля была внедрена в базовом проекте. Внедрение происходило в 3 этапа:
На первом этапе интеллектуальный модуль анализировал исторические данные. Результаты работы системы интеллектуальной поддержки сравнивались с результатами анализа, проведенного тестовыми инженерами в процессе ежедневной работы. Нужно отметить, что так как анализ велся только на основании файлов отчетов (невозможно исполнять интерактивные команды для исторических данных), контролировались только те состояния объектов, информация о которых может быть получена из этих отчетов.
На втором этапе система работала с актуальными данными и предоставляла инженерам свои рекомендации. Инженеры принимали решение о верности или неверности результатов анализа предоставленных системой интеллектуальной поддержки. После чего применяли или не применяли корректирующие действия.
На третьем этапе система работала в автоматическом режиме, когда корректирующее действие применялось без участия человека (если это возможно).
На всех этапах помимо верификации работы системы происходила ее корректировка и обновление базы знаний. Критерием качества работы интеллектуального модуля является отсутствие регрессий. Под регрессией понимается неверный результат анализа для заданного известной инфраструктурной проблемы. Например:
Если интеллектуальный модуль перестал детектировать проблему недоступности сетевого диска, это является регрессией.
Если интеллектуальный модуль не смог предоставить анализ для ранее не встречавшейся инфраструктурной проблемы и уведомил тестового инженера о необходимости ручных исследований, это не является регрессией.
Как уже говорилось выше на первом этапе использовались данные по тестовым запускам, которые уже были проанализированным тестовыми инженерами. Использование исторических данных позволило с одной стороны отладить базу знаний, с другой убедиться в работоспособности подхода без влияния на рабочий процесс.
Основными задачами в рамках первого этапа внедрения были:
проверка работоспособности базы знаний, в том числе убедиться в верности результата анализа;
исправление всех выявленных проблем.
На первом этапе использовались файлы тестовых отчетов, собранные за 3 месяца. Процесс анализа проводился итеративно. По мере выявления проблем вносились изменения в базу знаний, скрипты подготовки фактов и другие элементы инфраструктуры. После того как все файлы отчетов были обработаны процесс начинался сначала. Признаком окончания этапа было анализ всех выбранных файлов тестовых отчетов без выявления проблем в инфраструктуре и интеллектуальном модуле (регрессий).
В результате внедрения, на первом этапе 78% инфраструктурных проблем были выявлены интеллектуальной системой поддержки.
На втором этапе интеллектуальный модуль был внедрен в систему автоматизированного тестирования в режиме консультирования тестового инженера. Для любого тестового запуска инженеру предоставлялся результат анализа интеллектуальным модулем поддержки автоматизированного тестирования. Инженер проводил собственное исследование и оценивал работу интеллектуального модуля (соответствует ли результат ее анализа реальной причине проблемы).
В случае выявления проблем в интеллектуальном модуле отчет о несоответствии предоставлялся разработчику, который корректировал базу знаний, или инфраструктуру интеллектуального модуля для достижения корректного результата работы системы интеллектуальной поддержки.
Помимо этого, были внедрены проверки, требующие интерактивного доступа к элементам тестовой инфраструктуры (сетевым дискам, СНИ, тестовым устройствам), например, проверка доступности сетевого диска.
В результате, в течение второго этапа количество выявленных инфраструктурных проблем от их общего количества сначала снизилось до 70% (из-за проблем внедрения), но к концу этапа выросло до 90%.
Признаком завершения данного этапа являлось отсутствие регрессии в течение недели активного использования интеллектуальной системы поддержки автоматизированного тестирования.
На третьем этапе внедрялась автоматизированная система коррекции элементов инфраструктуры. При этом произошел незначительный рост процента обнаруженных проблем (с 90% до 92%) за счет дальнейшего совершенствования базы знаний.
Зависимость процента выявленных проблем от этапа внедрения представлена на рисунке.
После внедрения системы автоматизированной коррекции выявленных сбоев часть ошибок часть инфраструктурных ошибок исправляются в автоматическом режиме (Рисунок 3.7).
Основными результатами внедрения системы автоматизированной коррекции стали:
Снижение доли простаивающего оборудования. Одним из проявлений инфраструктурных проблем является мгновенное «падение» исполняющегося теста. Если существует несколько идентичных тестовых устройств и на одном из них появляется подобная проблема, в течение 10-15 минут очередь тестов, рассчитанная на исполнение в течение 5-10 часов, завершается, проходя через проблемное устройство. В результате простаивают как проблемное, так и работоспособные устройства той же конфигурации. Анализ данных по работе системы автоматизированного тестирования показал, что около 10% времени тестовые устройства простаивают из-за подобных проблем.