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

工作内容

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

**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.验收测试计划
上有很多这种模板，不一一列出了，合适的才是最好的，可以自己编也可以下个合适的。
以上这些计划都是组织层，自我层面建议测试人员也需要做计划，根据每个测试任务不外乎做每天的计划、每周的计划，每个功能的计划等等，尽管没有文件，最好也规划一下。

如何有效地掌握需求动态