HK1192960B - Robotic device tester - Google Patents

Description

Automatic machine device tester

Cross-reference to related applications

This application claims priority to U.S. Provisional Patent Application No. 61/046,355, entitled “Robotic Device Tester,” filed on April 18, 2008, and U.S. Non-Provisional Patent Application No. 12/239,271, entitled “Robotic Device Tester,” filed on September 26, 2008, each of which is incorporated herein by reference in its entirety.

Background Art

Devices, and in particular handheld communication devices such as mobile phones, are frequently manufactured and upgraded. Each such device requires testing of the device's hardware, software, and communication functionality during and after the device's development and design, and prior to mass production and distribution of the new device or new software for operation on new or legacy devices.

Conventional test systems expose and access the internal interfaces of the device under test to simulate the device's operation according to a pre-defined test sequence that has been input. However, this operation of the device under test is inadequate because it does not accurately reflect how the device will ultimately be used, i.e., by pressing buttons or actuating other input hardware such as scroll bars, wheels, or joysticks. Furthermore, in the event of a failure, if the failure occurs during a long, unattended test run, it may be difficult for an operator to determine the exact failure or its cause, for example, for troubleshooting purposes. Furthermore, with respect to communications, testing is incomplete because the results of communications at the receiving device to which communications are transmitted during testing are unknown, and because the device under test's reception of communications from another device is not tested.

Other conventional test systems provide a robotic arm for performing button presses to simulate the use of the device under test. Cameras can capture screenshots or short videos of the device under test during the test sequence, which can aid in troubleshooting. However, even these systems are insufficient because, when receiving communications from another device, they do not allow the results at the other receiving device to be determined, and they cannot test the functionality of the device under test.

Furthermore, conventional test systems require tedious and detailed configuration and calibration for each different device under test. This situation is further exacerbated when a first device under test is removed from the test system, for example, to repair a minor malfunction, and then returned to the test system after testing a second device under test for which the test system was configured following the initial testing of the first device under test. This scenario would require the test system to be configured a second time for the second test of the first device under test.

Summary of the Invention

Embodiments of the present invention provide a device, system, and method that overcome each of the drawbacks described above with respect to conventional device testing systems. Embodiments of the present invention can be applied to both hardware and software stress testing. A device testing system may include a robotic arm for operating a device under test and may include an arrangement for operating a second, non-tested device that communicates with the device under test, including transmitting a message or initiating a call to the device under test. A first camera may be provided to record a snapshot of a display screen of the device under test, and a second camera may be provided to capture a video of the device under test and the second, non-tested device as a whole, both within the second camera's field of view.

The above functionality may be the primary utilization of the first and second cameras. However, in alternative exemplary embodiments, both cameras capture snapshots, both cameras capture video, or both cameras capture both snapshots and video. In yet another alternative exemplary embodiment, the first camera captures video and the second camera captures snapshots.

A wizard can be included to facilitate rapid configuration of the test system for each device under test. The wizard can reference a previously stored set of input test scenarios to apply to various devices under test. The wizard can further reference configuration files associated with previously tested devices to create new associations of some or all files with the new device under test. The new files associated with the new device under test can be further modified to customize them for the characteristics of the new device under test.

The configuration of the test system can include recording three-dimensional coordinates for each or one or more buttons or other input devices of the device under test, such as a joystick, trackball, thumbwheel, switch, etc. Two of the coordinates can represent the two-dimensional position of the input device on the plane of the device under test. The third coordinate can represent the position to which the input device is to be moved, for example, in a direction perpendicular to the two-dimensional plane, so that the device under test registers the actuation of the input device and does so without over-extending the input device or the plane of the device under test, for example, by too aggressive a button press. With respect to the input device of the device under test for which the three-dimensional coordinates are to be recorded, after inputting the coordinates representing the two-dimensional plane, the device testing system can automatically determine and record the coordinates of the third dimension based on the signals obtained from the force sensor during the movement of the robot arm in a direction perpendicular to the input plane.

The device testing system may include a single main workstation in which test configuration and subsequent testing will be performed. The device testing system may also include a second workstation having a lower complexity than the main workstation, for example by omitting some software and/or hardware, such as omitting a robotic arm. According to this embodiment, some configuration of the device testing system for testing the device under test can be performed using the second, less complex workstation. This can be advantageous because it can provide flexibility, for example, to allow a group of operators to collaborate to perform configuration, each operator at a separate location, such as at the operator's own desk or at home, rather than at the main testing location where the main workstation is located. It may be required to use the main workstation to perform some configuration steps. After configuration, the device under test can be transferred to the main workstation for testing according to the configuration, and part of the configuration may have been performed at the auxiliary location.

According to an exemplary embodiment of the present invention, a unique code can be stored for each tested device for which the device testing system is configured. The code can be associated with a configuration file that will be used for the test of the tested device. At any time, the device testing system can be reconfigured for a previously tested device by code input. In addition, in order to allow rapid reconfiguration without any user input, each code can be encoded in a barcode format. Each tested device or fixture to which the device is attached for device testing can be marked with a barcode. At the beginning of a test sequence, a camera of the test device can capture an image of the tested device and/or fixture, match the barcode with a barcode stored in the test system, for example, in a database or other file structure, such as a directory tree of phone configurations, and automatically load the configuration associated with the imaged barcode.

According to an exemplary embodiment of the present invention, a device mount includes an attachment plate having: a central aperture extending therethrough; and corresponding lips on each of at least two sides of the central aperture, at least a portion of the lips extending along at least a portion of the aperture on at least two sides of the aperture. The device mount further includes a base having a wide base and a narrow base above the wide base, the base being slidably coupled to the attachment plate, the wide base extending below the at least two lips and the narrow base extending between the at least two lips. The device mount further includes a first vertical plate extending upward from a surface of the narrow base parallel to a surface of the attachment plate through which two elongated apertures and the central aperture extend, the first vertical plate having at least two apertures extending from the surface of the first vertical plate and in a direction perpendicular to the direction in which the first vertical plate extends from the narrow base. The device fixture further includes a second vertical plate having: a curved hole extending therethrough and capable of being slidably coupled to the first vertical plate via at least two holes coupled to at least two fasteners extending through the curved hole; and a structure having a certain shape and extending from a surface of the second vertical plate that is parallel to a surface of the narrow base from which the first vertical plate extends when the second vertical plate is coupled to the first vertical plate. The device fixture further includes a mounting plate having: a first hole having a shape corresponding to the shape of the structure of the second vertical plate, the structure of the second vertical plate being capable of being slidably received in the first hole of the mounting plate to couple the second vertical plate to the mounting plate; and at least one second hole extending from a surface of the mounting plate perpendicular to the surface of the narrow base from which the first vertical plate extends and the first hole when the mounting plate is coupled to the second vertical plate and the second vertical plate is coupled to the first vertical plate, the coupling of the mounting plate to the second vertical plate being by inserting at least one fastener in a fastenable manner into the structure of the second vertical plate extending through the first hole through the at least one second hole.

