ЛАБОРАТОРНАЯ РАБОТА № 5. Тестирование программ методами «белого ящика»

Цель работы: изучить методы тестирования логики программы, формализованные описания результатов тестирования и стандарты по составлению схем программ.

Подготовка к лабораторной работе

1. Ознакомиться с лекционным материалом по теме «Этапы разработки программного обеспечения. Тестирование и отладка программных продуктов» учебной дисциплины «Технология разработки программного обеспечения».

2. Изучить соответствующие разделы в изданиях [1, 2, 7, 8, 9, 37, 45].

3. Ознакомиться с разд. 5.2 данного пособия.

Теоретическая часть. Виды тестирования

Тестирование программного обеспечения включает в себя целый комплекс действий, аналогичных последовательности процессов разработки программного обеспечения. В него входят [7]:

• постановка задачи для теста;

• проектирование теста;

• написание тестов;

• тестирование тестов;

• выполнение тестов;

• изучение результатов тестирования.

Наиболее важным является проектирование тестов. Существуют разные подходы к проектированию тестов.

Первый состоит в том, что тесты проектируются на основе внешних спецификаций программ и модулей либо спецификаций сопряжения модуля с другими модулями, программа при этом рассматривается как «черный ящик». Смысл теста заключается в том, чтобы проверить, соответствует ли программа внешним спецификациям. При этом содержание модуля не имеет значения. Такой подход получил название — стратегия «черного ящика».

Второй подход — стратегия «белого ящика», основан на анализе логики программы. При таком подходе тестирование заключается в проверке каждого пути, каждой ветви алгоритма. При этом внешняя спецификация во внимание не принимается.

Ни один из этих подходов не является оптимальным. Реализация тестирования методом «черного ящика» сводится к проверке всех возможных комбинаций входных данных. Невозможно протестировать программу, подавая на вход бесконечное множество значений, поэтому ограничиваются определенным набором данных. При этом исходят из максимальной отдачи теста по сравнению с затратами на его создание. Она измеряется вероятностью того, что тест выявит ошибки, если они имеются в программе. Затраты измеряются временем и стоимостью подготовки, выполнения и проверки результатов теста.

Тестирование методом «белого ящика» также не дает 100%-ной гарантии того, что модуль не содержит ошибок. Даже если предположить, что выполнены тесты для всех ветвей алгоритма, нельзя с полной уверенностью утверждать, что программа соответствует ее спецификациям. Например, если требовалось написать программу для вычисления кубического корня, а программа фактически вычисляет корень квадратный, то реализация будет совершенно неправильной, даже если проверить все пути. Вторая проблема — отсутствующие пути. Если программа реализует спецификации не полностью (например, отсутствует такая специализированная функция, как проверка на отрицательное значение входных данных программы вычисления квадратного корня), никакое тестирование существующих путей не выявит такой ошибки. И наконец, проблема зависимости результатов тестирования от входных данных. Одни данные будут давать правильные результаты, а другие нет. Например, если для определения равенства трех чисел программируется выражение вида:

---

Ш (А + В+С)/Ъ = А,

то оно будет верным не для всех значений А, В и С (ошибка возникает в том случае, когда из двух значений В или С одно больше, а другое на столько же меньше А). Если концентрировать внимание только на тестировании путей, нет гарантии, что эта ошибка будет выявлена.

Таким образом, полное тестирование программы невозможно, т. е. никакое тестирование не гарантирует полное отсутствие ошибок в программе. Поэтому необходимо проектировать тесты таким образом, чтобы увеличить вероятность обнаружения ошибки в программе.

Стратегия «белого ящика»

Существуют следующие методы тестирования по принципу «белого ящика»:

• покрытие операторов;

• покрытие решений;

• покрытие условий;

• покрытие решений/условий;

• комбинаторное покрытие условий.

Метод покрытия операторов

Целью этого метода тестирования является выполнение каждого оператора программы хотя бы один раз.

Пример.

