Browser test practical guide

This page describes practical uses specific to browser testing. Please click here for a common guide for mobile app and browser testing.

Table of Contents

1. Switching to the test execution environment
2. Acquiring temporarily displayed element captures
3. Testing screens where you need to scroll
   • Acquiring captures
   • Creating test cases
4. File download tests
5. File upload tests
6. Testing separate tabs and separate windows
7. Testing using the MagicPod Cloud and running command line batches
8. Testing using external Cloud services and running command line batch tests
9. Running command line batch tests using the local PC
   • Windows
   • Linux
   • Mac
   • Parallel execution
10. In case the tests do not work with older versions of the browser
11. Mobile website support
12. Using client certificates

 

1. Switching test execution environments

If you need to switch between multiple environments (e.g., such as between a test environment within the team and a production-like staging environment) to run the test cases you have created, you can use the concept of a base URL. Here, base URL is used to mean "a URL that serves as the basis for the other URLs used during testing". Let us take a look at an example.

If a base URL is not used, you should enter the full URL when transitioning to the web page for the test.

When using a base URL, enter the common part of the URL in the "Base URL" field on the "Details" tab of the pop-up window when specifying the browser. Then, enter a character string describing the noncommon parts in the test case.

Doing it this way means that the environment can be easily switched simply by rewriting the base URL in the popup window before the test is run. If the URL within the test case starts with “http” or “https”, the base URL will be ignored. If you only intend to use a particular URL during the test, you can enter just that URL from the beginning.

 

2. Acquiring temporarily displayed element captures

Normally, the "Capture UI in Desktop App" button is used to obtain a screen capture, but this is not possible for elements that are only visible when the mouse is moved over them. To capture such elements, click the small downward-pointing triangle button to the right of the capture button. This activates the option "Capture after 5 seconds". If you click the capture button in this state, there is a 5-second grace period before the actual capture is taken, and the necessary elements can be displayed during this time.

State in which the “Capture after 5 seconds” option is enabled (option is checked)

This option shall remain valid until the test case Edit page is reloaded or you click the “Capture after 5 seconds” option again to remove the check.

 

3. Testing screens where you need to scroll

Here, we explain how to acquire the capture or create test cases when the initial display screen for the browser does not fit on the screen.

Basically, when testing Web browsers, even UI elements that are outside the screen can be automatically scrolled and manipulated, so there is not really any need to be conscious of this when creating test cases. However, some adjustment may be required, depending on the UI elements used and the screen layout.

・Acquiring captures

In order to capture a long vertical screen in one go, click on the small downward pointing triangle button located to the right of the Capture button to activate the "Capture whole page" option. If you click the Capture button in this state, it is possible to scroll through and capture the whole screen.

“Capture whole page” option

Currently, the following restrictions apply.

• Horizontal scrolling of the screen is not supported.
• Screens including fixed headers and footers may be inserted multiple times within the capture.
• In the case of types of screens in which elements are dynamically added when you scroll, it is not possible to capture all of the elements.
• In other cases, depending on the screen layout, it may not be possible to capture the entire screen. (for example, cases where only a part of the page scrolls instead of the whole page, or the layout of elements changes when scrolling, etc.)

In case it is not possible to acquire the target UI elements when capturing the whole screen, remove the check from “Capture whole page”, and acquire the capture after scrolling manually until the target elements can be viewed.

・Creating test cases

As described above, after acquiring the capture once, it is not necessary to pay much attention to scrolling. For example, even if you click elements that are off-screen, selecting the "click" command for that element means that the click will be performed after it has automatically scrolled.

However, there are situations in which automatic scrolling will not work.

1. In cases where the UI element locator is the AI locator (as in ai=XX)
2. In cases where the UI element exists within the scope of the screen, but fixed headers and/or footers are hidden
3. In cases where the target element will not be visible unless only a part of the screen, rather than the whole screen, is scrolled

