除此之外，敏捷开发将完美主义的抛弃会对测试观念有很大的冲击。测试驱动的开发能够很大程度上预防很多不必要产生的缺陷，而即便在测试的执行中发现了缺陷，在高度频繁的构建中是否一定要解决它也是不确定的，因为敏捷追求软件的正常运作，而并不是十全十美。这样，在技术能力之外，测试人员的价值认同感还是会降低，甚至可能会由此产生一些困惑或者其他不好的情绪。总之，无论是开发人员还是测试人员，都要在了解敏捷的真相和本质之后才可能认同敏捷，才能够有能力参与敏捷，从而在敏捷开发过程中进行高效的沟通与协作。

　　2）怎样满足敏捷测试需要

　　看过敏捷测试的一些特征之后大家可能会想，敏捷测试到底如何实施，测试部门又能在敏捷的测试中做些什么呢？

　　首先，我们要转变观念，理解敏捷测试的真谛，把敏捷开发的准则当作测试人员工作的指引之一。概念性问题看起来总是很简单的事情，但是实际操作过程中，测试主管会不会犯形式主义错误，会不会搞运动，测试人员是不是能够真正把测试当作驱动软件开发的手段而不是用于证明自己价值的方式，都很难说。如果测试人员在敏捷开发过程中有太多自我意识，那么敏捷开发可能真的就不需要专职的测试人员的存在了，所以，意识和理念上的转变是势在必行的。

　　其次，从敏捷开发的需求来看，还是有很大一部分测试人员的技能需要一定程度的提高的，尤其是像笔者这样常年从事黑盒测试，编码经验稍微欠缺的人。我们知道UI向上的测试比例在敏捷测试中只占20%不到，那么我们要放弃余下的80%的测试么？如果真的这样，那么测试与开发的比例真的就该变成1：10或者1：20了，而且这只会让一部分测试意识较强的开发人员转变为测试人员；即便是放弃，我们将会去哪里呢？相信绝大多数测试人员的选择无非是转岗做开发而已，那么我们所要面临的问题将不可改变的定格在编码能力上的提高上。既然无论如何都要提高，那么还不如自己主动提高，至于编制归入开发部门还是测试部门对于老板来说都不重要。

　　第三，自动化测试管理平台和框架的搭建。由敏捷开发和测试的特点看来，我们还需要一个稳定、高效的测试管理平台，随时能够支持快速的测试运行，并且不为测试工具而困扰，不为测试数据而困扰，不为测试环境可用性而困扰。这个平台由开发部门主导搭建还是由测试部门主导搭建也不重要，关键在于如何能够做到尽可能不受方方面面因素的困扰。

　　第四，足够强大的UI验证测试自动化。单元测试和集成测试全部通过完成之后是否就意味着本次构建测试就是通过的呢？当然不是。在很多夹杂着复杂业务逻辑的软件中，复杂的操作场景和数据逻辑的正确性验证还是要依赖大量的UI层面上的验证测试。所以对于有些形态的软件产品的敏捷开发来说，有足够强大的UI层自动化测试支持也是必需的；否则，测试有效性就将面临很大的挑战，软件质量无法得到切实的保证。那么，这里边有一个很大的挑战：测试运行的频度和效率！因为敏捷开发过程中每天可能需要运行一组测试几十、几百、乃至上千次，对于单元测试和集成测试来说这都不成问题，但是，如上节所述，如何大幅提高UI自动化测试的执行效率来支持高频率的构建是必须面临的问题。因此我们要尽量避开臃肿的、执行效率缓慢的测试工具或测试程序的使用，让自动化测试程序的运行速度尽可能追上接口测试和单元测试的执行速度。而这种执行效率决不是像QTP这种工具或者框架所能支持的，所以我们必须不断学习、尝试更加多的工具和框架的使用。

　　通过上文对敏捷测试的阐述，大家应该能够理解笔者对测试自动化和敏捷测试的看法，我们需要为敏捷测试的开展所作的准备不多，但却不是很容易就能做到。反观自己，我们不妨把思维缩小到我们自己的公司或部门来考虑一下，按照我们当前的体制和资源，我们到底是否适合开始尝试这种先进的开发模式。套用鲁迅先生一句话：我向来不惮以最坏的恶意揣测管理者，不过埋在我们骨子里的在做事方式上的一些形式化趋向的确值得引起大家的警觉与注意。很多人抱怨自己所在的组织所进行的敏捷开发只是一个华而不实的东西，混乱无序以至于无法管理；甚至有些时候敏捷开发成了拒绝一切规范与文档编制、抛弃软件设计过程、回避测试缺陷的挡箭牌。到如今，敏捷开发已经不再是一个概念，它已经成为一种先进的手段，它能够降低管理成本，能够加速开发进程，但它不是随便一个人抓起来就可以用的工具。这些抱怨表明，还是有很多人没有真正地理解敏捷开发与敏捷测试到底是什么就匆匆一头扎了进去。当然，很大一部分人还是比较理性或者聪明的，要么谨慎地学习，要么经过充分的准备再去实践。敏捷开发让我们的软件开发秩序变得很像趴在山崖上振翅的雏鹰，骨骼是否足够强壮、是否掌握了最基本得飞行技能就是决定它到底是翱翔蓝天还是粉身碎骨的决定性因素。