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

ВВЕДЕНИЕ

Многие организации, занимающиеся созданием программного обеспечения, до 50% средств, выделенных на разработку программ, тратят на тестирование, что составляет миллиарды долларов по всему миру в целом. И все же, несмотря на громадные капиталовло¬жения, знаний о сути тестирования явно не хватает и большинство программных продуктов неприемлемо ненадежно даже после «ос¬новательного тестирования». О состоянии дел лучше всего свидетельствует тот факт, что боль¬шинство людей, работающих в области обработки данных, даже не может правильно определить слово «тестирование», и это на самом деле главная причина неудач. «Тестирование — процесс, подтверждающий правильность програм¬мы и демонстрирующий, что ошибок в программе нет ». Основной недостаток подобного определения заключается в том, что оно совершенно неправильно; фактически это почти определение анто¬нима слова «тестирование». Читатель с некоторым опытом програм¬мирования уже, вероятно, понимает, что невозможно продемонст¬рировать отсутствие ошибок в программе. Поэтому определение описывает невыполнимую задачу, а так как тестирование зачастую все же выполняется с успехом, по крайней мере с некоторым успе¬хом, то такое определение логически некорректно. Правильное определение тестирования таково: Тестирование — процесс выполнения программы с намерением найти ошибки.

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

Цель курсовой работы: Самостоятельно изучить модели тестирования программного обеспечения

Объект курсовой работы: Информационные технологии

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

1.ТЕСТИРОВАНИЕ И ОТЛАДКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

1.1 Фундаментальный принцип тестирования

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

Рисунок 1.1 - Спектр подходов к проектированию тестов

Сторонник подхода, соответствующего левой границе спектра, проектирует свои тесты, исследуя внешние спе¬цификации или спецификации сопряжения программы или модуля, которые он тестирует. Программу он рассматривает как черный ящик. Позиция его такова: «Меня не интересует, как выглядит эта программа, и выполнил ли я все команды или все пути. Я буду удовлетворен, если программа будет вести себя так, как указано в спецификациях. Его идеал — проверить все возможные комбина¬ции и значения на входе.[2]

Приверженец подхода, соответствующего другому концу спект¬ра, проектирует свои тесты, изучая логику программы. Он начинает с того, что стремится подготовить достаточное число тестов для того, чтобы каждая команда была выполнена, по крайней мере, один раз. Если он немного более искушен, то проектирует тесты так, чтобы каждая команда условного перехода выполнялась в каждом направлении хотя бы раз. Его идеал — проверить каждый путь, каждую ветвь алгоритма. При этом его совсем (или почти со¬всем) не интересуют спецификации. Ни одна из этих крайностей не является хорошей стратегией. Читатель, однако, уже, вероятно, заметил, что первая из них, а именно та, в соответствии с которой программа рассматривается как черный ящик, предпочтительней. К сожалению, она страдает тем недостатком, что совершенно неосуществима. Рассмотрим по¬пытку тестирования тривиальной программы, получающей на входе три числа и вычисляющей их среднее арифметическое. Тестирова¬ние этой программы для всех значений входных данных невозмож¬но. Даже для машины с относительно низкой точностью вычислений количество тестов исчислялось бы миллиардами. Даже имей мы вычислительную мощность, достаточную для выполнения всех тес¬тов в разумное время, мы потратили бы несколько циклов больше времени для того, чтобы эти тесты подготовить, а затем проверить. Такие программы, как системы реального времени, операционные системы и программы управления данными, которые сохраняют «память» о предыдущих входных данных, еще хуже. Нам потребовалось бы тестировать программу не только для каждого входного значения, но и для каждой последовательности, каждой комбинации входных данных. Поэтому исчерпывающее тестирование для всех входных данных любой разумной программы неосущест¬вимо. Эти рассуждения приводят ко второму фундаментальному прин¬ципу тестирования: тестирование — проблема в значительной сте¬пени экономическая. Поскольку исчерпывающее тестирование не¬возможно, мы должны ограничиться чем-то меньшим. Каждый тест должен давать максимальную отдачу по сравнению с нашими затра¬тами. Эта отдача измеряется вероятностью тою, что тест выявит не обнаруженную прежде ошибку. Затраты измеряются временем и стоимостью подготовки, выполнения и проверки результатов теста. Считая, что затраты ограничены бюджетом и графиком, можно ут¬верждать, что искусство тестирования, по существу, представляет собой искусство отбора тестов с максимальной отдачей. Более того, каждый тест должен быть представителем некоторого класса вход¬ных значений, так чтобы его правильное выполнение создавало у нас некоторую убежденность в том, что для определенного класса входных данных программа будет выполняться правильно. Это обычно требует некоторого знания алгоритма и структуры програм¬мы, и мы, таким образом, смещаемся к правому концу спектра.[6]

