测试人员如何做好需求分析

需求评审的产品研发过程中的重要一环，而测试人员也是需求评审中的重要参与人员，但在实际工作中，往往会发现测试人员虽然参与了需求评审，但反馈的需求意见缺很少，甚至没有。导致在用例设计和用例编写的时候经常发现自己对需求实现还不了解，还要反过来重新了解需求，更有甚者，就直接根据自己的理解去设计用例，往往用例质量不高，在实际版本测试中发现很多用例的预期结果都与版本实现不符。更严重的是，如果需求文档本身就写的质量就不高，或者敏捷研发流程中的简单的一句话需求，那测试用例的设计更是残缺不全，导致用例质量一般，很多场景未覆盖到，最终现网发现版本缺陷，造成漏测并被客户投诉的严重后果，所以做好需求评审和对需求的充分理解，是把测试用例设计好的重要前提，马虎不得。那如何才能进行需求分析呢？结合我自己多年的工作经验，谈谈我的体会。

一、结合测试种类进行需求分析
所谓结合测试种类，就是软件测试工作一般包含哪些测试。无外乎是功能测试、系统测试、接口测试、性能测试、安全测试、可靠性测试、兼容性测试、UI测试、文档测试以及最近兴起的用户体验性测试等这些内容。在分析需求的时候无论这些测试种类是否都适合当前的被测系统，但都要从这些角度去分析，保证你对被测系统的需求做到全面的分析覆盖，不遗漏。往往从不同的测试角度会发现不同的需求问题。
二、充分了解需求来源及背景
一些测试人员在评审需求的时候，经常会仅根据提供的需求文档来评审需求，我认为这样的方式是为了需求评审而评审。测试人员经常被人说要站在客户的角度去测试，但如何站在用户的角度？首先的关键问题就是要了解一个产品的一个功能或一个需求他的来源是什么，他要解决客户什么问题？这里很重要的就是“客户”。如果需求不清楚，就一句话需求，一定要和需求提出发进行沟通，如果直接能和客户沟通是最好的，否则要和公司内部第一了解或反馈这个需求的人进行深入沟通。要了解需求的出处、来源，要解决什么问题，达到什么效果；并同时了解这个需求以外的情况，例如客户为何要提这个需求，之前的功能无法满足吗？不能满足的原因是什么？客户的使用场景是什么，客户的业务量是怎样的？可以一般用这个功能的时间点是相对集中在什么时候等等。总之，了解的越详细越好，这就发现一些隐藏需求。
三、要了解实现的业务架构
对业务实现架构的了解，往往是测试人员容易忽略的地方，如果说充分了解需求的来源和背景是从业务场景层面的了解，那业务架构的实现就是开发是如何把用户的业务需求转化为产品功能需求的。我们都知道一些网上的段子，客户明明想要的是一栋豪华别墅，但最后的开发结果却是个破房子。所以一定要和开发了解清楚需求的业务架构，就是如何这些这个需求的，要从前端-中台-后端的层级结果逐层了解，最终要能画出一个端到端的业务流程，才知道这个业务的实现都需要依赖哪些组间，哪些相关功能，每个模块都要处理什么问题，只有这样才能真正了解需求并发现需求中的问题，也可以更加全面的设计测试用例
四、需求分析和竞品进行对标
目前很多产品都存在很大的类似的竞品产品，尤其互联网产品或公有云产品，都有很多的竞品产品，可以通过和竞品进行对标分析，发现我们的优缺点，并针对缺点提出我们的需求问题，从而进一步完善和丰富需求。

最后，提供大家一个需求分析的套路方法，就是把自己当成一个什么都不懂的小孩，不要怕被嘲笑，就是多问为什么，在高大上说就是用六和分析法（5W1H)。
Who：谁要这个功能？
When：何时用到这个功能？
Where：在哪里使用这个功能？
What：这个功能是用来做什么？
Why：为何要用到这个功能？
How：如何实现这个功能？
以上可以循环问，能循环问的次数越多，你对需求分析的越透彻，大家不妨在实际需求分析中尝试循环问问。