No, a test harness in this case is not just a hardware thingy to stimulate different I/O.

No, you can't just test a complex state machine with a logic analyzer and a pattern generator.

Why? Because the state length of the state machines may take the pattern generator a billion years to try to swing through 2^128 alternatives.

So what do you do? In some situations, you create a software test harness where you can basically intersect different parts inside the software and perform module tests on modules that do have a manageable number of bits of state information.

A test vector machine have a hard time to step an int variable counter to "just before turn-over" before applying the different test patterns to see what happens at the turn-over time. What happens at overflow time if button 1 is pressed? What happens at overflow time if button 2 is pressed? What happens at overflow time if button 1 + 2 +3 + 4+ 5+ 6+ 7+ 8... 15 is pressed but not button 16? Let's say that this integer is 16 bits long and ticks at 1Hz. Then it takes 65536 seconds between each turn-around. Let's say that you want to test 2^16 different input stimuli at the time of turn-around. With a sw test harness you may do it in 2^16 quick tests. Without a test harness you would need to wait 2^32 seconds. Not fun to do such a test before every firmware release.

So the term test harness is very often used for test constructs for sw module testing. Many tools exists that can automatically generate both test patterns and the helper functions for such module testing. At least when using C and C++. Assembler can't really be machine-read to deduce the loop constructs, making it virtually impossible to auto-generate test setups.