1 / 27

AControllerTest: A Module Testing Framework for AController

2. 20.9.2012. Software testing. Software Testing is the process of executing a program or system with the intent of finding errorsThere are two types of software testingManual software testing is the process in which a person carries out the task with hands Automated software testing is the proce

michael
Télécharger la présentation

AControllerTest: A Module Testing Framework for AController

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

    1. 20.9.2012 1 AControllerTest: A Module Testing Framework for AController By Afzal Rehman Khaskheli Supervised by Dr. Jyrki Nummenmaa

    2. 2 20.9.2012 Software testing Software Testing is the process of executing a program or system with the intent of finding errors There are two types of software testing Manual software testing is the process in which a person carries out the task with hands Automated software testing is the process of creating test scripts that can then be run automatically, repetitively, and through much iteration

    3. 3 20.9.2012 Mobile phone testing Mobile phones testing is the process to assure the quality of mobile phones Various difficulties in testing mobile devices Complex environments- as they have to interact with end users, wireless signals and other devices Diversity- reduces the reusability and maintainability of test cases Highly resourceful- constrains the processing ability, memory capacity and communication ability Highly interactive- devices constantly accept activations from users and send responses back for user to take further actions

    4. 4 20.9.2012 Audio functions in mobile phones Mobile devices provide various audio types such as call audio music audio ringing tone audio keypad audio Estimated that over 400 different audio types available for mobile phones Audio function is required in almost all applications of mobile phones

    5. 5 20.9.2012 Audio processing- Complexity

    6. 6 20.9.2012 Audio processing- Hardware Real world sound -> converted into electrical signals using a transducer (e.g. microphone) -> electrical signals are converted into digital signals using a circuit called ADC (Analog-to-Digital Converter) Digital signals are converted back to the sound using DAC (Digital-to-Analog Converter) -> sound using a transducer (e.g. loudspeaker) Digital signal processor (DSP) is responsible for processing the digitized signal by ADC

    7. 7 20.9.2012 Audio processing- Software Various Symbian based components/modules form audio processing framework Software modules hide the internal details of the hardware allow the mixing of audio from various components interact with various hardware components The interaction of audio software modules is controlled by a component called the AController

    8. 8 20.9.2012 The AController The AController sits in between the hardware and software modules and works with various streams The AController itself is composed of different sub-components volume controller filter controller input router output router The AController testing issues Covers the execution of the code in few routes with fewer combinations of different sub-systems in the audio processing. Manually testing

    9. 9 20.9.2012 What and how to do? Perform automatic testing at the module level Enhance the existing audio testing Develop a framework Cover more execution routes with more combinations of sub-components Automate the test cases White-box testing takes into account the internal mechanisms of a system or component the code is run with predetermined inputs and it makes sure that the code produces predetermined outputs

    10. 10 20.9.2012 Design of AController The AController interacts with other modules AMapper AServer HW Drivers Audio Devices The AMapper module interacts with the domestic operating system for transforming physical stream attributes to hardware configuration settings Logical streams created by the AServer are mapped on to the physical streams created by the AStreamer The AController itself consists of two other modules AStreamer- the AServer creates logical streams using this API ARouter- the AServer sends requests to the ARouter to provide a path to correct physical stream the ARouter sends the requests to the AMapper AMapper forwards the appropriate request to the domestic operating system

    11. 11 20.9.2012 Design of AController (conti)

    12. 12 20.9.2012 The AControllerTest

    13. 13 20.9.2012 The AControllerTest (conti) The system with stubbed AServer, Audio Devices, HW Drivers and AMapper Stubs hide the real functionality of a component Stubs are used when a system has many components there is a need to test these components

    14. 14 20.9.2012 The AControllerTest (conti) The AMapper stub publishes the status of the services to publish and subscribe component The TestModule component (a class in the AControllerTest) is registered for checking test step results to the publish and subscribe component as a subscriber and is therefore notified of the success or failure of the sent request Similarly, the AController module communicates with the Audio Device stubs, HW Driver stubs and AMapper stub modules for acquiring the functions that it needs

    15. 15 20.9.2012 The AControllerTest (conti) Specifications for AControllerTest 1. Test case specification identifier 2. Test items 3. Input specifications 4. Output specifications

    16. 16 20.9.2012 The AControllerTest- Class diagram

    17. 17 20.9.2012 The AControllerTest- Examples

    18. 18 20.9.2012

    19. 19 20.9.2012 Tools used Development Symbian C++ Testing PC-based Series 60 emulator Problems faced Some features are mutually exclusive, therefore, it may be possible to enable some flag and get some cases passed but at the same time some others will still fail It still takes some manual work to compile the stubs but this may be improved by writing some compilation scripts that would automate the process

    20. 20 20.9.2012 Test case execution Step1- Create MO CS call Create MO CS call DL stream A Set stream A sink device to mono Bt headset Set volume of stream A to some given value Activate stream A Create MO CS call UL stream B Set stream B source device to mono Bt microphone Set stream B to un-mute Activate stream B

    21. 21 20.9.2012 Test case execution (conti) Step1, Expected results: The call is created. No errors occur Stream A is created Sink device is set to mono BT headset Volume is saved correctly DL audio path power is set ON. Mono Bt analog volume is set correctly. DL audio signal is routed to mono Bt audio path Stream B is created Source device is set to mono Bt microphone Stream B gain is non-zero UL audio path power is set ON. Mono Bt microphone signal is routed to UL

    22. 22 20.9.2012 Test case execution (conti) Step2: Transfer audio to IHF Set sink device to IHF for stream A Set stream B source device to microphone Step2, Expected results: Audio is transferred correctly to IHF. No errors occur Sink device is set to IHF. Audio routing to mono Bt audio path is terminated. IHF speaker power is set ON. IHF analog volume is set correctly. DL audio signal is routed to IHF Stream B source device is set to microphone. Mono Bt microphone audio path is terminated. Phone microphone power is set ON. Microphone signal is routed to UL

    23. 23 20.9.2012 Test case execution (conti) Step3: Transfer audio to already connected mono Bt headset Set sink device to mono Bt headset for stream A Set source device to Bt microphone for stream B Step3, Expected results: Audio is transferred correctly to mono Bt headset. No errors occur Sink device is set to mono Bt headset. IHF speaker power is set OFF. DL audio signal is routed to mono Bt audio path. Bt analog volume is set. Source device is set to Bt headset for stream B. Phone microphone power is set OFF. Mono Bt microphone signal is routed to UL. Bt gain is non-zero

    24. 24 20.9.2012 Test case execution (conti) Step4: End the call Stop stream B Delete stream B Stop stream A Delete stream A Step3, Expected results: Call ends and no errors occur IHF power is set OFF and DL audio path power is set OFF Stream B is deleted Microphone power is set OFF and UL audio path power is set OFF Stream A is deleted

    25. 25 20.9.2012 Advantages of the AControllerTest Easier to modify the code in case of an error Verification of the code within few seconds Gives a better insight of the code Beneficial in identifying the audio errors where the humans are weak at interpretation; for example, measuring different volume levels of an audio playback where the difference between the two consecutive volume levels is very narrow Tests are run for every small change in the code to verify that the code didnt break any other code In the long run is a big time saver Provides a larger set of regression test cases Believed to reduce the number of bugs in the long run Provides automatic testing mechanism

    26. 26 20.9.2012 Disadvantages of the AControllerTest Same test cases are repeated to test the same functionality of the code Extra code is added to the actual code Doesnt guarantee that the bugs will be prevented in the future cycles of the development Does not guarantee that the system works seamlessly with other components in real hardware environment Functional testing cant be replaced completely by module testing

    27. 27 20.9.2012 Questions, suggestions? Thank you!

More Related