Файл: Методические указания по выполнению практических по мдк 02. 02.pdf

25
Рис.3 Нисходящая интеграция
При нисходящей интеграции вы создаете те классы, которые находятся на вершине иерархии, первыми, а те, что внизу, — последними.
Хорошей альтернативой нисходящей интеграции в чистом виде может стать подход с вертикальным секционированием.
Рис. 4 Вертикальное секционирование
При этом систему реализуют сверху вниз по частям, возможно, по очереди выделяя функциональные области и переходя от одной к другой.
Восходящая интеграция
Рис.5 Восходящая интеграция
При восходящей интеграции вы пишете и интегрируете сначала классы, находящиеся в низу иерархии. Добавление низкоуровневых классов по одному, а не всех одновременно — вот что делает восходящую интеграцию инкрементной стратегией. Сначала вы пишете тестовые драйверы для выполнения низкоуровневых классов, а затем добавляете эти классы к тестовым драйверам, пристраивая их по мере готовности. Добавляя класс более высокого уровня, вы заменяете классы драйверов реальными.

26
Рис. 6 Гибридный подход при восходящей интеграции
Как и нисходящую, восходящую интеграцию в чистом виде используют редко — вместо нее можно применять гибридный подход, реализующий секционную интеграцию.
Сэндвич-интеграция
Проблемы с нисходящей и восходящей интеграциями в чистом виде привели к тому, что некоторые эксперты стали рекомендовать сэндвич-подход.
Рис. 7 Сэндвич-интеграция
Сначала вы объединяете высокоуровневые классы бизнес-объектов на вершине иерархии.
Затем добавляете классы, взаимодействующие с аппаратной частью, и широко используемые вспомогательные классы в низу иерархии.
Напоследок вы оставляете классы среднего уровня.
Риск-ориентированная интеграция
Риск-ориентированную интеграцию, которую также называют «интеграцией, начиная с самых сложных частей» (hard part first integration), похожа на сэндвич-интеграцию тем, что пытается избежать проблем, присущих нисходящей или восходящей интеграциям в чистом виде. Кроме того, в ней также есть тенденция к объединению классов верхнего и нижнего уровней в первую очередь, оставляя классы среднего уровня напоследок. Однако суть в другом.
При риск-ориентированной интеграции вы определяете степень риска, связанную с каждым классом. Вы решаете, какие части системы будут самыми трудными, и реализуете их первыми.
Функционально-ориентированная интеграция
Еще один поход — интеграция одной функции в каждый момент времени. Под «функцией» понимается не нечто расплывчатое, а какое-нибудь поддающееся определению свойство системы, в которой выполняется интеграция.
Когда интегрируемая функция превышает по размерам отдельный класс, то «единица приращения» инкрементной интеграции становится больше отдельного класса. Это немного снижает преимущество инкрементного подхода в том плане, что уменьшает вашу уверенность об источнике новых ошибок. Однако если вы тщательно тестировали классы, реализующие эту функцию, перед интеграцией, то это лишь небольшой недостаток. Вы можете использовать стратегии инкрементной интеграции рекурсивно, сформировав сначала из небольших кусков отдельные свойства, а затем инкрементно объединив их в систему.

27
Рис. 8 Функционально-ориентированная интеграция
Обычно процесс начинается с формирования скелета, поскольку он способен поддерживать остальную функциональность. В интерактивной системе такой изначальной опцией может стать система интерактивного меню. Вы можете прикреплять остальную функциональность к той опции, которую интегрировали первой.
Т-образная интеграция
Последний подход, который часто упоминается в связи с проблемами нисходящей и восходящей методик, называется «Т-образной интеграцией». При таком подходе выбирается некоторый вертикальный слой, который разрабатывается и интегрируется раньше других. Этот слой должен проходить сквозь всю систему от начала до конца и позволять выявлять основные проблемы в допущениях, сделанных при проектировании системы. Реализовав этот вертикальный участок (и устранив все связанные с этим проблемы), можно разрабатывать основную канву системы
(например, системное меню для настольного приложения). Этот подход часто комбинируют с риск- ориентированной и функционально-ориентированной интеграциями.
Рис. 9 Т-образная интеграция
Задание.
1.
Оформить внешнюю спецификацию.
2.
Составить в виде блок-схемы алгоритм решения задачи.
3.
Спроектировать и разработать модули программы для решения задачи на любом алгоритмическом языке программирования.
4.
Выполнить отладку и тестирование модулей программы.
5.
Выполнить инкрементную интеграцию модулей с использованием одного из подходов.
6.
Выполнить системное тестирование программы.
7.
Оформить отчет по лабораторной работе.
Отчет по лабораторной работе должен включать:
1.
Внешнюю спецификацию.
2.
Алгоритм решения задачи.
3.
Текст программы на языке программирования.
4.
Набор тестов для отладки модулей программы.

