Тестування телекомунікаційного домену за допомогою зразків тестових випадків OSS/BSS

Що таке телекомунікаційне тестування?

Тестування телекомунікацій визначається як тестування телекомунікаційного програмного забезпечення. З моменту переходу телекомунікаційного сектору до цифрових та комп'ютерних мереж, телекомунікаційна галузь використовує програмне забезпечення незамінно.

Телекомунікаційний сектор залежить від різних типів програмних компонентів для надання послуг, таких як маршрутизація та комутація, VoIP та широкосмуговий доступ. Отже, тестування телекомунікаційного програмного забезпечення є неминучим і охоплює апаратні компоненти, серверні системи та фронтенд-додатки.

Приєднуйтеся до нашого проекту Live Telecom Testing безкоштовно

Що таке домен у тестуванні?

Перш ніж описувати будь-який телекомунікаційний сценарій, термін «домен» потребує визначення.

Домен – це не що інше, як галузь, для якої створюється проект тестування програмного забезпечення. Коли ми говоримо про програмний проект або розробку, часто маємо на увазі цей термін. Наприклад, домен страхування, банківський домен, домен роздрібної торгівлі, домен телекомунікацій тощо.

Як показано на ілюстрації, один тестувальник може працювати в кількох таких галузях промисловості. Зазвичай, під час розробкиping Для будь-якого конкретного доменного проекту потрібна допомога експерта з предметної області. Експерт з предметної області є майстром у своїй галузі, і він може знати продукт або програму зсередини.

Чому тестування знань предметної області має значення?

Знання предметної області є квінтесенцією для тестування будь-якого програмного продукту, і воно має свої переваги, як підсумовано на діаграмі нижче.

Тестер, який розуміє тарифи, правила взаємоз’єднання та стани забезпечення, розробляє реалістичні сценарії та виявляє граничні випадки, які може зазнати загальний тестовий випадок бібліотека ніколи не покриває.

Бізнес-процеси в телекомунікаційній галузі

Знання предметної області тут починається з бізнес-процесів, які здійснюють надання послуги від продажу до виставлення рахунку-фактури.

Для тестування телекомунікаційних систем важлива наскрізна перевірка послуг. Для забезпечення ефективного тестування обов'язковим є добре розуміння різних бізнес-процесів.

Перш ніж складати тестові приклади, вам потрібно зрозуміти кожен етап надання послуг.

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

У наступній таблиці показано, які дії виконуються на різних рівнях.

Відділ зв'язку	Телекомунікаційна діяльність
Попередній продаж	Він обробляє всю інформацію про продажі, як-от знижки, послуги, акції тощо.
замовлення	Подання заявки на нове підключення або розрив підключення
Резервування	Цей підрозділ займається фізичним зв’язком між клієнтами та TSP (постачальником телекомунікаційних послуг).
BillІНГ	За цим підрозділом виконується вся робота з виставлення рахунків
Забезпечення обслуговування	У разі будь-якої несправності цей підрозділ усуває проблему
Системи інвентаризації	Це сховище всієї інформації
Tracking	Цей відділ tracсистема замовлень та статус замовлення

Типовий бізнес-процес телекомунікацій

Щойно ці відділи будуть чітко визначені, наступним кроком буде спостереження за тим, як одне замовлення фактично переміщується між ними. Нижче наведено типовий бізнес-процес у телекомунікаційній галузі.

Як показано у наведеному вище потоці, запит переходить від етапу передпродажу до етапу замовлення, потім підготовки та, нарешті, виставлення рахунків. Кожна передача є межею інтеграції та цінною метою для тестування від початку до кінця.

Типи протоколів, що використовуються в телекомунікаційній галузі

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

• Технології VoIP: VoIP, IMS, MPLS, ISDN, PSTN
• Signalінг і протоколиSIP, ISDN, Codecs, H.323
• Бездротові технології: GPRS, CDMA, GSM, UMTS
• Управління мережею: SNMP
• Протоколи рівня 2: ARP, STP, L2TP, PPP
• Протоколи/маршрутизація рівня 3: ICMP, BGP, ISIS, MPLS
• Інфраструктура/безпека: ATM, TCP/IP, LAN/VLAN, SSH

