实际工作中测试用例应用难点调查

s428lsy

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

gxf1015

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

xiaoyaoke

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

regwizh

http://bbs.51testing.com/thread-96486-1-1.html

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

熙文

我们公司根本就没给过我们需求,我们只是凭自己经验和参照实际的产品作对比写测试用例的,感觉根本就没用

shaofei19820625

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

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

tianyue

4.  缺乏必要的需求设计文档，以及需求设计的频繁变更
感觉中国大部分中小型企业都是这样的~还美其名曰敏捷型开发~

kpsz202

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

mvjh13

大量的需求设计变更，导致不断的修改测试用例，让人烦

wzts1985

谢谢共享～～～～

葫葫

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

liulinzhu

待了几个公司，发觉第四点是它们的共同点。

x00ganlu

我觉得如何组织测试用例是个很大的问题，如果一个用例步骤繁多，就个人感觉，自己写完了都不会照着执行

◎了了

我就我自己一个人设计 一个人检查

李靖之

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

cultureroom

千头万绪~~

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

夏日么么茶

写用例好枯燥呀！

junlingliu

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

追寻浮华

59楼的正常， 大部分公司都这样。.是公司项目缺乏竞争力,很多时候没这种机会让你按照规则来， 没办法，的事情， 尽力处理吧.只能

jiuquanzi

个人觉得第一个选项也是存在的,但还是可以通过个人或是集体的努力能克服的.
但是第四个选项的dependency太大, 通过集体的努力是没法克服的, 只能是尽量减小影响而已