If any of these cases apply, use either “Scroll whole page before it is displayed” or “Scroll UI elements until displayed” before clicking or inputting text, to put the elements you wish to operate in an operational state.

The following are examples of the actual commands used. If “3. In case the target element will not be visible unless only a part of the screen, rather than the whole screen, is scrolled” described above occurs, select “Scroll UI elements until displayed.” In this example, the element to be displayed for the next operation is "Home (menu)" and the "area(1)" element (sidebar, gadget, etc.) is to be scrolled for that purpose.

“Scroll until displayed” command

As it is difficult to judge whether automatic scrolling is required before running the test, we would recommend creating a test case without scrolling commands and making small adjustments while running the test.

 

4. File download test

Behavior in case a file download occurs while operating the test differs according to the browser.

• In case of Chrome, Firefox, or Edge
  • The download confirmation dialog box will not be displayed, and the file will be downloaded to the designated location (by default, it will be downloaded to the magicPod/downloads folder on the Desktop).
• In the case of IE11
  • As, with IE11, it is not possible to automatically hide the confirmation dialog box, use the keyboard operation to save the file to the same folder as in the case of Chrome, Firefox, or Edge. For this reason, the operation may be slower than with other browsers.
  • Also, as it will tend to operate with less stability than other browsers, unless you have a particular need to perform a download test using IE, we would recommend testing using other browsers.

How to specify the download operation

When performing a test using only Chrome or Firefox, there is no need to do anything special for the download operation. For example, if you specify “clicking” a particular button, downloads shall take place automatically.

On the other hand, IE does not allow for the above keyboard operation to be performed by simply clicking on the download button, so a special "Click to download file" command is employed. As it is not clear which button will cause the download process to occur on the MagicPod side, it is necessary to set this up when creating the test case. In Chrome or Firefox, if the “Click to download file” command is specified, this has the same operation as “Click”, so it is possible to use IE and these browsers for common test cases.

Checking download results

To check whether a file has been downloaded without issues, check whether the file with that specific name is present in the download folder. Confirm by running the “Check it has been downloaded” command. You can use regular expressions for the filename.

It is not currently possible to open the downloaded file and check the contents with MagicPod.

Waiting for time-consuming downloads

In case the file download seems as though it may take some time (10 seconds or more), enter the “Wait until download is complete” command before the confirmation command. Regular expressions can be used for the filename here, too. If it finishes within 10 seconds, it will wait with the confirmation command alone, so you do not need to enter the wait command.

Download test

If there is no need to check the downloaded file(s), the two commands below will not be necessary.

 

5. File upload test

Preparation

If you use the “Click and upload file” command, you can use files registered on MagicPod in advance for the file upload test. If you select the command and click the “Select file” button, the file selection/registration dialog box shall be displayed, so where necessary, register the file from the “Add new file” button.

When using the standard browser file upload button

When using the standard browser (although it depends on the browser, the file upload button has the following kind of design. The type attribute is a file input element), the button and the file path name area to its right are combined into one element.

You can upload the file by selecting this element as the UI element in the “Click to upload file” command, and selecting the file you wish to upload.

In case the file upload element has an original design

On many sites, specially designed file selection buttons are implemented instead of the standard browser buttons described above. For example, even with MagicPod, an original file selection button is used for the file selection and registration described above.

As it is not possible to operate the button in this case, run a command in relation to the input elements with the type attribute compatible with the file upload area.

Basically, if you specify button elements in the same way as in “When using the standard browser file upload button” (“Select” button in the above figure), MagicPod automatically searches for the necessary input elements. However, it may be difficult to determine this automatically depending on the HTML structure of the website. If the following kind of message is displayed, specify the locator manually after checking the candidates displayed in the message.

key=xpath, value=//input[@name='foo'] is a candidate but is very different from the originally selected element

key=id, value=foo and key=id, value=bar are candidates, but it was not possible to select one as both were closest to the originally selected element

