Тестирование может показать лишь наличие ошибок

Тестирование может показать лишь наличие ошибок, но не их отсутствие.

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

Для выявления ошибок в программах ЖЦ разработки ПО предусматривает процесс тестирования, который является достаточно трудоемким и занимает больше времени, чем кодирование. (Г. Майерс дает оценку 1/3 для тестирования, при том, что кодирование занимает примерно 1/6 [6].) Тестируемое ПО обычно называют SUT — Software Under Test. Цель тестирования — не убедиться в безошибочной работоспособности программы, а наоборот — найти ошибки. Поэтому в первую очередь возникает вопрос: а что есть ошибка в программе?

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

При рассмотрении вопросов анализа программного кода порой удобнее применять ранее рассмотренную в разделе 1 модель жизненного цикла. Ее часто называют V-образной из-за расположения блоков на рисунке (рис. 7.1).

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

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

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

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

7.1. Тестовый план

Тестирование обычно проводится снизу вверх, т.е. сначала тести-руются отдельные функции, затем целые модули и далее проводится комплексное тестирование всей программы или комплекса программ. Для проведения тестирования разрабатывается тест-план (test-plan) — совокупность тестовых наборов {примеров} (test-case). В каждом тестовом примере производится выполнение тестируемого программного элемента SUT при заданных Input — условиях и входных данных и проверяются все Output — выходные данные на соответствия заданным значениям.

Тестовый пример (набор) должен включать в себя как минимум:

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

Кроме указанных данных удобно, если каждый тестовый пример имеет дополнительно:

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

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

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

7.2. Проблема полноты тестирования

Основная проблема тестирования ПО заключается в том, что проверить программу при всех возможных условиях функционирования в большинстве случаев невозможно. Это происходит либо в силу ограниченности ресурсов, либо в силу бесконечного количества возможных условий. Например, если рассмотреть функцию умножения двух рациональных чисел, варьируемых от -1000 до +1000, то в интервале от минимального возможного числа до максимального содержится бесконечное количество чисел. Т.е. все возможные значения входов проверить нельзя. Если же учесть, что машина оперирует невсеми этими числами, а различает только 10 знаков после запятой (т.е. множество чисел в интервале дискретно, минимальное отличие двух чисел 0,0000000001), то для проверки всех комбинаций из заданного диапазона понадобится степени тестовых примера, что является достаточно большим числом для такой простой функции. Если проверяются не все возможные комбинации входных условий, то тестирование является неполным.

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

Этот подход называют методом трех точек. В нашем примере для функции умножения двух чисел можно рассмотреть области [-1000; 0] и [0; +1000]. Деление образовано путем выявления трех особых точек (-1000, 0 и +1000). Такие точки называют критическими точками, в них тестируемая функция может менять свое поведение или потенциально вести себя особо. Т.е. для тестирования функции методом трех точек достаточно проверить случаев (для каждого входа это точки -1000; 0; 1000 и, например, -500 и 500), что значительно меньше полного перебора. Конечно, при таком подходе возможно, что какие-то ошибки останутся, но вероятность этого будет невелика и зависит от выбора критических точек.

Функции, выполняющие различные сравнения, могут неверно их проводить, поэтому имеет смысл проверять их работу в непосредственной близости к критическим точкам. Для этого берутся значения, отстоящие от критических точек на величину дискретизации значений. Т.е. для примера функции умножения двух чисел, кроме значений метода трех точек, стоит рассмотреть значения -999,9999999999; -0,0000000001; 0,0000000001 и 999,9999999999. Этот подход называют методом пяти точек.

Иная сторона тестирования связана с типизацией переменных, при помощи которых задаются входные данные. Если для входных значений функции используются переменные типа float, а максимальное значение входа ограничено как +1000, то теоретически можно передать на вход и число +1001. Зачастую реакция функции на такое число не будет даже описана. Однако существуют приложения, чье поведение критично даже при передаче им входных значений, выходящих за пределы допустимых (например, авиационные программы, программы управления ядерными реакторами). В этом случае подразумевается, что программа должна вести себя корректно, т.е. не «зависнуть», не «повесить» систему, хотя выходное значение предсказать нельзя. Тестовые примеры, проверяющие поведение программы, в таких случаях, называются тестами на устойчивость (robustness). Если при тестировании методом пяти точек проверять еще и значения, выходящие за пределы допустимых диапазонов, то такой метод будет называться методом семи точек. В примере функции умножения двух чисел кроме значений -1000; -500; -999,9999999999; -0,0000000001; 0,0; 0,0000000001; 500,0; 999,9999999999; 1000 для каждого входа следует взять, например, еще значения -1001 и 100,0000000001.

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

