ACATS - комплект тестов для сертификации Ада-компиляторов

Данный документ является неформальным переводом:
   "The Ada Conformity Assesment Test Suite (ACATS) Version 2.5 User's Guide"

Copyright (C) 2003 А.Гавва.
Коммерческое распространение, без разрешения автора, запрещено.

Введение

Общие сведения

ACATS (Ada Conformity Test Suite) является официальным комплектом тестов, который используется для сертификации Ада-компиляторов на соответствие реализации Ада-системы требованиям стандарта (ANSI/ISO/IEC 8652:1995). Поставка ACATS включает в себя руководство пользователя, тестовые программы и пакеты поддержки.

ACATS является важной составной частью процесса сертификации реализации Ада-системы, который описывается в "ISO/IEC-18009, Ada: Conformity fo a Language Processor [ISO99]. Этот стандарт предопределяет среду тестирования языковых процессоров, предусматривая стабильную и воспроизводимую основу для тестирования. С октября 1998 года процесс сертификации финансирует Ada Resource Association, при этом управление процессом сертификации осуществляет Ada Conformity Assessment Authority (ACAA).

До выхода в свет стандарта ISO финансирование подобного процесса сертификации осуществлялось Министерством Обороны США (U.S. Department of Defense), а непосредственное управление процессом осуществлялось через Ada Joint Programm Office (AJPO). Комплект тестов AJPO известен под названием "Ada Compiler Validation Capability" (ACVC). Версии этого комплекта тестов разрабатывались с учетом требований стандартов ANSI/MIL-STD-1815A-1983, ISO/8652:1987 (Ada 83), которые нумеровались 1.X, где X находится в диапазоне от 1 до 11. Позже AJPO разрабатывал версии комплекта тестов ACVC, которые основывались на стандартах ANSI/ISO/IEC 8652:1995 (Ada 95). Эти версии нумеровались: 2.0, 2.0.1, 2.1 и 2.2.

Когда управление процессом сертификации перешло к ACAA, за основу был взят комплект тестов ACVC. Кроме того, во избежание конфликтов и разночтений, было принято решение об использовании той же схемы нумерации версий комплекта тестов. В настоящее время, текущей версией комплекта тестов ACVC является версия 2.1. Эта версия была взята за основу и использована как ACATS 2.1. Более поздняя, уже разработанная, но не опубликованная версия ACVC 2.2 была опубликована и использована как ACATS 2.2. Далее ACAA последовательно опубликовывает версии 2.3 и 2.4, включая сопроводительные изменения и несколько новых тестов.

В настоящее время, текущей версией комплекта тестов ACATS является версия 2.5. Эта версия, также как и версии 2.3 и 2.4, была разработана под управлением ACAA, и она содержит тестовые программы для проверки новых языковых возможностей, которые определены в [Ada 95], а также тестовые программы для проверки языковых возможностей, которые используются как в [Ada 95] так и в [Ada 83]. Нумерация последующих сопроводительных или расширенных версий комплекта тестов, если они потребуются, будет основана на 2.5.

Комплект тестов ACATS (и вся сопроводительная документация) может быть получен в любой из лабораторий "Ada Conformity Assessment Laboratories" или в "Ada Information Clearinghouse" (финансируется ARA). Более подробная информация может быть получена с сайта: http://www.adaic.org.

Суть целевого предназначения ACATS

Целью комплекта тестов ACATS является проверка соответствия реализации системы компиляции Ады требованиям стандарта, то есть, проверка того, что реализация предоставляет допустимые результаты для каждого теста.

Фундаментальной задачей сертификации является способствование переносимости программного обеспечения написанного на языке программирования Ада, путем гарантирования однозначной обработки свойств языка Ада в соответствии с описанием [Ada 95]. Тесты ACATS используют языковые средства в контекстах и идиомах, которые ожидаются в производном программном обеспечении. Хотя эти тесты отображают широкое использование языковых средств, они не включают и не могут включать примеры использования всех допустимых средств языка и их совместное взаимодействие.

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

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

Сведения по конфигурированию тестов ACATS

Рассмотрим физическую и логическую структуру поставки тестов ACATS 2.5, то есть классы тестов, используемые соглашения по наименованию, формат тестовой программы, структуру теста, структуру поставки и форматы файлов.

ACATS 2.5 является результатом переработки ACATS 2.4 и имеет такую же структуру поставки. По существу, средства поддержки не подверглись изменениям, за исключением обновления заголовков комментариев и идентификаторов версии.

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

Структура

Программное обеспечение ACATS 2.5 содержит:

Комплект тестов ACATS состоит из тестов проверки основных свойств языка (Core Tests) и из тестов проверки свойств специализированных дополнений языка (Specialized Needs Annexes / SNA Tests). Следующая таблица обобщает состав тестов и файлов комплекта ACATS:

Физическая организация

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

Следует заметить, что число файлов, которые содержат код тестов, больше числа тестов ACATS. Это вызвано тем, что некоторые тесты используют код, который содержится в отдельных файлах.

Имена файлов состоят из, собственно, имен файлов и расширений. Файлы, которые содержат код используемый одним тестом, имеют похожие имена. По возможности, имена файлов соответствуют именам тестов, которые в них содержатся. Следует звметить, что используемые имена файлов могут быть короче названий содержащегося в них программного обеспечения поскольку имена файлов соответствуют соглашениям принятым в MS-DOS (например, enumchek вместо enumcheck). Принято соглашение, согласно которого имена файлов (и тестов) индицируют функцию соответствующего файла (и/или теста) в комплекте ACATS (принятые соглашения по наименованию будут рассмотрены более подробно позднее). В соответствии с функциональным назначением, файлы располагаются в отдельных каталогах и подкаталогах.

Поставка ACATS может быть получена в ACAL или через Internet. Ссылки на поставку комплекта тестов ACATS можно обнаружить на страничке ACAA ACATS:

Следует также заметить, что файлы ACATS доступны в виде упакованных архивов для систем DOS и UNIX.

Логическая организация

Показанная ранее таблица демонстрирует наличие тестов для проверки реализации Ада-системы на соответствие основным свойствам языка (Core Tests) и на соответствие свойствам специализированных дополнений (SNA Tests).

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

В общем, комплект тестов ACATS построен таким образом, что результаты какого-либо одного теста не зависят от обработки или результатов какого-либо друглго теста. Исключения из этого правила будут рассмотрены позже. Таким образом, ни один тест свойств какого-либо одного специализированного дополнения не зависит от реализации какого-либо другого специализированного дополнения, за исключением случаев, когда реализация одного специализированного дополнения непосредственно зависит от реализации другого специализированного дополнения (например, тесты соответствия требованиям специализированного дополнения для информационных систем (Information Processing Annex) не используют никаких свойств, которые определяются в других специализированных дополнениях; однако, тесты специализированных дополнений для систем реального времени (Real Time Annex) и систем распределенных вычислений (Distributed System Annex) могут зависеть от реализации свойств специализированного дополнения для системного программирования (System Programming Annex)).

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

В дополнение к коду тестов и базовому коду существует код от которого зависят многие или все выполняемые тесты ACATS (например, такими пакетами являются Report, ImpDef, TCTouch). Часть этого кода должна быть адаптирована под соответствующую реализацию Ада-системы. Кроме того, существует код, который должен использоваться для построения средств поддержки, применяемых для адаптации комплекта тестов ACATS для проверки соответствующей реализации Ада-системы (более подробно процесс адаптации будет рассмотрен далее).

Унаследованные тесты (legacy tests)

Множество тестов осуществляет проверку свойств, которые характерны как для Ada-83, так и для ada. Большинство таких тестов неизменно портированы из комплекта тестов ACVC 1.12. Некоторые тесты были модифицированы для корректной проверки реализации правил ada (когда правила языка претерпели изменения по сравнению с правилами Ada-83).

Базовый код (foundation code)

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

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

Специальные тесты ядра (special core tests)

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

Требования специализированного дополнения C (Annex C)

Секция 13 [ada] содержит параграфы реализационных рекомендаций. ACATS не требует от какой-либо реализации Ада-системы соответствие рекомендациям указанным в этих параграфах, когда Ада-система не декларирует поддержку специализированного дополнения C - "Специализированные Дополнения для Системного Программирования" (Annex C "System Programming").

Ниже перечислены тесты, которые проверяют соответствие этим рекомендациям:

Реализация Ада-системы, которая декларирует поддержку специализированного дополнения C - "Специализированные Дополнения для Системного Программирования" (Annex C "System Programming"), должна подвергнуться проверке этими тестами.

Реализации Ада-систем, которые не декларирует поддержку для соответствующих специализированных дополнений также должны подвергаться проверке этими тестами. Такие реализации могут отвергать строки отмеченные специальным комментарием "-- ANX-C RQMT", указывая, что тест не поддерживается. Если реализация принимает такие строки в одном из таких тестов, то тест должен быть скомпилирован, скомпонован и выполнен (при этом, допускается как успешный, так и не приемлемый результат выполнения теста).

Код других языков программирования (foreign language code)