In an exemplary embodiment, the device fixture further includes a base plate having a plurality of holes extending from a surface of the base plate, wherein the attachment plate has two elongated holes extending through the attachment plate, each elongated hole being at a respective one of two opposite sides of the attachment plate, an intermediate hole extending between the two elongated holes, and wherein the attachment plate is capable of being coupled via two of the plurality of holes coupled to two corresponding fasteners extending through a respective one of the two elongated holes in a direction perpendicular to the surface of the narrow base from which the first vertical plate extends.

In an exemplary embodiment of the device mount, the structure is in the shape of an elongated T.

In a still further variation of the immediately preceding exemplary embodiment, the at least one second hole includes three holes.

In an exemplary embodiment, the device fixture further includes an adhesive on a surface of the mounting plate that is perpendicular to the surface of the mounting plate from which the at least one second hole extends and parallel to the surface of the narrow base of the first vertical plate from which it extends when the mounting plate is coupled to the second vertical plate and the second vertical plate is coupled to the first vertical plate.

BRIEF DESCRIPTION OF THE DRAWINGS

1a and 1b are diagrams illustrating components of a system according to an exemplary embodiment of the present invention.

FIG. 2 is a diagram illustrating a robot arm and a plate according to an exemplary embodiment of the present invention.

3 and 4 illustrate exemplary embodiments of the present invention in which a device under test and a companion device may be placed in close proximity during testing.

FIG. 5 illustrates components and a barcode of a device fixture base plate according to an exemplary embodiment of the present invention.

FIG. 6 shows components of an automatic machine according to an exemplary embodiment of the present invention.

FIG. 7 illustrates components of a disassembled device fixture, according to an exemplary embodiment of the present invention.

FIG. 8 shows the device fixture of FIG. 7 in its assembled state according to an exemplary embodiment of the present invention.

FIG. 9 illustrates a brace that may be used to prevent twisting of a device under test, according to an exemplary embodiment of the present invention.

FIG. 10 is a diagram illustrating a micro workstation according to an exemplary embodiment of the present invention.

FIG. 11 is a screenshot illustrating an exemplary file structure for a configuration file according to an exemplary embodiment of the present invention.

12 is a cross-functional flow diagram illustrating a method according to which a device may be tested, including generating a configuration file and performing tests, according to an exemplary embodiment of the present invention.

FIG. 13 is a flow chart illustrating a method of generating a local configuration file, for example, at a micro workstation, according to an exemplary embodiment of the present invention.

FIG. 14 is a flowchart illustrating a method of completing a configuration file according to an exemplary embodiment of the present invention.

DETAILED DESCRIPTION

FIG1a shows a device testing system 1 according to an example of the present invention. The device testing system 1 may include a compartment 100 that may house a robot 102, a platform 104, a user terminal 105, a light fixture 110, and a camera arrangement 111. The robot 102 may include an arm 103 to manipulate a device under test 115. As used herein, the term device under test does not necessarily mean that the device is currently undergoing testing, but rather means that the device is a component for which the system 1 can be configured to perform testing. However, in certain contexts, the device under test 115 may be described as undergoing testing.

During configuration of the device testing system 1 and/or testing of the device under test 115 , the compartment 100 may be fully enclosed so that lighting may be controlled at optimal levels during various stages of configuration and/or testing.

The platform 104 may include attachment points for attaching a device fixture 114, to which a device under test may be securely mounted, for example, via an adhesive, on the device fixture 114. The platform 104 may, for example, include recesses into which pins extending from the bottom surface of the device fixture 114 may be inserted to ensure that the device fixture 114 is placed in the same position relative to the robot 102 each time the device fixture 114 is placed to test a mounted device under test 115.

During configuration and/or testing, the device under test 115 may be positioned relative to the device testing system such that the plane of the device under test 115, including the display screen, is perpendicular to the direction along which the arm 103 extends toward the platform 104 to operate the device under test 115. When a portion of the device under test 115, including a majority of user-operable input devices, such as a keyboard, is, for example, hingedly coupled to a portion including the display screen, such that in an open position of the device under test 115, the keyboard portion is disposed at an angle of less than or greater than 180° relative to the display screen portion, it may be necessary for the arm 103 to extend in a direction perpendicular to the plane of the platform 104 to substantially different positions to operate different buttons of the device under test 115.

2 , the arm 103 can be attached to the body of the robot 102 such that the arm 103 is laterally displaced from the vertical axis of the body of the robot 102. This displacement can provide the cameras of the camera arrangement 111 with a better view of the device under test 115 during configuration and/or testing.

As shown in FIG1b , camera arrangement 111 may include a first camera 113 and a second camera 112. In an exemplary embodiment of the present invention, second camera 112 is tilted such that the axis extending perpendicularly through its lens extends at a non-perpendicular angle toward platform 104, and may be positioned such that its field of view encompasses the entire device under test 115. The display screen of device under test 115 may be displaced laterally from the axis extending perpendicularly through the lens of second camera 112 toward platform 104. Furthermore, portion 115a of device under test 115 including the display screen may be at an angle relative to the axis extending through the lens of second camera 112, where the angle is not 90°.

In an exemplary embodiment of the present invention, first camera 113 is positioned such that its lens is approximately parallel to platform 104 and, therefore, approximately parallel to the surface of the display screen of device under test 115. Furthermore, camera 113 and device mount 114 can be positioned relative to each other such that an axis extending perpendicularly through the lens of camera 113 passes approximately perpendicularly through the display screen of device under test 115, e.g., through the center of the display screen. The display screen of device under test 115 can thus be better focused and viewed at a higher resolution by first camera 113 than by second camera 112. Thus, while second camera 112 can record an image of the entire device under test 115, e.g., a moving image, first camera 113 can record an image in which the display screen is more clearly depicted, allowing the image of the display screen to be processed using image recognition software, including, for example, optical character recognition (OCR). In an exemplary embodiment, the zoom setting of first camera 113 can be such that the display screen fully or nearly fully encompasses the field of view of first camera 113.

The device mount 114 can be configured to allow a device under test 115 and, as shown in the two exemplary embodiments of Figures 3 and 4 , a companion device 116 (which can itself assume the role of a device under test and be tested during different testing operations of the system 1) to be mounted thereon. The camera 112 can be arranged and the camera 112 settings can be configured so that the device under test 115 and the companion device 116 can be within the field of view of the camera 112, so that the recorded image produced by the camera 112 can be of both the device under test 115 and the companion device 116 simultaneously.

