CC BY
51
ТЕХНИЧЕСКИЕ НАУКИ
PROBLEMS VERIFICATION AND SOFTWARE TESTING INFORMATION-MANAGEMENT SYSTEMS Amirov A.1, Kogan G.2, Tomilov A.3, Kasylkasova A.4, Kasylkasova K.5 ПРОБЛЕМЫ ВЕРИФИКАЦИИ И ТЕСТИРОВАНИЯ
ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ИНФОРМАЦИОННО-УПРАВЛЯЮЩИХ СИСТЕМ Амиров А. Ж.1, Когай Г. Д.2, Томилов А. Н.3, Касылкасова А. О.4,
Касылкасова К. Н.5
'Амиров Азамат Жанбулатович/Amirov Azamat - PhD, заведующий кафедрой;
2Когай Галина Давыдовна /Kogay Galina — кандидат технических наук, доцент;
3Томилов Александр Николаевич / Tomilov Alexander — докторант;
4Касылкасова Айман Ошакпаевна /Kasylkasova Ayman — старший преподаватель;
5Касылкасова Камила Нуралиевна / Kasylkasova Kamila — магистрант, кафедра информационно-вычислительных систем,
Карагандинский государственный технический университет, г. Караганда, Республика Казахстан
Аннотация: в статье рассмотрены разработка технологии верификации и тестирования распределённых информационно-управляющих систем и проблемы при создании программного обеспечения информационно-управляющих систем. Информационно-управляющие системы востребованы в современном рынке. Их применение помогает решать задачи в самых различных областях человеческой деятельности. Использование информационно-управляющих систем позволяет повышать эффективность хозяйственной и экономической деятельности, сберегать ресурсы и улучшать условия жизни человека. Автоматизация процесса проектирования программного обеспечения информационно-управляющих систем является важной задачей, позволяющей улучшить характеристики, как конечного изделия, так и самого процесса разработки.
Abstract: the article describes the development of verification technology and testing of distributed information management systems and the problems of software development management information systems. Information-management system makes calling for contemporary market. Their practice helps to solve problems in widely differing areas of human activity. The appliance of information management systems allow to improve the efficiency of business and economic activities to save resources and improve the human condition. Automation of process design software information management systems is an important task, which allows to improve the performance, as the final product, and of the development process.
Ключевые слова: информационно-управляющие системы, технология верификации, тестирование, автоматизация процесса проектирования, программное обеспечение, разработка.
Keywords: information-management system, verification technology, testing, automation of process design, software development.
В рамках модельно-ориентированного проектирования модель системы служит исполняемой спецификацией для разработки элементов и верификации. Полученные ранее тестовые процедуры для применения на системном уровне могут быть повторно использованы для подробной проверки разработанных элементов на соответствие исполняемой спецификации.
При создании программного обеспечения информационно-управляющих систем (ПО ИУС), в том числе системного программного обеспечение (СПО), существует ряд проблем. Одной из основных проблем является повышения качества и надежности программного обеспечение. Перспективным способом решения данной задачи является построение и верификация моделей программного обеспечение информационно-управляющей системы, которая позволяет делать математически доказанные выводы о выполнении требований безопасности и надежности для сложных систем, которые не могут быть исследованы другими методами.
В настоящее время существует ряд методов построения и автоматизированной верификации моделей ПО ИУС, однако их использование на практике затруднено из-за сложности применения методов и высокой стоимости инструментов.
Технологии проверки и подтверждения, используемые в процессе разработки, позволяют выявлять ошибки на ранних этапах проектирования. Большинство ошибок возникает на этапе формирования первичной спецификации, однако проявляются только при тестировании. Используя модели для виртуального тестирования на ранних этапах проектирования, специалисты могут сократить время разработки до 50%.
Чтобы глубже изучить поведение системы, следует использовать модели, содержащие описание программной составляющей, физические аспекты и особенности окружающей среды. Для анализа и валидации требований на ранних стадиях модель системы может быть связана с проектными требованиями. Например, продукты MathWorks для физического моделирования позволяют создавать функциональные модели объектов, фиксировать параметры проекта и функциональные требования в среде моделирования. Эти модели можно исполнять совместно с программными моделями. Разработчик может моделировать параметры разработки и анализировать модели, используя формальные методы для улучшения проекта и обнаружения непредвиденной функциональности, что проблематично сделать исключительно при помощи исполнения моделей. При помощи Simulink Design Verifier™ генерируются тесты для модели и подтверждаются параметры [1].
Разработчик получает доступ ко всему пространству параметров системы, благодаря чему может выбрать тесты, критичные для запуска на целевых вычислительных устройствах в реальном времени или на реальной аппаратуре. Моделирование по методу Монте-Карло, реализованное в продукте SystemTest, позволяет сгенерировать большие случайные пространства параметров для проверки системы. При помощи Simulink Verification and Validation™, разработчик может связать модель системы с проектными требованиями для их изучения и валидации на ранней стадии.
Понятие модельно-ориентированного проектирования включает в себя исполнение моделей и тестирование. Это помогает организовать процесс разработки и верификации. Благодаря итеративному исполнению моделей, тестированию и анализу, разработчик получает возможность обнаружить ошибки на ранней стадии, когда их проще и дешевле всего устранить.
В настоящее время наблюдается повышение уровня автоматизации в различных сферах человеческой деятельности, переход на новые технологии построения систем автоматизации. В значительной мере этому способствует использование заказных встроенных систем управления объектами. Таким образом, проектирование встроенных вычислительных систем приобретает массовый характер.
Ко многим подобным системам предъявляются повышенные требования по надежности и безопасности функционирования. Так как тестирование - это основной метод измерения качества, определения корректности и реальной надежности функционирования программ [2], приобретает большое значение вопрос о применимости классических методов тестирования программ к ПО встроенных систем и в частности - ПО распределенных информационно - управляющих систем (РИУС).
Распределенная информационно-управляющая система (РИУС) - один из самых сложных видов встроенных систем. Перечислим классические задачи при тестировании ПО [1]:
1. Тестирование функциональности: проверка функциональности системы на соответствие требованиям.
2. Тестирование производительности: определение характеристик производительности.
3. Стрессовое тестирование системы при предельной нагрузке на различные ресурсы.
4. Проверка устойчивости системы к неполадкам и безопасного оперативного восстановления при сбоях: оценка эффективности защиты от аппаратных сбоев, последствий проявления невыявленных дефектов и ошибок программ и данных.
5. Тестирование совместимости ПО со всеми модификациями аппаратуры, для которых оно предназначено.
6. Анализ исходных текстов (просмотр экспертом и автоматический анализ).
7. Оценка удобства использования системы.
8. Тестирование способности модулей системы к взаимодействию, в том числе перераспределения нагрузки.
9. Тестирование надежности: проверка поведения при длительной непрерывной эксплуатации при большой нагрузке.
Несмотря на многообразие методов и инструментов тестирования, как правило, некоторые ошибки все равно остаются не выявленными. Основной причиной этого является недостаток времени и сил для тестирования. Эффективность тестирования можно повысить, встроив средства тестирования в архитектуру системы уже на этапе проектирования - практикуется также создание
тестов перед написанием тестируемого кода. Еще один путь - автоматическая генерация тестовых наборов и автоматическое проведение тестов, особенно регрессивных.
На процесс тестирования и отладки системного ПО РИУС влияют следующие факторы:
- РИУС - сложный программно-аппаратный комплекс, состоящий из множества разнообразных компонентов;
- работа в реальном масштабе времени;
- в реальных условиях доступ к модулям РИУС часто затруднен или невозможен, так как они устанавливаются в труднодоступных местах; тяжелые климатические, механические и электромагнитные условия эксплуатации: высокая влажность, неблагоприятная температура, вибрация, сильные электромагнитные поля;
- жесткие требования к надежности и безопасности функционирования;
- тесная интеграция программного и аппаратного обеспечения РИУС: качественное тестирование ПО невозможно при отсутствии корректно функционирующей аппаратуры. В то же время на начальных стадиях разработки аппаратура работает нестабильно или не работает вообще.
- Таким образом, приходится тестировать сразу весь программно-аппаратный комплекс, каждый модуль которого может содержать ошибки. Это значительно усложняет интерпретацию результатов тестирования:
- во-первых, иногда некоторые ошибки компенсируют друг друга;
- во-вторых, из-за невозможности тестирования единичных модулей отдельно от всей системы очень трудно локализовать источник проблем.
Тестирование производительности РИУС малозначимо на фоне остальных задач. Однако существует гораздо более серьезная проблема - проверка способности системы к работе в реальном масштабе времени. Способов формального доказательства соответствия системы требованиям РВ пока не существует, а проверка на практике усложняется тем, что сама система тестирования при совместной работе с целевой системой искажает временные показатели и содержимое памяти. Таким образом, проблема может быть замаскирована инструментальной погрешностью или наоборот, может быть выдано ложное сообщение о несоответствии системы требованиям РВ. Более того, анализ причин проблемы будет затруднен из-за порожденных системой тестирования искажений в дампах памяти. Чтобы избежать этих трудностей, система тестирования интегрируется в целевую систему, но тогда появляется другая проблема: система тестирования съедает ресурсы, которых и так не хватает.
Тестирование совместимости: в отличие от тестирования ПО для универсальных персональных компьютеров, обычно не требуется проверки совместимости с широкой номенклатурой аппаратных и программных продуктов, а нужна только совместимость с продукцией этого же производителя и некоей базовой конфигурацией ПК. Таким образом, тестирование совместимости увеличивает общий объем работ по тестированию всего в несколько раз. Хотя анализ исходных текстов позволил бы обнаружить потенциальные дефекты ПО на ранних стадиях разработки, для проведения подобного анализа вручную необходим эксперт по аппаратуре и ПО. Проблема выбора и подготовки такого эксперта усугубляется сложностью и частой сменой элементной базы. Автоматизированный просмотр исходных текстов не представляется целесообразным: как правило, системное ПО РИУС не содержит сложных алгоритмов, а основное количество ошибок кроется в неправильном использовании регистров специального назначения, несоблюдении временных соотношений и т. п. Автоматическая система анализа исходных текстов вряд ли сможет обнаружить подобные ошибки, а значит, будет практически бесполезна.
Тестирование способности модулей системы к взаимодействию: несмотря на то, что эта способность является ключевой для РИУС, как правило, подобное тестирование проводится на малом числе модулей (воспроизведение необходимых внешних условий для большого числа модулей трудоемко и дорого).
Автоматической генерации тестов мешают такие факторы, как тесная связь ПО с аппаратурой, интеграция РИУС с ОУ, а также их модульность (это увеличивает объем тестовых испытаний: нужно создать тесты не для одной системы, а для множества разнообразных модулей). Автоматическая генерация тестов для РИУС сложна и в некоторых случаях опасна: некоторые, на первый взгляд совершенно невинные, наборы тестовых значений могут привести к катастрофе [3]. Поэтому перед запуском тесты обязательно должен проверять эксперт.
Регрессивное тестирование вручную очень трудоемко и требует использования сложного тестового оборудования. Практика показывает, что регрессивное тестирование одного контроллера только лишь для одного варианта внешних условий может длиться часами, при этом большое количество ручных операций делает возможным пропуск тестировщиком многих ошибок
(человеческий фактор). Еще одним препятствием для регрессивного тестирования является ограниченность рабочего ресурса аппаратуры.
Автоматическое проведение тестов, в том числе регрессивных, ограничивается тем, что для генерации входных тестовых воздействий необходима дополнительная аппаратура и, возможно, ОУ.
В классическом варианте встраивание средств тестирования в архитектуру системы является необязательным, для РИУС это жизненно необходимо. Практика показывает, что тестирование РИУС требует создания соизмеримого с ней или даже превосходящего ее по сложности тестового комплекса.
Как видно из представленных примеров, применение классических способов тестирования либо не дает должного эффекта, либо приводит к очень большим материальным затратам. Для ликвидации этого разрыва требуется переосмысление привычных подходов к проектированию встроенных систем.
Можно отметить, что ни исчерпывающее входное тестирование, ни исчерпывающее тестирование маршрутов не могут стать полезными стратегиями, потому что оба они не реализуемы. Поэтому реальным путем, который позволит создать хорошую, но, конечно не абсолютную стратегию, является сочетание тестирования программы несколькими методами.
Литература
1. Батурин Н. А. Технология разработки тестов: часть I / Н. А. Батурин, Н. Н. Мельникова // Вестник ЮУрГУ. Серия «Психология», 2009. Вып. 6. № 30 (163).
2. Липаев В. В. Надежность программных средств. Серия «Информатизация России на пороге XXI века». М.: СИНТЕГ, 1998. 232 с.
3. Ключев А. О. «Методы и инструментальное обеспечение разработки распределенных информационно-управляющих систем с программируемой архитектурой» тезисы кандидатской диссертации. СПбГИТМО(ТУ). Санкт-Петербург, 1999.
ТЕСТИРОВАНИЕ МОДЕЛЕЙ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Касылкасова А. О.1, Когай Г. Д.2, Кайбасова Д. Ж.3, Касылкасова К. Н.4, Бимбетова Г. М.5, Буканов Ж. У.6
'Касылкасова Айман Ошакпаевна — старший преподаватель, кафедра сварочного и литейного производства;
2Когай Галина Давыдовна — кандидат технических наук, доцент;
3Кайбасова Динара Женисбековна - старший преподаватель, магистр;
4Касылкасова Камила Нуралиевна — магистрант, кафедра информационно-вычислительных систем;
5Бимбетова Гаухар Мырзахметовна - старший преподаватель, магистр, кафедра физики;
6БукановЖанат Умиртаевич - старший преподаватель, магистр, кафедра металлургии, материаловедения и нанотехнологии, Карагандинский государственный технический университет, г. Караганда, Республика Казахстан
Аннотация: несмотря на сравнительно недавнее появление объектно-ориентированных языков, таких как Smalltalk, Object Pascal, C++, Ada, объектно-ориентированное программирование (ООП) стало наиболее широко используемым стилем разработки программного обеспечения (ПО) в мире. ООП - методология программирования, основанная на представлении программы в виде совокупности объектов, каждый из которых является экземпляром определенного класса, а классы образуют иерархию наследования. ООП подразумевает событийную управляемость. С целью управления качеством ОО ПО необходимо решать задачи автоматизации тестирования, что требует разработки новых моделей, методов и алгоритмов, приспособленных к ОО ПО. В статье указываются причины, которые приводят к необходимости проведения тестирования моделей объектно-ориентированных программ, а также описываются наиболее популярные из существующих подходы к проведению тестирования основных видов UML-диаграмм, среди которых диаграмма вариантов использования, диаграмма классов, диаграмма состояний и диаграмма последовательностей.
Ключевые слова: тестирование, объектно-ориентированная программа, UML-диаграмма, модель, корректность, класс.