28 5.
Описание процесса интеграции модулей.
Задача. Задан двумерный массив размерности nm. Отсортировать элементы строк массива по возрастанию значений, а затем отсортировать строки массива по возрастанию среднего арифметического элементов строк.
Реализовать сортировку разными способами и сравнить эффективность этих способов для разных исходных данных.
Контрольные вопросы.
1. Значение фазы интеграции программных модулей.
2. Подходы к интегрированию программных модулей.
Эффективность и оптимизация программ.

29
Лабораторная работа №21 «Тестирование интерфейса пользователя средствами
инструментальной среды разработки»
Цель работы. Получение практических навыков автоматической генерации тестов на основе формального описания.
Теоретическая часть.
Практически все программные системы предусматривают интерфейс с оператором.
Практически всегда этот интерфейс – графический (GUI – Graphical User’s Interface).
Соответственно, актуальна и задача тестирования создаваемого графического интерфейса.
Вообще говоря, задача тестирования создаваемых программ возникла практически одновременно с самими программами. Известно, что эта задача очень трудоёмка как в смысле усилий по созданию достаточного количества тестов (отвечающих заданному критерию тестового покрытия), так и в смысле времени прогона всех этих тестов. Поэтому решение этой задачи стараются автоматизировать (в обоих смыслах).
Для решения задачи тестирования программ с программным интерфейсом (API – Application
Program Interface: вызовы методов или процедур, пересылки сообщений) известны подходы – методы и инструменты – хорошо зарекомендовавшие себя в индустрии создания программного обеспечения. Основа этих подходов следующая: создается формальная спецификация программы, и по этой спецификации генерируются как сами тесты, так и тестовые оракулы – программы, проверяющие правильность поведения тестируемой программы. Спецификации, как набор требований к создаваемой программе, существовали всегда, Ключевым словом здесь является формальная спецификация. Формальная спецификация – это спецификация в форме, допускающей её формальные же преобразования и обработку компьютером. Это позволяет анализировать набор требований с точки зрения их полноты, непротиворечивости и т.п. Для задачи автоматизации тестирования эта формальная запись должна также обеспечивать возможность описания формальной связи между понятиями, используемыми в спецификации, и сущностями языка реализации программы.
Правильность функционирования системы определяется соответствием реального поведения системы эталонному поведению. Для того чтобы качественно определять это соответствие, нужно уметь формализовать эталонное поведение системы. Распространённым способом описания поведения системы является описание с помощью диаграмм UML (Unified
Modeling Language). Стандарт UML предлагает использование трех видов диаграмм для описания графического интерфейса системы:
 Диаграммы сценариев использования (Use Case).
 Диаграммы конечных автоматов (State Chart).
 Диаграммы действий (Activity).
С помощью UML/Use Case diagram можно описывать на высоком уровне наборы сценариев использования, поддерживаемых системой. Данный подход имеет ряд преимуществ и недостатков по отношению к другим подходам, но существенным с точки зрения автоматизации генерации тестов является недостаточная формальная строгость описания.
Широко распространено использование UML/State Chart diagram для спецификации поведения системы, и такой подход очень удобен с точки зрения генерации тестов. Но составление спецификации поведения современных систем с помощью конечных автоматов есть очень трудоёмкое занятие, так как число состояний системы очень велико. С ростом функциональности системы спецификация становится всё менее и менее наглядной.
Перечисленные недостатки этих подходов к описанию поведения системы преодолеваются с помощью диаграмм действий (Activity). С одной стороны нотация UML/Activity diagram является более строгой, чем у сценариев использования, а с другой стороны предоставляет более широкие возможности по сравнению с диаграммами конечных автоматов.
Для создания прототипа работающей версии данного подхода используется инструмент
Rational Rose. В первую очередь для спецификации графического интерфейса пользователя при помощи диаграмм действий UML.
Для прогона сгенерированных по диаграмме состояний тестов используется инструмент
Rational Robot. Из возможностей инструмента в работе мы использовали следующие:
1.
Возможность выполнять тестовые воздействия, соответствующие переходам между состояниями в спецификации.