User terminal 105 may include a processor 106, memory 107, a display 108, and an input device 109. Processor 106 may include any suitable conventional processing circuitry implemented in any conventional form, such as a central processing unit (CPU) of a personal computer (PC). Memory 107 may include any suitable conventional memory device, such as random access memory (RAM), read-only memory (ROM), a hard disk, magnetic tape, a compact disc (CD), a flash-based device, and/or a digital versatile disc (DVD). Memory 107 may include program instructions executable by processor 106 to perform the various functions described herein for configuring and operating system 1 and for operating pairing device 116 in the various exemplary manners described herein.

In an exemplary embodiment of the present invention, the processing circuitry may include a robot controller PC and a test execution PC (TEPC), where both PCs are connected to an Ethernet switch in the station and communicate via a local network. The TEPC sends button presses and other commands to the robot controller PC, which has software running on it to listen and act on the commands. The display and input devices are common to the TEPC and robot controller PC, which are connected using a KVM switch.

The device under test 115 and the pairing device 116 can each be a communication device, such as a mobile phone. The processor 106 can be connected to the pairing device 116, for example, via a communication/control interface of the pairing device 116, such as a serial interface. In an exemplary embodiment, the pairing device is connected to a TEPC. During testing of the device under test 115, the processor 106, such as the TEPC, executing pairing device instructions 120 in the memory 107, for example, a portion of the instructions 120 residing in a portion of the memory 107 accessible by the TEPC processor, can input commands to the pairing device 116 via the serial interface of the pairing device 116. The commands can simulate the operation of the input hardware of the pairing device 116, causing the pairing device 116 to transmit communications to the device under test 115.

In an exemplary embodiment of the present invention, processor 106 (e.g., TEPC) may also intercept data from pairing device 116 that is used to generate a display on a display screen of pairing device 116. Here, during testing of device under test 115, device under test 115 is operated to transmit communications to pairing device 116. Processor 106 (e.g., TEPC) may analyze the data intercepted from pairing device 116 to determine whether the expected results regarding communications from device under test 115 were achieved by comparing the intercepted data with expected data stored in memory 107 (e.g., TEPC memory). If the results were not as expected, processor 106 may determine that an error has occurred. Similarly, if, during a portion of the testing of device under test 115, device under test 115 will not communicate with pairing device 116, processor 106 (e.g., TEPC) may determine that an error has occurred in which unexpected data was intercepted from pairing device 116.

In an exemplary embodiment of the present invention, a processor 106, such as a TEPC, may be coupled to cameras 112 and 113. Processor 106, such as a TEPC, may receive an image sensed by a sensor of camera 113, which captures light passing through the lens of camera 113. Processor 106, such as a TEPC, may execute image processing software 121 to compare the image received from camera 113 with an image in a collection of display screen images 122, such as stored in the TEPC's memory, to determine whether the image received from camera 113 matches an image in collection 122, such as stored in the TEPC's memory. For each image in collection 122, such as stored in the TEPC's memory, collection 122 may identify the specific, corresponding operation(s) of device under test 115 with which the image is associated. For each such identified operation(s), when the identified operation(s) are performed by robot 102, processor 106, such as a TEPC, may compare the image captured by camera 112 immediately after the operation(s) are performed with the image associated with the performed operation(s).

While camera 113 is providing images to user terminal 105, camera 112 may also be providing images to user terminal 105. The images provided by camera 112 may be moving images, i.e., movies. The moving images may be stored in a buffer, such as in memory 107 of a TEPC. In response to processor 106, such as a TEPC, determining that an error has occurred, processor 106, such as a TEPC, may transfer the plurality of images in the buffer to a permanent memory location where the images can be played as a movie, such as on display 108. In an exemplary embodiment of the present invention, the transferred images are those covering a period that begins shortly before the error occurs and ends shortly after the error occurs.

In an exemplary embodiment of the present invention, the buffer may be configured as a first-in, first-out (FIFO) memory and store only a small number of images. Once full, for each newly received image, all images in the FIFO received before any other images in the FIFO are deleted, and the newly received image is written to the FIFO. In an exemplary embodiment, upon detection of an error, all images in the FIFO, or images captured in video form, may be transferred to permanent storage. Alternatively, the number of images transferred to the temporary storage may be based on a predetermined number or predetermined time interval used to configure the processor 106, such as the TEPC. Note that, for example, if the frame capture rate of the camera 112 changes, the number of recorded image frames representing the time interval may change. Alternatively, all images may be captured and saved to a file on a local disk. Upon detection of an error, multiple images may be stored in separate memory locations to facilitate error monitoring. In yet another alternative embodiment, all images are stored in a temporary file that is deleted if no errors occur and permanently stored if an error is detected. By adjusting the permanent storage of images upon error detection as described with respect to these embodiments, the required memory capacity can be reduced because, for example, the full length of each play from start to finish is not stored.

In an exemplary embodiment of the present invention, memory 107, for example, on a TEPC, may include a configuration file database 123 containing a corresponding configuration file or folder for each device under test 115 configured for that device. In an exemplary embodiment of the present invention, some of the test devices 115 are very similar, such that the configuration of the system 1 is identical with respect to the operations to be performed during device testing and the location of the input hardware manipulated by the robot 102 during testing. These similar test devices 115 may share the same configuration file or folder. In an alternative exemplary embodiment, regardless of feature similarity, no two test devices, such as phones, share the same configuration file; rather, each has a unique configuration file/folder structure. A unique code may be generated by the processor 106 for each different configuration file or folder. Alternatively, a separate PC outside the robot station may generate and/or print the code. The code may be, for example, encoded as a barcode. In an exemplary embodiment of the present invention, the code, such as a barcode, may be placed on the device under test 115 or on the device fixture 114. For example, FIG5 shows a barcode 500 positioned on device fixture 114 proximate to device under test 115 relative to an axis extending perpendicularly through the lens of camera 112 such that barcode 500 is in the field of view of camera 112 when device fixture 114 is mounted on platform 104 in a testing position.

When initializing the system 1 to perform a test, the processor 106, e.g., a TEPC, can operate the camera 112 to obtain an image. The processor 106, e.g., a TEPC, executing image processing software 121 stored, e.g., on the TEPC, can detect the barcode 500 in the obtained image, process the barcode 500 to determine its underlying code, compare the underlying code to a set of codes stored in the memory 107, select a configuration file or folder associated with the code, and begin operating the robot 102 according to the configuration parameters included in the configuration file or folder to perform the test sequence outlined in the configuration file or folder.

If no barcode is detected, processor 106, such as a TEPC, may cause display 108 to output an error message, a message requesting the user to manually enter a code via input device 109, or a message requesting the user to initiate a process for generating a new configuration file or folder, depending on various exemplary embodiments. In an exemplary embodiment of the present invention, processor 106, such as a TEPC, may cause an error message to be displayed indicating that no barcode is included (or that the included barcode is unrecognized) and requesting input indicating whether a configuration file that can be used for the installed device under test 115 exists. If the user indicates that a configuration file exists, the user may be prompted to enter a code. If the user indicates that a configuration file does not yet exist, the user may be prompted to initiate a process for generating a configuration file or folder.