Add the file selection button locator, in accordance with the Defining an Original Locator guide. With the input content, the upper level (key) is the error message key, and the lower level (value) is the error message value. In case a second message is displayed, and it is not clear what the correct element is, or the candidates are not displayed, search for the correct element by confirming with the development team, etc.

 

6. Testing separate tabs and separate windows

If the page being tested opens in a new tab or window while the test is being run, you can operate it using the following procedure. See here for how to use the various commands.

• In case a new tab or window is opened by clicking a link, or the like, run the “Select new window” command after clicking. This causes the tab or window operation to switch over, and you can operate the new tab and window elements.
• Run the “Select previous window” command to return the target to the previous window calling the “Select new window” command.
• Select “Close window” to close the current tab or window with the “x” button. To operate other windows after closing, it is necessary to call the “Select previous window” command, and switch the target of operation once again.

 

7. Running tests using the MagicPod Cloud and command line batch tests

It is possible to run simple batch tests using the Cloud environment provided by MagicPod.

• Only “HTML” can be specified for “Screen capture range”.

Refer to this procedure when performing batch executions from the command line.

 

8. Testing using external Cloud services and running command line batch tests

You can run batch tests on BrowserStack or SauceLabs. Refer to the following pages for how to set this up. It describes how to batch run from the command line.

• Running batch tests (browser tests) in the BrowserStack Cloud environment
• Running batch tests in a SauceLabs Cloud environment (browser test)

Currently, there are the following restrictions on execution. Please inquire if you desire improvement.

• You can only specify “HTML” for “Screen capture range”. “Window” cannot be specified.
• The “Click to download” and “Check what has been downloaded” commands are not supported.

 

9. Running Command Line Batch Tests Using the Local PC

Windows

Test batch execution within the project can also be performed from the Windows PowerShell.

Writing a setup file

First, you need to write the setup file required for command line execution of the test.

Once you launch the MagicPodDesktop once, there should be a file called “magic_pod_config.json” in the “C:\Users\<Username>\AppData\Roaming\magic_pod_desktop” folder (this is the setup file used by MagicPodDesktop), so copy this somewhere on the desktop.

After you copy this, following the format below, write the setup file in JSON format.

{
  "owner": <Organization name. This is not the display name, but the alphabet description in the URL>,
  "project": <Project name. This is not the display name, but the alphabet description in the URL>,
  "capabilities": <setup of the target browser, etc. This is the same as Desired Capabilities in Selenium>,
  "sendMail": <whether to distribute a test results e-mail. If omitted, this is false>,
  "baseUrl": <base URL>,
  "captureType": <test results screen capture setup. Any one of on_error, on_ui_transit, or on_each_step If omitted, this is on_each_step>,
  "stepCaptureScope": <Whether to include only the HTML content in each line of screen captures or the entire browser window. Either html or window If omitted, this is html>
  "xmlTestOutput": <output the test results XML in JUnit format. Mainly in coordination with Jenkins. If omitted, this is false>,
  "workDir": <full path to the work directory. If omitted, this is “magicPod” on the Desktop>,
  "authTokenFilePath": <full path to authentication token file. If omitted, this is C:\Users\ [Username] \.magic_pod_token>
  "envVars": <list of environmental variable strings in KEY=VALUE format. If omitted, this is a blank list>,
  "testNumber": <describes the test number to be run delimited by commas. If this is blank or omitted, all tests are run>,
  "includedTestCaseLabels": <specifies the label for the test in character string list format>,    
  "excludedTestCaseLabels": <specifies the label for the test in character string list format>,
  "logLevel": <sets the volume of log to output. Any one of beginner, expert, or magic_pod_bug_investigation. If omitted, this is beginner>,
  "retryCount": <how many times to retry failed tests. If omitted, this is 0 (in other words, do not retry)>,
  "language": <display language for the test execution log. ja or en. If omitted, this is en>,
  "visualDiffPattern": <Image difference pattern name. It is possible to specify skip. If omitted, this is treated as unspecified>,
  "testCondition": <conditions when running tests (*see example below)>
}

