每次接触到完全新的需求，在开始测试之前，似乎都会想到一个问题:是先严格按照需求文档来一项项验证功能，然后从用户角度去添加一些非正向使用场景，还是一开始就考虑采用一些探索测试方法论，对功能进行类型划分以求代码覆盖率。根据以往经验来看，这似乎不是一个简单的选择题...
一般来说，以需求为导向的测试本身并没有什么问题，但是往往需求本身定义的场景比较局限，也不会在需求定义的一开始就已经想到所有可能的使用场景。同时，作为产品设计的下游节点-开发，一向是考虑为实现需求所规定的功能为目标，自然容易忽略掉一些逆向情景，并在此暴露出很多使用入口给用户。这些属于需求描述场景之外的使用入口的不同组合，就是经常所见的很多bug的主要来源。
设计上无法面面俱到，开发实现上又没有效的规范去进行约束，开发出来的产品的质量自然难以仅参照需求就能有效保证了。
但是，我们能单纯从测试的一些方法论为导向去进行测试吗？我们知道，单纯从更好的保障测试覆盖率和质量，不考虑实际情况:项目周期，技术团队规模和产出效率，其他风险这些等等，测试理论会要求你永无止境的，使用无穷的组合方法进行无限的测试。显然，这是现实所不允许的，事实上我们既不能满足100%的覆盖率，也不可能总是能确保没有任何质量问题。所以完全以测试理论为导向没有可能，也没必要。
综合两种方式，很显然，我们既要求覆盖率和更好的质量，也要求测试投入可预期可控，最好的方式就是:在全局方面验证用户所需要的所有功能的场景，在场景局部上使用测试方法进行探索和演变。
也许是信口开河，也许是以偏概全，只有去思考，然后尝试了，才能知道结果对错，谁又能说不是呢？:-D
