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

发表于:2010-01-15来源:作者:点击数: 标签:系统设计概念
计测试用例的过程是否就是系统设计的概念? 测试用例设计 设计、测试用例,两码事 测试人员设计测试用例的过程跟系统设计的概念没有太大的联系,测试人员可以参与设计,从测试人员的角度提出自己的建议,但不要把自己当做设计人员去设定系统规则。 测试的目的

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

    设计、测试用例,两码事

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

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

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

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

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

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

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

  对TDD的理解

  1.什么是测试驱动开发

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

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

  2.测试驱动开发的好处

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

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

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

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

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

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

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