排名前十的验证忠告
1.这是遗留下的代码，所以不用验证
-小心！你能 100%保证你面对的是经过硅验证的代码吗？你能保证没有在上次工作之后
没有任何人碰过这代码吗？
2.我可以在 5 分钟内就把补丁加上
-只要你能保证你的验证环境不像是一大堆补丁堆在一起形成的，这样做到也可以。但
是想一下从今天起用一周时间来修改和修正你的验证环境是一件容易的事吗？难道多用几
分钟时间来写一个更健壮的代码不是更好吗？
3.随心所欲地计划和开始测试
-这是大大地错了！即使你的工作是小菜一碟你也要提前做好计划。你会惊讶地发现可
以避免多少无谓的问题。铭记 5 个 P:合适的计划排除差的性能。(proper planning prevents
poor performance)
4.这工作很简单，不必作测试计划
-将测试计划当作你的工作合同。你加入其中的定义了你当前所要做的工作，如果工作
真的很简单，就用半页纸把测试计划写下来。
5.验证不是产品，所以不必遵循软件标准
-验证的确不是产品，但是你仍需处理数千行的代骊，所以你最好可以确保一定程度的
一致性，更不用说可能存在代码错误的可能了。
6.别花时间在写注释上
-还记得最近一次你花费半天时间在反向研究别人的代码上吗？那么对于你自己写的代
码呢？更好的做法是，在开始每个测试前，保证代码中有足够的注释解释程序步骤，并要保
证注释的更新。
7.我知道了！让我们从外部强制这个信号的值就 OK 了
-强制的信号值往往会在整个流程中被遗忘，并在最后阶段才被发现，这时通常只有一周就
tapout 了！所以要极端的小心。
8.必须在后台一直运行回归运行(regression running)
-单纯的回归运行不能完成所有工作。你必须有一个分析人员(Regression Sitter)来监
视和分析运行结果-否则就是在白白磨损服务器！
9.我们己经实现了 100%的覆盖率真，所以没有必要再运行更多的测试了！
-实际上并不是这样。你的覆盖率模型只能捕捉到你提前想到的东西。很明显随机测试
平台可以产生能揭示出 bug 的额外情景。所以不要在 100%时停止。相反，要在这时加强覆
盖率模型。
10.验证应该寻找 bugs-这是一个很普遍的对验证工作的误解。验证者应该将注意力放在建立一个构建得很好的，强健和完整的测试平台上。bugs 将会自己被检测出来。