30 2.
Возможность проверять соответствие свойств объектов реальной системы и эталонных свойств, содержащихся в спецификации. Из тех возможностей, которые доступны с помощью этого инструмента, используется проверка следующих свойств объектов:

Наличие и состояние окон (заголовок, активность, доступность, статус).

Наличие и состояние таких объектов, как PushButton, CheckBox, RadioButton, List,
Tree и др. (текст, доступность, размер).

Значение буфера обмена.

Наличие в оперативной памяти запущенных процессов.

Существование файлов.
Рис. 2 Общая схема генерации и прогона тестов
Генератор строит по диаграмме состояний набор тестов. Условием окончания работы генератора является выполнение тестового покрытия. В данном случае в качестве покрытия было выбрано условие прохода по всем рёбрам графа состояний, то есть выполнения каждого доступного тестового воздействия из каждого достижимого состояния.
Автоматическая генерация тестов по диаграммам действий имеет следующие преимущества перед остальными подходами к тестированию графического интерфейса:
Генератор тестов есть программа (script), написанная на языке ‘Rational Rose Scripting language’ (расширение к языку Summit BasicScriptLanguage). В Rational Rose есть встроенный интерпретатор инструкций, написанных на этом языке, посредством которого можно обращаться ко всем объектам модели (диаграммы состояний).

Спецификация автоматически интерпретируется (тем самым она проверяется и компилируется в набор тестов).

Если какая-то функциональность системы изменилась, то диаграмму состояний достаточно изменить в соответствующем месте, и затем сгенерировать новый тестовый набор. Фактически, это снимает большую часть проблем, возникающих при организации регрессионного тестирования.

Гарантия тестового покрытия. Эта гарантия даётся соответствующим алгоритмом обхода графа состояний.
В процессе построения обхода, генератор тестов компилирует набор тестов - инструкции на языке SQABasic. Эти инструкции есть чередование тестовых воздействий и оракула свойств объектов, соответствующих данному состоянию.
Задание.
1. Сформировать диаграмму вариантов использования для задачи лабораторной работы № 1.
2. Сгенерировать набор тестов.
3. Составить отчет по лабораторной работе.
Отчет по лабораторной работе должен включать:
1. Диаграмму вариантов использования.
Файл с тестовым набором.

31

Лабораторная работа №22 «Разработка тестовых модулей проекта для тестирования
отдельных модулей»
Цель работы. Получение практических навыков использования средств автоматизации тестирования.
Теоретическая часть.
Для того чтобы продолжать тестирование, когда один тест не прошёл, в генератор тестов встроена возможность выбора – генерировать один большой тест или набор атомарных тестов.
Атомарный тест – тот, который не требует приведения системы в состояние, отличное от начального состояния.
В связи с наличием ограничения инструмента прогона тестов на тестовую длину, в тесты после каждой законченной инструкции вставляется строка разреза. Во время прогона по этим строкам осуществляется разрез теста в случае, если его длина превышает допустимое ограничение.
После прохождения части теста до строки разреза продолжается выполнение теста с первой инструкции, следующей за строкой разреза. Нарезку и сам прогон тестов осуществляет прогонщик тестов.
В качестве прогонщика тестов мы используем Rational Robot, который выполняет сгенерированные наборы инструкций. В случае удачного выполнения всех инструкций выносится вердикт – тест прошёл. В противном случае, если на каком-то этапе выполнения теста, поведение системы не соответствует требованиям, Robot прекращает его выполнение, вынося соответствующий вердикт – тест не прошёл.
Задание.
1. Выполнить тестовый набор лабораторной работы № 2.
2. Проанализировать отчёт о прохождении тестов.
3. Составить отчет по лабораторной работе.
Отчет по лабораторной работе должен включать:
1. Отчёт о прохождении тестов.
2. Анализ отчёта о прохождении тестов.

