Дж. Рамбо, М. Блаха - UML 2.0 - Объектно-ориентированное моделирование и разработка (1158633), страница 88
Текст из файла (страница 88)
Это называется модульныч тестированием (цпй Гез11пй). Затем нужно перейти к тестированию взаимодействия (1птедгавоп гезг1пй), то есть к проверке согласованности классов и методов. Тестирование взаимодействия осуществляется путем последовательного объединения все больших блоков кода и поведения. Такое тестирование должно проводиться уже на ранних этапах разработки (см. главу 21). Завершающий этап — системное тестирование (зузтеш Гезт1пя), при котором проверяется все приложение в целом. 17.5.1. Модульное тестирование Обычно разработчики проверяют свой собственный код и выполняют тестирование взаимодействия, потому что они понимают конкретную логику приложения и знают, где нужно искать ошибки. Модульное тестирование выполняется по тем же принципам, что и до эпохи объектно-ориентированного программирования: разработчики пытаются перебрать все возможные случаи, использовать особые значения аргументов, а также проверяют свои блоки на устойчивость, наличие ошибок счета объектов и др. Если методы и классы достаточно просты, вы легко сможете подготовиться к тестированию модулей.
Можно снабдить объекты и методы средствами для обнаружения ошибок. Вы можете помещать в код какие-либо утверждения (аззег11опз): предусловия, постусловия, инварианты. Ошибки нужно стараться обнаруживать вблизи их источника, а не далее по ходу программы, где их результат может быть не столь очевиден. Мы поддерживаем рекомендации, касающиеся парной работы программистов и активной инспекции кода. При этом мы рекомендуем выполнять формальный обзор программ (см. главу 22), когда разработчики предоставляют свой код коллегам с целью услышать их мнение.
17.6. Резюме 369 17.5.2. Системное тестирование В идеале системное тестирование должно выполняться отдельной командой, ие зависящей от разработчиков. На эту роль подходит оргаиизация контроля качества (йпа11гу аззцгапсе). Подход к системному тестированию должен быть выработав иа основании аналитической модели, построенной по исходным требоваииям. Тестовая среда должна готовиться параллельно с разработкой системы. Тогда тестеры ие будут отвлекаться иа детали разработки и смогут дать иезависимую оценку приложения, что сократит вероятность пропуска ошибки. После завершения альфа-тестирования клиенты выполняют бета-тестирование, а затем программа готовится к выпуску законченной версии.
Тестовые сценарии иа уровне системы определяются вариантами использоваиия из модели взаимодействия. Дополнительные сценарии можно строить иа осиоваиии вариантов использования или конечных автоматов. Выберите несколько типичных случаев, ио ие забудьте и про нетипичные ситуации (иулевое количество проходов цикла, максимальное количество проходов цикла, одновременное осуществление событий — если оио допускается моделью и т.
д.). Хорошие тестовые сценарии получаются из нетипичных последовательностей смены состояний конечного автомата, потому что при этом проверяются принятые по умолчанию предположения. Не забудьте уделить внимание производительности: нагрузите систему одновременным распределенным доступом нескольких пользователей, если, конечно, это подразумевалось в системных требованиях.
Используйте тестовую систему по максимуму. Тестовая система (гезг зп)ге) полезна для проверки кода после исправления ошибок и обнаружения ошибок, которые появятся в будущих выпусках той же системы. Автоматизация тестироваиия системы с интерактивным пользовательским интерфейсом может представлять определенную сложность, ио в любом случае вы можете задокументировать тестовые сценарии для последующего использования. Пример с банкоматом. Мы аккуратно подготовили модель банкомата в соответствии с предлагаемой методологией.
Поэтому если бы иам нужно было иаписать само приложение, с тестированием у иас бы проблем ие возиикло. 17.6. Резюме Реализация — это последний этап разработки, иа котором приходится иметь дело со спецификой языков программирования. В первую очередь нужно заняться вопросами реализации, ие зависящими от выбранного языка. Иногда бывает полезио подкорректировать классы, прежде чем приступать к написанию кода, чтобы упростить разработку или повысить производительиость. Делать это без веских оснований ие следует. Ассоциация — ключевая концепция, лежащая в основе модели классов ()М1., однако эта концепция ие поддерживается большинством языков программироваиия иепосредствеиио.
Тем ие менее в процессе изучения требований нужно сохраиять ясность мысли и пользоваться ассоциациями, а иа переходе к реализации заменять их более примитивными конструкциями. Существует два основных ЗУО Глава 17 ° Моделирование реализации способа реализации ассоциаций: при помощи указателей (в одном или двух направлениях) и при помощи отдельных объектов. Объект ассоциации — зто пара объектов-словарей (по одному для каждого направления). Аккуратное моделирование сокращает вероятность ошибок, но не исключает необходимость тестирования.
Вы должны выполнить модульное тестирование, тестирование взаимодействия и системное тестирование. В процессе модульного тестирования разработчики проверяют написанные ими самими классы и методы. Тестирование взаимодействия заключается в объединении различных классов и методов. Системное тестирование — зто проверка всего приложения в целом на предмет соответствия выявленным на агапе анализа требованиям. Таблица 17.1. Ключевые понятия главы Библиографические замечания Разделы 17.2 и 17.3 мотивируются концепцией трансформаций.
Исчерпывающее рассмотрение трансформаций приводится в работе [Вайп?-92]. Дополнительные трансформации описываются в [В1аЬа-96] и [В!аЬа-98]. Литература [Вабш-92] Саг!о Вас!п?, Яге?апо Сеп', апд 8Ьаш?ганг В. Ь?анагЬе. Сопсерспа! РагаЬазе Рез18п: Ап Епбгу-Ве?айопзЬ1р АрргоасЬ. ВегЬтоог? Сйу, СА: Веп]аш1п Сцшш!пйз, 1992. [В!аЬа-96] М!сЬае! В1аЬа апд Чг!11!аш Ргешег1ап!. А са?а?о8 о? оЬ]ест шог?е! сгапз!отша!!опз, ТЬ1гг? ЪЧогЬ1п8 Соп?егепсе оп Ветегзе Еп81пеепп8, ХочешЬег 1996, Мопгегеу, СА, 87 — 96. [В!аЬа-98] МкЬае! В1аЬа ап4 Чг1111аш Ргетег1аш.
ОЬ]есг-Опелей Мог?е?1п8 апг? Рез!8п ?ог РагаЬазе Арр!кагюпз. (?ррег Яаг?г?!е В?чег, Щ: Ргепйсе На!1, 1998. [ВцшЬац8Ь-87] [ашез Е. ВшпЪац8Ь. Ве1атюпз аз зешапйс сопзгпкгз !и ап оЬ]есгопепгед 1апйцайе. ООРЯ.А'87 аз АСМ 3?СР1 АЬ? 22, 12 (РесешЬег 1987), 466 — 481. Упражнения 17.1. (7) Реализуйте все ассоциации, имеющиеся на рис. 17.6. Используйте односторонние или двусторонние указатели в соответствии с семантикой задачи. Ответ поясните. объект ассоциации словарь моделирование реализации тестирование интеграции указатель тестирование системы трансформация модульное тестирование двусторонняя ассоциация односторонняя ассоциация упражнения 371 17.2. (5) Реализуйте все ассоциации, имеющиеся на рис.
У12.3. Используйте односторонние или двусторонние указатели в соответствии с семантикой задачи. Ответ поясните. 17.3. (4) Реализуйте все ассоциации, имеющиеся на рис. У15.2. Используйте односторонние или двусторонние указатели в соответствии с семантикой задачи. Ответ поясните. 17А. (3) Реализуйте все ассоциации, имеющиеся на рис. У15.3. Используйте односторонние или двусторонние указатели в соответствии с семантикой задачи. Ответ поясните. 17.5. (7) Реализуйте все ассоциации, имеющиеся на рис. У12А. Используйте односторонние или двусторонние указатели в соответствии с семантикой задачи.
Должен ли какой-нибудь из полюсов ассоциаций быть упорядоченным? Ответ поясните. О бъектноориентированные языки В этой главе рассматривается реализация готового проекта на языках С++ и )ача. Именно эти объектно-ориентированные языки распространены в настоящее время наиболее широко. Цель данного этапа: получить код программы. Мы не пытаемся уместить учебник по С++ или )ача в одну главу. Мы хотели подчеркнуть особенности этих языков и рассказать о том, каким образом их следует использовать для реализации моделей.
Материалы для этой главы предоставила Крис Келси, за что мы ей очень благодарны. 18.1. Введение Реализовать объектно-ориентированный проект на объектно-ориентированном языке довольно легко, поскольку языковые конструкции в данном случае близки к проектным. В этой книге мы расскажем о языках С++ и )ага, так как они распространены наиболее широко. Даже если вы работаете с другим языком, большинство принципов от этого не изменятся. У языков С++ и )ача много общего. Язык )ага моложе С++ и заимствовал довольно большую часть синтаксиса последнего.