众所周知，软件测试中需求是软件测试的起源，也是最重要的环节，如果初期各个环节需求理解有问题的话，会出现很严重的BUG，更严重的甚至导致项目的失败。目前情况下经常是由于某种原因测试人员到需求评审的时候才参与进去，由于前期没有任何准备，在评审的时候基本处于听众，找不出需求中的任何问题。有些时候甚至都不清楚为什么要这样做，以及做这个项目的目的。测试人员最好要了解用户的真正需求，因为测试人员需要验证软件的正确性，测试人员不仅把自己作为测试人员，也把自己当做用户去考虑这个需求，挖掘需求。

　　在这里讲个亲身经历的事情，刚刚毕业的时候，进了一家做证券软件的公司，我对此业务一点不通也没有做过相应的培训。开始半个月没给什么重要的事给我做，让我看看证券信息，学习相关业务，要不就给一个小需求做做，当时感觉很纳闷，不知道为什么老让我看这些证券资料，头都大了，抱着这种态度可想而知也没认真学习那些证券知识。有一天老大给了我一个项目，记得当时给了一个月的时间。也没人带领，让我一人做那个项目，拿到需求以后就快速的审阅起需求，也没有太多的跟需求方和其他人沟通就按照自己的思路设计起方案和数据库了。中间也就是问问技术性的问题，一个月后项目是做完了交给老大去验收，老大给了一句话：“恩，该有的功能都有了，你觉得这个软件符合用户的需求吗？用户会去使用吗？“当时给了我当头一棒，我不明白为什么不符合用户需求，我测试了觉得都能用呀。然后老大就跟我讲了怎么怎么不符合用户的胃口需求等等。从用户角度从整个设计上推翻了我的设计方案。那次经验给了我一个很大的教训。

　　造成那次失败的原因有以下几点：

　　首先，在学习业务的态度上就没有下功夫，轻视了行业业务的重要性

　　其次，根本没有从用户的角度思考问题，也没有跟相关的业务专家多请教业务

　　第三，没有进行深入的了解需求，挖掘需求。需求了解不透彻。

　　第四，在设计上没有考虑软件的扩展性，数据库设计上没有考虑数据的冗余量。

　　第五，当然也没有什么经验，只想着把功能完成了就OK了。

　　总之，不管是开发人员还是测试人员，无论在项目还是在日常下建议多花点时间在需求上，如果对于老系统的改造，需要了解老系统，新系统与老系统的兼容，数据的兼容性，大家一起考虑问题总比一个人考虑问题强，我相信团队的力量。对于新系统要多了解了解行业知识，都从用户的角度考虑问题，不要只把自己当做技术人员看待。对于多应用的接口的项目，尽量的去了解其他应用的东西，找出尽可能多的疑问。