前言

作为一名测试开发工程师，与我们密切相关的不止是开发的代码，还有功能依赖的需求文档。一份好的需求文档，不止能够加速开发和测试的脚步，还能够提前发现风险，是产品的第一道风险保障。

当然，工作中难免会遇到并不“完美”的需求文档，比如牵一发而动全身不清楚的交互逻辑，子条目频繁的变更，交流缺失导致的歧义，都会让测试在项目推进中手足无措。这篇文章一起讨论下，当我们阅读需求文档时，我们都需要了解什么。

从宏观的角度看需求文档

在阅读需求文档之前，我们要对项目或者功能本身有一个宏观的认识，当前项目追求的是什么，是与时俱进快速迭代的更新速度，还是稳中求胜的代码质量，还是耳目一新的智能化设计，明确这些有助于我们在测试中有明确的重心。站在宏观的角度看需求文档，主要是明确需求的合理性和优先级，是针对需求整体作用进行的评审，如果整体的方向错误，那么细节上也没有再讨论的意义了。

在合理性的意义上，通读需求文档，从客观的角度出发，应有一整套合理、公正、客观、完善的需求文档的评价体系去保证需求质量。更多的时候我们也要换位思考，站在用户的角度，去评价需求文档解决的痛点是什么，是否符合用户需求；解决的这个需求会不会只考虑到小范围的用户，从而影响到大众关注的逻辑，更应站在开发的角度去评估，在效率、效果上是否可行，在技术上实现是不是会有阻碍。如果这个需求的涉及到的资源紧张，那么这个需求和其他需求的优先级又该怎么取舍，都是应该在需求评审时，首先应该考虑到的。

从细节的角度看需求文档

站在完整性的角度看需求文档，实际上是将当前的负责的项目模块化（或者抽象化），根据功能的需求确定功能的影响范围，再细化，同时对比需求文档，这样对目标的操作有个明确的预期结果。

1）结构化项目流程

以内核为例，无论是功能类的需求、质量类的需求还是解决用户反馈的需求，都可以把这些需求抽象成为操作（增、删、改）、查询两个大模式。要么是纯查询类需求（即刻俊译），要么就是两者结合操作类+查询类（灵犀）。在这里有些看起来是纯操作类的需求（删词），但是实际上要通过查询的方式才能生效在这里就不单独作为一个模式赘述。

2）确认影响模块

比如一个纯查询类的功能需求，我们通过以上的图就可以知道，整个过程影响我们的因素有：

I. 用户输入

例如：

1）类型（中文、汉字、英文、数字、不支持编码、表情、符号）

2）长度（最短、最长）

3）异常输入

II. 查询条件

例如：

1）完全匹配查询、部分匹配查询（简拼、暴力）

2）需求中定义的查询规则（匹配规则、优先级逻辑）

III. 查询内容

这里的查询内容指的是被查询内容的特性，存在/不存在，同步/异步，正常/异常，或某些需求文档中指明的情况

IV.效果展示

例如 :

1）展示位置

2）排序优先级

3）展示个数

4）标记情况等

3）考量综合因素

这里的外界影响因素，指的是其他外界因素，有可能改变这四个过程中的某些因素，比如开启繁体下会改变用户输入，比如当用户关闭用户词会使用户词查询内容失效，再比如某些固排的词会影响效果展示。

还有一些效果性的需求，比如提高查询效率，我们知道这个功能只需要改动查询条件就可以，但是在需求文档中也应明确是否有用户输入和查询内容的约束。当然这些综合考量离不开测试人员项目知识的掌握程度、在这里建议（类比相似功能、总结记录（bug、特殊）以及用例评审去提升综合因素的覆盖度）。

将以上因素排列组合和归纳，再对比需求文档，我们就可以知道某种特定的输入下，有哪些预期结果，那这些预期结果到底好不好，这就涉及到需求细节的合理性、明确性以及优先级。

合理性的验证也需要从用户行为和开发行为两个角度去进行分析，细节是否合理到位。比如之前出现过得需求中，上屏标点后，再输入上屏不会自动补空格。我们找了一篇英文文章去输入体验，发现每次上屏标点后，都需要手动输入一个空格，再输入其他词条，这样的体验肯定不是用户想要的，因此会针对这种现象提出需求建议，再比如某些效果需求的时候，罚分与其他功能冲突，都是我们期待在需求分析阶段发现的。

明确性是需求阅读中的痛点，因为阅读的时候人都是主观的，所以很难有这个明确性的意识。经常出现问题的地方是歧义和没有约束。在这里我对歧义的建议是多次阅读，特别是那些觉得非常拗口的地方，往往都是问题频发的根源。约束的问题往往依赖个人经验，比如键盘类型的约束以及异常校验的约束等。

优先级某些需求项与已有功能有“冲突”，针对这些需求项，是否明确了优先级，并评估优先级的合理性。

需要注意的是，合理性、明确性以及优先级的相关的影响因素是在完善性的考量中确定的，所以结构化项目流程，明确影响因素范围尤其重要。