- 20.3.1. Customize Perspective dialog
- 20.3.2. Find/Replace dialog
- 20.3.3. Import Squish Resource dialog
- 20.3.4. Manage AUTs dialog
- 20.3.5. New dialog
- 20.3.6. New Squish Test Case wizard
- 20.3.7. New Squish Test Data dialog
- 20.3.8. New Squish Test Script dialog
- 20.3.9. New Squish Test Suite wizard
- 20.3.10. Open Perspective dialog
- 20.3.11. Preferences dialog
- 20.3.12. Screenshot Verification Point dialog
- 20.3.13. Search dialog
- 20.3.14. Show View dialog
- 20.3.15. Squish Server Settings dialog
- 20.3.16. Switch to Editor dialog
This dialog is used to customize a predefined or custom perspective—for example, customizing some of the toolbars, menus, and submenus that are visible when the perspective is shown. The dialog is invoked by clicking |. (To change the views shown in a perspective simply close any you don't want and add new ones using the Show View action (Section 20.1.1.62).)
Use the Tool Bar Visibility tab to hide or show toolbars and individual toolbar buttons within toolbars. Similarly, use the Menu Visibility tab to hide or show menus and individual menu options within menus. The Command Groups Availability tab is for advanced users and is not documented in this manual. The Shortcuts tab can be used to add keyboard shortcut actions to submenus.
This modeless dialog is used to find and optionally replace text in the active editable window. The dialog is invoked by clicking | or by pressing Ctrl+F.
Be aware that even if you set Scope to be All the search will only be made from the current cursor position Forward (or Backward depending on the Direction setting) to the end (or start) of the file—unless you check the checkbox. Searching is case insensitive by default but this can be changed by checking the checkbox. If the checkbox is checked the Find text can be a regex using Eclipse's regular expression syntax.
This dialog can be popped up by invoking the Import Test Resource action (Section 20.1.1.19). It is used to import scripts, test data, and verification points into a test case or a test suite.
The File to Import should be chosen by clicking the
button and navigating to it using the Open
File dialog that pops up. The file should either be a test data file in
.tsv (tab-separated values format),
.csv (comma-separated values format), or
.xls (Microsoft® Excel™ spreadsheet
format—but not .xlsx
format), or a test script file (e.g., a file containing functions you
want all the test suite's test cases to be able to share using the source function). If you import a test script it
must use the same scripting language as that used by the test suite's
test cases.
Once the file has been chosen you must tell the Squish IDE whether it is test data or a test script by setting the combobox's value appropriately.
With any resource you have two choices as to its location: it can either be stored within a particular test case or it can be stored in a place that is accessible to all the test suite's test scripts. Unless the test data or test script resource really is specific to one particular test case it is almost always more convenient to store it so that it can be shared by the entire test suite. If you just want to store the data or script in the current test case check the radio button. And if you want the data or script to be shared by all the test cases check the radio button. Then, in either case, click the button.
See also the New Squish Test Data dialog (Section 20.3.7) and the New Squish Test Script dialog (Section 20.3.8).
This dialog is used to manage the Mapped AUTs, AUT Paths, and Attachable AUTs that are registered with the squishserver. (See AUT Paths and Mapped AUTs (Section 19.3.2).) This dialog can be invoked by clicking ||.
Any child item shown in this dialog can be removed by clicking the button. To add a new Mapped AUT, AUT Path, or Attachable AUT, first click the appropriate parent item (e.g., “Mapped AUTs” if you want to add a Mapped AUT), and then click the button. Once you have finished with the dialog click the button.
It is also possible to register and unregister AUTs using Squish's command line tools; see AUT Paths and Mapped AUTs (Section 19.3.2).
(From Squish 4.2 this dialog is replaced by the Manage AUTs pane in the Squish Server Settings dialog (Section 20.3.15).)
This dialog is used to import a new shared Squish test script or test data file, or to create a new test case within the current test suite, or to create a new test suite. The dialog can be invoked by clicking the main window's toolbar button or by pressing Ctrl+N. (Note that there are more convenient direct menu options for all of these—apart from creating a new test case from a template.)
Once the wizard is visible click the type of the thing you want to create, then click the button.
If you click “Squish Script File” the New Squish Test Script dialog (Section 20.3.8) will replace the "New" dialog. This dialog is used to add a shared test script file (e.g., a script that contains functions you want to share amongst your test cases).
If you click “Squish Test Case” the New Squish Test Case wizard (Section 20.3.6) will replace the "New" dialog. This dialog is used to create a new empty test case.
If you click “Squish Test Case from Template” the Create Test Case from Template dialog will replace the "New" dialog. This dialog is used to create a new test case based on the specified template. (Note that there are no default templates, so you will need to create at least one template to be able to use this option. A Test Case Template can be created using the Test Suites view (Section 20.2.16)'s Test Cases list's context menu.)
If you click “Squish Test Data File” the New Squish Test Data dialog (Section 20.3.7) will replace the "New" dialog. This dialog is used to import shared test data that can be used by the test suite's test cases.
If you click “Squish Test Suite” the New Squish Test Suite wizard (Section 20.3.9) will replace the "New" dialog. This dialog is used to create a new test suite.
This dialog is used to create a new test case within the current test suite. It can be invoked by clicking the Test Suites view (Section 20.2.16)'s toolbar button or by clicking | or ||, or via the New dialog (Section 20.3.5). (See also the New Test Case action (Section 20.1.1.28).)
Once the wizard has appeared, enter the name of the new test case and
click the button to finish. At this point
an empty test case with the given name will be created (prefixed with
tst_ if it isn't already), ready for a new test
script to be entered or recorded.
This dialog is used to add test data for a particular test case or to be shared by an entire test suite. It can be invoked by clicking ||, or via the New dialog (Section 20.3.5).
The Test Data Filename should be entered first. The filename should be
in .tsv (tab-separated values format),
.csv (comma-separated values format), or
.xls (Microsoft® Excel™ spreadsheet
format—but not .xlsx
format). If entering the filename directly isn't convenient because you
want to pick the file using a file chooser dialog, close this dialog and
open the Import Squish Resource dialog (Section 20.3.3) instead.
With any resource you have two choices as to its location: it can either be stored within a particular test case or it can be stored in a place that is accessible to all the test suite's test scripts. Unless the test data really is specific to one particular test case it is almost always more convenient to store it so that it can be shared by the entire test suite. If you just want to copy the data into the current test case check the radio button. And if you want to copy the data so that it can be shared by all the test cases check the radio button. Then, in either case, click the button.
See also the New Squish Test Script dialog (Section 20.3.8).
This dialog is used to add a test script (e.g., containing supporting functions) for a particular test case or to be shared by an entire test suite. It can be invoked by clicking ||, or via the New dialog (Section 20.3.5).
The Test Script Filename should be entered first. The filename should be for the same scripting language as that used for the test suite's test cases. If entering the filename directly isn't convenient because you want to pick the file using a file chooser dialog, close this dialog and open the Import Squish Resource dialog (Section 20.3.3) instead.
With any resource you have two choices as to its location: it can either be stored within a particular test case or it can be stored in a place that is accessible to all the test suite's test scripts. Unless the test script really is specific to one particular test case it is almost always more convenient to store it so that it can be shared by the entire test suite. If you just want to copy the test script into the current test case check the radio button. And if you want to copy the test script so that it can be shared by all the test cases check the radio button. Then, in either case, click the button.
See also the New Squish Test Data dialog (Section 20.3.7).
This dialog is used to creat a new test suite. It is invoked by clicking the Test Suites view (Section 20.2.16)'s toolbar button or by clicking | or ||, or via the New dialog (Section 20.3.5). (See also, the New Test Suite action (Section 20.1.1.29).)
The use of this wizard is described in the tutorials:
Creating a Test Suite (Section 5.2) (Java AWT/Swing).
Creating a Test Suite (Section 6.2) (Java SWT).
Tutorial: Starting to Test Web Applications (Chapter 8) (Web).
Creating a Test Suite (Section 9.2) (Windows).
Creating a Test Suite (Section 10.2) (Mac OS X).
Tutorial: Starting to Test Flex Applications (Chapter 16) (Web).
N/A (XView)
N/A (GDC)
This dialog is used to open a particular perspective. It is invoked by the Open Perspective action (Section 20.1.1.36).
By default the Squish IDE has three perspectives (see Perspectives (Section 20.1.2)) each of which can be opened directly using the appropriate action—Squish Test Management Perspective action (Section 20.1.1.69), Squish Spy Perspective action (Section 20.1.1.67), and Squish Test Debugging Perspective action (Section 20.1.1.68). Note that in practice is not necesary to open any of these perspectives manually since the Squish IDE automatically opens the right one depending on context. So this dialog is only really useful if you have created your own custom perspectives and want to choose one of them. (See the Customize Perspective dialog (Section 20.3.1).)
This dialog is used to set the Squish IDE's global preferences. It is invoked by the Preferences action (Section 20.1.1.38).
The screenshot above shows the dialog's first section's first pane. The dialog has a lot of sections (“Dynamic Languages”, “General”, etc.), and most of thes have several panes. For example, the Dynamic Languages section has its own pane plus “Debug” and “Validators” child panes. Some child panes have their own child panes and so on. Most of the dialog's panes are inherited from Eclipse and most of them are rarely used. Here we will only document the most important panes, and within them the most important options.
In general, all the panes have a button which restore's the panes's settings to their defaults and an button which applies any changes you have made. If you make a mistake and don't want to restore the defaults (because your previous non-default settings are what you want), simply click the dialog's button—but note that this will not revert your changes if you clicked the button. To accept your changes click the button.
The Dynamic Languages pane is used to set various “DLTK” (Dynamic Language ToolKit) settings.
Probably the only interesting setting is the checkbox. If this is checked syntax errors are highlighted as you edit (and also indicated in the line numbers margin).
The Dynamic Languages pane has two child panes, Debug and Validators. These are very rarely needed and are not documented here. (Note that the Dynamic Languages Debug pane is not concerned with debugging test scripts.)
The General pane is used to set some miscellaneous settings. This pane has many child panes (some of which have their own child panes and so on).
Probably the most interesting setting is the Open mode. Squish defaults to Double click mode which means that you have to double-click test cases to get their code to appear in a code editor and so on. Setting the mode to Single click can save a lot of needless mouse clicking.
The General pane has many child panes. Here will will merely mention those that have settings that are likely to be of interest.
The Appearance pane has a Colors and Fonts child pane in which it is possible to customize the colors and fonts used by the Squish IDE and in particular by the Editor view (Section 20.2.6)s. To change the fonts, expand the Colors and Fonts pane's tree view's Basic item; the last two items concern text fonts: click one of these and then click the button to set the font. Usually it is best to set both fonts to be the same. The same tree view can be used to set various colors—simply click the color of interest and then click the button to choose a new color. There are other top-level items in the tree such as Debug, Dynamic Languages, and so on, so you can customize fonts and colors in very fine detail if you wish. The Appearance pane also has a Label Decorations child pane, but this is not currently used by the Squish IDE.
The Content Types pane can be used to set up file type associations. For example, Squish's non-scriptified verification points (such as screenshot verifications) are recorded in an XML-format file. If you wanted to use a custom file extention for such files you could add a file association in this pane. To do this, navigate in the Content types tree to the Text item then inside that tem to the XML item and then inside that item to the Verification Point item. (It is also possible to specify a default encoding but we recommend always using UTF-8 which is the default.)
The Editors pane and its child panes can be used to set up some general
and some language-specific editing preferences. The Editors pane itself
can be used to set the number of recently opened files that are
available from the menu, and to restore (or not)
editor state when the Squish IDE is started up. The File Associations child
pane can be used to associate file types with particular editors. For
example, to make the Squish IDE open .pyw files using
its Python editor, click the File types
button (the top-most Add button) and enter a file type of
*.pyw. Then click the new *.pyw File types
entry if it isn't already selected and click the Associated editors
button and choose the Python Source Editor.
The Editors pane's Text Editors child pane itself has a number of options, plus its own child panes. Use the Text Editors pane to customize general editing features such as the undo history size, the displayed tab width, whether to show line numbers, and so on. It is also possible to customize a limited range of colors here too. The child panes provide means of customizing the cursor (in the Accessibility pane) and the code annotations (in the Annotations pane). There are also some other rarely used child panes.
The Editors pane has one other direct child pane, Keys. This can be used to change the Squish IDE's keyboard shortcuts. Of course, if the shortcuts are changed this will invalidate some or all of those shown in this manual's Keyboard Shortcuts (Section 20.4) section.
The Perspectives pane is used to control some of the high level behavior of perspectives, such as whether a newly opened perspective replaces the current perspective (the default) or appears in a new window.
The Search pane is used to control some general features that apply to the Search view (Section 20.2.13).
The Workspace pane and its child panes control some aspects of the Squish IDE's behavior such as the automatic save interval and the default text encoding. Squish always and only uses the UTF-8 encoding so this setting should never be changed. Of the Workspace pane's child panes, the Build Order pane isn't used by Squish, and the Linked Resources pane's checkbox must be checked—or the Squish IDE simply won't work properly. The Local History pane can be used to control a certain amount of undo history—even between sessions.
The JavaScript pane and its child panes are used to set various JavaScript-specific options.
The main pane is empty and neither the Console nor the Debug panes (or
the Debug pane's child panes) are used by Squish. The other panes are
used however. The Editor pane is used to control how the caret is
positioned during navigation and whether to use spaces or tabs and the
what and how much indentation to use. This pane also has some child
panes. These are used to control such things as folding and syntax
highlighting, code templates, and whether the editor closes strings and
opening brackets of various kinds. The Error/Warnings child pane is used
to control how strict the editor is about JavaScript syntax. The
Formatter child pane is used to control how JavaScript is formatted by
the editor. The Interpreters pane is used to specify which JavaScript
interpreter to use. Squish uses its own built-in JavaScript
interpreter but this option could be used to influence how the
JavaScript editor does its syntax highlighting and error reporting. The
Task Tags child pane is used to manage a list of special words that the
Squish IDE must recognize and highlight inside JavaScript comments—for
example, FIXME or TODO.
The Perl EPIC pane and its child panes are used to set various Perl-specific options.
The Perl executable setting is from Eclipse—it has no effect on
test script execution. The Perl EPIC pane has a number of child panes
including an Editor pane that itself has child panes (which are not
documented here). The Editor pane can be used to set what and how much
to indent, syntax highlighting colors, and whether the editor closes
open quotes and various kinds of brackets. Those who use the Squish IDE
to create Perl modules or who are deeply into Perl programming may wish
to enable the Squish IDE's Module::Starter and Perl::Critic
functionality—but these features are too specialized to be
documented here. The Source Formatter pane is used to control how the
editor formats Perl source code. The Task Tags child pane is used to
manage a list of special words that the Squish IDE must recognize and
highlight inside Perl comments—for example,
FIXME or TODO.
The Python pane and its child panes are used to set various Python-specific options.
The Python pane has no options of its own but it does have various child
panes. The Debug child pane is not used by the Squish IDE. The Editor pane is
used to control how the caret is positioned during navigation and
whether to use spaces or tabs and the what and how much indentation to
use. This pane also has some child panes. These are used to control such
things as folding and syntax highlighting, code templates, and whether
the editor closes strings and opening brackets of various kinds. The
Interpreters pane is not used by the Squish IDE—Squish uses the
Python interpreter it is shipped with. The Task Tags child pane is used to
manage a list of special words that the Squish IDE must recognize and
highlight inside Python comments—for example,
FIXME or TODO.
The Run/Debug pane and its child panes are used to set some general options concerning the running and debugging of test scripts.
The Run/Debug pane itself can be used to set some basic behaviors, for example what to do when a breakpoint is hit, and various color settings. It is best to at least keep the checkboxes checked. The Console child pane is not used by the Squish IDE. The Launching child pane can be used to control the Squish IDE's behavior when running a test, although options relating to “building” are ignored. It is best to have the Save required dirty editors before launching set to Always (the default), or at least to Prompt; setting it to Never introduces a risk that test edits could be lost in the unlikely event that the Squish IDE crashes. The Launch pane's Default Launchers sub-pane is ignored by the Squish IDE. The Launch pane's Launch Configurations pane should not be used. The Run/Debug pane's Perspectives child pane is ignored by the Squish IDE—Squish will always use the Squish Test Debugging Perspective (Section 20.1.2.3) when debugging is required. The String Substitution child pane is rarely needed and not documented here. The View Management child pane is used to control some aspects of how perpectives behave regarding their views.
The Squish pane and its child panes are used to control various Squish-specific settings.
The Squish pane itself shows the Squish tools folder being used by the Squish IDE. This folder can easily be changed by navigating to another folder in the tree. This is useful when you have AUTs that use different GUI toolkits and want to switch between toolkits while using the Squish IDE.
The Squish pane has several child panes: Application Behavior, Browser, Logging, Playback, Recording, Remote Testing, and Test Creation, all of which we will briefly describe here.
The Application Behavior pane is used to set how long Squish should
wait for an AUT to start up before giving up and how long Squish
should wait for any given response from the AUT. (The response time can
also be set using the squishrunner's or squishserver's
setResponseTimeout option (see Configuring squishrunner (Section 19.4.1.7) or Configuring squishserver (Section 19.4.2.3)).
(From Squish 4.2, the Application Behavior pane is in the Squish Server Settings dialog (Section 20.3.15), not the Preferences
dialog.)
The Browser pane is only relevant to those testing web applications since it is used to set the browser to use for web testing. (From Squish 4.2, the Browser pane is in the Squish Server Settings dialog (Section 20.3.15), not the Preferences dialog.)
The Logging pane provides some settings to achieve finer control over logging. (Note that the IDE Internal Logging Level affects only the Squish IDE's internal log. Occassionally froglogic's support staff may ask you to set its level to Verbose when trying to help solve a problem that you have encountered.)
The Playback pane is primarily used to set the snooze factor. This is
only relevant to calls to the snooze
function—and this function has been almost completely replaced by
calls to Squish's wait functions such as the waitForObject function.
(From Squish 4.2, the Playback pane's mouse cursor animation
setting is in the Squish Server Settings dialog (Section 20.3.15)'s
Playback pane, not the Preferences dialog.)
The Recording pane is used to control how Squish records tests. The
default settings are to synchronize based on object existence (i.e.,
using Squish's wait functions such as the waitForObject function), and to compress events
(i.e., to record a mouse move from one position to another as a single
mouse move rather than as lots of smaller moves). These defaults are
highly recommended since they produce the most robust and shortest test
scripts possible. If you choose to use time based synchronization,
Squish will record calls to the snooze
function rather than to the wait functions; but be aware that this is
almost always less reliable than using wait functions. (And if you hit a
real problem using a wait function you can always set the timeout for
the wait function's call manually to a longer duration; or insert a
snooze manually if necessary.) Switching off event compression won't
affect recording and playback reliability, but could lead to recorded
test scripts having many more lines than with event compression on.
The Remote Testing pane is used to control which computer tests should be executed on. The default settings tell the Squish IDE to start a local squishserver whenever necessary (i.e., to record or play back a test), on Squish's default port. If you want to run the squishserver on a remote machine you can enter the remote machine's hostname and the port to use. See Distributed Tests (Section 19.1.2) for more about this topic.
The Test Creation pane is used to specify the Test Case Template directory and the default scripting language to use for new test suites (which can be overridden when a new test suite is created of course). A Test Case Template can be created using the Test Suites view (Section 20.2.16)'s Test Cases list's context menu; see also Testcase Templates (Section 19.13).
The Tcl pane's child panes are used to set various Tcl-specific options.
The main pane is empty and none of the Console, Core, Debug,
Interpreters, Libraries, or Man pages panes (or any of their child
panes) are used by Squish. Many of the other panes are used however.
The Code Templates pane can be used to create Tcl template files
(separately from Squish's own file template mechanism). Some very
basic predefined templates are provided and these can easily be edited
or custom ones added. The Editor pane is used to control how the caret
is positioned during navigation and whether to use spaces or tabs and
the what and how much indentation to use. This pane also has some child
panes. These are used to control such things as folding and syntax
highlighting, code templates, and whether the editor closes strings and
opening brackets of various kinds. The Task Tags child pane is used to
manage a list of special words that the Squish IDE must recognize and
highlight inside Tcl comments—for example,
FIXME or TODO.
This dialog is used to compare expected and actual screenshots and to configure how screenshot comparisons work on a per-screenshot basis. It is invoked by right-clicking a failed screenshot verification in the Test Results view (Section 20.2.15) to pop up the context menu and then choosing the context menu's menu item. (See also, Setting Masks and Modes (Section 20.3.12.1) for another way to invoke the dialog.)
The dialog has some controls that apply generally: these are shown along the bottom and consist of zoom in and zoom out buttons, a restore to original size button, a button to show or hide the mask, a button to show or hide highlighting (i.e., show or hide a red outline around differences), and a button to pop up a color chooser dialog to choose the highlighting line color. Then there is a button to save the settings for the current screenshot, and a button for closing the dialog without saving any changes.
The dialog's first tab (Differences) shows the difference between the expected and actual image. This tab offers four different ways to view the difference with the default being Flicker view where the expected and actual images are shown alternately (and with differences outlined in red). The flicker speed can be set using the control on the right.
The Differences tab's Subtract view shows the differences by removing all the common pixels and just leaving those that differ between the two images. The way the subtraction works can be influenced by changing the HSV (Hue, Saturation, Value) color settings, and by checking or unchecking the checkbox.
The Differences tab's Gray Diff view shows the differences by removing all the common pixels and just leaving those that differ between the two images. The way the differencing works can be influenced by changing the Contrast setting, and by checking or unchecking the checkbox.
The Differences tab's Split View view shows the left half of the expected image and the right half of the actual image with a vertical slider inbetween which can be used to vary the proportions to show more of one and less of the other.
The dialog's second tab (Mask) shows the expected and actual images. It also provides tools (in the form of buttons at the right hand side of the dialog) for adding positive and negative masks, for masking a highlighted region, and for removing masks. (Most of these buttons are only enabled if the global Show/Hide Mask toggle button is pressed down, i.e., is set to show the mask—the highlighted region button is only enabled if the global Show/Hide Highlighting button is pressed down.)
The dialog's third tab (Comparison Mode) is used to set the comparison mode. By default Strict mode is used which does a straight pixel-by-pixel comparison and where any difference is counted as a failure (i.e., as the actual and expected images being different). If Strict mode is too strict there are two other modes that can be used. Pixel mode can be used to set a threshold—this is, in effect, a tolerence of up to a specified percentage of pixels being different. Histogram mode is similar to Pixel mode, only using a different comparison algorithm and with two controls for influencing the algorithm's behavior: Bins (how many pieces to divide the image into), and Threshold (how much difference is tolerated for each piece before a difference is flagged).
It is possible to set the Mask and Comparison Mode for a screenshot verification point before running a test (or between test runs), or when there is no failed screenshot test in the Test Results view (Section 20.2.15) (so no context menu item). This is done by clicking the VPs tab in the Test Suites view (Section 20.2.16)'s Test Case Resources list and then clicking (or double-clicking depending on your settings) the image verification point whose Mask or Comparison Mode you want to modify. This will result in the Verification Point being shown, along with a tiny button. Click this button to invoke the Screenshot Verification Point dialog. The dialog will pop up with only two tabs, Mask and Comparison Mode—the Differences tab does not appear because the only image available is the expected image. The Mask and Comparison Mode tabs can be interacted with as described above, and if you save the settings they will be used next time the test that uses the verification point is run.
This dialog is used to perform sophisticated searches across files. It is invoked by using the Search action (Section 20.1.1.59). (If you just want to do a simple find or find and replace in an Editor view (Section 20.2.6) use the Find and Replace action (Section 20.1.1.16) instead.)
This dialog has several tabs but we will only very briefly describe the File Search tab (which is the one shown by default). The first combobox is used to specify the text to search for. The combobox keeps a record of texts used this session so it is easy to drop down and pick a previous search text. By default the search uses very simple glob-style wildcards, but you can use full regular expressions and control case sensitivity using the appropriate checkboxes if you wish. The File name patterns combobox can be used to restrict the names of the files that are searched in. For example, if your scripting language is Python, you could set the pattern to be “*.py” so that only Python files are searched. The dialog has some other more advanced settings, and can even be used to replace the matching text across files, but these features are not covered here. After performing a search a Search view (Section 20.2.13) appears in the current perspective showing a tree view of the files searched and the line numbers within them where the search text matched.
The other tabs are all scripting-language-specific. They allow you to search for text in all the files containing source code in the tab's scripting language (e.g., all the JavaScript files or all Python files), and where the search text matches the name of a type (class), method (or function), or field (attribute).
This dialog is used to open a view that isn't already open. It can be invoked using the Show View action (Section 20.1.1.62). (See also, the Show View Menu action (Section 20.1.1.63).)
The Squish IDE provides so many views that the dialog shows them in a tree
view grouped by category. Views that are already visible are shown
grayed out. One view that isn't shown by default but which can be useful
when you need technical support is in the Squish Tests group—the
Runner/Server Log view. The Squish IDE remembers which views are showing in
which perspectives between sessions, so you only have to add a view once
for it to always be shown. Correspondingly, you only have to click a
view's close button 
to get rid of it.
This dialog is used to control various aspects of the squishserver that the Squish IDE uses when recording and playing back tests.
This dialog is used to set Squish's timeouts for AUT startup time and response time, to specify the web browser to use with Squish for Web, and whether to animate the mouse cursor on playback. The dialog also contains a Manage AUTs panel that replaces the Manage AUTs dialog (Section 20.3.4) used in Squish 4.0 and 4.1.
The Manage AUTs panel is used to manage the Mapped AUTs, AUT Paths, and Attachable AUTs that are registered with the squishserver. (See AUT Paths and Mapped AUTs (Section 19.3.2).)
Any child item shown in this dialog can be removed by clicking the button. To add a new Mapped AUT, AUT Path, or Attachable AUT, first click the appropriate parent item (e.g., “Mapped AUTs” if you want to add a Mapped AUT), and then click the button. Once you have finished with the dialog click the button.
It is also possible to register and unregister AUTs using Squish's command line tools; see AUT Paths and Mapped AUTs (Section 19.3.2).
(Added with Squish 4.2.)
This dialog is used to make one of the editor views' tabs the active one (i.e., the one shown and with the keyboard focus). It can be invoked using the Switch to Editor action (Section 20.1.1.74).
One convenience of using this dialog is that it shows the path as well
as the filename of the files being edited. This is particularly useful
for Squish 4.0.x since it only shows the
filenames on the Editor view (Section 20.2.6) tabs (e.g.,
test.py, test.py,
test.py). (Note that if you hover the mouse over an
Editor view (Section 20.2.6) tab the full path is shown.)
To switch to an particular tab simply click the name of the file in the list and then click the button. There are also buttons for selecting multiple tabs and for closing and saving.