Testing av telekomdomener med eksempler på OSS/BSS-testtilfeller

Hva er telekomtesting?

Telekomtesting er definert som testing av telekommunikasjonsprogramvare. Siden telekomsektoren gikk over til digitale nettverk og datanettverk, har telekommunikasjonsbransjen brukt programvare uunnværlig.

Telekomsektoren er avhengig av ulike typer programvarekomponenter for å levere tjenester som ruting og svitsjing, VoIP og bredbåndstilgang. Derfor er testing av telekomprogramvare uunngåelig, og det strekker seg over maskinvarekomponenter, backend-systemer og frontend-applikasjoner.

Bli med på vårt Live Telecom Testing-prosjekt gratis

Hva er domene i testing?

Før et hvilket som helst telekomscenario skrives, trenger begrepet domene en definisjon.

Et domene er ikke annet enn bransjen som programvaretestprosjektet er laget for. Når vi snakker om et programvareprosjekt eller en programvareutvikling, brukes ofte denne betegnelsen. For eksempel forsikringsdomenet, bankdomenet, detaljhandelsdomenet, telekomdomenet osv.

Som illustrasjonen viser, kan én tester jobbe på tvers av flere slike bransjedomener. Vanligvis, mens utviklingping For ethvert spesifikt domeneprosjekt søkes hjelp fra en domeneekspert. En domeneekspert er en mester i faget, og han kan kjenne produktet eller applikasjonen inn og ut.

Hvorfor er det viktig å teste domenekunnskap?

Domenekunnskap er avgjørende for testing av ethvert programvareprodukt, og det har sine egne fordeler, som diagrammet nedenfor oppsummerer.

En tester som forstår tariffer, samtrafikkregler og provisjonstilstander, utformer realistiske scenarier og identifiserer kanttilfellene som en generisk testforsøk biblioteket dekker aldri.

Forretningsprosesser i telekombransjen

Domenekunnskap her starter med forretningsprosessene som bærer en tjeneste fra salg til faktura.

For telekomtesting er ende-til-ende-tjenesteverifisering viktig. For å sikre effektiv testing er god forståelse av de ulike forretningsprosessene et must.

Du må forstå hvert trinn i tjenesteleveransen før du utarbeider testsakene.

Telekommunikasjonstjenester er enten basert på et forretningsstøttesystem som inkluderer IVR-er, kundesentre og generering av fakturaer, eller et driftsstøttesystem som inkluderer rutere, svitsjer og mobilmaster.

Tabellen nedenfor viser hvilke aktiviteter som utføres på ulike nivåer.

Telekomavdelingen	Telekomaktiviteter
Før salg	Den håndterer all salgsinformasjon som rabatter, tjenester, kampanjer, etc.
bestilling	Søke om ny tilkobling eller koble fra tilkobling
Provisioning	Denne divisjonen tar for seg den fysiske forbindelsen mellom kunder og TSP (Telecom Service Provider)
Billing	Under denne divisjonen gjøres alt faktureringsarbeid
Serviceforsikring	I tilfelle feil, retter denne inndelingen opp problemet
Inventarsystemer	Det er depotet for all informasjon
Tracking	Denne divisjonen tracbestillingssystemet og statusen til en bestilling

Typisk telekom forretningsprosess

Når disse avdelingene er klare, er neste steg å se hvordan én ordre faktisk beveger seg mellom dem. Følgende er en typisk forretningsprosess i telekombransjen.

Som flyten ovenfor indikerer, går en forespørsel fra forhåndssalg til bestilling, deretter klargjøring og til slutt fakturering. Hver overlevering er en integrasjonsgrense og et mål med høy verdi for ende-til-ende-testing.

Typer protokoller som brukes i telekomindustrien

Disse overleveringene er basert på protokoller, så testere må gjenkjenne hvilke stablene som er i bruk. Her er de populære protokollene som brukes i telekombransjen.

• VoIP-teknologier: VoIP, IMS, MPLS, ISDN, PSTN
• Signaling og protokollerSIP, ISDN, Codecs, H.323
• Trådløs teknologi: GPRS, CDMA, GSM, UMTS
• Nettverksadministrasjon: SNMP
• Lag 2-protokoller: ARP, STP, L2TP, PPP
• Lag 3 protokoller/ruting: ICMP, BGP, ISIS, MPLS
• Infrastruktur/sikkerhet: ATM, TCP/IP, LAN/VLAN, SSH