Некоторые тесты свойств специализированного дополнения B - "Интерфейс с Другими Языками" (Annex B: Interface to Other Languages) включают файлы, которые не Ада-код (Фортран, Си, Кобол). Эти тесты должны быть скомпилированы, скомпонованы и выполнены реализациями, которые поддерживают интерфейсы с соответствующими языками. Код других языков программирования в большинстве случаев использует только базовую семантику языка и должен быть совместим со всеми соответствующими компиляторами Фортрана, Си, Кобола. В случаях, когда компилятор другого языка программирования отвергает предусмотренный код, допускается модификация этого кода.

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

Тесты CXB5004 и CBX5005 содержат фортран-код.

Тесты CXB3004, CBX3006, CBX3013 и CD30005 содержат си-код.

Тест CXB4009 содержит кобол-код.

Классы тестов

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

Тесты класса A

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

Считается, что реализация Ада-системы прошла успешную проверку тестом класса A, когда тест был успешно скомпилирован, скомпонован и выполнен с получением отчета "PASSED". Любое другое поведение проверяемой Ада-системы рассматривается как ошибочное.

Тесты класса B

Тесты класса B осуществляют проверку способности распознавания недопустимых языковых конструкций, которые должны трактоваться как ошибки. Предполагается, что эти тесты не должны быть успешно скомпилированы, скомпонованы или выполнены. Строки, которые содержат ошибки, отмечены комментарием "-- ERROR:" и содержат краткое описание недопустимости (ошибки) в этой же или последующей строке (поскольку комментарий-индикатор содержит завершающий символ ':', программа поиска может легко отличить его от слова "error" в тестовом коде или документации). Кроме того, некоторые тесты отмечены строками "-- OK", которые индицируют, что строка не должна быть индицирована как ошибка. Отмеченные таким образом строки, часто, но не всегда, указывают конструкции, которые были ошибочными для Ada-83, но являются корректными в ada.

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

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

Тесты класса C

Тесты класса C осуществляют проверку корректности реализации выполняемых конструкций и того, что эти конструкции обладают предопределенным поведением. Предполагается, что эти тесты успешно компилируются, компонуются и выполняются с выдачей отчета "PASSED" или "NOT APPLICABLE". Каждый отчет тестов класса C: "PASSED", "NOT APPLICABLE" или "FAILED", - основывается на результатах проверки тестируемых условий.

Считается, что реализация Ада-системы прошла успешную проверку тестом класса C, когда тест был успешно скомпилирован, скомпонован и выполнен с получением отчета "PASSED". Тест считается не пройденым когда он не был успешно скомпилирован, скомпонован или выполнен (зависание или разрушение); когда в результате выполнения теста получен отчет "FAILED" или не полный отчет.

Тесты CZ1101A, CZ1102A, CZ1103A и CZ00004 имеют самостоятельную трактовку и будут рассмотрены позже.

Тесты класса D

Тесты класса D осуществляют проверку корректности арифметики на больших литеральных числах. Предполагается, что эти тесты успешно компилируются, компонуются и выполняются с выдачей отчета "PASSED". Каждый отчет тестов класса D: "PASSED" или "FAILED", - основывается на результатах проверки тестируемых условий. Некоторые реализации могут выдавать ошибки компиляции когда литеральное число превышает пределы компилятора.

Считается, что реализация Ада-системы прошла успешную проверку тестом класса D, когда тест был успешно скомпилирован, скомпонован и выполнен с получением отчета "PASSED". Кроме того, считается, что реализация Ада-системы прошла успешную проверку тестом класса D, когда компилятор выдает соответствующее сообщение об ошибке компиляции, если литеральное число превышает лимиты компилятора. Тест считается не пройденым, когда не был получен отчет "PASSED" если литеральное число не превышает лимиты компилятора; когда тест не был успешно скомпилирован, скомпонован или выполнен (зависание или разрушение); а также когда в результате выполнения теста получен отчет "FAILED", не полный отчет или отчет отсутствует.

Класс D содержит только унаследованные тесты (legacy tests).

Тесты класса E

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

Считается, что реализация Ада-системы прошла успешную проверку тестом класса E, когда был получен отчет "TENTATIVELY PASSED", и отмеченные в тесте специальные условия удовлетворены. Проверка также считается успешной, когда Ада-система выдает ошибку компиляции, которая удовлетворяет специальные условия. Тест класса E считается не пройденым, когда содержащееся в тесте специальное условие классификации не удовлетворено, когда тест не может быть успешно выполнен (зависание или разрушение), когда результатом отчета теста является "FAILED", а также когда тест выдает не полный отчет или отчет отсутствует.

Класс E содержит только унаследованные тесты (legacy tests).

Тесты класса L

Тесты класса L осуществляют проверку того, что зависимости всех библиотечных модулей программы удовлетворены до того как программа скомпонована или запущена на выполнение, обнаружены все случаи межмодульных кольцевых ссылок, а также, что программа, которая в целом является самостоятельным разделом, обработана корректно. Предполагается, что эти тесты будут успешно компилироваться, но не будут компоноваться или выполняться. Некоторые реализации Ада-систем могут выдавать сообщения об ошибках во время компиляции. Потенциально недопустимые конструкции отмечены с помощью комментария "-- ERROR:". Некоторые тесты класса L индицируют места в которых предполагаются ошибки связывания/компоновки. Успешная обработка не требует, чтобы сообщения об ошибках, выдаваемые редактором связей (компоновщиком), имели строгое совпадение с подобными индикаторами.

Считается, что реализация Ада-системы прошла успешную проверку тестом класса L, когда отсутствует успешное завершение фазы связывания/компоновки. Также считается, что реализация Ада-системы прошла успешную проверку, когда она обнаруживает ошибку и выдает соответствующее сообщение во время компиляции. Реализация не проходит проверку, когда она успешно завершает связывание/компоновку теста класса L и/или начала его выполнение.

Как и в случае с тестами класса B, разработчики тестов определили, что некоторые конструкции могут генерировать или не генерировать сообщения об ошибках, и что такое поведение системы будет приемлемым. Подобные строки отмечены с помощью комментария "-- OPTIONAL ERROR:". В таких случаях, для реализации Ада-системы допускается как выдача сообщения об ошибке, так и отсутствие выдачи сообщения об ошибке. Если сообщение об ошибке выдается во время компиляции, то не должен осуществляться запуск редактора связей (компоновщика). Когда ошибка не была обнаружена во время компиляции, должен осуществляться запуск редактора связей (компоновщика), а фаза связывания/компоновки не должна иметь успешного завершения (как индикатор о невозможности начала выполнения).

Базовый код (Foundation Code)

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

Тесты специализированных дополнений
(Specialized Needs Annex Tests или SNA Tests)

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

Соглашения по наименованию

Рассмотрим соглашения по наименованию, которые используются в ACATS 2.5 для именования файлов. Все имена файлов имеют вид <name>.<type>, где <type> является одно- двух- или трехсимвольным расширением имени файла. Имя файла индицирует класс теста, порядок компиляции (если требуется), а также то, что тест является зависимым от реализации или нуждается в адаптации (настройке). Когда весь тест помещается в одном файле, <name> деблирует имя теста. То же самое верно для базового кода. В тестах, состоящих из множества файлов, первые 7 символов имени файла совпадают с первыми символами имени теста, однако, в некоторых случаях, структура теста требует, чтобы имя файла отличалось от имени Ада-модуля.

В ACATS 2.5 существует две различных, но похожих, схемы соглашений по наименованию тестов. Унаследованные тесты используют схему наименований, которая использовалась в ранних версиях ACVC. Новые тесты, появившиеся после ACVC 1.12, используют новые соглашения по наименованию. Используемую схему соглашения можно распознать по седьмому символу имени: седьмым символом унаследованного имени будет буква, а у нового имени - цифра.

Унаследованное именование

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

В многофайловых тестах, необходимый порядок последовательности компиляции указывается в позиции 8. Файл, который должен быть скомпилирован первым, будет иметь в этой позиции '0', второй компилируемый файл - '1', и т.д.

Номера глав и секций в "ACVC Implementer Guide" соответствуют номерам глав и секций в [Ada83].

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

Все расширения имен файлов состоят из трех символов. Существуют следующие расширения имен файлов:

Тесты, которые были разработаны после ACVС 1.12 используют другие расширения имен файлов.

Именование в ACATS 2.5

Имя теста Ada95 состоит из семи или восьми символов. Базовый код (Foundation Code) обладает именами, состоящими из семи символов. Каждая символьная позиция имеет специальное смысловое значение, которое описывается в таблице показанной ниже. Первый столбец таблицы указывает порядковый номер позиции символа (отсчет ведется слева направо), второй столбец указывает вид допустимого символа (буква, цифра...), а третий столбец содержит описание соответствующего смыслового значения.

Все расширения имен файлов состоят из одного, двух или трех символов. Существуют следующие расширения имен файлов:

Любой тест, который зависит от базового кода содержит буквенный символ в пятой позиции своего имени. Имя требуемого базового кода будет содержать в позициях 2-5 такие же символы как и имя зависимого теста. Например, тест C123Axx зависит от базового кода F123A00.

Тесты состоящие из множества файлов

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