Урок «Принципы тестирования и отладки программ»

Для студентов СПО специальности 09.02.03
«Программирование в компьютерных системах», изучающих дисциплину «Основы
алгоритмизации и программирования».

ПРИНЦИПЫ ТЕСТИРОВАНИЯ

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

Для чего нужно
тестировать программы?  Цель тестирования — найти в программе ошибки.  Но, как
справедливо указывал известный теоретик программирования Э. Дейкстра,
тестирование может показать лишь наличие ошибок, но не их отсутствие.

Цель тестирующего
— «сломать» программу, доказать ее ошибочность, найти ситуацию, в
которой результаты неверны.  В задачу тестировщика входит предложить программе самые
неожиданные входные данные. И если программа выдержала подобный натиск, можно
надеяться, что она действительно написана правильно.

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

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

—              
Тестирование никогда не
доказывает отсутствия ошибок.
Если Вы тщательно протестировали программу и обнаружили тысячи ошибок, значит
ли это, что Вы нашли все ошибки или в программе все еще остались тысячи других
ошибок? Отсутствие ошибок может указывать как на безупречность программы, так и
на неэффективность или неполноту тестов.

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

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

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

Тестирование (англ. test —
испытание) — это испытание, проверка правильности работы программы в целом,
либо её составных частей.

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

Особенности отладки
и тестирования:

—       
при отладке происходит
локализация и устранение синтаксических ошибок и явных ошибок кодирования;

—       
в процессе же тестирования
проверяется работоспособность программы, не содержащей явных ошибок.

Тестирование
устанавливает факт наличия ошибок, а отладка выясняет ее причину.

Рекомендуемый
подход к тестированию, выполняемому разработчиками, позволяющий находить
максимальное число дефектов всех типов при минимуме усилий:

—       
Для проведения
тестирования должна быть спроектирована система тестов.

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

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

—       
Тестируйте программу на
предмет реализации каждого значимого аспекта проектирования.

—       
Систематично выполняйте
тестирование и ищите дефекты как можно раньше, потому, что в этом случае
исправление дефектов будет дешевле.

—       
Наряду с «чистыми
тестами», разрабатывайте «грязные тесты». Разработчики склонны тестировать код
на предмет того, работает ли он (чистые тесты), а не пытаться нарушить его
работу всевозможными способами (грязные тесты). В организациях со зрелым
процессом тестирования на каждый чистый тест обычно приходятся пять грязных.

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

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

Все методы
тестирования можно разделить на две группы:

—       
 «тестирование методом
черного ящика»;

—       
 «тестирование методом
белого (прозрачного) ящика».

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

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

Оба вида имеют
свои плюсы и минусы.

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

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

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

Общие принципы
построения тестов:

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

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

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

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

—       
Количество тестов не
должно быть слишком большим. Постарайтесь спроектировать набор так, чтобы в
одном тесте проверить сразу несколько ситуаций.

Процесс проведения
тестирования можно разделить на три этапа:

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

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

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

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

—       
что произойдет, если
программе, не рассчитанной на обработку отрицательных и нулевых значений
переменных, в результате какой-либо ошибки придется иметь дело как раз с такими
данными?

—       
как будет вести себя
программа, работающая с массивами, если количество их элементов превысит
величину, указанную в объявлении массива?

—       
что произойдет, если числа
будут слишком малыми или слишком большими?

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

Пример 1.

В таблице 1 представлена система
тестов для задачи нахождения корней квадратного уравнения ax² + bx +
c = 0

Таблица 1. Система тестов

Номер теста	Проверяемый случай	Исходные данные (коэффициенты a,b,c)	Результаты
1	d >0	1	1	-2	x1 = 1, x2 = — 2
2	d=0	1	2	1	Корни равны: x1 = — 1, x2 = — 1
3	d < 0	2	1	2	Действительных корней нет
4	a=0, b=0, c=0	0	0	0	Все коэффициенты равны нулю, х — любое число.
5	a=0, b=0, c<>0	0	0	2	Неверное тождество, неверные коэффициенты
6	a=0, b<>0	0	2	1	Линейное уравнение. Один корень: x = — 0,5
7	a <> 0, b <> 0, с = 0	2	1	0	x1 = 0, x2 = — 0,5

СПОСОБЫ ОТЛАДКИ ПРОГРАММЫ

Как было сказано
ранее, в программе во время ее работы могут возникать исключения (ошибки).  Исключения
— это нарушения в работе программы. Процесс поиска и устранения ошибок и есть
процесс отладки программы.

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

