设计测试用例与系统设计的关联（08-08-04）（获奖名单已公布）
测试驱动开发，意味着测试人员先设计测试用例，设定系统的规则（比如输入什么类型的数值，输出结果是什么），然后开发人员在此规则下进行开发。那么，测试人员设计测试用例的过程是不是就是系统设计的概念呢？感谢会员fmsbai5提供此精彩问题！如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！
非常感谢各位会员积极参与，截止至8月9日24：00分，从该贴所有评论中选出部分作出精彩评论的会员予以奖励。礼品和积分将在下周内送出。
获奖名单奖项获奖名单奖励答案链接一等奖rolei当当购物卡50元5#二等奖archonwang300论坛积分6#三等奖goal1860100论坛积分 3# 这种东西如果由tester来定的话理论上也可以，不过据我的经验是不太现实。1个2个tester还好，如果是一个很大的team，那么每个人对产品行为都由自己不同的理解，那么写出的case可能五花八门，夸张一点的话连返回值都不一样。所以系统设计还是要有专人负责，这样出来的东西会有一致性，作为tester可以在前期参与review,提出改进意见。
TDD应该是由agile引入的吧，个人感觉agile的东西有时候还是形式多一些，如果一个team里面人都是牛人，那可以不要任何process，我觉得agile里最有用的还是iteration的概念，一个task完了就能立马测试，发现问题解决问题，能做到这一步的话，我觉得TDD也是可有可无的，其实TDD或许更适合designer开发小模块的时候使用，自己一边写BT，一边写code，一方面解决了designer懒得做BT的问题，另一方面也让designer从测试的角度来设计模块，一般是可以防止掉很多最基本的问题。
以上是本人的一些看法，欢迎大家踊跃讨论 呵呵，我喜欢这样的问题，因为这又牵扯到了很多好玩的东东。首先TDD应当是在敏捷开发（同意楼上）的范畴内的，但我一直没有找到一个完美的定义。一般狭义的理解TDD是单元测试和代码的关系，即先单元测试后代码。这是针对开发来说的。对于测试来说又怎样呢？在一些更加“敏捷“的测试模型(如x模型)当中，各种测试类型，如单元测试，集成测试，系统测试真能分得那么清楚么？所以在本人看来TDD应该针对所有的测试类型：从最粗的验收测试到最细的单元测试。不想细述具体方法，因为现在似乎并没有完全成熟的理论来指导。在细分的敏捷开发过程，如统一方法，Scrum等都有各自的最佳实践供参考，但更多的应当从组织的实际出发，以提高开发效率和质量为目的选择性地采用测试驱动。从本人实践来看先写单元测试似乎总是不错的选择，虽然刚开始需要一段时间来适应。良好的单元测试覆盖率能给人以很大自信心。
绕了一大圈，再来回答一下楼主的问题：测试用例不等于设计。因为他们的着眼点是不同的。驱动开发的测试用例可以来自于测试人员，也可以来自于需求分析（参见测试驱动需求TDR的有关资料)。我们通常是不会指望需求分析人员和测试人员提供完美的系统设计，哪怕是粗略设计的。在本人看来，它只是需求的一种展现形式而已。这样设计师(SA)可以更有针对性地进行高级设计和详细设计。举个例子来讲，系统的组件关系，对象关系，细到设计模式的应用是很难在测试用例当中得到完全体现的。
最后补充以下，个人不太赞同楼上对敏捷开发的观点。每一种开发流程的出现都是去解决软件工程实践当中的具体问题。敏捷开发的主要目的是为了减少各种变更带来的风险，而增加软件项目的可控性。它的最佳实践对象个人看来应当是大型的高风险项目。“稳”是它的精髓。流程是为工厂化大生产，而不是一堆牛人的天才团队设计的。至于牛人不要流程，本人倒是赞同的，就像他们同样不需要设计模式一样--他们的实践就是符合流程和模式的 很显然不是同一概念，但我认为两者之前有了更多的互通性，都是为了设计出更完美的系统给用户。
说说两者之间我认为的最主不同之处：
系统设计：是从整体上将系统构建起来，让系统去做正确的事情，实现用户所需功能。
设计测试用例：检验是否达到用户需求，也就是系统是否做了正确的事，以及没有做不正确的事（个人理解）。
测试驱动开发是最近才提出来的，也是为了适应当前形势。所以个人认为这是将系统设计融入了测试当中，也就是为了在系统开发前期从多角度考虑系统是否为用户所需要的系统，缩减了开发时间，也降低了开发风险。
设计、测试用例，两码事。
测试人员设计测试用例的过程跟系统设计的概念没有太大的联系，测试人员可以参与设计，从测试人员的角度提出自己的建议，但不要把自己当做设计人员去设定系统规则。测试的目的,第一验证程序是可以按照需求和设计运行的；第二找出程序不能按照需求和设计运行的问题，并保证这些问题被最终修正。
因此不要期望 测试人员设计测试用例的过程 跟 系统设计 划上什么等价关系。
首先，设计、开发、测试从原则上讲是相互独立的，但彼此之间互相协作，通过不同的角度去审视之前的工作，发现前期工作的存在的问题。
因此，测试可以去对设计进行测试，发现设计中的不足。特别是那些设计中提到的，但是在实际的测试过程中跟本就如法去实现测试的设计点。
其次，“系统的规则（比如输入什么类型的数值，输出结果是什么）”不是由测试人员来定的，而是由需求和最终的用户实际需求来定的。除非测试人员是行业专家或者是全程参与了需求的获取过程，否则不要去设定系统规则。
最后，“然后开发人员在此规则下进行开发”，不要期望用测试人员的规则去规范开发。因为测试的目的是从不同的角度发现设计和开发中的问题，如果用测试人员的规则去指导开发，然后再由测试人员来测试，这跟开发人员开发后自己再测试有什么区别吗？
对TDD的理解
1.什么是测试驱动开发
测试先行。在动手进行编码时，先编写相应的测试用例，然后跟据用例进行编码，生成的编码必须通过先前的测试用例的验证。
但测试先行，不是测试人员先行，而是单元测试先行，一般是由开发人员自行完成的（如果有能力，测试人员可以参与，结对编程是个不错的选择）。用先行的单元测试用例去验证生成的代码的正确性，循环往复，尽可能早的暴露问题。
2.测试驱动开发的好处
引用《Agile Software Development:Principles, Patterns, and Practices 》的观点
1）测试先行可以避免相当数量的反馈循环。－－可以将问题暴露在最小的代码范围内。
2）程序的每一基功能都有测试来验证它的操作的正确性。－－同时也验证了需求和设计的正确性，功能实现来自于需求和设计。
3）编写测试用例可以迫使我们使用不同的观察点。－－以不同的角度审视程序实现，提高代码质量。
4）编写测试用例帮助程序员了解如何使用代码，测试用例是可编译、可运行的，它保持最新，不会撒谎。
5）测试驱动开发迫使我们把程序设计为可测试的，易于调用，因此程序必须和它的周边环境解耦，迫使我们解除软件中的耦合。－－个人认为这个是最重要的，一个不可测试的程序，对于后期的工作将是灾难的。
浅见，勿见笑~
呵呵，我觉得要回答这个问题，需要把重点放在两者的根——需求上。从根本上来讲，设计与测试案例只不过是同一个需求的不同表现形式。设计更多的是从逻辑上表现系统/功能的内部结构，对象间关系，算法或者流程等内容。测试案例则偏重于其设计实现的校验上。我个人觉得，无论是传统的开发模式，或是TDD，都无法脱离或背离需求这个根本。
接下来回答楼主的问题。自己觉得：设计测试案例的过程是对需求的解读和翻译过程。但不同的是，不同的人，不同的技能等级和系统认知都会对相同的需求产生不同的结果。设计测试案例的过程不能等同于设计过程，尤其是黑盒测试（从细粒度上讲）的测试用例。充其量作为系统设计的补充，以完善异常处理，验证现有实现。所以，我现在反而觉得，所谓设计，只不过是人对系统的一种理解和实现手段，不是最终目标。而相关的人认同或不认同该种手段，而后讨论、修订，最后达成妥协一致，进而实现。所以，我认为设计测试用例的过程不能等同于设计过程，但是却可以作为设计的中间认知过程。
TDD中实现的不断集成，不断测试，先实现测试模块再进行逻辑编码，不过是种实现手段，也许开发出来的内容质量会相对更好些，但并不代表非它莫属，更与测试案例设计过程和及系统设计毫不关系——TDD更多代表一种思想而非具体的实现。更现实点讲，实现有很多种方法，过程有很多选择，我想不必太过执着于哪种形式吧。
[ 本帖最后由 archonwang 于 2008-8-5 17:26 编辑 ] agile带给人的其实只是一种思想，记得哪本书上说过，没有哪一个流程可以说是对的，我是很赞同的，一个标准流程带来的应该是一个指导思想。同意二楼的，正因为一个team里不会都是牛人，所以需要一个流程来约束大家，但也不应该完全盲目的去follow这个流程，比如scrum中提到的没有team leader，没有PM，没有designer和tester之类的，现实生活中是很难发生的，再比如cross function team这个概念，实现的可能性也是微乎其微。
说回TDD与系统设计，楼上几位说的都很对，这两个是完全不同的概念，但是如果从另一方面来想，当review系统需求的时候tester由测试方面入手发现了问题，这是不是也算是TDD呢，假如teste team很牛，发现了很多问题，甚至是颠覆了这个系统原来大部分的设计，如果最后team完全采用了tester们的意见，那我们可以说TDD也介入了系统设计。
所以我的理解是，TDD不能替换系统设计，但是它可以参与系统设计，或者说应该鼓励TDD介入系统设计，这也是一般说的tester要尽可能早的介入项目。 首先应确定的一点是，高质量的测试用例是在理解系统需求的成熟度上完成的
在做项目开始，测试人员得到系统需求，有许多测试人员认为不值得在需求上浪费太多时间，认为只要对其了解即可，因为在测试系统的时候，会自动将其中的内容覆盖，这种观点是不全面的。首先系统的开发需求是软件质量保证的凭借手段，在测试础，整理测试用例时，如果不了解需求，无法写出高质量的测试用例，（在这里说的高质量的测试用例就是指的对需求覆盖的百分比了，当然不可能有百分之百覆盖率的用例）如果只按自己的系统的理解去写，当然覆盖率会很低。所以说系统的需求对测试用例来说是至关重要的。 解决楼主的问题，要说明两个概念：
1.测试驱动开发（TDD）是极限编程的一个重要组成部分，它的基本思想就是在开发功能代码之前，先编写测试代码。我们可以针对v模型来简单说下
如图是普通的流程，应用测试驱动的流程则是：需求分析-->概要设计-->详细设计-->编写单元测试代码-->编码（当然集成测试代码也可以在编码之前编写）。
而这里的单元测试编码的内容，参考的无疑是详细设计，已经设定好的规则。根据已定义好的函数（输入输出）、调用关系，选择的测试策略等来编写桩和驱动。
2.测试用例的设计要依据详细设计，或者高于详细设计，包括两部分：
a.用基本路径覆盖等方法覆盖输入输出值的各种情况，乃至处理过程中的异常情况等。
b.单元测试代码的设计编写（如上所述）。
另，支持7楼的观点，“一个标准流程带来的应该是一个指导思想”，有很多的开发模型，测试模型，各有优势与不足，重要的是“拿来主义”的思想，适合有用才是硬道理。
无名小卒，请勿见笑。 在测试驱动开发TDD的模式下面，测试人员会先进行测试用例的设计，然后在有了测试代码以后，负责开发的工程师才开始写代码。对于TDD，一句经典的话就是，在没有任何测试之前，不要编写任何代码；因为在没有测试去验证写出来的代码，也就没有办法去验证写出来的代码是否是正确的，可靠的。
我们可以看一下开发的模式：
瀑布模型：制定计划、需求分析、软件设计、程序编写、软件测试和运行维护
增量模型：多个（分析、设计、编码、测试）
螺旋模型：（需求、架构、设计、编码、测试）
无论什么模型，设计总是在编码和测试的前面，万变不离其中。而TDD，测试驱动开发，只是把测试稍微提前了一点，提到了编码之前，而且这里的测试也只是部分的测试（单元测试），还有相当一部分的测试（系统测试，性能测试，UAT等……）是在开发完成以后才能进行的。所以，测试先行，指的只是“单元测试”。
一些常见的开发过程，局部上也是遵循（分析、设计、编码、测试）这样的顺序。暂时还没有一种过程会是（测试~编码~分析~设计~需求）的吧。现在搞清楚了一点，测试驱动开发TDD里面的测试，其实指的是单元测试，不是所有的测试。那下面我们主要单元测试。
在维基百科里面，单元测试的定义是：unit testing is a method of testing that verifies the individual units of source code are working properly，单元测试是一个用来verify单个但源代码是否正确地工作的方法。对于我们做测试的人来说，双V(Validation & Verification)的区别是需要理解的。
Validation 和 Verification
前者是build the right thing, 后者是build the thing right.
前者的标准是客户需求，后者的标准是产品设计
前者从更加高的角度来看，后者的站的角度稍低
（以上三条理解有不同意的欢迎各位补充:) ）
好像走的有点远……其实最后得出一个结论就是，单元测试（也就是TDD里面说的测试）其实是去verify一段代码是否正确工作；这里单元测试的根据是系统设计而得出来的，单元测试源自于系统设计；而不是等同于系统设计。
在TDD活动中，测试人员设计测试用例的过程并不是系统设计，而是根据系统设计去verify代码是否正确工作的用例设计。 “设计测试用例”和“系统设计”显然不是同一概念。
测试驱动开发，同时也还驱动着系统设计，驱动着软件架构的改进。所以，测试驱动开发不能单纯的理解为“测试用例设计”就是“系统设计”，也不能认为仅仅是测试工作。
TDD是一种开发方式，这种开发方式是在明确需求、明确要开发某个功能后，首先考虑如何对这个功能进行测试，并完成相应的测试用例，然后编写代码满足这些测试用例。然后循环进行添加其他功能，直到完成软件的所有功能。
TDD所设计的测试用例，在某种意义上为完善代码、迅速发现bug、定位bug提供了方便，从而保证了软件进度正常和软件功能的正确性。但是，通常TDD方式开发的软件，在开发过程中就逐一通过了最初设计的测试用例，再想通过这些测试用例发现bug已经不是很现实了，那么就需要根据功能的细化，不断的更新、完善测试用例，再不断的修正代码，直到完全满足客户需求，并保证软件完整性和正常运行。
在实际应用中，不是所有软件都适合用TDD方法，TDD开发方式中，没有明确的系统设计过程，所以，需要根据实际情况综合分析再决定是否采用此种方式进行软件开发。比如，软件的系统设计至关重要，必须提前将系统设计做好，就不能通过TDD方式进行开发。
[ 本帖最后由 sunyh 于 2008-8-8 13:25 编辑 ] 10楼把TDD限于单元测试也无不可，很多教科书也都是那么解释的：测试先于编码。个人认为这样的理解有些过于狭义，没有理解TDD的精神。测试在敏捷开发中占据及其重要的作用。很大程度上测试指导很多开发活动，如编码，设计，甚至于需求开发。这也正是为什么我们不叫它测试驱动编码(test driven coding or test driven implementation)。
现在很多人公认V模型或者双V（W）模型对于敏捷开发过程来说都是有缺陷的，于是有人构想了H模型和X模型的组合。它们有个共同点就是测试贯穿始终，而不是楼上所说的“万变不离其宗“。指导思想是在任何可测试的时候进行测试。各个测试阶段穿插融合。从个人实践来说，我们普遍地开发验收测试用例先于系统设计，这又何尝不是TDD？
一些开源项目已经在实践测试驱动的需求分析，个人觉得已经具备了一定的使用性。
以上仅是个人对TDD的一些浅见，但对于测试和设计的关系，似乎大家都能达成共识了。
我的答案
不是系统设计的概念~当设计人员快速反应客户的变化后，生产出新的功能（只是概要设计），然后向测试人员和开发人员进行讲解需要实现的目标和功能，了解设计后，分头行事，开发人员进行详细设计，测试人员根据设计编写用例，并对详细设计进行测试，一旦发现重大设计缺陷，直接向设计人员提出bug，bug解决后才能进行程序开发。开发人员和测试人员在此过程中可以测试设计人员的设计是否存在缺陷。
所以测试人员在此阶段进行的设计用例只是对设计的测试，和对开发人员的详细设计的测试，并通过测试来驱动开发和降低后期反功的概率。 我刚接触到TDD这个概念，感觉2楼回答的情况和我们公司目前运用的模式相当 这个问题来源于工作中思考的，原始动机是测试人员如何更多的参与到项目中，不要仅仅作为设计开发的影子。很喜欢你们思考性的回答，让我受益良多，都很棒。谢谢。 分析比较到位！ 哈哈 都是什么啊，逻辑好像不是很强
页:
[1]
