关于需求阅读的思路

平时工作过程中，少不了要阅读需求，今天跟大家聊一聊关于阅读需求这块，个人的一点心得体会。

阅读需求共分四部：

粗读需求→精读需求→挖掘问题→提出建议，并且这是一个循序渐进的过程。

目的：

粗读需求：了解产品目标、掌握需求内容、评估工作量。

精读需求：提升需求了解程度、设计测试用例

挖掘问题：提高需求完整度、提升产品质量

提出建议：提升产品体验、提高项目效率

本次主要介绍一下：粗读需求和精读需求

粗读需求：

对于敏捷开发而言，当前版本测试过程中启动下一版本，基本上属于标准操作。因此在介入下一版本需求时，对测试同学而言，存在多版本并行的压力。此时可以采取“粗读需求”的方式，缓解压力，同时完成下一版本的前期准备工作。

粗读需求，主要达到以下几个目标：

1. 了解产品的目的：了解产品的目的，明确要达到一个怎样的目标，始终以该目标为核心，为后续阅读需求打好基础、做好铺垫。
2. 掌握需求的内容：了解需求大致包含哪些内容，清楚需要做哪些事情，作为后续评估工作量、产出工期的依据。
3. 评估工作量：对项目而言，介入下一版本需求时，最重要的任务，就是产出工期。通过粗读需求，可以大致评估出工作量。

具体思路：

1. 通读需求，了解目的和目标。如果需求文档中没有，可与产品沟通。
2. 建立需求与功能划分的对应关系，以功能为依据评估工作量。可参考需求文档（或交互文档）中对功能的划分。
3. 针对需求（功能）进行逐一拆分，由大到小、化整为零，提高工作量评估结果的精度。
4. 以功能点（如数据存储、音频播放）、页面元素（如文本框）等为基准，提取测试对象，暂不深究具体细节，然后根据以往经验，评估测试对象的工作量。如果某个功能点涉及需求细节量级较大，需要特别关注，因为可能会对工作量有较大影响。
5. 明确功能变化与已有功能之前的关联关系，准确把握测试范围。可通过模块间相互关系列表，作为参考依据。

精读需求：

完全介入新版的项目任务之后，测试同学就可以全面、完整的跟进需求，并且接下来的用例设计工作，也是对需求理解有更高的要求，此时就进入“精读需求”的阶段。

精读需求，主要达到以下几个目标：

1. 掌握需求细节：详尽掌握所有的需求细节，为用例设计做准备。
2. 挖掘需求问题：提前暴露需求问题，减少后续的需变，提高产品的质量和项目的效率。
3. 明确产品预期：明确各种场景下的产品预期，保证开发产出物的合理性，以及与测试理解的一致性，从而形成测试依据。
4. 设计测试用例：针对需求，我们最终的阶段产出物，一定是测试用例。

具体思路：

1. 确认需求的准确性。开始精读需求前，先要确认需求是否已经更新到最新，拿到的需求是否与产品和开发手里的一致。不要小看这个点，或多或少都遇到过这种问题。
2. 按照“粗读需求”的方式，完成对需求（功能）的逐一拆分，由大到小、化整为零。
3. 针对拆分后的每一个功能点、元素等，进行详细的阅读，掌握每一个细节。
4. “精读需求”过程中，需要思考是否存在“隐性需求”。这也是设计用例时需要覆盖的部分。
5. “精读需求”过程中，需要挖掘需求问题，寻求解决，完善需求文档，从而提升测试用例的完整性。
6. “精读需求”过程中，对于已经覆盖的部分，最好进行标记，然后全部阅读完毕，再重新进行一次复查，通过标记确认是否全部覆盖。

注意事项：

1. 在“精读需求”一定要仔细，不能遗漏。
   1. 对于功能的拆分，实际上就是用例设计中功能、子功能的拆分过程；
   2. 对于功能点、元素等的拆分，就是用例设计中提取测试对象、检查点的过程；
   3. 每一个细节描述，都有可能对应测试用例中的一个或多个检查点，以及影响因素。
   4. 同时测试用例的预期结果也都体现在细节描述中。
2. 通过“精读需求”，了解需求细节的目的，有可能对测试的侧重点产生影响。
   1. 了解需求对应内容的应用场景，会影响测试设计时选取什么样的测试环境和测试数据。 例如：当前的同传功能，主要应用于大型演讲会，那么测试数据，就应该选择演讲性的视频/音频。
   2. 看似不合理的需求，更需要通过了解目的，才能有效的理解需求。 例如：为了减少用户的卸载率。当用户卸载程序时，已经进行二次确认后，仍然给用户弹出一个挽留界面，阻拦用户卸载。
3. 在“精读需求”过程中，解惑答疑。 需求中或多或少会存在部分内容，无法理解，在精度的过程中，与产品沟通，解决相关疑问。
4. 在“精读需求”过程中，统一概念。 对于需求中的某些专属功能、元素等，在定义或概念上需要与产品和开发达成一致，以免产生歧义。