Отладка и тестирование программ: основные подходы и ограничения (Тестирование безопасности.)

Содержание:

ВВЕДЕНИЕ

Процесс тестирования программного обеспечения обеспечивает получение актуальной информации о статусе проекта разработки ПО в разрезе требования/функциональность.

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

1. Основные понятия тестирования и отладки программного обеспечения

   1. Отладка программного обеспечения

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

Отладка не является одной из разновидностей тестирования, хотя слова «тестирование» и «отладка» зачастую используются как синонимы. На самом деле, под ними подразумеваются совершенно разные виды деятельности:

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

«Тестирование» и «отладка» тесно взаимосвязаны и поэтому обычно рассматриваются как комплексная проверка программного обеспечения.

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

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

По различным оценкам специалистов, из времени разработки программного обеспечения, отладка занимает от 50% до 90% (в зависимости от результатов проведения предыдущих этапов).

Отладку можно разделить на синтаксическую и семантическую.

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

В отличие от синтаксической ошибки, семантическая ошибка не является формализуемой и поэтому она не составляет основу отладки.

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

• 1. Тестирование программного обеспечения

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

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

Основным методом обнаружения ошибок в программном обеспечении является его тестирование. Эффективность тестирования – важнейший фактор, определяющий стоимость и длительность разработки больших программных продуктов с заданным качеством. Затраты на тестирование для обнаружения ошибок в программном обеспечении достигают от 30% до 40% от общих затрат на его разработку и в значительной степени определяют его качество.

Цель проверяющего программное обеспечение (тестировщика программного обеспечения) – заставить программное обеспечение работать некорректно.

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

• 1. Этапы тестирования программного обеспечения

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

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

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

Процесс тестирования программного обеспечения можно разделить на три этапа:

1. Проверка в нормальных условиях.

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

1. Проверка в экстремальных условиях.

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

Типичные примеры — очень большие числа, очень малые числа или отсутствие информации.

1. Проверка в исключительных ситуациях.

Используются исходные данные, значения которых лежат за пределами допустимой области их изменения.

Наихудшая ситуация – когда программное обеспечение воспринимает неверные данные как правильные и выдаёт неверный, но правдоподобный результат.

Программное обеспечение должно самостоятельно отвергать любые данные, которые оно не в состоянии обрабатывать верно (так называемые исключения).

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

Различают еще так называемые «Альфа» и «Бета» – тестирования (см. п. 2.3).

• 1. Ошибки программного обеспечения

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

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

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

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

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

На этапе отладки программ выявляются и исправляются много ошибок, но далеко не все. Опыт показывает, что всякая последняя найденная ошибка на самом деле является предпоследней, т.к. программисты не продумывают до конца последствия исправления найденной ошибки.

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

Ошибку можно отнести к одному из нижеперечисленных классов:

1. Системные ошибки.

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

На начальных стадиях проектирования программного обеспечения не всегда удается точно сформулировать целевую задачу всей системы и требования к ней. В процессе проектирования ПО целевая функция системы уточняется и выявляются отклонения от уточненных требований, которые могут квалифицироваться как системные ошибки.

1. Алгоритмические ошибки.

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

К алгоритмическим ошибкам следует отнести также ошибки связей модулей и функциональных групп программ. Их можно квалифицировать как ошибки некорректной постановки задачи. Алгоритмические ошибки проявляются в неполном учете диапазонов изменения переменных, в неправильной оценке точности используемых и получаемых величин, в неправильном учете связи между различными переменными, в неадекватном представлении формализованных условий решения задачи в спе­цификациях или схемах, подлежащих программированию и т.д. Эти обстоятельства являются причиной того, что для исправления каждой алгоритмической ошибки приходится изменять иногда целые ветви программного обеспечения, т.е. пока еще существенно больше операторов, чем при исправлении программных ошибок.

Алгоритмические ошибки значительно труднее поддаются обнаружению методами формализованного автоматического контроля.

1. Технологические ошибки.

Технологические ошибки — это ошибки документации и фиксирования программ в памяти ЭВМ. Они составляют 5—10 % от общего числа ошибок, обнаруживаемых при отладке. Большинство технологических ошибок выявляются автоматически формализованными методами (например, транслятором).

