xUnit测试体系入门引导

最近新员工培训开展的如火如荼，新同学的压力很大，动力也很足；老同学忙着干活和教导，不亦累乎，美中不足，似乎少了些前瞻性的的提高和进步。现在似乎还有很多东西可以教给新同学，可是一两年后呢，我们现在的技术底蕴，是否还能支撑部门业务的需求和发展，经过谷歌段念的一个简短培训，大家是否意识到了巨大的差距，我这里简单写写自己对后续技能发展的一些想法。

做过底层测试的同学都会碰到接口或者组件的测试，我们花了一年多的时间培训和学习loadrunner,python之类的脚本开发语言，在各种项目和接口中也进行了应用，收效差强人意，虽然很多同学用的仍不够熟练，至少已可以覆盖各类接口的测试需求；性能测试这块，大多数高负载项目我们也有了去做性能分析的能力，很多同学也不再像以前只是把压力测试当作录制/回放的走场，能够发现和分析系统的性能瓶颈，虽有许多不足，我们已经去做了；我们的测试实验室，也已经能够很好的支撑项目的开发、测试和部署需求，12台的服务器构建了一个相对完善的测试环境支撑。

那自动化测试呢？这个测试领域一直是很困惑我们的一个话题，作为一家手机终端的移动互联网公司，自动化测试到底有多少的用武之地？QTP、watir这些业内知名的自动化测试在这个领域变得步履蹒跚，追根刨底，罪根只在一词：UI。在移动互联网领域，针对UI的机器人商业测试程序变得格格不入，那么抛开UI层呢，我们有办法去做自动化测试吗，怎么去做，做的价值在哪，是否在这个领域自动化只是一颗可望不可及的“银弹”。

我想，办法是有的。淘宝，阿里，谷歌，百度这些大型国内互联网公司都已经有了独立的底层测试小组，而所用的方法，大同小异，都是xUnit测试体系，如果访问junit.org，您就会看到Gerard Meszaros的一句名言：“在软件开发领域，如此少的几行代码，作用如此巨大，真是从未有过”。“JUnit之所以重要并受到丘吉尔式的评价，是因为这个小工具对于许多编程人员的根本性转变至关重要：测试移动到了编程前沿和中心位置。人们以前提倡它，但JUnit使得它真正成为现实。”

当然，不仅仅是JUnit，现在许多编程语言都已经编写了JUnit端口。这个开放的工具家族(通常称为xUnit工具)已经从它的Java根源广泛蔓延开来。对于xUnit工具，更重要的是它们的基本原理，为项目团队提供了大量机会——编写强大回归测试套件的机会，这些套件允许团队以较小风险对代码库做出重大变更，以及使用测试驱动开发重新思考设计过程的机会。

我们可以先不提测试驱动开发，也毋庸去讨论结对编程、mock、stub，最现实的，我们现在可以把以前零星编写的测试脚本用xUnit语言组织起来，把我们的测试用例以测试脚本的方式存储转换，并随着项目的进展持续追加，而回归，那不过是点击下按钮看看呈现给我们的是绿条还是红条的问题，当然这些建立在你对测试的系统足够的了解和熟练的代码组织能力。

Junit,httpunit,xmlunit,dbunit等测试代码生成工具，配合ant或mavens的自动化构建，加上后续CC或hudson的持续集成，将是我们底层接口和自动化测试的发展重点，新老同学们，可以准备了。

小文一篇，只做引导，具体方法，再做阐述。