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

Введение

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

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

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

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

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

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

Отладка = Тестирование + Поиск ошибок + Редактирование

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

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

C учетом поставленной цели будут решены следующие задачи:

- рассмотрено понятие и принципы тестирования;

- проанализирована стратегия и методы тестирования;

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

Курсовая работа состоит из введения, двух глав, заключения и библиографии.

Глава 1 Тестирование программ

1.1 Определение и принципы тестирования

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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