产品分为两种: 一是由客户向公司提出需求，二是公司内部自主研发。不管是哪种产品形式，都要将需求从脑中、嘴中比较虚无缥缈的思路、语言转化为看得见，摸得着的纸面上的存在。产品、开发、测试都要依照纸面上的存在进行，才能保证工作的正确性及全面性，这个存在就是需求说明书。测试通常从以下方面开展需求分析。

1. 模块功能和逻辑规则分析

系统由多个模块组成，模块由多个功能组成，功能由多个字段和按钮组成。在进行需求分析的过程中，需要根据需求说明书中一个字段、一个功能、一个模块的逻辑规则说明，判断出测试过程中可能会发生的情况。判断的有效情况越多，测试覆盖率也就越大，系统测试完毕后可能隐藏的问题也就越少。

2. 模块关联分析

模块之间的关联主要体现在数据的交互，A模块中的数据会在后续的B模块中进行使用，这时我们就要仔细分析测试情况。若A模块的数据进行了修改、删除、状态的变化等操作，B模块会对应产生什么影响，具体影响如下所示。

（1）修改。通常修改造成的影响最小，A模块的数据进行了部分字段的修改，B模块中的数据也要进行对应修改。

（2）删除。删除可能会对B模块造成一定影响，如A模块是政治面貌管理，B模块为人员信息管理，B模块中存在已创建的人员数据：张三，政治面貌为汉族。此时，若在A模块中将汉族的这一条政治面貌数据删除，通常会有下面几种情况：

v 提示已有数据使用此政治面貌，不许删除；

v 允许删除，成功删除，B模块中张三的政治面貌项留存快照，依然显示汉族；

v 允许删除，成功删除，B模块中张三的政治面貌变为空。

（3）状态变化。状态变化在模块关联中隐藏的很深，通常也是测试工程师遗漏的测试点。如资产管理系统中存在资产报废和资产借还两个模块，资产报废可以将正常状态的资产变为已报废状态的资产，不可再次报废。资产借还可以将正常状态的资产变为已借出状态的资产，归还后才可再次借出。这些都是状态变化对自身模块的影响。那么在模块关联中，就要考虑两个模块中间的关联，情况如下：

v 已报废的资产是否可以借出；

v 已借出的资产是否可以报废；

v 已归还的资产是否可以报废。

3. 数据状态分析

单独的字段比较容易判断测试的情况，但是当字段组成了数据，数据就可能会存在状态之分。比如在日常生活中常见的外卖软件，收货地址可以存在多条数据，但并不是所有数据都是有效数据，如果超出配送范围，那么收货地址就会变为不可选取的状态。最常见的数据状态为可用/不可用，当然还有其他种类的数据状态，要根据数据依附的功能实际判断。当数据的状态发生变化时，通常会跟随着一点的规则限制；如报废登记，将正常状态的资产变为已报废状态的资产，那么已报废的资产是否可以再次报废。同理，已借出的资产是否可以再次借出。这些数据状态的变化以及对应的限制，需求说明书中通常都会说明清楚，若未说明，需根据测试工程师的经验进行质疑，反馈给产品经理进行确认。

1. 权限差别分析

权限管理一般指根据系统设置的安全规则或者安全策略，用户可以访问而且只能访问自己被授权的资源，从控制力度来看，可以将权限管理分为功能级权限管理、数据级权限管理两大类。

系统中通常会有角色之分，也就是权限的差别。如张三是总经理，李四是部门经理，两个人的职责不同、权利不同，在同一个系统中所拥有的角色可能会有差别：

v 张三属于总经理角色，李四属于部门经理角色；

v 张三可以访问A、B、C、D模块，李四可以访问C、D、E模块（功能级权限管理）；

v 在两人可以共用访问的C、D模块中，张三可以查看全公司的数据，李四只能查看自己部门的数据（数据级权限管理）；