Программа-отладчик обычно обеспечивает следующие
возможности:

—       
пошаговое исполнение
программы с остановкой после каждой команды (оператора) —  трассировка
программы. Существуют два режима трассировки: без захода в процедуру
(Debug/Step Over) и с заходом в процедуру (Debug/Step Into). В последнем случае
осуществляется трассировка всей программы, в том числе всех процедур;

—       
установку в программе «контрольных
точек» (Breakpoint), т.е. точек останова, в которых программа временно
прекращает свое выполнение, так что можно оценить промежуточные результаты;

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

Ошибки могут быть допущены на всех
этапах решения задачи — от ее постановки до оформления. Разновидности ошибок
и соответствующие примеры приведены в таблице 2.

Таблица 2. Виды ошибок

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

Пример 2.

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

1. Пользовательская функция
MinVal()

using
System;

public
static int MinVal(  int[] nums)

{ int m;

m =
nums[0];

for( int
i=1;i < nums.Length; i++)

if
(nums[i] < m) m = nums[i];

return m;
}

2. Для тестирования метода выбрана
следующая система тестов (таблица 3)

1-2 тест – проверка в нормальных условиях

3 тест — проверка в граничных условиях

4-5 тест – проверка в экстремальных условиях

Таблица 3. Система тестов

Номер теста	Проверяемый случай	Исходные данные (массив)	Результаты
1	Массив значений	45, 67, 34, 9, 112, 8	8
2	Пять значений	8, 23, 3, 14, 25	3
3	Одно значение	0	0
4	Отсутствие аргументов		Ошибка времени исполнения
5	Недопустимый тип значения	-3.5	Ошибка времени исполнения

3. Листинг главного метода Main(), тестирующего
работу функции MinVal()

static
void Main()

{
//Вызвать метод для массива из 6  целых значений

int[]
arg = { 45, 67, 34, 9, 112, 8 };

min
= MinVal(arg);

Console.WriteLine(«Наименьшее
значение равно » + min);

//Вызвать
метод для произвольного массива целых значений

int n = Convert.ToInt32(Console.ReadLine());

int[] a =
new int[n];

Random r
= new Random();

for (int
i = 0; i < a.Length; i++)

  a[i] =
r.Next(-10, 10);

min =
MinVal(a);

Console.WriteLine(«Наименьшее
значение равно » + min);

Console.ReadKey();

}

4. Результаты тестирования

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

Наименьшее значение равно 8

Наименьшее значение равно 3

Наименьшее значение равно 0

Ошибка

Ошибка

4 и 5 тесты вызывают остановку
программы на этапе выполнения с системными ошибками: отсутствие входных данных
или невозможность их правильного конвертирования].

Что предпринять в этом случае?

5. Усовершенствование программы

Предусмотрим обработку
исключительных ситуаций, возникающих при неверном вводе исходных данных.
Обработку будем осуществлять с помощью оператора Try – Catch, который в случае
возникновения исключительной ситуации перехватывает управление и выдает
сообщение «Неверно введены данные».

static
void Main()

