实际工作中测试用例应用难点调查
一直以来作为测试工程师的我们深信测试用例设计技术是我们的一项核心技术并进行了很多交流,但在实际工作中测试用例真正应用起来了吗,我们把测试用例真正应用起来的难点在哪呢?大家一起来投票看看。该投票结果应该对我们学习测试用例设计技术的方向、深度、如何应用有很大的影响。如果还有其它选项,请补充。 看来都是有心无力! 顶一下!希望引起更多的关注! 我现在的公司就是这样的,尽管想把测试用例做好,也知道测试用例在以后工作的重要性,但是等项目忙起来的时候,就无暇顾及了。
感觉还是方法问题。。。个人想法 测试用例经常是测完了再补,边测边写,明天就要测了,今天才拿到需求写用例,晕阿~~ 我一般都不写什么正规的测试用例,测试前想下需要测试哪些功能,然后写个简单的文档列出来
一个一个测试完有问题的就记录下来..感觉好菜啊 耗费的时间和人力成本很高,效果也不见得很好,对测试用例既认同又反对,很矛盾。
如果团队相对稳定,建立纲领性问题和框架就可以,如果流动很大或多头处理,还是老老实实写吧。 有时候项目的需求不是很明朗,需求的变动很大,在前期很难写测试用例,但是等产品基本成形后又由于项目进度不得不马上进行测试...这种情况下测试用例只能边测边写,甚至是等测完再补sdlkfj7 需求变化频繁,但是不会更新需求文档,往往是需求文档形成后,到测试结束都不会有更新.在测试过程中,发现程序与需求不符的情况,就跟项目经理或开发人员沟通.确认才被告之需求变更...所以需求说明书本身的实用性不是很强,有时只是一个形式,简单的描述模块功能.这样设计的测试用例也很简单,几乎用不到什么设计方法,就是操作步骤的一个描述而已.
顺便说下,公司就一个测试人员,自己写测试用例自己测试.知道如何测试后,一般就不按测试用例去执行了....sdlkfj1 哈哈 都大同小异
回复 #7 archonwang 的帖子
很同意#archonwang 的话:耗费的时间和人力成本很高,效果也不见得很好,对测试用例既认同又反对,很矛盾。测试用例的输入条件(设计技术、时间资源、必要文档)与测试用例的输出产生的价值有很大的关系,两者相互相乘。满足输入条件则可以产生高价值的输出,高价值的输出又对输入有更好的推动作用。 我们公司比较重视用例的维护,在测试过程中需要补充用例。不知道各位是怎么使BUG和对应的用例关联起来的。用例的格式中包含有测试编号吗?一般大家采用的用例编写格式是怎么样的啊? TD
直接将需求 测试计划 测试用例 BUG几者联系起来 是啊,郁闷啊
回复 #8 Jeongspear 的帖子
我刚接触测试,在方法和技术上面欠缺。 现在公司的项目的需求管理不规范,程序员对需求都不是十分清楚,我们测试就更不清楚了,迷茫中. 现在很多的公司测试计划和用例都很不规范的 要想提高这方面的业务必须提升员工的业务水平和领导的重视的 公司的整个文档还没有规范,写测试用例真是没有效率需求的变更,人员的交流
需求变更,可能会导致功能的删除和增加,修改。导致测试用例有大的变更。人员之间的交流也需要加强,比如测试人员之间,测试人员与开发人员的交流需要及时性 心有余而力不足 !