Липаев В.В. Программная инженерия

Лекция 13. Верификация, тестирование и оценивание корректности компонентов

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

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

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

410

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

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

При анализе обработки данных в пределах областей их определения

методы тестирования целесообразно применять упорядоченно в сле­ дующей последовательности:

—тестирование при значениях данных, определяющих маршруты исполнения программы (стратегия областей);

—тестирование корректности записи и считывания переменных при вычислениях и полноты состава выходных данных на всех маршрутах исполнения программы;

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

—тестирование на полное соответствие спецификации требований состава, значений и точности выходных данных.

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

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

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

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

411

Лекция 13. Верификация, тестирование и оценивание корректности компонентов

Программы. Эти участки в среднем невелики и содержат около 5—10 строк текста программы. Каждая ограниченная область исходных данных соответствует определенному маршруту в программе. Граница области определяется интерпретациями предикатов по маршруту и состоит из набора участков границы, каждый из которых определяется единствен­ ным, простым предикатом, выбирающим дугу маршрута в графе програм­ мы. Каждый участок границы области может быть открытым или закры­ тым в зависимости от оператора условий в предикате. Закрытый участок границы принадлежит ограничиваемой области и формируется предикатами с операторами <, > или = . Открытый участок границы не входит в состав области и формируется операторами < , > и ?^. Общее число предикатов в маршруте — это верхний предел числа граничных участков области вход­ ных переменных данного маршрута, так как некоторые предикаты марш­ рута могут в действительности не создавать граничных участков. Такие случаи возникают, когда предикат требуется для нескольких путей, и в некоторых из них повторно анализируется на маршруте.

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

Сложность тестов линейно растет с увеличением размерности про­ странства исходных данных (числа требований или переменных) и с рос­ том числа предикатов на маршрутах. Для многих типовых модулей слож­ ность тестов оказывается допустимой для практически полной проверки модуля. Ограничения метода проверки областей могут проявляться при

412

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

сложных организациях циклов, когда резко возрастает число маршрутов и анализируемых условий.

Тестирование корректности определения и использования дан­ ных на маршрутах исполнения программы. Если маршруты исполнения программы соответствуют допустимым областям изменения входных дан­ ных, то целесообразно проверять корректность основных операций обра­ ботки данных на выделенных маршрутах. Каждая величина на маршруте исполнения программы считывается из памяти, и после использования для вычислений записывается в память ЭВМ для хранения и последующей обработки. Чередование операций чтения и записи переменных может быть нарушено в результате ошибок в программе. Для выявления таких ошибок проводится тестирование корректности записи и считывания ре­ альных данных или статический анализ этих операций по исходному тек­ сту программы.

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

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

том следующих правил:

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

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

413

Л Е К Ц И Я 14

ИНТЕГРАЦИЯ, КВАЛИФИКАЦИОННОЕ ТЕСТИРОВАНИЕ

И ИСПЫТАНИЯ КОМПЛЕКСОВ ПРОГРАММ

14.1. Процессы оценивания характеристик и испытания программных средств

Для оценивания характеристик и испытаний программных средств на различных этапах жизненного цикла в качестве методологической основы целесообразно использовать рекомендации стандарта ISO 14598:1-6 — Оценивание программного продукта. Процесс оценивания ПС в стандарте представлен как совокупность действий, выполняемых в кооперации за­ казчиком и оценщиком — испытателем. Потенциальными заказчиками оценивания ПС могут быть разработчики, поставщики, покупатели, пользо­ ватели ПС, производители систем обработки информации, а также третей­ ские испытательные лаборатории программных продуктов. Для получе­ ния наибольшего эффекта от результатов испытаний рекомендуется, что­ бы оценивание было насколько возможно:

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

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

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

415

Лекция 14. Интеграция, квалификационное тестирование и испытания комплексов...

— беспристрастным — исполнители процесса оценивания должны относиться непредубежденно к любому конкретному результату.

Общую схему процессов оценивания характеристик комплексов про­ грамм составляют (рис. 14.1):

Формализация исходных требований для оценки программного средства:

-определение целей испытаний и оценивания качества на промежуточных и завершающих этапах ЖЦ ПС;

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

-идентификация потребителей результатов оценивания;

-выделение особенностей модели оценивания и состава требуе­ мых характеристик качества

Формализация принципов оценивания характеристик

ииспытаний программного средства:

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

-установление уровней приоритета характеристик и атрибутов качества;

-выделение критериев для экспертизы и сравнения характеристик качества с требованиями