{
 try

{
//Вызвать метод для массива из 6  целых значений

 int[] arg
= { 45, 67, 34, 9, 112, 8 };

min =
MinVal(arg);

Console.WriteLine(«Наименьшее
значение равно » + min);

//Вызвать
метод для произвольного массива целых значений

int n = Convert.ToInt32(Console.ReadLine());

int[] a =
new int[n];

Random r
= new Random();

for (int
i = 0; i < a.Length; i++)

  a[i] =
r.Next(-10, 10);

min =
MinVal(a);

Console.WriteLine(«Наименьшее
значение равно » + min);

Console.ReadKey();

}

catch
(Exception exc)

{
//обработка неверного ввода данных

  
MessageBox.Show(«Неверно введены данные»);

}

6. Результаты тестирования.

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

Наименьшее значение равно 8

Наименьшее значение равно 3

Наименьшее значение равно 0

Ошибка

Ошибка

Контрольные вопросы для
самоанализа материала.

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

—           
тестирование

—           
отладка

—           
правила тестирования

—           
принципы составления
тестов

—           
методы тестирования

—           
способы отладки

—           
виды ошибок

2.             
Сравните процессы
тестирования и отладки. Наиболее принципиальные позиции зафиксируйте в таблице
4.

Таблица 4. Сравнение процессов тестирования и отладки

Основания для сравнения	Тестирование	Отладка
Назначение процесса
Инструменты выполнения процесса
Методы (способы) выполнения процесса
Ошибки, выявляемые в процессе

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

—         
Перечислите, какие тесты
относятся к проверке работы программы в нормальных условиях;

—         
Перечислите, какие тесты
относятся к проверке работы программы в граничных условиях;

—         
Перечислите, какие тесты
относятся к проверке работы программы в экстремальных условиях;

—         
Дополните систему
недостающими тестами, проверяющими ошибки ввода-вывода данных, чтобы сделать тестирование
более эффективным.

Таблица 5. Система тестов

Номер теста	Проверяемый случай	Исходные данные (массив)	Результаты
1	Массив из нескольких целых чисел	8, 23, 3, 14, 25	1
2	Массив из нескольких повторяющихся целых чисел	8, 23, -23, 14, 23	2
3	Массив из одинаковых целых чисел	8, 8,8,8	4
4	Одно значение	8	1
5	Одно значение (нулевое)	0	1

1. Этапы решения задач
   на ЭВМ.

2. Пример оформления
   решения задачи на ЭВМ.

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

1. постановка задачи;

2. формирование
   математической модели задачи;

3. выбор и обоснование
   метода решения;

4. алгоритмизация
   вычислительного процесса;

5. составление
   программы;

6. отладка и тестирование
   программы;

7. решение задачи на
   ЭВМ и анализ результатов.

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

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

• четкая
  формулировка цели с указанием вида и
  характеристик конечных результатов;

• представление
  значений и размерностей исходных
  данных;

• определение
  всех возможных вариантов решения,
  условий выбора каждого;

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

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

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

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

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

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

Полученная математическая
модель должна отвечать следующим
требованиям:

• вначале
  составляется модель исходных данных,
  затем — расчетные зависимости;

• в модели
  исходных данных не изменяются размерности
  данных и не используются никакие
  математические операции;

• обозначение
  всех входящих в зависимости величин
  именами, определяющими их суть;

• указание
  размерностей всех используемых величин
  для контроля и дальнейшей модернизации
  решения;

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

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

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

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

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

3. Некоторые
   простые приемы позволяют повысить
   эффективность программы. К таким
   приемам относится:

• использование
  операции умножения вместо возведения
  в степень (
  );

• если некоторое
  арифметическое выражение встречается
  в вычислениях несколько раз, то его
  следует вычислить заранее и хранить в
  памяти ЭВМ, а по мере необходимости
  использовать;

• при
  организации циклов в качестве границ
  индексов использовать переменные, а
  не выражения, которые вычислялись бы
  при каждом прохождении цикла;

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

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

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

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

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

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

Тестирование — это испытание, проверка
правильности работы программы в целом,
либо её составных частей.

Отладка и тестирование (англ. test —
испытание) — это два четко различимых и
непохожих друг на друга этапа:

• при отладке
  происходит локализация и устранение
  синтаксических ошибок и явных ошибок
  кодирования;

• в процессе
  же тестирования проверяется
  работоспособность программы, не
  содержащей явных ошибок.

Тестирование устанавливает факт наличия
ошибок, а отладка выясняет ее причину.

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

• пошаговое
  исполнение программы с остановкой
  после каждой команды (оператора);

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

• установку
  в программе «контрольных точек»
  и др.

При отладке программ важно помнить
следующее:

• в начале
  процесса отладки надо использовать
  простые тестовые данные;

• возникающие
  затруднения следует четко разделять
  и устранять строго поочередно;

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

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

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

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

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

• должна
  быть испытана каждая ветвь алгоритма;

• очередной
  тестовый прогон должен контролировать
  нечто такое, что не было проверено на
  предыдущих прогонах;

• первый
  тест должен быть максимально прост,
  чтобы проверить, работает ли программа
  вообще;

• арифметические
  операции в тестах должны предельно
  упрощаться для уменьшения объема
  вычислений;

• количества
  элементов последовательностей, точность
  для итерационных вычислений, количество
  проходов цикла в тестовых примерах
  должны задаваться из соображений
  сокращения объема вычислений;

• тестирование
  должно быть целенаправленным,
  систематизированным;

• усложнение
  тестовых данных должно происходить
  постепенно.

Процесс тестирования можно разделить
на три этапа.

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

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

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

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

Разработанная программа
длительного использования устанавливается
на ЭВМ. К программе прилагается
документация, включая инструкцию для
пользователя.

Рассмотрим
предпрограммную подготовку типовых
вычислительных задач на конкретных
примерах.

Линейные вычислительные процессы

Рассмотрим предпрограммную подготовку
задачи линейного вычислительного
процесса на конкретном
примере.

Этап 1. Постановка
задачи

Вклад размером 500
рублей хранился в банке 21 день под 15%
годовых.
Какую сумму
и какой доход получит клиент банка?

Анализ задачи показал необходимость
ее уточнения:

1. примем длительность
   года 360 дней, что соответствует
   коммерческим процентам, в отличие
   от точных процентов;

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

Этап 2. Математическая модель задачи

Исходные данные:

первоначальная сумма вклада	Р = 500 р.
годовая процентная ставка	l = 15% в год
Число дней хранения вклада	I = 21 день
Число дней в году	К = 360 день/год

Расчетные
зависимости:

Срок хранения вклада в годах	[год=Дн/(дн/год)]
Процент доходов вклада	р = р — год [ % ]
Сумма при закрытии вклада	, р [р — р ]

Этап 3. Выбор метода решения

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

Этап 4. Составление алгоритма решения

На основании полученной математической
модели и выбранного метода
решения составим графическую схему
алгоритма (рис. 17).

Рис. 17. Блок-схема
алгоритма решения задачи

Составим словесное описание

1. начала алгоритма

2. Ввод данных P, I,
t, K

3. Действие

4.

5.

6. Вывод I,
S

7. Конец алгоритма

Этап 5, 6, 7 —
самостоятельно

Контрольные вопросы

1. Каким
   требованиям должен отвечать этап
   «постановка задачи»?

2. Каким
   образом происходит формирование
   математической модели задачи?

3. Обоснуйте,
   как происходит выбор метода решения
   поставленной задачи?

4. Каким
   требованиям отвечает этап алгоритмизация
   вычислительного процесса?

5. Что важно
   помнить при составлении и
   отладке программы?

6. Какие нужно подобрать
   виды тестовых примеров?

7. Каким
   образом осуществляется анализ
   результатов решения задачи?

8. Рассмотрите
   предпрограммную подготовку ветвящихся
   и циклических
   вычислительных задач на конкретных
   примерах.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

ТЕСТИРОВАНИЕ И ОТЛАДКА

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Процесс тестирования более эффективен, если проводится не автором программы. По своей сути тестирование — это процесс деструктивный (разрушительный). Именно этим и объясняется, поче­му многие считают его трудным. Особенно трудным и малоэффек­тивным он является для самого автора программы, так как после выполнения конструктивной части при проектировании и написания программы, ему трудно перестроиться на деструктивный образ мышления и, создав программу, тут же приступить к пристрастному выявлению в ней ошибок. Поэтому для проведения тестирования создаются специальные группы тестирования. Это не означает, что программист не может тестировать свою программу. Речь идет о повышении эффективности тестирования.

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

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

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

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

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

Основные определения

Тестирование (testing) — процесс выполнения программы или ее части с целью найти ошибки.

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

Контроль (verification) — попытка найти ошибки, выполняя программу в тестовой, или моделируемой, среде.

Испытание (validation) — попытка найти ошибки, выполняя программу в заданной реальной среде.

Аттестация (certification) — авторитетное подтверждение правильности программы. При тестировании с целью аттестации выполняется сравнение с некоторым заранее определенным стандартом.

Отладка (debugging) не является разновидностью тестирования. Хотя слова «отладка» и «тестирование» часто используются как синонимы, но под ними подразумеваются разные виды деятельности.

Тестирование — это деятельность, направленная на обнаружение ошибок.

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

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

Тестирование модуля иногда включает математическое доказательство.

Тестирование сопряжений (integration testing) — контроль сопряжений между частями системы (модулями, компонентами, подсистемами).

Тестирование внешних функций (external function testing) — контроль внешнего поведения, определенного внешними спецификациями.

Комплексное тестирование (system testing) — контроль и/или испытание системы по отношению к исходным целям.

Комплексное тестирование является процессом контроля, если оно выполняется в моделируемой среде, и процессом испытания, если выполняется в реальной среде.

Тестирование приемлемости (acceptance testing) — проверка соответствия программы требованиям пользователя.

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

Отношения между этими типами тестов и процессами проектирования показаны на рис. 15.

Другие вопросы тестирования, которые следует рассмотреть и решить, включают:

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

Позитивистская спецификация

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

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

Невозможность полной спецификации

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

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

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

Неформальный вход

Клиенты обычно описывают свои требования с помощью правил : Если A, то X. Но если B, то Y. С одной стороны, такой метод кажется интуитивно понятным, с другой стороны, он может быть хорошо формализован с использованием производственных правил , теории множеств и логики предикатов . На практике ни клиенты, ни трейдеры не формализуют свои назначения, результирующие требования затем предполагают невысказанное поведение или, что еще хуже, они не определяют выходы для некоторых возможных входов или не определяют все входные данные, хотя они возможны.

Практическим следствием могут быть случаи, когда:

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

Неустановленный результат

Это случай, когда FS определяет поведение только для части всех теоретически возможных ситуаций (декартова, поддерево ). Таким образом, в приведенном ниже примере явно указано требование для ситуаций A и D. Однако оно не указывает напрямую другие возможности. В этом случае анализ (тестирование документации) может привести к нескольким результатам.

Пример показывает, что из другого контекста FS был сделан вывод, что опция E + F исключена из-за других контекстов. Вероятно, это было также причиной, по которой Ф.С. не осмелился прямо упомянуть этот случай. Поскольку это состояние не может быть достигнуто, а результат наблюдается, этот случай, таким образом, выпадает из тестирования.

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

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

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

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

1. Методы стратегии ‘белого ящика’

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

1.1. Метод покрытия операторов

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

Пример:

Рисунок 1.1 Рисунок 1.2

В этой программе можно выполнить каждый оператор, записав один единственный тест, который реализовал бы путь ace. Т.е., если бы на входе было: А=2, В=0, Х=3, каждый оператор выполнился бы один раз. Но этот критерий на самом деле хуже, чем он кажется на первый взгляд. Пусть в первом условии вместо “and”®“or” и во втором, вместо “x>1”®“x<1” (блок-схема правильной программы приведена на рисунке 1.1, а неправильной — на рисунке 2.2). Результаты тестирования приведены в таблице 1.1. Обратите внимание: ожидаемый результат определяется по алгоритму на рисунке 1.1, а фактический — по алгоритму рисунка 1.2, поскольку определяется чувствительность метода тестирования к ошибкам программирования. Как видно из этой таблицы, ни одна из внесенных в алгоритм ошибок не будет обнаружена.

Таблица 1.1 — Результат тестирования методом покрытия операторов

Тест	Ожидаемый результат	Фактический результат	Результат тестирования
A=2, B=0, X=3	X=2,5	X=2,5	неуспешно

1.2. Метод покрытия решений (покрытия переходов)

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

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

Для программы приведенной на рисунке 1.2 покрытие решений может быть выполнено двумя тестами, покрывающими пути {ace, abd}, либо {aсd,abe}. Пути {aсd,abe} покроим, выбрав следующие исходные данные: {A=3, B=0, X=3} и {A=2, B=1, X=1} (результаты тестирования — в таблице 1.2).

Таблица 1.2 — Результат тестирования методом покрытия решений

Тест	Ожидаемый результат	Фактический результат	Результат тестирования
A=3, B=0, X=3	X=1	X=1	неуспешно
А=2, В=1, Х=1	Х=2	Х=1,5	успешно

1.3 Метод покрытия условий

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

В предыдущем примере имеем четыре условия: {A>1, B=0}, {A=2, X>1}. Следовательно, требуется достаточное число тестов, такое, чтобы реализовать ситуации, где A>1, A£1, B=0 и B¹0 в точке а и A=2, A¹2, X>1 и X£1 в точке В. Тесты, удовлетворяющие критерию покрытия условий и соответствующие им пути:

а) A=2, B=0, X=4 ace

