一、十年企业技术变化之怪现状
技术的进步推动了社会的进步，提高了人们的生活水平，但同时也将我们进入企业的门槛抬高了，对我们从业人员的技术水平提出了更高的要求
十年前的今天，会写个Hello World就能找到一份开发的工作，会一丁点的测试的知识就能顺利进入企业做个愉快的测试工程师
十年后的今天，会写代码、会做自动化测试…成为了进入企业的基本要求
二、自动化测试的金字塔模型
金字塔模型反映出了：
越下层投入应当越多
越下层效率越高
越下层成本越低
越下层实现专业性要求越高
对于google产品，70%的投入为单元测试，20%为集成、接口测试，10% 为UI层的自动化测试
但，公司现状是：倒金字塔模型
金字塔可见：最有效的也是收益最大的是单元测试，而UI自动化收益最小
倒金字塔模型 - 自动化测试主要针对于用户界面，对于单元测试和集成测试用例的数量或者投资要少很多。UI层有大量的手工测试用例，自动化只占了很少一部分，这是目前大多数公司遇到的一个问题，因为系统的快速迭代导致开发时间被严重压缩，很多时候开发不愿意做单元测试甚至根本不做单元测试
适合多数公司的模型 - 橄榄型： 中间层的接口自动化最大，两端的UI和Unit测试适度实施
这种方式遇到的问题：
1、开发的单元测试做不到位或不愿意做（这是大多数公司开发所存在的问题）
2、接口测试所需的技术难点高于UI，技术人员挑战较大
3、手工测试人员的接口测试能力有限，接口自动化框架推广较难
三、UI自动化如何做？？？
在谈UI自动化如何做之前，先考虑一下自动化测试的几个缺点
ROI（投入产出比）低：
辛辛苦苦写好的测试用例，跑了还没几天，新的需求之后，开发把页面改了，原来定位的控件失效了，N条测试用例跑不通了。每条用例改完之后，UI又变了，又得改，很崩溃啊有木有？？？
问题来了，如何最大程度避免这种情况？？？
Ø 技巧 – 元素定位的技巧（元素定位技巧之Xpath定位）
维护成本高：
为了快速进行自动化，前期没有良好的规划就开始写大量的测试用例，有些测试用例甚至是通过录制回放的方式来创建的。维护测试用例编变成一项繁重的任务，比如一个页面元素细微的变化，就可能导致自动化工具没有识别UI控件，那么所有用到这个控件的测试用例都需要更新，查找替换并且保证没有替换错就是一个很大的工作量，更别说一般录制的脚本人工都不容易理解。再比如运行完测试用例之后，需要花费大量的时间排查错误，错误有脚本错误，有功能的变更，有bug等。逐个排查和解决需要耗费大量的人力
如何有效解决这类的问题？？？
Ø 完全抛弃录制回放
Ø 测试框架规划（框架的规划与搭建）
稳定性差 ：
某条测试用例本地调试的时候是通的，批量执行的时候就失败了
某条用例上次跑通了，怎么这次又失败了
web界面上明明有这个元素，怎么就找不到
深究这些问题的原因，无非有以下几个原因：（1）代码里用了sleep，但是不同网络环境下，页面加载时间不一样，批量执行的时候，加载时间比较长，sleep已经结束了，还没加载成功，就跑下一语句了。导致了用例失败。（2）通过图像识别来定位按钮等空间，不同的机器分辨率不一样，识别不出按钮控件了 针对这些难点，在动手进行UI自动化之前，需要考虑清楚两个问题：一是什么时候进行UI自动化测试，二是该怎么做自动化测试
问题来了，如何最大程度避免这种情况？？？
Ø 框架的引入（请关注框架封装部分文章）
Ø 封装通用的功能
如何做UI自动化：
是长期使用的项目
项目规模较大
有大量的UI重复操作
迭代较快
项目组有编程能力的人或团队
UI自动化由于先天的不足，如不克服和做详细的分析，最终只能以失败告终
敬请关注下篇 - UI自动化框架的引入与搭建
1803
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