In an alternative exemplary embodiment, the user is prompted to create a configuration file or folder only if: (a) no barcode is found; or (b) a barcode is found and no configuration data exists for the phone. The user is not prompted as to whether a configuration file exists because this is determined programmatically.

In an exemplary embodiment of the present invention, light fixture 110 may include, for example, light-emitting diodes (LEDs), for example, two LEDs. In an exemplary embodiment of the present invention (not shown), there are two independently controllable light fixtures, one on each side of the camera, each light fixture including approximately six LEDs. Light fixture 110 may be configured to generate multiple levels of light. Processor 106, such as a TEPC, may be directly or indirectly coupled to light fixture 110 and may be configured to control light fixture 110 to vary the light level generated by the light fixture according to, for example, a light control program 124 on the TEPC.

Specifically, luminaire 110 can be configured to generate light at two different light levels. When initiating system 1 to perform a test on device under test 115, processor 106, e.g., a TEPC, executing light control program 124 can operate luminaire 110 to emit light at a first level and can operate camera 112 to record an image when luminaire 110 emits light at the first level. Processor 106, e.g., a TEPC, can process the image obtained from camera 112 operating when the luminaire emits light at the first level to identify barcode 500 (if any barcode is included).

After obtaining an image and/or recognizing barcode 500 or otherwise determining the code to be used to obtain the necessary configuration file or folder, processor 106, such as a TEPC, can turn off light fixture 110 so that it does not emit any light. While light fixture 110 is off, processor 106, such as a TEPC, can further operate robot 102, such as by executing instructions for a selected configuration file from database 123, to operate device under test 115 so that the display screen of device under test 115 is turned on. Processor 106, such as a TEPC, can be further configured to execute instructions, such as in memory 107 on the TEPC, to detect the precise location and perimeter of the display screen of device under test 115 relative to camera 113 based on a comparison between the light generated by the display screen and the unilluminated surrounding area, the comparison being determined by analyzing an image obtained from camera 113 while light fixture 110 is off and the display screen is enabled to generate light. Although the device under test 115 may be securely mounted to the device fixture 114 and although the position of the device fixture 114 relative to the platform 104 may be substantially the same each time the fixture 114 is placed on the platform 104 in a position for testing, the display screen discovery process may be performed using the processor 106, such as the TEPC, because slight shifts of the display screen relative to the camera arrangement 111 may still occur, which may cause incorrect calculations of the region of interest (ROI) used for image processing during testing of the device under test 115. For example, such shifts may be caused by slight differences in camera alignment on different copies of the test system.

After determining the position of the display screen relative to the camera 113, the processor 106, such as the TEPC, can control the light fixture 110 to emit light at a second level that is different from the first level used to read the fixture barcode. The second light level can be maintained for the remainder of the testing process of the device under test 115. In particular, the second light level can be lower than the first light level so that the light emitted by the display screen is more prominent relative to the light emitted by the light fixture 110 than if the light fixture 110 were to emit light at the first light level.

In an exemplary embodiment of the present invention, the compartment 100 can be completely enclosed. At one or more sides, the compartment 100, the enclosure of the compartment can be via an openable door or door curtain, so that the user can reach the interior of the compartment 100. The enclosure of the compartment 100 can allow precise control of the light level in the compartment without being affected by ambient light from outside the compartment 100.

In an exemplary embodiment of the present invention, the processor 106, e.g., the TEPC, can execute a device under test button location training wizard 125 stored in, e.g., the memory 107 on the TEPC. For example, a user can input a command via the input device 109 to cause the processor 106, e.g., the TEPC, to load and execute the wizard 125. The instructions of the wizard 125 can cause the processor 106 to prompt the user, e.g., via the display 108, regarding various data or regarding manually operating the robotic arm 103. In response to the user input and the arm operation, the processor 106 can generate a new configuration file or folder of the database 123 and/or new sub-files or folders thereof. In an exemplary embodiment of the present invention, no new files or folders are generated in response to the user input and the arm operation, but, in effect, the existing configuration file is modified to include the trained button location.

During execution of wizard 125, processor 106, such as a TEPC, may prompt the user to enter basic software features supported by the new device under test 115. For example, the prompt may take the form of a series of yes and no questions or checkboxes, each asking whether the new device under test 115 includes the corresponding basic features. A non-exhaustive list of exemplary features that processor 106 may inquire about includes support for various tasks, such as handling calls, sending messages, and/or sending emails, and the type of input hardware included in the device under test 115, such as a camera and/or a surface on the device under test 115 on which the corresponding input hardware is located. Processor 106 may then determine whether database 123 includes a configuration file or folder for another device having input features similar to those for the new device under test 115. For example, if a majority of the features entered for the new device under test 115 match the features entered when configuring system 1 for the other device, processor 106 may determine that the two devices are similar. Furthermore, if the processor 106 determines that more than one other device is similar to the new device under test 115 , the processor 106 may select the device that is most similar to the new device under test 115 , as determined based on the input.

In an alternative exemplary embodiment, the program does not determine whether two devices are similar. Instead, the user makes this determination and selects a phone with similar features, if any, as a baseline for modification.

In an exemplary embodiment of the present invention, processor 106, such as a TEPC, may initially ask the user to identify a device for which system 1 has been previously configured and which the user considers most similar to the new device under test 115. If the user identifies such a device and processor 106 finds a configuration file or folder in database 123 associated with the identified device, processor 106 may omit the step of requesting the user to enter the basic characteristics of the new device under test 115. In an alternative exemplary embodiment, no steps are omitted. All configuration steps are performed, but less effort is required if only a modification of the baseline file can be performed rather than generating the configuration file characteristics from scratch.

If processor 106 determines that the device associated with the configuration file or folder in database 123 is similar to the new device under test 115, or if the user recognizes such a similar device, processor 106 can obtain the associated configuration file or folder from database 123 or other device or phone configuration directory and create a copy of the obtained file or folder as a new configuration file or folder to be stored in database 123 or other device or phone configuration directory and associated with the new device under test 115. The folder can be named according to the brand and model of the device under test. For example, the folder can be named by the manufacturer and can include subfolders, each of which is associated with a corresponding device under test and named by the corresponding brand of the device under test. The brand folder can include subfolders for the button sequence to be used and for the display screen image. The files can correspond to different sequences and different display screen images. An example file structure is shown in Figure 11.

The wizard can automatically populate a configuration file that identifies the supported features of the device under test 115, including the overall placement of supported behaviors and included hardware such as buttons and an included camera. This file can be used to determine which test cases to execute to test the features of the device under test 115.

