[svn-commits] mmichelson: branch mmichelson/queue_tests r216 - /asterisk/team/mmichelson/qu...

Wed Apr 7 17:32:31 CDT 2010

Author: mmichelson
Date: Wed Apr  7 17:32:30 2010
New Revision: 216

URL: http://svnview.digium.com/svn/testsuite?view=rev&rev=216
Log:
Add potential queue tests.

I came up with 19 tests for now.


Modified:
    asterisk/team/mmichelson/queue_tests/Queue_testing.txt

Modified: asterisk/team/mmichelson/queue_tests/Queue_testing.txt
URL: http://svnview.digium.com/svn/testsuite/asterisk/team/mmichelson/queue_tests/Queue_testing.txt?view=diff&rev=216&r1=215&r2=216
==============================================================================

--- asterisk/team/mmichelson/queue_tests/Queue_testing.txt (original)
+++ asterisk/team/mmichelson/queue_tests/Queue_testing.txt Wed Apr  7 17:32:30 2010
@@ -3,7 +3,7 @@
 Aspects to test:
 
 -Options to the Queue application:
-n,c,i are testable.
+n,c,i,r are testable.
 h,H,t,T,k,K,w,W,x,X are bridge options not specific to queues
 d,C are not easily testable
 I is testable but would fit better in a connected line test instead
@@ -89,3 +89,109 @@
 Queue rules
 Realtime?
 
