接口这块，我有个疑问就是，我现在的公司就接口方面，一般情况数量级也没有那么夸张，异步的需求好像也没有那么高吧，另外异步虽然比较高级，但是同样也带来了编码和后期问题定位的难度！你是处于什么考虑用异步来做处理的？你是准备后期增加 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 测试报告中建议还是增加一个导出功能，方便后期人工相关的筛选和统计