When doing a Serial Loopback Test on a USB Port (assume COM1) using Hyperterminal or any other serial terminal (i.e. PuTTY), you can verify that the test passed if what you type on the keyboard is displayed on the Terminal (although it's not for all characters).
My question is: What's happening underneath? So, the keyboard sends data to its USB port COM2 (assume it's connected there): What makes the COM1 Port resend and receive data, which I presume is the same data sent by the keyboard, then displayed on the terminal?
Is the keyboard data received on COM2 and redirected by hardware to all other USB ports so COM1 (the adapter) receives it internally in some way, then sends it out and receives it back?
Actually, I'm using a laptop, so it's one port used here for the Serial/USB adapter (I'm using an FTDI module), not two ports as I just tried to show an example.
The question is pretty wide, but I give it a try:
The COM ports you connect are the typical PC implementation of the RS-232 serial interface. A Loopback configuration is just what the name suggests: Among the signal lines of the RS-232, the Transmitted Data line (TxD) is looped back to the Received Data line (RxD) of a port at the same host.
You could also perform a similar (yet more simplistic) test using a minimal configuration where the loopback is just a direct "paperclip test" loopback between the TxD/RxD lines of the very same COM port. With only little abstraction, the logical loopback you build from one COM port of a PC to another COM port at the same PC has in common the feature that you can see your own transmission being returned at the same display screen.
The important feature why such a test works easily on the serial port of your example is that the interface is so low-level that there is no connection layer (or hardware feature) in between on which the receiver side could notice that the signals aren't posted by an external peer host, but that they come from the local host.
The connection between the two COM ports (of your PC and the adapter at your PC) forms the core part of the loopback test arrangement. Your question suggests that you are interested in what is going on beyond the serial connection itself, so please continue reading below...
From the keyboard to the screen, there are various (hardware and) software components involved. The details of these depend on your actual PC installation, but some properties of it can be described independently from what exactly you have. For example, the question whether you have two native COM ports or one native plus another one that is emulated on a USB port is not relevant to the question what happens on the serial line actually (because it is the job of the adapter that the other side is compatible with native COM ports).
On the PC, you run a terminal emulation program, which is normally used to communicate with some sort of external peer, transmitting and receiving characters to/from the full-duplex connection. Although this is not necessary, a typical communication mode is that ASCII data is exchanged in a ping-pong scheme where one side holds a client/master role, and the other implements a server/slave that receives requests and issues responses. Then (typically) the server-side can be implemented by a Linux/Unix PC running an interactive shell that is driven through the serial line instead of a native (non-emulated) console terminal composed of a keyboard and a display screen.
Now imagine that you have cut off the external peer, installed the loopback and you are listening to yourself. Then, everything you enter through your keyboard will
If you use one USB-emulated COM port as you wrote, the signal runs through the adapter dongle and its corresponding driver software instead of the simpler way the data takes at the native port.
If you were running a "port loopback" (special cabling at a single COM port), the output text would show up in the receiver window of the same terminal emulator where you posted your input text.
If you run a "host loopback" between two ports, you normally need two running instances of the terminal emulator (or emulators - you could also have Hyperterminal talk to PuTTY for example). You are typing to one instance, and the received text shows up at the other one. - Well, plus one extension: Usually, terminal emulators "echo" the input text to their local output part so that the user can verify (and remember) what has earlier entered and transmitted to the underlying line. Since experimenting with loopbacks is not the main purpose of terminal emulators, the default configuration is often to have this echo activated. That is, you will probably see the text you enter echoed on the "INPUT" side (type it once, read it right there) as well as once in the window on the "OUTPUT" side (which depicts what came through the serial connection. The echo part is delivered within your terminal emulator program (look up its code yourself if it is OSS), the received part is delivered through the serial line.
If you would like to verify this for educational purposes, try to reconfigure the "INPUT" terminal emulator not to echo - you will see the output only on the window you didn't activate while typing. Then, solder another connector to your loopback cable/plug and attach it to a different "sniffer" machine (which only listens but doesn't transmit by itself): Here you can read everything that is actually transferred through the loopback line.