1. Программные ошибки.

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

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

Семантика языка – это система правил истолкования построений конструкций.

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

1. Синтаксические ошибки.

Под синтаксическими ошибками понимается нарушение правил записи программ на данном языке программирования. Они выявляются самой машиной, точнее транслятором, во время перевода записи алгоритма на язык машины. Исправление их осу­ществляется просто — достаточно сравнить формат исправляемой конструкции с синтаксисом в справочнике и исправить его.

1. Семантические ошибки.

Семантические (смысловые) ошибки — это применение операторов, которые не дают нужного эффекта, ошибка в структуре алгоритма, в логической взаи­мосвязи его частей, в применении алгоритма к тем данным, к которым он неприменим и т.д. Правила семантики не фор­мализуемы. Поэтому поиск и устранение семантической ошибки и составляет основу отладки.

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

Число программных ошибок зависит также от квалификации программистов, от общего объема комплекса программ, от глубины логического и информационного взаимодействия модулей и от ряда других факторов.

Каждая программная ошибка влечет за собой необходимость изменения команд существенно меньше, чем при алгоритми­ческих и системных ошибках. На этапах комплексной отладки ПО и эксплуатации удельный вес программных ошибок падает и составляет примерно 15 и 30 % соответственно от общего коли­чества ошибок, выявляемых в единицу времени.

1. Стратегия тестирования и отладки программного обеспечения

   1. Тестирование элементов

Объектом тестирования элементов является наименьшая единица проектирования программной системы, т.е. программный модуль. Для обнаружения ошибок в рамках модуля тестируются его важнейшие управляющие пути.

Относительная сложность тестов и ошибок определяется как результат ограничений области тестирования элементов.

Тестированию подвергаются:

1. Интерфейс модуля;
2. Внутренняя структура данных;
3. Независимые пути;
4. Пути обработки ошибок;
5. Ограниченные условия;

Интерфейс модуля тестируется для проверки правильности ввода/вывода тестовой информации. Исследование внутренних структур данных гарантирует целостность сохраняемых данных. Тестирование независимых путей гарантирует однократное выполнение всех операторов модуля.

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

Наиболее общими ошибками вычислений являются:

1. Неправильный или неопределенный приоритет арифметических операций;
2. Некорректная инициализация;
3. Несогласованность представления и точности;
4. Некорректное символьное представление выражений;

Источником ошибок сравнения и неправильных потоков управления являются:

1. Сравнение данных различных типов;
2. Некорректные логические операции или их приоритеты;
3. Ожидание эквивалентности в условиях, когда ошибки точности делают эквивалентность невозможной;
4. Неправильное прекращение цикла;
5. Отказ в выходе из цикла при прекращении итераций;
6. Неправильное изменение элементов цикла;

Обычно при проектировании модуля предвидят некоторые ошибочные условия. Для защиты от ошибочных условий в модуль вводят пути обработки ошибок. Такие пути тоже должны тестироваться.

Тестирование путей обработки ошибок необходимо ориентировать на следующие ситуации:

1. сообщение об ошибке невразумительно;
2. текст сообщения не соответствует обнаруживаемой ошибке;
3. вмешательство системных средств, регистрация ошибки произошла до обработки ошибки в модуле;
4. обработка исключительного условия некорректна;
5. описание ошибки не позволяет определить ее причину.

Часто необходимо выполнять граничное тестирование модулей, поскольку ошибки часто происходят:

1. при обработке n-ого элемента массива из n элементов;
2. при выполнении m-ой итерации цикла с m-проходами;
3. при появлении минимального или максимального значения.

Тестовые варианты, ориентированные на данные варианты, имеют высокую вероятность обнаружения ошибок.

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

Дополнительными средствами тестирования является драйвер тестирования и заглушки.

Драйвер – это управляющая программа, которая принимает исходные данные и ожидаемые результаты тестовых вариантов, запускает тестируемый модуль, получает из модуля реальные результаты и на основе сравнения ОР и РР формирует отчет о результатах тестирования.

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

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

• 1. Тестирование итераций

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

Категории ошибок интерфейса:

