Patent Description:
Human input devices (HID) such as keyboards and computer mice may be used to provide user inputs to a computing device. For example, a user may type on the keys of a keyboard to activate functions in an application running on the computing device. The HID may send an output signal to the computing device based on the user input performed on the HID. A device driver software of the computing device may translate the output signal into an event in the application, to activate functions in the application. The device driver software may be configured to support more than one type of HID, for example, it may be capable of translating the output signals of several keyboard models and several computer mouse models. Typically, testing the device driver software may include coupling the supported HIDs to the computing device, one device at a time, followed by providing a series of user inputs on the coupled HID, and then observing the events that are activated in the application as a result of each user input.

Prior art <CIT> discloses a system and method for emulating a universal serial bus device (EUP). A test executor computing device may provide specific descriptor information to the EUP device for a particular model. By loading descriptor information including device identifiers into an EUP device's memory, the EUP device is able to complete the enumeration. Prior art <CIT> discloses a method for changing operation of a device, comprising: sending target device descriptors to the device emulator, the device emulator processing the target device descriptors and storing the target device descriptors as the current descriptors in a memory of the device emulator, and the device emulator responding to a query from a host simulating operation of the target device. Prior art <CIT> discloses a test system for verifying the ability of USB devices to provide correct responses to a set of standard device requests. The test system comprises a test application and a test application driver. The test application driver interfaces with USB system software including a USB driver, a host controller driver and USB Framework Support. The USB driver interfaces with the test application through the test application driver. The host controller driver interfaces with the host controller, which in turn interfaces the software on the host system with the USB interconnect and USB devices. The test system incorporates a command line interpreter through which a user can enter commands to perform specific operations and tests. Prior art <CIT> discloses a storage device simulator created on a computing device. The storage device simulator is connected to an operating system of the computing device, wherein the storage device simulator interacts with the operating system without modification of the operating system.

According to an aspect of the present invention a method for testing a device driver software of a processor is provided including the features of claim <NUM>.

According to another aspect of the present invention a testing device is provide including the features of claim <NUM>.

Additional features for advantageous embodiments of the present invention are recited in the dependent claims.

As a further embodiment of the present invention, a non-transient computer-readable medium according to claim <NUM> is provided.

In the following description, various embodiments are described with reference to the following drawings, in which:.

Embodiments described below in context of the devices are analogously valid for the respective methods, and vice versa. Furthermore, it will be understood that the embodiments described below may be combined, for example, a part of one embodiment may be combined with a part of another embodiment.

It will be understood that any property described herein for a specific device may also hold for any device described herein. It will be understood that any property described herein for a specific method may also hold for any method described herein. Furthermore, it will be understood that for any device or method described herein, not necessarily all the components or steps described must be enclosed in the device or method, but only some (but not all) components or steps may be enclosed.

In this context, the device as described in this description may include a memory which is for example used in the processing carried out in the device. A memory used in the embodiments may be a volatile memory, for example a DRAM (Dynamic Random Access Memory) or a non-volatile memory, for example a PROM (Programmable Read Only Memory), an EPROM (Erasable PROM), EEPROM (Electrically Erasable PROM), or a flash memory, e.g., a floating gate memory, a charge trapping memory, an MRAM (Magnetoresistive Random Access Memory) or a PCRAM (Phase Change Random Access Memory).

In an embodiment, a "controller" may be understood as any kind of a logic implementing entity, which may be special purpose circuitry or a processor executing software stored in a memory, firmware, or any combination thereof. Thus, in an embodiment, a "controller" may be a hard-wired logic circuit or a programmable logic circuit such as a programmable processor, e.g. a microprocessor (e.g. a Complex Instruction Set Computer (CISC) processor or a Reduced Instruction Set Computer (RISC) processor). A "controller" may also be a processor executing software, e.g. any kind of computer program, e.g. a computer program using a virtual machine code such as e.g. Java. Any other kind of implementation of the respective functions which will be described in more detail below may also be understood as a "controller" in accordance with an alternative embodiment.

In the specification, the term "comprising" shall be understood to have a broad meaning similar to the term "including" and will be understood to imply the inclusion of a stated integer or step or group of integers or steps but not the exclusion of any other integer or step or group of integers or steps. This definition also applies to variations on the term "comprising" such as "comprise" and "comprises".

