#13 楼 @carl 赞。一段时间没关注，怕教错人了。确认了就好~

#4 楼 @codeskyblue 更正下，7 天这个数字我不是十分确定，只是印象中大致是这个数字。因为以前公司有做应用市场这块，所以有了解到。

#1 楼 @carl 免费个人开发者账号生成的 provision profile 目前只有 7 天有效期，简单的说就是用这个证书打的包 7 天后就不能用了，需要重新打包。

估计原因是之前有些应用市场通过免费个人开发者账号重打包应用发布，所以苹果加了这个限制。

不用选 Launch AVD，AVD 是 android 官方模拟器。

报错说的是你选了 Launch AVD（添加了 --avd 参数），但它的值不是有效值（一个空字符串）。

不要用 xpath 不行嘛。。。xpath 原理上决定了很难兼容。因为 iOS 10 上 WebDriverAgent 识别元素的方式和 iOS 10 以下的 UIAutomation 区别很大，包括元素标签名这些都有差别。

#38 楼 @Zhumeng223 没日志，没脚本代码，也没有你 app 具体加了什么 accessibilityId ，要帮你找到原因太难了。。。

#39 楼 @Anikikun 额，哪里套路了。。。

最终结论是 usb hub 芯片和 linux 上的 adb server 有兼容性问题。

实验方法：

1. 准备好 3 个脚本，一个脚本就是上面的一直检测 adb 连接是否被断开，第二个是每隔 1s 打印 adb devices ，第三个是每隔 1s 打印当前连接的 usb 设备列表（类似 lsusb）。
2. 使用同型号的 hub ，分别在 windows 、mac、ubuntu 上连接手机（手机已试验过和 stf 能稳定连接），并通过 adb server 或者 stf provider 连到同一个 stf 平台。
3. 在三个操作系统上同样运行上述三个脚本，过约 24 小时候查看脚本运行情况。

在 mac 和 windows 上，手机未出现掉线，adb devices 和 lsusb 输出都正常
在 ubuntu 上，手机掉线超过 3 次，每次掉线持续约 5-10s（通过 adb devices 脚本日志看出），但每次掉线时 lsusb 设备列表没有变化。

最终只能说这个 hub 和 linux 上的 adb server 有兼容性问题了。。。

#37 楼 @Josen 额，你直接发帖问吧，qq 上回答技术问题不方便。

谢谢分享，竟然被 @ 到了，受宠若惊啊。

我现在也没做过 sdk 测试，公司目前没有 sdk 型的项目，不过后面可能有写测试辅助用 sdk 的需要，到时候可以应用文中的技巧~

#25 楼 @wyjcwow 保险起见确认下，你在跑 appium 脚本前已经手动跑过 adb connect 命令，并确认在你自己外部的命令行用 adb devices 能看到设备吧？

appium 可不会自动去跑 adb connect 命令。

#10 楼 @wyjcwow 。。。你发之前预览下吧，现在排版明显还是有问题。

排版说明里面的空格都是不可忽略的，不要随便就把空格或者换行符干掉，去掉后就不符合语法了。

No appActivity desired capability or server param. Parsing from apk

这个是表示你的脚本没定义 activity 名称，appium 会自动从 apk 里面解析获取。这只是一个步骤说明，并不是报错。

你能用 markdown 排下版吗，日志像上面那样用代码块来显示？现在好难分清那些诶是你的失败日志，哪些是你的成功日志。。。
不知道怎么排版的话可以看下回帖框右下角的排版说明。

能把整个 stack trace 发出来看下吗？从你的 isElementPresented 方法来看，不应该在脚本端抛出这个异常（异常都被 catch 住了）。我觉得报异常的并不是你这个封装后的方法。

1. 麻烦使用下 markdown 的代码块吧，现在正文真心乱。。。
2. 看了下 UiAutomatorHelper 的 github 仓库，两年没更新了，现在能不能用这个我表示比较担忧。建议你还是用原生的方法，把 jar 包 push 到收集然后 adb 命令行运行吧。

先想清楚自己想做哪方面的测试？有开发经验的话做白盒测试可能更有优势，如果是普通业务测试那么本身测试用例设计、测试思想这些可能更重要。

然后建议找本测试的经典书籍看下，了解一下测试的基本思想。对于开发转测试，最担心的就是不了解测试具体是做什么，没有测试思想。所以这块会比较关键。

