Considerations for Web Testing

Common Considerations

Specifics of Web Testing in Edge

Specifics of Web Testing in Internet Explorer

Specifics of Web Testing in Chrome

Specifics of Web Testing in Embedded Browsers

• Before you record or run web tests, make sure you configure web browsers as explained in the Preparing Web Browsers section.

• When the Use CSS pixels for scaled pages option is enabled, TestComplete recalculates sizes of web page elements and their coordinates on web pages to take into account the browser’s zoom and the system DPI setting.

  When this option is disabled, the system DPI setting and the browser zoom must be set to 100%. Otherwise, TestComplete will not be able to correctly identify these values.

• When testing HTML input fields, keep in mind that their text is specified by the value attribute. It is not included in the innerHTML and outerHTML properties (although they can include the initial text displayed in the input field).

  For example, web comparison checkpoints verify the page’s HTML markup and therefore do not check values of input fields. To verify the inputted value, use a property checkpoint for the value attribute of the input field.

• The Windows 10 October 2018 update has changed the behavior of the Edge browser: when you close the browser, its process is not terminated and remains in the system. So, the Sys.Browser("*") or Sys.Browser method calls and other script statements that return an active browser will return the Browser object that matches the running Edge instance. This might cause issues for tests that check whether a browser is running or not. Please keep this in mind and modify your tests, if needed.

• To test Microsoft Edge, TestComplete must be installed into a subfolder of the Program Files folder (on 32-bit Windows) or the Program Files (x86) folder (on 64-bit Windows).

• Recording tests in Edge can be slow. We recommend that you record tests in another browser. You can then change the recorded tests to use Edge or make the tests cross-browser.

• TestComplete cannot get page contents if the Content-Security-Policy response header is set to unsafe-inline. To avoid this problem, do not use the Content-Security-Policy header in your tested application or use another browser for testing.

• TestComplete always uses the Tree web object model to expose web elements in the Edge browser. Other web object models are obsolete and are ignored for the Edge browser.

• Standard dialogs (for example, Open File, Save File, Select Folder, and others) you call in the Edge browser are children of a separate PickerHost helper process, not the Edge process. To create a cross-browser test that simulates actions against these dialogs, you need to address those dialogs in the test properly. For sample code that demonstrates how you can address the dialogs, see Handling Browser Differences.

• In the Edge browser, the Authorization dialog is implemented as a separate page, not as a browser dialog.

• Due to security restrictions, the Edge browser prohibits certain actions when local web pages are open in it (that is, web pages stored on your local computer). Namely, it does not display linked images, nor does it load data for framesets that display local files.

• TestComplete cannot identify Edge as a browser if TestComplete is launched with the Compatibility > Run this program as an administrator option set in the file properties. Use the Advanced > Run as administrator file option or the regular Run as administrator command instead.

• After you add or hide toolbars in Edge (such as Favorites), you need to restart Edge in order for TestComplete to calculate the object coordinates correctly.

• Edge does not support Silverlight (and ActiveX plugins in general). Use another browser to test Silverlight applications.

• To test Flash and Flex applications in Edge, you need to use one of the following approaches:

  • Compile the application with the FlexClient library.

  • Run the application via the Runtime Loader.

  The FlashInjector approach is not supported in Edge, because there is no debug version of Flash Player for Windows 10. The MSAA approach cannot be used either.

• The Modern UI (Metro) version of Internet Explorer 11 is not supported.

• To test web applications in Internet Explorer 11 on Windows 10, you must disable multiple processes in Internet Explorer.

• Automated patching of Silverlight applications is not supported in Internet Explorer 11. You need to patch your Silverlight application manually. For instructions, see Preparing Applications With the tcAgPatcher Utility.

• When testing Flash and Flex applications, keep in mind the following:

  • The FlashInjector approach is not supported in Internet Explorer on Windows 10, because the debug version of Flash Player cannot be installed. You can still use Firefox or Chrome with the Flash Player debugger.

  • The MSAA approach is not supported in Internet Explorer 11 on Windows 8 and later.

