Today I've been reading about
CREATE USER testusername WITHOUT LOGIN
CREATE LOGIN testl
WITH PASSWORD = 'test'
CREATE USER test
FOR LOGIN testl
GRANT SELECT, INSERT, UPDATE ON Doctor TO test
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
EXECUTE AS USER = 'test'
INSERT INTO Doctor VALUES ('Johnson', 'Jack',2)
UPDATE Doctor SET Dep_ID=2 WHERE Doc_ID=71
REVOKE SELECT, UPDATE, INSERT ON Doctor FROM test
/*DROP USER test
DROP LOGIN testl*/
Cannot grant, deny, or revoke permissions to sa, dbo, entity owner, information_schema, sys, or yourself.
Msg 15151, Level 16, State 1, Line 2
Cannot drop the user 'test', because it does not exist or you do not have permission.
Msg 15151, Level 16, State 1, Line 3
Cannot drop the login 'testl', because it does not exist or you do not have permission.
Your room and cabinet analogy is basically correct. Logins are server (or more accurately SQL instance) level principals whereas users are database level principals.
The user without login could be thought of as a file clerk locked in the room (never enters the room from the outside) and assigned to a single file cabinet. The security context of a user without a login is confined to that database only.
Your "master key" analogy maps to server roles. For example, a login that is a member of the sysadmin server role has full control over all databases on the SQL instance and is automatically mapped to the dbo user in all databases.
The reason for the error after running the script is that you are still running under the context of the test user. You need to execute
REVERT; to return to your original security context.