0

The website we're testing uses Windows Authentication. We have a script using Start-Process to launch Internet Explorer with alternate user credentials. Looks something like:

$username = 'test\AdminUser1'
$selected_password = 'P@$$word'
$selected_runCommand = 'http:\\QA_env1.com\MainPortal.asp'
$cred = New-Object System.Management.Automation.PSCredential -ArgumentList @($username,(ConvertTo-SecureString -String $selected_password -AsPlainText -Force))
$path = $env:programfiles
Start-Process -FilePath "$path\Internet Explorer\iexplore.exe" -LoadUserProfile -Credential $cred -ArgumentList $selected_runCommand

Over the course of executing a test plan we might end up with half a dozen open sessions, with no easy way to tell them apart since they all have the same title. What I'd like to do is append the user ID (and maybe other info) to the title. I've been searching diligently and have found PS examples using Start-Process -PassThru to get and change the window title, which doesn't work (not sure if it's because it simply doesn't work with with IE, or if it does work but that the app code is then overwriting it). Also using the Win32 API to get window handles and change titles, which, again, doesn't work with IE.

Obviously the WebClient has means of changing a tab title, but we've had serious problems getting this approach (with PS, or with Selenium) working against the authentication requirements here. Sure, we can pop-up a Windows authentication dialog when launching the site but the whole point of having a script with a UI is to save users the need to remember over a dozen test IDs and passwords.

rabbit_rebozo
  • 25
  • 1
  • 2

1 Answers1

0

Would it be possible to use Start-Job and Wait-Job to wait for output versus spawning multiple IE processes and then trying to determine which is which? This may work if the execution is only checking for a certain response.

Wisman
  • 71
  • 3
  • Hey Wisman; For automated scenarios we often work that way... launch as one user, perform some action, close and launch as second user, evaluate impact on second user of actions of first user. For live/manual testing we prefer to work asynchronously... have both users available at the same time, so we can switch back and forth. Greatly speeds things up. – rabbit_rebozo Jul 24 '15 at 17:25