Для всех тестов поддерживается соглашение: головная подпрограмма именуется также как и файл ее содержащий (исключая расширение имени файла) плюс буква 'm' (только для унаследованных тестов). Например, унаследованный тест C39006F содержится в четырех файлах с именами: c39006f0.ada, c39006f1.ada, c39006f2.ada и c39006f3.ada. Головная подпрограмма этого теста содержится в файле c39006f3.ada и именуется "C39006F3M". Тест C390006 также содержится в четырех файлах. Эти файлы именуются: c3900060.a, c3900061.a, c3900062.a и c3900063.am. Головная подпрограмма этого теста содержится в файле c3900063.am и именуется "C3900063".

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

Формат тест-программы

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

Общий формат пролога следующий:



<имя файла>       - Поставочное имя файла содержащего пролог.

DISCLAMER        - Ограничения по использованию ACATS тестов.
                   Включается во все тесты.

OBJECTIVE        - Предложение описывающее целевое предназначение теста.
                   Включается во все тесты.

TEST DESCRIPTION - Краткое описание дизайна или стратегии теста,
                   или другая соответствующая информация.
                   Включается во все новые тесты, но присутствует не во всех
                   унаследованных тестах.

SPECIAL REQUIREMENT - не обязательно - Присутствует, когда тест обладает
                   какими-либо специальными требованиями обработки.
                   Обычно, эта секция присутствует только в тестах для
                   Специализированных Дополнений.
                   Например, какой-либо тест дополнения E может проверять
                   корректность реализации разделов. Таким образом, требования
                   для проверки разделения распределенной программы на разделы
                   и описание использования головных подпрограмм для каждого
                   раздела будет документироваться в этой секции.

TEST FILES       - не обязательно - Присутствует, когда тест зависит
                   от множества файлов; идентифицирует компонентные файлы тестов
                   состоящих из множества файлов.

APPLICABILITY CRITERIA - не обязательно - Определяет условия при которых
                   тест может быть признан как неприемлемый (inapplicable).

PASS/FAIL CRITERIA - не обязательно - Объясняет как интерпретировать компиляцию,
                   связывание/компоновку и/или результаты времени выполнения
                   для оценивания результатов проверки.

MACRO SUBSTITUTIONS - не обязательно - Идентифицирует макро-символы файла, которые
                   должны быть заменены в результате макро-подстановки,
                   и предусматривает краткое описание осуществляемой
                   макро-подстановки.

CHANGE HISTORY   - История тестового файла.
                   Включается во все тесты.

Все тесты обладают строкой, расположенной после DISCLAMER, которая маркирована как "--*". Новые тесты обладают строкой, расположенной после последней строки пролога (перед первой строкой исполняемого кода), которая маркирована как "--!". Другие комментарии не маркируются в соответствии с этими соглашениями, и, таким образом, первая строка после DISCLAMER и первая строка кода могут быть быстро найдены в любом текстовом редакторе.

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

Общие стандарты

Тесты ACATS были разработаны в соответствии с общим множеством стандартов. При написании тестов, разработчики руководствовались общим набором стандартов (не всегда буквально) с целью демонстрации использования различных стилей кодирования и идиом. Для облегчения электронной поставки тестов максимальная длина строки не превышает 79 символов (за исключением специальных требований тестирования; обычно, в файлах .dep и .tst) Как правило, длина теста находится в пределах 120 исполняемых строк. Такой дизайн позволяет максимально сфокусировать внимание на целевом предназначении теста, а также повысить читабельность и улучшить сопровождаемость теста. Иногда, сложное целевое предназначение проверки разделяется на подмножества, чтобы достичь максимального охвата всех задач проверки в понятных и хорошо сопровождаемых тестах. Некоторые тесты способны проверять наборы подмножеств целевого предназначения; в других случаях подмножества общего целевого предназначения проверяются отдельными тестами.

Унаследованные тесты используют только базовый 55-символьный набор символов (26 заглавных букв английского алфавита, 10 цифр и 19 символов пунктуации). Исключая специфические требования тестирования, численные значения находятся в диапазоне (-2048..2047), который может быть представлен с помощью 12 битов. В общем, численные значения находятся в диапазоне (-128..127). Новые тесты ACATS 2.x используют символы верхнего и нижнего реристра, а также могут использовать бОльшие численные значения (оставаясь, однако, за исключением, в диапазоне (-65536..65535)).

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

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

Новые исполняемые тесты предусматривают некоторое визуальное разделение тестовых элементов, которые сфокусированы на проверке соответствия, от тестовых элементов, которые управляют последовательностью выполнения теста. Например, часто необходима установка предварительных условий тестирования и проверка пост-условий результата, после выполненной секции тест-кода. Чтобы различить конструкции (типы, объекты...), которые являются частью тест-кода, от конструкций, которые являются предметом процесса проверки (например, пре- пост- условия), последние используют в именах идентификаторов префикс "TC_". Этот префикс является сокращением от "Test Control".

Структура теста

Общий формат исполняемых тестов (тесты класса A, C, D и E) имеет следующий вид:

    

with Report;
procedure Testname is
    < описания и определения >
begin
    Report.Test ("Testname", "Description ...");
    ...
    < контрольная ситуация выдающая результат проверки >
    if Post_Condition /= Correct_Value then
        Report.Failed ("Reason");
    end if;
    ...
    Report.Result;
end Testname;

Начальный вызов Report.Test, используя Text_IO, распечатывает целевое предназначение теста. Обычно, после каждой секции тест-кода присутствует секция проверки пост-условий. Такой проверкой, в показанном выше шаблоне теста, является инструкция if. В случае, когда в результате проверки получен непредвиденный результат, осуществляется вызов Report.Failed. Последовательности "тест-код"/"проверка результатов" могут повторяться в одном тесте несколько раз. В заключение, вызов Report.Result распечатывает результат проверки на выход Text_IO. Часто, но не всегда, такая структура помещается в блок declare.

Вызов Report.Failed (один или более) выдаст отчет "FAILED" и краткое объяснение смысла получения такого результата.

Более сложные тесты могут включать вызов Report.Failed в код, который не принадлежит головной процедуре теста. Подобные тесты имеют следующий формат головной процедуры:

    

with Report;
procedure Testname is
    < описания и определения >
begin
    Report.Test ("Testname", "Description ...");
    ...
    Subtest_Call;
    ...
    Report.Result;
end Testname;

Обнаружение ошибочных условий осуществляется в подпрограммах (или задачах) и вызов Report.Failed выполняется из них.

Иногда, после запуска тест может обнаружить, что он является неприемлемым. В подобном случае, будет осуществляться вызов Report.Not_Applicable, что выдаст в качестве отчета "NOT_APPLICABLE" (если при этом не был также выполнен вызов Report.Failed).

Часто какой-либо тест вызывает одну из функций Report.Ident_Int или Report.Ident_Bool, для получения значения, которое предусмотрено как литерал. Предполагается, что для этих функций не желательно применение оптимизации, которая исключает некоторые секции тест-кода. Комплект тестов ACATS не стремится отвергать технологию оптимизации, однако, удовлетворительное тестирование языковых средств часто требует присутствие и выполнение специфических строк тест-кода. Report.Ident_Int и Report.Ident_Bool структурированы таким образом, чтобы иметь возможность модификации, при необходимости отказаться от преимуществ оптимизации.

Структура тестов класса B может отличаться. Поскольку эти тесты не являются исполняемыми, они, как правило, не содержат обращений к Report.Test или Report.Result (поскольку эти строки кода не будут обладать эффектом вывода). Вместо этого, в тест-код включены преднамеренные ошибки, которые требуют проверки специальных правил допустимости. Исходный текст содержит комментарии, которые документируют ожидаемые результаты компиляции. Допустимые конструкции также могут быть включены в тесты класса B. Конструкции, которые разрешены правилами допустимости, маркированы с помощью "--OK"; конструкции, которые не разрешены правилами допустимости, маркированы с помощью "--ERROR:". Обычно, в той же самой строке или в строке последующего комментария присутствует краткое описание (индикация) проявления ожидаемой ошибки. Такое описание ожидаемых результатов выравнивается по правой границе кода в файле (символьная позиция 79) для быстрой визуальной идентификации.

Тесты класса L являются многофайловыми тестами содержащими недопустимости, которые должны быть детектированы на этапе связывания. В общем, тесты этого класса структурированы также как тесты класса C, часто с обращением к Report.Test или Report.Result, однако предполагается, что эти вызовы не будут реально выполнены.

Структура каталогов поставки

Поставка ACATS структурирована в дерево каталогов, которое отражает организацию комплекта тестов и кода поддержки. Схематический вид этой иерархии показан ниже.

    

ACATS_25-|
         |--- a
         |
         |--- b2 ... be
         |
         |--- bxa ... bxh
         |
         |--- c2 ... ce
         |
         |--- cxa ... cxh
         |
         |--- cz
         |
         |--- d
         |
         |--- e
         |
         |--- l
         |
         |--- lxa ... lxh
         |
         |--- docs
         |
         |--- support

