JP6336958B2 - Method for enabling a partial retry of a prescribed test sequence of a device under test (DUT) - Google Patents

Description

  The present invention generally relates to a method of testing an electronic device. More particularly, the present invention tests a wireless device using a test platform consisting of hardware components, firmware components, and / or software components that requires minimal feedback from the device. For improving the method.

  Many of today's portable devices utilize wireless “connections” for telephone calls, digital data transfer, geographical positioning, and the like. Despite the differences in frequency spectrum, modulation method, and power spectral density, wireless connectivity standards transmit and receive data using synchronized data packets.

  In general, all of these wireless connection capabilities (eg, WiFi, WiMAX, Bluetooth, etc.) are industry recognized standards that specify parameters and restrictions that devices with these connection capabilities must follow ( For example, defined by IEEE 802.11 and IEEE 802.16).

  At any point along the course of device development, it may be necessary to test and verify that the device operates within the specifications of that standard. Most such devices are transceivers, that is, those that transmit and receive wireless RF signals. Dedicated systems designed to test such devices are typically designed to receive and analyze device transmit signals and send signals according to industry recognized standards , Including subsystems designed to determine whether the device is receiving and processing wireless signals in accordance with the standard.

  In some cases, the device under test (DUT) may be subjected to a predetermined test sequence to accelerate test execution. This may include a test sequence that is applied to the DUT or stored directly therein. The configuration of the DUT may also include means for performing a test sequence. Typically, test sequences may be grouped into blocks. Continuous TX (eg, a DUT that sends packets to the tester), RX (eg, a tester that sends packets to the DUT), or TX and RX (packets sent in both directions) measurements are then Can be executed.

  Generally, in a sequence for testing a conventional electronic system, the entire test sequence is performed. The test sequence may or may not include the occurrence of one or more test block failures. There is no clear way to "retry" in conventional systems, unless direct access to the DUT is possible when one or more test block failures occur. However, it is difficult and time consuming to perform such direct control in many modern devices. Thus, the entire test sequence is typically re-executed without direct control. This action increases overall test time and increases test costs while reducing test efficiency.

  Therefore, it is necessary to allow a test system to determine when an error occurs in a test sequence in a time efficient manner. In the absence of direct control, and without requiring the entire test sequence to be re-executed at the end of the test, the test system automatically “retrys” the failed block in a period close to the point of failure. It needs to be possible.

  Accordingly, the object of the present invention is to allow the test system to initiate a retest of a failed block by operating the DUT according to the retry protocol and allowing the tester to utilize this protocol to initiate this retry. To overcome the disadvantages of the prior art. The system in this case can interact with the DUT configured to perform the specified sequence and behave in a manner consistent with the retry protocol, and to interact with the DUT in the execution of the specified sequence. It consists of a test machine that can initiate a retry of any failed block using the protocol.

  In accordance with one disclosed exemplary embodiment, the disclosed invention enables a test sequence after the tester's analysis subsystem determines that a previous block of data packets meets one or more specified test criteria. Perform a block test “retry” in a test environment in which each block is transmitted. When it is determined that a block or a portion thereof transmitted by the device under test does not meet the specified test criteria, a retry sequence is initiated to allow the block to be retested.

  According to another exemplary embodiment, the disclosed invention performs block test retries in a test environment where analysis of the previous block occurs during execution of the subsequent block. If it is determined that the block or part of it transmitted by the DUT does not meet the specified test criteria and that determination is made during the execution of a later sequence, several blocks into the block determined to have failed Returning initiates a retry sequence. The present invention also allows testing to resume at the next untested block in the sequence.

  In order that the "Mode for Carrying Out the Invention" herein may be better understood and so that the contribution of the present invention to the art can be better appreciated, Certain embodiments have thus been outlined somewhat broadly. There are, of course, additional embodiments of the invention that will be described below and which will form the subject matter of the claims appended hereto.

  In this regard, before describing at least one embodiment of the invention in detail, the invention is limited in its application to the details of construction and the arrangement of components set forth in the following description or illustrated in the drawings. Please understand that it is not. The invention is capable of embodiments other than those described and of being practiced and carried out in various ways. It is also to be understood that the language and terminology used in this specification and the abstract are for illustrative purposes and should not be considered limiting.

  Accordingly, one of ordinary skill in the art will readily appreciate that the concepts upon which this disclosure is based can be readily used as a basis for designing other structures, methods, and systems for carrying out the objectives of the present invention. You will understand. It is important, therefore, that the claims be regarded as including such equivalent constructions insofar as they do not depart from the spirit and scope of the present invention.

  Still other aspects, features, and advantages of the present invention will be described below by merely describing a number of exemplary embodiments and implementations, including the best mode contemplated for carrying out the invention. It will be readily apparent from the “Description of Embodiments”. The invention is also capable of other and different embodiments, and its several details are capable of modifications in various respects, all without departing from the spirit and scope of the invention. . Accordingly, the drawings and descriptions are to be regarded as illustrative in nature and not as restrictive.

