昨天的一位同事和我讨论一个被测试对象。讨论之后觉得颇有所得，所以拿出来分享。

　　被测试对象是一个DSL描述的系统，通过输入一个DSL的输入文本，定义一个复杂的规则，使用这些规则来控制被测试对象的一个系统。

　　遇到这样的被测试对象，我第一反应时，首先，DSL的语法实现应该是一个比较重要的测试点。然后就是要映射出DSL中所表述的每一个要点，是否可以完全被系统所接受。然后用几个实用的场景数据跑一下，就可以说测试过程结束了。

　　但是接下来我关心的事情是，这个程序是谁开发的。开发同学的能力和性格决定了被测试对象的稳定性。这个程序的开发同学我很熟悉，是典型的完美主义者，做事情非常稳健，所以我想当信任他写的代码。根据开发人员的情况，我第一反应是，DSL语法解释引擎是不是使用了现成的框架。最后得到的情况是，果然会使用antlr作Parser Generator。那么第一步DSL语法测试，应该就已经不是问题了。因为Antlr一定是已经经过测试的开源产品，可以用来直接使用的。

　　然后考虑第二步，如何验证DSL语句中的每一个表述都被正确的被系统理解。这个测试我的想法是把表述的意义归类，然后用过等价类划分的方式测试其中的一些，然后通过灵活的自动化测试框架，比如说数据驱动的框架，帮助测试人员做完整的测试。其实到了具体测试，就会考虑到，这种测试更容易在单元测试完成。所以我问了单元测试覆盖率。出于意料，代码覆盖率接近100%。那这一步，其实已经覆盖了。而且开发人员的专业和谨慎让我非常放心。测试人员其实只需要对开发的单元测试进行简单review，就可以确认覆盖。

　　第三步场景测试则是没有办法省略掉的。测试人员需要整理，制造和使用场景接近的DSL语句，提供给被测对象，进行测试。

　　分析到这里，也许你会开始质疑测试人员存在的意义了，如果只是简单的场景测试，我们测试人员还有什么存在的意义呢？其实当开发人员非常专业和谨慎的情况下，测试人员并不是必须的。Facebook不是号称没有测试人员吗？遇到这样的开发人员，测试人员更应该庆幸，因为没有自己，整个产品的质量也是可以得到保障的。

　　那最后一步场景测试可以省略吗？我认为不可以，因为场景测试是站在用户考虑问题的，这是最后一道把关，所以是必须做的。而且如果在这一步做一点自动化，也可以提高之后的回归效率。

　　最后总结一下：

　　1、测试范围的确定要因开发而异。

　　2、测试范围的确定也要根据开发的单元测试覆盖情况而定。

　　3、专业且谨慎的开发时测试人员的福气。