1. потеря данных при прохождении через интерфейс;
2. отсутствие в модуле необходимой ссылки;
3. неправильное влияние одного модуля на другой;
4. подфункции при объединении не образуют требуемую главную функцию;
5. отдельные допустимые неточности при интеграции выходят за допустимый уровень;
6. возникают проблемы при работе с глобальными структурами данных.

Существует два варианта тестирования, поддерживающих процессы интеграции:

1. нисходящее тестирование (см. п. 2.1);
2. восходящее тестирование (см. п. 2.1).
   1. Тестирование правильности

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

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

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

1. Системная спецификация;
2. План программного проекта;
3. Спецификация требований к программной системе и работающий или бумажный макет;
4. Предварительное руководство пользователя;
5. Спецификация проектирования;
6. Листинги исходных текстов программ;
7. Плановая методика тестирования;
8. Руководство по работе;
9. Исполняемый код программы;
10. Описание базы данных;
11. Руководство пользователя по настройке;
12. Документы сопровождения;
13. Отчеты о проблемах программной системы;
14. Отчеты о конструкторских изменениях;

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

Разработчик не может предугадать, как заказчик будет реально использовать программную систему. Для обнаружения ошибок, которые может найти только конечный пользователь, используют процесс, включающий «Альфа» – тестирование и «Бета» –тестирование.

«Альфа» –тестирование – тестирование проводится заказчиком в организации разработчика. Разработчик фиксирует все выявляемые заказчиком ошибки и проблемы использования программной системы.

«Бета» –тестирование – тестирование проводится конечным пользователем в организации заказчика. Разработчик в этом процессе участия не принимает.

Фактически «Бета» –тестирование – это реальное применение программной системы в среде, которая не управляется разработчиком. Заказчик сам записывает все обнаруженные проблемы и сообщает о них разработчику.

«Бета»–тестирование проводится в течение фиксированного срока, обычно, около года. По результатам выявленных проблем разработчик изменяет программную систему и тем самым подготавливает полностью программный продукт к использованию в организации заказчика.

• 1. Системное тестирование

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

1. Предусмотреть средства обработки ошибок, которые тестируют все виды информации из других элементов системы;
2. Провести тесты, моделирующие неудачные данные или другие потенциальные ошибки интерфейса программной системы;
3. Записать результаты тестов, чтобы использовать их в качестве доказательства невиновности;
4. Надо принять участие в планировании и проектировании системных тестов, чтобы гарантировать адекватное тестирование программной системы;

В конечном счете, системные тесты должны проверить, что все системные элементы правильно объединены и выполняют назначенные функции.

Основные типы системных тестов:

1. Тестирование установления.

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

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

1. Тестирование безопасности.

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

При неограниченном времени и ресурсах хорошее тестирование безопасности взломает любую систему.

Задача проектировщика системы сделать цену проникновения более высокой, чем цена полученной информации.

1. Стрессовые тесты.

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

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

1. Тестирование производительности.

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

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

1. Методы тестирования и отладки программного обеспечения
   1. Восходящее тестирование

Восходящее тестирование – метод тестирования аппаратных и программных средств, при котором проверка начинается с самых простых элементов или частей программы.

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

Проверка завершается после того, когда будет произведена оценка работоспособности системы в целом.

Шаги методики восходящего тестирования интеграции:

1. Модули нижнего уровня объединяются в так называемые кластеры (группы, блоки), выполняющие определенную программную подфункцию.
2. Для координации ввода/вывода тестового варианта пишется драйвер, управляющей тестированием кластеров.
3. Тестируется кластер.
4. Драйверы тестирования удаляются, а кластеры объединяются в структуру движения вверх.

Основной недостаток восходящего тестирования заключается в том, что система не существует как объект до тех пор, пока не будет добавлен последний модуль.

Основное достоинство восходящего тестирования заключается в том, что оно упрощает разработку тестовых вариантов благодаря отсутствию заглушек.

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

Признаки критического модуля:

1. реализуют несколько требований в программной системе;
2. имеет высокий уровень управления, то есть находится достаточно высоко в иерархии программной структуры;
3. имеет высокую цикломатическую сложность;
4. имеет определенные требования производительности обработки.

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

• 1. Нисходящее тестирование

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

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

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

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

При нисходящем тестировании интеграции модули объединяются движением сверху вниз по управляющей иерархии, начиная от главного управляющего модуля.

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

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

