测试驱动开发,有没有人知道是怎么回事?
测试驱动开发,有没有人知道是怎么回事?reply
一般来说就是测试的桩。象在手工测试中的e测试数据，
不过当测试的力度很大时，你就需要一个小程序让这个系统活动起来。
这就使驱动测试！
抛砖引玉！ 测试驱动开发---TDD 好像集成测试中要用到~！它是系统测试前的测试工作，测试时分为增量测试和非增量测试！ 1#说的大概是驱动单元的开发吧。
单元测试时有时要设计驱动单元和桩单元。
驱动单元（Driver):所测函数的主程序，它接受测试数据，并把数据传送给所测试单元，最后再输出实际测结果。当被测试单元能完成相关功能时，也可以不要驱动单元。
桩单元（Stub）：用来代替所测单元调用的子单元。 应该是XP编程的概念吧。
先设计测试用例和所有可能的结果，然后再进行开发，
测试过程完全自动化，出现新的需求就增加相应的测试用例。
开发出来的程序，直接跑测试。
测试用例同时也是系统功能的详细说明。 原帖由 slide 于 2006-3-31 12:58 发表
应该是XP编程的概念吧。
先设计测试用例和所有可能的结果，然后再进行开发，
测试过程完全自动化，出现新的需求就增加相应的测试用例。
开发出来的程序，直接跑测试。
测试用例同时也是系统功能的详细说明。
测试过程完全自动化。。。这个可是 Dream test阿-v-~~~~
每个测试员的梦想，当然。。这个是不可能的，没有完善的体系，标准，管理这些根本不可能
再说了，自动化测试目前适用范围是一些冗长，反复，机械的动作脚本，很多的bug还是从手工测试中实现
毕竟程序的思维模式是人给与的，他只有布尔判断。但是人的思维完全不是这样啊
测试驱动开发，比较浅显解释就是在计划阶段就介入。对于代码的使用需求的预判。一句话就是代码是依据测试用例来编写，在开发某项功能的代码之前，先写出这项功能的测试用例，之后所编写的代码满足这些测试用例。
NND现在哪个开发人员愿意这样玩。。。靠…………在中国目前阶段貌似实现不了 本人不喜欢驱动这个词，应该用规范更好
根据我们老师的说法，应该测试人员参与到开发的早期阶段，参加需求评审、概要设计评审和详细设计评审，然后根据评审结果制定系统测试计划和方案、集成测试计划和方案、单元测试计划和方案，并设计系统测试用例、集成测试用例和单元测试用例；因为测试的依据是开发文档，所以测试人员必须对开发文档进行把关；因此测试人员的素质要求就很高了，必须能够帮助开发人找出开发文档中的问题，这也就是所谓的静态测试 原帖由 bobli 于 2006-4-2 16:56 发表
本人不喜欢驱动这个词，应该用规范更好
根据我们老师的说法，应该测试人员参与到开发的早期阶段，参加需求评审、概要设计评审和详细设计评审，然后根据评审结果制定系统测试计划和方案、集成测试计划和方案、单 ...
终于说到重点了，最近偶也在想这个问题。
测试驱动开发意思是：如何通过做好测试来驱动开发的质量。组长也问我们这个问题了，偶说考虑几天回答她。现在找到答案了，哈哈，感谢李老师哦！
只是具体可以怎么做呢？ 可以做些什么呢？参与评审。。。还有呢？需要参与单元测试嘛？
[ 本帖最后由 swallow0918 于 2006-4-5 12:29 编辑 ] slide回答的基本是正确的。如果这些问题还不是特别清楚，可以看看下面的一篇文章
http://www.51testing.com/html/9/652.html
下面还有一本测试驱动开发的电子书
http://www.51testing.com/html/43/214.html 原帖由 testing 于 2006-4-6 00:00 发表
slide回答的基本是正确的。如果这些问题还不是特别清楚，可以看看下面的一篇文章
http://www.51testing.com/html/9/652.html
下面还有一本测试驱动开发的电子书
http://www.51testing.com/h ...
看到了觉得做到很难 有几个公司可以做到这样呢？ sdlkfj 肤浅的了解一些，自己也没有作过
应该是在做单元测试的时候用到
作为一个独立的、未与其他模块集成的模块体，它需要一个模块来向它传送预想的数据与传出实际的结果，来测试当前模块是否可以运行自己编写的基本流与备选流，看执行是否与预想结果一样 正在学习呢!有兴趣的同事,加我啊!MSN:jason-dsr@hotmail.com 驱动开发好象就是集成测试里的自底向上方法,需要驱动程序.
而自顶向下则需要桩模块了
页:
[1]
