在阿里也差不多待了一个多月，接触的项目也很具有代表性，简单描叙一下场景吧。需求方是我们的运营同学，该项目涉及到有ETL部分和UED部分，前期，我没有进入到该项目组，详细设计阶段缺少我们测试人员，导致当进行项目之后，发现项目文档写得不具备可测试性。后期，文档修改完成之后，测试阶段碰到的最多的就是变化，需求在变，设计也在变，测试人员拖在后面，压力很大的！

　　场景，大致就是这样子的。具体的问题细节，应该是很有代表性的。

　　1、进入项目比较晚，导致的问题就是详细设计文档，没有测试人员参与，当测试人员进入之后，发现根据文档，测试人员无法进行测试分析，编写测试案例的工作。而此时开发人员已经开发了一定的时间，所以，这个时候，开发人员配合修改文档的工作不是很积极。当直接和开发人员讨论，会看到每个开发人员并不清楚其他人的工作，也就是说开发人员也都没法完全理解详细设计文档。他们的工作模式可能是边coding边重新设计。这个是很可怕的事情。

　　如果这种事情发生了，怎么办？一个好的测试人员，需要在整个项目流程中，引导开发，PM，去遵守一定的流程，好的流程可以事半功倍的。当我碰到这个情况后，我是按下面的步骤进行：

　　● 第一步，与开发，PM沟通，花一个下午的时候，把详细设计文档中的问题指出来，并给出一个期望的模板。

　　● 第二步，制定测试计划，期间规定详细设计文档交付的时间，单元测试交付的时间，测试案例评审的时间，测试脚本和测试执行的时间。这个测试计划也需要和DEV，PM达成共识。

　　● 第三步，为开发人员引进一个合适的单元测试框架，给出单元测试的案例标准。

　　● 第四步，在流程的每个关键点进行把控开发的活动，不能只制定流程，而不去关心流程在运转的状况。

　　2、需求变更太多.虽然说，标准的流程已经制定了，但是由于之前没有一个好的设计，后面需求的实现出入也会比较大。一般情况下，开发，测试，PM沟通之后，设计还是会修改的。那么，这个时候的测试人员一定得搞清楚，变更所带来的影响，以及测试会增加的工作量。

　　比如说：在项目测试的最后阶段，发现一个缺陷，但是开发人员的修改方案却是推翻之前的一个模块设计（该模块的测试已经结束），也就说该模块的代码需要重构。在进行多次讨论之后，开发人员还是需要对这部分进行变更（虽然我是反对在项目发布前做这么大的改动）。这种情况下，我能做的事情主要就集中在下面几个方面：

　　● 分析， 这些改变会影响到那些模块，及时发出邮件通知影响涉及到的人员。

　　● 同开发人员讲清楚，单元测试一定要更新，并保证通过。

　　● 即使更新测试脚本和测试数据，进行回归测试。

　　● 对之前所以的测试模块进行一次测试执行。

　　自己也不知道要说明什么，只是感慨一下进入阿里之后的一个项目经历，和之前有很大的不同。这里，是一个测试人员对着一堆的开发人员，测试人员需要做的就是全程跟进，了解项目的方方面面，让项目的质量得到保障。