前段时间更新了测试活动过程详解的系列文章，从单元测试的特点、集成测试的实践方法，到系统测试的注意事项、回归测试要解决的问题，对整个测试活动执行过程进行了详细拆解。
但对于整个质量保障工作而言，测试活动最早的介入时机，其实是在需求阶段。只有明确了需求，后续的技术方案设计、编码以及测试执行才能正确合理地开展，否则最终的结果大概率会变成“牛头不对马嘴”，最终交付的质量也可能会变成被各种补丁覆盖的残次品。
这篇文章，分享一些我对于需求测试的实践经验和思考。
如何理解需求测试
以一次正常的迭代为例，从需求到上线，大致要经历如下几个阶段：
在需求阶段，测试同学比较熟悉的是需求评审，主要针对需求范围、实现需求所需的资源以及关键的时间节点进行评估，因为这三点是影响交付质量的基础三要素。但在这之外，我的理解是测试同学还需要对需求本身进行测试。
如何对需求进行测试呢？回想一下我们日常的工作场景：首先产品会预订需求评审会议，并附产品PRD等相关内容；然后产研设等相关同学参会，开展需求评审，确定范围/资源/时间等重要信息。我所指的需求测试，就是在得到产品PRD和开展需求评审之间，对需求本身进行可测性验证。
需求测试的核心在于明确“测试什么”，即被测对象中的什么需要测试，以及是否满足测试执行条件。需求测试的结果，要求必须有一个明确的预期结果，或者需求最终的实现必须满足可观察可验证的要求。
需求测试常用的方式是实例化，简单理解就是将需求故事化。故事一般具有这几个特征：有背景和设定、有过程有逻辑、交代了前因后果。而需求评审，更多的是对需求实例化中不确定的部分进行确认和澄清，最终得到和业务规则较为匹配的测试用例模型。
关于可测性和实例化需求，请参考前面的文章:《聊聊实例化需求》、《可测性，到底是什么？》
需求测试的实践步骤
一般来说，需求测试大致要经历如下几个步骤：
- 需求分析：一般需求都是业务或者产品通过PRD提供，测试要做的是对需求进行故事化；
- 明确范围：明确需求涉及的业务范围，具体的功能模块，对应的应用服务以及前置依赖条件；
- 罗列操作：对需求进一步拆分，需求范围内的各模块，用户都存在哪些业务场景和操作步骤；
- 需求评审：和产研设等同学对需求开展评审，确保需求描述是具体的、可度量的、可测试的；
这里需要说明的是，需求测试的目的更多的是让测试同学对需求更加了解，对于本次要测试的内容提前做到心里有数。在需求测试阶段不明确或者存在疑问的部分，在需求评审时进行确认。
需求评审时，除了明确需求范围/所需资源/关键时间节点这三要素之外，还应该关注用户场景的工作流程和业务规则的定义是否清晰明确。
需求测试的注意事项
其实需求测试的注意事项和其他测试活动阶段没什么区别，主要有如下几点：
- 完整性：需求描述应该清晰明确完整，便于理解；
- 正确性：需求场景和逻辑描述应该准确无误，避免产生歧义；
- 一致性：需求描述应该考虑到边界和其他依赖，不相互产生矛盾；
- 容错性：需求应该考虑到可能出现的异常和逆向场景，并给出容错处理描述；
- 可跟踪：需求应与设计、源代码、测试用例建立连接，便于跟踪管理(非强制）;
在需求测试阶段，测试同学应该尽量对需求开展充分的测试，在需求评审时将存在疑义和不合理不明确的部分尽量明确和澄清，避免在后续的编码和测试阶段出现新的问题。
风险越早发现，修复成本越低。控制风险，才是质量保障最核心的理念。
