#1 楼 @aizaimenghuangu
首先很感谢你码了这么多字来回应这篇帖子，我分 4 点来说一下我的感受吧。

1. 真的劝你一句，千万别用 bug 数量来考核 QA，原因我帖子里说过，过于专注于 bug 数量也很容易忽略流程上的，机制上的，工具上的东西。而且也容易因为 bug 数量的问题跟开发团队造成矛盾。

2. 我理解你的痛点，我曾经也为这些痛苦过。但后来我把这些考核都抛弃了，只要产品上线没什么问题就可以。这个是实的，其他都是虚的。即便发现了一万个 bug，如果线上还是出问题那又有什么用呢。

3. 就像你说的，我们是以结果为导向的，那么线上质量就是结果。中间大家加了多少班，利用业余时间学习了多少，分享了多少经验为什么要列入考核呢？如果这些都变成 KPI 了，那么结果我几乎可以肯定是，大家尽量加班耗时间，营造一种很忙，很爱学习的样子。动不动就开什么技术分享会来分享一下装个 B 也是很常见的。时间长了只会培养出了一个很不好的气氛而已。我们的文化以加班为耻，能不加班就不加班。逼着大家把效率提升上来，逼着大家把自动化做起来。所以我不太理解你费尽心思营造一个加班的团队文化是为什么？

4. 产品质量不是 QA 一个团队的事情，感觉你的眼界太局限于 QA 团队个体了。应该多想想怎么协同其他部门，定制标准，规范流程。如果某一天你发现 RD 提测以后测试出的 bug 特别少。那时候 QA 团队才是成功的

作为一个在 58 到家工作过的人来发表一下意见。如果你是做技术的，不要去学一个刚成立 2 年的公司的管理经验，尤其是这个公司是以销售为导向的，尤其是其领导层在半年前还在不停的洗牌出局。尤其是成立一年，脚跟还没站稳就引入 KPI 管理机制的公司。也许他对外忽悠的很好，但是你看技术部的离职率就知道了。他的这种方式也许很适合管理市场和销售部门。但别套用在技术部上。58 到家的技术部。。。那叫一个人仰马翻

测试用例的策略不能一概而论。看产品类型，看产品所处的阶段。
互联网 To C 的产品，迭代快，发布时间不可妥协，明知一堆 bug 还发布的情况太常见了。 业务不一样，用例策略也不一样。每次发布前回归主流程，不必事皆巨细。监控和 troubshooting 的速度很重要。就算你用例做的特别好，特别细，也是跑不完的。
产品前期，堆功能的时候。连用例都可以不写。 所处的阶段不一样，用例策略也不一样。这时候业务不稳定，产品能活多久还不一定，所以没必要投资源写用例。

以上两种情况都是弱化用例策略的。因为修复成本低，监控做的好，trouble shooting 快。要快速发布抢占市场，出问题直接线上一修就行了。所以互联网才高度重视监控，高可用，trouble shooting 机制等等。如果在这里用例设计的特别全，特别细。恐怕测试没跑完呢市场已经让别人占了。很可能大家都是在用 excel 写用例，连用例管理平台都没有

相反如果是 TO B 的业务，尤其进场部署困难。升级困难的。一定是高度重化用例策略的。这种项目发布周期长，有足够的时间进行全覆盖的验收测试。并且是一锤子发布，一旦发布几乎没什么后悔药，你没机会玩监控。所以这种项目在发布前搞个一两周的测试时间都正常。测试流程极其严谨，用例管理平台里堆积着大量的 case。这种产品弱化监控，trouble shooting。重视自动化,CI，流程和文档。

不同种类的业务，测试策略是不一样的。

#39 楼 @early 我都不用关键字的。我觉得最好的方式就是老老实实的写代码，使用良好的代码设计应对变化即可。

#17 楼 @panxq5 这是转开发的节奏么。。。

#11 楼 @wildboar 恩，我是有些太理想化了

#9 楼 @monkey 标题的名字是有点歧义了，我是希望所有的测试人员都能达到 QA 的标准，这是我的一个愿望吧。所以不管是测试开发还是普通的测试。都要把自己当成 QA 来做事。

#6 楼 @monkey 恩 是啊。。。我没说是一回事啊。。。测试只是 QA 的能力之一。。上面我几乎没怎么提测试的事

#35 楼 @lingcizhisheng 这个都得看你 case 的重复执行度。如果平均人家一周变动一次页面，但你一天就必须得执行一次 case。那即使不太稳定我也会选择去自动化它。一切都是权衡的。如果改变的成本低于每天执行用例的成本。 还是有自动化的价值的

#2 楼 @harsayer 额，这次没怎么吐槽。。。只是捎带着的

#32 楼 @dancingcat_ 可能每个人的目的和预期都不一样吧。有的人为了学习，有的人听说自动化了就要在自己的团队里搞。各有各的目的

#2 楼 @blackcherry 看你用的 idea，加 sdk 了么。idea 默认不添加 sdk 的

#20 楼 @klxiaoqi 6 年了，其实还是在努力摸索和提高的状态~ 谈不上多厉害

#10 楼 @seveniruby 加了

#6 楼 @caikaibai 谢谢~

#8 楼 @wyb199026 嗯，你说的有道理

#2 楼 @jiazurongyu 问题是很多人连最基本的封装都不在意了。

首先自动化是为了节省成本的。不论你在做什么自动化之前都要问自己，你做了自动化会节省多少成本？即便是简单的 UI 自动化，即便根本没发现几个 bug。但是你每次是不是要花时间去手动执行这些用例？心中做好权衡利弊以后，你就会有答案的。 其次，自动化仅仅在于测试。环境搭建，打包，部署，监控等等等等。如果你搭建一个环境要一天，但是如果你花一周的时间搭建好了自动化部署。以后你每次搭环境都只有 5 分钟。 权衡下利弊你会有答案的

#4 楼 @jack1785 sungaofei@4paradigm.com
欢迎加入

#11 楼 @seveniruby 额。。。原谅我的懒惰。 一忙起来就有惰性了，一有时间就想歇着。。

#9 楼 @seveniruby 嗯，以后多交流。说不定以后就有好的方案了

#6 楼 @seveniruby 请教一下，研究了 spark 之后怎么应用到测试中呢？ 因为我们的产品也用到了 spark，我一直没有什么好的方案。虽然知道了原理但是感觉测试上还是得从上层调用 API。现在除了调用 yarn 的 API 以外我没想到什么好的方式辅助测试了

#6 楼 @seveniruby 嗯~ 暂时不搞

#4 楼 @seveniruby 其实如果 scala 普及起来了的话，我觉得我会用 scala 的。现在换成 scala 的话实在是担心写出来的东西只能自己用。

#16 楼 @success 那就要不就分几个机器那种,做成集群化的.要不就找个好点的机器哈哈