Сущность технологии COM
Основы тестирования программного обеспечения
Качество программного продукта характеризуется набором свойств, определяющих, насколько продукт "хорош" с точки зрения заинтересованных сторон, таких как заказчик продукта, спонсор, конечный пользователь, разработчики и тестировщики продукта, инженеры поддержки, сотрудники отделов маркетинга, обучения и продаж. Каждый из участников может иметь различное представление о продукте и о том, насколько он хорош или плох, то есть о том, насколько высоко качество продукта. Таким образом, постановка задачи обеспечения качества продукта выливается в задачу определения заинтересованных лиц, их критериев качества и затем нахождения оптимального решения, удовлетворяющего этим критериям. Тестирование является одним из наиболее устоявшихся способов обеспечения качества разработки программного обеспечения и входит в набор эффективных средств современной системы обеспечения качества программного продукта.Тестирование - способ обеспечения качества
С технической точки зрения тестирование заключается в выполнении приложения на некотором множестве исходных данных и сверке получаемых результатов с заранее известными (эталонными) с целью установить соответствие различных свойств и характеристик приложения заказанным свойствам.
Концепция тестирования
Формальный подход или доказательство применяется, когда из исходных формул-аксиом с помощью формальных процедур (правил вывода) выводятся искомые формулы и утверждения (теоремы). Вывод осуществляется путем перехода от одних формул к другим по строгим правилам, которые позволяют свести процедуру перехода от формулы к формуле к последовательности текстовых подстановок
Требования к идеальному критерию тестирования
Критерий должен быть достаточным, т.е. показывать, когда некоторое конечное множество тестов достаточно для тестирования данной программы. Критерий должен быть полным, т.е. в случае ошибки должен существовать тест из множества тестов, удовлетворяющих критерию, который раскрывает ошибку.Критерий должен быть надежным, т.е. любые два множества тестов, удовлетворяющих ему, одновременно должны раскрывать или не раскрывать ошибки программы
Оценка Покрытия Программы и Проекта
Тестирование программы Р по некоторому критерию С означает покрытие множества компонентов программы P М = {m1...mk} по элементам или по связям T = {t1...tn} - кортеж неизбыточных тестов ti. Тест ti неизбыточен, если существует покрытый им компонент mi из M(P,C), не покрытый ни одним из предыдущих тестов t1...ti-1. Каждому ti соответствует неизбыточный путь pi - последовательность вершин от входа до выхода.
Пример модульного тестирования
Модульное тестирование - это тестирование программы на уровне отдельно взятых модулей, функций или классов. Цель модульного тестирования состоит в выявлении локализованных в модуле ошибок в реализации алгоритмов, а также в определении степени готовности системы к переходу на следующий уровень разработки и тестирования.
Особенности интеграционного тестирования
Программный проект, написанный в соответствии с объектно-ориентированным подходом, будет иметь ГМП, существенно отличающийся от ГМП традиционной "процедурной" программы. Сама разработка проекта строится по другому принципу - от определения классов, используемых в программе, построения дерева классов к реализации кода проекта.
Системное тестирование
Системное тестирование качественно отличается от интеграционного и модульного уровней. Системное тестирование рассматривает тестируемую систему в целом и оперирует на уровне пользовательских интерфейсов, в отличие от последних фаз интеграционного тестирования, которое оперирует на уровне интерфейсов модулей. Различны и цели этих уровней тестирования.
Автоматизация тестирования
Использование различных подходов к тестированию определяется их эффективностью применительно к условиям, определяемым промышленным проектом. В реальных случаях работа группы тестирования планируется так, чтобы разработка тестов начиналась с момента согласования требований к программному продукту (выпуск Requirement Book, содержащей высокоуровневые требования к продукту) и продолжалась параллельно с разработкой дизайна и кода продукта
Качество программного продукта и тестирование
Каждый из участников может иметь различное представление о продукте и по-разному судить о том, насколько он хорош или плох, то есть насколько высоко качество продукта. С точки зрения разработчика, продукт может быть настолько хорош, насколько хороши заложенные в нем алгоритмы и технологии. Пользователю продукта, скорее всего, безразличны детали внутренней реализации, его в первую очередь волнуют вопросы функциональности и надежности.
Выполнение тестов
Рассмотрим два основных подхода к выполнению тестов: подход ручного тестирования и подход автоматического исполнения (прогон) тестов. Подходы рассмотрены на примере тестирования продукта, поддерживающего интерфейс командной строки. Тесты описывают вызов продукта с параметрами и проверку возвращаемого значения в виде фиксируемых при прогоне – текста из STDOUT и состояния некоторых файлов, зависящего от входных параметров.
Цели и задачи регрессионного тестирования
При корректировках программы необходимо гарантировать сохранение качества. Для этого используется регрессионное тестирование - дорогостоящая, но необходимая деятельность в рамках этапа сопровождения, направленная на перепроверку корректности измененной программы. В соответствии со стандартным определением, регрессионное тестирование - это выборочное тестирование, позволяющее убедиться, что изменения не вызвали нежелательных побочных эффектов, или что измененная система по-прежнему соответствует требованиям.
Случайные методы
Случайные методы оказываются на удивление дешевыми и эффективными. Случайно выбранные входные данные могут давать больший разброс по покрытию кода, чем входные данные, которые используются в наборах тестов, основанных на покрытии, в одних случаях дублируя покрытие, а в других не обеспечивая его.
Интеграционное регрессионное тестирование
С появлением новых направлений в разработке программного обеспечения (например, объектно-ориентированного программирования), поощряющих использование большого количества маленьких процедур, повышается важность обработки межмодульного влияния изменений кода для методик уменьшения стоимости регрессионного тестирования.
Методика регрессионного тестирования
Методика предназначена для эффективного решения задачи выборочного повторного тестирования. Ее исходными данными являются: программа P и ее модифицированная версия P', критерий тестирования C, множество (набор) тестов T, ранее использовавшихся для тестирования P, информация о покрытии элементов P (M(P,C)) тестами из T.
Описание тестируемой системы и ее окружения
Практикум базируется на тестировании модели реальной системы управления автоматизированным комплексом хранения подшипников. Она обеспечивает прием подшипников на склад, сохранение характеристик поступивших подшипников в базе данных (БД), а при поступлении заявки на подшипники вместе с параметрами оси - подбор подходящих подшипников и их выдачу.
Модульное тестирование на примере классов
Цель тестирования программных модулей состоит в том, чтобы удостовериться, что каждый модуль соответствует своей спецификации. Если это так, то причиной любых ошибок, которые возникают при их объединении, является неправильная стыковка модулей. В процедурно- ориентированном программировании модулем называется процедура или функция, иногда группа процедур, которая реализует абстрактный тип данных.
Идентификация взаимодействий
Взаимодействие объектов представляет собой просто запрос одного объекта (отправителя) на выполнение другим объектом (получателем) одной из операций получателя и всех видов обработки, необходимых для завершения этого запроса.
Системное тестирование
Системное тестирование качественно отличается от интеграционного и модульного уровней. Системное тестирование рассматривает систему в целом и применяется на уровне пользовательских интерфейсов, в отличие от последних фаз интеграционного тестирования, которое оперирует на уровне интерфейсов модулей, хотя набор модулей может быть аналогичным. Различны и цели этих уровней тестирования.
Ручное тестирование
Наиболее распространенным способом разработки тестов является создание тестового кода вручную. Такой способ создания тестов является наиболее гибким, однако производительность тестировщиков при создании тестового кода соизмерима с производительностью разработчиков при создании кода продукта, а объемы тестового кода часто бывают в 1-10 раз больше объема самого продукта.
Автоматизация тестирования с помощью скриптов
Общая тенденция последнего времени предусматривает максимальную автоматизацию тестирования, которая позволяет справляться с большими объемами данных и тестов, необходимых для современных продуктов.
Автоматическая генерация тестов на основе формального описания
Тесты составляются на основе спецификации требований. При формулировании требований на естественном языке существует проблема их различных толкований. Одним из способов избежать этого является применение формальных языков для описания структуры и поведения системы (UML, SDL, MSC).
Описание ручного тестирования
Реализация выбранного подхода для ручного тестирования приводится в Class1.cs (..\SystemTesting\ManualTests\Tests\Class1.cs). Все классы входят в пространство имен Tests.
Как создать свой тест?
В данном случае используется тот же принцип, что и при ручном тестировании: задать состояние окружения (StoreStat, AxlePar, RollerPar, StoreMessage, CommandStatus);ждать, когда в системе произойдет определенное событие;задать новое состояние окружения;и т.д.
Структура и описание содержимого каталогов
В папке Documents находится:FDS;HLD;Практикум (этот документ). Папка IntegrationTesting содержит проект Visual Studio .NET с примером интеграционного теста. Папка ModuleTesting содержит проект Visual Studio .NET с примером модульного теста. В папке SystemTesting\ManualTests содержится проект Visual Studio .NET с примерами системных ручных тестов.
Использование MS Visio для генерации MPR-файлов
Разработанный набор утилит предназначен для: преобразования MSC-диаграмм в формат MPR;проверки правильности подключения сигналов;загрузки комментариев. Утилита поддерживает следующие типы конструкций: Instance Instance End Message Action Comment Coregion Text Condition Reference Block(Alt, Par, Loop, Opt).
Необходимое аппаратное обеспечение
Запустите программу инсталляции. Появится диалоговое окно. Для продолжения инсталляции нужно нажать кнопку NEXT. После этого необходимо ввести путь, куда будет установлено приложение.
Принятые сокращения
Система предназначена для управления автоматизированным комплексом хранения подшипников. Она обеспечивает прием подшипников на склад, а также подбор и выдачу по запросу. Данный документ описывает требования и ограничения на использование приложения.
Описание структуры проекта
Данный документ описывает внутреннюю структуру, взаимодействие с окружением и внешние интерфейсы приложения. Приводится описание классов, их взаимодействие, а также описание их внешних и внутренних интерфейсов.
Сущность технологии COM
Прошло около шести месяцев, прежде чем я почувствовал, что понял в СОМ хоть что-либо. В течение этого шестимесячного стартового периода работы с СОМ я мог успешно писать СОМ-программы и почти мог объяснить, почему они работают. Однако у меня не было органического понимания того, почему модель программирования СОМ была тем, чем она была. К счастью, в один из дней, а именно 8 августа 1994 года, примерно через шесть месяцев с момента покупки книги OLE2 изнутри (Inside OLE2), на меня снизошло прозрение, и в одночасье СОМ стал для меня понятен. Это никоим образом не означало, что я понимал каждый интерфейс СОМ и каждую API-функцию. Но я в значительной степени понял главные побудительные мотивы СОМ. А значит, стало ясно, как применить эту модель программирования к ежедневным программистским задачам. Многие разработчики испытали нечто похожее. А так как я пишу это введение три августа спустя, эти разработчики все еще вынуждены пройти сквозь этот шестимесячный период ожидания, прежде чем стать продуктивными членами сообщества СОМ. Я хотел бы надеяться, что моя книга сможет сократить этот период, но обещаний не даю.Практичность
СОМ является чрезвычайно гибкой основой для создания рассредоточенных объектно-ориентированных систем. Чтобы использовать эту гибкость СОМ, часто требуется мыслить вне ограничений, диктуемых документацией по SDK, статьями или книгами. Моя личная рекомендация состоит в том, чтобы осознать: все, что вы читаете (в том числе и эта книга), может быть неверным или вопиюще устареть, и вместо этого необходимо сформировать свое собственное понимание этой модели программирования. Безошибочный путь к пониманию этой модели программирования состоит в том, чтобы сконцентрироваться на совершенствовании базового словаря СОМ.
СОМ как улучшенный C++
C++ уже давно с нами. Сообщество программистов на C++ весьма обширно, и большинство из них хорошо знают о западнях и подводных камнях языка. Язык C++ был создан высоко квалифицированной командой разработчиков, которые, работая в Bell Laboratories, выпустили не только первый программный продукт C++ (CFRONT), но и опубликовали много конструктивных работ о C++. Большинство правил языка C++ было опубликовано в конце 1980-х и начале 1990-х годов. В этот период многие разработчики C++ (включая авторов практически каждой значительной книги по C++) работали на рабочих станциях UNIX и создавали довольно монолитные приложения, использующие технологию компиляции и компоновки того времени
Интерфейсы
В предыдущей главе было показано несколько приемов программирования на C++, позволяющих разрабатывать двоичные компоненты повторного использования, которые со временем могут быть модернизированы. По своему смыслу эти приемы идентичны тем, которые используются моделью СОМ. Незначительные различия между методиками предыдущей главы и теми, которые используются СОМ, в большинстве случаев заключаются в деталях и почти всегда достаточно обоснованы.
Классы
В предыдущей главе обсуждались принципы интерфейсов СОМ вообще и интерфейс IUnknown в частности. Были показаны способы управления указателями интерфейса из C++, и детально обсуждалась фактическая техника реализации IUnknown. Однако не обсуждалось, как обычно клиенты получают начальный указатель интерфейса на объект, или как средства реализации объекта допускают, чтобы их объекты могли быть обнаружены внешними клиентами. В данной главе демонстрируется, как реализации объектов СОМ интегрируют в среду выполнения СОМ, чтобы дать клиентам возможность найти или создать объекты требуемого конкретного типа.
Объекты
IUnknown не имеет реализации по умолчанию, которая являлась бы частью интерфейса системного вызова СОМ. Заголовочные файлы SDK не содержат базовых классов, макросов или шаблонов, предусматривающих реализации QueryInterface, AddRef и Release, которые должны использоваться во всех программах на С или C++. Вместо этого Спецификация СОМ (Component Object Model Specification) предоставляет очень точные правила относительно допущений, которые клиенты и объекты могут делать относительно этих трех методов.
Апартаменты
Некоторые разработчики всесторонне используют многопоточные программные технологии и способны написать удивительно изощренный программный продукт с использованием примитивов синхронизации потоков, доступных из операционной системы. Другие разработчики больше сконцентрированы на решении вопросов, специфических для их области, и не утруждают себя написанием нудного потоко-безопасного кода. Третьи разработчики имеют особые ограничения по организации потоков, связанные с тем, что многие системы с управлением окнами (включая Windows) имеют очень строгие правила взаимодействия потоков и оконных примитивов.
Подводные камни внутрипроцессной активации
Итак, серверы COM были ранее представлены как внутрипроцессные модули кода, загружаемые в активизирующий их процесс с целью создания объектов и выполнения их методов. Для значительного класса объектов это является разумной стратегией развертывания. Эта стратегия, однако, не лишена недостатков. Одним из подводных камней при запуске объекта в клиентском процессе является отсутствие изоляции ошибок. Если объект вызывает нарушение условий доступа или другую фатальную ошибку во время исполнения, то клиентский процесс завершится вместе с объектом. Более того, если программа клиента вызовет какую-либо ошибку, то все объекты, созданные в его адресном пространстве, будут немедленно уничтожены без предупреждения.
Основы указателей
СОМ, подобно DCE (Distributed Computing Environment — среда распределенных вычислений), ведет свое начало от языка программирования С. Хотя лишь немногие разработчики используют С для создания или использования компонентов СОМ, именно от С СОМ унаследовала синтаксис для своего языка определений интерфейсов (Interface Definition Language — IDL). Одной из наиболее сложных проблем при разработке и использовании интерфейсов является управление указателями. Рассмотрим такое простое определение метода IDL: HRESULT f([in] const short *ps);
Эволюция объектов
Развитие объектно-ориентированного программирования перешло в стадию коммерческого применения в конце 1980-х годов. Центральной темой объектного ориентирования в середине 1980-х было использование классов, которые позволили разработчикам моделировать состояние и поведение как единый абстрактный модуль. Такая упаковка состояния и поведения помогает провести в жизнь модульный принцип через применение инкапсуляции. В классическом объектном ориентировании объекты принадлежали классам, а клиенты манипулировали объектами посредством основанных на классах ссылок. Такая модель программирования принята в большинстве сред и библиотек C++ и Smalltalk тех времен.
Электронные издания
Электронное издание значительно дешевле, чем печатное, и изготовление такого издания не связано с расходом трудно возобновимых ресурсов (леса) и загрязнением окружающей среды. Электронные издания зачастую оказываются даже более функциональными. Так, справочное или учебное электронное издание позволяет более динамично построить процесс изучения материала и усилить его мотивацию, что в конечном счете позволяет ускорить процесс восприятия и запоминания информации.Если художественная литература преимущественно распространяется в привычной нам форме типографских изданий, то детские электронные издания уже существенно потеснили книги, так как последние не обладают многими возможностями электронных компьютерных технологий. Постепенно, но неуклонно продолжается наступление электронных изданий в учебной сфере, начиная со школьного обучения и до высшего образования.
Структура и элементы гипертекстовых документов
Электронные издания не только публикуются в базах данных, но и могут применяется также в виде баз данных - реферативных и библиографических. Эти два вида изданий объединяет то обстоятельство, что они предназначены для квалифицированных пользователей, среди которых присутствуют как библиографы - работники крупных библиотек, так и научные работники, скрупулезно следящие за изданиями в своей предметной области.
Последовательность проектирования сайта в пакете Dreamweaver
Прежде всего надо тщательно продумать общую структуру сайта, а также структуру каталогов (папок) и размещение в них файлов. В качестве прикладного примера рассмотрим проектирование сайта небольшого издательства. В начале работы следует разместить в корневом каталоге сайта все HTML-файлы и не менее трех подкаталогов, в том числе: каскадных стилей, изображений и каталог с фрагментами текста и отзывами на книги, выпускаемые издательством. Для непосредственного создания сайта следует предварительно сделать все необходимые установки. С этой целью в секции меню «Редактирование» (Edit) следует выбрать команду «Установки» (Preference).
Forekc.ru
Рефераты, дипломы, курсовые, выпускные и квалификационные работы, диссертации, учебники, учебные пособия, лекции, методические пособия и рекомендации, программы и курсы обучения, публикации из профильных изданий