GB2618082A - A test apparatus and method - Google Patents

Abstract

An apparatus comprising: circuitry configured to obtain a sequence of values from a device output corresponding to a plurality of pixels and apply the values to a linear feedback shift register (LFSR) to determine an identifier; and a controller configured to perform an action in response to the identifier. The output may comprise an image of a workflow (i.e. GUI) and the identifier may identify a position within the workflow. A sequences of values may be obtained from each colour channel of the output. The values may be calculated by comparing the intensity or contrast of the pixels to a threshold. The action may comprise a test, or a command to navigate to a different position within a workflow or an instruction to display or perform optical character recognition (OCR) on an image. The apparatus may obtain the sequence of values by capturing images of the screen of the device under test (DUT) using a camera. The LSFR may comprise 24 bits.

Description

A test apparatus and method

Field of the invention

The present invention relates to a test apparatus and method for testing, for example, modems or apparatus containing modems, audio/visual apparatus and/or other electronic devices.

Background to the invention

Vast numbers of consumer electronics devices, or electronics devices for industry or business are produced every year, and typical households or businesses use significant numbers of electronic devices on a daily basis.

Many electronics devices are provided, for example, as part of a subscription package or on a contractual basis. Service providers often bear responsibility for servicing and replacing such devices. Furthermore, when a contract or subscription package is terminated devices are often returned, potentially for subsequent use by other customers. Also, devices are often reconditioned and sold to or used by other users. These processes require devices to be tested for the presence of faults or to ensure correct operation.

Testing of electronic devices for faults, or to confirm correct operation, can be a high volume, technically sophisticated process, often taking place in a factory setting.

By way of example, in the UK more than a million used set top boxes are tested each year, leaving aside any testing that may take place as part of the manufacturing process. Similarly, there is a wide range of other electronic devices that are subject to testing processes, for example testing processes in factory settings, including modems, routers and a range of communication or networking devices.

Given the volumes of devices being tested, any increase in the speed of testing, even by seconds per device, and avoidance of mis-testing can be significant.

Automated or partially automated testing systems are described in W02011070320, the content of which is hereby incorporated by reference.

Known automated or partially automated testing systems are configured to perform testing processes at particular points in an operational workflow of a device, to test particular funcfionalifies or components. Correct operation of such testing systems can rely on the system being able to navigate the device under test to a desired point in a workflow, for example by automatically issuing a sequence of commands to the device, and/or the system being able to detect correctly at what point in its operational workflow the device is currently at. Any errors, or non-availability, of such automated navigation or detection processes can produce significant delays or non-completion of tests, and can require manual intervention by an operator.

Linear-feedback shift registers (LFSRs) are known and may have an input bit that is a linear function of its previous state. One linear function of single bits that is used is exclusive-or (XOR). Known LFSRs include shift registers whose input bit is driven by the XOR of some bits of the overall shift register value.

It is an aim of the present invention to provide an improved or at least alternative testing apparatus or method.

Summary

In a first, independent aspect there is provided A test apparatus for testing a device, the test apparatus comprising:-a test controller configured to control a test procedure; image data processing circuitry configured to obtain a device output at least one sequence of values corresponding to a plurality of pixels included in or representing the output, wherein the processing circuitry is configured to apply the at least one sequence of values to a linear feedback shift register (LFSR) to determine a corresponding identifier based on the output of the LFSR, and the test controller is configured to perform at least one action in response to the determined identifier.

The output may comprise a window, frame or other image, for example of a graphical user interface (GUI) and/or a workflow.

The pixels may represent a selected part of the window, frame or other image.

The identifier may identify the output and/or a position in a workflow.

The image data processing circuity may be configured to obtain a plurality of sequences of values from the output and to apply the plurality of sequences of values to the LFSR to obtain the identifier.

Each sequence of values may be obtained from a respective one of a red (R) channel, a green (G) channel, a blue (B) channel or other channel.

Each sequence of values may comprise intensity and/or contrast values for the plurality of pixels.

Each sequence of values may be determined based on a comparison of intensity and/or contrast values for the plurality of pixels to at least one threshold.

Each of a plurality of values of the sequence may be determined based on whether the intensity values for a corresponding pixel or pixels are higher or lower than the threshold.

The values may be determined to have a binary value, for example 1 or 0, based on the comparison to the threshold.

The at least one action may comprise a test action or a navigation action.

The navigation action may comprise providing an instruction to the device to move to a different position of a workflow and/or to display a selected frame, screen, window, image or data and/or to provide a different output.

