Automated testing of websites based on mode

Examples of techniques for testing websites are described herein. In one example, a method for testing a website includes receiving, via a processor, a website address of the website to be tested. The method can include determining, via the processor, whether the website is in a staging mode or a production mode. The method can also include configuring, via the processor, a testing application to test the website according to the determined mode.

BACKGROUND OF THE INVENTION

The present invention relates to automated testing of websites, and more specifically, to an automated method of testing web sites based on whether the websites are running in staging or production web deployment modes.

SUMMARY

According to an embodiment described herein, a method for testing a web site can include receiving, via a processor, a website address of the website to be tested. The method can also include determining, via the processor, whether the website is in a staging mode or a production mode. Furthermore, the method can include configuring, via the processor, a testing application to test the website according to the determined mode.

According to another embodiment described herein, a system can include a processor and a storage device comprising processor executable instructions. In some examples, the instructions when executed by the processor, cause the computing system to receive a website address of the website to be tested. The processor can also determine whether the website is in a staging mode or a production mode. Furthermore, the processor can configure a testing application to test the website according to the determined mode.

According to another embodiment described herein, a computer program product can test a website. The computer program product includes a computer readable storage medium having program code embodied therewith, the program code executable by a processing circuit to perform a method including receiving, via the processing circuit, a website address of the website to be tested. The method includes determining, via the processing circuit, whether a website to be tested is running in a staging mode or a production mode. Furthermore, the method includes configuring, via the processing circuit, a testing application based on the determined mode.

DETAILED DESCRIPTION

According to embodiments of the present disclosure, a computing device can test a website based on whether the website is running in a staging mode or a production web deployment mode (herein “production mode”). A staging mode, as referred to herein, is the operation of a website in a testing environment in which the website is not available publicly to users. A production mode, as referred to herein, is the operation of a website wherein a website is publicly available to users. In the staging mode, the operation of the website may not fully represent the behavior, data, or functionality of the production site. In the production mode, the operation of the website may not allow for intrusive testing to the level and depth of testing in the staging mode. In some examples, an external computing device can detect whether the website is running in a staging mode or a production web deployment mode. The external computing device may send the detected mode to a mode detection module of the system to configure a testing application accordingly.

In some scenarios, the techniques described herein may be implemented in a cloud computing environment. As discussed in more detail below in reference to at leastFIGS. 1, 5, and6, a computing device configured to detect a mode of operation of a given website may be implemented in a cloud computing environment. It is understood in advance that although this disclosure may include a description on cloud computing, implementation of the teachings recited herein are not limited to a cloud computing environment. Rather, embodiments of the present invention are capable of being implemented in conjunction with any other type of computing environment now known or later developed.

Characteristics are as follows:

Service Models are as follows:

Deployment Models are as follows:

With reference now toFIG. 1, an example computing device can test websites based on mode of operation. The computing device100may be, for example, a server, desktop computer, laptop computer, tablet computer, or smartphone. In some examples, computing device100may be a cloud computing node. Computing device100may be described in the general context of computer system executable instructions, such as program modules, being executed by a computer system. Generally, program modules may include routines, programs, objects, components, logic, data structures, and so on that perform particular tasks or implement particular abstract data types. Computing device100may be practiced in distributed cloud computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed cloud computing environment, program modules may be located in both local and remote computer system storage media including memory storage devices.

The computing device100may include a processor102that is capable of executing stored instructions, a memory device104to provide temporary memory space for operations of said instructions during operation. The processor can be a single-core processor, multi-core processor, computing cluster, or any number of other configurations. The memory device104can include random access memory (RAM), read only memory, flash memory, or any other suitable memory systems. The instructions executed by the processor102may be used to implement a method that can monitor transmitted data.

