CC BY
80
Таблица 2. Сравнительная характеристкиа значений глянца запечатанных оттисков, отделанных ВД и УФ- лаком
Исследуемый запечатаннй оттиск Значения глянца Среднее значение глянца
1-ая точка 2-ая точка 3-я точка
Офсетная бумага 120 г/м2 39,7 37,9 41,2 39,6
Офсетная бумага 120 г/м2 с нанесением ВД-лака 50,1 51,2 49,9 50,4
Офсетная бумага 120 г/м2 с нанесением ВД и УФ лака 86,4 81,4 86,5 84,7
Мелованная бумага 100 г/м2 66,2 66,4 66,7 66,4
Мелованная бумага 100 г/м2 с нанесением ВД-лака 86,6 86,2 84,4 85,7
Мелованная бумага 100 г/м2 с нанесением ВД и УФ лака 95,7 96,1 97,4 96,4
Таким образом, анализируя полученные данные, можно сделать вывод, дисперсионные лаки практически не влияют на цветовые характеристики оттиска, так как они бесцветны и обладают высокой прозрачностью, при этом незначительно увеличивают значения глянца. Значения глянца увеличиваются для запечатанных образцов как офсетной, так и мелованной бумаги, независимо от нанесения лака. Для незапечатанных образцов офсетной бумаги незначительно повышается глянец, полученный с помощью ВД-лака, в то время, как УФ-лак, нанесенный после ВД-лака увеличивает значение глянца практически в 8 раз.
Список литературы / References
1. Лакирование. Назначение лакирования и его виды. [Электронный ресурс]. Режим доступа: http://book.calculate.ru/book/otdelka_tari_i_produkcii_drugih_vidov_posle_pechati/lakirovanie._n aznachenie_lakirovaniya_i_ego_vidi/ (дата обращения: 10.01.2017).
2. Бобров В.И., Горшкова Л.О. Технология лакирования печатной продукции. Учебное пособие. М.: МГУП, 2015. 128 с.
3. Современные лакировальные технологии: каталог оборудования. М.: Электрограф. 36 с.
4. Прибор для оценки качества оттисков, глянца. [Электронный ресурс]. Режим доступа: http://www.zehntner.com/products/categories/gloss/zgm-1020/ (дата обращения: 12.01.2017).
ОБЗОР ПОДХОДОВ И МЕХАНИЗМОВ ТЕСТИРОВАНИЯ БАЗ
ДАННЫХ
Величкевич А.Г.1, Черепахин А.А.2, Кудряшов Н.И.3, Мельникова К.Б.4, Бычков Б.И.5 Email: Velichkevich1796@scientifictext.ru
'Величкевич Андрей Геннадьевич — магистрант; 2 Черепахин Артем Алексеевич — магистрант; 3Кудряшов Никита Игоревич — магистрант; 4Мельникова Ксения Борисовна — магистрант; 5Бычков Борис Игоревич — магистрант, кафедра компьютерных систем и сетей, факультет информатики и систем управления, Московский государственный технический университет им. Н.Э. Баумана,
г. Москва
Аннотация: в данной работе освещены основные подходы к тестированию баз данных, их классификация, достоинства и недостатки. Рассмотрены механизмы функционального и нагрузочного тестирования, в том числе основанные на бизнес-процессах и сценариях действий пользователя. Подчеркнута важность применения аудита и правильного выбора исходных данных для тестирования. Приведены особенности работы специального инструментария для тестирования производительности. Оценена зависимость результатов от согласованности хранимых данных. Сделаны выводы об особенностях тестирования баз данных. Ключевые слова: база данных, модульное тестирование, нагрузочное тестирование, датафикация, аудит.
DATABASE TESTING APPROACHES AND MECHANISMS Velichkevich A.G.1, Cherepakhin A.A.2, Kudryashov N.I.3, Melnikova K.B.4, Bychkov B.I.5
'Velichkevich Andrey Gennadievich — undergraduate;
2Cherepakhin Artem Alexeevich — undergraduate;
3Kudryashov Nikita Igorevich — undergraduate;
4Melnikova Ksenia Borisovna — undergraduate;
5Bychkov Boris Igorevich — undergraduate, DEPARTMENT OF COMPUTER SCIENCE AND CONTROL SYSTEMS, BAUMANMOSCOW STATE TECHNICAL UNIVERSITY, MOSCOW
Abstract: this article is dedicated the main approaches of database testing process, it's classification, advantages and disadvantages. The mechanisms of functional and load testing are considered, including those based on business processes and scenarios of user actions. The importance of applying the audit and the correct choice of the initial data for testing is underlined. Features of the special tool for performance testing are given. The consistency results of the stored data is estimated. Conclusions are made about the features of testing databases. Keywords: database, unit testing, load testing, datafication, audit.
УДК 004.415.53
Введение
Современные условия организации рабочего процесса на предприятиях требуют проектирования сложных, в том числе распределенных, баз данных (БД) [1, 2]. При этом широкое распространение получили различные программные системы, призванные служить интерфейсом пользователя при работе с БД [3]. Подход к тестированию подобной системы отличается от такового для обычного приложения. Поскольку для работы с БД используется непроцедурный язык запросов SQL, классические методы белого и черного ящика не подходят для разработки тестов. Данная работа посвящена подходам и методам тестирования БД и программных систем, их использующих.
Подходы к тестированию баз данных
Согласно ГОСТ, оценка качества программной продукции осуществляется по следующим критериям: функциональность, надежность, практичность, эффективность, сопровождаемость, мобильность [4]. При этом тестировать можно отдельные компоненты системы (модульное тестирование), их связи (интеграционное) или всю систему в целом (системное). Типовая программная система, использующая БД, как правило, состоит из следующих компонентов:
- база данных;
- пользовательский веб-интерфейс;
- серверная часть, отвечающая за связь интерфейса и БД;
- модуль отчетов (если они не интегрированы в интерфейс).
Целесообразной является оценка функциональности БД в виде модульного тестирования интерфейсов и отчетов, системного тестирования приложения по утвержденным в техническом задании бизнес-процессам, оценка надежности в виде нагрузочного тестирования. При этом могут применяться специальные метрики [5].
Поскольку язык SQL непроцедурный, правильность написания запросов можно проверить лишь на конкретных массивах данных, составленных с учетом используемой схемы БД. При этом нужно иметь эталонные результаты выполнения запросов.
Данные, загружаемые в БД для тестирования, должны предоставлять возможность тестирования всех деталей пользовательского интерфейса и отчетов. Поэтому процесс тестирования тесно связан с датафикацией - формированием целостных полезных данных для заполнения БД.
Данные в БД можно условно разделить на две части: исходные (первичные) и вторичные. Исходные данные должны быть загружены в БД до начала работы системы и до ее тестирования (например, перечень географических объектов для системы, связанной с путешествиями). Для проверки правильности введенных исходных данных разрабатываются сверочные отчеты. Зачастую для генерации непротиворечивых данных требуется выполнить отдельное исследование [6]. Вторичные данные появляются в БД в процессе эксплуатации
системы, поэтому процедура их загрузки также подлежит тестированию, которое облегчается использованием аудита.
Аудит применяют для отслеживания изменений БД и осуществляется следующим образом. Из бизнес-процессов выделяют действия пользователя, модифицирующие БД: добавление, редактирование и удаление данных. Создают триггеры на операции модификации всех подлежащих проверке таблиц. Каждый триггер добавляет в отдельно созданную базу данных аудита записи, содержащие имя таблицы, тип операции (добавление, изменение, удаление), идентификатор измененной строки, дату изменения, автора изменения. По хранимым в БД аудита данным несложно восстановить последовательность действий пользователя, а также проверить корректность каскадного обновления таблиц.
На этапе тестирования имеет смысл организовать расширенный аудит для контроля подробностей всех изменений. По окончании тестирования база аудита может быть удалена или сокращена для ускорения работы системы.
Функциональное тестирование системы
Ошибка (баг) - это любое несоответствие работы приложения спецификациям (техническому заданию), а также тому, что ожидает от приложения пользователь в процессе работы с ним. Если исходить из такого определения ошибки, следует учитывать не только корректность выполнения операций, но и дружественность интерфейса. Дружественность предполагает, что пользователь понимает, к чему может привести та или иная его активность в системе, и это понимание совпадает с реальным процессом работы приложения.
Наиболее общий метод тестирования - выделение сценариев действий пользователя и отслеживание выполнения программы на них, с указанием расхождений с бизнес-процессами. По результатам тестирования системы с применением заданных сценариев составляют протокол тестирования, где указана подробная информация о найденных ошибках. Желательно подробно описать условия, в которых ошибка появляется. Протокол тестирования отправляют профильным группам разработчиков, которые вносят исправления. После этого тестирование повторяют, составляют новый протокол. Должны быть пройдены, по крайней мере, две итерации тестирования.
Модульное тестирование интерфейса в случае с БД часто сводится к оценке его дружественности пользователю. В частности, проверяются: соответствие названий кнопок и назначенных им операций, ссылки, переходы, заложенные в интерфейс, валидация вводимых данных. Тестирование отчетов представляет собой проверку выдаваемых результатов в соответствии с заданными входными параметрами.
По итогам тестирования составляется документ «Программа и методика испытаний», который регламентирует приемку разработанной системы заказчиком [7].
Нагрузочное тестирование
Нагрузочное тестирование, или тестирование производительности - это автоматизированное тестирование, имитирующие работу определенного количества пользователей на каком-либо разделяемом ресурсе. Основные виды нагрузочного тестирования: тестирование производительности, стрессовое тестирование, объемное тестирование, тестирование стабильности или надежности [8, 9].
Задачей тестирования производительности является определения масштабируемости приложения под нагрузкой, при этом происходит:
- измерение времени выполнения выбранных операций при определенных интенсивностях выполнения этих операций;
- определение количества пользователей, одновременно работающих с приложением;
- определение границ приемлемой производительности при увеличении нагрузки;
- исследование производительности на высоких, предельных, стрессовых нагрузках.
Стрессовое тестирование позволяет проверить, насколько система в целом работоспособна
в условиях стресса, и оценить ее способность к регенерации, т.е. к возвращению к нормальному состоянию после прекращения воздействия стресса. Стрессом в данном контексте может быть повышение интенсивности выполнения операций до очень высоких значений или аварийное изменение конфигурации сервера. Одной из задач при стрессовом тестировании может быть оценка деградации производительности.
Задачей объемного тестирования является получение оценки производительности при увеличении объемов данных в базе данных приложения.
Задачей тестирования стабильности (надежности) является проверка работоспособности приложения при длительном тестировании со средним уровнем нагрузки. Время выполнения операций может играть в данном случае второстепенную роль. При этом на первое место
выходит отсутствие утечек памяти, перезапуска серверов под нагрузкой и другие аспекты, влияющие именно на стабильность работы.
Нагрузочное тестирование проводят с помощью специальных средств, таких как Apache JMeter, HP LoadRunner. Данные инструменты имеют возможность создания большого количества запросов с помощью нескольких компьютеров при управлении процессом с одного из них. Архитектура, поддерживающая плагины сторонних разработчиков, позволяет дополнять инструменты новыми функциями. В программах реализованы механизмы авторизации виртуальных пользователей, поддерживаются пользовательские сеансы, логирование результатов теста, и разнообразная визуализация результатов в виде диаграмм, таблиц.
Для отдельных операций работы с БД разрабатывают тест-кейсы. С помощью прокси-сервера имитируется работа реального сервера. После формирования необходимых запросов в инструментах нагрузочного тестирования задается число виртуальных пользователей, выполняющих эти запросы на определенном промежутке времени. Система мониторинга позволяет наблюдать за тем, в какой момент времени и при каком количестве виртуальных пользователей сервер начинает занимать дополнительные ресурсы.
Заключение
Сложность и глубина тестирования БД определяются техническим заданием на систему и разработанной схемой данных. Процессы тестирования и датафикации тесно связаны, так как без правильно сформированных данных тестирование приложения не имеет смысла.
Описанные подходы могут быть использованы при разработке систем работы с БД. Следует помнить, что никакое тестирование не может обеспечить гарантии работоспособности системы, так как оно ограничено некоторыми условиями. Требуется довести до сведения пользователя, что делать в случае некорректной реакции системы на его действия, предусмотреть соответствующие разделы в руководствах пользователя и администратора.
Список литературы / References
1. Иванова Н. С. Конкурентная стратегия компании // Проблемы современной науки и образования, 2015. № 2 (42). С. 99-101.
2. Киселев Ю.B., Кузнецов ИЛ. Разработка и тестирование базы данных рекомендательной системы // Теория. Практика. Инновации. М.: ООО «Вектор науки», 2016. № 7 (7). С. 18-25.
3. МавлютовA.P., AmнабаевA.Ф., ИльметовР.К. Модуль объединения пространственных баз геоданных для ARCMAP // Вестник науки и образования, 2017. № 1. С. 21-23.
4. Ревякина O.B., Болдырева Л.М. Интеграция базы данных клиентов и профессиональной САПР одежды в единой информационной системе предприятия // Проблемы современной науки и образования, 2016. № 26. С. 32-36.
5. ГОСТ Р ИСО/МЭК 9126-93. Информационная технология. Оценка программной продукции. Характеристики качества и руководства по их применению.
6. Суслов Ю.Б. Анализ параметров баз данных и разработка системы метрик тестирования баз данных // Сборник трудов рег. научно-технической очно-заочной конф. (Ижевск, 21 мая 2016). Ижевск: Изд-во Ижевского государственный технический ун-та им. М.Т. Калашникова, 2016. С. 75-81.
7. Костычев E.A., Омельченко B.A., Зеленов C.B. Нацеленная генерация данных для тестирования приложений над базами данных // Труды института системного программирования РАН, 2011. Т. 20. С. 253-268.
8. Программа и методика испытаний по ГОСТ 19.301-79. [Электронный ресурс]: ООО «Техническая документация». Режим доступа: http://tdocs.su/12290/ (дата обращения: 01.04.2017).
9. Нагрузочное тестирование. [Электронный ресурс]: ПроТестинг. Режим доступа: http://www.protesting.ru/testing/types/loadtesttypes.html/ (дата обращения: 01.04.2017).
10. РудюкЕ.П., Соломатин A.A. Оценка производительности сервера базы данных путем применения нагрузочного тестирования // Наука, техника и образование: электрон, 2016. № 4 (9). С. 97-106.
