Method and system for testing internet software

[0001] New software products that communicate over the Internet must consider the impact of various types of internet security devices and software, such as firewalls. Common test procedures dictate establishment of one or more private networks under the control of the software developer that are connected to the Internet and to each other, but not to the software developer's corporate network due to security issues and concerns. These extranets require additional hardware and specialized procedures to maintain and implement the test environment, and by definition, normal access procedure for product deployment, testing and debugging do not apply. During the development of internet software there are many cycles of code, compile, deploy, test, debug, fix, and repeat. Typically, all development processes are based on access to the software developer's corporate network. In utilizing the extranets the deployment and testing of the internet software is quite challenging, and debugging becomes nearly impossible on the separate extranets.

[0002] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0003] In order to improve upon the testing of internet software, a private network that acts like the Internet, referred to as a simulated internet, is configured with communications paths between two firewall devices, one a web proxy, and the other a publishing firewall, that at the same time are also protecting the corporate network. A domain name server provides name resolution for servers connected to the simulated internet. A test web server on the corporate network is published to the simulated internet by the publishing firewall (also know as reverse proxy) as a unique domain or internet name that only exists on the simulated internet. One or more test client machines on the corporate network are configured to use the test web proxy to access the unique internet name. With this configuration all the pieces are in place for what the Internet does, except the simulated internet is a private network under the control of the software developer. All communications protocol rules that apply to the Internet also apply to the simulated internet, but the tester now has full control over all components of the test environment. This approach eliminates the need for additional hardware and software deployments, and facilitates standard test and debugging procedures. The advantage of such a testing environment is that the simulated internet allows the testers to utilize the same server and test client machines normally used to test direct network connections and multiple Internet connection environments by simply manipulating a few settings in the test client machines and using an appropriate domain name for the target server.

[0011] Referring now to the Figures, in which like reference numerals and names refer to structurally and/or functionally similar elements thereof, FIG. 1 shows a schematic/block diagram of a testing environment utilized by a software developer for testing internet software. In the figures, connections allowing communication between networks and devices are shown as solid lines. Specific transaction or communication paths are shown as solid lines with arrows. Referring now to FIG. 1 and Testing Environment 100, one or more private networks such as Extranet 118 under the control of the software developer are established in order to perform testing on new and existing software products that communicate over the Internet 114. Extranet 118 is connected to Internet 114 but not directly to the software developer's Corporate Network 108.

[0012] Test Automation System 104 controls the configuration and assignment of test machine resources, execution of specific test cases, and the collection of test case results for later analysis. Test Automation System 104 is designed to function within the controlled corporate environment where it has complete control of all machine resources. When the targeted test web server(s) reside in a separate network, such as Extranet 118 that can only be accessed via Internet 114, Test Automation System 104 looses direct control of these server machines. Workarounds to address this type of testing environment create instability in the controlled test environment of Test Automation System 104, and some Internet security settings may not be testable due to corporate security policies implemented on Corporate Web Proxy 110. Therefore, Testing Environment 100 also includes Simulated Test Environment 120 (explained more fully in respect to FIG. 2) which bypasses the use of Corporate Web Proxy 110 and allows Test Automation System 104 to maintain direct control over the test procedures.

[0013] Internet security has two main roles: allow users to safely access internet computers (via a forward proxy), and allow users to safely publish specific computers for internet access (via a reverse proxy). Most internet security products incorporate features of these two roles into a firewall service. The majority of communication directly on the Internet is between firewall devices/firewall software that are protecting anywhere from one to hundreds or thousands of computers.

[0014] In order for Test Client Machines 102 to access servers on Internet 114, Test Client Machines 102 would connect through Corporate Network 108 to Corporate Web Proxy 110 (forward proxy), requesting a URL. Corporate Web Proxy 110 takes over the task and creates a DNS request to find the location of the target server, and sends it over Internet 114. Internet Domain Name Servers 112 provide the location information requested, which may be the internet address of Firewall Server 116 (see description of FIG. 3 below). Corporate Web Proxy 110 then makes a connection to the target server, submits the URL request and returns the requested web page to Test Client Machines 102.

[0015] Firewall Server 116 protects Extranet 118 from requests that come from Internet 114. Extranet 118 is a separate network that is not connected to Corporate Network 108, but is maintained by the software developer to host test servers. Extranet 118 will typically contain web servers, email servers, and so forth (not shown). Firewall Server 116 defines the types of requests from Internet 114 that are allowed to the target servers in Extranet 118. However, corporate IT security policies may dictate network traffic filters that prevent the testing of some internet protocols and firewall features.

