简单体验了一下testwo网站，功能简洁，操作方便，即刻觉得这是一个不错的网站，从功能的用户体验上来看，给我留下不错的印象，但testwo是不是采用mysql的数据库，还是用tomcat中小web 服务作为应用服务器，总是感觉性能仍需提高，因为看好这个网站，未来三年用户数会猛增，也就对响应时间的指标要求提高了。
承上，话峰转回，所以有心情在testwo留下印迹。我们知道作为测试同行，很多人谈到技术提升，谈到职业规划，会有相当部分人在参与黑盒测试一定阶段后，介入自动化测试的念头，下面谈谈自动化测试之我实践的三个阶段：
一， 认为技术很重要
从事过自动化测试负责或主要带头人的同学，肯定有这样的感受，如何寻找到一款强大的自动化测试工具？
比如：Robot, QTP, silktest, watir, selenium? 还是自己开发？
大部分签于面向项目，面向团队测试服务可能很难抽出时间进行自主开发，也就选择了前者。
那么就是在商业工具和开源工具之间做抉择，利用工作或休息挤出时间学习VBS,Java, Ruby 掌握或者精通一款工具。一段时间你会了，并开始推广，引起无数同学之羡慕，在大家参与和簇拥下，我们一起开始准备自动化脚本，在项目的发布，数据的准备，以及主干功能的回归验证测试中，有人使用了自动化测试，你当上了明星。
一段时间实践后，你会发现任何一款商业自动化工具与人一样，有优点有缺点，但最大的缺点在于面对商业工具
缺点的不可修复性。
于是乎，开源的工具提上案头，经过无数次的学习与挫败，恨下心来下之决定，我们开发吧：
搞清自动化对象识别的原理，采用document对象，还是代理，还是模拟浏览器？技术上一阶段，思想开阔眼界丰满，不能再等了。经过几个版本发布，自动化的框架平台与工具初有雏形，再次在鲜花与掌声之中，先不谈你是否已经迷醉，或者偏离你最自始之终所热爱的自动化技术，不知不觉之间，我们积累sense, tech 但更多的是scripts.
接下来，我们该怎么办？
1，需求的变动与对象元素变更，脚本是否第一时间能得以维护？
2, 自动化测试的业务覆盖，除了避免故障，我们还想要预防缺陷？
3，面向业务的自动化脚本的测试设计？
不言而喻，我们进入了应该排在第一阶段的第二阶段
二，认为业务很重要
投入是可以算它眇小，但收益不能不说它无所谓沉重？我们提出要找到业务专家，懂业务的人在哪里？
回头一看，少之又少？因为得不到价值认可，或者他们都不在做P事了，也有可能他们被自动化所淹没了。。。
无论如何，我们得找出一个业务专家，暂且称之吧，在一起看看，哪些测试场景适应自动化，于是进行业务的抽像，封装设计提高脚本复用，从而降低维护成本。
1，我们的脚本开发好后，使用频率大于5-7次以上么？
2，基于不同的web 开发框架，对像的源头是否统一属性？
3，我们需要整合业务的公共用例？
所有的问题，引入了第三阶段。。。
三，认为管理很重要
提到技术与业务，想到自动化测试的真正目标，如果你已经上升到这个阶段，所谓思想与眼界较之前或更有开阔。与之相适应的自动化准入标准，脚本开发规范，自动化运作的工作系统流程，自动化测试的度量体系提上案头，不得不说，此时还得有个管理者坚定的支持，才是走到如何产生较好“自动化测试体系”。
不想再提，自动化是好还是坏，给出一个答案的人终究应噎废食，唯有积沙成塔，坚定信念给出在一定时间与背景情形下最好的答案。曾经与微软自动化工程师聊过，当自动化成为习惯，大部分人会“麻木”接受。
因为我们可以让他看到，今天有多少开发check 多少行代码？ 有哪些代码经过测试？ 脚本自动化分发执行后多少用例是通过？ 以供决策，我们当前的项目计划是否合理，满足基线或里程碑的功能？最终我们可以承诺给客户。。。
没有放之四海而皆准的，唯有合理与有效，工具又何尝不是？就连到现在，也没有发现较大网站系统运行100次脚本，会有100%成功概率，现实与理想纵有差距。
庆幸自己在这不到三年内经过如此丰富的阶段！从而不在盲目，最简单的东西往往决定如此深远，回头一眸，测试基础不做好，如同空中楼阁，一垮即踏。
写给想做自动化的人，也许给测试管理中想做好自动化管理的人也有借鉴。自动化测试，UI自动化，接口/api等等与测试相关的自动化，不能再当快餐享用。