However, because the configuration file or folder was initially created for a different device, not all of the settings will accurately reflect the new device under test 115. Therefore, the wizard can step through a series of display screens that the user can interact with to enter information about the new device under test 115 regarding its operability during testing. The display screens can initially be populated with information reflecting the different device for which the configuration file or folder was created. As soon as the user notices a discrepancy between the displayed data and the data that will accurately reflect the new device under test 115, the user can enter the necessary changes. For example, at or after a specific event, the user can update the button sequence that will be used to perform a specific task on the device under test 115 and/or can update the display screen image displayed on the display screen of the device under test 115.

Furthermore, if the new device under test 115 includes an added feature for which the previous configuration file does not provide an equivalent feature, a new sub-file or sub-element for the added feature may be added to the configuration file. Similarly, the processor 106, such as the TEPC, may remove the sub-file or sub-element corresponding to the feature for which the new device under test 115 does not provide an equivalent feature.

If the user does not identify a similar device and the processor 106, such as the TEPC, determines that a stored configuration file or folder (if any) in the database 123 is not associated with a device similar to the new device under test, a new configuration file or folder can be generated from scratch, requiring the user to enter all necessary information. In an alternative exemplary embodiment, the user is always forced to select an existing phone/device, so that the wizard automatically generates a configuration file for the new device based on the selected device's files. For example, the initial configuration file can be stored when the wizard is programmed in order to later generate files for the device to be tested.

After customizing the configuration file for the supported features of device under test 115, the wizard can step through a number of test scenarios for which the wizard has been previously configured. While stepping through the test scenarios, for each scenario, the wizard can prompt the user to operate the new device under test 115, once it is installed so that the display screen of device 115 is within the field of view of camera 113, so that the display screen of the new device under test 115 displays the screen generated from the corresponding test scenario. Once the generated screen is displayed, the user can input an instruction to display the screen. Processor 106, such as a TEPC, can record, in the configuration file and in association with the corresponding test scenario, the image captured by camera 113 when the user inputs the instruction to display the requested screen. Processor 106 can compare the image captured by camera 113 during the testing of device under test 115 with the image in the configuration file associated with device under test 115.

In an exemplary embodiment of the present invention, as described above, processor 106, such as a TEPC, may initially utilize occupancy profiles for devices identified by the user or processor 106 as similar to the new device under test 115 (if any). The user may indicate for each test scenario whether a different display should be provided. In an alternative exemplary embodiment of the present invention, a new display screen may always be requested for each new device under test 115 to ensure that processor 106, such as a TEPC, accounts for slight spatial variations in the display screens.

In an exemplary embodiment of the present invention, robot 102 may include a force sensor 600, as shown in FIG6 . Force sensor 600 can sense forces applied by arm 103 in directions perpendicular to platform 104 and in directions parallel to platform 104. Note that arm 103 can operate the input hardware of device under test 115 by pressing buttons on a face of device under test 115 parallel to platform 104, and can also operate the input hardware of device under test 115 by pressing buttons on a face of device under test 115 perpendicular to platform 104. In the former scenario, the force detected in the perpendicular direction increases when the button is pressed, while in the latter scenario, the force detected in the parallel direction increases when the button is pressed. Different portions of arm 103 can be used to press a button depending on the direction in which the button is pressed. For example, arm end 601 can be used to press a button in the perpendicular direction, while side member 602, formed, for example, by a loop, can be used to press a button in the parallel direction.

In an exemplary embodiment of the present invention, during the generation of a configuration file for the device under test 115, the processor 106, e.g., the TEPC, may record the coordinates of each input hardware to be operated by the system 1 during the testing of the device under test 115. Based on the information included in the configuration file indicating the input hardware included in the new device under test 115, as described in detail above, the wizard 125 may cause the processor 106, e.g., the TEPC, to prompt the user, for each hardware input device, e.g., a button, to manually move the robot arm 103 to a position that matches the position of the button but is in a different plane than the plane in which the button is located. For example, with respect to a button on a face of the device under test 115 that is parallel to the platform 104, the user would move the arm 103 so that the arm end 601 is aligned with the button but is in a plane that is parallel to, but different from, the face of the device under test 125 in which the button is located. Regarding buttons on the face of device under test 115 that is perpendicular to platform 104, the user will move arm 103 so that side element 602 is aligned with the button but in a plane parallel to, but different from, the face of device under test 125 in which the button is located.

Regarding buttons on the face of the device under test 115 parallel to platform 104, once the user inputs an indication that the robot arm 103 has been moved to the requested position, the processor 106, such as the TEPC, can record the x and y coordinates of the arm end 601 in a configuration file, where the x coordinate is the position along an axis extending horizontally along the plane of platform 104, and the y coordinate is the position along an axis extending vertically along the plane of platform 104. The processor 106, such as the TEPC, can also operate the arm 103 to extend vertically to press the button. Once the force sensor 600, which can provide its readings to the processor 106, such as the robot controller PC, detects that a predetermined force has been reached, the processor 106, such as the TEPC, can record the current z coordinate of the arm 103, where the z coordinate is the position along a plane extending perpendicular to platform 104, in a configuration file associated with the button. For most buttons, the force to be used as the predetermined force has been determined to be approximately 500 grams. However, different predetermined forces can be used for different buttons.

In an alternative exemplary embodiment, once the user inputs an indication that the robotic arm 103 has been moved to the requested position, the processor 106, such as a TEPC, initially records the x and y coordinates and the initial z coordinate in a configuration file. After force calibration, the z coordinate is updated.

Regarding buttons on a side of the device under test 115 perpendicular to the platform 104, once the user inputs an indication that the robotic arm 103 has been moved to the requested position, the processor 106, such as the TEPC, can record the z and y coordinates of the arm end 601 (and, in the exemplary embodiment, the initial x coordinate) in a configuration file. The processor 106, such as the TEPC, can also operate the arm 103 to extend in one of the parallel directions (depending on which side of the device under test 115 the button is located) to press the button. Once the force sensor 600 detects that a predetermined force has been reached, the processor 106 can record the current, e.g., modified, x coordinate of the arm 103 in a configuration file associated with the button. During subsequent testing of the device under test 115, the processor 106, such as the TEPC, can cause the robotic arm 103 to move to the recorded x, y, and z coordinates to press the corresponding button on the device under test 115, according to the associated configuration file.

