测试是一个和开发同样重要的工作。好的测试人员起码应该熟悉自己的工作流。做软件测试的，熟悉自己测试的软件，熟悉常用的操作方法。做硬件测试的，熟悉硬件平台，会迅速搭建自己的测试系统，会迅速定位错误的来源。做通信测试的，熟悉各种协议，了解丢包的原理和协议的差异。测试一定需要开发经验吗？不一定，但是有很多“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都很容易失败，一点都不健壮。
　　于是在一个月黑风高的晚上，功能测试组的几个大牛在一起商量出一个解决解决方法。
分为Task和Wizard，并且规定若干规定：
　　1、杜绝Case里面HardCode控件的识别码，这些应该包含到Task里面。
　　2、杜绝Case直接使用Task，而应该用Wizard。
　　比如登陆的Wizard是输入用户名，输入密码，确认密码，输入验证码，点击登陆几步组成的；而其中每个小步骤都是Task。
　　3、凡事设计到关键字的必须使用资源文件的表达方法，不能硬编码，这是为了后来多国语言化。
　　4、每个Case尽可能小，不能一个Case进行多个验证。这是保证Case的粒度够小。
　　在经过功能自动化全员8个月的测试间歇的自动化后，又开发出一系列的自动化Case。
　　在总共6500个Case中，自动化的有70%，剩下的都是打印或者画图或者需要复杂的测试场景的。
　　可以说这个测试框架是成功的。减少了Regression的成本。也直接导致除小A意外的所有实习学生全部不要了，呵呵。
　　在这种情况下造成了2类问题：
　　1、高手只想写自动化而不愿意跑Case，造成测试框架脱节，写的方法不好用。
　　2、每天跑Case的人很郁闷。
　　经理安排人人都来自动化，用SVN把测试框架和测试的Case管理起来。
　　由于都是写的常用的路径，在产品稳定了之后，人们开始写那些不常用的路径。发现了很多非回归的缺陷.....
　　由于SM产品不想想象中那么卖座，开发的和测试都抽调一般人手去做新的项目FM(File Management)。
　　剩下的人维护SM继续发布行了。
性能测试组的同志们除了测试API之外，觉得大数据量情况下的SM也有问题。在和功能组的人商量后，把小A借调到系统测试组。
　　主要任务是把这套框架在大数据量的系统上跑起来取反应时间：
　　小A看了看需求：
　　自己实现了 在每次重要待测的操作前计时间，操作结束后记时间，然后把差写进自己的是时间日志的功能。
　　但是他忽然间发现，之前的框架有一个重要的缺陷，可以说是致命缺陷：
　　所有的等待全是写的硬编码，并且为了保证功能能够完成，都是额外等待很多秒。
　　而在小A 的要求里面，是精确得等完成。 比如登陆结束会出现一个大的树状列表。
　　之前的至少等待出现窗体算完成了，而在大数据量的情况下，后面的树的显示还得花很长的时间。
　　像开车，小A知道起点，但是人家Framework的终点确实靠死等20秒来的。
　　这样，要不时间不够直接失败要不是等不到。
　　小A得重写Framework的所有这种等待函数……
　　是活其实不难是烦，很多情况，开发的也没考虑到UI只是一个小图标没有了。
　　经过若干次，小A终于成功了。
　　每次操作跑100次，1次40多秒。取均值方差得稳定值，再在新的版本跑Regression……
　　小A把自己做的一起总结出来，也成了新人眼中的老鸟。也是开发认可的测试人员。