按照业务流和数据流写测试用例

发表于:2011-05-12来源:不详作者:领测软件测试网采编点击数: 标签:
曾经看过一些公司写的测试用例,通常都是从业务流的角度来写测试用例,比如进入画面,点了什么按钮,出来什么结果。当然在一些数据检查的时候也会写一些输入**,会报错之类。数据流在测试用例中并没有得到足够的体现。 作为一个完整的详细设计书,它应该写清

  曾经看过一些公司写的测试用例,通常都是从业务流的角度来写测试用例,比如进入画面,点了什么按钮,出来什么结果。当然在一些数据检查的时候也会写一些输入**,会报错之类。数据流在测试用例中并没有得到足够的体现。

  作为一个完整的详细设计书,它应该写清楚数据的增删改查,当然很多详细设计书没有写到这种程度,可是我们换个角度想,开发人员也是在这种不是很详细的设计下进行开发的,他们要根据式样的理解,写出满足条件的SQL文。

  测试人员是不是同样需要根据式样的理解,写出满足条件的SQL文呢。反映到我们的用例中,然后可以通过用例评审的方法,达成双方式样理解的一致性。

  作为功能测试而言,在我看来,数据的增删改查是最重要的测试点,应该清楚数据在程序中的流动,并将其反映到用例中,比如画面刚进入,我们需要写出数据的抓取条件是怎样的,也就是SQL文中的查,当然有时候也会做一些增删改,根据式样情况了,但画面刚进入的时候,最多做的是查的处理。比如点了什么按钮,数据做个什么抓取,数据库中的数据会有什么变化。如果是插入,插入的每一项值是否对,如果是修改,修改的条件是否对,修改的值是否设置的对。如果是删除,删除的条件对吗。

  写完测试用例后,我们就要造出基本的测试数据,这数据要包括有效和无效的数据,有了基本的测试数据,程序就能顺利的转起来。在测试过程中你可以根据你的用例要求修改数据。当然如果安排给你的时间比较多,你可以将各种情况的数据都造出来。 

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