51Testing软件测试论坛

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

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

作者: juyoc 时间: 2007-2-9 11:35
看来都是有心无力！

作者: ppent 时间: 2007-2-9 18:12
顶一下！希望引起更多的关注！

作者: phoenixDT 时间: 2007-2-15 21:41
我现在的公司就是这样的，尽管想把测试用例做好，也知道测试用例在以后工作的重要性，但是等项目忙起来的时候，就无暇顾及了。

感觉还是方法问题。。。个人想法

作者: lona_ma 时间: 2007-2-16 09:13
测试用例经常是测完了再补，边测边写，明天就要测了，今天才拿到需求写用例，晕阿~~

作者: 花蕾恋 时间: 2007-3-2 13:08
我一般都不写什么正规的测试用例，测试前想下需要测试哪些功能，然后写个简单的文档列出来
一个一个测试完有问题的就记录下来．．感觉好菜啊

作者: archonwang 时间: 2007-3-2 13:52
耗费的时间和人力成本很高，效果也不见得很好，对测试用例既认同又反对，很矛盾。

如果团队相对稳定，建立纲领性问题和框架就可以，如果流动很大或多头处理，还是老老实实写吧。

作者: Jeongspear 时间: 2007-3-4 00:16
有时候项目的需求不是很明朗,需求的变动很大,在前期很难写测试用例,但是等产品基本成形后又由于项目进度不得不马上进行测试...这种情况下测试用例只能边测边写,甚至是等测完再补sdlkfj7

作者: Joan2005 时间: 2007-3-5 14:06
需求变化频繁,但是不会更新需求文档,往往是需求文档形成后,到测试结束都不会有更新.在测试过程中,发现程序与需求不符的情况,就跟项目经理或开发人员沟通.确认才被告之需求变更...所以需求说明书本身的实用性不是很强,有时只是一个形式,简单的描述模块功能.这样设计的测试用例也很简单,几乎用不到什么设计方法,就是操作步骤的一个描述而已.
顺便说下,公司就一个测试人员,自己写测试用例自己测试.知道如何测试后,一般就不按测试用例去执行了....sdlkfj1

作者: shiyi1022 时间: 2007-3-6 17:42
哈哈都大同小异

作者: ppent 时间: 2007-3-7 10:52
标题: 回复 #7 archonwang 的帖子
很同意#archonwang 的话：耗费的时间和人力成本很高，效果也不见得很好，对测试用例既认同又反对，很矛盾。
测试用例的输入条件（设计技术、时间资源、必要文档）与测试用例的输出产生的价值有很大的关系，两者相互相乘。满足输入条件则可以产生高价值的输出，高价值的输出又对输入有更好的推动作用。

作者: ypeony 时间: 2007-3-14 10:33
我们公司比较重视用例的维护，在测试过程中需要补充用例。不知道各位是怎么使BUG和对应的用例关联起来的。用例的格式中包含有测试编号吗？一般大家采用的用例编写格式是怎么样的啊？

作者: kevin_swpi 时间: 2007-3-14 11:18
TD
直接将需求测试计划测试用例 BUG几者联系起来

作者: zl_coffee 时间: 2007-3-22 19:24
是啊，郁闷啊

作者: vickiren 时间: 2007-3-23 14:30
标题: 回复 #8 Jeongspear 的帖子
我刚接触测试，在方法和技术上面欠缺。

作者: jacky9947 时间: 2007-3-23 15:05
现在公司的项目的需求管理不规范,程序员对需求都不是十分清楚,我们测试就更不清楚了,迷茫中.

作者: kyy 时间: 2007-4-12 11:50
现在很多的公司测试计划和用例都很不规范的要想提高这方面的业务必须提升员工的业务水平和领导的重视的

作者: leiying 时间: 2007-4-12 17:25
公司的整个文档还没有规范，写测试用例真是没有效率

