Предисловие Специальный выпуск трудов Института системного программирования, который Вы держите в руках, состоит из двух частей и содержит работы сотрудников отдела технологий программирования, посвященные различным методам тестирования сложных систем. В этом выпуске мы постарались представить информацию практически обо всех работах, которые ведутся на данный момент в отделе. К сожалению, это не получилось сделать в полной мере, и ряд разработок остались за рамками сборника, прежде всего, работы по тестированию телекоммуникационных протоколов и систем интеграции уровня предприятия. Однако набор тем статей все же позволяет получить некоторое представление о текущей деятельности отдела. Разнообразие затронутых в сборнике предметов связано с множеством задач, с которыми приходится сталкиваться при оценке качества сложной программной или аппаратной системы. Тем не менее, и из чисто эстетических, и из прагматических соображений, хотелось бы иметь дело с некоторым единым, унифицированным подходом к тестированию. Несколько лет назад, еще не столкнувшись с большинством проблем, играющих важную роль в текущих проектах, мы полагали, что такой подход у нас есть — это технология UniTESK, предназначенная для автоматизации разработки тестов на основе формальных спецификаций. Какие-то элементы этого взгляда вполне подтвердились, например, удалось использовать технологию UniTESK для тестирования модулей микропроцессоров. Но сейчас мы знаем больше как о различных методах тестирования, так и о разнообразных внешних ограничениях, которые могут в значительной степени определять используемые в проектах технологии, и недостаточная универсальность положений, лежавших в основе нашего подхода, становится все более очевидной. Тем не менее, некоторую эклектичность тех методик и технологий, которые разрабатываются и используются сейчас, мы склонны рассматривать не как финальное состояние, а как переход к новому этапу унификации, позволяющему более целостно осмыслить проблемы обеспечения качества для сложных систем. Итогом должно стать создание «новой версии» подхода UniTESK, унифицирующего методы тестирования в значительно более широкой области и на новом уровне. Пока контуры такого подхода лишь едва проглядывают за многообразием используемых техник и методов. Анализ ситуации проводит А. К. Петренко в первой статье первой части сборника «Унификация в автоматизации тестирования. Позиция UniTESK». Вторая и третья статьи сборника посвящены теории, лежащей в основе методов тестирования компонентов распределенных систем. И. Б. Бурдонов и А. С. Косачев в первой статье «Системы с приоритетами: конформность, 5
тестирование, композиция» формализуют понятие взаимодействия с приоритетной обработкой сообщений различных типов и строят теорию тестирования для компонентов, взаимодействующих подобных образом. Во второй своей статье «Эквивалентные семантики взаимодействия» они анализируют наборы тестовых возможностей, предоставляемых различными семантиками взаимодействия, и определяют условия эквивалентности таких семантик, т.е. условия, при выполнении которых их возможности с точки зрения тестирования одни и те же. Тему тестирования компонентов распределенных систем продолжает статья В. С. Мутилина «Многопоточное тестирование программных интерфейсов». В ней представлен метод проверки программ на безопасность их работы в многопоточном окружении, сочетающий элементы тестирования и дедуктивного анализа программного кода. Две следующих статьи рассказывают о критериях тестового покрытия, используемых при тестировании на основе формальных спецификаций, и техниках вычисления достигнутого покрытия во время тестирования. Статья В. В. Кулямина «Критерии тестового покрытия, основанные на структуре контрактных спецификаций» определяет несколько удобных для использования критериев покрытия на базе спецификаций. Статья С. В. Зеленова и С. А. Зеленовой «Автоматическое определение выполнимости наборов формул для операций сравнения» посвящена алгоритму, позволяющему отбрасывать невыполнимые комбинации значений формул, использующих сравнения чисел, получая таким образом более точные отчеты о достигнутом тестовом покрытии. Еще одна статья С. В. Зеленова и С. А. Зеленовой «Генератор сложных данных Pinery: реализация новых возможностей UniTESK», написанная в соавторстве с А. В. Демаковым, представляет инструмент Pinery для генерации сложных тестовых данных и различные техники его использования, позво-ляющие точнее нацелить процесс генерации на создание специфических данных. Статья С. Г. Грошева «Локализация ошибок методом сокращенного воспроизведения трассы» описывает методику минимизации сложных тестов для облегчения анализа и более аккуратной локализации обнаруживаемых ими ошибок, а также инструмент, позволяющий строить минимальные тесты автоматически. В последней в первой части статье Е. С. Чернова и В. В. Кулямина «Тестирование современных библиотек тригонометрических функций» рассказывается о результатах тестирования нескольких реализаций тригонометрических функций с помощью разработанных в ИСП РАН общих подходов к проверке правильности работы математических библиотек. Член-корреспондент РАН В. П. Иванников Кандидат физ.-мат. наук В. В. Кулямин 6
Унификация в автоматизации тестирования. Позиция UniTESK А. К. Петренко
[email protected] Аннотация. Рассматриваются современные тенденции унификации в средствах автоматизации тестирования, анализируется текущий уровень унификации в инструментах семейства UniTESK и очерчиваются возможные формы унификации, которые позволят расширить круг возможностей технологии.
1. Введение. Специализация и унификация в развитии UniTESK Первые работы по созданию новой технологии тестирования, которая вскоре была названа UniTESK, начались в ИСП РАН во второй половине 1999 года. Само название включало в себя один из корней слова унификация (UNIfication), а в целом расшифровывалось как Unified TEsting Specification toolKit. Унификации в UniTESK постоянно придавалось большое значение. Одним из важных элементов унификации был принцип использования однородного спецификационного расширения языков программирования — во всех расширениях использовалась одна и та парадигма спецификации (контрактные спецификации) и единообразная архитектура теста, включающая одинаковые механизмы взаимодействия тестовой системы с целевой системой. Этот принцип позволил, следуя одной общей методике, создавать тесты для программного обеспечения на различных языках программирования. В основу новой технологии был положен опыт разработки и использования технологии KVEST [1] и опыт ее использования в задачах тестирования программного интерфейса (API, Application Program Interface) ядра операционной системы компании Nortel Networks [2]. Кроме того, рассматривались сценарии применения новой технологии при тестировании реализаций телекоммуникационных протоколов и других распределенных и компонентных систем. Предшественник UniTESK, технология KVEST, была в некотором роде «еще более унифицированной». Она в качестве языка формального описания функциональных требований и тестовых сценариев использовала язык формальных спецификаций RSL [3], что, в принципе, 7
позволяло разрабатывать спецификации и тесты независимо от языков программирования, которые используются в реализации. Опыт KVEST показал, что в чем-то принятые принципы унификации оказались достаточно удачными, а в чем-то совсем неприемлемыми. К удачным можно отнести подход к описанию функциональных требований в форме контрактных спецификаций — в виде ограничений типа пред- и постусловия и ограничений на типы данных. К неудачным приходится отнести принцип использования единого, универсального языка спецификаций. Причем первым основанием для критики такой декларации является совсем не ограниченность возможностей языка (хотя RSL достаточно консервативный язык, он не имеет объектно-ориентированных возможностей, в нем практически нет средств для описания темпоральных свойств и др.). Главным тезисом критики RSL является его непохожесть на распространенные языки программирования, что сразу вызывает сложности как в обучении будущих пользователей, так и в совместном использовании программ на языке RSL и языке программирования во время разработки и отладки теста. Выбирая принципы унификации UniTESK, мы сделали небольшой шаг назад, сказав, что языки спецификаций для разных языковых платформ реализации могут быть разными. Так появилось семейство однородных спецификационных расширений для разных языков: для Java — J@va, для языка C — SEC (Specification Extension of C) и Chase — спецификационное расширение для C#. Одновременно с разработкой новых инструментов семейства UniTESK мы расширяли круг использования этих инструментов. Поскольку о тестировании реализаций протоколов мы думали заранее, опыт применения CTESK (UniTESK для C-платформы) не потребовал кардинальных переделок в инструменте. Однако при анализе возможностей UniTESK-инструментов для системного тестирования компиляторов стало ясно, что для этого требуются новые техники, так появились инструменты BNF tool и ОТК. Затем были попытки применения UniTESK для тестирования графических пользовательских интерфейсов и их разновидности — Web-интерфейсов. Часть попыток была вполне успешной, тесты удавалось построить достаточно быстро, их было легко модернизировать и синхронизовать с эволюционирующей реализацией. Однако в общем случае, оказалось, что помимо чисто технических проблем управления графическим интерфейсом имеются и принципиальные ограничения UniTESK в плане возможностей по описанию/спецификации пользовательского интерфейса как такого. В последние 3 года спектр работ, в которых проводились эксперименты по применению UniTESK, резко расширился. В него вошли тестирование распределенных платформ интеграции крупных информационных систем, тестирование ОС реального времени, тестирование библиотек ОС Linux, тестирование системы поддержки времени исполнения Java, реализаций 8
протоколов Mobile IPv6, IPsec, IPMP и др. Расширение спектра приложений, естественно, повлекло необходимость развития имевшихся инструментов UniTESK, необходимость разработки новых и использования инструментов, имеющихся на рынке. В итоге иногда складывается впечатление, что для каждой новой задачи приходится искать (а, если найти не удается найти, то создавать) новый инструмент. С одной стороны, специализация — это тоже известный путь развития. Не бывает универсальных самолетов, автомобилей, даже в более прозаических вещах, таких как ложки и ножи, также нет универсальных решений. Однако универсальность и унификация — это не одно и тоже. Унификация — это средство, позволяющее на основе некоторого типового набора возможностей получить решение широкого круга задач. Интуиция подсказывает, что в тестировании может быть построен набор средств, достаточно ограниченный, из которых как из Lego-конструктора можно собрать нужный инструмент. Анализу достигнутого уровня унификации в автоматизации тестирования и направлениям развития унификации и посвящается данная статья.
2. Унификация в программировании и в автоматизации тестирования Начнем с определения термина «Унификация». Унификация (от лат. unus — один и facio — делаю) — приведение к единообразию, к единой форме или системе (Большой энциклопедический словарь, М., БСЭ, 1964). Унификация — в технике, приведение различных видов продукции и средств её производства к рациональному минимуму типоразмеров, марок, форм, свойств и т.п. Основная цель У. — устранение неоправданного многообразия изделий одинакового назначения и разнотипности их составных частей и деталей, приведение к возможному единообразию способов их изготовления, сборки, испытаний и т.п. У.— важное направление в развитии современной техники, комплексный процесс, охватывающий вопросы проектирования, технологии, контроля и эксплуатации машин, механизмов, аппаратов, приборов. В условиях научно-технической революции принципы У. используют не только в отраслях производства, но и в др. сферах человеческой деятельности... (Большая советская энциклопедия. БСЭ, 1969-1978 [4]). В качестве ключевых понятий, которые определяют цели и формы унификации, авторы этой статьи называют: взаимозаменяемость; типизация; построение агрегатных унифицированных систем;
9
качество выпускаемой продукции, её надёжность и долговечность благодаря более высокой технологичности конструкции изделий и проработанной технологии их изготовления; стандартизация; единые системы технической документации; специализация производства. Похоже, авторы БСЭ затронули практически все моменты, которые являются ключевыми в автоматизации тестирования. Пожалуй, по понятным причинам, осталась не затронутой только одна тема — интероперабельность компонентов тестовых систем.
2.1. Унификация в использовании и в разработке средств тестирования Каков опыт унификации в программировании, каковы удачные примеры унификации в программировании? Самый первый общепризнанный результат унификации — это библиотеки программ (раньше они назывались библиотеками стандартных программ). Собственно, с создания библиотек и средств их использования началось программирование как новая научная и техническая дисциплина. Следующим направлением унификации можно назвать стандартизацию языков программирования. Второй, возможно, не такой заметный, но чрезвычайно важный пример унификации — это определение стандартных представлений программ, позволяющих объединять объектные модули, оттранслированные с различных языков программирования в единую программную систему. Это как раз тот случай, когда мы не можем предложить совершенно общего, универсального решения при выборе языка программирования, но имеем средства унификации, чтобы, комбинируя модули на разных языках, решить любую стоящую перед нами задачу. Хороший пример унификации — общая схема построения компиляторов, которая предусматривает фазы лексического, синтаксического, семантического анализа, вместе они образуют так называемый front-end компилятора, фазы оптимизации и генерации кода, которые вместе образуют так называемый back-end. Такая разбивка на фазы позволяет не только упростить изучение устройства компиляторов, становится реальной возможность построения компилятора методом сборки отдельных компонентов. Можно собрать несколько фронт-ендов (для разных языков) и несколько бэк-ендов для разных аппаратных платформ и получить компилятор, который объединяет в себе наилучшие качества, реализованные в его отдельных модулях. Унификация в компиляторах проводится и на уровне инструментов разработки компиляторов. Например, имеются средства типа Lex и Yacc, при помощи которых можно сгенерировать модули фронт-енда. Рассматривая вопросы унификации в автоматизации тестирования, следует обратить внимание на то, что имеется два ракурса этого рассмотрения. Первый ракурс — это позиция разработчика тестов, второй — позиция 10
разработчика средств автоматизации тестирования. Начнем с анализа позиции тестировщика, или разработчика тестов. Переходя от проекта к проекту или переключаясь с разработки тестов для одной системы к другой, тестировщик отвечает на однотипные вопросы: На каких входных данных нужно проверять систему? Что является критерием правильности функционирования системы? Что является критерием полноты тестирования? и др. В зависимости от особенностей интерфейса системы, от возможностей взаимодействия с системой (например, за счет прямого доступа к ее внутреннему состоянию), от требований заказчика и других условий тестировщик выбирает (или получает в свое распоряжение) набор инструментальных средств для разработки тестов. По крайней мере, из соображений экономии времени, очевидно, что разработка тестов будет выполняться быстрее, если в новом инструментарии тестировщик увидит привычные средства с привычными возможностями. Это возможно только при условии, что при разработке различных инструментов следуют некоторой общей схеме унификации1. Теперь вернемся к унификации с точки зрения разработки самих инструментов автоматизации тестирования. По сути, все инструменты автоматизации тестирования выполняют ограниченный набор операций. Сложность этого набора можно сравнить со сложностью компиляторов, недаром, некоторые генераторы тестов называются трансляторами (например, изначальное название генератора тестов ADLT расшифровывалось как Assertion Definition Language Translator [5]). Если аналогия верна, то, казалось бы, что в распоряжении разработчиков инструментов генерации тестов уже давно должны были появиться генераторы входных тестовых данных, генераторы тестовых оракулов, выносящих вердикт на основе того или иного представления требований, анализаторы тестового покрытия в соответствии с тем или иным критерием покрытия и так далее. У разработчиков компиляторов есть еще один «инструмент унификации» — это компилятор GCC, который можно рассматривать как коллекцию типовых решений задач разработки компиляторов. На основе такой «коллекции» многие строят свои собственные компиляторы методом инкрементальных модификаций. Какова же ситуация с унификацией в нашем случае? Ответ пугает своей категоричностью — инструментов, которые позволяли бы воспользоваться типовыми решениями перечисленных выше задач тестирования, нет. Одной из причин этого служит то, что нет единого подхода ни к форме представления
1
Заметим, что временной фактор в оценке эффективности процесса разработки тестов не является единственным и, возможно, не является главным. Унификация ведет к постоянному росту профессионального мастерства, что, в свою очередь, ведет к повышению качества тестирования. 11
входных данных для программ таких библиотек, ни к форме представления их результатов.
2.2. Обзор работ по унификации и стандартизации средств тестирования Тема унификации технологий и инструментов тестирования широко и активно обсуждается. Сейчас трудно сказать, является ли этот интерес некоторой модной темой или в программной индустрии имеется реальная заинтересованность, подпитывающая исследования и разработки (одним из оснований для сомнений в реальной заинтересованности является то, что активность в этой области заметна в Европе и мало заметна в США и Азии). Большая часть исследований и публикаций по этой теме так или иначе опираются на UML 2.0 Testing Profile (U2TP) [6], который развивается Консорциумом U2TP [7]. Это профиль унифицированного языка моделирования систем UML 2.0. U2TP претендует стать стандартом в данной области и является развитием подхода Model Driven Architecture (MDA), который продвигается группой OMG [8]. В Консорциум U2TP входят такие известные компании как Ericsson, IBM, Motorola, Telelogic и один из ведущих немецких исследовательских институтов Fraunhofer FOKUS. U2TP ограничивает спектр рассмотрения процессов тестирования тестированием по методу «черного ящика». Сам он рассматривается как систематическая модель для описания компонентов тестовых систем и их возможных взаимодействий в ходе выполнения тестов с помощью конструкций UML 2.0 и базируется на метамодели UML. Такие описания в дальнейшем используются как артефакты, позволяющие автоматизировать часть работ по созданию и исполнению тестов. Одна из задач U2TP состоит в систематизации терминов, которые используются при описании архитектуры тестов, целей тестирования (test purposes), тестовых вариантов (test cases) и средств их привязки к тестируемым системам (адаптеров), процессов тестирования и участников процесса. Помимо инициативы U2TP в Европе имеется еще несколько проектов, например, два проекта из программы ITEA (Information Technology for European Advancement) [9], которая, в свою очередь является ветвью программы Eureka [10]. EAST/EEA (Electronics Architecture and Software Technology — Embedded Electronic Architecture) [11]. Суть этого проекта, объединяющего 23 партнера из 4 стран, — разработка профиля UML 2.0, который станет языком описания архитектуры программноаппаратных систем в автомобильной промышленности. В частности, отдельным разделом в разрабатываемом профиле выделены процессы верификации и валидации, включающие тестирование, и набор модельных компонентов, используемых в рамках этих процессов. 12
Проект TT-Medal [12], цель которого — продвижение наукоемких методов тестирования, в особенности с использованием языка TTCN3, в промышленную практику европейских компаний. Практическим результатом проекта стала интеграция трех инструментов: TTworkbench [13], включающего компилятор TTCN-3, среду разработки тестов в Eclipse, генераторы кодеков; Classification Tree Editor (CTE) [14], средство для ручного построения классов эквивалентности в системах с большим числом параметров и генератор тестов финской компании Conformiq [15]. В рамках данного проекта рассматривались различные способы построения интерфейса между тестирующей системой и тестируемой. В проекте была продемонстрирована возможность использования описаний интерфейсов на ASN.1, IDL, и XML. Стоит упомянуть еще два проекта из программы ITS Framework Programme 6. HIDENETS (Highly Dependable IP-based Networks and Services) [16] нацелен на разработку устойчивой к отказам архитектуры (resilience solutions) для распределенных и мобильных систем (mobility-aware services). Так же, как и в других проектах, которые мы здесь рассматриваем, большое внимание уделяется не только самим целевым системам, но инфраструктуре для моделирования, верификации и валидации. Этим объясняется использование в проекте U2TP. В контексте данной статьи интересным является полный обзор стандартов, которые затрагивают вопросы унификации и переиспользования артефактов как ПО в целом, так и артефактов из области тестирования. В частности, достаточно подробно анализируется RAS: Reusable Asset Specification [17], также разработанный под патронажем OMG. ATESST (Advancing Traffic Efficiency and Safety through Software Technology) [18]. Одним из результатов этого проекта является отчет по теме Linking Requirements and Test Artifacts [19]. В нем подробно перечисляются различные способы выделения требований и их привязки к различным артефактам и процессам проектов, включая тесты и их отдельные компоненты. В качестве объективной оценки достижений в данной области можно сослаться на то, что многие работы, которые изначально поддерживались европейскими программами, теперь нашли свое продолжение в рамках альянса AUTOSAR [20], который финансируется индустриальными партнерами. Сейчас список партнеров альянса включает практически всех крупных поставщиков автомобилей и электроники для них. Вместе с тем, имеется по крайней мере два аспекта, в которых результаты активности, связанной с U2TP, можно было оценить как недостаточно значимые (естественно, здесь мы рассматриваем только проблемы тестирования): спектр рассматриваемых проблем и подходов к их решению, а 13
также доведение результатов до реальных техник, технологий, программных продуктов и автоматизированных сервисов. Начнем с последнего аспекта. Сейчас основной формой практических результатов являются стандарты, описывающие архитектуры и процессы тестирования. Пока эти стандарты являются некоторыми рекомендациями, они не обрели четкой и строгой формы, необходимой для того, чтобы быть переведенной на язык интерфейсов компьютерных систем. Причем, наряду с организационными трудностями, которых всегда много при создании новых стандартов, похоже, есть трудности, обусловленные нестыковкой подходов при описании артефактов и ролей на абстрактном уровне и реальными технологиями, методами и инструментами, которые используются в производстве. Возможно, корни этой проблемы лежат в сфере первого из указанных выше аспектов, а именно в том, что идеологически подход U2TP и язык разработки тестов TTCN-3 следуют логике разработки ручных тестов и практически не уделяют внимания собственно методам генерации тестов. По различным соображениям приверженцы U2TP пытаются сохранить представление о тестовом варианте (test case) как о простом сценарии. Сложные модели, из которых могут извлекаться тесты, в концепции U2TP просто не рассматриваются. Профиль ограничивается описанием компонентов самих тестов, без всякой оглядки на способы их получения. Идея «черного ящика» как единственного рассматриваемого подхода к тестированию также позволяет разработчикам U2TP закрывать глаза на проблемы анализа структуры реализации, без чего нельзя решить, например, такие важные задачи как построение модели тестового покрытия и модели ошибок, учитывающей особенности реализации и хорошо зарекомендовавшие себя на практике эвристики. Эти ограничения в постановке задачи унификации не позволяют решить ее с использованием наиболее перспективных подходов к автоматической генерации тестов. В частности, на основе U2TP невозможно обеспечить интеграцию различных передовых техник верификации и валидации программ, таких как проверка моделей (model checking), верификационный мониторинг2 (run-time verification), генерация тестов методами статического анализа или с помощью генетических алгоритмов и др. Сложность интеграции этих методов обусловливается тем, что при эффективном решении задачи автоматической генерации тестов для реальных больших систем часто нельзя выделять решение отдельных задач генерации в модули, достаточно слабо связанные друг с другом. Простейший пример: пусть нам надо отобрать представителей различных классов эквивалентности из некоторого
2
Русский перевод В. В. Куляминым. 14
термина
«run-time
verification»
предложен
дискретного многомерного пространства, являющегося областью определения некоторой функции. Логически задачу можно разбить на следующие три шага. Построить все наборы значений — точки пространства. Разбить полученное множество на классы эквивалентности. Выбрать из каждого класса по одному произвольному представителю.
На практике такой последовательный подход и, соответственно, простая схема композиции модулей, которые отвечают за выполнение каждого шага, не работают по простой причине — число точек в области определения, хотя и конечно, но не может уместиться ни в каких разумных вычислительных ресурсах. Вместе с тем эта задача имеет решение, которое требует как можно более прямой генерации наборов значений в заданных классах эквивалентности. В заключение данного критического анализа хотелось бы отметить, что хотя концептуально важно отделять друг от друга методы тестирования на основе «белого ящика» и на основе «черного ящика», и хотя тестирование на основе моделей, конечно, является одним из методов «черного ящика», но технически автоматическая генерация тестов на основе моделей во многом не отличается от методов генерации на основе исходных кодов (или другого представления реализации). Поэтому декларация U2TP об использовании в качестве базового подхода исключительно метода «черного ящика», будучи понятой буквально, является барьером на пути более полной автоматизации генерации тестов.
работы этого теста. Более детальное рассмотрение этой задачи вскрывает новые вопросы: что является источником критериев правильности, удается ли, и как именно, описать такие критерии в общем виде, как они трансформируются в оракул, как выносится общий вердикт теста, если в нем несколько оракулов, и т.п. Определение критериев полноты тестирования. Сбор информации о достигнутом покрытии. Использование информации о достигнутом покрытии для управления ходом генерации. Собственно генерация тестовых воздействий, которая распадается на следующие подзадачи. o Построение последовательности тестовых воздействий в целом. o
Выбор вызываемой операции в рамках одного воздействия, если интерфейс предоставляет несколько операций.
o
Генерация входных данных операции.
3. Специализация и унификация в UniTESK. Текущее состояние
3.1. Задачи построения тестов В работах по методам тестирования и по автоматизации тестирования затрагиваются многочисленные задачи, которые необходимо уметь решать при создании тестов. Примерный список этих задач представлен ниже. Определение требований к системе, выделение из них условий корректного воздействия на целевую систему и критериев правильности результатов3. Построение оракула — компонента теста, выносящего вердикт о выполнении или нарушении требований на основе результатов
3
Некоторые теоретики программной инженерии рассмотрение этого вопроса отнесли бы к дисциплине, которая называется управлением требованиями (requirements management), однако на практике, даже если в начале проекта требования сформулированы, тестировщики должны к ним отнестись критически и проанализировать, насколько имеющиеся формулировки требований пригодны как основа для разработки тестов. Часто проектирование тестов влечет переформулировку и пополнение требований. 15
16
Простейшая итерация данных из области определения операции, без анализа других моделей (требований, ошибок, структуры системы). Итерация простых структур данных. Итерация иерархических структур данных. Нацеливание итерации входных данных при использовании моделей требований, ошибок или структуры тестируемой системы. Статическое вычисление входных данных для достижения покрытия ситуаций в различных моделях, в том числе и в структуре системы.
o
Отбрасывание некорректных тестовых данных.
o
«Прореживание» тестовых данных, то есть обеспечение покрытия того же множества существенно различных в соответствии с используемыми критериями покрытия ситуаций при помощи меньшего количества отдельных воздействий.
Генерация отчетов о тестовом покрытии. o Отчеты на основе каталогов неформальных требований. o
Отчеты на основе структурных характеристик реализации (для различных метрик тестового покрытия).
o
Отчеты на основе формальных моделей, при этом рассматриваются модели реализации, модели требований, модели ошибок. Примерами возможных видов моделей
являются контрактные спецификации, исполнимые модели (конечные автоматы, LTS, сети Петри, MSC диаграммы и пр.), грамматики и производные от них структуры, например графы зависимости и деревья вывода, другие формализмы описания структурированных данных (SQL, XML scheme, Relax NG, ASN 1.0 и др.).
Связь теста с целевыми интерфейсами, в том числе конвертация данных, их транспорт, marshalling, перехват событий; эти задачи часто связываются с элементами тестовых систем, которые называют адаптерами, медиаторами, брокерами, proxy и др. Служебные задачи, например, сбор трассировочной информации для целей анализа обнаруженных ошибок или вычисления достигнутого покрытия, то есть для генерации отчетов различных видов; конфигурационное управление системой тестов и ассоциированной с ними информации (каталоги требований, об ошибках, запросы на их исправление, трассировка процесса устранения ошибок и т.п.). Попробуем рассмотреть материал данного сборника сквозь призму унификации систем автоматизации разработки тестов. Заметим, что статьи сборника представляют достаточно широкий спектр походов и техник. Так в работах Д. Силакова и В. Мутилина за основу взят метод «белого ящика», используется инструментация исходного кода, все остальные работы — классический пример использования подхода «черного ящика». В работах А. Демакова, С. Зеленова, С. Зеленовой, Р. Зыбина, В. Кулямина, А. Пономаренко, В. Рубанова и Е. Чернова тесты строятся, в основном, на основе изучения области входных данных. В. Рубанов, А. Хорошилов, Е. Шатохин представляют технологию традиционной ручной разработки тестов, в статьях А. Камкина и М. Чупилко описывается подход к тестированию модулей микропроцессоров. Часть работ использует прием тестирования на лету (testing-on-the-fly, генерацию тестовых данных и воздействий в ходе выполнения теста). Повышению эффективности локализации ошибок по результатам тестирования на лету посвящена статья С. Грошева. В статье А. Камкина рассматриваются методы статической генерации тестов (тестовых программ), в статье В. Кулямина — методы определения критериев тестового покрытия, в статьях И. Бурдонова и А. Косачева разрабатывается формальный подход к определению понятия конформности — соответствия поведения системы некоторой модели — и методы проверки этого соответствия. Возьмем, например, первые два пункта из списка задач, приведенного выше. Определение требований к системе. Построение оракула. В работах, описывающих разработку тестов на соответствие стандарту LSB, подробно рассматриваются выделение требований для тестов проверки базовой работоспособности (инструмент Azov) и для тестов традиционного 17
типа (инструмент T2C). Кроме того, в этих же работах упоминаются тесты более высокого качества для LSB Core, созданные в рамках проекта OLVER [21] при помощи инструмента CTESK. Все эти работы используют общую базу данных, в которой хранятся разнообразные данные об интерфейсах. Данные о сигнатурах интерфейсных функций используются всеми тремя инструментами — здесь унификация уже достаточно высокого уровня. Вместе с тем, в работе по модульному тестированию микропроцессоров, где используется тот же инструмент CTESK, возможности единообразного хранения требований к интерфейсам не использованы. Рассматривая те же работы в плане унификации механизма вынесения вердикта можно обнаружить, что три инструмента, использующиеся для разработки тестов для LSB строят оракул совершенно по-разному, то есть в этом аспекте унификации пока нет.
3.2. Вектор развития UniTESK Если рассмотреть все задачи, которые необходимо решить при автоматизации создания тестов, то для каждой из них в отдельности можно предложить некоторую систематизацию подходов к решению этих задач. Разработка такой системы — это первый шаг к унификации. Но, похоже, что этого шага пока не сделали разработчики U2TP — они предложили номенклатуру компонентов, из которых состоят тестовые системы, но не сделали попытки более подробного описания каждой сущности, попавшей в номенклатуру. После первого шага должен следовать второй. Он состоит в разработке шаблонов проектирования. Это нелегкая задача, но здесь она еще более усложняется из-за того, что эти шаблоны должны учесть варианты совместного и согласованного решения нескольких задач автоматизации тестирования. Примером таких взаимосвязанных задач является целенаправленная генерация тестовых данных для покрытия заданных операторов или заданного пути в коде и «прореживание» комбинаций входных данных, если их общее количество слишком велико. При этом стратегия генерации и стратегия «прореживания» часто должны динамически адаптироваться в ходе тестирования. Шаблоны согласованных решений должны появиться и для тех случаев, когда можно совместно использовать разные техники тестирования или верификации, например, элементы проверки моделей (model checking) и статического анализа с применением инструментов, автоматически находящих данные, удовлетворяющие сложным ограничениям (constraint solvers). Другое место, где потребуются специальные усилия для согласования разных подходов — использование нескольких разных моделей, служащих для описания требований, поведения, гипотез о возможных ошибках и т.п. На первый взгляд может показаться, что задача унификации, если ее решать достаточно основательно, становится неоправданно сложной. Но судить об этом нужно, соотнося трудоемкость ее решения и эффект, который может 18
быть получен. Результат, к которому должна привести унификация средств разработки инструментов автоматизации тестирования, с одной стороны, должен обеспечить совместимость компонентов тестов друг с другом, а, с другой стороны, выведет нас на возможность интеграции различных методов и инструментов верификации. Сколько шагов унификации уже пройдено технологией UniTESK? Прямого ответа на этот вопрос пока дать нельзя, но что-то уже сделано. Есть задел в плане введения единой номенклатуры артефактов, ролей и процессов тестирования. Наработан некоторый опыт унифицированных решений для разработки тестов совершенно разного плана (например, база данных интерфейсов для систем, тестирующихся при помощи инструментов Azov, T2C, CTESK). Начаты работы по интеграции JavaTESK и генератора сложных структур данных Pinery, ведется работа по интеграции Pinery и алгоритмов «прореживания» на основе покрывающих наборов [22]. То есть, сейчас есть некоторый опыт в унификации как в рамках программы первого шага, так и второго, однако полной картины унифицированной схемы разработки инструментов тестирования пока нет. Создание такой схемы — это и есть новый вектор развития технологии.
4. Заключение В статье рассматривались проблемы и перспективы унификации в области разработки систем автоматического построения тестов. Были перечислены положительные и отрицательные моменты, сопровождающие любую унификацию и унификацию разработке программных систем, в частности. Были выделены два ракурса унификации в автоматизации тестирования: позиция разработчика тестов и позиция разработчика инструментов создания тестов. Далее в статье был проанализирован опыт в унификации систем тестирования сконцентрированной вокруг работ по использованию MDA подхода, реализованного в U2TP — UML 2.0 Testing Profile. Была показана ограниченность постановки задачи, определенной авторами U2TP. На примере работ, представленных в сборнике, показано, какие решения в рамках разрабатываемых в ИСП РАН технологий уже в некоторой степени унифицированы, какие пока далеки от унификации. Отмечено, что унификация в автоматизации тестирования может проводиться на основе компонентного подхода. Это подразумевает, что должны выделяться модули, играющие те или иные роли, должны описываться интерфейсы этих модулей, типовые шаблоны проектирования (patterns), которые на основе стандартизованного набора модулей позволят строить инструменты, с учетом как специфики тестируемой системы, так и методов спецификации и тестирования, выбранных в данном инструменте. Заключая статью, хотелось бы, во-первых, отметить, что задача унификации в автоматизации тестирования расценивается как в высшей степени актуальная, во-вторых, что опыт европейских исследователей и специалистов показывает 19
на трудности, которые встают при попытках проведения унификации методом «сверху-вниз». Вероятно, коренная причина здесь в идеологии подхода MDA — реализацию можно построить на основе модели, если адекватная модель, или хотя бы схема моделирования уже есть. Такое бывает лишь в областях, где накоплен большой опыт разработки типовых решений. Поскольку область автоматической генерации тестов бурно развивается и проблем в ней еще больше, чем решений, здесь пока таких моделей нет, и не понятно, когда они появятся. Констатация этого факта не означает, что унификация невозможна. Она возможна, но подходить к решению этого вопроса надо с двух сторон: от общего к частному, как в MDA, и от частного к общему, как это всегда происходит в программировании, если разработчик постоянно думает об обобщении своего опыта, о выделении тех модулей и тех операций, которые повторяются многократно в разных проектах, при решении разных задач. Замечу, что объектами такого переиспользования могут быть не только программные модели (что каждый раз является настоящей удачей), такими объектами могут быть шаблоны проектирования, протоколы взаимодействия отдельных компонентов и другие артефакты и процессы, которые составляют как сами системы автоматизации тестирования, так и процессы их разработки и эксплуатации.
5. Благодарности Автор выражает признательность А. В. Бойченко за предоставление большого набора материалов по стандартизации профилей процессов тестирования и В. В. Кулямину за многочисленные обсуждения проблем унификации в тестировании. Литература [1] I. Burdonov, A. Kossatchev, A. Petrenko, D. Galter. KVEST: Automated Generation of Test Suites from Formal Specifications. Proceedings of Formal Method Congress, Toulouse, France, 1999, LNCS 1708:608–621, Springer-Verlag, 1999. [2] http://www.nortel.com. [3] The RAISE Language Group. The RAISE Specification Language. Prentice Hall Europe, 1992. [4] http://slovari.yandex.ru/dict/bse. [5] http://adl.opengroup.org/exgr/icse/icse98.htm. [6] http://www.omg.org/technology/documents/formal/test_profile.htm. [7] http://www.fokus.fraunhofer.de/u2tp/index.html. [8] http://www.omg.org. [9] http://www.itea2.org. [10] http://www.eureka.be. [11] http://www.east-eea.net. [12] http://www.tt-medal.org/. [13] http://www.testingtech.de/products. [14] http://www.systematic-testing.com/functional_testing/cte_main.php?cte=1. [15] http://www.conformiq.com. [16] http://www.hidenets.aau.dk/.
20
[17] http://www.omg.org/technology/documents/formal/ras.htm. [18] http://www.atesst.org. [19] http://www.atesst.org/scripts/home/publigen/content/templates/show.asp?P=114&L=EN &ITEMID=5. [20] http://www.autosar.org. [21] http://linuxtesting.org/. [22] C. J. Colbourn. Combinatorial aspects of covering arrays. Le Matematiche (Catania) 58:121–167, 2004.
21
Системы с приоритетами: конформность, тестирование, композиция И. Б. Бурдонов, А. С. Косачев {igor, kos}@ispras.ru Аннотация. В статье представлен подход к моделированию компонентов распределенных систем, взаимодействие которых построено на обработке событий с учетом их приоритетов. Несмотря на широкое использование на практике приоритетной обработки запросов или сообщений, математические модели взаимодействия таких программ чаще всего абстрагируются от приоритетов, вводя излишний недетерминизм в описание их поведения. Предложенный подход пытается избежать этого недостатка за счет определения параллельной композиции, моделирующей взаимодействие такого рода. Основное содержание статьи — построение теории формального тестирования компонентов, использующих приоритеты. В рамках этой теории вводятся понятие безопасного выполнения модели и отношение конформности между моделями, а также рассматриваются вопросы построения наборов тестов, проверяющих конформность.
«Если воняет, то это химия, когда ничего не работает — физика, а если понять нельзя ни слова — математика». Из «Законов Мэрфи», цитируется по публичной лекции В.И. Арнольда «Сложность конечных последовательностей нулей и единиц и геометрия конечных функциональных пространств».
1. Введение В существующих теориях тестирования конформности (conformance testing) подразумевается отсутствие приоритетов между действиями, которые тестируемая система может выполнять в данной ситуации [23]. Это называется правилом недетерминированного выбора действий. В то же время для реальных программных и аппаратных систем это правило не всегда адекватно отражает требуемое поведение системы. Рассмотрим несколько примеров.
23
Выход из дивергенции. Под дивергенцией понимается бесконечная внутренняя активность («зацикливание») системы. Запрос, поступающий извне, может бесконечно долго игнорироваться системой, если он имеет тот же приоритет, что и внутренняя активность. Заметим, что внутренняя активность может быть инициирована предыдущим запросом. Если речь идёт о составной системе, собранной из нескольких компонентов, то такая внутренняя активность может быть естественным результатом взаимодействия компонентов между собой. И в этом случае для обработки запроса, поступающего в систему (в один из её компонентов) извне, он должен иметь больший приоритет, чем внутреннее взаимодействие. Выход из осцилляции (приоритет приёма над выдачей). Под осцилляцией понимается бесконечная цепочка выдачи сообщений системой. Для того, чтобы такую цепочку можно было прервать, заставив систему обрабатывать поступающий извне запрос, последний должен иметь больший приоритет, чем выдача сообщений. Приоритет выдачи над приёмом в неограниченных очередях. Этот обратный пример характерен для неограниченной очереди, используемой в качестве буфера между взаимодействующими системами, в частности, при асинхронном тестировании (тестировании в контексте). Здесь нужно, чтобы выборка из очереди была приоритетней постановки в очередь. В противном случае очередь имеет право только принимать сообщения и никогда их не выдавать. При асинхронном тестировании для входной очереди это означает, что все входные сообщения, посылаемые тестом, не доходят до реализации, бесконечно накапливаясь в очереди. Соответственно, для выходной очереди это означает, что тест может не получать никаких ответных сообщений от реализации, хотя она их выдаёт, поскольку они «оседают» в очереди. Прерывание цепочки действий. Команда «отменить» (cancel) должна останавливать выполнение последовательности действий, инициированной предыдущим запросом, и вызывать цепочку завершающих действий. При отсутствии приоритетов такая команда, даже если она выдана сразу после выдачи запроса, имеет право быть выполнена только после того, как вся обработка закончится, то есть, фактически, ничего не «отменяет». Приоритетная обработка входных воздействий. Если в систему поступает одновременно несколько запросов, то часто требуется их обработка в соответствии с некоторыми приоритетами между ними. Это обычно реализуется в виде очереди запросов с приоритетами или в виде нескольких очередей запросов с приоритетами между очередями. К этому типу приоритетов относится и обработка аппаратных прерываний в операционной системе. Отсутствие приоритетов в моделях систем не даёт возможности проверять при тестировании выполнение тех требований к системе, которые могут быть выражены только в форме приоритетов. В данной статье предлагается способ введения приоритетов в теорию конформности: семантику взаимодействия и модель системы, отношение конформности, методы генерации тестов и 24
оператор композиции (сборки составной системы из взаимодействующих между собой компонентов). Теория конформности без приоритетов кратко описана в нашей статье [13], подробное изложение с доказательствами утверждений содержится в диссертации одного из авторов данной статьи [16], теория конформности для класса так называемых -семантик излагается в книге [15]. Здесь мы сначала повторим основные положения этой теории, а затем модифицируем их для случая приоритетов.
2. Теория конформности без приоритетов 2.1. Семантика взаимодействия и безопасное тестирование Верификация конформности понимается как проверка соответствия исследуемой системы заданным требованиям. В модельном мире система отображается в реализационную модель (реализацию), требования — в спецификационную модель (спецификацию), а их соответствие — в бинарное отношение конформности. Если требования выражены в терминах взаимодействия системы с окружающим миром, возможно тестирование как проверка конформности в процессе тестовых экспериментов, когда тест подменяет собой окружение системы. Само отношение конформности и его тестирование основаны на той или иной модели взаимодействия.
Рис. 1. Машина тестирования. Мы будем рассматривать такие семантики взаимодействия, которые основаны только на внешнем, наблюдаемом поведении системы и не учитывают её внутреннее устройство, представленное на уровне модели в виде состояний. В этом случае говорят о тестировании методом «чёрного ящика» или функциональном тестировании. Мы можем наблюдать только такое поведение реализации, которое, во-первых, «спровоцировано» тестом (управление) и, вовторых, наблюдаемо во внешнем взаимодействии. Такое взаимодействие может моделироваться с помощью, так называемой, машины тестирования [13,15,16,22,23,33]. Она представляет собой «чёрный ящик», внутри которого находится реализация (Рис. 1). Управление сводится к тому, что оператор машины, выполняя тест (понимаемый как инструкция для оператора), нажимает какие-то кнопки на клавиатуре машины, «приказывая» или «разрешая» реализации выполнять те или иные действия, которые могут им наблюдаться. Наблюдения (на «дисплее» машины) бывают двух типов: наблюдение некоторого действия, разрешённого оператором и выполняемого 25
реализацией, и наблюдение отказа как отсутствия каких бы то ни было действий из числа тех, что разрешены нажатыми кнопками. Следует подчеркнуть, что при управлении оператор разрешает реализации выполнять именно множество действий, а не обязательно одно действие. Например, при тестировании реактивных систем, основанных на обмене стимулами и реакциями, посылка одного стимула из теста в реализацию может интерпретироваться как разрешение реализации выполнять только одно действие — приём этого стимула. Однако приём тестом ответной реакции должен означать разрешение реализации выдавать любую реакцию как раз для того, чтобы проверить, правильна эта реакция или нет. Мы будем считать, что оператор нажимает одну кнопку, но на кнопке «написано», вообще говоря, не одно действие, а множество разрешаемых действий. Когда происходит наблюдение (действие или отказ) кнопка автоматически отжимается, и все внешние действия считаются запрещёнными. Далее оператор может нажимать другую (или ту же самую) кнопку. В то же время «кнопочное» множество — это, вообще говоря, не любое подмножество множества всех действий. В вопросе о том, какие множества действий могут разрешаться тестом, а какие нет, среди исследователей существует большое разнообразие точек зрения. Например, для реактивных систем обычно считается, что нельзя (или бессмысленно) смешивать посылку стимулов с приёмом реакций (Ян Тритманс). Но существует и прямо противоположный подход: нельзя «тормозить» выдачу реакций реализацией, поэтому, даже посылая стимул, тест должен быть готов к приёму любой реакции (А. Ф. Петренко в [36]). Также следует подчеркнуть, что наблюдение отказа возможно не при любой кнопке. И здесь разные исследователи опираются на разные предположения. Для тех же реактивных систем долгое время считалось, что тест может наблюдать отсутствие реакций (quiescence, стационарность), например, по тайм-ауту, но не видит, принимает реализация посланный ей стимул или нет (input refusal, блокировка стимула). С другой стороны, в последние годы появляется всё больше и больше работ, в которых такие блокировки стимулов допускаются или допускаются частично [10-15,26,27,31]. Также и реакции, если они принимаются тестом по разным «выходным каналам», можно принимать не все, а лишь те, которые относятся к одному или нескольким выбранным каналам [26,27]. Итак, семантика взаимодействия определяется тем, какие (в принципе) существуют наблюдаемые действия — алфавит внешних действий L, какие множества действий может разрешать тест — набор кнопок машины тестирования, и для каких из этих кнопок наблюдаемы соответствующие отказы — семейство (L), а для каких нет — семейство (L). Предполагается, что = и =L. Такую семантику мы называем /-семантикой. 26
Кроме внешних, наблюдаемых действий реализация может совершать внутренние, ненаблюдаемые (и, следовательно, неразличимые оператором) действия, которые обозначаются символом . Выполнение таких действий не регулируется оператором — они всегда разрешены. Предполагается, что любая конечная последовательность любых действий совершается за конечное время, а бесконечная последовательность — за бесконечное время. Бесконечная последовательность -действий («зацикливание») называется дивергенцией и обозначается символом . Кроме этого мы вводим специальное, не регулируемое кнопками, действие, которое называем разрушением и обозначаем символом . Оно моделирует любое запрещённое или недекларированное поведение реализации. Например, в терминах пред- и постусловий, поведение программы определено (постусловием) только в том случае, когда выполнено предусловие обращения к ней. Если же предусловие нарушено, поведение программы считается полностью неопределённым. Семантика разрушения предполагает, в частности, что в результате такого поведения система может быть разрушена. При тестировании мы должны избегать возникновения ненаблюдаемых отказов (-отказов), попыток выхода из дивергенции и разрушения. Такое тестирование называется безопасным. Опасность разрушения подразумевается его семантикой. Поясним остальные случаи. В целом их опасность означает, что после нажатия кнопки оператор может не получить никакого наблюдения, и, не зная об этом, не может ни продолжать тестирование, ни закончить его. Если после нажатия кнопки P возникает -отказ P, оператор не знает, нужно ли ему продолжать ждать наблюдения внешнего действия, разрешённого нажатой кнопкой, или это бессмысленно, поскольку машина стоит. Однако, узнать об остановке машины оператор не может, поскольку это как раз означало бы наблюдение отказа P. Само по себе возникновение дивергенции не опасно, однако, нажимая после этого любую кнопку, оператор, не наблюдая внешнего действия или -отказа (если нажимается кнопка), не знает, случится ли такое наблюдение в будущем, или реализация так и будет бесконечно долго выполнять свои внутренние действия. Можно также отметить, что из-за внутренних действий нажатие пустой кнопки (кнопки с пустым множеством разрешаемых действий) не эквивалентно отсутствию нажатой кнопки. В обоих случаях все внешние действия запрещены, однако наблюдение отказа означает, что оператор узнаёт об остановке машины, когда она не может выполнять также и внутренние действия. Пустая -кнопка не может вызвать разрушение после действия (никакого действия быть не может), но она опасна, если есть дивергенция, как и любая другая кнопка. Пустую -кнопку вообще никогда нельзя нажимать, поскольку никакого наблюдения быть не может: все внешние действия запрещены, а отказ не наблюдаем. Поэтому можно считать, что .
27
2.2. LTS-модель и трассовая модель В качестве модели реализации и спецификации мы используем систему помеченных переходов (Labelled Transition System, LTS). LTS — это ориентированный граф с выделенной начальной вершиной, дуги которого помечены некоторыми символами. Формально, LTS — это совокупность S=LTS(VS,L,ES,s0), где VS — непустое множество состояний (вершин графа), L — алфавит внешних действий, — символ внутреннего действия, — символ разрешения, ESVS(L{,})VS — множество переходов (помеченных дуг графа), s0VS — начальное состояние (начальная вершина графа). Переход из состояния s в состояние s` по действию z обозначается szs`. Обозначим sz =def s` szs`. Выполнение LTS, помещённой в «чёрный ящик» машины тестирования, сводится к выполнению того или иного перехода, определённого в текущем состоянии и разрешаемого нажатой кнопкой (- и переходы разрешены при нажатии любой кнопки и при отсутствии нажатой кнопки). Состояние называется стабильным, если в нём нет - и -переходов, и дивергентным, если в нём начинается бесконечная цепочка -переходов (в частности, -цикл, в том числе, -петля). Отказ P порождается стабильным состоянием, в котором нет переходов по действиям из P. Для получения трасс LTS достаточно добавить в каждом стабильном состоянии виртуальные петли, помеченные порождаемыми состоянием отказами, а также добавить -переходы во всех дивергентных состояниях. После этого рассматриваются все конечные маршруты LTS, начинающиеся в начальном состоянии и не продолжающиеся после - или -перехода. Трассой маршрута считается последовательность пометок его переходов с пропуском -переходов. Такие трассы мы называем полными или F-трассами, а множество F-трасс LTS S — полной трассовой моделью или F-моделью, и обозначать F(S). F-трасса, все отказы которой принадлежат семейству , называется -трассой. Это те трассы, которые могут наблюдаться на машине тестирования в /-семантике. Множество всех -трасс LTS, то есть проекция её F-модели на алфавит, состоящий из всех внешних действий, -отказов, символов и , называется -моделью, соответствующей «взгляду» на реализацию в /-семантике.
2.3. Гипотеза о безопасности и безопасная конформность Безопасное тестирование, прежде всего, предполагает формальное определение на уровне модели отношения безопасности «кнопка безопасна в модели после -трассы». При безопасном тестировании будут нажиматься только безопасные кнопки. Это отношение различно для реализационной и спецификационной моделей. В LTS-реализации I отношение безопасности означает, что нажатие кнопки P после -трассы не может означать 28
попытку выхода из дивергенции (после трассы нет дивергенции), не может вызывать разрушение (после действия, разрешаемого кнопкой), и не может привести к ненаблюдаемому отказу (если это -кнопка): P safein I after =def uP u,F(I) & F(I). P safe in I after =def P safein I after & (P PF(I)). В LTS-спецификации S отношение безопасности отличается только для кнопок: мы не требуем, чтобы трасса не продолжалась безопасным отказом Q, но требуем, чтобы она продолжалась хотя бы одним действием zQ. Кроме того, если действие разрешается хотя бы одной неразрушающей -кнопкой, то оно должно разрешаться какой-нибудь безопасной кнопкой. Если это неразрушающая -кнопка, то она же и безопасна. Но если все неразрушающие кнопки, разрешающие действие, являются -кнопками, то хотя бы одна из них должна быть объявлена безопасной. Такое отношение безопасности всегда существует: достаточно объявить безопасной каждую неразрушающую кнопку, разрешающую действие, продолжающее трассу. Однако, в целом указанные требования неоднозначно определяют отношение safe by, и при задании спецификации указывается конкретное отношение. Требования к отношению safe by записываются так: R zL Q 1) R safe by S after R safein S after , 2) T T safein S after & zT & zF(S) P zP & P safe by S after , 3) Q safe by S after Q safein S after & vQ vF(S). Безопасность кнопок определяет безопасность действий и -отказов после трассы. -отказ R безопасен, если после трассы безопасна кнопка R. Действие безопасно, если оно разрешается некоторой кнопкой, безопасной после трассы. Теперь мы можем определить безопасные трассы. -трасса безопасна, если 1) модель не разрушается с самого начала (сразу после включения машины ещё до нажатия первой кнопки), то есть в ней нет трассы , 2) каждый символ трассы безопасен после непосредственно предшествующего ему префикса трассы. Множества безопасных трасс реализации I и спецификации S обозначим SafeIn(I) и SafeBy(S), соответственно. Требование безопасности тестирования выделяет класс безопасных реализаций, то есть таких, которые могут быть безопасно протестированы для проверки их конформности или неконформности заданной спецификации. Этот класс определяется следующей гипотезой о безопасности: реализация I безопасна для спецификации S, если 1) в реализации нет разрушения с самого начала, если этого нет в спецификации, 2) после общей безопасной трассы реализации и спецификации любая кнопка, безопасная в спецификации, безопасна после этой трассы в реализации: 29
I safe for S =def (F(S) F(I)) & SafeBy(S)SafeIn(I) P (P safe by S after P safe in I after ). Следует отметить, что гипотеза о безопасности не проверяема при тестировании и является его предусловием. После этого можно определить отношение (безопасной) конформности: реализация I безопасно конформна (или просто конформна) спецификации S, если она безопасна и выполнено тестируемое условие: любое наблюдение, возможное в реализации в ответ на нажатие безопасной (в спецификации) кнопки, разрешается спецификацией: I safe for S I saco S =def & SafeBy(S)SafeIn(I) P safe by S after obs(,P,I)obs(,P,S), — где obs(,P,T) =def {u|uF(T) & (uP u=P & P)} множество наблюдений, которые можно получить над моделью T при нажатии кнопки P после трассы .
2.4. Параллельная композиция и генерация тестов Взаимодействие двух систем моделируется в LTS-теории оператором параллельной композиции. Мы используем оператор композиции, аналогичный тому, который определяется в алгебре процессов CCS (Calculus of Communicating Systems) [32,34]. Будем считать, что для каждого внешнего действия z определено противоположное действие z так, что z=z. Например, посылке стимула из теста соответствует приём теста в реализации, а выдаче реакции реализацией соответствует приём этой реакции в тесте. Параллельное выполнение двух LTS в алфавитах A и B понимается так, что переходы по противоположным действиям z и z, где zA и zB, выполняются синхронно, то есть, в обеих LTS одновременно, причём в композиции это становится -переходом. Такие действия называются синхронными. Остальные внешние действия zA\B и zB\A, а также символы и называются асинхронными. Переход по такому символу выполняются в одной из LTS при сохранении состояния другой LTS. Результатом композиции двух LTS I и T становится LTS IT в алфавите AB =def (A\B)(B\A). Её состояния — это пары состояний it LTS-операндов, начальное состояние — это пара начальных состояний, а переходы порождаются следующими правилами вывода: (1) z{,}A\B & izi` itzi`t, (2) z{,}B\A & tzt` itzit`, iti`t`. (3) zAB & izi` & tzt` Тестирование понимается как замкнутая композиция LTS-реализации I в алфавите A и LTS-теста T в противоположном алфавите B=A. Для 30
обнаружения отказов в тесте (но не в реализации!) допускаются специальные -переходы, которые срабатывают тогда и только тогда, когда никакие другие переходы не могут выполняться: (4) tt` & Deadlock(i,t) itit`, где Deadlock(i,t) = i & i & t & t & (zAB iz tz). Мы будем предполагать, что в тесте также нет разрушения (требование t всегда выполнено). Поскольку алфавиты реализации и теста противоположны, композиционный алфавит пуст и в композиционной LTS есть только - и -переходы. При безопасном тестировании -переходы недостижимы. Выполнению теста соответствует прохождение -маршрута, начинающегося в начальном состоянии композиции IT. Тест заканчивается, когда достигается терминальное состояние теста. Каждому такому терминальному состоянию назначается вердикт pass или fail. Реализация проходит тест, если состояния теста с вердиктом fail недостижимы. Реализация проходит набор тестов, если она проходит каждый тест из набора. Набор тестов значимый, если каждая конформная реализация его проходит; исчерпывающий, если каждая неконформная реализация его не проходит; полный, если он значимый и исчерпывающий. Задача заключается в генерации полного набора тестов по спецификации. Обычно ограничиваются, так называемыми, управляемыми тестами, то есть тестами без лишнего недетерминизма. Для этого множество внешних действий, для которых определены переходы в данном состоянии теста, должно быть одним из «кнопочных» множеств /-семантики (точнее, множеством противоположных действий, поскольку при композиции CCS тест определяется в противоположном алфавите). Оператор, исполняя тест, однозначно определяет, какую кнопку ему нужно нажимать в данном состоянии теста. Если это -кнопка, то в состоянии должен быть также определён -переход. Полным набором всегда является набор всех примитивных тестов. Примитивный тест строится по одной выделенной безопасной -трассе спецификации. Для этого сначала в трассу перед каждым -отказом R вставляется кнопка R, а перед каждым действием z — какая-нибудь безопасная (после префикса трассы) кнопка P, разрешающая действие z. Для различения кнопок и отказов (и то и другое — подмножества внешних действий) мы будем кнопки заключать в кавычки и писать “P”, а не просто P. Безопасность трассы гарантирует безопасность кнопки R и наличие такой безопасной кнопки P. Выбор кнопки P может быть неоднозначным, то есть по одной безопасной трассе спецификации можно сгенерировать, вообще говоря, множество разных примитивных тестов. После расстановки кнопок 31
получается последовательность, которая во втором разделе статьи называется /-историей. По ней и строится LTS-тест (Рис. 2). Его состояниями становятся расставленные кнопки, начальное состояние — это первая в трассе кнопка, символы переходов из состояния-кнопки — это действия, противоположные тем, которые могут наблюдаться после нажатия этой кнопки, или символ , если это -кнопка. Если это не последняя кнопка, то один переход ведёт в состояние, соответствующее следующей кнопке. Остальные переходы ведут в терминальные состояния. Вердикт pass назначается тогда, когда соответствующая -трасса есть в спецификации, а вердикт fail — когда нет. Такой вердикт соответствует строгим тестам, которые, вопервых, значимые (не ловят ложных ошибок) и, во-вторых, не пропускают обнаруженных ошибок. Любой строгий тест можно заменить на объединение примитивных тестов, которое обнаруживает те же самые ошибки. =A,b,cвставляем ,безопасные кнопки “A”,A,“B”,b,“C”,c такие, что: A,B, C, bB, cC. Внешнее действие имеет индекс «хорошо», если оно есть в спецификации после префикса трассы; иначе — индекс «плохо». Пунктиром показаны взаимоисключающие переходы, ведущие из одного состояния. Индексы «хорошо» и «плохо» означают наличие или отсутствие продолжения префикса трассы соответствующим -отказом. Рис. 2. Примитивный тест для безопасной R-трассы . Теперь рассмотрим две проблемы, связанные с применением теории тестирования конформности на практике.
2.5. Недетерминизм и глобальное тестирование Как уже было сказано, в каждый момент времени реализация может выполнять любое определённое в ней и разрешённое оператором внешнее действие, а также определённые и всегда разрешённые внутренние действия (мы избегаем разрушения при безопасном тестировании). Если таких действий несколько, выбирается одно из них недетерминированным образом. Здесь предполагается, что недетерминизм поведения реализации — это явление того 32
уровня абстракции, которое определяется нашими тестовыми возможностями по наблюдению и управлению, то есть семантикой взаимодействия. Иными словами, поведение реализации недетерминировано, поскольку оно зависит от неких не учитываемых нами факторов — «погодных условий», которые определяют выбор выполняемого действия детерминировано. Для того, чтобы тестирование могло быть полным, мы должны предположить, что любые погодные условия могут быть воспроизведены в тестовом эксперименте, причём для каждого теста. Если такая возможность есть, тестирование называется глобальным [33]. Мы абстрагируемся от количества вариантов погодных условий. Здесь нам важна только потенциальная возможность проверить поведение системы при любых погодных условиях и любом поведении оператора. Конечно, на практике используется только конечное число прогонов каждого теста. Без дополнительных условий мы не можем быть уверены, что провели тестовые испытания каждого теста для всех возможных погодных условий. Возможны различные решения этой проблемы. Одно из них — специальные тестовые возможности по управлению погодой. Для этого мы должны выйти за рамки модели, которая как раз и абстрагировалась от второстепенных деталей внешних факторов, то есть от погоды. Тем самым, тестирование становится зависящим не только от спецификации, но и от реализационных деталей, от того, что можно назвать операционной обстановкой, в которой работает реализация. Для каждого варианта такой операционной обстановки мы будем вынуждены создавать свой набор тестов. Тем не менее, в некоторых частных случаях на этом пути можно получить практические выгоды. Другое решение — специальные реализационные гипотезы. Для конечного числа прогонов теста предполагают, что, если реализация ведёт себя правильно при некоторых погодных условиях, то она будет вести себя правильно при любых погодных условиях [6]. Третье решение основано на том, что нам известно распределение вероятностей тех или иных погодных условий. В этом случае тестирование оказывается полным с той или иной вероятностью [19]. Близкое к этому четвёртое решение предполагает, что в каждой ситуации (после трассы) возможно лишь конечное число погодных условий (с точностью до эквивалентности) и существует такое число N, что после N прогонов теста гарантированно будет проверено поведение реализации при всех возможных в этой ситуации погодных условиях [21,32]. Наконец, существует и более радикальное решение — просто запретить недетерминизм реализации, то есть реализационная гипотеза ограничивает класс реализаций только детерминированными реализациями. При всей своей наивности, это достаточно распространённый практический приём [35] (он применялся и в ИСП РАН в рамках системы UniTESK). Обоснованием может 33
служить то, что во многих случаях заранее известно, что интересующие нас реализации детерминированы.
2.6. Бесконечность полного набора тестов На практике используются только конечные наборы конечных (по времени выполнения) тестов. Поскольку тесты конечные, полный набор, как правило, содержит бесконечное число тестов (полный набор конечен только для моделей с конечным поведением, то есть конечным числом трасс; в частности, в LTS-спецификации не должно быть циклов). Возможны различные решения этой проблемы. В конечном счёте все они сводятся к специальным реализационным гипотезам. Такие гипотезы, по сути, предполагают ровно то, что хотелось бы «доказать»: если реализация ведёт себя правильно на тестах данного конечного набора, то она будет вести себя правильно на всех тестах полного набора. Обоснованием может служить некоторое (не важно как полученное) «знание» о том, как могут быть устроены тестируемые реализации (тестируем не все возможные реализации, а только такие). На классе всех реализаций такие конечные наборы тестов будут только значимыми (не ловят ложных ошибок), а полными — только на подклассе, определяемом реализационной гипотезой. Конечный набор тестов строится по тому или иному критерию покрытия, чтобы проверить все интересующие нас классы ситуаций (ошибок) [24,25,37]. Теоретически конечный набор можно получить фильтрацией по критерию покрытия перечислимого полного набора. Поэтому теория конформности должна быть развита до уровня алгоритмов перечисления полного набора. Однако на практике обычно используются более прямые методы построения нужного конечного набора. Достаточно общий подход сводится к тому, что вместо исходной спецификационной модели используется более грубая, так называемая, тестовая модель. Тестовая модель — это результат факторизации исходной LTS-спецификации по отношению эквивалентности переходов, что обычно сводится к эквивалентности состояний и/или действий [1]. Иногда при факторизации исчезает недетерминизм, что заодно решает и эту проблему. Разумеется, чтобы такой подход был оправданным, нужны мотивированные реализационные гипотезы о том, что ошибки, возможные в реализации, обнаруживаются при тестировании по факторизованной спецификации (вообще по конечному набору, удовлетворяющему критерию покрытия). Примером практического тестирования может служить тестирование конечного автомата по спецификации, заданной также в виде конечного автомата [3,4,6,18,28,29]. Если у нас есть специальная операция, позволяющая достоверно и напрямую опросить текущее состояние реализации (status message), то, как известно, полное тестирование сводится к обходу графа переходов автомата и применению операции опроса в каждом проходимом состоянии [3,6-9,20,29]. Обход графа переходов используется также в случае тестирования методом «чёрного ящика», когда состояния реализации не 34
видны. Но здесь для полноты тестирования требуются реализационные гипотезы, компенсирующие отсутствие тестовой возможности достоверного опроса состояний [3,4,6]. Предполагается, что число состояний реализации не превосходит число состояний спецификации (с точностью до эквивалентности состояний) или превосходит не более, чем на заранее известную величину [17,18,29,30]. Этот подход переносится и на общий случай LTS для реактивных систем [5]. В частности, когда используется, так называемое, стационарное тестирование, при котором стимулы подаются в реализацию только в её стационарных состояниях (в этом случае также снимается проблема торможения реакций) [2].
3. Теория конформности с приоритетами 3.1. Предикаты на переходах LTS-модели Независимо от наличия или отсутствия приоритетов семантика взаимодействия предполагает, что выполняться может только то действие, которое определено в реализации и разрешено оператором машины тестирования. Если приоритетов нет, то выполняться может любое определённое и разрешённое действие, и выбор выполняемого действия не детерминирован. Наличие приоритетов означает, что не все определённые и разрешённые действия могут выполняться, то есть выполнимость действия зависит также от того, какие ещё действия определены и/или разрешены. Эту зависимость можно изобразить в виде предиката от множества разрешённых действий, который назначается переходу LTS-модели. Поскольку для перехода szs` известно его пресостояние s, а для этого состояния s известно, какие ещё переходы в нём начинаются, предикат на переходе можно считать не зависящим от множества определённых (в состоянии s) действий. Иными словами, переходы по одному и тому же действию, ведущие из разных состояний, могут иметь разные предикаты. LTS-модель с приоритетами — это LTS, алфавит которой — декартовое произведение алфавита внешних действий и множества предикатов на алфавите внешних действий ={:(L)Bool}: S=LTS(VS,L,ES,s0). Переход sz,s` может выполняться только тогда, когда оператор разрешает такое множество внешних действий RL, что zR{,} и (R)=true. Если есть несколько выполнимых действий, выполняется одно из них, выбираемое, по-прежнему, недетерминированным образом. Предикат можно понимать как булевскую функцию от булевских переменных z1,z2,…, взаимно-однозначно соответствующих внешним действиям из алфавита L. Например, для предиката =a&bc переход sz,s` может выполняться только тогда, когда оператор разрешил такое множество внешних действий R, что zR{,} & (aR&bRcR). Это означает, 35
что действие z — это внутреннее действие, разрушение или внешнее действие, разрешённое оператором, а также выполнено хотя бы одно из двух условий: 1) оператор разрешил действие a и не разрешил действие b, 2) оператор разрешил действие c. Итак, в общем случае предикат — это булевская функция от множества разрешённых действий. Можно отметить важный частный случай, когда предикат зависит только от разрешённых и определённых внешних действий. Иными словами, предикат на переходе sz,s` не зависит от тех булевских переменных, которые соответствуют внешним действиям, по которым нет переходов из состояния s. Это означает, что выполнимость перехода зависит только от того, разрешено ли действие z, и какие ещё действия определены в состоянии s и разрешены оператором. В этом случае реализацию не интересуют (она «не видит») те действия, которые оператор разрешает, но они всё равно не могут выполняться, поскольку не определены в текущем состоянии реализации. Нажимая кнопку, оператор как бы «подсвечивает» некоторые действия реализации, определённые в её текущем состоянии, и выполнимость перехода по каждому из них определяется соответствующим предикатом от множества «подсвеченных» действий. Предикат как булевская функция от булевских переменных-действий может быть представлен в виде совершенной дизъюнктивной нормальной формы (СДНФ) =12…, где i=xi1&xi2&…, xij=zj или xij=zj, и zj пробегает множество всех внешних действий. Тогда переход sz,s` можно заменить на множество кратных переходов с предикатамидизъюнктами sz,is`. В свою очередь дизъюнкту i взаимнооднозначно соответствует множество Pi тех действий, для которых xij=zj. При композиции это множество является множеством действий, разрешаемых партнёром. В случае, когда таким партнёром является тест для заданной /семантики, эти множества разрешаемых действий соответствуют кнопкам из . Тем самым, при тестировании мы можем считать, что на переходах написаны не произвольные предикаты, а кнопки sz,Pis`. Когда нажимается некоторая кнопка Pi, выполняться могут только переходы вида sz,Pis`, где zPi{,}. Такой переход от LTS с предикатами к LTS с кнопками аналогичен переходу от расширенных автоматов (EFSM — Extended Finite State Machine) к обычным автоматам (FSM).
3.2. Остановка и дивергенция Машина без приоритетов останавливается в стабильном состоянии (состоянии без - и -переходов), в котором нет переходов по разрешённым внешним действиям. Если есть приоритеты, то меняется, прежде всего, само понятие стабильности. Оно становится условным: состояние стабильно, если для всех переходов из этого состояния их предикаты от пустого множества разрешённых внешних действий ложны ()=false. Соответственно 36
меняется условие остановки машины: машина стоит, если при разрешённом множестве внешних действий P для всех переходов из этого состояния их предикаты ложны (P)=false. Здесь мы должны уточнить, что происходит, когда кнопка отжимается. Для машины без приоритетов кнопка автоматически отжимается при любом наблюдении действия или отказа. После действия машина может выполнять любые -переходы (а также -переход), но после отказа машина стоит, поскольку отказ происходит в стабильном состоянии, в котором нет - и переходов. Однако для машины с приоритетами отжатие кнопки меняет множество разрешённых действий (если только не была нажатой пустая кнопка, дающее единственное наблюдение пустого отказа). После наблюдения реализация начинает выполнять -переходы с приоритетом ()=true. Заметим, что таким наблюдением может быть не только действие, но и отказ. Причина этого в том, что отказ P означал невозможность выполнения разрешённых внешних действий zP, а также - и -переходов, поскольку их предикаты стали ложны (P)=false. После отжатия кнопки P множество разрешённых внешних действий пусто и теперь могут выполняться - и переходы с предикатами ()=true. Далее оператор может снова нажать ту же кнопку (но без гарантии повторного наблюдения того же отказа, если реализация сменила состояние по -переходам) или другую кнопку. Если допускается переключение кнопок, то есть нажатие второй кнопки, не дожидаясь наблюдения по первой кнопке, то это интерпретируется как отжатие первой кнопки, а потом нажатие второй кнопки. Мы будем считать, что «в промежутке» между двумя кнопками создаётся ситуация, когда ни одна кнопка не нажата, и реализация может выполнять - и -переходы с предикатами ()=true. Общая парадигма здесь заключается в том, что ситуация отсутствия тестового воздействия возникает всегда при включении машины (до нажатия первой кнопки), после любого наблюдения и между двумя тестовыми воздействиями. Более подробно переключение кнопок рассматривается в следующем подразделе. Мы уже говорили, что даже для машины без приоритетов проблема дивергенции не в ней самой по себе, а в выходе из неё. При наличии приоритетов, если внешнее воздействие имеет больший приоритет, чем внутренняя активность, дивергенция прекращается. Теперь выполнимость действий зависит от нажатой кнопки, и мы можем косвенно управлять ими и, следовательно, дивергенцией. Тогда можно говорить о выполнимой дивергенции: при одной нажатой кнопке (или когда нет нажатой кнопки) все -действия бесконечной цепочки выполнимы, а при другой — нет и, следовательно, нет «зацикливания». Выйти из дивергенции, которая начинает выполняться после кнопки A, можно с помощью кнопки B, при которой дивергенция не выполнима. Заметим, что для этого требуется переключение кнопок, то есть нажатие кнопки без наблюдения (которого может не быть). 37
Единственный случай, когда из дивергенции нельзя гарантированно выйти, — это когда дивергенция выполнима при нажатии любой кнопки.
3.3. Переключение кнопок В машине без приоритетов кнопку можно нажимать либо после включения машины, либо после того, как произошло наблюдение по предыдущей кнопке. Иными словами, запрещается переключать кнопки без наблюдения, отжимая одну кнопку и нажимая другую. Этот запрет объясняется тем, что, если приоритетов нет, возможность переключения кнопок не увеличивает мощность тестирования. Действительно, если была нажата кнопка P, а потом без наблюдения нажата другая кнопка Q (а кнопка P отжата), то в этом интервале времени реализация могла выполнять только -действия. Но действия всегда разрешены, поэтому реализация могла бы выполнять их и в том случае, когда вместо кнопки P сразу нажималась кнопка Q (а второй раз, естественно, не нажималась). Тем самым, любое поведение, которое можно наблюдать в первом случае, можно было бы наблюдать и во втором случае.
Рис. 3. Переключение кнопок. При наличии приоритетов переключение без наблюдения необходимо для полноты тестирования, поскольку различные множества разрешённых действий по-разному влияют на выполнение -действий (-переходы тоже могут иметь предикаты), что приводит к внешне различимым поведениям. Например, если в реактивной системе приём стимула приоритетнее выдачи реакций и -действий, последние выполняются только тогда, когда реализация не может принять стимул, посылаемый ей тестом. На Рис. 3 показан пример, где для получения тестом реакции !y после стимула ?a нельзя сразу посылать этот стимул (тогда после него будет реакция !x), а нужно сначала послать стимул ?b, а потом переключить кнопку {?b} на кнопку {?a}, послав тем самым стимул ?a. Если реализация принимает стимул ?b, то переключение нужно успеть сделать до приёма стимула ?b. Если же реализация блокирует стимул ?b (нет пунктирного перехода), то можно «не торопиться»; если блокировка {?b} наблюдаема, можно сначала её дождаться, а потом послать стимул ?a. 38
Тем не менее, в пользу запрета на переключение кнопок имеются разумные аргументы и в случае наличия приоритетов. Дело в том, что переключение кнопок позволяет «обходить» ненаблюдаемый отказ: если оператор переключает -кнопку P на (любую) другую кнопку Q, то возникновение ненаблюдаемого отказа P не препятствует такому переключению (как на 0, когда нет пунктирного перехода по стимулу ?b, а блокировка {?b} не наблюдаема). Другое дело, что, если возможен отказ P, то при безопасном тестировании мы не можем нажимать кнопку P без последующего переключения на другую кнопку, то есть с ожиданием наблюдения (на 0 кнопку {?b} всегда нужно переключать на кнопку {?a} или какую-то другую). Тем самым, если можно переключать кнопки, условие безопасности -кнопок более сложное (ниже мы его подробно рассмотрим). Если переключений кнопок нет, тестирование выглядит более привычно как чередующаяся последовательность тестовых воздействий (нажимается кнопка) и наблюдений. Кроме того, в этом случае к работе оператора предъявляется меньше временных требований.
3.4. Временные ограничения на работу оператора (теста) Введение приоритетов усложняет работу оператора, налагая более сложные требования по времени. Если приоритетов нет, то оператор должен уметь достаточно быстро нажимать кнопку после включения машины или после предыдущего наблюдения. Заметим, что если оператор не успевает достаточно быстро нажать кнопку, ничего страшного не случится, поскольку машина успеет выполнить только одно или несколько -действий, которые (в машине без приоритетов) она может выполнить и в том случае, когда кнопка была нажата немедленно. Иными словами, мы требуем, чтобы оператор мог работать быстро, но не заставляем его всегда работать быстро. Если приоритеты есть, то возможность наблюдения тех или иных поведений реализации требует не только достаточно высокой скорости работы оператора, но также достаточно медленной, средней и т.д. В примере на Рис. 4 стимул ?a может приниматься в трёх состояниях 1, 2 и 3, но реакции после этого различны: !x, !y или !z. Эти состояния связаны -переходами, которые выполнимы только, если тест не посылает стимул ?a. Поэтому реакция !x будет наблюдаться только, если оператор быстро нажмёт кнопку {?a}, реакция !z — только если оператор не будет торопиться, а реакция !y — только при средней скорости работы. Если есть переключение кнопок, то такое переключение также нужно уметь делать с различными интервалами времени, чтобы «заставить» реализацию проходить нужное число -переходов между двумя кнопками.
39
Рис. 4. Модель, поведение которой зависит от скорости нажатия кнопок. Таким образом, для машины с приоритетами следует учитывать временные задержки, которые делает оператор между наблюдением и последующим нажатием кнопки или между двумя нажатиями кнопок при их переключении без наблюдения. Мы можем считать, что в погодные условия включены также те факторы, которые влияют на «свободу воли» оператора, определяя те или иные временные задержки при нажатии кнопок. Это согласуется с тем, что оператор должен моделировать любую скорость работы окружения. Работа оператора моделирует выполнение тестовой программы на компьютере. Такая программа недетерминирована только на некотором уровне абстракции, когда мы отвлекаемся от других программ или аппаратуры, влияющих на её поведение.
3.5. Истории Если приоритетов нет, возможность наблюдения действия после некоторой предыстории взаимодействия не зависит от того, какая именно нажимается кнопка, разрешающая это действие. При наличии приоритетов это становится важным, поскольку различным кнопкам соответствуют различные множества разрешённых действий, и при нажатии одной кнопки предикат может оказаться истинным, и действие может наблюдаться, а при нажатии другой — ложным, и действие не может наблюдаться. Поэтому теперь нужно запоминать не только наблюдения, но также те кнопки, которые нажимал оператор. Тем самым, результатом тестового эксперимента становится последовательность действий, отказов и кнопок. Такую последовательность мы будем называть историей. Чтобы в истории отличить кнопку от отказа (и то и другое — подмножество внешних действий), мы будем кнопку заключать в кавычки и писать “P”, а не просто P. Если не ограничиваться только безопасным тестированием, то мы должны включить в истории также разрушение и дивергенцию, но после них история не может продолжаться, аналогично трассам. Очевидно, что в истории каждому внешнему действию z непосредственно предшествует кнопка “P”, разрешающая это действие zP, а каждому отказу R — -кнопка “R”. Могут или не могут идти две кнопки подряд, зависит от того, разрешено или запрещено переключение кнопок. 40
Для заданной /-семантики истории будем называть /-историями. Определим их более формально. Рассмотрим LTS с предикатами S. Для множества разрешённых действий P переход sz,s` будем называть P-выполнимым, если его предикат истинен (P)=true. Будем говорить, что для множества разрешённых действий P -маршрут P-выполним, если все его переходы P-выполнимы. Пустая /-история заканчивается в состояниях, достижимых из начального состояния по -выполнимым -маршрутам, то есть, когда после включения машины не нажата никакая кнопка. Пусть /-история заканчивается во множестве состояний S after . Рассмотрим различные продолжения этой /-истории. Мы будем предполагать, что /-история не заканчивается разрушением или дивергенцией, поскольку после дивергенции и разрушения нет продолжений. Продолжение кнопкой P, где P. Если допускается переключение кнопок, такое продолжение всегда возможно. Если переключения кнопок нет, /-история не должна заканчиваться кнопкой. Переключение интерпретируется как отжатие первой кнопки, а потом нажатие второй кнопки. Поэтому сначала реализация может выполнить любой -выполнимый -маршрут, начинающийся в состоянии из S after , а затем продолжить выполнение любым P-выполнимым -маршрутом. Множество концов таких маршрутов и будет множеством состояний S after “P”. Заметим, что, если история не заканчивалась на кнопку, то концы всех -выполнимых маршрутов уже входят в S after . Продолжение внешним действием z. Такое продолжение возможно только в том случае, когда сама /-история имеет вид “P”, то есть заканчивается кнопкой P, разрешающей это действие zP. Наблюдение действия z происходит, когда совершается P-выполнимый переход по z из состояния после предшествующей /-истории, то есть перехода sz,s`, где s(S after “P”) и (P)=true. В результате такого перехода кнопка автоматически отжимается, и далее могут выполняться -выполнимые маршруты до тех пор, пока не возникнет разрушение, пока не будет нажата кнопка (та же самая или другая), или пока оператор не выключит машину, заканчивая сеанс тестирования. Множество концов этих -маршрутов и является множеством S after “P”,z. Продолжение -отказом P. Такое продолжение возможно только в том случае, когда сама /-история имеет вид “P”. Отказ P возникает в таком состоянии s(S after “P”), в котором выполнено условие остановки машины: для каждого перехода (по любому действию, включая и ) sz,s` должно быть (P)=false. После отказа кнопка 41
отжимается и реализация может выполнить -выполнимый -маршрут, начинающийся в одном из состояний, где наблюдался отказ. Множество концов этих -маршрутов и является множеством S after “P”,P.Заметим, что состояния, где наблюдался отказ, тоже входят в это множество (для пустого -маршрута). Продолжение разрушением . Такое продолжение возможно только в том случае, когда в некотором состоянии s(S after ) переход s,s` P-выполнимым, если /-история заканчивается кнопкой P (наблюдения ещё не было, и продолжает действовать кнопка P), или -выполним в противном случае (после наблюдения не действует никакая кнопка). Поскольку после разрушения нет продолжения, нас не интересует множество состояний после такого продолжения. Продолжение дивергенцией . Поскольку опасна не сама дивергенция, а попытка выхода из неё, нас будет интересовать только такая дивергенция, которая выполнима при нажатой кнопке P. Такая дивергенция возникает после /-истории вида “P”, если есть бесконечный P-выполнимый маршрут, начинающийся в состоянии из S after “P” (очевидно, достаточно считать, что маршрут начинается в состоянии из S after ). В этом случае символ будет продолжать /-историю после кнопки P. Поскольку после дивергенции нет продолжения, нас не интересует множество состояний после такого продолжения. Теперь аналогично трассам определим полные истории или F-истории как /-истории для =(L) и, соответственно, =, когда любое подмножество внешних действий является -кнопкой. Множество F-историй LTS S — обозначим так же, как множество F-трасс, — F(S), поскольку в дальнейшем мы будем рассматривать только истории, а не трассы. Теперь /-история LTS — это такая её F-история, в которой встречаются кнопки только из семейств и , а отказы — это только -отказы.
3.6. Безопасность и конформность без переключения кнопок Поскольку выполнимость переходов LTS-модели с приоритетами зависит от предикатов на этих переходах, меняются отношения безопасности кнопок в реализации (safe in) и спецификации (safe by). Если нет переключения кнопок, то отношения safe in и safe by определяются почти так же, как для машины без приоритетов. Изменения заключаются в том, что вместо -трасс рассматриваются /-истории, безопасность или опасность кнопки определяется только после /-истории, не заканчивающейся кнопкой, продолжение внешним действием зависит от кнопки, дивергенция возможна лишь после кнопки, разрушения не должно быть не только после действия, но также после отказа (для -кнопки) и сразу после нажатия кнопки. 42
Определение отношения безопасности в реализации без переключения кнопок: P safein I after =def “P”,F(I) & uP “P”,u,F(I) & (P “P”,P,F(I)). P safein I after =def P safein I after & “P”,F(I). P safe1in I after =def P safein I after &(P“P”,PF(I)). Требования к отношению безопасности в спецификации без переключения кнопок: R zL Q 1) R safe1by S after R safein S after , 2) T T safein S after & “T”,zF(S) P P safe1by S after & “P”,zF(S), 3) Q safe1by S after Q safein S after &vQ “Q”,vF(S). На основе отношений безопасности кнопок в реализации и спецификации определяются безопасные действия, безопасные /-истории Safe1In(I) и Safe1By(S), гипотеза о безопасности и безопасная конформность аналогично тому, как это делалось для трасс в случае машины без приоритетов. Отличия сводятся к следующему: В определении безопасности /-истории и в гипотезе о безопасности следует говорить не о трассе , а об истории , то есть о разрушении, выполнимом без нажатия кнопок (-выполнимом). I safe for S =def (“”,F(S) “”,F(I)) & Safe1By(S)Safe1In(I) P (P safe1by S after P safe1in I after ). В определении множества наблюдений, которые можно получить над моделью T при нажатии кнопки P после трассы , вместо продолжения трассы наблюдением нужно говорить о продолжении /-истории кнопкой и наблюдением: obs(,P,T) =def {u|“P”,uF(T) & (uP u=P & P)}. I saco S =def I safe for S & Safe1By(S)Safe1In(I) P safe1by S after obs(,P,I)obs(,P,S).
3.7. Безопасность и конформность с переключением кнопок Если допускается переключение кнопок, мы можем обходить запрет на возникновение ненаблюдаемого отказа после нажатия -кнопки Q, а также дивергенцию, просто переключая её на другую кнопку P. Соответственно, модифицируются отношения безопасности: удаляются условия в определениях safe1in и safe1by, подчёркнутые волнистой линией, и остаются условия, связанные только с разрушением. 43
Определение отношения безопасности в реализации с переключением кнопок: P safe2in I after =def P safein I after . Требования к отношению безопасности в спецификации с переключением кнопок: R zL Q 1) R safe2by S after R safein S after , 2) T T safein S after & “T”,zF(S) P P safe2by S after & “P”,zF(S), 3) Q safe2by S after Q safein S after . Однако возникает вопрос: сколько раз оператор может переключать кнопки? Здесь нужно учитывать, что целью нажатия кнопок является получение, в конечном счёте, некоторого наблюдения. Поскольку мы рассматриваем только конечные (по времени выполнения) тесты, цепочка переключений кнопок должна быть конечной, то есть заканчиваться нажатием кнопки, после которой оператор ожидает гарантированного наблюдения, что даёт ему возможность, в частности, закончить сеанс тестирования. Это означает, что все кнопки в цепочке, кроме последней, безопасны после непосредственно предшествующего им префикса истории по отношению safe2in/by, а последняя кнопка — по отношению safe1in/by: P safe in I after =def P0=P,P1,…,Pn & i=0..n-1 Pi safe2in I after “P0”,“P1”,…,“Pi-1” & Pn safe1in I after “P0”,“P1”,…,“Pn-1”, P safe by S after =def P0=P,P1,…,Pn & i=0..n-1 Pi safe2by S after “P0”,“P1”,…,“Pi-1” & Pn safe1by S after “P0”,“P1”,…,“Pn-1”. Таким образом, отношение безопасности с индексом “2” определяет продолжение истории кнопкой, не вызывающей разрушение, а отношение безопасности с индексом “1” дополнительно запрещает ненаблюдаемый отказ и дивергенцию. Понятно, что 2-безопасная кнопка также и 1-безопасна, но обратное, вообще говоря, не верно. Для полной безопасности кнопки после истории требуется, чтобы она была 1-безопасна, и после неё можно было поместить конечную цепочку 1-безопасных кнопок, а затем 2-безопасную кнопку, гарантирующую наблюдение. На основе отношений безопасности кнопок в реализации и спецификации определяются безопасные действия, безопасные истории, гипотеза о безопасности и безопасная конформность аналогично тому, как это делалось для случая без переключения кнопок. Отличия сводятся к следующему: 1) В гипотезе о безопасности из i-безопасности кнопки в спецификации должна следовать тоже i-безопасность кнопки в реализации, где i=1,2: 44
I safe for S =def (“”,F(S) “”,F(I)) & SafeBy(S)SafeIn(I) P (P safei by S after P safei in I after ). 2) В определении конформности вложенность множеств наблюдений должна требоваться только после 1-безопасных историй, то есть историй, заканчивающихся на 1-безопасную кнопку: I safe for S I saco S =def & SafeBy(S)SafeIn(I) P safe1by S after obs(,P,I)obs(,P,S).
3.8. Параллельная композиция и генерация тестов Рассмотрим композицию двух LTS с приоритетами I и T в алфавитах, соответственно, A и B. Возьмём любое композиционное состояние it. При композиции множество разрешённых внешних действий для LTS I в состоянии i — это множество противоположных внешних действий, по которым есть переходы из состояния t другой LTS T, и наоборот. Поэтому, прежде всего, нам нужно пересчитать предикаты переходов из этих состояний. В силу коммутативности оператора композиции (с точностью до изоморфизма, то есть именования состояний it или ti), нам достаточно рассмотреть только пересчёт предикатов одной LTS, для определённости, LTS I. Для перехода iz,ii` мы должны в предикат i, понимаемый как булевская функция от булевских переменных-действий, подставить константное значение каждой переменной, соответствующей синхронному действию zAB. Если есть переход tz,tt`, то подставляется значение true, иначе — false. Получается новый предикат it. Заметим, что вычисление нового предиката на переходе из состояния i зависит от состояния t, с которым оно компонуется, то есть для разных состояний t будут разные предикаты it. Новый предикат it может быть не константным, поскольку в нём могут остаться переменные, соответствующие асинхронным внешним действиям из A\B. Кроме того, теперь этот предикат следует понимать как предикат в композиционном алфавите AB=(A\B)(B\A), хотя реально он не зависит от переменных, соответствующих действиям из B\A. Асинхронный переход соответствует одному переходу в одном из LTSоперандов. Он может выполняться, если может выполняться наследуемый переход. Следовательно, предикат асинхронного композиционного перехода совпадает с предикатом наследуемого перехода после пересчёта, то есть не с исходным предикатом i, а с предикатом it. Синхронный переход — это одновременное выполнение переходов в каждом LTS-операнде. Он может выполняться, если могут выполняться оба перехода-операнда. Следовательно, 45
предикат синхронного композиционного перехода равен конъюнкции пересчитанных переходов-операндов it&ti. В целом композиционные переходы порождаются следующими правилами вывода: (1*) z{,}A\B & iz,ii` itz,iti`t, tz,tt` itz,tiit`, (2*) z{,}B\A & (3*) zAB & iz,ii` & tz,tt` it,it&tii`t`. Как и в случае машины без приоритетов тестирование понимается как композиция LTS-реализации I в алфавите A и LTS-теста T в противоположном алфавите B=A. Мы также будем предполагать, что в тесте нет разрушения. Переходы по внешним действиям в тесте не имеют предикатов, точнее их предикаты тождественно истинны. Поэтому в композиционной LTS все переходы (а это уже только - и -переходы) — это пересчитанные предикаты переходов реализации. Поскольку композиционный алфавит пуст, эти предикаты константны (true или false). Для обнаружения отказов в тесте (но не в реализации!) также используются переходы с тождественно истинными переходами. Если нет переключения кнопок, такой переход срабатывает тогда и только тогда, когда никакие другие переходы не могут выполняться: (4*) tt` & Deadlock(i,t) itit`, где Deadlock(i,t) = i,it & i,it & t & (zAB iz,it tz). Если допускается переключение кнопок, то в тесте оно отображается в виде перехода “P”“Q” из состояния, соответствующего одной кнопке P, в состояние, соответствующее другой кнопке Q. -переход определяется в состоянии “P”, если кнопка P — это -кнопка. Нужно, чтобы -переход мог срабатывать независимо от -перехода переключения кнопок “P”“Q”: удаляется условие t, подчёркнутое волнистой линией. Мы будем рассматривать только безопасные реализации и безопасные тесты. Под безопасным тестом здесь понимается тест, при взаимодействии которого с любой безопасной реализацией не возникают разрушение, дивергенция, выполнимая после нажатия кнопки, а также тупики. Такие тесты строятся на основе безопасных историй спецификации. Тестовая история — это либо безопасная история спецификации, либо безопасная история спецификации, заканчивающаяся кнопкой, которая продолжена наблюдением (действием или -отказом), отсутствующим после этой истории в спецификации. Также мы будем рассматривать только такие тесты, которые заканчиваются через конечное время; мы будем называть их конечными тестами. Для безопасного LTS-теста это означает отсутствие в нём бесконечных маршрутов.
46
=“A”,A,“B”,b,“C”,c, где A,B, C. Внешнее действие имеет индекс «хорошо», если оно есть в спецификации после префикса истории; иначе — индекс «плохо». Пунктиром показаны взаимоисключающие переходы, ведущие из одного состояния. Индексы «хорошо» и «плохо» означают наличие или отсутствие продолжения префикса истории соответствующим -отказом. Маленькими серыми кружками показаны пустые состояния. Рис. 5. Примитивный тест для безопасной R/Q-истории . В композиции теста с реализацией все предикаты константны, мы можем удалить все переходы с ложными предикатами. Если реализация безопасна, а тест конечен и безопасен, то оставшиеся -переходы недостижимы. Как и для машины без приоритетов выполнению теста соответствует прохождение маршрута, начинающегося в начальном состоянии композиции и заканчивающегося в композиционном состоянии it, где t терминальное состояние теста, которому назначен вердикт pass или fail. Заметим, что в композиции могут быть бесконечные маршруты, но они не могут проходиться при тестировании. Действительно, поскольку тест конечен, в таком маршруте, начиная с некоторого места, состояние теста не меняется: дальше идут только асинхронные -переходы реализации. В процессе тестирования оператор машины всегда за конечное время дожидается наблюдения, нажимает или переключает кнопку, что означает смену состояния теста и, тем самым, прекращение выполнения бесконечной цепочки -переходов реализации. Здесь мы опираемся на то, что за конечное время может выполняться только конечная цепочка переходов. Оператор может также выключить машину (окончание тестирования), что происходит через конечное время после наблюдения. Тест должен взаимодействовать с реализацией, согласно той /-семантики, в которой рассматривалась спецификация, по которой тест сгенерирован. 47
Поэтому в каждом состоянии теста множество действий, по которым определены переходы из состояния, должно соответствовать - или -кнопке, причём для -кнопки дополнительно должен быть определён -переход. Мы приняли допущение о том, что сразу после включения машины до нажатия первой кнопки, после любого наблюдения, а также при переключении кнопок в реализации могут выполняться -выполнимые - и -переходы. Это допущение является частью семантики взаимодействия, которую должен соблюдать тест. Поэтому нужно ввести в тест дополнительные пустые состояния, соответствующие ситуации, когда нет нажатых кнопок. Эти состояния теста должны позволять реализации совершать -выполнимые переходы. При отжатых кнопках множество разрешённых действий пусто, поэтому в пустом состоянии могут быть определены только -переходы. Эти -переходы, в конечном счёте, должны приводить к непустым состояниям, соответствующим той или иной кнопке (пустая -кнопка соответствует состоянию, в котором определён -переход, а пустую -кнопку мы запретили). Такой пустой кнопкой должно быть начальное состояние и постсостояние каждого перехода по наблюдению, если это не терминальное состояние. Примитивный тест строится аналогично тому, как это делается для машины без приоритетов. Но есть три отличия. 1) Без приоритетов мы строили тест по безопасной -трассе, превращая её в одну из /-историй, а теперь сразу начинаем с некоторой безопасной /-истории. 2) Если в истории есть переключение с кнопки P на кнопку Q, то в тесте проводится -переход “P”“Q”. 3) Добавляются пустые состояния. По-прежнему, набор всех примитивных тестов полон, а любой строгий тест можно заменить на объединение примитивных тестов, которое обнаруживает те же самые ошибки.
3.9. Примеры задания приоритетов Покажем, как задаются приоритеты с помощью предикатов на переходах LTSмодели для примеров, приведённых во введении. Выход из дивергенции. Переход по внешнему действию имеет тождественно истинный предикат, а -переход имеет предикат , истинный только на пустом подмножестве алфавита внешних действий: (U)=(U=). Выход из осцилляции (приоритет приёма над выдачей). Переход по стимулу имеет тождественно истинный предикат, а переход по реакции имеет предикат , истинный на любом подмножестве действий, не содержащем стимулов: (U)=(?x ?xU). Обычно также подразумевается, что внутренняя активность менее приоритетна, чем приём стимула, то есть -переход имеет такой же предикат, как переход по реакции. Приоритет выдачи над приёмом в неограниченных очередях. Переход по реакции имеет тождественно истинный предикат, а переход по стимулу имеет 48
предикат , истинный на любом подмножестве действий, не содержащем реакцию: (U)=(!y !yU). Обычно также подразумевается, что внутренняя активность менее приоритетна, чем выдача реакции, то есть переход имеет такой же предикат, как переход по стимулу. Прерывание цепочки действий. Переход по команде «отменить» (cancel) имеет тождественно истинный предикат, а все остальные переходы имеют предикат , истинный на любом подмножестве действий, не содержащем “cancel”: (U)=(cancelU). Приоритетная обработка входных воздействий. Множество стимулов разбивается на непересекающиеся подмножества X1,X2,… так, что стимулы из подмножества с большим индексом имеют больший приоритет. Предикат i на переходе по стимулу из Xi истинен на любом подмножестве действий, не содержащем стимулы из подмножества с большим номером: i(U)=(j>i UXj=). Возможна также дифференциация переходов из некоторого состояния по одному и тому же стимулу в зависимости от наличия или отсутствия менее приоритетных стимулов. Например, один переход по стимулу из Xi выполняется, если окружение предлагает менее приоритетные стимулы i1(U)=i(U)&(j, где индексы j1, …, j2 и j3, …, j4 (список j1, …, j2 может быть пуст) соответствуют переходам, принадлежащим трассе Tk-1, а i1, …, i2 — переходам, принадлежащим трассе Tk. По построению начальное состояние перехода i1 совпадает с конечным состоянием перехода j2, если он существует, или с начальным состоянием трассы Tk-1 в обратном случае, а конечное состояние перехода i2 совпадает с начальным состоянием перехода j3. Таким образом, для любого номера k=2..N определена сумма трасс Tk-1 + Tk, причем начальное и конечное состояния этой суммы трасс совпадают соответственно с начальным и конечным состояниями трассы Tk-1. Можно сказать также, что каждая следующая подтрасса в полученном разбиении или вложена в предыдущую, или непосредственно предшествует ей в исходной трассе. В силу доказанного свойства, не существует индекса, относящегося к трассе Tk-2 и лежащего между двумя индексами, относящимися к трассе Tk-1. Следовательно, добавление трассы Tk-2 к сумме трасс Tk-1 + Tk не нарушает предусловие операции сложения трасс, то есть, для k3 определена также и сумма трасс Tk-2 + Tk-1 + Tk, а её начальное и конечное состояние совпадают соответственно с начальным и конечным состояниями трассы Tk-2. Повторяя аналогичные рассуждения необходимое количество раз, мы доказываем даже более сильное утверждение относительно построенного алгоритмом разбиения: Для i, j: 1 i j N, следовательно, определена сумма трасс Ti + … + Tj. Следовательно, Требование 1 также выполняется для построенного разбиения. Теорема доказана. Доказав существование таких разбиений, мы можем пользоваться методом локализации ошибок путём сокращенного проигрывания трасс, который опирается на них. Метод заключается в следующем. 1. Считываем из трассы теста, обнаруживающего ошибку, список пройденных состояний и переходов и выкидываем из него все элементы, следующие за состоянием, в котором была обнаружена ошибка. 2. Строим разбиение полученной трассы на набор подтрасс, удовлетворяющий вышеописанным свойствам. 3. Находим минимальный номер k такой, что трасса k = T1 + T2 + … + Tk-1 + Tk находит ошибку, а трасса k-1 = T1 + T2 + … + T k-1 — не находит. Таким образом, мы обнаруживаем, что ошибка впервые 149
начинает проявляться после добавления к проигрываемой части трассы теста простого цикла Tk. Этот цикл естественным образом становится первым «подозреваемым» на внесение ошибки в состояние тестируемой системы. Как мы видели в примере выше, такое разбиение не единственно. Более того, различные разбиения одной и той же трассы, удовлетворяющие приведённым выше требованиям, могут содержать даже разное количество элементов, как показано на Рис. 5. Поскольку в общем случае мы не знаем заранее, где именно допущена ошибка в тестируемой реализации, мы тем более не можем также знать, какое из разбиений будет более полезным для локализации ошибки. Однако если выполняются гипотезы I и II, мы можем, тем не менее, ожидать, что разбиение, которое содержит большое количество коротких циклов, будет лучше разбиения, содержащего малое количество длинных.
Рис. 5. Пример разбиений одной трассы с разным числом элементов. На данный момент создана и апробирована реализация метода, использующая приведенный в Приложении 1 алгоритм и строящая с его помощью единственное разбиение.
5. Реализация Создана реализация предложенного метода для технологии CTESK. Инструментарий CTESK [8,9] реализует технологию UniTESK для языка Си, поддерживая спецификационное расширение языка Си SeC [10].
5.1. Описание инструмента Инструмент написан на языке Java и инсталлируется как дополнение к пакету программ UniTESK Trace Tools. Он принимает на вход набор файлов с трассами CTESK, анализирует их и для каждой трассы генерирует следующие выходные файлы. 150
Результат анализа графа трассы. Этот файл содержит следующую информацию. o Все обнаруженные во входной трассе состояния тестового сценария. o Информацию о первой обнаруженной в трассе ошибке (сценарий UniTESK в некоторых случаях может продолжать работу после ошибок, но в рассматриваемом методе оставшаяся часть трассы считается недостоверной и игнорируется). o Сигнатуры встретившихся во входной трассе сценарных методов. Сигнатура состоит из имени сценарного метода, а также типов и имён используемых в нём итерационных переменных. o Разбиение входной трассы на подтрассы согласно приведённым выше требованиям к такому разбиению. o Некоторая дополнительная информация, полученная в результате анализа графа состояний модельного КА. Эта информация не используется инструментом, но может быть полезна для разработчика. Сценарий, позволяющий воспроизводить записанную в трассе последовательность вызовов сценарных методов целиком или частично для поиска ошибок. Поскольку язык SeC не предусматривает непосредственного вызова сценарных методов с указанием значений итерационных переменных, сценарий генерируется на языке Си и работает совместно с результатом трансляции сценария на SeC в язык Си транслятором CTESK.
Инструмент налагает на входные трассы следующие ограничения. Трасса должна быть сгенерирована с помощью CTESK. Трасса содержит запуск ровно одного тестового сценария (работа с множеством сценариев, работающих последовательно или параллельно, пока что не реализована). Запущенный в трассе сценарий имеет тип DFSM (такой сценарий имеет единственный активный поток управления [7], в котором происходит обход детерминированного КА [6]). Некоторые дополнительные ограничения на внутреннюю целостность трассы, гарантирующие корректность извлеченной из неё информации о структуре модельного КА и сигнатурах вызываемых методов. При нарушении некоторых из этих условий инструмент выдает соответствующее сообщение об ошибке и прекращает обработку трассы, при нарушении других сгенерированный сценарий может не компилироваться или быть неработоспособным. Например, если подать на вход инструменту трассу, 151
сгенерированную с помощью JavaTESK, на выходе можно получить корректный анализ трассы (который может быть полезен разработчику) и не имеющий смысла сценарий на языке Си.
5.2. Сгенерированный сценарий Пример сгенерированного инструментом сценария приведён с некоторыми сокращениями в Приложении 2. Сценарий содержит следующие методы. replay_check_state(const char *state) — проверка текущего модельного состояния исходного сценария CTESK. replay_call__initialize(int argc, char **argv) — инициализация сценария CTESK. replay_call__finalize() — завершение сценария CTESK. replay_call__(…) для каждого встретившегося во входной трассе сценарного метода — вызов соответствующего сценарного метода с заданными значениями итерационных переменных. Имена и типы параметров метода соответствуют именам и типам итерационных переменных исходного сценарного метода, с точностью до некоторых преобразований типов. do_replay(int path_number) — воспроизведение подтрассы path_number main_(int argc, char **argv) — главный метод сгенерированного сценария. parse_(char *val) для каждого встреченного в исходной трассе пользовательского типа итерационной переменной — декларация внешней пользовательской функции, восстанавливающей значения данного пользовательского типа из используемого в файле трассы строкового представления. Тела и сигнатуры сгенерированных методов согласованы с извлеченными из входной трассы сигнатурами вызванных сценарных методов, с реализуемой транслятором CTESK схемой генерации кода и с библиотекой поддержки тестовой системы времени выполнения TSBasis. Для реализации инструмента автор совместно с разработчиками инструментария CTESK доработал схему трансляции языка SeC: в неё была добавлена возможность вызова на уровне сгенерированного кода сценарных методов с точно указанными значениями итерационных переменных. Эти изменения вошли в очередную официальную версию CTESK. Для использования сгенерированного сценария его можно собрать (например, в проекте Microsoft Visual Studio с подключенным модулем интеграции CTESK) вместе со сценарием, сгенерировавшим исходную трассу, и со всем, что необходимо для его исполнения (спецификации, медиаторы, тестируемая система, библиотека поддержки выполнения тестов TSBasis, внешние 152
модули). После этого можно (а иногда необходимо) доработать сгенерированный сценарий (такая доработка необходима, если в исходном сценарии использовались итерационные переменные сложных спецификационных типов; в противном случае, сценарий работоспособен сразу после создания), заменить в процедуре main() запуск исходного сценария CTESK на вызов процедуры main_…() сгенерированного сценария, откомпилировать и запустить проект.
5.3. Запуск сценария При запуске сценарий ищет в параметрах командной строки параметр -path <path_number>. Если параметр найден и имеет положительное значение в диапазоне 1 path_number MAX_PATH_NUMBER , то воспроизводится подтрасса path_number. Если параметр отсутствует, то воспроизводится подтрасса DEFAULT_PATH_NUMBER. При значении path_number = 0 сценарий переходит в режим автоматической локализации ошибок методом инкрементального поиска — он последовательно перебирает все значения этого параметра от 1 до максимально возможного для построенного разбиения и останавливается после первой обнаруженной ошибки. При этом перед воспроизведением каждой подтрассы состояние тестовой системы инициализируется методом init() исходного сценария, а после воспроизведения сбрасывается методом finish(), если таковые в нём определены. Остальные параметры командной строки обрабатываются тестовой системой и исходным тестовым сценарием. В ходе выполнения сценарий генерирует трассу UniTESK, которую разработчик может впоследствии анализировать. Перед воспроизведением подтрассы k сценарий сбрасывает в выходную трассу сообщение Scenario replay: trying path . При наличии в исходной трассе ошибок, в полученной при запуске сгенерированного сценария трассе обязательно встречается одно из следующих сообщений: Scenario replay: repeatable failure — если при воспроизведении подтрассы удалось воспроизвести ожидаемую ошибку; Scenario replay: could not repeat failure — если ожидаемую ошибку воспроизвести не удалось. Также независимо от наличия ошибок в исходной трассе возможно появление сообщения Scenario replay: unexpected failure — в случае, если при работе сценария возникла неожиданная ошибка. В режиме автоматической локализации ошибок в выходную трассу сценария дополнительно сбрасываются сообщения следующего вида: Scenario replay: failure found at path — если ошибка впервые возникла при воспроизведении подтрассы k; Scenario replay: could 153
not repeat failure at any path — если ошибку не удалось воспроизвести ни на одной из подтрасс k Ошибкой считается возникновение любого из следующих событий. 1. Вызванный сценарный метод возвращает сообщение об ошибке (оно может быть вызвано сообщением об ошибке от тестового оракула или нарушением внутренних условий целостности тестового сценария). Такая ошибка считается ожидаемой, если она произошла в том же переходе, что и в исходной трассе; в противном случае, ошибка считается неожиданной. Какие-либо другие характеристики ошибки при этом не проверяются. 2. При воспроизведении трассы тестируемая система пришла в состояние, отличное от ожидаемого. Такая ошибка не может быть ожидаемой. При возникновении любой ошибки, соответствующая информация сбрасывается в выходную трассу, а работа сценария завершается.
6. Апробация Описываемый метод был опробован на примерах, поставляемых вместе с инструментами CTESK. Примеры состоят из реализации небольшой системы, формальных спецификаций, медиаторов [4] и тестовых сценариев. Для апробации в реализацию, спецификации и тестовые сценарии (для технологии UniTESK несущественно, где именно возникла ошибка) вносились ошибки следующих видов. 1. Неверный результат работы метода при определённой комбинации состояния и входных параметров. 2. Вызов одного целевого метода с определёнными параметрами «портит» состояние так, что последующий вызов другого метода работает с ошибкой. 3. Накапливающаяся ошибка, которая проявляется только после определённого числа вызовов целевого метода. Все эти ошибки обнаруживались тестовыми сценариями CTESK, при этом генерировались соответствующие трассы тестов, которые потом обрабатывались инструментом и воспроизводились с использованием той же ошибочной реализации, а также с другими реализациями (без ошибок и с другими ошибками). Как и следовало ожидать, наилучшие результаты достигнуты для ошибок первого вида: сгенерированный из трассы сценарий успешно находил эти ошибки на кратчайшем пути от начального состояния к ошибочному (1). Ошибки второго вида обнаруживались на любой подтрассе k , начиная с первой включающей вызов, вносящий ошибку (вызов, обнаруживающий ошибку, всегда входит в эти подтрассы, так как расположен в исходной трассе 154
позже). Даже для ошибок третьего вида иногда удавалось сократить трассу, выкинув из неё находящиеся в начале трассы циклы, не участвующие в накоплении ошибки; но в целом для таких ошибок предлагаемый метод малоэффективен, поскольку минимальный тест, находящий ошибку, должен содержать все те взаимодействия с целевой системой из исходного теста, в которых ошибка накапливалась, а они обычно более-менее равномерно распределены по трассе теста, то есть не выполняется гипотеза II. Инструмент также испытывался на трассах тестов, полученных из проекта верификации ОС Linux OLVER [11] и ОС реального времени для встроенных систем «Багет». Для этих проектов в ИСП РАН были разработаны тесты, моделирующие разнообразные части ядра ОС и стандартных библиотек конечными автоматами с состояниями различной сложности: от вырожденных до имеющих весьма сложную структуру. Наиболее простым и эффективным было применение инструмента для подсистем, имеющих вырожденное состояние (например, семейство функций …printf()), но в целом для таких случаев ценность рассмотренного метода невелика, поскольку тестируемые функции не зависят от предыстории, и возникновение ошибки зависит только от входных параметров, которые можно извлекать из отчетов UniTESK напрямую. В случае сложного внутреннего состояния системы (например, сценарии, работающие с подсистемами mutex, pthread) сгенерированные инструментом файлы анализа во многих случаях достаточно наглядно описывали внутреннюю структуру состояния, в котором была обнаружена ошибка, и способ его получения. При работе с этими подсистемами было обнаружено еще одно ограничение, налагаемое инструментом на тесты: эквивалентные состояния модельного КА, в том числе полученные из разных запусков, должны иметь одинаковое строковое представление. Например, если состояние моделируется неупорядоченным множеством, то сравнение двух состояний как объектов может сообщать об их равенстве, а сравнение их строковых представлений — о неравенстве, так как порядок вывода элементов множества стандартными библиотечными функциями не регламентирован. Так как инструменту доступно только строковое представление состояния из входной трассы, для его применения в таких случаях необходима соответствующая доработка исходного сценария (написание детерминированных преобразований в строковое представление) или сгенерированного сценария (например, с помощью пользовательских функций, восстанавливающих значения соответствующих типов из строкового представления). Однако даже несмотря на эти ограничения, в некоторых случаях удавалось быстро получить сокращенный тест, находящий ту же ошибку.
7. Заключение В данной статье описан метод сокращения тестов, находящих ошибку, предназначенный для помощи разработчикам в анализе результатов 155
тестирования и локализации обнаруженных ошибок. Приведённый метод предназначен в первую очередь для тестирования систем, обладающих сложным и недоступным для теста напрямую внутренним состоянием. Метод сокращенного воспроизведения трасс позволяет автоматически обнаруживать тестовые воздействия, которые с большой вероятностью ответственны за возникновение ошибки в тестируемой системе, даже если проявления ошибки были зафиксированы позже. Приведено математическое обоснование предложенного метода. Предложен алгоритм, реализующий его, и доказана корректность этого алгоритма. Разработан и апробирован инструмент, реализующий предложенный метод для технологии CTESK [8], которая реализует унифицированную технологию тестирования UniTESK [1] для языка Си. Результаты апробации показывают хорошие перспективы применения данного метода в промышленных проектах. В дальнейшем планируется развивать предложенный метод в следующих направлениях. Разработка аналогичных инструментов для других языков, поддерживаемых технологией UniTESK. Создание библиотечных компонентов, упрощающих работу с пользовательскими типами данных. Реализация возможности работы с несколькими последовательными сценариями в одной трассе. Исследование возможности работы с параллельно работающими в одной трассе сценариями. Исследование других стратегий нахождения минимальных подтрасс, обнаруживающих заданную ошибку. Исследование возможности обработки более чем одной ошибки исходной трассы. Литература [1] http://www.unitesk.com/ru/ — сайт, посвященный технологии тестирования UniTesK и поддерживающим ее инструментам. [2] В. В. Кулямин, А. К. Петренко, А. С. Косачев, И. Б. Бурдонов. Подход UniTesK к разработке тестов. Программирование, 29(6):25–43, 2003. http://www.ispras.ru/~kuliamin/docs/Unitesk-2003-ru.pdf [3] I. Bourdonov, A. Kossatchev, A. Petrenko, and D. Galter. KVEST: Automated Generation of Test Suites from Formal Specifications. FM'99: Formal Methods. LNCS 1708:608–621, Springer-Verlag, 1999. [4] I. Bourdonov, A. Kossatchev, V. Kuliamin and A. Petrenko. UniTesK Test Suite Architecture. Proceedings of FME 2002, LNCS 2391:77–88, Springer-Verlag, 2002. http://www.ispras.ru/~kuliamin/docs/FME-2002-en.pdf [5] И. Б. Бурдонов, А. С. Косачев, В. В. Кулямин. Использование конечных автоматов для тестирования программ. Программирование, 26(2):61–73, 2000. http://www.ispras.ru/~kuliamin/docs/FSM-2000-ru.pdf
156
[6] И. Б. Бурдонов, А. С. Косачев, В. В. Кулямин. Неизбыточные алгоритмы обхода ориентированных графов: детерминированный случай. Программирование, 29(5):59–69, 2003. http://www.ispras.ru/~kuliamin/docs/Graphs-2003-ru.pdf [7] С. Г. Грошев. Применение технологии UniTesK для тестирования систем с различной конфигурацией активных потоков управления. Труды Института Системного Программирования РАН, 9:67–81, 2006. http://www.citforum.ru/SE/testing/unitest_use/ [8] CTESK. Документация. http://www.unitesk.ru/content/category/7/18/51/ [9] CTESK. Automating Testing of C Applications. Official CTESK whitepaper. http://www.unitesk.ru/download/papers/ctesk/ctesk_wp.pdf [10] CTESK 2.2: Описание языка SeC. http://www.unitesk.ru/download/papers/ctesk/CTesK2.2LanguageReference.rus.pdf [11] OLVER — проект по верификации ОС Linux. http://linuxtesting.ru/project/olver
Приложение 1. Алгоритм разбиения трассы В данном разделе приведёна реализация предложенного алгоритма на языке Java версии 1.5. В модели данных определен класс State, моделирующий состояние КА, и класс Arc, моделирующий переход трассы. Класс Arc содержит поля startState и endState типа State, ссылающиеся соответственно на начальное и конечное состояние соответствующего перехода. Входные данные:
List fullPath — исходная трасса (сокращенная форма записи, в которой фигурируют только переходы). Согласно определению трассы, для любых двух последовательных переходов трассы A1 и A2 , A1.endState == A2.startState
for (int j = 0; j < currentPath.size(); j++) { // Поиск цикла if (currentArc.endState == currentPath.get(j).startState) { // Выделяем обнаруженный цикл List newLoop = currentPath.subList(j, currentPath.size()); // Добавляем его в начало списка pathes pathes.add(0, newLoop.toArray(new Arc[newLoop.size()]) ); // Удаляем входящие в него переходы из currentPath newLoop.clear(); break; } } } // Добавляем в список pathes оставшийся прямой путь из начального состояния в конечное if (currentPath.size() > 0) pathes.add(0, currentPath.toArray(new Arc[currentPath.size()]) );
Приложение 2. Пример использования инструмента Дан следующий исходный сценарий CTESK, тестирующий реализацию банковского счета. AccountModel acct; static bool account_init (int argc, char **argv) {...} static Integer* account_state() { return create_Integer(acct.balance); } scenario bool deposit_scen() { if (acct.balance 62) { ... } if (path_number > 63) { ... }
159
if (path_number > 64) { GOOD_CALL(replay_check_state("4")) GOOD_CALL(replay_call__deposit_scen(1)) // transition #5 } if (path_number > 65) { GOOD_CALL(replay_check_state("5")) GOOD_CALL(replay_call__deposit_scen(1)) // transition #6 GOOD_CALL(replay_check_state("6")) GOOD_CALL(replay_call__withdraw_scen(1)) // transition #7} } if (path_number > 64) { GOOD_CALL(replay_check_state("5")) ... } if (path_number > 63) { ... } ...... if (path_number > 2) { ... } if (path_number > 1) { GOOD_CALL(replay_check_state("1")) GOOD_CALL(replay_call__deposit_scen(1)) // transition #400 GOOD_CALL(replay_check_state("2")) GOOD_CALL(replay_call__deposit_scen(1)) // transition #401 GOOD_CALL(replay_check_state("3")) GOOD_CALL(replay_call__deposit_scen(1)) // transition #402 GOOD_CALL(replay_check_state("4")) GOOD_CALL(replay_call__deposit_scen(5)) // transition #403 GOOD_CALL(replay_check_state("9")) GOOD_CALL(replay_call__withdraw_scen(1)) // transition #404 GOOD_CALL(replay_check_state("8")) GOOD_CALL(replay_call__withdraw_scen(1)) // transition #405 GOOD_CALL(replay_check_state("7")) GOOD_CALL(replay_call__withdraw_scen(1)) // transition #406 GOOD_CALL(replay_check_state("6")) GOOD_CALL(replay_call__withdraw_scen(5)) // transition #407 } // Straight path GOOD_CALL(replay_check_state("1")) GOOD_CALL(replay_call__deposit_scen(1)) // transition #408 GOOD_CALL(replay_check_state("2")) GOOD_CALL(replay_call__deposit_scen(1)) // transition #409 GOOD_CALL(replay_check_state("3")) GOOD_CALL(replay_call__deposit_scen(1)) // transition #410 GOOD_CALL(replay_check_state("4"))
160
// Original error: info = 'Scenario function failed', kind = 'Scenario Function Failed' BAD_CALL(replay_call__deposit_scen(1)) // transition #411 /* The rest of replay is skipped */ return 0; __unexpected_failure: traceException("Scenario replay: unexpected failure"); return 1; __no_expected_failure: traceException("Scenario replay: could not repeat failure"); return 2; __expected_failure: traceUserInfo("Scenario replay: repeatable failure"); return 3; } int main_account_scenario_2007_06_15_11_00_01(int **argv) { ... }
argc,
char
Из приведённого отрывка кода мы можем, например, видеть, что переходы 408-411 принадлежат подтрассе T1, причем переход 411 вызывал в исходной трассе ошибку. Кроме того, подтрасса T66 состоит из переходов с индексами 6 и 7, начинается в состоянии, имеющем строковое представление «5» и заканчивается в нём же, вложена в T65 и не содержит других вложенных подтрасс; подтрассы T65, T64, T63 и T62 последовательно вложены друг в друга. Что касается подтрасс T62…T18, то они вложены напрямую в T17; такого рода ситуации возникают, когда несколько подряд циклов (не обязательно простых) начинаются в одном и том же состоянии. Более подробный анализ входной трассы содержится в файле анализа, который включает описание каждой подтрассы Tk в виде списка входящих в неё состояний и переходов и некоторую дополнительную информацию о графе КА, извлеченном из исходной трассы.
161
Тестирование современных библиотек тригонометрических функций Е. С. Чернов, В. В. Кулямин {ches, kuliamin}@ispras.ru Аннотация. Данная статья посвящена созданию тестового набора по методу, описанному в работе [1], для четырех тригонометрических функций (cos, tan, arccos, arctan) на основе существующих стандартов и дополнительных требований, возникающих из математических особенностей этих функций и специфических свойств представления чисел с плавающей точкой. Здесь также представлены результаты тестирования различных реализаций этих функций в математических библиотеках на разных платформах и при различных режимах округления.
1. Введение Одной из областей человеческой деятельности, опирающейся на использование сложного программного обеспечения (ПО), является математическое моделирование сложных явлений. Это, например, моделирование развития вселенной в целом, галактик и звезд, физических процессов в экстремальных условиях, биохимических, климатических и социальных процессов. Во многих случаях компьютерное моделирование дает важную информацию о таких явлениях, но очень нелегко получить независимую оценку правильности получаемых результатов, что позволило бы проверить корректность самого используемого ПО. Это порождает серьезные проблемы при разработке надежных систем математического моделирования. Тем не менее, повысить надежность и правильность работы таких систем можно за счет формальной проверки корректности библиотечных компонентов, на которые оно во многом опирается, в частности, реализаций математических функций. Уверенность в надежности фундамента, на котором построены эти системы, даст возможность разрабатывать их более качественно и с меньшими усилиями, сосредоточившись на поиске и исправлении ошибок в других компонентах. Правильность работы библиотек обычно определяется стандартами. Но большинство имеющихся стандартов, которые должны определять требования к реализациям математических функций, почти не содержат таких требований, ограничиваясь общими указаниями и апеллируя к широкой известности свойств этих функций. При попытке детализировать подразумеваемые требования оказывается, что 161
свойства реализаций функций существенно отличаются от свойств самих функций из-за использования чисел с плавающей точкой. В связи с этим актуальной является работа по определению четких требований к работе реализаций математических функций на основе чисел с плавающей точкой, а также разработка тестовых наборов для проверки соответствия этим требованиям. Этим двум вопросам и посвящена данная статья. Во втором разделе статьи производится обзор существующих стандартов для реализаций математических функций и существующих тестовых наборов. В третьем разделе проводится исследование свойств 4-х тригонометрических функций и на его основе строится тестовый набор для них. В четвертом разделе представлены результаты тестирования нескольких различных реализаций выбранных функций с помощью созданного набора.
2. Обзор стандартов и тестовых наборов Правильность работы реализаций математических функций определяется стандартами. Рассмотрим несколько наиболее распространенных стандартов для математических функций и требования, которые они предъявляют к работе их реализаций.
2.1. Существующие стандарты для математических функций Общепринятые базовые стандарты на вычисления с числами с плавающей точкой — это IEEE 754 [2] и IEEE 854 [3]. Они определяют представление чисел с плавающей точкой и основные операции над ними. Помимо обычных чисел, числа с плавающей точкой могут представлять положительную и отрицательную бесконечности (±∞), а также NaN («not-a-number» — «не число», приписываемое как результат действиям, у которых нельзя определить корректно ни конечный, ни бесконечный результат) и -0 (отрицательный ноль, используемый иногда в значении «очень маленькое по абсолютной величине отрицательное число»). Кроме того, обычные числа могут быть нормализованными (если их абсолютная величина достаточно велика, например, при двойной точности — не меньше 2-1022) или денормализованными (если их абсолютная величина меньше некоторого, своего для каждой точности, значения). Для получения представимых результатов при выполнении вычислений с числами с плавающей точкой эти стандарты предписывают использовать один из четырех режимов округления: к ближайшему числу, вверх, вниз и к нулю. Они также предписывают возвращать правильно округленный точный результат при выполнении арифметический действий (сложения, вычитания, умножения, деления), преобразовании типов, взятии остатка по модулю и извлечении квадратного корня. Про другие функции в этих стандартах ничего не сказано. 162
Стандарты библиотек языка C. В стандарте языка C ISO/IEC 9899 [4] и в стандарте переносимого интерфейса операционной системы IEEE 1003.1 [5] (известном как POSIX), описывающих библиотеку математических функций языка C, так же мало говорится о других функциях. Стандарт языка С ссылается на стандарт IEEE 754, добавляя лишь требования на поведение ряда функций в некоторых особых точках. Например, exp(0) = 1, а sin(0) = 0. Стандарт POSIX, в свою очередь, ссылается на требования стандарта языка С, добавляя лишь требования на выставление флагов в случае возникновения переполнения, слишком маленьких или слишком больших аргументах, а также на поведение функции при денормализованных аргументах, в нуле, в бесконечности и в NaN. К примеру, для функции синус POSIX требует, чтобы sin(x) = x при x = 0, -0, а также при денормализованных значениях x. Значение синуса для NaN, -∞ и +∞ должно быть NaN. Кроме того, указаны случаи выставления флага выхода за нормализованные значения (range error) и флага недопустимого аргумента (domain error). Других ограничений на синус не накладывается. Стандарты ISO/IEC 10967. В последние 5-10 лет появились предложения стандартизовать необходимые для аккуратного моделирования требования к реализациям математических функций [6,7]. Многие инициаторы этой деятельности работают в проекте Arenaire [8], совместно проводимом во Франции INRIA, CNRS и Высшей Нормальной школой Лиона. В результате появился набор стандартов ICO/IEC 10967 [9-11], формулирующий естественные ограничения на работу реализаций элементарных функций — корней, экспонент и логарифмов с различными основаниями, гиперболических и тригонометрических функций, а также обратных к ним. Эти ограничения касаются нескольких аспектов: точности вычислений, интервалов сохранения знака и монотонности, а также поведения функции в окрестности некоторых особых для данной функции точек (например, реализация экспоненты для значений аргументов, достаточно близких к 0, должна возвращать в точности 1). Эти стандарты на сегодняшний день являются наиболее полными и строгими, однако, к сожалению, они не используются на практике, поскольку не поддерживаются никем из основных производителей программных или аппаратных реализаций математических функций. Кроме того, набор стандартов ICO/IEC 10967 ничего не говорит о неэлементарных функциях, к которым относятся некоторые часто используемые библиотечные функции, например, гамма-функция и функции Бесселя.
2.2. Работы по тестированию реализаций математических функций Существует достаточно большое количество различных наборов тестов для тестирования функций над числами с плавающей точкой (см. например, [12]), 163
но подавляющее большинство таких тестов крайне несистематично и проверяет какой-то один аспект вычислений. Несмотря на то, что стандартизация вычислений над числами с плавающей точкой началась более 20 лет назад, проблема проверки соответствия реализаций стандартам до сих пор актуальна и тесты на правильность поведения реализаций математических функций по-прежнему необходимы. Среди наиболее систематичных работ по тестированию вычислений с плавающей точкой можно назвать следующие. Тестовый набор ELEFUNT [13] содержит тесты для нескольких математических функций в виде программ на C и Java. В этих тестах проверяется корректность возвращаемых значений для специальных значений аргументов (0, 1, +, -, NaN), а также для ряда генерируемых случайно значений аргументов проверяется выполнение некоторых тождеств, связанных с данной функцией (например, exp(x)·exp(-x) = 1). Тестовый набор UCBTEST [14] предназначен для тестирования базовых арифметических действий и достаточно широкого набора математических функций (тестируется больше функций, чем в ELEFUNT). Он оформлен как набор тестовых программ на Fortran и C и предопределенных входных данных для разных функций. В качестве тестовых данных, по-видимому, выбраны специальные значения аргумента и несколько случайным образом полученных значений. В целом, однако, в этом наборе используется больше данных и проверяется больше функций, чем в ELEFUNT. Использование в качестве тестовых данных специальных значений, границ интервалов, определяемых часто используемыми алгоритмами вычисления данной функции, а также чисел, построенных по некоторым шаблонам и случайных значений, применялось для построения более объемных тестовых наборов, например, набора Беркли [15]. Работы, выполнявшиеся в проекте Arenaire. Отдельно стоит отметить работы в рамках проекта Arenaire [16] по определению чисел, для которых корректное вычисление элементарных функций с заданной точностью наиболее трудоемко. На основе их результатов был разработан инструмент MPCheck [17] для тестирования правильности реализаций элементарных функций с точки зрения сохранения монотонности и корректности округления. В целом, имеющиеся в открытом доступе исследования, посвященные выработке требований к реализациям математических функций и тестированию на соответствие этим требованиям, не содержат систематического подхода к этим вопросам, объединяющего рассмотрение всех указанных проблем. Нигде, кроме работ группы Arenaire, не 164
рассматривается дилемма составителя таблиц (необходимость использовать вычисления повышенной точности для корректного округления) и значения аргументов, для которых вычисление корректных результатов функций наиболее трудоемко. В то же время, в работах группы Arenaire никак не фигурируют тестовые данных, основанные на границах интервалов, в которых заданная функция ведет себя однородным образом.
Специальные значения, значения в 0, касательные и асимптоты. o Бесконечности и -0. Нужно наиболее естественным образом определить значения функции для особых значений аргумента: -0, +∞, -∞. o Значение в NaN. Значение функции для аргумента NaN должно быть равно NaN. o Точные значения. В ряде точек значения функций должны вычисляться точно. Например, exp(0) = cos(0) = ch(0) = 1, sin(0) = sh(0) = tg(0) = arcsin(0) = 0, ln(1) = 0 и т.п. o Окрестности экстремумов, являющихся точными значениями. Если в такой точке производная функции равна 0, то для любого аргумента из некоторой ее окрестности реализация должна возвращать то же самое значение. o Окрестность 0. Функции, имеющие ненулевое значение в 0, тоже должны в некоторой окрестности 0 возвращать это же значение. o Горизонтальные асимптоты. В тех случаях, когда функция имеет горизонтальные асимптоты, необходимо аккуратно определить границы, после которых ее значение должно стать постоянным при определенном режиме округления. o Асимптотики. На интервалах, где основные асимптотики функций при правильном округлении превращаются в тождества, следует требовать соблюдения этих соотношений. Например, exp(x) ~ 1+x при x ~ 0 или sin(x) ~ x при x ~ 0.
Область значений функции. o Выбор ветви. Если математическая функция в строгом смысле является многозначной, должна быть четко определена ее ветвь, которая будет соответствовать реализации. o Сохранение ограничений области значений. Ограничения сверху или снизу на значения функции нужно соблюдать и в ее реализации, в противном случае возможны ложные нарушения непрерывности поведения при моделировании сложных систем. o Денормализованные значения. Необходимо аккуратно определить интервалы, на которых значения функции должны быть денормализованными.
Монотонность и сохранение знака. o Сохранение монотонности. На всех интервалах, где математическая функция монотонна, ее реализация должна иметь тот же вид монотонности.
3. Анализ требований к функциям и создание тестового набора 3.1. Методика определения требований Используемый метод определения требований к реализациям математических функций описан в статье В. Кулямина [1] и заимствует большую часть идей из стандарта ISO 10967 [9-11] и работ [6,7], посвященных разработке стандартов с повышенными требованиями к корректности вычисления математических функций. Требования к результатам реализации математической функции могут быть разделены на несколько аспектов. Область определения функции и особые точки функции. o Область определения. Во всех точках области определения, где значения функции лежат в интервале чисел с плавающей точкой, ее реализация должна возвращать соответствующим образом округленные значения. o Предельные значения. В точках, где функция не определена, но имеет предел в диапазоне чисел с плавающей точкой, реализация должна возвращать округленное значение этого предела. o Односторонние пределы в 0. Значения функции в точках 0, -0 определяются как односторонние пределы. Например, сtg(0) = +∞ и ctg(-0) = -∞. o Полная неопределенность. В точках, где функции нельзя осмысленно приписать ни конечного, ни бесконечного значения, ее значением считается NaN. Примеры таких ситуаций: sqrt(-1.0) = ln(-1.0) = NaN, sin(+∞) = NaN. o Окрестности полюсов. Необходимо точно определить окрестности полюсов, в которых значение функции выходит за интервал чисел с плавающей точкой. o Окрестности бесконечностей при бесконечных пределах. Для функций, стремящихся к бесконечности при x +∞ или x -∞, должны быть точно определены границы, за пределами которых их значения не представимы.
165
166
o
функций на базе чисел с плавающей точкой, нужно вычислить числа с плавающей точкой, приближающие подобные числа наилучшим образом. Это можно сделать с помощью одной и той же техники (упоминаемой, например, в [18,19]). Любое число с плавающей точкой, большее 1, может быть представлено как m·2k, где m — натуральное число, не превосходящее 253-1, а k — натуральное число, не превосходящее 971. Если такое число расположено очень близко к n·α, где α — иррациональное число, то α m·2k/n. Таким образом, можно искать эти числа с помощью наилучших рациональных приближений к α. Для этого числа вида α·2k при k от 52 до -971 раскладываются в непрерывные дроби, при обрыве которых в какомлибо месте получаются подходящие дроби, наилучшим образом приближающие исходные числа среди всех рациональных чисел, имеющих меньшие или такие же знаменатели [20].
Сохранение знака. Знак значения реализации функции для некоторого аргумента должен совпадать со знаком значения самой функции.
Симметрии и периодичность. o Четность и нечетность. Если математическая функция является четной или нечетной, этим же свойством должна обладать ее реализация. o Другие симметрии. Помимо четности и нечетности все другие симметрии функции должны быть проанализированы на предмет возможности их соблюдения для чисел с плавающей точкой. Например, соотношение Γ(1+x) = x·Γ(x) для гамма-функции может быть выполнено точно только для представимых целых чисел, для них оно и должно быть выполнено в любой реализации. Соотношения типа периодичности тригонометрических функций, или, например, sin(π-x) = sin(x), могут выполняться на числах с плавающей точкой только приближенно, поэтому не имеет смысла накладывать соответствующие ограничения.
Такие вычисления дают около 1000 кратных для каждого из чисел π/4, π/3, π/2 и π, которые приближаются числами с плавающей точкой двойной точности, с абсолютной погрешностью не больше, чем 2-52. Эти числа с плавающей точкой являются ближайшими к нулям, полюсам, максимумам, минимумам или к прообразам значений ±1 и ±1/2 для косинуса и тангенса. Поэтому они являются хорошими тестовыми значениями.
Корректное округление. Помимо всех перечисленных ограничений, нужно требовать, чтобы результат, возвращаемый реализацией, получался из точного результата функции для данного аргумента при помощи округления в соответствии с текущим режимом.
Например, так можно вычислить число двойной точности, ближайшее к нечетному кратному π/2 — 1.01101010110001011011001001100010110010100001111111112·2849. Поскольку нечетные кратные π/2 являются полюсами тангенса, вычислив его значение в этой точке, получаем максимальное по абсолютной величине его значение на числах двойной точности — 2.13348538575370393610·1018. Так как кратные π/2 являются нулями косинуса, его значение в этой точке дает минимальное по абсолютной величине значение косинуса на числах с плавающей точкой двойной точности вне окрестности нуля — 4.68716592425462669110·10-19.
3.2. Анализ требований для выбранных функций Для двух тригонометрических функций и двух обратных к ним — тангенса, косинуса, арктангенса и арккосинуса — анализ требований для дальнейшего построения тестового набора был проведен по описанной выше методике. При этом пришлось иметь дело со следующими их особенностями. Нули, полюса и прообразы специальных значений. Для определения интервалов сохранения знака важно вычислить нули и полюса функции. Для определения интервалов монотонности ту же роль играют максимумы и минимумы. Нули косинуса совпадают с полюсами тангенса и являются числами вида π/2+π·n. Максимумы и минимумы косинуса имеют вид 2π·n и (2n+1)·π. Кроме того, для проверки корректности вычисления тригонометрических функций можно использовать широко известные соотношения вида cos(±π/3+2π·n) = 1/2, cos(±5π/3+2π·n) = -1/2, tg(π/4+π·n) = 1 и tg(-π/4+π·n) = -1.
Во всех этих случаях фигурируют целые кратные иррациональных чисел π/3 или π/4. Чтобы определить накладываемые этими соотношениями ограничения на реализации тригонометрических 167
168
Асимптотики. Тангенс и арктангенс имеют хорошо известные асимптотики в нуле: tg(x) ~ x и arctg(x) ~ x при x ~ 0. Арктангенс имеет горизонтальные асимптоты на бесконечности: arctg(x) ~ π/2 при x ~ +∞ и arctg(x) ~ π/2 при x ~ -∞. Каждая из таких асимптотик определяет некоторые интервалы чисел с плавающей точкой, в которых она должна быть выполнена точно при режиме округления к ближайшему и либо точно, либо же с отступом на одно значение при других режимах («точное» равенство π/2 означает равенство числу с плавающей точкой, к которому π/2 округляется при заданном режиме).
Кроме того, поскольку в окрестности нуля числа с плавающей точкой расположены плотнее, чем в окрестностях других точек, любая функция, имеющая ненулевое значение в 0, должна принимать его же и в некоторой окрестности нуля. Это верно для косинуса и арккосинуса — первый в нуле имеет значение 1, второй — π/2. Границы соответствующих интервалов можно вычислить с помощью метода последовательных приближений. Например, для тангенса имеем tg(1.00100101000010111111111000011011000010000010111101002·2-26 = x1) = 1.0010010100001011111111100001101100001000001011110100 015001…2·2-26; tg(1.00100101000010111111111000011011000010000010111101012·2-26) = 1.0010010100001011111111100001101100001000001011110101 105210…2·2-26; tg(1.01110001001101110100010010010001001000111110111101012·2-26 = x2) = 1.0111000100110111010001001001000100100011111011110101 150011…2·2-26; tg(1.01110001001101110100010010010001001000111110111101102·2-26) = 1.0111000100110111010001001001000100100011111011110111 055100…2·2-26. Следующие из этих соотношений требования к значениям тангенса в окрестности 0 для всех режимов округления сформулированы в Таблице 1. В этой таблице функция next(x) для числа с плавающей точкой x обозначает непосредственно следующее за x число с плавающей точкой, а функция previous(x) — число, предшествующее x. Округление
к0
к -∞
к ближайшему
к +∞
Интервал/точка x = -next(x2)
Previous
previous(x)
(previous(x)) -next(x1) x -x2
previous(x)
0 > x -x1
previous (x)
x
previous(x) x
x=0
0
x1 x > 0 x2 x next(x1) x = next(x2)
x
x x
next(x) next(x)
next(x)
Next (next(x))
Таблица 1. Требования к поведению тангенса в окрестности 0. Аналогичные требования определяются и для других функций в тех интервалах, где их асимптотики превращаются в точные или почти точные равенства. 169
Симметрии. Тангенс и арктангенс являются нечетными функциями, а косинус — четной. Эти свойства учитываются при выборе тестовых значений и проверяются в тестах. Другие симметрии, в частности, периодичность, выполнены для чисел с плавающей точкой только приближенно и не накладывают строгих требований на реализации выбранных функций.
3.3. Выбор тестовых значений В качестве тестовых значений для всех функций выбирались специфические числа с плавающей точкой: 0, -0, +∞, -∞, NaN, минимальное и максимальное положительные денормализованные и нормализованные числа, противоположные им, а также вычисленные границы интервалов действия асимптотик для различных режимов округления. Были выбраны периоды тангенса и косинуса, содержащие хотя бы одну из упоминавшихся выше точек, близких к кратным π (включая 0), π/2, π/3 (для косинуса) и π/4 (для тангенса). Для каждого из выбранных периодов вычислены его левый и правый концы, а также точки, ближайшие на этом интервале к кратным π/2, π/3 (для косинуса) и π/4 (для тангенса). Эти точки разбивают каждый период на несколько интервалов. Всего таких точек меньше, чем 3000, поэтому получающийся набор тестовых данных будет одновременно достаточно представительным и обозримым. Полученные таким образом интервалы можно разбить далее, пользуясь техникой, описанной в статье [1] в разделе 4.2. А именно, разбивать каждый интервал на N более мелких интервалов, при этом получая (N+1) точку. Далее брать все числа, лежащие в рассматриваемом интервале и отстоящие не более чем на K чисел с плавающей точкой. Кроме того, к тестовым значениям добавлены числа, для которых вычисление корректно округленного значения функций наиболее трудоемко. Вот пример такого числа из [21] для косинуса. cos(1.10000000000000000000000000000000000000000000000010012·2-23) = 1.1111111111111111111111111111111111111111111101110000 089110…2·2-01 Для четных или нечетных функций для каждого полученного уже тестового значения в тестовый набор было добавлено противоположное значение. Значение косинуса для него должно быть таким же, а значение тангенса и котангенса вычисляются по-разному в зависимости от режима округления. При округлении к 0 или к ближайшему достаточно просто поменять знак значения нечетной функции, чтобы получить ее значение на противоположном аргументе. При режимах округления к ±∞ нужно менять и знак, и режим — значение нечетной функции при режиме округления к +∞ на противоположном аргументе получается сменой знака из ее значения на исходном аргументе при режиме округления к -∞, и наоборот. 170
4. Результаты тестирования
Косинус
Тестирование проводилось в рамках проекта OLVER с использованием технологии UniTESK. Были протестированы реализации 4-х тригонометрических функций (tan, cos, arctg, arcos) при четырех режимах округления (“к ближайшему”, “к +∞”, “к -∞” и “к нулю”) на следующих пяти платформах: 1. Glibc 2.3.4 (Red Hat 4.64 AMD64); 2. Glibc 2.3.6 (Debian 4 IA32); 3. Glibc 2.4 (SUSE 10.0 IA32); 4. Glibc 2.4 (SUSE 10.0 Itanium); 5. MS Visual C++ RunTime Library (Windows XP IA32).
4.2. Классификация ошибок Для анализа ошибок числа с плавающей точкой были разделены на 5 классов: NaN, ±∞, ±0, нормализованные числа и денормализованные числа. При сборе статистики использовалась следующая классификация ошибок.
“Грубые ошибки” фиксировались, если полученный и правильный результаты лежали в разных классах по приведенной классификации. “Нарушение знака” — полученный результат имеет неправильный знак. “Очень неточный результат” — все 53 бита полученного результата отличаются от соответствующих бит в правильном результате. “Не очень точный результат” — количество неправильных бит в полученном результате меньше 53.
Glibс 2.3.6 (IA32) Glibс 2.4 (IA32) MSVCRT(Windows) Glibc 2.3.4 (AMD64) Glibc 2.4 (Itanium) Glibс 2.3.6 (IA32) Glibс 2.4 (IA32) MSVСRT(Windows) Glibc 2.3.4 (AMD64) Glibc 2.4 (Itanium)
5772 5772 5708 3015 3015
11336 11336 11340 3926 3934
1006 1006 1006 14431 14423
0 0 0 0 0
3914 3914 0 3968 3968
1792 1792 0 1752 1752
6324 6324 5 6310 6310
4010 4010 16035 4010 4010
0 0 0 0 0
0 0 0 0 0
0 0 0 0 0
0 0 0 0 0
1116 1116 1116 1116 1116
Грубых ошибок ни на одной из платформ зафиксировано не было. Арккосинус во всех протестированных реализациях вычисляется достаточно точно, поскольку наиболее прост для вычисления из рассматриваемых функций. 60 50 40 30 20
В Таблице 2 приведена общая статистика ошибок, обнаруженных при выполнении построенных тестов при режиме округления к ближайшему. Функция/ Грубые НаруОчень Не очень Абсолютно Платформа ошибки шение неточный точный точный знака результат результат результат Тангенс 9305 9305 9337 5010 5010
2691 2691 2700 1445 1445
Таблица 2. Общая статистика обнаруженных ошибок.
4.3. Анализ результатов тестирования
0 0 0 0 0
10128 10128 10115 5359 5359
Арккосинус
Если полученный результат совпадал с правильным (совпадал знак, экспонента и все биты мантиссы), то никакой ошибки не фиксировалось, и результат считался “абсолютно точным”.
Glibс 2.3.6 (IA32) Glibс 2.4 (IA32) MSVCRT(Windows) Glibc 2.3.4 (AMD64) Glibc 2.4 (Itanium)
0 0 0 0 0
Арктангенс
Средняя ошибка
4.1. Тестовые платформы
Glibс 2.3.6 (IA32) Glibс 2.4 (IA32) MSVCRT(Windows) Glibc 2.3.4 (AMD64) Glibc 2.4 (Itanium)
7324 7324 7356 1829 1832
10 0 0
599 599 599 13146 13143
100
200
300
400 500 600 экспонента аргумента
Рис. 1. Средняя величина ошибки (в количестве неправильных знаков результата) при вычислении тангенса в зависимости от экспоненты аргумента (IA32). 171
172
Средняя ошибка
Тангенс и косинус вычисляются с заметным количеством ошибок, в основном связанных с корректной редукцией аргумента — аккуратным приведением аргумента в интервал от 0 до π/2 [19]. Дело в том, что для правильного приведения в этот интервал больших по абсолютной величине значений, необходимо хранить много дополнительных знаков числа π, что, повидимому, не делается ни в одной из проверенных реализаций. Величина ошибок начинает возрастать при некотором удалении от нуля (там, где используемого представления π становится недостаточно для корректной редукции аргумента), причем на 64-разрядных платформах это происходит гораздо позже, чем на 32-разрядных (см. Рис. 1 и 2).
Средняя ошибка
60 50 40 30 20
60
10
50
0 0
200
400
600
40
800 1000 экспонента аргумента
Рис. 3. Средняя величина ошибки (в количестве неправильных знаков результата) при вычислении косинуса в зависимости от экспоненты аргумента (AMD64, режим округления к 0).
30 20
600
10
N 500
0 0
100
200
300
400 500 600 экспонента аргумента
400
Рис. 2. Средняя величина ошибки (в количестве неправильных знаков результата) при вычислении тангенса в зависимости от экспоненты аргумента (AMD64).
300
200
На 32-битных платформах тангенс вычисляется неправильно для чисел, больших 264, на 64-битных платформах соответствующая граница расположена около 2500. Для тангенса картина, показанная на Рис. 1 и 2, примерно сохраняется при всех режимах округления. Для косинуса она такая же при режиме округления к ближайшему, но изменяется при других режимах (см. Ри). Здесь видно влияние других факторов, не связанных с редукцией аргумента.
100
0 0
10 Все точки
20 cos ~1
cos ~0
30 cos ~1/2
40
50
кол-во неправильных бит
Рис. 4. Распределение величины ошибки для косинуса в точках разных типов (IA32). Другая особенность ошибок, обнаруженных при тестировании реализаций тангенса и косинуса на 32-битных платформах, связана с некорректным
173
174
вычислением значений тангенса в точках, близких к его полюсам или нулям, отличным от 0, а также косинуса в точках, близких к его нулям. В обоих случаях ошибки практически для всех таких точек превышают 35-40 бит (т.е. результаты имеют столько неправильных знаков) — см. Рис. 4. Это также, скорее всего, связано с проблемой корректной редукции аргумента, поскольку для правильного вычисления функций в окрестностях их нулей и полюсов редукция аргумента должна быть более точной. Однако для 64-битных платформ этой особенности нет — во всех таких точках тангенс и косинус на них вычисляются правильно. 600
N 500 400 300 200
Использованный метод продемонстрировал хорошие результаты, позволив при помощи небольшого числа тестов обнаружить серьезные ошибки в широко используемых реализациях тригонометрических функций. Большинство найденных ошибок связано с проблемой корректной редукции аргумента тригонометрических функций [19]. Обнаруженные в реализации арктангенса в библиотеке Glibc серьезные ошибки имеют непонятную природу, поскольку возникают в окрестности нуля или на очень больших числах, где арктангенс имеет достаточно хорошие асимптотики, позволяющие вычислять его точно без больших усилий. Вместе с тем для более серьезной проверки корректности вычисления математических функций необходимо расширить набор тестовых точек, где корректное округление результата функции требует повышенной точности вычислений. В работах группы Arienaire [16,21] для каждой функции приводится лишь несколько таких точек, вычисленных с помощью оптимизированных переборных алгоритмов. Для пополнения тестов такими значениями на систематической основе необходимы техники, которые позволят вычислять их гораздо эффективнее. Литература
100 0 0
10 Все точки
20 x ~inf
30 x ~0
x ~1
40
50
кол-во неправильных бит
Рис. 5. Распределение величины ошибки для арктангенса (Glibc). Самая большая неожиданность — значительные ошибки при вычислении арктангенса в реализации библиотеки Glibc на всех платформах. Реализация этой функции от Microsoft работает значительно более корректно — обнаружено лишь 5 небольших ошибок. Полное недоумение вызывают как ошибки на больших по абсолютной величине аргументах (превосходящих 230), где график арктангенса превращается в горизонтальные прямые, так и ошибки, связанные с нарушением знака результата (знак значения арктангенса всегда должен совпадать со знаком аргумента). Рис. 5 показывает распределение величины ошибки вычисления арктангенса в библиотеке Glibc в зависимости от типа тестовых значений.
5. Заключение В данной статье представлены результаты работы по созданию тестового набора на основе метода, предложенного в [1] для тестирования реализаций 4-х математических функций — тангенса, арктангенса, косинуса и арккосинуса. 175
[1] В. Кулямин. Формальные подходы к тестированию математических функций. Труды ИСП РАН, 10:69–114, 2006. [2] IEEE 754-1985. IEEE Standard for Binary Floating-Point Arithmetic. NY: IEEE, 1985. [3] IEEE 854-1987. IEEE Standard for Radix-Independent Floating-Point Arithmetic. NY: IEEE, 1987. [4] ISO/IEC 9899:1999. Programming Languages — C. Geneve: ISO, 1999. [5] IEEE 1003.1-2004. Information Technology — Portable Operating System Interface (POSIX). NY: IEEE, 2004. [6] G. Hanrot, V. Lefevre, J.-M. Muller, N. Revol, and P. Zimmermann. Some Notes for a Proposal for Elementary Function Implementation in Floating-Point Arithmetic. Proc. of Workshop IEEE 754R and Arithmetic Standardization, in ARITH-15, June 2001. [7] D. Defour, G. Hanrot, V. Lefevre, J.-M. Muller, N. Revol, and P. Zimmermann. Proposal for a standardization of mathematical function implementation in floating-point arithmetic. Numerical Algorithms, 37(1–4):367–375, December 2004. [8] http://www.inria.fr/recherche/equipes/arenaire.en.html [9] ISO/IEC 10967-1:1994. Information Technology — Language Independent Arithmetic — Part 1: Integer and Floating Point Arithmetic. Geneve: ISO, 1994. [10] ISO/IEC 10967-2:2002. Information Technology — Language Independent Arithmetic — Part 2: Elementary Numerical Functions. Geneve: ISO, 2002. [11] ISO/IEC 10967-3. Information Technology — Language Independent Arithmetic — Part 3: Complex Integer and Floating Arithmetic and Complex Elementary Numerical Functions. Draft. Geneve: ISO, 2002. [12] http://www.math.utah.edu/~beebe/software/ieee/ [13] http://www.math.utah.edu/pub/elefunt/ [14] http://www.netlib.org/fp/ucbtest.tgz
176
[15] Z. A. Liu. Berkeley Elementary Function Test Suite. M.S. thesis, Computer Science Division, Dept. of Electrical Engineering and Computer Science, University of California at Berkeley, December 1987. [16] D. Stehle, V. Lefevre, P. Zimmermann. Searching Worst Cases of a One-Variable Function Using Lattice Reduction. IEEE Transactions on Computers, 54(3):340–346, March 2005. [17] http://www.loria.fr/~zimmerma/mpcheck/ [18] W. Kahan. Minimizing q*m–n. 1983. Неопубликованные заметки, доступны по http://http.cs.berkeley.edu/~wkahan/testpi/nearpi.c. [19] K. C. Ng. Arguments Reduction for Huge Arguments: Good to the Last Bit. 1992. Доступна как http://www.validlab.com/arg.pdf. [20] А. Я. Хинчин. Цепные дроби. М: Наука, 1978. [21] V. Lefevre, J.-M. Muller. Worst Cases for Correct Rounding of the Elementary Functions in Double Precision. Proc. of 15-th IEEE Symposium on Computer Arithmetic, Vail, Colorado, USA, June 2001.
177
