2、自动化测试，减小人力或者重复劳动。

　　纯粹的自动化功能测试，而不是手工测试。即使测试用例有上千个，自动化测试也可以每天可以回归几十次。而手工测试如果要回归，将花费大量的人力和重复劳动。

　　也许，测试最重要的好处就是它对于构架和设计的影响。为了使一个模块或者应用程序具有可测试性，必须对它进行解耦合。越是具有可测试性，耦合关系就越弱。全面的考虑验收测试和单元测试的行为对于软件的结构具有深远的正面的影响。

　　（五）新型测试模式的不足

　　1、频繁的变更，对自动化测试架构提出了更高的要求。

　　由于自动化功能测试是基本UI 的测试，如果是频繁的变更，不便于自动化脚本的维护。那么这就对代码的架构提出更高的要求，怎么样让自动测试脚本快速对应变更？开发人员在设计初期就应该考虑到测试先行的问题，就应该有不同于普通的系统架构方面的权衡，而不是在进行迭代后，使用自动化测试工具出现很多问题之后，才发现架构的问题，这时的人力、物力的浪费都是很巨大的，在Webpos 项目中，就是因为没有考虑到这个问题，导致自动化测试脚本在每次版本变更后对应起来非常困难，甚至在项目中期因为可扩展性差的问题而重新进行架构设计，造成了大量的人力成本的浪费。

　　2、如果太多依赖客户，影响我们在客户心中的信誉度。

　　由于敏捷开发中频繁变更的需求都是从客户那里获取的，所以对于一些建议性方面的bug 是否该提，测试人员的立场非常尴尬。因为开发人员不愿意为了这些建议性的问题来增加工作量，特别是这些问题客户可能并未提出。时间久了就会对测试人员产生抱怨。这样，测试人员的积极性也会被降低甚至从此不再关注此类问题；但是对于客户来说，遇到此类问题就可能会抱怨为何测试人员没能及早发现而遗留到最终用户手上。

　　3、由于自动化测试，对测试人员提出了更高的要求。

　　敏捷开发的测试人员不但要熟悉开发语言、自动化测试工具，能够编写自动化测试脚本或者用工具录制，而且要参与项目和系统的需求分析和架构设计中。但是对于目前实际的项目，测试人员只是被要求进行验收测试，并没有被要求更多的思考需求的可实现性，也没有将自身作为第一用户参与项目和系统的需求分析，设计和开发。当然这也是很多敏捷开发项目中测试人员甚至开发人员都无法达到的水平。这也是我们今后努力的方向。

　　（六）改进

　　无论是传统开发的测试模式，还是新型开发的测试模式，目的都是为了保证产品质量，达到客户满意。对于目前实际项目来说，目前仍旧需要持续改进的就是：

　　1、系统架构的设计应该充分考虑测试的需求和可测试性。

　　2、测试人员加强主流测试工具的学习，提高测试水平，并且积极的参与到项目讨论及客户交流中去。

　　希望能通过我们的持续改进，使我们的团队充满激情和活力，能够适应更大的变化，做出更高质量的软件。