The processor102may be connected through a system interconnect106(e.g., PCI®, PCI-Express®, etc.) to an input/output (I/O) device interface108configured to connect the computing device100to one or more I/O devices110. The I/O devices110may include, for example, a keyboard and a pointing device, wherein the pointing device may include a touchpad or a touchscreen, among others. The I/O devices110may be built-in components of the computing device100or may be devices that are externally connected to the computing device100.

The processor102may also be linked through the system interconnect106to a display interface112adapted to connect the computing device100to a display device114. The display device114may include a display screen that is a built-in component of the computing device100. The display device114may also include a computer monitor, television, or projector, among others, that is externally connected to the computing device100. In addition, a network interface controller (NIC)116may be adapted to connect the computing device100through the system interconnect106to the network118. In some embodiments, the NIC116can transmit data using any suitable interface or protocol, such as the internet small computer system interface, among others. The network118may be a cellular network, a radio network, a wide area network (WAN), a local area network (LAN), or the Internet, among others. An external computing device120may connect to the computing device100through the network118. In some examples, external computing device120may be an external webserver120.

The processor102may also be linked through the system interconnect106to a storage device122that can include a hard drive, an optical drive, a USB flash drive, an array of drives, or any combinations thereof. In some examples, the storage device122can include a mode detection module124and testing application126.

In some embodiments, a mode detection module124can communicate with external computing device120to determine if a website is in a staging or production mode. For example, mode detection module124may receive a message from external webserver120that a website is running in production mode. In some embodiments, the mode detection module124may send the mode information to a testing application126. Testing application126can have testing configured according to the mode detected by the mode detection module124.

In embodiments, the testing application126can test a website based upon its mode. In some examples, the testing application126may send a uniform resource locator (URL) to mode detection module124which in turn sends the URL to external webserver120. External webserver120may then determine whether a website at the URL is running in a staging or production mode. For examples, external webserver120may determine the mode by pinging the URL and monitoring for a response as described in greater detail below, in reference to FIG.2andFIG. 3. The external webserver120may then return the mode of operation at the URL to mode detection module124. The testing application126may then receive the mode of operation and configure testing based on the mode of operation received.

It is to be understood that the block diagram ofFIG. 1is not intended to indicate that the computing device100is to include all of the components shown inFIG. 1. Rather, the computing device100can include fewer or additional components not illustrated inFIG. 1(e.g., additional memory components, embedded controllers, additional modules, additional network interfaces, etc.). Furthermore, any of the functionalities of the mode detection module124and testing application126may be partially, or entirely, implemented in hardware and/or in the processor102. For example, the functionality may be implemented with an application specific integrated circuit, or in logic implemented in the processor102, among others.

FIG. 2is a block diagram of an example system that can automate testing of websites based on mode of operation. In some embodiments, the system200can include an external webserver202, a testing platform204, and at least one website206. The external webserver202can attempt to communicate with at least one website206to determine whether it is running in a staging or production mode. The external webserver202can transfer the mode information to a testing platform204by any suitable protocol.

In some embodiments, the testing platform204can include a mode detector208and at least one website testing application210. In some examples, there may be one instance of the website testing application210for each website206to be tested. The mode detector208may receive operation mode data from external webserver202and forward the data to the website testing application210. In some embodiments, the mode detector208may receive mode data from any suitable number of external webservers202. For example, multiple external webservers202may receive URLs to determine the mode of a website206. In some examples, the external webserver202may then ping the URL. For example, the external webserver202may send echo request packets to a given URL. If no response is received by any of the external webservers202for the given URL echo requests sent, then a staging mode may be determined, as discussed in more detail below in reference toFIG. 3.

