为啥不直接在 5+ 手机上用 gfxinfo 呢?
#1 楼 @seveniruby 已经放好了。 在 wiki 里。但是不太好处理。 我们不允许外链,他就只能搬过来了。
这个作为合集的入口吧。
哥哥 我是说让你放在 wiki 里呀~
宣传和广告,请先联系管理员。
又一个把 context 和 window 搞混的。你的 webview context 里面有多个 web windows。 还得切换 windows 啊
保持自动化测试用例的有效性,基本就是一个投入大人力的过程。另外你觉得好的设计并不一定是别人眼中的好设计。业务快速增长之后,你的架构能否无缝的包容这些增长。
你所说的几点都不错。如果能把这些揉入到整个自动化测试架构中去,让写用例的人无感知的遵守你的约定,那就更好了。
发表意见的勇气不错,有小 @monkey 的感觉。
不能同意你的看法。对目前测试现象否定的太随意,而且标题也太大,博人眼球。而且也真的没有那么好混。
#16 楼 @seveniruby 这个比原来的 emoji 来的好看,twitter 的 emoji
Robot Framework is a generic test automation framework for acceptance testing and acceptance test-driven development (ATDD). It has easy-to-use tabular test data syntax and it utilizes the keyword-driven testing approach. Its testing capabilities can be extended by test libraries implemented either with Python or Java, and users can create new higher-level keywords from existing ones using the same syntax that is used for creating test cases.
把一个自动化框架比喻为一台运作的车子,编写测试用例(Robot Framework 里面编写测试用例估计比较容易或者轻松)的工程师是驾驶员,真正执行测试用例的 test libraries 是发动机,那么把驾驶员的意图传动到发动机的就是 Robot Framework,无论是认为他是解释层,胶水层,还是 xxx 都好,他的作用很明显,你要把握下方向盘,踩踩油门或者刹车,就能运作的很好了,当然记得遵守交规。
robotframework+appium
中的 Appium 就是一个发动机。其实你了解 robotframework 的话,你应该知道他有不同的发动机,比如 Webdriver,比如数据库连接,反正很多就是了。
接着轮到 Appium,Appium 本身可以成为一个自动化框架,也就是说他本身也是一台可以运作的车子(需要 xunit 的支持),你可以使用各种 bindings 来写测试脚本,然后通过 Webdriver protocol 和 Appium Server 交互, Appium Server 则驱动各种 driver 去干活。
所以本质上都是一样的,说什么框架,还不如不去理解框架,直接理解意图。
#7 楼 @canty https://testerhome.com/wiki 给你这边编辑的权限了。 你可以把文章搬过来。