使用工具和开发工具还是有很大差别的，自动化测试到测开还有一定距离；学习可以从模仿开始，可以多看看这些优秀的框架是如何设计和实现的

这叫作弊，不叫 bug

曾经跟我老板聊过这个话题，得到的答案是这样的 1.外包里面能力好的概率小，需要花太多时间去筛选，成本大，这个跟只要本科不要专科一个道理 2.外包项目流动性大，不会有太多的沉淀，个人追求普遍较低

你们测试左移做了些啥，为何有那么多 “干等”

不是被开除了吗，还在用"现"？

其实还是缺乏应用场景，不凡试试把工作中的痛点利用这些技术或工具解决掉，做深入；学太杂而没有精通的会让人感觉深度不够，做某方面的专家就好

这种面试官感觉就是在装 X

我们都叫精准测试,测试漏斗挺形象👍

我理解测试和测试开发不应该分的这么细致，只有在业务一线的同学才会感受到测试过程中的痛点，而工具都是从这些痛点提炼出来的；抛开业务测试开发能做的就只有一些通用的能力，而其他的业务同学的痛点感知不到

远程 debug 一下就好吧

“我把工作当成人生中非常重要的一部分，能挣到更多的钱，媳妇才不会在想吃一顿大餐的时候思前想后，才不会看到衣服上的价签望而生叹”

感觉有点策略模式的味道，关键字驱动思想，通过 Map 映射控件和具体的 Action
然后根据不同的控件调用通用方法：Map.get(控件).Set() Map.get(控件).Get()

我一般不用配置文件，而采用 maven-surefire-plugin 自动扫描 Case 的方法运行 Case

  <configuration>
                   <includes>
                       <include>**/testcase/*Test.java</include>
                   </includes>
</configuration>

LR 学习成本相对较高，但是结果分析方面 jmeter 是不能比的

Jmeter 扩展性较好，开发插件方便 (比如一些私有协议需要测试)，至于报告不好看，这个完全可以自己定制（InfluxDB+grafana+Jmeter 的 BackEndListenser）

个人见解：工具无分好坏，适合自己的场景能达到测试目的即是好工具

打包成 docker image 可能会更方便

基于 class 文件字节码修改的 AOP 实现，赞

赞，很有意思

大概能想到以下这些内容：
1.测试数据的准备，并能重复使用

2.支持事务管理：数据还原

3.异常用例的参数组合算法

4.结果校验多样化（body 校验&数据库校验&模糊匹配）

5.测试结果的持久化
.....

接口测试要做的东西还是挺多的

#71 楼 @seveniruby 感谢这么详细的回答。确实如你所讲，技术岗位在薪资和决策力上都存在不足，所以最近在思考是否要转向管理岗位

“” 早年对自己定过一个要求. 不做管理 “”，很想知道是居于什么考虑呢？
我也是偏技术，但是发现不做管理有时很难把自己的设计和想法通过技术实现，而只能按照管理的想法去做事。好的想法固然很好，但是明知道不行，还得去做，有时很无奈

羡慕这样的生活，赞

” 当一份工作变得驾轻就熟的时候我就会开始恐慌，我有一种渴望变化的冲动”

赞，同感！！
不学习点新的东西，就感觉欠缺点什么

楼主这种方式实现不错，但是存在一定的使用成本，依赖用户的环境
可以考虑用 anyproxy 做代理，利用前后端技术提供可视化编辑界面做一个 Mock 平台，动态绑定 Rule 及 Mock 数据可能会更加人性化。

可以自己实现一个 Listenser
public class UiAutomatorTestListenser implements TestListener

然后在 UiAutomatorTestCase 的 run 方法中注册这个 Listenser
result.addListener(UiAutomatorTestListenser）

#4 楼 @testblue 所以你需要 case 管理（case 的执行顺序、执行哪些 case、case 失败了是否重试、测试报告的生成。。等等）
看下 testng 这些框架吧