计测试用例的过程是否就是系统设计的概念?

       计测试用例的过程是否就是系统设计的概念?  测试用例设计　

   　设计、测试用例，两码事

　　测试人员设计测试用例的过程跟系统设计的概念没有太大的联系，测试人员可以参与设计，从测试人员的角度提出自己的建议，但不要把自己当做设计人员去设定系统规则。

　　测试的目的,第一验证程序是可以按照需求和设计运行的;第二找出程序不能按照需求和设计运行的问题，并保证这些问题被最终修正。

　　因此不要期望 测试人员设计测试用例的过程 跟 系统设计 划上什么等价关系。

　　首先，设计、开发、测试从原则上讲是相互独立的，但彼此之间互相协作，通过不同的角度去审视之前的工作，发现前期工作的存在的问题。

　　因此，测试可以去对设计进行测试，发现设计中的不足。特别是那些设计中提到的，但是在实际的测试过程中跟本就如法去实现测试的设计点。

　　其次，“系统的规则(比如输入什么类型的数值，输出结果是什么)”不是由测试人员来定的，而是由需求和最终的用户实际需求来定的。除非测试人员是行业专家或者是全程参与了需求的获取过程，否则不要去设定系统规则。

　　最后，“然后开发人员在此规则下进行开发”，不要期望用测试人员的规则去规范开发。因为测试的目的是从不同的角度发现设计和开发中的问题，如果用测试人员的规则去指导开发，然后再由测试人员来测试，这跟开发人员开发后自己再测试有什么区别吗?

　　对TDD的理解

　　1.什么是测试驱动开发

　　测试先行。在动手进行编码时，先编写相应的测试用例，然后跟据用例进行编码，生成的编码必须通过先前的测试用例的验证。

　　但测试先行，不是测试人员先行，而是单元测试先行，一般是由开发人员自行完成的(如果有能力，测试人员可以参与，结对编程是个不错的选择)。用先行的单元测试用例去验证生成的代码的正确性，循环往复，尽可能早的暴露问题。

　　2.测试驱动开发的好处

　　引用《Agile Software Developmentrinciples, Patterns, and Practices 》的观点

　　1)测试先行可以避免相当数量的反馈循环。--可以将问题暴露在最小的代码范围内。

　　2)程序的每一基功能都有测试来验证它的操作的正确性。--同时也验证了需求和设计的正确性，功能实现来自于需求和设计。

　　3)编写测试用例可以迫使我们使用不同的观察点。--以不同的角度审视程序实现，提高代码质量。

　　4)编写测试用例帮助程序员了解如何使用代码，测试用例是可编译、可运行的，它保持最新，不会撒谎。

　　5)测试驱动开发迫使我们把程序设计为可测试的，易于调用，因此程序必须和它的周边环境解耦，迫使我们解除软件中的耦合。--个人认为这个是最重要的，一个不可测试的程序，对于后期的工作将是灾难的。

原文转自：http://www.ltesting.net