1.2 Интеграция модулей

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

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

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

Нисходящее тестирование называемое также нисходящей раз¬работкой не является полной противоположностью, но в первом приближении может рассматриваться как тако¬вое, При нисходящем подходе программа собирается и тестируется сверху вниз. Изолировано тестируется только головной модуль. После того как тестирование этого модуля завершено, с ним соеди¬няются (например, редактором связей) один за другим модули, непосредственно вызываемые им, и тестируется полученная комби¬нация. Процесс повторяется до тех пор, пока не будут собраны и проверены все модули. При этом подходе немедленно возникает два вопроса: что де¬лать, когда тестируемый модуль вызывает модуль более низкого уровня (которого в данный момент еще не существует), и как подаются тестовые данные. Для имитации функций недостающих модулей программируются модули-заглушки, которые моделируют функции отсутствующих модулей. Фраза «просто напишите заглушку» часто встречается в описании этого подхода, но она способна ввести в заблуждение, поскольку задача написания заглушки» может оказаться трудной. Ведь заглушка редко сводится просто к оператору RETURN, поскольку вызывающий модуль обычно ожидает от нее выходных параметров. В таких случаях в заглушку встраивают фиксирован¬ные выходные данные, которые она всегда и возвращает. Это иногда оказывается неприемлемым, так как вызывающий модуль может рассчитывать, что результат вызова зависит от входных данных. Поэтому в некоторых случаях заглушка должна быть довольно изощ¬ренной, приближаясь по сложности к модулю, который она пытается моделировать.[7]