Refer here when specifying shared variables.

Refer here when using variables for values in the setup file.

Based on the above, the setup description may be, for example, as follows.

{
  "owner": "MyCompany",
  "project": "SampleWebApp",
  "capabilities": {
    "browserName": "chrome"
  },
  "sendMail": true,
  "testCondition": {
    "browser": "chrome"
  }
}

• The current specification is such that similar content must be written for capabilities and testCondition, but we plan to improve this in the future. The test may be run even if there is no testCondition, but browser information may be missing when viewing the test results on the Web.

Running tests

Once the setup file is complete, run the test according to the following procedure.

1. Close MagicPodDesktop if it has been launched.
2. Open Windows PowerShell. There are several ways of doing this, but the simplest way is to open “Windows PowerShell” from the Start Menu.
3. Run the following command. For the “MagicPodDesktop version” section, enter (0.36.0, etc.) according to the folder in which it actually exists. This can be completed on PowerShell. Note that an error will occur if there is no “&” at the start (when entering from 1 on PowerShell, this is inserted automatically)
   • & "C:\Users\<Username>\AppData\Local\magic_pod_desktop\app-<MagicPodDesktop version>\MagicPodDesktop.exe" run --magic_pod_config="<magic_pod_config.json full path>"; Wait-Process -Name MagicPodDesktop -Timeout 3600
   • The “3600” in the command is the maximum number of seconds to wait for the test to complete, and means to wait up to 3600 seconds. This wait time may be changed based on the length of the test.
4. Run the test in accordance with the magic_pod_config.json setup.

If you copy magic_pod_config.json, it is possible to run the command line in the same way on other Windows PCs.

However, as only the authentication information is not saved in magic_pod_config.json, it is necessary to start MagicPodDesktop once, enter the e-mail address and password, and save the authentication information on the PC.

 

Linux

It is possible to run a test batch on Linux, using a procedure similar to the Windows one.

Installing the required libraries

First, install xvfb (required libraries for browser rendering) and imagemagick (required libraries to acquire screen shots for the entire browser window). For Ubuntu, you can install these using the following commands.

sudo apt-get update
sudo apt-get install -y unzip xvfb libxi6 libgconf-2-4 imagemagick

In certain CI services, such as CircleCI, xvfb and imagemagick are installed from the start, so this procedure is not necessary.

Next, if we are using Chrome to run the test, we must first install Chrome. For Ubuntu, you can install these using the following commands.

wget -q -O - https://dl-ssl.google.com/linux/linux_signing_key.pub | sudo apt-key add -
sudo sh -c 'echo "deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main" >> /etc/apt/sources.list.d/google.list'
sudo apt-get update
sudo apt-get install google-chrome-stable

Next, we need to install Japanese language fonts so that there will be no garbled characters in Japanese language screen captures. In the case of Ubuntu, you can install these using the following commands.

