- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Email to a Friend
- Printer Friendly Page
- Report Inappropriate Content
Behind Blue Boxes
I’ve spoken with a lot of iTest users who have come to love the “blue boxes” in the Response view. These blue boxes identify parts of a response that iTest knows how to extract in the form of a query when you are analyzing data. If you use a blue box for analysis, you don’t have to mess around with regular expressions and you can rest assured that if the format of that response changes in a future version of the device software, then tests won’t have to be updated.
But people often ask me about where these blue boxes come from. They seem a bit magical. So I thought some of you might appreciate an in-depth explanation.
To understand blue boxes, open up one of your test cases in iTest. Pick a step that has a response that shows blue boxes. (If you don’t know how to get blue boxes in the first place, you’ll find a lot more in the online help about “response maps”.) Under the Show View dropdown in the main toolbar, select Structure. This will open a new view accordingly. With the same step selected in your test case (or test report), you’ll see in the Structure view that associated with that step is not only the textual response, but there is also a bunch of structured data. You can think of this like a tiny database of information associated with each step. This “database” is actually an XML document. And the way to query information in XML is in a language called XPATH. You can enter any valid XPATH query into the textbox at the top of the Structure view and click the Evaluate button to see what that query will find. If you’d like to learn more about XPATH, click here for a tutorial.
Your Structure view may be covering up the Response view. If you want to see both at the same time, you can drag the Structure view to a different area of your window. Now click on one of the blue boxes in the Response view and keep an eye on the Structure view. What you are going to see is as you click on different blue boxes, the corresponding data in the Structure view will be highlighted automatically. Likewise, if you click on an entry in the Structure view, the corresponding blue box will be selected in the Response view – as long as that structured data appears somewhere in the textual response. Now you get the idea that the blue boxes represent information in the textual response that also appears in the structured portion of the response.
But we’re not finished yet. Now open the Queries view. Here you will see a list of named queries that are associated with this step. If you scroll the Queries view until you can see the XPath column, you will see that each named query corresponds to a raw XPath query. You can think of the query name as a shorthand way of describing a complex XPath query. You might notice that queries have parentheses after them – and that’s because iTest declares an XPath function for each query when processing that step. An XPath function can do anything. The implementation of these “query” XPath functions is to perform an XPath query and return the results of that query as the result of the function. XPath functions are allowed to take arguments and so if your step contains a table, for example, then it is likely that you will see that some of the queries take an argument. For example, a query like inputPkts_By_Port(“Fa1/0/1”) is really an XPath function that takes one string argument. If you look at the raw XPath for that function, you’ll see that it has an XPath that uses the argument as a replacement field in the middle of the XPath.
In the Queries view, you will also see a Location column. If you click on a query whose Location column is populated, you’ll see that the corresponding location is highlighted in the Response view. Again, each query is usually associated with something within the textual response and vice versa.
So now you have the idea that iTest maintains both a textual response and an XML structured response for every step and it maintains a list of named queries associated with that step. You can see the text, XML, and query list in the Response, Structure, and Queries views respectively.
Experienced iTest users find that the Structure and Queries views start to become even more valuable than the Response view. For example, it can often be easier to find the information you want to analyze in the Queries view than in the Response view. You can right-click on items in the Queries view and add analysis rules there, just like you do in the Response view. And when you want to perform more exotic analysis – such as extracting certain lists of values from a response that meet certain strict criteria – then you can build a new XPath query right in the top of the Structure view and play with it until you have exactly the right query. Then you can copy the final query and use it in a new analysis rule. (Did you know that analysis rule queries can be any valid XPath expression?)
Once you have this model in mind and have some understanding of XPath, you can begin to do all kinds of new things in iTest that you never realized you could do before!
![]() | Kingston Duffie is the founder and CTO of Fanfare. Learn more about Kingston >> |



You must be a registered user to add a comment on this article. If you've already registered, please log in. If you haven't registered yet, please register and log in.