This topic explains how to extract a value so you can validate it or store it for use in another scenario step or tool.
Sections include:
In the Browser Contents Viewer tool that is automatically added to each scenario step recorded from the browser, you can click on page elements within a rendered view and automatically set up functional tests on those elements. If a validation is not satisfied in a subsequent playback, the associated scenario step will fail.
In addition, you can "extract" and store data from those elements, then use those extracted values in additional tools (for instance to populate form fields or to validate data). This allows you to easily set up scenarios where dynamic data validation is important. Extracted data can be used in both Web tests and service/API tests.
You can also extract path elements from within your Web browser WHILE you are recording a path. To do so, right-click an element from within your browser and select Configure Validations from the shortcut menu. The Validation Options dialog displays. The options within this dialog will be the same as the options in the Browser Contents Viewer tool that appears AFTER a path has been recorded and replayed at least once. |
To validate or store a value represented in the rendered page, complete the following from the Browser Contents Viewer’s tool configuration panel (accessible by double-clicking the tool’s node) or the Post-Action Browser Contents tab (for extraction only):
Click here to log in”:Click”, leave the left boundary blank and enter “ here” (including the space) in the right boundary.here”, enter “Click “ in the left boundary and “to” in the right boundary (again including spaces).in”, enter “log “ (including the space) as the left boundary and leave the right boundary blank.${My Value} in literal or multiple response views.
The value will be validated or stored when the scenario is executed.
If the Browser Contents Viewer tool does not display the value you want to extract or validate—for example, because the related scenario step failed or because the item is not visible in the rendered page (e.g., it is a title), you can manually add a Browser Validation tool or Browser Data Bank tool as described in Adding Test Outputs. |
One way to handle dynamic attribute values in validations is to use partial string XPaths. To use XPaths, ensure that the Browser Validation tool’s Element Locator is set to Use XPath, then specify an appropriate XPath. For details on using XPaths, see XPath Reference. For details on using partial string XPaths, see Handing Dynamic Attribute Values: Partial String Matching Using XPath. |
You can retrieve the HTML for a browser window or frame using input.getHTML(). See the Javadoc for com.parasoft.api.BrowserContentsInput. The Javadocs can be accessed by choosing Parasoft> Help, then looking for the book titled "Parasoft SOAtest Extensibility API". For example, here is a JavaScript that searches for an RFC title.
|
A Browser Validation tool will be chained to the test. This tool will performing the validation. If you later want to modify the validation, you can do so by modifying this tool’s settings.
The element that is the source of a validation will be highlighted with a solid red border in the Browser Contents viewer, and in the Post-Action Browser Contents tab of the Browser Validation tool.
A Browser Data Bank tool will be chained to the Browser Playback tool. This tool will store the extracted value. The extracted value can be used wherever parameterized values are allowed, such as the value to type into an input in a subsequent scenario step or another tool. If you later want to modify the stored value, you can do so by modifying this tool’s settings.
The element that is the source of an extraction will be highlighted with a solid gray border in the Browser Contents viewer, and in the Post-Action Browser Contents tab of the Browser Data Bank tool.
A Browser Validation tool and a Browser Data Bank tool will be chained to the test as described above. In addition, a dotted purple border will be used to highlight the source element.
To validate text that appears on a page (or to extract text to a browser data bank), complete the following:
To create a test that validates the color on a page, complete the following:
-- rgb(0, 255, 0). For more information, see Validation Colors Mapping File.The color validation will be performed when the test is executed.
There is a file in the product installation called the Validation Colors Mapping file. This file defines how SOAtest validates colors by name. It is located in <SOAtest_Installation_Directory>/plugins/com.parasoft.xtest.libs.web_<soatest_version>/root/validation/validationColors.txt.
Each line of the file defines a color by name, along with ranges for each component of the RGB color model. The specified ranges tell SOAtest that if a color is validated and falls within the ranges for each of the components of the RGB color model, then the color being validated matches the color that is defined within those ranges. For example, a line in this file may look like the following:
red, b0-ff, 00-30, 00-30
This line defines the valid ranges for the color “red”. The ranges are specified using hex notation. In the above example the valid R range for red is between the hex values b0 and ff. The valid G and B ranges for red are between the hex values 00 and 30. In other words, if an element has a hex value of #c80000, then it will be considered to be red, since the R value, which is c8, falls between b0 and ff, and each of the G and B values, which are 00, fall between 00 and 30. However, if a validation is set up on an element that is expected to be red, but the element’s color has a hex value of #909090, then SOAtest will display a message that the element has the incorrect color.
The mapping file has a few standard colors already defined. However, if you would like to specify additional colors, you can simply modify the file. There must be only one color defined per line. Also, if you want to change the valid RGB ranges for a defined color, you can also modify the mapping file. Ranges can be specified with a hyphen (b0-ff, as already described), or they can be a single value (ff). If they are a single value, the range of valid values only includes one value. As mentioned before, the ranges must also be in hex notation.
SOAtest must be restarted in order for changes to this file to take effect.
To validate a style property, open the Browser Validation tool’s configuration panel, then set the validation’s Element Property to the value "style_" + <the JavaScript name of the property>. For example, to validate the text-decoration style property, you would specify style_textDecoration (textDecoration is the JavaScript way to specify the style property text-decoration) in the Element Property field, and specify the desired value of the property using the Expected Value controls. In the text-decoration case, the expected value might be equal to line-through or underline.
If you want a certain style property to display as an available property in the validation wizard, you can add that style to the Validation Styles List.
The Validation Styles List file, located in <SOAtest_Installation_Directory>/plugins/com.parasoft.xtest.libs.web_<soatest_version>/root/validation/validationStylesList.txt, specifies runtime style properties that can be validated.
The format of this file is to have one property per line. By default, the color property is specified in this file; however, you can add any valid style properties that you would like to validate. SOAtest must be restarted in order for changes to this file to take effect. Once it is restarted, you will see the properties specified in this file in the validation dialog when right-clicking on an element. The properties will have “style_” appended to each of the properties to tell you (and SOAtest) that these refer to the runtime value individual style properties.
A validation set-up using one of these properties will validate the runtime value of that style property. This is the runtime value of the property after all inline styles and styles defined in CSS files have been applied. Because of this, the value may differ from what is defined inline in the element. For example, these runtime style validations allow you to validate the actual color that is seen by a user after all styles have been processed by the browser.
For each validation, SOAtest automatically configures a message to be shown in the Quality Tasks view (and in reports) if that validation fails. This message typically looks something like "Validation failed for property [property_name]: Actual value found on the page [actual value]" must be equal to expected value [expected value]."
You can easily configure custom messages that are more meaningful in the context of your application. For instance, assume that you are working with an online banking application, and you are adding a validation to check that the account balance does not reach zero. In this case, you might want to spec-ify the custom validation message "Account should not be zero" instead of using the default built-in message, which might be "//span[text() = "account" was not found".
To configure a custom validation:
You can configure the Console view (Window> Show View> Console) to display the stored data bank variables used during test execution. For details, see Console view.
XPaths can be used to specify complex validations. To use XPaths, ensure that the Browser Validation tool’s Element Locator is set to Use XPath, then specify the appropriate XPath. See XPath Reference for details on using XPaths.
If you want to perform complex validations that cannot be properly representing using the GUI controls, you can express them using scripting. To do this, you change the Browser Validation tool’s Element Locator to Use Script, then specify an appropriate script.
For example, suppose that you want to validate all of the rows in a table. That table could be of variable length. You can attach an Extension tool to a browser functional test and pull values from the document provided by input.getDocument(). Here's a sample JavaScript script that accomplishes that.
var Application = Packages.com.parasoft.api.Application;
var WebBrowserTableUtil = Packages.webking.api.browser2.WebBrowserTableUtil;
var WebKingUtil = Packages.webking.api.WebKingUtil;
// Verify that all values in a table column are equal to a previously
// extracted value. For example, we searched for all places in which
// widget 11 is sold, and we want to make sure that all results are // for widget 11.
// input: com.parasoft.api.BrowserContentsInput.
// context: com.parasoft.api.ExtensionToolContext.
function validateTable(input, context) {
// For the column we want to validate. var widgetColumnIndex = 0;
// We extracted through a Browser Data Bank in a previous test
// the expected value to data bank column "widgetName".
// The value was extracted, not from a data source, so use "" or
// null (None in Python) as the name of the data source.
var expectedWidgetName = context.getValue("", "widgetName");
var document = input.getDocument();
// Table should have some unique identifying attribute (e.g., id).
var table = WebBrowserTableUtil.getTable("id", "mytable", document);
// If the first row of the table contained column headers, we could
// use getCellValuesForColumn(String, Element). For example if the
// widget name column was named "Widget Name", then we could use
// getCellValuesForColumn("Widget Name", table). In either case,
// getCellValuesForColumn returns an array of String objects. See
// the JavaDocs for more information.
var values = WebBrowserTableUtil.getCellValuesForColumn(widgetColumnIndex, table);
if (values.length == 0) {
context.report("No rows found!");
}
for (var i = 0; i < values.length; ++i) {
if (values[i] != expectedWidgetName) {
var errorMessage = "Widget name (column " + widgetColumnIndex + "): "
+ "Expected value '" + expectedValue
+ "', but found '" + values[i] + "'.";
context.report(errorMessage);
}
} |