During configuration of system 1 for a new device under test 115, e.g., during the generation or modification of a configuration file for device under test 115, processor 106, e.g., TEPC, can operate luminaire 110 in a manner similar to that described above with respect to its operation during testing of device under test 115. For example, before configuring system 1 for a new device under test 115, a barcode can be placed on device fixture 114. When configuration begins, processor 106 can operate luminaire 110 to emit light at a first level so that processor 106 detects barcode 500. Once detected, processor 106, e.g., TEPC, can turn luminaire 110 off and prompt the user to activate the display screen of the new device under test 115. Once processor 106 receives an indication of display screen activity, processor 106 can determine the precise position of the display screen relative to camera 113 by comparing the display screen's light to the surrounding, unilluminated area. After recording the display screen's position, processor 106, e.g., TEPC, can operate luminaire 110 to emit light at a second level. While the luminaire 110 emits light at the second illumination level, the processor 106 may record the template display screen as described in detail above.

Note that the configuration of the system 1 for a new device under test 115 can be interrupted, saved in an unfinished configuration file, and continued at a later time. Each time the configuration is continued, the processor 106, such as the TEPC, can execute one or more lighting control steps again. For example, each time the processor 106, such as the TEPC, can operate the lamp 110 to emit light at a first lighting level to read a bar code and determine which configuration file to open for modification. If not all display screen templates have been executed, other light control steps can be executed. In an exemplary embodiment of the present invention, the first light control step in which the user manually enters a code can be omitted, so that the bar code does not need to be read. In an exemplary embodiment, the system always attempts to read the bar code and when the reading is unsuccessful, the user is prompted to configure a new device, such as a phone.

In an exemplary embodiment of the present invention, system 1 may include a micro-station 1100, such as shown in FIG. 10 , to perform a substantial portion of the configuration of system 1 for a new device under test 115. For example, micro-station 1100 may be used to perform all configuration except for the recording of input hardware coordinates. Many components of the main workstation, where the input hardware coordinate testing and configuration are performed, may be omitted from micro-station 1100. For example, one or more, or all, of the following components may be omitted: automaton 102, device pairing instructions 120, the portion of configuration wizard 125 used for inputting hardware coordinates, and most image processing software (if image processing software for recognizing barcodes 500 is not included). In an exemplary embodiment, much of the main workstation's software may be included in micro-station 1100, as most of this software may be required to acquire a template image at micro-station 1100. Portions of the configuration file associated with the new device under test 115, such as any portion other than the portion for inputting hardware coordinates, may be generated and modified at micro-station 1100. The micro workstation can include the light fixtures 110 and camera arrangement 111 described above with respect to the main workstation, each of which can be operated as described above with respect to the main workstation. Although not shown in FIG10 , the micro workstation can include or be connected to a user terminal including a processor, input devices, and output devices so that the user can control the processor to operate the devices and generate and/or modify configuration files. In addition, although not shown in FIG10 , the compartment 1102 of the micro workstation 1100 in which the device under test 115 can be placed to configure the system 1 can include walls, doors, and/or curtains to enclose the compartment 1102 to increase control over the lighting conditions within the compartment 1102.

The micro workstation 1100 provides flexibility in allowing many users to collaborate by, for example, performing different portions of a configuration simultaneously and/or at many locations.

At any time, configuration can be stopped and subsequently continued at the micro workstation 1100 or at the main workstation. The device under test 115 mounted on the device fixture 114 can be transferred to the main workstation to run actual tests on the device under test 115 or to modify the configuration file to include data specifying input hardware coordinates. The user has the option of using only the main workstation for all configuration and testing.

In an exemplary embodiment of the present invention, different test sequences can be used for different devices under test 115. A configuration file associated with a device under test 115 can identify the test sequence to be applied to the corresponding device under test 115 when testing the device under test 115. The processor 106, such as a combination of a TEPC and an automaton controller PC, can operate the automaton 102 during testing according to the test sequence of the associated configuration file. The processor 106 can also interface with the companion device 116 according to the test sequence included in the configuration file to control the companion device 116 to communicate with the device under test 115.

In an alternative exemplary embodiment, the test sequence is not located in a configuration file or the phone configuration directory, but is instead designed to be generally applied to all devices. The test sequence references the configuration, reference images, and general button sequence files in the phone configuration directory to achieve this by isolating the device's unique operational characteristics from the general test sequence. Because paired device 116 is a constant device, the files that determine its control are stored outside the phone configuration directory.

FIG12 illustrates a process according to an exemplary embodiment of the present invention, according to which a device can be tested, including generating a configuration file and performing a test. At step 1200, the processor of the micro workstation can automatically turn on the lights at a first level. At step 1202, a barcode can be detected using the camera of the micro workstation when the lights are at the first level. At 1204, the processor can automatically turn off the lights. When the lights are turned off, at 1206, the processor can detect the position of the display screen of the device under test relative to the camera. At 1208, the processor can automatically turn on the lights at a second level. At 1210, the processor can generate a portion of a configuration file to be associated with the detected barcode. Exemplary details of generating a configuration file are illustrated in FIG13.

At 1212, steps 1200-1208 may be repeated at the master workstation. Based on the barcode detection at the master workstation (1202), a profile associated with the barcode may be selected. At 1214, the profile may be completed. FIG14 illustrates exemplary details of completing the profile.

At 1216, the tested device and the partner device can be operated according to the configuration file and according to the stored test sequence. For example, the tested device can be operated using a robotic arm, while the partner device can be operated via an interface to the partner device. If the operation of the device for testing is separated from the generation of the configuration file, for example by powering off the master workstation or using the master workstation to configure or test another device, steps 1200-1208 can be repeated before 1216, for example, immediately before 1216.

At 1217, one camera may be used to capture a video image of the device under test and the paired device. At 1218, another camera may be used to obtain a still image of the device under test, and the still image and/or text on the paired device's display may be obtained via an interface to the paired device. At 1220, the processor may compare the captured still image with the stored image. At 1222, based on the comparison, a determination may be made as to whether an error has occurred. If an error has occurred, the processor may store the captured still image and/or video image in persistent storage at 1226. If no error has occurred, or after 1226, if the test sequence has not yet completed (N branch of 1224), the process may continue from 1216. Otherwise, the process may terminate.

Figure 13 shows some details of step 1210 according to an exemplary embodiment of the present invention. At 1300, the processor may output a prompt for inputting device features. At 1302, the processor may compare the features input in response to the prompt with those features of other devices included in other configuration files associated with those other devices. If it is determined based on the comparison that the devices are similar, the processor may obtain the configuration files associated with the similar devices at 1304 and copy the files as new configuration files associated with the tested device. If no similar devices are found, the processor may generate a new configuration file at 1303. Subsequently, the processor may update the configuration file associated with the tested device at 1306 in response to user input and according to the task file indicating the tasks to be performed during the test, as described in detail above. In an exemplary embodiment, 1306 may include repeatedly executing 1300 to gradually go through each device feature for further customization.

