Система поддержки принятия решений при выборе способа тестирования программных систем тема диссертации и автореферата по ВАК РФ 00.00.00, кандидат наук Галимова Екатерина Юрьевна

• Галимова Екатерина Юрьевна
• кандидат наук
• 2023

Оглавление диссертации кандидат наук Галимова Екатерина Юрьевна

ВВЕДЕНИЕ

ГЛАВА 1. ОСОБЕННОСТИ РУЧНОГО И АВТОМАТИЗИРОВАННОГО ТЕСТИРОВАНИЯ

1.1. Развитие подходов к тестированию программных систем

1.2. Формирование понятия качества и процесс его оценки

1.3. Анализ процесса формирования отношений предпочтения

1.4. Применение информационных систем для поддержки принятия решений

1.5. Тестирование как часть жизненного цикла ПС

1.6. Модель качества ПС

1.7. Классические методы оценки затрат на автоматизацию тестирования

1.8. Постановка задачи исследования

1.9. Выводы по первой главе

ГЛАВА 2. ФОРМИРОВАНИЕ СИСТЕМЫ ХАРАКТЕРИСТИК ПС И РАЗРАБОТКА МОДЕЛИ РЕЗУЛЬТИРУЮЩЕГО ВИДА ТЕСТИРОВАНИЯ

2.1. Преимущества ручного тестирования

2.2. Преимущества автоматизированного тестирования

2.3. Системный анализ ПС для решения задачи тестирования

2.4. Задание свойств ПС с помощью вопросов

2.5. Вопросы как характеристики ПС

2.6. Модель результирующего вида тестирования ПС

2.7. Выводы по второй главе

ГЛАВА 3. РАЗРАБОТКА АЛГОРИТМА РАСЧЕТА ДОЛИ АВТОМАТИЗИРОВАННОГО ТЕСТИРОВАНИЯ И МЕТОДИКИ ОЦЕНКИ СТОИМОСТИ ТЕСТИРОВАНИЯ

3.1. Формирование группы экспертов

3.2. Расчет групповых оценок вопросов и коэффициентов компетенции экспертов

3.3. Постановка задачи тестирования как многокритериальной задачи

3.4. Алгоритм расчета доли автоматизированного тестирования

3.5. Методика оценки стоимости процесса тестирования

3.6. Метрический базис сложности программной системы

3.7. Адекватность алгоритма расчета доли автоматизированного тестирования

3.8. Выводы по третьей главе

ГЛАВА 4. РАЗРАБОТКА ИНФОРМАЦИОННОЙ СИСТЕМЫ ПОДДЕРЖКИ ПРИНЯТИЯ РЕШЕНИЙ ПРИ ВЫБОРЕ СПОСОБА ТЕСТИРОВАНИЯ ПС

4.1. Требования к системе поддержки принятия решений

4.2. Структура информационно-советующей системы

4.3. Особенности инструментов программной реализации ИСС

4.4. Блок-схема алгоритма для программной реализации ИСС

4.5. Программная реализация ИСС

4.6.Оценка повышения эффективности за счет внедрения ИСС

4.7. Выводы по четвертой главе

ЗАКЛЮЧЕНИЕ

СПИСОК СОКРАЩЕНИЙ И УСЛОВНЫХ ОБОЗНАЧЕНИЙ

СПИСОК ЛИТЕРАТУРЫ

Приложение А. Список экспертной комиссии

Приложение Б. Критериальная характеристика экспертной комиссии

Приложение В. Метрический базис сложности ПС

Приложение Г.1 Описание вопросов как характеристик ПС, ведущих в целом к выбору автоматизированного тестирования

Приложение Г.2 Описание вопросов как характеристик ПС, ведущих к необходимости значительной доли ручного тестирования

Приложение Г.3 Описание вопросов как характеристик ПС, ведущих к равновесному сочетанию ручного и автоматизированного тестирования

Приложение Д. Акт о внедрении результатов диссертационной работы в ООО «Импульс 3А»

Приложение Е. Акт об использовании результатов диссертационной работы в ВШПМ СПбГУПТД

Приложение Ж. Свидетельство о государственной регистрации программы для ЭВМ

Введение диссертации (часть автореферата) на тему «Система поддержки принятия решений при выборе способа тестирования программных систем»

ВВЕДЕНИЕ

Актуальность темы исследования. В условиях роста числа задач, для решения которых применяются различные программные системы (ПС), каждая из которых представляет совокупность программного и аппаратного обеспечения, взаимодействующих между собой, проблема оценивания их качества занимает особое место в общем комплексе исследований, что приводит к новым задачам, для решения которых уже недостаточно последних достижений в области обеспечения качества ПС. По стандарту ISO/IEC 25000:2014, качество ПС есть способность при заданных условиях удовлетворять определенным или предполагаемым пользовательским потребностям. Тестирование является частью процесса обеспечения качества и представляет собой системный анализ, в процессе которого необходимо вникнуть в суть связей в ПС. Одним из принципиальных вопросов при планировании тестирования является выбор между автоматизированным и ручным методами проверки ПС или её отдельных модулей. Поскольку для отдельных модулей выбор может быть различен, то фактически речь идёт о сочетании этих методов, это является важной особенностью оценки качества ПС.

В концепции жизненного цикла ПС этап тестирования является одним из самых трудоёмких и дорогостоящих. Согласно исследованиям Камаева В. А. [1], заслуженного деятеля науки РФ, для типового процесса создания ПС примерно 50% временных затрат и более 50 - 60% финансовых затрат приходится на этап тестирования ПС. Доля финансовых затрат на тестирование увеличивается с возрастанием сложности разрабатываемой системы и с повышением требований к ее качеству. Следовательно, тщательное планирование процесса тестирования является актуальной и важной задачей. Исследования Уильяма Э. Льюиса [2], проработавшего 40 лет в сфере информационных технологий в таких известных фирмах, как General Electric и IBM, автора 8 книг, показали, что при наличии эффективной концепции тестирования количество дефектов исследуемой системы обычно сокращается в 4 раза. Поскольку исправление ошибок в фазах

эксплуатации и обслуживания стоит от 20 до 100 раз дороже, общая экономия намного превышает расходы на тестирование.

Исчерпывающее тестирование невозможно. Например, для программы нахождения среднего арифметического 4 целых чисел, существует 264 комбинаций входных параметров. Программа выполняется примерно 0,001 секунду, следовательно, на её исчерпывающее тестирование требуется примерно 585 млн. лет [3]. Выработка наилучшего подхода к тестированию позволит проверить её за 1 день.

По данным World Quality Report [4], в среднем в мире отделы тестирования или центры компетенций по тестированию (Testing Center of Excellence) созданы в 26% организаций в ИТ-отрасли. Согласно расчету, проведенному НИУ ВШЭ [5], в России общее число организаций в ИТ-отрасли приближается к 70000. Резюмируя вышеизложенные факты, получаем, что более 18000 организаций в России проводят тестирование своих продуктов самостоятельно. Заинтересованность в создании новых подходов к тестированию существует у всех ИТ-компаний, что подчеркивает актуальность темы исследования.

Степень разработанности темы.

Методы тестирования программного обеспечения обсуждались в работах Майерса Г., Тейера Т., Канера С., Макгрегора Дж., Тамре Л., Бейзера Б., Котлярова В. П., Степанченко И. В., Криспина Л., Липаева В. В., Вигуры А. Н., Блэка Р. Вопросы разработки информационно-советующих систем в различных предметных областях отражены в работах Казакова О. Д., Остапчик В. П., Аверченкова А. В., Четыркина Е. А., Лыгина Н. И., Степанова А. С., Капустина С. В., Лапина Л. А., Горенского Б. М., Кирякова О. Г., Brandon A. Beemer, Dawn G. Gregg, Susan G. Hadden. Исследованиями проблемы автоматизации процесса тестирования занимались Дастин Э., Винниченко И. В., Бирюков С. В., Веденеев В. В., Linz T., Daigl M., Гребенюк В. М., Хамбл Дж., Sahaf Z., Garousi V., Pfahl D.,Irving R., Amannejad Y. В тоже время недостаточно исследований о принятии решений по выбору способа тестирования, основанного на критериях качества ПС. В процессе разработки стратегии тестирования ориентируются главным

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

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

Объектом исследования является процесс подготовки и проведения тестирования ПС.

Предметом исследования является процесс принятия решения по выбору способа тестирования ПС.

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

Для достижения поставленной цели были выделены и решены следующие задачи:

1. Провести системный анализ предметной области и сформировать систему характеристик ПС для решения задачи выбора способа тестирования.

2. Разработать модель, формализующую задачу выбора способа тестирования ПС.

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

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

5. Разработать концептуальную структуру информационно-советующей системы для прикладной реализации результатов исследования.

Научная новизна работы состоит в следующем:

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

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

3. Предложена методика оценки стоимости процесса тестирования, отличающаяся использованием метрики Холстеда «число потенциальных ошибок в программной реализации», а также формированием метрического базиса сложности ПС, позволяющая при принятии решения сопоставить результирующую стоимость развертывания процесса тестирования с заложенными в проекте бюджетными ограничениями на проведение тестирования.

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

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

процесса тестирования и ИСС по тематике исследования используются в профессиональной деятельности ООО «Импульс 3А», в учебном процессе направления «Информационные системы и технологии» Высшей школы печати и медиатехнологий Санкт-Петербургского государственного университета промышленных технологий и дизайна.

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

Положения, выносимые на защиту:

1. Модель, формализующая задачу выбора способа тестирования ПС.

2. Алгоритм расчета доли автоматизированного тестирования.

3. Методика оценки стоимости процесса тестирования.

4. Концептуальная структура ИСС при выборе подхода к тестированию ПС.

Степень достоверности полученных результатов подтверждается

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

Апробация работы. Основные положения и отдельные результаты исследования были доложены и обсуждены на 17 конференциях разного уровня: XV и XVII Международные конференции «Региональная информатика» (Санкт-Петербург, 2016, 2020); Всероссийская научно-практическая конференция «Проблемы сертификации, управления качеством и документационного обеспечения управления» (Красноярск, 2019); I Международная научно-практическая конференция «Цифровая трансформация промышленности: тенденции, управление, стратегии» (DTI2019) (Екатеринбург, 2019); III Международная научно-практическая конференция «Информационные технологии в образовании и аграрном производстве» (Брянск, 2020); XVIII Научный форум Уральской горнопромышленной декады (Екатеринбург, 2020); III Всероссийская научно-практическая конференция «Возможности и угрозы

цифрового общества» (Ярославль, 2020); I Международная научно-практическая конференция «Инновационные направления интеграции науки, образования и производства» (Керчь, 2020); Всероссийская научно-техническая конференция «Управление качеством в образовании и промышленности» (Севастополь, 2020); I Международная конференция CAMSTech-I 2020: Современные достижения в области материаловедения и технологий (Красноярск, 2020); II Всероссийской научной онлайн-конференции с международным участием «Концепции в современном дизайне» (Москва, 2020), XX и XXI Международные конференции по науке и технологиям Россия-Корея-СНГ (Москва, 2020, 2021), IV и V Всероссийские научно-практические конференции «День спортивной информатики» (Москва, 2020, 2021), Международная научно-практической конференция, посвященная 95-летию члена-корреспондента РАСХН, Заслуженного деятеля науки РСФСР и РД, профессора М.М. Джамбулатова (Махачкала, 2021); XXXII Международная научно-методическая конференция «Актуальные проблемы модернизации высшей школы: высшее образование в информационном обществе» (Новосибирск, 2021).

Публикации. По результатам исследования опубликовано 30 научных работ, в том числе: 9 в изданиях, рекомендуемых ВАК; 2 в сборниках трудов международных конференций, проиндексированных в БД Scopus и Web of Science. Имеется 1 свидетельство о регистрации программы для ЭВМ.

Структура и объем диссертации. Диссертационная работа состоит из введения, четырех глав, заключения, библиографического списка литературы, приложений. Она изложена на 147 страницах машинописного текста, включает 20 рисунков, 5 таблиц. Библиографический список литературы включает в себя 195 наименований.

ГЛАВА 1. ОСОБЕННОСТИ РУЧНОГО И АВТОМАТИЗИРОВАННОГО

ТЕСТИРОВАНИЯ

1.1. Развитие подходов к тестированию программных систем

Одной из первых классических книг, целиком посвященных тестированию программного обеспечения, стала книга Гленфорда Майерса «Искусство тестирования программ», вышедшая в 1979 году в США. Её перевод на русский язык увидел свет в 1982 году. Книга остаётся актуальной и в наши дни, в ней излагаются основные подходы к тестированию и отладке программ. Майерс предлагает методику количественной оценки качества программных комплексов, вводит метрики. Подчёркивается трудоёмкость процесса тестирования, которая составляет от 30 до 60 % общей трудоёмкости. Автор утверждает, что «программирующая организация не должна сама тестировать разработанные ею программы». [6] С течением времени стало понятно, что это не совсем верно. На сегодняшний день существует большое количество фирм, занимающихся разработкой программных продуктов, которые создали свой отдел тестирования. Таким образом полный цикл разработки и тестирования программного продукта осуществляется в таких командах за счёт собственных ресурсов.

