请给我一份火星人的需求文档

　　逛测试论坛时，经常会碰到问如何测试一杯水，一张纸等等的帖子，下面的回复络绎不绝，见解更是百花齐放。我很纳闷，这个有多大讨论的价值和意义吗，除了头脑风暴带给的娱乐性。

　　如果你应聘时被淘汰，是仅因为测试经理面试时提出类似的问题，而你回答的很糟，那么恭喜你，幸好没进入一个糊涂的测试团队，起码是个华而不实的测试经理领导的团队。

　　其实回答出色的同学不见得比回答很糟的同学测试水平就高，只不过你更了解决定这个物品好坏的诸多因素；如果要是问你如何测试火星人，你肯定疯了，没概念。所以在出色的回答这个问题前，你首先要清楚回答这个问题的前提——我的需求在哪？

　　没错，之所以你可以回答如何可以测试一杯水，是因为你潜意识里默认了关于”这个项目“的需求；你回答的出色说明你具有成为需求人员的潜力。

　　一个IT项目，最早介入的人员是架构师和需求人员，这应该是经验和能力最高的人来担当的，如果从测试的眼光来看，他们是避免产生bug的第一层人员。抛开架构师（这个主题太大，我扛不住），一个需求人员的所撰写的需求文档应该可以让开发人员，UI设计人员，测试人员分别生成代码，界面，测试用例，然后经过合作生成最终的产品。

　　但是需求人员的价值不容易评估，水平也参差不齐。当一个团队有一个很不称职的需求人员时，这就会导致后面的开发人员，UI设计人员，测试人员来扛起需求人员所应承担的责任。所以当一份需求文档发到你手里的时候，你就应该清楚这个团队的水平了。

　　我在上个公司和现在的公司所接触的需求文档是截然不同的两种概念，前者看其来是个脑袋就可以写，这直接导致我在写测试用例的轻松，但轻松不见得是好事，因为文档中对于项目业务应具备的拓展，对开发技术点的理解没有任何要求，所以你可以很快完成设计测试用例的任务；后者，也就是现在我测试的项目，需求文档是 USE CASE,我需要向开发人员请教存储过程，和项目涉及的.NET相关技术，同时自己逼着自己去了解电子商务，考虑如何提高性能，这倒不是我好学，而是因为人家需求文档有明确规定，在生成测试用例时，我需要了解这些内容。

　　以上好像都是在说一些需求人员的不是，其实我想说的是一个项目对于一个测试人员的锻炼，有的项目完全是你在用积累的经验来工作，那其实是原地踏步；而有的项目是可以不断提示你的经验，从而提示你的竞争力。

　　而这种差别，从需求分析就开始了……

版权声明：原创作品，允许转载，转载时请务必以超链接形式标明文章原始出处 、作者信息和本声明，否则将追究法律责任。

本文出自lghss23的51Testing软件测试博客：http://www.51testing.com/?227608