我是一名测试攻城狮。
一块SSD到不同客户手上，不知道会接在什么机器，使用什么样的OS和Host驱动，在什么环境下使用，
结合巨大的使用数量，不知道哪天某块SSD就会从Host那边收到一个不按套路出牌的FIS或者Primitive （SATA SSD）。
举个例子: Host发了一个读命令，SSD二话不说开始干活，辛辛苦苦把Data从NAND里读出来， 仔仔细细的进行ECC Decode，小心翼翼传到DDR，进行MPECC检查，再全神贯注的传到SATA模块的某个FIFO，这时候SSD抹抹头上的汗，把手擦干净，写了一张字条，上书”X_RDY”, 恭恭敬敬的递给Host， 然后把data捧在怀里，细心的用SOF包装好，殷切的期盼Host也回复一张小字条”R_RDY”。Host十分感动的看着SSD，然后回复了一句”R_ERR”拒绝了他。
林子大了，什么样的客户都有，但是客户们的要求是一样的 – “Host虐你千百遍，SSD你要待他如初恋” — 术语叫做Robustness （健壮性）。
为了保证健壮性，ASIC和FW固件攻城狮们要花大量的精力，脑补各种错误可能性，在RTL和FW 中加入相应的Error Handling的流程。
这么做有两个问题：
- 这些Error handling的流程，在Lab里面跑个一礼拜，可能也撞不到一个；
- 再牛的攻城狮，也没法提前考虑到各种错误可能性；
搞测试的就是平时给ASIC和FW找麻烦，麻烦真大了的时候帮他们解决麻烦，以SATA SSD来说，可以用一种工具 — Jammer.
下图中小的那个就是一款SATA Jammer。
Analyzer就是一个窃听器，让你知道Host和Device之间发生了什么。
Jammer就是一个邮递员，Host和Device之间所有的通信都必须经过他的手，然后Jammer可以把信拆开，将里面的内容修改或者替换，再转发出去。
结合之前的例子，我们可以把正常Host回复R_RDY改成R_ERR, 从而检查SSD遇到这种情况处理是否正确。
下面是张操作截图 – 向一个Data FIS中故意注入CRC Error。
通过在SATA链路上创建各种不同的错误，可以确认各种Error Handling的流程是否正确，或者完善，甚至增加新的流程。
Jammer还有别的用处， 当你想知道某种Scenario发生以后Host或者Device的反应时，你可以通过Jammer来知道答案。比如当Device回复的SDB里面Error Bit被置上，或则Device一直不发SDB时，Host是不是会重发命令，重发几次，重发多次Device都没反应的话Driver会不会启动OOB，Application会不会报错?
这货不便宜，但你值得拥有。
