Часть VII

7.9 Методика написания утверждений

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

Проверку разделов с определениями терминов и понятий, используемых при определении требований конформности. В частности, особое внимание следует уделять фрагментам стандарта, в которых встречаются такие слова как shall, may, should, can, implementation-defined, undefined и unspecified. Например, слово shall используется в спецификациях POSIX и других международных стандартах для определения требований конформности. Часто для этих же целей используются слова may, should и can. Далее анализ раздела Conformance, в котором, как правило, определяются общие требования для рассматриваемого стандарта.
Выделение цветом каждое появление указанных выше терминов, которые потенциально могут формировать фрагменты текста, определяющие требования конформности в тексте стандарта, наряду с утверждениями, которые не используют данные ключевые слова, но имеют смысл утверждений (например, определение синтаксической структуры элемента).
Анализ выделенных фрагментов текста с целью выяснения являются ли они требованиями конформности.
Анализ фрагментов текста стандарта, в которых описываются дополнительные возможности или опции (так как требования конформности можно найти как среди основных требований стандарта, так и среди описаний дополнительных возможностей). По этой причине следует уделять особое внимание использованию ключевых слов may и shall.

В качестве простого примера рассмотрим следующее утверждение:

Реализация может делать A или B (The implementation may do A or B).

Это утверждение ничего не требует от реализации. Оно позволяет событиям A или B иметь место, но не может требовать того, чтобы произошло хотя бы одно из них. Реализация в праве осуществить одно, оба, ни одного или даже какое-то другое событие C.

Однако рассмотрим теперь другое утверждение:

Реализация может делать A или B.
Если A имеет место, тогда A1 должно…

или в оригинале:

The implementation may do either A or B.
If A occurs, then A1 shall…

Это утверждение является для реализации требованием конформности только в том случае, когда имеет место A.

Другой аспект, часто приводящий к затруднениям, - использование терминов unspecified и undefined. На первый взгляд они совершенно идентичны. Но это не так.

В стандартах PASC (Portable Applications Standards Committee), unspecified относится к поведению, являющемуся результатом использования правильных программных конструкций и правильных данных, тогда как undefined относится к поведению, являющемуся результатом использования неправильных программных конструкций и неправильных данных. Использование термина unspecified позволяет разработчикам стандарта разрешить неопределенное поведение правильным программным конструкциям. Напротив, undefined позволяет определенным ошибочным условиям иметь место и не требовать диагностики. И тот, и другой термин не должны повлечь за собой возникновение требования конформности. Они могут лишь вызвать потребность в документировании соответствующего поведения реализации.

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

A call to fopen() may cause the st_atime field of the underlying file to be marked for update

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

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

С другой стороны, если may используется для описания необязательных возможностей, позволенных стандартом, и при этом в описании используется слово shall, то такие shall-утверждения внутри may являются требованиями конформности. Например:

The implementation may do this...if it does, when this happens, the implementation shall...

(Реализация может делать так... Если она это делает, то, когда это происходит, реализация должна...)

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