Add the public image Japanese language fonts for CircleCI, and try running the E2E test (https://qiita.com/takayamag/items/b632524e7994210fd1e8)

sudo apt -qqy --no-install-recommends install -y locales-all
sudo locale-gen ja_JP.UTF-8
sudo update-locale LANG=ja_JP.UTF-8
sudo update-locale LANGUAGE="ja_JP:ja"
sudo apt -qqy --no-install-recommends install -y fonts-takao-gothic fonts-takao-mincho
sudo dpkg-reconfigure --frontend noninteractive locales
sudo fc-cache -fv

 

 

Download the magicpod-command-line

Acquire the zip file of magicpod-command-line for Linux from the Download page, unzip it, and place the obtained magicpod-command-line and node_modules directories in an appropriate place (store both of these in the same place).

Writing a setup file

Create “magic_pod_config.json” using the same format as In the case of Windows (as there is no original file that can be copied, create this in the Editor).

Setting authentication information

If you are using a PC on which you have successfully logged into MagicPodDesktop, below the Mac folder “/Users/<Username>” or for Windows, in the “C:\Users\<Username>”folder, there should be a file called “.magic_pod_token”. This file is the authentication information file for the login user, so copy this below “~/” on a Linux machine.

Alternatively, you can set the authentication information by running the following command and acquiring the token information called {"token":"****"}, and saving the contents of the **** part in “~/.magic_pod_token”.

#Specify the e-mail address used for MagicPod in xxxx and the password in yyyy.
curl -X POST -L --data-urlencode "email=xxxx" --data-urlencode "password=yyyy" https://magic-pod.com/api/v0.1/token-auth/

 

The path for “~/.magic_pod_token” can be changed using authTokenFilePath in magic_pod_config.json.

Launching Xvfb

You need to launch xvfb before running the Launch test, and close it when it is finished. As this process is carried out automatically by some Cloud CI services, such as CircleCI, this is not required. If you are using Jenkins, the Xvfb plug-in will automatically launch Xvfb when running a job. In other cases, by changing the command when running the test, it is possible to launch Xvfb and the test together (to be described later).

Running tests

Once you are ready, you can run the test using the following command. This is the command when Xvfb is already running on CircleCI, Jenkins, etc.

magicpod-command-line --magic_pod_config="<magic_pod-config.json full path>"

The command to run when launching Xvfb and the test at the same time is as follows.

xvfb-run magicpod-command-line --magic_pod_config="<magic_pod-config.json full path>"

In any case, it is necessary either to use the full path to the magicpod-command-line on execution, or specify a relative path to the magicpod-command-line.

Saving the test results as a video

It is only possible to save a video of the test in progress when running local tests in a Linux environment.

Before running the test, install a tool called ffmpeg, which is required for saving the video.

sudo apt install ffmpeg

Next, add the option to save videos to the test setup file. Note that this option cannot be added as a screen operation, so it is necessary to edit the setup file manually. If you specify record_type as the key and always as the value, it will be saved as a video every time you run a test. If you specify “only_failed” as the value, it will only save if the test fails, and if you specify “never”, the setting is for it not to be saved.

{
  "owner": "MyCompany",
  "project": "SampleWebApp",
  "capabilities": {
    "browserName": "chrome"
  },
  "sendMail": true,
  "testCondition": {
    "browser": "chrome",
    "record_type": "always"
  }
}

Specify several environment variables as necessary when running the test.

# Mandatory in principle
export MAGIC_POD_RECORDING_SCREEN_SIZE=1280x1024
# Option
export MAGIC_POD_RECORDING_DISPLAY=:99.0
export MAGIC_POD_RECORDING_FRAME_RATE=8

xvfb-run magicpod-command-line --magic_pod_config=""

Variable name	Meaning	Default value
MAGIC_POD_RECORDING_SCREEN_SIZE	Specifies the area size of the display rendered by Xvfb, to be saved as a video. (method of looking this up is described later)	None (although, even if this is not specified, the video will be saved to an appropriate range, although this may only be the case on some browsers)
MAGIC_POD_RECORDING_DISPLAY	This is the number of the display depicted by Xvfb. (method of looking this up is described later)	:99.0
MAGIC_POD_RECORDING_FRAME_RATE	Specifies the video frame rate (number of frames per second). The larger the value, the more detailed the movement that can be saved. However, as this will greatly increase the file size, uploads may take more time, and if the file size limit (50 MB) is exceeded, it may not be possible to complete the upload.	8

To find out what to specify for the above two environment variables, check the display numbers, etc., used, with Xvfb running.

# Example when launching Xvfb and Chrome manually. Launch these using method used for ordinary tests
xvfb-run google-chrome --no-sandbox &


# Check the running Xfvb processes and parameters
ps -ef | grep Xvfb


(Output example)
root       213   202  0 02:17 pts/1    00:00:00 Xvfb :99 -screen 0 640 x 480 x 16 -nolisten tcp -auth /tmp/xvfb-run.uyTR8o/Xauthority
root       810    13  0 02:18 pts/1    00:00:00 grep --color=auto Xvfb

640 x 480 x 16 is where the screen resolution is specified. In this case, the MAGIC_POD_RECORDING_SCREEN_SIZE is “640 x 480”. The display number is “:99.0”, in accordance with the first parameter and screen option. As the default value is “:99.0”, it will work even if not specified, but you can specify this as an environment variable if the value is different. Be sure to close related processes (Xvfb, xvfb-run, google-chrome, etc.) after checking the variable value.

 

Mac

If you use the Mac version of MagicPodDesktop, it is possible to run from the command line using the same flow as in Windows. The differences from Windows are as follows.

• “json”, by default, is in the “/Users/<Username>/Library/Application Support/magic_pod_desktop/magic_pod_config.json” folder.
• This is run from the Mac “console”.
• The command to call this is shown below.

# Update MagicPodDesktop to the latest version if available

"/Applications/MagicPodDesktop.app/Contents/MacOS/MagicPodDesktop" update --magic_pod_config="<magic_pod_config.json full path>"

# Test batch execution

"/Applications/MagicPodDesktop.app/Contents/MacOS/MagicPodDesktop" run --magic_pod_config="<magic_pod_config.json full path>"

 

Parallel execution

No special settings are required if you are preparing multiple machines, and performing the batch execution of local PC tests in parallel.

To perform batch execution of multiple local PC tests on the same machine, prepare separate magic_pod_config.json files in the same way as in the case of the mobile app test, and allocate workDir, internalAppiumPort, and internalMagicPodPort to each in a manner such that they do not overlap.

 

10. In case the tests do not work with older versions of the browser

If you have an older version of Chrome or Edge (Chromium), in rare cases, there may be version errors that cause the browser to not launch properly. This error is due to a version discrepancy in the “ChromeDriver” or “Microsoft Edge driver” libraries required for the test. This problem can be resolved using the following procedure.

1. From the ChromeDriver download page or Microsoft Edge driver download page, download the ChromeDriver or Microsoft Edge driver for the browser version you are using (note that this does not include the legacy version of Microsoft Edge), and unzip it to an appropriate location.
2. Open the MagicPod setup file (in case of Windows, “C:\Users\<Username>\AppData\Roaming\magic_pod_desktop\magic_pod_config.json”, in case of Mac, “/Users/<Username>/Library/Application Support/magic_pod_desktop/magic_pod_config.json”) and write it as follows. This should resolve the version error. (In the case of Windows, note that it is necessary to record “\” and “￥” as “\\” and “￥￥” in the path. )

{
  ...
  "driverExecutablePath": {
    "chromedriver": "ChromeDriver execution file full path"
  },
  ...
}

Setup in case of Chrome

 

{
  ...
  "driverExecutablePath": {
    "chromiumedgedriver": "Microsoft Edge driver execution file full path"
  },
  ...
}

Setup in case of Edge (Chromium)

 

11. Mobile Website test

Broadly speaking, there are two ways of testing mobile websites using MagicPod. The first is to use Chrome's mobile emulation function to simulate test creation and execution. The other method is to run a test created using the mobile emulation function on a real device on an external Cloud. First, we shall explain the common test creation method (this does not currently support testing on a real device).

By setting the mobile device (smartphone, tablet) screen size and user agent using the mobile emulation on Chrome, it is possible to check behavior close to that of the mobile website. The advantage of this is that there is no need to launch a real device or a simulator/emulator, so the test can be performed both simply and quickly.

However, as it is not actually operating on the mobile device OS, the following types of detailed operations cannot be reproduced.

• Detailed differences in operation due to browser differences
  • For example, if you are emulating the iPhone, the user agent will be Safari; however, since it will be operating on Chrome, it will not be able to find bugs specific to Safari.
• Differences in operation caused by the OS/hardware

In order to use the mobile emulation function, select “Mobile emulation (Chrome)” from “Device type” on the panel for selecting the browser, etc., and then choose the OS type and model. These models are taken from those currently provided in Chrome's developer tools, but you should contact MagicPod support if there is anything else you need to check.

State in which mobile emulation (Chrome) is selected

If you connect to the browser in this state, Chrome will open with the mobile-oriented display shown in the following figure. Other aspects can be operated in the same way as a normal desktop browser.

Chrome opened in mobile emulation mode

If the HTML on the site is the same, test cases created on websites for desktops can be run in mobile emulation mode and vice versa. Regardless of which mode the test cases were created in, the test will be carried out in the mode selected at the time of execution.

Refer to “Batch execution in a BrowserStack Cloud environment” or “Batch execution in a SauceLabs Cloud environment” for how to run the created test on a real device (a separate service contract shall be required in either case).

 

12. Using Cloud certificates

In case a client certificate is required to connect to the site to be tested during a MagicPod browser test, the client certificate can be automatically selected according to preconfigured settings.

Support target

Execution environment

Currently, this only supports Chrome in the Cloud environment.

• There are plans to support Chrome for local PCs (Macs) at a later date.
• There are no plans to support external Cloud services (SauceLabs, BrowserStack).
• Although there are no current plans to support other local PC environments (Windows PC Chrome or other browsers), consult with support if necessary. We shall consider whether to provide support.

Types of certificate files

This only supports PKCS #12 type (with .pfx or .p12 extension).

Reference: Certificate file types

Setup method (Cloud)

Open the batch execution settings on the Project test batch execution screen. From the environment item, select “Cloud”, and open the Details tab to display the client certificate settings column.

For Cloud environments, the certificate(s) used for the test must be uploaded to the MagicPod Server.

If you click the “Manage certificates” button, the dialog box for registration will be displayed, so register the file from the “Add new file” button.

After selecting the file, enter the password for the certificate file. This password is required to install the certificate on the machine for running the test on the Cloud.

After completing registration, click the “Close” button to return to the batch execution setup screen.

After closing the dialog box, select the certificate you have just registered in the pull-down menu for selecting certificates. Alternatively, enter part of the URL for the site where you wish to use this certificate in the column where “Enter the URL pattern” is written.

As the URL pattern will be a partial match, you can specify as in the figure above when you are accessing a URL such as “https://test.example.com/login”.

This completes the settings. If you run the test in this state, the client certificate will be automatically selected during execution.

Setup method (Local PC)

If you are using a client certificate for a local PC test, install the certificate on the PC in advance.

Open the batch execution settings on the Project test batch execution screen. If you select the “local PC” for the environment item, and open the Details tab, the client certificate settings column will be displayed.

Unlike in the Cloud, there is no need to store the certificate on the Server, but you will need to enter the certificate “Issuer name” instead. If you do not know the issuer name, you can look it up using the following procedure. (From the second use onward, if you already know the issuer name, you can skip the following steps.)

If you click the “Issuer” button, the following dialog box will be displayed, so upload the certificate file according to the instructions and enter your password. The password you enter here is the same password as when you installed the certificate on the local PC. This is necessary for analyzing the certificate and acquiring the issuer name. The certificate itself is uploaded to the Server once and analyzed, but as it is not required after that point, it will not be stored on the Server.

Once the analysis completes, the following message will be displayed.

The analyzed issuer name is stored on the clipboard, so enter this by pasting it into the “Enter the issuer name” column. Alternatively, enter part of the URL for the site where you wish to use this certificate in the column where “Enter the URL pattern” is written.

As the URL pattern will be a partial match, you can specify as in the figure above when you are accessing a URL such as “https://test.example.com/login”.

This completes the settings. If you run the test in this state, the client certificate will be automatically selected during execution.