最喜欢有效这种话题了，有效的本质是有比较性，测试也是分和之前比，和测试后比。

从事前用例的角度来说，如果每次执行的用例都是不变的，那么这个同学本身发现 bug 的概率就是低的。所以当业务耦合，系统耦合发生时用例一定是变的。所以之前的误区就是用例本身是不变的，至少每个版本测试用例是肯定需要变化的。
而如何更有效那就得从业务及代码的角度来看了，之前提到的提高用例覆盖率，接口测试是不错的点。
比如做单接口覆盖 (容错，模糊)，当单接口覆盖完了基本可以区别之前的业务测试用例哪些是有效，哪些是不重要的了。

从事后的角度来说，漏测分析非常有必要。将漏测的或者监控到的线上 bug 统一起来分析自己的用例并补全。

另外用例有效性一定不是 okr 的指标。测试只有一个指标 － 线上质量

互联网金融这个比较特殊，从你的描述中应该是个人消费金融这块业务。主要是对业务足够的熟悉，然后引入接口自动化。从正常的申请，征信，验证，放宽和还款的流程来走。更多的是了解业务。如果有风控才会涉及风控准确性。其他的保证接口测试覆盖率及数据准确性，个人信息安全性即可。

根据以上指标：

1，3 是同质的问题，建议按数据准确性及重要性业务排序来做

2，看了下大部分的流程都可以接口自动化，建议尽量完善接口自动化流程

4，5 也是同质的问题，主要是权限的分配，先从流程及业务角度来看权限分配合理性。线上更多是验证，互金开权限就有刷单的嫌疑，但是基础流程可以普通账号完成。5 同样的问题 流程和权限是否合理，如果不合理如何有效的提出。

6，互金分不同的模式，各种模式都不一样，所以从本质上还是看公司架构及业务的划分

持续集成几个关键的要素。分支策略, 持续集成, 持续测试。分支策略的点没有覆盖全。feature, dev, master, release 之间的关系要交代清楚。至于集成是一个全面的过程。环境配置如何做，上线回滚如何做。代码不是重点哦。

测试的点不是直播的主流程。登入－加入房间－点赞 这些都是 micro service 做的。 rtmp 流的主瓶颈是带宽和延迟你也提到了。这其实还是回到 10 年前直播的问题，如何平衡。提高压缩比，延迟高。降低压缩比带宽高。

onealert 免费版基本也是够用的。通知途径还是很多的

非常不错的成熟度模型啊。结合自动化测试成熟度模型，测试成熟度模型及实践总结出来的。非常值得借鉴。

#7 楼 @monkey 嗯，前端时间忙。测试的路偏向开发了，😄

#5 楼 @monkey 不能这么说，😄，现在你应该也体验到不少了吧

#2 楼 @monkey 呃。。monkey... 现在是打杂的型