Каталог верхнего уровня содержит подкаталоги support, docs, в также подкаталоги для каждой значительной группы тестов. Подкаталог support содержит все пакеты поддержки (Report, ImpDef, TCTouch), а также все исходные тексты для всех средств обработки (макропроцессор, Wide_Character-процессор). Все остальные подкаталоги содержат тесты, которые начинаются с указанного префикса. Например, все тесты B2* расположены в подкаталоге b2; все тесты CXH* расположены в подкаталоге cxh. Следует заметить, что все тесты A* расположены в подкаталоге a, все тесты D* расположены в подкаталоге d, а все тесты E* расположены в подкаталоге e. Подкаталог l содержит L-тесты ядра; остальные L-тесты расположены в подкаталогах с трехбуквенными именами, указывая класс L и соответствующее специализированное дополнение.

Формат файлов

С целью уменьшения объема, все файлы поставки тестов ACATS 2.5 (включая тестовые файлы, файлы базового кода и файлы поддержки) упакованы. Распакованные файлы используют только кодировку ASCII. Все файлы, кроме файлов документации, не содержат символов управляющих форматированием, которые, как правило, необходимы для текстовых процессоров. Файлы документации поставляются в нескольких форматах: текстовые файлы ASCII, файлы MS Word 97 и файлы PDF.

Файлы с тасширением .zip упакованы с помощью DOS-утилиты zip; файлы с расширением Z сначала архивированы с помощью UNIX-утилиты tar, а затем с помощью UNIX-утилиты compress.

Использование тестов ACATS

Использование комплекта тестов ACATS требует выполненить восемь основных шагов (иногда, выполнение двух из этих шагов не требуется). Такими шагами являются:

  1. установка программного обеспечения
  2. подстройка/подгонка программного обеспечения
  3. обработка файлов поддержки
  4. установка командных скриптов
  5. обработка тестов ACATS
  6. оценка полученных результатов
  7. поиск проблем возникших при тестировании (при необходимости)
  8. повторная обработка тестов в которых были обнаружены проблемы тестирования (при необходимости)

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

Установка комплекта тестов ACATS

Комплект тестов ACATS может быть установлен с носителя поставки или загружен с сайта поставки тестов ACATS в Internet. После этого комплект тестов может быть распакован, настроен под реализацию выполнен и оценен.

Состав поставки ACATS

Поставка тестов ACATS состоит из восьми архивов (набор упакованных файлов) или восьми упакованных tar-файлов. Каждый архив или упакованный tar-файл содержит упакованную версию программного обеспечения ACATS (тесты, базовый код и/или код поддержки), которое структурировано как дерево каталогов. Файлы должны быть распакованы из архивов. Каждый архив содержит файл readmrX.txt (где X является цифрой, представляющей номер архива), который содержит советы по распаковке и обзор содержимого архивного или tar-файла. Эти файлы не рассматриваются как составная часть ACATS; они существуют только для идентификации архивных файлов. Остальное содержимое архивов будет рассмотрено несколько позже.

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

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

Такие тесты документируются в перечне модификаций ACATS (ACATS Modifications List, сокращенно - AML). Этот перечень содержит список всех новых тестов, всех модифицированных тестов и список всех изолированных тестов, а также указание необходимости использования каждого изменения при сертификации реализации Ада-системы. Каждая версия перечня модификаций указывается как буквенный суффикс. Архивный и tar-файл, который содержит новые или модифицированные тесты, является доступным. Подобные файлы иненуются MOD_2_5x, где 'x' представляет буквенный суффикс, который указывает версию перечня модификаций.

Эти файлы доступны и могут быть получены с сайта ACAA:

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

написав в теле сообщения

Руководство по распаковке файлов

Как уже говорилось, для файлов поставки ACATS предусмотрено два формата: упакованный ZIP-формат и формат UNIX compress. ZIP-файлы включают восемь файлов с расширением имени .zip. Восемь упакованных UNIX-файлов, с расширением имени .Z, содержат tar-файлы UNIX. Эта секция предусматривает общие инструкции по распаковке. Эти инструкции не являются единственно возможным способом распаковки и некоторые, более осведомленные, пользователи могут использовать свои собственные процедуры и способы распаковки.

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

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

Распаковка ZIP-файлов

Все файлы ACATS, которые упакованы в ZIP-файлы с помощью утилиты DOS имеют расширение имени файла MS-DOS ".zip". Прежде чем осуществлять какую-либо обработку эти файлы должны быть распакованы (утилита распаковки присутствует в источнике поставки файлов ACATS). Для распаковки под управлением DOS, необходимо приблизительно 25 мегабайт дискового пространства. Все файлы поставки ACATS могут быть распакованы следующим образом.

Создайте каталог, который будет содержать ACATS. В нашем случае предполагается, что это будет каталог с именем "acats2_5", однако Вы можете использовать любое другое имя. Скопируйте каждый zip-архив на жесткий диск. Выполните распаковку, используя распаковку в подкаталоги (для программы "unzip" - это установлено по умолчанию; для программы "pkunzip" - используйте опцию "-d"; для программы "winnzip" - необходимо отметить "Use Directory Names"). Убедитесь, что файлы распаковываются в правильный подкаталог. Для утилит распаковки, использующих командную строку, это подразумевает, что текущим каталогом должен быть каталог "acats2_5". Для "winnzip", необходимо просто указать каталог "acats2_5" как каталог распаковки.

Например, при использовании "unzip" и, предполагая что архивом является файл "ACATS2.zip", следует выполнить команду:

чтобы указать правильный каталог, и команду:

чтобы выполнить непосредственную распаковку.

Файлы были упакованы на системе Windows, где в качестве терминатора строки используется пара символов <CR><LF>. Программы распаковки других систем, которые используют другой терминатор строки, должны быть способны выполнить соответствующее преобразование. ACAA имеет короткую Ада-программу, которая позволяет выполнить преобразование файлов Windows в файлы Unix (для этого, при необходимости, можно послать запрос по адресу [email protected]).

После распаковки файлов из архива, архивный файл можно удалить, освободив, таким образом, пространство на диске.

В процессе распаковки "unzip" сформирует необходимую структуру подкаталогов, с соответствующим расположением файлов.

Некоторые пользователи предпочитают работать с ACATS используя альтернативную структуру подкаталогов или не используя подкаталоги. При запуске "unzip" с опцией "-j", все файлы архива будут распакованы в текущий рабочий каталог, т.е. не создавая подкаталоги. Поскольку ACATS содержит число файлов, которое не сможет поместиться в корневой каталог DOS, поэтому перед распаковкой архивов необходимо обязательно создать подкаталог.

Распаковка упакованных файлов Unix

Все файлы ACATS, которые включены в восемь tar-файлов UNIX упакованных с помощью утилиты UNIX compress, имеют расширение имени ".Z". Для создания набора файлов ACATS необходимо скопировать архивный файл "acats25?.tar.Z" на диск, и, затем, распаковать его с помощью команд:

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

Файлы с непечатаемыми символами

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

A22006C

Этот тест проверяет, что символы управления форматированием могут появляться в начале компиляции. В начале файла, первая строка - пуста (индицирована маркером конца строки системы, который может быть последовательностью из одного или более символов, или может быть индицирован каким-либо другим образом). Следующая строка содержит 20 символов: 6 управляющих символов следующих за ограничителем комментария, пробел и имя файла (A22006C.ADA). Управляющими символами являются:

B25002A

Этот тест проверяет, что управляющие символы (отличные от символов управления форматированием) не допустимы в символьных литералах. Ожидаемые символы документированы в комментариях исходного текста, с помощью использования 2-х или 3-х символьную мнемонику. Для 28 символов использован порядок следования ASCII. Символы имеют ASCII-значения от 0 до 8, от 14 до 31 и 127.

B25002B

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

B26005A

Этот тест проверяет недопустимость использования управляющих символов в строковых литералах. Каждый строковый литерал (коды ASCII, от 0 до 31 и 127) используется однократно, используя порядок следования ASCII. Каждое использование документируется комментарием исходного текста, который идентифицируют символ с помощью его 2-х или 3-х символьной мнемоники.

"Подгонка" ACATS

Поставка комплекта тестов ACATS 2.5 содержит файлы, которые нуждаются в модификации, прежде чем они будут готовы к обработке какой-либо реализацией Ада-системы. Пакет ImpDef (impdef.a) должен быть отредактирован, чтобы установленные в нем значения соответствовали характеристикам тестируемой Ада-системы (когда значения по умолчанию не приемлемы). Пакет ImpDef является новым пакетом для комплекта тестов 2.X, и всем пользователям необходимо осуществлять эти модификации. Кроме того, для установки соответствующих значений, также должен быть модифицирован файл macros.dfs. По сравнению с предыдущими версиями ACATS, этот файл несколько отличается, поэтому внесение изменений потребуется для всех пользователей. Однако, основные изменения предыдущих версий могут быть сохранены. Во всех файлах .tst (включая пакет Spprt13, из файла spprt13.tst) должна быть выполнена макроподстановка символов, в соответствии со значениями определяемыми реализацией Ада-системы. При необходимости, должно быть предусмотрено тело FcnDecl (fcndecl.ada). И в заключение, при необходимости, должен быть модифицирован пакет Report (repbody.ada). При этом, могут быть использованы предыдущие изменения.

Настройка ImpDef

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

