把他原来的代码重新补上呗 概率的问题估计还是等待那块没处理好,
最近版本变动太大, 我也没追踪代码变更, 我在等 1.0 正式版本发布.
mobile 的部分方法取消后, 改成了正规的 webdriver 方法, 你可以看看正规的方法有哪些.
另外第三方貌似也应该支持, 比如 ruby_lib 这种
没看懂话题, 通过反编译 uiautomatorviewer 代码 这个什么意思
服务器本森会开 2 个端口, 4723 和 4724, 麻烦的是 4724 必须和手机里面的 app 启动的端口保持一致, 所以估计还是需要代码. appium 估计也会考虑这个问题吧
高大上的文章, 没人回, 看来大家都被英文挡住了 包括我
appium 有自己的解锁 apk, 会自动调用解锁的. 锁屏就没用过了
请帖完整的 log.感觉跟 appium 无关
#4 楼 @noshuai 用不起 mac, 哈哈, 让 mac 高手来回答吧. @lihuazhang
#15 楼 @lp19851119 我最近还没来得及看, 按理说不应该用全名的. 使用缩减名本来就是优势, 感觉不会倒退的
这个只是普通的编程问题, 跟测试关系不大, 建议你使用标准的方法去解决. 比如统一存储到某个 hash 结构中, 然后最后存入文件, 这样反序列化也很容易.
你太直接了, 直接上代码的节奏...
你这个话题虽然简单 但是回答范围也挺大.
解决问题之前你得先自己去审视下问题, 先明确自己的问题在哪里.
比如你先梳理下产品的问题, 客户反馈的, 测试发现的, 线上故障, 其他团队期望等, 做一个分类梳理. 先找自己产品缺陷的来源, 有了来源就知道如何封堵了.
接下来就是把问题交给对应的测试手段去保证了.
有的适合手工测试来防范,
有些适合自动化来防范
有些适合单测, 或者通过 code review 来解决.
产品发布慢就通过持续集成来解决.
体验问题就需要使用监控手段
重构多就多使用 diff 测试
等等吧...
在这些对应的工作上, 就需要对应的人才和技能储备.
做 ios 测试需要你多了解 ios 系统自身, ios 的驱动框架, 以及在此基础上封装的 uiautomation 和 kif, appium 等技术体系.
你们肯定也得自己了解 ios 的产品研发体系, 对原生或者混合型的 app 的一些开发知识. 了解研发的流程.
因为不了解更细节的问题, 我先提些肤浅的建议, 当抛砖引玉吧
我看你在 google group 也提了问题 有结果了吗
这个框架限制了语言和框架, 虽然很好, 但是普及有难度
#1 楼 @lihuazhang 别吝啬, 呵呵, 写的很好啦.
@noshuai 赞, 期待更深入的分享
自己代码的问题, 自己调试下吧