标题借用《web之困》这本书名，借机吐槽一下在web自动化测试中遇到的各种不顺畅。看了这本书，大感欣慰，因为终于有专家说出了我多年想说而不好意思说的话——现在的web应用就是建立在一堆胡乱拼凑的技术基础之上的。
从底层协议级就定义不周到渲染技术的五花八门；从古老的html、css、java applet、ActiveX到javascript、flash、sliverlight、html5；从浏览器的各显神通到眼花缭乱的版本升级；从静态到动态；从即时到异步，真是一个百家争鸣、百花齐放啊。虽说给普通用户带来了赏心悦目的享受，可真苦了我们这些测试工程师了。手工做浏览器兼容性测试都不是一般的麻烦，更别提自动化了。十几年前我每样技术都尝试去学习，后来发现我学的速度还赶不上技术新出的速度，于是我厌倦了，从此对web前端技术及其排斥。我幻想着某一天前端技术可以统一得象操作系统那样规矩和稳定。不过看来一时半会还实现不了，所以厌倦归厌倦，活还是要干的，所以几年来我也在考虑这是非做不可的。于是前一篇提到的vs2010就是一个尝试。当时考虑操作系统是ms家的、浏览器是ms家的、自动化工具是ms家的甚至C#语言也是ms家的，要是这样还不顺利，恐怕别的工具更别指望了。事实上，我还是低估了事情的复杂性。
录制/回放遇到的麻烦随便列举一下就有这些：
只支持ie，且不能使用64位版本
视图缩放比例要求必须为100%
不能识别flash插件
各种意外（如窗口没有在最前端、没有最大化等、控件被阻止运行……）导致回放中断
建立自动化任务时不能在后台运行（因为要在桌面环境真实启动浏览器），所以管理员必须登录。这样一来，服务器一旦重启就无法做到无人值守的继续运行
……
诸如此类，总之想顺利走通一段自动化脚本可费劲了，经常是烦不胜烦
为此我还总结出一堆录制脚本的经验，比如：
把场景分割成每段尽量少操作的多个脚本文件
尽量用键盘操作，少用鼠标操作
屏幕上尽量少留无关窗口
对于浏览器，尽量在同一个页签中操作，尽量避免弹出窗口造成主流程被干扰
动作、脚本之间留的延时要足够，比如连续执行两条sql，就有可能第二条执行出错
……
但真要把这些问题都注意到了，费的心还不如手工来一遍算了。再说费这么大事只是为了回归验证以前的功能，确实有点得不偿失。所以过后反思起来有这样一些教训：
1.目标定位有偏差。借鉴自Apple Chow观点：只保留少数几个用来验证端到端的集成场景的高级别冒烟测试，除此之外尽可能编写底层的测试。
2.工具不给力。当然如果有google的水平，自行探索和开发各式各样的测试工具和框架那自然是厉害了，但是没这水平啊，还是只能找现有的工具用。
后续准备尝试selenium。说到这里，就想起有的团队成员提出经常换工具的困扰。——这个问题应该这样看：使用工具是为了解决问题，是人的思想和能力去驾驭工具而不能让工具限制了人的思想和能力。所以要去掌握事物的本质，那么换工具也会是经常和顺理成章的事情。
