711 大会的时候貌似提过,直接发一条 adb 命令点击安装按钮那个坐标。
找天要试用下 Android Robot ,现在基本都在弄 iOS 端的东西了。。。
#1 楼 @gaopeng1106 每次都好快。。。不愧是秒赞之王啊!
最后一个已经用起来了,同事回头率接近百分百。不过震动必须关掉,否则晕死。。。
#39 楼 @zyl911_1012 因为收费。。。灵活一点的 assert 都需要用收费版,而且大部分它能做的 Jmeter 也能做吧。
#7 楼 @seveniruby 对,确实不一样。
Q 的 Keynote 风格很赞~话说 PPT 只有 2 个?
移动无线测试工程师必备技能
接口自动化测试实践的记录
第二篇给我帮助好大。
#4 楼 @seveniruby linux 最有前途,哈哈。
感谢,已 star
不是很明白你说的移动端和 PC 端是指所有在移动端/PC 端的带界面的软件还是什么。
因为个人觉得大部分移动端只是 PC 端的前台(类似 web 页面的前端),背后还是得有 PC 端的服务器存在。
如果是特指带界面的软件,那么我觉得 1-2 年内应该是移动端比较火热,因为现在用户大部分时间都花在手机而非电脑上。但前途这个说不准,像大数据、机器学习这类新热点基本都是在 PC 端的,毕竟要求有高性能的应用移动端还做不了。
#23 楼 @lihuazhang 已加入 wifi 首页。
#15 楼 @anikikun
#16 楼 @lylyliuyu 我只是小兵,最认真的还是 @huanzhijin ,他做的事情最多。
整体看了一遍,写的不错,有些坑有写出来了,不过有一小部分的翻译有问题。
Whether the element is visible to a user.
该元素是否是可见的用户
翻译错了,应该是此元素用户是否可见。简单地说就是隐藏元素和被控件挡住无法操作的元素(仅限 Selenium,appium 是否实现了类似功能不是太确定)这一项都会返回 False 70.execute_script
Synchronously Executes JavaScript in the current window/frame.
同步执行的JavaScript在当前窗口/框架
这个正确翻译应该是:在当前窗口/框架(特指 Html 的 iframe )同步执行 javascript 代码。你可以理解为如果这段代码是睡眠 5 秒,这五秒内主线程的 javascript 不会执行。
71.execute_async_script
execute_async_script(self, script, *args):
Asynchronously Executes JavaScript in the current window/frame.
异步执行JavaScript在当前窗口/框架。
和上一个类似,也是插入 javascript 代码,只是这个是异步的,也就是如果你的代码是睡眠 5 秒,那么你只是自己在睡,页面的其他 javascript 代码还是照常执行。
#10 楼 @lylyliuyu get attribute 这个可以参考我以前的一个帖子:https://testerhome.com/topics/2606,不过有点超出 API 文档的范畴了。
#29 楼 @4amla 首先澄清一点,我这个不是科普贴,是个人感悟贴。不敢说我的观点一定正确,只能说是我个人的个人感悟。
那我表达一下对你这几个问题的观点吧:
如果只验证返回值,是否代表着这个接口的功能完全 OK,或者接口测试不去管这个接口的具体功能实现?
首先,我这里关于接口测试的观点都基于一个前提:你有比较完备的功能测试。而且我是因为条件所限按照一个用例一个接口的规则只能检查到返回值,如果你有条件应该还要同时检查数据库内容,这样完整性好一些。
那,如果不管这个功能是否 OK(这个返回值研发也可以直接 return 一个正确值即可),那么这个功能就要在其他阶段再进行详细的测试?
我的其中一个用例就发现了这样的一个问题,A 用户无权删除 B 用户的帖子,但接口却返回操作成功(当然实际上还是没有成功删除的)。对于这样的情况,如果可以获取到数据库那就可以调用单个接口完成,因为数据是否成功修改可以直接通过数据库知道。如果不能,而是需要调用其他 API 才能知道,那更建议把这个部分放到功能测试里做,毕竟功能测试里这个基本是必测的。当然你也可以根据功能的优先级考虑专门为这个功能做个接口层面的校验,但这个更多的是补充,而非接口测试本身的目的。
如果这些便于测试的接口,由研发人员提供,我们是否需要检查接口的具体实现(貌似也要消耗一点时间),还是说就直接拿过来用就行了?
肯定不是直接拿来用。。。而且检查接口的具体实现也不现实,如果某一次研发错改了这个接口呢?我觉得有两种方式吧,一种是为这个接口也做一个用例,用于保证这个接口的返回值正确,另一种是直接通过数据库来计算得出这个数据。我这里说的艰难特指模拟用户操作来逐个翻页,导致翻页次数不确定,因此应该有更合适的办法保证一次性能翻到最后一页。
很开心我的分享能帮助到你,也欢迎你以后在接触接口测试,或者其他新的事物的时候把感悟分享出来。如果只是单纯感悟我发到自己博客给自己以后看就好,产生思维碰撞才是我把这个帖子发在 Testerhome 的目的。因为我有感觉,我目前的观点仍然不完全正确。
#4 楼 @huanzhijin 右下角铅笔图标。
angular 现在这么强大了!?
#2 楼 @huanzhijin 64. location_once_scrolled_into_view 这里 markdown 有问题
这个过程中为什么要有接口测试呢?主要是为了保证开发过程中能比较高频率得跑测试,最好做到服务端一提交代码接口测试就自动跑。同时接口测试也能在后续每次服务端更新代码的时候跑一遍,保证没有出什么重大问题。自动化本身的优势之一不就是能大幅度提高测试效率嘛。
至于你说业务稳定为啥要测接口,这个我的观点和 monkey 一样,为了回归。而且接口有个好处,定位问题简单,一出问题基本都是服务端的问题,而且肯定是和这个接口相关的代码,不用花时间再去抓包->分析(->撕逼)
https 的话建议你了解下 https 和 http 区别是什么吧,相信你了解后也就知道答案了。
#2 楼 @lihuazhang 这不是 iOS ?