Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
METHOD OF TESTING WEBPAGE LAYOUT
Document Type and Number:
WIPO Patent Application WO/2016/075552
Kind Code:
A1
Abstract:
A method of regression testing of the appearance of a webpage or pages is described. The function of particular code portions that are used in rendering particular portions of a webpage are evaluated and images associated with that function are stored. This defines a reference and the method provides subsequent testing to evaluate the functionality of a particular webpage in multiple browsers or versions of the same webpage in the same browser. The testing provides a comparison between the reference and the output of the test process.

Inventors:
BELOV SERGEI IGOREVICH (RU)
TATARINTSEV SERGEI VLADIMIROVICH (RU)
ALAEV VLADIMIR VIKTOROVICH (RU)
Application Number:
PCT/IB2015/052432
Publication Date:
May 19, 2016
Filing Date:
April 02, 2015
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
YANDEX EUROPE AG (CH)
YANDEX LLC (RU)
YANDEX INC (US)
International Classes:
G06F11/36; G06F3/048
Domestic Patent References:
WO2008065426A22008-06-05
Foreign References:
US20140105491A12014-04-17
US20110276834A12011-11-10
US20040059809A12004-03-25
Attorney, Agent or Firm:
CUTLER, Jonathan D. (1100 Rene-Levesque Blvd WestSuite 250, Montreal Qu├ębec H3B 5C9, CA)
Download PDF:
Claims:
Claims:

1. A method of regression testing webpage functionality, the method comprising: identifying at least one functional block within a webpage, each functional block of the at least one function block having a first functional state and a second functional state, each functional state being associated with a specific rendered image that is generated as a result of the execution of code defined by that functional block; emulating, at a first instance in time, an execution of code defined by the functional block and capturing, for that emulated execution, a rendered graphical image for each of the first functional state and the second functional state; associating the captured rendered images with the functional block and storing the captured rendered images as a benchmark dataset; emulating, at a second instance in time, an execution of the functional block and capturing, for that emulated execution, test rendered graphical images for each of the first functional state and the second functional state so as to form a test dataset; comparing image pixel values from images of each of the test dataset and the benchmark dataset to identify changes between the test dataset and the benchmark dataset.

2. The method of claim 1 wherein emulating an execution of the at least one functional block is effected by initially defining a test suite for that functional block, the test suite being defined by accessing pre-generated test routines that are stored within a test library database. 3. The method of claim 2 wherein the test routines are linked to one another and define a series of steps which when executed against a specific one of the at least one functional block mimic user interaction with the webpage incorporating that functional block.

4. The method of claim 3 wherein the test suite is configured to process the functional block through the first functional state and second functional state and effect capture of a screen shot for each of the first and second functional states.

5. The method of claim 1 comprising generating a library of benchmark datasets, each benchmark dataset comprising images associated with a specific functional block.

6. The method of claim 1 wherein each of the test dataset and the benchmark dataset comprises rendered graphical images captured from emulation of the functional code in a single browser environment.

7. The method of claim 1 wherein each of the test dataset and benchmark dataset comprise rendered graphical images captured from emulation of the functional code in different browser environments thereby providing identification of compatibility of the webpage in the different browser environments.

8. The method of claim 1 comprising creating a data file comprising data indicative of changes between the test dataset and the benchmark dataset. 9. The method of claim 8 comprising identifying differences between the test dataset and the benchmark dataset for each state of a plurality of states which the functional code generates during the emulation process.

10. The method of claim 1 wherein the comparing image pixel values comprises analysing colors of pixels in each of the images in the test dataset and the benchmark dataset. 11. The method of claim 10 wherein the comparing comprises treating colors of each pixel as a simplified color.

12. The method of claim 1 comprising parsing code defining the webpage to determine which portions of the code have been defined in functional blocks.

13. The method of claim 12 comprising identifying which of the functional blocks have been tested at the second instance in time.

14. A computer program product comprising executable instructions stored on a computer readable medium which when executed on a computing apparatus are arranged to perform the method of claim 1.