В книге используется термин «ручное тестирование» (human testing) как «тестирование без применения ЭВМ». Говорится о высокой эффективности данного подхода. Ручное тестирование предлагается применять до автоматизированного. Подчёркивается неформальная природа первого подхода. Human testing включает такие методы, как математическое доказательство корректности программ, инспекции, проверки за столом.

Термин manual testing в контексте ручного тестирования с использованием компьютера, но без применения специально разработанных программных средств, в книге не встречается.

В толковом словаре по информатике, изданном в СССР в 1991 году, еще не упоминается термин «автоматизированное тестирование». Дается определение ручному тестированию (manual testing) [7].

Одним из первых изданий, опубликованных в России и полностью посвященных вопросам автоматизации тестирования, стала книга Винниченко И. В. «Автоматизация процессов тестирования», вышедшая в 2005 году. В ней освещаются практические вопросы автоматизации тестирования, рассматриваются актуальные на то время инструменты автоматизации: Segue SilkTest, Mercury Interactive WinRunner, Rational Robot. Выбор между ручным и автоматизированным тестированием предлагается делать, основываясь на «экономической целесообразности автоматизации», которая рассчитывается по разработанной автором формуле [8]. В расчётах не учитывается, применяется ли на данный момент ручное тестирование или тест-план разрабатывается с нуля, не рассматриваются особенности программного продукта. Рассматриваются только стоимостные метрики автоматизации (зарплата персонала, цена специального программного обеспечения).

В учебном пособии «Основы тестирования программного обеспечения», изданном в России в 2010 году, авторами которого являются Котляров В. П. и Коликова Т. В., затрагивается вопрос сравнения ручного и автоматизированного тестирования [9]. Сравнение производится по следующим критериям: задание входных значений, проверка результата, повторяемость, надёжность, чувствительность к незначительным изменениям в продукте, скорость выполнения тестового набора, возможность генерации тестов.

Гибкость в задании входных значений и в проверке результата отдаётся авторами ручному тестированию. Указывается «не повторяемость» ручного тестирования. При этом не рассматривается возможность создания правильной тестовой спецификации, в которой подробно пошагово записаны все тестовые проверки. Правильная организация процесса ручного тестирования позволяет повысить его повторяемость. Высокая скорость выполнения тестового набора отдаётся автоматизированному тестированию. Нет упоминания о том, что высокой скорости выполнения автоматизированных тестов предшествуют большие временные затраты по их написанию и по настройке тестового окружения. Редко используемые тестовые сценарии высокой скоростью

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

В этом же, 2010 году, в США была издана книга Джез Хамбл и Дэвид Фарли «Непрерывное развёртывание ПО: автоматизация процессов сборки, тестирования и внедрения новых версий программ». Она очень быстро завоевала популярность во всем мире, в частности, в России была напечатана в 2011 и в 2016 годах. Цель данной книги - помочь читателю перейти от ручного процесса поставки программного обеспечения к автоматизированному. Авторы являются активными сторонниками автоматизации, однако оставляют место и для ручного тестирования. После автоматизированного приёмочного тестирования рекомендуется проводить ручное исследовательское тестирование. По словам Джеймса Баха, в процессе исследовательского тестирования «тестировщик активно управляет структурой тестов и применяет получаемую при этом информацию для создания новых, лучших тестов» [10]. Также нужны ручные тесты удобства использования.

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

В 2011 году издательство Wiley в США выпустило дополненное издание книги Гленфорда Майерса «Искусство тестирования программ». По сравнению с первым изданием, были добавлены главы «тестирование в среде гибкой разработки», «тестирование интернет-приложений», «тестирование мобильных приложений», в которых изложены концепции тестирования новых направлений на рынке программных продуктов [11]. В новых главах делается акцент на автоматизированном тестировании, алгоритмы ручного тестирования не обсуждаются. В России книга опубликована в 2012 году и допечатана в 2016 году.

Научно-исследовательская работа по исследованию преимуществ автоматизированного тестирования была проведена компанией imbus GmbH в конце двадцатого столетия [12]. Исследование проводилось только в области тестирования графических пользовательских интерфейсов. Одни и те же функции приложения тестировались параллельно ручными и автоматизированными методами. Затем по предложенной авторами формуле вычислялся коэффициент уменьшения расходов при внедрении автоматизации. В данном подходе не учитывались ресурсы на модификацию автоматизированных тестовых скриптов. Расчёт значений можно осуществить только после проведения одного цикла ручного и автоматизированного тестирования.

В области разработки методов автоматизации тестирования проведено значительное число исследований, в том числе: метод автоматизации функционального тестирования web-сервисов [13]; метод автоматизации тестирования автоматизированных систем управления на основе контроля неожидаемых, a также ожидаемых событий [14]; подход к автоматизации тестирования на основе символьного выполнения программы [15]; метод автоматизации тестирования на основе графов переходов конечных автоматов [16].

Исследования в области тестирования нашли своё отражение в ряде диссертационных работ. Перечислим несколько из разработанных направлений исследований: тестирование на основе семантических моделей [17], разработка узкоспециальных методов тестирования современных микропроцессоров [18, 19],

специальный метод автоматизированного тестирования мобильных устройств [20], метод редукции для интеграционного тестирования [21], метод мониторинга качества объектно-ориентированного программного обеспечения на этапе проектирования [22].

Начальные исследования по вопросу выбора между автоматизированным и ручным тестированием проводились в работах [23], [24], но они носят алгоритмический характер, без программной реализации. Анализ производится на малом числе параметров. Можно сделать вывод, что недостаточно исследований о принятии решений по выбору способа тестирования, основанного на критериях качества ПС, недостаточно проработаны вопросы создания информационно-советующих систем, ускоряющих процесс принятия решений о выборе подхода к тестированию ПС.

1.2. Формирование понятия качества и процесс его оценки

Категория «качество» имеет несколько аспектов, поэтому исследуется специалистами разных отраслей науки и техники. Рассмотрим основные из этих аспектов [25].

Качество как философская категория. В древней философии Индии качеством называлось то, что существует в субстанции, не проявляет активности и не имеет своих отличительных свойств. Оно является непроизводящей причиной вещей. Индийские философы выделяли 24 типа качеств [26]. Греческий философ Аристотель определил «качество», с одной стророны, как видовое отличие сущности, а с другой - как характеристику состояния сущности [27]. Средневековая схоластика пришла к «мистическому» пониманию качества, приписав ему «скрытые», «неизменные», «вечные» формы [28]. В 17 - 18 веках материалисты перешли к механическому пониманию данной категории. Ограниченность такого подхода пытается преодолеть немецкая философия. И. Кант сформировал представление о качестве, которое используется в наши дни во многих справочниках. Речь идет о том, что первичные качества идеальны, а вторичные реальны. Эрнст Кассирер, на рубеже 19 и 20 веков, связал понятие

качества с сущностью научного мышления. Переход от качества к количеству он называет «специфической познавательной задачей» научного метода, одной из граней сущности научного мышления [29].

Вектор современной концепции качества направлен от глобальных мировых объектов к локальным и затем к индивидуальным. Особенность текущей ситуации в том, что субъекты и объекты концепции качества могут меняться местами. Человек делает объектом своих действий качество, при этом сам может рассматриваться как объект революции качества [30]. Подводя итог представленного выше анализа, можно подчеркнуть, что исследование категории качества присутствует в большинстве философских систем как важная компонента взглядов человека на мир.

Качество как пользовательская пригодность является отражением взгляда потребителя. Сложность состоит в том, что требования пользователя непостоянны. На них оказывает влияние ряд факторов, например, конкурентная борьба, мода, законодательные нормы.

Качество как совокупность внутренних характеристик ПС включает те свойства продукта, которые видят разработчики. К внешним характеристикам обычно относят надежность, функциональность, сопровождаемость, стоимость. Внутренние характеристики включают в себя размер, сложность, стилистические особенности (например, документов или отдельных компонентов ПС) [31].

На некоторых уровнях анализа системы внутренние характеристики качества могут влиять на внешние. Например, когда ПС неудобна для сопровождения, в ней сложно исправлять ошибки, что оказывает воздействие на надежность и корректность (внешние характеристики ПС).

Качество как стоимость объекта подробно рассматривается у К. Маркса в «Капитале». Любую полезную вещь возможно анализировать с разных точек зрения, а именно с позиции количества или качества. Если вещь полезна, она становится «потребительной стоимостью», таким образом качество связано с конкретной денежной суммой, которую готов заплатить покупатель.

С позиции производителя качество есть степень соответствия продукта спецификации, модели, опытному образцу. Можно выделить несколько направлений развития термина качества: для продукции, для процессов, для ресурсов.

Н. Кано предложил модель «профиль качества», которая является частью систематизированного подхода под названием «структурирование функции качества (СФК)» [32]-[34]. Он позволяет производителю составлять правильное и максимально полное представление об ожиданиях потребителя, а также реализовать их через структурирование операций и функций деятельности организации. Для успешной реализации данного подхода производитель должен правильно составить «профиль качества» продукта. Он состоит из нескольких уровней.

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

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

Профиль желаемого качества включает в себя параметры, отражающие скрытые характеристики продукта, то есть такие качества продукта, о наличии которых пользователь мог мечтать, но не придумывал их самостоятельно. Хорошо, если параметры желаемого качества останутся недоступными для конкурентов продолжительное время. Следует помнить, что с течением времени желаемые параметры могут стать требуемыми.

Список литературы диссертационного исследования кандидат наук Галимова Екатерина Юрьевна, 2023 год

СПИСОК ЛИТЕРАТУРЫ

1. Камаев, В. А. Технологии программирования / В. А. Камаев, В. В. Костерин. - М.: Высшая школа, 2006. - 454 с.

2. Lewis, W. E. Software testing and continuous quality improvement. - CRC Press, 2009. - 640 p.

3. Павлова, М. В. Тестирование программ / М. В. Павлова // Компьютерные инструменты в образовании. - 2002. - № 3-4. - С. 30 - 43.

4. Исследование: Центры тестирования ПО российских компаний пока не демонстрируют бизнес-эффективность [Электронный ресурс]: https://www.cnews.ru/reviews/2014/articles/issledovanie_tsentry_testirovaniya_po_ross ijskih_kompanij_poka (дата обращения: 02.08.2022).

5. Министерство цифрового развития, связи и массовых коммуникаций РФ. Статистика: ИТ-отрасль. [Электронный ресурс]: https://digital.gov.ru/ru/activity/statistic/rating/it-otrasl/ (дата обращения: 02.08.2022).

6. Майерс, Г. Искусство тестирования программ/ Г. Майерс / Пер. с англ. под ред. Б. А. Позина. - М.: Финансы и статистика, 1982 - 176 с.

7. Першиков, В. И. Толковый словарь по информатике / В. И. Першиков, В. М. Савинков. - М.: Финансы и статистика, 1991. - 543 с.

8. Винниченко, И. В. Автоматизация процессов тестирования / И. В. Винниченко. - СПб.: Питер, 2005. - 203 с.

9. Котляров, В. П. Основы тестирования программного обеспечения: учебное пособие / В. П. Котляров, Т. В. Коликова. - М.: Интернет-Университет Информационных Технологий; БИНОМ. Лаборатория знаний, 2010. - 285 с.

10. Хамбл, Дж. Непрерывное развёртывание ПО: автоматизация процессов сборки, тестирования и внедрения новых версий программ / Дж. Хамбл, Д. Фарли / Пер. с англ. - М.: ООО «И.Д. Вильямс», 2016. - 432 с.

11. Майерс, Г. Искусство тестирования программ / Г. Майерс, Т. Баджет, К. Сандлер. - 3-е изд. / Пер. с англ. - М.: ООО «И.Д. Вильямс», 2016. - 272 с.

12. Linz, T., Daigl, M. GUI Testing Made Painless. Implementation and results of the ESSI Project Number 24306, 1998. In: Dustin, et. al., Automated Software Testing.

- Addison-Wesley, 1999. - p. 52.

13. Бирюков, С. В. Автоматизация функционального тестирования WEB-сервисов / С. В. Бирюков // Известия южного федерального университета. - 2008.

- № 2. - С. 175-178.

14. Гришанов, И. В. Разработка механизма тестирования модулей программ автоматизированных систем управления / И. В. Гришанов // «Труды МАИ» [Электронный ресурс]. - 2014. -№ 74. http://trudymai.ru/published.php?ID=49320 (дата обращения: 02.08.2022)

15. Вигура, А. Н. Анализ и тестирование программ на основе алгебраической модели / А. Н. Вигура // Вестник Нижегородского университета им. Н. И. Лобачевского. - 2011. -№ 5 (1). - С. 185-190.