Тесты пишутся в виде обычных для пользователей внешних данных и передаются программе через выделенные ей устройства ввода. Так, однако, случается редко. В хорошо спроектированной програм¬ме физические операции ввода-вывода выполняются на нижних уровнях структуры, поскольку физический ввод-вывод — абстрак¬ция довольно низкого уровня. Поэтому для того, чтобы решить проблему экономически эффективно, модули добавляются не в стро¬го нисходящей последовательности (все модули одного горизонталь¬ного уровня, затем модули следующего уровня), а таким образом, чтобы обеспечить функционирование операций физического ввода-вывода как можно быстрее. Когда эта цель достигнута, нисходящее тестирование получает значительное преимущество: все дальнейшие тесты готовятся в той же форме, которая рассчитана на пользователя. Остается еще один вопрос, в какой форме пишутся тесты до тех пор, пока не будет достигнута эта цель? Ответ: они включаются в некоторые из заглушек. Нисходящий метод имеет как достоинства, так и недостатки по сравнению с восходящим. Самое значительное достоинство — в том, что этот метод совмещает тестирование модуля, тестирова¬ние сопряжении и частично тестирование внешних функций. С этим же связано другое его достоинство — когда модули ввода-вывода уже подключены, тесты можно готовить в удобном виде. Нисходя¬щий подход выгоден также в том случае, когда есть сомнения от¬носительно осуществимости программы в целом или если в проек¬те программы могут оказаться серьезные дефекты. Преимуществом нисходящего подхода очень часто считают от¬сутствие необходимости в драйверах; вместо драйверов вам просто следует написать заглушки. Как читатель сейчас уже, вероятно, понимает, это преимущество спорно. Нисходящий метод тестирования имеет, к сожалению, некоторые недостатки. Основным из них является тот, что модуль редко тес¬тируется досконально сразу после его подключения. Дело в том, что основательное тестирование некоторых модулей может потре¬бовать крайне изощренных заглушек. Программист часто решает не тратить массу времени на их программирование, а вместо этого пишет простые заглушки и проверяет лишь часть условий в модуле. Он, конечно, собирается вернуться и закончить тестирование рас¬сматриваемого модуля позже, когда уберет заглушки. Такой план тестирования определенно не лучшее решение, поскольку об от¬ложенных условиях часто забывают. Второй тонкий недостаток нисходящего подхода состоит в том, что он может породить веру в возможность начать программирова¬ние и тестирование верхнего уровня программы до того, как вся программа будет полностью спроектирована. Эта идея на первый взгляд кажется экономичной, но обычно дело обстоит совсем наобо¬рот. Большинство опытных проектировщиков признает, что проекти¬рование программы — процесс итеративный. Редко первый проект оказывается совершенным. Нормальный стиль проектирования структуры программы предполагает по окончании проектирования нижних уровней вернуться назад и подправить верхний уровень, внеся в него некоторые усовершенствования или исправляя ошибки, либо иногда даже выбросить проект и начать все сначала, потому что разработчик внезапно увидел лучший подход. Если же головная часть программы уже запрограммирована и оттестирована, то воз¬никает серьезное сопротивление любым улучшениям ее структуры. В конечном итоге за счет таких улучшений обычно можно сэконо¬мить больше, чем те несколько дней или недель, которые рассчиты¬вает выиграть проектировщик, приступая к программированию слишком рано. Нисходящий подход имеет еще один существенный недостаток, касающийся полноты тестирования. При проектировании и программировании модуля с такой функцией всегда следует понимать, что квадратное уравнение может иметь как действительные, так и комплексные корни. Для полной реали¬зации этой функции необходимо, чтобы результаты могли быть дей¬ствительными или комплексными числами (или, если дополнитель¬ные затраты на нахождение комплексных корней не оправданы, модуль должен по крайней мере возвращать код ошибки в случае, когда входные коэффициенты задают уравнение с комплексными корнями). Предположим, что конкретный контекст, в котором используется модуль, исключает комплексные корни (т. е. вызы¬вающие модули никогда не задают входных параметров, которые привели бы к комплексным корням). При строго нисходящем методе иногда бывает невозможно тестировать модуль для случая комплек¬сных корней (или тестировать ошибочные условия). Можно попы¬таться оправдывать это тем, что, поскольку такое уравнение никогда не будет дано модулю, никого не должно заботить, работает ли он и в этих случаях. Да, это безразлично сейчас, но окажется важным в будущем, когда кто-то попытается использовать модуль в новой программе или модифицировать старую программу так, что станут возможными и комплексные корни.

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

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

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

2.СЕРТИФИКАЦИЯ И СТАНДАРТИЗАЦИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

2.1 Технологическая схема испытания

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

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

2.2 Стандартизация систем качества программ

Индустриальные методы бази¬руются на строгой регламентации и автоматизации технологиче¬ских процессов. Таким образом, стандартизация и в области по¬строения программ стала жизненной необходимостью. В рамках Единой Системы Про¬граммной Документации разработано и введено в дей¬ствие около тридцати стандартов, упорядочивающих разработку программной документации. Многие виды стандартов для про¬граммной продукции еще не разработаны (общие технические требования, общие технические условия, технические условия на виды программного продукта, номенклатура показателей качества, методы выполне¬ния отдельных видов работ в технологических процессах, порядок проведения этих работ). Систематизация и классификация направлены на упорядоче¬ние элементов управления (ГКК, СКК и др.), установление их прав и обязанностей, а также взаимодействия между ними. На рисунке2.1 показана типизация и унификация, направленная на выявление и форми¬рование сходных компонентов программ и программных комплексов по профилю организации, па создание библиотек унифициро¬ванных компонентов, средств генерации программ из этих ком¬понентов, интерфейсных соглашений.[1]