作者: hapliu 时间: 2007-5-19 10:08
标题: 需求的变更，人员的交流
需求变更，可能会导致功能的删除和增加，修改。导致测试用例有大的变更。
人员之间的交流也需要加强，比如测试人员之间，测试人员与开发人员的交流需要及时性

作者: 巩员外 时间: 2007-5-25 11:30
心有余而力不足 !

作者: I_hui 时间: 2007-6-13 16:20
其实不同的环境中，遇到的情况是不一样的
不过都是大同小异的吧
那因人而异吧！！！

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

作者: njalic 时间: 2007-7-4 13:30
没时间,没人,没文档,
什么都有~~~~~~~~~~~
领导还要求测的软件一个问题都没有,

我要死的心都有了~~~~~~~~~~~~~

作者: 刘洪鹏 时间: 2007-7-4 13:58
没有难做的事只有难成事的人
我就不相信没有做不成的事

作者: bluejone 时间: 2007-7-4 20:07
一般来说，根据需求文档分析测试需求，之后设计测试用例，整个项目下来，用例倒是设计了不少，可是在执行过程中却发现，用例和实际执行情况还是有差别的，感觉用例和实际脱节了。
问题好像是出在对需求的分析不够细节上，可是设计用例时，如何考虑到开发具体的实现细节呢

作者: sleepygirl 时间: 2007-7-11 15:43
我们公司有时候是时间很紧，给你需求报告，要求很短的时间把测试用例做好；有时候又没有需求报告，完全是根据产品来写！感觉不太规范！不过我还是尽量按照需求写测试用例！
sdlkfj5

作者: iceblue72 时间: 2007-7-12 11:36
公司各种规范都不完善。很难啊

作者: victoriatuline 时间: 2007-7-12 16:10
标题: 确实是这样
我们公司只重视发现了多少人Bug。

作者: zhanbuqiu 时间: 2007-7-13 11:19
我做的是WEB測試，測試時沒有文檔資料
也不要求寫用例，測到BUG就一條條記錄下來

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

作者: testw 时间: 2007-8-12 19:57
一直很费解

作者: liulinzhu 时间: 2007-8-13 16:00
都没需要，怎么写用例，难道公司认为我们都是天才？！

作者: serena_chueng 时间: 2007-8-13 16:48

原帖由 Ancen 于 2007-3-11 01:46 发表
我所在的公司，由于体制不完备性，需求经常变更，更有可能上线前两天还在变；
但是无论怎样，我都会按照测试用例去执行。
我所做的流程是
分析需求-->写用例-->执行用例
若有需求变更
需求变更分析-->维护 ...

我们一直没做到的...那如果时间不够怎么办呢?

作者: 平平淡淡才是真 时间: 2007-8-17 14:51
感觉对测试用例的后期维护还是不够到位。

作者: sandsor 时间: 2007-8-18 12:54
我是一个还没上测试工作岗位的人, 看到大家写的工作体会,
如果都能在公司里反映并且重视了,
那样的想法是不是世外桃源?

我相信公司总是在逐渐成熟中....
可是, 总得有期吧, 什么时候呢?? 我盼忘着,

作者: jaunty 时间: 2007-9-21 16:08
我觉得很奇怪
为什么最后一项选择的人那么多呢
需求变更多，没有合理的控制是项目管理的问题
而不应该是用例实践的难点
我们应该针对用例和它的实施来分析

我觉得这个投票的选项本身就有问题

作者: tongfei96 时间: 2007-10-4 15:01
标题: 回复
第四面的选票这么多,我也意外,需求这东西变更这么快吗?

作者: baiking1 时间: 2007-10-23 16:32
需求文档根本不合格才是我的困扰，只是描述了基本功能，如何实现根本没有，怎么写哦

作者: 沙巴克 时间: 2007-10-23 17:42
如果文档是应付的
测试用例就很弱了
效果不是很明显，而且浪费时间
但是要坚持写用例