• To test web pages stored on the local computer in Internet Explorer 11, you need to enable the Allow active content to run in files on My Computer option.

• After closing a tab in Internet Explorer 11 or navigating a tab to another page, the old Page object may remain in the browser’s object hierarchy for some time. This is the actual lifetime of browser tab objects in Internet Explorer.

• TestComplete may not be able to access the Login dialog if it is invoked by a domain other than the domain to which the page that is currently open in the browser belongs. For more information, see Login Object.

• In the Object Browser panel, the object tree displays Internet Explorer windows as separate Browser("iexplore") nodes. For easier testing, each of these nodes contains all the pages that are open in all Internet Explorer windows, so you do not need to address a specific window in your tests.

• On Windows Server operating systems TestComplete may fail to retrieve information on web page objects. To overcome this issue, add the tested site to the list of trusted sites.

• Page hierarchy is not exposed if JavaScript is disabled in Chrome. SmartBear Test Extension embeds its scripts into the page, so, scripting must be enabled in the browser. JavaScript can be enabled (globally or for the tested site) on the Content Settings page in Chrome (chrome://settings/content).

• The hierarchy of web page elements is displayed either as the Tree (recommended) or DOM (obsolete) object model. If some other object model is chosen, it is treated as the Tree model.

• Due to limitations of Chrome’s native messaging protocol, the size of parameters passed to web page scripts cannot exceed 1 MB.

• For security considerations Chrome refuses all extensions to inject code into its internal pages (about:*, chrome:*). Because of that, internal pages, like the new tab page, the extension manager, the download manager, the history page and so on, are not accessible to TestComplete.

• To test web pages stored on the local computer, you need to enable the Allow access to file URLs option of the SmartBear Test Extension.

• With the default security settings Chrome follows the same-origin policy and does not allow cross-origin interaction. Because of this, TestComplete cannot access the contents of cross-origin framesets (when a host of an HTML frame differs from the host of the parent page). To test the contents of such framesets, you need to open the contained frame as a separate web page or launch the Chrome application with the following command-line switches:

  --disable-web-security (for all Chrome versions)

  --user-data-dir=<ProfilePath> (for all Chrome versions)

  --disable-site-isolation-trials (for Chrome version 70 and later)

  The same-origin policy also applies to framesets displaying local files. By default, the local files are considered to belong to different origins and not allowed to access one from another. To solve the latter issue, you can launch the Chrome application with the --allow-file-access-from-files command-line switch.

  The --disable-web-security, --disable-site-isolation-trials and --allow-file-access-from-files command-line switches impair the browser security. We do not recommend using these switches unless required by your testing needs.

• To execute the JavaScript eval function on a web page frame in Chrome, you need to use a specific syntax that includes the frame ID. See Executing JavaScript in Frames in Google Chrome.

• While recording or performing long-term automated tests, Chrome’s hang monitor can consider the SmartBear Test Extension to be stalled and re-launch it.

  To prevent such behavior, TestComplete disables the hang monitor when Chrome is run using the Run Browser keyword test operation or the Browsers.Item(...).Run scripting method. If you launch Chrome in some other way, we also recommend disabling the monitor by appending the --disable-hang-monitor command-line switch to the Chrome executable (chrome.exe).

• Recording tests against complex pages in Chrome with Test Visualizer set to the Capture tested object properties mode may negatively affect Chrome performance. If you experience slowdowns, disable this option or disable Test Visualizer entirely.

• Web testing using Chrome is not supported on Windows XP and Windows Server 2003.

• Testing Silverlight applications in Chrome is not currently supported.

• Chrome running in Modern UI (Metro) mode is not supported.

TestComplete supports web testing in applications that use the Microsoft WebBrowser control or Chromium web browser (in CEF-based and Electron-based applications). Such applications are recognized as generic Windows applications, however, TestComplete uses its web testing abilities to expose the hierarchy of web pages displayed in the embedded browser.

To test web pages displayed in embedded browsers, you must have an active license for the TestComplete Web module. The Desktop module is not required.

Common Considerations for Testing with Embedded Web Browsers

Specifics of Testing Applications with the Embedded Chromium Browser