自动化测试思想

自动化测试的实质是为了快速、高效地发现和预防回归缺陷

自动化测试（特别是基于UI的自动化测试）不是万能的，也不是测试的全部，更不是没有成本的。

从本质上讲，非UI测试和UI测试，是互为补充的，根据其成本和特性的不同，在实际工程应用中也应该领会运用。其基本原则：非UI自动化测试用例为主，UI自动测试为必要的补充，考虑成本因素，UI自动测试可以被手动测试所取代。

/quicknet/archive/2010/11/24/6032674.aspx

---------------------------------------------------------------------------------------------------------------

自动化测试消亡的原因及应对措施

什么原因会导致自动化测试的退化和过早消亡?

1、未提前通知的软件变更：当我们已经积累了大量的自动化脚本，而且脚本中存在大量的被引用测试包，当发生的变更隐藏在某个或某些个被引用测试包的时候，测试人员并没有得到应得的提前通知，而是在发现自动化测试失效的时候才发现问题的严重性，随之带来的失效诊断、问题修复、脚本维护上的时间打断了我们目前的测试进程，为了不过多影响软件发布，项目组不得不采取手动替代的方案让大家继续测试，自动化测试被迫搁置一边;

2、软件重构：当产品进入市场，由于性能或其他问题并不被客户看好的时候，我们会考虑到软件的大规模重构，由此带来的未知的界面和业务变更会使得我们前期积累的大批量自动化测试脚本无法复用，除了一些文档、方法、策略，其他都成了明日黄花，同时，开发语言、开发工具、平台的变更同样会导致这类问题;

3、关键自动化测试人员的离职：当一些测试策略、文档、规范一直存放于一个或些个自动化测试人员的脑海、未被公布的测试机的某个路径下的时候，关键自动化测试人员的离职也会导致自动化测试的停滞不前、日益退化;

如何应对与避免?

1、软件架构与设计阶段就应当考虑到自动化测试：软件测试并不仅仅是软件测试工程师自己的事情，需要架构师、需求人员、系统工程师、开发人员的协助，比如，在软件被开发出来之前就可以在软件原型上进行自动化测试设计、脚本编制等，这就要求原型开发人员、需求人员的大力支持，需求文档尽量精确详细，尽量避免变更，软件开发过程中，及时对原型进行维护等;

2、时刻考虑到维护：安排专门的自动化脚本维护工程师在特定的时间对脚本进行及时维护，而不是在发现测试大量失效的情况下再亡羊补牢;

3、不要集权：自动化测试策略、自动化测试文档、资料等不要集中在一个人手中，要有特定的机器存放，自动化测试进行过程中积累的各种经验和教训要及时付诸文档，或者及时沟通与培训;

4、摆脱被动：自动化测试不要做软件开发的附属物，而是要驱动和指引软件开发，当发现问题时决不手软，比如软件性能问题，不要到软件开发后期再考虑到性能测试，时刻积累数据，发现问题及时通知，而不是到了一定程度，忍无可忍时再去通知，当软件不得不进行重构时，发愁的不仅是开发，还有测试。

5、规范：有严格的自动化脚本编写规范、每个里程碑的自动化测试目标明确、每个里程碑的测试策略明确、脚本编制人、编制日期、测试功能点、期望结果等要清晰可辨，这些都是为了脚本的易维护性而考虑的;