另外，确实如 @piaoransk 所说，熟悉开源测试框架也会有加分，这样能显示你对测试领域的工具有一定了解。

说具体一些？

原理上只要 adb devices 能显示的设备，appium 都能连上。你连不上有可能是你的脚本配置问题。

如果用无线连接，udid 要用 adb devices 显示出来的那个类似 ip 地址的信息，和用有线时显示的会不一样。

#11 楼 @zailushang 哈哈，指导说不上，相互交流而已。期待你更多的分享~

看了下，貌似是空间换取时间，原来是比较的同时不断替换，现在是比较的时候用中间变量 z 记录比较得出的较大值，确认所有数字都比较过后再进行替换。

相比原始的性能优化是比较明显，赋值次数减少了很多。不过看起来有点像选择排序法。

PS：你这种测试方法不大对吧，排序算法的效率提升评估不应该纯粹增大数据量吧，应该还要考虑最好情况（本来就排好序）和最坏情况（例如本来是倒序的）下的算法性能差距吧。或者用算法的时间和空间复杂度进行比较。

赞，写得不错，期待后续。

另外提醒下，iOS 的那个是老图了，底层还是 UIAutomation ，现在应该改 WebDriverAgent 了。

能开到多少取决于你的技能的独特度。从你描述上看独特度不是特别高，按我了解广州的话大公司应该过 10k 一些（个别可能可以去到 15k，取决于你目前的薪酬和公司内类似程度的人的薪酬），小公司估计还是 10k 内。

不过不知道你在项目中的成果如何，如果有很好的成果，可以带到新公司的话另说。

个人建议：

1. 坚持敲 iOS 代码。既然学过，捡起来不会很难。倒不需要冲着 iOS 开发来走，但至少保持着对开发的热度，这是你的优势。
2. 尝试用工具或者自己写脚本解决流程不规范造成的重复劳动。既然会编程，何不利用编程减轻自己负担。
3. 点点点的过程做好总结，比如发现了闪退，那么缠着开发了解为啥闪退，他是怎么修复的。
4. 趁着这个过程积累一下测试用例的设计这些基础技能。这其实很重要。

PS：如果觉得在这家公司呆下去也只是不断重复，很难提高，尝试换个好一些的环境也未尝不可。

赞大猫~

#8 楼 @lunamagic 你的安排也是可以的。不过我觉得这样安排条理性是提高了，但工作量还是比较大，毕竟一个接口一般都有数个参数，边界值排列组合起来的用例数量还是不小的，能够用工具生成效率会高不少咯。

PS：我还是比较建议先确保了正常场景和预期会出现的异常场景的覆盖，再考虑这种参数排列组合的用例，效果可能会好一些。

好佩服你们写总结能写那么长，而且还能让读者读得津津有味。

#5 楼 @lunamagic 加上优先级其实还是没有减少多少工作量，毕竟还是要先穷举再去掉优先级不高的用例。我觉得边界值覆盖这种另外做个小程序来生成用例会比较好，既没有牺牲完整性，也减少了工作量。

举个例子，接口规则是参数 a 为 0~1000 的纯数字，那么那个小程序自动生成的用例就是-1、0、1000、1001、"0"、"a"、""、null 这几个边界值。当然，前提是你确认确实有达到这种覆盖率的必要，毕竟写这个小程序本身也有一定工作量。如果不重要，与其花时间把接口各个参数的排列组合覆盖全 ，还不如多写几个接口的测试用例。

另外，你提到的这种方式在我看来有点像是把接口的业务逻辑在接口测试中再次实现了一次，然后直接对比两种实现结果是否一致。这样就变成了验证接口是否正确执行了 sql 语句。

我觉得这样的测试有所欠缺，比如 sql 语句本身是否正确就没有测试到了，而且可能适用场景有限（很多时候接口背后的逻辑不仅仅是一句 sql ，此时实现业务逻辑的成本很高）。我比较偏向于设计几个比较具有代表性的参数 1，参数 2，参数 3，以及数据库预先配置好需要返回字段 a 的相关配置，即接口外部数据条件（接口数据、数据库数据）都是固定的，然后根据需求得出的接口返回值自然也是固定的。测试的时候直接比对接口返回的字段 a 的值是否和用例一致就行了。