The term "coupled" (or "connected") herein may be understood as communicatively coupled, electrically coupled or as mechanically coupled, for example attached or fixed, or just in contact without any fixation, and it will be understood that both direct coupling or indirect coupling (in other words: coupling without direct contact) may be provided.

The reference to any conventional devices in this specification is not, and should not be taken as an acknowledgement or any form of suggestion that the referenced conventional devices form part of the common general knowledge in Australia (or any other country).

In order that the invention may be readily understood and put into practical effect, various embodiments will now be described by way of examples and not limitations, and with reference to the figures.

In the context of various embodiments, the word "processor" may refer to a processor of a computing device, for example, a central processing unit of a personal computer, or to any kind of logic or circuit.

In the context of various embodiments, the phrase "device driver software" may be but is not limited to being interchangeably referred to as a "device driver" or a "driver".

In the context of various embodiments, the word "tester" may refer to a person who is testing a device driver software.

According to various embodiments, a device driver software is configured to translate messages from any processor into messages that are readable by any hardware device that is supported by (in other words: compatible with) the device driver software. The messages may be generated by the operating system of the processor or an application running on the processor. The device driver software may be further configured to translate messages from any compatible hardware device into messages that are readable by the processor. The processor may read the messages using the operating system or an application running on the processor. In other words, the device driver software may serve as a translator between any compatible hardware device and the processor. The device driver software may also be configured to operate under a "key assignment" mode in support of a compatible hardware device that is a human input device (HID). Under the "key assignment" mode, the device driver software may be configured to assign user inputs performable on the compatible HID to respective output signals that are may trigger respective events in an application. For example, the compatible HID may be a keyboard or a computer mouse or the like. The user inputs performable on the keyboard may include the pressing of any key of the keyboard. Each key of the keyboard may be mapped to a respective output signal. The mapping may be controlled by a firmware of the keyboard. For example, under a normal mode of operation, when a key 'A' is pressed, the keyboard may be configured to generate an output signal carrying the message 'A'. The device driver software may receive the output signal from the HID and may instruct an application, for example a typing application, to activate an event of displaying 'A'. Under the "key assignment" mode, the device driver software may be configured to assign the output signal generatable by at least one key of the keyboard to activate an event as if the output signal is generated by another key of the keyboard. A user may define the assignment in the device driver software. For example, the device driver software may be configured to assign the output signal generatable in response to a key 'A', to an event corresponding to the output signal generatable by key 'B. In this example, when a user presses the key 'B' on the keyboard, the device driver software receives the output signal corresponding to the key 'B' and then translates the output signal into an event corresponding to key 'A'. The device driver software may provide the event to an application or the operation system. The device driver software may also be configured to operate under a "macro assignment" mode in support of the compatible HID. Under the "macro assignment" mode, the device driver software may be configured to assign the output signal generatable by a key to activate a sequence of events as if a predetermined sequence of keys is pressed. For example, the device driver software may assign the output signal generatable by key 'A' to the sequence of displaying 'h', 'e', '<NUM>', '<NUM>' and 'o'. In this example, when the user presses key 'A' on the keyboard, the device driver software may activate a sequence of events for displaying 'hello' on the application, as if the user had typed "hello". To manually test the device driver software, for example, functionality of the "key assignment" mode, a tester typically has to assign a key to an event using the device driver software, connect the HID to the processor, press the assigned key and check whether the key is correctly assigned to activate the expected event in an application such as a text input application. The tester may need to test all the keys on a keyboard, when testing the device driver software. Assuming an average key count of <NUM> on one keyboard, on average, the test may spend about one and a half hours on testing the device driver software with respect to one keyboard. Moreover, if the device driver software is configured to support a wide range of keyboards, the amount of time required for testing the device driver software may be multiplied according to the number of supported (in other words: compatible) keyboards. It may be understood that the HID may be any other types of HID such as computer mice, joysticks or game controllers. According, the functions of the device driver software with respect to keys of a keyboard may also be analogously applicable to other user input components of any other types of HID, such as buttons, scroll wheels or joystick handles.