Ви можете дізнатися більше про тестування протоколу тут

Тестування LifeCycle в телекомунікаційній галузі

Завдяки відображенню процесів і протоколів роботу можна організувати в життєвий цикл. Життєвий цикл тестування в телекомунікаційній галузі подібний до життєвого циклу будь-якої іншої галузі, але з акцентом на деталях. Ось як виглядає життєвий цикл тестування разом з артефактами тестування.

Телеком етап тестування	Тестові артефакти
Business View	Тестові артефакти на основі вимог Артефакти на основі здійсненності Тестові артефакти на основі ідентифікації стандартів і політик Operaції та технічного обслуговування, пов’язані з тестовими артефактами
система/ Archiтектура	Артефакти тестування системи (безпека, встановлення) Тестуйте артефакти для віртуального прототипу спеціальний Тестування системи артефакти (сумісність, аварійне відновлення)
Реалізація	Артефакти модульного тестування Артефакти тесту інтеграції Артефакти якості та продуктивності Регресія, тестування навантаження, розумність тощо.
розгортання	Артефакти приймального випробування Артефакти тесту інтеграції Артефакти якості та продуктивності Артефакти функціонального тесту Альфа/бета-тестові артефакти

Типи тестування програмного забезпечення Telecom

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

• Тестування з'єднань
• Тестування відповідності
• Тестування IVR
• Тестування продуктивності
• Тестування безпеки
• Тестування сумісності
• Тестування протоколу
• Функціональне тестування
• Тестування автоматизації

Як писати ефективні тестові кейси для телекомунікацій

Знання процесів – це лише половина справи. Самі кейси мають бути написані так, щоб будь-який тестувальник у команді міг їх виконати без знання племені. Наведені нижче кроки однаково застосовуються як до області застосування OSS, так і до області застосування BSS.

1. Залишайте один бізнес-процес на кожен пакет. Розділити пакети замовлень, підготовки та виставлення рахунків, щоб збій вказував на єдину систему-власника, а не на неоднозначний ланцюжок їх.
2. Запишіть передумову як дані, а не прозу. У справі вкажіть точний статус абонента, тарифний план, кредитний ліміт та баланс рахунку, оскільки дефекти телекомунікацій зазвичай є дефектами стану даних.
3. Враховуйте межі рейтингу та стягнення плати. Вичерпання безкоштовних хвилин, поновлення плану опівночі, перемикання роумінгових тарифів та пропорційне підвищення тарифного плану – це моменти, де найчастіше ламаються механізми виставлення рахунків.
4. Додайте негативний варіант для кожного позитивного випадку. Недійсна довжина номера, заборонений абонент, дублікат замовлення та невдалі зворотні виклики підготовки заслуговують на власний очікуваний результат.
5. Перевіряйте далі, не лише на екрані. Замовлення на забезпечення є правильним лише тоді, коли запис CRM, запис інвентаризації, мережевий елемент і медіаційний канал узгоджуються між собою.
6. Додайте вимірний очікуваний результат. Таке твердження, як «рахунок правильний», не може бути виконане, тоді як «загальна сума рахунку-фактури дорівнює 249.00, включаючи 18-відсотковий податок» може.
7. Позначте кандидати регресії. Позначте кожен випадок, що стосується рейтингу, оподаткування та взаємозв'язку, щоб він входив до кожного циклу випуску. регресійне тестування.

Зрештою, перед тим, як визначити базовий варіант, перегляньте кожен випадок з аналітиком з питань виставлення рахунків або мережевим інженером. Правила телекомунікаційного бізнесу змінюються з кожним запуском тарифу, і випадок, який все ще кодує акцію минулого кварталу, місяцями повідомлятиме про хибні збої.

Зразки тестових випадків для тестування телекомунікацій

Застосування цих правил створює набір, подібний до наведеного нижче. У тестуванні телекомунікацій необхідно враховувати наступне тестування

