Материал: Технол_разраб_прогр_обесп_Гагарина_Кокарева

Процесс построения набора тестов при структурном тестировании принято делить на три фазы:

• конструирование УГП;

• выбор тестовых путей;

• генерация тестов, соответствующих тестовым путям. Первая фаза соответствует статическому анализу программы,

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

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

Вторая фаза обеспечивает выбор тестовых путей. Выделяют три подхода к построению тестовых путей:

• статические методы;

• динамические методы;

• методы реализуемых путей.

Статические методы. Самое простое и легко реализуемое решение — построение каждого пути посредством постепенного его удлинения за счет добавления дуг, пока не будет достигнута выходная вершина управляющего графа программы. Эта идея может быть усилена в так называемых адаптивных методах, которые каждый раз добавляют только один тестовый путь (входной тест), используя предыдущие пути (тесты) как руководство для выбора последующих путей в соответствии с некоторой стратегией. Чаще всего адаптивные стратегии применяются по отношению к критерию С1. Основной недостаток статических методов заключается в том, что не учитывается возможная нереализуемость построенных путей тестирования.

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

1. не терять при этом реализуемости вновь полученных путей;

2. покрыть требуемые элементы структуры программы.

Методы реализуемых путей. Данная методика [16] заключается в выделении из множества путей подмножества всех реализуемых путей. После этого покрывающее множество путей строится из полученного подмножества реализуемых путей.

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

5.6. Интеграционное тестирование

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

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

На рис. 5.2 приведена структура комплекса программ К, состоящего из оттестированных на этапе модульного тестирования модулей М,, М₂, М_и, М₁₂, М₂₁, М₂₂. Задача, решаемая методом интеграционного тестирования, — тестирование межмодульных связей, реализующихся при исполнении программного обеспечения комплекса К. Интеграционное тестирование использует модель «белого ящика» на модульном уровне. Поскольку тестировщику текст программы известен с детальностью до вызова всех модулей, входящих в тестируемый комплекс, применение структурных критериев на данном этапе возможно и оправданно.

Рис. 5.2. Пример структуры комплекса программ

Интеграционное тестирование применяется на этапе сборки модульно оттестированных модулей в единый комплекс. Известны два метода сборки модулей:

• монолитный, характеризующийся одновременным объединением всех модулей в тестируемый комплекс;

• инкрементальный, характеризующийся пошаговым (помо-дульным) наращиванием комплекса программ с пошаговым тестированием собираемого комплекса. В инкрементальном методе выделяют две стратегии добавления модулей:

• «сверху вниз» и соответствующее ему восходящее тестирование;

• «снизу вверх» и соответственно нисходящее тестирование.

Особенности монолитного тестирования заключаются в следующем: для замены не разработанных к моменту тестирования модулей, кроме самого верхнего (К на рис. 5.2), необходимо дополнительно разрабатывать драйверы (test driver) и/или заглушки

(stub) [9], замещающие отсутствующие на момент сеанса тестирования модули нижних уровней.

Сравнение монолитного и интегрального подходов дает следующие результаты.

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

Пошаговое тестирование связано с меньшей трудоемкостью идентификации ошибок за счет постепенного наращивания объема тестируемого кода и соответственно локализации добавленной области тестируемого кода.

Монолитное тестирование предоставляет большие возможности распараллеливания работ, особенно на начальной фазе тестирования.

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

Например, порядок тестирования комплекса К (см. рис. 5.2) при нисходящем тестировании может быть таким, как показано в примере 5.3, где тестовый набор, разработанный для модуля Mi, обозначен как XYi = (X, Y)i.

1. К -> XY_K

2. М, -> XY, 3)M_M->XY_M

4. М₂ -> XY₂

5. М₂₂ -> XY₂₂

6. М_2| -> XY_2I

7. M_I2 -> XY_I2

Пример 5.1. Возможный порядок тестов при нисходящем тестировании (html, txt).