16. Веденеев, В. В. Автоматизация тестирования использования программных интерфейсов приложений на основе моделирования конечными автоматами / В. В. Веденеев (Руководитель А. А. Шалыто). [Электронный ресурс]: http://is.ifmo.ru/testing/vedeneev/ (дата обращения: 02.08.2022).

17. Бурдонов, И. Б. Теория конформности для функционального тестирования программных систем на основе формальных моделей: дис. ... доктор физ.-мат. наук: 05.13.11/ Бурдонов Игорь Борисович. - М., 2008. - 596 с.

18. Чибисов, П. А. Встречное тестирование высокопроизводительных микропроцессоров: дис. ... канд. техн. наук: 05.13.11 / Чибисов Пётр Александрович. - М., 2013. - 174 с.

19. Зубковская, Н. В. Метод тестирования производительности и корректности микропроцессоров при помощи нацеленных тестовых программ: автореф. дис. ... канд. техн. наук:05.13.11 / Зубковская Наталья Владимировна. -М., 2013. - 24 с.

20. Хатько, Е. Е. Исследование и разработка метода, моделей и алгоритмов тестирования приложений для мобильных устройств: автореф. дис. ... канд. техн. наук: 05.13.11 / Хатько Евгений Евгеньевич. - М., 2013. - 21 с.

21. Кичигин, Д. Ю. Метод редукции тестового набора для интеграционного тестирования: дис. ... канд. физ.-мат. наук: 05.13.11/ Кичигин Дмитрий Юрьевич.

- М., 2010. - 148 с.

22. Морозов, А. В. Мониторинг качества объектно-ориентированного программного обеспечения на этапе проектирования: автореф. дис. ... канд. техн. наук: 05.13.01 / Морозов Александр Васильевич. - Астрахань, 2009. - 20 с.

23. Dustin, E., Rashka, J., Paul, J. Automated Software Testing: Introduction, Management and Performance. - Addison-Wesley, 2008. - p. 575.

24. Как и когда внедрять автотесты: преимущества и недостатки автоматизации тестирования [Электронный ресурс]: https://quality-lab.ru/Ыog/как-и-когда-внедрять-автотесты-преиму/ (дата обращения: 02.08.2022).

25. Галимова, Е. Ю. Выбор метода тестирования как способ повышения качества программного продукта / Е. Ю. Галимова // Проблемы сертификации, управления качеством и документационного обеспечения управления [Электронный ресурс]: сборник материалов Всероссийской научно-практической конференции (23 марта 2019 г., Красноярск). - С. 8 - 11.

26. Фрайман, А. С. «Качество» как философская категория / А. С. Фрайман // Вестник Челябинского государственного университета. - 2012. - №9 (263). - С. 46-51.

27. Аристотель. Метафизика. - Ростов-на-Дону: Феникс, 1999. - 608 с.

28. Минасян, А. М. Диалектика как логика / А. М. Минасян. - Ростов-на-Дону: РИСИ, 1991. - 536 с.

29. Гаиденко, П. П. Научная рациональность и философский разум / П. П. Гаиденко. - М.: Прогресс-Традиция, 2003. - 528 с.

30. Maykova, A. V. Philosophical and methodological analysis of quality problems in the projection of the modern philosophy of quality // Science Time. - 2015.

- vol. 3 (15). - pp. 380-386.

31. Карпович, Е. Е. Оценивание качества программного обеспечения САПР на основе метрических характеристик / Е. Е. Карпович // Горный информационно-

аналитический бюллетень (научно-технический журнал). - 2013. - № 5. - С. 235243.

32. Ефимов, В. В. Спираль качества / В. В. Ефимов, В. М. Князев. -Ульяновск: УлГТУ, 2002. - 232 с.

33. Макэлрой, Дж. СФК. Построение дома качества. Почему и как структурирование функции качества распространяется в автомобильной промышленности / Дж. Макэйлор // Курс на качество. - 1992. - № 1. - с. 67-73.

34. Попов, М. Е. Разработка и постановка продукции на производство на основе структурирования функции качества / М. Е. Попов, А. М. Попов // Вестник машиностроения. - 2000. - №7. - с. 52-58.

35. Теория принятия и выбора решений. - М.: Наука. Главная редакция физико-математической литературы, 1982. - 382 с.

36. Орлов, А.И. Теория принятия решений / А. И. Орлов. - М.: Издательство «Экзамен», 2006. - 573 с.

37. Петровский, А.Б. Теория принятия решений / А. Б. Петровский. - М.: Издательский центр «Академия», 2009. - 400 с.

38. Надежность и эффективность в технике: справочник. В 10 т. / под общ. ред. В. Ф. Уткина. - Т. 3. Эффективность технических систем. - М.: Машиностроение, 1988. - С. 167 - 168.

39. Ларичев, О. И. Наука и искусство принятия решений / О. И. Ларичев. -М.: Наука, 1979. - 200 с.

40. Жуковин, В. Е. Модели и процедуры принятия решений / В. Е. Жуковин

// Проблемы и методы принятия решений в организационных системах управления. - М.: ВНИИСИ, 1985. - С. 35-44.

41. Шестаков, О. А. Методы выявления непрерывных индивидуальных предпочтений. / О. А. Шестаков // Многокритериальные задачи принятия решений. / Под ред. Д. М. Гвишиани и С. В. Емельянова. - М.: Машиностроение, 1978. - С. 83-95.

42. Orlovski, S. Decision-making with a fuzzy preference relation. // Fuzzy Sets and Systems. 1978. - Vol. 1(3). - pp. 155-168.

43. Dubois, D., Prade, H. Fuzzy sets and systems: Theory and application. -Academic Press, New York, 1980. - 393 p.

44. Chiclana, F., Herrera, F., Herrera-Viedma, E. Integrating three representation models in fuzzy multipurpose decision making based on fuzzy preference relations // Fuzzy Sets and Systems. - July 1998. - Vol. 97. - No. 1. - pp. 33-48.

45. Nur Syibrah Muhamad Naim, Mohd Lazim Abdullah, Che Mohd Imran Che Taib, Abu Osman Md. Tap. New fuzzy preference relations and its application in group decision making. // Mathematical and Computational Sciences. - 2009. - Vol. 3. - No. 6. URL: https://publications.waset.org/2189/new-fuzzy-preference-relations-and-its-application-in-group-decision-making (дата обращения: 02.08.2022).

46. Hryhoruk, P. M., Khrushch, N. A., Grygoruk, S. S. An approach to construct fuzzy preference relationships for managerial decision making. // Scientific bulletin of Polissia - 2017. - Vol. 4 (12). - No. 2. - pp. 92-99.

47. Шигина А. А. Применение технологии экспертной системы при построении интеллектуальных систем поддержки принятия решений / А. А. Шигина // Научно-методический электронный журнал «Концепт». - 2014. - Т. 20.

- С. 3566-3570. - [Электронный ресурс]: http://e-koncept.ru/2014/54977.htm (дата обращения 11.08.2022).

48. Bruegge, B. Software Lifecycles Models. URL: https://ase.in.tum.de/lehrstuhl_1/files/teaching/ws0607/So^ware%20Engineering%20I/ L17_SoftwareLifecycleModels.pdf (дата обращения: 02.08.2022).

49. Hamlet, D. Composing software components: a software testing perspective.

- Springer, 2010. - 368 p.

50. Шафер, Д. Ф. Управление программными проектами: достижение оптимального качества при минимуме затрат. / Д. Ф. Шафер, Р. Т. Фатрелл, Л. И. Шафер. - М.: Издательский дом «Вильямс», 2003. - 1136 с.

51. Денисова, Е. В. Основные подходы к моделированию жизненных циклов информационных технологий / Е. В. Денисова, Д. А. Халапсин // Россия: потенциал инновационного развития. Сборник научных статей аспирантов и студентов. - СПб.: НОУ ВПО «Институт бизнеса и права», 2011. - С. 52-60.

52. Смирнова, Г. Н., Проектирование экономических информационных систем / Г. Н. Смирнова, А. А. Сорокин, Ю. Ф. Тельнов. - М.: Финансы и статистика, 2002. - 512 с.

53. Кролл, П. Rational Unified Process - это легко. Руководство по RUP для практиков / П. Кролл, Ф. Крачтен. - М.: Кудиц-Образ, 2004. - 432 с.

54. Щукова, К.Б. Методология IBM Rational Unfied Process как инструмент для создания эффективных систем / К. Б. Щукова // Современная техника и технологии. - 2015. - № 11 [Электронный ресурс]: https://technology.snauka.ru/2015/11/8172 (дата обращения: 05.05.2022).

55. Smith, J., A Comparison of the IBM Rational Unified Process and eXtreme Programming, A technical discussion of RUP, p. 24. [Электронный ресурс]: http://citeseerx.ist.psu.edu // viewdoc // download (дата обращения: 02.08.2022).

56. Kinmond, R. M., Kinmond, K. S. The teaching of RAD skills // Proceedings of the second international conference on Software engineering in higher education II. -1996. - pp. 75-82.

57. Кон, М. Scrum: гибкая разработка ПО / М. Кон. - М.: Издательский дом «Вильямс», 2016. - 576 с.

58. Rumpe, B. Agile modeling with UML: Code generation, testing, refactoring. - Springer, 2017. - 388 p.

59. Вольфсон, Б.И. Гибкие методологии разработки / Б. И. Вольфсон. -СПб.: Издательский дом «Питер», 2017. - 144 с.

60. Ларин, С. Н. Модели, методы, показатели, характеристики и метрики, применяемые в экспертных системах оценки качества разработки и создания инновационных программных проектов / С. Н. Ларин, Л. Ю. Лазарева, Т. С. Ларина // Региональная экономика: теория и практика. - 2017. - Т. 15. - №6. - С. 1187-1198.

61. McCall, J.A., Richards, P.K., Walters, G.F. Factors in Software Quality: Preliminary Handbook on Software Quality for an Acquisition Manager. Final Technical Report. -National Technical Information Service, Springfield. - 1977. - Vol. 3.

62. Кулямин, В. В. Место тестирования среди методов оценки качества ПО / В. В. Кулямин, О. Л. Петренко // Труды института системного программирования РАН. - 2003. - том 4. - С. 163-175.

63. Boehm, B.W., Brown, J.R., Kaspar, H., Lipow, M., MacLeod, G.J., Merritt, M.J. Characteristics of Software Quality // TRW Series of Software Technology. -Amsterdam, North Holland, 1978. - 166 p.

64. Ghezzi, C., Jazayeri, M., Mandrioli, D. Fundamental of Software Engineering. - Prentice-Hall, NJ, USA, 1991. - 543 p.

65. Grady, R.B., Caswell, D.L. Software Metrics: Establishing a Company-Wide Program. - Prentice-Hall, 1987. - 275 p.

66. Жарко, Е. Ф. Сравнение моделей качества программного обеспечения: аналитический подход / Е. Ф. Жарко // [Электронный ресурс]: XII Всероссийское совещание по проблемам управления ВСПУ-2014, сборник трудов (16-19 июня 2014 г.). - С. 4585-4594.

67. Dubey, S.K., Ghosh, S., Rana, A. Comparison of Software Quality Models: An Analytical Approach // International Journal of Emerging Technology and Advanced Engineering. - 2012. - Volume 2. - Issue 2. - pp 111-119.

68. Гордеев, А. А. Эволюция моделей качества программного обеспечения: методика и результаты анализа в контексте стандарта ISO 25010 / А. А. Гордеев, В. С. Харченко // Системы обработки информации. - 2013. - выпуск 6 (113). - С. 13-31.

69. Горбаченко, И. М. Оценка качества программного обеспечения для создания систем тестирования / И. М. Горбаченко // Фундаментальные исследования. - 2013. - № 6. - С. 823-827.

70. Sahaf, Z., Garousi, V., Pfahl, D., Irving, R., Amannejad, Y. When to automate software testing? Decision support based on system dynamics: an industrial case study. // ICSSP 2014: Proceedings of the 2014 International Conference on Software and System Process. Nanjing, China, May 26-28. - 2014. - pp. 149 - 158.

71. Гребенюк, В. М. Оценка целесообразности внедрения автоматизированного тестирования / В. М. Гребенюк // [Электронный ресурс]:

Интернет-журнал «Науковедение». - 2013 - № 1. https://naukovedenie.ru/PDF/13tvn113.pdf (дата обращения: 02.08.2022).

72. Теория автоматического управления: Учеб. для вузов по спец. «Автоматика и телемеханика». В 2-х ч. Ч. II. Теория нелинейных и специальных систем автоматического управления. / А. А. Воронов, Д. П. Ким, В. М. Лохин и др.; Под ред. А. А. Воронова. - 2-е изд., перераб. и доп. - М.: Высш. шк., 1986. -504 с.

