看起来你现在的测试方法是黑盒且偏用户角度。
换做是我的话，整体思路可能是：了解技术实现，从每一部分的技术实现去分析测试点
另外，如果开发有找出一些你没发现的测试点，可以深入咨询下 bug 详情，了解 bug 产生原因，分析复现手法，复盘为什么自己没有发现，然后往自己脑子里的测试池添加内容。
我觉得是先有思路，再结合复盘提高自己的测试质量。

感觉你这完全像是客户体验啊，没有什么测试内容和方法

比如说你们用的什么播放器？这款播放器都支持哪些音频格式文件？都能解析哪种编码格式？ 感觉这些你都没有考虑过啊

你只做了一个冒烟测试，不知道你是 APP 还是 web，首先专项兼容测试肯定要做。尽可能的多想一点异常情况。功能兼容层面比如 1、MP4、AVI 等其他格式是否支持。2、播放时来回切换播放节点是否卡顿、是否爆音。3、断网情况下是否读本地缓存播放，联网情况下是否继续下载缓存。4、性能层：播放时 CPU 是否过高、内存是否溢出过高、磁盘是否读取正常。等等等的

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

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

服务器测试可就另一个领域了。
拿多少工资啊，什么都要测。
他想怎么测，你问问他。让他说清楚。
还要凭啥他说怎么测就怎么测，他是开发，你是测试，角度就不一样。

服务挂了，不是测试的事情，是运维的事情。

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

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

Android 服务？ Android sdk 挂，关测试什么事情，你们有 sdk 测试？

我觉得你有点薄脸皮了，这完全跟测试没关系，不能他说测试问题就测试问题。
如果你是小白，将来出 bug 扯皮的事情多了去了，如果这种锅你都背，那你以后会更心累。
说说我的看法：出现 bug，肯定是测试不希望的，不管是任何 bug。第一时间查 bug，修复 bug。第二如果要追究责任，可以追究，是测试没到位，自己长记性，不是测试的测试范围，比如说运维监控没到位，服务挂掉、Android sdk 中间件挂掉（一般是兼容性出问题）等等，不背锅。

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

测试那么久测不出 bug，其实两点，第一：测试经验有限，技术层面不足，这个只能是招大佬或者开发培训了。第二测试覆盖率不够，建议写测试用例，然后叫开发一起评审，找到遗漏的测试点

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

慢慢来吧。多积累经验就好了。 就像开发不知道高并发下如何应对一样，都需要经验的累计。

复盘下研发提的这几类 bug，总结下发生的场景与对应的测试用例。考虑将其加入到日常回归用例中。服务器挂掉的场景可以定期内网模拟，然后验证。而且楼主真的脾气好，用例评审都通过了。这类场景就不能算测试的锅

没看到提弱网, 可以在弱网环境下跑下常规的用例