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

ВУЗ: Не указан

Категория: Курсовая работа

Дисциплина: Не указана

Добавлен: 28.03.2023

Просмотров: 115

Скачиваний: 2

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

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

2.2.2 Анализ граничных значений

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

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

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

  1. Можно построить тесты для границ области и тесты с неправильными входными данными для ситуаций незначительного выхода за границы области.
  2. Построить тесты для минимального и максимального значений условий и тесты, большие и меньшие этих значений.
  3. Использовать первое правило для каждого входного условия.
  4. Также можно использовать второе правило для каждого выходного условия.
  5. Если же вход или выход программы есть упорядоченное множество, то сосредоточить внимание на первом и последнем элементах этого множества.
  6. Можно также попробовать свои силы в поиске других граничных условий.

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


2.2.3 Применение функциональных диаграмм

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

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

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

  1. Спецификация разбивается на участки. Конечно, это связано с тем, что функциональные диаграммы становятся слишком громоздкими при применении данного метода к большим спецификациям.
  2. В спецификации определяются причины и следствия. Причина есть отдельное входное условие или класс эквивалентности входных условий. Следствие есть выходное условие или преобразование системы (остаточное действие, где входное условие оказывает на состояние программы или системы).
  3. Анализируется семантическое содержание спецификации, которая преобразуется в булевский граф, связывающий причины и следствия.
  4. Диаграмма снабжается примечаниями, задающими ограничения и описывающими комбинации причин и следствий, которые являются невозможными из-за синтаксических или внешних ограничений.
  5. Путем методического прослеживания состояний условий диаграммы она преобразуется в таблицу решений с ограниченными входами
  6. Столбцы таблица решений преобразуются в тесты.

Базовые символы для записи функциональных диаграмм показаны на рисунке. Где каждый узел диаграммы может находиться в двух состояниях – 0 или 1 ; где 0 обозначает состояние “отсутствует”, а 1 – “присутствует”. Функция тождество устанавливает, что если значение a есть 1, то и значение b есть 1; в противном случае значение b есть 0. Функция не устанавливает, что если a есть 1, то b есть 0; в противном случае b есть 1. Функция или устанавливает, что если a, или b, или c есть 1, то d есть 1; в противном случае d есть 0. Функция и устанавливает, что если и a, и b, есть 1, то и c есть 1; в противном случае c есть 0. Последнее две функции разрешают иметь любое число входов.


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

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

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

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

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

Предположение об ошибке

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

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


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

  1. Сортируемый список пуст.
  2. Сортируемый список содержит одно и то же значение.
  3. Все записи в сортируемом списке имеют одно.
  4. Список уже отсортирован.

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

  1. Существует только один вход в таблицу, в которой ведется поиск.
  2. Размер таблица есть степень двух.
  3. Размер таблица должен быть меньше или больше степени двух.

2.3 Метод Сандвича

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

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

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


2.4 Методы отладки программного обеспечения

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

  1. Ручное тестирование.
  2. Прологи.
  3. Снижения
  4. Обратная трассировка.

2.4.1 Метод ручного тестирования.

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

2.4.2 Метод пролога

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

2.4.3 Метод снижения

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

2.4.4 Метод обратной трассировки

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

Заключение

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