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

Основные определения. ØТестирование (testing) — процесс выполнения программы (или части программы) с намерением (или целью) найти ошибки. ØДоказательство (proof) — попытка найти ошибки в программе безотносительно к внешней для программы среде. Большинство методов доказательства предполагает формулировку утверждений о поведении программы и затем вывод и доказательство математических теорем о правильности программы. Доказательства могут рассматриваться как форма тестирования, хотя они и не предполагают прямого выполнения программы.

Основные определения. ØКонтроль (verification) — попытка найти ошибки, выполняя программу в тестовой, или моделируемой, среде. ØИспытание (validation) — попытка найти ошибки, выполняя программу в заданной реальной среде. ØАттестация (certification) — авторитетное подтверждение правильности программы. При тестировании с целью аттестации выполняется сравнение с некоторым заранее определенным стандартом.

Основные определения. Отладка (debugging) не является разновидностью тестирования. Тестирование — деятельность, направленная на обнаружение ошибок; отладка направлена на установление точной природы известной ошибки, а затем — на исправление этой ошибки. Эти два вида деятельности связаны — результаты тестирования являются исходными данными для отладки.

Основные определения. ØТестирование модуля, или автономное тестирование (module testing, unit testing), — контроль отдельного программного модуля, обычно в изолированной среде (т. е. изолированно от всех остальных модулей). Тестирование модуля иногда включает также математическое доказательство.

Основные определения. ØТестирование сопряжений (integration testing) — контроль сопряжений между частями системы (модулями, компонентами, подсистемами). ØТестирование внешних функций (external function testing) — контроль внешнего поведения системы, определенного внешними спецификациями. ØКомплексное тестирование (system testing) — контроль и/или испытание системы по отношению к исходным целям. Комплексное тестирование является процессом контроля, если оно выполняется в моделируемой среде, и процессом испытания, если выполняется в среде реальной, жизненной.

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

ВИДЫ ТЕСТИРОВАНИЯ Статическое тестирование предполагает поиск ошибок путем просмотра текста программы и выполнения ее «вручную» , т. е. «в уме» или на бумаге. Применяется в процессе разработки алгоритма.

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

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

СТРАТЕГИИ ТЕСТИРОВАНИЯ Под стратегией тестирования понимают совокупность принципов, положенных в основу построения системы тестов.

Стратегии Способы построения тестов(Стратегии) «Черного ящика» «Белого ящика»

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

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

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

Пример. Пусть требуется разработать тесты для проверки следующих функций, реализуемых программой работы с базой данных: ввод с клавиатуры (1) сохранение в файле (2) Выбранная функция задается пользователем номером, указанным в скобках. Пусть структура записи в базе имеет следующий вид: фамилия (от 2 до 20 символов) возраст (от 0 до 100) И пусть число записей в базе не должно быть больше 2000. Примечание. В базе данных не может быть двух одинаковых записей.

Этапы разработки тестов: первый – выделение классов эквивалентности (не только для допустимых, но и для недопустимых входных данных) ; второй - разработка по одному тесту для каждого класса.

Входные условия Операция Фамилия Возраст Наличие в базе определенной фамилии Номер введенной записи Неправильные Правильные классы Классы для кода операции Число: 1 или 2 Любое другое число (соответствуют (несуществующая операция) номерам существующих операций с базой) Классы для операции «Ввод» 2 <= длина <= 20 длина < 2 длина > 20 0. . 100 значение < 0 значение > 100 да / нет 1, > 1 ( до 2000) Классы для операции «Сохранение в файле» Наличие записей да / нет в базе Наличие в базе да / нет одноименного файла Наличие свободного места да / нет – – –

Тесты: • проверка реакции программы на ввод номера операции требуется 2 теста, по одному для правильного и неправильного классов. • проверка операции «Ввод» - требуется 10 тестов: • по три теста (для правильного и неправильных классов) при вводе фамилии и возраста; • по два теста для правильных классов для двух остальных проверяемых ситуаций (для случая «да» и «нет» , и для случая « 1» и «>1» ); • проверка операции «Сохранение в файле» требуется 6 тестов.

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

Методы стратегии «белого ящика» В основу построения тестов положено знание структуры программы. Именно знание правил интерпретации структурных элементов «альтернативный выбор» и «цикл» определяет количество тестов, необходимых и достаточных для полноценной проверки программы. В рамках данной стратегии применяются следующие методы: • покрытие операторов ( «все операторы» ); • покрытие решений ( «все пути» ); • комбинированное покрытие условий.

