USPatentGranted
B2

Electronic device, system, and method for testing exception handling mechanism

Granted 17 Feb 2015 · no office action yet

Life of the patent

9 dated events
⤢ drag to zoom20122014201620182020202220242026202820302032ProsecutionOwnershipTerm & fees
ProsecutionOwnershipTerm & feeshover for detail · click to open

Abstract

A method for testing exception handling mechanism of an electronic device, the method includes: establishing a connection between the electronic device and another electronic device when the electronic device is booting up. Obtaining parameters of a timer of the electronic device in response to an operation of a user, and determining whether the parameters are satisfied by the another electronic device. Simulating an abnormal event to cause the electronic device not to start up successfully if the parameters are satisfied by the another electronic device. Determining that the exception handling mechanism of the electronic device works well when the parameters do satisfy the requirement and when the other electronic device is in fact restarted or turned off after an abnormal event has been simulated via the other electronic device.

Description

4 parts
›BACKGROUND

1. Technical Field

The present disclosure relates to electronic devices, and particularly to an electronic device with an exception handling mechanism, a system, and a method capable of testing an exception handling mechanism.

2. Description of Related Art

Electronic devices, such as smart phones, electronic readers, and computers, usually have exception handling mechanism. For example, when the electronic device to crash or displays the “blue screen of death”, the electronic device can be restarted due to the exception handling mechanism. To guarantee that the exception handling mechanism of the electronic devices works well, a related test for the exception handling mechanism is needed before the electronic devices leave the factory. The method for testing the exception handling mechanism of related art is to simulate an abnormal event by the electronic device itself to trigger the electronic device to run the exception handling mechanism, and detect whether the electronic device is restarted to determine whether the exception handling mechanism works well. However, such method is only capable of testing the exception handling mechanism when the electronic device is already running within an operating system environment. If the electronic device is booting up, the electronic device cannot simulate the abnormal event and the exception handling mechanism cannot be tested.

Therefore, an electronic device, a method, and a system, for testing an exception handling mechanism, to overcome the described limitations are thus needed.

›BRIEF DESCRIPTION OF THE DRAWINGS

Many aspects of the present disclosure are better understood with reference to the following drawings. The components in the drawings are not necessarily drawn to scale, the emphasis instead being placed upon clearly illustrating the principles of the present disclosure. Moreover, in the drawings, like reference numerals designate corresponding parts throughout the several views.

FIG. 1 is a block diagram of a system for testing exception handling mechanism of an electronic device, in accordance with an exemplary embodiment.

FIG. 2 is flowchart illustrating a method for testing exception handling mechanism of an electronic device when the electronic device is booting up, applied in a system, such as that of FIG. 1 , in accordance with an exemplary embodiment.

FIG. 3 is flowchart illustrating a method for testing exception handling mechanism of an electronic device after boot up, applied in a system, such as that of FIG. 1 , in accordance with an exemplary embodiment.

›DETAILED DESCRIPTION · 1 of 2

Embodiments of the present disclosure will be described with reference to the accompanying drawings.

FIG. 1 illustrates an embodiment of a system 100 for testing the exception handling mechanism. The system 100 includes a first electronic device 1 and a second electronic device 2 . The first electronic device 1 is an electronic device needing to be tested. The first electronic device 1 can be a computer, a smart phone, an electronic reader, or a digital photo frame, for example. The second electronic device 2 can also be a computer, smart phone, digital photo frame, or electronic reader. The first electronic device 1 and the second electronic device 2 can be the same or be different devices. For example, the first electronic device 1 is a smart phone, and the second electronic device 2 is a computer.

As shown in FIG. 1 , the first electronic device 1 includes a processing unit 10 , a timer 11 , an execution circuit 12 , and a communication unit 13 . The processing unit 10 includes an update module 101 , an abnormal simulation module 102 , and a result analysis module 103 . The update module 101 repeatedly updates the timer 11 after the lapse of a first predetermined time t 1 . In the embodiment, the timer 11 is a countdown timer and counts down from a timing length t 2 when the timer 11 starts the countdown period. In the embodiment, the first predetermined time t 1 is shorter than the timing length t 2 , the timer 11 is updated and reset with the timing length t 2 again before the timer 11 counts down to zero. As is well known, if the exception handling mechanism of the first electronic device 1 is operating properly, when the first electronic device 1 suddenly crashes, the update module 101 cannot update the timer 11 and the timer 11 counts down to zero and outputs an interrupt signal to the execution circuit 12 when it has counted down to zero. The execution circuit 12 then turns off or restarts the first electronic device 1 when an interrupt signal is received. Then, if the exception handling mechanism of the first electronic device 1 works well, when the first electronic device 1 crashes suddenly, the first electronic device 1 will be restarted or turned off.

The abnormal simulation module 102 is used to simulate an abnormal event in response to an operation of a user after the first electronic device 1 has booted up and entered an operating system environment. In the embodiment, the abnormal event is a crash event, such as a blue screen of death event.