Du kan lære mer om protokolltesting her.

Testing av livssyklus i telekomindustrien

Med prosessene og protokollene kartlagt, kan arbeidet organiseres i en livssyklus. Testlivssyklusen i telekombransjen er lik den i enhver annen bransje, men med vekt på detaljer. Slik ser testlivssyklusen ut sammen med testartefaktene.

Teststadiet for telekom	Test artefakter
Business View	Kravbaserte testartefakter Mulighetsbaserte artefakter Standard- og policyidentifikasjonsbaserte testartefakter Operasjons- og vedlikeholdshensyn relatert til testartefakter
System/ Architecture	Systemtestartefakter (sikkerhet, installasjon) Test artefakter for virtuell prototype Spesiell Systemtesting artefakter (interoperabilitet, katastrofegjenoppretting)
Gjennomføring	Enhetstestartefakter Integrasjonstestartefakter Kvalitets- og ytelsesartefakter Regresjon, belastningstesting, fornuft osv.
Utplassering	Aksepttest artefakter Integrasjonstestartefakter Kvalitets- og ytelsesartefakter Funksjonelle testartefakter Alfa/beta-testartefakter

Typer testing utført på telekomprogramvare

Hvert livssyklusstadium ovenfor benytter seg av en annen testtype, og listen nedenfor dekker de som oftest brukes på telekomprogramvare.

• Sammenkoblingstesting
• Samsvarstesting
• IVR-testing
• Ytelsestesting
• Sikkerhetstesting
• Interoperabilitetstesting
• Protokolltesting
• Funksjonell testing
• Automatiseringstesting

Hvordan skrive effektive telekomtesttilfeller

Å kjenne prosessområdene er bare halve jobben. Selve casene må skrives slik at enhver tester i teamet kan utføre dem uten stammekunnskap. Trinnene nedenfor gjelder likt for OSS-omfang og BSS-omfang.

1. Behold én forretningsprosess per suite. Separate bestillings-, klargjørings- og faktureringspakker, slik at en feil peker mot et enkelt eiersystem i stedet for en tvetydig kjede av dem.
2. Skriv forutsetningen som data, ikke prosa. Oppgi nøyaktig abonnementsstatus, tariffplan, kredittgrense og kontosaldo som saken antar, fordi telekomfeil vanligvis er datatilstandsfeil.
3. Dekk grensene for vurdering og lading. Gratisminutter oppbrukt, abonnementsfornyelse ved midnatt, bytte av roamingpris og forholdsmessige oppgraderinger er punktene der faktureringsmotorer oftest svikter.
4. Legg til en negativ variant for hvert positivt tilfelle. Ugyldig nummerlengde, sperret abonnent, duplikatbestilling og mislykkede tilbakeringinger ved klargjøring fortjener hver sitt forventede resultat.
5. Bekreft nedstrøms, ikke bare på skjermen. En klargjøringsordre er bare korrekt når CRM-oppføringen, lageroppføringen, nettverkselementet og formidlingsfeeden alle stemmer overens.
6. Legg ved et målbart forventet resultat. En uttalelse som «regningen er korrekt» kan ikke utføres, mens «fakturasum tilsvarer 249.00 inkludert 18 prosent moms» kan.
7. Tagg regresjonskandidatene. Merk alle saker som berører vurdering, beskatning og sammenkobling, slik at de går inn i hver utgivelsessyklus av Regresjonstesting.

Til slutt bør du gjennomgå hvert tilfelle med en faktureringsanalytiker eller en nettverksingeniør før du vurderer det som en baseline. Regler for telekomvirksomhet endres med hver tarifflansering, og et tilfelle som fortsatt inneholder kampanjen fra forrige kvartal vil rapportere falske feil i flere måneder.

Eksempel på testtilfeller for telekomtesting

Ved å bruke disse reglene produseres en pakke som ligner på den nedenfor. I telekomtesting må man vurdere testingen som følger

