See also Synthetic Scripts FAQ (Part I).
Controller |
Web/Mobile RUM |
Synthetic |
SaaS |
SaaS |
SaaS |
On-Premises (4.5.4+) |
On-Premises (4.5.4+) |
On-Premises (4.5.4+) |
Not at this time.
The short answer is that scripts and their results always go over encrypted channels. The scripts and results are stored in clear text in various databases, so a database breach could compromise the information, but, of course, we try very hard to prevent database breaches.
For the long answer, see the summary of the data path of a script and its results below. (Foo) denotes data at rest.
Each of the -> links uses HTTPS, with two possible exceptions which are determined by the user:
If you can write Python code to do something using the standard libraries, you can do that in your script. For example, you can use Python's requests library to make REST calls to fetch a password.
You can wait for the iFrame element to be clickable as shown in the snippet below.
|
Two weeks.
No, this cannot currently be extended on SaaS.
As of April 2016, API testing is in the long-term vision for Synthetic, but the feature is not on any roadmaps yet. If the customer's use case involves monitoring the API from inside their network, then Service Availability is the preferred solution. Monitoring from outside their network is not an option at this time.
Virtual pages are not yet supported in Synthetic (possible future feature), so virtual page naming is not supported.
Yes, JavaScript popups created with window.alert or window.prompt are fully supported.
Multiple windows or tabs with loaded HTML documents are only partially supported. You can create scripts to handle multiple windows, but the session results will combine the waterfall metrics and the resources from all of the windows into one page. Thus, you will not be able to view the individual results for each browser window.
We recommend doing your initial debugging locally: that’s always the easiest place to debug. We capture the stdout and stderr streams from your script, so you can debug that way. And we show partial sessions for scripts that failed part-way through, so you can see what the browser did up until the script failed.
Timeouts in scripts can be prevented by explicitly waiting for specific element states (e.g., clickable). See also the paragraph Expected Conditions discussed in Explicit Waits.
If your script has an assertion failure, the session status is “Failed”, which indicates a problem with your site. If your script crashes, the session status is “Broken”, which indicates a problem with your script. If we can’t run your script, the session status is “Internal Error”. We hope you’ll never see that. For single-URL measurements, a 5xx is “Failed,” and a 4xx is “Broken”.
There are currently two known issues regarding visual metrics: