51Testing软件测试论坛

标题: 实际工作中测试用例的应用程度调查 [打印本页]

作者: ppent 时间: 2007-2-5 11:34
标题: 实际工作中测试用例的应用程度调查
一直以来作为测试工程师的我们深信测试用例设计技术是我们的一项核心技术并进行了很多交流，但在实际工作中测试用例的应用程度有多少呢？大家一起来投票看看。该投票结果应该对我们学习测试用例设计技术的方向、深度、如何应用有很大的影响。

[ 本帖最后由 ppent 于 2007-2-5 11:36 编辑 ]

作者: juyoc 时间: 2007-2-9 11:24
根据目前投票的结果，看来还是符合中国目前的情况啊！

作者: ppent 时间: 2007-2-9 18:10
看的人多，投票的人好少。
希望大家都来投上宝贵的一票，更加客观的体现国内测试用例的应用程度。

作者: davids 时间: 2007-2-27 10:27
测试用例写了,但很少完全按照测试用例来进行测试.

作者: merry 时间: 2007-2-27 18:24
测试用例后期维护很重要

作者: archonwang 时间: 2007-3-2 13:53
维护很累啊，开发修改一份用例，测试组可能需要修改N份。简直用例杀手！！！！

目前还正在尝试更好的方法，可以控制变更成本。

作者: drp100 时间: 2007-3-3 16:08
只编写了基本的测试用例，根据情况有时按测试用例执行测试，测试用例效果一般.
没有测试用例只是记录了测试要点，测试时根据测试要点进行发挥.

其实我觉得用例效果不大。自由发挥、认真不停的实践，能测出些严重的问题！sdlkfj3
些测试用例、太粗不好、太细费时间、维护很累。我都修改过3次了。现在已经有快3个月没有改用例了。sdlkfj1

作者: ppent 时间: 2007-3-7 10:21
标题: 回复 #6 archonwang 的帖子
测试用例的维护确实很麻烦，工作量很大，特别是当没有规范的变更管理时，测试用例不能跟的上功能的变化，测试用例则成了一个鸡肋。真的是用之无益，弃之可惜。
不知道你有什么好的方法呢？

作者: ppent 时间: 2007-3-7 10:38
标题: 回复 #7 drp100 的帖子
测试用例设计被称为最能体现测试人员价值的工作之一，同时也是测试的精华所在。然而测试用例的实际应用如果象上面投票所示，说明测试用例实际应用根本达不到理论的高度。在这种情况下，就更加谈不上测试用例的维护了。正如#davids 所说的“测试用例写了,但很少完全按照测试用例来进行测试.”#drp100 所言，“些测试用例、太粗不好、太细费时间、维护很累。”

在我个人的工作经验中，详细的测试用例使得测试执行过程中变成了非常机械性的劳动，只需严格按照测试用例执行，对比期望输出即可，无需进行过多的思考。这种测试行为将使得测试执行变得麻木，若多次的测试执行将严重降低测试的积极性，并达不到测试效果就是这样的问题。这时适合用自动化测试代替。
而概要性的测试用例只记录了测试要点及注意事项，测试人员在测试时需要进行思考及发挥，有利于发现新的问题。另外两者在测试用例投入的时间和维护的成本都有很大的差别。

以上是个人见解，希望有更多的讨论。

[ 本帖最后由 ppent 于 2007-3-7 10:43 编辑 ]

作者: 不开窍的大饼 时间: 2007-3-31 15:25

原帖由 ppent 于 2007-3-7 10:38 发表
测试用例设计被称为最能体现测试人员价值的工作之一，同时也是测试的精华所在。然而测试用例的实际应用如果象上面投票所示，说明测试用例实际应用根本达不到理论的高度。在这种情况下，就更加谈不上测试用例的维 ...
...而概要性的测试用例只记录了测试要点及注意事项，测试人员在测试时需要进行思考及发挥，有利于发现新的问题。另外两者在测试用例投入的时间和维护的成本都有很大的差别。

邓爷爷说：不管黑猫白猫能抓到老鼠的就是好猫

我想如果企业的部门流程不能有力给予支持

还是先按最实际有效的方法来

作者: xiaochenchen 时间: 2007-4-4 10:42
国内测试还很不成熟，应该在设计用例的时候让测试员也能自己找到乐趣