The action may comprise at least one of selecting output resolution, navigating to a network connection page or other page, and/or checking at least one network setting.

The action may comprise outputting and/or storing the identifier and/or an indication that the identifier is correct or incorrect.

The action may comprise determining whether the identifier corresponds to an identifier expected to be obtained from text and/or image(s) that are expected to be present.

The action may comprise using the identifier to perform optical character recognition (OCR).

The image data processing circuity may be configured to obtain the pixels included in or representing the output by capturing image(s).

The test apparatus may comprise or be connected to a camera or other imaging device that is configured to capture the image(s).

The captured images may comprise images of at least part of a screen included in, or associated with, the device under test.

The device under test may comprise at least one of a modem, a set-top box, a Wi-Fi mesh device, an internet-of-things enabled device, and audio and/or visual device, or an electronic device configured to provide a user interface, for example as a video output or web page The test apparatus, or at least the image data processing circuitry, may be in the form of, or comprise, a suitably programmed personal computer (PC) or other programmable computing device.

The test apparatus, or at least the image data processing circuitry. may comprise dedicated circuitry, for example at least one field programmable gate array (FPGA).

The test apparatus may be, at least in part, remote from the device under test, and optionally the test apparatus may obtain the output and/or the pixel values via a network connection.

The test apparatus may be at a test facility and the device under test may be at a user's home, office or other workplace remote from the test facility.

The LFSR may have at least 24 bits.

The image data processing circuitry may be configured to compare the identifier to a plurality of stored identifiers, and the test controller may be configured to perform the at least one action in dependence on the comparison.

In a further aspect, which may be provided independently, there is provided a method comprising obtaining from an electronic device at least one sequence of values corresponding to a plurality of pixels included in or representing an output from the device, applying the at least one sequence of values to a linear feedback shift register (LFSR) to determine an identifier value based on the output of the LFSR, and comparing the identifier value to a stored identifier value, thereby to identify or determine a screen, value(s), character(s) or other feature(s) comprising or forming at least part of the output.

In another aspect; there is provided a computer program product comprising computer readable instructions that are executable to perform a method as claimed or described herein.

There may also be provided an apparatus or method substantially as described herein with reference to the accompanying drawings.

Any feature in one aspect of the invention may be applied to other aspects of the invention, in any appropriate combination. For example, apparatus features may be applied to method features and vice versa.

Detailed description of embodiments

Embodiments of the invention are now described, by way of non-limiting example, and are illustrated in the following figures, in which:-Figure 1 is a schematic illustration of a set top box test system according to an embodiment Figure 2 is a flow chart representing a process according to an embodiment; Figure 2 is a representation of a linear feedback register (LFSR) applied to a red (R), green (G) and blue (B) pixel values of a portion of a screen displayed, as part of a workflow, by a device under test; Figure 3 is a screenshot of a screen output by a device under test; Figure 4 is a schematic illustration of an LFSR process; Figure 5 shows a region of interest of the screenshot of Figure 3; and Figure 6 shows a corresponding portion of a different screen obtained for the region of interest applied in Figure 5.

A test system is illustrated in Figure 1. The test system comprises a test apparatus 4, for example a PC or other computer, that includes dedicated test and control software, connected to a display screen 6 for display of an operator interface. The test apparatus 4 is connected to an interface unit 8 that in turn is connected to a device 10 under test.

The test apparatus 4 is connected to a server 18 via a network. In the example of Figure 1 the test system is installed in a factory for testing devices and the test apparatus 4 is connected to the server 18 via a local area network (LAN) 19 within the factory. The server 18 is connected to the device 10 under test via cable and is operable to stream data to the device 10 via the cable if desired.

In the example of Figure 1, the test apparatus 4, the display screen 6, and the interface unit 8 are installed in a test station unit 20, indicated by the dashed line in Figure 1. In a factory environment many test stations 20 are provided, each testing devices and each receiving data from the server 18 as necessary. In the embodiment of Figure 1, the test station 20 can test two devices 10 simultaneously.

The test apparatus 4 operates under a Windows (RTM) operating system 30 (although any suitable operating system can be used). The test apparatus 4 includes test management software 22 that is operable to control automated testing of the device 10, communication with the server, communication with the device 10 and the interface unit, and processing and analysis of test data.

The test management software 22 is stored in the hard disk or other memory 26 of the test apparatus 4 and can be retrieved and executed in order to perform the device testing.

The test management software includes image processing software 24 that can perform image processing of received data under control of the test management software 22, and a test command module 25 that is operable to communicate with, and access test procedures or data at the device 10 under test.

