如何设计出高质量的测试用例

2010-05-18  胡名海 

            做为一个测试人员,设计测试用例可以说看家本领,不管你到那一个层次,都需要时时揣摩。我也一直在考虑如何设计出高质量的测试用例,经过多年的学习和实践,从中得出一些心得,在此班门弄斧一番,另外也想抛一块砖换块玉回去。
            我把测试用例分成几个大类,一类是场景用例,一类是个别用例,一类是体验用例。
            1. 场景用例,我把用户使用或操作习惯搭配称之为场景,不同的用户可能有不同的操作习惯,所以要完全模拟出用户的操作是比较难的,但是入口确是我们可以控制的,因此我们要整理出达到测试目标的入口,然后根据入口搭配出各种路径,针对这些路径进行覆盖,这样就可以设计出的场景用例。要写好场景用例,需要仔细了解测试目标的业务逻辑,然后根据业务逻辑来筛选出有效场景和无效场景,此类用例贴近用户使用习惯,查不出缺陷则已,一旦查出都是影响比较大的。举例来说:比如一个查询页面,有三个查询条件,其中两个个是选择型输入,一个是输入框,然后加一个按钮。这样的页面,普通用户比较实在,只找他想要的,所以选择条件和输入都比较规矩。这类场景比较好写。但是有些刁钻的用户可能会随意选择,然后输入的时候会空着,或者输入一些奇怪的字符进去。还有一些比较专业的用户,可能会尝试输入一些sql注入之类的东西。如果数据量太大,搜索响应比较慢,性急的用户可能反复点击搜索按钮,或者反复刷新页面。诸如此类的场景我们都会遇到,所以这些场景要保证有保护或者正常,不能出现异常或崩溃。
            2. 个别用例,主要是指针对输入或者各类参数进行的针对性的用例,比如上例中的输入框,选择框的针对性用例。这类用例比较好设计,因为大家见得比较多了,这类用例可以抽出其共同部分写成通用用例,这样不但可以让用例看起来清楚,还能突出重点。设计方法不外乎极限值,等价类划分,因果图之类的。
            3. 体验用例,用户体验可以说是很重要的部分,做好了产品的粘性就好,竞争力也就强力了,做的不好,用户也就浅尝辄止,没有粘性的产品很难说是成功的产品。用户体验分为视觉体验,操作习惯体验,心理体验几个部分,视觉主要是颜色搭配,界面模式等;操作习惯主要是符合人体工学,符合大众口味,简洁,易于使用,傻瓜型;心理体验方面主要是培养成就感,归属感等。这部分用例扩展出来比较多,而且也是仁者见仁智者见智的事情,我这里就不细说了,大家有兴趣可以探讨一下。
            最后一点就是测试用例和测试数据分离,用例中不出现具体的测试数据,保证用例的灵活性和可操作性。
799°/7875 人阅读/12 条评论 发表评论

程守标  2010-05-18

“测试用例和测试数据分离,用例中不出现具体的测试数据,保证用例的灵活性和可操作性”这个方法比较好


张峰  2010-05-18

我觉得测试用例是保证测试覆盖度的重要依据,也是保证测试人员对项目功能的准备把握。但很多公司和很多特定项目很难把测试用例做好,也不允许做好。
我更觉得如何从测试用例和测试过程中提炼测试方法,总结经验,建立这样的库,更有价值。


胡名海  2010-05-18

张峰: 我觉得测试用例是保证测试覆盖度的重要依据,也是保证测试人员对项目功能的准备把握。但很多公司和很多特定项目很难把测试用例做好,也不允许做好。
我更觉得如何从
嗯,完善测试过程,总结经验确实很有价值,受教了。


许文生  2010-05-18

覆盖度高,可执行性好的用例不一定是好的用例,如果用发现bug的多少来定义一个用例那么可能就不会有质量高的用例,如何能够更多的发现bug,提高软件的质量,完善的测试过程及测试人员的素质以及经验是提高软件质量的关键一环,但是在软件开发过程中大多存在测试介入时机的问题,往往软件原型出来了测试才开始介入。


胡名海  2010-05-18

许文生: 覆盖度高,可执行性好的用例不一定是好的用例,如果用发现bug的多少来定义一个用例那么可能就不会有质量高的用例,如何能够更多的发现bug,提高软件的质量,完善的测试过程
这个介入时机肯定是重要的,我觉得从需求开始介入不算早。


赵璐  2010-05-19

lz说的不错,我还想补充一点,就是我们应该时刻记得系统的整体需求,对整个业务有个理解。
我曾经在测试中有个印象比较深刻的bug:管理员可以建多个公司,每个公司下会有他的业务数据,但是测试时发现每个公司都可以看到其他公司的数据。
希望能以这个例子提醒大家


王浩  2010-05-19

程守标: “测试用例和测试数据分离,用例中不出现具体的测试数据,保证用例的灵活性和可操作性”这个方法比较好
顶起来,的确如此,数据不会是一成不变的。


王浩  2010-05-19

额,看楼主的话,好像平时在做用例的时候,用例设计的方法用的不是很多?


胡名海  2010-05-19

王浩: 额,看楼主的话,好像平时在做用例的时候,用例设计的方法用的不是很多?
用例设计的方法就那么几种,我的感觉还是"功夫在诗外"。所以我这里没有详细的介绍那几个方法,因为在网上一搜都能搜到。我的想法是说一下设计部分的东西。


刘旸  2010-06-09

程守标: “测试用例和测试数据分离,用例中不出现具体的测试数据,保证用例的灵活性和可操作性”这个方法比较好
这个我觉得不一定好。
如果用例中包含测试数据的话,会大大加快测试的速度,也比较易于理解。

想设计一个一劳永逸的测试用例是不现实的,该更新的还是要更新。


程守标  2010-06-09

刘旸: 这个我觉得不一定好。
如果用例中包含测试数据的话,会大大加快测试的速度,也比较易于理解。

想设计一个一劳永逸的测试用例是不现实的,该更新的还是要更新。
可以建立一个数据表,而在测试用例中用一些名称来和数据表中的数据对应,类似于自动化中的参数化一样,这样影响不了多少速度的。
测试用例和测试数据分离并不能说不要更新,也是要不断的更新,因为软件也是不断在变化,所以一个一劳永逸的用例也是不可能的。
这样的操作可以提高用例的复用吧


刘旸  2010-06-09

程守标: 可以建立一个数据表,而在测试用例中用一些名称来和数据表中的数据对应,类似于自动化中的参数化一样,这样影响不了多少速度的。
测试用例和测试数据分离并不能说不要
呵呵,这样的话,我觉得也不是测试数据和用例分离啦,
只是不同的表现形式而已。


登录 后发表评论