#11 楼 @quqing 模式不一样也回避不了一些问题的

#16 楼 @wen_chang 你搜一下 RAP 吧。我们用来约定前后端接口定义的工具，同时还能当 mock server 用

#4 楼 @quqing《比如字段要取随机数怎么办？字段关联怎么办？字段加密怎么办？接口有执行顺序怎么办？接口执行以后需要检查有没有触发第二个接口的执行，等等诸如此类的内容》这部分没太明白为什么没有这些问题了。 同样如果接口参数个数就改变了怎么办，接口依赖很复杂的数据怎么办，各接口之间依赖的数据有冲突怎么办，各接口依赖过强过长其中一个接口 bug 了导致大部分 case 都失败了怎么办，断言的报文是随机生成的怎么办，断言报文不够还需要断言数据库怎么办，断言数据库也不够需要断言各种 hadoop 集群和文件系统怎么办，功能是异步执行必须等一个执行成功的状态怎么办，已经铺开了大规模自动化测试，但是突然接口，UI 等都发生了变化怎么办。等等等等，感觉要考虑的情况很多

#2 楼 @ycwdaaaa 另外用例管理平台也不一定只有 test link， 免费的还有 bug free，禅道也有免费功能。 你可以挑一个适合你自己的项目的。如果公司肯花钱买商业软件，功能就更强大了

前期就用测试管理平台也没什么不行得，不一定非得等产品稳定之后再迁移。没人逼你在用例管理平台上写用例就一定得把详细步骤写清楚。 就算光写个 title 当 check list 也是可以的。规矩是死的，人是活的。用例管理平台的优势不仅是给你个地方管理用例，它也相应的跟踪了每个迭代的用例执行情况，将测试信息展现给团队中的所有人等等

#2 楼 @0x88 这个问题看开发就知道了。他们要应对的变化因素更多？ 他们是怎么做的？ 开发有严格的流程保证代码质量，保证代码风格统一， 有架构师先搭起骨架在让底下的人填血肉，要求文档，注释。 这些都是手段，你再看 QA 写代码的时候有几个严格要求过代码质量的。如果手底下人的水平差，就让测试架构师搭好一个架子，要求所有人都按着这个架子写，严格执行 code review，规定良好的分支策略，编写好文档和注释。开发那边成熟的管理方式都摆在那了。但是用不用是我们的选择。

关于这个问题我一直想写个帖子专门说一说的，就是最近一直没时间。你可以看一下我之前写的有一个文章《测试开发之路 -- 喷喷埋雷的事，吵吵代码的情》。 里面提了几点。这个需要依赖良好的代码设计，尽量把所有可能变化的地方都封装起来。这样将来控件变化的时候能做到只改一个地方就适用于所有 case。 不过确实你再自动化前要评估一下这个模块是不是适合自动化。一定程度的稳定性也是重要的。 接下来的就是别怕麻烦，一开始设计代码的时候就别埋雷，好的设计肯定在一开始的时候要多写一些代码，别懒惰，现在不多考虑一些，之后会痛苦死

#37 楼 @tcat 你可以看看我写的监控式数据管理方式，我通过 assertJ 的 changes 概念写了个工具。 自动对比用例执行前和执行后数据库中数据的变化并拼出 sql 语句，将数据恢复回去。

怎么说呢，如果一个想入行测试行业的人问我该学哪门语言，我会说其他语言都可以不学，但是 java 一定要学好。

#2 楼 @wyb199026 感受到了你的无奈~~~ 不要放弃 UI，UI 才是做 somke 的正途~~

额，好像那个极力不推荐关键字驱动框架的人貌似是我。 倒不全是技术原因，除非你团队的成员都不会写代码，否则还是算了。我说说我的感觉吧，你的思路挺好的。不过有几点，咱们探讨一下吧。

• 接口测试开始的时间：现在前后端都是并行开发没有先后顺序了吧？约定好 API 的定义，前端依靠 mock server 就可以自测了。然后约定时间联调，提测。虽然做不到无缝衔接，但基本没有时间说等测过了再联调的。我们公司就是用 RAP 做 API 定义管理和 mock server 的。
• 接口测试的目的：第一点尽早暴露问题是没错的。但那是把它加入到 CI 中才比较有效。 第二点我觉得接口测试执行快，反馈快，建议尽量当成单元测试一样测，出现问题可以迅速找到根源，也不会因为一个 bug block 住之后的流程，加入到 CI 中定期执行，快速反馈，它主要的优势是尽早，尽快找到问题的根源。而不是取代前端的重复性功能测试。他也取代不了
• Jenkins 有邮件报警和 report 展示的插件~ 楼主不用自己写。。。
• 越是底层的东西覆盖率更应该提高，UI 层的反而应该少。所以不太明白楼主说的不要过多的覆盖业务的想法
• POSTMAN、Jmeter、soupUI 都只是过渡，它们的优势本就不是在企业级项目中做自动化的
• 最后关于测试的 report，有很多开源的 report 项目啊。python 的我不熟悉，但是 java 的 reportng，allure-report。都是定制 report 的最佳选择

#3 楼 @jamesparagon 其实理解哈哈，国庆一般都忙，各种应酬么。 我是因为媳妇怀孕了，在北京伺候她才有时间的。

#1 楼 @jamesparagon 额，其实我朋友有个公众号叫 QA 之道，我总在哪上面写

#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 的