How to identify dynamically changing objects in QTP ?
Consider an example where you are having a tree with nodes [can be folder or directory]. The tree as a whole is designed as a web table and sub-folders again as a sub-web table. It is easy to identify the index of the tree node while recording, but during playback when an additional folder or directory is added the index will be changed. In this kind of situation where the index of the objects changes dynamically, there are two actions to be performed. Identify the properties of the object Identify the index at run time Identify the properties of the object Use object spy Add the object to OR Identify the index at run time We can use the following piece of code once the properties are identified For i = 0 to 1000 set sObjTable = Browser(“Browser”).Page(“Page”).WebTable(“index:=”&i) If Browser(“Browser”).Page(“Page”).WebTable(“index:=”&i). exist Then If sObjTable.GetROProperty(“property name that is not changed”) = <Value that is expected> Then Set sRootFolder = sObjTable End if Else Exit for End If Next In a similar manner, we can identify checkbox and radio button objects whose index changes at run time. This worked for me, hope it will be useful for you too. Have questions? Contact the software testing experts at InApp to learn more.
Work with multiple IE instances using QTP
If your IE-based application opens another window whose properties are the same, it would be difficult to identify the objects in the newly opened browser. For example, consider an application, login user is navigated to a launch page where we can launch our application in a new window. All the windows opened are having the same set of properties like title, name, etc. Solution: We can select the objects in any page based on the creation time property of the window. Set oDesc = Description.Create oDesc( “micclass” ).Value = “Browser” Set sDesk=Desktop.ChildObjects(oDesc) Set objBrowser = Browser(“creationtime:=1”) Set App_objPage = objBrowser.Page(“title:=NAME”) Make sure all the other IE instances are closed before our scripts start execution. Have questions? Contact the software testing experts at InApp to learn more.
Harness Test Automation
What is Harness Test Automation? The harness is a server-side testing framework. It is being used for testing the server-side functionalities. Cactus (Jakarta product for java server-side testing) is a simple open-source test framework used for unit testing server-side java code (Servlets, EJBs, Tag Libs, Filters,…), and harness is built over it. JUnit V/s Harness JUnit tests run in the same JVM as the test subject whereas Harness tests start in one JVM and are sent to the app server’s JVM to be run. The package is sent via HTTP to the redirector. The redirector then unpacks the information, finds the test class and method, and performs the test. How do the Cactus work? Cactus has a class called ServletTestCase and it has 3 functionalities. 1) beginXXXX(WebRequestwebRequest){ } 2) testXXXXX(){ } 3) endXXXXX(WebResponsewebResponse ){ } Begin() – Here parameters are added to a request. It is executed on the client side. eg): In login, we can add a username and password to webRequest. Test() – Here we call the respective actions to be tested. In this, we get the implicit objects like request, response, and session as well as the parameters that we pass via Testcases.xml which are added inbeginXXXX(). Here we call the respective actions to be tested, which return pass or fail based on assertions. It is executed on the server-side. End() – The values in the response from the action can be tested here. It is executed on the client side. We have extended ServletTestCase to our harness framework with a class called FrameworkServletTestCase. FrameworkServletTestCase has the functionalities to getconfiguration files, testcases etc. The FrameworkServletTestCase is further extended to another class called QAToolTestCase. QAToolTestCase has postAssertions() and preAssertions()functionalities, which form the basis of whether a test case passes or fails. Cactus is configured in its property file called cactus.properties. Parameters configured are – cactus.contextURL = http://localhost:8080/CServer cactus.servletRedirectorName = ServletRedirector cactus.enableLogging=true We need to add the servlet class and servlet-mapping in web.xml for ServletRedirecton <!– Cactus Servlet Redirector configuration –> <servlet> <servlet-name>ServletRedirector</servlet-name> <servlet-class>org.apache.cactus.server.ServletTestRedirector</servlet-class> </servlet> <!– Cactus Servlet Redirector URL mapping –> <servlet-mapping> <servlet-name>ServletRedirector</servlet-name> <url-pattern>/ServletRedirector</url-pattern> </servlet-mapping> Test cases are configured in the testcasexmls, where the parameters to be passed are defined. Test cases can be broken into smaller units called Snippets. These snippets are called fromTestCases.xml. Have questions? Contact the software testing experts at InApp to learn more.