实际工作中，写的测试用例你会用到多少？
需求在不断的变化，测试时间的紧迫性，实际工作中，你会写完整个系统的全部测试用例吗，在执行测试的过程中，你又会用到多少测试用例？（发觉执行测试时，灵机一动，突来灵感，还好比原先写的测试用例）。哎 这个问题困惑我好久好久。。。望好心人指点！ ding 现在测试用例都很少写了，一般就是比较重要的场景写个测试用例，其他的都是直接开动的 时间紧迫，全写的是功能点的测试用例，写完之的，直接执行，顾不了这么多 本帖最后由 linghai521 于 2011-9-21 15:25 编辑
闲来无事试着解答一下你的困惑吧，4年前我刚入职测试的时候也是对测试用例的实际价值和具体应用有过相当一段时间的不解，不过当时没人能给我一个真正合理并具有说服性的理由，只知道很重要，就这样一直做下来，直到4年后现在的我，当带别人的时候我也会说测试用例很重要，是一个测试人员的核心能力，测试的好坏一半取决于你对测试用例的编写能力，另一半来自于你对业务的发散性思维，来自于测试人员测试时的状态。
不要说时间紧迫，需求变化较快，如果你提前在心里就为自己找好了不去做的理由，那么对这项工作你会永远都保持着抵触的情绪，进而越发的觉得测试用例没用。我具体说几点希望能让你对测试用例有所改观：
1、先说说你所说的编写用例和临时的灵感之间的区别，这也是现在很多测试人员的困惑，因为工作中所有的感觉都在告诉我们，临时的发挥往往发现更多更隐蔽的bug，而测试用例中往往也都是开发人员已经注意过的地方，能出现让你感觉很有成就感的bug实属不易，但我前面说了，这仅仅限于我们的感觉，举个大学时的例子来解答你这个困惑，我记得我大学的时候我的高数老师在讲课的同时不忘提醒我们该以怎样的态度对待目前的知识，我想大多数同学都会有我这样的想法，看看书本上的东西，这么简单还用学么，临时看看就会了，况且学了能有什么用呢？有一天老师在讲一个简单的公理时突然说了一句话，他说这个公理是很简单，是最基础的，但我提醒大家最基础不是不重要，相反它是最重要的，如果没有这个基础公理后续课程中所有的理论都不存在。这句话我一直记在心里，基础的是最重要的，这也是我一直很痛心的地方，因为平时我看着都会的东西，一个学期过去，我居然什么都不会了，我很鄙视同学平时不断的做着我看着都会的题目，可到最后我都答不上来了，可同学却很轻松的交卷了。
不知道你对我所说的能否理解，编写测试用例我们都很不耐烦，觉得自己到时候也知道这些，写了又有什么用呢？可真正到了测试的时候你凭什么说你都知道呢，这不过是一厢情愿的想想罢了，就像我面对刚开始简单的公理，我反复做这个公理的题有什么用呢，多简单啊，可对简单的都无法理解吃透，又如何在简单的基础上进行发散性思考？一个系统连基本的保障都没有，仅靠临时的灵感去挖掘我们不太容易发现的问题，我想你自己心里对系统都没底吧。简单的说，编写是基础，临时的灵感是深度挖掘。
2、如果说上面的理由不足以说服你，那么再看看这一点如何。不靠谱的灵感——如论是哪个测试人员，都会承认，测试与我们本身的状态有相当紧密的关系，如写文章一样，状态好时文思如泉涌，状态不好时提笔忘字，甚至生厌，毕竟我们大多仍然还执行着手工测试，工作的单调和枯燥不会让你像一直打了兴奋剂一样，此时你如何保障你的测试是有效的？
3、盲点。不知道你是否听过这个词，由于每个人的逻辑思维迥异，看待事物必然不同，针对一个测试点每个人编写的测试用例也会有不同，我不相信一个人可以把一个系统想得方方面面滴水不漏，bug总是源源不断超出你的想象，这些你想不到的即是你的盲点，当你把编写好的测试用例上交评审时，你会发现别人总是会提出这样那样的问题，你会发现你原有的逻辑竟然暗藏N多漏洞，更可怕的是随着工作的进行，当你对系统进行多次的回归，你会发现你可测的越来越少，为何？不是你的错，每个人在持续的重复同样的活动时，都会渐渐失去原有状态，渐渐麻木，那么我们的盲点也会偷偷的加大，如果没有提前的测试用例保证，你可以保证你在系统交付前的测试与你第一遍测试的内容完全一致么？如果不完全一致，那些落下的测试点，你测试过吗，测试几次呢？现在是正确的吗？
4、管理成本。这个应该说和部门对项目的长期管理有关，面对现今IT业人员流动大的特性，每个部门对项目的管理成本在加大，老员工离职留下一堆问题，新员工入职业务不熟，无法马上接手，之前的系统如何，由谁去给他讲解？对于测试，我想如果我是管理者，我会直接给他一些模块的测试用例，按着这些用例去测试，从这些用例中去理解系统，即增加了一点人手，也极大提高他学习的速度，4年的经历告诉我一个新入职的测试人员仅仅是看需求说明来学习，效率异常低下，并且一旦实际接手测试任务，之前所学习的基本还得对着系统重来一遍，记得，企业招聘员工，要尽可能要你来创造更多的效益，当然这个效益创造的越早越好，而不是真的让你来学习。
或者整体来说，测试用例是测试对系统的一个基本的质量保障，是一个项目可持续化管理的有效手段之一，当然，不是说写了测试用例就万事大吉，软件就毫无问题，还是我老师那句话，这是最基础的，也是最重要的，你的那些灵感会使你的测试大放异彩，但绝不要被这色彩蒙住你的眼睛，导致你看不清基石而摔下来。
最后回到我开始说的，"不要说时间紧迫，需求变化快"，这个问题我不想多说，因为这个问题只要我们想解决，总会有办法，关键是看你以什么样的态度对待，想克服就不是什么大问题，不想克服，那就无解。
以上只是简单说了下测试用例实际的好处与作用，当然不止这些，既然有这些好处，至于你执行多少全在自己，现在很多企业都想采用敏捷开发的方式，对测试也发起了新的挑战，也有人用测试点或者需求列表的形式来代替，无论什么形式都无所谓，选择一条最适合当前部门状况的方式，但你所说的灵感是绝不靠谱的事情，两者无法比较。
希望上面的文字能对你有所帮助。 回复 5# linghai521
不错 顶一个 写的很不错 回复 5# linghai521
多谢你的指导~~从中受益匪浅~~·thanks！ 回复linghai521
多谢你的指导~~从中受益匪浅~~·thanks！
黄袖标 发表于 2011-9-23 16:01 http://bbs.51testing.com/images/common/back.gif
呵呵，我也一直在学习总结之前的工作，测试不仅是一项技术工作，更是一门管理艺术，不懂的太多，一起努力学习吧。 自卑啊 新手过来学习的 新手过来学习的 读过。 不错，学习了。。。。。。。 回复 1# 黄袖标
我一般都会写测试用例的，我们公司的流程还蛮正规的，我们的测试经理会留时间给我们写用例的，并且用例还需要评审的
对于你说的需求在不断的变化，那你可以在进行测试之前把用例改一下呀，如果你对系统熟悉的话，也不是需要花费很多时间呀，有测试用例的话，很有条理，可以知道自己哪块测了，哪块没测，并且不会遗漏，这样还方便以后的回归测试，重点回归那些没通过的测试用例
以上是我个人观点，\(^o^)/~ 我们公司也要写，毕竟临场发挥是个不靠谱的事情，有用例，就可以追踪 现在基本把用例当备忘录吧，真的要找BUG的话还是手工找。。。。 回复 15# xuxf
嗯~~受教！公司现在只有我一个人做测试，想把测试流程正规化，看来我还得继续加油呀。~~ 领教了。 顶 5 楼..
页:
[1]
2
