Archit Goel, IJRIT 798 International Journal of Research in Information Technology (IJRIT)
www.ijrit.com www.ijrit.com www.ijrit.com
www.ijrit.com ISSN 2001-5569
Automation Testing of Web Applications Using Controller Driven Framework
Archit Goel 1 , Prof. (Dr.) Jayant Shekhar 2
1 Department of Computer Science and Engineering, Swami Vivekanand Subharti University Meerut, Uttar Pradesh, India
Email: [email protected]
2 Principal, Subharti Institute of Technology and Engineering, Swami Vivekanand Subharti University Meerut, Uttar Pradesh, India
Email: [email protected]
Abstract:
Manual testing is performed when Test Engineer is given Application and he starts executing the test steps.
Automation Testing is described as use of automation tool for executing the test case suite. Test Automation demands investments of money and engineers efforts. Successive development cycles demands execution of same test suite repeatedly. Thus involvement of Automation of web applications will reduce the count of test cases which needs to be executed manually but it will not replace manual testing completely. Automation testing become important due to reasons like: Manual Testing of complete application, all scenarios is time and cost consuming Hence it is difficult to perform testing for multi language web applications manually, Human intervention not required in automation testing, We can run automation test scripts without need of attention (overnight), Automation leads to speedy execution, Automation helps in increasing Test Coverage, manual testing leads to error due to human errors. Test cases that are required to be automated can be selected depending on increasing the ROI which are further based on- client based critical test cases, Test cases that need repeated execution, Test Cases or scenarios which are very typical to execute manually, Test Case requiring long time duration. Automation testing being part of today’s world and various Test Automation frameworks leads to execution of all the test scenarios and all test cases in test suite but Automation Testing of Web Applications using Controller driven Framework is proposed to enhance the testing of web applications. Automation testing of web Applications in controlled way, executing only those test cases that are needed for that moment and Getting output for only those test cases in Pass and Fail form.
Keywords
Automation Testing, QTP, Manual testing, Controller driven Framework
1. Introduction
Regression Testing is the testing of software when changes has been made, this testing is done to make sure that the reliability of each software release, testing after changes has been made to ensure that changes did not introduce any new errors into the system.
Software quality is regarding how much the functions of that given software under test are according to the requirements of the customers need. It may take execution of many test cases to determine about a web application is working as expected. Test cases are often referred to as test scripts, particularly when written. Test cases are usually collected into test suites [7]. Software quality can be discussed, analyzed, and judged, but can’t be measured.
A primary purpose of testing is to report software failures so that defects can be discovered and fixed. Testing
Archit Goel, IJRIT 799
cannot give us surety that a web application working properly under all possible conditions but will only let us inform that it does not work properly under given conditions of client and test cases. Scope of software testing usually includes code examination as well as code execution in various conditions. You can create tests that check all aspects of your application or Web site, and then run these tests every time your site or application changes [8].
In Software developments current culture, a testing team is supposed to be working in a way to let the development team down by finding more bugs. Challenges occur during the Software Testing both in manual and automation testing. In manual testing generally developers deploys build to testing team by assuming that the responsible test team or test engineer will pick the build and will come and say this is not good build. This is the case in organizations when not following the processes. Tester Engineer is between development team and the customers who handle the pressure from both the sides but this is not the situation always. Sometimes test engineers create havoc in testing due to lack of application and testing knowledge while working.
In automated testing the costs are mainly influenced by the number of test cases, manual testing costs are determined by the number of test executions. Thus, in manual testing, it does not make a difference whether we execute the same test twice or whether we run two different tests. This is consistent with manual testing in practice – each manual test execution usually runs a variation of same test case [6]
2. Literature Review
In this section we introduce the two strategies unified by our tool, manual testing and automated testing, then an analysis of already present frameworks. We can create tests that check all aspects of our Web application and then run these tests suit every time our application changes. [3]
Speed-Automation testing runs comparatively faster than human user.
Coding-We code sophisticated tests that bring out some critical information.
Reliable -Performs the same operations each time accurately thereby eliminating error by test engineer.
Reusable-We can build a tests suite which covers every feature in our web application.
2.1 Manual Testing
Here (input data generation and test result verification) need to be created by hand. In manual testing the test team generates various test cases, repeated again till the error is removed. [3]
a) Manual Testing is not reusable.
b) Each time effort will be same.
c) Scripting facility is not available in manual testing. [1]
d) Visibility of Manual Tests is limited and needs to be repeated by everyone.
e) Results can only be seen by the developer testing the code.
2.2 Automated Testing Frameworks
Automation test cases used to execute a sequence of actions without any human interference. It is also described as testing a system with different data sets again and again without human intervention. Simply automated testing is automating the manual efforts of testing process currently being used. Automation is the use of tools and sequence that tries to reduce the need of manual, human efforts, interaction in repetitive tasks. All this includes: Detailed test cases creation- including expected results that have been created from Business Specific point of view and by looking Design Documents of application. A standalone Test Environment including a Test Database that is restorable to a known constant, such that test cases are able to repeat each time there are modifications made to the application[1], [4].
In Data Driven Framework, we put data in excel sheet or data table of QTP itself and then write the code using VB Scripting and when script executes then data is derived from excel sheets or data table of qtp into variable so that it will be used in code.
Archit Goel, IJRIT 800 Fig. 1. QTP picking data from Excel
QTP opens excel sheet and then excel sheet gets copied to the data table of qtp and then qtp reads from the data table.
In Keyword driven framework, we write the script for test case in linear manner then divide the linear script in form of functions and transfer the functions into library of function and call from script and create the test flow sheet and keywords are added in same sheet and separate library for functions is created to read keywords from sheet and map all the keywords with appropriate functions and then scripts execute and gives the result to find whether everything working fine or not.
Fig. 2 Flow diagram of Keyword driven framework
3. Proposed Controller driven framework model
Table.1 first sheet QTPCRCQID as sheet name
QTPCRCQID sheet name have three columns
a) CQIDNO is name of column where we mention CR name b) CRCQ_Description is description of CR
c) CQexecFlag is flag where we write ‘Y’ or ‘N’ where Y denotes that we want to execute the CR to be executed and N denotes that this CR should not be executed.
Table.2 Second sheet QTPCRCQ_TestScenario is sheet name
Archit Goel, IJRIT 801 QTPCRCQ_TestScenario is sheet name where following fields are present-
a) CRCQ_TS_IDNO - denotes Scenario name or number of CR b) CRCQ_TestScenario_Description - denotes description of Scenario c) CRCQ_TS_ExeFlag - denotes ‘Y’ and ‘N’ flag
d) Result- result of execution
e) Map_CQIDNO_CRCQTSID –denotes CR name as mentioned in 1st sheet f) ActionCQIDNO – Action name for that test scenario
g) ActionNamePath – denotes path where action is located
Table.3 Third sheet QTPCRCQ_TestScenario_TestCase is sheet name
QTPCRCQ_TestScenario_TestCase is sheet name where following fields are present-
a) CQ_TS_TC_IDNO - denotes test case name of scenario b) CQ_TS_TC_Description – denotes test case description
c) Keyword – denotes keyword name that identifies test case in test script d) Result – denotes pass or fail status of test case
Archit Goel, IJRIT 802
e) Map_CRCQ_TS_IDNO - denotes test scenario name under which this test case comes acts as foreign key and denotes test scenario name and maps scenario name mentioned in sheet 2nd of keyword file with test cases in 3rd sheet under which this test case comes in short (CRCQ_TS_IDNO column in sheet 2nd mapped with column Map_CRCQ_TS_IDNO in sheet 3rd)
f) CRCQ_TS_TC_ExeFlag – Y or N depending on if we want to execute.
4. Controller Framework Working
Fig. 3 Flow diagram of Controller Driven Framework
Driver script-
We open QTP and then open this driver script in QTP and then when we run this driver script then firstly (action 1 runs and then Stub Script)Environment file-This file will contain test data file name and its location and controller file name and its location Controller file-This file contains detailed information of which test cases to be executed and which not and actions names and its location and it gets loaded by the driver script.
Test data file-This file contains test data to be used for testing purpose of application, this file is also gets loaded by the driver script.
Test scripts-This file also gets loaded for execution and then it move on to script actions that we coded for CR and application pages starts getting visited and executed as per test cases that gives result .
5. Conclusion
After using Controller driven framework all the below conditions will be easily tackled a) Test cases which have frequent defects
b) Functionalities which are clearly visible to the users
c) Test cases which verify basic and important features of the product
d) Test cases of Functionalities which has undergone changes recently and very largely.
e) Execution of all Integration Test Cases f) Execution of Complex Test Cases
We will be able to see the output for following conditions easily- a) Feature that is important for the business
Archit Goel, IJRIT 803 b) Scenarios which have large amount of data
c) Common functionalities across applications d) Extent to which business components are reused e) Complexity of test cases
Table.4 Output in PASS and FAIL form for particular test cases
New proposed method helpful in reducing the cost and risk in our component based development process to defeat the problem before software testing phase according to the Halsted software science. It would be very beneficial because the testing phase consume more time in comparison of all the phases and by applying this method researchers and practitioners predict the software reliability and reusability with general factors viz. software requirement, design, code, component complexity, software complexity. So this method will help to make a reliable component based software based system and thus it has great applicability in measuring the quality of component- based software.
6. References
[1] Innovative approaches of automated tools in software testing and current technology as compared to manual testing, Global journal of enterprise of information system, Jan 2009-june 2009.
[2] Leckraj Nagowah and Purmanand Roopnah, “AsT -A Simp le Automated System Testing Tool”, IEEE, 978-1- 4244- 5540-9/10, 2010.
[3] Alex Cerv antes, “Exploring the Use of a Test Automation Framework”, IEEEAC p ap er #1477, version 2, up dated January 9, 2009.
[4] A. Ieshin, M. Gerenko, and V. Dmitriev, “Test Automation- Flexible Way”, IEEE, 978-1-4244-5665-9, 2009.
[5] Boehm, B., Value-Based Software Engineering: Overview and Agenda. In: Biffl S. et al.: Value-Based Software Engineering. Springer, 2005.
Archit Goel, IJRIT 804
[6] RamlerR., Biffl S., Grünbacher P., Valuebased Management of Software Testing. In: Biffl S. et al. Value-Based Software Engineering. Springer, 2005.
[7] D. Marinov and S. Khurshid, "TestEra: A Novel Framework for Automated Testing of Java Programs," in Proc.~16th IEEE International Conference on Automated Software Engineering (ASE), 2001, pp. 22-34.
[8] Dustin, E. et. al., Automated Software Testing, Addison- Wesley, 1999.
[9] Khaled M.Mustafa, Rafa E. Al-Qutaish, Mohammad I. Muhairat, “Cassification of Software testing Tools Based on the Software Testing Methods”, 2009 second International Conference on Computer and Electrical Engineering, 978-0-7695-3925-6, 2009.
[10] R.S.Pressman, “Software Engineering A Practitioner‟s Approach”, Mcgraw-Hill International Edition, ISBN 007-124083-7.
[11] D. Marinov and S. Khurshid, "TestEra: A Novel Framework for Automated Testing of Java Programs," in Proc.~16th IEEE International Conference on Automated Software Engineering (ASE), 2001, pp. 22-34
[12] P. Tonella, "Evolutionary testing of classes," in International symposium on Software testing and analysis (ISSTA'04). Boston, Massachusetts, USA: ACM Press, 2004, pp. 119-128.
[13] N. K. Patrice Godefroid, Koushik Sen, "DART: directed automated random testing," presented at PLDI '05:
Proceedings of the 2005 ACM SIGPLAN conference on Programming language design and implementation, 2005.
[14] Dustin, E. et. al., Automated Software Testing, Addison- Wesley, 1999.
[15] Fewster, M., Graham, D., Software Test Automation: Effective Use of Text Execution Tool, Addison-Wesley, 1999.