The image processing software when run on the apparatus 4 provides image data processing circuitry. The apparatus 4 running the test management software provides a test controller configured to control a test procedure. In alternative embodiments, the test controller and the image data processing circuitry may be provided by software, hardware or any suitable combination of software and hardware. The image data processing circuitry may be included in the test controller in some embodiments and/or the image data processing circuitry and the test controller may be provided as a single combined unit or circuitry in some embodiments.

The test management software can use various routes for sending test commands and receiving responses from the set top box, modem or other apparatus under test. For example, the test management software can send test commands and receive responses via a Management Information Base (MIB) module using SNMP calls via a modem of the device 10. Alternatively the test commands and responses can be sent using a serial RS232 port via a 9-way D-type connector, or using a serial RS232 port via a logic translator via a Scart connector, or using a serial RS232 port via a logic translator via a specific test port connector on the device, or by using a combination of RS232 and MIB routes.

The use of test commands provides the test management software with access to a set of commands or manufacturer's internal test procedures on the device under test. The commands and procedures are usually intended to be accessed manually by an operator via a test or engineering screen, but the use of test commands means that such commands and procedures can be accessed automatically by the test management software. The commands can be accessed by sending and receiving messages between the test apparatus 4 and the device 10 via a CMTS 84 at the server (in the case of MIB commands) or directly via cabling linking the test apparatus 4 and the device 10. The device 10 may include an ethernet card 27, which can be used to transmit and receive messages over a network linking the test apparatus 4 and the server 18.

In operation a test command is sent to the device under test from the test apparatus 4. Test commands may comprise or be associated with particular commands or tests within the device 10 under test. For example, GET or SET commands can be used to enable retrieval of data concerning the current state of the device 10 or to set the device 10 to a desired state. Test commands can be used for automatically retrieving data from a diagnostics page of the device 10, collecting data such as signal to noise (SNR) values or upstream/downstream power levels, and obtaining other diagnostic data. The use of test commands can save the operator from having to manually access the engineering menu page on device 10 which can take significant amounts of time.

In the case of MIB test commands, the MIB command uses a unique object identifier (DID) consisting of numbers separated by decimal point, with each number representing a node on the MIB structure. For example, OlDs for telecommunication devices of the company DPS all begin with 1.3.6.1.4.1.2682 and further numbers can be added to the sequence to access particular functions of such devices. Other OID sequences can be used to access functions of other devices, for example devices of other manufacturers. Any additional MIB functionality is at the manufacturer's discretion. A network operator can further implement MIB functionality within their own application code under which the product operates. Access to MIB functionality for testing purposes may, in some circumstances, only be available with the manufacturers or network operator's permission.

The choice of route for sending test commands and receiving responses usually depends on the characteristics of a particular device 10 under test, for example whether or not it includes a modem and the configuration of the device's own internal test procedures.

Any suitable device 10 can be tested in various embodiments. For example, the device may be a modem or any device containing a modem, or a set top box, or router or other telecommunication device. In the embodiment of Figure 1, the device 10 is a set top box that includes a modem.

The test apparatus 4 also includes other dedicated circuitry, or software modules, for use in performing tests. The circuitry included in the test apparatus 4 can vary in different embodiments, depending on the devices it is intended to test. In the embodiment of Figure 1, the test apparatus 4 includes a dedicated High Definition (HD) image acquisition card 40 which is connected to a HDMI output of the device under test (if it is HD enabled), and a TV tuner card 36 that, when connected to the device 10 is operable to tune the device to a desired frequency, to receive and digitise the signal transmitted on that frequency and to store it. The test apparatus 4 includes a standard definition (SD) image acquisition card 32. The SD image acquisition card 32 is operable to receive and capture audio/visual output obtained via the interface unit 8, for further processing by the image processing software 24. Any suitable other circuitries or other functionalities can be provided by the test apparatus 4 and/or by other test apparatus in alternative embodiments, depending on the devices to be tested and the functions that are tested.

The test apparatus 4 is connected to the interface unit 8 via an RS232 cable on a serial port of the test apparatus 4, and in operation can communicate with and send instructions to control operation of the interface unit 8 via the serial port. An Ethernet card is also provided at the test apparatus 4 and can be used to communicate with the server 18 or other devices via the network.

The interface unit 8 includes circuity, in this embodiment suitably programmed Raspberry PI circuity that is configured to capture images from a CSI bridge to HDMI interface, and is able to take screenshots, as PNG files, from the output of a web browser included in the device 10 under test. The interface unit can include various other devices or circuitry, depending on the device 10 that is to be tested and the tests that are to be performed.

