APPROACH TO TEST DATA INSTRUMENT AND AUTOMATION OF TEST CASES USING REMOTE TESTING PLATFORM
MS. UMA RANI.M Assistant professor
Department of Computing Coimbatore Institute of Technology, Tamil Nadu, India umarani79@yahoo.com.
DR. T.VENKATACHALAM Associate Professor
Department of Physics Coimbatore Institute of Technology, Tamil Nadu, India
Abstract– This paper addresses the technical complexities of the remote testing platform and the test instruments needed to support any device in a remote area. Typically this area addresses the area of verification aspects of any system namely the system testing or field testing.This paper mainlyfocuses on the strategy that needs to be adopted to achieve the concept of remote testing using automation. Here the idea is to have a cloud server where the user can deploy the automated remote testing software and the test devices in remote locations namely the test clientcan connect to the cloud server and make the necessary transactions to complete the installation of test software, test instrument and prepares the test result that gets published back to the server without any human intervention. For any testing to happen we need two basic prerequisites one is test cases and the other is test data, based on the same we arrive at the test result. Now in an era of agile computing and technology sophistication where the areas of work and the requirements are very complex and anarchical in nature it is very difficult to have a complete coverage of test scope and test cases. Now in such an environment where different scenarios and changing scenarios and test data‟s it is highly impractical to foresee and make the test data and test cases. So with that in mind we have presented the test instrument approach where in the complexity of writing, changing and updating the test cases have been abstracted using the automation and test data instrument approach. Here we conceive an XML based approach where in the testers capture their test cases and test data in an xml format and these test data are executed and the results are captured in an automated way.
Index Terms:Android, Complex, Anarchical Requirements, Automation, Agile, Remote Testing, Test instrument.
I. INTRODUCTION
The term testing has lots of implications by the large it has two aspects one is verification and other is validation. As per the V-Model of testing, testing is associated with each and every phase of software development life cycle. The term Remote Automation testing here it means performing the verification activities of system testing once the production phase of the system is completed. It takes in to account of the environment, configuration, power, communication, connectivity, protocol, component integration, deployment and the operating aspects of the system in the intended functional product. Remote testing platform here it means providing the necessary spatial constraints and the ecological attributes that can easily accommodate the flexible, scalable, and reliable needs and wants of the system. Automation here it means reducing the variations and complexitiesby modelling into an entity that exists on it very own virtually without the needs of
human intervention. Typically the above mentioned complexities are modelled from a real world environment in to the virtual world with the support of operating systems, compilers, services, activities, annotations, integrations, functions, databases, datatypes and attributes. The other aspect of validation is of not the interest of this topic as its means of unit testing and checking the capabilities and limits of the built in system. Since the current information technological practices is to provide automation in the retail, financial, healthcare, governance, military and agricultural services there by enabling the migration of the intelligence towards artificial intelligence. Based on the past trends and shifts in the mindset of the industry, the industry has converge towards introduction of new devices namely the mobile phones more appropriately called as smart devices. Now the objective is to how to smartly or innovatively test the smart devices and introduce automation to
already automated devices. Typically we call this approach as innovating the innovation or systemizing the systems more descriptively called as system of systems.
This leads to an area of intuitive thinking to arrive at reutilizing innovative systems in a
recursive manner there by enhancing existing technologies and research areas of the value chain so called as location independent automationwith the aid of the support systems that enables us such a feature.
Although there are many such systems existfor earlier systems namely the pc based rational robot, windows installer for desktop systems. However these systems are standalone systems and the purpose of these systems are well defined by their manufacturing companies. The ideas of this area is to bring in the complexities of these systems bundled together and with the aid of scripts, webservices and XML technologies enabling the usage of different platforms to arrive at a solution which capitalizes the innovations and best features of each standalone platforms like Windows and Linux systems there by enabling the user to leverage the functionality of such above described system so called as SYSTEM of SYSTEMs.
These so called „enablers‟ – namely webservices and xml allows the end users to define their own platforms to satisfy the vagaries and complexities of modelling the real world language and platform independent problems in to intuitive solutions.
As describe above the idea is to bring in plethora of technologies together and reusage of existing innovate platforms to arrive at the needed solution. Keeping in mind the above requirements this paper comes up with an approach that encases the rich and powerful features of windows,Linux, java,android, .Net, webservices,XML, junit, sqlserver and other scripting languages like json and jquery languages.
II. APPROACHOVERVIEW
To support the above requirements, remote testing platform is arrived as a web server with a sql server with webservices interfaces deployed on a cloud server platform. The Client application is typically an Android based application that consumes the webservice interface. The common interfaces between the server and the client
sql server database to hold the artifacts of server and client configurations. The Client side has test case execution engine that typically makes use of the android uiautomator 2.0 api‟s. The intelligence and the operations of testing along with the test data are abstracted in the test instrument;
this instrument along with the testing apk is pushed in to the connected client device through the configured cloud platform. The client based on the commands issues to the client remotely deploys and executes the testapk and generates the test result which isextracted by the server through webservices.
III. IMPLEMENTATIONSCOPE
The test instrument can also be generated with the help of automation but for simplicity and demonstration purposes and to abstract the complexities of android platform we have considered the case of generating the test instrument manually, where in the tester envisages the scenario to be tested captures the same in the XML through his intelligence and the same is used on the client side by the testing apk in the android side to execute the test cases.
As part of the system realization the scope of implementation is development of server side components, development of client side components, arrival of test instrument, Test engine development, generation of test results, hosting the solution to the cloud.
IV. REMOTE AUTOMATION TEST PROCESS
The Remote Automation Test Process is carried out as described in the below diagram and the following are the steps The Remote Test Client performs Login to the running Remote Testing Platform The Client connection status is updated as connected in the webapp Application The tester prepares the test instrument and uploads the Test Engine Apk and
been scheduled for testing and downloads the scheduled artifacts
1. Now the tester decides to issue the command Start Test
2. The Start Test command is notified to all the selected devices
3. On the receipt of the start test command the Test Engine executes the test instrument in the smart devices and generates the result.
4. Now the tester decides and issues the PULL request to pull the generated test results.
5. The Remote testing platform Notifies the PULL request and the same test results are uploaded to the test platform and the platform updates the test results to the management application.
Note:- To maintain and know the status of test engine execution the management client can install any of the third party
supplied VNC or TEAMVIEWER applications to view the destination screens.
Also the Remote test platform maintains the state of the applications pushed and pulled from the connected devices using the SQL Server DB, where the Database maintains the status of the platform for the end users.
The End users are also provided with the option of refresh and clear in the remote test platform upon using the same the remote test platform status gets refreshed or the data maintain gets deleted appropriately.
The End users can maintain and manage the status of the respective test devices and their respective test software‟s and the same is viewed and populated using the dynamic updating of the table view provided in the management webapp application.
V. TESTINSTRUMENTFORMAT&DESCRIPTION
The test instrument that is used to capture the test cases and test data is a XML document, the structure and format of the instrument is based on the UIAutomatorViewer screen. The scope and discussion of UIAutomator is not the objective of this paper.
Based on the uiautomatorviewer the testinstrument xml collected has the below structure as shown in the attached figure.We have also followed the node structure same as the standard structure but added and customized few items suitable to the testers
In-addition to the standard structure we have increased the number of the validation and verification items and the extra customized items are as follows
1. <KeyMap> – This field is to capture the information related to hardware keyevents 2. <ScreenShot> – This field enables the user
to capture the test validation parameters where in the tester can verify screen to screen by checking the changes in the pixel variations
3. <Swipe>– This field allows the tester to capture the swipe functionality
4. <Validation> – This field allows the custom handling of variations in verification criteria by enabling this tester can customize the test commands and can handle the implementation to his situation of course any customization needs the software to be re-engineered.
Note: - The addition of above items needs to be handled by the way manually edition by the tester as it is understood that these are the clear improvement areas from the standard ones and is only applicable as improvement areas of this research paper.
With this capability the system allow us to perform the key functionality of Test case execution of the functional area.
VI. TESTCASEEXECUTIONS
Now how to visualize the areas of test case execution, to connect with the standard testing process, any testing process as the following methodology:
Apart from this each test case which the tester visualizes are captured using the node structure based on the values of the structure that is part of the input data is compared in the runtime with the structure of the system running data this will be the current value, now if this both the things are matching we can claim that the test cases are PASS, if not the test cases are FAIL. Now based on the attributes the system reads the data from the input it will execute the operations as desired. Like for eg- if clickable is set to “one or true” the respective item is searched using the uiautomator api and performed the respective action, now based on the condition parameter we evaluate the node structure and infer the results.
For customized items and any items newly added by the tester, we have left the implementations to the testers and their field of view basically we have visualized a very flexible, scalable customized test platform through this approach.
VII. TESTRESULTSANDREPORTS
Now when we add the inference like status or outcome to the above test cases we arrive at the test result, the system will output the test result in a test report format like
“TestReport.XLS” the structure of the same is listed below.
The same report can be further customized to have a test summary in case if we have multiple functionalities to be tested captured as separate test case documents.
VIII. REMOTETESTPLATFORM IMPLEMENTATION
client communicates with the server through the webservices and its respective interfaces are as follows:
IX. REMOTETESTPLATFORMSERVER UI
REMOTE TEST PLATFORM CLIENT UI
X. LIMITATIONS
The only limitation we foresee as part of this paper is to usage of the technology such as ASP.net and Android; the same concepts can be conceived and visualized using any of the other platforms and technologies. The limitations with respect to the instruments are with respect to the usage of uiautomator viewer. This paper The following are the UI of client
has stopped with suggestion of capturing of test cases manually.
XI. CONCLUSION
Now we have presented the system of remote testing platform in a more robust , scalable, extendible work that easily captures the day today transactions of any tester there by successfully leading to the area of automations more broadly this paper classifies it as remote automation.
Based on the results arrived Based on the cost uncertain we conclude that by adopting such an approach will lead to a great reduction in the cost, schedule and effort parameters that is needed in any software development lifecycle. Moreover this platform and solution presented has provided many opportunities for the testers to visualize and make this approach innovative. However the important aspect of testing is capturing of test cases, if any tester thinks innovatively with the same approach the user can easily create the capturing of test cases also automatically by employing the same technique as suggested. As there is way suggested to easily capture the test scenario s and test cases this is left to the end user to apply the same and benefit out of this research area
XII. FUTUREWORK
As captured in the limitations section this solution can be made innovative by automating the capturing of test cases and also employing any new cutting edge technologies.
ACKNOWLEDGEMENTS
We sincerely thank the working institution in providing me an opportunity to work in the areaof automation research. Also all my fellow colleagues and friends, for theireverlasting support to achieve this work. We also thank all our support materials and schemes used to implement this work.
REFERENCES
1. AndroidUIAutomator, -
2. https://developer.android.com/training/testing/ui -testing/uiautomator-testing.html
3. Xuetao Wei, Lorenzo Gomez, Iulian Neamtiu, and Michalis FaloutsosProfileDroid: Multi-layer Profiling of Android Applications - MobiCom‟12, August 22–
26, 2012, Istanbul, Turkey
4. Lorenzo Gomez, Iulian Neamtiu, Tanzirul Azim, and Todd Millstein. Record and Replay for Android -RERAN-ICSE May 2013
5. XML specifications- https://www.w3.org/XML/
6. Automated Integration Tests for Mobile Applications in Java 2 Micro Edition- Weiss, D., Zduniak,. BIS 2007, pp. 478-487
7. JoukoKaasila,DenzilFerreira,VassilisKostakos,Timo OjalaTestdroid: automated remote UI testing on AndroidMUM ‟12, Dec 04-06 2012, Ulm, Germany
