17.Тестирование и отладка

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

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

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

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

1. испол-ние справочников;

2. вычисление вручную;

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

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

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

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

Стратегии тест-ния

Существуют два основных крайних подхода к выработке страте­гии тест-ния программного продукта.

1.Тест-ние проги как черного ящика, при котором прога рассматривается как Объект, внутренняя структура кото­рого неизвестна.

2.Тест-ние проги как прозрачного (белого) ящика подразумевает знание исходного кода проги и полный доступ к нему.

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

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

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

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

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

Разновидности тест-ния:

1.детерминированное — контролируются каждая комбинация исходных эталонных данных и соответствующая ей комби­нация результатов функционирования программ. На прак­тике полное детерминированное тест-ние обычно нере­ализуемо;

2. стохастическое— исходные тестовые данные берутся случай­ным образом, как правило, с испол-нием статистическо­го распределения;

3. ручное — проводится без исполнения тестируемой проги на ПКе.

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

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

Принципы тест-ния

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

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

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

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

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

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

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

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

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