Тестирование программных продуктов

Размещено на http://www.allbest.ru/

ОБЩИЕ ПОНЯТИЯ

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

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

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

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

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

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

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

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

Еще одна причина, по которой трудно говорить о тестировании -- это тот факт, что о нем известно очень немногое. Если сегодня мы располагаем 5% тех знании о проектировании и собственно программировании (кодировании), которые будут у нас к 2000 г., то о тестировании нам известно менее 1%.

ОСНОВНЫЕ ОПРЕДЕЛЕНИЯ.

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

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

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

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

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

Аттестация (certification) -- авторитетное подтверждение правильности программы, аналогичное аттестации электротехнического оборудования Underwriters Laboratories. При тестировании с целью аттестации выполняется сравнение с некоторым заранее определенным стандартом.

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

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

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

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

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

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

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

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

Рис. 1. Спектр подходов к проектированию тестов,

Рис. 2. Процессы тестирования и их связь с процессами проектирования.



ФИЛОСОФИЯ ТЕСТИРОВАНИЯ

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

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

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

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

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

ИНТЕГРАЦИЯ МОДУЛЕЙ

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

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

ВОСХОДЯЩЕЕ ТЕСТИРОВАНИЕ

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

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

НИСХОДЯЩЕЕ ТЕСТИРОВАНИЕ

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

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

Интересен и второй вопрос: в какой форме готовятся тестовые данные и как они передаются программе? Если бы головной модуль содержал все нужные операции ввода и вывода, ответ был бы прост:

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

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

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

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

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

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

МОДИФИЦИРОВАННЫЙ НИСХОДЯЩИЙ МЕТОД

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

.

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

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

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

МЕТОД БОЛЬШОГО СКАЧКА.

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

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

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

МЕТОД САНДВИЧА

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

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

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

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

МОДИФИЦИРОВАННЫЙ МЕТОД САНДВИЧА.

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

СРАВНИТЕЛЬНАЯ ХАРАКТЕРИСТИКА МЕТОДОВ ТЕСТИРОВАНИЯ.

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

	Восходящий	Нисходящий	Модифицированный нисходящий	Метод большого скачка	Метод сандвича	Модифицированный метод сандвича
Сборка	Рано	Рано	Рано	Поздно	Рано	Рано
Время до появления работающего варианта программы	Поздно	Рано	Рано	Поздно	Рано	Рано
Нужны ли драйверы (новые программы или готовые инструменты) ?	Да	Нет	Да	Да	Частично	Да
Нужны ли заглушки	Нет	Да	Да	Да	Частично	Частично
Параллелизм в начале работы	Средний	Слабый	Средний	Высокий	Средний	Высокий
Возможность тестировать отдельные пути	Легко	Трудно	Легко	Трудно	Средне	Легко
Возможность планировать и контролировать последовательность	Легко	Трудно	Трудно	Легко	Трудно	Трудно

Рис. Количественная оценка подход к сборке.

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

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

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

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



Вес		Восходящий	Нисходящий	Модифицированный нисходящий	Метод большого скачка	Метод сандвича	Модифицированный метод сандвича
3	Сборка	Рано +	Рано +	Рано +	Поздно -	Рано +	Рано +
3	Время до появления работающего варианта программы	Поздно -	Рано +	Рано +	Поздно -	Рано +	Рано +
1	Нужны ли драйвера (новые программы u/uли готовые инструменты) ?	Да -	Нет +	Д а -	Да -	Частично	Да -
2	Нужны заглушки?	Нет +	Да -	Да -	Да -	Частично	Частично
1	Параллелизм в начале работы	Средний	Слабый-	Средний	Высокий+	Средний	Высокий +
3	Возможность тестировать отдельные пути	Легко +	Трудно -	Легло +	Легко +	Средне	Легко +
2	Возможность планировать и контролировать последовательность	Легко +	Трудно -	Трудно -	Легко +	Трудно -	Трудно -
0	Неэффективность
Всего	+6	-1	+4	-3	+4	+7

Рис.. Взвешенная оценка подходов к сборке.

ИСПЫТАНИЕ ПРОГРАММНЫХ ПРОДУКТОВ (АНАЛИЗ). ЦЕЛЬ И ОСОБЕННОСТИ ИСПЫТАНИИ.

