有期权可以拿吗

钱挣不够的，人生苦短，开心最重要，总有挣不完的钱，对越来越老的技术人员时间比金钱珍贵太多，创业去吧

做录制回放，类似的系统无法穷尽，看测试策略，项目紧张的话做主干覆盖；资源充裕的情况下，可以构造数据跟输出，输入规则做对比；
抽丝剥茧，基础功能测试、线上数据的复制构造、大数据的压力；这样基本就能保证了

这里 hadoop 是 docker 资源管理用的 mesos 吗？

中小型公司应该会的 ，大型公司不好说

#104 楼 @seveniruby 不少大厂喜欢从小厂里面找开发，让他们做测试倒是真的。互联网企业测试技术发展和人员发展也是挺快的，未来人只会越来越贵。记得十年前狼厂主推自动化测试的时候，就由 cto 发表了一系列言论，意思是公司 QA 只会做手工测试，测试周期太长，以前招聘的门槛太低，要提高招聘门槛要提高测试待遇。公司业务的发展，也是有生老病死的过程，业务启动的时候做为一个 demo 可能就不需要测试，发展到一定程度用户激增的时候产品体验就很重要测试的价值也很明显，到了产品的稳定器，测试框架本身都固定，添添补补用例的事情，自然是谁可以做。专职测试投入。测试和产品一样存在生老病死的周期。测试这个事情本质上是怎么根据业务发展阶段，去针对性的制定质量保证的解决方案，选择用人去堆业务，还是选择自动化的层次用技术方式实现，都是具体测试策略，策略本身也依赖技术选型和技术工具，依赖于团队的技术实力。

测试行业经过自身的净化洗涤会有新生. 典型的变化就是薪资从以前的 3k-15k 的范围, 整体提升到 1w-3w 之间. 主要是房价也涨了很多倍，然后公司的业绩也增大了很多倍

这个薪水匹配这个职位，应该会是学院派

#4 楼 @seveniruby 还有灰度发布，不然直接把用户当小白鼠了；端到端测试虽然土，但是很直接的验证方式

屌

#9 楼 @seveniruby 没有漏测是很多质量团队首要目标，互联网公司的质量保证归根结底是又好又快的实现版本的发布，不同的行业不同的阶段对 bug 要求也不应该是一样的。对新人来说，熟悉业务的阶段，发现 bug 多少确实可以是一个考核标准，当已经成为业务熟手以后很难说还有什么用处。相反的，以前听过某个通讯行业公司的分享，不光通过 bug 考核 QA 也同样的考核开发，而且双方的 KPI 是背道而驰鼓励对立的，提 bug 的行为被称为上甘岭，双方反复争夺，这样去倒推开发去提高自己的代码质量，测试去尽最大可能的发现验证代码质量。

QPS、lantency、数据正确性
性能信息：内存、cpu、句柄泄露、网络负载

#7 楼 @yunbin_7 jira 里面能定义执行 shell cmd 的话就可以，jenkins api 可以直接支持 resul api 格式

#3 楼 @yunbin_7 就是用 jenkins 自己的定时调度就可以，设置一个虚拟的头结点，然后触发我们真实的调度作业，里面再通过 jenkins api 驱动，jenkins 的 python 版本 api 很完善，可以通过 buildWithParameter 进行任务触发。其中有获取 text 的配置，可以获取到全部参数信息。

流程、理念、技术、工具都很重要，如果平台能沉淀这些东西就更好

对于第一点，确实可以改进，先提交过去再轮询，jenkins api 都已经提供，再去调用一下就可以；
难和易是一方面，使用习惯上现在大多都依赖于 jenkins，不少大厂自己都做了 jenkins 替代产品，基本上能满足自己需要都不错了，能拿出来的很少，开源自有其生命力；
我们当时也遇到过一个 jenkins 的 bug，自己绕过去都能解决，最后升级 jenkins 影响面也还好，一年升级一次也不麻烦；
目前暂时能满足业务需求，我觉得 jenkins 最大的问题是没有中心数据库，master 上面的数据都保留在本地 master 的磁盘上面，这样导致很多时候不得不再通过 resful api 绕一层，如果有更好的东西当然欢迎

我部门采用 master 模式进行开发，从提交代码开始做限制，代码提交时候评论必须按照规定写，跟 bug 系统任务系统打通的，表明这次代码提交是跟那个任务相关的；然后每次提交都相当于是在这个基础上进行的；每个提交的代码都必须有人 review 过才能 ci，ci 以后会进行校验，首先是自动编译，然后是运行 ut，没有问题以后才进入主干。定时任务每间隔三个小时运行一次，进行 deploy，运行 p0 级别 ft，失败邮件告警然后人肉处理。

我擦，公司挂壁了？

多个任务能运行到一个机器上面吗

任何工作都需要衡量投入产出的关系

xmind 就差不多了，缺点是不好管理，最好是测试代码跟随业务代码，这样其实也能比较好的进行积累

占坑