[0016] FIG. 2 shows a schematic/block diagram of the testing environment of FIG. 1 with an expanded view of the simulated test environment for testing internet software. Referring now to FIG. 2, Simulated Test Environment 120 has a Test Web Proxy 202 (forward proxy), Test Publishing Firewall 204 (reverse proxy), and Test Domain Name Server 206 which are connected to form Simulated Internet 208. Test Web Proxy 202 and Test Publishing Firewall 204 are shown as dual-homed in that they are also connected to Corporate Network 108, and Test Domain Name Server 206 is not. However, Test Domain Name Server 206 could be configured as dual-homed to allow automated control of Domain Name to IP address entries. Test Domain Name Server 206 will only function on the connection to Simulated Internet 208, and provides name resolution for servers connected to Simulated Internet 208. Test Domain Name Server 206 may be configured to run as a Dynamic Host Configuration Protocol (“DHCP”) server to automatically provide internet addresses to any additional devices attached to Simulated Internet 208. The domain and server names of Test Domain Name Server 206 may be controlled manually or via scripted commands.

[0017] Test Publishing Firewall 204 is connected so that the protected network is Corporate Network 108 and the public connection is to Simulated Internet 208. Rules are created on Test Publishing Firewall 204 to allow Test Web Servers 106 to be accessed on Simulated Internet 208.

[0018] Test Web Proxy 202 is connected so that the protected network is Corporate Network 108 and the public connection is to Simulated Internet 208. Rules are created on Test Web Proxy 202 to allow Test Client Machines 102 to access servers published to Simulated Internet 208.

[0019] Simulated Internet 208 is a private internet with communications paths between the two firewall devices (Test Web Proxy 202 and Test Publishing Firewall 204) that are also protecting Corporate Network 108. For a small testing network, Simulated Internet 208 may simply have a small network switch or hub. For a larger testing network, Simulated Internet 208 may require multiple switches and\or routers.

[0020] Test Web Servers 106 on Corporate Network 108 are published to Simulated Internet 208 by Test Publishing Firewall 204 using reverse proxy or network address translation (“NAT”) as a unique internet name that only exists on Simulated Internet 208. One or more of Test Client Machines 102 are configured to use Test Web Proxy 202 to access servers on Simulated Internet 208. All communications protocol rules apply to Simulated Internet 208 that apply to Internet 114.

[0021] The uniqueness of Testing Environment 200 is that the addition of Simulated Test Environment 120 having Test Web Proxy 202 and Test Publishing Firewall 204, which are connected to private Simulated Internet 208, provides the software developer the ability to create and fully control an “Internet Test Environment” using existing hardware resources of the developer. Corporate IT security policies are not violated since in this embodiment there is no use of Corporate Web Proxy 110 and a connection to an external network. Simulated Test Environment 120 can be controlled by Test Automation System 104, allowing the software developer to utilize existing test automation scripts, with minor modifications, or design new automated tests using current tools and techniques.

[0022] FIG. 3 shows a schematic/block diagram of an embodiment of the simulated test environment having third party firewall and proxy hardware/software for testing internet software. Referring now to FIG. 3, it is shown that Simulated Test Environment 120 could be expanded to allow testing of internet software interactions with security devices and/or firewalls from different third party vendors (Vendor Web Proxies 302 and Vendor Publishing Firewalls 304). Additional optional connections to one or more Private Domain 306 and one or more internal Private Network 308 are also shown that may also be utilized in testing. Many other such configurations are possible, and the ones shown here are merely exemplary of the many such configurations that would suggest themselves to one skilled in the art. The configurations shown are not to be interpreted as limiting the scope of the invention.

[0023] FIG. 4 shows a schematic/block diagram of the data paths and how traffic flows in the simulated test environment of FIG. 2. Referring now to FIG. 4, Test Web Proxy 202 allows access to private domain names on Simulated Internet 208. Test Publishing Firewall 204 contains rules that allow Test Web Servers 106 to be accessed from Simulated Internet 208. Test Automation System 104 controls task execution on all test systems on Corporate Network 108 and Simulated Internet 208. For instance, within Corporate Network 108 a Test Web Server 106 may be named http://server.corp.com). Then when a Test Client Machine 102 connects to http://server.corp.com, the Transaction Path 402 uses Corporate Network 108 to access Test Web Servers 106 and the response comes back along the same Transaction Path 402.

