Disable lock_release_all
The lock system is initialized during bootstrap (during the DRUPAL_BOOTSTRAP_VARIABLES phase, which follows the DRUPAL_BOOTSTRAP_DATABASE one) using the following code.

// Initialize the lock system.
require_once DRUPAL_ROOT . '/' . variable_get('lock_inc', 'includes/lock.inc');
lock_initialize();


You could:


Bootstrap Drupal to the DRUPAL_BOOTSTRAP_DATABASE phase
Change the value of the lock_inc Drupal variable to make it point to an include file containing your implementation of the lock system, with functions that don't do anything
Execute the rest of the code, including the one to raise the bootstrap level to the desired one


Since you are loading other modules, this resolves the problem with the lock database table, but it doesn't avoid that modules try to access a database table that normally exists on a Drupal installation, including the ones they install. If you need to execute a query (for example, a SELECT) on a database that is different from the default one you could use the following code.

Database::addConnectionInfo($db_alias, 'default', $test_database);
query = Database::getConnection('default', $db_alias)-&gt;select('table name', 'table alias');
// The rest of the code goes here.


The first two arguments for Database::addConnectionInfo() and Database::getConnection() are flipped: The first argument of Database::addConnectionInfo() becomes the second argument of Database::getConnection(), and the second argument of Database::addConnectionInfo() becomes the first argument of Database::getConnection().