接口这块，我有个疑问就是，我现在的公司就接口方面，一般情况数量级也没有那么夸张，异步的需求好像也没有那么高吧，另外异步虽然比较高级，但是同样也带来了编码和后期问题定位的难度！你是处于什么考虑用异步来做处理的？你是准备后期增加 mooc？然后持续集成开发的单元测试吗？

你好， 看了你的思路， 你这个全程通过异步的方式来请求 http，这种的接口测试，你是不是未考虑接口关联这种特性，感觉你的这种方式好像只适合单接口的各种字段参数验证呀？

原来如此，谢谢指导！

共勉作者，很明白作者的体会，个人就来说下个人的理解：
招聘公司层面上：

1. 公司对于测试职位的刻板印象：就国内的不说所有，但是 90% 的公司对于测试的理解还存在可替代，技术能力低，点点的刻板印象中，这个从测试的薪资待遇，晋升机会等都会有所体现
2. 测试的专项方面： 性能，安全，测试开发， 这些方面实际上虽然说是测试的专项分支，但是从另外一方面这个职位何尝不是开发，运维等一切相关性的职位的分支？，好比如果一个公司需要测试工具开发，同样的工资为什么不招聘一个开发来？
3. 测试的工作方面： 虽然很多的大咖级别的互联网公司下的测试部门在拼命的转型，但是我们要明确的他们之所以有这个能力和决断我觉得离不开公司和部门的支持，最常见的一点大量的功能测试外包等等。而对应一些小公司，测试部门实际上很少有这个能力和决断来进行部门全方位的提升（因为提升太好，就代表着离职率越高）
4. 公司测试部门提供的技术栈需求和市场就业需求的偏差：比如你之前的公司也许是一个 C# 的公司，现在你跳槽到了 Java 的，想想自己后期的就知道，从头来，并且之前的 C# 随着时间的推移，能记住都怪了

个人层面上：

1. 缺乏自驱动力： 我们的同僚很多时候，就会在一个公司的业务里面沉浸而不可自拔， 想想有的测试能再一个业务线干 7.8 年都不跳槽，而实际的工作就是功能测试，这种情况在内地里面尤为明显。我自己也是这两年才觉醒，虽然不算太晚，但是感觉已经和上面落后一大截了
2. 工作中的主观能动性：我记得很早之前我的态度就是公司给多少钱，自己就做多少事情， 虽然这个说法上面没有问题，但是在公司层面上面你就会缺少大量的上位机会，同样待遇也不会有变化，
3. 家庭方面：随着结婚生孩子等一堆家庭事宜， 实际上会发现会越来越觉得自己在学习方面越来越懒惰，各种精神压力等

当然说的是理由，但是不能成为不进步的借口。 在此也共勉和我有相同困扰的同僚，一起加油吧。

你好，问一下你的属性拦截器中的，return target_page(self,_driver) 是如何得出的，按照代码来看你的 target_page 只是一个局部变量， 可是你返回的是一个方法， 这块如何理解？

你把房子过户给我吧，花呗和债务就算了。不过你 gameover 之前，一定要给我留一份过户税，不然估计你给我房子，我还给不了过户税。

这年头测开，不说自己写过 xxx 框架，感觉自己都不够格，也许这个框架自始至终只跑了登录

从平台角度来说。参数化可能需要考虑的更加全面点。期待方案的出炉

第一点实际上就是一份数据库脚本，用于支持你自动化执行的依据，实际上可以理解备份数据库，当然如果从项目角度来说这个可能没有那么大的体会，我们公司一般一个项目中间可能存在一定的间歇期，所以我一般都会备份数据库脚本，第二点的参数化，我觉得九豪大神的思路很好，我也我实现了一个简单的，但是有点粗糙，

自己最近也在写 api 的一些测试框架， 所以对 api 刚算是入门吧， 说一下自己的建议吧：
1 建议后期维护一份对应项目下的数据库备份来支撑你的 api 自动化测试，否则你的 api 平台只能说有点一次性产品的感觉，这种情况主要 体现在关联依赖的部分接口中，
2 未发现你的的接口参数中对于参数化的部分支持，比如一些 url 或者其他 header 等中可能就存在参数化的值，（当然可能你的支持但是我没有找到吧 ），常见的就是 token 参数化，这个如果接口一个一个修改还是很麻烦的。
3 测试报告中建议还是增加一个导出功能，方便后期人工相关的筛选和统计

1. 大部分情况是公司问题，测试职位的产出不明显，高层接触少，导致很难有大的表现机会
2. 个人原因的话就是自己的能力或者说优势和公司的发展不符合，比如公司希望一个技术男，可惜你是业务男，甭管你业务多强，就测试职位来说，就很难给到你相应的待遇
3. 第一印象差，可能在公司的表现给直属领导第一印象不好，导致了后期再多的补救都无法胜出