В США, например, в середине 80-х годов введены в действие следующие стандарты: ANSI Спецификация требований к ПО (Guide to Software Requirements Specifications); Планирование управления конфигурацией ПО (Software Configuration Management Plans); Документирование тестов ПО (Software Test Documentation); Планирование уровня качества ПО (Software Quality Assurance Plan). В качестве про¬ектов апробируются и другие стандарты, в том числе Справочник гарантии качества, Классификация отказов, сбоев и ошибок. При организации управления качеством многие полезные рекомендации можно заимствовать из соответствующих стан¬дартов по управлению качеством.

Рисунок 2.1 - Испытание программного продукта

В 1987 г. утверждено пять международных стандартов ISO, уста¬навливающих требования к системам обеспечения качества про¬дукции на предприятиях: Стандарты по управлению качеством и обеспечению качества. Руководство для выбора и применения (ISO 9000); Система качества. Модели обеспечения качества при проектировании, разработке, производстве, монтаже и обслужи¬вании (ISO 900S); Система качества. Модели обеспечения качества при производстве и монтаже (ISO 9002); Система качества. Модели обеспечения качества в процессе контроля и испытания готовой продукции (ISO 9003); Управление каче¬ством и элементы системы качества. Основные направления (ISO 9004).[3]

2.3 Классификация показателей качества программ

Под показателем качества программной продукции в соответ¬ствии с ГОСТ 15467—79 следует понимать количественную характеристику одного или нескольких свойств, состав¬ляющих ее качество, рассматриваемую применительно к опре¬деленным условиям ее создания и эксплуатации. Свойство про¬дукции — это объективная особенность, которая может проявиться при создании или эксплуатации продукции. В определении поня¬тия показатель качества слова «Количественная характеристи¬ка» не следует понимать в буквальном смысле. При определении значений показателей качества успешно могут применяться и не¬числовые характеристики, хотя в общем случае наличие строго количественных, числовых характеристик предпочтительней. Показатели качества программной продукции в зависимости от характера решаемых задач по оценке качества продукции можно классифицировать по следующим признакам: характери¬зуемые свойства; способ выражения; количество характеризуемых свойств; место применения в процедуре оценки; стадии опреде¬ления значений показателей. По способу выражения различают показатели, выраженные в натуральных единицах, и показатели, выраженные в стоимостных единицах. В качестве натуральных единиц обычно используют единицы физических величин (килограммы, метры, секунды и т. п.), а также баллы и безразмерные единицы. ПО являются информационными объектами. Какими-либо собствен¬ными физическими свойствами они не обладают, поэтому едини¬цы физических величин в традиционном виде при определении значений показателей качества ПО почти не применяются, за исключением единиц времени. Но как составной элемент системы обработки данных ПО вносит определенную долю погрешности в точность выходных результатов. Эта погрешность может изме¬ряться в единицах преобразуемых физических величин. Вместе с тем в программировании широко используют такие натуральные единицы, как бит, байт, условная машинная команда, строка тек¬ста и т. п. Стоимостные единицы применяют при определении значений экономических показателей качества программной про¬дукции. По количеству характеризуемых свойств различают единичные и комплексные показатели. Единичные показатели качества ха¬рактеризуют одно из свойств ПО, комплексный—несколько. Комплексные показатели могут быть групповыми, обобщенными или интегральными. В зависимости от места применения в процедуре оценки уров¬ня качества различают ПО базовые и относительные показатели. Базовым значением показателя качества продукции называют значение показателя, принятое за основу при сравнительной оценке качества продукции. Относительное значение показателя качества продукции представляет собой отношение фактического значения показателя качества оцениваемой продукции к базовому значению этого показателя. По стадии определения значений показателей качества раз¬личают прогнозируемые, проектные, производственные и эксплуа¬тационные показатели. Прогнозируемыми показателями опери¬руют на стадиях выполнения научно-исследовательских работ, на разработку, т. е. на тех стадиях, когда нет еще ни детального проекта, ни, тем более, самого программного продукта. Значения прогнозируемых показателей в основном определяют на основе интуиции и опыта аналогичных разработок, поэтому эти показатели носят субъективный характер. Значения проектных показателей определяют на основе ана¬лиза проектов ПО (эскизного, технического, рабочего), а также путем испытания опытного образца ПО. Эти показатели носят более объективный характер. Степень их достоверности зависит от эффективности используемых инструментальных средств ана¬лиза и испытания. Значения эксплуатационных показателей определяют по ре¬зультатам промышленной эксплуатации. При соблюдении определенных правил сбора, и обработки данных о качестве ПО в процессе эксплуатации эксплуатационные показатели дают наиболее объективную и достоверную оценку. Только по этим показателям можно произвести действительную оценку научно-технического уровня и качества программного обеспечения.[4,8]

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

