测试是一个和开发同样重要的工作。好的测试人员最起码应该熟悉自己的工作流。

　　做软件测试的，熟悉自己测试的软件，熟悉常用的操作方法。

　　做硬件测试的，熟悉硬件平台，会迅速搭建自己的测试系统，会迅速定位错误的来源。

　　做通信测试的，熟悉各种协议，了解丢包的原理和协议的差异。

　　测试一定需要开发经验吗？不一定，但是有很多“Nice to hava”的技能，开发就是其中一个不可缺少的技能。

　　自动化测试就是其中一个很重要的组成部分。最起码的一点，是减少Regression的Effort。

　　很多同仁都是做过自动化的。有测试API的自动化，有测试GUI的自动化。

　　今天我就想说说GUI自动化测试：

　　这个东西有点老生常谈。有很多GUI自动化测试框架。

　　我的这个也不是最好的，但是确实是工作正常的。我见证了这个测试框架的兴起到衰落。

　　还是以故事的方式进行吧：

　　某产品SM（Software Management）是一个欣欣向荣的产品，是某小公司的主打产品。经理召集精兵强将，准备了开发10人，白盒5人，功能测试12人，性能测试4人。打算大张旗鼓的好好整一整这个产品。

　　小A作为实习生很高兴能进去该产品的功能测试组，做手工测试和自动化测试。

　　产品的初期大家一起讨论每个新出的窗体和页面，讨论最常用的手工测试方案。主要测试边界值和不合理的输入。

　　这样经过了半年生成了大概3000个手工测试的Case。

　　慢慢的，大家发现完全跑一遍太费时间了。

　　于是大家嚷嚷着要去做自动化。

　　由于大家都是才工作的对C++和MFC以及VB比较熟悉，大家都建议使用了Robot。

　　工具上手很容易，大家都录制一遍然后就算把这3000个Case给自动化1500个了。

　　可是功能测试的组长发现，很多Case都很容易失败，一点都不健壮。

　　于是在一个月黑风高的晚上，功能测试组的几个大牛在一起商量出一个解决解决方法。

　　由高手利用自己开发的经验写出最常用的各种控件的操作（不够的再继续补充）。