#17 楼 @wkx101 技术和工具都是用来解决问题的. 做工具之前就已经想清楚了. 当时提出了设想. 组内的领导和同事也都赞成. 所以我就开始动手做了, 然后就越做越多.
加了一堆的功能. 也是刚刚开始使用没多久. 当时的背景如下

面临的问题

• 新版本升级后, 某些 UI 的界面 feature 会略有改变. 比如新版本少了一个文字项, 不细心很难发现
• 不在变更范围内的功能也容易被影响. 比如更改了代码导致老的功能 crash 或者发生变化. 但是我们又不能全部回归
• monkey 的控制力度较弱, 虽然借助 monkeyrunner 实现了自动登录, 但是有时候也会在乱点中给线上带来未知的效果, 比如给其他的用户发消息等干扰用户行为的事情.
• 各大云测服务中的遍历层次很浅. 时长不够限制也大
• 比如某个列表每一行的逻辑都差不多, 只是数据不同. 重复点击意义也不大
• 希望是遍历, 更希望是可控的遍历. 从而节省时间. 更快的遍历到想要的功能
• 在触发 app 动作的时候经常需要抓取接口数据. 自动遍历如果可以结合接口数据的抓取. 就可以方便 qa 更快的了解产品的功能和逻辑

解决方法

问题有了方法就来了

• 结构 Diff. 每个界面的结构其实也是数据化的. 跟接口测试一样. 这样就会 diff 带来了可能
• 抓取接口数据. 结合代理工具即可. 或者借助其他的 xposed 框架.
• 自动遍历有了, 有些功能需要登录等特殊操作. 所以需要指出自动输入.

目前的进展

自动输入被我关闭了.这个特性有点危险. 只支持自定义规则输入.
结构 Diff 和接口拦截还未实现完
自动遍历, 指出 android 和 ios, 真机和模拟器, 已经做到了. 可以生成截图和思维导图.
自动识别不同屏幕尺寸的兼容性问题也能做到, 只是还需要时间.
目前我自己也没太多精力做这个. 这次发出来只是先告一里程碑. 给感兴趣的同学做个参考. 我也趟了很多坑, 算是给大家一个经验吧.

#12 楼 @kilmer 有些界面需要用户登录, 不登陆遍历不到的. 所以一定要支持自动引导输入

#8 楼 @testor windows 下如何运行我没测试. 得你们自己探索了

#4 楼 @tcat 没什么关联吧. 支持自动输入引导.

#5 楼 @quqing 还没完成这两个 feature. 设计思路是结构对比和代理拦截.

#6 楼 @kilmer 遍历的逻辑应该跟层次无关吧.

#1 楼 @hysocnhou 这个赞

我等 appium 支持这个驱动 最近看 appium 把很多支持的测试框架都单独剥离出了驱动. appium 正在改进架构, 这样可以轻松融合其他的框架. 目前 EarlGrey 的优点就好像是 espresso vs robotium 的优点. 还不是特别明显. 期待有人改造为更简单的 DSL

#5 楼 @lihuazhang @chenhengjie123 这么压榨恒姐...

#4 楼 @sanlengjingvv 很明显不存在. 错误提示的就是这儿的问题

#6 楼 @kasi 其实是中级水平. 还可以. 这是乐视的子公司吗

#4 楼 @chenhengjie123 主要是 merge 错了, 没有任何东西可以探测. 容易留隐患

#4 楼 @quqing 这个可以, 没问题的. Har 只是个简单的 json 格式, 你自己做一套也可以的. 没必要纠结. 不过 Har 的好处是代理工具都可以跟他互相转换. 如果你自己做了, 可能需要自己编写代理工具才能实现 Har 和其他工具的数据导入导出了.

强大. 我最怕 merge 了. 尤其是大段的代码. 简直是梦魇.
最近 ruby-china 的代码貌似有问题, 合并得谨慎. 我看华顺还在不断的改进.

#2 楼 @quqing 接口的正确性需要多方评估. 但是实际中这样的成本较大, 经验丰富的测试工程师只需要 review 下接口的交互即可. 分析 Har 的调用关系, 跟分析代码的调用关系类似. 都是一种 review 机制. 通过这个即可保证. 常常是在测试过程中, 所有人都觉得没问题, 而测试工程师通过抓取接口就能分析出一些潜在的隐患. 这个过程中懂接口正确性的其实只有研发和测试, 产品帮不上忙的.

