Existing testing methodology for RELAP5-3D employs a set of test cases collected over two decades to test a variety of code features and run on a Linux or Windows platform. However, this set has numerous deficiencies in terms of code coverage, detail of comparison, running time, and testing fidelity of RELAP5-3D restart and backup capabilities. The test suite covers less than three quarters of the lines of code in the relap directory and just over half those in the environmental library. Even in terms of code features, many are not covered. Moreover, the test set runs many problems long past the point necessary to test the relevant features. It requires standard problems to run to completion. This is unnecessary for features can be tested in a short-running problem. For example, many trips and controls can be tested in the first few time steps, as can a number of fluid flow options. The testing system is also inaccurate. For the past decade, the diffem script has been the primary tool for checking that printouts from two different RELAP5-3D executables agree. This tool compares two output files to verify that all characters are the same except for those relating to date, time and a few other excluded items. The variable values printed on the output file are accurate to no more than eight decimal places. Therefore, calculations with errors in decimal places beyond those printed remain undetected. Finally, fidelity of restart is not tested except in the PVM sub-suite and backup is not specifically tested at all. When a restart is made from any midway point of the base-case transient, the restart must produce the same values. When a backup condition occurs, the code repeats advancements with the same time step. A perfect backup can be tested by forcing RELAP5 to perform a backup by falsely setting a backup condition flag at a user-specified-time. Comparison of the calculations of that run and those produced by the same input w/o the spurious condition should be identical. Backup testing is more difficult the other kinds of testing described above because it requires additional coding to implement. The testing system constructed and described in this document resolves all of these issues. A matrix of test features and short-running cases that exercise them is presented. A small information file that contains sufficient data to verify calculations to the last decimal place and bit is produced. This testing system is used to test base cases (called null testing) as well as restart and backup cases. The programming that implements these new capabilities is presented.