б) A=1, B=1, X=0 abd

Таблица 1.3 — Результаты тестирования методом покрытия условий

Тест	Ожидаемый результат	Фактический результат	Результат тестирования
A=2, B=0, X=4	X=3	X=3	неуспешно
A=1, B=1, X=0	X=0	X=1	успешно

1.4 Критерий решений (условий)

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

Два теста метода покрытия условий

а) A=2, B=0, X=4 ace

б) A=1, B=1, X=0 abd
отвечают и критерию покрытия решений/условий. Это является следствием того, что одни условия приведенных решений скрывают другие условия в этих решениях. Так, если условие А>1 будет ложным, транслятор может не проверять условия В=0, поскольку при любом результате условия В=0, результат решения ((А>1)&(В=0)) примет значение ложь. Следовательно, недостатком критерия покрытия решений/условий является невозможность его применения для выполнения всех результатов всех условий.

Другая реализация рассматриваемого примера приведена на рисунке 1.4. Многоусловные решения исходной программы разбиты на отдельные решения и переходы. Наиболее полное покрытие тестами в этом случае выполняется так, чтобы выполнялись все возможные результаты каждого простого решения. Для этого нужно покрыть пути HILP (тест А=2,В=0,Х=4), HIMKT (тест А=3, В=1, Х=0), HJKT (тест А=0, В=0, Х=0), HJKR (тест А=0, В=0, Х=2)..

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