The result analysis module 103 detects whether the first electronic device 1 is restarted or turned off, to determine whether the exception handling mechanism of the first electronic device 1 works well, after the abnormal simulation module 102 has simulated the abnormal event. In detail, the result analysis module 103 detects whether the timer 11 outputs the interrupt signal and detects whether the execution circuit 12 executes its function, namely that the execution circuit 12 does restart or turn off the electronic device 1 after abnormal simulation module 102 has simulated the abnormal event, and produces corresponding test result. If the first electronic device 1 is restarted or turned off, the result analysis module 103 determines that the exception handling mechanism of the first electronic device 1 works well when the first electronic device 1 has entered the operating system environment. The operating system can be a Windows or any other operating system.

In the embodiment, the first electronic device 1 also includes a communication unit 13 . The second electronic device 2 includes a processing unit 20 and a communication unit 21 . The communication unit 21 communicates with the communication unit 13 of the first electronic device 1 . The processing unit 20 includes a parameter obtaining module 201 , an abnormal simulation module 202 , and a result analysis module 203 . In the embodiment, the communication units 13 and 21 can be wired ports, such as USB ports, PS/2 ports, and iEEE1394 ports.

When the first electronic device 1 is booting up and has not yet entered the operating system environment, the second electronic device 2 tests the exception handling mechanism of the first electronic device 1 , in response to the operation of the user. The user connects the first electronic device 1 with the second electronic device 2 via the communication units 13 and 21 and triggers the second electronic device 2 to test the exception handling mechanism of the first electronic device 1 via operating a preset button or a menu.

In detail, the parameter obtaining module 201 obtains parameters of the timer 11 of the first electronic device via the communication units 13 and 21 , and determines whether the parameters satisfy a requirement, in response to the operation of the user. In the embodiment, the parameters of the timer 11 include the timing length t 2 of the timer 11 , the parameter obtaining module 201 determines whether the timing length t 2 of the timer 11 is less than a predetermined period of time t 3 to determine whether the parameters in fact satisfy the requirement.

Normally, the first electronic device 1 is in a final stage of the bootup process and is about to enter the operating system environment when the timer 11 is activated and starts to count down the timing length t 2 . If the first electronic device is booting up normally, the first electronic device 1 enters the operating system environment before the timer 11 has counted down to zero. If the first electronic device 1 is not booting up properly, and hangs at some stage, then the timer 11 counts downs to zero and outputs the interrupt signal to trigger the execution circuit 12 to restart or turn off the first electronic device 1 . Normally, the first electronic device 1 will enter the operating system environment within the predetermined period of time t 3 , thus the timing length t 2 of the timer 11 should be substantially less than the predetermined period of time t 3 to ensure that the first electronic device 1 can be restarted or turned off in case the process of booting up of the first electronic device 1 is abnormal.

›DETAILED DESCRIPTION · 2 of 2

If the parameter obtaining module 201 determines that the parameters do not satisfy the requirement, namely that the timing length t 2 of the timer 11 is longer than the predetermined period of time t 3 , the result analysis module 203 determines that the exception handling mechanism of the first electronic device 1 does not work well, and records a test record.

If the parameter obtaining module 201 determines that the parameters do satisfy the requirement, namely that the timing length t 2 of the timer 11 is less than the predetermined period of time t 3 , the abnormal simulation module 202 simulates an abnormal event and prevents the first electronic device 1 from entering the operating system environment. The result analysis module 203 detects whether the first electronic device 1 is restarted or turned off after the abnormal simulation module 202 has simulated the abnormal event. If the first electronic device 1 is not restarted or turned off, the result analysis module 203 determines that the exception handling mechanism of the first electronic device 1 does not work well.

In the embodiment, when the first electronic device 1 is booting up, the result analysis module 203 determines that the exception handling mechanism of the first electronic device 1 works well only when the parameters of the timer 11 in fact satisfy the requirement and when the first electronic device 1 is actually restarted or turned off after the abnormal simulation module 202 has simulated the abnormal event.

In one embodiment, the first electronic device 1 itself tests the exception handling mechanism after the first electronic device 1 has entered the operating system environment, and the second electronic device 2 tests the exception handling mechanism of the first electronic device 1 during the bootup process of the first electronic device 1 .

In another embodiment, it is the second electronic device 2 which tests the exception handling mechanism of the first electronic device 1 when the first electronic device 1 is booting up or after the first electronic device 1 has entered the operating system environment. Namely, in this other embodiment, the abnormal simulation module 202 and the result analysis module 203 of the second electronic device 2 also execute their functions of testing the exception handling mechanism of the first electronic device 1 after the first electronic device has entered the operating system environment.

Referring to FIG. 2 , a flowchart illustrates a method for testing exception handling mechanism of the first electronic device 1 when the first electronic device 1 is booting up and before it has entered an operating system environmentThe method is applied in the system 100 as shown in FIG. 1 . In step S 210 , a connection between the first electronic device 1 and the second electronic device 2 is established when the device is booting up, in response to user's operation.

