Your use of the terminology in your edited post and comments is problematic because you are not being clear enough. For example:
"I mean during Serial.begin(57600); I get garbage values. How can I skip this? " and "If I comment out I get nothing".
"By "When port is re-connected" means clicking "call" in HyperTerminal or openning Arduino serial monitor. First data is always garbage". There are others."
"An example screenshot of the output. When port is re-connected the first received data is not Test:" - But, the first received data you are showing is, in fact, the word Test.
There are others.
I will try to help by answering your main question which seems to be "How to prevent the garbage data" and note that I have not included "when the serial port is initialized".
Firstly, when I use my Uno and V 1.8.13 of the IDE, and I compile and run your sample program, I get the usual output showing progress of the compilation and upload to the board, and that text ends with "avrdude done. Thank you." At this point, the program is running and println is doing its thing.
When I open the serial monitor (by clicking on the box in the upper right corner of the full IDE screen - baud rate=57600, no line ending), I get corrupt characters at first. This always happens and I believe that is what you are seeing.
This happens because when you open the serial monitor, the UNO is being reset, but it is not the complete reset that is done when you upload code and begin execution. To be a bit simplistic, when you open the serial monitor, your program is running and the reset from opening the serial monitor is not the clean start that is done when you compile, upload and begin to execute the program.
Use either of these programs to test out what I am getting at.
void setup() {
// initialize serial:
Serial.begin(57600);
}
void loop() {
delay(10000);
while(1){
Serial.println("Test");
}
}
or
void setup() {
// initialize serial:
Serial.begin(57600);
delay(10000);
}
void loop() {
Serial.println("Test");
}
Go through your steps with either of these modified versions and open the serial monitor during the 10 second delay (unclick autoscroll to make it easier to see) and you will not get any corruption.
If, however, you compile/load/execute the program and then start opening and closing the serial monitor, you will start to see corruption in subsequent opens of the serial monitor - again because the reset when you open the serial monitor is not the clean reset that is done when you compile/load/execute.
Why doesn't everybody complain like crazy about the problem that you are experiencing? I think because folks learns to work with/around the way the UNO works. Your code just sends out serial data, so it is a prominent illustration of the issue, but it is not an insurmountable issue.
You can go deep into the serial monitor code and learn all about what is going on and come up with an elegant and likely tedious solution - I'm not sure, but I don't doubt that some have done this and it may even involve some hardware manipulation of serial control lines.
Alternatively, you can write the program to allow time to complete the serial monitor opening before you start sending out the data. You can even clean out any residual data (as long as you know what you are doing) if you anticipate multiple opening and closings.
Hope it helps.