Файл: Отладка и тестирование программ.pdf

Комплексное тестирование является процессом контроля, если оно выполняется в моделируемой среде, и процессом испытания, если выполняется в реальной среде.

Тестирование приемлемости (acceptance testing) – проверка соответствия программы требованиям пользователя.

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

Отношения между этими типами тестов и процессами проектирования показаны в приложении А (стр. 47).

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

1.4. Экономика тестирования

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

Итог первой главы

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

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

ГЛАВА 2.

Основные методологии проведения тестов и их ограничения

2.1. Стратегия проектирования тестов

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

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

• тестирование по отношению к спецификациям (не заботясь о тексте программы)
• тестирование по отношению к тексту программы (не заботясь о спецификациях)

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

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

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

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

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

2.2. Интеграция модулей

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

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

2.3. Методы тестирования

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

а) статический

б) детерминированный

в) стохастический

г) в реальном масштабе времени

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

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

Статическое тестирование – методология тестирования, проводящаяся без непосредственного использования ЭВМ путём просмотра текста программы после трансляции, путём контроля правил структурного построения программ и обработки данных. Как эталон воспринимаются во-первых, внутренние спецификации, во-вторых, совместный опыт специалистов-тестировщиков. Использование данного подхода является достаточно эффективным. По данным компании IBM, для типичных программ можно найти от 30% до 80% ошибок кодирования и логического проектирования. Благодаря данному подходу можно существенно увеличить эффективность а так же надежность программного обеспечения, а так же следуя этому методу можно раньше обнаружить ошибки, из чего следует уменьшить стоимость их исправления.

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

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

2.3.1. Восходящее тестирование

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

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

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

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

В ходе применения такого подхода появляются два вопроса:

а) Что необходимо делать в том случае, когда тестируемый модуль требует вызвать модуль, которого в данный момент ещё не существует (модуль более низкого уровня), и как подаются тестируемые данные? Решением данного вопроса будет программирование модулей-заглушек, для имитации функций отсутствующих модулей, которые моделируют функции недостающих модулей. Зачастую написание «заглушки» может оказаться трудоёмкой и непонятной, а фраза «напишите заглушку» часто может ввести в заблуждение. Это происходит потому что заглушка обычно не сводится просто к оператору RETURN, так как вызывающий модуль, как правило, ожидает от неё входных данных. В данных случаях заглушку оснащают фиксированными выходными данными, которые она возвращает каждый раз. Но иногда это может оказаться неприемлемым, поскольку вызывающий модуль может рассчитать, что результат вызова зависит от входных данных. По этой причине в особенных случаях заглушку следует сделать достаточно изощренной, и по сложности приближаясь к модулю, который она пытается моделировать.

б) В какой форме необходимо подготовить тестовые данные и как