32
Лабораторная работа №23 «Выполнение функционального тестирования»
Цель работы. Получить практические навыки разработки тестов на основе внешней спецификации программы.
Теоретические основы.
Программа в случае тестирования с управлением по данным рассматривается как "черный ящик", и целью тестирования является выяснение обстоятельств, в которых поведение программы не соответствует спецификации. Различают следующие методы формирования тестовых наборов:
- эквивалентное разбиение;
- анализ граничных значений;
- анализ причинно-следственных связей;
- предположение об ошибке.
Эквивалентное разбиение.
Область всех возможных наборов входных данных программы по каждому параметру разбивают на конечное число групп - классов эквивалентности. Наборы данных такого класса объединяют по принципу обнаружения одних и тех же ошибок. Для составления классов эквивалентности нужно перебрать ограничения, установленные для каждого входного значения в техническом задании или при уточнении спецификации. Каждое ограничение разбивают на две или более групп.
Граничные значения.
Граничные значения - это значения на границах классов эквивалентности входных значений или около них.
Анализ причинно-следственных связей.
Метод анализа причинно-следственных связей позволяет системно выбирать тесты, используя алгебру логики. Причиной называют отдельное входное условие или класс эквивалентности. Следствием - выходное условие или преобразование системы. Идея заключается в отнесении всех следствий к причинам, то есть в уточнении причинно-следственных связей.
Предположение об ошибке.
Метод основан на интуиции программиста с большим опытом работы. Составляется список, в котором перечисляются возможные ошибки или ситуации, в которых они могут появиться, а затем на основе списка составляются тесты.
Задание.
1. На основе внешней спецификации задачи Практического занятия №5 составить набор тестов на основе подхода «чёрного ящика».
2. Провести тестирование программы.
3. Оформить отчет по лабораторной работе.
Отчет по лабораторной работе должен включать:
1.
Внешнюю спецификацию.
2.
Алгоритм решения задачи.
3.
Текст программы на языке программирования.
4.
Набор тестов на основе подхода «чёрного ящика» для отладки программы.

33
Лабораторная работа №24 «Тестирование интеграции»
Цель работы. Получить практические навыки отладки программ с помощью отладчика среды программирования.
Теоретические основы.
Отладка — это процесс определения и устранения причин ошибок. Этим она отличается от тестирования, направленного на обнаружение ошибок. В некоторых проектах отладка занимает до
50% общего времени разработки. Многие программисты считают отладку самым трудным аспектом программирования.
Для сокращения времени отладки необходимо пользоваться научным подходом.
Классический научный подход включает следующие этапы:
1.
Сбор данных при помощи повторяющихся экспериментов.
2.
Формулирование гипотезы, объясняющей релевантные данные.
3.
Разработка эксперимента, призванного подтвердить или опровергнуть гипотезу.
4.
Подтверждение или опровержение гипотезы.
5.
Повторение процесса в случае надобности.
Эффективный метод поиска дефектов при отладке с использованием научного подхода может быть описан следующими шагами:
1.
Стабилизация ошибки.
2.
Определение источника ошибки. a.
Сбор данных, приводящих к дефекту. b.
Анализ собранных данных и формулирование гипотезы, объясняющей дефект. c.
Определение способа подтверждения или опровержения гипотезы, основанного или на тестировании программы, или на изучении кода. d.
Подтверждение или опровержение гипотезы при помощи процедуры, определенной в п. 2(c).
3.
Исправление дефекта.
4.
Тестирование исправления.
5.
Поиск похожих ошибок.
Способ подтверждения или опровержения гипотезы может быть одним из следующего списка:
1. сокращение подозрительной области кода;
2. проверка классов и методов, в которых дефекты обнаруживались ранее;
3. проверка кода, который изменялся недавно.
Отладка — это тот этап разработки программы, от которого зависит возможность се выпуска. Конечно, лучше всего вообще избегать ошибок. Однако потратить время на улучшение навыков отладки все же стоит, потому что эффективность отладки, выполняемой лучшими и худшими программистами, различается минимум в 10 раз.
Систематичный подход к поиску и исправлению ошибок — непременное условие успешности отладки. Организуйте отладку так, чтобы каждый тест приближал вас к цели.
Используйте Научный Метод Отладки.
Прежде чем приступать к исправлению программы, поймите суть проблемы. Случайные предположения о причинах ошибок и случайные исправления только ухудшат программу.
Установите в настройках компилятора самый строгий уровень диагностики и устраняйте причины всех ошибок и предупреждений.
Инструменты отладки значительно облегчают разработку ПО. Найдите их и используйте.
Большинство современных сред программирования (Delphi, C++ Builder, Visual Studio и т.д.) включают средства отладки, которые обеспечивают максимально эффективную отладку. Они позволяют:

выполнять программу по шагам, причем как с заходом в подпрограммы, так и выполняя их целиком;

предусматривать точки останова;

выполнять программу до оператора, указанного курсором;

отображать содержимое любых переменных при пошаговом выполнении;

отслеживать поток сообщений и т.п.
Задание.
1. Составить в виде блок-схемы алгоритм решения задачи.
2. Создать программу решения задачи на любом алгоритмическом языке программирования.