Главная  Новые телекоммуникационные услуги 

[0] [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] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] [49] [50] [51] [52] [53] [54] [55] [56] [57] [58] [59] [60] [61] [62] [63] [64] [65] [66] [67] [68] [69] [70] [71] [72] [73] [74] [75] [76] [77] [78] [79] [80] [81] [82] [83] [84] [85] [86] [87] [88] [89] [90] [91] [92] [93] [94] [95] [96] [97] [98] [99] [100] [101] [102] [103] [104] [105] [106] [ 107 ] [108] [109] [110] [111] [112] [113] [114] [115] [116] [117] [118] [119] [120] [121] [122] [123] [124] [125] [126] [127] [128] [129] [130] [131] [132] [133] [134] [135] [136] [137] [138] [139] [140] [141] [142] [143] [144] [145] [146] [147] [148] [149] [150] [151] [152] [153] [154] [155] [156] [157] [158] [159]

Процедуры координации тестирования

Верхний тестер

ASPs

Тестируемая реализация (IUT)

ASPs PDUs

Нижний тестер

Рис. 4.4.1 Концептуальная архитектура тестирования

В тестере выделяются две части, именуемые нижним и верхним тестером. Нижний тестер (LT) абстрактно определяется как средство, которое в процессе тестирования воздействует на тестируемую реализацию и наблюдает за ней в РСО, находящейся на нижней границе этой реализации. Определяемый подобным образом верхний тестер (UT) взаимодействует с тестируемой реализацией в РСО на верхней границе этой реализации. При необходимости верхний и нижний тестеры взаимодействуют между собой с помощью процедур координации тестирования (TCP - Test coordination procedures).

Нижний тестер сложнее верхнего, поскольку он выполняет функции контроля и наблюдения за протокольными блоками данных (PDU - Protocol data units). Эти блоки являются частями абстрактных примитивов ASP, которые нижний тестер передает и принимает во время выполнения теста.

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

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



зации, либо извне, например, через звено ОКС-7. Для тестирования реализаций открытых систем определены следующие четыре категории методов:

a) методы локального (local) тестирования;

b) методы внешнего распределенного (external distributed) тестирования;

c) методы внешнего координированного (coordinated) тестирования;

d) методы внешнего дистанционного (remote) тестирования.

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

4.4.2 Архитектура и методы тестирования INAP

Стандартом ETS 300 374-9 для тестирования INAP предлагаются метод внешнего распределенного и метод дистанционного тестирования. Первый метод основан на использовании в верхнем тестере таких тестовых сценариев, которые предусматривают считывание из базы данных определенных параметров, интерпретируемых затем в действиях протокола. База данных может быть частью SCP. Преимущество этого метода состоит в том, что он не требует использования логики услуг и, следовательно, оборудования SCEP, когда нужно модифицировать тестовый сценарий. Недостатком метода является использование специального протокола передачи информации, необходимой для конфигурирования базы данных в соответствии с тестовым сценарием.

При использовании второго метода тестовые сценарии состоят из поставляемых в составе SCP элементарных программ SLP, выполняю-



щих задан ную последовательность операций INAP. Активизация и выбор SLP производится либо вручную командами MMLc консоли оператора, либо на основе значения параметра Called Party Number в принятой операции InitialDP. Метод дистанционного тестирования представляется более предпочтительным по той причине, что специальный протокол обмена информацией для координации тестирования оказывается ненужным, так как в качестве такого протокола выступает сам INAP (совместно с TC/SCCP/MTP), связывая нижний и верхний тестеры. Кроме того, этот метод обеспечивает полную автоматизацию процесса тестирования. На рисунке 4.4.2 приведена конфигурация включения средств тестирования для проверки SCP, представляющая собой модификацию концептуальной архитектуры тестирования применительно к протоколу INAP.

Тестирующая система (TS)

Нижний тестер:

Симулятор SSP

LT-PCO

(TC-ASPS+ INAP-PDUs)

Процедуры координации тестирования

Тестируемая система (SUT) SCP

Верхний тестер


Тестируемая реализация (IUT)

INAP

МТР/5ССРДСАР

Рис. 4.4.2 Архитектура тестирования протокола INAP в SCP

Задачи тестирования протокола INAP в интерфейсе SCF-SSF/SRF требуют наличия в SCP дополнительных функций, определенных в виде программ логики услуг, которые предназначены специально для тестирования. В качестве тестирующей системы может использоваться либо реальный SSP/IP, либо симулятор. Использование реального SSP/IP позволяет тестировать обе стороны интерфейса одновременно. Однако с помощью реального SSP/IP не всегда можно выполнить все тесты, например, из-за того, что отсутствует возможность передавать сообщения, содержащие синтаксические ошибки. Преимущество использования симулятора состоит еще и в том, что он дает возможность полностью автоматизировать рутинную процедуру выполнения сотен тестовых сценариев.

В зависимости оттого, насколько детально проверяется с помощью некоторого набора тестов соответствие реализации протокола ВОС его спецификациям, различаются четыре типа тестирования:



[0] [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] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] [49] [50] [51] [52] [53] [54] [55] [56] [57] [58] [59] [60] [61] [62] [63] [64] [65] [66] [67] [68] [69] [70] [71] [72] [73] [74] [75] [76] [77] [78] [79] [80] [81] [82] [83] [84] [85] [86] [87] [88] [89] [90] [91] [92] [93] [94] [95] [96] [97] [98] [99] [100] [101] [102] [103] [104] [105] [106] [ 107 ] [108] [109] [110] [111] [112] [113] [114] [115] [116] [117] [118] [119] [120] [121] [122] [123] [124] [125] [126] [127] [128] [129] [130] [131] [132] [133] [134] [135] [136] [137] [138] [139] [140] [141] [142] [143] [144] [145] [146] [147] [148] [149] [150] [151] [152] [153] [154] [155] [156] [157] [158] [159]

0.0014