Тестування різних телекомунікацій	Тестування діяльності в Telecom
BillСистема	Перевірте, чи номер телефону клієнта зареєстровано на оператора зв'язку Перевірте, чи номер все ще працює Переконайтеся, що введене число є дійсним і складається з 10 цифр Переконайтеся, що номер не заблоковано з певних причин Перевірте, чи є на номері неоплачені рахунки, якщо такі є, відобразіть їх на екрані Переконайтеся, що всі попередні облікові записи чи рахунки сплачені за номером Переконайтеся, що система дозволяє генерувати звіти відповідно до вимог замовника Переконайтеся, що система точно записала кількість дзвінків Перевірте, чи план, вибраний клієнтом, відображається в білінговій системі Переконайтеся, що загальна виставлена ​​сума є точною та відповідає пропонованій послузі
Тестування додатків	Протоколи, сигналізація, польове тестування для IOT Використання і Функціональне тестування для ядра Mobile такі програми телефону, як виклик, SMS, передача/утримання тощо. Тестування різноманітних додатків, таких як фінанси, спорт, послуги на основі визначення місцезнаходження тощо. Тестування OSS-BSS
Тестування OSS-BSS	Billing, клієнтська справа, виставлення рахунків за з’єднання, управління замовленнями та шахрайством, гарантія доходу Управління мережею, посередництво, надання тощо. EAI, CRM і ERP, зберігання даних, І т.д.
Тестування відповідності	Сумісність електричного інтерфейсу Відповідність протоколу Відповідність транспортних шарів
Тестування IVR	Інтерактивні тестові сценарії Виявлення голосової енергії Широкосмугові звукові сигнали Великі послідовності умовного розгалуження Записи DTMF

Проблеми тестування телекомунікаційних доменів

Навіть добре написаний пакет документів стикається з перешкодами, характерними для цієї галузі, і їх раннє планування захищає графік випусків.

Перша проблема — це взаємодія між різними постачальниками. Шлях одного абонента може передбачати перехід від одного постачальника, посередницької платформи від іншого та платіжного продукту від третього, тому дефект часто знаходиться в проміжку між двома постачальниками, а не всередині будь-якого з продуктів.

Друге – це глибина протоколу. Зчитування SIP, Diameter або SS7 tracНавички es є спеціалізованими, і команди без них схильні вважати дефекти програми тим, що насправді сигналізує про помилки.

Третя проблема — це вартість середовища. Реалістичні сценарії навантаження, роумінгу та взаємоз’єднань вимагають лабораторного обладнання або симуляторів, ліцензування яких є дорогим, а планування — повільним, що підштовхує команди до спільних середовищ та нестабільних тестових даних.

Тарифи та правила також постійно змінюються. Правила перенесення номерів, податкові пільги та рекламні плани вимагають частого оновлення даних, тому ставтеся до підтримки тестових даних як до постійної діяльності.

Популярні інструменти для тестування телекомунікацій

Правильний інструмент залежить від тестованого рівня, оскільки жоден продукт не охоплює сигналізацію, застосування та білінг однаково добре.

• Тестовий центр Spirent: Генерує великий обсяг трафіку для комутаторів, маршрутизаторів та основних мережевих пристроїв під час перевірки продуктивності та відповідності.
• Мережа Keysight Ix: Емулює топології маршрутизації та комутації в масштабі, що відповідає валідації протоколів 2-го та 3-го рівнів.
• Wireshark: Захоплює та декодує трафік SIP, Diameter та RTP, щоб тестувальники могли перевіряти поведінку сигналізації пакет за пакетом.
• Голосові тестери Hammer та Abacus: Керуйте сценаріями IVR та якості голосового зв'язку, включаючи введення DTMF та послідовності умовного розгалуження.
• JMeter: Завантажує портал самообслуговування та API замовлень, що лежать в його основі, як пояснено в JMeter тестування працездатності.
• Selenium: Автоматизує веб-шляхи CRM та самообслуговування як частину ширшого тестування автоматизації стратегії.
• Мікрофокус ALM: Зберігає бібліотеку телекомунікаційних кейсів, пов'язує дефекти з вимогами та повідомляє зацікавленим сторонам про готовність до релізу.

Більшість операторів поєднують два або три з них, замість того, щоб стандартизувати один, оскільки рівні OSS та BSS рідко мають спільний інтерфейс.

Поширені запитання