A method for testing a device driver software according to various embodiments, may reduce the time required for testing the device driver software. The method may include emulating a plurality of HIDs. In other words, instead of physically connect the plurality of HIDs sequentially to a processor that is running the device driver software, emulation programs may provide emulated output signals of the plurality of HIDs to the device driver software. The method may also include automating the test procedure using a testing software. In other words, at least one process of assigning a key to an event, pressing the assigned key or checking whether the key is correctly assigned to activate the expected event in an application, may be performed by the testing software. The testing software may be a script or a computer program that may be run on a processor. By emulating the HID and automating the test procedure, the time taken to test the device driver software with respect to a keyboard may be reduced to only about <NUM> minutes. The device driver software may be run on a different processor that is distinct from the processor that runs the testing software. Alternatively, a single processor may run both the device driver software and the testing software.

<FIG> shows a schematic diagram of a test setup <NUM> implementing a method for testing a device driver software <NUM> according to various embodiments. The method may be performed to test the device compatibility of the device driver software <NUM> with respect to a range of HIDs. The test setup <NUM> includes a testing device <NUM>, a control processor <NUM> and a target processor <NUM>. The testing device <NUM> may be a computer peripheral device that is configured to be connectable to any processor. For example, the testing device <NUM> may be a flash disk or a HID like a computer mouse. The testing device <NUM> includes a first device interface <NUM> and further includes a second device interface <NUM>. Each of the control processor <NUM> and the target processor <NUM> may be a computing device, for example a personal computer or a laptop. The control processor <NUM> may include a testing software <NUM>. The control processor <NUM> may be configured to run the testing software <NUM>. The target processor <NUM> includes the device driver software <NUM>. The target processor <NUM> is configured to run the device driver software <NUM>.

The first device interface <NUM> is configured to communicatively couple the testing device <NUM> to the control processor <NUM>. In other words, the testing device <NUM> is configured to at least one of receive data from, or transmit data to the control processor <NUM> through the first device interface <NUM>. The second device interface <NUM> is configured to communicatively couple the testing device <NUM> to the target processor <NUM>. In other words, the testing device <NUM> may be configured to at least one of receive data from or transmit data to the target processor <NUM> through the second device interface <NUM>. At least one of the first device interface <NUM> or the second device interface <NUM> may include a data bus connector, such as a Universal Serial Bus (USB) connector, an IEEE <NUM> connector, a parallel connector, a serial connector or a PS/<NUM> connector. The data bus connector may be a plug, in other words, a male connector. The data bus connector may be configured to couple with a corresponding receptacle, in other words, a corresponding female connector. The control processor <NUM> may include a receptacle that corresponds to the first device interface <NUM>. The target processor <NUM> may include a receptacle that corresponds to the second device interface <NUM>. Each of the first device interface <NUM> and the second device interface <NUM> may further include a communication protocol, for at least one of packaging data that is to transmitted or interpreting data that is received through the data bus connector. At least one of the first device interface <NUM> or the second device interface <NUM> may also include a data carrier connected between the respective data bus connector and a controller of the testing device <NUM>. The data carrier may be a wire such as a cable or a cord. The data carrier may also be a wireless transceiver, for example an infra-red transceiver, a Bluetooth transceiver or a Wi-Fi transceiver.

A tester may use the control processor <NUM> to control the process of testing the device driver software <NUM>. The tester may enter testing parameters into the testing software <NUM> for controlling the testing process. For example, the tester may select a HID model such as the Razer Deathstalker keyboard, in the testing software <NUM>. The testing software <NUM> may provide a device emulation command to the testing device <NUM> through the first device interface <NUM>, based on the tester's selection. The testing device <NUM> may emulate the Razer Deathstalker keyboard in response to the device emulation command. The tester may also select a user input to be emulated on the emulated HID. For example, the test may select "spacebar" in the testing software <NUM>. The testing software <NUM> may provide an input instruction indicative of the "spacebar" being pressed on the emulated HID, such as the Razer Deathstalker keyboard. The testing software <NUM> may provide the input instruction to the testing device <NUM> through the first device interface <NUM>.

According to various embodiments, a single processor may be configured to perform the functions of the control processor <NUM> and the target processor <NUM>. The single processor may include the device driver software <NUM> and the testing software <NUM>. The testing device <NUM> may include only a single device interface which may be one of the first device interface <NUM> or the second device interface <NUM>. The testing device <NUM> may be configured to receive data from, or transmit data to, the single processor through the single device interface.