15. A system for regression testing webpage functionality, the system comprising: A first datastore storing a benchmark dataset, the benchmark dataset comprising rendered graphical images of at least portion of a webpage in a first functional state and a second functional state, the rendered graphical images being associated with code from a functional block which when emulated effected a rendering of the rendered graphical images; A processor configured to: effect an emulation of the functional block to generate a test dataset, the test dataset comprising captured rendered images of at least portion of the webpage in the first functional state and the second functional state at a second instance in time;

Compare image pixel values of images in each of the benchmark dataset and the test dataset to identify changes in the rendered graphical image between the benchmark dataset and the test dataset.

16. The system of claim 15 comprising a test suite library, the test suite library comprising pre-generated test routines that are useable in a test suite to evaluate functionality of a functional block.

17. The system of claim 16 wherein the test routines are linked to one another and define a series of steps which when executed against a specific one of the at least one functional block mimic user interaction with the webpage incorporating that functional block.

Description:
METHOD OF TESTING WEBPAGE LAYOUT

Cross-Reference

[0001] The present application claims priority to Russian Patent Application No. 2014145739, filed November 14, 2014, entitled "METHOD OF TESTING WEBPAGE LAYOUT" the entirety of which is incorporated herein.

Field

[0001] The present technology teaches a method of processing webpages and in particular to a method of processing webpages to facilitate testing functionality in webpages. Background

[0002] Webpage testing is known and is used for a variety of reasons. For example, it is known to test a compatibility of a particular webpage with different browsers. It is also known to test the effect of updates in the underlying code that is used to effect a rendered effect in a generated webpage when viewed on a browser. Examples of this testing include regression testing which is a known form of software testing. This software testing is used to identify bugs or other software regressions which cause an intended feature to stop functioning after changes in the underlying software or as a result of using a different browser type to render the intended graphical user interface, GUI, for that particular software code.

[0003] US 6,898,764 B2 identifies that a significant part of the development cycle in any software program is the testing cycle. Testing is necessary to ensure that the program functions correctly. For many programs, part of the testing cycle includes graphical user interface (GUI) object testing and this patent discloses how GUI object testing is typically implemented via testing tools such as GUI capture play back testing tools. To facilitate the automation of GUI test cases, the testing tools commonly create various forms of GUI mapping files that are used to describe the contents of the program's GUI at an object level. Specifically, a GUI mapping file generally includes one line of text for each GUI object, with each line describing a particular GUI object [0004] US 2008/0310736 Al discloses a visual comparison system whereby a comparison of two images can be compared analytically. The two images can be screenshots of a user interface, or any other pair of images to be compared. As described, the two images can be compared using both graphic information as well as control information and metadata. The control information can enhance the information known about an image beyond simple graphic information. Elements represented in the image such as buttons, lists, text boxes, lists, radio buttons, and the like, can be identified for their functionality rather than just for their aesthetics. Using this control data, the elements can be compared for differences, which can then be represented to a tester for easy identification and resolution.

Summary

[0005] In accordance with a first broad aspect of the present technology, there is provided a method of regression testing of the appearance of a webpage or pages. In this aspect the present teaching provides a method that allows testing of fragments of a particular test page in multiple browsers or versions of the same page in the same browser.

[0006] A method in accordance with the present teaching can be used for testing a webpage for browser compatibility or the effect of changes in the underlying code that is used to render the intended same webpage on the same browser.

[0007] In accordance with the present teaching, a webpage, or a plurality of webpages that collectively define a website, is defined into a plurality of functional blocks. Each of the functional blocks has at least a first functional state and a second functional state, each functional state being associated with a specific rendered image that is generated as a result of the execution of code defined by that functional block. By emulating, at a first instance in time, an execution of code defined by the functional block it is possible to capture, for that emulated execution, a rendered graphical image for each of the first functional state and the second functional state. These captured rendered images can then be associated with the functional block and stored as a benchmark dataset. At a second instance in time it is possible emulate an execution of the functional block and capturing, for that emulated execution, test rendered graphical images for each of the first functional state and the second functional state so as to form a test dataset. Comparing image pixel values from each of the benchmark dataset and the test dataset allows an identification of changes between the two. These changes can be used to assess the result of changes in the webpage or the compatibility of the webpage with specific browsers.