For example, in the embodiment of Figure 1, the interface unit 8 includes an IR emulator device controller 50 that can be used to control operation of an IR emulator device (not shown) if used as part of a testing process, a video decoder/encoder and multiplexer 52 for receiving and routing analogue video inputs from device 10, a relay multiplexer 55 for routing analogue audio signals, an AC power switch device 65, for powering the set top box under test, an optical audio receiver unit 56, and an interface control processor 66 for controlling operation of the interface unit 8. The interface control processor 66 is connected to the test apparatus 4, and in operation instructions are provided by the test management software 22 of the test apparatus 4 to the interface control processor 66, which then controls operation of the interface unit 8 in accordance with those instructions.

The system can include further devices or components, which can be controlled by the test apparatus 4, either directly or via the interface unit, for example an IS emulator and/or remote controller, and/or any desired measurement or communication devices.

In other embodiments, functionality provided by the test apparatus 4 and the interface unit 8 can be provided by a single device, or can be split across multiple further devices.

The server 18 comprises a memory 80 (for example an array of hard disks) for storing test content and other data, a processor 82 for controlling operation of the server 18, a cable modem termination system (CMTS) 84, which is DOCSIS 1.1 compliant in this embodiment, and various stream players for streaming content in different formats to the devices 10 under test. The stream players can include a DVB-C stream player 86, a DVB-S/S2 stream player 88, and an I PTV stream player 90. The server 18 may include each of the different stream players, and one or more of the stream players can be selected for use in dependence on the properties of the particular device or other apparatus under test. Alternatively one or more of the stream players may be omitted from the server 18 if not required for a particular testing system. The server 18 also comprises a combiner for multiplexing together signals from the CMTS and one or more of the stream players to form a combined signal, and passing the combined signal to an output of the server for transmission to the devices 10 under test via cable network or other delivery mechanism. Different functionality can be provided by the server 18 depending on the nature of the device 10. For example, testing of certain types of devices may not require streaming of content to the device.

Any suitable device 10 can be tested using the test system. In the embodiment of Figure 1, the device 10 is a set top box with an in-built modem and that includes an HDM I output 34, a UHF output 38 as mentioned above, and also includes a card reader 43, an RJ45 port 44, a VCR Scarf output 45, a TV Scarf output 46, a Component output 47, and an optical audio output 48. The set top box also includes a VCR input (not shown). Various other components (not shown) are included within the set top box to provide the set top box functionality. For example, in the device 10 of Figure 1 a CPU, memory, audio/video processing devices, an M PEG encoder/decoder, and encryption/decryption modules are also included in the device 10 and provide the basic content processing, storage, output and selection functions of the set top box. It will be understood that devices with a wide range of different funcfionalifies are available and that the testing apparatus can be configured or selected to test any suitable devices.

A flowchart illustrating in overview in a testing process performed by the test system of Figure 1 is provided in Figure 2.

The test apparatus 4 displays in a window on display 6 an indication to an operator that it is ready to test a device. In the first stage 100 of the test process, the operator takes the device 10 to be tested and connects cables to link it to the test apparatus 4, the interface unit 8 and the server 18. The operator then uses a barcode reader (not shown) connected to the test apparatus 4 to read a barcode representative of the MAC address of the device 10 under test.

In the next stage 102, the test management software 22 receives and stores the barcode data from the barcode reader, and instructs the interface unit 8 to provide power to the device 10 via the AC power switch device 65 of the interface unit. The test management software 22 then issues test commands (for example MI B calls) to obtain the IP address from the device 10 (the MI B calls in this example are sent over the factory network to the server 18 and then to the device).

At stage 104 the test management software 22 then monitors the booting up of the device 10 and performs further automated tests using embedded self-test routines of the device 10 itself. For example, the test management software monitors the correct operation of the CPU, and DRAM in the device, checking cyclic redundancy codes (CRC) of Flash memory of the device, performing a non-volatile memory (NVM) reset procedure and checking the hardware revision of the set top box, using test routines installed in the device 10 itself. Each of those tests is performed by sending test commands (for example, MI B commands) to the device 10 to perform the test routines, and receiving data representative of the results of the test routines from the device 10, using the SNMP protocol. In each case test commands are used to retrieve from the device 10 the pass or fail status, as represented by an integer value (for example, 0=in progress, 1=pass, 2=fail).

At the next stage 106, the test management software 22 issues commands to the device to navigate it to the next workflow position and/or screen where a test is to be performed.

