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

#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. 弹出浏览器

预期结果
显示计划分配

实际结果
显示计划待分配

应该是配置不对。检查下 url 对不对，get、post 这些方法对不对，服务器监听地址对不对 (不应该只监听 127.0.0.1)

赞，不过模拟器的结果真的那么可靠么？

能给下英文版地址？

表示天天都很忙。。。个人年度总结到现在都还没有写好。。。

可以趁这段时间做一些自己一直想做但没时间做的事，例如学学新技术，把上一年感兴趣但没时间看的技术 topic 看完。

#2 楼 @wxy_fight

#7 楼 @yefnegjun 应该不影响。

找到原因了，webpack 的配置文件里面 exclude 了 node_modules 文件夹，你改变路径前 WebDriverAgent 刚好在 appium 的 node_modules 文件夹中，里面的文件都被忽略了，所以报错。

修改方法：

把 /Users/hengjiechen/.nvm/versions/node/v4.2.6/lib/node_modules/appium/node_modules/appium-xcuitest-driver/WebDriverAgent/Inspector/webpack.config.js 中的

...
loaders: [
      { test: /\.js?$/, loaders: ['babel-loader'], exclude: /node_modules/ },
      { test: /\.css?$/, loader: 'style-loader!css-loader' },
    ]
...

改为

...
loaders: [
      { test: /\.js?$/, loaders: ['babel-loader'] },
      { test: /\.css?$/, loader: 'style-loader!css-loader' },
    ]
...

把 , exclude: /node_modules/ 这部分去掉即可。不过我只确定能打包成功，能不能正常运行没试过，你可以试下。

官方 issue ：https://github.com/appium/appium/issues/7088

官方已经回复了，不支持运行 WebDriverAgent 自带的 inspector 。

至于为何单独移出来就可以用，我猜和 webpack 检测相对目录的根目录有关。有兴趣你可以细究下。

#52 楼 @yefnegjun SyntaxError: Unexpected token (59:4) 看起来是语法错误。你换另一个版本的 wda 试试，或者另外发个帖？

源码好长。。。。建议源码放 github ，给个对应 github 地址就好。

前面也可以加一些铺垫，例如为啥想做这个工具。

#3 楼 @suren 有几个地方包含了 html 标签。请使用纯 markdown 排版。

#118 楼 @rolex_sky001 重装 ideviceinstaller 试试？

微信有同学回复：

@testly 回复下？

#35 楼 @liuang68

1. 端口号你要根据自己服务具体配置的端口号来配置哦，我上面的示例是根据我自己 triproxy dev 的端口配置来配置的。如果你用 stf local 来启动 stf ，可以看下日志或者源码里面 triproxy dev 具体的端口配置情况。
2. 先确认下，你用的是我示例中 mac 的方法还是 windows 的方法？看你在 stf 服务的机器上多开 provider ，我能理解为你用的是 windows 的方法？如果是，那就漏了 adb host 这个参数。除了 adb host 要用 windows 主机的 ip 地址，其它还是用 stf 服务所在主机的 ip 地址。

话说，DecoderConfig 除了 charset ，支持其它类型的 decode 不？例如通过自己另外写的外部类把收到的数据（私有协议）转化成 json 格式。