[0008] In accordance with the present teaching, a rendered graphical image which is generated by execution of that code is captured using one or more capturing screen shots. These screen shots are then linked or otherwise associated with the originating code. By isolating individual portions of the functional code and associating them with individual screen shots for that code portion it is possible to see at a greater level of granularity what is achieved by the code- for example the effect of drop down menus etc. By providing analysis at this level of granularity, it is also possible to see how that specific portion of code will affect the overall aesthetic of the webpage. For example in accordance with the present teaching it is possible to test the visual effect caused by a test portion of code against adjacent rendered portions of a webpage that originate from non-changed portions of code. It is also possible to subsequently determine which portions of the originating code were actually tested as opposed to the overall page itself.

[0009] Such a methodology is particularly advantageous in allowing testing of specific blocks of a webpage and associating with those blocks of code appropriate screen shots which can then be used as reference screen shots.

[0010] The present teaching provides a methodology that facilitates generation of a library of a series of reference screen shots for specific blocks of code. This library of reference screen shots can then be used at a later time period to examine how a later iteration of that webpage or the same instance of that webpage in a different browser environment results in a different rendered image. In accordance with an aspect of the present teaching a data file is created as a result of the test process that identifies a reference image, a current image and differences between the two. This can be done for each state in each browser within which a particular webpage is tested. In another aspect a data file is created as a result of the test process that identifies a reference image, a current image and differences between the two for each time delimited period within which a particular webpage is tested in the same browser.

[0011] In order to identify differences in the test image and the reference image the present teaching provides, in one aspect, a comparison based on colors of the pixels that are in each image. By comparing actual pixel colors as opposed to machine code of each of the colors the present teaching advantageously compensates for variations in how colors may be displayed as part of a rendering process of a web page.

[0012] In another aspect each color of each pixel is treated as a simplified color in a similar fashion to how a human eye recognizes color. By abstracting the color of each of the reference image and the test image it is possible to reduce the possibility of false positives, i.e. the incorrectly identifying dissimilarities between the two images.

[0013] In an aspect of the present teaching an individual webpage is deconstructed into individual functional blocks or elements. By testing individual elements it is possible to provide greater granularity on the effect of execution of active elements which have static and active cases.

[0014] In a further aspect, there is provided a system for regression testing webpage functionality, the system comprising a first datastore storing a benchmark dataset, the benchmark dataset comprising rendered graphical images of at least portion of a webpage in a first functional state and a second functional state, the rendered graphical images being associated with code from a functional block which when emulated effected a rendering of the rendered graphical images. The system additionally comprises a processor which is configured to effect an emulation of the functional block to generate a test dataset, the test dataset comprising captured rendered images of at least portion of the webpage in the first functional state and the second functional state at a second instance in time. By comparing image pixel values from images in each of the benchmark dataset and the test dataset it is possible to identify changes in the rendered graphical image between the benchmark dataset and the test dataset.

[0015] In another aspect there is provided a computer program product comprising executable instructions stored on a computer readable medium which when executed on an electronic device are arranged to perform the above method.

Brief Description of the Drawings

[0016] Various embodiments will now be described, by way of example, with reference to the accompanying drawings, in which: [0017] Figure 1 illustrates schematically a system provided in accordance with the present teaching;

[0018] Figure 2 is an exemplary methodology that can be implemented in accordance with the present teaching;

[0019] Figure 3 is an exemplary methodology that can be implemented in accordance with the present teaching; [0020] Figure 4 is an example of a webpage fragment that may be tested in accordance with the present teaching;

[0021] Figure 5 is an example of a screen shot of a rendered webpage in a first functional state;

[0022] Figure 6 shows a screen shot of the rendered webpage of Figure 5 in a second functional state.

Detailed Description

