测试用例的覆盖度高不高，取决于测试同学对业务理解的程度。所以分析客户的需求，是产品经理要做的事，而分析测试需求就是测试工程师要做的事。要把软件需求转化为测试需求。拿到测试需求，首先要弄清楚以下几个问题：

1、这个需求主要做什么事情？

      直接从头到尾看PRd，本身就比较累，如果写的再凌乱点，东拼西凑组装起来需求文档，阅读起来更没有头绪，所以了解一个需求是做什么的，最快的是从业务流程下手，产品也会先讲流程图，让大家有一个概况的认识。如果没有可以让产品补，每个测试根据自己对业务的理解，也应该具备画出流程图的基本能力。通过流程图去发问。流程清析，后期的测试场景覆盖度才会全面。

2、这个需求是给拥有什么样角色的人使用？

      因为所有的产品最终落地肯定是指具体某一个人的，所以权限问题一定要清楚，有效权限用户的交互规则要明确，在后期测试过程中还要考虑数据权限问题，一个是跟角色的权限有关，另外跟城市权限有关。如果一个需求是针对角色定的，一个角色上会涉及若干人，就要考虑并发处理的情况。即一个任务同一到达同一个角色的多个人身上，有先后处理的交互要测，还要测多窗or多个平台or多个人同时并行的情况。这就需要了解些组织架构，因为组织架构是将整个系统功能分担了。业务实现落实在人，人归属于组织架构。设计用例时肯定是要结构角色，菜单权限去设计数据的。

3、在什么样的平台下使用这个些功能？

     现在产品的形式非常多元化，常见的有：WEB版，wap版（很少见了）、M站（html5），APP、微信公众号、小程序、快应用，C/S客户端（互联网会少见，传统行业比较多）等，足以展示了产品平台多元化。但是每个公司的产品中心思想其实是一样的，每个公司的产品诞生后都离不开推广，自然需要通过不同的渠道打入消费者，所以就产生了不同平台领域，渠道多了，在测试需求分析时，务必要弄清楚某个业务功能涉及的平台。而有些产品负责的行业线不同，所以可能在设计需求时，难免会遗漏多种平台之间的关联。这个在测试需求分析时，可以抛出来。

 （在发问这个问题之前，每位同学都应该先去了解一下，我们的业务都对有哪些产品，做不到每个产品的细节，至少要知道每个主品主要是做什么的，什么人使用的。）

4、整个业务流中是否存在逆流程，或是否会受现有的逆流程业务的影响？

      如现有可逆业务：拍场-车辆检测；财务到成交接待，接待到检测邀约，成交邀约到拍场等等。在需求分析阶段，即要明确状态发生变更的条件规则，应该呈现的结果，这些都会是测试设计时的依据。这只是一个公司实例，希望大家可以撑握住分析问题的方法，应用到所有的项目中去。

5、明确每个业务点的人机交互过程及规则是什么？业务过程是否连贯明确？即如何使用这个需求？

      通俗讲要明白什么条件下，什么人可以操作什么样的按扭？或人可以发起什么样的请求？之后系统如何显示？逻辑其实是针对系统的，即针对机的。而人的行为是通过一定规则控制的。人机交互过程一定是有规则，有逻辑判断，这个一定要弄清楚。人输入什么系统输出什么？如果这样还不足以明白这个点，你可以这样理解：满足什么条件可以成功登录？满足什么条件可以展示什么内容？满足什么条件可以操作什么button？操作后又有什么样的交互？满足什么条件可以输出什么内容？这样是正向理解，再去反向挖掘一下不符合正向条件时会是什么样的交互效果？明确以上问题，就差不多了。

      为了便于大家更清楚的去理解人机交互过程，我专门查了一下人机交互界面表标模拟与实现方式。点击查看。也可以自己去百度一下，多了解一些有益无害。

