The most basic way to test a Web application is to manually test the app through the client software (IE in a Microsoft environment). From the scenario described in the previous entry, you would type in a search term, click the submit/search button on IE, wait for the HTTP request to be received and processed by the target Web server. Then after the resulting HTML page is returned to the client as an HTTP response and rendered by IE, you would visually verify that the result page is correct or not. Manual testing is essential but gets very tedious, very quickly.
The most fundamental way to test a Web application using test automation is shown by the screenshot at the bottom of this page. Instead of sending a request through IE, you create a test harness client and programmatically send an HTTP request to the Web server. The request is received by IIS, and an HTML page is returned back to the test harness client. Instead of rendering the HTML in friendly form, the test harness examines the HTML response, looking for values which indicate whether the response is correct or not.
In principle, this testing technique is quite simple, but there are a lot of details. Luckily, if you are working in a Microsoft environment, the .NET Framework makes this technique relatively easy. The technique is centered around HTTP. Now HTTP is a protocol which rides on top of TCP/IP. So, an alternative approach is to programmatically send the request from client to server using TCP/IP. I’ve heard mixed opinions on whether using this approach is necessary, or even a good idea. On argument goes, "why bother?" Another argument goes, "you easily get additional testing and also validate your HTTP-based test results." In general, because there is rarely enough time to test any software system thoroughly, I rarely use the TCP/IP technique, but it has come in handy several times.