[0023] Referring now to Figure 1, there is shown a system 100, including a server 110, which is used to test webpages and particular the effect of the underlying code that is used to render a webpage which is displayed, using a browser, on a display of one or more devices 120. One of the one or more devices 120 can be used by a system operator to access functionality of the system 100. It is to be expressly understood that the system 100 is merely one possible implementation of the present technology. Thus, the description thereof that follows is intended to be only a description of illustrative examples of the present technology. This description is not intended to define the scope or set forth the bounds of the present technology. In some cases, what are believed to be helpful examples of modifications to the system may also be set forth below. It will be appreciated that this is done merely as an aid to understanding, and, again, not to define the scope or set forth the bounds of the present technology. These modifications are not an exhaustive list, and, as a person skilled in the art would understand, other modifications are likely possible. Further, where this has not been done (i.e. where no examples of modifications have been set forth), it should not be interpreted that no modifications are possible and/or that what is described is the sole manner of implementing that element of the present technology. As a person skilled in the art would understand, this is likely not the case. In addition it is to be understood that the system may provide in certain instances a simple implementation of the present technology, and that where such is the case they have been presented in this manner as an aid to understanding. As persons skilled in the art would understand, various implementations of the present technology may be of a greater complexity.

[0024] In the context of the present specification, unless expressly provided otherwise, "electronic device" is any computer hardware that is capable of running software appropriate to the relevant task at hand. Thus, some (non-limiting) examples of electronic devices include personal computers (desktops, laptops, netbooks, etc.), smartphones, and tablets and satellite-navigation devices. It should be noted that a device acting as an electronic device in the present context is not precluded from acting as a server to other electronic devices. The use of the expression "an electronic device" does not preclude multiple electronic devices being used in receiving/sending, carrying out or causing to be carried out any task or request, or the consequences of any task or request, or steps of any method described herein.

[0025] The general implementation of the electronic device 120 is known in the art and, as such, will not be described here at much length. Suffice it to say that the electronic device 120 comprises a user input interface (such as a keyboard, a mouse, a touch pad, a touch screen and the like) for receiving user inputs; the above mentioned display (such as a screen, a touch screen, a printer and the like) for providing visual or audible outputs to the user; a network communication interface (such as a modem, a network card and the like) for two- way communication over a communications network; and a processor coupled to the user input interface, the user output interface and the network communication interface, the processor being configured to execute various routines, including those described herein below. To that end the processor may store or have access to computer readable commands which commands, when executed, cause the processor to execute the various routines described herein.

[0026] In the context of the present specification, unless expressly provided otherwise, a "server" is a computer program that is running on appropriate hardware and is capable of receiving requests (e.g. from electronic devices 120) over a network 130, and carrying out those requests, or causing those requests to be carried out. The hardware may be one physical computer or one physical computer system, but neither is required to be the case with respect to the present technology. In the present context, the use of the expression a "server" is not intended to mean that every task (e.g. received instructions or requests) or any particular task will have been received, carried out, or caused to be carried out, by the same server (i.e. the same software and/or hardware); it is intended to mean that any number of software elements or hardware devices may be involved in receiving/sending, carrying out or causing to be carried out any task or request, or the consequences of any task or request; and all of this software and hardware may be one server or multiple servers, both of which are included within the expression "at least one server".

[0027] In the context of the present specification, unless expressly provided otherwise, a "database" is any structured collection of data, irrespective of its particular structure, the database management software, or the computer hardware on which the data is stored, implemented or otherwise rendered available for use. A database may reside on the same hardware as the process that stores or makes use of the information stored in the database or it may reside on separate hardware, such as a dedicated server or plurality of servers.

[0028] In the context of the present specification, unless expressly provided otherwise, the expression "component" is meant to include software (appropriate to a particular hardware context) that is both necessary and sufficient to achieve the specific function(s) being referenced.

[0029] The system 100 implemented per the teaching of Figure 1 is configured to enable a method of regression testing of the appearance of a webpage or pages and the following example of how such a system may be used can be understood with reference to Figure 2. In this aspect the present teaching provides a method that allows testing of fragments of a particular test page in multiple browsers or versions of the same page in the same browser. To provide this testing, a webpage, or a plurality of webpages that collectively define a website, is defined into a plurality of functional blocks which are then stored in a test environment database 140 within the system (Step 200).