In an alternative exemplary embodiment, the process begins at 1302, when a user manually compares the characteristics of the device to be tested with those of other devices. At 1304, the user selects a device for comparison, and the processor obtains and copies a configuration file for that device. The process then proceeds from 1304 to 1300, where the processor may prompt for device characteristics to modify the copied configuration file, thereby customizing the configuration file for the new device at 1306. This alternative embodiment may also omit the decision and step 1303, as the system may always require the selection of a stored configuration file when using the setup wizard. Thus, according to this alternative embodiment, the method sequence is 1302 to 1304 to 1300 to 1306.

FIG14 illustrates some details of step 1214 according to an exemplary embodiment of the present invention. At 1400, the processor may output a prompt instructing the robot arm to move so that it is positioned at a two-dimensional coordinate in a plane parallel to the plane in which the button is positioned, where the two-dimensional coordinate corresponds to the two-dimensional coordinate of the button in its plane. Once in this position, the processor may cause the robot arm to extend toward the button at 1402. At 1404, a force sensor may sense the force at the tip of the robot arm and provide a reading to a processor, such as a robot controller PC. At 1406, the processor, such as the robot controller PC, may compare the sensed force to a predetermined force value. If the force value has not been reached, the process may continue from 1402. Otherwise, the processor may record the three-dimensional coordinates of the robot arm for the button at 1408. This process may be repeated for all buttons. Once the coordinates have been recorded for all buttons, the process may end.

In an exemplary embodiment of the present invention, the steps of FIG. 14 are divided into two separate loops. In the first loop, step 1400 is performed for all buttons. At 1400, once the arm is in the commanded position, the processor records the two-dimensional coordinates of the button. In an alternative exemplary embodiment, the processor may initially record the initial three-dimensional coordinates of the button and then modify the three-dimensional coordinates at step 1408. In a subsequent loop, steps 1402-1408 are performed for all buttons.

One exemplary embodiment of the present invention is directed to a processor that may be implemented using any conventional processing circuitry to execute code provided, for example, on a hardware-implemented computer-readable medium to perform any of the processing features described above, alone or in combination, including control of other hardware components.

One exemplary embodiment of the present invention is directed to a hardware-implemented computer-readable medium having stored thereon instructions executable by a processor to perform any one of the processing features described above, alone or in combination, including control of other hardware components.

One exemplary embodiment of the present invention relates to a method comprising the step of transmitting instructions executable by a processor to perform any one of the processing features described above, alone or in combination, including control of other hardware components.

In an exemplary embodiment of the present invention, device fixture 114 can be provided so that it has a small footprint, thereby allowing the tested device 115 and the companion device 116 to be placed in close proximity. Device fixture 114 can also be constructed in a manner that allows the position of tested device 115 relative to robot 102 and/or camera arrangement 111 to be quickly, easily, and conveniently adjusted. In particular, as noted above, it is advantageous to position tested device 115 so that its display screen is substantially parallel to platform 104 and within good view and focus of camera 113. Furthermore, device fixture 114 can be configured so that it can accommodate many different types of test devices 115 having different configurations without requiring complex customization. FIG. 7 illustrates the components of an exemplary device fixture 114, in addition to the illustrated base plate to which the components can be attached, which can provide all of the advantages described. FIG. 8 illustrates exemplary device fixture 114 in its assembled state, in addition to the base plate.

Device fixture 114 may include attachment plate 700, base 702 which may include wide base 703 and narrow base 704, first vertical plate 705, second vertical plate 706, and mounting plate 750. The device fixture of Figures 7 and 8 may be secured to base plate 900 shown in Figure 5 .

The attachment plate 700 can have a corresponding elongated hole 701 extending through each of its two sides. Screws 720 can extend through the elongated holes 701 into threaded holes 902 of the base plate 900 to be screwed therein, thereby securing the components illustrated in Figures 7 and 8 to the base plate 900. Because the screws 720 extend perpendicularly through the length of the elongated holes 701, the attachment plate 700 can be displaced relative to the base plate 900 by a distance equal to the length of the elongated holes 701 minus the thickness of the screws 720, at least until the screws are substantially secured in the holes 902.

The attachment plate 700 may also include a window 710 formed in a substantial portion of the attachment plate 700 between the elongated holes 701. After coupling a screw 720 extending through the elongated hole 701 to the hole 902, the base 702 may slide within the window 710 in a direction perpendicular to the direction in which the attachment plate 700 may be displaced relative to the base plate 900, at least until the screw 720 is substantially tightened in the hole 902. By contacting the wide base 703 with the lip 715 of the attachment plate 700, the base 702 may be prevented from being withdrawn from the attachment plate 700 through the window 710. The thickness 708 of the wide base 703 may be greater than the height 709 of the lip 715 from the bottom of the attachment plate 700 in which the wide base 703 may slide. Accordingly, once the screw 720 is sufficiently tightened in the hole 902, the compressive force of the attachment plate 700 on the wide base 703 can prevent the base 702 from sliding relative to the attachment plate 700 due to the disparity between the thickness 708 and the height 709 of the wide base 703. Alternatively, the thickness 708 and the height 709 can be equal, and tightening the screw can generate a frictional force that prevents the base 702 from sliding relative to the attachment plate 700.

The first vertical plate 705 may include a plurality of holes 730, for example two holes 730, extending through the first vertical plate 705 in a direction perpendicular to the direction in which the base 702 slides relative to the attachment plate 700. The second vertical plate 706 may include a curved hole 707 therethrough. Screws may extend through the curved hole 707 and into the hole 730 to be screwed therein, thereby coupling the second vertical plate 706 to the first vertical plate 705. Before substantially tightening the screws extending into the hole 730, the second vertical plate may be twistable relative to the first vertical plate 705 to change the angle of the surface of the T-shaped structure 740 of the second vertical plate 706 relative to the attachment plate 700 and the base plate 900. Tightening the screws extending into the hole 730 may prevent the second vertical plate 706 from further displacement relative to the first vertical plate 705 to change the angle of the T-shaped structure 740 relative to the attachment plate 700 and the base plate 900 due to increased friction.

The mounting plate 750 can include a T-shaped aperture 752 on the underside of the mounting plate 750 that can extend the length of the mounting plate 750. The T-shaped structure 740 and the T-shaped aperture 752 can be formed in a form-fitting manner so that the mounting plate 750 can be slid onto the second vertical plate 706 with the T-shaped structure 740 extending through the T-shaped aperture 752. It will be understood that other shapes can be used for the form-fitting structure of the aperture of the vertical plate 706 and the mounting plate 750 that will allow for similar coupling of the mounting plate 750 to the vertical plate 706. The mounting plate 750 can further include an aperture 755 that can extend in a direction perpendicular to the T-shaped aperture 752 to the T-shaped aperture 752. After the mounting plate 750 is slid onto the vertical plate 706 as described above, the positioning screws can be inserted until they form a considerable compressive stress toward the T-shaped structure 740 to prevent the mounting plate 750 from further shifting relative to the vertical plate 706, and thereby prevent the mounting plate 750 from detaching from the second vertical plate 706.