Для каждого вида (группы), а иногда и конкретного ПО уста¬навливают свою номенклатуру показателей качества, учитываю¬щую специфику назначения условий применения. Номенклатура показателей качества для каждого под¬класса, группы и вида ПО оформляется в виде таблиц применяе¬мости показателей качества. Помимо перечня рекомендуемых и обязательных показателей качества для данного подкласса (вида, группы) ПО, в таблицах применяемости следует указы¬вать и коэффициенты (параметры) весомости (значимости) каж¬дого из показателей. Определение коэффициентов весомости показателей качества — наиболее существенная и трудная задача выбора номенклатуры показателей качества. В принципе при ре¬шении этой задачи можно использовать либо метод стоимостно - регрессионных зависимостей, либо метод предельных номиналь¬ных значений. Но их использование затруднено из-за отсутствия необходимых исходных данных. Поэтому на практике наиболее распространен экспертный метод определения коэффициентов весомости. Таблицы применяемости являются руководящим или справоч¬ным материалом для выбора рабочей номенклатуры показателей качества конкретного ПО. Рабочая номенклатура ПО устанавли¬вается с учетом назначения и условий использования ПО; резуль¬татов анализа требований пользователя (заказчика), поставленных задач управления качеством; состава, структуры и специ¬фики характеризуемых свойств. Цели применения номенклатуры показателем качества уста¬навливают в соответствии с задачами управления качеством программной продукции. Такими целями, в частности, могут быть следующие: составление технического задания па разработ¬ку ПО; составление технических условии на ПО; заполнение кар¬ты технического уровня; установление контролируемых показа¬телей при проектировании ПО; установление контролируемых показателей при опытной эксплуатации ПО; аттестация ПО по категориям качества.[5]

Стадии определения значении показателей качества соответст¬вуют стадиям жизненного цикла ПО. При выделении свойств и соответствующих показателей каче¬ства ПО необходимо руководствоваться следующими основными принципами: выделение групп свойств должно производиться по четко определенным признакам; свойства, входящие в одну группу, должны, как правило, вза¬имно исключать друг друга и быть независимыми. Если свойст¬ва зависят друг от друга, то в методиках определения значении показателей качества должны быть даны четкие указания по исключению многократного (неоднократного) влияния одного и того же свойства на обобщенную оценку качества ПО; всякая исходная номенклатура показателей должна быть открытой, т. е. должна допускать возможность внесения мне исключения из нее отдельных элементов. Это требование обу¬словлено, с одной стороны, недостаточным опытом оценки каче¬ства программной продукции, а с другой, большим разнообра¬зием и условий их применения; для каждого из выделенных свойств должна существовать возможность выражения их в шкалах лучше — хуже, боль¬ше — меньше; в группу следует включать свойства, необходимые и достаточные для определения соответствующего сложного свойства; формулировка свойств должна быть однозначной; совокупность свойств, характеризующих качество оценивае¬мого ПО, должна быть упорядочена по определенному правилу в виде многоуровневой иерархической структуры — дерева свойств; выбранные показатели качества должны быть скорректированы с соответствующими свойствами. Это значит, что между каждым из выделенных свойств и характеризующими его показа¬телями должно быть установлено однозначное соответствие. Установление такого соответствия позволяет вместо дерева свойств использовать дерево показателей качества программной продукции.[9,10]

