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