+Tests to run:
+Test 1: Basic dry run. Set up a queue with a single member. Place a call in with no
+extra options specified and ensure that the member is rung and he answers.
+
+Test 2: Queue options test. We'll test the n, c, and i options in this test. This will
+require 5 calls and 2 queues. Queue 1 will have 2 members in rrmemory, and Queue 2 will
+have 2 members in random. We'll test the n option with both queues to ensure that Queue
+1 rings both members before bailing and that Queue 2 just 1. We'll test the c option by
+calling into either queue, having the member answer, and then end the call. We'll set some
+channel variable in the dialplan after the call to Queue and gauge our test on whether that
+variable gets set or not. The i option will be tested by having a UAS SIPp scenario return
+a 302. The first iteration will be done without the 'i' to be sure that the forwarding works.
+The second iteration will be done with the 'i' to be sure that we do not try to forward. We
+can test 'r' by ensuring that res_musiconhold emits a message when the option is not set.
+This is also a chance to test the musicclass queues.conf option.
+
+Test 3: Macro, gosub, and AGI tests. This will require a 1 queue and 2 calls. The queue will have
+a membermacro and membergosub configured. On call 1, we'll ensure that when the member
+answers, the macro and gosub are executed. On call 2, we'll specify an overriding macro
+and gosub in the call to Queue and ensure that the overriding options are what is executed. On one
+of the two calls, we will specify an AGI to run.
+
+Test 4: Strategy tests. This will require four queues, each with at least three members.
+Each queue will have a different strategy, either rrmemory, linear, leastrecent, or fewestcalls
+Each queue will require some "priming" so that we can get into testing form.
+Priming to be done:
+rrmemory: Place calls to all members to determine the order. Now we can start answering calls and
+ensuring that the next calls start with the next one after the last who answered the call.
+linear: No priming necessary. Easy to test. Just ensure that members are rung in proper order.
+leastrecent: Place calls so that the three members all have different times they last answered.
+Then proceed to place three calls and make sure that members are rung in the correct order.
+fewestcalls: Similar to leastrecent, except that we can probably test this one with fewer than
+three queue members, and the calls answered count is used instead of the time answered.
+
+Test 5: Wrapuptime tests. This will require 2 spawnings of Asterisk, one with sharedlastcall set
+and one without. Each instance will have 2 queues with 2 members, with each queue using the linear
+strategy, and each having a very large wrapuptime set. We'll test by calling a queue, having the
+first member answer, and then hangup. We'll call the second queue. With sharedlastcall set, we
+should reach the second member; without it, we should reach teh first. Then we'll call the first
+queue again. With sharedlastcall set, we should time out since both members will be in wrapup;
+without it, we should reach the second member.
+
+Test 8: Ringinuse and pause testing. We'll need a 2 queues. One will have ringinuse set to
+no, the other will have ringinuse set to yes. One will have autopause set to no, the other will
+have autopause set to yes. The goal of this test is to make sure that we do not try to ring
+a paused member and that we honor the ringinuse setting. It also makes sure that autopause
+properly pauses a queue member if he does not answer. Also test manual pausing and unpausing
+through the manager and dialplan.
+
+Test 9: Joinempty and Leavewhenempty tests. This will require many queues with many different
+combinations of joinempty and leavewhenempty options. We will have to "prime" each queue so
+that specific conditions are met which should cause the joinempty or leavewhenempty conditions
+to be met.
+
+Test 10: Queue position, priority, and maxlen tests. The point of this test is to ensure that
+the placement of callers into the queue goes as expected. The higher-priority callers go
+to the front. The time at which the caller entered is then the determining factor. This test
+will require that a bunch of callers join the queue at the same time. We'll be sure that they
+are placed in the position we expect them to be placed in when they arrive. In addition, we'll
+be sure that we do not exceed the maxlen of the queue.
+
+Test 11: Queue resetting and reloading. We need to prime a queue with a bunch of calls and then
+use QueueReset manager action and make sure that all statistics have been placed back to 0. After
+handling more calls, we can call QueueReload and be sure that the stats are not reset. In addition
+we can modify queues.conf before the reload and ensure the new settings took effect. Testing every
+single setting is not practical for this test, so we'll likely just use a single setting as an
+indicator that a reload was actually performed. I can also shoehorn in a test for servicelevel
+since I'll be checking Queue statistics.
+
+Test 12: Dynamic Queue Members test. We'll use the manager and dialplan applications to add
+queue members and remove queue members from a queue. We'll attempt to remove a non-dynamic queue
+member from a queue and ensure the member is not removed. We also will test persistentmembers this
+way by performing a reload and ensuring that dynamic queue members are not deleted.
+
+Test 13: Penalty and Rules test. We'll use a queue with a Queue member with a high penalty. A rule
+will state that after 5 seconds in the queue, the QUEUE_MAX_PENALTY will be raised to allow the
+member to be called. We'll place a second call that uses an overriding rule in the call to Queue
+but essentially does the same thing, only the increment of QUEUE_MAX_PENALTY is different and
+happens at a different time. We can also make a test call wherein the member cannot be reached
+until a Manager or Dialplan app call is made to change the member's penalty to be within reach.
+One of these tests will likely also play with the idea of putting a member's penalty below the
+QUEUE_MIN_PENALTY instead, thereby testing that as well.
+
+Test 14: (Probably should be done before Test 12) Queue member test. Create various queue members
+with various items set or not set. Ensure that the name, state interface, penalty, etc. are all
+reflected properly for these queue members.
+
+Test 15: State interface test. Set up queue members on local channels with a state interface
+that corresponds to a SIP interface. Ensure that when the SIP device answers, the state changes
+to "in use" and when the call is over, the state changes to "not in use."
+
+Test 16: Queue Log test. Use the QueueLog manager action and dialplan function and ensure the
+information is written to the queue_log as expected.
+
+Test 17: Queue Weight test.
+
+Test 18: Autofill test. We'll need a queue with and a queue without autofill. The best way I can
+think to do this is to check the holdtimes of the phone calls during the AgentConnect event to
+ensure that there is no extra waiting time when autofill is enabled.
+
+Test 19: context test. Simple. Have a caller enter the queue and press a button to exit to
+the appropriate context.
+
+Note that I will not be directly testing the various options that emit manager events in specific
+situations. Instead, I will just always have these options enabled and depend on these events in
+order to determine that stuff has worked as expected.


