信息太少,帮不了你。。。
只能看出不通过原因可能是某些控件位置变了,导致原有的定位逻辑无法定位到对应的控件。但为何变了,变成了什么,如何修复,这个没相关信息没法给建议,你可以自己 dump 一下控件树对比看看。
前面歪楼了。。。我来回答下楼主留的问题吧。
首先,不要觉得学 java 是从零学另一门语言,编程语言除开各个语言的一些设计理念外,核心逻辑不外乎就是那几个,而且 python 和 java 都是面向对象的,两者很多地方都比较接近,能看懂 python 不至于看不懂 java。
然后,从提高开发的问题解决效率来说,并不见得还得把解决方案都给到才能提高,能找到并给出相关的关键错误日志(如异常堆栈)已经帮助非常大了。进一步的可以拿开发代码本地跑起来后,给错误日志所在代码行加断点,便于看到此时各个变量的信息,排查为何报错。
最后,如果真的是要掌握到知道怎么修 bug 的程度,那得知道怎么写代码。那可以找开发拿到项目代码后,仿照开发的形式基于这个项目自己去加一个对某个库表的增删改查接口,从 controller 写到 service 再到 dao,三层结构都写一遍并调通(过程中你会学到项目用到的框架最常用用法,特别是各个注解的用法和含义,这个对于读懂代码非常重要)。做完后相信你就可以掌握了。
有两个概念建议理清一下:
1、native、webview 属于 context(上下文)领域的概念。主要对应 appium 的底层调用工具切换。如 android 上,native 底层用 uiautomator,webview 底层用 chromedriver 。由于一个 app 是可以有多个 webview 的,所以这个名字后面会有一个不固定的后缀,方便进行唯一标识。
2、基于上面这个概念,我不能针对首页 H5 这个 ‘WEBVIEW_’ 写一个专门的 page 类
这个本身就不大对,page 类应该是针对 webview 里面某个具体 h5 页面(一个 url 对应一个 h5 页面)去编写,而非针对一个 webview 去编写。
我觉得很合理。要保证自测质量,自测用例很重要。一个功能背后一般会拆分好几个模块,开发很清楚自己模块,但不见得清楚完整功能。如果他自己设计,大多都会只是测试自己的模块,而且也比较随意,甚至用例都没有。
提供自测用例,可以让开发减少自测的思考成本,满足开发的诉求,同时也能保障开发自测不跑偏,提高提测通过率,满足测试的诉求,性价比挺高的呀。
可以分享下你们这个系统的开发成本大概多少不?
先表达一个个人观点:OCR、NLP 个人觉得严格意义上不属于 AI ,我更偏向 AI=机器学习,而非 AI=算法 。
然后,针对你这个维护成本问题,想先问几个点:
1、经常在调研题型里面,会有改动,导致元素定位不准确
,这个改动是怎样的改动?非自动化的人工用例,对这些改动是怎么适配的?
2、你想核心解决的点,是元素变动后脚本可以做到无需人工维护自适应,还是从人工用例直接转换生成脚本?这两个点技术关注点是不一样的,前者关注的是元素识别的容错性,后者关注的是自然语言的语义识别。我看你前言是第一个,正文变成了第二个,没太看懂你的核心关注点是啥。
个人对于这种基于 NLP 生成脚本的,不是太感冒,核心原因是日常接触中,人工用例会写得非常详细,详细到达到 “是个人都能执行” 的并不多,大部分实际操作步骤都需要自行脑补或者问人。连人都无法准确判断的,NLP 就更难了。而且写得很详细的用例编写成本并不低(参考 BDD 写法的用例,详细到每个具体操作步骤了,但编写成本也高了很多),从投入产出比角度并不划算。
在 ios 系统限制下,除了 appstore 以及企业证书签名包(现在已经很难买到企业证书了),没有包是可以安装到任意手机的,都需要先把手机信息登记到开发者证书,然后用这个证书给安装包进行签名,认证这个包在这个手机上跑,是经过开发者和手机拥有者确认的。
由于这个机制的存在,意味着你就算找到了一个已经编译好的 wda 安装包(网上确实有这样的,有的开源项目自带的单测里有记录这个包,比如这个地方),也必须重签名才能安装到你的手机上,否则会在安装时由于 ios 系统限制直接不允许安装。至于重签名是否有 windows 版工具可用,我暂时没有见到。
另外:
1、windows 安装 ipa 到手机上,tidevice 也支持,tidevice install xx.ipa
就可以。如果不清楚 tidevice 的可以百度一下。
2、wda 不需要每次使用都编译的,使用的时候用 tidevice 启动手机里装好的 wda 就可以了,只有首次安装的时候,如果没有编译过需要编译。如果你手上有已经签名好的 wda ipa 包,也是可以直接不编译直接安装的。
PS:我们现在能享受到的非 mac 可以安装/启动应用的福利,背后其实都是逆向 xcode 相关通讯协议,然后换种能多平台运行的语言重写,让 ios 系统觉得这个就是 xcode 得到的产物。重签名这个涉及到安全(签名本身就是为了保障应用的可靠性,重写后你想加啥料都可以,带来的影响甚至可能比XcodeGhost要大),可能没那么容易被逆向,而且这个很有可能会把开发者带上法庭甚至监狱,所以估计也没人会公开出来吧。
刚试了下,貌似是用不了。之前这个功能基本没用过,一直没发现这个问题。。。
你先 github 记录个 issue ?这周事情比较多,估计得下周才有空研究。
临时用的话,可以找开发帮你装一个,你后面就可以用了。
但如果要深入,还是建议你想办法搞个苹果系统,黑苹果也可以。ios 自动化深入点的话,还是离不开 xcode 。
刚看了下,默认数据的问题。默认数据没有 id,而搜索要求用到节点 id。
刚修复了,你更新下代码重新跑应该就没问题。正式项目里添加节点后,id 是自动生成的,所以也不会有问题。
这个你得通过 logcat 找到这个应用启动失败的具体报错信息,然后再针对性解决。没有通用解决方法。
这个是机器翻译的么?有些文字读起来好怪异,比如
JCov 是一个测试框架不可知代码覆盖工具
以及
它是 JUnit 的 Python 端口
和 android sdk 无关,是一个 appium 自带的应用启动失败。一般和系统兼容性有关。
可以先换台机器试试,还是不行的话,把各个工具的版本号和完整的日志(不要只是报错那一小段,发完整的)发一下吧。
如果是单纯获取网站所有接口列表,简单接入 swagger 就可以获取到。但这个没啥意义,因为不是所有接口都是直接可以成功调用的,必须参数符合内部逻辑要求才行。
一般单个接口测性能测试,除了调用接口,还要提前构造数据、确认参数组合等,不是能调用就能压测的。你这个 “感觉” 有点太理想化了,可以先再仔细分析下吧。
这个地址打不开呀。。。
大家还是分享学习成果吧,我理解楼主初衷也是想大家分享知识,不是分享网址。。。
从方式上,可能线上流量录制回放比较接近你的需要,里面参数基本都是真实有效的,而且只要日活不低,覆盖率也不会太差。实际上大会上也有见过讲流量回放的时候,提到其中一个扩展使用场景是压测的。
但没明白做个性能测试,为啥要遍历全部接口?
理解。
提个小建议,这么简短的文字估计没法让这类不合适的候选人有产生要改变的感受,而且也容易引起歧义(比如走向另一个极端,不去听任何分享)。建议写个详细点的文章来说吧。
好奇为啥会突然有这样的感慨呢?
你现在看的是商城类的,业务和测试领域差异比较大,你比较需要补的应该是业务领域知识,直白点说就是测试工具的设计思路。
可以想想现在测试工作有什么需要帮助的,比如哪些地方效率低,是否需要做一些测试工具平台辅助。典型的像接口测试平台这种。
PS:如果你出发点是帮助测试工作,建议先想有什么需要帮助的,大概要用到什么技术,再去学习技术。先学习技术,容易陷入手里有个锤子,什么问题都想用锤子解决的倾向。
开发不适合我。。。以前在学校有做过开发类的活,明确了自己兴趣不在这块。
楼上说的非常清晰了,我只补充一个小点:文档积累也会有过时的问题,可以推荐每一个新人在看完文档实践完后,多吐槽甚至直接可以动手去优化文档(担心会改乱的可以弄一些简单的审核机制,改完后导师确认下改动点没问题再发布)。
新人才最知道新人需要什么,所以新人文档,新人参与会很好避免文档发挥不了作用的问题。
哈哈,不错。
保持自己习惯就好,个人喜欢辩证地看东西多一点,所以不大喜欢太绝对的东西。不过观点无对错,期待你后面对楼上说的基于 k8s 支持做流量回放的成功案例分享。
前辈客气了,我还有很多需要学习的,称不上大佬。
这。。。那就转给硬件测试工程师好了。
可以找你 leader 反馈下这个问题,也一起探讨下有什么方法可以优化。