Возможные шаги процесса нисходящей интеграции:

1. Главный управляющий модуль, находящийся на вершине иерархии, используется как тестовый драйвер. Все подчиненные ему модули замещаются заглушками.
2. Одна из заглушек заменяется реальным модулем. Этот модуль выбирается поиском в глубину или в ширину.
3. После подключения каждого модуля и установки на нем заглушек проводится набор тестов, проверяющих полученную структуру.
4. Если в модуле-драйвере уже нет заглушек, производится смена модуля-драйвера поиском в ширину или в глубину.
5. Выполняется возврат на шаг два до тех пор, пока не будет протестирована вся структура.

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

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

Существует три пути борьбы с этим недостатком:

1. откладывать некоторые тесты до замещения заглушек реальными модулями;
2. разработать заглушки, частично выполняющие функции модулей;
3. подключать модуль движением снизу вверх.
   1. Метод сандвича

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

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

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

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

Модифицированный метод сандвича.

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

• 1. Метод тестирования «черного ящика»

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

1. набор, образуемый входными данными, который приводит к аномалиям поведения программы;
2. набор, образуемый такими входными данными, которые демонстрируют дефекты программы.

Любой способ тестирования черного ящика должен:

1. выявить такие входные данные, которые с высокой вероятностью приводят к аномалиям поведения программы;
2. сформулировать такие ожидаемые результаты, которые с высокой вероятностью выявляют наличие дефектов.

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

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

Тестирование черного ящика обеспечивает поиск следующих категорий ошибок:

1. некорректных или отсутствующих функций;
2. ошибок интерфейса;
3. ошибок во внешних структурах данных или в доступе к внешней базе данных;
4. ошибок характеристик аппаратных устройств;
5. ошибок инициализации и завершения.

Подобная категория ошибок не позволяет выявить тестирование белого ящика.

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

Технология тестирования черного ящика ориентирована на решение следующих задач:

1. Сокращение необходимого количества тестовых вариантов из-за проверки нестатических, а динамических аспектов системы;
2. Выявление классов ошибок, а не отдельных ошибок.
   1. Тестирование методом «белого ящика»

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

1. гарантируется проверка всех независимых маршрутов программы;
2. проверяются ветви TRUE и FALSE для всех логических решений;
3. выполняются все циклы в пределах их границ и диапазонов;
4. анализируется правильность внутренних структур данных.

Недостатки тестирования белого ящика:

1. количество независимых маршрутов может быть очень велико;
2. исчерпывающее тестирование маршрутов не гарантирует соответствие программы исходным требованиям к ней;
3. в программе могут быть пропущены некоторые маршруты;
4. нельзя обнаружить ошибки, появление которых зависит от обрабатываемых данных.

Достоинства тестирования белого ящика позволяют учесть особенности программных ошибок.

1. Количество обнаруживаемых ошибок минимально в центре и максимально на периферии программы.
2. Предварительное предположение о вероятности потока управления или данных в программе часто бывает некорректно. В результате типовым может стать маршрут, модель вычислений по которому проработана слабо.
3. При записи алгоритма программного обеспечения на языке программирования возможно внесение типовых ошибок, как синтаксических, так и логических.
4. Некоторые результаты в программе зависят не от исходных данных, а от внутренних состояний программы.

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

ЗАКЛЮЧЕНИЕ

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

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

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1. Луиза Тамре «Введение в тестирование программного обеспечения». ISBN 5-8459-0394-7, 0-2017-1974-6.
2. Борис Бейзер «Тестирование черного ящика. Технологии функционального тестирования программного обеспечения и систем». ISBN 5-94723-698-2.
3. Святослав Куликов «Тестирование программного обеспечения. Базовый курс». ISBN 978-985-581-125-2.
4. Сэм Канер, Джек Фолк, Енг Кек Нгуен «Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений». ISBN 966-7393-87-9, 1-85032-847-1.
5. Элфрид Дастин, Джефф Рэшка, Джон Пол «Тестирование программного обеспечения». ISBN 978-5-85582-318-9.
6. И.В. Степанченко «Методы тестирования программного обеспечения». ISBN 5-230-04563-9.
7. Роберт Калбертсон «Быстрое тестирование». ISBN 5-8459-0336.