Тестирование софта - статьи


Проблемы тестирования мобильного узла и способы их решения - часть 6


В предлагаемом подходе для различных групп требований предусмотрены три группы действий:
  1. Обязательные действия (obligated) - для требований, обязывающих мобильный узел отправить определенное сообщение (требования, выделенные словами MUST или SHOULD согласно RFC2119). Если тестируемая реализация отправляет такое сообщение в отведенный временной интервал, то сообщается о том, что ее поведение в данном случае удовлетворяет требованию спецификации, которое определяет данное действие. В противном случае выносится вердикт о том, что тестируемая реализация не выполнила данное требование. Для этой группы требований можно задавать альтернативные варианты действий. То есть задаются несколько возможных сообщений для одного требования, и если реализация отправляет одно из таких сообщений, условия требования считаются выполненными.
  2. Запрещенные действия (prohibited) - для требований, запрещающих мобильному узлу отправлять определенное сообщение после наступления какого-либо события (требования, выделенные словами MUST NOT или SHOULD NOT). Если данное сообщение было отправлено в выделенный временной интервал, то выносится вердикт о том, что тестируемая реализация нарушила данное требование. В противном случае сообщается о том, что она выполнила требование, определяющее данное действие.
  3. Допустимые действия (allowed) - для наблюдения за тем, что мобильный узел реализует некоторую необязательную функциональность протокола (требования, выделенные словом MAY). Если данное сообщение отправлено в отведенный интервал времени, то сообщается о том, что тестируемая реализация поддерживает необязательную функциональность, которая определяется данным требованием. В противном случае ничего не сообщается.

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

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


Начало  Назад  Вперед



Книжный магазин