Ulike telekomtesting	Testing av aktiviteter i Telecom
Billing System	Bekreft, telefonnummeret til kunden er registrert under teleoperatør Kontroller om nummeret fortsatt fungerer Bekreft at nummeret som er angitt er gyldig, og at det er et 10-sifret nummer Bekreft at nummeret ikke er blokkert på grunn av noen årsaker Bekreft om nummeret har utestående regninger, hvis det finnes, vis det på skjermen Kontroller at nummeret har alle tidligere kontoer eller regninger slettet Bekreft at systemet aktiverer erklæringsgenerering i henhold til kundens krav Kontroller at systemet har tatt opp et antall samtaler nøyaktig Bekreft at planen valgt av kunden vises på faktureringssystemet Kontroller at det totale beløpet som faktureres er nøyaktig og tilordnet tjenesten som tilbys
Applikasjonstesting	Protokoller, signalering, felttesting for IOT Bruk og Funksjonell testing for kjerne Mobil håndsettapplikasjoner som anrop, SMS, overføring/hold osv. Testing av ulike applikasjoner som økonomi, sport og lokasjonsbaserte tjenester, etc. OSS-BSS testing
OSS-BSS-testing	Billing, kundecase, samtrafikkfakturering, ordre- og svindelhåndtering, inntektssikring Nettverksadministrasjon, formidling, klargjøring osv. EAI, CRM og ERP, datavarehusOsv
Samsvarstesting	Kompatibilitet med elektrisk grensesnitt Overensstemmelse med protokoll Overensstemmelse med transportlag
IVR-testing	Interaktive testscenarier Deteksjon av stemmeenergi Bredbåndslydtoner Omfattende betingede forgreningssekvenser DTMF-oppføringer

Utfordringer innen testing av telekomdomener

Selv en velskrevet pakke møter hindringer som er spesifikke for denne bransjen, og tidlig planlegging av dem beskytter utgivelsesplanen.

Den første utfordringen er interoperabilitet mellom flere leverandører. Én abonnementsreise kan gå gjennom et bytte fra én leverandør, en formidlingsplattform fra en annen og et faktureringsprodukt fra en tredje, slik at en feil ofte ligger i gapet mellom to leverandører snarere enn inni noen av produktene.

Det andre er protokolldybde. Leser SIP, Diameter eller SS7 traces er en spesialisert ferdighet, og team uten den har en tendens til å rapportere applikasjonsfeil som egentlig signaliserer feil.

Det tredje er miljøkostnader. Realistiske belastnings-, roaming- og sammenkoblingsscenarier krever laboratoriemaskinvare eller simulatorer som er dyre å lisensiere og trege å planlegge, noe som presser team mot delte miljøer og ustabile testdata.

Tariffer og forskrifter endres også kontinuerlig. Regler for nummerportabilitet, skattesatser og kampanjeplaner tvinger frem hyppige dataoppdateringer, så behandle vedlikehold av testdata som en permanent aktivitet.

Populære verktøy for telekomtesting

Det riktige verktøyet avhenger av laget som testes, fordi ingen enkeltprodukter dekker signalering, applikasjoner og fakturering like godt.

• Spirent Testsenter: Genererer trafikk med høyt volum mot svitsjer, rutere og kjernenettverksenheter under ytelses- og samsvarskjøringer.
• Keysight IxNetwork: Emulerer ruting- og svitsjetopologier i stor skala, noe som passer til protokollvalidering på lag 2 og lag 3.
• Wireshark: Fanger opp og dekoder SIP-, Diameter- og RTP-trafikk slik at testere kan bekrefte signalatferd pakke for pakke.
• Hammer og Abacus stemmetestere: Kjør IVR- og talekvalitetsscenarier, inkludert DTMF-inntasting og betingede forgreningssekvenser.
• JMeter: Laster inn selvhjelpsportalen og bestillings-API-ene bak den, som forklart i JMeter ytelsestesting.
• Selenium: Automatiserer CRM- og selvhjelpsnettreiser som en del av et bredere automatiseringstesting strategi.
• Mikrofokus ALM: Lagrer saksbiblioteket for telekom, kobler feil til krav og rapporterer klargjøring for utgivelse til interessenter.

De fleste operatører kombinerer to eller tre av disse i stedet for å standardisere på én, fordi OSS- og BSS-lag sjelden deler et felles grensesnitt.

Spørsmål og svar