At stage 108, the test management software 22 uses image processing software 24 to obtain pixel data representing a screen, or part of a screen, output by the device 10 and a comparison to an LFSR identifier is performed to determine that the correct screen is being output and thus, for example, that the device 10 is in the correct state for the next test to be performed. The obtaining of the pixel data and the comparison to the LFSR identifier is described in more detail below.

If it is determined that the pixel data does not match the identifier, then at stage 110 the test apparatus 4 retries the navigation to the next workflow position, or returns to home screen or other previous workflow position and retries navigation, before returning to stage 108, and/or outputs an error message, and/or terminates the test procedure.

Alternatively, If it is determined that the pixel data does match the identifier, indicating that the device 10 is in a correct workflow position for the next test to be performed, then at stage 112 the next test is performed.

The tests in a test sequence provided by the test apparatus 4 may comprise any suitable tests, for example any suitable tests depending on the type of device 10 being tested.

The tests may, for example, comprise automatic tests of video and audio output from various outputs of the device 10 and/or tests of the modem included in the device, for example checking network settings and checking correct functionality of the modem.

Any suitable tests can be used. For example, any suitable tests as described in W02011070320, the content of which is hereby incorporated by reference, may be used.

At stage 114 it is determined whether all tests of the test sequence have been performed. If all tests have not yet been performed then the test management software returns to stage 106, and stages 106, 108, 110/112, 114 are repeated until all test have been repeated.

The test management software then, at the next stage 122, transmits the results of the test to the server 18, displays a pass/fail message to the operator on the display 6, powers down the set top box and instructs the operator at stage 124 to remove the cables from the set top box and remove the set top box from the test station in preparation for the testing of the next set top box.

Any suitable testing procedure, and sequence of stages, can be provided in alternative embodiments. For example, in some embodiments if a negative test result is obtained on a test, or one or more selected tests, at stage 112 then the process progresses directly to stage 122 without completing the sequence of tests.

As mentioned above in relation to stage 108, it is a feature of the embodiment that, as part of the testing procedure, the testing software 24 monitors the screen to which the device 10 has been navigated (for example, by issuance of M I B commands) to ensure that the device 10 is at the correct point in its workflow for a particular test to be performed and/or for particular data to be obtained from the device 10.

It is also a feature of the embodiment that a linear feedback shift register (LFSR) procedure applied to values of pixels of screens output by the device 10 is used to determine whether the screens are correct for the expected point in the device workflow and/or test procedure. Actions, for example navigation or test actions, may be performed automatically in response to the determination of whether a screen is correct or as expected based on the LFSR value.

For a device 10 under test, operation of the device 10 will usually involve output of a series of screens by the device 10 as the device 10 is navigated to different points in its workflow. For example, the device 10 may begin by displaying a home screen and then, as part of the test procedure, the device 10 may be navigated automatically to a settings screen, for example to obtain networks setting values.

In one example, the test management software 22 needs to establish that the device 10 is correctly on the home screen before sending commands, for example, MI B commands or commands using a remote control unit, to move the device 10 automatically to a desired screen for instance a network settings screen, if the test procedure is to work correctly.

A home screen output by a device 10 under test in the embodiment of Figure 1 is shown in Figure 3. Specific details of the broadband user name and device names and address values are blanked out in Figure 3, for privacy.

In the embodiment of Figure 1 LFSR values for screens output by the device 10 and of relevance for the testing procedure are pre-determined and stored, for example in the memory 26.

In the embodiment of Figure 1, the processor 80 of the server 18 determines the LFSR values for relevant screens of the type of device 10, stores the LFSR values in the memory 80 of the server and also distributes the LFSR values for storage in the memory 26 of the test apparatus 4 for use by the test management software 22 and image processing software 24 during the test procedure. For example, LFSR values may be determined and stored for each screen that corresponds to a point in the device workflow for which a test is to be performed (e.g. a home screen, a network settings screen, an EPG screen etc.).

In alternative embodiments, the LFSR values can be determined or processed by any other suitable processor at any location, and/or may be downloaded in real time during or in advance of a particular test procedure if desired.

In the example screen of Figure 3, the LFSR is applied to a selected part, e.g. a region of interest, of the screen 100 rather than to the whole screen. In this example, the region of interest is a rectangular region defined by x = 500, y = 100 co-ordinates for the top left hand corner of the region of interest, and x = 1270, y = 300 for the bottom right hand corner of the region of interest. The selected region of interest is shown in isolation in Figure 5.

For each pixel in the region of interest, red (R), green (G) and blue (B) values are obtained. The R, G and B values may be intensity values, contrast values, a combination of intensity and contrast values or any other suitable values obtained from, for example, the R, G and B channels for the screen image. Other channels could be used in other embodiments, for example opacity values or any other suitable values depending on the image scheme used.