The present invention will be more fully understood from the following Detailed Description, and the accompanying drawings of various embodiments of the invention, which, however, identify the present invention. It should not be construed as limiting to the embodiments but merely for explanation and understanding.
FIG. 1 shows a diagram of a conventional and prior art test environment and method, in which a controller communicates with a DUT and a tester and orchestrates the transmission of packets between the DUT and the tester. FIG. 2 is a diagram representing a newer prior art in which a DUT stores and executes a predetermined sequence of packets transmitted or received after establishing synchronization with a tester. As shown, a communication path between the DUT and the controller is no longer necessary. FIG. 3 is a diagram representing a method for performing a block test “retry” according to a first exemplary disclosed embodiment. FIG. 4 is a flow diagram illustrating the logical flow in a DUT that supports the method of FIG. 3 according to the examples disclosed in the embodiments. FIG. 5 is a diagram representing a method for performing a block test “retry”, according to another representative disclosed embodiment. FIG. 6 is a flow diagram illustrating the logical flow of a DUT that supports the method of FIG. 5 in accordance with another representative disclosed embodiment.

  The present invention will now be described with reference to the drawings, wherein like reference numerals refer to like parts throughout. The following Detailed Description is of an exemplary embodiment of the claimed invention with reference to the accompanying drawings. Such description is exemplary and not limiting with respect to the scope of the present invention. Such embodiments are described in sufficient detail to enable those skilled in the art to practice the subject invention and do not depart from the spirit or scope of the subject invention. It will be appreciated that variations may be used to practice other embodiments.

  Throughout this disclosure, it will be understood that the individual circuit elements as described may be singular or plural in number, unless there is a clear indication that the contents are contrary. . For example, the terms “circuit” and “circuit arrangement” are either a single component, or active and / or passive, connected together to provide the functions described. Or any other combination (eg, as one or more integrated circuit chips). Further, the term “signal” may refer to one or more currents, one or more voltages, or a data signal. In the drawings, similar or related elements have similar or related alphabetic, numeric, or alphanumeric designators. Furthermore, although the invention has been described in the context of an embodiment that uses discrete electronic circuitry (preferably in the form of one or more integrated circuit chips), any part of such circuitry may be used. Functions can alternatively be implemented using one or more appropriately programmed processors, depending on the signal frequency or data rate being processed.

  Referring to FIG. 1, a conventional system for testing a wireless device includes a DUT (101), a tester (102), a controller (103), and between a DUT and a controller (105), a tester and a controller. (104) and between the DUT and the tester (106). These communication paths can be implemented using wired or wireless technology.

  Referring to FIG. 2, a newer system for testing a wireless device is described in which a DUT (201) configured to store and execute a predetermined sequence (206) and a predetermined packet of packets after synchronizing with the DUT. A test machine (202) capable of interacting with the DUT in such a way that it can be transmitted to or from the DUT with minimal or no control transformation required. including. As shown, the DUT (201) and the tester (202) communicate via a bidirectional communication path (205), and the tester communicates with the controller (203) via a bidirectional communication path (204). These communication paths can be implemented using wired or wireless technology.

  With reference to FIG. 3, an embodiment for testing a system over a period of time is disclosed. The disclosed inventive method can be used in a test environment in which each block of a test sequence is transmitted after the analysis subsystem of the tester determines that the previous block of the data packet met the test standard. Try again. If the block transmitted by the DUT determines that the tester does not meet the test standards, the tester initiates a retry sequence so that the block can be retested.

  In accordance with one disclosed embodiment, the tester and DUT initiate a defined synchronous message exchange (301, 302, and 303) that occurs at frequency F1. The tester may include one of a variety of test equipment including, for example, a wireless tester or other electronic component (eg, a vector signal generator (VSG), and a vector signal analyzer (VSA)). A DUT includes one or more electronic components and configurations, such as a number of embedded subsystems, including a host processor, memory (eg, non-volatile memory), a wireless transceiver, and one or more peripheral devices. obtain. The host processor can be configured to control the memory, wireless transceiver, and peripheral devices via various control interfaces. Typically, the memory stores programs used by the DUT as firmware.

  The tester sends one or more packets to the DUT during message exchange 301, while the DUT listens for packets during message exchange 302. When the DUT receives the expected packet from the testing machine, it returns an acknowledgment 303 to the testing machine, thus indicating that synchronization (SYNC) has been established. When synchronization is achieved, the DUT transmits a sequence 305 of one or more defined packets (eg, a TX sequence) to the tester at frequency F1. The tester receives the above packets and analyzes (304) the desired parameters to determine if they meet specified test criteria. Blocks 304 and 305 may further include scenarios in which the tester transmits one or more packets to the DUT (eg, a TX sequence) and tests the ability to receive DUT packets. In this case, the test criteria are met and the DUT changes the frequency to F2 according to a predetermined test flow.

  At frequency F2, the tester and DUT also exchange synchronization packets (306, 307, and 308). Similar to the test scheme at frequency F 1, the tester sends one or more packets to the DUT during the message exchange 306, during which the DUT listens for packets during the message exchange 307. When the DUT receives the expected packet from the testing machine, it returns an acknowledgment 308 to the testing machine, thus indicating that synchronization has been established. Upon achieving synchronization, in this example, the DUT transmits a sequence 311 of one or more defined packets to the test machine at frequency F2. The tester receives the above packets and analyzes (310) the desired parameters to determine if they meet specified test criteria. Blocks 310 and 311 may additionally include scenarios where the tester tests the ability to send one or more packets to the DUT (eg, an RX sequence) and receive the DUT's packets. However, in this case, error 309 exists. In one embodiment, the error may be determined, for example, by the tester's analysis subsystem and communicated to the tester's control subsystem. Error determination may also occur if the analysis data from the DUT cannot clearly determine the result, or if the DUT does not follow the expected (eg, prescribed) sequence. In accordance with the disclosed embodiments, the tester is configured to retry the test sequence when an error is determined.

  In particular, to reduce unnecessary feedback and provide an effective electronic control design, the DUT is not configured to directly determine error events in accordance with the disclosed embodiments. Thus, a DUT that does not recognize any errors or intent of the tester's function to retry the test proceeds to the next test sequence. In this case, the DUT switches to frequency F3 and waits for the expected synchronization exchange 312. On the other hand, the tester that recognizes the error in block (N = 2) is configured to retry the test that caused the previous error and does not proceed to the next expected synchronization event. Instead, the tester is configured to know the DUT's prescribed retry protocol, remains at frequency F2, and tries to perform the normal synchronization process (eg, via message exchanges 313, 314, and 315). .

  On the other hand, the DUT does not receive any further exchange packets from the tester, times out based on the retry protocol at event 312 and determines that this event does not cause synchronization. Accordingly, in response, the DUT is configured to return to the previous frequency (F = F2) and attempt synchronization based on the retry protocol. The tester timeout period is specifically configured to be always longer than the DUT timeout period to ensure that the tester does not time out before the DUT returns to its retry routine. Thus, according to a retry scheme at frequency F 2, the tester sends one or more packets to the DUT during message exchange 313, while the DUT listens for packets during message exchange 314. When the DUT receives a predicted packet from the testing machine, it returns an acknowledgment 315 to the testing machine, thus indicating that synchronization has been established. Once synchronization is established (315), the DUT sends the same defined packet or packets (as expected previously from 311 (eg, 311 = 317)) and the tester Receive and analyze (316) to determine if they meet the test criteria. Blocks 316 and 317 may additionally include scenarios in which the tester tests the ability to send one or more packets to the DUT (eg, an RX sequence) and receive DUT packets. At this time, the block N = 2 satisfies the prescribed test standard. As a result, the DUT continues and switches to the frequency F3. As in blocks 104 and 105, blocks 116 and 317 may additionally include a scenario where the tester transmits one or more packets to the DUT and tests, for example, the ability to receive DUT packets.

  At frequency F3, the DUT and the tester exchange synchronization messages (318, 319, and 320). While the tester sends one or more packets to the DUT during message exchange 319, the DUT listens for packets during message exchange 318. When the DUT receives the expected packet from the testing machine, it returns an acknowledgment 320 to the testing machine, thus indicating that synchronization has been established. Upon achieving synchronization, the DUT sends one or more predefined packet sequences 322 to the test machine at frequency F3. The tester receives the above packets and analyzes them (321) to determine whether they meet specified test criteria. At this point, in the exemplary embodiment, the test sequence is complete. Blocks 321 and 322 may additionally include a scenario where the tester transmits one or more packets to the DUT, eg, testing the ability to receive DUT packets. In the above scenario, most of the described tests have a DUT that sends packets to the tester, but for those skilled in the art, the test also includes the case where the tester sends packets to the DUT, and both It will be readily appreciated that this combination may also be included.

  Referring to FIG. 4, the flow diagram illustrates the logical flow of the DUT that supports the method in FIG. First, synchronization 400 of block N is executed (302 and 303 in FIG. 3). If synchronization occurs during exchange message transmission (303), the 401 branch "Y" path is selected. The DUT then executes the remainder of block N (eg, N = 1 in F1) by sending and receiving (305 and 304) sequences, respectively (402). The DUT now increments the block by 1 (N = N + 1, ie, N = 2) (403). Since the retry (RETRY) variable is not set (N in 404), the DUT attempts to synchronize blocks N = 2 and F = 2 (307, 308 in FIG. 3). In N = 2 blocks, the DUT follows the same flow as above, so N increases to N = 3. However, an error occurs during block N = 2, causing the tester to decide to perform a retry.

  At N = 3 and F = 3, the DUT attempts to obtain synchronization 400 (312 in FIG. 3), but no synchronization occurred at this time. As a result, the “N” path of 401 branches is taken. The DUT then checks whether the retry variable has been set (405). In this case, it is not set, so the “N” path of 405 branches is selected. Thus, N decreases from N = 3 to N = 2 (406) and a retry variable is set (407), which means that a retry was requested by the tester.

  The DUT then performs synchronization of block N = 2 with F = 2 (eg, 313, 314 in FIG. 3). When synchronization is obtained (eg, 315 in FIG. 3), the “Y” path of the 401 branch is executed, block N (N = 2) is executed, and then N increases to N = 3. At this time, retry is set, so the “Y” path of the 404 branch is selected. At this time, since synchronization is correctly executed, the retry variable is cleared (retry ok) (408), and N is set to N (for example, N = 3) (409).

  However, if no synchronization occurred, the “N” path of branch 401 would have been selected. Since the retry has already been set, the “Y” path of branch 405 is selected and the DUT exits the test flow (410). At this point, the test sequence may be configured to perform additional operations, such as resume (eg, N = 1), or may instead terminate the operations. Also, other configurations may be considered, as will be readily understood by those skilled in the art.

  In some cases, during the test sequence, the DUT and the tester do not recognize the opportunity to analyze the results of the block test and / or have a presence after the test sequence and before moving to another block test. May not. For example, FIG. 5 illustrates a test environment and method for performing a block test “retry” in a test environment in which each block in the sequence is transmitted while the tester's analysis subsystem is operating simultaneously. ing. A determination of whether the previous block of the data packet met or did not meet the test criteria may occur during the execution of subsequent blocks. As shown, the disclosed embodiments allow the tester to return to the required amount of blocks, for example, to retest one or more failed blocks. Thereafter, if the retest is successful, the DUT and the tester proceed to the appropriate amount of blocks (ie, blocks that have not been previously tested) to resume the prescribed test sequence. In the example described below, the test returns two blocks to retest the failed blocks. Thereafter, if the retest is successful, the DUT and the tester will advance two blocks and resume the prescribed test sequence.

  As in FIG. 3, the tester and DUT of FIG. 5 initiate a defined synchronous message exchange (501, 502, and 503) at frequency F1. For example, the tester sends one or more packets to the DUT during message exchange 501 while the DUT listens for packets during message exchange 502. When the DUT receives an expected packet from the testing machine, it returns an acknowledgment 503 to the testing machine, thus indicating that synchronization has been established. Upon achieving synchronization, the DUT transmits one or more predefined sequence of packets 505 at frequency F1. The tester receives the above packets and analyzes them (504) to determine if they meet specified test criteria. Blocks 504 and 505 may additionally include a scenario where the tester transmits one or more packets to the DUT, for example, testing the ability to receive DUT packets. In this case, the test criteria are met and the DUT changes the frequency to F2 according to a predetermined test flow.

  Here again, at frequency F2, the tester and DUT exchange synchronization packets (506, 507, and 508). Similar to the test scheme at frequency F1, the tester sends one or more packets to the DUT during the message exchange 506, while the DUT listens for packets during the message exchange 507. When the DUT receives the expected packet from the tester, it returns an acknowledgment 508 to the tester, thus indicating that synchronization has been established. When synchronization is achieved, the DUT sends one or more predefined sequence 510 of packets to the test machine at frequency F2. The tester receives the above packets and analyzes them (509) to determine if they meet specified test criteria. Blocks 509 and 510 may additionally include scenarios where the tester tests the ability to send one or more packets to the DUT (eg, an RX sequence) and receive the DUT's packets. However, in this case, error 511 exists. In disclosed embodiments, the error may be determined, for example, by the tester's analysis subsystem and communicated to the tester's control subsystem. Error determination can also occur when the analysis data from the DUT cannot clearly determine the result.

  However, in the disclosed embodiment of FIG. 5, the tester test analysis is not completed at the time of error occurrence (511). On the other hand, the DUT and the tester continue the test sequence and proceed continuously to block N = 3 with frequency = F3. At frequency F3, the tester and DUT exchange synchronization packets (512, 513, and 514). Similar to the test schemes at frequencies F1 and F2, the tester sends one or more packets to the DUT during message exchange 512, while the DUT listens for packets during message exchange 513. When the DUT receives the expected packet from the testing machine, it returns an acknowledgment 514 to the testing machine, thus indicating that synchronization has been established. Upon achieving synchronization, the DUT transmits one or more predefined packet sequences 516 at frequency F3. The tester receives the above packets and analyzes them (515) to determine if they meet specified test criteria. Blocks 515 and 516 may additionally include a scenario in which the tester transmits one or more packets to the DUT, eg, testing the ability to receive DUT packets.

  However, so far, the tester may have recognized that there was an error in block N = 2 at F = 2. In this example, the tester is configured to verify or overcome the error by initiating a retry. On the other hand, the DUT may not be designed to directly recognize error events in order to reduce unnecessary feedback and provide an efficient electronic control design in accordance with the disclosed embodiments. Thus, a DUT that does not recognize any error or tester retry function to re-run the test continues that function, switches to frequency F4, and waits for the expected synchronization exchange 517. Instead, the test machine that determined the error in block N = 2 is configured not to proceed to the next expected synchronization event. Alternatively, the tester is configured to execute a prescribed retry scheme based on the expected behavior of the DUT according to the retry protocol and return to the point of occurrence or event of the error. In this case, an error occurred at the frequency F2. At such time, the DUT apparently does not receive any further exchange packets from the tester at this point. The DUT times out at event 517 and further determines that no synchronization occurs at this event.

  On the other hand, the tester is configured to perform a retry scheme (eg, via message exchanges 518, 519, and 520) by attempting a normal synchronization process. Again, the tester timeout period is longer than the DUT timeout period so that the DUT has sufficient time to time out and return to the retry routine. The DUT that did not detect a synchronization event and timed out returns to F2 and attempts to synchronize according to its retry protocol (519). Thus, according to a retry scheme at frequency F2, the tester transmits one or more packets to the DUT during message exchange 518, while the DUT listens for packets during message exchange 519. When the DUT receives the expected packet from the testing machine, it returns an acknowledgment 520 to the testing machine, thus indicating that synchronization has been established. Once synchronization is established (520), the DUT sends the same defined packet or packets (as expected previously from 510 (eg, 510 = 522)) and the tester Receive and analyze (521) to determine if they meet the test criteria. Blocks 521 and 522 may additionally include scenarios in which the tester tests the ability to send one or more packets to the DUT (eg, an RX sequence) and receive the DUT's packets. At this time, the block N = 2 satisfies the test standard. As a result, the DUT continues to the next untested block and in this case switching to frequency F4.

  At frequency F4, the tester and DUT exchange synchronization packets (524, 525, and 526). Similar to the test schemes at frequencies F1, F2, and F3, the tester transmits one or more packets to the DUT during the message exchange 524, while the DUT listens for packets during the message exchange 525. When the DUT receives the expected packet from the testing machine, it returns an acknowledgment 526 to the testing machine, thus indicating that synchronization has been established. Once synchronization is established, the DUT sends one or more specified packets 528 to the tester, which receives and analyzes (527) and determines whether they meet specified test criteria. Blocks 527 and 528 may additionally include scenarios in which the tester tests the ability to send one or more packets to the DUT (eg, an RX sequence) and receive DUT packets. At this point, the test sequence is complete in the exemplary embodiment. In the above scenario, most of the described tests have a DUT that sends packets to the tester, but those skilled in the art will also consider the test if the tester sends packets to the DUT, and a combination of both. It should be recognized that cases may be involved.

  Accordingly, the disclosed embodiment of FIG. 5 provides a method for performing a block test “retry” in a test environment in which each block in the sequence is transmitted while the tester's analysis subsystem is operating simultaneously. Represents. A determination of whether the previous block of the data packet met or did not meet the test criteria may occur during the execution of subsequent blocks. The disclosed embodiment allows the tester to return when an error occurs. In this case, the tester returns 2 blocks and retests the failed block. Thereafter, if the retest is successful, the DUT and tester proceed to resume testing of the untested block. In this case, the DUT and the tester proceed two blocks and resume the prescribed test sequence.

  The embodiment described and shown in FIG. 5 is for illustrative purposes and explanation. The embodiment of FIG. 5 allows the tester to retry test errors by going back two blocks and retesting the failed block, but the test equipment will fail the test block that is more than three blocks away from the error block decision. May be configured to recognize. In this case, the test equipment may be configured to return to the appropriate number of blocks to retest the failed blocks. After retest verification (ie, retest is successful), the test equipment may proceed to the appropriate number of blocks and resume testing of the previous untested block. Thus, in the above scenario, the tester and DUT returned 2 blocks (eg, N = 4 to N = 2), but if the test analysis (eg, of the tester) takes longer than the above scenario, retry One skilled in the art can readily appreciate that the routine, and its supporting logic, has no reason not to return more blocks. In addition, the routine and support logic have no reason not to jump first to an untested block in order to resume the test sequence when verification occurs.

  With reference to FIG. 6, for example, a flow diagram illustrating the logical flow of a DUT supporting the method of FIG. 5 is disclosed. First, synchronization 600 of block N is executed (501 and 502 in FIG. 3). If synchronization occurs during exchange message transmission (503), the "Y" path of branch 601 is selected. The DUT then executes the remainder of block N (eg, N = 1 in F1) by sending and receiving (505 and 504) test sequences, respectively (602). The DUT now increments the block by one (603) (N = N + 1, ie, N = 2). Since the retry variable is not set (N in 404), the DUT attempts to synchronize blocks N = 2 and F = 2 (507, 508). In N = 2 blocks, the DUT follows the same flow as above, so N increases to N = 3. Here, since the analysis of the test machine in the block N = 2 is not yet completed, both the DUT and the test machine perform the synchronous exchange 600 (transmission and reception of the packets 512, 513, and 514 (see FIG. 5)). At this point, since neither the DUT nor the tester is aware of the block test failure, the DUT sends packets (516) and the tester receives and analyzes them (515). The DUT also proceeds to N = N + 1, or N = 4 at F4. However, an event occurs during block N = 2, causing both the tester and the DUT to complete the test of block N = 3 and then have the tester decide to perform a retry. The DUT has progressed to N = 4 and F = 4, but now the test machine that recognizes the problem can initiate a retry and return to F = 2.

  When N = 4 and F = 4, the DUT attempts to obtain synchronization 600 (eg, see 517 in FIG. 5), but no synchronization occurs at this time. Therefore, it follows the “N” path of 601 branches. The DUT then checks whether the retry variable has been set (605). In this case, it is not set, so it follows the “N” path of branch 605. Thus, N decreases from N = 4 to N = 2 (606) and a retry variable is set (607), which means that a retry was requested by the tester.

  The DUT then performs synchronization of block N = 2 with F = 2 (eg, 518, 519 in FIG. 5). When synchronization is obtained (eg, 520), following the “Y” path of branch 601, block N (N = 2) is executed, after which N increases to N = 3. At this time, a retry is set and follows the “Y” path of branch 604. At this time, since the synchronization is correctly performed, the retry variable is cleared (retry ok), and N is set to N + 1 (for example, N = 4) (609).

  However, if no synchronization occurred, the “N” path of branch 601 would have been selected. Because retry has already been set, the “Y” path of branch 605 is selected and the DUT exits the test flow (610). At this point, the test sequence may be configured to perform additional operations, such as resumption (eg, N = 1), or may instead terminate the operations. Other configurations may be considered, as will be apparent to those skilled in the art.

  According to the exemplary embodiment described above, the various data blocks N, N + 1, N + 2,. . . DUT testing at different corresponding frequencies F1, F2, F3,. . . Including transmitting a data block. However, as will be readily apparent to those skilled in the art, the transmission of a data block signal may include other signal characteristic changes. For example, in addition to or in place of changing the frequency at which data packets are transmitted, other signal characteristics may vary, including but not limited to data rate, signal modulation type, and signal power. . Thus, the defined test criteria may include various signal characteristics, including but not limited to frequency, data rate, signal modulation type, and signal power, as desired.

  Accordingly, the disclosed embodiments of the present invention overcome the deficiencies of the prior art by eliminating the need to re-execute the entire test sequence when one or more test block failures occur. The benefits of this embodiment are associated with test costs by allowing the test system to automatically "retry" failed blocks rather than having to re-run the entire test sequence. Reducing the overall test time of a test sequence event. Repeating the test for only the most recently failed block requires only a small amount of time for the test event, whereas conventional test systems require a complete test sequence to be re-executed. The disclosed embodiments of the present invention thus reduce overall test time, increase test efficiency, and reduce test costs.

  It will be apparent to those skilled in the art that various modifications and variations can be made to the disclosed method without departing from the scope of the disclosure. In addition, other embodiments of the method will be apparent to those skilled in the art from consideration of the specification. It is intended that the specification and examples be considered as exemplary only, with a true scope of the disclosure being indicated by the following claims and their equivalents.

  The above description is presented to enable one of ordinary skill in the art to make and use the technology and is described in the context of patent acquisition requirements. This description is the best currently contemplated method for implementing the technology. Various modifications to the preferred embodiment will be readily apparent to those skilled in the art, and the general principles of the technology may be applied to other embodiments, and some features of the technology may be Can be used without the use of the features of Accordingly, the technology is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features described herein.

