4、尽可能少的数据维护量，提高数据灵活性，降低对测试数据健康度的依赖：抛开运行速度，基础数据足够的情况下如果需要跑800次，那么也必须得能够支持，也是说要有一套自动化数据构造的方法来支持自动化业务测试的运行；

　　5、要做到使用尽可能少的数据覆盖尽可能多的场景或流程，降低整体测试的消耗与对数据的依赖性；

　　6、彻底mock掉对关联系统的依赖，即使是同一个开发组的系统也不可以；

　　7、测试业务逻辑必须与框架和工具自身的逻辑完全剥离，不允许存在混杂；

　　8、每个流程独立，不能够通过条件去判断数据类型而向不同分支延伸，也是不允许存在树状流程设计，只允许平行的流程设计；

　　有几个测试组分别演示了自己的selenium自动化设计方法，其中有两个让我印象非常深刻。一个是把数据和操作拼接为一个字符串作为一个xml节点或者csv单元格来存储，测试执行的时候通过外层的方法去加载命令执行；另一个组是把每个页面组件封装成一个VO，内含一组get和set的方法，将操作封装为一系列的BO，测试用例中直接引用这一堆的VO和BO去组装成测试脚本。这些很与众不同的方法都是来自于他们各自的实践和总结，不能说不好或者不实用，但是我想说的是：技术手段虽好，但是设计方法遗漏了根本的效益因子和对一些基本原则的遵守。很明显，第一个虽然号称在模仿RF，但是错误的理解了关键字驱动是怎么回事，绑定了测试数据和操作，不够灵活：维护不便、重构不便、转平台不便。而第二个则明显复杂化了自动化测试脚本设计，要知道测试人员在做测试，而并非去写一套很高明的、需要交付给客户的代码。这么做耗费的人力成本是很高的，被测应用逻辑的变更造成的维护成本翻倍，而且这种做法让脚本的可读性严重降低。

　　我原以为那些粗浅的设计原则都是公理一样被所有人所遵从，但是这次会议真的让我见识到了人的思维意识差别之大。恕我不厚道的猜想，大家并非不知道这些简单的规则，只不过这些行为都是基于主动创新为出发点的，所以忘记了一些基本的、必须遵守的原则。前面说了，测试自动化不是创新活动，而且可以说测试工作不需要以创新活动来保持活力，所以还是要强调一下，请不要为了一些没有意义的目标去违背一些简单的原则。

　　重复建设——测试部门的灾难

　　无论团队组建是还是人员发展，无论是自动化体系建设还是得到自动化测试收益，都不是一朝一夕的事情，这些行为一旦开始以进度为主，急于得到回报的时候，质量问题会在不远的前方等待着你。由此开始的问题暴露和新的快速修复会导致反反复复的重复建设、重复开发，让人身心俱疲并且找不到问题所在：到底是工具不好还是人员素质不够高呢？显然都不是！我们测试部门方方面面的发展都是点滴积累的过程，无论是技术积累还是管理方法的摸索，都要切中当前的测试需求。测试经理和所有的工程师都要记得时刻提醒自己：我们是做软件测试的，我们应该为软件质量买单，这些先进的技术如果无法一时半会得以应用，那么我们要先以测试为主，这华丽的技术现阶段能用多少用多少，不能一蹴而。

　　——摘自《软件测试自动化的探索与管理》2009

　　这个问题初体现在我们的QTP自动化测试建设上，花两年时间逐步完善自动化的系统，他们的测试脚本质量远远高过那些为了完成指标在3个月内匆匆赶工做出来的系统。无论测试脚本可用性、正常情况下的运行通过率，还是测试脚本本身的可信程度，都有着质的差别。不过，这都是过去的事情了，测试部门为了迎合规划部门对整个公司的持续集成体系的规划，要丢弃历时近5年建设而成的QTP自动化测试平台体系、测试框架和近2万回归测试脚本，全部从头开始重新建设。这种行为太野蛮了，实在是荒诞不经，我本无意在你们玩过家家玩得正High的时候说这些，但是我觉得你们惯于玩一刀切，你们已经严重伤害到我个人的利益了。即便我无力改变你们的想法、做法，但我还是得说两句：

　　1、应该搞清楚哪些系统必须要参与持续集成，而哪些不需要，哪些不能够，如果一定要坚持认为整齐划一，那我们只能选择沉默不语、被动配合，坐等你的决策带领我们走向失败；

　　2、必须要参与持续集成的系统可以优先安排开源自动化的转平台；

　　3、无需持续集成的系统，不要强制，让开发和测试分析、协商如何选择后续的做法；

　　4、不能够参与持续集成或者说做持续集成没有价值的系统，不要强制他们去参与这项活动，同时自动化测试脚本可以根据现有的自动化水平去选择是要保持原有的建设成果还是推翻重来；