很早就听说过敏捷软件开发的概念，觉得是个新生事物，挺好玩，现在IT的炒作已经太多了，后来发现敏捷的思想越来越深入人心，大大小小的公司开始使用敏捷的模式进行软件开发。终于，敏捷来到了我的身边。

　　在传统的软件开发模式中，系统测试属于软件开发过程的较后阶段，基本是在所有开发代码全部完成，开发人员拿出所有精力修改bug时才会正式进行系统测试，包括安装啦、稳定性啦、负载啦等等。

　　这次项目开始大约半年了，是一个小版本的升级，采用了scrum模式，我切实的感觉到敏捷系统测试不太对劲。在scrum中，根据开发的实际情况，设定一个时间间隔（比如每两个周）为一个sprint周期，每个周期都有需求跟踪和实现，然后在进入下一个sprint阶段。

　　目前，我发现了几个敏捷系统测试的主要问题：

　　1. 不断增加的新功能导致测试结果失效。

　　既然是敏捷，当然是时刻适应需求的变化，于是功能不断的改变。系统测试的结果在一次次的代码变化之后失效，比如测试应用的稳定性，跑了两天，内存和其他参数都没问题，然后开发人员在下一个sprint对代码做了很多修改，你说要不要重测？？通常这种回归测试都是在系统测试的最后阶段，拿到最后的build 的之后再测，现在呢，不得不测，如果说系统测试的工作量少也就算了，但事实上，系统测试的压力特别大，搞的大家身心疲惫。

　　2. 发现问题，开发人员无法适当处理。

　　如果在测试中发现了问题，按理说开发人员应该尽快解决，但在敏捷开发模式下，开发人员每一个sprint都有相应的需求要实现，精力有限，于是他们对于细微的bug根本置之不理，一般都会拖到最后才解决，这就导致了一个问题，这些bug在若干次build之后会不会重现，可能在报完bug之后3个月，开发人员才开始考虑这个问题，此时这个bug报告还有效吗？？是不是需要重新测试？？于是我们测试人员之前的测试工作根本没意义了。另一方面，对于严重的bug，开发人员也无法集中全部精力来处理，三心两意，你说bug能解的顺利吗？后果就是开发人员和测试人员都满心抱怨。

　　在我看来，这种紧跟敏捷的系统测试不是完全没有意义，有些严重bug可以提早发现，开发人员可以尽早解决，但是体现了帕累托现象：我们用80%的努力得到了软件质量20%的提高，的确，从公司老板的角度看，这样值得，反正软件质量提高了，但对于开发和测试人员来说确实非常痛苦。我记得敏捷的思想来自于计算机界的各位大牛，他们在设计软件开发模式时，没有考虑过系统测试的特殊性吗？还是他们从没把系统测试包含在敏捷思想里面，只是某些人狂热的把敏捷错误的用到了系统测试当中？