在Waterfall或V模型下的测试分层往往看起来很完美，但它是基于这样一个重要的假设：项目的需求变化不多或者说需求很稳定。产品由开发转测试后，当需求更改较多或者新需求不断涌现的时候，很多问题也随之而来，尤其对于大型的项目而言，问题较为突出，主要表现为：

　　1）需求的变化，测试人员不知晓；

　　2）测试人员知晓需求变化的时间滞后，例如在回归问题单时才知道；

　　3）由于版本间歇期短，测试没有人力和时间投入对新增修改需求的测试分析和设计上，基本上很难像对待老需求一样，开展详细的测试分析设计；

　　4）对变化需求与老特性的交互上分析不够或者根本没有展开继承性分析；

　　5）新增修改需求打乱了原有的测试规划，甚至包括对测试特性的划分原则，相应的测试结果分析、测试需求跟踪等都不到位；

　　6）测试策略的更新不及时；

　　7）产品转测试后，开发一般时间也很紧张，单元测试等做不到位，结果会遗留很多本应该在UT/IT阶段发现的问题到系统测试阶段。

　　在您的项目中，需求变更对测试还有哪些影响？测试又是如何应对转测试以后的需求变更呢？欢迎补充。

　　刘强：

　　许多的时候只有测试人员拿到软件的时候发现软件功能变化了，不知道是软件缺陷还是功能的变更，弄的测试人员很不开心，只能在边测试边沟通，这样导致许多的时候测试人员无法全面的考虑到测试的场景，我们当时根据现状自己开发了一款工具，当有新需求的进来的时候会自动发邮件通知相关部门的相关人员，同时需求会标记为New的状态，当需求经过评审以后就自动标记为评审的状态，是评审通过还是没有通过，没有通过的原因是什么都会由相关人员记录进去，同时会发送所有的相关人员，同时每天都会在下班的时候对今天新增需求，没有处理的需求自动的进行分类，发送邮件给相关的人员，这样每个部门都会收到需求变化的通知；所有就不会存在1，2，6两点的问题都就相应的解决了；

　　邰晓梅：

　　这种做法很好，可以实时地向相关人推送需求的变化，有点像敏捷项目里的可视化手段，比如持续集成（CI）的状态要实时地推送到每个人，推送的方式除了邮件外，更有效的方式比如用公共机器上的屏保、CCTray、声音等都是不错的选择。这种方式可能有几点需特别注意：通知源信息的完整性和及时性（像Scrum里的PO可以被认为是需求的统一接口，来自各方的需求都会汇集到PO这里，然后PO会维护所有原始需求的状态，初始、已分析、已计划、完成等等）、所通知的需求变更的粒度是否合适（有些是设计的变更，可能还反映不到需求的层面，但是对测试来说是很重要的风险信息）、如果有可能测试最好是参与到需求的评审和讨论中，而不是事后被通知一个结果而已。

　　刘强：

　　当时新需求源源不断的进入的时候很有可能打断我们测试人员的计划，这个我当时处理的办法就是要设立产品基线，什么时候的需求可以融入此时版本，同时加入该需求会有多少客户去买账，如果只是一个两个客户，那么我可以将下期版本更新或者不做应对处理，同时要拿出这样做会对现有的计划的影响和带来的后果，这样确保我现在的计划不会被打乱，因为有些市场反馈回来的信息很不准确，所有自己首先要对这个有把握，才可以不被这些外界因素打乱。

　　邰晓梅：

　　在需求不断变更的时候，测试的管理一定也是迭代进行的。每一个change到来后，要进行风险分析（优先级、估计），并相应地更新测试计划，而不是确保现在的计划不会被打乱。市场反馈的信息不准确这种因素，体现在你的风险分析工作做得怎样，你可能需求全方位的从各种角色那里了解该风险的属性，甚至召开风险评估会，大家一起进行风险分析（PRA 或 FRA）。你所说的产品基线的概念有点类似PO对需求处理时的DONE的概念，也就是此时XX需求经过一系列的分析处理已经可以进入testing的状态了。可见，你正在实施的是Risk Based Testing Planning的内容。

　　刘强：

　　关于7点，我的观点就是有多少个公司会做单元测试，包括微软这样的公司，他会对他所有的产品去做单元测试吗？肯定不会去做的，所有我们不一定要把所有的希望寄托到单元测试，而我们要利用现有的资源认真的去对待系统测试，同时还是多去规范开发和测试的规范，这样比依靠单元测试更有效；

　　这个是我自己对以上的几点做出的意见和看法，希望可以能得到你对我的意见的评价，这样我就可以更好的去在实际过程中处理这些事情，谢谢！

　　邰晓梅：

　　这里不是强调单元测试，而是强调开发早期所做的各种测试活动。不管开发人员做的是单元测试，还是模块级的集成、模块级的系统测试、甚至可能是早期的review等等，这些早期的测试活动的质量还是很关键的，如果只是把力量关注于后端的系统测试，成本比较高，不是高效的做法。

　　本文转载自：http://www.taixiaomei.com/archives/193