九毫兄你好 ， 咨询你个问题，就是你的这些 json\yaml 文件最后你是如何组织的呢？比如 A 接口需要 B 接口的响应数据，你的 hrunner 是通过参数化来实现了接口数据的管理，但是你是如何来控制 B 接口一定会在 A 接口前执行呢？ 目前我这边考虑过的方案一种是类似 unitest 这种通过 test_number 编号来排序，还有一种就是给 json 文件夹一个 tag 来判断是否有一个前置接口，可是两种情况 y 一个需要测试人员对接口的依赖关系和执行方面特别熟悉，然后才能有效排序， 另一个会增加 json 文件中的复杂度，特别是如果存在嵌套依赖的话

你的意思是，相当于本身就有个测试库脚本，这个脚本里面有需要接口测试的基本的一些前置等数据， 2， 接口管理你是通过控制接口顺序然后通过 mongo 的存储，然后从这些地方进行获取是吧，好的，谢谢，我这边想用 mock 来代替接口关联，但是我又害怕这种情况下又无法反应出接口的数据流转，这种方式是否可行呢？

关于你这个平台中，1，运行测试任务的时候，你的数据库中是默认将用例中涉及的数据都维护好了吗。还是说你的数据库是默认新的库，然后数据库的操作在用例中动态生成。2.你是如何处理接口测试时的接口关联的呢？能分享下经验吗。

我也很纠结基础数据问题，不知道你后面有没有新的方案，解决基础数据问题，我是想实现数据库的数据我们自己动态生成，然后这样就不用担心数据问题了，但是这种的还没有摸清如何设计，初期有个想法就是每个 case 前都增加一个初始化，特别是增删改查这种的 case，

不用管别人怎么说，工具能出来就有用武之地，虽不能各种场景覆盖但是对于一些特定环境下，还是不错的选择，如果后期你的工具玩的足够熟，你待遇不会一些写代码的低，玩代码只是说让你在测试这块增加一种手段。

为什么说写死呢？不明白你的理解！

自动化测试特别是 ui 方面，这玩意，我不知道国内究竟普及到啥程度了，反正我接触的中小企业来说更多的都是叫好不叫座！如果从小项目，用例更多体现在流程而不是覆盖率式的单元测试的话，个人觉得表格应该也有自己的用武之地的，当然如果用例规模很大，表格的一些参数化维护反而容易把数据和业务代码脱离特别厉害！

你在用这个 locust 和 jmeter 的时候，有没有遇到过最终输出的结果 tps 和服务端的 cpu 相差特别大的时候， 我这边测试同一个的环境中的同一个登录接口。最终查看服务端 java cpu 使用率 2000%，而用 locust 的时候 ，1 个 slave 的时候 100% 左右，开了 4 个 slave，也就在 200%，按照这个比例，难道我要开 N 个 slave，才能达到有效的 cpu 占用率吗。如果这么计算的话，我想问下，这个 locust 适合什么样的场景和平台进行测试呢？

能问下你跑的 300 左右的场景是什么？另外就是你有没有用 jmeter 查看过登录的 tps 和响应时间，你用 500 个线程去跑，如果你的 tps 并不足以支撑你的这个并发的话，你跑再多的线程组都没有用吧，他实际的并发数应该是小于这个线程组数的。

难道你不觉得，测试做到最后就是开发，开发做到最后也就是测试？ 殊途同归。只是两条路不一样，开发是具有非常鲜明的系统性，阶段性的宽广大道。测试属于具有非常高的机动性，多样性的阳间小道。但是最终的终点是一个。开发测试工程师和测试开发工程师，只是大家因为出处不一样，更加会在意你的 “” 出生地 “”

大神的文章通读下来，实际上每个人都有深有体会，特别是我们这批老测试，而且还是在三四线城市的测试，国内现在测试行业的断层实际上非常严重，不论是从公司角度，还是从测试行业角度。
那我这边有几个问题就是：

1. 楼主你认为测试的技能提高主要是依托于公司平台还是依托于外部个人自学能力？
2. 对于国内大部分公司来说，测试的职能的普遍低估，楼主是如何处理这类问题（由于从业内地，大部分公司都是小公司），如何提高公司领导层对于测试的地位？
3. 测试也细分了很多的专项测试，楼主认为：从测试的个人发展来说，是专项测试发展更符合，还是全面的系统测试发展更符合未来要求呢？
4. 至于说到测试开发（能力超高）默默的问下，这个级别的，是否已经脱离了测试范畴，而是隶属于开发职能呢？或者说，无论测试还是开发，大家属于殊路同归？开发最后也是测试，测试最后也是开发？

上线的标准是否适合，应该从多方面去考虑，比如你的项目是属于项目性质还是产品性质，针对的客户的性质以及数量大小，使用的频率等等，另外功能的后期影响的大小。根据这些东西，然后综合判断当前测试项目的 bug 情况，再提出是否具有上线的能力，至于说衡量自己的工作完成情况，完成是一方面。完成的质量是另一方面。说个真的，测试的工作很难量化和成果化