6、要弄清楚每个需求的数据源及数据流转规则是什么？

      这个也是要明确的一点，特别是一个新增的页面功新的产品。一定会涉及到数据问题，没有数据支撑就是一个空壳。毫无意义。符合什么样的数据要求的数据，什么样状态的数据会显示在哪一个页面里，经过什么样的操作，数据会发生流转（经过某个条件或某个操作，数据可能会跑到其它页面），规则一定要问清，后期测试中造数的依据就是从这里来的。

7、是否有需求与其他需求相互冲突或者重复？

    要想提出这个问题，需要测试先去分析需求涉及的模块，需求涉及的规则，与系统现有需求，或者其它进行中的需求进行匹配，看是否有需求冲突或重复的情况。

8、需求文档中是否存在二义性的问题点？

        一个需求二义性场景，需求编写人员心里想做个椭圆的盖子，开发者理解成了圆形，测试者理解成了方形（已开发了方形盖子的测试用例），然后开发者和测试者发生沟通冲突开发被迫返工。有一位叫“北京-牛牛”提出来一个解决二义性问题的方法：【结对需求评审法】这种形式，我个人觉的很好。实践方法如下：

1、 两人只对着一台电脑、由1人作为引导员来操作电脑，记录评审结论

2、 引导员控制时间节奏和维持结对需求评审的规则，两人针对每条需求，逐条进行固定时间窗（1－3分钟）范围内的理解。

3、 2位评审人在单个需求的理解时间到时，直接说出每人对这条需求的理解。如果两人理解一致，就直接看下一条需求；如果理解不一致，不能进行讨论，而是由引导员直接记录下两个人的不同理解内容，这时说明这条需求至少已让2个人产生了二义性的理解，需求存在二义性问题。

怎么去判断需求是不是有二义性，可以参靠以下两点：

一条需求（1－3行文字）如果需要你使劲思考和理解5分钟以上还不能准确说出其描述的本意，那么已说明这是一段容易让人理解出错，容易产生二义性问题的文字描述；    

如果一条需求已至少让两个人产生两种不同观点，那么就可能让更多的人同样产生二义性理解问题；

大家可以去试着消化一下“北京-牛牛”的需求评审方法。也可以去百度一下他的原创，对工作效率还是会有提高的，找合适的阶段，可以引入到我们的工作中来。

做项目一定要拒绝多选题，必须让大家对需求描述的理解能够达成一致，如果你在测试需求评审时，发现某个需求点己经存在了“二义性”，就必须找产品去明确修订PRD。并让开发，测试，产品保持在同一个理解层。这样做出来的产品才会是大家想要的。按各个理解去说，去做，去测，只能频繁的返工。

测试需求分析后，就需要测试同学输出业务流程、用例图、待确认的问题、风险点清单。并就相关问题、风险与产品、开发进行多次沟通，直到问题得到明确答复。以上问题最终敲定，必须是书面落地。

注释：

人机交互：

人机交互的表示分：行为模型，结构模型，模型转换，表现模型。

这里主要介绍下行为模型和结构模型。

行为模型：分析人员获取用户需求后，结合领域专家的意见和指导，获取系统中需要完成的任务，对任务的主要因素进行详细地分析，如任务的层次、发生条件、完成的方法以及它们之间的关系等等。行为是通过目标 (Goal)、操作(Operator)、方法 (Method) 以及选择规则 (Selection rule) 四个元素来描述用户行为。

目标：目标就是用户执行任务最终想要得到的结果。

操作：操作是任务分析到最底层时的行为，是用户为了完成任务所必须执行的基本动作。

方法：方法是描述如何完成目标的过程。一个方法本质上来说是一个内部算法，用来确定

子目标序列及完成目标所需要的操作。

选择规则：选择规则是用户要遵守的判定规则，以确定在特定环境下所使用的方法。当有多个方法可供选择时，GOMS 中并不认为这是一个随机的选择，而是尽量预测可能会使用哪个方法。

结构模型：形式化语言的描述――产生式规则：一般来说，组成界面描述的产生式规则很多，规则定义的顺序并不重要，只要与规则中的条件相匹配，就可以激活相应的动作。产生式规则系统可以是事件引导的，也可以是状态引导的，或者两者都有。）