[0024] For testing on Simulated Internet 208, a Test Web Server 106 named http://server.corp.com is published to Simulated Internet 208 as http://server.test.domain. When one or more Test Client Machines 102 connect to http://server.test.domain the Transaction Path 404 goes through Test Web Proxy 202 and uses Simulated Internet 208, through Test Publishing Firewall 204 to access Test Web Servers 106 and the response comes back along the same Transaction Path 404.

[0025] Test Automation System 104 can run a suite of tests utilizing Transaction Path 402 and then run the same tests using Transaction Path 404 and compare the results. Additional testing may focus on modifying the configuration of Test Web Proxy 202, Test Publishing Firewall 204, or Test Web Servers 106 between test runs.

[0026] FIG. 5 shows a schematic/block diagram of the additional data paths and how traffic flows in the simulated test environment of FIG. 3. Referring now to FIG. 5, Private Domain 306 which is connected to Corporate Network 108 may have Private Firewall 504, Private Domain Controller 506, and Private Servers 508. Private Domain 306 can publish its Private Servers 508 to Corporate Network 108. Transaction Path 510 is comparable to Transaction Path 402 of FIG. 4. Transaction Path 404 may be extended to encompass Vendor Publishing Firewalls 304 and Vendor Web Proxies 302.

[0027] Internet Clients 514 are connected directly to Simulated Internet 208. Transaction Path 512 from Internet Clients 514 may be channeled through either Vendor Publishing Firewalls 304 or Test Publishing Firewall 204 to reach Private Servers 508 published by Private Firewall 504 via Transaction Path 516. Test Web Servers 106 may also be accessed by Internet Clients 514 through Transaction Path 512 to Vendor Publishing Firewalls 304 or Test Publishing Firewall 204 via Transaction Path 404 or part of Transaction Path 516 external to Private Domain 306. Private Servers 508 may also be accessed by Test Client Machines 102 through an extension of Transaction Path 402 and part of Transaction Path 516 internal to Private Domain 306.

[0028] FIG. 6 shows a block flow diagram of an embodiment of a method of testing internet software utilizing a simulated internet. Referring now to FIG. 6, the method begins in step 602 by constructing Simulated Internet 208 that is connected to a Corporate Network 108. The details of this step are shown in FIG. 7 which shows a block flow diagram of an embodiment of setting up a simulated internet connected to a corporate network. Referring now to FIG. 7, in step 702 Test Publishing Firewall 204 is connected so that the protected network is Corporate Network 108 and the public connection is to the network switch or hub of Simulated Internet 208.

[0029] Next, in step 704 a Test Domain Name Server 206 is connected to Corporate Network 108 via the network switch or hub of Simulated Internet 208. DNS service of Test Domain Name Server 206 will only function on the connection to Simulated Internet 208. The connection to Corporate Network 108 via Simulated Internet 208 is used for remote control or automated creation of DNS entries.

[0030] Test Web Proxy 202 is connected in step 706 so that the protected network is Corporate Network 108 and the public connection is to the network switch or hub of Simulated Internet 208.

[0031] Referring back now to FIG. 6, in step 604 parameters are set for the particular testing environment. DNS records are used to create unique DNS Domains and server names in those domains required for the particular testing to be done. The simplest implementation is a “Wild Card” DNS entry that associates all server names with a single address on Simulated Internet 208. Internet proxy settings can be configured on Test Client Machines 102 to use a Proxy Automated Configuration (PAC) script to resolve server names for connection. Rules are created on Test Publishing Firewall 204 or Vendor Publishing Firewalls 304 to allow Test Web Servers 106 of Corporate Network 108 to be accessed from Simulated Internet 208. Rules are also created on Test Web Proxy 202 or Vendor Web Proxies 302 to allow internal Test Client Machines 102 to access servers that are published to Simulated Internet 208.

[0032] In step 606 the software tests are conducted utilizing Simulated Internet 208 and Corporate Network 108. Test Automation System 104 of Corporate Network 108 controls and runs suites of automated tests against the internet software to be tested, such as client software or server software. Test Automation System 104 has a centralized database of scripted instructions to accomplish a testing task. At the conclusion of the testing, the method ends. However, steps 604 and 606 can be repeated for additional tests on the same software, or, new software can be tested instead.

[0033] Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims. It will be understood by those skilled in the art that many changes in construction and widely differing embodiments and applications of the invention will suggest themselves without departing from the scope of the present invention.