Сущность технологии COM
Основы тестирования программного обеспечения
Качество программного продукта характеризуется набором свойств, определяющих, насколько продукт "хорош" с точки зрения заинтересованных сторон, таких как заказчик продукта, спонсор, конечный пользователь, разработчики и тестировщики продукта, инженеры поддержки, сотрудники отделов маркетинга, обучения и продаж. Каждый из участников может иметь различное представление о продукте и о том, насколько он хорош или плох, то есть о том, насколько высоко качество продукта. Таким образом, постановка задачи обеспечения качества продукта выливается в задачу определения заинтересованных лиц, их критериев качества и затем нахождения оптимального решения, удовлетворяющего этим критериям. Тестирование является одним из наиболее устоявшихся способов обеспечения качества разработки программного обеспечения и входит в набор эффективных средств современной системы обеспечения качества программного продукта.Тестирование - способ обеспечения качества
С технической точки зрения тестирование заключается в выполнении приложения на некотором множестве исходных данных и сверке получаемых результатов с заранее известными (эталонными) с целью установить соответствие различных свойств и характеристик приложения заказанным свойствам.
Тестирование - способ обеспечения качества
Требования к курсу
Основные темы лекционного курса
Основные темы практикума
Прогнозируемые результаты
Концепция тестирования
Формальный подход или доказательство применяется, когда из исходных формул-аксиом с помощью формальных процедур (правил вывода) выводятся искомые формулы и утверждения (теоремы). Вывод осуществляется путем перехода от одних формул к другим по строгим правилам, которые позволяют свести процедуру перехода от формулы к формуле к последовательности текстовых подстановок
Основная терминология
Пример поиска и исправления ошибки
Организация тестирования
Сравнение словесного описания пункта
Пример вставки операторов протоколирования
Пример пошагового выполнения программы
Пример выполнения с анализом трасс и дампов
Пример обратного выполнения
Сквозной пример тестирования
Требования к идеальному критерию тестирования
Критерий должен быть достаточным, т.е. показывать, когда некоторое конечное множество тестов достаточно для тестирования данной программы. Критерий должен быть полным, т.е. в случае ошибки должен существовать тест из множества тестов, удовлетворяющих критерию, который раскрывает ошибку.Критерий должен быть надежным, т.е. любые два множества тестов, удовлетворяющих ему, одновременно должны раскрывать или не раскрывать ошибки программы
Классы критериев
Структурные критерии (класс I).
Функциональные критерии (класс II)
Пример применения функциональных
Стохастические критерии (класс III)
Мутационный критерий (класс IV).
Пример применения мутационного критерия
Оценка Покрытия Программы и Проекта
Тестирование программы Р по некоторому критерию С означает покрытие множества компонентов программы 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
Спецификация тестового случая №1 - 2
Описание процесса системного тестирования
Ручное тестирование
Наиболее распространенным способом разработки тестов является создание тестового кода вручную. Такой способ создания тестов является наиболее гибким, однако производительность тестировщиков при создании тестового кода соизмерима с производительностью разработчиков при создании кода продукта, а объемы тестового кода часто бывают в 1-10 раз больше объема самого продукта.
Ручное тестирование
Подробное описание тестового случая №1
Описание тестовых процедур
Автоматизация тестирования с помощью скриптов
Общая тенденция последнего времени предусматривает максимальную автоматизацию тестирования, которая позволяет справляться с большими объемами данных и тестов, необходимых для современных продуктов.
Автоматизация тестирования с помощью скриптов
Подробное описание тестового случая №1
Автоматическая генерация тестов на основе формального описания
Тесты составляются на основе спецификации требований. При формулировании требований на естественном языке существует проблема их различных толкований. Одним из способов избежать этого является применение формальных языков для описания структуры и поведения системы (UML, SDL, MSC).
Авто генерация тестов на основе описания
Подробное описание тестового случая №1
Как сгенерировать и запустить тест
Пример теста с ошибкой
Описание ручного тестирования
Реализация выбранного подхода для ручного тестирования приводится в Class1.cs (..\SystemTesting\ManualTests\Tests\Class1.cs). Все классы входят в пространство имен Tests.
Описание ручного тестирования
Как создать свой тест?
Как создать свой тест?
В данном случае используется тот же принцип, что и при ручном тестировании: задать состояние окружения (StoreStat, AxlePar, RollerPar, StoreMessage, CommandStatus);ждать, когда в системе произойдет определенное событие;задать новое состояние окружения;и т.д.
Описание заголовка
Описание блока
Описание Wait
Структура и описание содержимого каталогов
В папке Documents находится:FDS;HLD;Практикум (этот документ). Папка IntegrationTesting содержит проект Visual Studio .NET с примером интеграционного теста. Папка ModuleTesting содержит проект Visual Studio .NET с примером модульного теста. В папке SystemTesting\ManualTests содержится проект Visual Studio .NET с примерами системных ручных тестов.
Структура и описание содержимого каталогов
Описание MSC
Основные понятия
Применение MSC-диаграмм для моделей
Обработка MSC-диаграмм
Проверка MSC-диаграммы на полноту
Использование MS Visio для генерации MPR-файлов
Разработанный набор утилит предназначен для: преобразования MSC-диаграмм в формат MPR;проверки правильности подключения сигналов;загрузки комментариев. Утилита поддерживает следующие типы конструкций: Instance Instance End Message Action Comment Coregion Text Condition Reference Block(Alt, Par, Loop, Opt).
Описание элементов
Генерация MPR
ConfigTAT
SysLog Animator Manual
Главное Меню
File-Open
File-Exit
Options-Config...
Необходимое аппаратное обеспечение
Запустите программу инсталляции. Появится диалоговое окно. Для продолжения инсталляции нужно нажать кнопку NEXT. После этого необходимо ввести путь, куда будет установлено приложение.
Необходимое аппаратное обеспечение
Необходимое программное обеспечение
Руководство по инсталляции
Проверка инсталлированной системы
Принятые сокращения
Система предназначена для управления автоматизированным комплексом хранения подшипников. Она обеспечивает прием подшипников на склад, а также подбор и выдачу по запросу. Данный документ описывает требования и ограничения на использование приложения.
Принятые сокращения
Склад
Статус склада
Список команд складу
Формат команд складу
Терминал подшипника
Терминал оси
Интерфейс со складом (Store.dll)
Интерфейс с терминалом подшипника (Bearing.dll)
Описание структуры проекта
Данный документ описывает внутреннюю структуру, взаимодействие с окружением и внешние интерфейсы приложения. Приводится описание классов, их взаимодействие, а также описание их внешних и внутренних интерфейсов.
Описание структуры проекта
Методы внешнего модуля Axle
Методы внешнего модуля Bearing
Методы внешнего модуля Store
Класс TBearingParam
Класс TTerminalBearing
Класс TAxleParam
Класс TTerminalAxle
Класс TCommand
Класс TСomm andQueue
Сущность технологии COM
Прошло около шести месяцев, прежде чем я почувствовал, что понял в СОМ хоть что-либо. В течение этого шестимесячного стартового периода работы с СОМ я мог успешно писать СОМ-программы и почти мог объяснить, почему они работают. Однако у меня не было органического понимания того, почему модель программирования СОМ была тем, чем она была. К счастью, в один из дней, а именно 8 августа 1994 года, примерно через шесть месяцев с момента покупки книги OLE2 изнутри (Inside OLE2), на меня снизошло прозрение, и в одночасье СОМ стал для меня понятен. Это никоим образом не означало, что я понимал каждый интерфейс СОМ и каждую API-функцию. Но я в значительной степени понял главные побудительные мотивы СОМ. А значит, стало ясно, как применить эту модель программирования к ежедневным программистским задачам. Многие разработчики испытали нечто похожее. А так как я пишу это введение три августа спустя, эти разработчики все еще вынуждены пройти сквозь этот шестимесячный период ожидания, прежде чем стать продуктивными членами сообщества СОМ. Я хотел бы надеяться, что моя книга сможет сократить этот период, но обещаний не даю.Практичность
СОМ является чрезвычайно гибкой основой для создания рассредоточенных объектно-ориентированных систем. Чтобы использовать эту гибкость СОМ, часто требуется мыслить вне ограничений, диктуемых документацией по SDK, статьями или книгами. Моя личная рекомендация состоит в том, чтобы осознать: все, что вы читаете (в том числе и эта книга), может быть неверным или вопиюще устареть, и вместо этого необходимо сформировать свое собственное понимание этой модели программирования. Безошибочный путь к пониманию этой модели программирования состоит в том, чтобы сконцентрироваться на совершенствовании базового словаря СОМ.
Практичность
Простота ведет к податливости (malleability)
Фольклор
Литература
СОМ как улучшенный C++
C++ уже давно с нами. Сообщество программистов на C++ весьма обширно, и большинство из них хорошо знают о западнях и подводных камнях языка. Язык C++ был создан высоко квалифицированной командой разработчиков, которые, работая в Bell Laboratories, выпустили не только первый программный продукт C++ (CFRONT), но и опубликовали много конструктивных работ о C++. Большинство правил языка C++ было опубликовано в конце 1980-х и начале 1990-х годов. В этот период многие разработчики C++ (включая авторов практически каждой значительной книги по C++) работали на рабочих станциях UNIX и создавали довольно монолитные приложения, использующие технологию компиляции и компоновки того времени
Где мы находимся?
Динамическая компоновка и С++
C++ и мобильность
Инкапсуляция и С++
Отделение интерфейса от реализации
Интерфейсы
В предыдущей главе было показано несколько приемов программирования на C++, позволяющих разрабатывать двоичные компоненты повторного использования, которые со временем могут быть модернизированы. По своему смыслу эти приемы идентичны тем, которые используются моделью СОМ. Незначительные различия между методиками предыдущей главы и теми, которые используются СОМ, в большинстве случаев заключаются в деталях и почти всегда достаточно обоснованы.
Снова об интерфейсах и реализациях
Оптимизация QueryInterface
Типы данных
Классы
В предыдущей главе обсуждались принципы интерфейсов СОМ вообще и интерфейс IUnknown в частности. Были показаны способы управления указателями интерфейса из C++, и детально обсуждалась фактическая техника реализации IUnknown. Однако не обсуждалось, как обычно клиенты получают начальный указатель интерфейса на объект, или как средства реализации объекта допускают, чтобы их объекты могли быть обнаружены внешними клиентами. В данной главе демонстрируется, как реализации объектов СОМ интегрируют в среду выполнения СОМ, чтобы дать клиентам возможность найти или создать объекты требуемого конкретного типа.
Снова об интерфейсе и реализации
Моникеры и сохраняемость
Время жизни сервера
Классы и IDL
Объекты
IUnknown не имеет реализации по умолчанию, которая являлась бы частью интерфейса системного вызова СОМ. Заголовочные файлы SDK не содержат базовых классов, макросов или шаблонов, предусматривающих реализации QueryInterface, AddRef и Release, которые должны использоваться во всех программах на С или C++. Вместо этого Спецификация СОМ (Component Object Model Specification) предоставляет очень точные правила относительно допущений, которые клиенты и объекты могут делать относительно этих трех методов.
Объекты
Снова IUnknown
Двоичная композиция
Апартаменты
Некоторые разработчики всесторонне используют многопоточные программные технологии и способны написать удивительно изощренный программный продукт с использованием примитивов синхронизации потоков, доступных из операционной системы. Другие разработчики больше сконцентрированы на решении вопросов, специфических для их области, и не утруждают себя написанием нудного потоко-безопасного кода. Третьи разработчики имеют особые ограничения по организации потоков, связанные с тем, что многие системы с управлением окнами (включая Windows) имеют очень строгие правила взаимодействия потоков и оконных примитивов.
Снова интерфейс и реализация
Маршалер свободной поточной обработки
Подводные камни внутрипроцессной активации
Итак, серверы COM были ранее представлены как внутрипроцессные модули кода, загружаемые в активизирующий их процесс с целью создания объектов и выполнения их методов. Для значительного класса объектов это является разумной стратегией развертывания. Эта стратегия, однако, не лишена недостатков. Одним из подводных камней при запуске объекта в клиентском процессе является отсутствие изоляции ошибок. Если объект вызывает нарушение условий доступа или другую фатальную ошибку во время исполнения, то клиентский процесс завершится вместе с объектом. Более того, если программа клиента вызовет какую-либо ошибку, то все объекты, созданные в его адресном пространстве, будут немедленно уничтожены без предупреждения.
Активация и SCM
Снова о времени жизни сервера
Основы указателей
СОМ, подобно DCE (Distributed Computing Environment — среда распределенных вычислений), ведет свое начало от языка программирования С. Хотя лишь немногие разработчики используют С для создания или использования компонентов СОМ, именно от С СОМ унаследовала синтаксис для своего языка определений интерфейсов (Interface Definition Language — IDL). Одной из наиболее сложных проблем при разработке и использовании интерфейсов является управление указателями. Рассмотрим такое простое определение метода IDL: HRESULT f([in] const short *ps);
Основы указателей
Указатели и память
Эволюция объектов
Развитие объектно-ориентированного программирования перешло в стадию коммерческого применения в конце 1980-х годов. Центральной темой объектного ориентирования в середине 1980-х было использование классов, которые позволили разработчикам моделировать состояние и поведение как единый абстрактный модуль. Такая упаковка состояния и поведения помогает провести в жизнь модульный принцип через применение инкапсуляции. В классическом объектном ориентировании объекты принадлежали классам, а клиенты манипулировали объектами посредством основанных на классах ссылок. Такая модель программирования принята в большинстве сред и библиотек C++ и Smalltalk тех времен.
Электронные издания
Электронное издание значительно дешевле, чем печатное, и изготовление такого издания не связано с расходом трудно возобновимых ресурсов (леса) и загрязнением окружающей среды. Электронные издания зачастую оказываются даже более функциональными. Так, справочное или учебное электронное издание позволяет более динамично построить процесс изучения материала и усилить его мотивацию, что в конечном счете позволяет ускорить процесс восприятия и запоминания информации.Если художественная литература преимущественно распространяется в привычной нам форме типографских изданий, то детские электронные издания уже существенно потеснили книги, так как последние не обладают многими возможностями электронных компьютерных технологий. Постепенно, но неуклонно продолжается наступление электронных изданий в учебной сфере, начиная со школьного обучения и до высшего образования.
Структура и элементы гипертекстовых документов
Электронные издания не только публикуются в базах данных, но и могут применяется также в виде баз данных - реферативных и библиографических. Эти два вида изданий объединяет то обстоятельство, что они предназначены для квалифицированных пользователей, среди которых присутствуют как библиографы - работники крупных библиотек, так и научные работники, скрупулезно следящие за изданиями в своей предметной области.
Общая структура HTML-документа
Тело документа
Теги логического форматирования текста
Теги физического форматирования текста
Последовательность проектирования сайта в пакете Dreamweaver
Прежде всего надо тщательно продумать общую структуру сайта, а также структуру каталогов (папок) и размещение в них файлов. В качестве прикладного примера рассмотрим проектирование сайта небольшого издательства. В начале работы следует разместить в корневом каталоге сайта все HTML-файлы и не менее трех подкаталогов, в том числе: каскадных стилей, изображений и каталог с фрагментами текста и отзывами на книги, выпускаемые издательством. Для непосредственного создания сайта следует предварительно сделать все необходимые установки. С этой целью в секции меню «Редактирование» (Edit) следует выбрать команду «Установки» (Preference).
Интерфейс пакета Macromedia Director
Основные окна и инспекторы пакета
Работа над мультимедийным изданием
Общая характеристика и интерфейс пакета
Эволюция современного мирового хозяйства - перейти
Экономика. Региональная - перейти
Муниципальный менеджмент - перейти
Государственные и муниципальные финансы - перейти
Финансы муниципальных образований - перейти
Региональная экономика - перейти
Основные понятия экономики региона - перейти
Экономика. Теневая - перейти
Бизнес презентация - перейти
- перейти
Введение - перейти
Общий план Word - перейти
Как работать в Word - перейти
Прогулки по документу - перейти
Основы редактирования - перейти
Forekc.ru
Рефераты, дипломы, курсовые, выпускные и квалификационные работы, диссертации, учебники, учебные пособия, лекции, методические пособия и рекомендации, программы и курсы обучения, публикации из профильных изданий