impdef.a был добавлен как новое свойство поставки тестов ACATS 2.0. Он подобен macro.dfs в том, что должен быть адаптирован в соответствии со значениями, которые характерны для реализации Ада-системы, и тесты ACATS будут использовать эти значения. Отличие пакета ImpDef заключается в следующем:

Для каждого специализированного дополнения ImpDef обладает соответствующим дочерним пакетом. Какая-либо реализация Ада-системы, для которой осуществляется проверка поддержки специализированных дополнений, должна выполнить настройку соответствующего дочернего пакета ImpDef (или использовать его установки по умолчанию) и должна установить соответствующее логическое значение в impdef.a. Для значений, которые требуются в ImpDef и его дочерних модулях, включены соответствующие инструкции в impdef.a, impdefc.a, impdefd.a, impdefe.a, impdefg.a и impdefh.a. Следует заметить, что, например, impdefc.a относится к специализированному дополнению C (Annex C).

Настройка определений макроподстановки

Тест-файлы с расширением ".tst" содержат символы, которые представляют значения зависящие от реализации Ада-системы. Такие символы являются идентификаторами начинающимися со знака доллара ('$'). Каждый такой символ должен быть заменен соответствующим текстовым значением, после чего, тесты могут быть скомпилированы.

Поставляемая в составе ACATS программа Macrosub способна выполнить необходимую макроподстановку автоматически. Эта программа читает значения, которые должны быть подставлены вместо символов, из файла macro.dfs и редактирует все файлы ".tst" комплекта тестов, осуществляя тем самым необходимые изменения. В процессе своей работы, программа записывает получаемые в результате изменений, готовые к компиляции файлы, сохраняя их имена и изменяя расширение на ".adt". Пример файла macro.dfs включен в поставку ACATS. Он содержит описания всех символов используемых в комплекте тестов.

Макроподстановка с помощью программы Macrosub может быть выполнена следующим образом:

  1. Отредактируйте файл macro.dfs используя значения, которые соответствуют характеристикам реализации Ада-системы. Символы, которые используют значение MAX_IN_LEN, вычисляются автоматически и не должны вводиться.
  2. Создайте файл tsttests.dat, который содержит все имена тестовых файлов ".tst", и, при необходимости, каталоги их расположения. Поставляется версия этого файла (без информации о каталогах).
  3. Откомпилируйте и скомпонуйте Macrosub.
  4. Запустите Macrosub на выполнение.

Программа выполнит замену всех символов в файлах ".tst" на значения из файла macro.dfs. Тест-файлы с оригинальными именами, но с расширением ".adt" будут содержать тесты, которые готовы к непосредственной обработке. Оригинальные файлы ".tst" не будут подвергнуты модификации.

Обработка тестов Wide_Character

ACATS 2.5 содержит два теста, которые проверяют способность реализации Ада-системы обрабатывать символы из полного набора печатаемых символов ISO 10646 BMP. Поскольку отсутствует способ надежного размещения таких символов на носителе поставки эти тесты содержат последовательности символов, которые должны быть заменены необходимыми символами. Для этого в дистрибутив включена программа WideChr осуществляющая необходимые подстановки автоматически.

Тесты, которые требуют осуществления таких подстановок, храняться в файлах с расширением ".aw". Каждый такой тест содержит шести- или восьми- символьные последовательности вида:

или

Следует заметить, что символы двойных кавычек являются частью специальной последовательности (служа частью ключевой последовательности). Процессор будет подставлять строку символы которой обозначаются как 16#abcd#, где алфавитно-цифровые символы 'a', 'b', 'c' и 'd' являются шестнадцатеричными цифрами. Следует также заметить, что строки, которые нуждаются в замене, не начинаются с символа '$', а также то, что выполняемая замена является синтетической (а не простой подстановкой). Таким образом, макропроцессор не обрабатывает эти тесты.

Программа WideChr принимает указываемый тест как ввод. Имена требуемых тестов включены в исходный текст программы WideChr как константы, а путь к каталогу она берет из ImpDef. Программа читает тесты, синтезирует необходимые замены и записывает полученные в результате обработки компилируемые программы в файлы, имена которых совпадают с именами оригинальных файлов и имеют расширение ".a".

Подстановки выполняемые с помощью программы WideChr могут быть осуществлены следующим образом:

  1. Отредактируйте файл impdef.a, для указания пути к каталогу где располагаются тесты. Вместе с именем теста, это значение будет использовано для получения полного имени файла.
  2. Откомпилируйте и скомпонуйте WideChr.
  3. Запустите WideChr на выполнение.

Программа заменит все специальные последовательности символов в файлах .aw на синтезированные символьные значения. Полученные в результате обработки файлы будут сохранены в том же каталоге, где расположены исходные файлы ".aw", с такими же именами, но с расширением ".a". Эти файлы будут содержать тесты, которые готовы к непосредственной обработке. Оригинальные файлы ".aw" останутся не модифицированными.

Пакет SPPRT13 и функция FcnDecl

Пакет SPPRT13 определяет шесть констант типа System.Address, Он храниться в файле spprt13s.tst. При поставке, пакет использует макро-символы, которые должны быть заменены. В большинстве случаев, макроподстановка может быть выполнена при осущетсвлении ранее описанного процесса макроподстановки. Если соответствующие литералы, константы или предопределенные вызовы функций могут быть использованы для инициализации этих констант, то это должно быть выполнено с помощью macro.dfs. В противном случае, необходимо модифицировать пакет FCNDECL.

Версия SPPRT13, которая поставляется в составе ACATS 2.5, несколько отличается от версии, которая поставлялась в составе ACVC 1.11. Этот пакет не требует наличия тела (что является не допустимым для ada).

Спецификация пакета FCNDECL находится в файле fcndecl.ada. SPPRT13 зависит от FCNDECL (FCNDECL указан в спецификаторах with и use). Согласно поставки ACATS 2.5 FCNDECL является пустой спецификацией. В случае, когда соответствующие литералы, константы или предопределенные вызовы функций не могут быть использованы для инициализации констант описанных в SPPRT13, разработчик реализации Ада-системы должен определить соответствующие функции в спецификации FCNDECL и предусмотреть их тела в теле пакета или использовать директиву компилятора Import.

Для модификации FCNDECL должно быть получено заблаговременное одобрение от ACAL (и, в случае необходимости, от ACAA), перед сертификацией реализации Ада-системы.

Модификация пакета REPORT

Все исполняемые тесты используют средства пакета поддержки отчетов Report. Этот пакет содержит подпрограммы автоматизации выдачи отчетов по результатам тестирования, а также подпрограммы, которые разработаны для предотвращения удаления оптимизатором компилятора ключевых секций тест-кода. Спецификация пакета Report находится в файле repspec.ada, а его тело - в файле repbody.ada.

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

Для модификации пакета Report должно быть получено заблаговременное одобрение от ACAL (и, в случае необходимости, от ACAA), перед сертификацией реализации Ада-системы.

Допустимые модификации тестов

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

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

Тесты, которые используют директивы конфигурации, могут нуждаться в модификации, поскольку способ обработки директив конфигурации зависит от реализации конкретной Ада-системы.

Некоторые тесты содержат код других языков программирования (Fortran, C или Cobol). Хотя используемые свойства должны нормально обрабатываться всеми реализациями Fortran, C и Cobol, некоторые реализации могут потребовать модификацию не Ада-кода. Подобные модификации, естественно, должны сохранять семантику подпрограмм ввода/вывода других языков программирования. В противном случае, тесты ACATS будут выдавать отчет об обнаружении ошибки.

Все разделения тестов на части и все модификации должны быть заблаговременно утверждены ACAL (и, в случае необходимости, от ACAA), перед сертификацией реализации Ада-системы (ответственность за это возлагается на пользователей). Модифицированные тесты должны именоваться путем добавления алфавитно-цифровых символов к имени оригинального теста. По возможности, при модификации должна сохраняться нумерация строк оригинального теста.

Все тесты должны быть представлены компилятору в том виде, в котором они поставляются в комплекте тестов (или в настроенном виде, когда это необходимо). Когда тест является исполняемым (тесты классов A, C, D, E) и их компиляция прошла успешно, они должны быть выполнены. Модифицированные или разделенные на части тесты могут быть обработаны позже.

Если ACAA публикует перечень модификаций ACATS, то необходимо осуществление требуемых модификаций. Разрешенные модификации могут быть выполнены по желанию (или при их необходимости для какой-либо реализации Ада-системы).

Обработка файлов поддержки

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

Файлы поддержки

Перечисленные ниже файлы необходимы для многих тестов ACATS:

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

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

Приемка тестов CZ

Четыре теста, имена которых начинаются с CZ, являются самостоятельной частью комплекта тестов ACATS. Их отличие от других тестов заключается в том, что они непосредственно не направлены на проверку средств языка Ада. Основной целью этих тестов является проверка того, что программное обеспечение, которое необходимо для корректного выполнения комплекта тестов, работает правильно. Например, эти тесты проверяют правильность работы пакетов Report и TCTouch.

Для успешной сертификации все тесты CZ должны быть выполнены корректно и должны продемонстрировать преопределенное поведение. Чтобы убедиться в правильности работы программного обеспечения поддержки, тесты CZ должны быть обработаны и выполнены как первый шаг процесса сертификации.