In the present embodiment each R, G and B value is compared to a threshold and is given a binary value, e.g. either 1 or 0, depending on whether the R, G or B value is higher than or lower than the threshold value. Thus, each pixel in the region of interest has an associated value of 1 or 0 corresponding to each of the R, G and B channels.

The red, green and blue values (converted to 1s and Os by comparison with the threshold(s)) for the pixels of the region of interest considered in succession (for example, reading each row of pixels in the region of interest from left to right, then moving to the next row) make up three sequences of values. In other embodiments there is no comparison to threshold(s) and the R, G, B values as read are used for the sequences of values, or a process other than a thresholding process is applied to the R, G, B or other pixel values to obtain the sequences of values.

In the embodiment of Figure 1, the sequence of values (1s or Os in this example) obtained for the R values of the pixels of the region of interest is applied to the LFSR, followed by the sequence of values obtained for the G values of the pixels of the region of interest, then followed by the sequence of values obtained for the B values of the pixels of the region of interest. The output of the LFSR can then be used as an identifier to identify the particular screen to whose pixel values the LFSR was applied.

The LFSR that is used in the embodiment of Figure 1 is a custom XOR linear-feedback register (LFSR) that can be applied to the whole or part of the image pixel data to create a unique code or other identifier as described. This unique code is dependent on the number of pixels and also the value of the pixels' red, blue and green contents.

The initial value of the LFSR can be referred to as the seed, and because the operation of the register is deterministic, the stream of values produced by the register can be completely determined by its current (or previous) state. Likewise, because the register has a finite number of possible states, it must eventually enter a repeating cycle.

However, an LFSR with a well-chosen feedback function can produce a sequence of bits that appears random and has a very long cycle.

The LFSR used in the embodiment of Figure 1 is illustrated schematically in Figure 4, in which the successive input of the sequence of R, G and B-derived values are represented by the three rows in the figure. The LFSR of the embodiment of Figure 1 is 3 x 24 bit LFSR, which covers all combinations of RGB values for a 1080 x 1920 resolution screen. In variants of the embodiment, or alternative embodiments, the size of the LFSR can be increased so that it can be used for a larger area and/or higher resolution screen.

In the example of Figures 3 and 5, the identifier value is 0xf5e2e40b30440b304, obtained by applying the LFSR to the values obtained from the pixels of the region of interest. The value is stored in memory 80 of the serve 18, and also transferred to the test apparatus 4 and stored in memory 26.

The identifier is then used in the test process of Figure 3 to confirm that the device is correctly displaying the home screen. If the expected image is determined to be displayed in the captured area of the home page (x1 = 500, y1 = 100 to x2 = 1270, y2 = 300) using the LFSR algorithm then the message "Login Successful" may be sent to a debug file or other output or file, and a test process may then proceed further. Otherwise, the test is failed.

Considering stage 108 of the testing process in more detail, the test management software 22 controls the suitably programmed Raspberry PI circuity in the interface unit 8 to take screenshots, as PNG files, from the output of a web browser included in the device 10 under test. The image processing software 24 then reads the co-ordinates of the region of interest from memory 26 (or memory 80 or other source) obtains pixel values (e.g. R, G and B values for each pixel) for pixels of the region of interest from the screenshot data (e.g. the PNG file in this case). Any other suitable method of obtaining pixel data can be used in alternative embodiments, using any known image capture or data processing techniques and any suitable hardware and/or software, either from a displayed image or from data that can be used to produce an image.

The image processing circuitry 24 then processes the pixel data and applies the LFSR to the obtained pixel data in the same way as described above in relation to calculation of the stored identifier. The output of the LFSR is then compared to the value of the stored identifier (0xf5e2e40b30440b304 in this example) and if the output value matches the identifier value it is determined that correct screen is being provided and/or the device workflow is at the correct position.

Figure 6 shows the content of the region of interest if an incorrect screen is displayed i.e. not the Home screen of Figure 3 in this example. The LFSR output obtained for the region of interest of Figure 6 would not match the value of the stored identifier (0xf5e2e40b30440b304 in this example) and so it would be determined at stage 108 that the incorrect screen was being output and/or that the device was not at the correct point in the workflow for a desired test to be performed.

In the example, of Figures 3 and 5, once is established that the correct screen is being displayed (e.g. a screen for network settings) the test may comprise determining if a particular setting is selected on screen. A change in then screen can be determined, for instance using the LFSR procedure, if a different option has been selected on screen e.g. using remote control unit.

