Технологии тестирования программного обеспечения

2.1. Введение.

Понятия процесса программирования качественно изменились.

Производство программ приобрело массовый характер, существенно

увеличились их объем и сложность. Разработка программных комп-

лексов потребовала значительных усилий больших коллективов

специалистов. Программы перестали быть только вычислительными

и начали выполнять важнейшие функции по управлению и обработке

информации в различных отраслях.

Развитие и применение технологий проектирования комплексов

программ приводит к необходимости измерения и сравнения их эф-

фективности прежде всего по степени влияния на качество прог-

раммного продукта.

Обеспечение высокого качества сложных комплексов программ

связано со значительными затратами труда разработчиков. Затра-

ты на создание программ быстро увеличиваются при возрастании

требований, причем для сложных комплексов весьма сложно дос-

тичь высокого качества функционирования, и после обеспечения

общей работоспособности могут понадобится годы труда для полу-

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

требуются методы и средства, которые позволили бы заметно по-

высить качество программ программ при относительно невысоких

затратах труда.

2.2. Обоснование выбора технологии тестирования.

Как известно, при создании типичного программного проекта

около 50% общего времени и более 50% общей стоимости расходу-

ется на проверку (тестирование) разрабатываемой программы или

системы. Кроме того, доля стоимости тестирования в общей стои-

мости программ имеет тенденцию возрастать при увеличении слож-

ности комплексов программ и повышения требований к их качест-

ву.

Учитывая это, при отработке технологии тестирования прог-

рамм следует четко выделять определенное (по возможности не

очень большое) число правил отладки, обеспечивающих высокое

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

дание.

Тестирование - это процесс исполнения программы с целью

обнаружения ошибок. Одним из способов изучения поставленного

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

мой стратегией черного ящика, тестированием с управлением по

данным, или тестированием с управлением по входу-выходу. При

использовании этой стратегии программа рассматривается как

черный ящик. Тестовые данные используются только в соответст-

вии со спецификацией программы (т.е. без учета знаний о ее

внутренней структуре).

При таком подходе обнаружение всех ошибок в программе яв-

ляется критерием исчерпывающего входного тестирования. Послед-

нее может быть достигнуто, если в качестве тестовых наборов

использовать все возможные наборы входных данных. Следователь-

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

программы требуется бесконечное число тестов, а значит постро-

ение исчерпывающего входного теста невозможно. Это подтвержда-

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

тирующий отсутствие ошибок; во-вторых, разработка таких тес-

тов противоречит экономическим требованиям. Поскольку исчерпы-

вающее тестирование исключается, нашей целью должна стать мак-

симизация результативности вложения капиталовложений в тести-

рование (максимизация числа ошибок, обнаруживаемых одним тес-

том). Для этого необходимо рассматривать внутреннюю структуру

программы и делать некоторые разумные, но, конечно, не облада-

ющие полной гарантией достоверности предположения.

Стратегия белого ящика, или стратегия тестирования, управ-

ляемого логикой программы, позволяет исследовать внутреннюю

структуру программы. В этом случае тестирующий получает тесто-

вые данные путем анализа логики программы.

Сравним способ построения тестов при данной стратегии с

исчерпывающим входным тестированием стратегии черного ящика.

Неверно предположение, что достаточно построить такой набор

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

раз. Исчерпывающему входному тестированию может быть поставле-

но в соответствие исчерпывающее тестирование маршрутов. Подра-

зумевается, что программа проверена полностью, если с помощью

тестов удается осуществить выполнение этой программы по всем

возможным маршрутам ее потока (графа) передач управления.

Последнее утверждение имеет два слабых пункта: во-первых,

число не повторяющих друг друга маршрутов - астрономическое;

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

программа может содержать ошибки (например, некоторые маршруты

пропущены).

В результате всех изложенных выше замечаний можно отме-

тить, что ни исчерпывающее входное тестирование ни исчерпываю-

щее тестирование маршрутов не могут стать полезными стратегия-

ми, потому что оба они не реализуемы. Поэтому реальным путем,

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

стратегию, является сочетание тестирования программы несколь-

кими методами.

2.3. Разработка технологического процесса тестирования.

Внимание, отключите Adblock

Вы посетили наш сайт со включенным блокировщиком рекламы!
Ссылка для скачивания станет доступной сразу после отключения Adblock!

Скачать