Тест CZ1101A проверяет корректностьь работы пакета генерации отчетов Report, включая проверку правильности выдачи отчетов "NOT_APPLICABLE" и "FAILED", а также проверку того, что преждевременные вызовы приводят к ошибке. Следовательно, в результате своей работы, тест CZ1101A будет печатать некоторые сообщения об ошибках. Присутствие таких сообщений об ошибках не обязательно подразумевает ошибку выполнения теста. Листинг предполагаемого вывода теста CZ1101A представлен в приложении C "Руководства пользователя ACATS" (естественно, что время и дата реального вывода будет отличаться).

Тест CZ1102A проверяет правильность работы подпрограмм пакета Report которые обработывают динамические значения. Этот тест должен выдать отчет "PASSED". Любой другой результат будет указывать на то, что тест потерпел неудачу.

Тест CZ1103A проверяет корректность работы процедуры Checkfile (некоторые исполняемые тесты ввода/вывода используют процедуру именуемую Checkfile, которая определяет характеристики текстового файла реализации; исходный текст этой процедуры расположен в файле checkfil.ada). Тест CZ1103A проверяет надежность обнаружения ошибок в текстовом файле. Следовательно, во время выполнения, этот тест будет печатать некоторые сообщения об ошибках. Присутствие таких сообщений об ошибках не обязательно подразумевает ошибку выполнения теста. Листинг предполагаемого вывода теста CZ1103A представлен в приложении C "Руководства пользователя ACATS" (естественно, что время и дата реального вывода будет отличаться).

Тест CZ00004A производит вывод, который проверяет цели сертификации. Он зависит от корректности обновления ImpDef и производит вывод идентифицирующий специализированные дополнения, проверка которых является составной частью процесса сертификации. Кроме того, этот тест проверяет правильность работы пакета TCTouch, включая проверку проверку правильности выдачи отчетов об ошибках условий. Таким образом, во время выполнения, тест CZ00004A будет печатать некоторые сообщения об ошибках. Присутствие таких сообщений об ошибках не обязательно подразумевает ошибку выполнения теста. Листинг предполагаемого вывода теста CZ00004A представлен в приложении C "Руководства пользователя ACATS" (поскольку вывод содержит значения настроенного ImpDef, не-ошибочные предполагаемого вывода строки могут отличаться; однако, число строк и их относительное расположение должно оставаться не измененным).

Установка командных скриптов

Достаточно часто пользователи предпочитают запускать большое количество тестов ACATS с помощью командных скриптов (в пакетном режиме). Эта секция обсуждает вопросы связанные с разработкой подобных скриптов.

Командные скрипты

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

Скрипты должны компилировать (только компилировать) все тесты класса B. Они должны выполнять компиляцию и связывание (компоновку) всех тестов класса L; если не было обнаружено явных ошибок связывания (компоновки), то скрипты должны осуществить попытку выполнения тестов класса L. Скрипты должны компилировать все файлы класса F. Они должны выполнять компилировать, свяывание (компоновку) и выполнение всех тестов класса A, C, D и E.

Зависимости

Командные скрипты должны учитывать все требуемые зависимости. Как отмечалось ранее, некоторые тесты состоят из множества файлов. Кроме того, некоторые тесты включают базовый код, который может быть использован другими тестами. Если базовый код не включен в окружение, его компиляция должна осуществляться как часть процесса построения теста. Все файлы, которые используются в тесте, должны компилироваться в правильной последовательности, которая указывается именами файлов. Для реализаций Ада-систем, которые нуждаются в распаковке из тест-файлов индивидуальных компилируемых модулей (перед тем как предоставить компилируемые модули компилятору), распакованные компилируемые модули должны быть переданы компилятору в той последовательности, в которой они представлены в файле.

Обработка тестов ACATS

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

Требуемые тесты

Какая-либо реализация может проверяться только на соответствие поддержки основных языковых средств (ядро языка) или на соответствие поддержки ядра языка и одного или более специализированного дополнения. Для сертификации на соответствие поддержки ядра языка, все тесты ядра должны быть обработаны с получением приемлемых результатов. К тестам ядра принадлежат все унаследованные тесты, а также все новые тесты (для clauses 2-13) и тесты дополнений A и B. Сертификация, которая включает поддержку одного (и/или более) специализированного дополнения, дополнительно к тестам ядра, требует осуществить обработку всех тестов соответствующего специализированного дополнения.

Тесты, которые не приемлемы для какой-либо реализации Ада-системы (например, ввиду ограничений размера), и тесты, которые при своем выполнении в среде проверяемой реализации Ада-системы выдают отчет "NOT APPLICABLE", также должны быть подвергнуты обработке (с целью демонстрации соответствующих результатов).

Обработка тестов выделенных текущим перечнем модификаций ACATS, который опубликован ACAA, не требуется.

Тестовые разделы

Все тесты должны быть сконфигурированы и выполнены в рамках одного раздела, за исключением случаев, когда секция специальных требований теста указывает обратное. Метод спецификации такого раздела зависит от реализации Ада-системы и не определяется ACATS. К тестам, которые должны выполняться множеством разделов, относятся только тесты проверяющие специализарованное дополнение E для распределенных систем (Annex E, "Distributed Systems").

Связывание тест-программ

В некоторых ситуациях, обычная последовательность обработки тестов может потребовать неприемлемый объем времени. Например, выполнение тестов на встроенной целевой системе может потребовать значительные дополнительные затраты времени на загрузку индивидуальных тестов. В таких случаях, исполняемые тесты могут быть связаны в "агрегаты" (пакеты), состоящие из множества тестов. Набор связанных тестов будет иметь драйвер, который вызывает тесты по очереди; таким образом, тесты ACATS будут вызываться как процедуры, а не как головные процедуры. При таком связывании, изменение исходных текстов тестов не допускается; таким образом, допускается только изменение метода вызова тестов.

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

Обработка, которая может быть опущена

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

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

Пользователь, не зависимо от ACAL, может определить, что некоторые тесты нуждаются в поддержке, которая не может быть предоставлена реализацией. Например, существуют тесты, которые предполагают доступность файлового ввода/вывода, в то время когда некоторые реализации (как правило, для встроенных систем) не обеспечивают поддержку файлового ввода/вывода. Такие тесты не нуждаются в обработке при доказательной проверке Ада-системы. Однако, разработчик реализации Ада-системы должен продемонстрировать, что такие тесты обрабатываются в соответствии со стандартом языка. Такая демонстрация может быть выполнена перед доказательной проверкой, во время которой повторение этой демонстрации не потребуется.

Тесты приложения B, которые требуют компиляции кода на других языках программирования (Fortran, C, Cobol) и его компоновки с Ада-кодом, не нуждаются в обработке, когда реализация Ада-системы не обеспечивает поддержку интерфейса с соответствующими языками программирования.

Тесты специализированных дополнений [Ada95] не нуждаются в обработке, за исключением случаев, когда для реализации Ада-системы желательно иметь документированные результаты проверки специализированных дополнений. В таком случае, должны обрабатываться только тесты для рассматриваемого дополнения (в дополнение к тестам ядра). Если обработаны какие-либо любые тесты выбранного специализированного дополнения, то все тесты этого специализированного дополнения должны быть обработаны. Если какая-либо реализация Ада-системы не поддерживает какие-либо свойства теста специализированного дополнения, то эта реализация должна индицировать отсутствие поддержки путем отбраковки (отброса) теста на этапе компиляции или возбуждением соответствующего исключения во время выполнения теста.

Тесты исключенные перечнем изменений не нуждаются в обработке. Кроме того не нуждаются в обработке тесты, которые классифицируются текущим перечнем изменений ACATS как новые (Pending New). Новые тесты включены в ACATS с целью их анализа, и, таким образом, они не требуются для сертификации.

Тесты, которые требуют специальной обработки

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

Список всех подобных тестов включен в приложение A "Руководства пользователя ACATS".

Тесты интерфейса с другими языками

Дополнение B, "Интерфейс с другими яязыками", является частью ядра языка ada. Любая реализация Ада-системы, которая предусматривает один или более пакетов Interfaces.C, Interfaces.COBOL или Interfaces.Fortran, обязана корректно обрабатывать и проходить тесты интерфейса с кодом на C, Cobol и/или Fortran, с возможным исключением тестов, которые содержат фактический код на другом языке программирования.

Реализация Ада-системы, которая предусматривает один или более дочерних пакетов пакета Interfaces, должна успешно компилировать Ада-модули тестов с фактическим кодом на другом языке программирования. Если реализация не поддерживает фактическое связывание другого языка программирования с Адой, то такие тесты могут выдавать сообщения об ошибках при редактировании связей (компоновке), или могут отвергать директиву Import; в этом случае, подобные тесты могут рассматриваться как неприемлемые. Если реализация обеспечивает поддержку связывания и доступен подходящий компилятор с другого языка программирования, тесты должны быть выполнены с выдачей отчета "Passed". Если реализация обеспечивает поддержку связывания, но подходящий компилятор с другого языка программирования отсутствует, то такие тесты могут быть расценены как неприемлемые, путем демонстрации ошибок при редактировании связей (компоновке).

