This topic provides an overview of SOAtest’s web functional (cross-browser) testing capabilities. In this section:

Web Testing Introduction

Organizations often abandon automated web testing in favor of manual testing due to the false positives and maintenance issues associated with automated tests. SOAtest removes the barriers to automated web testing by isolating and testing individual application components for correct functionality across multiple browsers without requiring scripts. Dynamic data can be stubbed out with constant data to reduce test case noise. Validations can be performed at the page object level as well as the HTTP message level. SOAtest also verifies the client-side JavaScript engine under expected and unexpected conditions through asynchronous HTTP message stubbing.

Browser Recording and Cross-Browser Execution

The first step in web testing is browser recording, which is described in Browser Recording and Playback.

Once created, tests can be executed as described in Executing Functional Tests.

Extending and Reusing Web Scenarios

You can rapidly extend your recorded web scenarios to meet your goals. The following examples are common practices for extending and reusing web scenarios:

Browser Support

The following browsers are supported for playback:

  • Firefox 47.0.2 and earlier
  • Google Chrome
  • Internet Explorer 11
  • Microsoft Edge Windows Anniversary Edition (version 38.14393)+ (see Microsoft Edge Notes for additional information)
  • Chromium-based Edge browser version 79+ (see Microsoft Edge Notes for additional information)

Firefox Notes

  • Playing back inputs that allow you to browse to a file to upload it is not supported in Firefox 3 and later.
  • If Firefox is in the middle of an automatic update (i.e., the update was downloaded but not yet installed), web scenarios may not play back correctly. Virtualize will launch Firefox and Firefox will open a dialog to check add-on compatibility, which causes playback to fail. If this occurs, launch Firefox outside of Virtualize to complete the update installation. Once the update is completed, web scenarios can be played back as usual.

Internet Explorer Notes

  • Before using Internet Explorer, see Configuring Internet Explorer Settings.

  • With Internet Explorer 9 or 10, we recommend using addEventListener() when registering event listeners. However, if you are using attachEvent(), which is an IE-specific event model, you will need to manually update HTMLUtil.js file located in the  <INSTALL>\plugins\com.parasoft.ptest.libs.web_<VERSION>\root\browsers\ie\ directory as follows to force Virtualize to emulate JavaScript events using the IE-specific model:

    SOAtest

    "ext.HTMLUtil.preferLegacyEventModel = false;"
    to
    "ext.HTMLUtil.preferLegacyEventModel = true;"

    Virtualize

    "_wk_HTMLUtil.preferLegacyEventModel = false;"
    to
    "_wk_HTMLUtil.preferLegacyEventModel = true;"

  • The first time that Internet Explorer 9 is launched, it will open a warning dialog that states "The Recorder Registrar is now ready to use." You need to click Enable to ensure that your web scenarios record and play back correctly. For best results, you should close and re-open the browser after clicking Enable.

  • File inputs inside modal dialogs are not supported.
  • Record and playback on file inputs (inputs that allow you to browse to a file to upload it) is not supported in Internet Explorer 8 and later.

Chrome Notes

  • When specifying the path to the Chrome executable on Linux, choose google-chrome (e.g. /opt/google/chrome/google-chrome)—not chrome. On Windows, the path is typically C:\Users\usernane\AppData\Local\Google\Chrome\Application\chrome.exe. On Mac, it’s typically /Applications/Google Chrome.app.
  • If you just recorded a web scenario and the browser contents for the last step was not captured, you can play the scenario to capture this content. Note that this happens when you stop recording by closing the browser window. The recommended best practice is to stop recording by clicking the Stop Recording button (instead of by closing the browser window).

  • On Chrome, Auto Generate Asynchronous Request Tests captures only requests from an XMLHttpRequest object. It does not detect asynchronous requests from hidden IFrame calls. If needed, you can add such asynchronous request tests manually.

  • When a user acts on an element, Chrome (unlike Internet Explorer and Firefox) does not check other frames to ensure that the locator is unique across frames. As a result, a recorded action might be played back in a frame other than the one it was recorded in. If you experience this unexpected behavior, determine a unique locator and change the locator being used in the Browser Playback tool.

  • In some cases, login is required before asynchronous requests can occur. Firefox and IE will detect this, and test suites will automatically create a setup test that performs this login. The asynchronous test will then use the cookies created by logging in. Chrome does not support this. For Chrome, SOAtest can generate asynchronous request tests, but the login step needs to be set up manually—either as a setup test, or a test suite tool that is run before the asynchronous tests.

  • Record and playback on file inputs (inputs that allow you to browse to a file to upload it) is not supported in Chrome.
  • When recording or playing back with Chrome on Mac using the Parasoft native engine, closing Chrome opens a dialog that says "Google Chrome wants to use your confidential information stored in ’Chrome Safe Storage’ in your keychain. Do you want to allow access to this item?" Even if you choose "Always Allow", this dialog opens every time that Chrome is started and then closed. To prevent this dialog from opening every time:
    • Open Applications> Utilities> Keychain Access.
    • Control-click Chrome Safe Storage, then choose Get Info from the shortcut menu.
    • Switch to Access Control, select Allowall applications to access this item, and click Save Changes. You will need to enter an administrator password to continue.

Microsoft Edge Notes

You must have the correct MicrosoftWebDriver executable for your version of Edge. If you receive an "Unable to launch Microsoft Edge" error message, you may need to download the driver. Visit https://developer.microsoft.com/en-us/microsoft-edge/tools/webdriver for additional information.

Enabling Support for the Chromium-based Microsoft Edge Browser

The msedgedriver.exe WebDriver necessary for playback on the Chromium-based Edge browser is not shipped with SOAtest and Virtualize. You can download the driver from the following website:

https://developer.microsoft.com/en-us/microsoft-edge/tools/webdriver/

Save the driver to the <INSTALL>\plugins\com.parasoft.ptest.libs.web_<VERSION>\root\browsers\webdriver\edge\x86\ directory to enable support for the Chromium-based Edge browser.

Troubleshooting Playback in Microsoft Edge

SOAtest/Virtualize cannot launch Edge when the SOAtest/Virtualize process is running with privileged access. Take the following actions to resolve this issue:

  1. Use a non-administrator account or an administrator account with User Account Control notifications turned on to run SOAtest/Virtualize as a non-privileged process.
  2. Enable user Account control notifications for administrator users:

    Non-Windows Home edition:

    1. Open the Local Security Policy (secpol.msc) and enable User Account Control Admin Approval Mode for the Built-in Administrator account under Local Policies/Security options.

    Windows Home edition:

    1. Use regedit.exe to navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
    2. If it does not exist, create the DWORD value "FilterAdministratorToken"
    3. Set the value of "FilterAdministratorToken" to 1
     
  3. If launching SOAtest/Virtualize from a Scheduled Task during startup, ensure that the Run only when user is logged on option is enabled.


Need assistance? Visit our support page