Документ взят из кэша поисковой машины. Адрес оригинального документа : http://old.hcs.cmc.msu.ru/lectures/AnalizeIT/Ch7_5.html
Дата изменения: Thu Jan 15 23:15:52 2004
Дата индексирования: Mon Oct 1 23:21:46 2012
Кодировка: Windows-1251
Часть VII - Синтаксис, типы, конструкции утверждений конформности  
Перейти в оглавлению раздела

Часть VII

7.5 Синтаксис, типы, конструкции утверждений конформности


    Как следует из рассмотренных выше определений системы понятий, важное место в методологии тестирования конформности POSIX отводится понятиям "спецификация метода тестирования" (test method specification) и "утверждение" (assertion).

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

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

    

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

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

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

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

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

    В этой нотации все утверждения должны иметь, по меньшей мере, три связанные с ними компоненты:

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

    Общая синтаксическая модель утверждения, названная структурой родового (Generic Assertion) утверждения изображается на Рис. 7.3.



Рис. 7.3 - Структура Родового Утверждения (Generic Assertion Structure)

    Квадратные скобки на рис. 7.3 означают, что заключенные в них элементы родового утверждения (вложенные в скобки "If" и "Else") необязательны. Таким образом, единственным элементом, присутствие которого обязательно, является Test_Text.

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

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

    Исполнение текста утверждений тестирующей системой SUT предполагается сверху вниз.

    Имена в скобках "<" и ">" называются символьными именами (symbolic names). Они определяют элементы синтаксического определения утверждений.

    Рассмотрим назначение основных синтаксических элементов родового утверждения.

  • For: Применяется, когда тело (текст) утверждения применяется к некоторому набору элементов. Он имеет сходство с циклическими конструкциями языков программирования. Если заголовок "For" содержит некоторый список элементов (например, функций и/или констант), то это равносильно применению тела утверждения к каждому элементу списка, подставленному в качестве значений параметров тела цикла. Заголовок "For" обычно используется при определении утверждений типа "general".
  • If Then Else: Конструкция 'If <precondition>, Then ... Else <outcome>' используется для задания условий применимости текста утверждения. Если предусловие поддерживается SUT или IUT, то логическое выражение, следующее за 'If', оценивается как ИСТИНА, а иначе как ЛОЖЬ. В последнем случае результат исполнения утверждения будет определяться альтернативной ветвью элемента 'If'.
  • Applicable Standard: Определяет базовые стандарты, которые применяются для тестирования данного утверждения. Если тестируемая реализация не поддерживает хотя бы один из требуемых в условии стандартов, тестирование данного утверждения бессмысленно.
  • Option: Определяет дополнительные возможности (опции) базового стандарта, которые должны быть включены в реализацию для тестирования данного утверждения.
  • Test Support: Определяет оборудование или программное обеспечение, не связанные с базовым стандартом, но необходимые SUT для тестирования данного утверждения.
  • Setup Requirements: Определяет действия или условия, которые необходимо выполнить перед началом тестирования для подготовки соответствующей среды. Если, хотя бы одно из таких действий или условий не обеспечивается, в качестве результата тестирования данного утверждения вырабатывается значение UNRESOLVED.
  • Test Text: Текст тестируемого утверждения. Утверждения формируются на основе требований стандарта так, чтобы каждое утверждение представляло собой независимую и законченную цель тестирования. Как правило, тест утверждения имеет следующую форму: <action> <result>.
  • Testing Requirements (TR): Определяет минимально допустимый уровень тестирования данного утверждения. Например, для тестирования некоторой операции над файлами данный раздел мог бы содержать указание того, для каких типов (или всех типов) файлов следует выполнять тестирование.
  • Notes: Дополнительная информация о методе тестирования.

    В методологии POSIX используются следующие типы утверждений:

  • Основной (Basic) - используется для представления одного или нескольких требований стандарта, относящихся к единственному элементу стандарта, например, функции или утилите;
  • Общий (General) - используется для представления утверждений, относящихся к нескольким элементам стандарта, при этом каждое утверждение данного типа разворачивается в ряд утверждений основного типа;
  • Ссылочный (Reference) - применяется для ссылок на уже существующие утверждения с целью исключения многократного дублирования одного и того же текста.
  • Документация (Documentation) - используется для представления требований конформности к документу, например, требования к структуре и формату документов или требование к документируемости свойств, зависящих от реализации;
  • Общая Документация (General Documentation) - используется для представления требований конформности к группе документов.

    Заметим, что состав типов может быть расширен.

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

    Для обозначения типа утверждения используются следующие соглашения:

  • Основной тип (Basic) - , т.е. обозначение типа не используется;
  • Общий (General) - "GA_";
  • Ссылочный (Reference) - "R_";
  • Документация (Documentation) - "D_";
  • Общая Документация (General Documentation) - "GD_".

    Примерами идентификаторов утверждений являются:

  • 10000
  • GA_stdC_proto_decl
  • D_5
  • R_err_fun
  • (2003.1-1997)GA_10

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

  • <Assertion_Identifier> - для основного типа (Basic);
  • <GA_Assertion_Identifier> - для общего типа (General);
  • <R_Assertion_Identifier> - для ссылочного типа (Reference);
  • <D_Assertion_Identifier> - для типа документация (Documentation);
  • <GD_Assertion_Identifier> - для типа общая документация (General Documentation).

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

  • Основной тип:
    <Basic_Assertion>::=
    <Assertion_Identifier><Generic_Assertion>
  • Общий тип:
    • a) Общее утверждение:
      <General_Assertion>::=
      <GA_Assertion_Identifier><Generic_Assertion>
    • b) Синтаксис утверждения (базового типа), выведенного из общего утверждения посредством подстановки в качестве параметров элементов из списка For:
      <GA_Assertion_Identifier><Generic_Assertion>
      See
      :<GA_Assertion_Identifier>
      /где элемент "See" добавляется, чтобы сохранить ссылку на текст исходного общего утверждения/
  • Ссылочный тип:
    <Reference_Assertion>::=
    <R_Assertion_Identifier><Generic_Assertion>[Setup: <Setup_Requirements>]
    Test:
    <Test_Text>
    See:
    <Assertion_Identifier>
  • Документация: <Documentation_Assertion>::=
    <D_Assertion_Identifier><Generic_Assertion>
    • Общая Документация:
      <General_Documentation_Assertion>::=
      <GD_Assertion_Identifier><Generic_Assertion>
    • Синтаксис утверждения (типа Документация), выведенного из утверждения типа Общая Документация посредством подстановки в качестве параметров элементов из списка For:
      <General_Documentation_Assertion>::=
      <GD_Assertion_Identifier><Generic_Assertion>
      See:
      < GD_Assertion_Identifier> /где элемент "See" добавляется, чтобы сохранить ссылку на текст исходного утверждения типа Общая Документация/

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

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

    Например,

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

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

M_GA_stdC_proto_decl(hdr,proto)=
     If PCTS_C_standard Then
        Setup: The header<hdr> is included.
        Test: The function prototype proto is declared

    Используя введенный макрос, можно было бы определить следующее общее утверждение, покрывающее различные объявления прототипов стандарта языка С.

    GA_stdC_proto_decl M_GA_stdC_proto_decl(header,synopsis_prototype)

    Введенный макрос может быть использован для введения утверждения с идентификатором 1, относящимся к конкретному элементу интерфейса, следующим способом:

    1 M_GA_stdC_proto_decl(semaphore.h,"int sem_init(sem_t *sem, int pshared, unsigned int value);")

Предыдущая глава Оглавление Следующая глава