也说自动化测试

　　我所经历的不同公司的产品按顺序大概进行过如下的自动化测试探索：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%左右，从实际体验来看制约自动化测试无法大规模开展的原因是项目迭代快，界面需求变更快等。
　　现在大部分项目在开发时框架已经定好界面逻辑分离的了，开发人员在更新产品时大部分情况都是改界面换控件，如果修改下层接口时一般也会兼容旧接口，不会不向下兼容的，所以我认为在资源有限的情况下做自动化测试要有所取舍，建议先集中精力做好接口自动化测试和函数自动化测试，界面自动化测试可以在项目稳定后针对那些预期很少变化的对象实施，这也涉及到一个自动化测试介入项目的时机问题，对于接口自动化测试也不是在接口定义一开始就需要进行的，因为开发联调或者经过实践后可能会对接口进行较大的调整，从我看到的项目实践证明，太早介入带来的成本往往比收益更大，如果最后发现大部分用例都不可用那它对测试人员的积极性打击也比较大，所以建议是在和开发确认联调通过后再开始进行接口测试代码编写。界面自动化测试的时机则更要靠后许多，在控件等确定后可以进行一些控件库定义之类，在产品快发布时再对指定对象进行测试用例编写就可以了，主要用于后期产品的稳定性测试和回归测试，尽管如此，从我的经验看界面自动化发现的问题往往不是问题，而是因为环境原因、需求变动等导致的，所以我并不推荐花太多时间在界面自动化上。
      最后说说我对自动化测试发展的看法，大部分公司从一开始甚至到现在都是把自动化测试作为平台来设立的，做完一个项目就可以离开去做第二个，这样的好处是，可以方便调度资源，以免有的人闲有的人忙之类。但是，我觉得qa和scm、ops毕竟差别很大，它和产品挂钩更深，大家是否想过，为什么开发人员不作为平台而是长期分到各个产品中？如果测试技术是通用的，那么开发技术也是通用的，所以开发完全也可以作为平台，对吧？显然现在的公司都低估了测试人员适应一个产品的难度了，所以我认为自动化测试也应该和开发一样，跟项目，而非平台，尤其是自动化测试需要持续代码集成和维护，如果作为平台的话，它的用例及时性和对项目的效率贡献肯定不会很高，有的公司，比如多玩，慢慢就把自动化测试放到项目中去，和开发一样，简单地说就是“跟产品”了。跟产品和跟平台，这两者的确各有好坏，如果将来测试和开发两职业只是侧重点不同和技术要求的界限越来越模糊的话，那么我认为自动化测试应该和开发一样，无论是岗位安排还是薪资待遇。