如何进行需求分析
需求分析概览图
业务类需求
技术类需求
工作中难免会遇到并不“完美”的需求文档，比如牵一发而动全身却不清晰的交互逻辑、子条目频繁的变更、交流缺失导致的歧义等，都会让测试在项目推进中手足无措。
一份好的需求文档，不止能够加速开发和测试的脚步，还能够提前发现风险，是产品的第一道风险保障。
需求分析概览图
业务类需求
背景&目标
在阅读需求文档时，首先我们要对项目或者功能本身有一个宏观的认识，首要针对需求的整体作用进行评审。如果整体的方向错误，那么细节上也没有再讨论的意义了。
完整性
站在完整性的角度看需求文档，实际上是将当前的负责的项目模块化（或者抽象化），根据功能的需求确定功能的影响范围，再细化，同时对比需求文档，这样对目标的操作有个明确的预期结果。
1）结构化项目流程
- 原型图
- 流程图
无论是功能类的需求、质量类的需求还是解决用户反馈的需求，都可以把这些需求抽象成为操作（增、删、改）、查询两个大模式。要么是纯查询类需求（即刻俊译），要么就是两者结合操作类+查询类（灵犀）。
2）确认影响因素
比如一个纯查询类的功能需求，我们通过以上的图就可以知道，整个过程影响我们的因素有：
- 用户输入
- 类型（中文、汉字、英文、数字、不支持编码、表情、符号）
- 长度（最短、最长）
- 异常输入
- ...
- 查询条件
- 完全匹配查询、部分匹配查询（简拼、暴力）
- 需求中定义的查询规则（匹配规则、优先级逻辑）
- 查询内容
- 这里的查询内容指的是被查询内容的特性，存在/不存在，同步/异步，正常/异常，或某些需求文档中指明的情况
- 效果展示
- 展示位置
- 排序优先级
- 展示个数
- 标记情况
3）综合外界因素
这里的外界影响因素，指的是有可能改变这四个过程中的某些外界因素，比如开启繁体下会改变用户输入，比如当用户关闭用户词会使用户词查询内容失效，再比如某些固排的词会影响效果展示。
还有一些效果性的需求，比如提高查询效率，我们知道这个功能只需要改动查询条件就可以，但是在需求文档中也应明确是否有用户输入和查询内容的约束。当然这些综合考量离不开测试人员对项目知识的掌握程度，在这里建议类比相似功能、总结记录（bug、特殊场景）以及用例评审去提升外界因素的覆盖度。
将以上因素排列组合和归纳，再对比需求文档，我们就可以知道某种特定的输入下，有哪些预期结果。那这些预期结果到底好不好，这就涉及到需求细节的明确性、合理性以及优先级。即明确性、合理性以及优先级的相关影响因素是在完整性的考量中确定的，所以结构化项目流程，明确影响因素范围尤其重要。
明确性
明确性是需求阅读中的痛点，因为阅读的时候人都是主观的，所以很难有这个明确性的意识。经常出现问题的地方是歧义和没有约束。
-
对歧义的建议是多次阅读，特别是那些觉得非常拗口的地方，往往都是问题频发的根源。
-
约束的问题往往依赖个人经验，比如键盘类型的约束以及异常校验的约束等。
合理性
-
是否符合用户需求：需求是否解决了用户痛点。
-
是否符合大众逻辑：解决的这个痛点会不会只考虑到小范围的用户，从而影响到大众关注的逻辑。
-
是否满足用户体验：同时要及时发现对于用户操作过程中的体验问题，在糗事百科创始人著作的《结网》一书中，提出了用户体验的三大原则：别让我等，别让我想，别让我烦。
优先级
某些需求项与已有功能有“冲突”，针对这些需求项，是否明确了优先级，并评估优先级的合理性。
技术类需求
为了能有助于测试开展，我们同样需要了解开发技术，毕竟在测试环境的搭建及维护，测试过程中各种场景的模拟特别是异常情况，以及自动化测试等，都需要借助于开发技术。
- 理解研发设计的架构及设计思路，并考察开发设计是否满足业务需求。
- 确认技术方案设计的影响点（代码影响、依赖模块、历史功能/数据兼容等）。
- 了解并熟悉开发使用的技术及开发框架（视不同项目具体情况而有所不同）。
- 考察代码的质量属性是否满足以下要求：
- 可用性：评估最终用户在使用软件并与软件交互时的可用性问题。
- 容错性/健壮性：用于测试系统在出现故障时，是否能够自动恢复或忽略故障继续运行。
- 安全性：避免出现SQL注入、XSS、泄密等相关安全风险。
- 性能：评估程序在不同并发用户数和不同数据量下的响应时间以及吞吐率/量。
- 可维护性：评估系统是否拥有良好的数据处理和日志机制，以备技术支持和调试之需。
- 可扩展性：解耦、参数配置或代码写死。
- 兼容性：不同的硬件、软件（操作系统、浏览器）等。
- 可靠性：是否能达到规格说明中的运行时常和 MTBF（平均无故障工作时间），避免影响用户的本身业务（内容、过程）。
- ...