Пример. Разработать тесты для проверки следующего фрагмента: if (a>1 && b == 0) x = x / a; if (a == 2 && x > 1) x++;

Метод покрытия операторов. Число тестов выбирается таким, чтобы каждый оператор был выполнен, по меньшей мере, один раз. В нашем случае достаточно одного теста: Тест 1. {a=2, b=0, x=6} Эталон: x=4

Метод покрытия решений. Число тестов выбирается таким, чтобы каждое решение было выполнено, по меньшей мере, один раз. Здесь под решением понимается конкретное значение условия в альтернативной или циклической структуре вне зависимости от сложности условия. В нашем случае требуется два теста, и их можно реализовать одним из двух вариантов:

if (a>1 && b == 0) x = x / a; if (a == 2 && x > 1) x++; Вариант 1. Первый тест – для случая, когда оба решения: первое –(a>1&& b==0) и второе -(a==2 && x>1) , не выполняются, а второй – когда оба они выполняются; Вариант 2. Первый – для случая, когда первое решение (a>1 && b==0) выполняется, а второе (a==2 && x>1) не выполняется, а во втором случае – наоборот, не выполняется первое и выполняется второе решение. Тесты для первого варианта. Тест 1. {a=2, b=0, x=3} Эталон: x=2, 5 Оба решения выполняются. Тест 2. {a=3, b=1, x=1} Эталон: x=1 Оба решения не выполняются.

Метод комбинированного покрытия условий. Все возможные комбинации условий в каждом решении должны быть выполнены хотя бы один раз. анализ таблицы показывает, что можно ограничиться четырьмя тестами: Тест 1. {a=2, b=0, x=4} Эталон: x=3 Тест 2. {a=2, b=1, x=4} Эталон: x=5 Тест 3. {a=1, b=0, x=2} Эталон: x=2 Тест 4. {a=1, b=1, x=1} Эталон: x=1 первый оператор if второй оператор if 1) a>1 и b=0 5) a=2 и x>1 2) a>1 и b≠ 0 6) a=2 и x<=1 3) a<=1 и b=0 7) a≠ 2 и x>1 4) a<=1 и b≠ 0 8) a≠ 2 и x<=1

Аксиомы (принципы) тестирования Ø 1 аксиома: Хорош тот тест, для которого высока вероятность обнаружить ошибку. Эта аксиома является фундаментальным принципом тестирования. Поскольку невозможно показать, что программа не имеет ошибок и, значит, все такие попытки бесплодны, процесс тестирования должен представлять собой попытки обнаружить в программе прежде не найденные ошибки.

Аксиомы (принципы) тестирования Ø 2 аксиома: Одна из самых сложных проблем при тестировании — решить, когда нужно его закончить. Как уже говорилось, исчерпывающее тестирование (т. е. испытание всех входных значений) невозможно. Таким образом, при тестировании мы сталкиваемся с экономической проблемой: как выбрать конечное число тестов, которое дает максимальную отдачу (вероятность обнаружения ошибок) для данных затрат.

Аксиомы (принципы) тестирования Ø 3 аксиома: Не нужно тестировать свою собственную программу. Ни один программист не должен пытаться тестировать свою собственную программу. Это относится ко всем формам тестирования — как к тестированию системы, так и к тестированию внешних функций и даже отдельных модулей. Тестирование всегда должна выполнять внешняя группа, которая в некотором смысле стоит особняком от программиста и проекта.

Аксиомы (принципы) тестирования Ø 4 аксиома: Необходимая часть всякого теста — описание ожидаемых выходных данных или результатов. Одна из самых распространенных ошибок при тестировании состоит в том, что результаты каждого теста не прогнозируются до его выполнения. Ожидаемые результаты нужно определять заранее, чтобы не возникла ситуация, когда «глаз видит то, что хочет увидеть» . Чтобы совсем исключить такую возможность, лучше разрабатывать самопроверяющиеся тесты либо пользоваться инструментами тестирования, способными автоматически сверять ожидаемые и фактические результаты.

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

Аксиомы (принципы) тестирования Ø 6 аксиома: Готовьте тесты как для правильных, так и для неправильных входных данных. Многие программисты ориентируются в своих тестах на «разумные» условия на входе, забывая о последствиях появления непредусмотренных или ошибочных входных данных. Однако многие ошибки, которые потом неожиданно обнаруживаются в работающих программах, проявляются вследствие никак не предусмотренных действий пользователя программы.

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

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