测试用例应该在什么时候开始写
大家来讨论一下测试用例应该在什么时段开始写,为了提高测试质量和效率,我们公司也要求我们在测试之前写测试用例了,由于要测试的是WEB应用,并且测试人员加入只是在开发快完成的时候,由开发负责人对系统进行讲解,然后我们就开始根据需求文档来写测试用例
不知道在这样的情况下能不能写好测试用例,大家在写测试用例都是在什么时段开始写的 开发快完成时再进行需求讲解和用例设计，那给了多少时间让你们设计用例？还是觉得再早一点开始设计用例好一些，这样就有充足的时间了解需求和程序设计，避免由于时间紧而影响用例的质量，这样测试的效果也不好。 应该是根据需求编写测试用例
只是现在一般软件公司的需求很难及时更新因为客户有变更在需求中经常没有体现出来
只是在程序中体现出来我们公司以前就是根据需求编写用例导致写的用例完全失效比如程序界面改得太多\功能变化
最后是在每开发完一个单独子功能时就进行用例的编写这样以后即使修改也十分容易 我觉得谈了这么久的测试用例设计,很多人都认为测试该提前介入.
我也从操作性上谈谈我的个人看法.
首先由于各公司的差别,需求的规范性差异,不可能要求大家做到一样的细致.
我认为,在需求阶段,应更多的和开发人员沟通,熟悉项目. 更多的该关心需求上不明确的问题和操作软件时,逻辑流程上的问题.
因为需求不明确的或没有说的，开发是不会做的。 开发会说多做是额外的满足,同样也是BUG.
无论开发是出于节省劳力,还是从软件质量角度出发,都无可厚非.
测试需要做的是把一个个不明确的,找项目人员开会,大家一致通过,并落实在文本或邮件上,这样就可以大大避免后期测试和开发的冲突了.因此一次做好比推倒重来,开发更乐与接受.因为什么都才开始做,变更容易.发现大的问题也可以重新评估风险.如果在软件开发到后期,才发现大的问题,任何人都会把无名火撒在测试上.并加上一句:"为什么没有早发现"
我觉得这才是我们测试的失败.
我认为,做测试,就要脸皮厚,要不耻下问,
允许你不懂就问,但不允许你不懂装懂.
测试不能以发BUG刁难开发做为一种快乐.你的成功不代表项目的成功.
需要站在项目的高度,优先发现需求中的缺陷,帮助开发,一起把项目做好.如果把大的问题避免了,测试在以后的测试中,会轻松很多.
此外,提一个我自己的心得,需求阶段,不要过多关注UI上某一个局部, 如果有报警提示,在设计用例时,只需先期望,有一个提示,文字上不应过多约束.在版本稳定后，再关注细节.
要抓大放小.
[ 本帖最后由 adong1982 于 2008-1-21 10:57 编辑 ] 测试用例如果不过多的关注UI
如何执行
难道写的含糊不清?如何保证A写的用例B能够执行
用例一定要写的切实可行且要执行否则纯是摆设应付验收 我们目前的做法是一个项目中分成如八个大功能模块
然后两到三个测试人员进行一人负责几个至于写到什么程度呢?
我们是写到一个功能点为止什么是功能点?比如一个导出\一个添加\一个修改算一个功能点
然后测试交换对方的用例互相测试根据功能点的多少评估工作量(当然这一点需要历史数据积累,且存在着诸多不稳定因素,如开发的程序不同\业务逻辑复杂程序、开发人员水平等) 好像跑题了。。。
项目小组所有人员应该都同步参与最初的需求讨论，此时，能同时了解小组内各角色人员对需求的理解程度
在需求的讨论基本确定下来后，测试是与开发同步开工。。。
测试人员应该尽量早的介入项目，在开发快完成时，才开始编写测试用例，是不是时间太紧了点？而且，测试人员需要对需求的消化时间啊。。。
过程还在改进中哇。。。用例的及时更新和维护也需要时间。 在需求阶段参与
和在需求完成后写用例是两回事
页:
[1]
