#26 楼 @quqing 真没觉得你说的很清楚，通篇文章都是高大上的专有名词，但就是没写解决什么问题了，问你你也不说。。。。真的，这文档除了你谁也看不明白

#24 楼 @quqing 能举个实际的例子么

#22 楼 @quqing 我已经很用心看了，真心没看明白这个工具能解决的测试点在哪

#19 楼 @quqing 我理解你用自动遍历的方式，随机频繁的点击 UI 上的控件来做驱动测试对么？ 然后监控 http 的 request 和 response。 那你说的规则都是什么？ 篡改 response 和 request？ 断言的也是 response？

#19 楼 @quqing 你没有说你再测什么啊？ 规则都是什么规则? 能举个例子么？

#17 楼 @quqing 能举个例子么？

#15 楼 @quqing 我理解篡改 response 就是 mock server，伪造 request 就是接口测试。我没太看明白有什么本质的不同，为什么不会遇到那些问题，难道 request 和 server 同事全 mock 了？ 能再说详细点么

#4 楼 @hu_qingen 恩恩 好的~

#29 楼 @hustar0102 可以啊，这没什么冲突的

#2 楼 @hu_qingen 额，媳妇已然怀孕了~ 这个阶段实在不想折腾了~~

#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 到家的技术部。。。那叫一个人仰马翻