新人请阅读:https://testerhome.com/topics/982
学会如何合理提问,请阅读:https://testerhome.com/topics/587
markdown 排版规范在回帖框右下角的排版说明里面有。
试过重启大法不?
#3 楼 @seveniruby appium 控制 webview 走的是 chromedriver ,这个时候 appium 只是个中继转发。
微信兼容了 inspector ,但有没有兼容 chromedriver 还是个未知数。
其实你的路线还是很不错的呀。像老徐说的,只要能解决问题,自动化就是成功的。
你提到的点确实都是优化点,但其实也是要看具体的项目情况决定的。一般前期需要先出效果,这些点都不一定会顾上,然后后期逐步优化,这些点再一点一点补充上去。等到后续有足够经验和代码沉淀后,前期就可以在开发效率能满足需要的前提下加上这些点。
有些时候也不要顾虑太多。太想面面俱到会导致过度设计,在合适的时候做合适的事情就好。
#1 楼 @Lihuazhang 官方有两种方式,一种是 weinre,iOS 和 Android 通用,但要授权。另一种就是文中的,只能用于 Android,应该是 x5 内核兼容了 chrome inspector。
#2 楼 @anonymous 等到我写年终总结的时候再一起说吧。我现在其实也是在做新的探索,还没探索出个所以然。
用 which appium
确认下你命令行用的 appium 是不是 dmg 里面的?
写得不错,但有几个点遗漏了:
get 的:
post 的:
HttpClientPostMethodWithJson
。最后,强烈建议使用类似 okhttpclient 之类的更高层次的封装框架代替直接用 httpclient ,省很多代码,可读性也会强不少。
最终不是成功启动了吗?那是个 warning 吧?
写得挺多,尤其是测试后的反思,可能也是不少人会遗漏的。
不过,文中有些观点不大认同:
如果只是对于只上线一次的项目,或是上线后项目基本不会改动,又或时间不允许的情况下,个人觉得就没必要写用例了。
个人不是很赞同。测试用例是审视自己测试活动的一个很重要的依据,对于避免遗漏作用很大。如果时间有限可以简化,但不写有点说不过去。
PS:这种贴没太大必要匿名吧。。。
.app 是个文件夹来的。你用 shell 的 file 命令检查下就知道了。
Finder 遇到这种文件夹默认会显示为文件,右键-显示包内容就能看到里面的文件了
#2 楼 @seveniruby 要定一个标准,到底咱们的 md 跟着哪个规范走。。。
gitlab 也是回车不等价于 md 的换行的。
#11 楼 @kelequy 我们之前强推过一次,用于做无界面的服务端接口测试。feature 由业务测试写,代码由测试开发写。当时遇到的几个主要问题是 story 的风格不统一(不同人写的风格不一样,会增大后续测试开发编写代码的沟通成本和维护成本)、粘合代码编写成本较高(如果不用确保和 feature 对应,写起来能更快更爽)、维护比较麻烦(一旦有更改,feature 和代码都要调整,偶尔也会出现 feature 不用改,但代码要调整的情况)。
总的来说,当时活文档这个特性的带来的好处没太大感觉(测试报告中更直观地看出具体是哪个步骤出错?),但由于这个特性带来的编写速度慢、维护困难的问题倒是深有体会。
建议先去看下 appium 官方 sample 里面切换 context 相关的代码。你现在的用法是 selenium 的用法,和 appium 的有一些出入。
#6 楼 @junewang 目前能想到的你这边基本都汇总了。iOS 的 stf 现在也搞出了个类似 minicap 的工具,你可以了解下:
https://testerhome.com/topics/6470
另外,既然是比较汇总,能否做一下各个方式的性能评测,比较各种方式的截图速度、兼容性?这样能更方便以后大家根据需要选择更合适的方案。