РазрПрогрПрилож / Липаев_Программная инженерия

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

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

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

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

—по данным моделирующего стенда или генераторов тестов, имити­ рующих отдельные объекты внешней среды;

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

—в полностью адекватной реальной или имитированной внешней среде и с реальными воздействиями от операторов-пользователей (см. лек­ цию 14).

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

390

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

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

Рассмотренная схема ориентирована на тестирование и испытания комплекса программ, размещаемого на единой аппаратной платформе. При cos^diHHH распределенных систем клиент-сервер возникают дополнитель­ ные, весьма сложные задачи тестирования. Программные средства, разме­ щенные на аппаратных платформах клиентов и серверов, необходимо пер­ воначально тестировать автономно по представленной выше полной про­ грамме, а затем дополнительно их взаимодействие. Это взаимодействие клиентской и серверной частей программного комплекса должно быть подготовлено автономным тестированием всей системы телекоммуника­ ции и гарантированием ее качества. После этого следует повторить послед­ ние три этапа комплексного тестирования в реальном времени, представ­ ленные на рис. 13.6, но уже при полном взаимодействии обоих функцио­ нальных компонентов системы клиент-сервер.

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

Как отмечалось выше (см. п. 13.1), оценивание корректности про­ граммных средств можно представить двумя видами работ:

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

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

391

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

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

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

На практике при отсутствии упорядоченного анализа потоков управ­ ления некоторые маршруты в программе оказываются пропущенными при тестировании (до 50%), поэтому первая задача, которая должна решаться при тестировании структуры программ, — это получение информации о

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

392

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

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

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

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

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

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

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

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

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

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

393

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

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

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

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

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

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

—стратегия 3 базируется на использовании вероятности исполнения маршрутов при реальном функционировании программы.

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

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

394

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

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

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

Эффективность тестирования определяется полнотой проверки про­ граммного модуля или вероятностью наличия невыявленных ошибок в зависимости от затрат ресурсов: на создание тестов, исполнение про­ грамм и анализ результатов тестирования. Затраты в значительной степе­ ни зависят от суммарной сложности формирования тестов, проверяющих маршруты исполнения программы. На каждой дуге графа программы между условными переходами производятся вычисления и преобразования пере­ менных, объем которых может изменяться в широких пределах. Для упро­ щения анализа и оценивания тестирования структуры программ предполо­ жим, что длительность и сложность вычислений на дугах графов про­ грамм одинаковы и относительно невелики. Некоторые вершины графа программы могут образовываться в результате схождения дуг без после­ дующего ветвления. Такие вершины не влияют на число маршрутов, и их можно обобщать с ближайшей последующей вершиной, в которой проис­ ходит ветвление. При этих предположениях сложность теста, проверяю­ щего каждый /-Й маршрут, в первом приближении пропорциональна числу дуг графа программы, входящих в этот маршрут, или числу Д условий, которые необходимо задать в тесте.

Экспериментально подтверждена адекватность использования

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

395

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

МОЖНО оценивать по числу маршрутов Мх, необходимых для их проверки, или более полно по суммарному числу условий Ех, которое необходимо задать в тестах для прохождения всех маршрутов программы, выделенных по Х-му критерию:

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

два вида:

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

—маршруты принятия логических решений и преобразования логи­ ческих переменных.

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

те, умноженном на число значений Sij для каждой исходной у-й величины на этом маршруте:

396

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

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

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

Структурная сложность программного модуля может быть рас­ считана по числу маршрутов Мх в программе и сложности каждого /-го маршрута £"/. Эти показатели в совокупности определяют минимальную сложность ExTQCTOb для проверки программного модуля (13.1), а следова­ тельно, трудоемкость его разработки и тестирования и вероятность про­ пуска логической ошибки в программе. Программные модули являются наиболее массовыми компонентами в ПС и требуют для тестирования суммарно наибольших затрат ресурсов. Затраты на тестирование каждого модуля прямо пропорциональны сложности, которая зависит от его струк­ туры и объема вычислений /,. При тестировании программного модуля необходимо задать и проанализировать число значений параметров:

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

м

Cx=cf^(2,Sy+E,). (13.4)

,=1 7=1

397

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

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

CnoJKHocmb тестирования программ, содер:н€ащих циклы. Нали­ чие циклов в программе способно резко увеличивать сложность их тести­ рования. Полное, исчерпывающее тестирование должно охватывать про­ верку каждого маршрута в цикле при всех возможных итерациях цикла и при всех сочетаниях циклов с маршрутами ациклической части програм­ мы. Предположим для простоты, что число маршрутов в нижней ацикли­ ческой части программы равно Мз = 1. Тогда полное множество маршру­ тов М состоит из полной совокупности всех маршрутов М^ в верхней ациклической части программы и группы маршрутов А/з, в которой к каждому маршруту из М\ присоединено 1..2..3... итерации (витка) цикла. При этом на каждой итерации выполняется, по крайней мере, один из внутренних маршрутов тела цикла.

Например, для графа, имеющего один цикл, требующего исполнения пяти итераций (витков) с тремя внутренними маршрутами, а также со­ держащего Ml = 10 ациклических маршрутов, проходящих через цикл, суммарное число маршрутов для исчерпывающего тестирования равно Л/= (3 X 5) X 10 = 150. При возрастании любого из сомножителей (числа независимых ациклических маршрутов, проходящих через цикл, числа внутренних маршрутов тела цикла или числа его итераций) пропорцио­ нально растет их произведение, а следовательно, и сложность тестирова­ ния. Поэтому исчерпывающее тестирование реальных слолсных про­

грамм с циклами может быть практически невозмо^н:но.

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

— на разных итерациях цикла исполняются независимо все возможные маршруты тела цикла;

398

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

—на всех итерациях цикла исполняется один и тот же маршрут тела цикла или некоторая определенная их последовательность;

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

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

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

399