Если один из дочерних пакетов пакета Interfaces не предусмотрен, то соответствующие тесты могут быть расценены как неприемлемые, путем отброса этими тестами соответствующего спецификатора with.

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

В ACATS, код на других языках программирования, не содержит каких-либо специальных или уникальных особенностей, и должен нормально обрабатываться любым стандартным компилятором (C, Cobol, Fortran). Однако, возможно наличие диалектических проблем, которые не позволяют осуществить корректную компиляцию кода. Допускается модификация кода других языков программирования; результат такой модификации должен удовлетворять требованиям, которые зафиксированы в заголовке файла. Подобные модификации должны быть заблаговременно согласованы с ACAL (и, при необходимости, с ACAA). Метод компиляции кода других языков программирования зависит от реализации Ада-системы и не определен как составная часть ACATS. Ада-код таких тестов должен компилироваться обычным образом. Ада-код включает директиву Import, которая ссылается на код другого языка программирования. Имя компоновки объектного кода другого языка программирования должно быть предусмотрено в ImpDef. Когда весь код скомпилирован, тест должен быть скомпонован (включая объектный код другого языка программирования) и выполнен. Метод связывания (компоновки) кода Ады и кода другого языка программирования зависит от реализации Ада-системы и не определяется как часть ACATS. В результате выполнения теста должен быть получен отчет "PASSED".

Интерфейс с C

Когда реализация Ада-системы предусматривает пакет Interfaces.C, описываемые ниже тесты должны быть удовлетворительно обработаны как было описано ранее.

Тесты отмеченные звездочками содержат код на языке C, который должен быть откомпилирован и, по возможности, скомпонован как было описано ранее. Код на языке C может быть легко идентифицирован, поскольку файлы имеют расширение ".c". Код на языке C может быть модифицирован с целью удовлетворения требований диалекта компилятора C. Файлы с кодом на языке C должны быть скомпилированы с помощью компилятора C и полученный в результате компиляции объектный код должен быть скомпонован с откомпилированным Ада-кодом. Директива Import будет брать имя кода языка C из ImpDef.

Интерфейс с Cobol

Когда реализация Ада-системы предусматривает пакет Interfaces.COBOL, описываемые ниже тесты должны быть удовлетворительно обработаны как было описано ранее.

Тесты отмеченные звездочками содержат код на языке Cobol, который должен быть откомпилирован и, по возможности, скомпонован как было описано ранее. Код на языке Cobol может быть легко идентифицирован, поскольку файлы имеют расширение ".cbl". Код на языке Cobol может быть модифицирован с целью удовлетворения требований диалекта компилятора Cobol. Файлы с кодом на языке Cobol должны быть скомпилированы с помощью компилятора Cobol и полученный в результате компиляции объектный код должен быть скомпонован с откомпилированным Ада-кодом. Директива Import будет брать имя кода языка Cobol из ImpDef.

Интерфейс с Fortran

Когда реализация Ада-системы предусматривает пакет Interfaces.Fortran, описываемые ниже тесты должны быть удовлетворительно обработаны как было описано ранее.

Тесты отмеченные звездочками содержат код на языке Fortran, который должен быть откомпилирован и, по возможности, скомпонован как было описано ранее. Код на языке Fortran может быть легко идентифицирован, поскольку файлы имеют расширение ".ftn". Код на языке Fortran может быть модифицирован с целью удовлетворения требований диалекта компилятора Fortran. Файлы с кодом на языке Fortran должны быть скомпилированы с помощью компилятора Fortran и полученный в результате компиляции объектный код должен быть скомпонован с откомпилированным Ада-кодом. Директива Import будет брать имя кода языка Fortran из ImpDef.

Тесты дополнения для распределенных систем

Тесты ACATS для распределенных систем применимы только к тем реализациям Ада-систем, для которых желательна проверка поддержки этого специализированного дополнения. Не все эти тесты приемлемы для всех реализаций Ада-систем, поскольку это дополнение включает некоторые особенности реализации, которые влияют на приемлемость некоторых тестов.

Принципиальными факторами, влияющими на приемлемость тестов являются:

  1. наличие поддержки для директивы Remote_Call_Interface
  2. наличие системы взаимодействия разделов (Partition Communication System, или PCS); например, наличие в реализации Ада-системы тела для пакета System.RPC
  3. наличие поддержки дополнения для систем реального времени

Какая-либо реализация Ада-системы может осуществлять проверку поддержки специализированных дополнений не предусматривая наличия системы взаимодействия разделов (PCS). В порядке проверки специализированного дополнения для распределенных систем, реализация Ада-системы должна позволять компиляцию тела пакета System.RPC.

Директива Remote_Call_Interface

[Ada95] допускает использовать между активными разделами явное взаимодействие (на основе сообщений), как альтернативу системы взаимодействия разделов [E.2.3(20)]. Если реализация Ада-системы не обеспечивает поддержку директивы Remote_Call_Interface, то следующие тесты будут неприемлемы:

Система взаимодействия разделов

Реализация Ада-системы не обязана обеспечивать поддержку системы взаимодействия разделов [E.5(27)] в порядке проверки специализированного дополнения для распределенных систем. Когда поддержка системы взаимодействия разделов не обеспечена, следующие тесты будут неприемлемы:

System.RPC

Два теста предусматривают тело для пакета System.RPC. Реализация может включать приватную часть, которая содержит определения, такие как дополнительные процедуры и функции, которые навязывают пакету System.RPC дополнительные требования. Если реализация Ада-системы включает дополнительные определения, то такие же определения могут быть добавлены в тело пакета System.RPC в тестах указанных ниже. Определения в приватной части реализации System.RPC не влияют на приемлемость тестов этой группы.

Поддержка дополнения реального времени

Многие реализации Ада-систем, которые обеспечивают поддержку специализированного дополнения для распределенных систем будут также поддерживать специализированное дополнение для систем реального времени. Тест CXE4003 разработан с учетом преимуществ предоставляемых свойствами дополнения для систем реального времени, с целью более качественной проверки дополнения для распределенных систем.

Для реализаций Ада-систем, которые не обеспечивают поддержку специализированного дополнения для систем реального времени, тест CXE4003 должен быть модифицирован. Модификация заключается в удалении всех строк, которые заканчиваются комментарием "--RT".

Конфигурирование тестов с множеством разделов

Некоторые тесты поддержки специализированного дополнения для распределенных систем требуют наличия множества разделов для выполнения теста, но для выполнения любого из этих тестов требуется не более двух разделов. Все тесты с множеством разделов содержат головную процедуру для каждого из двух разделов. Два раздела именуются как "A" и "B", а головные программы для этих разделов, соответственно, "<имя_теста>A" и "<имя_теста>B". Каждый тест содержит инструкции именующие компилируемые модули, которые должны быть включены в каждый раздел. Большинство реализаций будут, главным образом, заботиться о головной процедуре и пакетах удаленных интерфейсов (RCI-пакетов), которые будут назначаться каждому разделу. Остальное содержимое разделов будет определяться обычными правилами зависимости. Соглашения по наименованию, использованные в тестах с множеством разделов, содействуют выполнению назначений разделов. Если имя компилируемого модуля заканчивается как "_A<необязательная_цифра>", то этот модуль назначается разделу "A". Компилируемые модули, имена которых заканчиваются как "_B<необязательная_цифра>", назначаются разделу "B".

Следующие тесты требуют для своего выполнения наличия двух разделов:

(*) Тесты CXE2001 и LXE3002 содержат пакет Shared_Passive и два активных раздела. Конфигурация из двух разделов должна иметь два активных раздела и пакет Shared_Passive может быть назначен любому из разделов. Конфигурация из трех разделов состоит из двух активных разделов и одного пассивного раздела, и пассивный раздел будет содержать единственный пакет Shared_Passive.

Выполнение тестов с множеством разделов

Все тесты, состоящие из множества разделов, включают пакет Report в оба активных раздела. Для успешного прохождения теста, оба раздела должны выдать отчет "PASSED" (кроме теста LXE3002 - см. специальные инструкции для этого теста). Если оба раздела выдают отчет "FAILED", или один или два раздела не выдают отчет "PASSED", то считается, что тест потерпел неудачу.

При выполнении тестов: состоящих из множества разделов, не имеет значения какой из разделов был запущен на выполнение первым. В общем, раздел "A" выступает в роли сервера, а раздел "B" выступает в роли клиента. Таким образом, осуществление запуска на выполнение раздела "A" в первую очередь будет предпочтительнее. В случае, когда тест терпит неудачу по вине возбуждения исключения Communication_Error, допускается осуществление перезапуска теста.

Тесты численного дополнения

Многие тесты численного дополнения G обязаны выполняться в строгом режиме. Метод выбора строгого режима зависит от реализации и не определяется ACATS (следует заметить, что тесты численных функций определенные в дополнении A могут быть также выполнены в строгом режиме, но это не обязательно). Следующие тесты обязаны выполняться в строгом режиме:

Тесты, которые используют директивы конфигурации

