[原创] 实际工作中测试用例应用难点调查 工程师, 大家一起来

ppent

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

juyoc

看来都是有心无力！

ppent

顶一下！希望引起更多的关注！

phoenixDT

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

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

lona_ma

测试用例经常是测完了再补，边测边写，明天就要测了，今天才拿到需求写用例，晕阿~~

花蕾恋

我一般都不写什么正规的测试用例，测试前想下需要测试哪些功能，然后写个简单的文档列出来
一个一个测试完有问题的就记录下来．．感觉好菜啊

archonwang

耗费的时间和人力成本很高，效果也不见得很好，对测试用例既认同又反对，很矛盾。

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

Jeongspear

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

Joan2005

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

shiyi1022

哈哈 都大同小异

ppent

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

Ancen

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

我们做测试用例不仅是为了整理自己的思路，也是为了新入的测试人员根据用例就可以执行测试，而不需要耗时耗力去了解需求再写用例
目的并不是单纯的为了完成任务，提交测试用例文档。
仅以如此，逐渐完善我们的测试流程，提高效率。

-----
当然以上仅是个人的一些浅薄的观点，学习大家的经验，能共同提高

[ 本帖最后由 Ancen 于 2007-3-11 01:48 编辑 ]

ypeony

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

kevin_swpi

TD
直接将需求 测试计划 测试用例 BUG几者联系起来

zl_coffee

是啊，郁闷啊

vickiren

我刚接触测试，在方法和技术上面欠缺。

jacky9947

现在公司的项目的需求管理不规范,程序员对需求都不是十分清楚,我们测试就更不清楚了,迷茫中.

kyy

现在很多的公司测试计划和用例都很不规范的   要想提高这方面的业务必须提升员工的业务水平和领导的重视的

leiying

公司的整个文档还没有规范，写测试用例真是没有效率

hapliu

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