Если для тестирования задать значения переменных А = 2, В=0, Х=3, будет реализован путь асе, т. е. каждый оператор программы выполнится один раз (рис. Л5.1, а). Но если внести в алгоритм ошибки — заменить в первом условии and на or, а во втором Х> 1 на Х< 1 (рис. Л5.1, б), ни одна ошибка не будет обнаружена (табл. Л5.1). Кроме того, путь abd вообще не будет охвачен тестом, и если в нем есть ошибка, она также не будет обнаружена. В табл. Л5.1 ожидаемый результат определяется по блок-схеме на рис. Л5.1, а, а фактический — по рис. Л5.1, б.

Как видно из этой таблицы, ни одна из внесенных в алгоритм ошибок не будет обнаружена.

Метод покрытия решений (покрытия переходов)

Согласно методу покрытия решений каждое направление перехода должно быть реализовано, по крайней мере, один раз. Этот метод включает в себя критерий покрытия операторов, так как при выполнении всех направлений переходов выполнятся все операторы, находящиеся на этих направлениях.

Для программы, приведенной на рис. Л5.1, покрытие решений может быть выполнено двумя тестами, покрывающими пути {асе, аЪд\, либо {аса1, аЬе}. Для этого выберем следующие исходные данные: {А = 3, В = 0, Х=3} — в первом случае и {А = 2, В= I, Х= 1} — во втором. Однако путь, где ^не меняется, будет проверен с вероятностью 50 %: если во втором условии вместо условия Х> 1 записано Х< 1, то ошибка не будет обнаружена двумя тестами.

Результаты тестирования приведены в табл. Л5.2.

Этот метод может дать лучшие результаты по сравнению с предыдущими. В соответствии с методом покрытия условий записывается число тестов, достаточное для того, чтобы все возможные результаты каждого условия в решении выполнялись, по крайней мере, один раз.

В рассматриваемом примере имеем четыре условия: {А>1, В= 0}, {А = 2, Х> 1}. Следовательно, требуется достаточное число тестов, такое, чтобы реализовать ситуации, где А > 1, А < 1, В= 0 и 5^0 в точке а и А = 2, А * 2, Х> 1 и Х< 1 в точке Ь. Тесты, удовлетворяющие критерию покрытия условий (табл. Л5.3), и соответствующие им пути:

---

а) А = 2, В=0, Х=4асе;

6)А = 1, В= 1, Х=0аЬс1.

Таблица Л5.3. Результаты тестирования методом покрытия условий

Тест	Ожидаемый результат	Фактический результат	Результат тестирования
А = 2, В=0, Х=4	Х=3	Х=3	Неуспешно
А=\, В= 1, Х=0	Х=0	Х= 1	Успешно

Метод покрытия решений/условий

Критерий покрытия решений/условий требует такого достаточного набора тестов, чтобы все возможные результаты каждого условия выполнялись по крайней мере один раз, все результаты каждого решения выполнялись по крайней мере один раз и, кроме того, каждой точке входа передавалось управление по крайней мере один раз.

Недостатки метода:

• не всегда можно проверить все условия;

• невозможно проверить условия, которые скрыты другими условиями;

• недостаточная чувствительность к ошибкам в логических выражениях.

Так, в рассматриваемом примере два теста метода покрытия условий

а) А = 2, 5=0, Х=4 асе;

6)А= 1, 5 = 1, Х=0 аЪй отвечают и критерию покрытия решений/условий. Это является следствием того, что одни условия приведенных решений скрывают другие условия в этих решениях. Так, если условие А > 1 будет ложным, транслятор может не проверять условия 5=0, поскольку при любом результате условия 5=0 результат решения ((А> 1)&(5=0)) примет значение ложь. То есть в варианте на рис. Л5.1 не все результаты всех условий выполнятся в процессе тестирования.

Рассмотрим реализацию того же примера на рис. Л5.2. Наиболее полное покрытие тестами в этом случае осуществляется так, чтобы выполнялись все возможные результаты каждого простого решения. Для этого нужно покрыть пути aceg (тест А = 2, 5=0, ДГ=4), асаУк (тест Л = 3, В=1, Х=0), аЬр1 (тест Л = 0, 5 = 0, Х= 0), аЬА (тест А = 0, В = 0, Х= 2).