Рисунок 1.4

1.5 Метод комбинаторного покрытия условий

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

По этому критерию в рассматриваемом примере должны быть покрыты тестами следующие восемь комбинаций:

а) A>1, B=0;

б)A>1, B¹0;

в) A£1, B=0;

г) А£1, B¹0;

д) A=2, X>1;

е) A=2, X£1;

ж) А¹2, X>1;

з) А¹2, X£1;

Для того чтобы протестировать эти комбинации, необязательно использовать все 8 тестов. Фактически они могут быть покрыты четырьмя тестами:

— A=2, B=0, X=4 {покрывает а, д};

— A=2, B=1, X=1 {покрывает б, е};

— A=0,5, B=0, X=2 {покрывает в, ж};

— A=1, B=0, X=1 {покрывает г, з}.

Таблица 2.4 — Результаты тестирования методом комбинаторного покрытия условий

Тест	Ожидаемый результат	Фактический результат	Результат тестирования
A=2, B=0, X=4	X=3	X=3	неуспешно
A=2, B=1, X=1	X=2	X=1,5	успешно
A=0,5 B=0, X=2	X=3	X=4	успешно
A=1, B=0, X=1	X=1	X=1	неуспешно

Порядок выполнения практической работы

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

2. Провести тестирование программы и представить результаты в виде таблицы (Таблицы 1.1-1.4)

