核心理念：

首先需要想清楚一个问题：作为一个测试，有没有把需求当作产品中的一个组成部分，然后尽到一个测试的责任与义务？只有建立这样的意识和规则，才能够把挖掘需求的事情做好，否则始终抱着“需求是产品负责，我不关心”的心态，那接下来的事情就无法进行。

主要目的：

挖掘需求问题，有两大核心目的：

1.        提升产品质量通过挖掘需求中的问题，解决需求中的问题，完善产品需求，从而完善产品，提升产品的质量。

2.       提高项目效率通过挖掘需求中的问题，尽早查漏补缺、解决分歧，避免问题遗留到项目中后期，导致返工、进度delay等风险，从而提高项目的效率。

具体思路：

由于专业度上的差别，测试同学在挖掘产品需求问题时，确实存在一定的困难。但基于以往的经验，还是能够总结出一套思路，具体可以从以下几个角度进行：1.       需求描述层面的问题：    

a)         错别字、病句等

需求文档中难免会存在一些错别字、病句等文案错误，此类问题我们有必要给产品同学指正（但不要带着嘲讽的心态），因为有些时候这种错误一样会对产品、需求理解造成影响，例如：“未进行”和“为进行”，一字之差，谬之千里。又如：“账号”和“帐号”，用字用户提示中，影响产品的专业度问题。    

b)        描述存在歧义

需求描述的含义必须明确，描述存在二义性甚至多义性的问题，比较严重，可能会导致多方理解的不一致，导致开发、测试等团队的产出物不正确，进而返工，增加项目成本。我们需要与产品确认，并要求产品进行更正。例如：分身添加两个动作之间需要间隔字数的需求，需求描述为：4（以默认语速1.0为基准，覆盖4个字符）乘以语速（0.7～1.3）*视频长度取值（四舍五入）。产品和测试前期讨论的方式为：（4个字符*语速）取值四舍五入*视频长度。开发的实现结果为：（4个字符*语速*视频长度）取值四舍五入。结果就导致结果与预期不符。    

c)         需求内容遗漏

此处不等于需求遗漏，而是指需求已经明确，但产品没有写入需求文档的情况。对下游团队，尤其是测试团队，需求文档是极为重要的依据，我们需要检查产品的需求文档是否编写完整，如果存在没有写入的情况，需要要求产品同学补充。例如：经过讨论已经规定该文本框中输入的最大字符数为100，但需求文档中没有更新。

2.        需求覆盖度的问题：    

a)         缺少流程节点

在需求中涉及功能流程的地方，需要重点关注是否缺少某些流程节点，流程中的各个环节是否能够顺利连通。例如：用户没有权限使用某个功能时，应该给出跳转到购买该权益的入口，但需求中没有提供这个入口。    

b)        缺少逻辑分支

在需求中设计判断分支的地方，需要重点关注是否分支路径是否覆盖全面，是否存在分支路径的缺失。例如：提示用户购买高级会员，只规定了进行购买的后续流程，但没有规定用户取消购买的后续流程    

c)         缺少需求定义

在需求中涉及需求定义的地方，需要重点关注定义是否考虑充分，是否存在遗漏。例如：规定了高级会员有什么权益、普通会员有什么权益，但没有规定同时具备高级会员和普通会员的情况。    

d)        缺少用户场景

平时用户使用过程中经常出现的场景，在需求中是否有明确说明。例如：用户播放音频过程中，进行程序的前后台切换操作、手机锁屏状态下该如何处理等等。    

e)         缺少异常处理和容错机制

需要关注需求中，是否针对异常处理有约定的处理方式，用来提升程序的健壮性。例如：视频聊天过程中手机来电、断网，或者进行获取数据时服务器异常等等。

3.       需求预期的问题：    

a)        预期结果不明确

需要关注需求中的内容是否都有明确的预期结果，需要让其提供明确的预期结果。例如：当网络出现异常的时候，弹出错误提示，但没有个出错误提示的具体内容。

4.       需求合理性的问题    

a)        必要性

需要针对需求的必要性进行评估，要把产品的目标和用户的实际情况进行结合，综合考虑需求的必要性。例如：用户对转写结果的准确率要求极高，但本地转写的准确率又极差，那么添加本地转写这个需求的必要性，就需要探讨。    

