Many tester waste a lot of time over the script by wrong method call. A method call, especially one which goes from the client (Selenium bindings) to the code embedded in the web browser (WebDriver) is expensive (time consuming).
Here I would like to write down a typical example : The executing time of: driver.findElement("parent").findElement("child"); Is a lot slower than: driver.findElement("parent child"); Let's think about CSS. Adding a few milliseconds per web element find doesn't seem like a lot but in an entire test suite it could easily double or triple execution time.
1 Comment
Please log down y our all questions on any topic which arise in your mind while taking over the trainning process
Its pretty important. try the following, you will be able to do this !
public class WebDriverTestClass { public static void main(String a[]) throws InterruptedException { try { WebDriver driver = new FirefoxDriver(); // Go to Google Home Page26 driver.get("http://www.google.com"); // Look for search textbox and enter search term there WebElement searchBox = driver.findElement(By.name("q")); searchBox.sendKeys("WebDriver API"); // Click on 'Search'33 WebElement searchButton = driver.findElement(By.name("btnG")); searchButton.click(); // Not required or recommended any where, but just wait for the last37 // click() // operation to get completed fine Thread.sleep(2000); // to return the url System.out.println("What's the current Url: "+ driver.getCurrentUrl()); // if you wish to take screenshot of this page, File scrFile = ((TakesScreenshot) driver) .getScreenshotAs(OutputType.FILE); FileUtils.copyFile(scrFile, new File( "c:\\screenshot\\googlesearch-webdriverapi.png")); // Close the driver, once you're done driver.close(); } catch (Exception e) {53 e.printStackTrace(); // For debugging purposes54 } } } Test Automation on Mobile handsets and other related devices has largely been believed as ineffective and inefficient. The primary and foremost reason being that the difficulties which the automation scripts and tools had to deal with because different hardware characteristics , the resolution settings on the device, the language settings and the other hardware constraints. We have come up with a Mobile Test automation framework which is going to generate instant ROI for automation of functional test cases. The framework broadly covers the following high level approach:
The most significant benefits of traditional test automation are the decreased test execution time and cost, and increased test coverage for each testing cycle. The downside of test automation is the increased test development cost. In a typical test automation scheme, each test is first documented by a test engineer then scripted by an automation engineer. The cost benefit of automated testing comes through the repeated execution of the test automation suite. Since the cost of executing an automated test is far less than the cost of executing a manual test, eventually the decreased test execution cost will make up for the increased development costs.
For example, suppose that a test engineer costs your organization $60/hr, and an automation engineer costs your organization $100/hr. The test engineer can create 5 new test cases per hour during test plan development, and can execute 10 test cases per hour during test execution. The automation engineer can develop 2 test cases per hour. Once those test cases are completed, a test engineer can execute and analyze the results of 50 tests in one hour (typically the test engineer will run the tests overnight, or while he is doing some other work, then analyze the results once the test is done). Suppose you create a test plan with 1000 test cases: For manual testing, your initial test development cost is: 1000 tests * 1 hour/5 test cases * $60/hour = $12,000 The cost of executing all of the tests manually is: 1000 tests * 1 hour/10 test cases * $60/hour = $6,000 For automated testing, your initial cost is: $12,000 + 1000 tests * 1 hour/2 test cases * $100/hour = $65,000 The cost of executing all of the test cases w/ test automation is: 1000 tests * 1 hour/50 test cases * $60/hour = $600 The cost benefit of test automation is realized by running the tests several times (i.e. with each weekly or nightly build of your application). In this case, we begin to see a cost savings if we run the tests more than 12 times. There are several reasons why people choose to automate tests: o Speed up testing to accelerate releases o Allow testing to happen more frequently o Reduce costs of testing by reducing manual labor o Improve test coverage o Ensure consistency o Improve the reliability of testing o Allow testing to be done by staff with less skill o Define the testing process and reduce dependence on the few who know it o Make testing more interesting o Develop programming skills So here we go with the top challenges: 1) Testing the complete application: Is it possible? I think impossible. There are millions of test combinations. It’s not possible to test each and every combination both in manual as well as in automation testing. If you try all these combinations you will never ship the product 2) Misunderstanding of company processes: Some times you just don’t pay proper attention what the company-defined processes are and these are for what purposes. There are some myths in testers that they should only go with company processes even these processes are not applicable for their current testing scenario. This results in incomplete and inappropriate application testing. 3) Relationship with developers: Big challenge. Requires very skilled tester to handle this relation positively and even by completing the work in testers way. There are simply hundreds of excuses developers or testers can make when they are not agree with some points. For this tester also requiresgood communication, troubleshooting and analyzing skill. 4) Regression testing: When project goes on expanding the regression testing work simply becomes uncontrolled. Pressure to handle the current functionality changes, previous working functionality checks and bug tracking. 5) Lack of skilled testers: I will call this as ‘wrong management decision’ while selecting or training testers for their project task in hand. These unskilled fellows may add more chaos than simplifying the testing work. This results into incomplete, insufficient and ad-hoc testing throughout thetesting life cycle. 6) Testing always under time constraint: Hey tester, we want to ship this product by this weekend, are you ready for completion? When this order comes from boss, tester simply focuses on task completion and not on the test coverage and quality of work. There is huge list of tasks that you need to complete within specified time. This includes writing, executing, automating and reviewing the test cases. 7) Which tests to execute first? If you are facing the challenge stated in point no 6, then how will you take decision which test cases should be executed and with what priority? Which tests are important over others? This requires good experience to work under pressure. 8 ) Understanding the requirements: Some times testers are responsible for communicating with customers for understanding the requirements. What if tester fails to understand the requirements? Will he be able to test the application properly? Definitely No! Testers require good listening and understanding capabilities. 9) Automation testing: Many sub challenges – Should automate the testing work? Till what level automation should be done? Do you have sufficient and skilled resources for automation? Is time permissible for automating the test cases? Decision of automation or manual testing will need to address the pros and cons of each process. 10) Decision to stop the testing: When to stop testing? Very difficult decision. Requires core judgment of testing processes and importance of each process. Also requires ‘on the fly’ decision ability. Over to you: Many of you are working in manual and/or automation testing field. Though I have addressed many of above challenges in our previous articles, I want your views on handling these software testing challenges. Feel free to express your views in comment section below. Do you have interest in glassfish Admin GUI with selenium and experience the differences between silk testt and Selenium tools
1. Run Selenium from the build If you build admin-gui module you can find the README.SeleniumRC file under the ../glassfish/admin-gui/tests directory. Just follow the instruction from the file, you should be able to setup and run Selenium JBI tests with Glassfish Admin GUI. If you encounter a failure from your browser, open selenium test case files under java directory and replace statement selenium.waitForCondition("Selenium.browserbot.isNewPageLoaded()", TIMEOUT_PERIOD) by selenium.waitForPageToLoad( TIMEOUT_PERIOD) 2. Run Selenium with Glassfish V2 binary bit 1. You must setup the environment by installing Selenium IDE on your Firefox browser 2. Having ant 1.6.5 and jdk1.5.0_11 or latest version installed on your system 3. Create a AdminGUITest directory on your system and copy the following 4 files to the ../AdminGUITest/lib directory selenium-server.jar , selenium-java-client.jar, selenium-java-client-driver-tests.jar and testng-5.5-jdk15.jar andjunit.jar 4. Copy the simple test harness (AdminGUITest.jar file) to your AdminGUI directory and unjar the file 5. Update build.properties file with your setup environment 6. Start the selenium remote server (assume you're using a window system) cd %AdminGUITest.home% java -jar selenium-server.jar 7. Start glassfish domain1 8. Run the first AdminGUI test case cd %AdminGUITest.home% ant run-test 3. Differences between SilkTest and Selenium what is webdriver ? what is this doing now ? many questions running your mind. right ?
For example, Selenium, a popular and well established testing framework is a wonderful tool that provides a handy unified interface that works with a large number of browsers, and allows you to write your tests in almost every language you can imagine (from Java or C# through PHP to Erlang!). It was one of the first Open Source projects to bring browser-based testing to the masses, and because it's written in JavaScript it's possible to quickly add support for new browsers thatmight be released Like every large project, it's not perfect. Selenium is written in JavaScript which causes a significant weakness: browsers impose a pretty strict security model on any JavaScript that they execute in order to protect a user from malicious scripts. Examples of where this security model makes testing harder are when trying to upload a file (IE prevents JavaScript from changing the value of an INPUT file element) and when trying to navigate between domains (because of the single host origin policy problem). Additionally, being a mature product, the API for Selenium RC has grown over time, and as it has done so it has become harder to understand how best to use it. For example, it's not immediately obvious whether you should be using "type" instead of "typeKeys" to enter text into a form control. Although it's a question of aesthetics, some find the large API intimidating and difficult to navigate. WebDriver takes a different approach to solve the same problem as Selenium. Rather than being a JavaScript application running within the browser, it uses whichever mechanism is most appropriate to control the browser. For Firefox, this means that WebDriver is implemented as an extension. For IE, WebDriver makes use of IE's Automation controls. By changing the mechanism used to control the browser, we can circumvent the restrictions placed on the browser by the JavaScript security model. In those cases where automation through the browser isn't enough, WebDriver can make use of facilities offered by the Operating System. For example, on Windows we simulate typing at the OS level, which means we are more closely modeling how the user interacts with the browser, and that we can type into "file" input elements. With the benefit of hindsight, we have developed a cleaner, Object-based API for WebDriver, rather than follow Selenium's dictionary-based approach. A typical example using WebDriver in Java looks like this: // Create an instance of WebDriver backed by Firefox WebDriver driver = new FirefoxDriver(); // Now go to the Google home page driver.get("http://www.google.com"); // Find the search box, and (ummm...) search for something WebElement searchBox = driver.findElement(By.name("q")); searchBox.sendKeys("selenium"); searchBox.submit(); // And now display the title of the page System.out.println("Title: " + driver.getTitle()); Looking at the two frameworks side-by-side, we found that the weaknesses of one are addressed by the strengths of the other. For example, whilst WebDriver's approach to supporting browsers requires a lot of work from the framework developers, Selenium can easily be extended. Conversely, Selenium always requires a real browser, yet WebDriver can make use of an implementation based on HtmlUnit which provides lightweight, super-fast browser emulation. Selenium has good support for many of the common situations you might want to test, but WebDriver's ability to step outside the JavaScript sandbox opens up some interesting possibilities. These complementary capabilities explain why the two projects are merging: Selenium 2.0 will offer WebDriver's API alongside the traditional Selenium API, and we shall be merging the two implementations to offer a capable, flexible testing framework. One of the benefits of this approach is that there will be an implementation of WebDriver's cleaner APIs backed by the existing Selenium implementation. Although this won't solve the underlying limitations of Selenium's current JavaScript-based approach, it does mean that it becomes easier to test against a broader range of browsers. And the reverse is true; we'll also be emulating the existing Selenium APIs with WebDriver too. This means that teams can make the move to WebDriver's API (and Selenium 2) in a managed and considered way. If you'd like to give WebDriver a try, it's as easy as downloading the zip files, unpacking them and putting the JARs on your CLASSPATH. For the Pythonistas out there, there's also a version of WebDriver for you, and a C# version is waiting in the wings. The project is hosted athttp://webdriver.googlecode.com, and, like any project on Google Code, is Open Source (we're using the Apache 2 license) If you need help getting started, the project's wiki contains useful guides, and the WebDriver group is friendly and helpful (something which makes me feel very happy). So that's WebDriver: a clean, fast framework for automated testing of webapps. We hope you like it as much as we do! I need to get something straight: QA and QC are different. You may ask me. really ?
Why must I point this out? Because programmers don't seem to get it and use these terms interchangeably. so i will tell you like this ... QA is QualityAssurance butQC is QualityControl The difference is that QA is process oriented and QC is product oriented. Testing, therefore is product oriented and thus is in the QC domain. Testing for quality isn't assuring quality, it's controlling it. So still who was argue with me then for them is this clear to you my friend ?
Why all the fuss? There are lots of reasons to ensure the distinction between the two. Easily, the ones that come to mind are:
|
AuthorI am Masud Parvez. Working as IT Senior Project Manager for RMIT University. Previously I built and run a distributed Test Center. My success was to turn that in to one of the most successful business units of the company. Categories
All
|