作者: getfly 时间: 2007-10-25 17:16
有的时候，在简单与详细中去一个平衡点，这样会好一点。但是这个平衡点怎么样娶,也是一个问题。个人觉得要写详细点好，概要的用例是能够让执行的人没有枯躁的感觉，但是也是已相应得风险的作为代价的。随机的就会存在风险。而且不利于经验的积累。也无法跟踪。

作者: s428lsy 时间: 2007-11-6 14:28
我公司需求文档变更快，往往测试用例设计好了之后，需求已经变化很大，然后项目做完了，又赶时间测试，这样写测试用例往往没什么作用，只有在心里列出一些功能点来测试

作者: gxf1015 时间: 2007-11-7 10:03
标题: 用例
用例是肯定要写的，如果公司有新人加入。可以让他们更快上手的。再说回归测试的时候你也不可能再对以前没有改动的地方写啊。我觉得用例最重要还是在项目回归时。平时自己测心中都有相应的用例了，写写吧！

作者: xiaoyaoke 时间: 2007-11-7 10:26
标题: 个人意见
感觉用例还是需要写的，当然我所说的用例是通过性测试的用例，这些用例基本覆盖了软件的主要功能模块和常规操作，这样写出来的用例在后期变动相对较小，而且可以保证软件正常运行
至于崩溃性测试的用例，我感觉这样的测试是很难提前编写的，很多时候完全是一个灵感，所以只能说是一边测一边写或者测完之后再写

作者: regwizh 时间: 2007-11-9 10:11
http://bbs.51testing.com/thread-96486-1-1.html

技术分享：希望大家看看我的测试用例。。。。然后多多指教一下，特别是针对正交这方面。有经验的看看我写的可不可行。。。。

作者: 熙文 时间: 2007-11-10 21:37
我们公司根本就没给过我们需求,我们只是凭自己经验和参照实际的产品作对比写测试用例的,感觉根本就没用

作者: shaofei19820625 时间: 2007-11-14 12:55
我觉得最大的难点是如何设计有效用例的方法,有好的方法,那么需求的变更,用例的维护都会更加简单.
曾经视图用TD里的参数化的方式来写一些通用的用例,因为公司项目框架都是类似的,很多用例都可以复用

[ 本帖最后由 shaofei19820625 于 2007-11-14 12:57 编辑 ]

作者: tianyue 时间: 2007-11-19 17:37
4. 缺乏必要的需求设计文档，以及需求设计的频繁变更
感觉中国大部分中小型企业都是这样的~还美其名曰敏捷型开发~

作者: kpsz202 时间: 2007-12-12 23:48
感觉做测试这行的，最最最主要的是看顾客的要求，一个软件或系统做出来，时常会随着顾客的思路走，而顾客的思想是难以捉摸的，因此顾客要求变化，程序设计跟着改变，相应测试也跟改变。

作者: mvjh13 时间: 2007-12-18 11:33
大量的需求设计变更，导致不断的修改测试用例，让人烦

作者: wzts1985 时间: 2008-1-9 11:24
谢谢共享～～～～

作者: 葫葫 时间: 2008-1-23 11:28
我个人认为，时间，资源，需求设计文档，需求变更都是很关键的问题，
由于以上的种种问题，我的打算是，写一个测试用例指导文档，不写具体的例子，只写需要测到哪些方面，比如，一个输入文本框，应该测哪些输入，字母、符号、汉字、空格。不同的文本框有不同的要求，因为没有专门只是执行测试的人员，所以，个人感觉这样或许比较切实可行。

作者: liulinzhu 时间: 2008-2-18 17:09
待了几个公司，发觉第四点是它们的共同点。

作者: x00ganlu 时间: 2008-2-26 10:55
我觉得如何组织测试用例是个很大的问题，如果一个用例步骤繁多，就个人感觉，自己写完了都不会照着执行

作者: ◎了了 时间: 2008-2-26 11:30
我就我自己一个人设计一个人检查