Any suitable values can be applied to the LFSR, for example derived from the pixel values. For example, R, G, B values and/or contrast values and/or opacity values or combinations of those values, or parameter values derived from those values may be applied to the LFSR. In some embodiments values for a plurality of pixels may be combined, for example by performing an averaging or other mathematical operation on values for the plurality of pixels to obtain values representing a set of pixels (e.g. a sub-region of the screen or of the region of interest) and then the values for each of the sets of pixels (e.g. each of the sub-regions) may applied to the LFSR in turn. Pixel values or values derived from the pixels may be applied to the LFSR in any desired order, and embodiments are not limited to applying the pixel values to the LFSR in a left-to-right, row-by-row order. The region of interest is not limited to being a single region of interest and may comprise multiple non-contiguous regions of interest, at different positions on the screen. Regions of interest may be of any desired shape or size, for example a single pixel, a region By suitable selection of regions of interest, the LFSR procedure may be used for character recognition, for example optical character recognition, in which the stored identifier for a particular region(s) of interest for a particular screen may represent the present of a particular letter(s), number(s) or graphical feature(s) at particular position. The use of the LFSR procedure, comprising the comparison of an LFSR output to a stored identifier, may be used as a test or part of a test in some embodiments, for example to determine that particular letter(s), number(s) or graphical feature(s) are present correctly at selected positions of one or more screen(s). Thus, the LFSR procedure can be used effectively to determine the presence of specified features and/or to read values output by the device under test, if desired.

In certain embodiments, the RGB value is compared with a variable contrast value which is fed back into the LFSR. There are 3 individual contrast values for the RGB value. This allows different background colours and different EPG schemes to be dealt with, for example.

In some embodiments, if a change is made to an option in a menu system or the electronic programme guide (EPG) of the device, for example as part of a test procedure, LFSR codes can be used (e.g. by comparison between the output of an LFSR and a stored identifier) to confirm that the device is on the correct screen (e.g. the correct page) and/or that the correct option has been selected.

The LFSR procedure and identifiers can also be used for optical character recognition (OCR) e.g. checking that expected text is displayed.

LFSR pixel area identification can for example be used when navigating set top box on-screen menus, or other menus, for example when testing devices that do not have a test layer or that have a test layer that is driven via an on-screen display.

The described LFSR techniques can be used also for navigating graphical user interface (GUI), for example a web-based GUI, in a modem test system or other test system.

The testing described in relation to the embodiment of Figure 1 is performed in a factory or other dedicated test facility. In alternative embodiments, the components of the test system are incorporated into a portable test apparatus transported to a user's premises, for example a user's home, and used to test a device in situ. In other embodiments, the system is configured to test remotely a device. For example, the device may be in a location remote from the test apparatus and/or some or all of the components of the test system. For instance, the test device may communicate The embodiment of Figure 1 has been described in relation to the testing of a set top box that included a modem. However, it will be understood that the embodiments or aspects of the embodiments can also be used to test other electronic equipment, for example any electronic device that includes a modem, and/or any suitable audio/visual equipment, for example VCRs, video cameras, personal computers and devices equipped with video processing functionality, for example mobile phones.

Whilst components of the embodiments described herein have been implemented in software, it will be understood that any such components can be implemented in hardware or a combination of hardware. for example in the form of ASICs or FPGAs. Similarly some or all of the hardware components of embodiments described herein may be implemented in software or in a suitable combination of software and hardware.

Alternative embodiments of the invention or aspects of such embodiments can be implemented as a computer program product for use with a computer system, the computer program product being, for example, a series of computer instructions stored on a tangible data recording medium, such as a diskette, CD-ROM, ROM, or fixed disk, or embodied in a computer data signal, the signal being transmitted over a tangible medium or a wireless medium, for example, microwave or infrared. The series of computer instructions can constitute all or part of the functionality described above, and can also be stored in any memory device, volatile or non-volatile, such as semiconductor, magnetic, optical or other memory device.

It will be understood that the present invention has been described above purely by way of example, and modifications of detail can be made within the scope of the invention. Each feature disclosed in the description, and (where appropriate) the claims and drawings may be provided independently or in any appropriate combination.

Claims (28)

