Архитектура теста и метод теста, как правило, должны быть выбраны специально для требований, подлежащих испытанию, и не должны относиться к тем, которые, как правило, пригодны для других требований. Они могут быть даже теми требованиями, которые считаются недопустимыми для (стандартизированных) наборов тестов на проверку абстрактного соответствия, например, включающие конкретные методы реализации, используя, скажем, диагностические и отладочные средства из конкретной операционной системы.
Различие между поведенческими тестами и тестами на обследование разрешения соответствия нормам может быть проиллюстрировано на примере таких событий, как сброс. Поведенческие тесты могут включать только репрезентативный выбор условий, при которых может произойти сброс, и они могут не обнаружить некорректное поведение при других обстоятельствах. Тесты на обследование разрешения соответствия нормам ограничивались бы условиями, при которых некорректное поведение уже предположительно произошло, и они подтвердили бы, явились ли подозрения правильными или нет.
Тесты на обследование разрешения соответствия нормам подходят:
а) для обеспечения ответа «да / нет» в строго ограниченной и ранее идентифицированной ситуации (например, для того чтобы проверить, была ли конкретная функция правильно реализована в ходе развития реализации, или для того чтобы выяснить причину проблемы во время оперативного использования.
б) в качестве средства для идентификации и предложения решений для недостатков в текущем наборе тестов на обследование соответствия нормам.
Тесты на обследование разрешения соответствия нормам не подходят:
в) в качестве основы для вынесения оценки, соответствует ли или не соответствует реализация в целом.
Тесты на обследование разрешения соответствия нормам не стандартизированы. В качестве побочного продукта тестирования соответствия, могут быть выявлены ошибки и недостатки в частях протокола.
4.2.6 Интерпретация разделов / подразделов и положений
TCN (ПСС), описанное в МЭК 61375-2-1, является предметом интерпретации для перевода нескольких разделов / подразделов и требований в реализуемые наборы тестов. Сложность большинства протоколов TCN (ПСС) делает исчерпывающее тестирование непрактичным и на технических, и на экономических основаниях. Чтобы справиться с реальной реализацией и выполнить извлечения из МЭК 61375-2-1, были использованы все соответствующие испытания и некоторые критерии. Критерии были сгруппированы согласно их характеристикам:
а) императивы (содержащие указание на выполнение каких-то действий);
б) иллюстрации;
в) директивы (инструкция);
г) варианты (возможности);
д) слабые фразы
Следующие подразделы описывают критерии.
4.2.6.1 Императивы
Императивы - это слова и фразы, дающие команды о том, что должно быть обеспечено, и они классифицируются, как обязательные. К ним относятся:
а) shall / должен: предписывает предоставление функциональной возможности;
б) must / обязан: устанавливает требования к исполнению или ограничения;
в) is required / требуется: это описание (оператор описания), написанное в страдательном залоге;
г) is applicable / применяется: включает в себя, по ссылке, стандарты или другие документы, как дополнение к предписываемым требованиям;
д) responsible for /несет ответственность за: требование, написанное для уже определенных архитектур. В качестве примера,
"В расширенных приложениях задержки ответа, мастер («хозяин», задающее устройство, ведущий задатчик) несет ответственность за выделения пространства основным рамкам (кадр, фрейм), так что минимум времени выделяется для передачи подчиненного кадра (рамки), и следующий основной кадр (рамка) будет больше чем, T_safe Т_ безопасный.";
е) will / будет/должен: как правило, используется, чтобы цитировать те ситуации, которые операционная среда или среда разработок должны предоставить предписываемой возможности. Например, "Если это было сильное задающее устройство (сильный мастер), оно будет сигнализировать о своем понижении (перемещении) ко всем узлам, и оно будет оставаться в управлении шины, подобно слабому устройству, пока не будет назначен сильный узел."
ж) should / следует: при его использовании, утверждение с указанием (оператор описания) считается очень слабым.
Например, "Устройства, поддерживающие возможность данных сообщения, должны иметь адрес внешнего устройства меньше, чем 256. "
Продолжение
Фразы, которые следуют за императивом и вводят спецификацию утверждений (оператор описания) на более низком уровне, для дополнительного числа требований являются следующими:
з) как изложено ниже,
и) ниже,
к) далее,
л) в частности,
м) перечислены,
н) поддержка.
Фразы, которые вводят временную индикацию, что может привести к определенным или неопределенным действиям, или перечисления, которые могут привести к бесконечным тестовым случаям. Для примера, см. таблицу 2:
Таблица 2 – Постоянное показание
Положение | Пример | |
1 | для каждого | A PV_Set (Набор текущих данных) идентифицирует набор переменных, принадлежащих к одному и тому же набору данных, в том числе для каждой переменной в Memory_Address (адрес памяти), где он должен быть скопирован (или откуда), и в том числе для всего набора данных Freshness_Time. Свежесть_Время (Актуальность_Время) |
2 | в то время, как | При отправлении BD (бит/сек) пакетов, продюсер фильтрует входящие пакеты BR (bit rate – скорость передачи, выраженная в бит/сек) и начинает повторную передачу после ввода паузы передачи (PAUSE TMO в дополнение к нормальному SEND_TMO ОТПРАВИТЬ_ ТЕЛЕГРАФНОЕ ПЛАТЕЖНОЕ ПОРУЧЕНИЕ ТМО) |
1 Требование, содержащее временное или перечисленное, тестируется с конечным временем или с конечным образцом.
4.2.6.2 Иллюстрации
Эта информация содержится в документе с требованиями. Данные и информация, на которую указывает иллюстрация, усиливает спецификацию утверждений (оператор описания) документа и, всякий раз, когда возможно, используется как дискретный классифицированный входной сигнал в тест. А именно:
а) рисунок;
б) таблица;
в) пример;
г) примечание
4.2.6.3 Опции (варианты)
ОпцииЇ это категория слов, которые дают разработчикам широкий спектр в выполнении утверждений со спецификациями (описаний), которые содержат их.
Эта категория четко формирует основу для вариантных инструкций объявлений в PICS. Тем не менее, эти требования, содержащие такую категорию слов, ослабляют технические требования, увеличивают риск отказа от взаимодействия, и расширяют наборы тестов.
а) can / мочь (Пример: Шлюзы с возможностью шинного администратора (Bus_Administrator) могут синхронизировать шины);
б) may / мочь (Пример: устройства класса 5 могут предложить возможность шинного администратора Bus_Administrator);.
в) optionally / необязательно/ дополнительно (Пример: возможность, программируемый пользователь (User_Programmable) является необязательной/ дополнительной);
г) exclusion / исключение (Пример: в то время, как IUT (тестируемая реализация) называет узлы, один узел дает отклик на присваивание имени рамки (кадра), но не на запрос о состоянии, или посылает ответную рамку с неверным наименованием).
Опции должны запускать производство PICS.
4.2.6.4 Слабые утверждения
Слабые утверждения склонны вызывать неопределенность, оставляя место для различных интерпретаций, такая формулировка дает основание для расширения требований или добавления фьючерс требований. Для расширения тестирования, эта категория создает тест с тестовыми вариантами, выбранными из репрезентативного набора образцов. Тем не менее, такие наборы ни в коем случае в полной мере не представляют все значимые случаи, предусмотренные разделом в процессе тестирования. Они приведены в таблице 3:
Таблица 3Ї Слабые утверждения
Фразы с | Пример |
адекватный | Передатчик и коннектор (соединитель) приемника должны быть соответствующим образом (адекватно) идентифицированы, предпочтительно: • светло-серый для передатчика; • темно-серый для приемника. |
быть в состоянии | Канальный уровень, а также приложение должны быть в состоянии получить доступ к порту последовательно, т. е. записывать или считывать все свои данные в одной единой операции (в неделимой операции) |
быть способным | Устройство с двухпроводной линией подключения должно быть способно, присоединяться и к однопроводной линии и/или к сегменту двухпроводной линии |
эффективный | Субъект, который получает эффективные доступы к объектам на каждом уровне, называется субъектом уровневого управления, или LME |
нормальный | При отправке BD пакетов, производитель фильтрует поступающие BR пакеты и начинает повторную передачу после ввода паузы передачи (PAUSE TMO в дополнение к обычной SEND_TMO ОТПРАВИТЬ_ ТЕЛЕГРАФНОЕ ПЛАТЕЖНОЕ ПОРУЧЕНИЕ (TMO)). |
обеспечить | Уровень приложений для переменных (AVI) должен предусматривать для Cluster (кластер, блок, группа) доступа следующие примитивы, .. |
4.2.7 Отношение к взаимодействию (интероперабельности)
Одна из целей этого теста на соответствие состоит в том, чтобы привести к сопоставимости и расширить признание результатов испытаний, выполненных различными тестерами, и тем самым свести к минимуму необходимость в повторном тестировании на соответствие одной и той же системы. Взаимодействие играет главную роль, так как тест на соответствие направлен на содействие совместимости. Это было отображено в следующих областях в таблице 4:
Таблица 4 - Отношение к взаимодействию
Домен | Описание |
Применение совместимости | Способность TCN/ ПСС обеспечить последовательную реализацию синтаксиса и семантики данных, которые взаимозаменяемы |
Протокол совместимости | Способность TCN/ ПСС обменивать PDUs (протокольные единицы обмена) через коммуникационные платформы |
Обслуживание совместимости | Способность TCN/ ПСС поддерживать подмножество своих предполагаемых услуг |
Пользователь, воспринимающий совместимость | Способность пользователя услуг (человек, приложение, механизмы) к обмену информацией с помощью TCN/ ПСС |
Ни одно из положений в настоящем стандарте не выполнено для того, чтобы реализовать или рекомендовать тест на совместимость.
|
Из за большого объема этот материал размещен на нескольких страницах:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