Показатели качества, характеризующие свойства ПО, должны способствовать обеспечению соответствия качества ПО требова¬ниям со стороны их пользователей и учитывать современные достижения науки и техники. Для выполнения этого принципа часто необходимо проводить специальные исследования, так как в общем случае между показателями качества могут возникать серьезные противоречия, а улучшение одного показателя может привести к ухудшению другого. Для проверки работоспособности выбранной системы показа¬телей качества необходимо устанавливать степень корреляции каждого рассматриваемого показателя с качеством ПО, полез¬ность показателя, возможность количественного представление и автоматической оценки показателя. Около 50 % частных показателей можно определить автоматически с помощью ЭВМ, 25 % — с помощью среды разработки. Таким обра¬зом, оценка около 75 % показателей может быть формализована. Оценка 20 % показателей может быть произведена только квалифицированным специалистом. Большинство показателей устанавливают путем статического анализа программ и лишь около 5 % — в процессе динамических испытаний (данные соответствуют положению в этой области в 2007-е годы).

Следует иметь в виду, что оценка качества, а следовательно, к выбор показателей качества сложных многофункциональных про¬граммных комплексов типа операционных систем, систем управ¬ления базами данных, пакетов прикладных программ и так да¬лее имеет свои особенности. Каждая функция таких ПО реали¬зуется программным путем, задающим определенный технологи¬ческий процесс преобразования входных данных в выходные. Известна цель этого процесса и потребность в нем. Для того чтобы удовлетворить эту потребность, ПО должна обладать определенными свойствами. Причем свойства ПС, удовлетворяю¬щие потребности в одной функции, могут существенно отличаться от свойств ПО, необходимых для реализации другой функции. Поэтому степень удовлетворения потребности в выполнении каж¬дой из функций ПО в общем случае характеризуется своими показателями или, по крайней мере, параметрами весомости по¬казателей. Возникает необходимость выбора показателей и опре¬деления их весомости для оценки качества (эффективности) реа¬лизации каждой из основных функций ПО. Попытка выбора еди¬ной номенклатуры показателей качества оказывается, как пра¬вило, безрезультатной. В этом можно легко убедиться на примере оценки качества операционных систем (ОС) ЭВМ. На ОС ЭВМ возлагаются следующие функции: управление данными, задания¬ми, вводом-выводом; обслуживание библиотек пользователей; трансляция и редактирование программ; протоколирование со¬стояний и событий; перезапись и сортировка информации и др. Очевидно, что требования, например, к трансляторам существен¬но отличаются от требований к ПО протоколирования событий, как по своему перечню, так и по весомости каждого из показате¬лей. В свою очередь различие требований обусловливает необхо¬димость использования различных показателей качества, харак¬теризующих потребительские свойства программ, реализующих эти функции.[12,13,14]

ЗАКЛЮЧЕНИЕ