73. Галимова, Е. Ю. Методика ручного тестирования информационных систем управления высшим учебным заведением / Е. Ю. Галимова // II Всероссийская научно-практическая конференция «Теоретические вопросы разработки, внедрения и эксплуатации программных средств», сборник статей (апрель 2013, Орск). - С. 37-39.

74. Галимова, Е. Ю. Преимущества ручного подхода к тестированию программного обеспечения / Е. Ю. Галимова // III Международный научный форум "Наука в исследованиях молодых", сборник статей (май 2013, Новосибирск). - С. 39-42.

75. Моисеенко, А. Автоматизированное тестирование ПО: достоинства и недостатки / А. Моисеенко // [Электронный ресурс]: http://www.pcweek.ru/themes/detail.php?ID=72955 (дата обращения: 02.08.2022).

76. Галимова, Е. Ю. Пример разработки тестового плана на базе шаблона RUP / Е. Ю. Галимова // VI Ежегодная международная научно-практическая конференция "Перспективы развития информационных технологий", сборник статей (Новосибирск, декабрь 2011). - С. 97-103.

77. Automation testing vs. Manual testing: What's the difference? // [Электронный ресурс]: https://www.guru99.com/difference-automated-vs-manual-testing.html (дата обращения: 02.08.2022).

78. Локализация программного обеспечения // [Электронный ресурс]: http://www.alba-translating.ru/index.php/ru/translation/localization.html (дата обращения: 02.08.2022).

79. Брейдер, Л. Тестирование при непрерывной разработке / Л. Брейдер, А. Кэмерон // [Электронный ресурс]:Шр://твёп.тюго80Й.сот/ги-ru/magazine/jj618302.aspx (дата обращения: 02.08.2022).

80. Fewster, M., Graham, D. Software test automation. Effective use of test execution tools. - Addison-Westley Professional, 1999. - 600 p.

81. Галимова, Е. Ю. Автоматизация тестирования распределенных информационных систем / Е. Ю. Галимова // IV Всероссийская интернет-конференция «Информационные технологии и их применение», сборник тезисов (май 2016, Иркутск). - С. 29-31.

82. Галимова, Е. Ю. Подход к выбору инструмента автоматизации процесса тестирования программного обеспечения для коммерческой организации» / Е. Ю. Галимова // XIII Санкт-Петербургская международная конференция «Региональная информатика (РИ-2012), сборник тезисов/СПОИСУ - Спб., 2012. -С. 148-149.

83. Галимова, Е. Ю. Анализ возможностей интеграции свободного программного обеспечения для целей автоматизированного тестирования / Е. Ю. Галимова // Инновации молодёжной науки: тез. докл. Всерос. науч. конф. молодых ученых / Санкт-Петербургский государственный университет промышленных технологий и дизайна. - СПб.: СПбГУПТД, 2017. - С. 157

84. Галимова, Е. Ю. Анализ алгоритма принятия решения об автоматизации тестирования программного продукта с применением свободного программного обеспечения Selenium / Е. Ю. Галимова // Сборник материалов Российская молодежная конференция с элементами научной школы «Теория и практика применения свободного программного обеспечения» (18-22 мая 2016, Магнитогорск). - С. 133-138.

85. Винограй, Э. Г. Общая теория организации и системно-организационный подход / Э. Г. Винограй. - Томск: Изд-во Том. Ун-та, 1989. -336 с.

86. Сагатовский, В. Н. Опыт построения категориального аппарата системного подхода / В. Н. Сагатовский // Философские науки. - 1976. - № 3. - С. 67-78.

87. Сагатовский, В. Н. Природа системной деятельности / В. Н. Сагатовский // Понятие деятельности в философской науке. - Томск: Изд-во ТГУ. - 1978. - С. 69-92.

88. Гладких, Б. А. Основы системного подхода и их приложение к разработке территориальных автоматизированных систем управления / Б. А. Гладких, Ф. И. Перегудов, В. Н. Сагатовский и др. / Под ред. Ф. И. Перегудова. -Томск: Изд-во ТГУ. - 1976. - 244 с.

89. Перегудов, Ф. И. Системное проектирование АСУ хозяйственной области / Ф. И. Перегудов, В. Н. Сагатовский и др. - М.: Статистика, 1977. - 159 с.

90. Lewis, W. E. Software testing and continuous quality improvement: third edition, Taylor & Francis Group, LLC. - 2009 - 639 p.

91. Ракитов, А. И. Системный анализ и аналитические исследования: руководство для профессиональных аналитиков / А. И. Ракитов, Д. А. Бондарев, И. Б. Романов, С. В. Егерев, А. Ю. Щербаков. - М.: Альменда, 2009. - 448 с.

92. Каннер, С. Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений / С. Каннер, Дж. Фолк, Е. К. Нгуен. - Киев: Издательство «Диасофт», 2001. - 544 с.

93. Сагатовский, В. Н. Системная деятельность и ее философское осмысление / В. Н. Сагатовский // Системные исследования. Методологические проблемы. Ежегодник 1980. - М.: Наука. - 1981. - С. 52 -68.

94. Данелян, Т. Я. Формальные методы экспертных оценок / Т. Я. Данелян // Экономика, Статистика и Информатика. - 2015. - №1. - С. 183-187.

95. Литвак, Б.Г. Экспертиза в России / Б. Г. Литвак // Заводская лаборатория. - 2000. - Т. 66. - № 7. - С. 61-66.

96. Орлов, А. И. Организационно-экономическое моделирование: Ч. 2: Экспертные оценки / А. И. Орлов. - М.: МГТУ им. Н. Э. Баумана, 2011. - 486 с.

97. Галимова, Е. Ю. Метод выбора между ручным и автоматизированным тестированием, основанный на свойствах программного продукта / Е. Ю. Галимова, А. Н. Коваленко // Вестник Донского государственного технического университета. - 2016. - № 4. - С. 134-140.

98. Галимова, Е. Ю. Методы тестирования систем, разработанных с использованием алгоритмов машинного обучения для онлайн-оценки уровня выработки солнечной энергии / Е. Ю. Галимова // Современные проблемы электроэнергетики и пути их решения: материалы V Всероссийской научно-технической конференции. - Махачкала: ДГТУ, 2019. - С. 60-64.

99. Галимова, Е. Ю. Особенности тестирования программных средств автоматизированной системы управления ремонтами энергетического оборудования (АСУРЭО) / Е. Ю. Галимова // Цифровая трансформация в энергетике: материалы Всероссийской научной конференции. - Тамбов: Издательский центр ФГБОУ ВО «ТГТУ», 2020. - С. 253 -256.

100. Галимова, Е. Ю. Актуальные подходы к тестированию программного обеспечения, являющегося частью сельскохозяйственного интернета вещей / Е. Ю. Галимова // Аграрная наука - сельскому хозяйству: сборник материалов: в 2 кн. / XV Международная научно-практическая конференция (12-13 марта 2020 г.). - Барнаул: РИО Алтайского ГАУ, 2020. - Кн. 2. - С. 22 - 23.

101. Галимова, Е. Ю. Тестирование как инструмент повышения качества программного обеспечения, разрабатываемого для нужд индустрии гостеприимства / Е. Ю. Галимова // Сборник тезисов докладов участников I Международной научно-практической конференции «Инновационные направления интеграции науки, образования и производства» [Электронный ресурс]: Сборник тезисов. - Керчь: ФГБОУ ВО «КГМТУ», 2020. - С. 732-735.

102. Галимова, Е. Ю. Исследование подходов к тестированию программных продуктов, применяемых в кредитно-финансовой сфере / Е. Ю. Галимова // Управление качеством в образовании и промышленности: сборник статей Всероссийской научно-технической конференции (21-22 мая 2020 г., г.

Севастополь). - Севастополь: ФГАОУ ВО «Севастопольский государственный университет», 2020. - С. 505-509.

103. Нагул, Н. В. К вопросу сохранения свойств многоосновных алгебраических систем / Н. В. Нагул // Вестник Самарского государственного университета. Естественнонаучная серия. - 2007. - № 6 (56). - С. 223-241.

104. Бениаминов, Е. М. Элементы универсальной алгебры и ее приложений в информатике/ Е. М. Бениаминов, Е. А. Ефимова. - М.: Научный мир, 2004. - 168 с.

105. Крывый, С. Л. Абстрактные типы данных как многоосновные алгебраические системы / С. Л. Крывый // Инженерия программного обеспечения.

- 2010. - №3. - С. 3-18.

106. Маклейн, С. Категории для работающего математика/ С. Маклейн. -М.: Физматлит, 2004. - 352 с.

107. Куликов, Л. Я. Алгебра и теория чисел / Л. Я. Куликов. - М.: Высшая школа, 1979. - 559 с.

108. Каташевцев, М. Д. Математическое моделирование контурных изображений и вычислительная сложность их анализа: дис. ... канд. тех. наук: 05.13.18 / Каташевцев Михаил Дмитриевич. - Иркутск, 2017. - 100 с.

109. Мальцев, А. И. Алгебраические системы / А. И. Мальцев. - М.: Наука, 1970. - 392 с.

110. Шапошников, И. Г. О конгруэнциях конечных многоосновных универсальных алгебр / И. Г. Шапошников // Дискретная математика. - 1999. -том 11. - выпуск 3. - С. 48-62.

111. Павлов, А. Н. Методы обработки экспертной информации: учебно-методическое пособие / А. Н. Павлов, Б. В. Соколов. - СПб.: ГУАП, 2005. - 42 с.

112. Галимова Е. Ю. Особенности модели метода выбора способа тестирования программных систем / Е. Ю. Галимова, С. В. Белов // Перспективы науки. - 2020. - №8 (131) - С. 20-23.

113. Фишберн, П. Теория полезности для принятия решений / П. Фишберн.

- М.: Наука, главная редакция физико-математической литературы, 1978. - 352 с.

114. Трухаев, Р. И. Модели принятия решений в условиях неопределенности / Р. И. Трухаев. - М.: Наука, 1981. - 258 с.

115. Жуковин, В. Е. Нечеткие многокритериальные модели принятия решений / В. Е. Жуковин. - Тбилиси: Мецниереба, 1988. - 71 с.

116. Борисов, А. Н. Обработка нечеткой информации в системах принятия решений / А. Н. Борисов, А. В. Алексеев, Г. В. Меркурьев и др. - М.: Радио и связь, 1989. - 304 с.

117. Борисов, А. Н. Принятие решений на основе нечетких моделей: Примеры использования / А. Н. Борисов, О. А. Крумберг, И. П. Федоров. - Рига: Зинатне, 1990. - 184 с.

118. Саати, Т. Аналитическое планирование. Организация систем / Т. Саати, К. Керис. - М.: Радио и связь, 1991. - 224 с.

119. Давнис, В. В. Прогнозные модели экспертных предпочтений: монография / В. В. Давнис. - Воронеж: Изд-во Воронеж. гос. ун-та, 2005. - 248 с.

120. Галимова, Е. Ю. Модель информационно-советующей системы поддержки принятия решения при выборе способа тестирования программного обеспечения / Е. Ю. Галимова, С. В. Белов // Вестник Астраханского государственного технического университета. Серия: Управление, вычислительная техника и информатика. - 2020. - №3. - С. 52-60.

121. Подиновский, В. В., Идеи и методы теории важности критериев в многокритериальных задачах принятия решений / В. В. Подиновский. - М.: Наука, 2019. - 103 с.

122. Черноруцкий, И. Г. Методы оптимизации и принятия решений / И. Г. Черноруцкий. - СПб.: Лань, 2001. - 384 с.

123. Ногин, В. Д. Принятие решений в многокритериальной среде: количественный подход / В. Д. Ногин. - М.: Физматлит, 2002. - 176 с.

124. Doumpos, M., Zopounidis, C. Multicriteria decision and classification methods. - Dordrecht: Kluwer Academic Publishers, 2002. - 256 p.

125. Fumiko, S. Fundamentals of intelligent support systems for fuzzy multiobjective decition analyses // Proceedings of the Tenth International Conference:

Expand and Enrich the Domains of Thinking and Application. - Springer-Verlag, 1993. - pp. 209-219.

126. Кини, Р. Л., Райфа, Х. Принятие решений при многих критериях: предпочтения и замещения / Р. Л. Кини, Х. Райфа / Под ред. И. Ф. Шахнова. - М.: Радио и связь, 1981. - 560 с.

127. Hwang, C.L., Lin, M.J. Group decision making under multiple criteria. -Berlin: Springer-Verlag, 1987. - 405 p.

128. Roy, B. Multicriteria methodology for decision aiding. - Dordrecht: Kluwer Academic Publishers, 1996. - 292 p.

129. Галимова, Е. Ю. Выбор способа тестирования как решение многокритериальной задачи / Е. Ю. Галимова, А. Н. Коваленко // «Инженерный вестник Дона». - 2016. - №3. [Электронный ресурс]: http://ivdon.ru/ru/magazine/archive/n3y2016/3756 (дата обращения: 02.08.2022).