According to various embodiments, the control processor <NUM> may be a remote server, for example, a server hosted on a computing cloud. The testing device <NUM> may be configured to communicate with the control processor <NUM> through the first device interface <NUM> and further through a network such as the internet or a local area network.

<FIG> shows a schematic diagram <NUM> of the testing device <NUM> according to various embodiments. In addition to the first device interface <NUM> and the second device interface <NUM>, the testing device <NUM> may further include a memory <NUM>. The memory <NUM> may be configured to store data. The memory <NUM> may be a random-access memory such as a non-volatile random-access memory, a dynamic random-access memory or a static random-access memory, or a direct-access memory. The memory <NUM> may be re-programmable. The testing device <NUM> may further include a controller <NUM>. The controller <NUM> may be configured to control at least one of the first device interface <NUM>, the second device interface <NUM> or the memory <NUM>. The memory <NUM> may store an identity field <NUM>. The identity field <NUM> may be a re-writable data field. The identity field <NUM> may be configured to store a device identifier code <NUM>. The identity field <NUM> may be accessed by any computing device, for example the target processor <NUM>. The device identifier code <NUM> may be readable by any computing device, for example the target processor <NUM>. When the testing device <NUM> is connected to the target processor <NUM>, the target processor <NUM> may access the identity field <NUM> to read the device identifier code <NUM>. The device identifier code <NUM> may include information on a particular HID model. For example, the device identifier code <NUM> may include the product identity and vendor identity (PID/VID) of a particular computer mouse model. The target processor <NUM> recognizes the testing device <NUM> based on the device identifier code <NUM>. The testing device <NUM> may be recognized by the target processor <NUM> as being the particular computer mouse model, based on the device identifier code <NUM>. The testing device <NUM> may be configured to receive a device emulation command from the control processor <NUM> through the first device interface <NUM>. The controller <NUM> may be configured to alter the device identifier code <NUM> in the identity field <NUM> based on information in the device emulation command. The memory <NUM> may further store an emulation program <NUM>. The emulation program <NUM> may be configured, when performed by the target processor <NUM>, to emulate a HID corresponding to the device identifier code <NUM>. The emulation program <NUM> may include an emulation <NUM> of the HID identified by the device identifier code <NUM>. For example, the device identifier code <NUM> may indicate the identity of a Razer Black Widow Chroma keyboard. The emulation <NUM> may be an emulation of the Razer Black Widow Chroma keyboard. The emulation program <NUM> may be configured to emulate the behaviour of the identified HID, including how the HID reacts to user inputs. The memory <NUM> may store more emulation programs <NUM>. Each emulation program <NUM> may include an emulation <NUM> of a respective HID. The controller <NUM> may be configured to select one emulation program <NUM> from the plurality of emulation programs <NUM>, that matches the device identifier code <NUM>.

<FIG> shows a flow diagram of one cycle of a device emulation process <NUM> using a testing device according to various embodiments. The device emulation process <NUM> may be part of the method for testing a device driver software of a processor. The device driver software may be the device driver software <NUM>. The device driver software <NUM>
is run on the target processor <NUM>. The testing device may be the testing device <NUM>. As an illustrative, non-limiting example, the flow diagram shows that the testing device <NUM> is a computer mouse. In this example, the first device interface <NUM> and the second device interface <NUM> include USB connectors. The device emulation process <NUM> may include a plurality of sub-processes. In sub-process <NUM>, the testing device <NUM> may be connected to the receptacle of the target processor <NUM> through the second device interface <NUM>. The receptacle may be a USB port that may be coupled to the USB connector. In <NUM>, the testing device <NUM> may be powered up. The testing device <NUM> may receive electrical power from the target processor <NUM> through the second device interface <NUM>. Alternatively, the testing device <NUM> may receive electrical power from a power source such as a battery. In <NUM>, the target processor <NUM>
recognizes the testing device <NUM> and thereby
loads the default firmware of the testing device <NUM>. In other words, the target processor <NUM>
recognizes the true identity of the testing device <NUM> and then
loads a firmware based on the recognized identity. The target processor <NUM> may include an operating system that may be configured to perform the recognition process. In this example, the testing device <NUM> is a computer mouse and therefore, the target processor <NUM> loads the firmware of the computer mouse. In <NUM>, the testing software <NUM> may be launched on the control processor <NUM>. In <NUM>, the testing software <NUM> may configure the identity field <NUM> of the testing device <NUM> to reflect a new identity. The new identity may be a HID. The testing software <NUM> may configure the identity field <NUM> by providing a device emulation command to the testing device <NUM>. The device emulation command may include a device identifier code <NUM> of the HID. In this example, the HID may be a keyboard. The testing software <NUM> may configure the identity field <NUM> by writing to the identity field <NUM> with the device identifier code <NUM>. Alternatively, the testing software <NUM> may configure the identity field <NUM> by selecting one device identifier code <NUM> from a plurality of device identifier codes <NUM> stored in the memory <NUM> of the testing device <NUM>. The device identifier code <NUM> may contain information on the HID. The testing software <NUM> may configure the identity field <NUM> by writing over the existing device identifier code, also referred herein as the default device identifier code, i.e. the device identifier code containing information on the true identity of the testing device <NUM>. In this example, the testing software <NUM> may overwrite the device identifier code of the computer mouse with the device identifier code of the keyboard. Alternatively, the identity field <NUM> may be separate from the data field containing the true device identifier code of the testing device <NUM>.

