CC BY
41
(человеческий фактор). Еще одним препятствием для регрессивного тестирования является ограниченность рабочего ресурса аппаратуры.
Автоматическое проведение тестов, в том числе регрессивных, ограничивается тем, что для генерации входных тестовых воздействий необходима дополнительная аппаратура и, возможно, ОУ.
В классическом варианте встраивание средств тестирования в архитектуру системы является необязательным, для РИУС это жизненно необходимо. Практика показывает, что тестирование РИУС требует создания соизмеримого с ней или даже превосходящего ее по сложности тестового комплекса.
Как видно из представленных примеров, применение классических способов тестирования либо не дает должного эффекта, либо приводит к очень большим материальным затратам. Для ликвидации этого разрыва требуется переосмысление привычных подходов к проектированию встроенных систем.
Можно отметить, что ни исчерпывающее входное тестирование, ни исчерпывающее тестирование маршрутов не могут стать полезными стратегиями, потому что оба они не реализуемы. Поэтому реальным путем, который позволит создать хорошую, но, конечно не абсолютную стратегию, является сочетание тестирования программы несколькими методами.
Литература
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-диаграмма, модель, корректность, класс.
TEST MODELS OF OBJECT-ORIENTED SOFTWARE Kasylkasova A. O.1, Kogay G. D.2, Kaybasova D. Zh.3, Kasylkasova K. N.4, Bimbetova G. M.5, Bukanov Zh. U.6
'Kasylkasova Ayman Oshakpaevna - senior lecturer, DEPARTMENT OF WELDING AND FOUNDRY;
2Kogay Galina Davydovna - PhD, associate professor;
3Kaybasova Dinara Zhenisbekovna - senior lecturer, master;
4Kassylkassova Kamila Nuralievna - graduate student, DEPARTMENT OF INFORMATION AND COMPUTER SYSTEMS;
5Bimbetova Gauhar Myrzahmetovna - senior lecturer, master, DEPARTMENT OF PHYSICS;
6Bukanov Zhanat Umirtaevich - senior lecturer, master, DEPARTMENT OF METALLURGY, MATERIALS SCIENCE AND NANOTECHNOLOGY, KARAGANDA PUBLIC OF TECHNICAL UNIVERSITY, KARAGANDA, KAZAKHSTAN
Abstract: despite the relatively recent emergence of object-oriented languages such as Smalltalk, Object Pascal, C ++, Ada, object-oriented programming (OOP) has become the most widely used software development style (software) in the world. OOP - programming methodology, based on the idea of the program as a set of objects, each of which is an instance of a particular class, and classes form an inheritance hierarchy. OOP means event-handling. In order to control the quality of object-oriented software testing is necessary to solve the problem of automation, which requires the development of new models, methods and algorithms that are adapted to the object-oriented software. The article specifies the reasons that lead to need for testing models of object-oriented programming and describes the most popular of the existing approaches to testing the main types of the UML-diagrams, including use case diagram, class diagram, state diagram and sequence diagram. Keywords: testing, object-oriented software, the UML-diagram model is correct, the class.
УДК 00.004
Создание объектно-ориентированного языка было следствием все большего возрастания сложности программного обеспечения и увеличивающейся потребности в методах обеспечения им качества. В результате чего и был создан объектно-ориентированный язык.
Тестирование является одним из важнейших этапов разработки объектно-ориентированного программного обеспечения [1, с. 239] и представляет собой процесс исследования программного обеспечения с целью получения информации о качестве продукта. Тестирование программного обеспечения проходит в несколько этапов:
a. Тестирование модели программного обеспечения.
b. Тестирование его классов.
c. Проверка взаимодействия компонентов.
d. Системное тестирование.
e. Приемочные испытания.
ЕПроверка развертывания системы.
Сразу же после окончательной формулировки технического задания к проекту начинается этап проектирования, то есть создания модели разрабатываемого программного обеспечения. Для этого проводится анализ предметной области, который позволяет учесть ошибки других систем, подобных разрабатываемой, и уточнить сомнительные нюансы разрабатываемой системы, а также анализ приложения, то есть анализ задачи и требований к ее решению. Результатом проектирования является проектная модель системы [3, с. 23], чаще всего представляемая в виде UML-диаграмм [2, с. 300], которая и подлежит тестированию.
Для анализа и валидации требований на ранних стадиях модель системы может быть связана с проектными требованиями [4]. Это является наиболее распространенной проблемой, когда поставленные требования не дополняют друг друга, а наоборот вызывают конфликт, вследствие взаимного противоречия. И система не отвечает в полной мере потребностям заказчика.
Тестирование классов выполняется по мере того, как оно становится целесообразным или необходимым. Тестирование классов имеет смысл выполнять в процессе написания программных кодов, когда разработчику нужно узнать, какие детали упущены, и убедиться в правильности некоторой части реализации [3, с. 35]. В случаях необходимости добавления к базовому программному коду какого-нибудь компонента ПО, тестируются классы. Причем разработка класса не обязательно будет завершенной, хотя поведение его, должно быть правильным и представленным в завершенном виде.
Тестирование классов охватывает все виды деятельности, ассоциированные с проверкой реализации класса на точное соответствие спецификации этого класса. Если программа при тестировании реализуется корректно, то каждый экземпляр этого класса поведет себя правильно.
Еще один подход к тестированию классов основан на построении графов и предназначен для выявления противоречивых ограничений. Метод основан на построении ориентированного графа, который называется идентификационным графом, узлы которого обозначают классы и ассоциации, а его дуги соединяют ассоциативные узлы с классовыми узлами.
Диаграмма состояний - это некоторый автомат, который рассматривает действия объекта от состояния к состоянию, в течение его жизненного цикла, и описывает реакций на события.
При тестировании диаграмм последовательностей необходимо обеспечить корректный обмен сообщениями между объектами, классы которых были ранее протестированы.
Так как некоторые объекты на диаграмме последовательности будут существовать постоянно, а некоторые временно, то, прежде всего, следует убедиться в том, что для уничтожения объектов, которые создаются на время выполнения своих действий, предусмотрены явные сообщения. Для этого используются коллекции объектов, представляющие собой наборы объектов, каждый из которых использует в своей спецификации объекты, но фактически не взаимодействует с ними, а вместо этого выполняет одно или несколько из следующих действий [3, с. 55]:
- сохраняет ссылки на такие объекты, которые обычно представляют отношения один-ко-многим между объектами программы;
- создает экземпляры этих объектов;
- удаляет экземпляры этих объектов.
После этого тестируются взаимодействия между объектами, где в условиях контактного подхода следует уточнить выполнены ли объектом-отправителем предусловия методов получающего объекта. Нарушение этих предусловий не допустимо. Чаще всего объект-получатель переводится в определенное заданное состояние. После чего инициируется выполнение тестового драйвера, по условиям которого объект-отправитель требует, чтобы объект-получатель находился в другом состоянии. В то же время контролируется корректно ли объект-отправитель завершает свою деятельность, возможно, генерируя при этом исключение.
Также можно протестировать протоколы. При взаимодействии некоторого объекта с другими, по мере того, как некоторый объект вступает во взаимодействие с другими объектами, увеличивается число сообщений, которые поступают к искомому. Все эти сообщения выстраиваются в строгую последовательность. Тестированию по протоколу надлежит реализация соответствия этой последовательности. Различные протоколы, в которых Протоколы, в которых задействован тот или иной объект можно логически выводить из пред- и постусловий, отвечающий за соблюдение необходимых операций, в классе этого объекта.
Тестирование проектной модели является самым главным и необходимым этапом тестирования объектно-ориентированного ПО. Это обеспечивает тестирование всех UML-диаграмм, из которых состоит модель. К ним относятся основные виды UML-диаграмм, в том числе: диаграмма вариантов использования, диаграмма классов, диаграмма состояний и диаграмма последовательностей. В статье озвучены особо распространенные и популярные и действенные варианты выполнения тестирования основных видов UML-диаграмм. В завершение каждая диаграмма подвергается проверке на корректность. Только после всех этих процедур можно делать вывод о пригодности проектной модели объектно-ориентированного программного обеспечения для эффективной разработки программного обеспечения.
Список литературы / References
1. Balaban М. Management of Correctness Problems in UML Class Diagrams Towards a Pattern-
based Approach / Balaban М., Maraee А., Stur А. Beer Sheva: Department of Computer Science,
Ben-Gurion University of the Negev, 2002. P. 33.
2. Chillarege R. et al. «Orthogonal Defect Classification. A Concept for In-Process Measurements».
IEEE Transactions on Software Engineering 18. November 1992. P. 943-956.
3. Макгрегор Дж. Тестирование объектно-ориентированного программного обеспечения.
Практическое пособие / Дж. Макгрегор, Д. Сайкс; пер. с англ. К.: ООО «ТИД «ДС»», 2002. 432 с.
