软件测试-测试需求（终）

工作内容

测试需求分析不应只是阶段性的工作内容，每个阶段变更都会引起一系列的反应。尽管实际执行时并没有想象中完美，但是尽量往规范化靠。

1.测试需求分析

这个阶段主要搞清楚测什么的问题，为什么需要规范测试需求分析？
第一点，经历了很多需求会议，在讲到某个需求的时候总会跳跃性的讨论实现细节，把会议拉得又臭又长，目的性不明确，产品一表达需求，马上一堆人发起疑问，这个功能要怎么做？能不能做？要多长时间做?谁来做？然后导致会议结束又几乎回到起点，没人真正清楚这个项目到底要做什么。综合这些缺陷，结合一些资料的查阅，做出了优化测试需求分析过程的这个流程，控制那些本没有必要的内容。
第二点：不能清晰地知道需要做什么，很难做一个合理的计划，任务分解，各种时间、资源评估的问题暴露无遗。规范化需求分析后，无论是大计划小计划都能柔韧有余。
第三点：测试用例设计没有指导方向，全凭设计者个人经验，能力足写得不错，能力差写得差。只有规范化地分析，投入时间和人力去整理，讨论，才可能出现一个比较全面和共享性的文件作为下一步工作指导。而且在分析阶段已经能够定义需求的通过准则，其实这个工作可以减少后续很多问题。

1.需求差异化分析： 原始需求追溯，一致性比对，确认测试需求与原始需求差异始终在合理范围。
2.测试要点分析： 根据功能的重要性划分重点模块；根据具体功能划分重点内容；根据重点内容分析可能出现缺陷集群的地方（可以凭经验或者对负责开发的人员的技术能力啥的判断，一般会很有效）

**3.质量特性分析：**这个概念有点虚化，但是需求做得好的项目一般都会有说明，因为这也是立标的关键点。主要分析需要测试的功能需要达到一个什么样的质量范围。

4.测试类型分析： 测试类型有好几种分法,概念篇有说到，主要目的是分析功能需要在什么阶段做些什么样的测试。
https://blog.csdn.net/Hughier/article/details/109347924

3.测试需求矩阵

在测试需求分析过程不断的完善测试需求矩阵，最后出来一份测试清单。这是博主现在使用的模板，网上也有很多，也可以自己编写合适的。

需求标识	需求描述	原始需求	一级子需求	二级子需求	测试要点	质量特性	测试类型	通过准则

测试需求文件颗粒度根据项目情况把握，尽量考虑时间成本，维护成本，因为如果需求变更很频繁的话，你需要不停地去维护这份文档，过分细化或过分粗略都不是好事情，尽量平衡。

4.测试需求评审

也试过很多个项目做了测试需求但因为可能变更较多或者没有得到重视，没有执行测试需求评审，产生的问题主要如下：
1.测试结束后没有基线确定此次测试内容是否全面和正确
2.
3.
测试评审的目的和好处：
1.能够再次交流需求清单，能够确认被测项与需求项差异。
2.能够确认测试需求分析是否正确
3.能够确认测试准则，建立测试通过标准
4.能够减少与开发的分歧，因为你已经沟通好这个项目测试什么，需要达到什么样的质量。
…等等。
无论如何，推动评审工作，你会发现，测试工作执行起来，顺！实在无法评审，执行小会议做需求澄清也可以。

5.测试计划

主要大方面包含以下这些计划：
1.测试总体计划
2.单元测试计划
3.集成测试计划
4.系统测试计划
5.验收测试计划
网上有很多这种模板，不一一列出了，合适的才是最好的，可以自己编也可以下个合适的。
以上这些计划都是组织层，自我层面建议测试人员也需要做计划，根据每个测试任务不外乎做每天的计划、每周的计划，每个功能的计划等等，尽管没有文件，最好也规划一下。

如何有效地掌握需求动态

测试人员掌握需求动态有三个要点，一是主动，二也是主动，三还是主动。追女孩一样，主动很痛苦，不主动更痛苦。
测试需求分析不应只是阶段性的工作内容，每个阶段变更都会引起一系列的反应。尽管实际执行时并没有想象中完美，但是尽量往规范化去靠，好事多磨，谋事在人，成事在天。实际上博主用了两年时间才慢慢将这种流程走起来，一开始都是问项目经理不行问开发，问产品经理，问相关领导，反正跟需求来源有关系的人都唠个遍，自己输出文件只有自己看，越到后面越发现这种东西的好处，慢慢就自然地规范起来了。
图例一个测试需求分析的流程。

到此结束，写得不好欢迎提出建议，谢谢。