In <NUM>, the target processor <NUM> may detect a resetting, in other words, restarting or rebooting, of the testing device <NUM>. The target processor <NUM> loads new device firmware corresponding to the new identity of the testing device <NUM>. The testing device <NUM> may be restarted to simulate plugging in a new peripheral device to the receptacle of the target processor <NUM>. After the testing device <NUM> is restarted, the testing device <NUM> may load the new device identifier code that was written into its identity field <NUM> under the process <NUM>. In <NUM>, the target processor <NUM> may enumerate the testing device <NUM> according to its new identity, as if the testing device <NUM> is newly connected to the target processor <NUM>. In other words, the target processor <NUM>
recognizes the new identity of the testing device <NUM>. In <NUM>, a tester or the testing software <NUM> may determine if the new identity as recognized by the target processor <NUM> corresponds to the device emulation command. If the new identity is not correctly recognized by the target processor <NUM>, the tester or the testing software <NUM> may proceed to sub-process <NUM>, to unplug the testing device <NUM>. The tester or the testing software <NUM> may then proceed to sub-process <NUM>, to reset the identity field <NUM> of the testing device <NUM> and then connect the testing device <NUM> back to the receptacle of the target processor <NUM>, thereby returning to sub-process <NUM>. The testing device <NUM>
includes a reset button configured to reset the identity field <NUM> to the true identity of the testing device <NUM>, in other words, load the default device identifier code into the identity field <NUM>. If the new identity is recognized by the target processor <NUM>, the device emulation process <NUM> may end at sub-process <NUM>. The device emulation process <NUM> may be repeated from sub-process <NUM> to emulate more HIDs.

<FIG> shows a flow diagram of an event simulation process <NUM>. The event simulation process <NUM> may be part of the method for testing a device driver software of a processor. In <NUM>, the testing device <NUM> may be configured according to the device emulation process <NUM>. In other words, the process <NUM> may include the entire device emulation process <NUM>. The remaining processes may be performed after the device emulation process <NUM> has been completed. In <NUM>, the testing software <NUM> may send input instructions to the testing device <NUM>. The input instructions
are indicative of events, in other words, inputs that are performable on the HID. If the HID is a computer mouse, the inputs may include a left click, a right click or a rotation of the scroll wheel. In the example of a keyboard, the inputs may include depression of a key such as a spacebar or an "a" letter key, in other words a keystroke. The testing software <NUM> may also load an emulation program <NUM> into the testing device <NUM> based on the device emulation command. Alternatively, the testing device <NUM> may already store a plurality of emulation programs <NUM> and the testing software <NUM> may select one emulation program <NUM> from the plurality of emulation programs <NUM> based on the device emulation command. The loaded emulation program <NUM> or the selected emulation program <NUM> may correspond to the HID defined by the configured identity field <NUM>. In <NUM>, the testing device <NUM> simulates the inputs based on the input instructions sent by the testing software <NUM>. The testing software <NUM> may initiate the emulation program <NUM>. Alternatively, the testing device <NUM> may run the emulation program <NUM> once the emulation program <NUM> is loaded or selected. The emulation program <NUM> simulates the inputs based on the input instructions. The emulation program <NUM> may be configured to emulate an output signal of the HID in response to the inputs. The output signal may also be referred herein as a HID command. In <NUM>, the testing device <NUM> sends the HID commands to the target processor <NUM> through the second device interface <NUM>. In <NUM>, the device driver software <NUM> on the target processor <NUM> receives the output signal from the testing device <NUM>. The device driver software <NUM> may also be referred herein as the system driver. In <NUM>, the device driver software <NUM> translates the output signal and thereby activates an event in an application running on the target processor <NUM> based on the simulated inputs. The application may be a windows application or may be an operating system. In <NUM>, the tester or the testing software <NUM> may determine whether more HID events should be simulated. If yes, the process may revert to sub-process <NUM>, where the testing software <NUM> sends another input instruction to the testing device <NUM>. If no, the process may end at <NUM>.

