[ 你说我说 ] 如何应对转测试以后的需求变更？

MILY: 宋体; mso-ascii-font-family: Arial; mso-hansi-font-family: Arial; mso-bidi-font-family: Arial; mso-font-kerning: 0pt">上文提到的测试执行分层是Waterfall开发模式的典型测试模式，这个模型很完美，但它是基于这样一个重要的假设：项目的需求变化不多或者说需求很稳定。产品由开发转测试后，当需求更改较多或者新需求不断涌现的时候，很多问题也随之而来，尤其对于大型的项目而言，问题较为突出，解决办法可绝不是纸上谈兵那么简单。

问题主要表现为：

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

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

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

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

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

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

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

本人想到的可能的解决办法（其实做起来很困难）：

1）            从源头抓起，测试人员和开发人员一起在第一时间得知需求的变更；

2）            提前做好新需求的测试规划，包括测试设计和测试执行规划，并且在设计中要考虑新需求对老需求的影响；

3）            做好需求跟踪：对每个需求的测试相关属性（测试用例、测试执行记录等）都进行跟踪。

欢迎讨论。