测试用例的必要性？？

hotivy

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

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

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

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

null2

管理问题
计划问题

zgslhyh

测都测完了还补什么用例  接受教训下次在需求和详细设计的阶段就开始准备用例  在程序完成前准备好

huangsh2004

有机会还是补充一下用例比较好一点。至少有几个作用：
1、有时间想想测试究竟做到什么程度了，还有没有未测试到的，是不是测试可以结束了
2、锻炼一下测试思维。

luoyear

我觉得还是必要的
有些你不想列出详细的步骤
起码也要列出主要的测试点。
如：
测试用户注册。
你可以说用字符，数字，字符数字三种组合各测试一次登陆。
并且输入正确密码，错误密码和不输入密码应包含在组合内。
你可以不写步骤，
但最起码你要列出这些组合或描述组合规则。
并且在测试时候勾出你覆盖到的
这样才不至于遗漏测试点

hotivy

感谢大家的回复

1，2F的朋友有可能没有经历过我这样的工作，没有时间让开发人员作那些设计，需求完了之后就直接开发，好在我们测试的人都是业务比较熟练的，全部压到我们这里，累呀。

3F的朋友，我们有时间还是会补的，呵呵，项目一忙完大家都想休息，我不忍心呀，呵呵。

4F的朋友，我现在就是用您说的方法，但是测试点老是不全，也许是我经验不足造成的，我干测试一年，呵呵~

  我一直在想：测试用例的目的是 尽量全面的覆盖测试点，减少重复劳动，避免人员流失造成的损失等等。就“覆盖测试点”而言，写一个简要的测试功能列表也是可以实现的，不过要丰富的业务和测试经验（个人觉得）。
  这种测试点列表的方法会有很多弊端，但是在一些“违背”软件工程的项目中还是挺管用的~

sanjieyu

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

cjycjy11

回归测试

linkalee

如果时间确实特别紧张，没有时间写测试用例，就匆忙的列了测试点去完成测试执行，姑且不谈为什么会这样。呵呵，肯定是有原因的了。但是，测试用例还是要去补上，原因如下：
1、以后的类似项目可以直接用。
2、回归测试的时候会用到。
3、这些进入公司的测试用例库，应该是一些非常重要的，可供后来人学习的资料。

hotivy

7&9F 谢谢两位的指导。

很头痛的事情呀~
  按软件工程上说的，测试用例是根据详细设计来编写的，可是“超快速”开发的项目根本没有合格的概要和详细设计，我们设计用例只能是根据需求来弄，很多时候用例和实际设计出来的东西差别很大。
  业务逻辑上的用例基本没什么问题，但是对于按钮，文本框之类的具体的设计内容的测试用例往往对不上，时间长了也就都不写了。
  不要说计划的不好，就是没有时间~我们是边开发边测试，要是等开发出一个基本版本再测试时间肯定不够用。

  有时我也在怀疑，是不是我的能力太差，总是把“时间不够”当作借口...

Ken_Xue

我觉得时间不够是问题，但也不是问题～

老实说，永远都时间不够，永远都陷在那些一轮一轮的重复劳动中，就永远都不会提高，永远都会那么疲惫～～

有些痛是长痛不如短痛来滴！！

PS：个人认为还是有补用例的必要，至于那些按钮、文本框内的，应该是尽量促成公司形成统一的规范。象微软，所有的东西，界面、按钮等的风格都是差不多的，测试起来只要按照规范测就好～

SpiderMan

很早之前我做测试时，非常喜欢写测试用例，乐此不疲。
现在我做测试时，从不写用例，感觉完全没有必要，还挺浪费时间！


我想做过很多年测试的、有经验的同学 都有这种体会吧！

SpiderMan

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

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

nan3937

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

波波天地

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

irene_sophia

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

调皮精灵

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

lgwmlx

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

jiaerxue

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

jinyangheng

同意  up