반응형
블로그 이미지
개발자로서 현장에서 일하면서 새로 접하는 기술들이나 알게된 정보 등을 정리하기 위한 블로그입니다. 운 좋게 미국에서 큰 회사들의 프로젝트에서 컬설턴트로 일하고 있어서 새로운 기술들을 접할 기회가 많이 있습니다. 미국의 IT 프로젝트에서 사용되는 툴들에 대해 많은 분들과 정보를 공유하고 싶습니다.
솔웅

최근에 올라온 글

최근에 달린 댓글

최근에 받은 트랙백

글 보관함

카테고리


반응형

Internet Explorer Driver


인터넷 익스플로러드라이버는 webDriver의 wire 프로토콜을 implement한 standalone 서버 입니다. 이 드라이버는 XP, Vista, Windows 7에서 IE 6, 7, 8, 9 버전을 가지고 테스트를 했습니다.

이 드라이버는 브라우저의 32비트와 64 비트 버전을 지원합니다. 각 버전은 어떤 버전의 IEDriverServer.exe 에 따라 결정 됩니다. 32 비트 IEDriverServer.exe 가 실행이 되면 32비트 버전의 IE가 시작이 될 것이고 IEDriverServer.exe가 64비트라면 64비트 IE가 실행이 될 겁니다.

Installing


일단 standalon server 로 실행할 수 있는 IE버전다운로드 받아야 합니다. 그리고 여러분이 사용하는 PATH 에 복사해 넣습니다.


Pros (장점)

    Runs in a real browser and supports Javascript
    실제 브라우저가 실행되고 자바스크립트를 지원합니다.

Cons (단점)

    IEDriver는 Windows에서만 작동됩니다.
    Comparatively slow (though still pretty snappy :)
    비교적 느립니다.


Command-Line Switches


standalone으로 실행되니까, IE driver의 behavoir를 command-line argument들로 컨트롤 할 수 있습니다. 이 코맨드라인 argument의 값을 세팅하려면 여러분이 사용하는 language에 맞는 명령어를 사용해야 합니다. command line switch 는 아래 테이블에 있는 기능들을 지원합니다. -<switch>, --<switch> and /<switch> 가 사용 가능합니다.


Switch Meaning
--port=<portNumber> Specifies the port on which the HTTP server of the IE driver will listen for commands from language bindings. Defaults to 5555.
--host=<hostAdapterIPAddress> Specifies the IP address of the host adapter on which the HTTP server of the IE driver will listen for commands from language bindings. Defaults to 127.0.0.1.
--log-level=<logLevel> Specifies the level at which logging messages are output. Valid values are FATAL, ERROR, WARN, INFO, DEBUG, and TRACE. Defaults to FATAL.
--log-file=<logFile> Specifies the full path and file name of the log file. Defaults to stdout.
--extract-path=<path> Specifies the full path to the directory used to extract supporting files used by the server. Defaults to the TEMP directory if not specified.
--silent Suppresses diagnostic output when the server is started.




Important System Properties



아래의 시스템 프로퍼티들은 InternetExplorerDriver에 의해 사용됩니다. (자바의 경우 System.getProperty() and set using System.setProperty() 를 보세요. or the "-DpropertyName=value" command line flag)

Property What it means
webdriver.ie.driver The location of the IE driver binary.
webdriver.ie.driver.host Specifies the IP address of the host adapter on which the IE driver will listen.
webdriver.ie.driver.loglevel Specifies the level at which logging messages are output. Valid values are FATAL, ERROR, WARN, INFO, DEBUG, and TRACE. Defaults to FATAL.
webdriver.ie.driver.logfile Specifies the full path and file name of the log file.
webdriver.ie.driver.silent Suppresses diagnostic output when the IE driver is started.



Required Configuration


    - IEDriverServer 를 다운 받아서 해당 PATH에 복사해 넣어야 합니다.
    - Windows Vista나 Windows 7에서 IE 7 이상의 브라우저를 사용할 때 각 zone의 모드를 Protected Mode로 세팅 해야 합니다. 이 값들을 Tools 메뉴에서 on 이나 off로 세팅될 수 있습니다. 그리고 Security tab을 클릭하시면 됩니다. 각 zone에 보면 그 탭의 아래 부분에 체크박스가 있을 겁니다. 이 체크박스 (Enable Protected Mode)를 체크하시고 적용하시면 됩니다.
    - browser zoom level은 반드시 100%로 세팅되어야 합니다. 그래야 마우스 이벤트가 정확한 지점에서 일어날 수 있습니다. 






Native Events and Internet Explorer

