Abstract: A get request employing TCPIP sockets is issued which obtains requested HTML pages associated with the application from the web server. A search is executed extracting all links on the page automatically. The links are optionally sorted as designated in an input file or command line in random order so as to generate a typical access paths through the web server application during testing and verification thereof. The retrieved and extracted data is formatted and output in a common format employable in an input file by multiple test application tools which request, capture, store, verify data returned from, and stress the web servers and associated applications. In a preferred embodiment, server port, and server name specified by host name or address, may be designated either in the input file or command line.

Abstract: A computerized subsystem starts multiple user-defined threads, each of which is a virtual browser for a web site server application under test and executing on a web server. Each individual virtual browser requests and posts data to the server and corresponding server application under test at a rapid rate. Actual returned data is not saved but time of transaction and whether page is found and returned is logged. The server and port to test are user-specified in an input data file or can alternatively, by command line option. A repeat option causes the subsystem to loop through the input file a specified number of times, hours, and an indefinite repeat. User-specified sleep values slow down requests to simulate actual users. A wait option creates a semaphore causing all threads to wait for the semaphore which appear only after all threads are created, whereupon such threads begin execution simultaneously to maximize stress on the server and application.

Abstract: An Internet website virtual browser application automatically exercises and verifies web server applications and scripts by simulating a web browser to request, capture, store, and verify data returned from web servers, discarding data not critical to testing, and saving and reusing retained data for subsequent transactions. Input and links are accepted from a GUI edit field or input data file, with posts and gets supported to return pages and other requested data, saved in user-specified files for verification. GUI edit field options may override server/port definitions without changing input data files and provides for user-specified termination after a specified number of errors, specifying number of retries and level-setting of messaging for log files and screens. A log file stores the request and byte count total bytes transferred, time of transaction, throughput or transfer time, and result of compares. The verify option automatically compares previously received and current request data.