I think the testing frame work includes both the components <br>and system testing.<br>I wish to add some more test even though all giants may aware,<br>since i wish to do some contribution to asterisk what ever i can.<br>
<br>i am plannig for the framework and addon as given below, expecting <br>techies advise in this,<br>Testing frame work may contain testing internally and externally,<br>i mean to say internally, some client may stick into the problem of
<br>voice quality, when more phones on the PBX, that time, we may not <br>leave the system from the network, their call may get interrupted,<br>that time internal testing daemon will work for the performance analysis<br>till the lelvel of without affecting present calls.
<br><br>externally means PBX system on production for performance analysis,<br>as per the test case started in the mail. <br><br>internal and external testing may be configurable at the run time, through<br>some verbose like variable configurable at run time, addon should have the capability
<br>of releasing the testing call bandwidth, whenever PBX gets new call, this might be simple<br>example.<br><br>procesding with Testing frame work requirements,<br>call on volume, <br>1. SIP - SIP, multiple SIP clients support, through which we can either
<br>direct the call for testing to another client registered in testing frame work,<br>or return back to the different client registered in the same testing frame work,<br>when the call incoming and outgoing call are handled in single framework point,
<br>wave analysis also cane be done with the script and performance can be easily<br>evaluated.<br><br>On production performance testing, by connecting multiple testing framework point to the PBX,<br>having the sending files in all the frame work, analysis and performance evaluation can be
<br>done very easily,<br><br>i also think that once it is done for SIP with compatiblity of like<br>channel driver, we can adapt IAX2, anything we want.<br><br>i think this type of testing would make the system stable and provide
<br>good support on system on running also.<br><br>Hariharan.V.<br>R&D Engineer,<br>NEEVEE Technologies,<br><div><span class="gmail_quote">On 9/3/07, <b class="gmail_sendername">dave cantera</b> <<a href="mailto:david.cantera@iacnet.net">
david.cantera@iacnet.net</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">matt,<br>are you looking for unit testing of the * components or systems testing,
<br>testing the finished product? or both?<br>I think you are onto something here... I hope it takes root. I would<br>say put it in the addons. it would be Great if digium takes it up. it<br>is a smart move for them to foster, cajole, nudge, and support it.
<br>call volume I would leave to others as different processors, O/S,<br>builds, kernel versions, and configurations will have too many variables.<br><br>I was playing with the idea of monitoring multiple * systems. perhaps
<br>we can start out with testing the components and then migrate the<br>project (future) to one pbx monitor the other. we will need scripts to<br>initiate some action, config to make some measurements, the scripts to<br>
gather the results into a nice neat little summary report. you will<br>want to take the human aspect out of the picture as much as possible.<br>for example:<br><br> on pbx A<br><br> * create a recording in multiple formats .gsm, .wav, etc.
<br> * initiate a script to generate 5,10, or 25 calls to pbx B and<br> play the file<br><br> on pbx B<br><br> * pbx B gets the calls, records them,<br> * copy the recordings from pbx A to pbx B (or have that already
<br> done)<br> * have a wave analyzer compare the recordings to the original<br> files (you know I won't be writing that program! :)<br> * report on anomalies<br><br>*call<br>* *Technology
<br>* *recording<br>delta<br>*<br>1<br> Zap Provider 1<br> 2%<br>2<br> VoIP Provider 2<br> 5%<br>3<br> VoIP Provider 2<br> 15%<br>...<br> VoIP Provider 3<br> ...
<br><br><br>let me know what you think!<br>daveC<br><br><br><br>Matt Riddell wrote:<br>> Hash: SHA1<br>><br>> Hi,<br>><br>> So, now that we've all complained about the state of testing of Open<br>> Source versions of Asterisk, lets do something about it.
<br>><br>> I propose we start with a list of things that we think should be tested<br>> in Asterisk, and means to test them.<br>><br>> Maybe we could run certain tests based on the changes between minor<br>
> versions?<br>><br>> Anyway lets start.<br>><br>> Call Volumes<br>><br>> 1) Call volume up to x channels from SIP to SIP (i.e. sipp)<br>> 2) Call volume up to x channels from IAX2 to SIP<br>> 3) Call volume up to x channels from IAX2 to IAX2
<br>><br>> Application testing<br>><br>> 4) Connect x calls between techs to Meetme (leave running for 1 hour)<br>> 5) Connect x concurrent calls to VoiceMail<br>><br>> Call Centre Testing<br>><br>
> 6) Send x calls to a queue with no agents in it, leave them holding for<br>> x minutes<br>> 7) Run x calls against AMD connected to recorded known good files<br>><br>> Recording<br>><br>> 8) Run x calls recording simultaneously from an automatically generated
<br>> call, play ulaw/alaw - compare outputs.<br>><br>> You get the idea.<br>><br>> If people can add to this list, I can start making a few scripts and<br>> programs that will test them (as I'm sure others can).
<br>><br>> If we end up with a complete list, I'm sure some of our individual QA<br>> departments can take the responsibility for certain items.<br>><br>> The call volume ones are obviously going to either need a live person to
<br>> dial in at volume and check everything is ok, or a recording which can<br>> later be checked.<br>><br>> I'm of the opinion that the majority of tests should test individual<br>> components, but that we should also form some "Application Type"
<br>> frameworks so that we can test integration between Asterisk apps.<br>><br>> Any takers? Add to the list? If there is something you believe is<br>> mission critical to your business, write up a test case for it, and
<br>> we'll all try to code something that can run automatically to test it.<br>><br>> If we try and keep to ANSI C for the testing apps, Digium should be able<br>> to run them on their multi platform machines as well.
<br>><br>> Should these tests be added to Asterisk-Addons or maintained outside of<br>> the tree?<br>><br>> Anyway, what do you think? Feasible? I already have a few tests here and<br>> I'm sure others have a few too. Lets put them all together and get a
<br>> framework going.<br>><br>> - --<br>> Kind Regards,<br>><br>> Matt Riddell<br>> Director<br>> _______________________________________________<br>><br>> <a href="http://www.venturevoip.com">
http://www.venturevoip.com</a> (Great new VoIP end to end solution)<br>> <a href="http://www.venturevoip.com/news.php">http://www.venturevoip.com/news.php</a> (Daily Asterisk News - html)<br>> <a href="http://feeds.venturevoip.com/AsteriskNews">
http://feeds.venturevoip.com/AsteriskNews</a> (Daily Asterisk News - rss)<br>> -----BEGIN PGP SIGNATURE-----<br>> Version: GnuPG v1.4.7 (MingW32)<br>> Comment: Using GnuPG with Mozilla - <a href="http://enigmail.mozdev.org">
http://enigmail.mozdev.org</a><br>><br>> iD8DBQFG1yKhDQNt8rg0Kp4RAv5UAJ48tW28T5lWCQIPTwVimyvlhEPJowCgpnE6<br>> OF3L2M/6Hc+YBNL1NFx6dzA=<br>> =OXNn<br>> -----END PGP SIGNATURE-----<br>><br>> _______________________________________________
<br>> --Bandwidth and Colocation Provided by <a href="http://www.api-digital.com--">http://www.api-digital.com--</a><br>><br>> asterisk-users mailing list<br>> To UNSUBSCRIBE or update options visit:<br>>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-users">http://lists.digium.com/mailman/listinfo/asterisk-users</a><br>><br>><br>><br>><br><br>--<br>My wife's sister is in California.<br>I should buy her a Videophone2008!
<br><br>Truly, The Next Best Thing to Being There!<br>--<br><br>WorldWideVideoPhones.com<br>856.380.0894<br><br><br><br><br>_______________________________________________<br>--Bandwidth and Colocation Provided by <a href="http://www.api-digital.com--">
http://www.api-digital.com--</a><br><br>asterisk-users mailing list<br>To UNSUBSCRIBE or update options visit:<br> <a href="http://lists.digium.com/mailman/listinfo/asterisk-users">http://lists.digium.com/mailman/listinfo/asterisk-users
</a><br></blockquote></div><br>