新来了一家公司，流程神马的还不是特别的规范，前段时间，部门领导要我给他们做需求的搞个培训，我就给他们讲了一下，同时也引起了我的反思。
我不是专业搞需求出身，从事工作后就一直搞测试，但是与测试打交道的不是开发就是需求，做测试也做了几年，所以有接触的需求中也有做得很好的，但是很好也不是代表着没有问题。 我看到的大多都是写的测试和开发之间的沟通和矛盾的处理，但是我觉得测试与需求之间关系的处理并不比开发之间的要轻微，相反的，还会更重要，需求是一个项目的源头，如果你想要把项目做好，就要从源头开始把控；不是说“好的开始是成功的一半”嘛；
我总结一下自己在项目中遇到的需求问题，及处理的解决方案：
1.需求文档描述不细致，功能点模糊
解决：找到编写需求的责任人，问清自己的模糊点，并要求将期详细描述
2.需求方强烈要求，但技术可实施性不高
解决：对方强烈要求的情况下，无协商余地的，交给自己上面更大的头儿去处理，然后坐等解决方案
3.需求实现与实际的业务不符，有矛盾（这种问题一般发生在新员工）
解决：找需求责任人了解清楚真实的想法及项目背景，解释其业务之间的矛盾，及实施后的缺点
4.需求对自己的需求功能不坚定，或自己也没有考虑好需求就开始了项目
解决：1.发生在提交测试前期，要求需求对自己的功能进行详细的描述和考虑
2.在测试过程中，与需求确认，如果功能完成得比较符合大家一致，那就按实现完成；但一旦存在歧义，互相商议解决不了，还是汇报给你的头儿去跟商业的头协商解决（特别是商业需求）
还有许多的问题没有列举出来,相信大家在测试的过程中也会遇到很多的问题,也有自己独道的见解和想法.我写这篇文章不是为了讨论我们到底遇到了神马样的各种苦逼的问题,而是想说,我们如何才能根治这种问题?
这里提一下我自己的想法,大家都知道,测试介入项目中,是越早介入越好（越早介入了解需求 业务背景的时间就越充足，也可同时把项目中业务自己的盲点扫除）,我觉得最好的还是需求阶段,不是太早也不是太晚。
1.在需求提出来的时候,进行需求评审；可以把技术 测试 商业 架构等人员邀请参与,架构 开发可以从技术的角度来检查项目的可施性,及可能预见的问题;测试和商业方可以站在用户 业务的角度来优化需求的不足之处，共同评估项目的资源及风险点等
2.编写用例阶段，把控用例的颗粒度，细化需求。弄清楚不明确的需求，挖掘需求里面的潜在需求；－－这点是建立在大家对业务的了解和测试经验的基础上，所以手工测试并不是无用之徒
3.在测试执行过程中加深对需求的了解，与实际业务有冲突的情况及时提出。项目就是技术与需求的结合体，所以在测试执行时其实才是了解项目实施的最佳时刻，说白了，之前的一些都是纸上谈兵，现在才是动真格的。
先就列出这么几点吧，昨天没有写完就有事情走了！但是在我的观点里面，一直觉得好的测试人员不是说你代码能力有多么强，不管你代码能力有多好，但是如果你的手工测试及工作中的问题处理不好，你就不是一个好测试人员！所以，我觉得功能测试做得比别人突出、设计用例设计得比别人到位，反而是有优势的，你这些做好了，再往coding方向走，也会走得更远！~
欢迎大家一起讨论，共同学习！
