标签：
我所经历的项目按顺序大概进行过如下的自动化测试探索：1、C++函数自动化测试；2、GUI程序界面自动化测试；3、openresty接口自动化测试；4、web界面自动化测试；5、php接口自动化测试。
C++函数自动化测试等于白盒测试，通过把重要函数导出，从外面引用这些函数进行参数化测试和结果校验，测试逻辑走到每个函数内部，比如测试每个循环每个判断语句等，它的缺点也比较明显，因为基本每行代码都要手写，修改测试用例也是改代码，比较麻烦，所以只能做重点核心函数，例如驱动和驱动的环3接口层的函数测试，这些函数在产品形成之初就很少更改，无法覆盖整个产品。这个当时并没有用到现代的测试框架，可以理解为自己写的测试框架，纯C++实现。
GUI程序界面自动化测试，我经历的项目中有些是用C#进行界面自动化的，因为对象是运行在windows的，有的使用python，核心也是调用C++的函数来进行界面点击测试，它的好处是模拟了用户真实操作软件时的动作，运行之后的效果看起来很cool。缺点之一是受环境影响较大，机器快慢对测试结果影响较大，经常要调试很久，同样的代码换一台机器不一定跑得通；缺点之二是受制产品界面，如果界面出现较大变动，需要调整的测试代码也很多。
openresty接口自动化测试，使用python的unitest对各个location进行测试，模拟各种参数后校验接口执行结果，目前看来比较顺利。
web界面自动化测试，使用selenium为主，具体我没有参与，但是它的缺点也是比较明显的，对控件依赖很大，如果界面有变动，需要修改的地方也不少。
php接口自动化测试，使用python的unitest对各个php接口进行测试，目前看来比较顺利。
自动化测试肯定可以节约很大的人力资源，不过它在国内互联网公司的实际实施并不是非常普遍，前几天在某个交流网站看到一个同行问实际工作中自动化测试的比例，大家的回答大多是占30%左右，从实际体验来看制约自动化测试无法大规模开展的原因是项目迭代快，界面需求变更快等。
我认为在资源有限的情况下做自动化测试要有所取舍，建议先集中精力做好接口自动化测试和函数自动化测试，界面自动化测试可以在项目稳定后针对那些预期很少变化的对象实施，这也涉及到一个自动化测试介入项目的时机问题，对于接口自动化测试也不是在接口定义一开始就需要进行的，因为开发联调或者经过实践后可能会对接口进行较大的调整，所以建议是在和开发确认联调通过后再开始进行接口测试代码编写。界面自动化测试的时机则更要靠后许多，在控件等确定后可以进行一些控件库定义之类，在产品快发布时再对指定对象进行测试用例编写就可以了，主要用于后期产品的稳定性测试和回归测试。从我看到的项目实践证明，太早介入带来的成本往往比收益更大，如果最后发现大部分用例都不可用那它对测试人员的积极性打击也比较大。
标签：
原文地址：http://www.cnblogs.com/idbeta/p/5035583.html
