Основы стандартизации ПОИТ ч4. Руководство для студентов специальности i40 01 01 Программное обеспечение информационных технологий
 Скачать 460 Kb.
|
1.2 Тестирование надежности программного обеспечения1.2.1 Философия тестированияТестирование программного обеспечения охватывает ряд видов деятельности, аналогичный последовательности процессов разработки программного обеспечения. Сюда входят постановка задачи для теста, проектирование, написание тестов, тестирование тестов, выполнение тестов и изучение результатов тестирования. Решающую роль играет проектирование теста. Возможен целый спектр подходов к выработке философии, или стратегии проектирования. Чтобы ориентироваться в стратегиях проектирования тестов, стоит рассмот-реть два крайних подхода, находящихся на границах спектра. Следует отметить также, что многие из тех, кто работает в этой области, часто бросаются в одну или другую крайность. Сторонник подхода, соответствующего левой границе спектра (рисунок 1.1), проектирует свои тесты, исследуя внешние спецификации или спецификации сопряжения программы или модуля, которые он тестирует. Программу он рассматривает как «черный ящик». Позиция его такова: «Меня не интересует, как выглядит эта программа и выполнил ли я все команды или все пути. Я буду удовлетворен, если программа будет вести себя так, как указано в спецификациях». Его идеал – проверить все возможные комбинации и значения на входе. Приверженец подхода, соответствующего другому концу спектра, проектирует свои тесты, изучая логику программы. Он начинает с того, что стремится подготовить достаточное число тестов для того, чтобы каждая команда была выполнена по крайней мере один раз. Если он немного более искушен, то проектирует тесты так, чтобы каждая команда условного перехода выполнялась в каждом направлении хотя бы раз. Его идеал – проверить каждый путь, каждую ветвь алгоритма. При этом его совсем (или почти совсем) не интересуют спецификации.  Рисунок 1.1 – Схема спектра подходов к проектированию тестов Ни одна из этих крайностей не является хорошей стратегией. Первая из них, а именно та, в соответствии с которой программа рассматривается как «черный ящик», предпочтительней. К сожалению, она страдает тем недостатком, что совершенно неосуществима. Рассмотрим попытку тестирования тривиальной программы, получающей на входе три числа и вычисляющей их среднее арифметическое. Тестирование этой программы для всех значений входных данных невозможно. Даже для машины с относительно низкой точностью вычислений количество тестов исчислялось бы миллиардами. Даже имея вычислительную мощность, достаточную для выполнения всех тестов в разумное время, мы потратили бы на несколько порядков больше времени для того, чтобы эти тесты подготовить, а затем проверить. Такие программы, как системы реального времени, операционные системы и программы управления данными, которые сохраняют «память» о предыдущих входных данных, еще хуже. Нам потребовалось бы тестировать программу не только для каждого входного значения, но и для каждой последовательности, каждой комбинации входных данных. Поэтому исчерпывающее тестирование для всех входных данных любой программы неосуществимо. Эти рассуждения приводят ко второму фундаментальному принципу тестирования: тестирование – проблема в значительной степени экономическая. Поскольку исчерпывающее тестирование невозможно, мы должны ограничиться чем–то меньшим. Каждый тест должен давать максимальную отдачу по сравнению с нашими затратами. Эта отдача измеряется вероятностью того, что тест выявит не обнаруженную прежде ошибку. Затраты измеряются временем и стоимостью подготовки, выполнения и проверки результатов теста. Считая, что затраты ограничены бюджетом и графиком, можно утверждать, что искусство тестирования, по существу, представляет собой искусство отбора тестов с максимальной отдачей. Каждый тест должен быть представителем некоторого класса входных значений, так чтобы его правильное выполнение создавало у нас некоторую убежденность в том, что для определенного класса входных данных программа будет выполняться правильно. Это обычно требует некоторого знания алгоритма и структуры программы, и мы, таким образом, смещаемся к правому концу спектра. 1.2.2 Тестирование модулейВторым по важности аспектом тестирования после проектирования тестов является последовательность слияния всех модулей в систему или программу. Эта сторона вопроса обычно не получает достаточного внимания и часто рассматривается слишком поздно. Выбор этой последовательности, однако, является одним из самых жизненно важных решений, принимаемых на этапе тестирования, поскольку он определяет форму, в которой записываются тесты, типы необходимых инструментов тестирования, последовательность программирования модулей, а также тщательность и экономичность всего этапа тестирования. По этой причине такое решение должно приниматься на уровне проекта в целом и на достаточно ранней его стадии. Тестирование модулей (или блоков) представляет собой процесс тестирования отдельных подпрограмм или процедур программы. Здесь подразумевается, что, прежде чем начинать тестирование программы в целом, следует протестировать отдельные небольшие модули, образующие эту программу. Такой подход мотивируется тремя причинами. Во–первых, появляется возможность управлять комбинаторикой тестирования, поскольку первоначально внимание концентрируется на небольших модулях программы. Во–вторых, облегчается задача отладки программы, т.е. обнаружение места ошибки и исправление текста программы. В–третьих, допускается параллелизм, что позволяет одновременно тестировать несколько модулей. Цель тестирования модулей – сравнение функций, реализуемых модулем, со спецификациями его функций или интерфейса. Тестирование модулей в основном ориентировано на принцип «белого ящика». Это объясняется, прежде всего, тем, что принцип «белого ящика» труднее реализовать при переходе в последующем к тестированию более крупных единиц, например программ в целом. Кроме того, последующие этапы тестирования ориентированы на обнаружение ошибок различного типа, т. е. ошибок, не обязательно связанных с логикой программы, а возникающих, например, из-за несоответствия программы требованиям пользователя. Имеется большой выбор возможных подходов, которые могут быть использованы для слияния модулей в более крупные единицы. В большинстве своем они могут рассматриваться как варианты шести основных подходов: пошаговое тестирование; восходящее тестирование; нисходящее тестирование; метод «большого скачка»; метод сандвича; модифицированный метод сандвича. Метод сандвича. Тестирование методом сандвича представляет собой компромисс между восходящим и нисходящим подходами. Здесь делается попытка воспользоваться достоинствами обоих методов, избежав их недостатков. При использовании этого метода одновременно начинают восходящее и нисходящее тестирование, собирая программу снизу и сверху, встречаясь где-то в середине. Точка встречи зависит от конкретной тестируемой программы и должна быть заранее определена при изучении ее структуры. Например, если разработчик может представить свою систему в виде уровня прикладных модулей, затем уровня модулей обработки запросов, затем уровня примитивных функций, то он может решить применять нисходящий метод на уровне прикладных модулей (программируя заглушки вместо модулей обработки запросов), а на остальных уровнях применить восходящий метод. Метод сандвича сохраняет такое достоинство нисходящего и восходящего подходов, как начало интеграции системы на самом раннем этапе. Поскольку вершина программы вступает в строй рано, мы, как в нисходящем методе, уже на раннем этапе получаем работающий каркас программы. Так как нижние уровни программы создаются восходящим методом, снимаются проблемы нисходящего метода, которые были связаны с невозможностью тестировать некоторые условия в глубине программы. Модифицированный метод сандвича. При тестировании методом сандвича возникает та же проблема, что и при нисходящем подходе, но не так остро. Проблема эта в том, что невозможно досконально тестировать отдельные модули. Восходящий этап тестирования по методу сандвича решает эту проблему для модулей нижних уровней, но она может по– прежнему оставаться открытой для нижней половины верхней части программы. В модифицированном методе сандвича нижние уровни также тестируются строго снизу вверх. А модули верхних уровней сначала тестируются изолированно, а затем собираются нисходящим методом. Таким образом, модифицированный метод сандвича также представляет собой компромисс между восходящим и нисходящим подходами. Восходящее тестирование. Программа собирается и тестируется «снизу вверх». Только модули самого нижнего уровня («терминальные» модули; модули, не вызывающие других модулей) тестируются изолированно, автономно. После того как тестирование этих модулей завершено, вызов их должен быть так же надежен, как вызов встроенной функции языка или оператор присваивания. Затем тестируются модули, непосредственно вызывающие уже проверенные. Эти модули более высокого уровня тестируются не автономно, а вместе с уже проверенными модулями более низкого уровня. Процесс повторяется до тех пор, пока не будет достигнута вершина. Здесь завершается и тестирование модулей, и тестирование сопряжений программы. При восходящем тестировании для каждого модуля необходим драйвер: нужно подавать тесты в соответствии с сопряжением тестируемого модуля. Одно из возможных решений – написать для каждого модуля небольшую ведущую программу. Тестовые данные представляются как «встроенные» непосредственно в эту программу переменные и структуры данных, и она многократно вызывает тестируемый модуль, с каждым вызовом передавая ему новые тестовые данные. Имеется и лучшее решение: воспользоваться программой тестирования модулей – это инструмент тестирования, позволяющий описывать тесты на специальном языке и избавляющий от необходимости писать драйверы. Здесь отсутствуют проблемы, связанные с невозможностью или трудностью создания всех тестовых ситуаций, характерные для нисходящего тестирования. Драйвер как средство тестирования применяется непосредственно к тому модулю, который тестируется, где нет промежуточных модулей, которые следует принимать во внимание. Анализируя другие проблемы, возникающие при нисходящем тестировании, можно заметить, что при восходящем тестировании невозможно принять неразумное решение о совмещении тестирования с проектированием программы, поскольку нельзя начать тестирование до тех пор, пока не спроектированы модули нижнего уровня. Не существует также и трудностей с незавершенностью тестирования одного модуля при переходе к тестированию другого, потому что при восходящем тестировании с применением нескольких версий заглушки нет сложностей с представлением тестовых данных. Нисходящее тестирование. Нисходящее тестирование (называемое также нисходящей разработкой) не является полной противоположностью восходящему, но в первом приближении может рассматриваться как таковое. При нисходящем подходе программа собирается и тестируется «сверху вниз». Изолированно тестируется только головной модуль. После того как тестирование этого модуля завершено, с ним соединяются (например, редактором связей) один за другим модули, непосредственно вызываемые им, и тестируется полученная комбинация. Процесс повторяется до тех пор, пока не будут собраны и проверены все модули. При этом подходе возникают два вопроса: 1. «Что делать, когда тестируемый модуль вызывает модуль более низкого уровня (которого в данный момент еще не существует)?» и 2. «Как подаются тестовые данные?» Ответ на первый вопрос состоит в том, что для имитации функций недостающих модулей программируются модули – «заглушки», которые моделируют функции отсутствующих модулей. Интересен и второй вопрос: «В какой форме готовятся тестовые данные и как они передаются программе?» Если бы головной модуль содержал все нужные операции ввода и вывода, ответ был бы прост: тесты пишутся в виде обычных для пользователей внешних данных и передаются программе через выделенные ей устройства ввода. Так, однако, случается редко. В хорошо спроектированной программе физические операции ввода– вывода выполняются на нижних уровнях структуры, поскольку физический ввод– вывод – абстракция довольно низкого уровня. Поэтому для того, чтобы решить проблему экономически эффективно, модули добавляются не в строго нисходящей последовательности (все модули одного горизонтального уровня, затем модули следующего уровня), а таким образом, чтобы обеспечить функционирование операций физического ввода– вывода как можно быстрее. Когда эта цель достигнута, нисходящее тестирование получает значительное преимущество: все дальнейшие тесты готовятся в той же форме, которая рассчитана на пользователя. Нисходящий метод имеет как достоинства, так и недостатки по сравнению с восходящим. Самое значительное достоинство – то, что этот метод совмещает тестирование модуля, тестирование сопряжений и частично тестирование внешних функций. С этим же связано другое его достоинство: когда модули ввода– вывода уже подключены, тесты можно готовить в удобном виде. Нисходящий подход выгоден также в том случае, когда есть сомнения относительно осуществимости программы в целом или когда в проекте программы могут оказаться серьезные дефекты. Преимуществом нисходящего подхода очень часто считают отсутствие необходимости в драйверах; вместо драйверов вам просто следует написать «заглушки». Нисходящий метод тестирования имеет, к сожалению, некоторые недостатки. Основным из них является то, что модуль редко тестируется досконально сразу после его подключения. Дело в том, что основательное тестирование некоторых модулей может потребовать крайне изощренных заглушек. Программист часто решает не тратить массу времени на их программирование, а вместо этого пишет простые заглушки и проверяет лишь часть условий в модуле. Он, конечно, собирается вернуться и закончить тестирование рассматриваемого модуля позже, когда уберет заглушки. Такой план тестирования – определенно не лучшее решение, поскольку об отложенных условиях часто забывают. Второй тонкий недостаток нисходящего подхода состоит в том, что он может породить веру в возможность начать программирование и тестирование верхнего уровня программы до того, как вся программа будет полностью спроектирована. Эта идея на первый взгляд кажется экономичной, но обычно дело обстоит совсем наоборот. Большинство опытных проектировщиков признает, что проектирование программы – процесс итеративный. Редко первый проект оказывается совершенным. Нормальный стиль проектирования структуры программы предполагает по окончании проектирования нижних уровней вернуться назад и подправить верхний уровень, внеся в него некоторые усовершенствования или исправляя ошибки, либо иногда даже выбросить проект и начать все сначала, потому что разработчик внезапно увидел лучший подход. Если же головная часть программы уже запрограммирована и оттестирована, то возникает серьезное сопротивление любым улучшениям ее структуры. В конечном итоге за счет таких улучшений обычно можно сэкономить больше, чем те несколько дней или недель, которые рассчитывает выиграть проектировщик, приступая к программированию слишком рано. Метод «большого скачка». Вероятно, самый распространенный подход к интеграции модулей – метод «большого скачка». В соответствии с этим методом каждый модуль тестируется автономно. По окончании тестирования модулей они интегрируются в систему все сразу. Метод «большого скачка» по сравнению с другими подходами имеет много недостатков и мало достоинств. Заглушки и драйверы необходимы для каждого модуля. Модули не интегрируются до самого последнего момента, а это означает, что в течение долгого времени серьезные ошибки в сопряжениях могут остаться необнаруженными. Если программа мала (как, например, программа загрузчика) и хорошо спроектирована, метод «большого скачка» может оказаться приемлемым. Однако для крупных программ метод «большого скачка» обычно губителен. Пошаговое тестирование. Реализация процесса тестирования модулей опирается на два ключевых положения: построение эффективного набора тестов и выбор способа, посредством которого модули комбинируются при построении из них рабочей программы. Второе положение является важным, так как оно задает форму написания тестов модуля, типы средств, используемых при тестировании, порядок кодирования и тестирования модулей, стоимость генерации тестов и стоимость отладки. Рассмотрим два подхода к комбинированию модулей: пошаговое и монолитное тестирование. Возникает вопрос: «Что лучше – выполнить по отдельности тестирование каждого модуля, а затем, комбинируя их, сформировать рабочую программу или же каждый модуль для тестирования подключать к набору ранее оттестированных модулей?». Первый подход обычно называют монолитным методом, или методом «большого удара», при тестировании и сборке программы; второй подход известен как пошаговый метод тестирования или сборки. Метод пошагового тестирования предполагает, что модули тестируются не изолированно друг от друга, а подключаются поочередно для выполнения теста к набору уже ранее оттестированных модулей. Пошаговый процесс продолжается до тех пор, пока к набору оттестированных модулей не будет подключен последний модуль. Детального разбора обоих методов мы делать не будем, приведем лишь некоторые общие выводы. 1.Монолитное тестирование требует больших затрат труда. При пошаговом же тестировании «снизу– вверх» затраты труда сокращаются. 2.Расход машинного времени при монолитном тестировании меньше. 3.Использование монолитного метода предоставляет большие возможности для параллельной организации работы на начальной фазе тестирования (тестирования всех модулей одновременно). Это положение может иметь важное значение при выполнении больших проектов, в которых много модулей и много исполнителей, поскольку численность персонала, участвующего в проекте, максимальна на начальной фазе. 4.При пошаговом тестировании раньше обнаруживаются ошибки в интерфейсах между модулями, поскольку раньше начинается сборка программы. В противоположность этому при монолитном тестировании модули «не видят друг друга» до после дней фазы процесса тестирования. 5.Отладка программ при пошаговом тестировании легче. Если есть ошибки в межмодульных интерфейсах, а обычно так и бывает, то при монолитном тестировании они могут быть обнаружены лишь тогда, когда собрана вся программа. В этот момент локализовать ошибку довольно трудно, поскольку она может находиться в любом месте программы. Напротив, при пошаговом тестировании ошибки такого типа в основном связаны с тем модулем, который подключается последним. 6.Результаты пошагового тестирования более совершенны. В заключение отметим, что п. 1, 4, 5, 6 демонстрируют преимущества пошагового тестирования, а п. 2 и 3 – его недостатки. Поскольку для современного этапа развития вычислительной техники характерны тенденции к уменьшению стоимости аппаратуры и увеличению стоимости труда, последствия ошибок в математическом обеспечении весьма серьезны, а стоимость устранения ошибки тем меньше, чем раньше она обнаружена; преимущества, указанные в п. 1, 4, 5, 6, выступают на первый план. В то же время ущерб, наносимый недостатками (п. 2 и 3), невелик. Все это позволяет нам сделать вывод, что пошаговое тестирование является предпочтительным. Убедившись в преимуществах пошагового тестирования перед монолитным, исследуем две возможные стратегии тестирования: нисходящее и восходящее. Прежде всего, внесем ясность в терминологию. Во-первых, термины «нисходящее тестирование», «нисходящая разработка», «нисходящее проектирование» часто используются как синонимы. Действительно, термины «нисходящее тестирование» и «нисходящая разработка» являются синонимами (в том смысле, что они подразумевают определенную стратегию при тестировании и создании текстов модулей), но нисходящее проектирование – это совершенно иной и независимый процесс. Программа, спроектированная нисходящим методом, может тестироваться и нисходящим, и восходящим методами. Во-вторых, восходящая разработка, или тестирование, часто отождествляется с монолитным тестированием. Это недоразумение возникает из– за того, что начало восходящего тестирования идентично монолитному при тестировании нижних или терминальных модулей. Но выше было показано, что восходящее тестирование на самом деле представляет собой пошаговую стратегию. 1.2.3 Комплексное тестированиеКомплексное тестирование, вероятно, самая непонятная форма тестирования. Во всяком случае, комплексное тестирование не является тестированием всех функций полностью собранной системы; тестирование такого типа называется тестированием внешних функций. Комплексное тестирование – процесс поисков несоответствия системы ее исходным целям. Элементами, участвующими в комплексном тестировании, служат сама система, описание целей продукта и вся документация, которая будет поставляться вместе с системой. Внешние спецификации, которые были ключевым элементом тестирования внешних функций, играют лишь незначительную роль в комплексном тестировании. Часть аргументов в пользу этого должна быть уже очевидной: измеримые цели необходимы, чтобы определить правила для процессов проектирования. Остальные соображения должны проясниться сейчас. Если цели сформулированы, например, в виде требования, чтобы система была достаточно быстрой, вполне надежной и чтобы в разумных пределах обеспечивалась безопасность, тогда нет способа определить при тестировании в какой степени система достигает своих целей. Если вы не сформулировали цели вашего продукта или если эти цели неизмеримы, вы не можете выполнить комплексное тестирование. Комплексное тестирование может быть процессом и контроля и испытаний. Процессом испытаний оно является тогда, когда выполняется в реальной среде пользователя или в обстановке, которая специально создана так, чтобы напоминать среду пользователя. Однако такая роскошь часто недоступна по ряду причин, и в подобных случаях комплексное тестирование системы является процессом контроля (т.е. выполняется в имитируемой, или тестовой среде). Например, в случае бортовой вычислительной системы космического корабля или системы противоракетной защиты вопрос о реальной среде (запуск настоящего космического корабля или выстрел настоящей ракетой) обычно не стоит. Кроме того, как мы увидим дальше, некоторые типы комплексных тестов не осуществимы в реальной обстановке по экономическим соображениям, и лучше всего выполнять их в моделируемой среде. Комплексное тестирование – наиболее творческий из всех видов тестирования. Разработка хороших комплексных тестов требует часто даже больше изобретательности, чем само проектирование системы. Здесь нет простых рекомендаций типа тестирования всех ветвей или построения функциональных диаграмм. Комплексное тестирование системы – такая особая и такая важная работа, что в будущем возможно появление компаний, специализирующихся в основном на комплексном тестировании систем, разработанных другими. По своей природе комплексные тесты никогда не сводятся к проверке отдельных функций системы. Они часто пишутся в форме сценариев, представляющих ряд последовательных действий пользователя. Например, один комплексный тест может представлять подключение терминала к системе, выдачу последовательно 10–20 команд и затем отключение от системы. Вследствие их особой сложности тесты системы состоят из нескольких компонентов: сценария, входных данных и ожидаемых выходных данных. В сценарии точно указываются действия, которые должны быть совершены во время выполнения теста. 1.2.4 Организация и этапы тестирования при испытаниях надежности сложных программных средствОсновные этапы тестирования и испытаний комплекса программ и его компонентов представлены на рисунке 1.2. Для каждого этапа на рисунке представлены основные исходные данные и результаты тестирования и испытаний. При тестировании, отладке и испытаниях корректности компонентов комплексов программ выделены следующие этапы: – комплексирование модулей и отладка автономных групп программ в статике без взаимодействия с другими компонентами и, возможно, без подключения к операционной системе реального времени;  Рисунок 1.2 – Схема этапов тестирования и испытаний сложных комплексов программ – тестирование и отладка групп программ в статике с учетом взаимодействия с некоторыми другими важнейшими компонентами и с базой данных; – тестирование и отладка отдельных программных компонентов в реальном времени во взаимодействии с другими функциональными компонентами и с основными компонентами операционной системы и базы данных. Сложность тестирования компонентов на этих этапах в значительной степени обусловлена несинхронным процессом их разработки и отладки. Первично спланированная логика сопряжения между собой отдельных компонентов и подключения их к операционной системе не всегда выполняется из-за задержек в автономной отладке некоторых из них. Целесообразная последовательность отладки определенных компонентов может нарушаться неготовностью к сопряжению с ними других взаимодействующих программ. В результате к комплексному тестированию и испытаниям ПС могут быть готовы не все необходимые компоненты, и их приходится начинать с некоторой не всегда самой важной и целесообразной совокупности групп программ. Для обеспечения имитации объектов внешней среды и других взаимодействующих групп программ на этих этапах используются частные генераторы соответствующих тестов. Эти генераторы тестов целесообразно разрабатывать и оформлять как отдельные модули или группы программ, функционирующие на той же технологической ЭВМ и в той же операционной среде, что и отлаживаемые компоненты. Совместно с ними также реализуются и функционируют частные специализированные программы для обработки отдельных результатов отладки соответствующих групп программ, что также требует некоторых ресурсов ЭВМ. При этом не всегда удается полностью реализовать реальный масштаб времени для отдельных функциональных компонентов и приходится применять стартстопный режим тестирования или растягивать циклы решения функциональных задач и имитировать псевдореальный масштаб. После комплексирования основных функциональных компонентов начинаются тестирование и испытания ПС в целом. Для них наиболее характерны следующие стадии комплексного тестирования и испытаний ПС в реальном времени: – по данным моделирующего стенда или генераторов тестов, имитирующих отдельные объекты внешней среды; – с имитаторами отдельных объектов внешней среды и с реальными воздействиями от операторов–пользователей; – в полностью адекватной реальной или имитированной внешней среде и с реальными воздействиями от операторов–пользователей. На всех стадиях отладки, кроме операций непосредственной проверки функционирования программ, можно выделить еще две важные группы работ. Первая группа – это работы по методическому обеспечению тестирования и по созданию средств автоматизированной генерации тестов. Вторая группа работ должна обеспечивать возможность обработки результатов тестирования и оценки достигнутых показателей качества функционирования программ. Средства генерации тестов и обработки результатов отладки можно разделить на три вида (см. рисунок 1.2). Одни и те же средства автоматизации тестирования в статике обычно обеспечивают отладку групп программ как автономно, так и во взаимодействии с другими компонентами. Средства, имитирующие внешнюю среду в реальном времени, чаще всего ориентированы на отладку как функциональных компонентов, так и ПС в целом. Еще один вид генераторов тестов в той или иной степени использует реальные объекты внешней среды. Первоначально такими объектами являются имитирующие стенды с участием реального функционирования операторов–пользователей. Затем источниками тестов могут быть полные комплексы реальной аппаратуры внешних объектов или их аппаратные аналоги. Каждая из выделенных стадий тестирования может рассматриваться как обеспечивающая создание определенного промежуточного продукта – функциональной группы программ или программного средства с некоторыми ограниченными характеристиками качества. Эти характеристики выделяются и детализируются на основе первичного технического задания и спецификации требований на ПС. В процессе проектирования ПС они уточняются и конкретизируются в спецификациях требований на группы программ и их компоненты. В результате создается совокупность эталонов, имеющих последовательно расширяющиеся номенклатуру и наборы значений показателей качества, которым должны соответствовать отлаживаемые и испытываемые компоненты на каждой стадии тестирования. Подобная совокупность эталонных показателей качества промежуточных продуктов обеспечивает возможность управления процессом тестирования с целью достижения необходимого качества конечного продукта – ПС при минимальных или разумных затратах. Для этого каждая стадия тестирования должна иметь фиксированный и документированный результат с определенными эталонами и достигнутыми характеристиками программ. Подобный систематизированный контроль тестирования гарантирует высокое качество ПС реального времени, к которым предъявляются обычно высокие требования по надежности. Кроме того, компоненты, прошедшие все стадии тестирования, с большой уверенностью могут применяться как повторно используемые компоненты в последующих версиях ПС. Организация завершающих испытаний комплексов программ. Испытания главного конструктора, которые зачастую совмещаются с завершением комплексной отладки, должны оформляться документально и являются основанием для предъявления ПС заказчику на завершающиеся совместные испытания. Любые испытания ограничены допустимым объемом проверок и длительностью работы комиссии, поэтому не могут гарантировать абсолютную проверку изделия. Для повышения достоверности определения и улучшения характеристик ПС после испытаний главного конструктора программы целесообразно передавать некоторым пользователям на опытную эксплуатацию в типовых условиях. Это позволяет более глубоко оценить эксплуатационные характеристики созданного комплекса и устранить некоторые дефекты и ошибки. Опытная эксплуатация проводится разработчиками с участием испытателей и некоторых пользователей, назначаемых заказчиком. Результаты и показатели надежности опытной эксплуатации после испытаний главного конструктора могут учитываться при проведении совместных испытаний для их сокращения. Совместные приемо-сдаточные испытания проводятся комиссией заказчика, в которой участвуют главный конструктор разработки и некоторые ведущие разработчики, аттестованные сертификационной лабораторией. Комиссия при испытании руководствуется следующими документами: – утвержденным заказчиком и согласованным с разработчиком техническим заданием и спецификациями на ПС; – действующими государственными и ведомственными стандартами на проектирование и испытания программ и на техническую документацию, а также согласованными с заказчиком стандартами «де–факто»; – программой испытаний по всем требованиям технического задания; – методиками испытаний по каждому разделу требований технического задания; – комплектом эксплуатационной документации на комплекс про грамм. Программа испытаний является планом проведения серии экспериментов и разрабатывается с позиции минимизации объема тестирования в процессе проведения испытаний для проверки выполнения требований технического задания и соответствия предъявленной документации. Программа испытаний, методики их проведения и оценки результатов, разработанные совместно заказчиком и разработчиком, должны быть согласованы и утверждены. Они должны содержать уточнения и детализацию требований технического задания для данного ПС, а также гарантировать корректную проверку всех заданных характеристик, в том числе надежности. Программа испытаний должна содержать следующие четко сформулированные разделы: – объект испытаний, его назначение и перечень основных документов, определивших его разработку; – цель испытаний с указанием всех требований технического задания, подлежащих проверке, и ограничений на проведение испытаний; – собственно программу испытаний, содержащую проверку комплектности спроектированного ПС в соответствии с тexническим заданием, и план тестирования для проверки по всем разделам технического задания и дополнительным требoвaниям, формализованным отдельными решениями разработчиков и заказчика; – методики испытаний, однозначно определяющие все понятия проверяемых характеристик, условия и сценарии тестирования, средства, используемые для испытаний; – методики обработки и оценки результатов тестирования по каждому разделу программы испытаний. Большой объем разнородных данных, получаемых при испытаниях крупномасштабных ПС, и разнообразие возможных способов их обработки, интерпретации и оценки приводят к тому, что важнейшими факторами становятся методики обработки и оценки результатов, а также протоколы проверки по пунктам программы испытаний. В соответствии с методиками испытаний средства автоматизации должны обеспечивать всю полноту проверок характеристик по каждому разделу методик. Результаты испытаний фиксируются в протоколах, которые обычно содержат следующие разделы: – назначение тестирования и раздел требований технического задания, по которому проводились испытания; – указания методик, в соответствии с которыми проводились испытания, обработка и оценка результатов; – условия и сценарии проведения тестирования и характеристики исходных данных; – обобщенные результаты испытаний с оценкой их на соответствие требованиям технического задания и другим руководящим документам, а также технической документации; – выводы о результатах испытаний и соответствии созданного ПС определенному разделу требований технического задания. Протоколы по всей программе испытаний обобщаются в акте, в результате чего делается заключение о соответствии системы требованиям заказчика и завершении работы с положительным или отрицательным итогом. При полном выполнении всех требований технического задания заказчик обязан принять систему, и работа считается завершенной. Наиболее полным и разносторонним испытаниям должна подвергаться первая базовая версия ПС. При испытаниях очередных модернизированных версий ПС возможны значительные сокращения объемов тестирования повторно используемых компонентов. Однако комплексные и завершающие испытания каждой новой версии ПС, как правило, проводятся в полном объеме, гарантирующем проверку выполнения всех требований измененного технического задания. Для обеспечения выявления дефектов в процессе эксплуатации серийных образцов в каждом из них должен быть предусмотрен некоторый минимум средств проверки функционирования и обнаружения искажений результатов. Этот минимум средств должен позволять фиксировать условия неправильной работы программ и характер проявления дефектов. Последующее исправление ошибок должно проводиться специалистами, осуществляющими сопровождение. При завершающих испытаниях основное внимание, кроме проверок функциональной пригодности, должно сосредоточиваться на подготовке стрессовых тестов, тестировании в режимах предельного использования ресурсов, надежности функционирования ПС. Задача испытателей и заказчика при проведении совместных испытаний состоит в выделении условий и области изменения переменных, которые недостаточно проверены разработчиком и важны для последующего надежного функционирования программ. При этом разработчик контролирует, чтобы планируемые сценарии и тесты не выходили из областей, заданных техническим заданием и спецификацией требований. Испытания за пределами технического задания могут квалифицироваться как его расширение или могут исключаться по требованию разработчика. До начала испытаний подлежат проверке и паспортизации средства, обеспечивающие получение эталонных данных, средства имитации тестов от внешних объектов, средства фиксирования и обработки результатов тестирования. При испытаниях важную роль играют оценка и обеспечение близких значений методической и статистической достоверности результатов испытаний. Методическая достоверность приемо–сдаточных испытаний ПС определяется следующими факторами: – полнотой программы испытаний и корректностью методик тестирования по охвату возможных условий и сценариев функционирования программ и областей изменения исходных данных; – достоверностью и точностью эталонных значений, с которыми сравниваются результаты тестирования испытываемой про граммы или которые служат опорными при расчете параметров, зафиксированных в техническом задании; – адекватностью и точностью моделей, используемых для имитации тестов от внешней среды и подыгрыша их реакции на управляющие воздействия; – точностью и корректностью регистрации и обработки результатов тестирования, а также сравнения полученных данных с требованиями технического задания. Представленная выше организация испытаний сложных ПС ориентирована на наличие конкретного заказчика комплекса программ и ограниченное число пользователей, контролируемых заказчиком. Несколько иначе организуются испытания коммерческих пакетов прикладных программ, создаваемых по инициативе разработчиков для широкого круга пользователей при отсутствии конкретного заказчика. Для таких коммерческих прикладных программ принято проводить испытания в два последовательных этапа – Альфа- и Бета-тестирование. Испытания проводятся на соответствие критериям, формализованным руководителем проекта. Они заключаются в нормальной и форсированной (стрессовой) опытной эксплуатации конечными пользователями оформленного программного продукта в соответствии с сопроводительной документацией и различаются количеством участвующих пользователей. При Альфа-тестировании привлекаются конечные пользователи, работающие в той же компании, но не участвовавшие непосредственно в разработке комплекса программ. Для Бета-тестирования привлекаются добровольные пользователи (потенциальные покупатели), которым бесплатно передается версия ПС для опытной эксплуатации. При этом особое значение имеет выделение компетентных, тщательных и доброжелательных пользователей, способных своими рекомендациями улучшить качество испытываемых программ. Их деятельность стимулируется бесплатным и ранним получением и освоением нового программного продукта и собственной оценкой его качества. Эти пользователи обязуются сообщать разработчикам сведения о всех выявленных дефектах и ошибках, а также вносить изменения в программы и данные или заменять версии по указаниям разработчиков. Только после успешной эксплуатации и Бета-тестирования ограниченным контингентом пользователей, руководителем проекта или фирмы разработчиков принимается решение о передаче ПС в продажу для широкого круга пользователей. Обобщение результатов Бета-тестирования может использоваться как часть или основа сертификационных испытаний. При Альфа- и Бета-испытаниях принято разделять прогрессивное и регрессивное тестирование. Под прогрессивным понимается тестирование новых программных компонентов, для выявления дефектов и ошибок в исходных текстах программ и спецификациях. Регрессивное тестирование предназначено для контроля качества и корректности изменении в программах и данных после проведения корректировок. Необходимость и широта регрессивного тестирования определяются тем, что значительная доля изменений после Альфа- и Бета-тестирования, в свою очередь, содержит ошибки. Объем тестов и длительность обоих этапов тестирования определяются руководителями проекта в зависимости от сложности комплекса программ и интенсивности потока изменений. 1.2.5. Вопросы для самоконтроляЭтапы или виды деятельности при тестировании ПО. Назовите наиболее важный этап. Схема спектра подходов к проектированию тестов. Что общего в ней со стратегиями тестирования? Исходя из какого соображения может формироваться набор тестов при тестировании по отношению к тексту программы? Причины мотивации тестирования программы в целом начинать с тестирования модулей. На какую стратегию ориентировано тестирование модулей? Основные подходы в тестировании при слиянии модулей. Достоинства и недостатки нисходящего метода тестирования. Самый распространенный подход в тестировании при слиянии модулей. Когда он неприменим? Достоинства и недостатки пошагового тестирования. Нисходящее тестирование и нисходящая разработка – это синонимы? Восходящее тестирование и восходящая разработка – это синонимы? Что такое комплексное тестирование? Что такое тестирование внешних функций и чем оно отличается от комплексного тестирования? Всегда ли осуществимо комплексное тестирование? Приведите пример содержательного описания комплексного теста Разновидности средств генерации тестов и обработки результатов отладки. Существующие варианты схем организации испытаний сложных программных систем. Структура программы испытаний (разделы) для комплексного тестирования. Структура программы обработки результатов испытаний (разделы) для комплексного тестирования. Факторы, характеризующие достоверность приемо-сдаточных испытаний ПС. Характеристика тестов (данных, используемых при тестировании) и субъектов (кто проводит тестирование и что имеет за работу), проводящих Альфа- и Бета-тестирование. Изобразите схематично в виде таблицы. Прогрессивное и регрессивное тестирование. |