Испытания являются важнейшим элементом управления качеством продукции. В соответствии с ГОСТ 16504--81 под испытанием промышленной продукции понимают экспериментальное определение количественных и/или качественных характеристик объекта испытания как результата воздействия на него; при его функционировании; при моделировании объекта и/или воздействия. Под испытанием программной продукции следует понимать экспериментальное определение количественных и/или качественных характеристик свойств продукции при ее функционировании в реальной среде и/или моделировании среды функционирования.

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

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

В соответствии с ГОСТ 19,004--80 под испытанием программ понимают установление соответствия программы заданным требованиям и программным документам. Это определение построено на предположении, что в техническом задании на разработку программы определены все требования (характеристики), обеспечение которых гарантирует пригодность программы к использованию по своему назначению. Но такое требование редко соблюдается на практике. В некоторых случаях, особенно в автоматизированных системах, ТЗ на ПС либо вообще не пишут, либо в них перечисляют лишь функции, которые возлагаются на ПС, без указания требований к другим потребительским свойствам. При отсутствии ТЗ на разработку ПС или полного и обоснованного перечня требований к характеристикам разрабатываемого ПС задача испытания ПС становится неопределенной и неконструктивной. Что значит установить соответствие программы заданным требованиям, если эти требования формально не заданы? Какая польза от установления такого соответствия, если эти требования заведомо “усечены” и не отражают основных потребительских свойств программы? Пользователю будет не легче, если программа функционирует плохо, но это в явном виде не противоречит требованиям ТЗ.

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

В зарубежной литературе, в том числе в стандартах на программное обеспечение, понятие “испытание” часто отождествляют с понятием “тестирование”. Например, в Std IEEE 829--1983 “Документация тестов программного обеспечения” (США) дано следующее определение тестирования: “...процесс активного анализа ПО на предмет обнаружения расхождения между реальными и требуемыми нормами ПО (т. е. наличия ошибок в программах) и с целью оценки характеристик элементов ПО”. Данное определение объединяет два приведенных определения термина “испытание” с той лишь разницей, что при принятой (см. определения) концепции поиск и локализация ошибок на являются явно выраженными целями испытания. С учетом высказанных соображений термин “тестирование”, используемый в зарубежной литературе, будем интерпретировать как испытание методом тестирования,

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

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

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

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

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

ТЕХНОЛОГИЧЕСКАЯ СХЕМА ИСПЫТАНИЯ.

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

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

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

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

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

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

четкое, последовательное определение и исполнение плана испытания;

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

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

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

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

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

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

анализ пригодности накопленных данных о качестве ПС для использования при окончательном определении значений показателей качества испытываемого ПС;

проверка и согласование с представителем Заказчика конструкторской документации на ПС, предъявляемой при испытаниях;

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

аттестация специалистов на допуск к проведению испытаний;

приемка испытываемого опытного образца ПС на носителе данных и документации;

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

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

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

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

1. Обследование проектируемого ПС, анализ проектной документации.

2. Определение наиболее важных подсистем, функций и путей проектируемого ПС, подлежащих испытанию.

3. Анализ показателей качества ПС и методов определения их значений. Разработка программ и методик испытания.

4. Разработка (освоение) испытательных программно-технических средств, библиотек тестов и баз данных (если они требуются).

5. Непосредственное проведение испытаний, анализ результатов, принятие решения.

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

Рис. Технологическая схема испытания ПС.

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

ПЛАНИРОВАНИЕ И ОЦЕНКА ЗАВЕРШЕННОСТИ ИСПЫТАНИЙ.

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

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

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

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

4) ПС испытывают в реальной среде функционирования;

5) ПС испытывают в статистически моделируемой среде функционирования, адекватной реальной среде.

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

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

Методика решения задачи планирования испытания включает в себя следующие этапы: нахождение всех путей реализации;

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

Для установления потребности в машинном времени на проведение испытаний необходимо знать среднее значение абсолютной реактивности ПС. Эта характеристика должна быть задана в ТЗ. Если же она не задана, то можно принять где -- минимальное значение абсолютной реактивности; -- максимальное значение абсолютной реактивности.

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

Рассмотренный метод планирования на этапе автономных статистических испытаний модулей ПИ позволяет значительно уменьшить материальные и временные затраты на испытание программ. Ориентация на тот или иной подход к испытаниям зависит от типа испытываемого ПС.

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

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

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

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

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

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

В стандарте IEEE 829--1983 (США) большое внимание уделено документированию процесса испытания ПП. Перечень документов, которые разрабатываются и ведутся в соответствии с планом испытания, приведен в разделе “Документирование”,

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

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

...