[0030] As part of testing functionality of these individual blocks, there is provided a test generation module 150 which provides definition of one or more test suites for each functional block (step 210). Defined test suites may be configured to facilitate testing of each of these functional blocks within one or more of their operational states. For example, it will be appreciated that a search block may have two states; a first state which reflects the visual presentation of the page after the search block is initially loaded and prior to execution of the search, and a second state where data is returned and displayed within the search block. Another example of these functional states is related to drop down menus and an example is shown in Figures 5 and 6. In Figure 5, an example of a displayed webpage 500 is shown from which three distinct drop down menus 510, 520, 530 are evident. Each of these menus is shown in Figure 5 as being in a first functional state-which in this example is not activated. In the example of Figure 6, the same webpage with the same three drop down menus 510, 520 530 is shown, but in this scenario the first drop down menu 510 is in a second functional state where the menu 610 is visible. From this example at least, it will be appreciated that the visual impression formed by rendering the code on a display as perceived by a user will differ depending on which of the two states is implemented.

[0031] Generation of a specific test suite utilises pre-generated test routines or scripts (together referred to as "test routines") that are stored within a test library database 160. These pre-generated test routines or actions can be linked to one another and used to program a series of steps which will be executed against a specific functional block. The series of steps are configured to mimic user interaction with the webpage and bring, in an automated fashion, the functional block to a desired state. For each block of website that is to be tested a specific test suite stored is generated by the test generation module 150. Each test suite provides a testing of one or more states of the functional blocks and verifies their correct performance. To test each state it is necessary to create a functional workflow or action sequence that, when executed against the functional block, processes the block so that its arrives at or progresses through these states. The actions can be chained relative to one another and are desirably configured to run sequentially such that a first action within a test suite is executed and completed prior to initiation of a second action. Examples of actions include:

[0032] click(element) - mouse click at the center of the element.

[0033] doubleClick(element) - mouse double click at the center of the element. [0034] mouseDown(element, [button]) - press a mouse button at the center of the element. Possible button values are: 0 - left, 1 - middle, 2 - right. By default, left button is used.

[0035] mouseUp(element) - release previously pressed mouse button.

[0036] mouseMove(element, [offset]) - move mouse to the given element. Offset is specified relatively to the top left corner of the element. If not specified, mouse will be moved to the center of the element.

[0037] dragAndDrop(element, dragTo) - drag element to other dragTo element.

[0038] executeJS(function( window)) - run specified function in a browser. The argument of a function is the browser's window object. [0039] Any generated test suite will also include a screen capture portion that will effect the capture and storage of a particular portion of a webpage on execution. This screen capture function can also be configured to capture an array of different regions of a webpage and this function can be chained so as to allow multiple captures within the same test suite routine: Example of typical code portions that could be provided within the test library database 160 and used in generation of a test suite which is then stored in the test suite library 150 include: a. setUrl(url) - specifies address of a web page to take screenshots from. URL is relative to rootUrl config field.

b. setCaptureElements('selectorl', 'selector2', ... }) - specifies CSS selectors of the elements that will be used to determine a region of a web page to capture.

