Ok, that makes more sense. Myself, I haven't done an OS/DB migration, but I have performed many system copies, and Unicode migrations, using both backup/restore and r3load-based methods. But, none of them required a key, so I was going from memory of when I have seen the field that asks for the key.
SWPM does have such a field, so testing may not be GUI-based, but actually performing the migration, and entering the key, can certainly be done in the GUI. I don't know if that's what's taught for certification, but that is how the tool should work. If no key is required, one simply leaves the field blank, but if it's heterogeneous, then you can enter it in this field, no command-line required.
Based on how other similar tools have operated for me, and upon looking at the options for r3load, I think that "r3load -K" option is simply a way of determining that the key is valid for your installation number. You would simply type "r3load -K <key>". I think it's unlikely you need to have already performed the export and or have done much of the installation of the target system. You probably just need to run it while logged onto your source system console as sidadm.
The logfile seems to just go to stderr by default, i.e. to console output. I just experimented a little on on my sandbox system to see what would happen. I don't have a key to test, of course, so I was just looking to see what log messages were generated.
Anyway, have a look, and/or rephrase the question, over at the Software Logistics space that I linked earlier. That's where the support experts and the developers of these tools hang out.