Lecture05 (1133562), страница 4
Текст из файла (страница 4)
Снизить влияние этого ограничения можно,подготавливая тесты (а это — наиболее трудоемкая часть тестирования) на основе требованийзаранее, когда исходного кода еще нет. Подход опережающей разработки тестов с успехомиспользуется, например, в рамках XP.Проверка на моделяхПроверка свойств на моделях (model checking) [10] — проверка соответствия ПОтребованиям при помощи формализации проверяемых свойств, построения формальных моделейпроверяемого ПО (чаще всего в виде автоматов различных видов) и автоматической проверкивыполнения этих свойств на построенных моделях.
Проверка свойств на моделях позволяетпроверять достаточно сложные свойства автоматически, при минимальном участии человека.Однако она оставляет открытым вопрос о том, насколько выявленные свойства модели можнопереносить на само ПО.Обычно при помощи проверки свойств на моделях анализируют два вида свойств алгоритмов,использованных при построении ПО. Свойства безопасности (safety properties) утверждают, чтонечто нежелательное никогда не случится в ходе работы ПО. Свойства живучести (livenessproperties) утверждают, наоборот, что нечто желательное при любом развитии событийпроизойдет в ходе его работы.Примером свойства первого типа служит отсутствие взаимных блокировок (deadlocks).Взаимная блокировка возникает, если каждый из группы параллельно работающих в проверяемомПО процессов или потоков ожидает прибытия данных или снятия блокировки ресурса от одногоиз других, а тот не может продолжить выполнение, ожидая того же от первого или от третьегопроцесса, и т.д.ПроверяемыетребованияФормализацияпроверяемыхсвойствФормальныесвойстваАвтоматическаяпроверка свойствЭвристикипостроениямоделиПостроениемодели ПОМодель ПОАнализрезультатовРезультатыпроверки —отчетыРисунок 26.
Схема процесса проверки свойств ПО на моделях.Примером свойства живучести служит гарантированная доставка сообщения, обеспечиваемаянекоторыми протоколами — как бы ни развивались события, если сетевое соединение междумашинами будет работать, посланное с одной стороны (процессом на первой машине) сообщениебудет доставлено другой стороне (процессу на второй машине).В классическом подходе к проверке на моделях проверяемые свойства формализуются в видеформул так называемых временных логик. Их общей чертой является наличие операторов «всегдав будущем» и «когда-то в будущем».
Заметим, что второй оператор может быть выражен спомощью первого и отрицания — то, что некоторое свойство когда-то будет выполнено,эквивалентно тому, что отрицание этого свойства не будет выполнено всегда. Свойствабезопасности легко записываются в виде «всегда будет выполнено отрицание нежелательногосвойства», а свойства живости — в виде «когда-то обязательно будет выполнено желаемое».Проверяемая программа в классическом подходе моделируется при помощи конечногоавтомата. Проверка, выполняемая автоматически, состоит в том, что для всех достижимых приработе системы состояний этого автомата проверяется нужное свойство. Если оно оказываетсявыполненным, выдается сообщение об успешности проверки, если нет — выдается трасса,последовательность выполнения отдельных шагов программы, моделируемых переходамиавтомата, приводящая из начального состояния в такое, в котором нужное свойство нарушается.Эта трасса используется для анализа происходящего и исправления либо программы, либо модели,если ошибка находится в ней.Основная проблема этого подхода — огромное, а часто и бесконечное, количество состояний вмоделях, достаточно хорошо отражающих поведение реальных программ.
Для борьбы скомбинаторным взрывом состояний применяются различные методы оптимизации представленияавтомата, выделения и поиска состояний, существенных для выполнения проверяемого свойства.Ошибки в программахОшибками в ПО, вообще говоря, являются все возможные несоответствия междудемонстрируемыми характеристиками его качества и сформулированными или подразумеваемымитребованиями и ожиданиями пользователей.В англоязычной литературе используется несколько терминов, часто одинаково переводящихсякак «ошибка» на русский язык.• defect — самое общее нарушение каких-либо требований или ожиданий, не обязательнопроявляющееся вовне (к дефектам относятся нарушения стандартов кодирования,недостаточная гибкость системы и пр.).•failure — наблюдаемое нарушение требований, проявляющееся при каком-то реальномсценарии работы ПО.
Это можно назвать проявлением ошибки.• fault — ошибка в коде программы, вызывающая нарушения требований при работе(failures), то место, которое надо исправить. Хотя это понятие используется довольно часто,оно, вообще говоря, не вполне четкое, поскольку для устранения нарушения можноисправить программу в нескольких местах. Что именно надо исправлять, зависит отдополнительных условий, выполнение которых мы хотим при этом обеспечить, хотя внекоторых ситуациях наложение дополнительных ограничений не устраняетнеоднозначность.• error — используется в двух смыслах.Первый — это ошибка в ментальной модели программиста, ошибка в его рассуждениях опрограмме, которая заставляет его делать ошибки в коде (faults).
Это, собственно, ошибка,которую сделал человек в своем понимании свойств программы.Второй смысл — это некорректные значения данных (выходных или внутренних), которыевозникают при ошибках в работе программы.Эти понятия некоторым образом связаны с основными источниками ошибок. Поскольку приразработке программ необходимо сначала понять задачу, затем придумать ее решение изакодировать его в виде программы, то, соответственно, основных источников ошибок три.• Неправильное понимание задач.Очень часто люди не понимают, что им пытаются сказать другие. Так же и разработчикиПО не всегда понимают, что именно нужно сделать.
Другим источником непониманияслужит отсутствие его у самих пользователей и заказчиков — достаточно часто они могутпросить сделать несколько не то, что им действительно нужно.Для предотвращения неправильного понимания задач программной системы служит анализпредметной области.• Неправильное решение задач.Зачастую, даже правильно поняв, что именно нужно сделать, разработчики выбираютнеправильный подход к тому, как это делать. Выбираемые решения могут обеспечиватьлишь некоторые из требуемых свойств, они могут хорошо подходить для данной задачи втеории, но плохо работать на практике, в конкретных обстоятельствах, в которых должнобудет работать ПО.Помочь в выборе правильного решения может сопоставление альтернативных решений итщательный анализ их на предмет соответствия всем требованиям, поддержаниепостоянной связи с пользователями и заказчиками, предоставление им необходимойинформации о выбранных решениях, демонстрация прототипов, анализ пригодностивыбираемых решений для работы в том контексте, в котором они будут использоваться.• Неправильный перенос решений в код.Имея правильное решение правильно понятой задачи, люди, тем не менее, способнысделать достаточно много ошибок при воплощении этих решений.
Корректномупредставлению решений в коде могут помешать как обычные опечатки, так и забывчивостьпрограммиста или его нежелание отказаться от привычных приемов, которые не даютвозможности аккуратно записать принятое решение.С ошибками такого рода можно справиться при помощи инспектирования кода, взаимногоконтроля, при котором разработчики внимательно читают код друг друга, опережающейразработки модульных тестов и тестирования.Первое место в неформальном состязании за место «самой дорого обошедшейся ошибки в ПО»(см. [11,12]) долгое время удерживала ошибка, приведшая к неудаче первого запуска ракетыАриан-5 4 июня 1996 года (см. [13]), стоившая около $500 000 000.
После произошедшего14 августа 2003 года обширного отключения электричества на северо-востоке Северной Америки,стоившего экономике США и Канады от 4 до 10 миллиардов долларов [14], это место можноотдать спровоцировавшей его ошибке в системе управления электростанцией. Широко известнытакже примеры ошибок в системах управления космическими аппаратами, приведшие к их потереили разрушению.
Менее известны, но не менее трагичны, ошибки в ПО, управлявшеммедицинским и военным оборудованием, некоторые из которых привели к гибели людей.Стоит отметить, что в большинстве примеров ошибок, имевших тяжелые последствия, нельзяоднозначно приписать всю вину за случившееся ровно одному недочету, одному месту в коде.Ошибки очень часто «охотятся стаями». К тяжелым последствиям чаще всего приводят ошибкисистемного характера, затрагивающие многие аспекты и элементы системы в целом. Это значит,что при анализе такого происшествия обычно выявляется множество частных ошибок, нарушенийдействующих правил, недочетов в инструкциях и требованиях, которые совместно привели ксоздавшейся ситуации.Даже если ограничиться рассмотрением только ПО, часто одно проявление ошибки (failure)может выявить несколько дефектов, находящихся в разных местах.
Такие ошибки возникают, какпоказывает практика, в тех ситуациях, поведение в рамках которых неоднозначно илинедостаточно четко определяется требованиями (а иногда и вообще никак не определяется —признак неполного понимания задачи). Поэтому разработчики различных модулей ПО имеютвозможность по-разному интерпретировать те части требований, которые относятсянепосредственно к их модулям, а также иметь разные мнения по поводу области ответственностикаждого из взаимодействующих модулей в данной ситуации.
Если различия в их понимании невыявляются достаточно рано, при разработке системы, то становятся «минами замедленногодействия» в ее коде.Например, анализ катастрофы Ариан-5 показал следующее [13].• Ариан-5 была способна летать при более высоких значениях ускорений и скоростей, чемэто могла делать ракета предыдущей серии, Ариан-4.Однако большое количество процедур контроля и управления движением по траектории вкоде управляющей системы было унаследовано от Ариан-4. Большинство таких процедурне были специально проверены на работоспособность в новой ситуации, как в силубольшого размера кода, который надо было проанализировать, так и потому, что этот кодраньше не вызывал проблем, а соотнести его со специфическими характеристиками полетаракет вовремя никто не сумел.• В одной из таких процедур производилась обработка горизонтальной скорости ракеты.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