[0040] It will be appreciated that to ensure that the correct region of the rendered webpage is captured that the capture region is determined by a minimum bounding area for all of the elements plus their box-shadow size, if appropriate. By providing this capture routine, which will be automatically executed as part of anyone test suite, specific rendered images that are generated as a result of the execution of the code defined by a functional block that is being tested will be captured using one or more capturing screen shots. These screen shots are then linked or otherwise associated with the originating code. By isolating individual portions of the functional code and associating them with individual screen shots for that code portion it is possible to see at a greater level of granularity what is achieved by the code- for example the effect of drop down menus etc. [0041] Having generated a test suite for a particular functional block of code, it is then necessary as part of the test regime to execute that test suite against the particular code to define a reference set of images for that particular functional code portion (Step 220). As discussed above, each of the individual test suites are stored in particular locations within the test suite library 150. The server 110 can be configured to execute a particular test suite or combination of test suites using a command such as a gather command that will implement execution of one or more test suites which are within a particular section of the test suite library-as defined by a particular path. It will be appreciated that as the test suites are already individually personalised or linked to particular functional code blocks that have been defined within the functional code block database 140, that execution of a test suite causes the automatic processing of the code within the defined functional block including a graphical rendering on the webpage of the actions that are to be tested. The resultant visual display that is a result of this execution is then captured per the defined parameters of the test suite. In accordance with the present teaching, once captured, the generated reference set of images are then stored or otherwise associated within the functional code block database (step 230) to define a benchmark dataset. This benchmark dataset stores data indicative of the behaviour of the functional block at a first instance in time. This instance in time can be representative of how a webpage that is rendered by processing the code that defines the webpage functionality, or the portions of the webpage defined by the tested functional blocks, looks in a first browser or can be simply representative of the website look and feel at that date and time.

[0042] While the execution of a test suite can be performed in the background, execution of the test suites can also be configured to provide a user with a graphical overview of the executed code during the processing of an individual test suite. This is useful for a variety of reasons including the fact that it provides a real time demonstration of what is being captured. As will be explained in more detail below, such a graphical overview concurrently displayed during processing of an individual test suite could also be used to provide a real-time demonstration of differences between a reference set of captured images and those images captured during a subsequent execution of the test suite against nominally the same functional block.

[0043] It will be appreciated that forming the test environment database 140 140 and the underlying functional code that was executed to render those images is only a first step in a regression testing methodology. A second step is to compare those references images which are defined in the benchmark dataset against a second set of capture images, a test dataset. Figure 3 provides an overview of an exemplary schema that can be adopted as part of this compare methodology.

[0044] Having already executed the test suite (or suites) against one or more functional blocks within a particular webpage, the present teaching provides a second execution of the same test suite against a functional block that expected to nominally perform in the same fashion as the already tested reference functional block (step 300). Examples of such subsequent testing include the testing of the same functional block in different browser environments or the testing of a modified version of the functional block in the same browser environment as was used in the reference case, or indeed combinations of the two.

[0045] In a similar way to that described with reference to Figure 2, such execution of the test suites effects generated of a set of capture images which are linked to the functionality of the functional block being tested. In a similar fashion to the storage of the reference data for any functional block, these capture images can be stored in a test database 170 (Step 310) and define a test dataset. It will be appreciated that the capture images do not have to be stored permanently, it is sufficient that they are cached in memory to allow a processing of these capture images relative to the corresponding reference images (Step 320).

[0046] It will be understood from the above that the present teaching provides a methodology that facilitates generation of a benchmark dataset comprising a series of reference screen shots for specific blocks of code. This library of reference screen shots can then be used at a later time period to examine how a later iteration of that webpage or the same instance of that webpage in a different browser environment results in a different rendered image. In accordance with an aspect of the present teaching a data file is created as a result of the test process that identifies corresponding images in each of the benchmark dataset and the test dataset and forms a comparison between the two. The comparison is effected using pixel values such as pixel color or pixel intensities and provides an identification of differences between the images in the two datasets. The data file can be stored in the test database 170 (Step 330). This can be done for each state in each browser within which a particular webpage is tested. In another aspect a data file is created as a result of the test process that identifies a reference image within the benchmark dataset, a current image within the test dataset and differences between the two for each time delimited period within which a particular webpage is tested in the same browser.

[0047] By providing analysis at this level of granularity, it is also possible to see how that specific portion of code will affect the overall aesthetic of the webpage. For example in accordance with the present teaching it is possible to test the visual effect caused by a test portion of code against adjacent rendered portions of a webpage that originate from non- changed portions of code. It is also possible to subsequently determine which portions of the originating code were actually tested as opposed to the overall page itself. Such a methodology is particularly advantageous in allowing testing of specific blocks of a webpage and associating with those blocks of code appropriate screen shots which can then be used as reference screen shots.