作者: 李靖之 时间: 2008-4-17 19:43
用例最主要的输入,执行,预期
可是有些问题不是光凭需求文档就能够解决的,需求中没有描述的预期,让写用例的怎么办呢!
用例写出来了,有时候还会被开发或产品的一句"用户绝对不会这么做的!"给打发回去了~现在是残酷的呀!!!!!

作者: cultureroom 时间: 2008-4-24 15:44
千头万绪~~

总之，计划做得再好也赶不上变化.....

作者: 夏日么么茶 时间: 2008-4-29 10:51
写用例好枯燥呀！

作者: junlingliu 时间: 2008-5-12 16:34
我们也是，感觉写起来更浪费时间，忙起来就全凭脑袋了，真的不知道该如何控制此类情况；测试需求不断变更也导致维护的难度！

作者: 追寻浮华 时间: 2008-6-4 11:38
59楼的正常，大部分公司都这样。.是公司项目缺乏竞争力,很多时候没这种机会让你按照规则来，没办法，的事情，尽力处理吧.只能

作者: jiuquanzi 时间: 2008-6-17 10:57
个人觉得第一个选项也是存在的,但还是可以通过个人或是集体的努力能克服的.
但是第四个选项的dependency太大, 通过集体的努力是没法克服的, 只能是尽量减小影响而已

作者: yuelimin1211 时间: 2008-7-1 09:24
标题: 需求文档
需求文档的完备对于写测试用例真的很重要~

作者: gentlehug 时间: 2008-7-1 10:54
初学，1、4都是难点啊。。

作者: qiaoh 时间: 2008-7-22 09:15
标题: 颇有同感
感觉差不多一样的，一般任务过来比较急，连需求都不一定看的到，就拿着系统凭经验测试，大的系统需求跟系统还有距离，前期写的也笼统，都是边测试边写用例，系统都测完了，用例还没补完……

作者: 兰兰 时间: 2008-9-12 11:15
我们公司也是了，规定了严格的测试流程，但是在具体实施的过程中，有时由于项目工期紧张，需求不断变化，测试用例设计工作量太大，因此在具体的工作过程中就跟7楼说的现象一样，这样的做法是测试用例设计的实际意义并不大，只是单纯的为了应付领导们的检查。

作者: AwL_1124 时间: 2008-9-17 22:20

作者: sweetxmy 时间: 2008-10-13 18:44
标题: 我觉得测试完后补写测试用例可以更全面的完成测试
因为测试任务比较紧，基本是先做测试计划，然后做测试。
有空的时候我就补充测试用例，真的很有趣，我发现在写测试用例时，有时会发现原来当时测试时还有点漏动。

作者: jimoling 时间: 2009-5-25 18:16
看来大家都存在同样的烦恼。。。

作者: 兆隆8032 时间: 2009-6-8 11:07
四个选项中，我个人认为第一个是经验和技术水平的问题，这个通过学习和项目完全是可以提高的。编写测试用例是需要很长时间的，但是编写测试用例的好处大家众所周知，便于维护，利于后期的回归测试等等。约束测试人员的思路，我个人认为那是用例设计不合理的结果。需求的不断变化，对于测试的影响是最大的，我们什么都要来自需求，如果一直再变，不仅编写浪费了时间，执行也变得意义不大了。

作者: 兆隆8032 时间: 2009-6-8 11:08

原帖由 sweetxmy 于 2008-10-13 18:44 发表
因为测试任务比较紧，基本是先做测试计划，然后做测试。
有空的时候我就补充测试用例，真的很有趣，我发现在写测试用例时，有时会发现原来当时测试时还有点漏动。

顶你，同意

作者: zhengjie963 时间: 2009-6-10 13:38
要是需求更改了那就真的吐血了

