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

从事前用例的角度来说，如果每次执行的用例都是不变的，那么这个同学本身发现 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... 现在是打杂的型

工具主要是适合，都会有局限性，择优吧。而且也和被测对象有关，没有绝对性吧

赞👍

非常赞~~

#30 楼 @kinget007 嗯，这个有两块，后面的测试部分其实是可以黑盒的面向开发及功能测试。他的做法其实是一样的对于某个接口通过固定格式进行传参然后进行 case run。本身用于测试的同学成本并不高

貌似功能和 fitness 的功能差不多，外面的壳子 fitness 全部帮你做掉了

这样测试团队的规模要多少啊。

非常不错的分享。但是是不是可以利用已用的 crash 平台, crashlytics 然后做一个总汇 dashboard

全栈
#33 楼 @lihuazhang 不好意思，回复晚了啊，招人难因为上海的测试市场你也明白，除非自己培养出来的吧。其实就像敏捷一样，刻意去做敏捷的一定做出四不像来，全栈更多的也是自己去做，真实不排除中国特色的。正确的全栈测试更多的是自发形成的一种约束力，没有人说要做性能，又做自动化，又做线上监控，关键是如何能更好的保证质量。如果不做任何事质量能上去那么的确也会出现无测试化的状态。事业有专攻，测试的专供应该就是质量吧，无论线上还是线下。另外管理模式及团队一定也是影响的因素。

觉得这篇文章的题目和内容偏失度蛮高的。“全栈测试工程师，这是病态的项目管理下才产生的职位。” 这个其实也算吐槽吧。
即使 twitter 也有文章说去全栈工程师，但是不要误解的第一点就是团队是什么样的。
“全栈测试工程师，这是病态的项目管理下才产生的职位。” 这句话应该这么说 “病态的项目管理下，说全栈也是病态的全栈工程师” 比较好。作为一个开放的平等的论坛这么说没有问题，但是如果影响测试发展这么说就不负责任了。
据我所知北京至少也有 3 个团队 run 全栈测试非常好，他们的困惑和我都是一样的，全栈测试为什么难招。回到这个话题我觉得你理解的全栈可能有很大的偏差。 就像国人理解敏捷的偏差一样。

我同意@lihuazhang 的话，我也觉得@lihuazhang是符合要求的人选。

我也说说 glow 吧。公司在人民广场，上下班很方便。提供中饭，晚饭，零食和饮料。
每年还有几次和 Max 吃饭的机会。
公司的氛围偏技术性，所有的开发没有划水的所以需要在测试的方面有自己的想法来征服开发。
晚上大家一起加班打打 foosball 也是件很开心的事情。看着 app 的超满意的 crash rate，心里也是很开心的。
不管 google 到底好不好，但是 google 出来的工程师至少是有追求的，这让测试工作事半功倍是真实的事情。
作为 Glow 现在的 qa 我觉得 glow 还是值得大家来看下的。

但是创业公司就是创业公司，可能需要的是你全身心去做一件事，原来我以为这很容易，做了 1 年下来感受还是很深的，会失去很多自己的时间。之前论坛的坛友也有到公司来面试的，觉得失败的理由总结有 2 点：1.是对公司要做什么没有概念. 2. 基础 coding 没有过。原来要求招聘为 full stack 的 qa， 现在的要求为有 ‘激情’ 的 qa。如果您想一起来实践最新的测试技术，一起来实践最新的测试理论 glow 都很欢迎您。

可以直接私信头像的 email 我

@lihuazhang 赞！！ 不过可以走我这里的快速通道。