Файл: Отладка и тестирование программ: основные подходы и ограничения ( Определение и принципы тестирования).pdf

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

Тестирование программ – это составляющая более крупного определения – отладка программ.

Тестирование программ является одной из составных частей более общего понятия - «отладка программ»^{^[1]}. Под отладкой понимается процесс, позволяющий получить программу, функционирующую с требующимися характеристиками в заданной области изменения входных данных.

Процесс отладки включает:

 - действия, которые направлены на цели выявить ошибки (т.е непосредственно тестирование);

-  диагностику и локализацию ошибок (т.е определение характера ошибок и их местонахождение);

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

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

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

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

Рассмотрим особенности тестирования программного средства^{^[2]}:

-  отсутствие эталона (программы), которому должна соответствовать тестируемая программа;

- высокая сложность программ и принципиальная невозможность исчерпывающего тестирования;

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

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

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

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

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

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

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

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

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

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

Рассмотрим два самых противоположных подхода к проектированию тестов.

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

Рис. 1. Взаимосвязь процессов проектирования и тестирования

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

Сторонник второго подхода использует стратегию "белого ящика", или стратегию тестирования, управляемую логикой программы, которая позволяет исследовать внутреннюю структуру программы. В этом случае тестировщик получает тестовые данные путем анализа только логики программы; стремится, чтобы каждая команда была выполнена хотя бы один раз. При достаточной квалификации добивается, чтобы каждая команда условного перехода выполнялась бы в каждом направлении хотя бы один раз. Цикл должен выполняться один раз, ни разу, максимальное число раз. Цель тестирования всех путей извне также недостижима. В программе из двух последовательных циклов внутри каждого из них включено ветвление на десять путей, имеется 10¹⁸ путей расчета. Причем выполнение всех путей расчета не гарантирует выполнения всех спецификаций. Для справки: возраст Вселенной 10¹⁷с.

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

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

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

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

1.3 Сравнение методов тестирования

Рассмотрим с позиций надежности программного обеспечении стратегии тестирования и сравним их по семи критериям (табл.1 ).

Таблица 1

Качественная оценка подхода к сборке

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