Sample Driven Development

软件开发从设计开始,设计文档是系统行为的抽象规约。为验证其正确性,需抽样检验,构造全局性测试用例,对关键业务路径检验,局部异常流可用单元测试。测试用例最好以代码形式,早期运行并随开发调整,测试驱动开发不只是单元测试。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值