After many years working in the Silk Performer support team the most common type of support question raised is probably how Silk Performer scripts can fail to implement the behaviour we expect. This series of articles explains some of the reasons scripts may fail and the advice we provide in our support role. 200 - Not ok When working within http/html web business transaction type projects and recording scripts at the http protocol level it’s important to note that the success or failure of a particular API call is determined by the http status code the server responds with, not whether the business logic was implemented. With this in mind it is very possible, and common, that your running script can result in an all green TrueLog file which indicates a successful replay; but on closer inspection the database wasn’t updated, or the record doesn’t exist or the item was not added to the basket. So what’s happening here? The simplest way to understand this is to understand what Silk Performer is actually doing when it runs a http protocol level script. We tend to think at a system level where we expect a certain number of inputs to have a specific output but Silk Performer is not that way inclined – it works on a request response basis with no overall understanding of the application under test or how it is supposed to operate. So if every application is different, and Silk Performer has no knowledge of application business logic, workflows or expected application output then how does it work at all? The answer lies in the http specification. The http specification is a set of defined and agreed upon rules which lay out how web applications which use the http protocol for communication should behave. So Silk Performer sends a request, and based on this requests data, and the http specification rules it also knows what the response should be. RFC 7231 defines that any basic http client should understand at least the 5 main classes of http response codes: 1xx, 2xx, 3xx, 4xx, 5xx. In a nutshell, your script can generate a completely successful replay from a server status code perspective whilst being completely unsuccessful from your business logic perspective. Take the example of an image file. Web pages are made up of many image files and when Silk Performer requests a web page from an application it parses the source code of the response body and also performs sub requests for all additional embedded content (assuming the use of contextful functions). It might look something like this: Request` Response GET /take2.gif HTTP/1.1 Referer: http://demo.borland.com/ Host: demo.borland.com Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.0) HTTP/1.1 200 OK Content-Type: image/gif Accept-Ranges: bytes Server: Microsoft-IIS/7.5 X-Powered-By: ASP.NET Content-Length: 626 All that’s really happening here is that Silk Performer is sending a request header for a file called take2.gif from a particular host and the host returns a response header which provides the 200 ok status code, meaning the request was successful (the response body or image would follow). However the issue is that Silk Performer is basing its own green successful status in TrueLog solely on the http status code 200 returned by the server, not on the files contents. It’s safe to assume that if an image is requested from the server and the server returns 200 status code then the image has been returned successfully however this is not the case when dealing with entire pages. Let’s look at another request: Request` Response GET /InsuranceWebExtJS/ HTTP/1.1 Host: demo.borland.com Connection: Keep-Alive Accept: */* Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.0) HTTP/1.1 200 OK Content-Type: text/html;charset=UTF-8 Content-Encoding: gzip Server: Microsoft-IIS/7.5 X-Powered-By: JSF/1.2 Content-Length: 2629 On this occasion the request is for a page, not a single image. Again the page has been returned and this is verified by a 200 status code but without checking the content of the page there is no way of knowing whether this is the correct page – whether it contains the content you expect – whether your business logic has been implemented. Its important to note at this stage that Silk Performer's Page Based Browser level API does contain some built in verifications based on web context management. This means it scripts context-full functions (WebPageLink, WebPageSubmitBin etc) which, by their design use the results of previous function calls. This is best illustrated by the following example from the Silk Performer help files: Example HTML code: a hfref=http://www4.company.com/store/5423/account Edit Account \a The above link contains load balancing information (www4) and a session id (5423) in the target URL. Assume the user clicks this link. This can be modeled in BDL using the WebPageUrl function: WebPageUrl("http://www4.company.com/store/5423/account"); The problem with this is that the dynamic components of the URL are hard-coded into the script. Alternatively, the WebPageLink function can be used: WebPageLink("Edit Account"); This solution is better because the Silk Performer replay engine will, using its HTML parser, use the actual URL that is associated with the link name Edit Account during replay. While it is still possible that a link name can change dynamically, it is far less likely than having a URL change. So in essence context-full functions do give Silk Performer some knowledge of what a response should contain which empowers the replay engine to look for certain things. For example if the page which contains this edit account link is returned from the server a 200 OK is received. However if the edit account link is not on the page the server will still respond 200 OK but the Silk Performer replay engine will throw an error to indicate that a link which was expected was not found. Now that we understand how a TryScript can show as successful when the script hasn’t performed the actions you expected you might wonder what can be done about that beyond the built in verifications of context management or manually verifying the response of every request. The answer is to add verifications to your script to check for key items you know will be on the page if the business logic has been successfully implemented. In the next section we will look at Understanding Session, Missing Header Information and Post Data
↧