#34 楼 @quqing 后端测试场景 2

这个不是在该 request？

#32 楼 @quqing 我真的是仔细仔细再仔细的看了。一共就这么几句话。 但是这几句话里充斥着各种高大上的名词，就是没说到底解决了什么问题了

#30 楼 @quqing 这个跟我理解的有什么区别么？ 不是修改 request 和 response 么？

#26 楼 @quqing 我这么说一遍吧，看看我理解的对不对。这个工具的目的是通过自动遍历的方式（假设就以自动遍历为例子），自动的频繁的点击 UI 上的控件。触发接口调用，你的工具在监听 app 的 request 和 response。你可以截获这些报文做修改，假如特意让 response 里返回特别大的数来 check UI 做边界值测试，也可以修改 request 传入特别大的值。这样你来做接口测试和 UI 测试对么？ 不知道我这么理解对不对

#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 的最佳选择