测试用例应该在什么时候开始写

msnshow

大家来讨论一下测试用例应该在什么时段开始写,

为了提高测试质量和效率,我们公司也要求我们在测试之前写测试用例了,由于要测试的是WEB应用,并且测试人员加入只是在开发快完成的时候,由开发负责人对系统进行讲解,然后我们就开始根据需求文档来写测试用例

不知道在这样的情况下能不能写好测试用例,大家在写测试用例都是在什么时段开始写的

michael82730

开发快完成时再进行需求讲解和用例设计，那给了多少时间让你们设计用例？还是觉得再早一点开始设计用例好一些，这样就有充足的时间了解需求和程序设计，避免由于时间紧而影响用例的质量，这样测试的效果也不好。

423799223

应该是根据需求编写测试用例
只是现在一般软件公司的需求很难及时更新  因为客户有变更  在需求中经常没有体现出来
只是在程序中体现出来  我们公司以前就是根据需求编写用例  导致写的用例完全失效  比如程序界面改得太多\功能变化
最后是在每开发完一个单独子功能时就进行用例的编写  这样以后即使修改也十分容易

adong1982

我觉得谈了这么久的测试用例设计,很多人都认为测试该提前介入.
我也从操作性上谈谈我的个人看法.
首先由于各公司的差别,需求的规范性差异,不可能要求大家做到一样的细致.
我认为,在需求阶段,应更多的和开发人员沟通,熟悉项目. 更多的该关心需求上不明确的问题和操作软件时,逻辑流程上的问题.
因为需求不明确的或没有说的，开发是不会做的。 开发会说多做是额外的满足,同样也是BUG.
无论开发是出于节省劳力,还是从软件质量角度出发,都无可厚非.
测试需要做的是把一个个不明确的,找项目人员开会,大家一致通过,并落实在文本或邮件上,这样就可以大大避免后期测试和开发的冲突了.因此一次做好比推倒重来,开发更乐与接受.因为什么都才开始做,变更容易.发现大的问题也可以重新评估风险.如果在软件开发到后期,才发现大的问题,任何人都会把无名火撒在测试上.并加上一句:"为什么没有早发现"
我觉得这才是我们测试的失败.  
我认为,做测试,就要脸皮厚,要不耻下问,
允许你不懂就问,但不允许你不懂装懂.
测试不能以发BUG刁难开发做为一种快乐.你的成功不代表项目的成功.
需要站在项目的高度,优先发现需求中的缺陷,帮助开发,一起把项目做好.如果把大的问题避免了,测试在以后的测试中,会轻松很多.

此外,提一个我自己的心得,需求阶段,不要过多关注UI上某一个局部, 如果有报警提示,在设计用例时,只需先期望,有一个提示,文字上不应过多约束.在版本稳定后，再关注细节.
要抓大放小.

[ 本帖最后由 adong1982 于 2008-1-21 10:57 编辑 ]

423799223

测试用例如果不过多的关注UI
如何执行
难道写的含糊不清?  如何保证A写的用例B能够执行
用例一定要写的切实可行且要执行  否则纯是摆设应付验收

423799223

我们目前的做法是一个项目中分成如八个大功能模块
然后两到三个测试人员进行一人负责几个  至于写到什么程度呢?
我们是写到一个功能点为止  什么是功能点?  比如一个导出\一个添加\一个修改算一个功能点
然后测试交换对方的用例互相测试  根据功能点的多少评估工作量(当然这一点需要历史数据积累,且存在着诸多不稳定因素,如开发的程序不同\业务逻辑复杂程序、开发人员水平等)

asai-oyh

好像跑题了。。。

项目小组所有人员应该都同步参与最初的需求讨论，此时，能同时了解小组内各角色人员对需求的理解程度

在需求的讨论基本确定下来后，测试是与开发同步开工。。。

测试人员应该尽量早的介入项目，在开发快完成时，才开始编写测试用例，是不是时间太紧了点？而且，测试人员需要对需求的消化时间啊。。。

过程还在改进中哇。。。用例的及时更新和维护也需要时间。

423799223

在需求阶段参与
和在需求完成后写用例是两回事