开发的代码有 bug 会发生发错 不发 多发 解析错等各种情况. 无论有无 bug, 我都会分析整个流程是不是出现了非合理现象, 进行评估.
也就是一个 feature 的交互流程里从输入触发开始, 到接口发出, 数据收回, 本地处理, UI 渲染等整个流程都会被审核.

以至于现在我们组就算不做接口测试, 也会习惯的挂上拦截代理去分析整个交互流程. 确保每个环节都是对的.

code review 本质是 review 了代码的流程和规范. Har 代表的是接口的流程. 所以理论上讲, 这块应该也有个接口流程的 review. 文档不靠谱, 规范也不靠谱. 就算他们都正确最后落地的实际还是可能有 bug 的代码. 在度量这个流程的正确性中, 貌似也只有 Har 完整保存了整个接口交互的证据.
Har 只是 http 协议的典型代表, 任何印证接口流程的数据皆可代表, 比如 api 中的 send receive log. controller 和 servlet 的调用链记录, 代理工具, har, fiddler 导出的 curl 命令序列等.

我也好奇的是, 为什么行业里面对 Har 这么重要的东西视而不见. 据我所知, 在任何正规的教科书中都不曾出现过这个概念.

楼主这文笔和画风也太喜庆了. 哈哈

楼主是万达 HR 吗, 好霸气的待遇. 思聪哥的土豪公司啊, :)

估计是我最早在接口测试中提到这个根据 Har 生成接口测试的功能. 在我提之前, Gatling 和其他的性能测试也已经支持通过 Har 生成各种类型的测试脚本了. 其他的 LR 等工具本身也是借助于已有的产品交互来截获数据, 本质也是一种事后补充的测试用例生成方法.

是不是 Har 不重要, 比如 Nginx 的带 post 的 log 也可以. tcpdump 的数据也可以. 我还真的调研过可行性, 的确有工具能做到.
只要能抓到你测试需要的数据即可. 在可行的格式里面 Har 是最通用最简单的标准.
我选择 Har 是因为各种代理工具普遍都支持 Har, 这样自己的接口测试框架也容易跟 fiddler charles 等代理工具配合使用.

理想情况下是接口规范是先出, 然后编写测试用例. 但是实际的情况是. 大部分的公司都是后补的规范和文档. 另外就是很多公司在推崇小迭代. 或者是为现有的系统补充测试用例保证回归. 所以大部分的接口测试都是后补的. Har 等方式就能带来实际效果.
所以你的前两条假设和约定都不成立. 接口测试前置是比较好的, 但是这个理论不符合实践.

往长远看 Swagger 标准才是真的提出了接口测试前置的可行性方案. 在 api 设计的时候它能自动生成接口规范文档和接口交互模拟测试环境. 甚至是接口测试用例. 这个会是未来. 但是在目前更通用而简单的方案还是录制生成修改的方法

根据接口测试的经验, 是否前置, 是否足够简单也不重要, 重要的是维护成本. 如果能在极短的时间和极低的成本实现接口测试的编写和运行. 就足够好了. 比如有了自动生成接口测试用例的功能, 接口测试框架自身是否足够简单已经不重要了. 这也是 gatling 和 lr 工具的共同设计思路.

往大了说, 接口测试并不是描述的是 Http 接口, 他是一个广泛的接口, 不仅仅是某一层的网络接口协议, 还包括其他的"接口",
比如对 servlet 的调用, 对 class method 和 api 的调用, android activity 的调用, android message 的消息传递. 对 gps 的信号调用, 这些也都是接口. 找到一个可以方便定制和分析的接口层和接口维度都可以做接口测试. 我记得社区里面两年前还有人提过用 am 构造 intent 来测试 activity. 这也是一种接口测试思路. 属于广义接口测试. 在单测之上还有好几层概念可以实践. 其他公司有在探索. 不过就目前来看. 对大多数的公司来说, http 的接口测试是行业最成熟最标准的实践了.

#3 楼 @songvajra 最好给个大概的薪资. 不然别人没法投啊

diffy 降噪的思路可以借鉴下. 访问多次, 通过对比排除变化的字段. 然后再结合黑名单.

看大家讨论到这么热烈, 我觉得挺好的. 行业进步源于公开公正的辩论.

技术强情商弱, 技术弱情商强, 都是人才, 都比两样都不好的人要强多啦. 人才都有自己的用武之地, 都能找到合适的位置. 个人靠技术还是情商发展, 各有自己的路和生存的土壤.
有的人情商和智商都不行也能成功, 靠关系和血统或者选择与运气也都可以. 所以 不以物质成功来评判对错 要不然这儿就成厚黑学泛滥的泥沼了.

