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

ПЛАН РЕФЕРАТА. I. ВСТУПЛЕНИЕ. 1. ОБЩИЕ ПОНЯТИЯ. 2. ОСНОВНЫЕ ОПРЕДЕЛЕНИЯ. II. ТЕСТИРОВАНИЕ ПРОГРАММНЫХ ПРОДУКТОВ.
1. ФИЛОСОФИЯ ТЕСТИРОВАНИЯ. 2. ИНТЕГРАЦИЯ МОДУЛЕЙ. 3. ВОСХОДЯЩЕЕ ТЕСТИРОВАНИЕ. 4. НИСХОДЯЩЕЕ ТЕСТИРОВАНИЕ. 5. МОДИФИЦИРОВАННЫЙ НИСХОДЯЩИЙ МЕТОД. 6. МЕТОД БОЛЬШОГО СКАЧКА. 7. МЕТОД САНДВИЧА. 8. МОДИФИЦИРОВАННЫЙ МЕТОД САНДВИЧА. 9. СРАВНИТЕЛЬНАЯ ХАРАКТЕРИСТИКА МЕТОДОВ ТЕСТИРОВАНИЯ. III. ИСПЫТАНИЕ ПРОГРАММНЫХ ПРОДУКТОВ (АНАЛИЗ). 1. ЦЕЛЬ И ОСОБЕННОСТИ ИСПЫТАНИИ. 2. ТЕХНОЛОГИЧЕСКАЯ СХЕМА ИСПЫТАНИЯ. 3. ПЛАНИРОВАНИЕ И ОЦЕНКА ЗАВЕРШЕННОСТИ ИСПЫТАНИЙ. 4. СТЕНДЫ ОТЛАДКИ И ИСПЫТАНИЯ ПРОГРАММ. IV. СЕРТИФИКАЦИЯ ПРОГРАММНЫХ ПРОДУКТОВ. 1. СТАНДАРТИЗАЦИЯ СИСТЕМ КАЧЕСТВА. 2. КЛАССИФИКАЦИЯ ПОКАЗАТЕЛЕЙ КАЧЕСТВА. 3. ВЫБОР НОМЕНКЛАТУРЫ ПОКАЗАТЕЛЕЙ КАЧЕСТВА 4. ГРУППЫ ПОКАЗАТЕЛЕЙ КАЧЕСТВА I. ВСТУПЛЕНИЕ. 1. ОБЩИЕ ПОНЯТИЯ. Многие организации, занимающиеся созданием программного обеспечения, до 50% средств, выделенных на разработку программ, тратят на тестирование, что составляет миллиарды долларов по всему миру в целом. И все же, несмотря на громадные капиталовло­жения, знаний о сути тестирования явно не хватает и большинство программных продуктов неприемлемо ненадежно даже после «ос­новательного тестирования». О состоянии дел лучше всего свидетельствует тот факт, что боль­шинство людей, работающих в области обработки данных, даже не может правильно определить слово «тестирование», и это на самом деле главная причина неудач. «Тестирование — процесс, подтверждающий правильность програм­мы и демонстрирующий, что ошибок в программе нет.» Основной недостаток подобного определения заключается в том, что оно совершенно неправильно; фактически это почти определение анто­нима слова «тестирование». Читатель с некоторым опытом програм­мирования уже, вероятно, понимает, что невозможно продемонст­рировать отсутствие ошибок в программе. Поэтому определение описывает невыполнимую задачу, а так как тестирование зачастую все же выполняется с успехом, по крайней мере с некоторым успе­хом, то такое определение логически некорректно. Правильное определение тестирования таково: Тестирование — процесс выполнения программы с намерением найти ошибки. Невозможно гарантировать отсутствие ошибок в нетривиальной программе; в лучшем случае можно попытаться показать наличие ошибок. Если программа правильно ведет себя для солидного набора тестов, нет основании утверждать, что в ней нет ошибок; со всей определенностью можно лишь утверждать, что не известно, когда эта программа не работает. Конечно, если есть причины считать данный набор тестов способным с большой вероятностью обнаружить все возможные ошибки, то можно говорить о некотором уровне уверенности в правильности программы, устанавливаемом этими тестами. Психологические эксперименты показывают, что большинство людей, поставив цель (например, показать, что ошибок нет), ориен­тируется в своей деятельности на достижение этой цели. Тестовик подсознательно не позволит себе действовать против цели, т. е. подготовить тест, который выявил бы одну из оставшихся в програм­ме ошибок. Поскольку мы все признаем, что совершенство в проекти­ровании и кодировании любой программы недостижимо и поэтому каждая программа содержит некоторое количество ошибок, самым плодотворным применением тестирования будет найти некоторые из них. Если мы хотим добиться этого и избежать психологического барьера, мешающего нам действовать против поставленной цели, наша цель должна состоять в том, чтобы найти как можно больше ошибок. Сформулируем основополагающий вывод: Если ваша цель — показать отсутствие ошибок, вы. их найдете не слишком много. Если же ваша цель — показать наличие ошибок, вы найдете значительную их часть. Надежность невозможно внести в программу в результате тестирования, она определяется пра­вильностью этапов проектирования. Наилучшее решение проблемы надежности — с самого начала не допускать ошибок в программе. Однако вероятность того, что удастся безупречно спроектировать большую программу, бесконечно мала. Роль тестирования состоит как раз в том, чтобы определить местонахождение немногочислен­ных ошибок, оставшихся в хорошо спроектированной программе. Попытки с помощью тестирования достичь надежности плохо спроектированной программы совершенно бесплодны. Тестирование оказывается довольно необычным процессом (вот почему оно и считается трудным), так как этот процесс разрушитель­ный. Ведь цель проверяющего (тестовика) — заставить программу сбиться. Он доволен, если это ему удается; если же программа на его тесте не сбивается, он не удовлетворен. Еще одна причина, по которой трудно говорить о тестирова­нии — это тот факт, что о нем известно очень немногое. Если сегодня мы располагаем 5% тех знании о проектировании и собствен­но программировании (кодировании), которые будут у нас к 2000 г., то о тестировании нам известно менее 1%. 2. ОСНОВНЫЕ ОПРЕДЕЛЕНИЯ. Хотя в тестировании можно выделить несколько различных процессов, такие термины, как тестирование, отладка, доказатель­ство, контроль и испытание, часто используются как синонимы и, к сожалению, для разных людей имеют разный смысл. Хотя стан­дартных, общепринятых определений этих терминов нет, попытка сформулировать их была предпринята на симпозиуме по тестирова­нию программ. Нашу классификацию различных форм тестирования мы начнем с того, что дадим эти опре­деления, слегка их дополнив и расширив их список. Тестирование (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, Рис. 2. Спектр подходов к проектированию тестов, Рис. 3. Процессы тестирования и их связь с процессами проектирования. II. ОСНОВНАЯ ЧАСТЬ. 1. ФИЛОСОФИЯ ТЕСТИРОВАНИЯ Тестирование программного обеспечения охватывает целый ряд видов деятельности, весьма аналогичный последовательности про­цессов разработки программного обеспечения. Сюда входят поста­новка задачи для теста, проектирование, написание тестов, тести­рование тестов и, наконец, выполнение тестов и изучение результа­тов тестирования. Решающую роль играет проектирование теста. Возможен целый спектр подходов к выработке философии, или стратегии проектирования тестов, изображенный на рис.2. Чтобы ориентироваться в стратегиях проектирования тестов, стоит рассмотреть два крайних подхода, находящихся на границах спек­тра. Следует отметить также, что многие из тех, кто работает в этой области, часто бросаются в одну или другую крайность. Сторонник (или сторонница) подхода, соответствующего левой границе спектра, проектирует свои тесты, исследуя внешние спе­цификации или спецификации сопряжения программы или модуля, которые он тестирует. Программу он рассматривает как черный ящик. Позиция его такова: «Меня не интересует, как выглядит эта программа и выполнил ли я все команды или все пути. Я буду удовлетворен, если программа будет вести себя так, как указано в спецификациях». Его идеал — проверить все возможные комбина­ции и значения на входе. Приверженец подхода, соответствующего другому концу спект­ра, проектирует свои тесты, изучая логику программы. Он начинает с того, что стремится подготовить достаточное число тестов для того, чтобы каждая команда была выполнена по крайней мере один раз. Если он немного более искушен, то проектирует тесты так, чтобы каждая команда условного перехода выполнялась в каждом направлении хотя бы раз. Его идеал — проверить каждый путь, каждую ветвь алгоритма. При этом его совсем (или почти со­всем) не интересуют спецификации. Ни одна из этих крайностей не является хорошей стратегией. Читатель, однако, уже, вероятно, заметил, что первая из них, а именно та, в соответствии с которой программа рассматривается как черный ящик, предпочтительней. К сожалению, она страдает тем недостатком, что совершенно неосуществима. Рассмотрим по­пытку тестирования тривиальной программы, получающей на входе три числа и вычисляющей их среднее арифметическое. Тестирова­ние этой программы для всех значений входных данных невозмож­но. Даже для машины с относительно низкой точностью вычислений количество тестов исчислялось бы миллиардами. Даже имей мы вычислительную мощность, достаточную для выполнения всех тес­тов в разумное время, мы потратили бы на несколько порядков больше времени для того, чтобы эти тесты подготовить, а затем проверить. Такие программы, как системы реального времени, операционные системы и программы управления данными, которые сохраняют «память» о предыдущих входных данных, еще хуже. Нам потребовалось бы тестировать программу не только для каждого входного значения, но и для каждой последовательности, каждой комбинации входных данных. Поэтому исчерпывающее тестирование для всех входных данных любой разумной программы неосущест­вимо. Эти рассуждения приводят ко второму фундаментальному прин­ципу тестирования: тестирование — проблема в значительной сте­пени экономическая. Поскольку исчерпывающее тестирование не­возможно, мы должны ограничиться чем-то меньшим. Каждый тест должен давать максимальную отдачу по сравнению с нашими затра­тами. Эта отдача измеряется вероятностью тою, что тест выявит не обнаруженную прежде ошибку. Затраты измеряются временем и стоимостью подготовки, выполнения и проверки результатов теста. Считая, что затраты ограничены бюджетом и графиком, можно ут­верждать, что искусство тестирования, по существу, представляет собой искусство отбора тестов с максимальной отдачей. Более того, каждый тест должен быть представителем некоторого класса вход­ных значений, так чтобы его правильное выполнение создавало у нас некоторую убежденность в том, что для определенного класса входных данных программа будет выполняться правильно. Это обычно требует некоторого знания алгоритма и структуры програм­мы, и мы, таким образом, смещаемся к правому концу спектра. 2. ИНТЕГРАЦИЯ МОДУЛЕЙ. Вторым по важности аспектом тестирования (после проектиро­вания тестов) является последовательность слияния всех модулей в систему или программу. Эта сторона вопроса обычно не получает достаточного внимания и часто рассматривается слишком поздно. Выбор этой последовательности, однако, является одним из самых жизненно важных решении, принимаемых на этапе тестирования, поскольку он определяет форму, в которой записываются тесты, типы необходимых инструментов тестирования, последовательность программирования модулей, а также тщательность и экономичность всего этапа тестирования. По этой причине такое решение должно приниматься на уровне проекта в целом и на достаточно ранней его стадии.
Имеется большой выбор возможных подходов, которые могут быть использованы для слияния модулей в более крупные единицы. В большинстве своем они могут рассматриваться как варианты ше­сти основных подходов, описанных в следующих шести разделах. Сразу же за ними идет раздел, где предложенные подходы сравни­ваются по их влиянию на надежность программного обеспечения.
3. ВОСХОДЯЩЕЕ ТЕСТИРОВАНИЕ. При восходящем подходе программа собирается и тестируется снизу вверх. Только модули самого нижнего уровня («терминаль­ные» модули; модули, не вызывающие других модулей) тестируются изолированно, автономно. После того как тестирование этих модулей завершено, вызов их должен быть так же надежен, как вызов встроенной функции языка или оператор присваивания. Затем тес­тируются модули, непосредственно вызывающие уже проверенные. Эти модули более высокого уровня тестируются не автономно, а вместе с уже проверенными модулями более низкого уровня. Про­цесс повторяется до тех пор, пока не будет достигнута вершина. Здесь завершаются и тестирование модулей, и тестирование сопря­жении программы. При восходящем тестировании для каждого модуля необходим драйвер: нужно подавать тесты в соответствии с сопряжением те­стируемого модуля. Одно из возможных решении — написать для каждого модуля небольшую ведущую программу. Тестовые данные представляются как «встроенные» непосредственно в эту программу переменные и структуры данных, и она многократно вызывает тес­тируемый модуль, с каждым вызовом передавая ему новые тестовые данные. Имеется и лучшее решение: воспользоваться программой тестирования модулей — это инструмент тестирования, позволяю­щий описывать тесты на специальном языке и избавляющий от необходимости писать драйверы. 4. НИСХОДЯЩЕЕ ТЕСТИРОВАНИЕ. Нисходящее тестирование (называемое также нисходящей раз­работкой не является полной противоположностью восходя­щему, но в первом приближении может рассматриваться как тако­вое, При нисходящем подходе программа собирается и тестируется сверху вниз. Изолировано тестируется только головной модуль. После того как тестирование этого модуля завершено, с ним соеди­няются (например, редактором связей) один за другим модули, непосредственно вызываемые им, и тестируется полученная комби­нация. Процесс повторяется до тех пор, пока не будут собраны и проверены все модули. При этом подходе немедленно возникает два вопроса: что де­лать, когда тестируемый модуль вызывает модуль более низкого уровня (которого в данный момент еще не существует), и как подаются тестовые данные. Ответ на первый вопрос состоит в том, что для имитации функций недостающих модулей программируются модули-заглушки», которые моделируют функции отсутствующих модулей. Фраза «просто напишите заглушку» часто встречается в описании этого подхода, но она способна ввести в заблуждение, поскольку задача написания заглушки» может оказаться трудной. Ведь заглушка редко сводится просто к оператору RETURN, поскольку вызывающий модуль обычно ожидает от нее выходных параметров. В таких случаях в заглушку встраивают фиксирован­ные выходные данные, которые она всегда и возвращает. Это иногда оказывается неприемлемым, так как вызывающий модуль может рассчитывать, что результат вызова зависит от входных данных. Поэтому в некоторых случаях заглушка должна быть довольно изощ­ренной, приближаясь по сложности к модулю, который она пытается моделировать. Интересен и второй вопрос: в какой форме готовятся тестовые данные и как они передаются программе? Если бы головной модуль содержал все нужные операции ввода и вывода, ответ был бы прост: Тесты пишутся в виде обычных для пользователей внешних данных и передаются программе через выделенные ей устройства ввода. Так, однако, случается редко. В хорошо спроектированной програм­ме физические операции ввода-вывода выполняются на нижних уровнях структуры, поскольку физический ввод-вывод — абстрак­ция довольно низкого уровня. Поэтому для того, чтобы решить проблему экономически эффективно, модули добавляются не в стро­го нисходящей последовательности (все модули одного горизонталь­ного уровня, затем модули следующего уровня), а таким образом, чтобы обеспечить функционирование операций физического ввода-вывода как можно быстрее. Когда эта цель достигнута, нисходящее тестирование получает значительное преимущество: все дальнейшие тесты готовятся в той же форме, которая рассчитана на пользователя. Остается еще один вопрос: в какой форме пишутся тесты до тех пор, пока не будет достигнута эта цель? Ответ: они включаются в некоторые из заглушек. Нисходящий метод имеет как достоинства, так и недостатки по сравнению с восходящим. Самое значительное достоинство — в том, что этот метод совмещает тестирование модуля, тестирова­ние сопряжении и частично тестирование внешних функций. С этим же связано другое его достоинство — когда модули ввода-вывода уже подключены, тесты можно готовить в удобном виде. Нисходя­щий подход выгоден также в том случае, когда есть сомнения от­носительно осуществимости программы в целом или если в проек­те программы могут оказаться серьезные дефекты. Преимуществом нисходящего подхода очень часто считают от­сутствие необходимости в драйверах; вместо драйверов вам просто следует написать «заглушки». Как читатель сейчас уже, вероятно, понимает, это преимущество спорно. Нисходящий метод тестирования имеет, к сожалению, некоторые недостатки. Основным из них является тот, что модуль редко тес­тируется досконально сразу после его подключения. Дело в том, что основательное тестирование некоторых модулей может потре­бовать крайне изощренных заглушек. Программист часто решает не тратить массу времени на их программирование, а вместо этого пишет простые заглушки и проверяет лишь часть условий в модуле. Он, конечно, собирается вернуться и закончить тестирование рас­сматриваемого модуля позже, когда уберет заглушки. Такой план тестирования определенно не лучшее решение, поскольку об от­ложенных условиях часто забывают. Второй тонкий недостаток нисходящего подхода состоит в том, что он может породить веру в возможность начать программирова­ние и тестирование верхнего уровня программы до того, как вся программа будет полностью спроектирована. Эта идея на первый взгляд кажется экономичной, но обычно дело обстоит совсем наобо­рот. Большинство опытных проектировщиков признает, что проекти­рование программы — процесс итеративный. Редко первый проект оказывается совершенным. Нормальный стиль проектирования структуры программы предполагает по окончании проектирования нижних уровней вернуться назад и подправить верхний уровень, внеся в него некоторые усовершенствования или исправляя ошибки, либо иногда даже выбросить проект и начать все сначала, потому что разработчик внезапно увидел лучший подход. Если же головная часть программы уже запрограммирована и оттестирована, то воз­никает серьезное сопротивление любым улучшениям ее структуры. В конечном итоге за счет таких улучшений обычно можно сэконо­мить больше, чем те несколько дней или недель, которые рассчиты­вает выиграть проектировщик, приступая к программированию слишком рано.
5. МОДИФИЦИРОВАННЫЙ НИСХОДЯЩИЙ МЕТОД Нисходящий подход имеет еще один существенный недостаток, касающийся полноты тестирования. Предположим, что есть большая программа и где-то ближе к нижнему ее уровню находится модуль, предназначенный для вычисления корней квадратного уравнения. Для заданных входных переменных А, В и С он решает уравнение .
При проектировании и программировании модуля с такой функцией всегда следует понимать, что квадратное уравнение может иметь как действительные, так и комплексные корни. Для полной реали­зации этой функции необходимо, чтобы результаты могли быть дей­ствительными или комплексными числами (или, если дополнитель­ные затраты на нахождение комплексных корней не оправданы, модуль должен по крайней мере возвращать код ошибки в случае, когда входные коэффициенты задают уравнение с комплексными корнями). Предположим, что конкретный контекст, в котором используется модуль, исключает комплексные корни (т. е. вызы­вающие модули никогда не задают входных параметров, которые привели бы к комплексным корням). При строго нисходящем методе иногда бывает невозможно тестировать модуль для случая комплек­сных корней (или тестировать ошибочные условия). Можно попы­таться оправдывать это тем, что, поскольку такое уравнение никогда не будет дано модулю, никого не должно заботить, работает ли он и в этих случаях. Да, это безразлично сейчас, но окажется важным в будущем, когда кто-то попытается использовать модуль в новой программе или модифицировать старую программу так, что станут возможными и комплексные корни. Эта проблема проявляется в разнообразных формах. Применяя нисходящее тестирование в точном соответствии с предыдущим разделом, часто невозможно тестировать определенные логические условия, например ошибочные ситуации или защитные проверки. Нисходящий метод, кроме того, делает сложной или вообще невозможной проверку исключительных ситуаций в некотором модуле, если программа работает с ним лишь в ограниченном кон­тексте (это означает, что модуль никогда не получит достаточно полный набор входных значений). Даже если тестирование такой си­туации в принципе осуществимо, часто бывает трудно определить, какие именно нужны тесты, если они вводятся в точке программы, удаленной от места проверки соответствующего условия. Метод, называемый модифицированным нисходящим подходом, решает эти проблемы: требуется, чтобы каждый модуль прошел автономное тестирование перед подключением к программе. Хотя это действительно решает все перечисленные проблемы, здесь тре­буются и драйверы, и заглушки для каждого модуля. 6. МЕТОД БОЛЬШОГО СКАЧКА. Вероятно, самый распространенный подход к интеграции мо­дулей — метод «большого скачка». В соответствии с этим методом каждый модуль тестируется автономно. По окончании тестирования модулей они интегрируются в систему все сразу. Метод большого скачка по сравнению с другими подходами име­ет много недостатков и мало достоинств. Заглушки и драйверы не­обходимы для каждого модуля. Модули не интегрируются до самого последнего момента, а это означает, что в течение долгого времени серьезные ошибки в сопряжениях могут остаться необнаруженными. Метод большого скачка значительно усложняет отладку. И все же большой скачок не всегда нежелателен. Если програм­ма мала и хорошо спроек­тирована, он может оказаться приемлемым. Однако для крупных программ метод большого скачка обычно губителен. 7. МЕТОД САНДВИЧА Тестирование методом сандвича представляет собой компромисс между восходящим и нисходящим подходами. Здесь делается по­пытка воспользоваться достоинствами обоих методов, избежав их недостатков. При использовании этого метода одновременно начинают вос­ходящее и нисходящее тестирование, собирая программу как снизу, так и сверху и встречаясь в конце концов где-то в середине. Точка встречи зависит от конкретной тестируемой программы и должна быть заранее определена при изучении ее структуры. Например, если разработчик может представить свою систему в виде уровня прикладных модулей, затем уровня модулей обработки запросов, затем уровня примитивных функций, то он может решить приме­нять нисходящий метод на уровне прикладных модулей (програм­мируя заглушки вместо модулей обработки запросов), а на осталь­ных уровнях применить восходящий метод. Применение метода сандвича - это разумный подход к интеграции больших программ, таких, как операционная система или пакет прикладных программ. Метод сандвича сохраняет такое достоинство нисходящего и восходящего подходов, как начало интеграции системы на самом раннем этапе. Поскольку вершина программы вступает в строй ра­но, мы, как в нисходящем методе, уже на раннем этапе получаем работающий каркас программы. Поскольку нижние уровни програм­мы создаются восходящим методом, снимаются те проблемы нисхо­дящего метода, которые были связаны с невозможностью тестиро­вать некоторые условия в глубине программы. 8. МОДИФИЦИРОВАННЫЙ МЕТОД САНДВИЧА. При тестировании методом сандвича возникает та же проблема, что и при нисходящем подходе, хотя здесь она стоит не так остро. Проблема эта в том, что невозможно досконально тестировать отдельные модули. Восходящий этап тестирования по методу санд­вича решает эту проблему для модулей нижних уровней, но она может по-прежнему оставаться открытой для нижней половины верхней части программы. В модифицированном методе сандвича нижние уровни также тестируются строго снизу вверх. А модули верхних уровней сначала тестируются изолированно, а затем соби­раются нисходящим методом. Таким образом, модифицированный ме­тод сандвича также представляет собой компромисс между восходя­щим и нисходящим подходами. 9. СРАВНИТЕЛЬНАЯ ХАРАКТЕРИСТИКА МЕТОДОВ ТЕСТИРОВАНИЯ. С точки зрения надежности программного обеспечения эти стратегии можно оценить по восьми критериям, как показано на рис. 10.7. Первый критерий — время до момента сбор­ки модулей, поскольку это важно для обнаружения ошибок в сопря­жениях и предположениях модулей о свойствах друг друга. Второй критерий — время до момента создания первых работающих «ске­летных» версий программы, поскольку здесь могут проявиться глав­ные дефекты проектирования. Третий и четвертый критерии касают­ся вопроса о том, необходимы ли заглушки, драйверы и другие ин­струменты тестирования. Пятый критерий—мера параллелизма, который возможен в начале или на ранних стадиях тестирования. Это интересный вопрос, поскольку необходимость в ресурсах (т. е. программистах) обычно достигает пика на этапах проектирования и программирования модулей. Восходящий Нисходящий Модифици­рованный нисходящий Метод большого скачка Метод сандвича Модифици­рованный метод сандвича Сборка Рано Рано Рано Поздно Рано Рано Время до появления работающего варианта программы Поздно Рано Рано Поздно Рано Рано Нужны ли драйверы (новые программы или готовые инстру­менты) ? Да Нет Да Да Частично Да Нужны ли заглушки Нет Да Да Да Частично Частично Параллелизм в начале работы Средний Слабый Средний Высокий Средний Высокий Возможность тестиро­вать отдельные пути Легко Трудно Легко Трудно Средне Легко Возможность планиро­вать и контролировать последовательность Легко Трудно Трудно Легко Трудно Трудно Рис. 10.7. Количественная оценка подход к сборке. Поэтому важно, чтобы возможность параллельного тестирования появилась ближе к началу, а не концу цикла тестирования. Шестой критерий связан с ответом на обсуждавшийся ранее вопрос: возможно ли проверить любой конкретный путь и любое условие в программе? Седьмой критерий характеризует сложность планирования, надзора и управления в процессе тестирования. Это связано с осознанием того факта, что тестирование, которым трудно управлять, часто ведет к недосмотрам и упущениям. Время от времени раздаются возражения против нисходящего подхода в связи с тем, что тестирование нижних модулей требует многократных лишних прогонов головных модулей. Однако этот критерий отмечен как не­существенный. Хотя лишние прогоны действительно бывают необ­ходимы, возможно также, что во многих случаях, которые кажутся лишними, в действительности воссоздаются несколько разные усло­вия. Эти прогоны могут вскрыть новые ошибки, превращая таким образом недостаток в достоинство. Поскольку этот эффект недоста­точно осознан, мы им пренебрегаем.
Теперь оценим наши шесть подходов с помощью перечисленных восьми критериев. Как уже говорилось, такая оценка зависит от конкретного проекта. В качестве исходного приближения для вы­полнения ваших собственных оценок приведен вариант очень грубой оценки. Прежде всего следует взвесить относительное влияние каж­дого из восьми критериев на надежность программного обеспечения. Ранняя сборка и раннее получение работающего каркаса програм­мы, а также возможность тестировать любые конкретные условия представляются наиболее важными, поэтому им дается коэффициент 3. Сложность подготовки заглушек, а также сложность планирова­ния и управления последовательностью тестов также важны, поэто­му они получают вес 2. Третий критерий, необходимость драйверов, вес 1 ввиду доступности общих инструментов тестирования. Критерий, связанный с параллелизмом работы, также имеет вес 1, потому что, хотя он, может быть, и важен по другим причинам, на надежность сильно не влияет. Восьмой критерий получает коэффи­циент нуль. На рис. 10.8 показаны результаты этой оценки. В каждой графе таблицы вес берется со знаком плюс или минус либо не учитывается, в зависимости от того, благоприятно, неблагоприятно или безраз­лично проявляется соответствующий фактор при рассматриваемом подходе. Модифицированный метод сандвича и восходящий ме­тод оказываются наилучшими подходами, а метод большого скачка— наихудшим. Если способ оценки оказывается близким к вашей кон­кретной ситуации, следует рекомендовать модифицированный метод сандвича для тестирования больших систем или программ и восхо­дящий подход для тестирования программ малых и средних. Вес Восходящий Нисходящий Модифици­рованный нисходящий Метод большого скачка Метод сандвича Модифици­рованный метод сандвича 3 Сборка Рано + Рано + Рано + Поздно - Рано + Рано + 3 Время до появления работающего варианта программы Поздно - Рано + Рано + Поздно - Рано + Рано + 1 Нужны ли драйвера (новые программы u/uли готовые инстру­менты) ? Да - Нет + Д а - Да - Частично Да - 2 Нужны заглушки? Нет + Да - Да - Да - Частично Частично 1 Параллелизм в начале работы Средний Слабый- Средний Высокий+ Средний Высокий + 3 Возможность тестировать отдельные пути Легко + Трудно - Легло + Легко + Средне Легко + 2 Возможность планиро­вать и контролировать последовательность Легко + Трудно - Трудно - Легко + Трудно - Трудно - 0 Неэффективность Всего +6 -1 +4 -3 +4 +7 Рис. 10.8. Взвешенная оценка подходов к сборке. III. ИСПЫТАНИЕ ПРОГРАММНЫХ ПРОДУКТОВ (АНАЛИЗ). 1. ЦЕЛЬ И ОСОБЕННОСТИ ИСПЫТАНИИ. Испытания являются важнейшим элементом управления качеством продукции. В соответствии с ГОСТ 16504—81 под испытанием промыш­ленной продукции понимают экспериментальное определение количественных и/или качественных характеристик объекта испытания как результата воздействия на него; при его функцио­нировании; при моделировании объекта и/или воздействия. Под испытанием программной продукции следует понимать экспери­ментальное определение количественных и/или качественных характеристик свойств продукции при ее функционировании в реальной среде и/или моделировании среды функционирования.
Целью испытания является экспериментальное определение фактических (достигнутых) характеристик свойств испытывае­мого ПИ. Эти характеристики могут быть как количественными, так и качественными. Важно, чтобы на их основе можно было сделать вывод о пригодности данного ПИ к использованию по своему назначению. Если вывод отрицательный, то образец ПИ возвращается на доработку. Таким образом перекрывается до­ступ недоброкачественной продукции к пользователю, Непосред­ственно в ходе испытаний качество ПИ может и не измениться, так как локализация ошибок не является целью испытания. Вме­сте с тем некоторые дефекты в программах и документации могут устраняться по ходу испытания.
Испытание является завершающим этапом разработки. Ему предшествует этап статической и динамической отладки про­грамм. Основным методом динамической отладки является тести­рование. В узком смысле цель тестирования состоит в обнаруже­нии ошибок, цель же отладки—не только в обнаружении, но ив устранении ошибок. Однако ограничиться только отладкой про­граммы, если есть уверенность в том, что все ошибки в ней устра­нены, нельзя. Цели у отладки и испытания разные. Полностью отлаженная программа может не обладать определенными по­требительскими свойствами и тем самым быть непригодной к использованию по своему назначению. Не может служить аль­тернативой испытанию и проверка работоспособности программы на контрольном примере, так как программа, работоспособная в условиях контрольного примера, может оказаться неработо­способной в других условиях применения. Попытки охватить контрольным примером все предполагаемые условия функциони­рования сводятся в конечном счете к тем же испытаниям. В соответствии с ГОСТ 19,004—80 под испытанием программ понимают установление соответствия программы заданным тре­бованиям и программным документам. Это определение построе­но на предположении, что в техническом задании на разработку программы определены все требования (характеристики), обе­спечение которых гарантирует пригодность программы к исполь­зованию по своему назначению. Но такое требование редко соблюдается на практике. В некоторых случаях, особенно в авто­матизированных системах, ТЗ на ПС либо вообще не пишут, либо в них перечисляют лишь функции, которые возлагаются на ПС, без указания требований к другим потребительским свойствам. При отсутствии ТЗ на разработку ПС или полного и обоснован­ного перечня требований к характеристикам разрабатываемого ПС задача испытания ПС становится неопределенной и некон­структивной. Что значит установить соответствие программы заданным требованиям, если эти требования формально не за­даны? Какая польза от установления такого соответствия, если эти требования заведомо «усечены» и не отражают основных потребительских свойств программы? Пользователю будет не легче, если программа функционирует плохо, но это в явном виде не противоречит требованиям ТЗ. При наличии в ТЗ требуемых характеристик основных потре­бительских свойств ПИ приведенные определения термина «испытание» по цели испытания практически совпадают. Однако и в этом случае первое определение является более конструктивным, так как оно формулирует не только цель, но и основной метод проведения испытании — проверка ПИ, функционирую­щего в реальной или моделируемой, но близкой к реальной среде, В зарубежной литературе, в том числе в стандартах на программное обеспечение, понятие «испытание» часто отождествля­ют с понятием «тестирование». Например, в Std IEEE 829—1983 «Документация тестов программного обеспечения» (США) дано следующее определение тестирования: « .процесс активного анализа ПО на предмет обнаружения расхождения между реаль­ными и требуемыми нормами ПО (т. е. наличия ошибок в про­граммах) и с целью оценки характеристик элементов ПО». Дан­ное определение объединяет два приведенных определения тер­мина «испытание» с той лишь разницей, что при принятой (см. определения) концепции поиск и локализация ошибок на являются явно выраженными целями испытания. С учетом вы­сказанных соображений термин «тестирование», используемый в зарубежной литературе, будем интерпретировать как испыта­ние методом тестирования, Длительность испытания зависит от типа, конфигурации (сложности) ПС, а также от целей и степени автоматизации рас­сматриваемого технологического процесса. При испытании опе­рационных систем она колеблется от одного до шести месяцев [20]. Сложные программные комплексы после интеграции могут испытываться и более длительное время. Основными видами испытания ПП являются предварительные, приемочные и эксплуатационные испытания, включая опытную эксплуатацию. Особенности их организации и проведения подробно рассмотрены в книге [18]. В зависимости от места проведения различают стендовые и полигонные испытания. Под испытательным стендом понимают совокупность технических устройств и математических моделей, обеспечивающих в автоматическом режиме имитацию среды функционирования; поступление входных данных, искажающие воздействия; регистрацию информации о функционировании ПС, а также управление процессом испытания и объектом испытания. Если в основу стендовых испытаний положен принцип моделиро­вания, то соответствующие испытательные стенды называют моделирующими. Испытательным полигоном называют место, предназначенное для испытаний в условиях, близких к условиям эксплуатации, и обеспеченное необходимыми средствами испытания. Полигонным испытаниям подвергают системы, работающие в реальном мас­штабе времени. В полигонных условиях обычно сочетают натур­ные испытания с использованием реальных объектов автома­тизируемых систем и моделирование некоторых объектов и про­цессов их функционирования. В последнее. Время в некоторых разрабатывающих организациях создают испытательные полиго­ны, представляющие собой совокупность специализированных по профилю данной организации испытательных стендов. Такие по­лигоны имеют общую техническую и информационную базы, а также программные средства организации испытаний. По степени зависимости испытателей от разработчиков раз­личают зависимые и независимые испытания. При зависимых испытаниях основные операции с испытываемыми ПС (подготов­ка к работе, подготовка и ввод исходных данных, регистрация и анализ результатов) выполняют разработчики программ. Оцен­ку результатов испытания производит комиссия при активном участии разработчиков. Независимые испытания проводят спе­циальные подразделения, не несущие ответственности за разра­ботку программ и непосредственно не подчиняющиеся руководи­телям разработки. 2. ТЕХНОЛОГИЧЕСКАЯ СХЕМА ИСПЫТАНИЯ. Для повышения эффективности испытания, его ускорения и удешевления необходимо разработать научно обоснованные методы, средства и методики, позволяющие преодолеть недостат­ки подхода к испытанию как к своего рода эвристике, недооценку его роли в обеспечении требуемого уровня качества ПП, подмену испытаний процедурами типа проверки работоспособности на контрольном примере и т. п. Эта цель может быть достигнута лишь путем разработки технологической схемы испытаний, пред­усматривающей;
знание назначения испытываемого ПС, условий его функцио­нирования и требований к нему со стороны пользователей; автоматизацию всех наиболее трудоемких процессов и прежде всего моделирование среды функционирования, включая иска­жающие воздействия; ясное представление цели и последовательности испытания;
целенаправленность и неизбыточность испытания, исключаю­щие или минимизирующие повторение однородных процедур при одних и тех же условиях функционирования испытываемого ПС; систематический контроль за ходом, регулярное ведение про­токола и журнала испытания; четкое, последовательное определение и исполнение плана испытания; четкое сопоставление имеющихся ресурсов с предполагаемым объемом испытания; возможность обеспечения, а также объективной количествен­ной оценки полноты и достоверности результатов испытания навсех этапах. Любому виду испытаний должна предшествовать тщательная подготовка. В подготовку испытаний ПС входят следующие меро­приятия: составление и согласование плана-графика проведения испы­тания; разработка, комплектование, испытание и паспортизация про­граммно-технических средств, используемых при испытаниях; анализ пригодности испытательных средств, используемых во время предварительных испытаний, для проведения приемочных испытаний; анализ пригодности накопленных данных о качестве ПС для использования при окончательном определении значений показа­телей качества испытываемого ПС; проверка и согласование с представителем Заказчика кон­структорской документации на ПС, предъявляемой при испыта­ниях; разработка, согласование и утверждение программ и методикиспытаний; аттестация специалистов на допуск к проведению испытаний; приемка испытываемого опытного образца ПС на носителе данных и документации; проведение мероприятий, направленных на обеспечение до­стоверности испытаний. Особо следует подчеркнуть необходимость заблаговременной разработки и испытания всех программно-технических средств, которые будут использоваться при проведении испытаний. При этом следует иметь в виду, что уровень точности и надежности измерительной аппаратуры, используемой при испытаниях любого объекта, должен быть значительно выше соответствующих показателен испытываемого объекта. Поэтому реальные харак­теристики программно-технических испытательных средств необ­ходимо установить заранее, а их приемлемость согласовывать между разработчиками, испытателями и заказчиками ПС. Пре­небрежение этим правилом вызывает недоверие к результатам испытания и, как следствие, удлинение сроков испытания. Сложность программно-технических испытательных средств, требования к их совершенству, а следовательно, и затраты ре­сурсов на их разработку прямо пропорционально зависят от соответствующих показателей испытываемых ПС. Объем испы­тательных программных средств, выраженный в машинных командах, может достигать объема испытываемых с их помощью программ. Поэтому разработка программно-технических средств, предназначенных для испытания особо сложной ПП, должна начинаться одновременно с разработкой опытных образцов про­дукции. На основании изложенного можно определить следующие пять этапов испытания. 1. Обследование проектируемого ПС, анализ проектной доку­ментации. 2. Определение наиболее важных подсистем, функций и путей проектируемого ПС, подлежащих испытанию. 3. Анализ показателей качества ПС и методов определения их значений. Разработка программ и методик испытания. 4. Разработка (освоение) испытательных программно-техни­ческих средств, библиотек тестов и баз данных (если они требу­ются). 5. Непосредственное проведение испытаний, анализ результа­тов, принятие решения. На рис. 16 изображена технологическая схема в виде этапов подготовки и проведения испытания и их связи с этапами раз­работки ПС. Рис. 16. Технологическая схема испытания ПС. В зависимости от специфики, условий применения, требований к качеству испытываемых ПС испытания могут проводиться либо путем тестирования, либо путем статистического моделирования среды функционирования, либо на основе натурных и смешан­ных экспериментов. Часто полезно использование всех этих мето­дов. Значения некоторых показателей качества можно получить экспертным путем. 3. ПЛАНИРОВАНИЕ И ОЦЕНКА ЗАВЕРШЕННОСТИ ИСПЫТАНИЙ. План проведения испытаний должен быть ориентирован на обеспечение всесторонней проверки ПС и максимальной (задан­ной) достоверности полученных результатов при использовании ограниченных ресурсов, выделенных на испытаниях. Принципи­ально возможны следующие подходы к решению этой задачи: 1) анализируют весь диапазон входных данных. На основе анализа заранее готовят такое множество комбинаций данных (тестовых наборов данных), которое охватывает наиболее харак­терные подмножества входных данных. Программу рассматри­вают как черный ящик. Испытания сводятся к последователь­ному вводу тестовых наборов данных и анализу получаемых результатов; 2) анализируют множество ситуаций, которые могут возник­нуть при функционировании ПС. Выбирают наиболее характер­ные ситуации. Каждую из них выражают через тестовый набор входных данных. Далее сущность испытания и анализа результатов сводится к подходу 1); 3) с помощью графовой модели анализируют микроструктуру ПС. Выбирают множество путей, которое полностью покрывает граф-схему ПС, и такую последовательность тестовых наборов исходных данных, выполнение которой будет проходить по выделенным путям. Организация испытаний аналогична подходам 1) и2); 4) ПС испытывают в реальной среде функционирования; 5) ПС испытывают в статистически моделируемой среде функционирования, адекватной реальной среде. Ни один из этих подходов не является универсальным. Каждый из них имеет свои преимущества и недостатки, которые в разной степени проявляются в зависимости от специфики испытываемого ПС. Например, подход 1) может оказаться предпочтительным, если диапазон входных данных обозрим, сравни­тельно легко анализируется и систематизируется, и неприемлемым — в противном случае. Наиболее достоверные результаты получаются при испытаниях в реальной среде функционирования. Но такие испытания редко удается осуществить. Поэтому на практике используют комбинации всех видов. Типичным приме­ром такой комбинации может служить смешанный метод, когда среда функционирования ПС моделируется, а достоверность ре­зультатов проверяется путем сравнения с результатами, получен­ными при функционировании ПС в реальной среде. Анализ показывает, что абсолютная проверка ПС ни при одном из рассмотренных подходов не осуществима. Поэтому при планировании испытаний необходимо предварительно анализи­ровать структуры испытываемых программ и входных данных. В частности, следует устанавливать те пути граф-схемы програм­мы, использование которых при преобразовании данных наиболее вероятно. Эта задача аналогична подходам 1) и 2). Для сложных программных комп­лексов она не имеет строго математического решения. Вместе с тем на практике нередко удается заранее установить наиболее вероятные ситуации, которые могут возникнуть в автоматизируе­мой системе, а следовательно, и наборы входных данных, описы­вающие эти ситуации.
Методика решения задачи планирования испытания включает в себя следующие этапы: нахождение всех путей реализации; выделение минимального подмножества путей, обеспечивающих проверку всех участков программы; разработка тестов для про­верки выделенных путей. Необходимо отметить, что в результате решения получают не одно подмножество путей, а некоторую совокупность таких подмножеств. Анализируя эти совокупности по критериям мини­мального времени реализации их на ЭВМ, выбора наиболее ве­роятных путей, отсутствия в этих совокупностях несовместимых путей (рассмотренным методам присущ этот недостаток), выби­рают наиболее приемлемую совокупность. Для формирования входных данных тестирования для каждого выделенного пути реализации составляют специальные таблицы. В таблицах пред­ставляют только условные операторы, принадлежащие данному пути, и операторы, в которых вычисляются переменные управле­ния. В результате анализа предписаний, удовлетворяющих услов­ным операторам, вырабатывают входные данные тестирования.
Для установления потребности в машинном времени на про­ведение испытаний необходимо знать среднее значение абсолют­ной реактивности ПС. Эта характеристика должна быть задана в ТЗ. Если же она не задана, то можно принять где — минимальное значение абсолютной реактивности; — максимальное значение абсолютной реактивности. Несмотря на то что проверка всех путей граф-схемы большой программы неосуществима, при планировании испытаний необ­ходимо при заданных ресурсах обеспечить максимальную пол­ноту проверки, особенно проверки модулей решения наиболее ответственных задач. Стремление избежать при этом неэффектив­ного простого перебора приводит к задаче выбора минимального количества путей, покрывающих граф ПС. Под покрытием по­нимают включение всех дуг графа. Минимальное покрытие, с од­ной стороны, обеспечивает минимум тестов и контрольных про­счетов, а, с другой стороны, гарантирует прохождение каждой дуги графа хотя бы по одному разу. Рассмотренный метод планирования на этапе автономных стати­стических испытаний модулей ПИ позволяет значительно уменьшить материальные и временные затраты на испытание программ. Ориен­тация на тот или иной подход к испытаниям зависит от типа испы­тываемого ПС. В общем случае при планировании и организации испытаний следует искать компромиссное решение, учитывающее два про­тиворечивых требования: обеспечение максимальной достовер­ности обобщенной оценки качества ПИ и выполнение испытания в ограниченное время с использованием ограниченных ресурсов. Следует выделить три стадии испытания: подготовительную; непосредственные ис­пытания; заключительную (подготовка отчетных материалов). Задачи этих стадий очевидны. Подробнее остановимся на задачах подготовительной стадии. Эта стадия наиболее длительная и наиболее трудоемкая. Основными ее задачами являются: планирование испытаний; разработка технологической схемы испытаний и испытательных средств; разработка программ и методик испытания; накопление предварительных статистических данных, характеризующих ПС. Целенаправленность и четкость организации работ по накоп­лению статистических данных может существенно повысить до­стоверность оценки качества ПС, исключить дублированные (повторные) проверки и уменьшить сроки испытаний и затрачи­ваемые материальные ресурсы. Однако в некоторых случаях из-за плохой организации работы результаты тестирования на этапах отладки программ и предварительных испытаниях не реги­стрируются, поэтому не могут использоваться для окончательной. оценки качества программы. Между выделенными стадиями испытания ПС имеются пря­мые и обратные связи, аналогичные связям между этапами жиз­ненного цикла ПС. Это означает, что при выполнении работ заключительной стадии может быть выявлена необходимость возвращения к стадии непосредственных испытаний (или даже к подготовительной стадии) для уточнения отдельных характе­ристик. Составлению плана проведения испытаний должен предшествовать анализ Т3 на разработку ПС, структурных и функциональных схем, режимов функционирования, зависимостей между модулями програм­мы, планов-графиков разработки и отладки компонентов ПС, результатов контроля их качества на ранних стадиях разработки. В результате этого анализа необходимо разработать и обосно­вать общую стратегию испытания, а на ее основе—комплекс документов по организации испытаний, который должен содер­жать ответы на следующие вопросы: 1) задачи испытаний на каждой фазе, последовательность развития фаз; 2) используемые специальные испытательные средства; 3) количество необходи­мого машинного времени на каждой фазе испытаний; 4) конфи­гурация общего технического и программного обеспечения; 5) оцениваемые свойства, критерии оценки, способы их получе­ния; 6) процедуры контроля хода испытания; 7) процедуры реги­страции, сбора, обработки и обобщения результатов испытания; 8) условия (критерии) начала и завершения каждой фазы испы­таний. По каждому из этих вопросов необходимо определить ответственных исполнителей, сроки выполнения работ, вид конеч­ного результата. В стандарте IEEE 829—1983 (США) большое внимание уде­лено документированию процесса испытания ПП. Перечень доку­ментов, которые разрабатываются и ведутся в соответствии с планом испытания, приведен в разделе «Документирование», Проанализировав содержание выделенных разделов плана испытания/тестирования, можно сделать вывод о целесообраз­ности включения сведений, содержащихся в этих разделах, в про­граммы и методики испытания ПС. Такое включение будет спо­собствовать повышению информативности этих документов и упо­рядочению самого процесса испытаний. На проведение испытаний ПП приходится затрачивать зна­чительные трудовые и материальные ресурсы. Сроки проведения испытаний всегда ограничены. Поэтому перед испытателями все­гда стоит задача поиска путей минимизации затрат материаль­ных, трудовых и временных ресурсов для достижения цели испы­тания. Для реализации этой задачи необходимо установить критерии завершенности Испытаний, которые могут служить осно­вой для принятия решения о завершении испытаний. При оценке уровня завершенности испытаний ПС и достоверности полученных результатов часто возникают серьезные затруднения. Отметим следующие из них: 1) большинство ПС являются уникальными и либо не имеют аналогов для сравнения характеристик, либо имеют аналоги, ха­рактеристики которых неизвестны; 2) отсутствие общепринятых показателей, а также методов расчета требуемых и фактических значений приводит к тому, что в ТЗ на разработку ПС требования к характеристикам ПС либо фактически отсутствуют (в количественном выражении), либо не претендуют на полноту. Рассмотрим пути решения проблемы оценки завершенности испытаний ПС. Но прежде всего обратим внимание на необхо­димость тщательного документирования процесса испытания. Такое документирование следует начать с момента приобретения ПС свойства работоспособности и вести его непрерывно до мо­мента передачи ПС в промышленную эксплуатацию.
Опыт создания отечественных систем реального времени под­тверждает необходимость ведения одного или двух журналов. В одном из них следует регистрировать все эксперименты с ПС, а в другом—обнаруженные ошибки (проблемы) и ход их устранения. Периодически составляют от­четы об испытаниях за определенный период времени. Для ведения журналов необходимо тщательно разработать ин­струкции, в которых установить общие правила заполнения жур­налов, в том числе единые правила присвоения регистрационных номеров ошибкам, индексации типов ошибок, классификации ошибок и т. п. В журналах следует предусмотреть отдельные разделы, в которых при необходимости будут даваться подроб­ные комментарии к ошибкам и способы их устранения.
Не всякую ошибку можно быстро идентифицировать, поэтому в стандарте IEEE 829—1983 рекомендовано документировать в виде отчетов тест-инцидент все нестандартные события, про­исходящие во время испытания и требующие дополнительного анализа. Рекомендуется следующая структура этого отчета: иден­тификатор отчета тест-инцидент, аннотация, описание инцидента, влияние инцидента на последующий ход испытания. Последние два раздела являются основными. Описание инцидента должно включать следующие элементы: входные данные, ожидаемые и фактические результаты, отклонение от нормы, дата и время испытания, шаг процедуры испытания, среда функционирования, результаты попыток повторения условий эксперимента, испыта­тели, наблюдатели-регистраторы. Регистрация экспериментов и ошибок (инцидентов), периоди­ческая обработка данных и анализ результатов позволяют конт­ролировать испытания и управлять этим процессом. Сама про­цедура регистрации может быть разной, важно лишь предотвра­тить потерю ценной информации при минимальных трудозатра­тах на сбор и обработку данных. Данное условие можно обеспе­чить только путем максимальной автоматизации всех процессов. Критерий интенсивности обнаружения ошибок. Если считать, что во время одного эксперимента обнаруживается не более од­ной ошибки и каждая ошибка до начала следующего экспери­мента устраняется, то можно предположить, что при благоприят­ном ходе отладки и испытания кривая зависимости: N = 1 — п/К, где п — количество обнаруженных и устраненных ошибок; К. — . количество экспериментов, будет асимптотически стремиться к единице (кривая 1 на рис. 17). Кривая 2 свидетельствует о не­благополучном ходе процесса. Тогда в качестве критерия прекращения испытаний можно принять, например, следующее условие: N > 0,95 при обнаруже­нии в последних двухстах экспериментах не более трех несуще­ственных ошибок. Идея выбора такого критерия основана на том, что частота обнаружения ошибок, выраженная отношением п/К, по мере увеличения количества экспериментов должна уменьшаться и к моменту завершения испытаний принять значение, близкое к нулю. Следует иметь в виду, что оценка уровня завершенности испы­таний по этому показателю будет достоверной лишь в том случае, если каждый эксперимент проводится в новых условиях и испы­татели стремятся обнаружить ошибки, а не доказать их отсут­ствие. Если же программу проверяют при одних и тех же или близких условиях, то довольно быстро получают кривую вида 1, которая не свидетельствует ни о полноте, ни о глубине проверки программ, ни об отсутствии в ней ошибок. Критерий заданного значения средней наработки на отказ (критерий Дж. Д. Муса). Сделано два предположения. 1. Сум­марное количество обнаруженных и устраненных дефектов в про­ грамме (под дефектом понимается любая причина неудовлетво­ренности свойствами программы) описывается показательной функцией времени функционирования - исходное количество дефектов в программе; - общее количество дефектов, которое может проявиться за время эксплуа­тации ПС; — средняя наработка на отказ в начале испытаний; С—коэффициент сжатия тестов. Коэффициент С1 тогда, когда абсолютная реактивность программы при прогоне тестов или статистических испытаниях отличается от абсолютной реак­тивности при работе программы в реальных условиях. Если, на­пример, за один час испытаний моделируется управляемый про­цесс, происходящий в реальных условиях в течение десяти часов, то коэффициент сжатия С принимается равным 10. Скорость обнаружения и устранения дефектов, измеряемая относительно времени функционирования программы, пропорцио­нальна интенсивности отказов. Коэффициент пропорционально­сти B=n/m называется коэффициентом уменьшения дефектов. Количество зарегистрированных отказов т зависит от суммарного времени функционирования программы следующим образом: Значение средней наработки на отказ также зависит от суммарного времени функционирования: Если в ходе испытания обнаруженные ошибки устраняются, то текущее зна­чение средней наработки на отказ будет увеличиваться. Таким образом, в качестве критерия завершенности испытания можно принять достижение требуемого (заданного) значения средней наработки на отказ Tо. Тогда, определяя периодически текущее значение средней наработки на отказ по этой формуле , можно при планировании дальнейшего хода испытания рассчитать тре­буемое время для дальнейшего про­гона программы по формуле При планировании отладки и ис­пытания ПО следует учитывать влия­ние следующих факторов: 1) скоро­сти выявления дефектов; 2) скорости устранения дефектов; 3) удовлетво­ренности машинным временем. Пер­вый фактор зависит от укомплек­тованности и квалификации испы­тателей, второй—от укомплекто­ванности и квалификации группы программистов отладчиков, третий — от фондовооруженности (технической оснащенности) разрабатывающей (испытывающей) организации. На начальной стадии отладки программы интенсивность вы­явления дефектов высока. Программисты-отладчики перегружены работой, приходится даже прерывать тестовые прогоны, делать перерывы в испытаниях. На заключительной стадии интенсив­ность обнаружения дефектов низкая, но остро ощущается необ­ходимость в машинном времени. Испытатели перегружены в под­готовке все новых и новых тестовых исходных данных, в то время как у программистов-отладчиков работы может быть мало. 4. СТЕНДЫ ОТЛАДКИ И ИСПЫТАНИЯ ПРОГРАММ. Идея имитационного моделирования положена в основу со­здания комплексных имитационно-моделирующих испытательных стендов, используемых для отладки и испытания сложных систем управления в реальном масштабе времени. Комплексный имитационно-моделирующий испытательный стенд (КИМИС) представляет собой совокупность средств испы­тываемой системы и их моделей, модели внешней среды и про­грамм обработки результатов моделирования, функционально объединенных на основе испытываемого программного комплек­са. Комплексные имитационно-моделирующие испыта­тельные стенды используются при полигонных испытаниях сложных систем.
Общая идея создания КИМИС основана на том, что для испы­тания (исследования) ПС, реализованного непосредственно на управляющей ЭВМ, необходимо моделировать управляе­мый процесс и имитировать поступление в ЭВМ информации об этом процессе. Испытываемое ПС безразлично к непосредствен­ным источникам информации. Важно лишь, чтобы вся информа­ция была распределена по реальным физическим каналам ЭВМ и временным тактовым интервалам, а также соответствовала за­данному (ожидаемому) диапазону условий внешней среды. Со­пряжение моделей с реальными средствами системы необходимо для оценки результатов моделирования путем их сравнения с реальными данными. Использование в составе КИМИС непосред­ственно самого ПС, а не его модели, позволяет получить более достоверные результаты при моделировании и избежать больших дополнительных трудозатрат на разработку модели ПС.
Для создания КИМИС, помимо основной ЭВМ, на которой реализуется испытываемое ПС, используют ЭВМ примерно та­кой же производительности для реализации комплекса моделей соответствующего назначения. Первую ЭВМ (ВС) обычно назы­вают технологической, вторую—инструментальной. Инструмен­тальная ЭВМ и программное обеспечение образуют КИМИС. Та­кие КИМИС являются кроссовой системой (КРОСС-КИМИС). Моделируемые (имитируемые) на инструментальной ЭВМ дан­ные передаются в технологическую ЭВМ, где и обрабатываются как реальные данные. Программное обеспечение КИМИС может быть реализовано и на технологической ЭВМ (Резидент-КИМИС). Но такой вариант используется сравнительно редко из-за дефи­цита памяти и производительности в технологических (управля­ющих) ЭВМ. Автоматизированный технологический комплекс (АТК) со­стоит из элементов следующих типов: управляемый технологиче­ский агрегат (УТА), автоматизированная система управления технологическим процессом (АСУ ТП), датчики информации (ДИ) о состоянии управляемого процесса. На вход АТК посту­пает объект обработки (00), на выход—результат обработки (РО). Если прекратить доступ информации в ЭВМ от реальных физических объектов АТК, а вместо нее вводить адекватную ин формацию, имитируемую по КИМИС на инструментальной ЭВМ , то процесс функционирования ПО АСУ ТП бу­дет адекватен реальному. Оператор УТА в принципе может участвовать в обеих режимах. Программное обеспечение КИМИС в общем случае состоит из следующих подсистем: моделирования, анализа результатов испытания, регистрации событий (документирования), планиро­вания и управления и базы данных (рис. 20). В состав подсистемы моделирования входят: модель заявок на обработку (МЗ), модель объекта обработки (МОО); модели датчиков информации (МДИ); имитатор помех (ИП); модель управляемого технологического агрегата (МТА). Модель заявок имитирует поток заявок на обработку (напри­мер, поток слябов) исходя из плановых и производственных соображений В соответствии с заданным приоритетом или случай­ным образом выбирается 00, принимаемый на обслуживание, из совокупности 00, имитируемой МЗ, и его характеристики. Моде­ли датчиков информации являются информационными моделями конкретных типов датчиков информации, используемых в систе­ме управления АТК. Они имитируют выдачу текущих координат характеризующих состояние технологического процесса. Модель управляемого технологического агрегата (например, прокатного стана) имитирует управляемый технологический процесс (напри­мер, прокатки стали) с выдачей соответствующей информации об этом процессе. Имитатор помех в соответствии с заданными вероятностными характеристиками имитирует воздействие слу­чайных факторов на элементы моделируемой системы и управ­ляемый процесс. При этом используется датчик случайных чисел, позволяющий реализовать процедуру «розыгрыш». Таким образом, подсистема моделирования, имитируя техно­логический процесс в управляемом агрегате, обеспечивает вос­произведение потока входной информации в управляющую ЭВМ, адекватного этому потоку в реальных условиях эксплуатации АТК. Имитируемый поток входной информации подается' на вход испытываемого ПО АСУ и инициирует его функционирование, результатом которого является поток выходной (управляющей) информации, выдаваемый на УТА или его модель. Образуется замкнутый контур управления, адекватный контуру управления в реальном ДТК. Основными компонентами подсистемы анализа результатов испытаний являются: программа выборки результатов преобра­зования входных данных, программы формирования эталонных значений для анализа правильности результатов, программа сравнения фактических результатов с эталонными и оценки их приемлемости (правильности). Подсистема регистрации событий обеспечивает документиро­вание хода испытаний и регистрацию всех тех характеристик, которые могут быть полезны как для определения значений пока­зателей качества испытываемого ПС, так и для оценки эффек­тивности и состояния самого процесса испытаний. Подсистема планирования и управления на основе анализа состояния испытаний, полученных результатов, проверенных пу­тей граф-схемы испытываемого ПС и поступающих заданий от программистов-испытателей осуществляет планирование экспе­риментов и подготовку соответствующих исходных данных для подсистемы моделирования. На эту же подсистему возлагается координация действий (инициализация) всех элементов КИМИС. Достоинства КИМИС очевидны. Его использование позволяет осуществлять комплексную стыковку объектов испытываемой системы и проверку принципов управления задолго до создания всех элементов системы (элемент системы, разработка которого не завершена, заменяется моделью). Применение моделирования позволяет разнообразить условия испытания и сэкономить мате­риальные ресурсы. Комплексные испытательные моделирующие стенды можно использовать не только для испытания программ, но и для отработки взаимодействия всех элементов системы. Сопряжение реальных средств испытываемой системы с их моделями позволяет разнообразить условия испытания и про­вести полунатурные эксперименты. Можно, например, проверить работу автоматизируемого технологического агрегата, моделируя поведение объекта обработки или, наоборот, промоделировать работу технологического агрегата при работе с реальным объек­том обработки. Такие вариации позволяют, с одной стороны, про­верять адекватность моделей своим оригиналам и тем самым убеждаться в достоверности результатов статистических испыта­ний, а, с другой стороны, использовать КИМИС на самых ранних этапах разработки опытного образца ПС для выбора и апробации наилучших проектных решений. IV. СЕРТИФИКАЦИЯ ПРОГРАММНЫХ ПРОДУКТОВ. 1. СТАНДАРТИЗАЦИЯ СИСТЕМ КАЧЕСТВА. В начале 70-х годов многие специалисты пришли к выводу о необходимости широкого распро­странения индустриальных (инженерных) методов в области по­строения программ (см, § 1.1). Индустриальные методы бази­руются на строгой регламентации и автоматизации технологиче­ских процессов. Таким образом, стандартизация и в области по­строения программ стала жизненной необходимостью.
В рамках Единой Системы Про­граммной Документации (ЕСПД) разработано и введено в дей­ствие около тридцати стандартов, упорядочивающих разработку программной документации. Многие виды стандартов для про­граммной продукции еще не разработаны (общие технические требования, общие технические условия, технические условия на виды ПП, номенклатура показателей качества, методы выполне­ния отдельных видов работ в технологических процессах, порядок проведения этих работ и др.).
При разработке ПМК системы УК ПП приняты следующие исходные положения: 1) разработка ПП осуществляется в соответствии с действую­щими стандартами, техническими условиями, ТЗ или иными заме­няющими его документами, содержащими требования к качеству ПП, установленные на основании анализа требований конкрет­ного и (или) потенциального пользователя к потребительским свойств данного вида ПП; 2) качество ПП обеспечивается преимущественно в процессе его разработки; по завершению каждого этапа разработки про­екта должен проводиться документированный, систематический и критический анализы результатов разработки; 3) за качество разрабатываемой ПП ответственность несет разработчик, поставляемой — поставщик; 4) руководство организации — разработчика несет ответствен­ность за определение политики в области качества и за решения, касающиеся разработки, внедрения и ведения системы качества; 5) управление качеством ПП основывается прежде всего на стимулировании заинтересованности разработчиков и поставщи­ков в обеспечении высокого качества ПП, повышении профессио­нализма: 6) для обеспечения требуемого качества ПП управление каче­ством осуществляется на всех стадиях и этапах жизненного цикла ПП, начиная с самых ранних; 7) в разрабатывающей организации должны быть определены система качества (управляющие органы и лица, несущие ответ­ственность за качество), а также политика в области качества ПП; ответственность и полномочия за каждый вид деятельности, влияющей на качество ПП; определение обязанностей и полномо­чий должно обеспечивать достижение поставленных целей на заданном уровне эффективности; 8) управление качеством ПП базируется на контроле качества в процессе разработки; 9) все формализуемые функции, процедуры и операции по управлению качеством в конечном счете должны быть переданы ЭВМ и реализованы на ней в виде инструментальных программ; 10) в идейном (концептуальном) плане инструментальные программы и методики, входящие в состав ПМК, должны пред­ставлять единое целое, согласующееся с принятой технологией программирования и являющееся составной частью этой техноло­гии; 11) в составе ПМК подсистемы У К ПП можно выделить базо­вую (условно постоянную) и переменную части. Базовая часть-ПМК разрабатывается как типовое проектное решение с исполь­зованием принципов модульной структуры и может быть исполь­зована в различных организациях, независимо от ведомственной принадлежности и собственной специфики. Переменная часть-ПМК учитывает специфику разрабатывающей организации, структуры и задач подсистемы УК ПП. Она создается в конкрет­ной организации путем настройки базовой части ПМК и разра­ботки новых, недостающих частей подсистемы УК ПП; 12) все компоненты базовой части ПМК должны обладать свойствами автономности (независимости) разработки, настройки и применения. Однако наибольший эффект должен достигаться от комплексного использования всех компонентов ПМК. Основными методами стандартизации УК ПП в разрабатывающей организации являются: систематизация и классификация: типизация и унификация; регламентирование. Систематизация и классификация направлены на упорядоче­ние элементов управления (ГКК, СКК и др.), установление их прав и обязанностей, а также взаимодействия между ними. Типизация и унификация направлены на выявление и форми­рование сходных компонентов программ и программных комплексов по профилю организации, па создание библиотек унифициро­ванных компонентов, средств генерации программ из этих ком­понентов, интерфейсных соглашении. Регламентирование направлено на упорядочение организаци­онных и технологических процедур по обеспечению требуемого уровня качества на всех стадиях жизненного цикла ПП. В США, например, в середине 80-х годов введены в действие следующие стандарты: ANSI/IEEE «Спецификация требований к ПО» (Guide to Software Requirements Specifications); «Планирование управления конфигурацией ПО» (Software Configuration Management Plans); «Документирование тестов ПО» (Software Test Documentation); «Планирование уровня качества ПО» (Software Quality Assurance Plan?). В качестве про­ектов апробируются и другие стандарты, в том числе «Справочник гарантии качества», «Классификация отказов, сбоев и ошибок ПО». При организации управления качеством ПП многие полезные рекомендации можно заимствовать из соответствующих стан­дартов по управлению качеством промышленной продукции. В 1987 г. утверждено пять международных стандартов ISO, уста­навливающих требования к системам обеспечения качества про­дукции на предприятиях: «Стандарты по управлению качеством и обеспечению качества. Руководство для выбора и применения» (ISO 9000); «Система качества. Модели обеспечения качества при проектировании, разработке, производстве, монтаже и обслужи­вании» (ISO 900S); «Система качества. Модели обеспечения качества при производстве и монтаже» (ISO 9002); «Система качества. Модели обеспечения качества в процессе контроля и испытания готовой продукции» (ISO 9003); «Управление каче­ством и элементы системы качества. Основные направления» (ISO 9004). 2. КЛАССИФИКАЦИЯ ПОКАЗАТЕЛЕЙ КАЧЕСТВА Под показателем качества программной продукции в соответ­ствии с ГОСТ 15467—79 следует понимать количественную характеристику одного или нескольких свойств продукции, состав­ляющих ее качество, рассматриваемую применительно к опре­деленным условиям ее создания и эксплуатации. Свойство про­дукции — это объективная особенность, которая может проявиться при создании или эксплуатации продукции. В определении поня­тия «Показатель качества» слова «Количественная характеристи­ка» не следует понимать в буквальном смысле. При определении значений показателей качества успешно могут применяться и не­числовые характеристики, хотя в общем случае наличие строго количественных, числовых характеристик предпочтительней. Показатели качества программной продукции в зависимости от характера решаемых задач по оценке качества продукции можно классифицировать по следующим признакам: характери­зуемые свойства; способ выражения; количество характеризуемых свойств; место применения в процедуре оценки; стадии опреде­ления значений показателей. По способу выражения различают показатели, выраженные в натуральных единицах, и показатели, выраженные в стоимостных единицах. В качестве натуральных единиц обычно используют единицы физических величин (килограммы, метры, секунды и т. п.), а также баллы и безразмерные единицы. ПС являются информационными объектами. Какими-либо собствен­ными физическими свойствами они не обладают, поэтому едини­цы физических величин в традиционном виде при определении значений показателей качества ПС почти не применяются, за исключением единиц времени. Но как составной элемент системы обработки данных ПС вносит определенную долю погрешности в точность выходных результатов. Эта погрешность может изме­ряться в единицах преобразуемых физических величин. Вместе с тем в программировании широко используют такие натуральные единицы, как бит, байт, условная машинная команда, строка тек­ста и т. п. Стоимостные единицы применяют при определении значений экономических показателей качества программной про­дукции.
По количеству характеризуемых свойств различают единичные и комплексные показатели. Единичные показатели качества ха­рактеризуют одно из свойств ПС, комплексный—несколько. Комплексные показатели могут быть групповыми, обобщенными или интегральными. В зависимости от места применения в процедуре оценки уров­ня качества ПС различают базовые и относительные показатели. Базовым значением показателя качества продукции называют значение показателя, принятое за основу при сравнительной оценке качества продукции. Относительное значение показателя качества продукции представляет собой отношение фактического значения показателя качества оцениваемой продукции к базовому значению этого показателя.
По стадии определения значений показателей качества раз­личают прогнозируемые, проектные, производственные и эксплуа­тационные показатели. Прогнозируемыми показателями опери­руют на стадиях выполнения научно-исследовательских работ и составления ТЗ на разработку ПС, т. е. на тех стадиях, когда нет еще ни детального проекта ПС, ни, тем более, самого ПС. Значения прогнозируемых показателей в основном определяют на основе интуиции и опыта аналогичных разработок, поэтому эти показатели носят субъективный характер. Значения проектных показателей определяют на основе ана­лиза проектов ПС (эскизного, технического, рабочего), а также путем испытания опытного образца ПС. Эти показатели носят более объективный характер. Степень их достоверности зависит от эффективности используемых инструментальных средств ана­лиза и испытания. Производственные показатели мало отличаются от проектных, особенно если изготовление ПС сводится к простому копирова­нию. Если же копированию предшествуют операции сборки или генерации ПС, то производственные показатели качества таких ПС могут существенно отличаться от проектных. Значения эксплуатационных показателей определяют по ре­зультатам промышленной эксплуатации ПС. При соблюдении определенных правил сбора и обработки данных о качестве ПС в процессе эксплуатации эксплуатационные показатели дают наиболее объективную и достоверную оценку. Только по этим показателям можно произвести действительную оценку научно-технического уровня и качества ПС. 3. ВЫБОР НОМЕНКЛАТУРЫ ПОКАЗАТЕЛЕЙ КАЧЕСТВА Выбор номенклатуры показателей качества программной про­дукции заключается в установлении перечня наименований ха­рактеристик свойств продукции, определяющих качество данного вида продукции и обеспечивающих возможность полной и досто­верной оценки ее уровня качества. Порядок выбора номенклату­ры показателей качества программной продукции должен уста­навливаться с учетом специфики этой продукции. Выбор номенклатуры показателей качества кон­кретного ПС зависит от вида (группы) ПС, цели применения и стадии определения показателей. Для каждого вида (группы), а иногда и конкретного ПС уста­навливают свою номенклатуру показателей качества, учитываю­щую специфику назначения п условий применения. Номенклатура показателей качества для каждого под­класса, группы и вида ПС оформляется в виде таблиц применяе­мости показателей качества. Помимо перечня рекомендуемых и обязательных показателей качества для данного подкласса (вида, группы) ПС, в таблицах применяемости следует указы­вать и коэффициенты (параметры) весомости (значимости) каж­дого из показателей. Определение коэффициентов весомости показателей качества — наиболее существенная и трудная задача выбора номенклатуры показателей качества. В принципе при ре­шении этой задачи можно использовать либо метод стоимостно-регрессионных зависимостей, либо метод предельных номиналь­ных значений. Но их использование затруднено из-за отсутствия необходимых исходных данных. Поэтому на практике наиболее распространен экспертный метод определения коэффициентов весомости. Таблицы применяемости являются руководящим или справоч­ным материалом для выбора рабочей номенклатуры показателей качества конкретного ПС. Рабочая номенклатура ПС устанавли­вается с учетом назначения и условий использования ПС; резуль­татов анализа требований пользователя (заказчика), поставленных задач управления качеством; состава, структуры и специ­фики характеризуемых свойств. Цели применения номенклатуры показателен качества уста­навливают в соответствии с задачами управления качеством программной продукции. Такими целями, в частности, могут быть следующие: составление технического задания па разработ­ку ПС; составление технических условии на ПС; заполнение кар­ты технического уровня; установление контролируемых показа­телей при проектировании ПС; установление контролируемых показателей при опытной эксплуатации ПС; аттестация ПС по категориям качества. Стадии определения значении показателей качества соответст­вуют стадиям жизненного цикла ПС. При выделении свойств и соответствующих показателей каче­ства ПС необходимо руководствоваться следующими основными принципами : выделение групп свойств должно производиться по четко определенным признакам; свойства, входящие в одну группу, должны, как правило, вза­имно исключать друг друга и быть независимыми. Если свойст­ва зависят друг от друга, то в методиках определения значении показателей качества должны быть даны четкие указания по исключению многократного (неоднократного) влияния одного и того же свойства на обобщенную оценку качества ПС; всякая исходная номенклатура показателей должна быть открытой, т. е. должна допускать возможность внесения мне исключения из нее отдельных элементов. Это требование обу­словлено, с одной стороны, недостаточным опытом оценки каче­ства программной продукции, а с другой,—большим разнообра­зием ПС и условий их применения; для каждого из выделенных свойств должна существовать возможность выражения их в шкалах «лучше — хуже», «боль­ше — меньше»; в группу следует включать свойства, необходимые и достаточные для определения соответствующего сложного свойства; формулировка свойств должна быть однозначной; совокупность свойств, характеризующих качество оценивае­мого ПС, должна быть упорядочена по определенному правилу в виде многоуровневой иерархической структуры — дерева свойств; дерево свойств должно отражать все основные особенности использования н функционирования ПС; выбранные показатели качества должны быть скоррелнрованы с соответствующими свойствами ПС. Это значит, что между каждым из выделенных свойств и характеризующими его показа­телями должно быть установлено однозначное соответствие. Установление такого соответствия позволяет вместо дерева свойств использовать дерево показателей качества программной продукции; показатели качества, характеризующие свойства ПС, должны способствовать обеспечению соответствия качества ПС требова­ниям со стороны их пользователей и учитывать современные достижения науки и техники. Для выполнения этого принципа часто необходимо проводить специальные исследования, так как в общем случае между показателями качества могут возникать серьезные противоречия, а улучшение одного показателя может привести к ухудшению другого.
Для проверки работоспособности выбранной системы показа­телей качества необходимо устанавливать степень корреляции каждого рассматриваемого показателя с качеством ПС, полез­ность показателя, возможность количественного представление и автоматической оценки показателя. В частности, оценку полезности каждого из выбранных показателей для конкретных ПС рекомендуется производить по следующей шкале:
5—крайне важно, чтобы данный показатель имел высокое значение; 4—важно, чтобы данный показатель имел высокое значение; 3—хорошо бы иметь высокое значение данного показателя; 2— в некоторой степени полезно иметь высокое значение дан­ного показателя; 1—при низких значениях данного показателя ощутимых по­терь нет, Около 50 % частных показателей можно определить автоматически с помощью ЭВМ, 25 % —с помощью компаратора. Таким обра­зом, оценка около 75 % показателей может быть формализована. Оценка 20 % показателей может быть произведена только квалифицированным специалистом. Большинство показателей устанавливают путем статического анализа программ и лишь около 5 % — в процессе динамических испытаний (Данные соответствуют положению в этой области в 80-е годы). Следует иметь в виду, что оценка качества, а следовательно, к выбор показателей качества сложных многофункциональных про­граммных комплексов типа операционных систем, систем управ­ления базами данных, пакетов прикладных программ и так да­лее имеет свои особенности. Каждая функция таких ПС реали­зуется программным путем, задающим определенный технологи­ческий процесс преобразования входных данных в выходные. Известны цель этого процесса и потребность в нем, Для того чтобы удовлетворить эту потребность, ПС должна обладать определенными свойствами. Причем свойства ПС, удовлетворяю­щие потребности в одной функции, могут существенно отличаться от свойств ПС, необходимых для реализации другой функции. Поэтому степень удовлетворения потребности в выполнении каж­дой из функций ПС в общем случае характеризуется своими показателями или, по крайней мере, параметрами весомости по­казателей. Возникает необходимость выбора показателей и опре­деления их весомости для оценки качества (эффективности) реа­лизации каждой из основных функций ПС. Попытка выбора еди­ной номенклатуры показателей качества оказывается, как пра­вило, безрезультатной. В этом можно легко убедиться на примере оценки качества операционных систем (ОС) ЭВМ. На ОС ЭВМ возлагаются следующие функции: управление данными, задания­ми, вводом-выводом; обслуживание библиотек пользователей; трансляция и редактирование программ; протоколирование со­стояний и событий; перезапись и сортировка информации и др. Очевидно, что требования, например, к трансляторам существен­но отличаются от требований к ПС протоколирования событий как по своему перечню, так и по весомости каждого из показате­лей. В свою очередь различие требований обусловливает необхо­димость использования различных показателей качества, харак­теризующих потребительские свойства программ, реализующих эти функции. 4. ГРУППЫ ПОКАЗАТЕЛЕЙ КАЧЕСТВА Любому классу продукции присущи определенные свойства, характерные для данного класса. В свою очередь каждый под­класс, группа, вид этой продукции имеет частные свойства, отличающие изделия одной классификационной груп­пировки от другой. Рассмотрим формирование номенклатуры по­казателей качества, характеризующей общие свойства класса программной продукции. Эта номенклатура может быть исполь­зована в качестве исходной при выборе рабочей номенклатуры показателей качества любого конкретного ПС. Номенклатуры показателей качества всегда имеют иерархиче­скую структуру. Их формирование начинается с выделения групп верхнего уровня иерархии, а затем номенклатуры детализиру­ются вплоть до получения единичных показателей. Выделение групп показателей качества является важной и сложной задачей формирования номенклатуры показателей каче­ства. Неудачное комплектование групп может привести к услож­нению взаимосвязей между группами и отдельными показателя­ми, а также сделать номенклатуру показателей качества мало­конструктивной. Известно, что для оценки качества промышленной продукции используют следующие группы показателей: на­значения; экономичного использования сырья, материалов, топ­лива, энергии; надежности; эргономичности; эстетичности; техно­логичности; патентно-правовые; унификации и стандартизации; экологичности; безопасности. Все эти показатели можно использовать и при оценке качества ПП. По в силу особенностей ПП некоторые группы показателей при оценке ее качества применять нецелесообразно (неконструк­тивно). К таким показателям относят показатели экологичности, безопасности. Экологические показатели и показатели безопасности нехарактерны для ПП, так как программные изделия непосредст­венно не могут оказывать вредных воздействий ни на окружаю­щую среду, ни на здоровье человека. В принципе, такие воздей­ствия возможны в тех случаях, когда ПИ используют в качестве элементов управляющих объектов, например в АСУ. В этом слу­чае вырабатываемые ЭВМ по определенному алгоритму управ­ляющие воздействия могут вызвать и неблагоприятные экологи­ческие последствия, и быть опасными для человека. Но это уже косвенное воздействие через управляющие органы и исполни­тельные механизмы автоматизированных технологических ком­плексов (АТК). Они учитываются как соответствующие показа­тели AT К. Патентно-правовые показатели программной продукции не могут быть использованы до тех пор, пока вопросы патентно-правовой защиты этой продукции не будут решены в законодатель­ном (юридическом) плане. Относительно надежности программной продукции сущест­вует много противоречивых мнений. Вместе с тем большинство специалистов единодушны в мне­нии о том, что природа надежности программных и технических средств различна. Для программной продукции малопродуктив­ными являются такие показатели надежности, как долговечность, сохраняемость, ремонтопригодность. Источниками низкой надеж­ности ПС в основном являются ошибки в программах, внесенные на стадии проектирования и невыявленные при отладке и испыта­ниях. Заслуживает внимания мнение американского специалиста Фокса Д., который считает, что использование термина «надеж­ность программного обеспечения» наносит вред, так как способ­ствует неправильному пониманию природы программного обеспе­чения . Вместе с тем следует учитывать тот факт, что при анализе некоторых свойств ПП, проявляющихся при ее функцио­нировании, приходится пользоваться категориями надежности (работоспособность, отказ, сбой, восстановление и др.). Поэтому в номенклатуре показателей качества ПП признано целесообраз­ным выделять в отдельную группу показатели, характери­зующие свойства ПП, близкие по своим внешним проявлениям показателям надежности аппаратуры. Эта группа названа пока­зателями надежности функционирования. Таким образом, в базовой номенклатуре показателей качества ПП на верхнем уровне выделяем следующие показатели: назна­чения, надежности функционирования, эргономичности, техноло­гичности, унификации и стандартизации. Качество ПП в основ­ном формируется в процессе создания продукции и в значитель­ной мере зависит от эффективности структурных (конструктив­ных) решений. Поэтому на этом же уровне в отдельную группу выделим структурные показатели.
Показатели назначения, надежности функционирования, эрго­номичности и технологичности характеризуют свойства ПП, про­являющиеся в процессе ее использования (эксплуатации). По этому признаку их можно считать эксплуатационными. Структур­ные показатели и показатели унификации и стандартизации характеризуют свойства структуры (конструкции) ПС, их можно объединить в одну группу конструктивных показателей. По отно­шению к группе эксплуатационных показателей эта группа носит вспомогательный характер. Достижение определенного уровня значений этих показателей не может служить самоцелью, это лишь средство (путь) обеспечения требуемых значений одного или нескольких показателей, относящихся к основной группе — группе эксплуатационных показателей.
СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ: 1. Майерс. Искусство тестирования программного обеспечения. 2. Майерс. Надежность программного обеспечения. 3. Кулаков. Управление качеством программного обеспечения.