作者: pycctv 时间: 2009-7-1 14:32
我觉得还有一方面就是软件测试在国内的发展现状，毕竟要想组织一个测试团体不是一个人两个人的事，最主要的是现在的公司基本上没有做测试的合适的人员，连人都没有，还如何开展测试，更不要提设计测试用例了；还有就是所具备的人员的能力，还有公司对策是的重视程度，就像我们公司，领导觉得软件需求即使是有，也不应该是软件测试人员看的，软件测试人员就是运行一下软件而已，没有必要看需求，所以导致测试很难进行。

作者: lery 时间: 2009-8-12 23:55
标题: 测试时间紧迫问题
用例在遇到时间问题时候显得很无助，嘿嘿
用例一般是写给new hand 看的，嘿嘿

作者: gongx2008 时间: 2009-8-24 21:54
标题: 难
着局面难改啊。。。

作者: gnixougil 时间: 2009-11-11 11:54
研发的也是和咱们一个心理呵呵要怪就怪BOSS头脑经常发热

作者: muyang327 时间: 2009-11-19 18:14
普遍现象

作者: freedom_me 时间: 2009-12-3 12:19

作者: larkygirl 时间: 2010-5-13 11:53
标题: 貌似大家的处境都一样，。
呵呵。期待中国的测试业近五年有突破性的发展。

作者: 楠族开心果 时间: 2010-5-13 15:42
看来第四点人很多嘛

作者: my145 时间: 2011-10-28 16:11
我做黑盒测试三年半了，哎，无语啊

作者: hero_mars 时间: 2011-11-1 16:29
大家说的真的深有同感啊！悲剧啊！

作者: wallffpp 时间: 2011-11-22 23:03
需求变更永远是测试的天敌

作者: fuhao 时间: 2012-1-5 16:07
需求变更，可能会导致功能的删除和增加，修改。导致测试用例有大的变更。
人员之间的交流也需要加强，比如测试人员之间，测试人员与开发人员的交流需要及时性

作者: SariyaLee 时间: 2012-1-6 16:03
公司不重视测试人员测试也没有规范和框架

作者: 1987gql 时间: 2012-1-19 17:44
[img][/img]

作者: isco14k 时间: 2013-11-27 14:54
我都是直接根据需求测试的，等验收的时候，补点用例

作者: yj7503402 时间: 2013-11-28 14:35
大部分时间是根据需求，时间很紧，测试都不够时间，更加不用写测试用例了

作者: hsrak47 时间: 2014-8-4 13:27
回复 55# 李靖之

感同深受！

作者: shjpl238bbk 时间: 2014-12-2 20:07
在我看来，测试用例设计的难点在于测试工程师的基础
1、准确划分功能点
2、对业务的熟悉程度
3、用例属性划分不清晰（A/B/C）,这个划分清除了，直接可以通过筛选来实现不同任务的测试
4、测试用例步骤和预期结果的描述（其实这点靠的是测试人员的语言能力）
5、第一界面、一级菜单、基本功能、主要功能、次要功能等属性的细分和掌握

作者: USATOWN 时间: 2015-9-14 16:53
我的观点把上都覆盖了

作者: 这个猪猪有点瘦 时间: 2016-10-27 15:49
写用例时间长，工作紧时根本没空写

作者: simonash 时间: 2017-1-19 13:33
都是10年前的回复?

作者: 123913645 时间: 2017-2-6 15:26
项目目前的版本计划中测试的时间是不由测试人员来评的，直接一刀切了，导致测试用例设计时间不够，各种问题啊！

作者: 408467753 时间: 2017-4-19 22:41
不用想都知道肯定是第四个答案

作者: 408467753 时间: 2017-4-25 10:49
我就想问一下，选择第三个选项的人，是什么心态？

作者: zgfy+++ 时间: 2020-3-2 13:56
需求的变更实在太频繁了，最先写的用例到后来真正测试的时候能用的其实不多，好多都是后来改的。小公司也没有真正意义上的需求文档，只有UI做的一个原型图，好多需求都是给到测试的时候再去确认的。。前期的需求确认都没有测试参加的，就项目经理自己确定了然后和开发讲要怎么怎么做。

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