1. Структурное тестирование ПО. Критерии структурного тестирования. Сборка программ при тестировании. Оценка степени тестируемости программного продукта. Критерии завершения тестирования. Тестирование – процесс многократного повторения программ с целью обнаружения как можно большего кол-ва ошибок. Автор не допускается до тестирования (в конечной части). Структурное тестирование (модульное) – тестирование по принципу «белого ящика». Преимущества: проще обнаружить алгоритмические и кодерские ошибки. Структурные тесты строятся по принципам: 1) На основе анализа потока управления (управляющего графа программы - УГП). 2) На основе потока данных (информационного графа) Критерии структурного тестирования: С0 – условие тестирования команд, заключается в выполнении каждого операторы хотя бы один раз. Это очень слабый критерий, используется редко. С1 – условие тестирования ветвей. Требуется выполнение каждой ветви программы не менее 1 раза. Используется часто, но не может гарантировать выявления всех ошибок в программе. Пример – if (cond2 || func1()) stat1; else stat2; - здесь func() может быть не выполнена при покрытии всех ветвей. C2 – критерий покрытия всех путей в УГП. Тестирование на основе потока управления Кроме перечисленных выше критериев используют критерий покрытия всех условий (булевских) и критерий покрытия условий/решений, который совмещает С1 и критерий покрытия условий. Еще вариант – каждый вызов каждой функции должен быть выполнен хотя бы 1 раз (покрытие пар вызовов). Тестирование на основе потока данных Для поиска ссылок на неинициализированные переменны, избыточные присваивания (аномалии потока данных). Стратегии: 1) Покрытие дуг инф. графа – тестирование всех взаимосвязей: ссылки (использование), определение переменной-цели ссылки. Это не гарантирует покрытие решений. 2) Стратегия требуемых пар, например, критерий CP: покрытие всех пар дуг УГП (v, w) таких, что из v достижима w. Другой критерий: Cdu – тестируются пары (вершина, дуга), поскольку переменные определяются в вершинах, а использование – на дугах. Сборка программ при тестировании Два подхода: 1) Монолитная сборка: одновременное объединение всех модулей в единый комплекс. Для замены неразработанных еще модулей делаются тестовые драйверы или заглушки, замещающие некоторые модули. Плюсы монолитной сборки: больше возможностей для параллельной работы. 2) Инкрементальная сборка: пошаговое наращивание. Наращивание может быть «сверху вниз» (применяется восходящее тестирование) или «снизу вверх» (применяется нисходящее тестирование). При нисходящем тестировании приходится использовать заглушки. Плюсы пошаговой сборки: раннее обнаружение ошибок, меньшая трудоемкость, проще отладка. Оценка степени тестируемости Тестирование программы P по критерию C означает покрытие множества компонентов программы M(P, C)={m1,…,mk}. T={t1,…,tn} – кортеж неизбыточных тестов. Тест ti неизбыточен, если существует покрытый им компонент mi, не покрытый ни одним из предыдущих тестов. V(P, C) – сложность тестирования – минимальное число неизбыточных тестов, покрывающих M(P, C). DV(P, C,T) – остаточная сложность – минимальное число неизбыточных тестов, покрывающих оставшиеся непокрытыми элементы M(P, C) после прогона тестов из набора T. TV(P, C,T) = (V-DV)/V – оценка степени тестированности. Критерий окончания тестирования TV(P, C,T)≥L, где 0≤L≤1. L – заданный уровень оттестированности. | 2. Объектно-ориентированный подход при тестировании ПО. Тестирование методов и классов. Сравнение двух подходов (структурного и объектно-ориентированного) при тестировании ПО. Тестирование ОО-программ имеет свои особенности: 1) Управляющий граф программы не является определяющим, потому что программа состоит из объектов, обменивающихся сообщениями, а не только передачу управления от функции к функции. 2) Элементом тестирования является не процедура, а класс (объект), имеющий состояние (атрибуты) и поведение (методы). 3) Инкапсуляция создает проблему видимости данных. 4) Наследование: нужно ли повторно тестировать базовые методы, вызываемые из переопределенных? 5) Полиморфизм создает неоднозначность с вызовом методов. 6) Интеграция классов тоже должна тестироваться. Методика тестирования ОО-программы: 1) Тестирование методов каждого класса (модульное тестирование) 2) Тестирование методов, образующих контекст интеграционного тестирования (внешних методов) 3) Класс включается в общий контекст, интеграционное тестирование. При тестировании класса нужно учитывать: 1) Наследуемые методы должны быть протестированы заново при переопределении. 2) Для закрытых методов и атрибутов делаются аксессоры (если нет способов обойти защиту, типа рефлексии). 3) Каждый вариант вызова полиморфного метода должен быть выполнен. Стратегии интеграции: 1) Основанная на задаче. Когда есть управляющий (главный) класс и можно выстроить иерархию к классам-исполнителям, то достаточно протестировать каждый класс. 2) Основанная на использовании. Когда нельзя выделить управляющий класс. Выделяются группы классов, и тестируются классы, использующие некоторую группу. Отличия от структурного подхода: 1) Задана не структура программы, а модель ее поведения. 2) Помимо структурного тестирования необходимо проводить интеграционное с использованием инкрементальной стратегии «снизу вверх». 3) Проще писать программу – сложнее ее тестировать. | 3. Методы функционального тестирования. Метод «черного» ящика, метод граничных условий, метод функциональных диаграмм. Общая стратегия функционального тестирования. Метод "Черного ящика". Функциональное тестирование (= по принципу «черного ящика) – выяснение ситуаций, в которых поведение программы не соответствует спецификации. Методы функционального тестирования: 1) Эквивалентное разбиение. По спецификации выделяются классы эквивалентности входных данных (например, допустимые и недопустимые значения). Потом создаются тесты, моделирующие попадание данных в эти классы. 2) Анализ граничных условий. Проверяются границы классов эквивалентности. Строятся тесты: для границ классов, для минимальных и максимальных значений. Аналогичные тесты строятся для выходных данных (попытки получения некорректных выходных данных). 3) Метод функциональных диаграмм. Побочный эффект: обнаружение неполноты и противоречивости спецификаций. Функциональная диаграмма – текст на формальном языке, в который транслируется спецификация. В диаграмму включаются причины (входные условия) и следствия (выходные условия или преобразования системы). Затем функциональная диаграмма преобразуется в булевский граф, связывающий причины и следствия. Каждый узел графа может находиться в состояниях 0 (существует) или 1 (не существует). Затем диаграмма снабжается комментариями, которые задают ограничения на комбинации причин и следствий. И, наконец, диаграмма преобразуется в таблицу решений: выбирается следствие, которое устанавливается в 1, и находятся все комбинации причин (с учетом ограничений), которые устанавливают выбранное следствие в 1. Общая стратегия функционального тестирования Программа (модуль) тестируется как «черный ящик», знание о внутренней структуре не используется. Тестировщик знает только входные параметры и ожидаемые выходные значения. Результаты тестирования получаются достаточно объективными. |
4. Методы структурного тестирования. Метод «белого ящика», метод предположения об ошибке, статические и динамические методы тестирования. Управляющий граф программы (УГП). Примеры тестов с использованием УГП. Структурное тестирование – тестирование основыванное на знании исходного кода (по принципу «белого ящика»). Метод предположения об ошибке – неформальный метод, заключающийся в том, что некий опытный человек предполагает ситуации, в которых могут произойти ошибки. На основе этих предположений строятся тесты. Этапы построения набора тестов: 1) Конструирование управляющего графа программы (УГП). УГП: вершины – инструкции, дуги – переходы между ними. 2) Выбор тестовых путей. 3) Генерация тестов по выбранным тестовым путям. Подходы к построению тестовых путей: 1) Статические методы (без запуска) – просто строится УГП по программе, а потом по нему строятся пути между начальной и конечной вершинами УГП. Основной недостаток – не учитывается возможная нереализуемость путей. 2) Динамические методы – строится полная система тестов, удовлетворяющая заданному критерию, путем одновременного решения задач покрытия путей и тестовых данных. Учитывается реализуемость путей. 3) Методы реализуемых путей – из множества путей выделяется подмножество реализуемых путей, а потом из него выделяется покрывающее множество путей. Пример тестирования с помощью УГП void func1(double a, double b, double& x ) { if(a>1 && b=0) x = x/a; if(a=2 || x>1) x = x+1; } Покрытие операторов: a=2, b=0, x=3 Покрытие решений: a=3, b=0, x=3 путь – 1-2-3-4-5-6
a=2, b=1, x=1 путь – 1-2-4-6 Покрытие условий: a=2, b=0, x=4 путь – 1-2-3-4-5-6, условия 1-да, 2-да, 3-да, 4-да a=1, b=1, x=1 путь – 1-2-4-6, условия 1-нет, 2- нет, 3- нет, 4- нет Покрытие решений/ условий: a=2, b=0, x=4 путь – 1-2-3-4-5-6, условия 1-да, 2-да, 3-да, 4-да a=1, b=1, x=1 путь – 1-2-4-6, условия 1-нет, 2- нет, 3- нет, 4- нет Комбинаторное покрытие условий: 1) a>1, b=0 5) a=2, x>1 2) a>1, b<>0 6) a=2, x<=1 3) a<=1, b=0 7) a<>2, x>1 4)a<=1, b<>0 8) a<>2, x<=1 a=2, b=0, x=4 – проверяет (1), (5) a=2, b=1, x=1 – проверяет (2), (6) a=1, b=0, x=2 – проверяет (3), (7) a=1, b=1, x=1 – проверяет (4), (8) | 5. Жизненный цикл ПО информационных систем. Модели жизненного цикла. Методология быстрой разработки приложений – RAD. Стадии жизненного цикла ПО (могут меняться от проекта к проекту, но общая структура сохраняется): 1) Анализ: анализ пожеланий и требований заказчика, уточнение требований, создание технического задания. 2) Проектирование: создание технического проекта, подготовка документации. 3) Реализация и тестирование. 4) Внедрение (развертывание). 5) Сопровождение. Модели жизненного цикла ПО: 1) Каскадная (нисходящая, водопадная) 2) Каскадная с возвратами 3) Спиральная (итеративная)
Методология RAD. Относится к спиральной модели. Концепция создания ПО, уделяющая особое внимание быстроте и удобству программирования. Характерные черты: 1) небольшая команда программистов (от 2 до 10 человек); 2) короткий, но тщательно проработанный производственный график (от 2 до 6 мес.); 3) повторяющийся цикл, при котором разработчики, по мере того, как приложение начинает обретать форму, запрашивают и реализуют в продукте требования, полученные через взаимодействие с заказчиком. ЖЦПО по методологии RAD состоит из четырех фаз: 1).фаза анализа и планирования требований; 2).фаза проектирования; 3).фаза построения; 4).фаза внедрения. Основные принципы методологии RAD: 1) разработка приложений итерациями; 2) необязательность полного завершения работ на каждом из этапов жизненного цикла; 3) обязательное вовлечение пользователей в процесс разработки; 4) необходимое применение CASE-средств, обеспечивающих целостность проекта; 5) применение средств управления конфигурацией, облегчающих внесение изменений в проект и сопровождение готовой системы; 6) необходимое использование генераторов кода; 7) использование прототипирования, позволяющее полнее выяснить и удовлетворить потребности конечного пользователя; 8) тестирование и развитие проекта, осуществляемые одновременно с разработкой; 9) ведение разработки немногочисленной хорошо управляемой командой профессионалов; 10) грамотное руководство разработкой системы, четкое планирование и контроль выполнения работ. | 6. Сущность структурного подхода. Диаграммы потоков данных (DFD) (нотация Гейна-Сарсона), диаграммы «сущность-связь» (ERD) (нотация Чена), технология структурного анализа и проектирования (SADT). Сущность структурного подхода: декомпозиция на функциональные подсистемы, которые в свою очередь делятся не более мелкие единицы. Образуется иерархия, в которой система сохраняет целостное представление. Базовые принципы: «разделяй и властвуй» и принцип иерархического упорядочивания. Остальные принципы: абстрагирование (выделение существенного, отсечение остального), формализация (строгое описание), непротиворечивость, структурирование данных В структурном анализе используются средства выражения функций системы и отношений между данными (с помощью диаграмм). Наиболее популярные нотации: SADT, DFD, ERD. SADT (позже развилась в IDEF0) – Разработчики решили формализовать процесс создания системы, разбив его на следующие фазы: * Анализ — определение того, что система будет делать, * Проектирование — определение подсистем и их взаимодействие, * Реализация — разработка подсистем по отдельности, объединение — соединение подсистем в единое целое, * Тестирование — проверка работы системы, * Установка — введение системы в действие, * Функционирование — использование системы. SADT - совокупность методов, правил и процедур построения функциональной модели. При создании диаграмм: - число блоков на каждому уровне ограничивается 3-6; - блоки нумеруются для обеспечения связности; - метки и имена уникальны; - структура не учитывается, только функции.
Блок диаграммы SADT: Каждый блок может быть иерархически развернут в диаграмму более низкого уровня и т. д. Иерархия обозначается номерами блоков: на первом уровне 1, 2, 3, на втором 11, 12, 21, … и т. д. Всю иерархию можно изобразить отдельно в виде дерева диаграмм. DFD – иерархические диаграммы, описывающие асинхронный процесс преобразования информации в системе.
ERD – описание сущностей предметной области, их атрибутов и взаимосвязей. Здесь только основные элементы диаграммы, бывают еще: родительская сущность (прямоугольники сущностей вложены друг в друга), идентифицирующая связь (ромб с двойной границей), многозначный атрибут (эллипс с двойной границей). Связь соединяется с сущностями линиями, над которыми указывается порядок отношения.
|
7. Особенности объектно-ориентированного подхода при проектировании сложных программных систем: иерархичность, групповая разработка, сборочное проектирование. Основные методы разработки сложных систем, язык UML для описания, визуализации и документирования систем. Сложная система – содержит взаимоисключающие требования. О-О проектирование – методология проектирования, соединяющая в себе процесс объектной декомпозиции и приемы представления логической, физической, а также статической и динамической моделей проектируемой системы. Программная система представляется в виде множества самостоятельных сущностей, взаимодействующих друг с другом. Каждая сущность сама отвечает за необходимую информацию и реализует своё поведение. Сборочное программирование - технология программирования, при которой программа собирается посредством повторного использования уже известных фрагментов программ. О-О сборочное программирование - разновидность сборочного программирования: - основанная на методологии объектно-ориентированного программирования; и - предполагающая распространение библиотек классов в виде исходного кода или упаковку классов в динамически компонуемую библиотеку. Метод – концептуальное описание правил построения моделей с использованием графической нотации. Унифицированный язык моделирования - язык программирования, предназначенный для определения, представления, проектирования и документирования (программных) систем различной природы. Основными составляющими языка UML являются элементы, связи, механизмы расширения и диаграммы. 1. вариантов использования (use case diagrams) – для моделирования бизнес-процессов организации и требований к создаваемой системе; 2. классов (class diagrams) – для моделирования статической структуры классов системы и связей между ними;
3. поведения системы (behavior diagrams); 4. взаимодействия (interaction diagrams); 5. последовательности действий (sequence diagrams);
6. кооперативные (collaboration diagrams) – для моделирования процесса обмена сообщениями между объектами;
7. состояний (statechart diagrams ) – для моделирования поведения объектов системы при переходе из одного состояния в другое; 8. реализации (implementation diagrams); 9. деятельностей (activity diagrams) – для моделирования поведения системы в рамках различных вариантов использования, или моделирования деятельностей; 10. компонентов (component diagrams) – для моделирования иерархии компонентов (подсистем) системы;
11. размещения (deployment diagrams) – для моделирования физической архитектуры системы.
Существуют три различные точки зрения на построение диаграмм классов (или любой модели), однако эта разница гораздо более ощутимо проявляется по отношению к диаграммам классов. Концептуальная точка зрения. Если вы рассматриваете диаграммы классов с концептуальной точки зрения, то они будут отображать понятия изучаемой предметной области. Эти понятия, естественно, будут соответствовать реализующим их классам, однако такое прямое соответствие зачастую отсутствует. На самом деле, концептуальная модель, может иметь весьма слабое отношение или вообще не иметь никакого отношения к реализующему ее программному обеспечению, поэтому ее можно рассматривать как независимую от языка программирования. Точка зрения спецификации. В этом случае мы спускаемся на уровень ПО, но рассматриваем только интерфейсы, а не реализацию. Здесь мы будем иметь дело скорее с типами, а не с классами. О-О разработка подчеркивает различие между интерфейсами и реализацией, однако при таком подходе отсутствует какая-либо информация о структуре данных. Мы не знаем, содержит в действительности класс Заказ указатель на Клиента или же реализует свои функции, выполняя некоторый запрос к каждому Клиенту, чтобы выяснить, не связан ли он с данным Заказом. На диаграмме должен быть показан только интерфейс и ничего более. Точка зрения реализации. Если же модель отражает точку зрения реализации, мы можем исходить из предположения, что между связанными классами существуют указатели в обоих направлениях. | 8. Тенденции развития объектно-ориентированных инструментальных средств. CASE - средства разработчика и их сравнительная характеристика: методология IDEF0, диаграммы потоков данных DFD, метод описания процессов IDEF3. CASE-технология - программный комплекс, автоматизирующий технологический процесс анализа, проектирования, разработки и сопровождения сложных программных систем. CASE-технология поддерживает коллективную работу над проектом за счет: - использования возможностей локальной сети; - экспорта/импорта любых фрагментов проекта; - организованного управления проектами. Современные CASE-инструменты: - Code generation tools, - Data modeling tools, - UML, - Refactoring tools, - Queries/Views/Transformations or Model transformation Tools (MDE - Model-driven engineering is the systematic use of models as primary engineering artifacts throughout the engineering lifecycle), - Configuration management tools including revision control. Преимущества: 1. Единый графический язык (нотация), позволяющий полностью описать систему, делая ее наглядной, позволяя общаться аналитикам, программистам и заказчикам. 2. Единая БД проекта (репозитарий), в котором хранится документация, тесты, компоненты, отчеты… 3. Интеграция средств в CASE-системе (уровни анализа, проектирования…). 4. Поддержка коллективной разработки и управления проектом. 5. Быстрое создание макета (эскиза) системы (для показа пользователю). 6. Автоматическая генерация документации по стандартам. 7. Верификация (проверка на соответствие ТЗ) и контроль проекта на полноту и состоятельность на ранних стадиях (тестирование функциональных требований). 8. Автоматическая генерация объектного кода (до 90%). 9. Сопровождение и реинжиниринг (сопровождение всего проекта, а не кодов). Классификация CASE-систем: - по поддержке ЖЦ: Upper/Middle Case Tools (концептуальный дизайн/физическое проектирование и реализация). - по возможностям интеграции: CASE Framework, ICASE Tools, Integrated Project Support Environment. Сравнение:
RUP —Rational Unified Process MSF — Microsoft Solution Framework ORM — Object Role Modeling DFD — Data Flow Diagram SADT — Structural Analysis and Design Technique UNL — Unified Modeling Language. IDEF — Integrated Computer-Aided Manufacturing. IDEF0 — Function Modeling IDEF3 — Process Description Capture CASE — Computer-Aided System Engineering IDEF0 — методология и графическая нотация, предназначенная для формализации и описания бизнес-процессов. Отличительной особенностью IDEF0 является её акцент на соподчинённость объектов. В IDEF0 рассматривается логические отношения между работами, а не их временнамя последовательность DFD — общепринятое сокращение от англ. Data Flow Diagrams — диаграммы потоков данных. Так называется методология графического структурного анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных, к которым осуществляется доступ IDEF3 – стандарт документирования технологических процессов, происходящих на предприятии. Предоставляет инструментарий для наглядного исследования и моделирования их сценариев. Сценарием (Scenario) называют описание последовательности изменений свойств объекта, в рамках рассматриваемого процесса. Два основных потока: документы, определяющие структуру и последовательность процесса, и документы, отображающие ход его выполнения. Process Description Diagram:
Object State Transition Network Diagram | 9. Стандарты, поддерживающие создание мобильных прикладных программ информационных систем. Стандарты, регламентирующие интерфейсы пользователей с операционной средой, доступ к удаленной базе данных, язык SQL. POSIX - Portable Operating System Interface for Computer Environment [for Unix] - интерфейс переносимой операционной системы. Деление стандартов POSIX по функциональному назначению: • Базовый интерфейс. Определяют общие принципы проектирования, реализации и тестирования интерфейсов мобильных приложений. А также общее административное управление программами и данными (IEEE 1003.1; -2;-3; -4; -7); • Реализация интерфейса. Определяют интерфейсы ПО с ОС для языков C, Fortran, Ada (IEEE 1003.5; -9;-16; -19; -20); • Сетевой интерфейс. Определяют взаимодействие в открытых распределенных системах и телекоммуникацию в сетях, а также защиту информации (IEEE 1003.6; -8; -12; -15; -17); • Прочие интерфейсы (IEEE 1003.10; -11; -13; -14; -18). Определяют процесс создания, основные компоненты, структуру окружения для: - интерактивного взаимодействия с пользователями; - мультипроцессорных систем; - суперкомпьютеров; - систем реального времени. IEEE 1003.0, POSIX Guide; ISO 9945-1 Руководство по POSIX окружению открытых систем. Описывает принципы построения интерфейсов прикладных программ с платформой (ОС). ПО не должно взаимодействовать непосредственно с внешним окружением, только через сервисы платформы. Доработанная версия стандарта утверждена как ISO 9945-1. Определены интерфейсы: • между прикладными программами и платформой — API, Application Program Interface • между платформой и внешним окружением — EEI, External Environment Interface Эти интерфейсы и услуги детально расписаны в соответствующих частных стандартах POSIX. IEEE 1003.1, System Application Program Interface (API)(C language) Системный интерфейс прикладных программ (язык Си). Интерфейсы детализируются и уточняется. IEEE 1003.2, Shell and utilities; ISO 9945-2 Основные команды управления и сервисные программы, обеспечивающие переносимость. IEEE 1003.5; -9; -16; -19; 20 Конкретизируются интерфейсы прикладных программ, разрабатываемых на стандартизированных языках программирования: Си (ISO 9899), Ада (ISO 8652), Фортран (ISO 1359, 7846). В базовых стандартах упоминаются некоторые особенности интерфейсов приложений на языках программирования Паскаль (ISO 7185), Кобол (ISO 1989). Рекомендуется применение языков в виде современных модернизированных и дополнительных версий и использование для трансляции программ компиляторов, аттестованных авторитетными международными организациями. IEEE 1003.11; -13; –14 Формализуют профили взаимодействия для диалоговой обработки заданий, для информационных систем реального времени и для мультипроцессорных вычислительных систем соответственно. NIST разработал комплект аттестационных тестов и обеспечивает тестирование в аккредитованных на соответствие POSIX испытательных лабораториях, а также выдает сертификаты проверки. Каталог проверенных программных средств публикуется в специальном издании.
SQL служит для удобного и понятного пользователям формулирования обращений к реляционным БД и манипулирования данными. В языке имеются средства: • определения и манипулирования схемой БД; • определения ограничений и контроля целостности; • определения и уничтожения структур физического уровня для эффективной реализации транзакций; • авторизации и защиты доступа к данным; • использования точек сохранения транзакций и откатов при сбоях; • средства динамической компиляции запросов, на базе которых возможна диалоговая их обработка. Язык имеет строгую математическую основу на базе предикатов первого порядка. Группы по стандартизации и разработчики СУБД обеспечивают совместимость версий языка снизу вверх в последовательных расширениях языка. |