作者: handle 时间: 2007-4-7 22:34
顶一下，我也不会这个，学习中。。

作者: by1945 时间: 2007-4-9 11:52
标题: 回复 #9 ppent 的帖子
呵呵，非常赞同ppent 的观点，一直都觉得测试用例是个鸡肋，我测试也是写些测试要点进行标记，然后进行测试，觉得比呆板的维护执行测试用例好多了，人有激情些，感觉按照测试用例来执行，心里憋得慌；
不过我现在一直还在找测试用例该怎么结合实际的方法，目前正在实验testlink，看效果咋样

作者: pierre0505 时间: 2007-4-9 13:01
投了第三个。

作者: 200605200000 时间: 2007-4-10 15:32
第二个

作者: FLY000 时间: 2007-4-10 23:14
唉，现在是最后一个

作者: sweetness 时间: 2007-4-12 11:49
测试用例的实际应用如果象上面投票所示，说明测试用例实际应用根本达不到理论的高度。

作者: x00ganlu 时间: 2007-4-24 12:43
功能测试用例写到一半写不下去了,太多了都很细
估计也不能一一执行,

作者: vickiren 时间: 2007-4-25 17:25
标题: 回复 #9 ppent 的帖子
学习了

作者: LKJ 时间: 2007-4-26 08:52
看了大家的评论,受益很多,谢谢

作者: ayong401 时间: 2007-4-26 08:55
视公司规模,项目大小,时间安排而定....

作者: 风华绝代 时间: 2007-4-26 10:18
我是最近才用例写的。
以前就lz写的，自由发挥。呵呵～
若是完全按用例来感觉有点死板。不舒服。

作者: bond21360005 时间: 2007-4-27 15:44
几乎没有测试的经验，软件测试对我来说真的是很神秘。
哪位前辈帮我出出主意，怎样才能步入测试行业呀！
现在在努力学习ing......sdlkfj7

作者: 堆积颜色 时间: 2007-4-27 16:07

原帖由 ppent 于 2007-3-7 10:21 发表
测试用例的维护确实很麻烦，工作量很大，特别是当没有规范的变更管理时，测试用例不能跟的上功能的变化，测试用例则成了一个鸡肋。真的是用之无益，弃之可惜。
不知道你有什么好的方法呢？

其实这个最重要的还是看测试部门的leader是怎么看待这个问题的，如果leader是一个很有质量管理思想的人那么测试用例在经过两三个项目之后就不会再是鸡肋了，但如果连测试人员也不重视质量管理的话那这个就真的没什么意思了~

作者: 堆积颜色 时间: 2007-4-27 16:16

原帖由 ppent 于 2007-3-7 10:38 发表
测试用例设计被称为最能体现测试人员价值的工作之一，同时也是测试的精华所在。然而测试用例的实际应用如果象上面投票所示，说明测试用例实际应用根本达不到理论的高度。在这种情况下，就更加谈不上测试用例的维 ...

测试用例是在测试过程中不断进行更新与维护的，但一个项目做完而且也对该项目的测试用例做过系统总结之后，只需要用管理工具存放起来即可，当有类似项目类似功能时取出来做为借鉴，这样就会有一部分测试用例会跟随着项目而不断的完美和充实，最终形成一个测试用例的模板

至于测试人员在执行测试用例时的具体心态与积极性，这个要看一、本人的工作态度；二、本人的主观能动性；三、测试部门对测试人员工作成绩的具体衡量方法，如果前两点该测试人员做的不好，那只能靠第三点来督促，但如果第三点做的也不好或是不合理那问题就比较棘手了，所以其实最本质的是测试部门的管理问题

以上只是个人浅见~

作者: 国国国 时间: 2007-4-29 10:17
测试用例的粗细粒度很难把握.

作者: 小贝 时间: 2007-5-8 10:47
测试用例原本就是为了提高我们的测试效率,如果测试之前没有经过严密的测试用例的设计,真正到测试的时候,在这个很短的测试时间段内,我们可能会遗漏了一些无效的测试用例,没有覆盖到,也正如猴子测试班,我们的效率提高不起来,而且无形中也增大了测试的风险.

作者: fuzhijuan 时间: 2007-5-9 11:26
测试用例，根本就不怎么用。一般都是直接看产品需求。

