Вопросы

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) – совокупность методов, правил и процедур построения функциональной модели. При создании диаграмм: - число блоков на каждому уровне ограничивается 3-6; - блоки нумеруются для обеспечения связности; - метки и имена уникальны; - структура не учитывается, только функции. Блок диаграммы SADT: Каждый блок может быть иерархически развернут в диаграмму более низкого уровня и т. д. Иерархия обозначается номерами блоков: на первом уровне 1, 2, 3, на втором 11, 12, 21, … и т. д. Всю иерархию можно изобразить отдельно в виде дерева диаграмм. DFD – иерархические диаграммы, описывающие асинхронный процесс преобразования информации в системе. ERD – описание сущностей предметной области, их атрибутов и взаимосвязей. Здесь только основные элементы диаграммы, бывают еще: родительская сущность (прямоугольники сущностей вложены друг в друга), идентифицирующая связь (ромб с двойной границей), многозначный атрибут (эллипс с двойной границей). Связь соединяется с сущностями линиями, над которыми указывается порядок отношения.

7. Особенности объектно-ориентированного подхода при проектировании сложных программных систем: иерархичность, групповая разработка, сборочное проектирование. Основные методы разработки сложных систем, язык UML для описания, визуализации и документирования систем.

8. Тенденции развития объектно-ориентированных инструментальных средств. CASE - средства разработчика и их сравнительная характеристика: методология IDEF0, диаграммы потоков данных DFD, метод описания процессов IDEF3.

9. Стандарты, поддерживающие создание мобильных прикладных программ информационных систем. Стандарты, регламентирующие интерфейсы пользователей с операционной средой, доступ к удаленной базе данных, язык SQL.