引用:

Originally posted by ting_yt2 at 2004-7-8 04:13 PM:
我来试试

功能：
1.对去核的正常蔬果进行加工
2.对未去核的正常蔬果进行加工
3.蔬果汁的质量
4.对异常物品（坚硬食物）的加工

性能：
1.榨汁的速度
2.持续工作的时间
3.刀片的折旧速度
4.使用寿命
...

这个答复好啊，从不同的测试种类去考虑，估计就是这道题目的本意。

既然楼上的兄弟们说了这么多
我说点不"沾边"的:
纯粹是以用户为出发点:
1.功能\性能如此出色的机器,到底投入市场一台卖多少钱?(立项)
2.我们投入如此规模的研发队伍,市场需求量多大,前景如何?(立项)
3.这么好的榨汁机,体积到底多大呀?
4.榨汁机外观如何?

需求没整理出来就是说不知道要做什么, 不知道要做什么怎么知道测什么?

比如说这是一个一次性手工榨汁机, 人工操作,一次就扔.不要美观,不要安全. 大家列出的很多想法就都白费了.

大家之所以说出那么多想法, 原因在于心里先有了一个榨汁机的模型,比如qatest说的
"从榨汁机的额定功率/刀片的旋转速度考虑测试用例",那就是说已经认定了榨汁机是电动的.

说到是微软的面试题,我到想起来了,上次参加软件测试大会, 有个专家在微软工作过多年,名字叫陈宏刚,他介绍微软的测试管理经验时提到了面试测试人员的技巧, 其中描述了什么样的人不是tester的有这样一条:

Signs they aren't tester
   - Don't ask questions
          *Sometims,leaving things ambiguous is a good idea
   ......

就是说面试的时候故意设计一些含混不清问题, 如果被面试的人毫无疑义, 那么sign,
they aren't tester. 当然这只是其中一条, 并非唯一标准. 也许大家讨论的面试题是要考察别的能力的.

1）空转是什么效果？
2）用户安全，会不会对用户造成伤害

需求没有出来，有必要写测试用例吗？

同问。没有需求有必要吗？

引用:

Originally posted by bitter at 2004-11-12 03:50 PM:
需求没整理出来就是说不知道要做什么, 不知道要做什么怎么知道测什么?

比如说这是一个一次性手工榨汁机, 人工操作,一次就扔.不要美观,不要安全. 大家列出的很多想法就都白费了.

大家之所以说出那么多想法 ...

偶蛮赞同这位朋友的看法的，有些事情是应该有个先后顺序的，一般来说，测试的需求分析是建立在产品的功能说明基础上。没必要什么事都抢先一步，否则你的努力也许只是白费（有这时间，我宁可去干点其他事情）

http://www.devmanclub.com/ShowPost.aspx?PostID=8233

如这位微软人士所言,这题据说考察的是'test sence', 希望面试者至少说个十分钟.
看来我必须改正观点了.

不管如何还是强

都是强人啊！

引用:

Originally posted by bitter at 2004-11-12 03:50 PM:
需求没整理出来就是说不知道要做什么, 不知道要做什么怎么知道测什么?

比如说这是一个一次性手工榨汁机, 人工操作,一次就扔.不要美观,不要安全. 大家列出的很多想法就都白费了.

大家之所以说出那么多想法 ...

虽然这道题目的是要考察'test sence'，但我认为上面bitter的话说的很有道理，有时候我们很容易犯这种错误！

我也觉得测试人员在这个时候去考虑测试需求是不是有点过早了？有大家在哪绞尽脑汁的去考虑这些问题，还不如花这些时间放在其他工作或学习上。因为很有可能你考虑得方向跟最终的软件需求完全背道而驰。我就不喜欢做这种毫无目的的揣测工作。哈哈

楼上说的是，我个人认为最好先写一下测试计划比较实在。必竟案例还是不能靠想象，要靠实际上的需求文档才能得到更准确的测试方法。

需求都还没开始,测试人员去干什么?一起去搞搞需求分析,熟悉熟悉还可以吧.

榨汁机的电压也应该考虑到吧

还有直流与交流的问题

但是很多时候需求就是含混不清的，特别是项目工期短时。所有人都说没有文档。需求在他们各自的脑袋中？？？

谢谢。学到不少

楼上各位都是高手，今天学到很多
我个人认为，多做这些揣测是有必要的

至少要有一定的需求吧，否则根据自己的臆断来写测试用例，不是完全走入歧途了！