作者: shiliu 时间: 2007-5-14 14:21
只编写了基本的测试用例，根据情况有时按测试用例执行测试，测试用例效果一般
由于刚进入测试行业，所以在写测试用例时没考虑周到，执行效果一般

作者: yamaya 时间: 2007-5-14 15:59
我想在外企可能更注重测试用例的设计，测试时会按照设计的测试用例来操作。
在外企工作的朋友，说说你们的看法。

作者: Jon 时间: 2007-5-21 19:45
测试用例的设计是我们软件测试工程师的最基本要求和最基本技能，设计测试用例好处很多，
测试不能盲目进行，要有计划，有步骤，有思路，去合理科学地测试。
个人觉得测试一定要设计测试用例，既然都把时间给了写TC，为什么不写的更好点，更完整点呢？

作者: 巩员外 时间: 2007-5-22 09:50
变化中求生存!

作者: annayin 时间: 2007-5-31 16:45
sdlkfj7

作者: null2 时间: 2007-6-1 09:43
根据实际情况决定用例程度。没有详细的需求和设计文档，很难设计出非常好的用例

作者: velata 时间: 2007-6-1 10:39
之前的测试情况是第三种
但是现在想做成第一种
正在努力种

作者: sugebei 时间: 2007-6-11 18:44
我们写的用例来自客户的需求,但实际测试时往往又发现其实那些需求还是很粗的,越测试就离最开始的测试用例偏离越远了,
难道是缺少测试用例的维护么?一边测试一边还要不停的补充用例么?总觉得维护的工作量是一种浪费,所以很矛盾呢~~
sdlkfj9 sdlkfj9

作者: yiyi820106 时间: 2007-6-12 10:54
是啊，我也和楼上的一样矛盾啊。。

作者: xiaocuier 时间: 2007-6-14 13:55
标题: 回复 #6 archonwang 的帖子
确实是这样的，我们的用例需要随着PD和developer的文档变化而变化，维护非常的重要，很多时间都浪费在这个上面

作者: xiaocuier 时间: 2007-6-14 14:03

原帖由 by1945 于 2007-4-9 11:52 发表
呵呵，非常赞同ppent 的观点，一直都觉得测试用例是个鸡肋，我测试也是写些测试要点进行标记，然后进行测试，觉得比呆板的维护执行测试用例好多了，人有激情些，感觉按照测试用例来执行，心里憋得慌；
不过我现 ...

你说得很对，写写测试要点记录测试内容以防遗漏，这比呆板的写些test case要简略而且容易维护，但是如果所测试的项目这个版本发布了，以后还有后续版本的话，有test case，就只需要依照以前的case来执行就可以了，免去很多的工作，这时候有详细的case就比较好了

作者: xiaocuier 时间: 2007-6-14 14:05

原帖由 x00ganlu 于 2007-4-24 12:43 发表
功能测试用例写到一半写不下去了,太多了都很细
估计也不能一一执行,

刚写case的时候也有这种感觉，但是我们的是automation test，希望能够执行所有的case

作者: xiaocuier 时间: 2007-6-14 14:08
标题: 回复 #25 堆积颜色的帖子
同意堆积颜色的看法。 support！

作者: yeziqingqing 时间: 2007-6-14 15:30
写测试用例很累，而且在实际测试中好多BUG根本不是执行测试用例测出来的！但不写又不行真是好郁闷！

作者: lymusicar 时间: 2007-6-22 19:21
我是测试新手，谢谢帮助，现在急着充电 sdlkfj3

作者: snnylip 时间: 2007-8-7 15:25
标题: 回复 #36 sugebei 的帖子
有同感啊
有时个开发人员给的需求和原型并不全面，或是他们又改变了想法，还要不断继续的修改啊

作者: chipin64585 时间: 2007-8-8 10:39
值得收藏

作者: QQMSN 时间: 2007-8-8 17:03
我们公司写的都是简单的测试路径
个人觉得测试用例很重要，如果发现的BUG不能重现，那样就知道测试用例的重要性了

作者: zxyu1982 时间: 2007-8-12 00:09
ding

作者: chengmei410 时间: 2007-9-10 16:51
我们公司测试用例评审比较严格，用例完成的不错，可是执行的结果还没有很好的监控。

