Тестирование телеком-систем
•Download as PPTX, PDF•
0 likes•585 views
Каждый из нас пользуется мобильным телефоном и редко кто задумывается о том, что по другую сторону радиосигналов и проводов находится огромная система, которую тоже кто-то тестирует. Хотите узнать, как она работает? Хотите узнать, как происходит тестирование у операторов сотовой связи? Из доклада вы узнаете, как человечество пришло к существующим телеком-системам: из чего они состоят, как работают, что скрывается за мудреной аббревиатурой OSS/BSS. Вы узнаете, какие задачи выполняет отдел тестирования, какие используются стратегии и техники: может быть что-то вы можете использовать и в своей, не менее интересной, доменной области?»
Recommended
Recommended
More Related Content
What's hot
What's hot (11)
Similar to Тестирование телеком-систем
Similar to Тестирование телеком-систем (20)
Тестирование телеком-систем
- 1. Тестирование телеком-систем Вячеслав Лукьяненко, A1QA
- 8. Что такое OSS/BSS? OSS/BSS Core Network SGSN GMSC HLR AUC SMSC GGSN SMSG MSC Radio Access Network BTS BSC TRC TRC BSC BTS
- 9. Что такое OSS/BSS? • OSS: Operation Support System – Программный комплекс, созданный для управления большой сетевой инфраструктурой, соединяет отдельные подсистемы между собой • BSS: Business Support system • Программный комплекс, направленный на поддержку взаимоотношений компании с конечными пользователями.
- 10. Структура OSS/BSS Order Management SelfCare Stock Management Product Catalogues CRM Internet Customer Management Reporting Security Billing Raiting MSC Finance Management Payment Systems Resource Management IN Platforms
- 11. IT инфраструктура телеком-компании Бизнес IT отдел телеком внутри Проект компании компании • Разработка • Команда разработки- (конфигурирование, тестирования внутри настройка, мелкий телеком-компании девелопмент) • Сторонние IT компании • QA (приемка, тестирование своего • Компании-интеграторы девелопмента, ничего) • Компании-партнеры
- 12. Задачи разработки и тестирования 1. Внедрение новой функциональности в рамках системы 2. Внедрение новой платформы вне системы 3. Замена устаревшей системы более новой
- 13. Внедрение функциональности Production Pre-Prod Test-stand Local machine
- 14. Внедрение новой платформы Production Pre-Prod Test-stand Local machine
- 16. Ограничения 1. Время 2. Ресурсы 3. Люди
- 17. Техники тестирования Strategy = Scenario Testing + 0,5*Explaratory Testing 1. Разработка тестовой модели 2. Максимально возможная детализация тест- кейсов прямого пути 3. Постоянное обновление сценариев 4. Исследовательское тестирование по негативным и альтернативным сценариям
- 18. Количественное управление 1.2 Billing 1 Rating Payments 0.8 Stock Management Customer Management 0.6 Product Catalogues OrderManagement (OM) 0.4 Reporting Resource Management Security 0.2 SelfCare Customer Request Management 0 Rating апрель май июнь июль август сентябрь октбярь Функциональные метрики снимаются по каждой подсистеме выделено.
- 19. Тестирование телеком- систем, это… 1. Долго… 2. Дорого… 3. Сложно… 4. Интересно!
- 20. Спасибо за внимание! ВОПРОСЫ? E-mail: v.lukyanenko@a1qa.com Web: http://a1qa.com MSISDN: +375 29 739 51 51 Skype: Krylatyi
Editor's Notes
- Вначале было слово, и слово это было «Алло», произнесенное Александром Беллом в 1876 году. На самом деле он сказал нечто более нелицеприятное своему помощнику, который лишь с пятого раза верно замкнул провода, но мы будем считать , что начало телеком системам было положено здесь.
- Первые годы своего существования телефон был редкостью и позволял соединять лишь отдельно взятых абонентов по прямой линии. Однако время шло, телефон набирал популярность и возникла необходимость соединить в единую сеть абонентов одного города. Так появились первые компании, занимающиеся связью: они создавали единый коммутатор, к которому сходились все телефонные линии. Абонент снимал трубку, кричал в неё «Девушка! Абонента 1791 дайте!» и специально обученные телефонистки соединяли проводки и выписывали себе в записные книжки, кто кому звонил и сколько должен. Соответствующие счета выставлялись абонентамОднако случилось странное в одном американском городке, где жил и работал АлмонСтоуджер, владелец небольшого похоронного агентства. До определенного момента дела его шли неплохо, но потом Стоуджер начал замечать, как его обороты падают, а обороты его главного конкурента пропорционально растут. По какой—то причине, практически все заказы по телефону уходили к конкуренту Алмана. Расследование привело Стоуджера на телефонную станцию Канзас—сити, в которой, какой сюрприз, работала жена его главного конкурента. Ей звонили печальные люди и просили соединить их с ритуальным агентством. И эта хитрая женщина перенаправляла все вызовы своему мужу.Для того, чтобы сохранить свой бизнес, ему нужно было устранить телефонистку. Жалобы телефонному начальству не привели ни к чему, и казалось, что единственное решение проблемы — убить телефонистку или ее мужа, а лучше обоих сразу. Но Стоуджер не был преступником, по духу он был честным инженером. Поэтому, свою ярость он направил в создание замены таких вот женщин на автоматы. Раз проблема в телефонистке, думал Стоуджер, нужно придумать механизм, который заменял бы труд этой самой телефонистки. И что самое интересное Стоуджер создал этот механизм и назвал его шаговый искатель. Вот так личная драма, переросла в скачок развития телекоммуникационных систем. .
- Для коммутации можно было перестать использовать людей, но как быть с вставлением счета за предоставленные услуги? Каждый отдельный звонок регистрировался на отдельную ленту, которые собирались людьми в белых рубашках и тщательно заносились все в те же абонентские книги, подсчитывалась стоимость звонка от абонента А, абоненту Б, а затем выставлялись счета абонентам.
- Рождение первых серьезных телеком-систем произошло в тот момент, когда логику коммутации и правил подсчета стоимости догадались хранить на отдельных запоминающих устройствах. Это облегчило всеобщую интеграцию различных городов в глобальную сеть, да и «белым воротничкам» теперь нужно было лишь выписать конечную стоимость звонка, не проводя ночи напролет над тоннами бумажек с арифмометром в руках. Однако образовались и проблемы: если выходил из строя модуль отвечающий за подсчет, коммутация становилась невозможной — приходилось полностью заменять оборудование. А тут еще и абоненты скандируют «Сервисы! Сервисы! Хотим новых сервисов!».
- Производители коммутационного оборудования напряглись и родили очередную умную мысль - логика предоставления сервисов и подсчет их стоимости могут быть вынесены за пределы коммутатора! Логика будет жить на отдельном applicationserver-е, к которому коммутатор будет обращаться с просьбой "что-то сделать". Так родились Intellegence Network платформы.
- Казалось бы, не жизнь, а сказка: но и тут была загвоздка: попробуй-ка, сведи вместе информацию о всех услугах, предоставленных абонентам, да еще и проследи, чтобы оборудование, с которым работает оператор связи находится в строю, работает верно, да еще и обновлять его можно. Необходим был единый центр. Так появились системы семейства OSS/BSS, которые в данный момент использует каждый оператор связи, о тестировании которых и пойдет речь далее.
- Архитектурно систему можно разделить на три части: сеть радиодоступа (Radio Access Network), центральная сеть (Core Network) и OSS/BSS система. Сеть радиодоступа формирует покрытие мобильного оператора, так называемые «соты», она включает в себя вышки базовых станций, контроллеры и транскодеры. Её основная задача — передача информации от абонента к коммутатору. Центральная сеть обеспечивает коммутацию и непосредственное предоставление услуг: аутентификация абонента в сети, создание интернет-сессии, хранение и передача коротких сообщений.Задачи OSS/BSS давайте рассмотрим на примере.Предположим, вы только что заключили договор с оператором связи и первый раз включаете свой телефон. Телефон посылает радио-сигнал на базовую станцию (BTS), он попадает на контроллер базовой станции (BSC), затем через траснкодер сигнал поступает на коммутатор. Коммутатор в свою очередь опрашивает домашний регистр (HLR) о текущем состоянии абонента. Естественно тот скажет «Не знаю такого». Регистр обращается в OSS/BSS, чтобы узнать, какие услуги вам доступны, с кем вы можете установить связь. И лишь после этого он проводит аутентификацию в AuCи присваивает вашему номеру статус IDLE, мол, доступен в сети и ждет подключения. Здесь OSS/BSS выступает в качестве динамически обновляемого хранилища данных: ваш баланс, ваше имя, ваш пол и ваш номер паспорта хранятся здесь. Так система выполняет функции поддержки бизнеса.А теперь представим, что вы решили отправить СМС или выйти в интернет. Сделать это вы можете с помощью IN-платформ SMSC и SGSN, соответственно. Чтобы создать соединение, они обязаны выполнить сверку, являются ли ваша сим-карта и номер валидными: происходит так называемое ресурсное управление. Такой запрос является примером выполнения функций операционной поддержки.
- Если обобщить, мозг телеком-системы делится на две существенные части:BSS (Business Support System) — комплекс программных средств, направленных на поддержку взаимоотношений компании с конечным пользователем: например, управление заявками, управление счетами, управление платежами и т.п.OSS (Operation Support System) — комплекс программных средств, направленны на управление сетевой инфраструктурой: например конфигурирование сетевых компонентов, управление сетевыми ресурсами, управление сбоями и т.п.
- Вполне естетвенно, что системы, выпущенные различными компаниями, будут отличаться архитектурой, однако мы можем выделить несколько основных подсистем характерных для OSS/BSS семейства:BillingПодсистема, отвечающая за долгосрочную обработку пользовательских активностей. Подсистема «подводит итог» по действиям абонента за период (т.н. биллинговый период) и выставляет счет к оплате. Счет может быть погашен автоматически, если абонент препейдный (оплатил все по факту и имеет положительный баланс) или после оплаты (для постпейдов). Реализуется как компонент, не видный глазу и работающий в пассивном режиме. Должна быть устойчива к отказам и к ошибкам других систем. RatingПодсистема, отвечающая за тарификацию Just In time или «по факту» в зависимости от типа абонента. Компонент проводит тарификации, как разовых услуг (подключение услуги, плата за замену сим и т.п.), периодических услуг (абонентская плата, обязательная плата за трафик), а также плата за непосредственное использование сети (звонок, смс, интернет-сессия). PaymentsПодсистема, отвечающая за обработку платежей от различных внешних систем (банковские системы, системны онлайн-платежей и т.п.). Корректирует информацию в системе о текущем балансе абонента. «Гасит» выставленные биллингом счета. Stock ManagementПодсистема, отвечающая за хранение информации о физическом размещении элементов мобильной сети (сим-карты, оборудование): то есть, у какого продавца, сколько и какие элементы хранятся для последующей продажи (например, СЦ «Евросеть» - отд. 115: 15 сим-карт, 2 предоплаченных модема) Customer Management Подсистема, отвечающая за хранение данных абонента: имя\\название организации, реквизиты (номер паспорта, ИНН, КПП и т.д), его текущий тарифный план, список подключенных услуг. Отдает эти данные по запросу в другие системы. Product CataloguesПодсистема, отвечающая за хранение данных о продуктах системы и тарифах за их использование: тарифные планы, услуги. Отдает эти данные рейтингу для проведения тарификации, биллингу для подведения счетов, репортам для составления отчетов. OrderManagement (OM)Компонента, контролирующая корректную обработку заявок пользователей и корректность прохождения бизнес-процесса через все необходимые компоненты. Нотифицирует операторов в случае возникновения ошибки на этапе исполнения заявки (бизнес-процесса). ReportingПодсистема, отвечающая за построение отчетов по заданным шаблонам. Сюда входят как статистические данные по работе системы, так и стандартные письма с месячным счетом, которые отправляются абоненту. Т.о. основное назначение — сбор и представление информации в удобочитаемом формате на любую тематику. Resource ManagementПодсистема отвечающая за учет и связывание различных ресурсов: номерные ёмкости, симки, элементы сети (HLR, SMSCetc.). Также выполняет функции провижионинга элементов сети, управления сбоями. SecurityКомпонент, распределяющий права пользователей внутренней части системы (т.н. операторы OSS/BSS), например операторы региона г. Минск, видят в CRM пользователей только своего региона. SelfCareСистема самообслуживания абонента: ИССА, Голосовое меню (IVR), USSD-сервисы. Обеспечивает возможность самостоятельного управления сервисами подключенных абоненту: смена тарифного плана, подключение\\отключение услуг. Customer Request ManagementКомпонент, отвечающий за взаимоотношения с пользователями: обеспечивает обработку запросов пользователей операторами сервисных центров и службы поддержки.
- Первый тип задач, с которым приходится сталкиваться IT-отделам компаний операторов сотовой связи — улучшение текущей функциональности. Предположим, мы хотим дать нашим абонентам возможность, находясь в странах по их выбору, звонить по льготному роуминговому тарифу. Вроде задача не такая уж и сложная, нет необходимости внедрять новое оборудование, достаточно доработать существующую систему. Посмотрим внимательнее, что нам нужно сделать:Во-первых, необходимо доработать Product catalogue, т.к. по сути, мы добавляем новую сущность, ранее неизвестную системе;Во-вторых, нужно научить Raiting взаимодействовать с новой сущностью, выполнять тарификацию по новым правилам;В-третьих, Billing должен понимать, что же нам насчитал рейтинг и почему;В-четвертых, нужно рассказать Customer Management-у, что у нас появились новые услуги и дать описание подключенной услуги из Product Catalogue;В-пятых, нужно дать CRM и SelfCareинтерфейсы для подключения нового типа услуг;В-шестых, нужно модифицировать логику бизнес-процесса подключения услуг в Order Management, чтобы эта подсистема не растерялась, когда увидит нечто новое;И в-седьмых, необходимо доработать существующие отчеты и добавить новый, собирающий статистику по новой услуге.Вот так, простая задача, казалось бы, превращается в трудозатраты разработчиков половины существующих подсистем. Как же мы будет тестировать?Как правило, тестирование многоэтапное:На первом этапе изменения в каждой подсистеме тестируются выделено: сервера с подсистемами окружаются «заглушками» со стандартными ответами, в конфигурационные файлы ссылки на внешние интерфейсы заменяются ссылками на локальные файлы. Система тестируется до исправления всех ошибок 1-3 приоритетов.На втором этапе система соединяется в единое целое: все сервера настраиваются на единую базу данных, как правило, мигрированную с реальной платформы, происходит конфигурирование системы. Тестирование проводит тестирование интеграции подсистем, проверку конфигурации, а также полный функциональный тест затронутых бизнес-процессов, например: создание услуги «Любимая страна: Украина», подключение услуги абоненту, тарификация звонка из Украины. Тестирование завершается в тот момент, когда не остается дефектов 1-3 приоритетов. Цель тестирования на данном этапе — убедиться, что функциональность полностью соответствует требованиям.Третий этап начинается с того, что систему собирают на preprod-платформе, которая представляет из себя точную копию production-платформы. На этом этапе прогоняется полный регрессионный тест по разработанным сценариям и авто-тестам, а также проводится тестирование производительности. Цель тестирования на данном этапе — убедиться, что конфигурация собрана верно, а новая функциональность не испортила показатели общей производительности системы.Наконец, на четвертом этапе, функциональность устанавливается на Production-платформу. Как правило, это происходит во время спада клиентской активности: с 6 до 11 часов субботы или воскресенья. Проводится UAT-тестирование на тестовых абонентах. В случае успешного прохождения UAT — функциональность делают доступной всем абонентам и операторам CRM.
- Второй тип задач, который руководство может поставить перед вами: внедрение новой внешней платформы, не предусмотренной вашей системой. Примером такой задачи может служить внедрение технологии Mobile Number Portability (MNP): кратко, это технология, которая позволяет сохранить номер мобильного телефона при смене оператора сотовой связи. Внедрение технологии происходит на уровне внешних систем, однако точно также требует доработки внутри системы:Resource management — чтобы научиться хранить ресурсы принадлежавшие ранее другим операторам связи;CRM — чтобы научиться подключать/отключать таких абонентов;Order Management — доработать процесс обработки абонентских заявок, чтобы система на «удивлялась странным номерам»;Reports — учитывать в отчетах необычные номера.Тестирование такого типа задач мало чем будет отличаться от первого типа. Существенное отличие будет лишь в том, что на тестирование будет уходить меньше времени: так как основная функционирующая часть за пределами системы, наша функциональность играет лишь сопровождающую роль.
- Сложнее дело обстоит с задачами третьего типа. Вновь представьте себя руководителем компании: ваш маркетинг «жжот», у вас стабильная репутация и с каждым годом все больше и больше абонентов подключается к вам. Вот их становится уже более 5 миллионов… И вы начинаете замечать на форумах и в бложиках жалобы на то, что где-то ваша компания кого-то «обсчитала», где-то уже третий день не работает симка, где-то «пропала связь на полдня». Вы начинаете копать, в чем же проблема и обнаруживаете: а ведь ваша OSS/BSS безбожно устарела.Можно поставить костыли, переписать какую-либо подсистему чтобы она работала шустрее, это проще, дешевле, да и быстрее. Но вы же хороший руководитель! Вы решаете избавиться от устаревшей системы и перевести своих абонентов на новую OSS/BSS. Вы покупаете её у какого-нибудь производителя (благо таких немало: от отечественных продуктов Sitronicsдо NGOSS решений от титана HP) и пытаетесь имплементировать у себя. Что же делают ваши тестировщики?Вначале они тестируют ваши требования. Это не удивительно: требования к огромной системе собираются у нескольких десятков заинтересованных лиц, тех кто каждый день использует существующую систему. Даже лучшие бизнес-аналитики не могут избежать ошибок и противоречий в документации. Кроме того, задачей тестирования является сверка текущих требований к системе с документацией закупленной системы. Это помогает выявить функциональность, требующую архитектурной переработки на начальном уровне.После успешной интеграции системы в тестовое окружение начинаются сразу три типа тестов:Тестирование функциональности — проводится на тестовом стенде, заключается в тестировании законченных end-to-end сценариев, как правило — наиболее используемых бизнес-процессов. Части, которые были значительно переработаны подвергаются детальному тестированию.Тестирование конфигурации — также проводится на тестовом стенде, заключается в проверке настроек каждого из модулей: например, длительность нахождения ресурсов в карантине после расторжения контракта. Все найденные дефекты заносятся в отдельную конфигурационную ветку, которая мержится с общей функциональностью при поставке билда (очевидно, что изменения конфигурации происходят постоянно, цель отдельной ветки — сохранение верной конфигурации до последнего билда).Тестирование миграции данных — проводится на тестовом стенде, заключается в сверке результатов миграции данных из одной системы в другую по заданному маппингу. Также сверяется между собой результаты массовой тарификации событий: например, загружаем те же самые данные в новую систему, что уже обработала старая — сверяем значения по заданным критериям и получаем критерии качества работы системы на основании численных метрик качества данных.Затем, после стабилизации функциональности, приходит пора тестирования производительности: на точной копии Production-платформы происходит сбор метрик по различным параметрам: количеству обрабатываемых за период звонков, длительности обработки одного звонка, длительности формирования и т.п. Этот этап является наиболее критичным при внедрении новой системы: малейший дефект в производительности — означает возврат системы на доработку.Очевидно, что ограничения у нас будут те же, что и при тестировании новой функциональности: время, ресурсы и люди.
- Такая нехитрая схема, естественно имеет ряд ограничений:Время: каждая отдельная подсистема имеет большой функциональный вес: чтобы разобраться в ней и протестировать изменения с достаточным покрытием, необходимо большое количество времени. Работы тестирования на задачу описанную выше составили бы около 800 часов.Ресурсы: чтобы выполнить тест, необходимо серьезное оборудование. По сути, необходим как минимум дубликат реальной платформы (а это уже, как минимум, ряд дорогостоящих компьютеров с 64-ядерными процессорами и 256 Гб оперативной памяти (например, на платформе HP Superdome)), а также две линии тестового окружения для модульных и интеграционных тестов.Люди: нельзя просто так взять и протестировать систему. Количество входных параметров превышает возможности человеческого мозга, а чтобы знать, что нужно тестировать — необходимо разбираться в доменной области. Именно поэтому новые тестировщики, вовлекаются в проект долго: проходят через руки старших тестировщиков, интеграторов, разработчиков и даже пользователей.
- Любой из типов проектов описанных выше — длительный, ресурсоёмкий и нуждается в тщательном сопровождении. Именно поэтому, чаще всего используется техники тестирования по сценариям. Однако и здесь есть свои особенности:Разработка тестовой модели проводится исключительно в тест-трекинговых системах, где можно управлять качеством разработанных кейсов. Прекрасно, если используется HP QC со встроенным баг-трекером для тестов, или же при наличии прямых рук можно смело допилить и использовать под свои нужды TestLinkили любую другую бесплатную тест-трекинговую систему;Тест-кейсы разрабатываются с максимальной детализацией и техническим выкладками: если нужно найти какую-либо информацию в БД — прикладывается скрипт, если необходимо запустить какой-либо процесс — описывается, как и с какими параметрами его необходимо запускать. Это необходимо, так как сценарии вероятнее всего будут использоваться годами и скорее всего не только для тестов, но и для обучения новых тестировщиков или пользователей системы.Большое внимание уделяется актуализации кейсов: каждая новая функциональность, требует пересмотра всех сценариев. Причина в том, что проще регулярно исправлять ряд сценариев после каждой доработки, чем спустя год понять, что тестовая модель устарела и должна быть переписана почти с нуля.
- Однако использование сценариев не означает, что тестировщик всегда идет строго по ним. Сценарии идентифицирует, как правило, прямой путь прохождения бизнес-процесса, потому все специфические вещи: негативные сценарии и альтернативные ветки тестировщик проверяет в режиме «свободного полета». Обязательным является проверка базовых сценариев, именно на их основании снимаются метрики качества и готовности продукта к запуску. Метрики снимаются по каждой подсистеме выделено, так как совокупная метрика может содержать ошибки в сопроводительных частях приложения (например, в системе отчетности) и общий отчет существенно исказит реальную готовность продукта к запуску.
- Тестирование телеком это: долго, дорого и сложно. Каждый дефект имеет повышенное значение с точки зрения бизнеса, потому тестирование проводится с особой скрупулёзностью и дотошностью. Однако системы семейства OSS/BSS — непаханое поле для улучшения своих навыков, как в тестировании, так и в технических вопросах. Если вы хотите «прокачаться» – добро пожаловать в тестирование телеком-систем!