引言

          整个项目迭代周期中，产生的bug，其原因可能来自多个方面，例如：需求分析不足/需求不符合客户需求、技术实现与需求不符、环境因素等等，这里重点说一下需求阶段引入的bug问题。

           需求调研、分析、评审阶段中任何一个环节的不充分都会给需求本身留下隐患，进而在整个项目的中后期才能发现。更甚者，到了上线还没有发现，只能下次迭代进行弥补了。

需求引入问题的严重性

          这里举一个身边实际发生的一个需求评估不足产生的一个问题： 当时PM提出了一个大的首页大改版，经过需求评审后，没发现什么不合理之处，技术人员经过两周的加班加点实现、测试、产品验收，最终上线了。但大产品boss一看，明显不对自己的口味，于是乎这次的大改版马上就有进行了一个大改版，改回去了原来的样子。

          从上面的例子中可以看出，需求实现后又被推翻的根本原因在于： 需求调研、分析阶段上下级未达成一致，就匆匆拉技术人员进行了实现，导致了白白浪费了一大波时间。

基于需求测试的必要性

           调查表明56%的缺陷其实是在软件需求阶段被引入的（James Martin, "An Information Systems Manifesto", Prentice Hall, 1984）。这其中的50%是由于需求文档编写有问题、不明确、不清晰、不正确导致的；剩下的50%是由于需求的遗漏导致的。

           上面的数字来自权威数据，具体的数字可能与每个项目有所出入，但基本可以论证对基于需求测试的必要性了。

            记得自己在负责整个从0到1的项目，前大半年的时间里面，需求方面的bug占比大约20%+，这类需求从提出到修复会占用团队不少时间：测试人员提测——>产品人员确认——>技术人员实现——>测试人员测试——>产品人员验收。

基于需求测试需要做些什么

• 需求文档的质量

          由于需求文档编写有问题、不明确、不清晰、不正确等都可能引入问题，因而在需求评审时，一定要对类似可能出问题的地方一一核对清楚，并让PM人员记录在需求文档中。 

• 需求中的实现方案质量

         由于现在的系统往往都经过了一年、两年、甚至更长周期的迭代，系统本身往往都比较复杂，涉及的功能场景很多，逻辑分支很多，往往关联到的第三方，要做到完全的覆盖几乎不可能。

         需求评审中，需要对实现方案做反复斟酌，万万不可一刀切，给后续留下隐患。

• 需求中没有明确说明部分的质量

         这属于需求评审中隐藏比较深的部分了，这其中暗含了：

1、需要所有成员根据经验来评估哪些部分受到了影响，而需求本身又没有明说；

2、涉及到影响的部分如何处理、实现才能符合整体需求目标；

3、与产品目前现有的实现是否有冲突，或影响产品一致性等

最后

以上就是等待紫菜为你收集整理的基于需求的测试引言需求引入问题的严重性基于需求测试的必要性基于需求测试需要做些什么的全部内容，希望文章能够帮你解决基于需求的测试引言需求引入问题的严重性基于需求测试的必要性基于需求测试需要做些什么所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。