赞，原来那套基于 OCLint 的扫出来的质量真的一言难尽，现在扩展支持 Infer 太赞了

这种就是纯黑盒测试方法了。
结果基本能反映真实用户的情况，当然不大可能真的和你设定的概率一模一样，但只要误差在可接受范围就好。成本其实还好，写个脚本，接口调用 1w 次并记录下返回结果，成本倒没高到不可接受。用 jmeter 并行请求还能更快。

个人建议可以试试岩鼠，远程真机很流畅，和内网搭 stf 效果有的一拼。不过机型不知道是否满足你需要，可以综合看下。

不过一般各家平台都有远程真机免费试用几十分钟的，可以都比较下，远程真机不同云测平台流畅度差异还是比较大的。

另外，费用这个建议直接找这些云测平台的商务直接对接下，看是否有折扣价之类的。

这个兼容性，要求是通用型的 装应用、启动应用、跑 monkey/界面遍历，看是否崩溃，还是还有一些自定义场景，需要远程控制真机？
另外，楼主还漏了一个很重要的信息，是否准备付费，预算大概多少。

如果不计划付费，都用一遍里面提供的免费功能，直接比较就好啦

实习时的公司做的事情和楼主差不多，也是有资质的实验室出去各种测评，文档写一大堆，测试也就 1-2 天，只能算是很简单的验收。不过吐血的是这种情况竟然还能发现不少的 bug。。。

其实楼主这个情况，建议先不提离职，反正时间比较充裕，可以出去找几家自己比较心仪的去面试下试试（能找到内推最好，否则担心你的简历会被刷），了解一下外面的世界是怎样的，自己也尝试去按照外面的要求自主去学习一下，看下是否可以适应。

首先，根据方向，找好你想要学习的工具或框架

1、搭好运行环境，跑通官方给的 demo
2、读官方文档，最好通读一遍，以后遇到问题就有印象去哪里找答案了，比直接百度效率更高
3、在实际项目中完成一个最简单的用例，把它用起来
4、在项目中持续使用，持续改进，遇到问题发现文档找不到答案，再读源码。

如果觉得自己自学有困难，可以考虑看网上的视频来参考，甚至可以考虑报一些觉得适合的培训班。
前三步可以多做，作为调研，通过第三步比较觉得靠谱的再进入第四步

另外，希望后面提问的时候，先说下自己做出过哪些努力和尝试，遇到哪些问题想交流。
这样进步才快。别人直接给答案印象不深，很可能下次遇到自己还是没思路，依赖别人给答案。

把你完整错误和堆栈贴出来看看？没看出为啥你这一行会报这个错，怀疑是别的地方报错。

特别是说你参数个数是 13，这个很奇怪。

白盒：看代码怎么写的。很可能就是一个 random()*100 得出的随机数，判断是否在中奖概率区间（比如设定概率是 4%，那就是 [0,4) 区间的算作中奖）
黑盒：大量调用（至少 100 次以上，数量越多越准确）测试，看概率是否接近

能说服领导和客户的话，第一种能说得清楚是最好的，第二种始终是黑盒，无法准确证明逻辑一定写对，只能举几个例子反推逻辑没有大问题。

你学习方向最后不是自己也写了么？

不过最终还是需要什么学什么，要不学了用不上的东西，不到半年就还回去了，而且也经不起面试。

可以多试几个 hook 函数，找到最适合自己的。应该有函数可用的。

如果实在没有，那就规范限制 tearDown 里不要做 refresh 操作咯，或者考虑换个测试框架。毕竟 unittest 是 python 自带的一个能满足基本单测要求的框架而已，不是为集成测试设计的，功能丰富度不是很高。实际项目要支持各种扩展，一般用 pytest 或者 nose

有点好奇，你们跑自动化领导还会盯着么，不是都放柜子里，通过报告之类的方式去看结果的么。

两次刷新/get url，我觉得不太好

具体是为啥不太好？为了让它不刷新，付出的成本比收益高，而且可能引起其他额外问题（比如有的 web 框架切换展示内容是不会改变 url 的，所以判断 url 并不准确）