3. Оформить отчет по лабораторной работе.

Контрольные вопросы

1. Что такое тестирование ПС?

2. Чем тестирование отличается от отладки ПС?

3. Для чего проводится функциональное тестирование?

4. Каковы правила тестирования программы «как черного ящика»?

5. Как проводится тестирования программы по принципу «белого ящика»?

6. Какие методы используются при тестировании программы по принципу «белого ящика»?

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

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

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

Для реализации метода тестов должны быть изготовлены или заранее известны эталонные результаты.

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

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

Какими должны быть тестовые данные?

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

· должна быть испытана каждая ветвь алгоритма;

· очередной тестовый прогон должен контролировать нечто такое, что еще не было проверено на предыдущих прогонах;

· первый тест должен быть максимально прост, чтобы проверить, работает ли программа вообще;

· арифметические операции в тестах должны предельно упрощаться для уменьшения объема вычислений;

· количества элементов последовательностей, точность для итерационных вычислений, количество проходов цикла в тестовых примерах должны задаваться из соображений сокращения объема вычислений;

· минимизация вычислений не должна снижать надежности контроля;

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

· усложнение тестовых данных должно происходить постепенно.

Пример. Система тестов для задачи нахождения корней квадратного уравнения ax² + bx + c = 0 :

Номер теста	Проверяемый случай	Коэффициенты	Результаты
a	b	c
	d > 0			-2	x1 = 1, x2 = -2
	d = 0				Корни равны: x1 = -1, x2 = -1
	d < 0				Действительных корней нет
	a = 0, b = 0, c = 0				Все коэффициенты равны нулю. x — любое число
	a = 0, b = 0, c № 0				Неправильное уравнение
	a = 0, b № 0				Линейное уравнение; один корень: x = -0.5
	a № 0, b № 0, c = 0				x1 = 0, x2 = -0.5

Из каких этапов состоит процесс тестирования?

Процесс тестирования можно разделить на три этапа.

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

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

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

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

? Что произойдет, если программе, не расчитанной на обработку отрицательных и нулевых значений переменных, в результате какой-либо ошибки придется иметь дело как раз с такими данными?

? Как будет вести себя программа, работающая с массивами, если количество их элементов певысит величину, указанную в объявлении массива?

? Что произойдет, если числа будут слишком малыми или слишком большими?

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

Программа должна сама отвергать любые данные, которые она не в состоянии обрабатывать правильно.

Каковы характерные ошибки программирования?

Ошибки могут быть допущены на всех этапах решения задачи — от ее постановки до оформления. Разновидности ошибок и соответствующие примеры приведены в таблице:

Вид ошибки	Пример
Неправильная постановка задачи	Правильное решение неверно сформулированной задачи
Неверный алгоритм	Выбор алгоритма, приводящего к неточному или эффективному решению задачи
Ошибка анализа	Неполный учет ситуаций, которые могут возникнуть; логические ошибки
Семантические ошибки	Непонимание порядка выполнения оператора
Синтаксические ошибки	Нарушение правил, определяемых языком программирования
Ошибки при выполнении операций	Слишком большое число, деление на ноль, извлечение квадратного корня из отрицательного числа и т. п.
Ошибки в данных	Неудачное определение возможного диапазона изменения данных
Опечатки	Перепутаны близкие по написанию символы, например, цифра 1 и буквы I, l
Ошибки ввода-вывода	Неверное считывание входных данных, неверное задание форматов данных