[0048] As part of the comparison step 320, a system and method in accordance with the present teaching identifies differences in images forming part of the test dataset and the benchmark dataset. In some embodiments of the present technology, the identification of differences can be executed by means of a pixel-by-pixel comparison of the two image sets. In one aspect, this comparison is based on colors of the pixels that are in each image. By comparing actual pixel colors as opposed to machine code of each of the colors the present teaching advantageously compensates for variations in how colors may be displayed as part of a rendering process of a web page. After conducting an image comparison between the two capture images it is possible to automatically generate a report in one of a number of formats including HTML. [0049] In another aspect which does not rely on the actual colors of the pixels that are in each image, each color of each pixel is treated as a simplified color in a similar fashion to how a human eye recognizes color. By abstracting the color of each of the reference image and the test image it is possible to reduce the possibility of false positives, i.e. the incorrectly identifying dissimilarities between the two images. In some embodiments of the present technology, the simplified code color is obtained from more complex, machine-defined colors. For example, it is known to define machine-defined colors in terms of main colors and sub-colors (or hues). These sub-colors are not necessarily perceived by a human eye. Within the embodiments of the present technology, the system 100 maintains a mapping (not depicted) that correlates one or more complex colors not perceivable by a human eye to a single, simplified color perceivable by the human eye. For example, a given mapping can correlate three colors: <red>, <bright red> and <dark red> (or the respective machine-defined terms, such as #ABCD) to <red>. [0050] By analysis the capture images based on an image comparison it is also possible to compensate for rendering artefacts, erroneous text or character inclusion etc. For example an image processing technique, which is one of the techniques that can be used in accordance with the present teaching can be programmed to ignore presence of a cursor in a screen capture of either the reference image or the test image.

[0051] As any one test suite is generated using a test library database 160 of available pre- generated test routines or scripts, and the test suite is generated for a user defined code portion, it is possible for any one test suite to cover multiple functional blocks within the same webpage. In this way it is possible to generate screen captures that illustrate the effect of processing one set of code on another portion of a webpage. Figure 4 shows an example of a web page fragment that is generated as a result of processing two distinct functional code portions, Block A, 400 and Block B, 410. As a system and method per the present teaching allows the capture of multiple capture regions for any one functional block it is possible using the present teaching to recognize a sequence of several blocks with respect to the code of the elements. Each code portion can be associated with respect to each view representation of the code within the web page layout. Furthermore, as the test suite allows the user to define the capture area that is ultimately captured it is possible to define and deduce borders between the blocks within the captured screen shot and makes a determination whether the representation is one of:

a) one block with null state (for example, a button with drop down menu, the button being unselected;

b) two (several) blocks with null state;

c) one block with activated functions (the pressed button with shown drop down menu); d) two buttons, for example, where a drop down menu overlays a second button.

[0052] As part of a regression testing methodology, the present teaching may provide, as outlined above, testing of the same functional code within different browser environments or testing of different versions of the same code in the same browser environment. To provide this functionality the system 100 may interface with third party provided automation tools 180 (see Fig. 1, for example) such as those that are used to automate execution of a web application within a browser environment or simulate the execution of the same webpage in different browsers. Examples of these tools include Selenium- a set of different software tools each with a different approach to supporting test automation which can facilitate testing in different browser environments or PhantomJS which is a headless version of a webkit browser and can be configured to process a functional block and modified versions of that functional block within what is intended to define the same browser environment. While shown as being outside the functional constraints of the system 100, implementations of these automation tools can be installed locally within the system 100 or accesses over a network 130. It will be appreciated that the selection of either of these types of tools can be configured are part of the creation of specific test suites.

[0053] It will be appreciated that the functionality described heretofore has been with reference to testing of specific defined functional blocks of code within a specific webpage or groups of webpages that collectively define a website. As was discussed above, the user definition of a functional block of code, such as CSS code, within a particular webpage can be tested and the generated or rendered webpages associated with that specific can be stored and used in a testing regime. By allowing a webpage to be segmented into constituent functional blocks and then testing the performance of these blocks, the present teaching allows a very detailed assessment of the performance of these blocks within the context of the overall visual aesthetic of the webpage. By defining the capture area independently of the functional block, the present teaching also allows identification of how different blocks can influence the overall display including parts of a webpage that result from a rendering process from another functional block.

