Posted on 2005-11-26 10:37
canonical 阅读(538)
评论(0) 编辑 收藏 所属分类:
设计理论
软件开发是从设计开始的,
而设计的产物是一堆描述性的文档. 我们总是希望这些描述能够尽量完备, 例如在一个用例描述中我们总是希望加入尽量多的异常流描述,
尽量把所有的相关情况都同时呈现出来. 当我们对系统进行了大量的分解和分析工作之后, 往往会遇到一种理解上和验证上的困难,
即我们如何才能确保某个use case的运行结果恰好能够满足另外一个use case的输入需求, 整个系统能否精密的配合在一起.
此时我们可以依赖一些整体架构设计的文档描述, 或者补充更多的系统连接上的说明, 但是无论如何,
要在思维中同时把握那么多条执行路径是一件艰难的事情.
设计文档可以说是对系统行为的一种抽象性的规约,
为了验证这种抽象描述的正确性, 在缺乏理论保证的情况下, 我们唯一的选择就是抽样检验, 即我们需要构造一些测试用例,
特别是那些描述了一个完整业务流程的全局性的测试用例(用户故事). 在测试用例中, 我们并不需要构造出所有完整的执行路径,
只需要对一些关键性的业务路径进行检验就可以了, 局部的异常流处理很多时候都可以通过局部的单元测试来检验.
测试用例最好以测试代码的方式提供,而不是一组文本描述. 我们应该尽量在开发的早期使得全局测试用例就能够运行起来,
使它成为系统演化的驱动力之一, 并根据系统开发的进展同步的进行调整. 测试驱动开发(Test Driven
Development)所指的绝不仅仅是对单个类所进行的单元测试(Unit Test).
Test的一个重要作用在于实例化所有必要的抽象约束条件, 通过sample来驱动系统的发展.