前无古人~~
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的话说的很有道理，有时候我们很容易犯这种错误！ 我也觉得测试人员在这个时候去考虑测试需求是不是有点过早了？有大家在哪绞尽脑汁的去考虑这些问题，还不如花这些时间放在其他工作或学习上。因为很有可能你考虑得方向跟最终的软件需求完全背道而驰。我就不喜欢做这种毫无目的的揣测工作。哈哈 楼上说的是，我个人认为最好先写一下测试计划比较实在。必竟案例还是不能靠想象，要靠实际上的需求文档才能得到更准确的测试方法。
别急
需求都还没开始,测试人员去干什么?一起去搞搞需求分析,熟悉熟悉还可以吧. 榨汁机的电压也应该考虑到吧还有直流与交流的问题
但是很多时候需求就是含混不清的，特别是项目工期短时。
但是很多时候需求就是含混不清的，特别是项目工期短时。所有人都说没有文档。需求在他们各自的脑袋中？？？ 谢谢。学到不少 楼上各位都是高手，今天学到很多我个人认为，多做这些揣测是有必要的 至少要有一定的需求吧，否则根据自己的臆断来写测试用例，不是完全走入歧途了！