130. Галимова Е. Ю. Методика выбора автоматизированного, ручного и смешанного способа тестирования программного продукта, основанная на критериях качества / Е. Ю. Галимова // Известия Тульского государственного университета. Технические науки. - 2019. - №7. - С. 248-256.

131. Галимова, Е. Ю. Применение алгоритма многокритериальной оптимизации при выборе между ручным и автоматизированным тестированием / Е. Ю. Галимова, А. Н. Коваленко // 63-я Международная молодежная научно-техническая конференция «Молодежь. Наука. Инновации», сборник докладов (ноябрь 2015, Владивосток). - Том 1. - С. 84-86.

132. Подиновский, В. В. Парето-оптимальные решения многокритериальных задач / В. В. Подиновский, В. Д. Ногин. - М.: Наука. Главная редакция физико-математической литературы, 1982. - 256 с.

133. Галимова, Е. Ю. Анализ подхода к тестированию программной системы на базе решения многокритериальной задачи / Е. Ю. Галимова // XV Санкт-Петербургская международная конференция «Региональная информатика (РИ-2016)», сборник тезисов. - СПб.: 2016. - стр. 478.

134. Штойер, Р. Многокритериальная оптимизация. Теория, вычисления и приложения / Р. Штойер. - М.: Радио и связь, 1992. -504 с.

135. Ларичев, О. И. Теория и методы принятия решений / О. И. Ларичев. -М.: Логос, 2002. - 295 с.

136. Ногин, В. Д. Линейная свертка критериев в многокритериальной оптимизации / В. Д. Ногин // «Искусственный интеллект и принятие решений». -2014. - № 4. - С. 73-82.

137. Семенов, С. С. Методы и модели принятия решений в задачах оценки качества и технического уровня сложных технических систем / С. С. Семенов, Е. М. Воронов, А. В. Полтавский, А. В. Крянев. - М.: Ленанд, 2020. - 520 с.

138. Пиявский, С.А. Методы оптимизации и оптимального управления / С. А. Пиявский. - Самара: СГАСУ, 2004. - 156 с.

139. Уиттакер, Дж. Как тестируют в Google / Дж. Уиттакер, Дж. Арбон, Дж. Каролло. - СПб.: Питер, 2014. - 320 с.

140. Walsh, M., Coleman, G., Bertrand, C. and other, Agile testing foundations: An ISTQB foundation level Agile tester guide. - BCS: The Chartered Institute for IT, 2017. - 254 p.

141. Грегори, Дж. Agile-тестирование. Обучающий курс для всей команды / Дж. Грегори, Л. Криспин. - М.: Манн, Иванов и Фербер, 2019. - 528 с.

142. Галимова, Е. Ю. Применение для IoT методики выбора подхода к тестированию программного продукта в рамках процесса цифровой трансформации промышленности / Е. Ю. Галимова // Цифровая трансформация промышленности: тенденции, управление, стратегии: материалы I Международной научно-практической конференции (г. Екатеринбург, 11 октября 2019 года) - Екатеринбург: Институт экономики УрО РАН, 2019. - С. 94 - 103.

143. Галимова, Е. Ю. Особенности программного обеспечения Internet Of Bodies, влияющие на выбор методов тестирования / Е. Ю. Галимова // Информационные технологии: материалы 84-й науч.-техн. конференции профессорско-преподавательского состава, научных сотрудников и аспирантов (с

международным участием), Минск, 3-15 февраля 2020 года [Электронный ресурс]. - Минск: БГТУ, 2020. - С. 172-174.

144. Leach, R. J. Using Metrics to Evaluate Student Programs, ACM SIGCSE Bulletin. - 1995. - Vol. 27. - No. 2. - pp. 41-48.

145. Chuan, C. H., Lin, L., Ping, L. L., Lian, L.V. Evaluation of Query Languages with Software Science Metrics // Proceedings of the IEEE Region 10's Ninth Annual International Conference on Frontiers of Computer Technology TENCON'94. -Singapore, 1994. - pp. 516-520.

146. Bailey, C. T., Dingee, W. L. A Software Study Using Halstead Metrics // Proceedings of the 1981 ACM Workshop / Symposium on Measurement and Evaluation of Software Quality. - Maryland, USA, 1981. - pp. 189-197.

147. Кривченков, А. А. Особенности применения метрики программного обеспечения при программировании микропроцессоров на Ассемблере / А. А. Кривченко // Программирование. - 1988. - № 5. - С. 46-55.

148. AI-Qutaish, J., Elayyan, R. Incorporating software measurements into a compiler. Master thesis. Department of Computer Science. Putra University of Malaysia. - 1998. - 25 p

149. Шабалин, А. Н., Дейков, А. И. Проверка уравнения длины для Бейсик-программы // Программирование. - 1988. - №2. - С. 86-89.

150. Харченко, В. С. Использование метрик Холстеда при оценке безопасности критического программного обеспечения / В. С. Харченко, В. В. Скляр, А. А. Гордеев, В. И. Токарев, А. Д. Герасименко, Ю. А. Белый // Радюелектронш i комп'ютерш системи. - 2003. - № 4. - С. 145-150.

151. F Brito e Abreu, R Carapu?a Candidate metrics for object-oriented software within a Taxonomy framework // Journal of Systems and Software. - July 1994. -vol. 26(1). - No. 1. - pp. 87-96.

152. Афанасова, А. И. Программа по оценке качества академических программных продуктов на основе методики Холстеда / А. И. Афанасова // Программные продукты и системы. - 2015. - № 4. - С. 256-260.

153. Галимова, Е. Ю. Выбор метрик тестирования на основе подхода, применяемого при разработке программного обеспечения / Е. Ю. Галимова // XIX Международная научно-практическая конференция «Современное состояние естественных и технических наук». - М.: Издательство «Спутник +», 2015. - С. 77-79.

154. Василенко, Н. В. Модели оценки надежности программного обеспечения / Н. В. Василенко, В. А. Макаров // Вестник Новгородского государственного университета. - 2004. - №28. - С.126-132.

155. Изотов, Д. А. Эмпирические модели общего экономического равновесия / Д. А. Изотов // Пространственная экономика. - 2014. - №3. - С. 138167.

156. Майерс, Г. Надежность программного обеспечения / Г. Майерс. - М.: Мир, 1980. - 360 с.

157. Галимова, Е. Ю. Метод оценки затрат на применение автоматизированного тестирования программного продукта / Е. Ю. Галимова // Научно-технический вестник Поволжья - 2019. - №10. - C. 27-29.

158. Галимова, Е. Ю. Применение метрики Холстеда для расчета стоимости автоматизации тестирования программных систем / Е. Ю. Галимова // IX Международная научно-практическая конференция «Информационные и коммуникационные технологии в образовании и науке» (1-5 июня 2020 г.). [Электронный ресурс]: http://birskin.ru/index.php/2012-02-07-11-31-02/49-8-/451-2020-05-26-16-15-32 (дата обращения: 03.08.2022).

159. Тестирование производительности: последовательность тестов, измеряемые показатели, правила подачи нагрузки. [Электронный ресурс]: https://www.so^ware-testing.ru/library/testing/performance-testing/2685-test-perfomance (дата обращения: 02.08.2022).

160. Usability Testing Tutorial: A Complete Getting Started Guide [Электронный ресурс]: https://www.softwaretestinghelp.com/usability-testing-guide/ (дата обращения: 03.08.2022).

161. Галимова, Е. Ю. Применение метрики Холстеда для оценки временных затрат на обработку результатов тестирования программной системы / Е. Ю. Галимова // Modern science. М., 2020. - №7-1. - С. 375-379.

162. Хунов, Т. Х. Анализ моделей прогнозирования надежности программных систем / Т. Х. Хунов // Новые информационные технологии в автоматизированных системах. - 2016. - №19. - С.219-223.

163. Холстед, М. Начала науки о программах/ М. Холстед. - М.: Финансы и статистика, 1981. - 128 с.

164. Галимова Е. Ю. Применение метрик сложности в процессе тестирования программных систем / Е. Ю. Галимова, С. В. Белов // Современная наука: актуальные проблемы теории и практики. Серия: Естественные и Технические Науки. - 2021. - №05. - С. 59-62.

165. Корниенко, А. А. Подход к структурированию метрик сложности для выявления дефектов безопасности программного обеспечения / А. А. Корниенко, С. В. Диасамидзе // Известия ПГУПС. - 2016. - №3. - С. 421-429.

166. Мышенков, К. С. Анализ зависимости затрат на тестирование от сложности программного обеспечения // Современные тенденции развития науки и технологий / К. С. Мышенков, С. В. Морозов. - 2015. - №8-1. - С. 125-129.

167. Галимова, Е. Ю. Особенности тестирования экспертных систем, разрабатываемых для нужд спорта / Е. Ю. Галимова // Материалы IV Всероссийской научно-практической конференции «День спортивной информатики» (4-5 декабря 2020 года). - Москва, 2021. - С. 116-118.

168. Мухутдинов, Э. А. Информационные системы / Э. А. Мухутдинов, Р. Г. Тахавутдинов. - Казань: Казан. гос. энерг. ун-т, 2004. - 80 с.

169. Найханова, Л. В. Методы и алгоритмы трансляции естественноязыковых запросов к базе данных в SQL-запросы: Монография / Л. В. Найханов, И. С. Евдокимова. - Улан-Удэ: Изд-во ВСГТУ, 2004. - 148 с.

170. Казаков, О. Д. Разработка информационно-советующей системы управления производственными процессами / О. Д. Казаков, А. В. Аверченков // Вестник ВГУИТ. - 2017. - Т. 79. - № 2. - С. 280-284.

171. Аверченкова, Е. Э. Обеспечение безопасности информационной советующей системы / Е. Э. Аверченкова, Д. И. Гончаров, Д. А. Лысов // Вестник Иркутского государственного технического университета. - 2016. - Т. 20. - № 9. -С. 46-57.

172. Ольгаренко, В. И. Информационно-советующие системы при планировании водопользования / В. И. Ольгаренко, Г. Г. Костюнин // Мелиорация и водное хозяйство. - 2016. - № 14. - С. 47-50.

173. Аверченкова, Е. Э. Разработка структурно-функциональной схемы и алгоритмов работы информационной советующей системы по формированию управленческих решений на промышленном предприятии / Е. Э. Аверченкова, А. В. Аверченков, В. К. Черкасов, Д. В. Аксененко // Вестник БГТУ. - 2015. - № 4 (48). - С. 113-120.

174. Степанова, А. С. Методика синтеза информационно-советующей системы защиты на основе бинарной / А. С. Степанова // Сборник трудов 11 -й международной конференции САБ/САМ/РВМ-2011. - М: ООО НВП «ИНЭК», 2011. - С. 274-278.

175. Аверченкова, Е. Э. Автоматизированное принятие управленческих решений на основе моделей и алгоритмов информационной советующей системы / Е. Э. Аверченкова, А. В. Аверченков // Информационные системы и технологии. - 2016. - № 3 (95). - С. 31-39.

176. Остапчик, В. П. Информационно-советующая система управления орошением / В. П. Остапчик, В. А. Костромин, А. М. Коваль. - Киев: Урожай, 1989. - 245 с.

177. Аверченкова, Е.Э. Инфологическая и даталогическая модель базы данных информационной советующей системы для принятия управленческих решений на региональном уровне / Е. Э. Аверченкова, А. В. Аверченков // Михаило-Архангельские чтения: материалы Х международной научно-практической конференции (Рыбница, 17 ноября 2015). - Рыбница: Изд-во Преднестровского государственного университета, 2015. - С. 255-257.

178. Горенский, Б. М. Информационно-советующая система управления металлургическим объектом / Б. М. Горенский, О. В. Кирякова, С. В. Капустина, Л. А. Лапина // Сборник трудов III Всероссийской научно-практической конференции Моделирование, программное обеспечение и наукоемкие технологии в металлургии. - Новокузнецк, 2011. - С. 118-125.

179. Beemer, B. A., Gregg, D. G. Advistory systems to support decision making // Handbook on decition support systems 1. - Springer. - pp. 511-527.

180. Hadden, S. G., Intelligent advistory systems for managing and disseminating information // Public management information systems. - 1986. - Vol. 46. - pp. 572578.

181. Pasichnyk, V., Artemenko, O., Intelligent advisory systems and information technology support for decision making in tourism // 2015 Xth International Scientific and Technical Conference "Computer Sciences and Information Technologies" (CSIT), 2015. - pp. 16-21.

182. Нусс, М. В. Советующая интеллектуальная система управления процессом обжига цементного клинкера: Монография / М. В. Нусс, П. А. Трубаев, В. К. Классен, В. М. Коновалов. - Белгород: Изд-во БГТУ, 2015. - 171 с.

183. Галимова, Е. Ю., Разработка методики и компьютерной реализации выбора подхода к тестированию программного продукта / Е. Ю. Галимова // Современная наука: актуальные проблемы теории и практики. Серия «Естественные и технические науки». - 2019. - № 6-2. - С. 53-56.