如果说整个 IT 链条是个食物链的话, 情商的市场是管理层, 技术的市场是生产团队. 所以 在发展稳定的情况下情商高的人发展更好, 在不稳定的环境中技术好的人发展的更快 . 大家可以自行确认当下是什么时代什么环境并根据特点调整自己.

从我的个人经历看, 测试行业职场是一直秀情商. 研发行业才是秀智商的. 相对于每年研发在技术和管理模式上的改进和交流 测试行业几乎是没一个像样的能让研发重视的大会. 大行其道的一直是测试心理学 管理哲学和敏捷大论.
整个测试行业能进化到 技术是测试工程师的必备属性 这个共识已经很不容易了. 直到最近几年互联网公司测试工程师的招聘面试才开始真正的设立技术门槛. 现在没技术基础很难进好公司了. 所以作为一个新人, 技术这个基础是要确立的 .
如果继续秀情商, 测试行业被淘汰是迟早的事情. 情商可以带来个人事业的成功.
情商足够高可以保证自己的团队或者公司是一片和谐的. 但是有没有价值在整个行业是无法粉饰的.
所以你可以看到包括微软 Yahoo 阿里和大量的创业公司都在想办法缩编测试团队. 包括硅谷的各种创业大佬在其出书立说中也都建议把质量检测的事情外包出去. 目前的传统的测试理论实践和态度都已经是落后的生产力了, 不迎合科技发展就会被淘汰 .

这几年行业的发展, 传统测试->敏捷->持续集成->持续交付->DevOps. 这条行业发展轨迹里面测试能够代表的价值已经越来越小了. 这些变化的目的也仍然是围绕速度和质量目标的. 质量的重要性一直都在. 只是测试带来的价值相对变小而已. 我觉得测试应该想想如何找到自己的价值舞台, 测试需要先靠技术来保证质量和保证自己的行业地位. 其次才是寻找情商发挥的市场 .

测试行业被淘汰的人会很多, 但是一定不会淘汰掉 Testerhome 的群体. 现在的测试工程师薪资是 6k-3w 之间. 在即将带来的行业变革中, 测试工程师要么进化到 15k-3w 之间的薪资. 要不就是被淘汰或者外包. 大家可以翻翻社区的那些招聘, 不少公司都可以开到月薪 2-3w 了.
大家应该或多或少的注意到测试岗位的数量已经在下降了, 测试研发比例也已经从当年崇尚的 2:1 1:2 降低到 5:1 10:1 以下了. 更极端的情况, 如果将来测试工程师依托行业科技进步生产力得到提升, 人数会进一步缩减. 或者和研发工程师更密切合作融为一个团队的时候, 在群体基数变小的情况下测试工程师秀情商的市场就越来越窄了. 基于这个考虑, 我宁愿新人技术好点.

我希望无论是情商高还是技术高的领导, 或者是关系好人脉好的领导都可以在这里找到优秀的团队成员.
作为新人本身我希望是一开始就是技术足够好的. 以后可以根据环境自然往情商和智商发展.
往哪发展都是可以的. 各有用途和发挥舞台. 我希望分化的两类人是互补的,而不是对抗.

@lvchongen 这哪是最好的一篇, 我也理解你的意思, 你只是表示这个文章说到你的心坎上了. 不是每个人都有相同的经历和环境, 所以感受是不一样的. 别人质疑也很正常. 毕竟你的地图炮太大了.

@441385483 写的很好. 也问的很好, 结论观点我支持, 不过你在唯技术论里提到让研发团队做测试工具这个事情, 其实是不太靠谱的事情. 这是技术功底不足的测试团队最经常想到的答案. 实际上不具备可操作性. 在没有对问题的本质深入分析和用技术做调研实践的情况下就提工具需求这个事情本身就不靠谱. 这必然会引发更多的问题.

@441385483 @lvchongen 今年 testerhome 会在 7 月份举办第二届的中国移动互联网测试大会, 如果你们自己实践的很好, 也欢迎报名 topic 一起探讨交流下. 我希望无论是技术路线还是情商路线, 都能看到对公司和产品质量有好的推动作用, 也有助于个人事业发展. 进而传播优秀的正能量给大家.

思考你的产品使用场景和输入输出进行设计就可以了吧. 这方面的测试工程师估计少

#16 楼 @evelyn_tang ele 能在如此激烈的竞争中拼杀, 也不容易. 肯定是团队给力. 环境不错. 支持下.