In some embodiments, the website testing application210can include a tuner212and testing session214to perform testing on website206. For example, the website testing application210can use the tuner212to configure testing session214appropriately based on the mode of operation of website206. In some examples, tuner212may receive production mode data from mode detector208and filter out tests that are not to be performed in a production mode testing session214. For example, if website206is running in a production mode, then tests that would be deemed inappropriate for a production environment would be filtered out by tuner212from the corresponding testing session214to be run on that publicly available production mode website206. For example, in security testing, test payloads are fired at the website206. However, when operating in production mode, certain tests can potentially mutate the persistent state of website206as well as cause unintended behaviors such as crashes, deadlocks, and livelocks. The persistent state of the website206may include backend databases, its file system, among other file structures. Tuner212may, therefore, prevent test payloads capable of potentially mutating the persistent state from being used on the website206during production mode. For example, tuner212may exclude tests on CRUD (Create, Read, Update, Delete) operations that may alter site information (including the Create, Update, or Delete operations) from a testing session214to be run on a website206running in production mode.

In performance testing, certain tests can cause the website206, or an application associated with the website206, to become slow and unresponsive and may even lead to crashes. In some scenarios, the tuner212may prevent performance tests that are too burdensome from being executed on a website206determined to be in production mode. For example, the tuner212may limit the number of threads to be used on a testing session214for a production mode website206. In this manner, the tuner212may limit the number of tests that would be sent per second to the website206when in production mode. In some examples, tuner212may also exclude denial of service (DoS) tests from a testing session214to be run on a production mode website206.

In integrity testing, which may include verifying that response HTML pages of websites206are intact and abide by the HTML specification for example, certain tests may lead to unresponsiveness as well as crashes. Therefore, in some examples, tuner212may also prevent such integrity tests from running on the website206when in production mode. Testing of login sequences may also lock accounts. Therefore, in some examples, tuner212may also prevent tests on login sequences.

In some examples, the website206may be running in a staging mode. A website206running in staging mode may have additional tests or all tests included by tuner212in its testing session214. In some embodiments, the tuner212may analyze tests to be run in testing session214as they are added to website testing application210. For example, tests may be added or updated through updates to the website testing application210. In some examples, tuner212may analyze tests on a test-by-test basis at runtime of the website testing application210.

By automating the testing of websites based on mode detection of a given website to be tested, embodiments of the techniques described herein reduce the rate of error that may occur in manual configurations of testing by administrators due to human error. For example, an administrator might mistakenly run a staging mode test on a production mode website and cause it to crash. Thus, consistency is introduced through automation. The time required for an administrator to specify different configurations for testing may also be saved while allowing for the most intrusive, yet also safe, testing session to be performed. Moreover, response time to new threats in, for example, security testing may also be reduced.

FIG. 3is a process flow diagram of an example method that can test websites based on mode of operation. The method300can be implemented with any suitable computing device, such as the computing device100ofFIG. 1.

At block302, an external webserver120,202can receive a website address of a website206to be tested. As discussed above, the website address may be in the form of a URL address. In some examples, webserver120,202may receive website addresses for each website206to be tested. In some examples, the webserver120,202may receive the website addresses from a mode detector208of the testing platform204.

At block304, an external webserver120,202can determine whether a website is in a staging mode or a production mode. In some examples, external webserver120,202may determine whether a website206is running in production mode by sending a request to the website206using the URL address. For example, the external webserver120,202may send echo request packets using the Internet Control Message Protocol (ICMP) to website206to determine if it is operating in production mode. If the external webserver120,202receives no echo response to the ping, then external webserver120,202returns a no response message to mode detector208. If external webserver120,202receives an echo response to its echo request packets, then external webserver120,202returns a successful response message to mode detector208. In some examples, mode detector208may send an URL to multiple external webservers120,202to increase reliability of detection. For example, mode detector208may send an URL to three external webservers120,202and only receive successful response messages from one or two of the external webservers120,202. In some examples, the mode detector208may treat a successful response from at least one server as a detected production mode and send a production mode indication for the respective URL to tuner212.