According to various embodiments, the testing device <NUM> may communicate with a computing device through standard protocols, for example USB protocols. The communication between the computing device and the testing device may be in the direction of host-to-device, in other words, the computing device may send commands to the testing device <NUM> but not vice-versa. The computing device may be any one of the control processor <NUM> or the target processor <NUM>. The standard protocol may dictate that each command include three parts, namely identifier, length and payload. The identifier may be a package header that identifies the command. The payload may be contents directly relating to the instruction contained in the command. The length may indicate the length of the command. The computing device may send a set-USB-descriptor command to the testing device <NUM> for setting the USB descriptor. The payload of the set-USB-descriptor command may include a device descriptor, a configuration descriptor, an interface descriptor, a HID descriptor, an endpoint descriptor and a string descriptor. The device descriptor may include the device identifier code. The computing device may use the set-USB-descriptor command to send a standard USB descriptor byte array to the testing device <NUM>. The computing device may send a set-report-descriptor command to the testing device <NUM> for setting the report descriptor. The report descriptor may specify the quantity of data to transfer to the computing device and how the data is to be interpreted. The payload of the set-report-descriptor command may follow the USB HID standard and may be customized by users. The computing device may use the set-report-descriptor command to send a customized HID report format byte array to the testing device <NUM>. The HID report format byte array may be of a non-standard format. The HID report format byte array may be a rule agreed between the computing device, i.e. the host, and the testing device <NUM>, i.e. the client. Each of the set-USB-descriptor command and the set-report-descriptor command may be sent under process <NUM>. The computing device may send a reset-device command to the testing device <NUM> to reset the testing device <NUM>, in other words, to restart the testing device <NUM>, under process <NUM>. The payload of the reset-device command may be empty. On receiving the reset-device command, the testing device <NUM> may restart and thereby launch the new device descriptor that was sent to the testing device <NUM> under the process <NUM>. The computing device may send a device-event-simulation command to the testing device <NUM> to trigger the testing device <NUM> to simulate the HID events sent by the testing software <NUM>. The device-event-simulation command may include an extra field to indicate an interface identity. The interface identity may contain information on the interface from which the testing device <NUM> will receive the simulation events. The payload of the device-event-simulation command may include a simulation of a HID such as a keyboard or a mouse. The control processor <NUM> may send the set-USB-descriptor command and the set-report-descriptor command to the testing device <NUM> to transfer the device identifier code <NUM> from the control processor <NUM> to the testing device <NUM>, for example in process <NUM> of <FIG>. The control processor <NUM> may send the reset-device command to the testing device <NUM> to , for example in process <NUM> of <FIG> after the new device identifier code is written to the identity field <NUM>. The control processor <NUM> may send the device-event simulation command to the testing device <NUM>, for example in process <NUM> of <FIG>. The device-event simulation command may include input instructions.

