研发管理部、建生总临走前搞的……神兵嘛，我鸡道的
我照着 DPM 做的……现在你们是谁负责这个产品？gaoning 还是 licuifang~

木有木有，我只是仰慕一下蚂蚁高 P 的新工具，那架势要跟阿里云效一较高下

跟 jira 和 tuleap、testlink、redmine、qc 在某些方面都有点小相似

我听以前的一个小 MM 说，蚂蚁招了个曾在 MS 干掉质量部门的 P10 过去，搞了一套新的能效工具，很牛逼啊

业务测试、测试开发、产品开发，没有哪个心不累的，要想心不累，只有混日子捣糨糊了
这三个里面业务测试估计是心最累的，产品开发其次，因为都需要面对产品狗或者用户……

赞一个，不过有一条不是很能同意：
高昂的学习成本，这么复杂的脚本代码我还搞什么工具推广，工具面对的是小白怎么办

性能测试要做好，所需要的技能可能比安全测试还要宽、深（可能有些维度上深度会差异较大），这点学习成本，就不用给做性能测试的工程师们省了
平台的好处就是海纳百川，搜集足够多的信息，也能够灵活快速支持分布式压测，这都是很赞的~另外，如果从测试配置和执行、监控结果中挖掘一些基础的分析和调优建议倒是个不错的思路

那建议你还是坚持要求转业务测试吧，虽然会保持跟你做开发一样的 “压力大，太辛苦”，但是这样从业务测试转测试开发还可以体会到涨薪的快感

除了查 help 文档慢慢啃还有啥好办法吗
我觉得不知所措的都是没耐心仔细去上手去琢磨的，想着一步成为大神呢吧

今夜，我们都是文化人

同意，翻身做主人也是可以的，但是鸡汤有云：主人要有主人的态度，无论锅是谁的，自己没做好就得主动扛锅，不要纠结怎么甩锅……就算是别人的责任，也要想着帮别人改进，这才是主人
其实，我觉得领导可能在高层面前已经自己把锅给扛或者替小弟把锅甩给别人了，回过头来鞭策一下小弟也是有可能的，至于到底如何只能各自猜测了，这取决与大家自己的经历和心理阴暗程度了

那么，case 的确覆盖到了吗？

我合作过的 coder，最常犯的、最愚蠢的而且能反复错的问题：
1、循环外定义变量，内部不做初始化
2、不做 NPE 预处理，出了事就一脸懵逼反问测试会不会操作，换个数据给他立刻吃惊：还有这种骚操作？
3、catch exception 之后不在 finally 里面做事务完整性保护习惯性在 catch 里面做
……

这样就了了……这是习惯不好，跟 IF 没啥关系
另外，非空判断尽量把 null 写左边吧，少一点 npe 的报错~这是写 java 的经验，其他语言就不清楚了~

obj = rpc.getObj();
if(null != obj && obj.isSuccess()){
    doTask1();
    return;
}

doOtherTasks();

他吹牛逼的，我改正反胶倒板老大爷打法了，还没试过呢
不过你能得 6 分，估计搁我这也能及格了吧

你先跟他打打就知道了，槽神什么水平他知道的，反正正常情况下干不过他

蚂蚁杭州新员工陈飞腾，花名不清楚，你先挑战一下他，及格了再来找我

测试是个实践性很强的工作，悟性好的话做个 5 年 8 年之后可能需要看看书，从理论和工程、组织级管理层面拔高一下，悟性不好就没有这个必要了，自动化测试也是一样

两码事，合规、审计属于公司经营层面的事情，会涉足对所有部门的审查，常见的就是财务审计、信息安全审计等在外审之前的操作
我们现在在说的是以测试或者质量技术为核心的技术研发和创新部门

没有人愿意专门去搞质量，都是被动地受产品和项目驱动，受开发技术、框架的驱动，自发的进步从来没看到
这是功利体系必然的结果……阿里有达摩院，没有以质量为核心目标的戒律院吧

鸡哥，啥时候教我横打……

每次听到客户端并发我就醉了，不知道楼主是不是也想干这事……如果不是，跟 app 还是 web 就一毛钱关系都没有了，全都是服务端的并发测试，走接口就行了。

真特么会以讹传讹，手机壳变色这事跟 PA 打架有蛋关系啊，无语……

一看就是猎头，哈哈……

step 是交叉（相互）执行和设计、执行角色分开时用的，自己写自己测，写 step 有点矫情
当然，全量产品用例库建设除外~