You see - you don't want to invest time to find out exactly what's wrong with those supposedly bad parts, but you insist on that a simple digital test will screen the bad parts in the future...

As I said previously more times - I don't think so. Without knowing the internal details and ignorng the analog nature of many if not most possible faults, you are barely going to get reliably consistent results.

But it's certainly entertaining to think out how to perform such digital "symptomatic" testing, it is.

It is clear that a full test vector is impossible to run (and maybe even to create), For example, just think of the ALU - there are 8 different operations possible (add, addc, subb, mul, div, anl, orl, xrl) which have 2*8+1 bit input (2 byte operand and carry) that's 2**20 test cases (we are simplifying a bit but this is only an illustration); and let's optimistically assume, that we can somehow prepare the test, execute and check the result (including all flags, proper storage of result and check that anything else won't get corrupted) within 1000 instructions - that's 1E9 instructions. A quarter of hour on the plain vanilla - and that's only ALU.

And what about the jump adder testing? Even unconditional absolute jumps are tricky to test, and we have page and relative and conditional jumps, calls and returns...

But let's assume the execution time is not an issue - you have them on stock anyway, so maybe a week or two of test run time does not really matter. But to write such a test sounds to be a colossal job, too...

I have an idea, you might like it or not - what about running a random set of instructions simultaneously on a known good system and a system under test, interrupting from time to time to crosscheck the internal state... For a better sounding name, we can call it "Monte Carlo testing" :-)

JW