<FIG> shows a conceptual diagram of a testing device <NUM> according to various embodiments. The testing device <NUM> may be identical to, or at least substantially similar to, the testing device <NUM>. The testing device <NUM> includes an identity field <NUM>, a first testing device interface <NUM>, a second testing device interface <NUM> and an emulation program <NUM>. The identity field <NUM> may be identical to, or at least substantially similar to, the identity field <NUM>. The identity field <NUM> is accessible by a device driver software of a processor for recognizing the testing device <NUM>. The first testing device interface <NUM> may be identical to, or at least substantially similar to, the first device interface <NUM>. The first testing device interface <NUM> may be configured to receive a device emulation command. The identity field <NUM> may be configurable based on the device emulation command. The emulation program <NUM> may be identical to, or at least substantially similar to, the emulation program <NUM>. The emulation program <NUM> may include an emulation of a HID in accordance with the configured identity field <NUM>. The emulation may be identical to, or at least substantially similar to, the emulation <NUM>. The first testing device interface <NUM> is further configured to receive an input instruction indicative of an input performable on the emulated HID. The emulation program <NUM> is further configured to emulate an output signal generatable by the emulated HID in response to the input being performed on the emulated HID. The second testing device interface <NUM> may be identical to, or at least substantially similar to, the second device interface <NUM>. The second testing device interface <NUM> is configured to output the emulated output signal to the device driver software to translate the emulated output signal to an event in an application program running on the processor. The identity field <NUM>, the first testing device interface <NUM>, the second testing device interface <NUM> and the emulation program <NUM> may be coupled with each other, like indicated by lines <NUM>, for example communicatively coupled or electrically coupled, for example using a line or a cable, and/ or mechanically coupled.

In other words, the testing device <NUM> may be configured to test a device driver software. The device driver software may be running on a processor. The testing device <NUM> includes an identity field <NUM>. The identity field <NUM> is accessible to the device driver software. The device driver software recognizes the testing device <NUM> based on the identity field <NUM>. The identity field <NUM> may be configurable. The testing device <NUM> includes a first testing device interface <NUM> configured to receive a device emulation command. The identity field <NUM> may be configured based on the device emulation command. The configured identity field <NUM> may indicate the testing device <NUM> as a HID, for example a particular model of HID. The testing device <NUM> further includes an emulation program <NUM>. The emulation program <NUM> includes an emulation of the HID in accordance with the configured identity field <NUM>. The HID corresponding to the configured identity field <NUM> may also be referred herein as the emulated HID. The emulated HID may be one of a keyboard, a mouse, a joystick or a game controller. The first testing device interface <NUM> is configured to receive an input instruction. The input instruction indicates an input performable on the emulated HID. The emulation program <NUM> is configured to emulate an output signal that the emulated HID would have generated in response to the input being performed on the emulated HID. In other words, the emulation program <NUM> emulates the behaviour of the emulated HID in response to inputs being performed on the HID. The testing device <NUM> further includes a second testing device interface <NUM>. The second testing device interface <NUM> is configured to output the emulated output signal to the device driver software. At least one of the first testing device interface <NUM> or the second testing device interface <NUM> may be a USB interface.

The first testing device interface <NUM> may be the second testing device interface <NUM>. In other words, the testing device <NUM> may include only a single testing device interface. The device driver software translates the emulated output signal to an event in an application running on the processor.

<FIG> shows a conceptual diagram of a testing device <NUM> according to various embodiments. The testing device <NUM> may be similar to the testing device <NUM> in that it also includes an identity field <NUM>, a first testing device interface <NUM>, a second testing device interface <NUM> and an emulation program <NUM>. In addition, the testing device <NUM> may further include a memory <NUM>. The memory <NUM> may be configured to store a plurality of emulation programs <NUM>. The testing device <NUM> may also include a controller <NUM>. The controller <NUM> may be configured to identify the emulation program <NUM> corresponding to the configured identity field <NUM>, from the plurality of emulation programs <NUM>. In other words, the controller <NUM> may be configured to determine which emulation program <NUM> from the plurality of emulation programs <NUM> matches the configured identity field <NUM>. The identity field <NUM>, the first testing device interface <NUM>, the second testing device interface <NUM>, the emulation program <NUM>, the memory <NUM> and the controller <NUM> may be coupled with each other, like indicated by lines <NUM>, for example communicatively coupled or electrically coupled, for example using a line or a cable, and/ or mechanically coupled.

