测试需求分析 - 51Testing软件测试论坛

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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