测试用例的必要性？？

hotivy

众所周知，测试用例是软件测试流程中必不可少的内容之一，但是小弟最近的项目非常紧，几个项目交叉没有时间完成用例，项目都是交叉测试的，很累，很累。回头让下面的人补用例真的很残忍（大家都很辛苦，谁都想休息休息）~

我想“测试用例”是不是真的需要？

我现在用测试功能列表来代替测试用例，效果不是很好~

不知道大家实际工作中有没有好方法

hotivy

好多年前的帖子啦，自己回头看看也很有意思哈。

5楼的大牛，我一直没回复你的话，现在看看你说的方法很实际。当时太幼稚啊。

测试用例目前的看法：具体问题具体分析，写与不写，详细程度。都是要综合考虑公司，人员，项目的情况。

15楼当年的小弟，不知道你现在咋样了，对于新人，测试用例库真的很重要，我也曾经换过新单位，感触颇深。

wollon

It's up to your project situations

不开窍的大饼

对我们这些新手 还是该踏踏实实把需求分析仔细 所用的方法规划好 脑袋清楚一些 把用例写得周详；包括预置条件 输入 各步骤

老手们有能力在大脑里建网了吧；想想只要记下重点 大脑里的网络灯相应就亮起来。。好羡慕

cjycjy11 提到 回归测试；也是

vigo

用例是在设计阶段设计的，测试完了再补好像没有什么必要，但是考虑到重用，还是有必要补的，至少你知道哪些地方测过了。还有及时是在开始写了用例的，在测试过程中可能还要对用例作补充，反正用例是必须的，就象开发人员的软件一样。

zzc1

测试用例是说起来简单，但是要花相当大的力气也不一定做的号

厍仕杰

请把问题说具体详细一些。你说的“对table相关的控件支持很不好，取不到表里的值”具体是什么意思？ 把相应的代码和图片放上来。另外，请在论坛上搜索一下delphi方面的帖子，说不定这个问题别人已经解决了。

厍仕杰

请把问题说具体详细一些。你说的“对table相关的控件支持很不好，取不到表里的值”具体是什么意思？ 把相应的代码和图片放上来。另外，请在论坛上搜索一下delphi方面的帖子，说不定这个问题别人已经解决了。

厍仕杰

请把问题说具体详细一些。你说的“对table相关的控件支持很不好，取不到表里的值”具体是什么意思？ 把相应的代码和图片放上来。另外，请在论坛上搜索一下delphi方面的帖子，说不定这个问题别人已经解决了。

yxffiveo

我觉得写测试用例的话，能对很多进行全面的覆盖，不然头脑中的思路就比较乱。

easyinfor

用例是必须的吧

meiliqingdao

测试用例当然有必要了，如果没有测试用例只能是测到哪里算哪里。如果没有测试用例，就很难回归测试。回归测试就需要重新再从头来一遍，没有文档化的管理，公司是不会规范的。

jinyangheng

同意  up

jiaerxue

我觉得用例的编写必须详细仔细这样才能提高测试效率，因为有的时候用例是在给别人看，如果你说的不详细看你写的用例时必须还要向你请教是什么意思！这样很耽误我们的测试工作

lgwmlx

如果没有时间写测试用例，那么可以列一个大致的测试要点

调皮精灵

我认为如果项目很紧的话，就补充一下测试项，至于具体的操作步骤和操作结果可以省略。
这样也是可以起到跟踪作用，也可以供以后分析用。

irene_sophia

测试用例的必要性不言而喻，随便网上搜索一下，就能看到太多关于它所能带来的好处，但是现实问题也永远都存在的。各人感觉就项目未轻松前，可先缓缓case，先尽可能多的罗列测试点，罗列出相关的测试点后可以考虑召集所有测试人员共同召开一个review会议，毕竟测试最终的目的就是为了确保交出的货物高质量，因此测试时所能考虑到的多方面是很关键的，集百家所长永远比单打独斗要好！其次如果你组织中已经有可以参考的同类项目，可以从组织的经验库中查看下以往项目的测试角度，借鉴下。

波波天地

我是新手，刚进测试行业不到2周，我觉的测试用例是有必要的，个人认为最主要测试用例写好以后是给别人看的最多，如果是一个经验足够丰富的测试者，他个人不会非常在乎测试用例吧（毕竟他全知道了，最多没事看看，回味回味）不过该测试者要保持一直测试软件的状态，如果中间停个几年，他也会想念测试用例的。可是对于一个公司，对于其他测试人员，你的测试用例是相当重要的，这就是经验啊，在一个新人看来，公司有个测试用例库是多么宝贵的财富啊。
谢谢！

nan3937

这个是流程的问题，说明你们公司还不是很重视测试。
如果没有用例，而单有功能列表来代替，可能测试的数据的准备是临时的，不全面的。
我随便举个例子。比如一项投资的收费是（L+R+I）*x
x在0~5000是5%
在5000~10000是3%
如果出错L没有计算进去，而你取得数据是1000，4500，1000就不能得出正确的答案。
而且功能列表的一个功能点可能是多方面的，临时想可能不全面。

SpiderMan

用例应该结合实际情况来设计，各个公司的开发流程、产品或项目特点不同，对用例的编写有很大的影响；另外，开发流程的不规范和各种资源的不充分、测试进度的压力，对用例设计也有较大影响，需要采取合适的策略。

从整个测试过程的角度来说，设计用例是一个步骤，不是孤立的，编写用例前更需要对需求的充分理解、对测试对象的详细分析，在此基础上，实际上编写用例更多时候可以采用一种简化的用例编写方式，仅描述其所属功能、简要标题或测试点、测试类型、预期结果、需要关注的地方，对于测试目的、具体的操作步骤 就可以简化了。从这种角度来说，更加侧重关注于 测试用例对需求的覆盖、关注各种测试类型都被设计的充分性。