测试人员设计测试用例的过程跟系统设计的概念没有太大的联系，测试人员可以参与设计，从测试人员的角度提出自己的建议，但不要把自己当做设计人员去设定系统规则。
测试的目的,第一验证程序是可以按照需求和设计运行的；第二找出程序不能按照需求和设计运行的问题，并保证这些问题被最终修正。
因此不要期望 测试人员设计测试用例的过程 跟 系统设计 划上什么等价关系。
首先，设计、开发、测试从原则上讲是相互独立的，但彼此之间互相协作，通过不同的角度去审视之前的工作，发现前期工作的存在的问题。
因此，测试可以去对设计进行测试，发现设计中的不足。特别是那些设计中提到的，但是在实际的测试过程中跟本就如法去实现测试的设计点。
其次，“系统的规则（比如输入什么类型的数值，输出结果是什么）”不是由测试人员来定的，而是由需求和最终的用户实际需求来定的。除非测试人员是行业专家或者是全程参与了需求的获取过程，否则不要去设定系统规则。
最后，“然后开发人员在此规则下进行开发”，不要期望用测试人员的规则去规范开发。因为测试的目的是从不同的角度发现设计和开发中的问题，如果用测试人员的规则去指导开发，然后再由测试人员来测试，这跟开发人员开发后自己再测试有什么区别吗？
对TDD的理解
1.什么是测试驱动开发
测试先行。在动手进行编码时，先编写相应的测试用例，然后跟据用例进行编码，生成的编码必须通过先前的测试用例的验证。
但测试先行，不是测试人员先行，而是单元测试先行，一般是由开发人员自行完成的（如果有能力，测试人员可以参与，结对编程是个不错的选择）。用先行的单元测试用例去验证生成的代码的正确性，循环往复，尽可能早的暴露问题。
2.测试驱动开发的好处
引用《Agile Software Developmentrinciples, Patterns, and Practices 》的观点
1）测试先行可以避免相当数量的反馈循环。－－可以将问题暴露在最小的代码范围内。
2）程序的每一基功能都有测试来验证它的操作的正确性。－－同时也验证了需求和设计的正确性，功能实现来自于需求和设计。
3）编写测试用例可以迫使我们使用不同的观察点。－－以不同的角度审视程序实现，提高代码质量。
4）编写测试用例帮助程序员了解如何使用代码，测试用例是可编译、可运行的，它保持最新，不会撒谎。
5）测试驱动开发迫使我们把程序设计为可测试的，易于调用，因此程序必须和它的周边环境解耦，迫使我们解除软件中的耦合。－－个人认为这个是最重要的，一个不可测试的程序，对于后期的工作将是灾难的。
版权声明：原创作品，允许转载，转载时请务必以超链接形式标明文章原始出处、作者信息和本声明，否则将追究法律责任。
本文出自51Testing软件测试网，感谢会员rolei在每周一问（08-08-04）中的精彩回答。
http://bbs.51testing.com/forum-157-1.html
