以前就lz写的,自由发挥。呵呵~
若是完全按用例来感觉有点死板。不舒服。 几乎没有测试的经验,软件测试对我来说真的是很神秘。
哪位前辈帮我出出主意,怎样才能步入测试行业呀!
现在在努力学习ing......sdlkfj7 原帖由 ppent 于 2007-3-7 10:21 发表 http://bbs.51testing.com/images/common/back.gif
测试用例的维护确实很麻烦,工作量很大,特别是当没有规范的变更管理时,测试用例不能跟的上功能的变化,测试用例则成了一个鸡肋。真的是用之无益,弃之可惜。
不知道你有什么好的方法呢?
其实这个最重要的还是看测试部门的leader是怎么看待这个问题的,如果leader是一个很有质量管理思想的人那么测试用例在经过两三个项目之后就不会再是鸡肋了,但如果连测试人员也不重视质量管理的话那这个就真的没什么意思了~ 原帖由 ppent 于 2007-3-7 10:38 发表 http://bbs.51testing.com/images/common/back.gif
测试用例设计被称为最能体现测试人员价值的工作之一,同时也是测试的精华所在。然而测试用例的实际应用如果象上面投票所示,说明测试用例实际应用根本达不到理论的高度。在这种情况下,就更加谈不上测试用例的维 ...
测试用例是在测试过程中不断进行更新与维护的,但一个项目做完而且也对该项目的测试用例做过系统总结之后,只需要用管理工具存放起来即可,当有类似项目类似功能时取出来做为借鉴,这样就会有一部分测试用例会跟随着项目而不断的完美和充实,最终形成一个测试用例的模板
至于测试人员在执行测试用例时的具体心态与积极性,这个要看一、本人的工作态度;二、本人的主观能动性;三、测试部门对测试人员工作成绩的具体衡量方法,如果前两点该测试人员做的不好,那只能靠第三点来督促,但如果第三点做的也不好或是不合理那问题就比较棘手了,所以其实最本质的是测试部门的管理问题
以上只是个人浅见~ 测试用例的粗细粒度很难把握. 测试用例原本就是为了提高我们的测试效率,如果测试之前没有经过严密的测试用例的设计,真正到测试的时候,在这个很短的测试时间段内,我们可能会遗漏了一些无效的测试用例,没有覆盖到,也正如猴子测试班,我们的效率提高不起来,而且无形中也增大了测试的风险. 测试用例,根本就不怎么用。一般都是直接看产品需求。 只编写了基本的测试用例,根据情况有时按测试用例执行测试,测试用例效果一般
由于刚进入测试行业,所以在写测试用例时没考虑周到,执行效果一般 我想在外企可能更注重测试用例的设计,测试时会按照设计的测试用例来操作。
在外企工作的朋友,说说你们的看法。 测试用例的设计是我们软件测试工程师的最基本要求和最基本技能,设计测试用例好处很多,
测试不能盲目进行,要有计划,有步骤,有思路,去合理科学地测试。
个人觉得测试一定要设计测试用例,既然都把时间给了写TC,为什么不写的更好点,更完整点呢? 变化中求生存! sdlkfj7 根据实际情况决定用例程度。没有详细的需求和设计文档,很难设计出非常好的用例 之前的测试情况是第三种
但是现在想做成第一种
正在努力种 我们写的用例来自客户的需求,但实际测试时往往又发现其实那些需求还是很粗的,越测试就离最开始的测试用例偏离越远了,
难道是缺少测试用例的维护么?一边测试一边还要不停的补充用例么?总觉得维护的工作量是一种浪费,所以很矛盾呢~~
sdlkfj9 sdlkfj9 是啊,我也和楼上的一样矛盾啊。。
回复 #6 archonwang 的帖子
确实是这样的,我们的用例需要随着PD和developer的文档变化而变化,维护非常的重要,很多时间都浪费在这个上面 原帖由 by1945 于 2007-4-9 11:52 发表 http://bbs.51testing.com/images/common/back.gif呵呵,非常赞同ppent 的观点,一直都觉得测试用例是个鸡肋,我测试也是写些测试要点进行标记,然后进行测试,觉得比呆板的维护执行测试用例好多了,人有激情些,感觉按照测试用例来执行,心里憋得慌;
不过我现 ...
你说得很对,写写测试要点记录测试内容以防遗漏,这比呆板的写些test case要简略而且容易维护,但是如果所测试的项目这个版本发布了,以后还有后续版本的话,有test case,就只需要依照以前的case来执行就可以了,免去很多的工作,这时候有详细的case就比较好了 原帖由 x00ganlu 于 2007-4-24 12:43 发表 http://bbs.51testing.com/images/common/back.gif
功能测试用例写到一半写不下去了,太多了 都很细
估计也不能一一执行,
刚写case的时候也有这种感觉,但是我们的是automation test,希望能够执行所有的case