作者: jin8600929 时间: 2007-9-12 21:57
写了基本的测试用例
到是在发挥

作者: smile_liu029 时间: 2007-9-15 18:16
标题: 回复 #25 堆积颜色的帖子
测试用例要不段的维护才有效, 测试人员应该有这个意识,也应该尽力按这种方式去做.

作者: Suran2004 时间: 2007-9-17 17:12
我认为写测试用例并不断地更新与维护是很有必要的，古人云：“好记性不如烂笔头”，我觉得，在测试的过程中，有什么好的灵感不妨也用笔记下来，这样有利于以后版本的测试，同时，也有利于文档的管理

作者: bredri945 时间: 2007-9-21 11:09
中国测试业还不成熟，乃至软件业。test case的编写，除非公司管理层的投入，大多公司都是只编写了基本的测试用例，根据情况有时按测试用例执行测试，测试用例效果一般

作者: icive 时间: 2007-10-19 18:08
测试的结果符合中国的实际情况，但是不是大家都愿意看到的样子啊

作者: hanyancui28 时间: 2007-10-20 10:02
看完了大家的意见,觉得都说的很对,因为事物本来就是具有两面性的,有好的一面,固然也不好的一面,TC的编写能指导我们进行测试,但它同时也禁锢了我们的思想,让一些BUG没有能被发现.所以,当我们执行完了TC后,我们可以根据自己的一些经验,或是对同类软件的认识,进行随机测试,这样,可能会发现一些我们在执行测试用例时,没有发现的问题.
TC除了上面同志们所说的用途外,TC还有一个用途,那就是当我们进行回归测试的时候,可以执行完全相同的测试用例,验证bug是否真正的完全被修复.
这是我对TC的一些看法,有什么不正确的地方,请大家指出

作者: 追寻浮华 时间: 2007-10-26 10:41
我觉得有位说的很好。。忘了几楼了。没有绝对都。
视公司规模，项目情况。。。。而定。

作者: joetree 时间: 2007-10-29 15:34
我是性能测试工程师,我是写性能测试用例的,可以说这个测试用例很重要,不过我们这个也叫测试场景,因为用例就是在描写场景

作者: tianyue 时间: 2007-11-19 17:42
刚开始的时候~还很有激情写很详细的测试用例~但后来在公司都没有怎么用~

作者: asai-oyh 时间: 2007-12-4 11:01
现在越来越要求测试用例的数量和质量，但是需求在变化的话，用例也需要跟着一直变。。。

虽然也有按照用例来执行，但是我觉得如果都完全硬生生的全部按照用例来进行，难免遗漏，毕竟没有完美的测试用例

随机抽取进行测试有时也能有意外收获

作者: yunxiz 时间: 2007-12-8 13:51
很细的一般都不写……自己执行就好了，做产品就这样

作者: 胖英 时间: 2007-12-11 20:17
我们公司的软件按照测试用例,那发现的BUG是很少的,也是很基本的,但往往BUG又是在不断的反复的进行中发现,这样的情况让用例怎么写,同时,人的思想是在不断变化的.但我知道一个专业的测试肯定是离不开测试用例的.
测试用例想说爱你不容易呀

作者: zsp_123zhang 时间: 2007-12-12 13:34
最近公司在要求我们在写测试用例,还没用呢,现在主要靠个人的经验和能力

作者: chm_1223 时间: 2007-12-21 14:46

原帖由 bredri945 于 2007-9-21 11:09 发表
中国测试业还不成熟，乃至软件业。test case的编写，除非公司管理层的投入，大多公司都是只编写了基本的测试用例，根据情况有时按测试用例执行测试，测试用例效果一般

感觉我现在在的公司就是这样的

作者: yhhbqaz 时间: 2007-12-21 17:38
由于目前国内对需求管理水平较低，会导致用例设计效率不高，加上工期限制，对用例的维护力度自然不够。

作者: jacyxu 时间: 2007-12-27 14:30
顺便问问，测试用例写了，碰到经常行的需求变更，有更新的么？

