不得不说--自动化测试元素定位与用例设计
关于自动化测试，经常被问到元素的定位 与 如何设计用例。 很多时间我也帮不了你解决实际的问题，只能从个人脚本谈谈如何看待这些问题。
不得不说之元素定位
虽然，本章写了十几篇文章来讲元素的定位与操作，对于碰到的一些常见功能，如何通过技巧来定位它们，但是在实际的自动化脚本开发中，不管是新手还是具有一定经验的老手，我们面临最多的问题仍然是元素的定位问题。
有时间元素定位非常简单，例如，我们只要知道这个元素有的id和name 就可以轻松的来定位到它；有时间元素的定位却非常的令人非常头疼，尽管我们用尽了所以办法，仍然无法定位到它。在这里笔者也没万能的方法来帮你解决这些实际问题。
评估自动化可行性
对于不同的web项目，所用到的前端技术也不同，有些项目会用到EXT（一个强在的js类库），有些会用到AJAX（一种创建交互式网页应用的网页开发技术），这些技术的应用无疑对于前端开发人员可以快速的生成所需要的页面，但对于UI自动化测试人员来说，增加了定位页面元素的难度。
所以，在进行项目实现UI自动化评估的时候，页面元素的定位难度也是一个评估标准，如果处处都是很难定位的元素，那么无疑会增加脚本的开发与维护的成本，得不偿失。这个时候我可以考虑将更新多的精力放在单元或接口层的自动化上。
提高技术能力
对于自动化测试人员来说，如果熟悉前端技术也会大在降低你定位难度，熟练使用XPath和CSS技术会使你的定位变得容易很多，如果精通javascript、jquery 等技术，那么使你的定位之路变得更加随心所欲。
规范前端开发
在我们尝试实施的web项目中，大多数在设计初期，前端并没考虑到需要UI层的自动化，所以，有些前端开发人员以实现功能为目的，前端页面的代码相当不规范。这个也是自动化测试定位难的重要原因。如果开发人员在设计代码的时候规范的为元素加上id 和name属性的话，那我们的定们将会变得容易很多。
很多测试人员在对项目进行学习和实施自动化测试的过程总是觉得困难重重，就是因为这些普遍的客观原因所造成的。一方面，我们要努力学好技术，克服这些困难。另一方面，我们要清楚的认识到，自动化技术的应用与实践不是一个人的战斗。一定要得到整个团队的配合与支持。
当然，站在公司的立场，不能带来收益的事情是很难得到支持的，这个就需要读者去综合评估目前的产品真的适合引入自动化么？或者目前的阶段真的迫切需要自动化么？
不得不说之用例设计
自动化测试用例如何设计，对于新手来说也是比较难理解的问题。
不少新手刚刚掌握了写脚本的能力，一上来就拿着功能测试用例一条一条的转化成自动化用例。在写的过程中，会发现诸多问题，例如，脚本中重复代码很多，一个脚本的执行结果影响到另一个脚本的执行，有些功能用例很难转化成自动化用例等。
站在用户角度设计自动化
在功能测试的时候我们一般会遵循这个原因，但是自动化测试往往可以实现更强大的功能，所以，我们在设计脚本的时候很容易违背这个原则。例如，你要获得的数据是用户不可见的，你要判断用例是否成功的信息也是用户不可见的，或者你要模拟的是用户永远不可能做的操作等。
设计简单傻瓜的用例
自动化脚本本来是很傻瓜的。记得有同学问我，百度输入有个自动联想功能，就是在用户输入的过程中自动配置热门搜索的关键词，例如，用户输入“自”，会自动联想“自我评价”，“自行车”等。用继续输入“自动”，会自动联想“自动化”，“自动关机”，“自动档”等。他想定位自动联想下拉列表的某个关键词，这个关键词是百度根据用户搜索热度的变化而变化的。
再比例有同学问我，下拉列表功能，我想脚本执行时随机选择某一个选项，那么如何如何去判断随机的结果呢？换句话说，你都不知道你做了什么，怎么去判断做的结果对不对？
所以，我们在设计用例时尽量考虑简单傻瓜的用例，操作步骤简单，预期结果容易判断等。
从简单开始
对于新需要自动化的项目来说，自动化测试的实施是循序渐进的，不要一上来就设计几百条用例，而是逐步的将功能用例转成自动化用例，在转的过程中需要不断的调整测试结构。然后，再增加稳定的测试用例。然后，再调整测试结构。随着功能的增加你的自动化测试框架也在逐渐稳定，基础测试用例也在增加。一上来就几百条用例，需求的稍微变化，用例就可能大调整，那么你很可能每天疲惫于用例的维护。
所以，在开始自动化的时候，你可以只对登录功能写个十来条的自动化用例。从而，渐渐的考虑将更多功能自动化起来。
半自动化对于测试人员是个不错的开始，这样你可以将更多的精力花在安全测试，探索性测试，甚至是用例体验上等。不要觉得全职自动化就是多么高大上的职位。