Bug #3926
openMissing PCU_Tests.ttcn DL TBF tests
90%
Description
We should have a bunch of automatically executed tests in PCU_Tests.ttcn that cover DL TBF establishment
Updated by pespin over 4 years ago
I added a few here:
remote: https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/16507 pcu: Introduce test TC_imm_ass_dl_block_retrans
remote: https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/16508 pcu: Introduce test TC_t3193
see also TC_mo_ping_pong.
Updated by pespin about 4 years ago
- Status changed from New to Feedback
- % Done changed from 30 to 90
There's already a bunch of tests establishing TBFs in TTCN3's PCU_Tests_RAW.ttcn and the task is quite generic, so I think we can close it. I'll close it later if nobody disagrees.
Updated by fixeria about 4 years ago
Maybe laforge can clarify which aspects of DL TBF Establishment should be covered by TTCN-3 test cases...
There's already a bunch of tests establishing TBFs in TTCN3's PCU_Tests_RAW.ttcn [...]
I am not sure if we cover all corner cases, in particular we may also want to:
- verify how OsmoPCU handles Downlink TBF establishment failures (e.g. timeout);
- verify the operation of multiple Downlink TBFs co-existing in parallel
- on a single timeslot, and optionally
- on multiple timeslots;
- simulate resource exhaustion?
Updated by laforge about 4 years ago
I agre with fixeria here: We should at least cover timeouts and concurrent TBFs
Updated by pespin about 3 years ago
- We already have at least 1 test using concurrent allocation and use (GPRS+EGPRS): TC_multiplex_dl_gprs_egprs
- Resource exhaustion: This one is by far easier to handle as unit tests, and we already have long tests checking resource exhaustion there.
- I would welcome a more detailed scenario regarding mentioned "Downlink TBF establishment failures (e.g. timeout)". When is the timeout expected to happen? That's why I'm saying this ticket is not really helpful as it is now.