谢谢答复。
说实在的我还是不大能理解为什么这么做，所有类似 Jenkins 的 master-slave 模式应该都可以支持调度和资源利用最大化的目标，而至于所有人共用一套测试库（测试依赖？测试用例？），有什么情况是不共用的能否举个例子呢？至少我觉得无论用 git 还是 svn，这一套始终都是唯一的，所有的 slave 端获取到的都是一样的啊，为了节省网络开销和磁盘使用？
你所实现是否是将这一组库分割、分不到不同的 slave 上，执行需要依赖不属于当前 slave 的库的时候就通过代理去它所在的 slave 上去执行或者说获取呢？你是将对于一次完整测试执行来说的集群行为换成了分布式？

额，十几年前就有的分布式测试执行现在都流行叫云服务么？

哈哈哈，强迫症……
你对 mybatis 用法有误解，感觉你好像在说 hibernate

我以前写过一大套，后来用 mybatis 之后全删了代码
所以搞不清楚背景，框架用起来有什么毛病呢，非要自己费劲封装

这个看你们喜好吧，不争辩，建议你还是去看看正交覆盖法、all-pairwise 算法，然后回头再来审视自己的做法

all-pairwise 难道已经被人忘记了么
靠随机，还说能保证覆盖率？

哈哈，这个观点逆历史潮流而动啊
没有 ID 和 name 的确麻烦，但是要说发生变化，组件层次变化比 id、name 变的概率高太多了，用 xpath 有两条：
1、写法上技巧要求很高，用绝对路径的 9 成 9 都要中招，常常修改，楼主写的好像还是不错的；
2、效率的确就是最差，无容置疑~
综合起来，其他方式能解决的就用其他方式，尤其是 id、cssselector，逼不得已用 xpath 也是可以的

什么叫压力测试中的负载环节？

我理解压力测试和负载测试是性能测试中的两个不同的切面：

• 压力测试：在限定的资源下，短时间给系统加载过量的并发用户，并持续与系统交互，看系统什么时候被压跨，可以快速得知系统的最大容量；
• 负载测试：逐步加压，在极限负载且系统能够稳定运行（吞吐量曲线被水平拉直，系统未发生失效和超出容忍度的失败率）的情况下，观察系统的各个性能指标

好吧，.net 的世界充满了荆棘~

哦，我第一印象就是 java

ojdbc、mybatis 这些还不够你用吗？

长大的长沙~
曾哥的曾今~

屁股决定脑袋，等你自己混到 leader 的位子，你肯定会改变很多想法。比如，招人、面试这事，等你一年看够 1000 份来自不懂行的 HR、猎头的简历，只能抱着试试看的态度来看个很不起眼的简历，还幻想着引入外援来改变现有的团队状况，我不信你还能那么耐心，而且有时候你看到的攻击性的面试、交流……也是大厂面试必须有的一环，看你如何解决冲突和逆境处事等等~

再熬几年，等到 5 年、8 年，你再回头看看，很多想法会已经改变，不过你对测试、对流程的看法都是三观较正的

训练预期结果跟训练出需求好像没啥区别了吧

这个也需要匿名来说？

不能，多搞点虚拟机就行了

你这个观点比楼主的还要让人觉得无厘头，消极到家了

这个还是要看个人能力，无论是开发还是测试，新来的要树立自己的威信是需要时间和努力的，而且怎么分配他们的工作也决定了他们能够成长成什么样
早先几年外包还是很不错的，只要团队价值观、氛围 OK，都可以培养，我在平安科技的时候，中间因为团队拆分、扩张，一次性转入（变为正式员工）了 3 个初级外包，都是口碑不错的，后面也证明他们的确具备成为骨干的潜质和能力，而且还有一个邀请其加入人家因为不准备在上海长期发展而拒绝的~

测试有事，那是你们自己的责任，不赖流程

是的，的确更 low

我只是吹个牛逼，我才不会傻到去创业呢，哈哈哈

沙漠中间栽下一棵树，枯死只是迟早之事；即便有足够的资源让它能够永久地生存下去，而它除了给路过的摄影师的构图上增添一分绿色气息，便再也没有其它存在的意义了。如果要想它能够长久而有生命力地活下去，并期望它能够改善生态，那就需要将其根植在一片密林之中。自动化测试，尤其是前端自动化测试，如若离开其他层次的自动化测试和技术手段与之相互配合，便会如同这棵沙漠中间的树一样，不久便灭。

赞！不得不说我老了，想跟上时代，什么都去学一点已经不可能了……
所以我劝年轻人还是把基础搞好一点，感叹~

老陈当年还拉我们一波人一起搞了个社区，他做 QTP 比作 LR 其实还多，后来因为他创业疏于打理，也就荒废了
他也算自动化测试这个活里面的老湿傅了~

你说的是 git 的作用，不是 git 客户端~