At block306, the tuner212can configure the testing application126,210to test the website206according to the determined mode. In some embodiments, tuner212may create an appropriate testing session based on the mode of website206detected by the mode detector208and external webserver120. For example, tuner212may receive a message from external webserver120,202that website206is operating in a production mode. In some examples, tuner212may then prevent unsuitable tests from being run in testing session214for website206. In some examples, tuner212may exclude tests that are overly intrusive for a production environment. In some embodiments, configuring the testing application can include mode-specific test preparation options prior to determining the mode of the website. For example, the tuner212may configure testing application126,210by creating a testing session option to be run in production mode and a testing session option to be run in a staging mode before the external webserver120determines the mode of the website206. The website testing application210may then use the corresponding testing session of the mode detected by mode detector208when website206is to be tested.

At block308, a testing application126,210can test the website206. In some embodiments, website testing application210can create a testing session214for each website206to be tested. In some examples, the tuner212may continue tuning testing session214while it is running. For example, a new test may have been added to run, or a test may be determined to be inappropriate by the tuner212for the particular website206.

The process flow diagram ofFIG. 3is not intended to indicate that the operations of the method300are to be executed in any particular order or that all of the operations of the method300are to be included in every case. For example, the tuning of testing session214may occur before the external webserver202determines the mode of website206. In some examples, the tuning of testing session214may occur after external webserver202determines the mode of website206but before testing session214is run on website206. In some examples, tuning of testing session214may occur after testing session214has already been executed, and the testing session214may be tuned during runtime. Additionally, the method300can include any suitable number of additional operations.

Referring now toFIG. 4, a block diagram is depicted of an example of a computer readable storage medium that can test websites based on mode of operation. The computer readable storage medium400may be accessed by a processor402over a computer interconnect404. Furthermore, the computer readable storage medium400may include code to direct the processor402to perform the operations of the current method.

The various software components discussed herein may be stored on the computer readable storage medium400, as indicated inFIG. 4. For example, a mode detection module406may detect the mode of operation of a website to be tested. In some embodiments, a tuner module408can create website testing application410based on the mode of operation detected by mode detection module406. In some examples, the website testing application410can be tuned on a test-by-test basis in real-time. It is to be understood that any number of additional software components not shown inFIG. 4may be included within the computer readable storage medium400, depending on the specific application.

Referring now toFIG. 5, illustrative cloud computing environment500is depicted. As shown, cloud computing environment500comprises one or more cloud computing nodes502with which local computing devices used by cloud consumers, such as, for example, personal digital assistant (PDA) or cellular telephone504A, desktop computer504B, laptop computer504C, and/or automobile computer system504N may communicate. Nodes502may communicate with one another. They may be grouped (not shown) physically or virtually, in one or more networks, such as Private, Community, Public, or Hybrid clouds as described hereinabove, or a combination thereof. This allows cloud computing environment500to offer infrastructure, platforms, and/or software as services for which a cloud consumer does not need to maintain resources on a local computing device. It is understood that the types of computing devices504A-N shown inFIG. 5are intended to be illustrative only and that computing nodes502and cloud computing environment500can communicate with any type of computerized device over any type of network and/or network addressable connection (e.g., using a web browser).

Virtualization layer602provides an abstraction layer from which the following examples of virtual entities may be provided: virtual servers; virtual storage; virtual networks, including virtual private networks; virtual applications and operating systems; and virtual clients. In one example, management layer604may provide the functions described below. Resource provisioning provides dynamic procurement of computing resources and other resources that are utilized to perform tasks within the cloud computing environment. Metering and pricing provide cost tracking as resources are utilized within the cloud computing environment and billing or invoicing for consumption of these resources. In one example, these resources may comprise application software licenses. Security provides identity verification for cloud consumers and tasks as well as protection for data and other resources. User portal provides access to the cloud computing environment for consumers and system administrators. Service level management provides cloud computing resource allocation and management such that required service levels are met. Service Level Agreement (SLA) planning and fulfillment provide pre-arrangement for, and procurement of, cloud computing resources for which a future requirement is anticipated in accordance with an SLA.