Android Applications testing
Android Applications testing
There are different levels of testing for Android applications,in addition to the traditional unit testing, integration testing,system testing, and regression testing. Scopes that are specificto the mobile scenario must be considered. Kauret al.[12]list, among the most prominent testing needs for mobile apps,compatibility testing (i.e., to ensure that the application workson different combinations of handheld models and OS versions),performance testing (i.e., to ensure that the application does notexploit any of the resources available, since they can be limited),and security testing (i.e., to ensure that no unauthorized use ofdata and capabilities of the handheld device is performed bythe application). GUI testing is identified as a very prominenttesting need for all mobile applications, since GUI malfunctionscan hamper significantly the user experience provided by an app.GUI testing of Android apps can be performed in variousways. The first and most immediate option is to describe and ex-ecute manual test cases on the GUI of the applications. Linares-V ́asquezet al.[13], who conducted an empirical study in thefield of performance testing, identified manual testing as the op-tion preferred by developers, along with the examination of re-ports and feedbacks given by the users. However, as discussed byKropp and Morales [14], the manual execution of test cases—inaddition to requiring significative effort from testers—is rarelyexhaustive, error prone, and not easily reproducible. On theother hand, automated GUI testing techniques may define setsof scripts to exercise exhaustively—in a quick and repeatableway—all the main functionalities of a GUI. In addition to that,automated test scripts can also be used to test the presence oregressions in the transition between two consecutive releasesof an application.Several approaches exist for automated GUI testing of An-droid applications. Linares-V ́asquez [15] gives the followingclassificaton: fuzzy (or random) testing, systematic exploration-based testing, Capture & Replay testing, event-sequence genera-tion, and scripted testing. Most of those ways of testing Androidapps allow us to generate repeatable test scripts in some caseswithout having the need of accessing the source code (i.e., onlythe .apk package of the application is needed). If the sourcecode is available to the tester, it is also possible to performscript-based white box testing, as it is made possible by theAndroid testing framework.Random and fuzzy testing techniques provide random se-quences of inputs to the individual activities of the applica-tions in order to trigger potential defects and crashes. In theirsimplest forms—as in Monkey,4the random tester supportedby Android—no additional information about the AUT is re-quired. More complex random testers (like the ones proposedby Machiryet al.[16] and Zhauniarovichet al.[17]) can lever-age a model of the GUI to distribute inputs in a more intelligentway and create test cases that resemble typical user interactions.Model-based testing techniques leverage models (typically,finite-state machines, state charts, or universal modeling lan-guage (UML) diagrams) of the GUI of the apps under test, whichcan be created manually or extracted automatically through aprocess namedGUI ripping. Such models are, therefore, usedto generate systematic test cases traversing the GUI. The toolsand studies by Amalfitanoet al.[18], [19] and Yanget al.[20]can serve as examples of this approach.CodeShoppy
Capture & Replay testing tools (examples are presented inworks by Kaasilaet al.[21], Gomezet al.[22], and Liuet al.[23]) record the operations performed on the GUI to gener-ate repeatable test scripts. Image recognition techniques [24]can be used to verify visual oracles for black-box test cases.Event-sequence generation tools are based on the constructionof test cases as streams of events: examples of this paradigm areprovided in works by Choiet al.[25] and Jensenet al.[26].Less coverage (examples are given in works by Kropp andMorales [14] and Singhet al.[27]) is present in the litera-ture about white-box approaches and scripted GUI automationframeworks, which require the developer to manually select thesequences of operations to be performed on the AUT, identify-ing objects of the GUI through their definition and properties,and write test code accordingly.
There are different levels of testing for Android applications,in addition to the traditional unit testing, integration testing,system testing, and regression testing. Scopes that are specificto the mobile scenario must be considered. Kauret al.[12]list, among the most prominent testing needs for mobile apps,compatibility testing (i.e., to ensure that the application workson different combinations of handheld models and OS versions),performance testing (i.e., to ensure that the application does notexploit any of the resources available, since they can be limited),and security testing (i.e., to ensure that no unauthorized use ofdata and capabilities of the handheld device is performed bythe application). GUI testing is identified as a very prominenttesting need for all mobile applications, since GUI malfunctionscan hamper significantly the user experience provided by an app.GUI testing of Android apps can be performed in variousways. The first and most immediate option is to describe and ex-ecute manual test cases on the GUI of the applications. Linares-V ́asquezet al.[13], who conducted an empirical study in thefield of performance testing, identified manual testing as the op-tion preferred by developers, along with the examination of re-ports and feedbacks given by the users. However, as discussed byKropp and Morales [14], the manual execution of test cases—inaddition to requiring significative effort from testers—is rarelyexhaustive, error prone, and not easily reproducible. On theother hand, automated GUI testing techniques may define setsof scripts to exercise exhaustively—in a quick and repeatableway—all the main functionalities of a GUI. In addition to that,automated test scripts can also be used to test the presence oregressions in the transition between two consecutive releasesof an application.Several approaches exist for automated GUI testing of An-droid applications. Linares-V ́asquez [15] gives the followingclassificaton: fuzzy (or random) testing, systematic exploration-based testing, Capture & Replay testing, event-sequence genera-tion, and scripted testing. Most of those ways of testing Androidapps allow us to generate repeatable test scripts in some caseswithout having the need of accessing the source code (i.e., onlythe .apk package of the application is needed). If the sourcecode is available to the tester, it is also possible to performscript-based white box testing, as it is made possible by theAndroid testing framework.Random and fuzzy testing techniques provide random se-quences of inputs to the individual activities of the applica-tions in order to trigger potential defects and crashes. In theirsimplest forms—as in Monkey,4the random tester supportedby Android—no additional information about the AUT is re-quired. More complex random testers (like the ones proposedby Machiryet al.[16] and Zhauniarovichet al.[17]) can lever-age a model of the GUI to distribute inputs in a more intelligentway and create test cases that resemble typical user interactions.Model-based testing techniques leverage models (typically,finite-state machines, state charts, or universal modeling lan-guage (UML) diagrams) of the GUI of the apps under test, whichcan be created manually or extracted automatically through aprocess namedGUI ripping. Such models are, therefore, usedto generate systematic test cases traversing the GUI. The toolsand studies by Amalfitanoet al.[18], [19] and Yanget al.[20]can serve as examples of this approach.CodeShoppy
Capture & Replay testing tools (examples are presented inworks by Kaasilaet al.[21], Gomezet al.[22], and Liuet al.[23]) record the operations performed on the GUI to gener-ate repeatable test scripts. Image recognition techniques [24]can be used to verify visual oracles for black-box test cases.Event-sequence generation tools are based on the constructionof test cases as streams of events: examples of this paradigm areprovided in works by Choiet al.[25] and Jensenet al.[26].Less coverage (examples are given in works by Kropp andMorales [14] and Singhet al.[27]) is present in the litera-ture about white-box approaches and scripted GUI automationframeworks, which require the developer to manually select thesequences of operations to be performed on the AUT, identify-ing objects of the GUI through their definition and properties,and write test code accordingly.
https://codeshoppy.com/android-app-ideas-for-students-college-project.html
Comments
Post a Comment