测试脚本设计（context:smartcard)：isolate key failures from propagate failures

(This article is talking about a general test scrīpt design
approach with a smartcard application testing background)

During menu flow testing, we often design a scrīpt s.t it will take the menu flow as reference, once there's any discrepency, a lot general failure may encounter due to the mismatch of responses from card.

The reason we run into this situation is that we have an assumption that our card's aplication should follow the referece flow closely, and we predefined the 'expected' response sequence from the card in the scrīpt. In this case, any unexpected behavīor of the card, will make the scrīpt response and card application asynchronised, a lot "general”
will be generated.

This kind of design, which is used by most of testers, although works to test card applications, but does little to isolate failures and to reduce test cycle.

Think about a phone, it does not preassume any response from card, it simply responses soly depends on card real response. It provides a hint for us: we need to design the comparision module seperately. Every response from the card will be input to the module to verify the application, but response of the scrīpt is generated seperately to the module. In this design, even if there are some discrepency found, our test scrīpt still response according to the card's 'wrong' behavīor, propogated erros, in this case, will be minimized, key failures will be accurately identified and logged by the comparision module.