现在就是，好多不一致的，也没法判断有没有问题。再一个，重叠的这种还是需要人工去弄

翻译库的质量也是一个未知数，根据问了下开发，翻译不是从翻译库里来的，就感觉有些乱了

好的，谢谢啦

因为是操作了不同的数据库，所以打算把类型当成不同的接口每个都覆盖全面了，感谢感谢

嗯嗯，感谢感谢，目前也是打算不同的类型当成不同的接口来写

嗯嗯，token 这块的已经问过开发和类型无关，所以 token 只写了一份，其他的类型每个都单独写，细分下来了

我知道你意思了，请问下，这个有没有什么解决办法呢

我知道你意思了，麻烦问下，这个有没有什么解决办法呢

写在前面，前面的先执行是什么意思呀

感觉也是这样的，之所以不用上面的方法，是因为 test_search_type 和 change_id_to_name 这里面都需要用到 yaml 文件里的参数。最后直接把上面那个当成了一个普通的方法然后在测试用例里面调了，感谢回复

感谢建议，我选择了 fixture

感谢建议，架构这块已经打算重新设计了。关于第 4 点，fixture 中接受到命令参数后，将其 return 出去后，test 用例中怎么用呢，谢谢

意思是把生成 yaml 文件的步骤放到 fixture 里面单程前置处理么

这个我已经解决了，用的是 request.config，应该要附上代码的，感谢感谢

可以直接写到运行用例的 py 文件里面，

也有相同的困惑，也是觉得需要进一家测试体系很规范的公司，成长才能大，奈何进不去

测试用例已经让开发评审了，几乎是没有什么问题。技术层面这块的，我只能想到还是需要懂 android 基础，让开发讲具体代码实现，根据代码实现再去增加对应的测试用例。例如，我们有一个播放上一首/下一首的功能，从业务层面，就是点击播放上一首，点击播放下一首，但是开发实现涉及到提前加载，写入数据库等等一系列的操作。有个必现 bug 就是，提前加载到数据库的时候加载失败，导致点击上一首无法播放。但是不懂业务逻辑，这个时机根本就掌握不到，只能靠碰。

播放这个东西因为要挂后台播放，无界面的，所以是用的一个服务，android 的四大组件之一。现在完全不知道开发代码是怎么实现的，涉及到各种 android 基础，开发讲逻辑的时候。第一点几乎都做到了，可是第二点，通常开发反应就是，为啥测试没测出来，为啥这么迟才反馈出来等等类似的。但是测试这么久，好多 bug，真的是，没碰到就是碰不到，突然间碰到了，我也没办法。服务的这个还只是其中的一个例子。

我们是测一个音乐 app，然后是 android 端的，是 android 里面的服务，有个 bug，是服务挂了才会出现的。但是这种我们几乎操作不到。看待问题的角度不同，他就是从代码实现这块考虑的，我们不懂代码实现，只能凭借经验去测。所以开发说的时候，我还是蛮尴尬的。

我是稍微写的有些简陋，我们这块是有写用例的。具体的话各种本地音乐文件/在线歌曲/VIP/网络/歌曲品质/缓存等等一系列的。我单独把播放这个拿出来写，主要是被开发说的要杀掉播放服务来测试，被刺激到了。潜台词还是希望我们能从代码实现这块来考虑

这个也是我考虑的点，目前的测试几乎是纯黑盒以及偏用户体验这块的。开发的 bug 的复现手法这块的，不从代码这块来考虑，几乎没有什么关联性。从代码这块来考虑才能串起来。痛点的话 ，还是在于技术实现这块的。

这些都已经做了，除了性能那块的之外，各种格式的支持/缓存/各种来回切都做了，但是这些考虑点统统都是根据业务来考虑的，并不能达到开发想要的度。例如，播放服务由于未知原因，挂了，导致报错这种类似的，可能是开发更加希望我们能找到的点

边开发边测，我唯一的一个感受就是，提了 bug，开发直接说没时间，去开发新功能去了。所以测试不独占周期是不现实的。开发只有把功能都先开发完成才能对上面交差，修复 bug 是要放在后面的。

想问下，大佬转行打算干嘛。

业务不是万能的，如果懂业务就能测试的话，那产品经理就可以直接干测试的活了。有些代码方面注意的点时需要开发提出来的