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

我现在也没做过 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 的值是否和用例一致就行了。

如果是作为应届毕业生，个人觉得可以胜任了。

但如果是作为社招，建议你提到的 6 个条件其中一个要达到熟练级别，前三点是基础，而且说实话，你目前的描述看不出你在这三个方面有什么优势，根据用例执行测试，写过不少用例只是经历，不是能力，面试官不能根据这些看出你的用例设计、执行能力。至于 “知道发现 BUG 要怎么跟开发沟通” ，建议详细说下你的具体沟通方式，这种表述方式让人觉得心里没底。。。

至于后 3 点，是体现优势的地方，但从你的描述来看，有了解并不足够深入，或者说你描述的内容一个没具体做过这方面的人学习一周也能基本掌握，体现不出差距。建议找一个点深入一下。

PS：没有实际项目经验在社招是个硬伤，很多数据写不出来。建议寻找一些创业型公司或者愿意培养的大公司，在实际项目中学习比自己自学效率高不少。
PPS：没有项目经验可以自己找些项目做，比如设计一下 testerhome 网站的测试用例并通过执行用例发现里面的 bug ？

#8 楼 @kaitlyn 还没，目前还是起步阶段，也还在探索中。有所成后会分享出来的~

#6 楼 @Anikikun 赞~

#5 楼 @huayinwang 上家公司核心流程涉及 iOS 系统的一些核心功能，模拟器上实现不一样，结果不可靠，所以基本都用真机跑。如果是业务流程应该问题不大。

作为覆盖率高为目标的话，我觉得要把这些排列组合都列出来

个人觉得参数边界值完整覆盖这个，如果确实需要，建议做个小程序通过规则自动生成。手写数量很多，维护性也不高，而且说实话，部分用例实用性并不强，因为实际使用场景遇到的可能性很小。

我觉得，我们应该追求用尽可能少的用例覆盖尽可能多的高优先级场景，先确保核心功能可用，然后再是异常场景（比如参数不合法）。在接口还没开发完成前，根据协议覆盖最核心的部分（正常流程、需求中明确说明的异常流程）就差不多了。毕竟接口一天没开发完，一天都还有可能改，用例多的话自己维护工作量就大了。

PS：有条件看到开发源码的话建议看下开发源码，这样设计出来的用例准确度更高。有些边界值在程序里面其实并不是边界值。

#5 楼 @woniu 哈哈，大家一起加油~

请遵循 排版说明 进行排版。现在文字都挤在一起，阅读体验并不好。

1. 麻烦使用 markdown 排版。。。文字都挤在一起阅读体验并不好
2. 不大明白为何多处提到 TestWriter ，有比较明显的软文感觉。

另外，不是很赞同步骤、预期结果、实际结果都结合到一句话描述的风格。我比较喜欢用类似下面的比较明确的格式说明：

执行步骤

1. 点击调度计划
2. 弹出浏览器

预期结果
显示计划分配

实际结果
显示计划待分配