Недостатки нисходящего тестирования:

• проблема разработки достаточно «интеллектуальных» заглушек, т. е. заглушек, способных к использованию при моделировании различных режимов работы комплекса, необходимых для тестирования;

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

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

Особенности восходящего тестирования в организации порядка сборки и перехода к тестированию модулей, соответствующему порядку их реализации.

Например, порядок тестирования комплекса К (см. рис. 5.2) при восходящем тестировании может быть следующим (см. пример 5.4).

1)М_П->ХУ_И

2. M_I2 -> XY_I2

3. М, -> XY,

4. М₂₁ -> XY₂₁

5. M₂(M_2I, Stub(M₂₂)) -> XY₂

6. К(М„ M₂(M_2I, Stub(M₂₂)) -> XY_K

7. М₂₂ -> XY₂₂

8. М₂ XY₂

9. К -> XY_K

Пример 5.2. Возможный порядок тестов при восходящем тестировании.

Недостатки восходящего тестирования:

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

• необходимость в разработке и использовании драйверов [33].

5.7. Системное тестирование

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

Системное тестирование производится над проектом в целом с помощью метода «черного ящика». Структура программы не имеет никакого значения, для проверки доступны только входы и выходы, видимые пользователю. Тестированию подлежат коды и пользовательская документация.

Категории тестов системного тестирования:

1. Полнота решения функциональных задач.

2. Стрессовое тестирование — на предельных объемах нагрузки входного потока.

3. Корректность использования ресурсов (утечка памяти, возврат ресурсов).

4. Оценка производительности.

5. Эффективность защиты от искажения данных и некорректных действий.

6. Проверка инсталляции и конфигурации на разных платформах.

7. Корректность документации.

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

5.8. Эффективность и оптимизация программ

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

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

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

И тем более не следует «платить» за увеличение эффективности снижением технологичности разрабатываемого программного обеспечения. Исключения возможны лишь при очень жестких требованиях и наличии соответствующего контроля за качеством.

Частично проблему эффективности программ решают за программиста компиляторы.

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

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

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

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

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

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

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

Также следует помнить, что при передаче структурных данных в подпрограмму «по значению» копии этих данных размещаются в стеке. Избежать копирования иногда удается, если передавать данные «по ссылке», но как неизменяемые (описанные const). В последнем случае в стеке размещается только адрес данных, например:

Type Mas.4iv array [I. 100] of real; function Summa (Const a:Massiv; .)

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

• выносить вычисление константных, т. е. не зависящих от параметров цикла, выражений из циклов;

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

• минимизировать преобразования типов в выражениях;

• оптимизировать запись условных выражений — исключать лишние проверки;

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

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

Пример 5.3. Пусть имеется цикл следующей структуры (Pascal):

for у: 0 to 99 do for х: 0 to 99 do а [320*х+у] S [k,l];

В этом цикле операции умножения и обращения к элементу S[k] выполняются 10 ООО раз.

Оптимизируем цикл, используя, что 320 = 28 + 26:

ski: =S [k,l]; {выносим обращение к элементу массива из цикла}

for х: 0 to 99 do (меняем циклы местами} begin

х shl 8 + х shl б; {умножение заменяем на сдвиги и выносим из цикла) for у; 0 to 99 do a [i+y] =skl; end;

В результате вместо 10 ООО операций умножения будут выполняться 200 операций сдвига, а их время приблизительно сравнимо со временем выполнения операции сложения. Обращение к элементу массива S[k] будет выполнено 1 раз.

Пример 5.4. Пусть имеется цикл, в теле которого реализовано сложное условие:

for к: 2 to n do begin

ifx[k] > ук then S: S+y[k]-x [к];

if (x [k]< = yk) and (y[k]<yk) then S: = S+yk-x[k]; end;...

В этом цикле можно убрать лишние проверки:

for к: =2 to n do begin

ifx [к]>ук then S:=S+y[k]-x[k] else

ify[k]<yk then S: =S+yk-x [k]; end;

Обратите внимание на то, что в примере 5.3 понять, что делает программа, стало сложнее, а в примере 5.4 — практически нет. Следовательно, оптимизация, выполненная в первом случае, может ухудшить технологичность программы, а потому не очень желательна.

5.9. Стиль программирования

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

5.9.7. Основные принципы форматирования

Основная теорема форматирования гласит, что хорошее визуальное форматирование показывает логическую структуру программы. Создание красивого кода — хорошо, а демонстрация структуры кода — лучше. Если одна методика лучше показывает структуру кода, а другая выглядит красивей, следует использовать ту, которая лучше демонстрирует структуру.

Форматирование — это ключ к структуре программы. Компьютеру важна исключительно информация о скобках или операторах begin и end, а читатель-человек склонен делать выводы из визуального представления кода. Взгляните на фрагмент кода, приведенный ниже, схема отступов в котором заставляет человека думать, что все три выражения выполняются при каждом проходе цикла.

// меняем местами правые и левые элементы во всем массиве for ( i = 0; i < MAX ELEMENTS; i++ )

leftElement

left [ right[

left [ right[ leftElement;

Если код не содержит обрамляющих скобок, компилятор будет выполнять первое выражение МАХЕЬЕМЕЫТЗ раз, а второе и третье — по одному разу. Отступы делают очевидным, что автор кода хотел выполнять все три выражения и собирался поместить скобки вокруг них. Компилятору это неочевидно [35].

Цели хорошего форматирования

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

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

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

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

• выдерживать процедуру исправления. Лучшие схемы форматирования хорошо переносят модификацию кода. Исправление одной строки не должно приводить к изменению нескольких других.

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

5.9.2. Способы форматирования

Можно получить хороший формат кода, по-разному используя несколько инструментов для форматирования.

Неотображаемые символы

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

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

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

Группировка взаимосвязанных выражений — еще один способ применения неотображаемых символов [35].

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

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

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

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

Хотя эту статистику тяжело применить на практике, но одно исследование показало, что оптимальное число пустых строк в программе составляет от 8 до 16 %. Если оно больше 16 %, то время, затрачиваемое на отладку, заметно увеличивается.

Отступы. Применяйте отступы для демонстрации логической структуры программы. Как правило, операторы выделяются отступами, когда они следуют после некоторого выражения, от которого они логически зависят. Оптимальными являются отступы из 2—4 пробелов [35].

Скобки

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

Вариант на С++: 12 + 4% 3 * 7 / 8.

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

5.10. Надежность программного обеспечения

Это комплексное свойство включает две составляющие [3]:

• безошибочность (correctness) — соответствие спецификации;

• устойчивость (robustness) или отказоустойчивость (fault-tolerance) — способность продолжать правильно работать после отказов.

Улучшение первого качества достигается хорошей технологией, предупреждающей ошибки (fault-avoidance). Однако 100%-ное отсутствие ошибок недостижимо. Устойчивость должна быть относительно любых видов отказов, для ее поддержания создаются специальные программно-аппаратные средства.

Отказ (failure) по ГОСТу — нарушение работоспособности изделия и его соответствия требованиям технической документации (рис. 5.3). Применительно к программам (стандарт ШЕЕ/ ANSI) отказ есть неспособность функциональной единицы системы, зависящей от программы, выполнять требуемую функцию в заданных пределах.

Повреждение Отказ

Восстановление

Рис. 5.3. Диаграмма состояний и переходов при отказе

Классификация причин отказов:

1. Физические дефекты:

• внутренние (старение, износ);

• внешние воздействия (радиация, высокая температура).

2. Ошибки людей:

• ошибки эксплуатации или взаимодействия;

• проектные ошибки.

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

Восстановление (Recovery) — возврат в исправное состояние путем:

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

б) автоматически — задействованием резервов;

в) самопроизвольно, обычно быстро.