1. CLAIMS1. A test apparatus for testing a device, the test apparatus comprising:-a test controller configured to control a test procedure; image data processing circuitry configured to obtain from a device output at least one sequence of values corresponding to a plurality of pixels included in or representing the output, wherein the processing circuitry is configured to apply the at least one sequence of values to a linear feedback shift register (LFSR) to determine a corresponding identifier based on the output of the LFSR, and the test controller is configured to perform at least one action in response to the determined identifier.
2. 2. An apparatus according to claim 1, wherein the output comprises a window, frame or other image, for example of a graphical user interface (GUI) and/or a workflow.
3. 3. An apparatus according to claim 2, wherein the pixels represent a selected part of the window, frame or other image.
4. 4. An apparatus according to any preceding claim, wherein the identifier identifies the output and/or a position in a workflow.
5. 5. An apparatus according to any preceding claim, wherein the image data processing circuity is configured to obtain a plurality of sequences of values from the output and to apply the plurality of sequences of values to the LFSR to obtain the identifier.
6. 6. An apparatus according to claim 5, wherein each sequence of values is obtained from a respective one of a red (R) channel, a green (G) channel, a blue (B) channel or other channel.
7. 7. An apparatus according to any preceding claim, wherein each sequence of values comprises intensity and/or contrast values for the plurality of pixels.
8. 8. An apparatus according to any preceding claim, wherein each sequence of values is determined based on a comparison of intensity and/or contrast values for the plurality of pixels to at least one threshold.
9. 9. An apparatus according to claim 8, wherein each of a plurality of values of the sequence is determined based on whether the intensity values for a corresponding pixel or pixels are higher or lower than the threshold.
10. 10. An apparatus according to claim 9, wherein the values are determined to have a binary value, for example 1 or 0, based on the comparison to the threshold.
11. 11. An apparatus according to any preceding claim, wherein the at least one action comprises a test action or a navigation action.
12. 12. An apparatus according to claim 11, wherein the navigation action comprises providing an instruction to the device to move to a different position of a workflow and/or to display a selected frame, screen, window, image or data and/or to provide a different output.
13. 13. An apparatus according to any preceding claim, wherein the action comprises at least one of selecting output resolution, navigating to a network connection page or other page, and/or checking at least one network setting.
14. 14. An apparatus according to any preceding claim, wherein the action comprises outputting and/or storing the identifier and/or an indication that the identifier is correct or incorrect.
15. 15. An apparatus according to any preceding claim, wherein the action comprises determining whether the identifier corresponds to an identifier expected to be obtained from text and/or image(s) that are expected to be present.
16. 16. An apparatus according to any preceding claim, wherein the action comprises using the identifier to perform optical character recognition (OCR).
17. 17. An apparatus according to any preceding claim, wherein the image data processing circuity is configured to obtain the pixels included in or representing the output by capturing image(s).
18. 18. An apparatus according to claim 17, wherein the test apparatus comprises or is connected to a camera or other imaging device that is configured to capture the image(s).
19. 19. An apparatus according to claim 17 or 18, wherein the captured images are images of at least part of a screen included in, or associated with, the device under test.
20. 20. An apparatus according to any preceding claim, wherein the device under test comprises at least one of a modem, a set-top box, a VVi-Fi mesh device, an internet-ofthings enabled device, and audio and/or visual device, or an electronic device configured to provide a user interface, for example as a video output or web page
21. 21. An apparatus according to any preceding claim, wherein the test apparatus, or at least the image data processing circuitry, is in the form of, or comprises, a suitably programmed personal computer (PC) or other programmable computing device.
22. 22. An apparatus according to any of claims 1 to 20, wherein the test apparatus, or at least the image data processing circuitry, comprises dedicated circuitry, for example at least one field programmable gate array (FPGA).
23. 23. An apparatus according to any preceding claim, wherein the test apparatus is, at least in part, remote from the device under test, and optionally the test apparatus obtains the output and/or the pixel values via a network connection.
24. 24. An apparatus according to any preceding claim, wherein the test apparatus is at a test facility and the device under test is at a user's home, office or other workplace remote from the test facility.
25. 25. An apparatus according to any preceding claim, wherein the LFSR has at least 24 bits.
26. 26. An apparatus according to any preceding claim, wherein the image data processing circuitry is configured to compare the identifier to a plurality of stored identifiers, and the test controller is configured to perform the at least one action in dependence on the comparison.
27. 27. A method comprising obtaining from an electronic device at least one sequence of values corresponding to a plurality of pixels included in or representing an output from the device, applying the at least one sequence of values to a linear feedback shift register (LFSR) to determine an identifier value based on the output of the LFSR, and comparing the identifier value to a stored identifier value, thereby to identify or determine a screen, value(s), character(s) or other feature(s) comprising or forming at least part of the output.
28. 28. A computer program product comprising computer readable instructions that are executable to perform a method according to claim 27.