测试用例的必要性？？
众所周知，测试用例是软件测试流程中必不可少的内容之一，但是小弟最近的项目非常紧，几个项目交叉没有时间完成用例，项目都是交叉测试的，很累，很累。回头让下面的人补用例真的很残忍（大家都很辛苦，谁都想休息休息）~我想“测试用例”是不是真的需要？
我现在用测试功能列表来代替测试用例，效果不是很好~
不知道大家实际工作中有没有好方法 管理问题
计划问题 测都测完了还补什么用例接受教训下次在需求和详细设计的阶段就开始准备用例在程序完成前准备好 有机会还是补充一下用例比较好一点。至少有几个作用：
1、有时间想想测试究竟做到什么程度了，还有没有未测试到的，是不是测试可以结束了
2、锻炼一下测试思维。 我觉得还是必要的
有些你不想列出详细的步骤
起码也要列出主要的测试点。
如：
测试用户注册。
你可以说用字符，数字，字符数字三种组合各测试一次登陆。
并且输入正确密码，错误密码和不输入密码应包含在组合内。
你可以不写步骤，
但最起码你要列出这些组合或描述组合规则。
并且在测试时候勾出你覆盖到的
这样才不至于遗漏测试点 感谢大家的回复
1，2F的朋友有可能没有经历过我这样的工作，没有时间让开发人员作那些设计，需求完了之后就直接开发，好在我们测试的人都是业务比较熟练的，全部压到我们这里，累呀。
3F的朋友，我们有时间还是会补的，呵呵，项目一忙完大家都想休息，我不忍心呀，呵呵。
4F的朋友，我现在就是用您说的方法，但是测试点老是不全，也许是我经验不足造成的，我干测试一年，呵呵~
我一直在想：测试用例的目的是 尽量全面的覆盖测试点，减少重复劳动，避免人员流失造成的损失等等。就“覆盖测试点”而言，写一个简要的测试功能列表也是可以实现的，不过要丰富的业务和测试经验（个人觉得）。
这种测试点列表的方法会有很多弊端，但是在一些“违背”软件工程的项目中还是挺管用的~ I think it's important to update the test cases in time during your testing.
Pls see the reasons as below
1 Maybe you can use these update cases in next similar project
2 you can analyse these update cases then find which process you will improve in the future.
3 Test case is the important data base for all the QA 回归测试 如果时间确实特别紧张，没有时间写测试用例，就匆忙的列了测试点去完成测试执行，姑且不谈为什么会这样。呵呵，肯定是有原因的了。但是，测试用例还是要去补上，原因如下：
1、以后的类似项目可以直接用。
2、回归测试的时候会用到。
3、这些进入公司的测试用例库，应该是一些非常重要的，可供后来人学习的资料。 7&9F 谢谢两位的指导。
很头痛的事情呀~
按软件工程上说的，测试用例是根据详细设计来编写的，可是“超快速”开发的项目根本没有合格的概要和详细设计，我们设计用例只能是根据需求来弄，很多时候用例和实际设计出来的东西差别很大。
业务逻辑上的用例基本没什么问题，但是对于按钮，文本框之类的具体的设计内容的测试用例往往对不上，时间长了也就都不写了。
不要说计划的不好，就是没有时间~我们是边开发边测试，要是等开发出一个基本版本再测试时间肯定不够用。
有时我也在怀疑，是不是我的能力太差，总是把“时间不够”当作借口... 我觉得时间不够是问题，但也不是问题～
老实说，永远都时间不够，永远都陷在那些一轮一轮的重复劳动中，就永远都不会提高，永远都会那么疲惫～～
有些痛是长痛不如短痛来滴！！
PS：个人认为还是有补用例的必要，至于那些按钮、文本框内的，应该是尽量促成公司形成统一的规范。象微软，所有的东西，界面、按钮等的风格都是差不多的，测试起来只要按照规范测就好～
呵呵!！
很早之前我做测试时，非常喜欢写测试用例，乐此不疲。现在我做测试时，从不写用例，感觉完全没有必要，还挺浪费时间！
我想做过很多年测试的、有经验的同学 都有这种体会吧！
再谈谈个人体会吧！
用例应该结合实际情况来设计，各个公司的开发流程、产品或项目特点不同，对用例的编写有很大的影响；另外，开发流程的不规范和各种资源的不充分、测试进度的压力，对用例设计也有较大影响，需要采取合适的策略。从整个测试过程的角度来说，设计用例是一个步骤，不是孤立的，编写用例前更需要对需求的充分理解、对测试对象的详细分析，在此基础上，实际上编写用例更多时候可以采用一种简化的用例编写方式，仅描述其所属功能、简要标题或测试点、测试类型、预期结果、需要关注的地方，对于测试目的、具体的操作步骤 就可以简化了。从这种角度来说，更加侧重关注于 测试用例对需求的覆盖、关注各种测试类型都被设计的充分性。 这个是流程的问题，说明你们公司还不是很重视测试。
如果没有用例，而单有功能列表来代替，可能测试的数据的准备是临时的，不全面的。
我随便举个例子。比如一项投资的收费是（L+R+I）*x
x在0~5000是5%
在5000~10000是3%
如果出错L没有计算进去，而你取得数据是1000，4500，1000就不能得出正确的答案。
而且功能列表的一个功能点可能是多方面的，临时想可能不全面。 我是新手，刚进测试行业不到2周，我觉的测试用例是有必要的，个人认为最主要测试用例写好以后是给别人看的最多，如果是一个经验足够丰富的测试者，他个人不会非常在乎测试用例吧（毕竟他全知道了，最多没事看看，回味回味）不过该测试者要保持一直测试软件的状态，如果中间停个几年，他也会想念测试用例的。可是对于一个公司，对于其他测试人员，你的测试用例是相当重要的，这就是经验啊，在一个新人看来，公司有个测试用例库是多么宝贵的财富啊。
谢谢！ 测试用例的必要性不言而喻，随便网上搜索一下，就能看到太多关于它所能带来的好处，但是现实问题也永远都存在的。各人感觉就项目未轻松前，可先缓缓case，先尽可能多的罗列测试点，罗列出相关的测试点后可以考虑召集所有测试人员共同召开一个review会议，毕竟测试最终的目的就是为了确保交出的货物高质量，因此测试时所能考虑到的多方面是很关键的，集百家所长永远比单打独斗要好！其次如果你组织中已经有可以参考的同类项目，可以从组织的经验库中查看下以往项目的测试角度，借鉴下。 我认为如果项目很紧的话，就补充一下测试项，至于具体的操作步骤和操作结果可以省略。
这样也是可以起到跟踪作用，也可以供以后分析用。 如果没有时间写测试用例，那么可以列一个大致的测试要点
回复 #1 hotivy 的帖子
我觉得用例的编写必须详细仔细这样才能提高测试效率，因为有的时候用例是在给别人看，如果你说的不详细看你写的用例时必须还要向你请教是什么意思！这样很耽误我们的测试工作回复 #15 波波天地 的帖子
同意up
页:
[1]
2