Некоторые тесты приложения D (обработка в реальном времени), приложения E (распределенные системы) и приложения H (секретность и безопасность) используют директивы конфигурации. Техника применения директив конфигурации к тесту, который состоит из множества компилируемых модулей, зависит от реализации Ада-системы и не определяется ACATS. Следовательно, каждая реализация Ада-системы, которая использует подобные тесты при сертификации, должна осуществить соответствующие шаги, которые могут включать модификацию тест-кода и/или пост-компиляционную обработку, чтобы убедиться в корректности применения таких директив. Перечисленные ниже тесты нуждаются в специальной обработке директив конфигурации:

Выделение специфических свойств

Структура комплекта тестов ACATS позволяет разработчикам компиляторов и тестерам использовать только те части комплекта тестов, которые позволяют выделить спецефические свойства компилятора.

Унаследованные и новые тесты обладают тенденцией концентрировать внимание на характерных свойствах языка в индивидуальных тестах. Имя теста является хорошим общим средством индикции первичного содержания проверяемых свойств (это обсуждалось при описании соглашений по наименованию). Следует учитывать, что имена унаследованных тестов не были изменены, в то время как организация структуры "Ada Reference Manual" (при сравнении [Ada83] и [Ada95]) подверглась изменению. Более того, следует заметить, что общий стиль новых тестов создает тестовые ситуации, которые ориентированы на пользователя, путем включения в тесты различных свойств и их совместного взаимодействия. Таким образом, следует учитывать, что с помощью имени теста может быть индицировано только первичное выделение свойств.

Тесты ACATS 2.5 подразделяются на тесты ядра, и тесты специализированных дополнений. Напомним также, что дополнения A и B являются частью тестов ядра. Все тесты дополнений (включая дополнения A и B) содержат во второй символьной позиции своего имени символ 'X', а в третьей символьной позиции своего имени - символы от 'C' до 'H', в соответствии с буквенным индексом дополнения.

Оценка результатов тестирования

Хотя одиночный тест может быть использован для проверки множества редакций языка, результаты тестов ACATS ("PASSED", "FAILED", "NOT APPLICABLE) рассматриваются только как единое целое.

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

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

Далее будут рассмотрены: ожидаемые результаты для исполняемых и не-исполняемых тестов; тесты, которые не приемлемы для реализации Ада-системы; изолированные тесты.

Ожидаемые результаты для исполняемых тестов

Исполняемые тесты (тесты классов A, C, D и E) должны быть успешно обработаны компилятором и вся пост-компиляционная обработка (связывание, компоновка, разделение на разделы) должна быть выполнена без каких-либо ошибок. Эти тесты должны быть загружены в целевую систему и выполнены. Нормальное выполнение любого теста этой группы демонстрирует вывод какого-либо предварительного сообщения, которое сообщает об общем назначении теста, возможный вывод некоторых информационных замечаний о ходе выполнения теста, заключительное сообщение, которое определяет успешность/не-успешность прохождения теста и успешное завершение выполнения теста (без каких-либо дополнительных сообщений). Тесты могут выдавать отчет "PASSED", "TENTATIVELY PASSED", "FAILED" или "NOT APPLICABLE".

Какой-либо тест, который потерпел неудачу при компиляции и/или связывании (компоновке), включая компиляцию и связывание (компоновку) базового кода от которого этот тест зависит, расценивается как тест потерпевший неудачу, за исключением случаев, когда тест включает свойства, которые требуют поддержку любой реализацией Ада-системы. Например, реализация может отвергнуть определение численного типа, который не поддерживается. Допустимые случаи четко указываются в "Критериях приемлемости" ("Applicability Criteria) тестов. Дополнение L [Ada95] требует, чтобы реализация Ада-системы документировала подобные, определяемые реализацией характеристики.

Тест, который выдает отчет "FAILED", расценивается как тест потерпевший неудачу, за исключением случаев, когда ACAL (и, возможно, ACAA) определяет, что тест является не приемлемым для реализации Ада-системы.

Тест, который выдает отчет "PASSED", расценивается как успешный, за исключением случаев, когда тест выдал отчет об успешности, но не смог после этого успешно завершиться (нарпример, разрушился, завис, выдал непредвиденное исключение, раньше или позже выдал сообщение "FAILED"). Подобный вид неустойчивого поведения может возникнуть, например, в некоторых тестах многозадачности, где одновременно присутствуют несколько нитей управления. Сообщение успешности прохождения может быть выдано из одной нити управления, но другая нить управления может асинхронно разрушиться или неудачно завершиться.

Тест, который выдает отчет "NOT APPLICABLE" должен быть выполнен реализацией Ада-системы, и он расценивается как неприемлемый, за исключением случаев, когда впоследствии тест не смог успешно завершиться.

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

Тесты, которые потерпели неудачу при выдаче отчета или выдали только частичный отчет, будут расценены как потерпевшие неудачу, за исключением случаев, когда ACAL (и, возможно, ACAA) определяет, что тест является не приемлемым для реализации Ада-системы.

Ожидаемые результаты для тестов класса B

Предполагается, что для тестов класса B должна быть осуществлена компиляция, но последующая обработка, для получения исполняемых модулей, выполняться не будет. Реализация Ада-системы должна корректно распознавать каждую четко обозначенную ошибку (коментарий "--ERROR:" присутствует в правой части исходного текста). В общем, множество модулей файла теста принадлежащего к классу B будет содержать преднамеренные ошибки только в одном компилируемом модуле. Сообщения об ошибке должны предусматривать некоторые сведения указывающие на место ошибки, однако, это не требует наличия прямого соответствия с маркерами ошибок "--ERROR:".

Некоторые тесты класса B, содержат также комментарии "--OK", индицирующие конструкции, которые не должны быть распознаны как ошибочные. Это имеет специальное значение, поскольку некоторые конструкции, которые ошибочны для Ada83, являются допустимыми для Ada95.

Следует заметить, что для изображения маркеров "--ERROR:" и "--OK" может быть использован верхний, нижний и смешанный регистр символов.

Некоторые тесты класса B используют конструкции корректность которых зависит от исходного текста, который текстуально отделен (например, отложенная константа и ее полное описание). В таких случаях, имеет смысл выдача сообщения об одной ошибке для двух расположений. Подобные случаи маркируются комментарием "--OPTIONAL ERROR". Некоторые (но не все) реализации Ада-систем способны отмечать такие строки как ошибочные. Пока опциональная ошибка не отмечена как преднамеренная ошибка, любое сообщение об обнаружении (или не обнаружении) ошибки не влияет на результат прохождения теста.

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

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

Ожидаемые результаты для тестов класса L

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

В общем, предполагается, что любой тест класса L будет отвергнут (потерпит неудачу) на этапе его обработки редактором связей (компоновщиком). Некоторые тесты содержат комментарий "--ERROR:"; какая-либо реализация Ада-системы выдающая сообщение обошибке ассоциированное с одной из таких строк рассматривается как прошедшая проверку данным тестом (естественно подразумевая, что попытка связывания/компоновки также безуспешна).

Следующие тесты являются исключением из общего правила (тест класса L не должен выполниться):

Неприемлемые тесты

Каждый тест из комплекта ACATS обладает целевым предназначением, которое описывается в прологе теста. Некоторые целевые предназначения адресованы к свойствам языка Ада, которые не обязаны поддерживаться всеми реализациями Ада-систем (например, проверка операций с плавающей точкой до 18-й цифры). В общем, такие тесты содержат явную индикацию их приемлемости и ожидаемое поведение реализации для которой тест не приемлем. Приложение D "Руководства пользователя ACATS" перечисляет общие причины неприемлемости тестов и перечисляет затрагиваемые тесты.

Какой-либо тест может быть неприемлемым для данной реализации Ада-системы:

Соответствующие критерии оценки включают:

Все приемлемые тест-программы (тесты) должны быть обработаны и пройдены успешно.

Изолированные тесты

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

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

Изолированные тесты перечисляются в перечне изменений ACATS, который сопровождается ACAA.

Источники проблем или разногласия

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

Обычные разногласия

Существуют несколько типичных случаев непредвиденных неудач прохождения тестов ACATS (возникающих из-за ошибок в критериях оценки):

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

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

Отклонения от ожидаемых результатов - заявки и пересмотр

Каждый тест указывает в своем прологе, какое поведение он ожидает от соответствующей реализации Ада-системы. Результаты обработки теста являются приемлемыми если и только если результаты явно приемлемы при рассмотрении критерия для теста.

Пользователь может обоснованно оспорить приемлемость и корректность теста ACATS. Соискатель должен предоставить заявку на оспаривание теста в ACAL или в ACAA, в соответствии с процедурой и формой заявки, которые представлены в [Pro01]. Заявка должна четко отображать причины по которым тест не приемлем для реализации Ада-системы или причины по которым тест считается ошибочным. Заявка должна указывать фарактерный фрагмент кода, который является спорным и содержать исчерпывающие объяснения сути разногласий.

Для принятия решения, ACAL перенаправит заявки своих заказчиков в ACAA. После чего ACAA рассматривает заявки и принимает решение:

Отклонения рассматриваются как ошибки теста, до тех пор, пока заявка на допуск отклонения не будет принята ACAA.

Повторная обработка и оценка

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