Claims (12)

A method for testing a communication device, comprising:
Listening to a synchronization start message from the testing machine at the device under test (DUT);
If the DUT is unable to receive the synchronization start message during a synchronization start time interval, the DUT listens to the synchronization start message again;
If the DUT receives the synchronization start message within the synchronization start time interval, then sending a synchronization response message to the tester by the DUT, followed by
The step of listening for exchanging messages from the tester by the DUT, and one or more of the plurality of communication blocks divided data packet sequence, at least a portion, and at least one process of the process performed by the DUT ,
The DUT is
The step of listening for exchanging messages by the DUT, and one or more of the plurality of communication blocks divided data packet sequence, at least part, if at least one of the step of executing failure by the DUT,
Listens to the synchronization start message sent by the tester to retry the block data packet sequence that failed to execute after the timeout period of the tester that is longer than the synchronization start time interval , and the response message method comprising the steps of repeating the step of transmitting. One or more of the plurality of communications of the block data packet sequence are:
Receiving at least a portion of the block of data packet sequences;
Transmitting at least a portion of the block of data packet sequences;
The method of claim 1, comprising at least one of receiving at least a portion of the block data packet sequence and transmitting at least a portion of the block data packet sequence. The method described. At least one of the synchronization start message, the synchronization response message, the exchange message, and the block data packet sequence includes a data packet signal having a first plurality of signal characteristics;
Further, the listening step, the transmitting step and the executing step of claim 1 are repeated after the step of executing at least a part of one or more of the plurality of communications of the data packet sequence divided into blocks by the DUT. At least one of the synchronization start message, the synchronization response message, the exchange message, and the block-divided data packet sequence in the repeated listening, transmitting, and executing steps of claim 1 One comprising a data packet signal comprising a second plurality of signal characteristics;
The method of claim 1, wherein one or more of the second plurality of signal characteristics is different from a corresponding one or more of the first plurality of signal characteristics. The reception by the DUT of the exchange message within an exchange time interval in the repeated listening, transmitting and executing steps of claim 1, and the repeated listening step of claim 1. Following at least one of execution by the DUT of at least a portion of one or more of the plurality of communications of the block data packet sequence in the step of performing
A step of performing at least a portion of one or more of a plurality of communications of another block of data packet sequences by the DUT,
Receiving at least a portion of the another block-divided data packet sequence;
Transmitting at least a portion of the separate block data packet sequence;
At least one of receiving at least a portion of the another block-divided data packet sequence and transmitting at least a portion of the another block-divided data packet sequence. The method of claim 3 including performing.   5. The method of claim 4, wherein the another block-divided data packet sequence includes a corresponding data packet signal that has the same signal characteristics as the second plurality of signal characteristics. When at least one of the synchronization start and exchange messages of the repeated listening and transmitting steps of claim 1 does not comprise the second signal characteristic,
A data packet signal comprising one of the same signal characteristics as the first plurality of signal characteristics and a third plurality of signal characteristics;
4. The method of claim 3, wherein one or more of the third plurality of signal characteristics is different from each corresponding one or more of the first and second plurality of signal characteristics. A method for testing a communication device, comprising:
Transmitting a synchronization start message within the synchronization start time interval by the testing machine;
Listening to the synchronization response message from the communication device by the testing machine;
Retransmitting a synchronization start message to the communication device by the tester if the tester fails to receive the synchronization response message within a synchronization response time interval;
When the tester receives the synchronization response message within the synchronization response time interval,
Performing at least one of a step of transmitting an exchange message by the tester to the communication device , and a step of executing at least a part of one or more of a plurality of communications of the block data packet sequence by the tester Process,
If the tester fails the step of executing at least a portion of one or more of the plurality of communications of the block of data packet sequences;
The step of transmitting the synchronization start message by the tester and the step of listening to retry the failed data packet sequence divided into blocks after the timeout period of the tester longer than the synchronization start period interval. Including a method. One or more of the plurality of communications of the block data packet sequence are:
Receiving at least a portion of the block of data packet sequences;
Transmitting at least a portion of the block of data packet sequences;
8. The method of claim 7, comprising at least one of: receiving at least a portion of the block data packet sequence and transmitting at least a portion of the block data packet sequence. the method of. At least one of the synchronization start message, synchronization response message, exchange message, and block data packet sequence includes a data packet signal having a first plurality of signal characteristics;
Furthermore, the transmitting step, the listening step, and the executing step of claim 7 after the step of executing at least a part of one or more of a plurality of communications of the data packet sequence divided into blocks by the tester. Repetitive transmission, listening, and executing steps of the synchronization start message, the synchronization response message, the exchange message, and the block-divided data packet sequence of claim 7 At least one includes a data packet signal comprising a second plurality of signal characteristics;
The method of claim 8, wherein one or more of the second plurality of signal characteristics is different from a corresponding one or more of the first plurality of signal characteristics. 8. The step of performing at least a portion of one or more of the plurality of communications of the block-divided data packet sequence of the repeated transmitting, listening, and executing steps of claim 7 by the tester. Followed by further executing at least a portion of one or more of a plurality of communications of another block-divided data packet sequence by the tester, the executing step comprising:
Receiving at least a portion of the another block-divided data packet sequence;
Transmitting at least a portion of the separate block data packet sequence;
At least one of receiving at least a portion of the another block-divided data packet sequence and transmitting at least a portion of the another block-divided data packet sequence. The method of claim 9.   The method of claim 10, wherein the another block-divided data packet sequence includes a respective data packet signal having the same signal characteristics as the second plurality of signal characteristics. When at least one of the synchronization start and exchange messages of the repeated transmitting, listening and executing steps of claim 7 does not comprise the second signal characteristic;
The same signal characteristics as the first plurality of signal characteristics;
A data packet signal comprising one of the same signal characteristics as the first plurality of signal characteristics and a third plurality of signal characteristics;
The method of claim 9, wherein one or more of the third plurality of signal characteristics is different from each corresponding one or more of the first and second plurality of signal characteristics.

Images