[0054] As the system 100 allows a user to segment the webpage into constituent functional blocks, it may also be configured to then report on what portions of a webpage have been tested. As was discussed above, once a test suite for a functional block is created and stored in the test suite library 150, that specific test suite can be executed independently or concurrently with other test suites. If a plurality of executed test suites are related to the same webpage, then the system can be configured to determine which portions of code on the originating webpage have been tested. This can be reported using for example a colour sequence whereby those portions that have been captured by at least one test completely can be marked in a first colour, partially in a second colour or not at all in a third colour. By colour coding using a traffic light sequence; red, orange and green, a particularly effective reporting visual can be generated.

[0055] It will be appreciated that exemplary arrangements of a system and method that facilitates regression testing of a website has been described. Such a system and method exhibits a number of advantages including:

[0056] Compatibility with different browsers;

[0057] Ability to test separate sections of a web page;

[0058] Position and size of a capture element can be defined independently of the underlying code portion and can be calculated in a variety of different ways including for example, its box- shadow and outline properties;

[0059] By analysing on an image basis it is possible to provide selective testing such that some special case differences between images (rendering artifacts, text caret, etc.) can be ignored; [0060] Reporting on the overall test of a webpage and its associated test coverage can be reported on.

[0061] In the context of the present specification, unless expressly provided otherwise, the expression "computer usable information storage medium" is intended to include media of any nature and kind whatsoever, including RAM, ROM, disks (CD-ROMs, DVDs, floppy disks, hard drivers, etc.), USB keys, solid state-drives, tape drives, etc.

[0062] In the context of the present specification, unless expressly provided otherwise, the words "first", "second", "third", etc. have been used as adjectives only for the purpose of allowing for distinction between the nouns that they modify from one another, and not for the purpose of describing any particular relationship between those nouns. Thus, for example, it should be understood that, the use of the terms "first server" and "third server" is not intended to imply any particular order, type, chronology, hierarchy or ranking (for example) of/between the server, nor is their use (by itself) intended imply that any "second server" must necessarily exist in any given situation. Further, as is discussed herein in other contexts, reference to a "first" element and a "second" element does not preclude the two elements from being the same actual real-world element. Thus, for example, in some instances, a "first" server and a "second" server may be the same software and/or hardware, in other cases they may be different software and/or hardware.

[0063] Implementations of the present technology each have at least one of the above - mentioned object and/or aspects, but do not necessarily have all of them. It should be understood that some aspects of the present technology that have resulted from attempting to attain the above-mentioned object may not satisfy this object and/or may satisfy other objects not specifically recited herein. [0064] Additional and/or alternative features, aspects and advantages of implementations of the present technology will become apparent from the following description, the accompanying drawings and the appended claims.

[0065] One skilled in the art will appreciate when the instant description refers to "receiving data" from a user that the electronic device executing receiving of the data from the user may receive an electronic (or other) signal from the user. One skilled in the art will further appreciate that displaying data to the user via a user-graphical interface (such as the screen of the electronic device and the like) may involve transmitting a signal to the user-graphical interface, the signal containing data, which data can be manipulated and at least a portion of the data can be displayed to the user using the user-graphical interface.

[0066] Some of these steps and signal sending-receiving are well known in the art and, as such, have been omitted in certain portions of this description for the sake of simplicity. The signals can be sent-received using optical means (such as an optical connection), electronic means (such as using wired or wireless connection), and mechanical means (such as pressure- based, temperature based or any other suitable physical parameter based).

[0067] Modifications and improvements to the above-described implementations of the present technology may become apparent to those skilled in the art. The foregoing description is intended to be exemplary rather than limiting. The scope of the present technology is therefore intended to be limited solely by the scope of the appended claims.