The device under test 115 can be attached to the mounting plate 750, for example, via double-sided tape. The mounting plate 750 can then be attached to the vertical plate 706 as described above. The entire fixture 114 can be placed in a predetermined position relative thereto in a workstation, such as a main workstation. This predetermined position can be achieved, for example, by coupling legs extending downwardly from the underside of the device fixture 114 into receiving holes in the platform 104. Alternatively, the device fixture 114 can include multiple holes, such as four holes, for example, one in each corner, which are press-fitted onto corresponding multiple, such as four, custom-made posts with O-rings mounted on the platform of the workstation. Once positioned, the user can determine whether any adjustments are necessary. Adjustments can include displacement of the attachment plate 700 relative to the base plate 900, displacement of the base 702 within the window 710, and/or displacement of the second vertical plate 706 relative to the first vertical plate 705. In particular, the angle of the second vertical plate 706 relative to the platform 104 can be adjusted to ensure that the display screen of the device under test 115 is substantially parallel to the camera 113 .

Device under test 115 may include a button on a side of device under test 115 on a portion of device under test 115 that includes the display screen, such that the direction of button depressing extends parallel to the plane of the display screen surface. When robot 102 presses such a side button, a twisting force may be generated. To prevent device under test 115 from twisting under such a force, a support 1000, such as illustrated in FIG. 9 , may be screwed into hole 902 of base plate 900 in a position such that support 1000 contacts device under test 115 on the side opposite to the side on which the side button is located. If side buttons are located on both sides of device under test 115, support 1000 may be placed on both sides. If no side buttons are included, the support may be omitted.

Those skilled in the art will appreciate from the foregoing description that the present invention can be implemented in a variety of forms, and that various embodiments can be implemented individually or in combination. Therefore, although the embodiments of the present invention have been described in conjunction with specific examples thereof, the true scope of the embodiments and/or methods of the present invention should not be so limited, as other modifications will become apparent to the skilled person upon studying the drawings, the specification, and the following claims.

Claims (15)

1. A device testing system, comprising: A memory that stores multiple screenshots associated with the device; The first camera; Second camera; The platform is arranged such that at least a portion of the platform is in the field of view of the first camera and in the field of view of the second camera; Automated robotic arms; and A processor, which is coupled to the first and second cameras and to the memory; in: The first camera is arranged such that the axis extending through the lens of the first camera extends substantially perpendicularly toward the platform. The second camera is arranged such that the axis extending through the lens of the second camera extends toward the platform at a substantially non-perpendicular angle, and the second camera has a smaller zoom setting than the first camera, thereby allowing the second camera to sense a larger observation area than the first camera. The first camera is configured to transmit captured images to the processor; The field of view corresponding to each of the first camera and the second camera includes the screen of the device; And the processor is configured as follows: When the device is placed on the platform, it causes the automated arm to operate the device. Compare the images received from the first camera during operation of the device with a plurality of stored screenshots; If the compared images do not match, then an error has occurred; and The video captured by the second camera is stored in the memory during the period in which the error is determined. 2. The device testing system according to claim 1, further comprising: A force sensor configured to sense the force generated by the automated arm; wherein: Operation of the device includes manipulating each button in at least one of a plurality of button subsets to such effect as to cause a corresponding signal to be generated in the device, the signal recognizing the manipulation of the corresponding button; and For each button in at least one of the button subsets, the operation is performed by extending the automaton along a direction perpendicular to the corresponding button face until the position of the automaton corresponds to the corresponding coordinates for the corresponding button. 3. The device testing system according to claim 1, further comprising: A micro workstation, comprising a camera arrangement, a processor, and a platform below the camera arrangement, the micro workstation excluding an automated robotic arm capable of operating the device via it; The operation of the device is partly based on a screenshot of the display screen compared with the captured image during the operation of the device. 4. The device testing system of claim 3, wherein one or more configuration files include screenshots of the display screen, and the screenshots are compared with captured images during operation of the device. 5. The device testing system of claim 4, wherein at least one portion of the one or more profiles can be generated by capturing the screenshot using the camera arrangement of the micro workstation. 6. A device testing method, comprising: Operate the device according to the stored test sequence; A still image of the device’s display screen is captured using a first camera, the first camera having a field of view substantially occupied by the display screen; A second camera is used to capture video images, the second camera having the field of view of the device; In the first comparison step, the captured still image is compared with the stored screenshot; Based on the comparison, it is determined whether an error has occurred; and If it is determined that an error has occurred, a video clip captured by the second camera and corresponding to the period during which the determined error occurred is stored in the memory. 7. The device testing method according to claim 6, further comprising: If it is determined that an error has occurred, one or more captured still images are stored in the memory. 8. The device testing method of claim 6, wherein the period begins at a start time prior to the occurrence of the error and ends at an end time following the occurrence of the error. 9. The device testing method according to claim 6, further comprising: Locate the code region within the image captured by one of the cameras in the field of view of the device; and Process the code region to obtain the code encoded in the code region; and The configuration file is obtained based on the association between the code and the configuration file; The operation of the device is based on the configuration file. 10. The apparatus testing method according to claim 9, wherein the code is a barcode. 11. The device testing method according to claim 6, further comprising: The position of the display screen relative to the field of view of the first camera is detected, and a comparison step is performed based on the detected position. 12. The device testing method according to claim 9, further comprising: The processor automatically operates the luminaire to generate light during the step of locating the code region at a first level; Following the step of locating the code, the processor automatically operates the lamp so that the lamp does not emit light during the step of detecting the position of the display screen; and Following the step of detecting the position of the display screen, the processor automatically operates the lamps to generate light at a second level during the step of capturing still and video images. 13. The apparatus testing method of claim 6, wherein the test sequence is pre-stored. 14. The device testing method according to claim 6, further comprising: A configuration file is generated, and the operation of the device is executed according to the configuration file. Generating the configuration file includes, based on a file that identifies multiple test tasks, for each identified test task: Output prompts about the set of corresponding device operation sequences that can be used to perform the corresponding task; and In response to information received regarding the prompt, the configuration file is updated to include the received information. 15. A device testing apparatus, comprising: A means for operating a device according to a stored test sequence; A means for operating a first camera to capture still images of the display screen of the device, the first camera having a field of view substantially occupied by the display screen; A means for operating a second camera to capture video images, the second camera having the field of view of the means; A means for comparing a captured still image with a stored screenshot in a first comparison step; A means for determining whether an error has occurred based on the comparison; and A means for storing, in at least one of a memory and a disk, a video clip captured by the second camera and corresponding to the period during which the determined error occurred, when it is determined that an error has occurred.