额，看了几遍，有些地方没有看懂：

1. Method 的 init 方法不是没有参数吗？最后那段代码里 Method(noxdriver.getDriver()) 是啥？
2. 没看懂 为了测试方便，两个脚本公用一套代码 的意思，你是说这个脚本跑两次就是两个用例了？
3. 从你的解决方案来看，就是把 driver 实例分别放到 Method 里面，让它们分开使用两个 driver ？
4. 一开始的 Method 里面不就有个 get 方法获取 driver 嘛，为啥后面又加了个 getDriver ？

关于你最后的不会出现方法提示，我觉得这个应该和你的 element 对应的类有关吧。我感觉你前面和后面两个用例之间应该改了不少代码，但没有放出来，所以也没办法搞懂你出问题的原因。

另外，你的标题取得不好，这个不是 appium 如何管理 session（它的管理很简单，同一时间只能有一个 session ，每个 session 的生命周期就是开 (初始化)->使用->关 ( quit 或者 timeout )）。你的问题应该是用例（method）之间如何管理 appium driver 实例。管理方法应该是每个 Test suite（class）开始时开 session ，结束时关 session 。你一开始的问题应该是每个用例都不会去开 session ，但是都会关 session ，所以后面的就没 session 可用了。

那这个很奇怪。帮你找下原作者 @vigossjjj

#43 楼 @wangcityboy 你用啥参数启动的？

之前看过阿里一篇关于分层测试的文章

这篇文章是网上的吗？能否贴下链接？

#15 楼 @cxli2 具体方法很多，可以发送返回按钮事件，或者点击界面中的返回按钮。back() 这个我没用过，不知道是不是返回按钮，你可以试试。

#12 楼 @cxli2 可以确定的吧。
如果是界面方式，一路返回直到回到开始界面
如果是非界面方式，可以直接开指定 activity

#9 楼 @cxli2 有种函数叫做 teardown 。既然你每个 case 都是从打开 app 后的默认界面开始，那你每个 case 结束时都回到那个界面不就好了嘛。

#2 楼 @admin 这个问题应该是你思考后把思考的结果放出来，让大家给意见，而不是一上来就要答案。

没有尝试思考过，没有给出自己的思考结果就直接问问题，我认为都是伸手党。

#7 楼 @cxli2 我不会那么频繁开关 app ，而且我用的是真机，至少跑 20-30 个 case 是没问题的。

这不是是否下策的问题，应该说是综合考虑的结果吧，毕竟 7x24 小时的服务对于大部分自动化测试必要性不是那么大。

不要做伸手党。。。

我记下了 issue 了：
https://github.com/testerhome/A-Native-TesterHome/issues/7

从 log 来看和之前另一个 issue 比较类似，都是 onResponse 出问题，后续等客户端的同学有空再一并解决吧。

印象中 711 大会时 mujun 有提到过原生 adb 稳定性有问题。不过是否和频繁打开关闭 app 有关就不清楚了。

ATT 是什么缩写？

#7 楼 @woniu 有些图片我是压缩后再放上来的。。。我换回原图了。

#1 楼 @lihuazhang 。。。你应该关注妹子啊。。。

太简洁了。。。虽然大致知道你的意思，但是没看出它的具体做法和优势。而且如东哥所说，脱敏脱得太厉害了。。。要不你弄个 demo 来截图也好啊。。。

#15 楼 @jh901011 嗯，正常来说应该是能看到的。不过看你的截图还停在显示 template 阶段。

要不你拿另一个有 webview 的应用试试，看有没有问题？

#12 楼 @jennifer 你看下活动沙龙专区的帖子，上海和北京最多啊

#12 楼 @jh901011 android 版本是？
你的截图里不是有一个 webview 了吗？

忘了回答一下你的问题了。

测试的存在真的能提高产品的质量吗

我想先问清楚，你的测试时指测试人员还是测试活动？如果是人员，那只能说取决于他的能耐，如果大家都忽略他，那肯定对质量没多大贡献。如果是活动，我相信答案是肯定的。

你的疑惑我觉得应该是你提出的各种问题开发没有正视。例如你上面的例子，一个评论在网络良好的情况下超过 3s ，这在大部分情况下是不可接受的。但怎么说服开发，或者开发的老大去修复这个问题，这就需要一些技术之外的东西了。一般可以给出数据（平均评论时间多久，其中每一个环节的耗时是多久），说出和竞品或者大部分 app 的差距（一般差距超过 100% 就算比较严重了吧），如果能拿到源码，甚至可以自己去加一些 log ，加断点，了解到底是什么代码造成这么严重的耗时，给出可供参考的解决方案。

说白了就是报 bug 时不仅说出重现步骤、预期结果，还需要说明你认为它属于什么优先级（任何事情都有优先级）、给出合理的数据证明这点。

无论最后问题是否被采纳（我相信有这么齐全的数据如果还不采纳只能说情况特殊，例如这个 app 还存在很多比这个严重 n 倍的问题），你都学习到了不少东西。更重要的是你让开发同学看到你的能力，以后沟通起来会更顺畅。

看在你叫我大哥的份上，这次帮你调整了格式（仅此一次）。你自己使用编辑界面看下调整前后有什么区别。

写分享是好的，但如果格式让人没有读下去的欲望，效果会大打折扣。

#12 楼 @actionwind 额，不算纯白盒，不过确实是要拿到代码才能做。
不明白为啥不想研究？难懂的东西不是更有研究价值嘛。