当我们拿到需求文档的时候，往往是阅读一遍就开始按照需求写测试用例，然后执行测试用例，一般留于表象的功能都不会有问题，比如：测试一个发送短信的功能，表象上看来，发短信这个功能是主要测试点，保证能发出去这是基本的，所以开发一般不会在这里犯错误，错误往往在于：发短信给“谁”，这个“谁”取值经常会有问题，由于数据库庞大，字段复杂，字段名相似度也很高，这个“谁”的取值就会出现各种各样的问题。我们写测试用例应该建立在对需求非常透彻的分析之后的基础上，这样才能保证最深层的问题能被挖掘出来。

    举几个简单的例子：

    1、接口：很多需求文档会忽视这部分内容，尤其是通过接口交互的系统，如果一个系统升级或者发生变化，可能会影响到接口连接到的别的系统，这里是需求、开发、测试最容易忽略的测试点；许多接口往往是用来传送字段的，对于传送很少量字段来说，测试起来非常容易，而对于有很多字段需要传送，并且显示的字段名在两个交互系统之间不一致时，会比较麻烦；更为繁琐的是：一旦交互系统中的一个进行了升级或者变更，更有可能影响到接口，而此时这里是最容易被忽略的，所以测试时一定要注意这里，即：多次升级变化对接口的影响。

    2、逻辑：一份好的需求文档会把逻辑分析的比较透彻，阅读理解起来也比较容易，但是在开发设计阶段可能由于各种原因没有充分透彻的理解需求中的逻辑，等到测试时，如果流于表象，那么深层次的设计问题就不会被发现；所以测试之前要透彻的分析出需求文档中所隐含的各种逻辑，最好画出逻辑分析图，以便能更清晰的进行测试，发现深层次的问题。