b)       与目标的一致性

需要关注需求中的内容，能否实现产品的目标。例如：产品需要收集用户是否主动关闭某个功能的数据，但该功能的入口做的非常的深，一般用户发现不了，那么这种需求就很难实现目标。    

d)         连贯性

需要关注需求持续迭代过程中的连贯性，前后的风格或操作习惯尽量保持统一，否则每个版本都在变，增加用户熟悉的成本。例如：之前版本中的页面都支持右滑返回上一页，而新版本中的新增页面，则不支持右滑返回上一页。    

d)       耦合度

需要关注需求中不同功能之间的耦合度，尽量简单处理，保证各功能之间的相对独立性，如果耦合度太高，会导致功能复杂度变高，增加开发和测试的成本，也增加出现bug的几率。例如：文件存在语音转写和文件存储两部分功能，尽量让转写和存储这两部分的功能策略保持独立，不要把转写状态和存储状态增加组合的策略，如未转写状态只能按照条件1的情况存储、转写中状态只能按照条件2的情况存储、已转写状态可以按照条件1和2和3的情况存储。

5. 需求的用户体验问题    

a)         易操作性

需要考虑需求中的功能是否容易操作。包括不限于：

i. 操作行为是否简单（如：单手点击）

ii. 操作路径是否简短（如：一键生效）

iii. 操作入口是否直观（如：开关放在设置首页，而不是三级菜单中）

iv. 是否符合用户习惯（如：继承用户之前的设置风格）

v. 是否符合系统环境的标准规范（如：Windows的支持键盘操作、iOS下确认弹窗中按钮的左右摆放规则）

b)       易理解性

需要考虑需求中对功能或名词的定义是否容易理解，用户能够一看就明白具体是怎么回事。如果不易理解，是否有清晰的解释说明。    

b)         吸引力

需要关注需求中的功能，是否对用户有足够的吸引力。例如：抽奖活动的需求，奖品的价值以及中奖的概率，是否足够诱人。    

c)        交互反馈

需要关注需求中的功能，在用户触发后，是否能够给用户对应的反馈，让用户清楚当前的状态。例如：点击下载，显示loading状态或这下载进度；触碰按钮，按钮状态发生相应的变化。

6. 需求的可行性问题    

a)         开发实现的可行性

对于需求中的某些内容，需要关注开发实现层面的可行性，如果缺乏可行性，就需要提前指出。例如：语音识别准确率需要达到100%，这种在现有技术水平的状态下，根本无法实现。又如：整体功能逻辑与微信的效果对齐，这种在较短的项目周期内，根本无法实现。    

b)        测试的可验证性

对于需求中的某些内容，需要关注测试的可验证性，如果无法操作或者无法验证，就需要提前指出。例如：最大支持上传音频的个数为无上限，这种就明显无法验证。

7.        需求版本管理问题：    

a)        需求版本标记不清晰有时候需求文档中会同时存在多个版本的需求，或者因为工期问题导致同一个需求拆分成多个项目版本进行，这种情况下，就涉及到对需求版本的管理问题，需要关注需求的版本信息是否标记清晰、明确，能否清楚的掌握当前版本需要关注的需求范围。

注意事项：

1. 要勇于提出问题。虽然测试在产品的专业度上有欠缺，但我们也是用户，而且是最早体验产品的用户，因此对需求有疑问，一定要勇于指出。

2. 不能为了提问题而提问题，要加入自己的思考，要带着提这个问题的原因和目的。例如：这个弹窗上放5个按钮不合理，原因：太挤了、或者用户找不到重点。

3. 在挖掘需求问题的时候，需要跳出需求的思维和角度，基于用户的习惯或者测试的视角，去审核需求，否则容易陷入产品的思路，觉得哪都是对的。

4. 提出的需求问题，建议通过邮件的形式公示，产品不接受或者不解决，也可做到备忘；其中测试认为比较严重的问题，可以在后续的进度或者测试报告中，作为项目风险进行公示。

在发掘用户体验性问题的时候，可以借鉴优秀的竞品，通过审视竞品的效果如何，来评估我们的需求处理是否存在问题。