- •Стратегии тестирования: структурный подход – методы «белого» ящика, функциональный подход – методы «черного» ящика.
- •Структурное тестирование (тестирование маршрутов) – критерии формирования тестовых наборов: покрытие операторов.
- •Структурное тестирование (тестирование маршрутов) – критерии формирования тестовых наборов: покрытие решений (переходов).
- •Структурное тестирование (тестирование маршрутов) – критерии формирования тестовых наборов: покрытие условий.
- •Структурное тестирование (тестирование маршрутов) – критерии формирования тестовых наборов: покрытие решений/условий.
- •Структурное тестирование (тестирование маршрутов) – критерии формирования тестовых наборов: комбинаторное покрытие условий.
- •Функциональное тестирование (тестирование с управлением по данным) – критерии формирования тестовых наборов: эквивалентное разбиение.
- •Функциональное тестирование (тестирование с управлением по данным) – критерии формирования тестовых наборов: анализ граничных значений.
- •Функциональное тестирование (тестирование с управлением по данным) – критерии формирования тестовых наборов: анализ причинно-следственных связей.
- •Функциональное тестирование (тестирование с управлением по данным) – критерии формирования тестовых наборов: предположение об ошибке.
- •Тестирование модулей: восходящие, нисходящие, комбинированное, модули-заглушки, тестирование специалистами-тесторами, документирование тестирования, регрессивное тестирование.
- •Комплексное тестирование, критерии завершения тестирования, оценочное-системное тестирование.
- •Отладка по – классификация ошибок: ошибки компиляции, компоновки, выполнения; причины ошибок выполнения.
- •Методы отладки по: ручное тестирование, индукции, дедукция, обратное прослеживание.
- •Методы и средства получения дополнительной информации об ошибке: отладочный вывод, интегрированные средства отладки, независимые отладчики.
- •Общая методика отладка по: изучение проявления ошибки, локализация ошибки, определение причины ошибки, исправление ошибки, повторное тестирование.
- •Сборочное программирование, повторное используемые компоненты, основы компонентной объектной модели (com).
- •Организация интерфейса com: идентификация интерфейса, описание интерфейса, реализация интерфейса.
- •Базовый интерфейс com-iUnknown, серверы com-объектов, преимущества com.
- •Работа с com-объектами: создание com-объектов, повторное использование com-объектов.
- •Работа с com-объектами: размещение com-объекта в других процессах – маршалинг и демаршалинг, описание com-объекта в библиотеке операционной системы – idl-описание и библиотека типа.
- •Case-технология, особенности жизненного цикла, состав, основные функции case-систем, средства автоматизации программирования.
- •Перспективы развития технологии программирования, технологическая зрелость организаций-разработчиков по, лицензирование организаций-разработчиков по.
Сборочное программирование, повторное используемые компоненты, основы компонентной объектной модели (com).
Компонентный подход предполагает построение программного обеспечения из отдельных компонентов физически отдельно существующих частей программного обеспечения, которые взаимодействуют между собой через стандартизованные двоичные интерфейсы. В отличие от обычных объектов объекты-компоненты можно собрать в динамически вызываемые библиотеки или исполняемые файлы, распространять в двоичном виде (без исходных текстов) и использовать в любом языке программирования, поддерживающем соответствующую технологию.
Компонентный подход лежит в основе технологий, разработанных на базе COM (Component Object Model - компонентная модель объектов), и технологии создания распределенных приложений CORBA (Common Object Request Broker Architecture - общая архитектура с посредником обработки запросов объектов).
Компонентная объектная модель (СОМ) — фундамент компонентно-ориентированных средств для всего семейства операционных систем Windows. Рассмотрение этой модели является иллюстрацией комплексного подхода к созданию и использованию компонентного программного обеспечения [5].
СОМ определяет стандартный механизм, с помощью которого одна часть программного обеспечения предоставляет свои услуги другой части. Общая архитектура предоставления услуг в библиотеках, приложениях, системном и сетевом программном обеспечении позволяет СОМ изменить подход к созданию программ.
СОМ устанавливает понятия и правила, необходимые для определения объектов и интерфейсов; кроме того, в ее состав входят программы, реализующие ключевые функции.
В СОМ любая часть ПО реализует свои услуги с помощью объектов СОМ. Каждый объект СОМ поддерживает несколько интерфейсов. Клиенты могут получить доступ к услугам объекта СОМ только через вызовы операций его интерфейсов — у них нет непосредственного доступа к данным объекта.
Представим объект СОМ с интерфейсом РаботаСФайлами. Пусть в этот интерфейс входят операции ОткрытьФайл, ЗаписатьФайл и ЗакрытьФайл. Если разработчик захочет ввести в объект СОМ поддержку преобразования форматов, то объекту потребуется еще один интерфейс ПреобразованиеФорматов, возможно, с единственной операцией ПреобразоватьФормат. Операции каждого из интерфейсов сообща предоставляют связанные друг с другом услуги: либо работу с файлами, либо преобразование их форматов.
Как показано на рис, объект СОМ всегда реализуется внутри некоторого сервера. Сервер может быть либо динамически подключаемой библиотекой (DLL), подгружаемой во время работы приложения, либо отдельным самостоятельным процессом (ЕХЕ).
Для вызова операции интерфейса клиент объекта СОМ должен получить указатель на его интерфейс. Клиенту требуется отдельный указатель для каждого интерфейса, операции которого он намерен вызывать. Например, как показано на рис, клиенту нашего объекта СОМ нужен один указатель интерфейса для вызова операций интерфейса РаботаСФайлами, а другой — для вызова операций интерфейса ПреобразованиеФорматов.
Получив указатель на нужный интерфейс, клиент может использовать услуги объекта, вызывая операции этого интерфейса. С точки зрения программиста, вызов операции аналогичен вызову локальной процедуры или функции. Но на самом деле исполняемый при этом код может быть частью или библиотеки, или отдельного процесса, или операционной системы (он даже может располагаться на другом компьютере).
Благодаря СОМ клиентам нет нужды учитывать эти отличия — доступ ко всему осуществляется единообразно. Другими словами, в СОМ для доступа к услугам, предоставляемым любыми типами ПО, используется одна общая модель.