Протестировав алгоритм на рис. Л5.2, нетрудно убедиться в том, что критерии покрытия условий и критерии покрытия решений/условий недостаточно чувствительны к ошибкам в логических выражениях.

Метод комбинаторного покрытия условий

Критерий комбинаторного покрытия условий удовлетворяет также и критериям покрытия решений, покрытия условий и покрытия решений/условий.

Этот метод требует создания такого числа тестов, чтобы все возможные комбинации результатов условия в каждом решении выполнялись по крайней мере один раз. По этому критерию в рассматриваемом примере должны быть покрыты тестами следующие восемь комбинаций:

\.А> 1, 5=0. 5.А = 2, Х> 1. 2.А> 1, 5*0. 6. Л = 2, Х< 1. Ъ.А< 1, 5=0. 7. Л* 2, Х> 1. 4. А< 1, 5*0. 8. Л*2, Х< 1.

Для того чтобы протестировать эти комбинации, необязательно использовать все 8 тестов. Фактически они могут быть покрыты четырьмя тестами (табл. Л5.4):

• А = 2, 5= 0, Х- 4 {покрывает I, 5};

• А = 2, 5= 1, Х- 1 {покрывает 2, 6};

• А = 0,5, 5=0, Х= 2 {покрывает 3, 7};

• А = 1, 5= 0, Х= 1 {покрывает 4, 8}.

Порядок выполнения работы

1. Спроектировать тесты по принципу «белого ящика» для программы, разработанной в лабораторной работе № 4. Использовать схемы алгоритмов, разработанные и уточненные в лабораторных работах № 2, 3.

2. Выбрать несколько алгоритмов для тестирования и обозначить буквами или цифрами ветви этих алгоритмов.

3. Выписать пути алгоритма, которые должны быть проверены тестами для выбранного метода тестирования.

4. Записать тесты, которые позволят пройти по путям алгоритма.

5. Протестировать разработанную вами программу. Результаты оформить в виде таблиц (см. табл. Л5.1—Л5.4).

6. Проверить все виды тестов и сделать выводы об их эффективности.

7. Оформить отчет по лабораторной работе.

8. Сдать и защитить работу.

---

Защита отчета по лабораторной работе

Отчет по лабораторной работе должен состоять из:

1. Постановки задачи.

2. Блок-схемы программ.

3. Тестов.

4. Таблиц тестирования программы.

5. Выводов по результатам тестирования (не забывайте, что целью тестирования является обнаружение ошибок в программе).

Контрольные вопросы

1. Охарактеризуйте этап реализации и тестирования программного продукта.

2. Какие существуют виды тестирования?

3. Назовите критерии выбора тестов.

4. Перечислите свойства тестов.

5. Приведите критерии надежности программ.

6. В чем заключается оценка надежности программ?

ЛАБОРАТОРНАЯ РАБОТА № 6. Использование технологий OLE, СОМ и ActiveX

Цель работы: научиться создавать формальные модели и на их основе определять спецификации разрабатываемого программного обеспечения.

Лабораторная работа рассчитана на 4 академических часа.

Подготовка к лабораторной работе

1. Ознакомиться с лекционным материалом по теме «Ис-
пользование технологий OLE, СОМ и ActiveX» учебной дисцип-
лины «Технология разработки программного обеспечения».

2. Изучить соответствующие разделы в изданиях [1—3, 10, 11].

3. Ознакомиться с разд. 6.2 настоящего учебного пособия.

Теоретическая часть. От OLE к ActiveX

В данной лабораторной работе рассматривается использование технологии OLE (Object Linking and Embedding — связывание и внедрение объектов), которую можно определить как объектно-ориентированный протокол совместного доступа к данным и программному коду из разных процессов. OLE позволяет программистам создавать приложения для работы с составными документами, представляющими собой динамические связанные структуры, отдельные части которых могут разрабатываться в различных программах.

ActiveX и OLE фирмы Microsoft — еще один шаг к более совершенным, т. е. более надежным и эффективным, программам.