<FIG> shows a flow diagram <NUM> of a method for testing a device driver software of a processor according to various embodiments. In <NUM>, an identity of a testing device may be configured based on a device emulation command received through a first testing device interface. The device driver software may access the identity field for recognizing the testing device. The process of configuring the identity field may include one of writing a device identifier code into the identity field or selecting one device identifier code from a plurality of device identifier codes stored in the testing device. The device identifier code may include a product identifier and a vendor identifier. The device emulation command may include the device identifier code. In <NUM>, the testing device runs an emulation program. The emulation program may include an emulation of a HID in accordance with the configured identity field. The process of running the emulation program may include at least one of loading the emulation program into the testing device or selecting one emulation program from a plurality of emulation programs stored on the testing device based on the device emulation command. In <NUM>, an input instruction is received in the testing device, via the first testing device interface. The input instruction is indicative of an input performable on the emulated HID. In <NUM>, an output signal is emulated. The emulated HID generates the output signal in response to the input being performed on the emulated HID. In <NUM>, the emulated output signal is output via a second testing device interface, to the device driver software of the processor, to translate the emulated output signal to an event in an application program. The processor runs the application program.

<FIG> shows a flow diagram <NUM> of a method for testing a device driver software of a processor according to various embodiments. The method may be similar to the method shown in the flow diagram <NUM>, but may further include <NUM>, in which a query may be received by the processor via the second testing device interface for accessing the identity field. The method may further include <NUM>, in which data of the identity field may be sent to the processor in response to the query, via the second testing device interface. The method further includes loading a firmware onto the processor. The firmware is associated with the data in the configured identity field.

<FIG> shows a flow diagram <NUM> of a method that may be performed by a processor when the processor executes instructions stored on a non-transient computer-readable medium. The method may include a plurality of processes. In <NUM>, an identity field of a testing device may be configured by sending a device emulation command to the testing device through a first testing device interface. The device driver software reads the identity field for recognizing the testing device. In <NUM>, an emulation program is initiated on the testing device. The emulation program includes an emulation of a HID in accordance with the configured identity field. In <NUM>, an input instruction is sent to the testing device via the first testing device interface. The input instruction indicates an input performable on the emulated HID. The emulation program is configured to emulate an output signal generatable by the emulated HID in response to the input being performed on the emulated HID. The second testing device interface is configured to output the emulated output signal to the device driver software of a further processor to translate the emulated output signal to an event in an application program. The further processor may run the application program.

According to various embodiments, the testing device <NUM> or <NUM> may be configured to simulate any user input on a HID, for example a key press on a keyboard or a right click on a computer. The testing device may be coupled to a computing device that is running an application. The testing software <NUM> may provide an input instruction to the testing device, and the testing device simulates the user input based on the input instruction. The testing device generates an output signal based on the simulated user input. The application on the computing device may receive an event based on the output signal, as if a user is providing the user input on the HID. The simulation of the user input may be performed by the emulation program in the HID. The simulation of the user input may be realistic and may bypass bot-detecting software and anti-virus software, as the output signal is received by the computing device from a physical hardware device, through a device interface. A user may use the testing software <NUM> to predefine user inputs.

Claim 1:
A method for testing a device driver software (<NUM>) of a processor (<NUM>), the method comprising:
providing a testing device (<NUM>) comprising a default device identifier code containing information on a true identity of the testing device written in an identity field (<NUM>) of the testing device;
configuring (<NUM>) the identity field (<NUM>) of the testing device (<NUM>) based on a device emulation command received through a first testing device interface (<NUM>), wherein the identity field (<NUM>) is accessible by the device driver software (<NUM>) for recognising the testing device (<NUM>);
loading a firmware onto the processor (<NUM>), corresponding to the testing device (<NUM>) recognised, the firmware associated with data in the configured identity field (<NUM>);
running (<NUM>) an emulation program (<NUM>) on the testing device (<NUM>), the emulation program (<NUM>) comprising an emulation (<NUM>) of a human input device in accordance with the configured identity field (<NUM>);
receiving (<NUM>) an input instruction in the testing device (<NUM>) via the first testing device interface (<NUM>), the input instruction indicative of an input performable on the emulated human input device;
the emulation program (<NUM>), emulating (<NUM>) an output signal generatable by the emulated human input device in response to the input being performed on the emulated human input device;
outputting (<NUM>) the emulated output signal via a second testing device interface (<NUM>) to the device driver software (<NUM>) of the processor (<NUM>) to translate the emulated output signal to an event in an application program running on the processor (<NUM>); and
loading the default device identifier code into the identity field of the testing device by using a reset button comprised in the testing device.