Most computing systems utilize firmware to control their low-level operation. In many computing systems, the firmware provides functionality for performing a power-on self-test (“POST”) of the computing system, for performing an initial program load, or boot, of the computing system, for providing interfaces to the low-level operation of the computing system hardware to an operating system, and for performing other functions. Because the firmware controls the low-level operation of a computing system, it is imperative that the firmware operates without program errors, sometimes called “bugs.” Because of the complexity of most computing system firmware, however, this type of software can be very difficult to test and debug.
One commonly used mechanism for testing the operation of a computing system firmware involves installing an operating system on a computer system under test (“SUT”). If errors are detected during the installation of the operating system, the errors can be utilized to identify bugs within the computing system firmware. This process is typically repeated for many different operating systems and, potentially, many different versions of the computing system firmware. There are cases where slight variations in task completion time, or other timing problems or delays could cause installations to fail. Therefore, it is also useful to test the identical operating system installation multiple times; something that might be referred to as “burn-in” testing. Because this testing process is typically performed manually by a human operator, however, this process can be extremely time consuming, costly, and prone to human errors due to the often repetitive nature of these tasks.
It is with respect to these and other considerations that the disclosure presented herein has been made.
USPTO Backgrounds
USPTO Backgrounds