作者: langchaogc 时间: 2008-2-22 17:56
标题: 另类说法
我越来越觉得，测试只需做到“good enough”，因为测试也要服从公司目标，公司目标是盈利，这是大前提。
我觉得很多时候可以说很多道理，测试如何重要，用例必须如何写，但是现实中很多东西是没有道理的，至少不是书上说的理论那些道理。最讽刺的就是：很多教材上对好的测试用例的定义——发现了至今没有发现的缺陷的用例。这样的用例定义有价值么？如果是做外包，测试用例很重要，但是我们看看自主研发项目，测试用例你们是怎么做的，单元测试是怎么做的。。。。大家心里清楚。
我并不认为“测试用例是测试的精华所在”。他就是软件开发过程中的一个普通文档，用来说明本系统在什么条件下，输入什么，会有什么结果。测试人员不可能有时间吧用例穷举，也不可能写那么多文档，公司舍得投入那么多人，写那么多文档么。所以我建议，对于用例最多的功能测试，还是要多学学业务，用例的设计思维要在心中，测试时要认真，细致，也就够了。
  我所在的公司维护是一个可以卖的产品，所以如果一个缺陷也没有，那这个产品就卖不好；如果有缺陷，我们派人去，马上给他解决，客户最喜欢这样，觉得我们把他放在心上，所以我建议把客服做好，可能对一个公司的形象更好。
  测试只要做到够好，基本操作，基本功能不会出错，不会轻易死机。。。。
  个人意见，请各位批评

作者: ◎了了 时间: 2008-2-26 11:29
222

作者: jiang860718 时间: 2008-3-4 11:54
测试用例其实挺好的，只是现在来说用的太少了，苦恼啊！

作者: xhzhou_cll 时间: 2008-3-19 16:26
标题: 版本变更致使用例的难维护！！
1：刚开始从事测试的时候，我们是严格按照需求编写测试用例的，但是一到真正测试的时候，基本上是不按照测试用例来执行的，而是想到想测到哪。
2：后来自己想出了一个应对回归测试的办法。就是采用EXCEL维护好基础数据及业务数据，然后在执行测试的时候，将基础数据输入进去，及通过相应的操作产生业务数据。
3：等到下一版本发布时，再将上一版本测试时输入的基础数据与业务数据用SQL脚本删除，再次输入已维护好的测试数据以验证BUG是否修复。所以，我认为写测试用例，还不如维护好一套测试数据来的实用一些。
以上为个人经验！

[ 本帖最后由 xhzhou_cll 于 2008-3-19 16:28 编辑 ]

作者: zhongshch 时间: 2008-3-31 20:23
标题: 我的看法
个人觉得测试用例是很重要的，原因有以下两点：
1 提高测试的覆盖性，降低测试风险。有效的测试用例设计可减少遗漏测试点的可能性，当然也可以减少测试用例的重复性。
2 在一些领域，例如手机，新款手机很多情况下都是在上一款手机的基础上加上一些新的功能和对原来功能的充实来进行开发。当测试用例被有效的管理和利用那么可以减少很多的测试工作量。

但是工作中维护测试用例的确花很多时间，特别是每次开发组改动了文档的时候，我们的测试用例也必须跟着变更。

作者: mli@dtri.com 时间: 2008-4-1 14:59
没有我要选择的项，我选择测试用例详细，但是不按照测试用例执行，而是按照测试要点和自由测试为主。我觉得测试用例要尽量详细，但执行时并不需要每轮都严格按照用例执行，要根据实际情况而定。

作者: junlingliu 时间: 2008-5-12 16:55

原帖由 vickiren 于 2007-4-25 17:25 发表
学习了

对阿，一样的感受！

作者: vxiaoqiangs 时间: 2008-6-4 14:06
个人感觉测试用例必须要写，而且要写的细且全面，这样在测试的时候会节省一定的时间。
当然也有写不到的地方，这个时候就要根据用例和程序把测试工作扩展一下。用例写的好坏除了测试思路之外，更主要的是看你对项目的需求是否特别的熟悉了

作者: vxiaoqiangs 时间: 2008-6-4 14:08
哈，上面只是说了下功能测试，其他的如自动化和性能还不太熟悉

作者: 1qazse4 时间: 2008-8-5 15:46
2. 编写了比较详细的测试用例，严格按测试用例执行测试，但执行效果没有预期的好

作者: judyhu_2008 时间: 2008-8-29 14:51
我们公司的测试都要先用例，再用例评审，再根据用例测试。
有时候一个小小的需求变更，我们又要忙半天。
而且还有一个问题，需求变更对应的升级测试用例往往没有调整到集成测试用例中
从而存在这样的情况：一段时间以后，程序已经跟集成测试用例不匹配了