Является ли отсутствие синтаксических ошибок свидетельством правильности программы?

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

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

Примеры синтаксических ошибок:

· пропуск знака пунктуации;

· несогласованность скобок;

· неправильное формирование оператора;

· неверное образование имен переменных;

· неверное написание служебных слов;

· отсутствие условий окончания цикла;

· отсутствие описания массива и т.п.

Какие ошибки не обнаруживаются транслятором?

Существует множество ошибок, которые транслятор выявить не в состоянии, если используемые в программе операторы сформированы верно.

Примеры таких ошибок.

Логические ошибки:

· неверное указание ветви алгоритма после проверки некоторого условия;

· неполный учет возможных условий;

· пропуск в программе одного или более блоков алгоритма.

Ошибки в циклах:

· неправильное указание начала цикла;

· неправильное указание условий окончания цикла;

· неправильное указание числа повторений цикла;

· бесконечный цикл.

Ошибки ввода-вывода; ошибки при работе с данными:

· неправильное задание тип данных;

· организация считывания меньшего или большего объёма даных, чем требуется;

· неправильное редактирование данных.

Ошибки в использов нии переменных:

· использование переменных без указания их начальных значений;

· ошибочное указание одной переменной вместо другой.

Ошибки при работе с массивами:

· массивы предварительно не обнулены;

· массивы неправильно описаны;

· индексы следуют в неправильном порядке.

Ошибки арифметических операций:

· неверное указание типа переменной (например, целочисленного вместо вещественного);

· неверное определение порядка действий;

· деление на нуль;

· извлечение квадратного корня из отрицательного числа;

· потеря значащих разрядов числа.

Эти ошибки обнаруживаются с помощью тестирования.

В чем заключается сопровождение программы?

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

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

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

Вопросы для самоконтроля

8.1. Какие основные этапы включает в себя решение задач на компьютере?

8.2. Какие этапы компьютерного решения задач осуществляются без участия компьютера?

8.3. Что называют математической моделью объекта или явления?

8.4. Почему невозможно точное исследование поведения объектов или явлений?

8.5. Какие способы моделирования осуществляются с помощью компьютера?

8.6. Из каких последовательных действий состоит процесс разработки программы?

8.7. Доказывает ли получение правдоподобного результата правильность программы?

8.8. Какие ошибки могут остаться невыявленными, если не провести проверку (просмотр, прокрутку) программы?

8.9. Чем тестирование программы отличается от её отладки?

8.10. Каким образом программа-отладчик помогает исследовать поведение программы в процессе её выполнения?

8.11. Как следует планировать процесс отладки программы?

8.12. Можно ли с помощью тестирования доказать правильность программы?

8.13. На какой стадии работы над программой вычисляются эталонные результаты тестов?

8.14. Назовите основные этапы процесса тестирования.

8.15. В чём заключается отличие синта ксических ошибок от семантических?

8.16. О чём свидетельствует отсутствие сообщений машины о синтаксических ошибках?

8.17. Какие разновидности ошибок транслятор не в состоянии обнаружить?

8.18. Для чего программам требуется сопровождение?

Упражнения

Составьте системы тестов для решения следующих задач:

8.1. Найти наибольший общий делитель двух заданных целых чисел.

8.2. Найти наименьшее общее кратное двух заданных целых чисел.

8.3. Определить, является ли заданное число нечетным двузначным числом.

8.4. Заданы площади квадрата и круга. Определить, поместится ли квадрат в круге.

8.5. Решить биквадратное уравнение.

8.6. Найти среднее арифметическое положительных элементов заданного одномерного массива.

8.7. Элементы заданного одномерного массива разделить на его первый элемент.

8.8. Определить, лежит ли заданная точка на одной из сторон треугольника, заданного координатами своих вершин.

8.9. Определить, имеют ли общие точки две плоские фигуры — треугольник с заданными координатами его вершин и круг заданного радиуса c центром в начале координат.

8.10. Задано целое А > 1. Найти наименьшее целое неотрицательное k, при котором 2^k > А.

8.11. Дана последовательность целых чисел. Определить, со скольких чётных чисел она начинается.

8.12. В заданном двумерном массиве найти количество строк, не содержащих нули.

8.13. Определить, сколько строк заданного двумерного массива содержат элементы из заданного диапазона.

8.14. Преобразовать число, заданное в римской системе счисления, в число десятичной системы.

Другие вопросы по Информатике

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

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

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