IE드라이버는 윈도우즈에서만 돌아가기 때문에 브라우저에서 마우스나 키보드를 작동시킬 때는 OS level(이것을 native 라고 부르기도 합니다.)의 이벤트를 사용해야 됩니다.  같은 기능에 대해 시뮬레이트되는 자바스크립트 이벤트를 사용하는 것과 좀 차이가 있습니다.이 native 이벤트를 사용할 때의 장점은 JavaScript sandbox에 의존하지 않는 다는 겁니다. 그래서 브라우저 내에서 정확한 자바스크립트 이벤트를 사용할 수 있습니다. 하지만 현재 마우스 이벤트에 대한 몇가지 이슈들이 있는데요. IE 브라우저 윈도우가 focus를 잃어 버릴 때나 element들 위에 hover를 실행할 때에 이슈들이 좀 있습니다.



Browser Focus

The challenge is that IE itself appears to not fully respect the Windows messages we send the IE browser window (WM_MOUSEDOWN and WM_MOUSEUP) if the window doesn't have the focus. Specifically, the element being clicked on will receive a focus window around it, but the click will not be processed by the element. Arguably, we shouldn't be sending messages at all; rather, we should be using the SendInput() API, but that API explicitly requires the window to have the focus. We have two conflicting goals with the WebDriver project.

First, we strive to emulate the user as closely as possible. This means using native events rather than simulating the events using JavaScript.

Second, we want to not require focus of the browser window being automated. This means that just forcing the browser window to the foreground is suboptimal.

An additional consideration is the possibility of multiple IE instances running under multiple WebDriver instances, which means any such "bring the window to the foreground" solution will have to be wrapped in some sort of synchronizing construct (mutex?) within the IE driver's C++ code. Even so, this code will still be subject to race conditions, if, for example, the user brings another window to the foreground between the driver bringing IE to the foreground and executing the native event.

The discussion around the requirements of the driver and how to prioritize these two conflicting goals is ongoing. The current prevailing wisdom is to prioritize the former over the latter, and document that your machine will be unavailable for other tasks when using the IE driver. However, that decision is far from finalized, and the code to implement it is likely to be rather complicated.



Hovering Over Elements


When you attempt to hover over elements, and your physical mouse cursor is within the boundaries of the IE browser window, the hover will not work. More specifically, the hover will appear to work for a fraction of a second, and then the element will revert back to its previous state. The prevailing theory why this occurs is that IE is doing hit-testing of some sort during its event loop, which causes it to respond to the physical mouse position when the physical cursor is within the window bounds. The WebDriver development team has been unable to discover a workaround for this behavior of IE.



Clicking <option> Elements or Submitting Forms and alert()


There are two places where the IE driver does not interact with elements using native events. This is in clicking <option> elements within a <select> element. Under normal circumstances, the IE driver calculates where to click based on the position and size of the element, typically as returned by the JavaScript getBoundingClientRect() method. However, for <option> elements, getBoundingClientRect() returns a rectangle with zero position and zero size. The IE driver handles this one scenario by using the click() Automation Atom, which essentially sets the .selected property of the element and simulates the onChange event in JavaScript. However, this means that if the onChange event of the <select> element contains JavaScript code that calls alert(), confirm() or prompt(), calling WebElement's click() method will hang until the modal dialog is manually dismissed. There is no known workaround for this behavior using only WebDriver code.

Similarly, there are some scenarios when submitting an HTML form via WebElement's submit() method may have the same effect. This can happen if the driver calls the JavaScript submit() function on the form, and there is an onSubmit event handler that calls the JavaScript alert(), confirm(), or prompt() functions.

This restriction is filed as  issue 3508 .



Multiple instances of InternetExplorerDriver


With the creation of the IEDriverServer.exe, it should be possible to create and use multiple simultaneous instances of the InternetExplorerDriver. However, this functionality is largely untested, and there may be issues with cookies, window focus, and the like. If you attempt to use multiple instances of the IE driver, and run into such issues, consider using the RemoteWebDriver and virtual machines.

There are 2 solutions for problem with cookies (and another session items) shared between multiple instances of InternetExplorer.

The first is to start your InternetExplorer in private mode. After that InternetExplorer will be started with clean session data and will not save changed session data at quiting. To do so you need to pass 2 specific capabilities to driver: ie.forceCreateProcessApi with true value and ie.browserCommandLineSwitches with -private value. Be note that it will work only for InternetExplorer 8 and newer, and Windows Registry HKLM_CURRENT_USER\\Software\\Microsoft\\Internet Explorer\\Main path should contain key TabProcGrowth with 0 value.

The second is to clean session during InternetExplorer starting. For this you need to pass specific ie.ensureCleanSession capability with true value to driver. This clears the cache for all running instances of InternetExplorer, including those started manually.



Running IEDriverServer.exe Remotely


The HTTP server started by the IEDriverServer.exe sets an access control list to only accept connections from the local machine, and disallows incoming connections from remote machines. At present, this cannot be changed without modifying the source code to the IEDriverServer.exe. To run the Internet Explorer driver on a remote machine, use the Java standalone remote server in connection with your language binding's equivalent of RemoteWebDriver.

반응형