Файл: Отладка и тестирование программ:Основные подходы и ограничения ( РАЗРАБОТКА ПРОГРАММ ).pdf

1.4. Понятие тестирования

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

В настоящее время тестированием называется процесс исполнения программного кода с целью обнаружения ошибок [15].

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

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

• программа должна быть синтаксически корректна – в процессе трансляции не должны быть выявлены ошибки;
• программа должна правильно решать поставленную задачу – при вводе корректных данных программа должна выдавать правильный результат. Правильность результата при этом определяется заказчиком программы;
• программа не должна делать ничего лишнего;
• результат должен получаться за разумное время при разумных затратах прочих ресурсов;
• программа должна правильно реагировать на ввод некорректных данных, заранее предусматривая все исключительные ситуации [14].

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

Данный подход применим и сегодня, однако, он обладает рядом недостатков:

• метод «черного ящика» не позволяет обнаружить взаимоуничтожающиеся ошибки;
• не все ошибки воспроизводятся стабильно, поэтому они могут быть не выявлены в результате тестирования [10].

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

В таблице 1 приведены показатели эффективности различных методов тестирования [3].

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

Таблица 1 – Показатели эффективности различных методов тестирования

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

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

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

1.5. Выводы

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

2. ТЕСТИРОВАНИЕ

2.1. Виды тестирования

Принято выделять два основных вида тестирования:

• тестирование программы как черного ящика;
• тестирование программы как белого ящика.

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

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

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

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

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

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

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

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

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

Рисунок 2 – Граф передачи управления

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

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

5²⁰ + 5¹⁹ + … + 5¹ = 10¹⁴ (1)

В данном случае 5 – это количество различных путей внутри цикла. Таким образом, если на разработку одного теста в среднем тратится пять минут, то для построения полного набора тестов понадобится 5*10¹⁴ минут, что составляет примерно один миллиард лет.

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

Реальный путь, применяющийся в тестировании большинства прикладных программ – совокупность обеих стратегий тестирования [19].

2.2. Тестирование надежности

Известно, что качество программного обеспечения определяется несколькими признаками:

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

Понятие надежности также является комплексным свойством. Оно включает в себя следующие понятия:

• безотказность – способность сохранять работоспособное состояние в течение определенного времени;
• долговечность – способность сохранять работоспособное состояние до предельного состояния;
• ремонтопригодность – способность приспосабливаться к поддержанию и восстановлению работоспособного состояния путем обслуживания и ремонта;
• сохраняемость – способность сохранять значения параметров в заданных пределах [5].

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

Для определения надежности программного обеспечения принято использовать следующие свойства:

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

Важно отметить, что за безотказность здесь отвечают свойства стабильности и устойчивости, а восстанавливаемость является лишь возможностью восстановления функциональности после отказа [8].

Для оценки стабильности программного продукта принято использовать следующие характеристики:

• вероятность безотказной работы – вероятность того, что в пределах заданного промежутка времени не возникнет поломка. Такой промежуток времени называется наработкой на отказ;
• гамма-процентная наработка до отказа – наработка, в течение которой поломка не возникнет с заданным процентом вероятности;
• средняя наработка до отказа – математическое ожидание наработки до возникновения поломки;
• средняя наработка на отказ – отношение суммарной наработки к его математическому ожиданию;
• интенсивность отказов – условная плотность вероятности поломки, которая определяется при условии, что до рассматриваемого момента времени поломки не было;
• параметр потока отказов – отношение математического ожидания количества поломок за достаточно малый период наработки к значению этой наработки;
• осредненный параметр потока отказов – отношение математического ожидания количества поломок за конечный промежуток наработки к значению этой наработки [11].