作者: sunnisun 时间: 2008-9-1 10:43
我现在在做的项目，测试用例是我来写的，写了2周左右的用例后，来51看到了这个帖子，谈下感受：
1、测试用例不可能写得太详细，特别是在项目刚开始的时候，很多需求还是在变更中，比如页面某个tab的名称、位置等都不确定，这时连开发都不知道页面的一些细节该是怎样的，就更不用说是测试人员了，想用语言详细说明很难。
2、测试用例不宜写得太详细，设计者和执行者只需要在测试执行前沟通好，对于被测功能达成共识，设计者把测试的要点写清楚，而执行者在此基础上需要开拓思路，进行用例执行，这样调动了双方的积极性，实际效果会更好。
3、对于用例的维护，是执行者和设计者共同的事情。在用例执行的过程中，执行者把他所依据的测试数据归纳并提交给设计者，再统一提交到配置库中，如果需求变更，设计者设计出新的需要添加或改变的用例，执行人员再未这类用例设计测试输入数据进行测试。维护的流程基本如此。每个变更之后用例被更新一次。

作者: zrlcj 时间: 2008-9-1 18:13

我个人认为首先应编写基本的测试用例，在测试之初对测试有个大概的方向，然后根据自己的发挥，在测试过程中对用例进行完善，目前我是这样进行的，感觉还可以。

作者: happyfyw 时间: 2009-5-18 10:37
我们从来没有测试用例

作者: elisly 时间: 2010-3-2 11:00
我投了第三种情况，其实很多项目都是第四种

作者: 楠族开心果 时间: 2010-5-7 15:54
写测试用例还是蛮头疼的，不过测试用例真的很重要呢

作者: 楠族开心果 时间: 2010-5-17 13:16

原帖由 happyfyw 于 2009-5-18 10:37 发表
我们从来没有测试用例

那你们就直接测呀？？？？

作者: Jackc 时间: 2010-8-27 15:42
用例其实也算是一种工具，使用程度需要根据项目实际资源决定。

作者: 狼群 时间: 2011-3-15 11:53

作者: sana 时间: 2011-3-31 14:49
楼主组建个群我们多交流下

作者: Miss_love 时间: 2014-5-22 08:47
第三项比较多

作者: stephen_tjh 时间: 2014-8-21 22:23
一向比较认真写用例，就是为了后面能减少工作量

作者: Wei测试 时间: 2015-8-22 15:28
选项比较单一，基本都是负向的，用例设计做好了，会减少很多工作。有待再总结啊。楼主。

作者: bubblelone 时间: 2015-10-1 07:36
大家平时写测试用例真有这样去使用正交、因果图、判定表这些方法吗？

作者: 雪霁晴天 时间: 2015-11-12 15:55
我们写的不算是用例就算功能范围详细描述，用例写起来太费劲了

作者: 微风散落的 时间: 2016-12-12 09:50
每次写完用例后，在执行测试的时候会发现很多其他的点，想到了就再补到用例上

作者: chenjiawang 时间: 2016-12-22 15:10
123

作者: jessica2017 时间: 2017-11-24 09:54
我们公司的测试用例抓的比较严格，大家基本都严格执行。

作者: jessica2017 时间: 2017-11-24 09:55
测试用例对一个公司来说很难重要，能看出测试的力度和覆盖面。另外可以多人合作。回归也用得上。

作者: bling123 时间: 2018-3-5 15:57
画思维导图+需求业务结构及功能点，继而编写测试用例
但是实际测试过程中，用例是会变动的，测试的方式也会变动。
因此，我们这里初始用例较为详细，但是实际不会完全按照用例去执行，它是一个参照物。
实际效果较为良好。后期维护就比较麻烦了（初始+实际）

作者: HUI774351654 时间: 2019-2-16 11:37
每测试一个功能前，一般都会写一份详细的测试用例并执行，但是后面有需求变更或出现其他不在测试用例中的测试点，都懒得再添加到测试用例中了，即很少会再去维护测试用例了。希望能改掉这个坏毛病

作者: 楠族开心果 时间: 2020-5-19 15:13
哇挖坟啊

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)