In step S 211 , the parameter obtaining module 201 obtains parameters of the timer 11 of the first electronic device 1 via the communication units 13 and 21 , and determines whether the parameters satisfy the requirement. In the embodiment, the parameters of the timer 11 include the timing length t 2 of the timer 11 , the parameter obtaining module 201 determines whether the timing length t 2 of the timer 11 is less than a predetermined time t 3 and produces a result of comparison accordingly.

If the parameters do not satisfy the requirement, the process goes to step S 216 . Otherwise, in step S 212 , the abnormal simulation module 202 simulates an abnormal event and prevents the first electronic device 1 from entering the operating system environment.

In step S 213 , the result analysis module 203 detects whether the first electronic device 1 is in fact restarted or turned off after the abnormal simulation module 202 has simulated the abnormal event.

If the first electronic device 1 is not actually restarted or turned off, the process goes to step S 216 . Otherwise, in step S 214 , the result analysis module 203 determines that the exception handling mechanism of the first electronic device 1 works well.

In step S 216 , the result analysis module 203 determines that the exception handling mechanism of the first electronic device 1 is not working well and records a test result.

Referring to FIG. 3 , a flowchart illustrates a method for testing exception handling mechanism of the first electronic device 1 after the first electronic device 1 has entered an operating system environment. The method is applied in the system 100 as shown in FIG. 1 .

In step S 218 , the abnormal simulation module 202 / 102 simulates an abnormal event and causes the first electronic device 1 to crash after the first electronic device has entered the operating system environment.

In step S 220 , the result analysis module 203 / 103 detects whether the first electronic device 1 is restarted or turned off after the abnormal simulation module 202 / 102 has simulated the abnormal event.

If the first electronic device 1 is not restarted or turned off, the process goes to step S 222 . Otherwise, in step S 221 , the result analysis module 203 / 103 determines that the exception handling mechanism of the first electronic device 1 works well.

In step S 222 , the result analysis module 203 / 103 determines that the exception handling mechanism of the first electronic device 1 is not working well and records a test result.

It is believed that the present embodiments and their advantages will be understood from the foregoing description, and it will be apparent that various changes may be made thereto without departing from the spirit and scope of the disclosure or sacrificing all of its material advantages, the examples hereinbefore described merely being exemplary embodiments of the present disclosure.

Claims

14 · 3 independent · depth 3
1234567891011121314
14 granted claims

Classifications

4 codes
IPC · International Patent Classification
Section G — Physics
  • G06F11/22
  • G06F11/26
  • G06F11/00
USPC · US Patent Classification
714/15

Claim changes

Soon
Coming soonHow the claims changed between publication and grant

See which claims were amended, added or cancelled during examination, with every added and removed word marked.

AmendedAddedCancelledUnchanged

The published claims of this patent are not paired with the granted ones in what we hold.

File wrapper

⤢ drag to zoomOct 2012Jan 2013Apr 2013Jul 2013Oct 2013Jan 2014Apr 2014Jul 2014Oct 2014Jan 2015Apr 2015USPTOApplicantExaminer-initiated interview
USPTOApplicanthover for detail · click to open
Pendency
2.3 y
827 days filing → grant
Office actions
0
none on record
Interviews
1
examiner interview summaries
Examiner
Amine Riad
art unit 2113 · TC 2100
Citations: 14 back · 1 forward

See the full prosecution history — every USPTO and applicant action on this file, in order.

Log in to unlock

Chain of title

⤢ drag to zoom20122014201620182020202220242026202820302032Owner 1Owner 3
Titlehover for detail · click to open

See the full assignment history — every owner this patent has passed through, with recordation dates and reel/frame numbers.

Log in to unlock

Term & fees

See the term timeline — pendency span, in-force span, the maintenance fees paid and both computed expiry dates.

Log in to unlock

Priority chain

1 priority documents
›Priority documents — 1
TypeDocumentDate
related publicationUS 20130318400 A128 Nov 2013

Worldwide family

4 members · 3 offices
US2CN1TW1
this patentIP5 & PCTother officessolid = grantedhover for detail · click to open
Members
4
DOCDB simple family 49622538
Offices
3
US · CN
Granted
1 of 4
grant date present
›IP5 & PCT — 3 members
OfficePublicationKindPublishedFiledStatusTitle
USUS-2013318400-A1A128 Nov 201312 Nov 2012publishedElectronic device, system, and method for testing exception handling mechanism
USthis patentUS-8959394-B2B217 Feb 201512 Nov 2012grantedElectronic device, system, and method for testing exception handling mechanism
CNCN-103425541-AA4 Dec 201325 May 2012publishedElectronic device, system and method for exception handling mechanism detection
›Other offices — 1 members
OfficePublicationKindPublishedFiledStatusTitle
TWTW-201348953-AA1 Dec 20131 Jun 2012publishedElectronic device, system, and method for testing exception handling mechanism

Validity challenges

See the validity challenges on record — reexaminations, IPRs and PGRs, with their institution decisions and outcomes.

Log in to unlock

Citations

See every patent this one cites and every patent that cites it back — publication, assignee, and how each one was found.

Log in to unlock