Проектирование процессов оценивания и испытаний характеристик программного средства:

-разработка планов проведения оценки характеристик программ­ ного средства в соответствии с потребностью пользователей и этапами жизненного цикла;

-проектирование процессов оценивания характеристик и испы­ таний программного средства

Реализация процессов и использование результатов оценивания характеристик программного средства:

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

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

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

Рис. 14.1

416

14.1.Процессы оценивания характеристик и испытания программных средств

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

—формализация принципов и особенностей оценивания при прове­ дении экспертиз, измерений и испытаний характеристик программного средства, выделение критериев для сравнения полученных характеристик

стребованиями;

—планирование и проектирование процессов оценивания характери­ стик в жизненном цикле программного средства в соответствии с потреб­ ностями пользователей этих характеристик;

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

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

Решение о проведении оценивания характеристик ПС может быть принято в процессе разработки и всего ЖЦ. Если такое решение принято на начальном этапе разработки, то появляется возможность встроить в процессе разработки тесты и средства измерения для испытаний. Это обес­ печивает максимальный успех в удовлетворении всех требований относи­ тельно результатов оценивания характеристик ПС и минимизирует риск ошибок в экстремальных, незапланированных ситуациях. Когда заказчи­ ком является разработчик ПС, ранний контакт с оценщиком для испыта­ ния или экспертизы может помочь разработчику учесть некоторые специ­ альные требования со стороны испытателя. Для очень больших, сложных проектов ПС разработчику должно быть выгодным иметь детальную коо­ перацию с оценщиком характеристик во время всего процесса разработки продукта для минимизации продолжительности и стоимости процесса ис­ пытаний. Обязанностью заказчика мсшлтгяуж должно быть:

— установить его необходимые легальные права для выполнения испытаний ПС;

417

Лекция 14. Интеграция, квалификационное тестирование и испытания комплексов...

—Предоставить испытателю информацию, необходимую для иденти­ фикации и описания программного средства и компонентов;

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

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

—установить требования к конфиденциальности информации, пере­ даваемой на испытания;

—при необходимости обеспечить поддержку испытателю, включая обучение и доступ к подходящим документам;

—гарантировать своевременную поставку испытателю описания и компонентов ПС, включая документацию и другие материалы;

—информировать испытателя о любых возможных факторах, кото­ рые могут обесценить результаты испытаний.

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

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

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

—предоставить квалифицированный и обученный персонал для вы­ полнения испытаний;

—обеспечить инструментарий и технологию оценивания;

—выполнить испытания в соответствии с оценочными требованиями

испецификацией заказчика;

—хранить записи любой работы, выполняемой при оценивании, ко­ торые воздействуют на результаты;

418

14.1.Процессы оценивания характеристик и испытания программных средств

—обеспечить наглядность проведения испытаний для наблюдения заказчиком и своевременную передачу отчета об оценивании заказчику.

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

Спецификация оценивания — испытаний должна определять об­ ласть экспертизы и измерения различных компонентов продукта, переда­ ваемого на оценивание. Уровень детализации в спецификации испытаний должен быть таким, чтобы на ее основе гарантировались повторяемость и воспроизводимость испытаний. Заказчик должен представить описание оцениваемого продукта. Целью такого описания является определить об­ ласть оценивания и идентификацию тех компонентов, которые рассматри­ ваются как часть продукта, в отличие от компонентов ПС, на которые только ссылаются для облегчения понимания функций продукта. Это дол­ жно позволить разложить оценочные требования на субхарактеристики. Затем испытатель должен специфицировать методы измерения и экспер­ тизы, предназначенные для анализа характеристик, субхарактеристик и атрибутов качества выбранных компонентов. Оценщик должен выполнять верификацию спецификации оценивания в соответствии с требованиями, установить, что компоненты, перечисленные в описании продукта, содер­ жат всю необходимую информацию для выполнения оценивания в соот­ ветствии с требованиями.

План испытаний или экспертизы характеристик программных про­ дуктов должен состоять из разделов:

—введение — постановка задачи и цели оценивания — испытаний;

—методология обеспечения объективности испытаний характерис­

тик ПС;

—выделенные для проекта характеристики и атрибуты качества и безопасности ПС по стандарту ISO 9126:1-4 и другим стандартам;

—требуемое качество ПС и достоверности процессов испытаний;

—расписание выполнения работ по испытаниям характеристик ПС;

—распределение обязанностей и ответственности специалистов при оценивании характеристик и атрибутов качества;

419