184. Галимова Е. Ю. Модель информационно-советующей системы поддержки принятия решения при выборе способа тестирования программного обеспечения / Е. Ю. Галимова, С. В. Белов // Вестник АГТУ. Серия: Управление, вычислительная техника и информатика. - 2020. - №3. - С. 52-60.

185. Krishnaswamy, J. Microsoft Visual Studio Light Switch Business Application Development. - Packt publishing enterprise, 2011. - 384 p.

186. Ritchie, P. Practical Microsoft Visual Studio 2015. - Apress, 2016. - 220 p.

187. Bjorndander, S. Microsoft Visual C++ Windows Applications by Example. - Packt publishing, 2008. - 440 p.

188. Дейтел, Х. М. Как программировать на С++ / Х. М. Дейтел, П. Дж. Дейтел. - Бином-Пресс, 2008. - 1456 с.

189. Прата, С. Язык программирования С++. Лекции и упражнения / С. Прата. - М.: Изд-во «Диалектика», 2018. - 1244 с.

190. Свидетельство о государственной регистрации программы для ЭВМ № 2020660556 от 04.09.2020 г. Российская Федерация. Информационно-советующая программная система для выбора способа тестирования / Е. Ю. Галимова.

191. Бутов, А. М. Рынок продукции станкостроения / А. М. Бутов. [Электронный ресурс]: https://dcenter.hse.rU/data/2020/11/07/1361776905/Рынок продукции станкостроения-2020.pdf (дата обращения: 10.08.2022).

192. Галимова Е. Ю., Особенности тестирования веб-приложений, учитываемые в методике выбора способа тестирования на основе критериев качества и экспертных оценок / Е. Ю. Галимова // Научно-технический вестник Поволжья. - 2019. - №6 - С. 77-81.

193. Липаев, В. В. Тестирование компонентов и комплексов программ: учебник / В. В. Липаев. - М.: СИНТЕГ, 2010. - 400с.

194. Галимова, Е. Ю. Оценка рисков в процессе выбора подхода к тестированию 1111 / Е. Ю. Галимова // XIII Международная научно-практическая конференция «Фундаментальные и прикладные исследования в современном мире», сборник статей (17 марта 2016, Санкт-Петербург). - СПб.: «Стратегия будущего», 2016. - С. 71-74.

195. Галимова, Е. Ю. Тестирование программных продуктов как инструмент обеспечения качества и безопасности информационных взаимодействий в цифровом обществе / Е. Ю. Галимова // Возможности и угрозы цифрового общества: материалы конференции / под ред.: А. В. Соколова, А. А. Фролова. -Ярославль: Изд-во ООО «Цифровая типография», 2020. - С. 47-51.

Приложение А. Список экспертной комиссии

1) Белов С. В. , к. т. н., директор института информационных технологий и коммуникаций АГТУ

2) Шачнев А. Б., руководитель отдела тестирования ООО «Октавиан. СПб»

3) Силкин А. А., главный инженер ООО «Импульс 3А»

4) Галимов Т. А., старший инженер АО «Красный дельфин»

5) Дроздова Е. Н., к. т. н., доцент кафедры информационных и управляющих систем СПбГУПТД

6) Мелихов Е. А., инженер-программист ООО «Октавиан. СПб»

7) Украинский О. В., к. т. н., доцент кафедры телевидения и метрологии СПбГУТ им. проф. М. А. Бонч-Бруевича

8) Рубин А. В., руководитель отдела тестирования ООО «Квантум Арт»

9) Волнейкин П. А., ведущий программист ООО «Базальт-СПО»

10) Омельян А. В., к. т. н., доцент кафедры информационные системы и технологии СПбГЭУ

11) Галимова Е. Ю., старший тест-инженер ООО «Октавиан. СПб»

12) Пасечник П. А., заведующий лабораторией ИУСиТП СПбГУПТД

Приложение Б. Критериальная характеристика экспертной комиссии

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

Белов С. В. V V V V V V V

Шачнев А. Б. V V V V V V

Силкин А. А. V V V V V V

Галимов Т. А. V V V V V V

Дроздова Е. Н. V V V V V V V

Мелихов Е. А. V V V V V V

Украинский О. В. V V V V V V V

Рубин А. В. V V V V V V

Волнейкин П. А. V V V V V V V

Омельян А. В. V V V V V

Галимова Е. Ю. V V V V V V V V

Пасечник П. А. V V V V V V

Приложение В. Метрический базис сложности ПС

Обозна Название Формула Описание Рекоменду

чение в емыи

базисе диапазон значении

mi Цикломатическая сложность программы М = Е - N + 2P Е - количество ребер графа программы; N - количество узлов графа программы; Р -количество подключенных компонентов. <10

Ш2 Высота дерева наследования DIT = max (path) Максимальная длина пути от листа до корня дерева наследования классов. <9

m3 Количество детей класса NOC = number of children Количество непосредственных наследников класса. <9

m4 Количество откликов на класс RFC = Nm + K Нп - количество методов в классе; К - количество методов, вызываемых из этого класса. <50

ms Нехватка связности в LCOM2 = 1 - sum(MA) М - число методов в <0,7

методах M*A классе; А - число атрибутов в классе; МА -число методов, которые обращаются к А; 8иш (МА) - сумма всех МА в данном классе.