В основе ActiveX и OLE лежит очень простая идея, но, как оказалось, она позволяет существенно повысить эффективность программирования.

Первоначально OLE была задумана как технология интеграции программных продуктов, входящих в комплект Microsoft Office. Предшественницей OLE является реализованная в Windows технология динамического обмена данными DDE (Dynamic Data Exchange), до сих пор широко применяемая в данной среде. Однако многие разработчики не без оснований считают, что DDE трудно использовать, поскольку это технология низкого уровня.

В качестве технологии более высокого уровня была реализована OLE 1.0 OLE 1. Она расширила возможности протокола DDE и, используя его как базовый механизм коммуникаций, позволила активизировать встроенный объект в документе, т. е. получить составной документ. Таким образом, OLE 1.0 унаследовала многие проблемы асинхронного протокола. Эта технология имела множество недостатков, а ее компоновка была слишком сложна для пользователей среднего уровня. Кроме того, установленные связи легко нарушались, например, в результате изменения маршрута доступа к файлу связанного объекта.

---

С помощью OLE 1 пользователь мог, например, объединить электронную таблицу, созданную Microsoft Excel, с текстовым документом «производства» Microsoft Word. Идея состояла в том, чтобы документно-ориентированная (document-centric) модель работы с компьютером позволила бы пользователю больше думать об информации и меньше о приложениях, ее обрабатывающих. Как следует из слов «связывание и внедрение», составные документы можно создать, либо связав два разных документа, либо полностью внедрив один документ в другой.

OLE I, как и большинство первых версий программных продуктов, была несовершенна. Архитекторам следующей версии предстояло улучшить первоначальный проект. Вскоре они поняли, что составные документы лишь частный случай более общей проблемы: как разные программные компоненты должны предоставлять друг другу сервисы? Для решения этой проблемы архитекторы OLE создали группу технологий, область применения которых гораздо шире составных документов. Основу OLE 2 составляет важнейшая из этих технологий Модель многокомпонентных объектов (Component Object Model — COM). Новая версия OLE не только обеспечивает поддержку составных документов лучше, чем первая, но и, несомненно, идет куда дальше простого объединения документов, созданных в разных приложениях. OLE 2 позволяет по-новому взглянуть на взаимодействие любых типов программ.

В начале 1996 г. Microsoft ввела в оборот новый термин — ActiveX. Сначала он относился к технологиям, связанным с Интернетом, и приложениям, выросшим из него, вроде WWW (World Wide Web). Поскольку большинство разработок Microsoft в данной области было основано на СОМ, то и ActiveX была непосредственно связана с OLE. Однако очень скоро новый термин стал захватывать территории, традиционно принадлежавшие OLE, и вот теперь все вернулось на круги своя: OLE, как встарь, обозначает только технологию создания составных документов связыванием и внедрением, а разнообразные технологии на основе СОМ, ранее объединенные под именем OLE, собраны под знаменем ActiveX. А некоторые технологии, название которых содержало слово «OLE», даже перекрестили — теперь это технологии ActiveX.

Понятие СОМ

Все технологии OLE и ActiveX, описанные ниже, построены на основании, обеспеченном СОМ. Итак, что же такое СОМ? Чтобы ответить на этот вопрос, зададимся сначала другим: «Каким образом одна часть программного обеспечения должна получать доступ к сервисам, предоставляемым другой частью?» На сегодняшний день ответ зависит от того, что представляют собой эти части.

Приложения, например, скомпонованные с библиотекой, могут пользоваться ее сервисами, вызывая функции из этой библиотеки.

Приложение также может использовать сервисы другого, являющегося совершенно отдельным процессом. В этом случае два таких локальных процесса взаимодействуют посредством некоего механизма связи, который обычно требует определения протокола между этими приложениями (набор сообщений, позволяющий одному приложению выдавать запросы, а другому соответствующим образом отвечать на них).

---

Смотрите также файлы

• КР Руский язык22.docx

• Только для мужчин.docx

• Kursovaya_Malinovskaya333333333.docx

• вопросы ОММСЭП.docx

• РАЗДАТ. МАТЕР. СТУД. по БЖ.docx