对于你这个点，还有一种常用的办法，就是不要用原生 driver ，用你自己额外封装的 driver（driver 实例可以在 BaseTestCase 里面初始化，后面的用例只管用就是了）。然后改写里面的 get_url 方法，让它全部都先判断，不一致再切换 url。

楼主是不是应该先说下自己需求？ 好这个定义在不同人理解还是差异挺大的。

1、你说的执行前和执行后，指的是 setUp 和 tearDown 吗？如果是，那可以把这些部分放在父类的方法里，子类 setUp 方法第一行调用下 super() 就好

2、这个场景，建议你可以直接不用做判断，直接都进入设定的 url，这样就不用 if else 了。由于这个部分每个 case 对应 url 有点不一样，复用度不高，建议你还是写在 case 里吧。

3、原理上可以实现，但这样有点把业务的东西带到框架里了，对框架通用性不大好，这点建议要综合考虑。

1、每个用例出错进行截图，这个建议直接在 unittest 的 fail hook 里面直接加就好了，不用弄 BaseTestCase，如果有 driver 实例，那就调用一下 driver 的截图函数。写用例的人不用管任何事情。
fail hook 可以用这个方法 https://docs.python.org/zh-tw/3/library/unittest.html#unittest.TestResult.addFailure ，使用的实例可参考 https://github.com/SeldomQA/HTMLTestRunner/blob/master/TestRunner/HTMLTestRunner.py

2、没看懂你这个场景。能否举个具体的例子说明一下？
装饰器本身对应的是设计模式里的装饰器模式（https://www.runoob.com/design-pattern/decorator-pattern.html），是有自己对应的典型使用场景的，没看懂你的场景所以不知道是否适合。但装饰器应该是不支持继承的，所以应该做不到父类该函数加了装饰器，子类就可以不用加。

都有，社区公众号留言 ppt 就有了。历年的都有

建议留意开源专场的议题，议题内容基本都是开源的工具平台相关，是可以直接拿来用的。

那如果设备的数据不是存在服务器而是存在本地数据库，可以抓到设备的数据吗

和数据存哪里没关系，关键是有没有做过网络传输。有做过应该就可以抓（前提是 http 协议）

另外，你文中提到的 刷新不了的，而且抓不了包 ，能把详细信息说下么？这个信息太少了，可能原因很多（比如代理参数配置错了/app 写死了不走代理/app 判定 SSL 证书不对自动停掉网络传输...），无法判定原因。

我现在试了下，可以的。

现在多加了一个地址，你在公众号用一样的关键字发送就有回复了。可以 2 个地址都试试？

那个估计是百度网盘看到下载量大自动封掉的，社区没有下架过。
可以现在再试试，昨晚试了是可以的。

1、你这个东西可以看看 logger 的 handler ，这个机制就是用于日志多处打印且可能每一处都有不同要求的。但是估计要你自己写个自定义的 handler 实现，对接到你这个自定义的报告模块
2、错误信息加错误截图，可以把图片信息以 base64 形式 +html image 标签 存到你输出到 html 报告的日志里，这样 html 报告就能展示图片，且不用额外搞别的图床。缺点是 html 文件会因此变大，因为内嵌了图片，建议做下图片压缩。

比较好奇你这个是啥报告框架，竟然要用到 io.StringIO 来写入

手机上手动安装并信任 fildder 的 ssl 证书了么？

hmm，代码质量这个真的不好说，这个是内功了。

其实很多优秀的工具框架原版的代码质量都不算很好（时间一有压力自然会选择快而不一定好的方案），只是基本开源前都会去修补一番避免太丢人。以前还听说过某大厂开源框架在开源前一周全体补注释、单测和做重构的。

这些都是在开发层面的，那么测试开发中的测试怎么体现出来，仅仅是开发的工具应用于测试么？

没太理解这句话，能否分享下您比较期望通过大会了解到什么内容，而这次大会没有提供到？我们也很希望了解到大家这方面的反馈，看后续如何改进。

不知道你想要多自动化？如果是自动化，teardown 的时候自动删就行了。如果是人工测试用，那总归得人去触发的，系统不知道你啥时候用完数据。

不过测试环境其实没必要删，每次都用新数据那老数据删不删都无所谓的，想办法让数据尽量不容易撞车就行。