Программ без ошибок не существует. Ошибки, связанные с неверным вводом команд в редакторе, неверной записью идентификаторов почти всегда можно обнаружить простым анализом исходного текста, и фиксируются компилятором платформы, на которой написана программа. Обычно по традиции программисты применяют метод try – попытка, будет ли работать программа при той или иной модификации, обычно её называют отладкой. Некоторые организации занимающиеся разработкой программного обеспечения, тестированием и отладкой занимаются сами, дешевле. Поэтому приходится прибегать к различным программистским приемам, позволяющим повысить производительность программного обеспечения и выявлять ошибки как можно раньше, так как начинающие и профессиональные программисты допускают самые различные ошибки, как на этапе проектирования, так и в коде программы. Нередко ошибка приводит к лавинообразным последствиям, затрудняющих работу программиста, приводя к пересмотру всего кода на начальном этапе. Для этого программист сам создает программу тестирующую программное обеспечение или пользуется уже имеющимися тестирующими пакетами программ. Главная роль в тестировании все же принадлежит программисту, следящему за выполнением кода программы и появлением точек прерывания. За ошибками программист должен следить самостоятельно, только требуется, чтобы отлаживаемая программа была запущена. Только тогда среда разработки сможет контролировать ход выполнения программы и изменение значений различных переменных. Пошаговая отладка появилась сравнительно недавно. Ранее на больших ЭВМ, из-за крайне жестких требований к оперативной памяти и слабых вычислительных ресурсов программисты использовали технологию отладки, основанную только на введении протоколов. Исходя из этого, программист сможет определить ошибку, так как обнаружить её быстро не удается, зная подпрограмму, вызвавшую ошибку. В старых языках программирования были даже специальные операторы для выдачи протокольной информации. Однако просто просматривая исходный текст наиболее эффективно при поиске ошибок. В некоторых случаях разработчики программ занимаются выпуском сырых программ, так называемые программы не прошедшие тестирование. Пользователь или организация приобретшие такие программы используют их на свой страх и риск. Сообщения о серьезных ошибках, при наличии которых, построенный компилятором объектный код заведомо некорректен и его дальнейшее использование невозможно.

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

ГЛОССАРИЙ

№

п\п Понятие Определение

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

2 Доказательство попытка найти ошибки в программе безотносительно к внешней для программы среде

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

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

5 Аттестация авторитетное подтверждение правильности программы, аналогичное аттестации электротехниче¬ского оборудования

6 Отладка не является разновидностью тестирования. Хотя слова «отладка» и «тестирование» часто используются как синонимы, под ними подразумеваются разные виды деятельности. Тестирование — деятельность, направленная на обнаружение оши¬бок; отладка направлена на установление точной природы извест¬ной ошибки, а затем — на исправление этой ошибки. Эти два вида деятельности связаны — результаты тестирования являются ис¬ходными данными для отладки

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

8 ISO (International Standard Organization) международная организация по стандартам, находящаяся в Париже, которая разрабатывает стандарты для международных и национальных коммуникаций.

9 ANSI (American National Standard Institute) национальный институт стандартизации США. Один из известных международных разработчиков систем кодирования данных

10 Модуль единица, содержащая завершенную схему или подсхему данных

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1. Бобровский С.И. Delphi 7. – Питер, 2008

2. Бердж В. Методы рекурсивного программирования. – АиФ-Принт, 2006

3. Васильков Ю.В., Василькова Н.Н. Компьютерные технологии.- Лори, 2006

4. Змитрович А.И. Информационные системы. – Дрофа, 2006

5. Кулаков. Б. Г. Качество программного обеспечения.- Олма-Пресс, 2006

6. Майерс С. А. Надежность программного обеспечения. – АСТ, 2007

7. Майерс С. А. Тестирование программного обеспечения. – АСТ, 2007

8. Мацяшек Л. Проектирование систем. – Дрофа, 2006

9. Мейер Б., Методы программирования. – ДМК, 2007

10. Скотт Мюллер. Модернизация и ремонт ПК. – Вильямс, 2007

11. Фридман А. Разработка программных систем. – ДМК, 2006

12. Холзнер С. Visual C++ 6. – Питер, 2008

13. Хендерсон П. Функциональное программирование. – Нева, 2006

14. Шеннон Р. Имитационное моделирование. – Лори, 2007

ПРИЛОЖЕНИЕ А

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