m6 Средний размер класса CS = ir=1(Q+so С! - количество инкапсулированных классом методов (операций); 81 - количество инкапсулированных классом свойств. <20

m7 Количество операций, NOO = Overridden Количество операций, <3

переопределенных Operations унаследованных от

подклассом суперкласса и замещенных своей версией.

m8 Количество операций, NOA = Added Количество новых методов <4

добавленных подклассом Operations (операций), добавленных к методам суперкласса.

m9 Индекс специализации SI = (NOO*U)/Mtotal и - номер уровня в иерархии, на котором находится подкласс; М1оы -общее количество методов класса. <0,15

mio Метрика Джилба JM = CL/n СЬ - абсолютная сложность (количество операторов Ш-ТНЕН-ЕЬ8Е); п - общее число операторов. <0,5

mii Мера Вудворта WM = number of intersections of arcs Количество пересечений дуг управляющего графа. 0

mi2 Метрика Пивоварского N(G) = M* + 2?=i Pi М - модифицированная цикломатическая сложность; Р1 - глубина <28

вложенности i-ой предикатной вершины.

mis Количество методов на класс Nobj—TNmeth / TNclass TNmeth - общее количество методов; TNclass - общее количество классов. <20

mi4 Средняя сложность метода AMC — ( zUQi)/ Ntotal Qi - средний размер метода для i-го класса (в строках); Ntotal - общее число классов. <60

mis Среднее количество сообщений на операцию OSavg— ( YH=iN0fMi)/ NofOP NofMi - количество сообщений i-ой операции; NofOP - общее количество операций. <9

mi6 Среднее количество параметров на операцию NPavg — ( Yf=i Npan)/ Nop Npari - количество параметров в i-ой операции; Nop - общее количество параметров. <0,7

mi7 Уровень комментированности F — Ncom/Nstr Ncom - количество комментариев в программе; Nstr -количество строк или операторов в тексте программы. >0,i

mis Модифицированная цикломатическая сложность M*— E* - N* + 2P* Е - количество ребер графа программы; N - количество узлов графа * программы; Р - количество подключенных компонентов. Оператор «switch» считаем единым. <7

mi9 Метрика Чепина Q — P + 2M + 3C + 0,5T М - модифицируемые переменные; Р-не модифицируемые переменные; С -управляющие переменные; Т - не используемые в программе переменные. <i00

m20 Уровень программной реализации Холстеда L — V*/V V - объем программы (в битах); V - потенциальный объем алгоритма. >0,00i

m2i Метрика связности объектов DofC — NFan-In/Nall NFan-In - общее количество входов, полученных методом; Nall - общее число объектов. >i

Приложение Г.1 Описание вопросов как характеристик ПС, ведущих в целом к выбору автоматизированного тестирования

Обсудим вопросы, ответ «да» на которые концептуально ведет к выбору автоматизированного тестирования:

1. Предъявляются ли высокие требования к производительности? Первый вид тестирования производительности, нагрузочное тестирование - это работа ПС под нагрузкой, ожидаемой в процессе эксплуатации. С помощью специального ПО измеряется время отклика основных транзакций. Также проводится тестирование стабильности, в ходе которого отслеживается состояние памяти при длительной работе ПС. Регистрация различных характеристик работы ПС обычно проводится с использованием средств автоматизации. Вопрос отражает, в соответствии с ГОСТ Р ИСО/МЭК 25010-2015, свойство ПС уровень производительности.

2. Предполагается ли эксплуатация приложения на максимальной нагрузке? Для проверки поведения ПС на предельной нагрузке проводится стресс-тестирование. Имитацию стрессовых условий чаще приходится выполнять в ручную. При этом регистрацию различных характеристик работы ПС обычно проводят с использованием средств автоматизации. Свойства надежность, уровень производительности.

3. Будут ли производиться переходы с одной платформы (конфигурации аппаратных средств) на другую? В этом случае автоматизированные тестовые наборы потребуют лишь небольших изменений при переносе с одной конфигурации на другую. Свойство переносимость, совместимость.

4. Имеется ли большое количество форм с полями для ввода данных? Так как потребуются одинаковые по структуре скрипты, осуществляющие ввод разнотипных переменных. Свойство удобство использования.

5. В приложении много веб-ссылок? Существует ряд средств автоматизации, позволяющих выполнить тестирование ссылок. Если ссылок мало,

удобнее протестировать их вручную [i92]. Свойства функциональная пригодность, удобство использования.

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

7. Часто выходят новые версии приложения? С выходом каждой новой версии ПС происходит ряд изменений в функциональности. Могут возникать регрессионные ошибки. Они возникают, если часть изменений не была учтена в приемочных тестах. Попадание регрессионной ошибки к клиенту сильно ударяет по репутации компании - разработчика и может привести к штрафным санкциям со стороны заказчика. Для проведения регрессионного тестирования требуется выделить критические бизнес-процессы. Применяя автоматизированные проверки, рекомендуется развернуть 2 тестовые системы. На одну установить текущую версию продукта, а на вторую - предыдущую сборку. После тестового прогона на обоих системах сравниваются отчеты об ошибках. Небольшие расхождения ожидаемы. Главное, чтобы они соответствовали требованиям. Свойство совместимость.

s. Планируется ли проводить анализ покрытия кода? Оценка процента программного кода, который был проверен при тестировании. Свойства функциональная пригодность, сопровождаемость.

9. Будет ли проводиться дымовое тестирование (Smoke Testing)? Тестирование ПС, выполняемое после сборки, чтобы убедиться, что критические функции работают нормально. Выполняется «до» любых подробных функциональных или регрессионных тестов. Свойства функциональная пригодность, сопровождаемость.

10. Планируется ли проводить тестирование хеш-функций? Хеш-функция представляет собой математический алгоритм, который модифицирует массив данных в строку, состоящую из цифр и букв. Если используется одинаковый тип

функции, то длина строки не будет меняться. Длина будет инвариантна к объёму массива данных. Перечислим основные подходы к тестированию безопасности хеш-функций: подбор по словарю, грубый перебор, гибридная атака (подбор по словарю с правилами), атака на шифр, радужные таблицы. Можно использовать такие инструменты автоматизации, как MDCrack и John the Ripper. Свойство защищённость.

11. Планируется проведение случайного тестирования (Monkey/Random Testing)? Тестирование, проводимое без какого-либо плана; тесты выполняются в случайном порядке. Например, нажатие в хаотическом порядке на первые попавшиеся кнопки в приложении. Для автоматизации есть много приложений. Для Android - UI/Application Exerciser Monkey, инструмент командной строки, который можно запустить на любом экземпляре эмулятора или на устройстве. Он отправляет псевдослучайный поток пользовательских событий в систему. В приложении есть ряд настроек: основные параметры конфигурации, операционные ограничения, типы событий и их частота, настройки отладчика. Свойство надежность

12. Планируется проведение параллельного тестирования (Concurrency Testing)? Это многопользовательское тестирование для одновременного доступа к приложению для проверки влияния на код, модули и базы данных. В основном используется для определения ситуаций блокировки и взаимоблокировки в коде. Свойство надежность

13. Планируется проведение тестирования точности данных (Data Accuracy Testing)? В процессе тестирования проверяется правильность логики табличных преобразований, от области стейджа (Staging Area) до слоя аналитики. Staging area - это область памяти для временного хранения копии данных, так как перед началом интеграции данных в хранилище необходимо обеспечить наличие всех данных в одном месте. Свойство переносимость

14. Планируется проведение тестирования реконсиляции (Reconciliation Testing)? Процесс использования инструментов согласования данных для проверки системы. Тестирование проводят в процессе миграции данных, когда

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

15. Планируется проведение тестирования полноты данных (Data Completeness Testing)? В процессе тестирования проверяется, все ли ожидаемые данные загружаются в хранилище. Разрабатываются тесты для проверки правильности загрузки записей, наличия всех полей и полноты содержимого каждого поля. Количество записей и уникальность значений ключевых полей должны сравниваться между исходными и целевыми данными. Свойство переносимость

16. Планируется проведение тестирования преобразования данных (Data Transformation Testing)? Успешное проведение данного типа тестирования показывает, что данные успешно проходят все преобразования в ПС. Свойство надежность

17. Планируется проведение тестирования качества данных (Data Quality Testing)? В процессе тестирования проверяется, что неправильные данные обрабатываются корректно. Свойство защищённость

is. Планируется проведение тестирование сравнения баз данных (Database Comparison Testing)? В процессе тестирования сравнивают целевую и исходную базы данных. Свойство надежность

19. Планируется ли проведение тестирования сравнения данных (Data Comparison Testing)? В процессе тестирования проводится сравнение данных между различными точками потока данных. Свойство функциональная пригодность

20. Планируется ли проведение тестирования хранилища данных (Data Warehouse Testing)? В процессе тестирования проверяется успешность

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

21. Планируется ли проведение тестирования на больших объемах данных (Volume Testing)? В процессе тестирования проверяется, может ли ПС обрабатывать объёмы данных, указанные в техническом задании. Производится постепенное нарастание объёмов данных, как приложения, так и базы данных, что позволяет обнаружить части кода, которые требуют доработки. Свойство уровень производительности

22. Планируется проведение стресс-тестирования (Stress Testing)? В процессе тестирования проверяется, является ли производительность ПС удовлетворительной при экстремальных нагрузках. Свойство уровень производительности

23. Планируется проведение тестирования стабильности (Stability Testing)? В процессе тестирования измеряется способность ПС продолжать функционировать в течение длительного периода времени без сбоев и не вызывая сбоев в других приложениях. Свойства совместимость, функциональная пригодность

24. Планируется ли проведение тестирования масштабируемости (Scalability Testing)? В процессе тестирования проверяется способность ПС правильно выполнять свои функции при внесении изменений в размер или объем ПС для удовлетворения растущих потребностей пользователей. Свойства уровень производительности, функциональная пригодность

25. ПС разрабатывается по Agile-методологии? В процессе тестирования в Agile-методологии обычно применяется значительное количество автоматизированных тестов. Автоматизация помогает достичь большего тестового покрытия внутри спринта. Свойство сопровождаемость, совместимость.

26. Планируется тестирование потенциальных возможностей (Capacity Testing)? В процессе тестирования проверяется, может ли ПС и окружение

обрабатывать объём трафика, заявленный в техническом задании. Свойство уровень производительности

27. Планируется проведение синтетического тестирования (Synthetic Testing)? Для десктопных приложений используется для тестирования мониторинга удалённых рабочих столов. Для веб-приложений используется для мониторинга веб-сайта с помощью эмуляции веб-браузера. Инструменты синтетического тестирования используют симулированных пользователей для предоставления информации о времени безотказной работы, производительности критических бизнес-транзакций и наиболее распространенных путях навигации. Свойства уровень производительности, защищённость

28. Планируется проведение интеграционного тестирования (Integration Testing)? В процессе тестирования отдельные модули объединяются в ПС. Основной целью является тестирование интерфейсов между модулями. Свойства функциональная пригодность, совместимость

29. Планируется ли проведение изоляционного тестирования (Isolation Testing)? Изолированное тестирование отдельных модулей ПС. Свойство функциональная пригодность

30. Планируется проведение тестирования сборки (Build Verification Testing)? В процессе тестирования проверяется основная функциональность для дальнейшей передачи ПС в отдел тестирования. Свойства функциональная пригодность, переносимость, сопровождаемость, совместимость

31. Может ли ряд тестовых проверок выполняться параллельно? Параллельный запуск способен значительно ускорить процесс тестирования. Если автоматизированные тесты изолированные, независимые и воспроизводимые, то они должны хорошо подойти для параллельного запуска. Если тесты запрашивают доступ к одному и тому же файлу или БД, у них есть общие переменные, которые меняются в процессе выполнения, или тесты обращаются к встроенному веб-сервису, то параллельный запуск может быть затруднен.

Свойство сопровождаемость

32. Собираетесь ли вы интегрировать тесты в процесс сборки в конвейере DevOps (Development Operation)? Концепция DevOps подразумевает применение Agile-методологии ко всем этапам жизненного цикла ПС. Используется микропроцессорная архитектура, поэтому можно применять непрерывное автоматизированное тестирование. Свойство функциональная пригодность

33. Будут ли выполняться snapshot тесты? Актуально в первую очередь для проверок на мобильных устройствах. Автоматизированные snapshot тесты сравнивают эталонный скриншот экрана с текущим. В первую очередь используются для проверки качества верстки, календаря и т. д. Свойства удобство использования, сопровождаемость

Приложение Г.2 Описание вопросов как характеристик ПС, ведущих к необходимости значительной доли ручного тестирования

Обсудим вопросы, ответ «да» на которые концептуально ведет к выбору автоматизированного тестирования:

34. При разработке использовалось много сторонних управляющих элементов? Рекомендуется применять ручной подход тестирования, поскольку мы не знаем внутреннюю структуру этих элементов. Разработка корректных программных скриптов для них весьма проблематична. Свойства надёжность, сопровождаемость.

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

36. Тестирование должно пройти в сжатые сроки? Если автоматизированные тесты не разрабатывались в предшествующие итерации тестирования, то целесообразно применять ручной подход. На первоначальную разработку автоматизированных тестовых наборов требуются большие временные затраты. Свойство сопровождаемость.

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

38. Планируется проверка эргономичности приложения? Рекомендуется проводить в ручном режиме юзабилити - тестирование. Оно представляет собой проверку эргономичности ПС, в которой участвуют потенциальные пользователи. Проверка осуществляется в «лабораторных» условиях, под наблюдением, с составлением специального протокола. При тестировании юзабилити человеческое участие необходимо для проверки правильности установки, оценки простоты и элегантности пользовательского интерфейса, удобства бизнес-логики. Свойство удобство использования.

39. Необходимо оценивать способность восстановления системы после сбоя? Если критична способность приложения к полному восстановлению после сбоя, рекомендуется использовать ручной подход для имитации ситуаций, способных вызвать временную потерю работоспособности приложения. Выбор ручного тестирования связан с тем, что ситуации, вызывающие сбой, очень разноплановы. Часть из них может быть частично автоматизирована существующими средствами автоматизации, а часть - пока нет. При этом нужно оценивать трудозатраты на разработку таких автоматизированных тестов, обычно они слишком велики по сравнению с затратами на аналогичные ручные тесты. Например, если нам надо искусственно вызвать ошибку в работе сервера, мы можем временно отключить его. Свойство уровень производительности.

40. В приложении много графических объектов? Обычно применяется ручной подход к тестированию. Рассмотрим конкретный пример для языка разработки тестовых скриптов Selenium. Если в тестируемом приложении не отключена анимация, тесты, разработанные на Selenium, работают очень медленно, поскольку тест ожидает каждый раз окончания анимационного ролика. В среднем один автоматизированный тест для проверки конкретного функционала web-страницы, где есть анимация, выполняется примерно за 5 минут. Свойства функциональная пригодность, удобство использования.

41. Функционал программы подразумевает выполнение ручных взаимодействий (например, загрузка диска)? Зачастую применяется ручное тестирование, так как подобные ручные операции на сегодняшний день не

поддаются автоматизации существующими программными инструментами. Свойство функциональная пригодность.

42. Будет проверяться удобочитаемость формата выходных данных? Применяется ручной подход к тестированию, поскольку здесь используется оценка экспертов. Свойство удобство использования.

43. Будет ли проводиться аудит архитектуры ПС? Одним из методов являются контрольные списки, которые представляют собой таблицы или списки вопросов с комментариями для тестировщика. Проверка проводится в ручную, без использования инструментов автоматизации. В первую очередь данный метод направлен на поиск уязвимостей, влияющих на безопасность. Свойство защищённость.

44. Планируется проведение раннего тестирования (Early Testing)? Проведение тестирования так рано, как возможно в цикле разработки для выявления дефектов на ранних стадиях жизненного цикла. Раннее тестирование позволяет снизить стоимость устранения дефектов на более поздних стадиях жизненного цикла. Используется в первую очередь в каскадной модели жизненного цикла, редко используется в модели Agile. Проводится обычно в ручную, например, методом верификации артефактов. Свойство функциональная пригодность

45. Планируется проведение статического тестирования (Static Testing)? Ручная проверка кода без выполнения программы. В этом процессе проблемы идентифицируются в коде путём проверки кода, требований и проектных документов. Свойство функциональная пригодность

46. Планируется проведение исследовательского тестирования (Exploratory Testing)? Исследование приложения, понимание его функциональных возможностей, добавление или изменение существующих тестовых случаев для лучшего тестирования. Свойства функциональная пригодность, удобство использования, надёжность, защищённость, сопровождаемость, переносимость

47. Планируется проведение глобализационного тестирования (Globalization Testing)? Это процесс проверки возможности запуска ПС независимо от географической и культурной среды. Проверка наличия в ПС функций настройки и изменения даты, языка, форматов, валют, в случае, если ПС предназначена для глобальных пользователей. Свойство удобство использования, совместимость.

48. Планируется проведение тестирования локализации (Localization Testing)? Проверка глобализованной ПС для конкретной местности в специфических географических и культурных условиях. Свойство удобство использования

49. Планируется проведение альфа-тестирования? Это ручное тестирование, один из распространённых подходов к тестированию ПС. Используется при разработке ПС, ближе к концу стадии разработки. Состоит из нескольких итераций. Выполняется самими разработчиками, внутренними специалистами по тестированию. Преимуществом альфа-тестирования является то, что найденные дефекты могут быть оперативно устранены разработчиками. Процесс тестирования осуществляется путём выполнения задач, которые может выполнить потенциальный пользователь. Альфа-тестирование может выступать в роли внутреннего приёмочного тестирования для готовой ПС, перед началом бета-тестирования. Проводится методом белого, серого или чёрного ящика. Свойства функциональная пригодность, совместимость, надёжность, защищённость, сопровождаемость, переносимость

50. Планируется проведение бета-тестирования? Это ручное тестирование, проводится с целью получения обратной связи от реальных пользователей. Обычно проводится методом чёрного ящика. Для проведения бета-тестирования не требуется развёртывание специальной лабораторной или тестовой среды. Тестирование осуществляется в пользовательской среде, в так называемой "real time environment" (среда реального времени). Существуют закрытая и открытая бета-версии. Закрытая выпускается для ограниченного числа пользователей, открытая доступна всем интересующимся. Свойства функциональная пригодность, удобство использования, защищённость, переносимость

51. Будут проводиться инспекции кода? Используются для проверки соответствия ПС указанным стандартам и требованиям. Проверка осуществляется путём сравнения ПС с уже существующими проектами, кодом, артефактами и документацией. Требуется тщательное планирование, большое количество подготовительных мероприятий. Проводится запланированная встреча всех участников, у каждого из которых есть своя роль. Например, сотрудник с ролью "reader" прочитывает код продукта. Все остальные проверяют и ищут дефекты. Сотрудник с ролью "recorder" фиксирует дефекты. Сотрудник с ролью "moderator" следит, чтобы обсуждение было продуктивным. Инспекции проводятся в формате совещаний. Затем на основе отзывов инспекции проводится доработка ПС. Инспекции осуществляются отделом контроля качества, являются строгим и формальным мероприятием. Свойства функциональная пригодность, сопровождаемость

52. Будут проводиться сквозные просмотры кода? В рамках сквозного просмотра автор представляет разработанный артефакт аудитории коллег. Последние задают вопросы и комментируют артефакт, чтобы идентифицировать как можно больше дефектов. Данный процесс не предполагает дополнительной подготовки аудитории. Сквозные просмотры обычно включают в себя минимальное документирование процесса и/или любых возникающих проблем. Отслеживание дефектов в процессе проведения сквозных просмотров не состоятельно. Сквозные просмотры - это процесс оценки, который представляет собой неформальную встречу, которая не требует подготовки. Продукт описывается заданными вопросами и сделанными комментариями. Результатом сквозного просмотра является информация для участников о ПС, а не её исправление. Свойства функциональная пригодность, удобство использования

53. Планируется тестирование пользовательских типов метаданных? Пользовательские типы метаданных - это инструмент конфигурации приложения. Под «конфигурацией» подразумеваются декларативные метаданные, которые являются частью приложения или могут использоваться для настройки поведения приложения. Распространённые типы метаданных: настройки, вкладки, правила

рабочего процесса, макеты слоёв, пользовательские определения объектов. Перечисленные типы метаданных варьируются от набора простых перечислений до довольно сложных объектов с обширной функциональностью. Общим является то, что все они есть часть конкретного экземпляра клиентского приложения, в них не входят бизнес-данные. Пользовательский тип метаданных - это новый тип установленного на данном компьютере объекта. Записи этого пользовательского типа метаданных становятся частью установленного на отдельно взятом компьютере приложения или его конфигурации. Свойства удобство использования, защищённость

54. Планируется ли проведение тестирования потоков управления (Control Flow Testing)? Тестирование методом белого ящика. В качестве модели используется граф потока управления, где узлами являются блоки программы, рёбрами - передача потока управления между этими блоками. В графе выбираются различные пути, для которых создаются тестовые примеры. Количество тестов зависит от выбранного уровня покрытия кода. Свойство функциональная пригодность

55. Планируется ли проведение тестирования сравнения (Compare Testing)? В процессе сравнительного тестирования сопоставляются данные из файлов и баз данных с фактическими результатами. Требуется выявить различия между ожидаемыми и фактическими результатами. Свойство функциональная пригодность

56. Планируется проведение санитарного тестирования (Sanity Testing)? В процессе тестирования проверяется только новая или исправленная функциональность. Обычно не документируется, осуществляется отделом тестирования. Свойство функциональная пригодность

57. Будет ли проводиться тестирование требований (Requirements based Testing)? Значительная часть ошибок в программной реализации является следствием ошибок, допущенных в требованиях. В процессе тестирования необходимо проверить, что требования отвечают следующим свойствам: атомарность (atomicity), непротиворечивость (consistency), однозначность

(unambiguousness), обязательность (obligatoriness), актуальность (up-to-date), трассируемость (traceability), модифицируемость (modifiability), упорядоченность по важности (ranked for importance), упорядоченность по стабильности (ranked for stability), упорядоченность по срочности (ranked for priority), корректность (correctness), проверяемость (verifiability). Данный тип тестирования является нефункциональным. Используются такие техники, как рецензирование (peer review), беглый просмотр (walkthrough), технический просмотр (technical review), инспекции требований (inspection). Свойство функциональная пригодность

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

59. Будет ли проводиться анализ псевдокода (pseudocode analyses)? Псевдокод представляет собой описание алгоритма на более структурированном языке, чем разговорный. На данном этапе проектирования ещё не отслеживаются проблемы в дизайне программы. Псевдокод менее подробный, чем программная реализация. В значительной степени независим от языка, на котором планируется писать программный код. Алгоритмы, представленные в виде псевдокода, могут интерпретироваться специалистами без узкоспециальных знаний и опыта. Псевдокод - это своеобразный «мост» между алгоритмом и его программной реализацией. Основная цель псевдокода - описать, что именно должно реализовываться в каждой программной строке. В процессе анализа выявляются лишние блоки, некорректные обращения и т. д. Свойство функциональная пригодность

60. Планируется ли проведение тестирования поведения программного обеспечения при возникновении прерываний? Такие тестовые проверки особо

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

61. Будет ли проверяться работа программного обеспечения при разных типах подключения к интернету? Актуально в первую очередь для мобильных приложений. Проверяется работа с мобильным интернетом (3G, 4G, 5G), в режимах Wi-Fi и авиа, при переключении из одного режима в другой. Свойство надежность

62. Планируется ли проверка взаимодействия программного обеспечения с тачскрином? Проверяется отклик на нажатие (tap), на нажатие и удержание (long tap), проматывание (scroll), перелистывание страниц (swipe), растягивание экрана вниз с целью обновления страницы (pull to refresh), приближение изображения при помощи двух пальцев (pinch). Свойство удобство использования

Приложение Г.3 Описание вопросов как характеристик ПС, ведущих к равновесному сочетанию ручного и автоматизированного тестирования

63. Наборы входных тестовых данных предполагается создавать заново перед каждой итерацией тестирования? Если удобный способ заполнения данными автотестов, это не усложнит процесс автоматизированного тестирования. Свойство функциональная пригодность.

64. Планируется ли проводить функциональное тестирование? При функциональном тестировании возможно использование как ручного, так и автоматизированного подхода к тестированию ПС. Свойство функциональная пригодность.

65. При разработке ПС использовались преимущественно сложные логические структуры (ветвления, циклы)? При автоматизации используется метод покрытия решений или метод покрытия условий, либо ручные методы тестирования. Свойство сопровождаемость.

66. Будет ли проводиться тестирование на некорректных входных данных? Корректность входных данных можно проверять как в ручную, так и с применением автоматизации. Свойство надежность.

67. Это игровая ПС? В процессе тестирования игрового ПС обычно применяется несколько типов тестирования. Комбинаторное тестирование проводится с применением автоматизации для генерации тестовых наборов. С помощью тестов стремимся покрыть все возможные комбинации параметров. В качестве параметров выступают результаты выполнения функций, элементы, события, настройки, атрибуты персонажей, пользовательские настройки. Основной задачей функционального тестирования является проверка выполнения требований спецификации. Проводится чаще всего по методике «чёрного ящика», можно комбинировать ручной и автоматизированный подходы. Тестирование совместимости (конфигурационное) - это проверка корректной работы ПС на различных конфигурациях программных, графических и аппаратных средств. Нужно создать список конфигураций, на которых будет проводиться

тестирование. Все возможные конфигурации обычно указать невозможно, поэтому осуществляется приоритизация. Часто используется парк компьютеров, насчитывающий от 5 до 50 штук. Автоматизированное кроссплатформенное тестирование можно проводить с использованием виртуальной машины, создав многообразные окружения. Тестирование удобства использования проводится вручную. Регрессионное тестирование предназначено для проверки работы ПС после внесения изменений в код программы. При частых выходах новых версий удобно использовать автоматизацию. В процессе нагрузочного тестирования проверяется, корректно ли работает приложение на максимальной нагрузке, например, при выполнении большого количества вычислений, когда одновременно подключается много пользователей. Используются специальные инструменты для автоматизации тестирования. Из вышесказанного можно сделать вывод, что для тестирования игровых ПС подходит смешанный подход. Свойства функциональная пригодность, удобство использования.

68. Тестируемый объект является программно-аппаратным комплексом? В процессе планирования тестирования программно-аппаратный комплекс обычно разделяют на модули. Применяются последовательно метод анализа потоков управления и метод анализа потоков данных [193]. Программный код представляется в виде графа, на основе которого строятся основные маршруты выполнения программы. Узлами графа являются условия, при которых данный маршрут может быть реализован. Ошибкой является отклонение выполнения теста от назначенного маршрута. Тестирование потоков управления является менее ресурсозатратным, чем тестирование потоков данных. Второй способ тестирования потоков управления базируется на спецификации. Необходимые эталонные значения данных формируются экспертным путём. Данный метод наиболее эффективен при простой структуре программы, когда много вычислительных операторов, много констант и переменных. Для тестирования потоков данных строится граф, имена данных пишутся над входящими связями, исходящие связи есть функция, выполнившая вычисления над этими данными. Вычисление функции производится в узле. В процессе тестирования нужно

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

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

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

71. Существует ли значительная вероятность того, что в процессе выполнения тестовых сценариев придётся их изменять и/или вводить дополнительные проверки? Вводить дополнительные проверки и изменять тестовые сценарии чаще всего приходится при тестировании новой системы, когда автоматизированные тестовые наборы прогоняются в первый раз. Вводить дополнительные проверки и изменять тестовые сценарии чаще всего приходится при тестировании новой системы, когда автоматизированные тестовые наборы

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

72. Будет ли проводиться аудит исходного кода ПС? Для частичной автоматизации процесса поиска уязвимостей в программном коде используются «сканеры кода». Свойство защищённость.

73. Планируется проведение динамического тестирования (Dynamic Testing)? Это тестирование, производимое путём выполнения кода или программы с различными входными данными. Затем результаты проверяются. Свойства функциональная пригодность, удобство использования, надёжность, защищённость, сопровождаемость

74. Планируется проведение формального тестирования (Formal Testing)? Стандартизированная проверка ПС, выполняемая в соответствии с планом тестирования и другой формальной документацией. В процессе тестирования выполняются итоговые тесты по всей функциональности ПС. Применяются формальные математические методы. Свойства функциональная пригодность, уровень производительности, удобство использования, надёжность, защищённость, сопровождаемость

75. Планируется проведение риск-тестирования (Risk Based Testing)? Выявление критических функций в системе и тестирование этих функций в первую очередь [i94]. Анализ рисков рекомендуется проводить на стадии проектирования архитектуры. Если уязвимости созданы в процессе проектирования, то такие дефекты очень сложно выявляемые. Рекомендуется использовать при разработке уже существующие архитектурные стили. Обычно применяют сразу комбинацию стилей [i95]. Свойства защищённость, надёжность

76. Планируется проведение сквозного тестирования (End-To-End Testing)? Тестирование всей функциональности системы, включая интеграцию данных между всеми модулями. В частности, проверяется взаимодействие ПС с оборудованием, базами данных, сетью, другим программным обеспечением. Основной причиной проведения этого тестирования является определение различных зависимостей приложения, а также обеспечение передачи точной информации между различными компонентами системы. Обычно выполняется после завершения функционального и системного тестирования любого приложения. Контрольные тесты разрабатываются с точки зрения конечного пользователя. Свойства функциональная пригодность, совместимость, переносимость

77. Планируется проведение регрессионного тестирования (Regression Testing)? Проверка существующей функциональной и нефункциональной области после внесения изменений в часть ПС или после добавления новых функций. Свойства функциональная пригодность, уровень производительности, совместимость, удобство использования, надёжность, защищённость, сопровождаемость, переносимость

78. Планируется проведение тестирования отказоустойчивости (Failover Testing)? Тестирование поведения ПС при возникновении системных сбоев. Способ измерить пропускную способность системы, чтобы убедиться, что система способна перераспределять дополнительный ресурс. Отказоустойчивое тестирование используется, например, для проверки способности системы продолжать повседневные операции, пока создается резервная копия. Свойства уровень производительности, надёжность, защищённость

79. Планируется проведение приёмочного тестирования (Acceptance Testing)? В процессе тестирования определяется, соответствует ли ПС требованиям спецификации. Свойство функциональная пригодность

80. Будет ли проводиться тестирование геолокации? В процессе тестирования предлагается использовать симуляторы для создания различных геолокаций (например, Fake GPS). Свойства переносимость, совместимость

Приложение Д. Акт о внедрении результатов диссертационной работы в

ООО «Импульс 3А»

о внедрении результатов диссертационной работы Галимовой Екатерины Юрьевны на тему «Система поддержки принятия решений при выборе способа тестирования

программных систем»

Комиссия ООО «Импульс ЗА» в составе Шафеева А. С., Силкина А. А. и Милованова С. А. составили настоящий акт о том, что результаты диссертационной работы Галимовой Екатерины Юрьевны, а именно алгоритм выбора способа тестирования программных систем и информационно-советующая программная система для выбора способа тестирования, использованы в профессиональной деятельности общества с ограниченной ответственностью «Импульс ЗА». Использование результатов диссертационного исследования Галимовой Е. Ю. позволяет повысить качество процедур наладки и ремонта программного обеспечения станков с числовым программным управлением.

;тор ООО «Импульс ЗА» ^еев Алексей Сергеевич, <0Ъ июля 2020 г.

«УТВЕРЖДАЮ»

АКТ

Генеральный директор Шафеев Алексей Сергеевич

Главный инженер Силкин Антон Александрович

Ведущий инженер Милованов Сергей Александрович

Приложение Е. Акт об использовании результатов диссертационной работы в ВШПМ

СПбГУПТД

УТВЕРЖДАЮ

Результаты диссертационной работы «Система поддержки принятия решений при выборе способа тестирования программных систем» Галимовой Екатерины Юрьевны, выполненной па соискание ученой степени кандидата технических наук, использованы н учебном процессе ФГБОУ ВО «Высшая школа печати и медиатехпологий Санкт-Петербургского государственного университета промышленных технологий и дизайна» кафедры «Информационные и управляющие системы» для студентов, обучающихся по направлению 09.03.02 «Информационные системы и технологии» при проведении лекционных занятий и практических работ по дисциплинам «Информатика и программирование», «Информационные технологии», «Интсрументальные средства информационных систем». Циклы лабораторных работ по этим дисциплинам апробированы при обучении студентов гр. 1-ТИДА-1,4-ТИДЛ-2 в 2018/19, 2019/20 уч. годах.

В рамках данных дисциплин используются основные результаты диссертационной работы, а именно:

1, Модель, формализующая задачу выбора способа тестирования программной системы.

2. Алгоритм расчета доли автоматизированного тестирования,

3, Методика опенки стоимости процесса тестирования.

4. Концептуальная структура информационно-советующей системы при выборе подхода к тестированию программной системы.

За», кафедрой ИиУС. к.ф.-мли длцен!

Л. М. Конанешео августа 2020 г,

Приложение Ж. Свидетельство о государственной регистрации программы

для ЭВМ