当项目已经上线并且趋于稳定，测试人员就不会每天对版本做一轮又一轮的回归测试。这时，开发在迭代版本中改动一点代码，没有告知测试人员，那么测试人员很难发现由改动引发的BUG。

这种情况下，测试人员确实无奈：产品也好、开发也罢，不主动告知改动内容，测试人员会把它默认成为上一个稳定版本，不会整天放精力在这类版本的回归测试中。再者，测试人员每天都对所有项目做手工的回归测试也不现实。这造成测试人员很被动。测试人员若想提高产品质量只能寄希望于高效的团队管理，加上与产品、开发人员的及时沟通、提醒。

测试人员能不能改变这种被动的局面，全权掌握版本的动态？我想是可以的，借助自动化测试。

何谓自动化测试，老生常谈地讲，就是使用程序、工具、软件等代替手工来测试。你执行一段脚本，可以说自动化测试。你使用JMeter、Robot Framework等工具，可以做自动化测试。当然，你也可以使用一款软件来检测产品，类似于MacAfee杀毒软件对电脑的检测。

对大型且稳定的项目而言，自动化测试不仅释放测试人员的双手，还是测试人员的好帮手。

回到刚才被动的话题。在项目稳定后，测试人员根据测试用例，着手执行自动化测试、接口测试、性能测试等。根据项目及测试用例分类，然后把所有功能涉及到的自动化测试脚本放在Jenkins上，持续集成。Jenkins从检出代码、编译构建、运行测试、结果记录、测试统计等都是自动完成的，无需人工干预。测试人员每天只用手动跑一次Jenkins，就对项目做了一次回归测试。哪里提交代码引起了问题，通过Jenkins分析，即可得出结论。

或者还可以更智能化一些。测试人员自个儿开发合适的集成工具，不仅仅能检出代码、自动编译构建、运行测试、结果记录等，还可以在某一时刻自动执行测试，将测试结果发送到测试人员的邮箱，直观展示上一版本与这一版本的改动内容。

最后，不得不说，不是所有的项目都适用自动化测试，也不是所有项目使用了自动化测试就能提高测试效率。开展自动化测试最好是稳定、大型一些的项目。而当自动化测试恰到好处地发挥作用，你会发现，它正像一颗在阳光下闪闪发光的钻石。