Core Network Testing
Core network testing checks that the fundamental components of a network are behaving correctly over the course of a system life cycle. This includes regression tests for patches, updates, upgrades and network element replacement projects.
Network operators follow system life cycles, involving regular system updates that, in turn, require system verification. Core network testing checks that the fundamental components of a network are behaving correctly over the course of a system life cycle. This includes regression tests for patches, updates, upgrades and network element replacement projects.
Examples of core network functionality that requiring testing include:
- Making and receiving different types of phones calls using:
- Mobile phones (2G, 3G, 4G, WiFi, VoLTE)
- VoIP phones
- ISDN phones
- POT phones
- Sending and receiving SMS
- Managing data connections and uploading/downloading content
- Roaming scenarios
- Verifying the speech channel of a call
- Verifying protocol messages of a call flow
- Verifying audio announcements
intaQt significantly shortens the test cycle by automating virtually all core network functionality with its Telephony, SMS and Data Steps. Our custom languages and Built-ins further support the creation of unique steps for complicated or uncommon scenarios. This ensures that testing reflects real-world scenarios and interdependencies within a live network.
One of the greatest advantages of using intaQt for core network testing is its Compound Steps: These are parameterized steps, which perform the entirety of a voice call, SMS transfer or data download/upload. Parameters may be explicitly specified: For example, if a call duration should be declared. When parameters are not specified, intaQt uses default values.
intaQt also automates the following critical functionality for core network testing:
- Configure tariffs in the intaQt Rater to ensure that calls, SMS or data events are charged accurately.
- Configurations enable defining subscribers, local/remote phones and devices, context objects, network interfaces, reporting services and much more.
- Switch between virtual phones and real phones as you integrate components into your test environment.
- Access intaQt’s suite of Built-ins, which provide functionality for database connections, utility functions, protocol testing as well as accessing and manipulating different file types.
- The intaQt Audio Service tests audio-related characteristics, such as speech channel quality and checking that the correct voice announcements are triggered under different circumstances.
Example Test Case with Compound Steps
Feature: callCompoundStep Scenario: callCompoundStepScenario Given a phone as A: * of type Android * where operator == "3 AT" * with profile Vienna And a phone as B: * of type Android And A starts a call to B as MYCALL: * detect incoming call within 10 seconds * call duration is 7 seconds * caller ends the call * caller connects within 5 seconds * callee connects within 5 seconds * caller dials nat format * callee expects signaled number in any format * ringing duration is 8 seconds And expect the call MYCALL to start ringing And expect the call MYCALL to connect And expect the call MYCALL to disconnect
QiTASC’s integrated development environment provides features that improve your productivity and the quality of your tests:
- Auto-completion, go-to declarations and rename refactoring help you write, find and edit your tests with ease.
- the intaQt Phone Plug-in, which shows a project’s phones in real time and enables interacting with remote phones from within intaQt Studio.
- Error inspections, line markers and notifications help you identify problems with your code as you write it.
- Create templates, in-code documentation, and more!
QiTASC Product Add-ons
intaQt Verification (Optional) - intaQt Verification is often included as an add-on for core network testing, and used to check charging conformity and tariffs based on call detail records (CDRs). intaQt Verification may be executed online, as an intaQt test case is being executed, or offline, for example, if CDRs are only collected at the end of each day. In both cases, the following functionality is included with intaQt Verification:
- CDR Selectors - These tell intaQt Verification which CDRs to choose. For example, if only voice call tickets should be used.
- Verification Rules - Rules define the type of “checks” that will be performed against the selected CDRs. For example, checking the difference between two properties such as the difference in time between the beginning of a voice call and its end, or the difference in a customer’s account balance.
- Special functions for calculating properties and values within a test case.
intaQt Client is used to execute entire intaQt test projects from the command line, and can be integrated into continuous integration (CI) environments like Jenkins and TeamCity. Combined with intaQt’s parallel execution functionality, test suites can be run and re-run between very short development cycles.
intaQt Client also provides configurable features that allow users to:
- Specify how often to retry failed tests.
- Pass parameters to specify ports, configurations or hosts for different projects.
- Upload local project changes to the server before execution.
- Create XML configuration files to create complex test suites with tags.
ConQlude Reporting Service
Collect, manage and export intaQt test case project data manage defects, which can be accessed by all members of your project’s team. ConQlude automatically uploads all test reports, logs, media attachments and metadata to a centrally-accessible, secure web interface. conQlude provides approval workflow features and can be integrated into most test management systems and defect tracking systems. Our reporting interface ensures that users can remain confident that all test execution details are 100% correct, up-to-date and conform to formats recognized by external project management systems.