可以配成 mvn test 吧。。。

这种问题我们一般会在上线评审时看出来，上线评审会对比本次上线和之前的变更内容，包括且不限于所有的配置、文件、包等，以避免这种误修改。

经常能避免什么全局替换，复制粘贴少了个符号之类的问题，挺有效的。（前提是大家都认真对待）

除了通勤这个无法接受，其他都还好，比较锻炼能力。
传统行业的业务没有互联网分享的思维，是比较恼火，只能靠自己一点点积累和钻研了。
多总结归纳，多给人分享你的收获，温故知新。

人会消失，但是工作内容不会，只是分解到其他地方去了。

我们的比例是浮动的，有 1:2 的，也有 1:8 的，1：14 的，根据待测内容，测试人员素质，产品风险，成熟度等综合评估，最高甚至达到过 2:1，花了两倍开发的时间来测试。单纯固定比例，真不好固定，拍脑袋是简单，后面要还的。

学习了。这都能复盘出来，NB。

比如开发 8 个人做 2 周，那 2 个测试该给到多久的测试时间呢
-------看团队质量意识，看测试业务熟练程度，看测试基础建设，看开发自测水平，看集成策略，看研发流程总体质量，看进度要求，来总体评估时间。单纯给个比例没啥意义，是在不行根据你们以前的实际样本采样后来评估，虽然各项都在变化，但好歹也有个参考。

在开发过程中，大家除了熟悉需求、设计用例之外还会做些什么
-------在测其他开发提交的测试，在实现别人 PPT 吹的牛逼。

项目负责人在做排期时压缩测试时间，该怎么说服 ta 给到足够的测试时间
-------从风险作为切入口来谈，测试策略上，保障高风险业务的测试时间，低风险业务提前约定好线上缺陷接受程度。如果又不给时间，又不让有缺陷，资源也不给，那就直接开喷，谁嗓门大谁就 NB，大不了打一架，没准比背锅的结果更好也说不准呢。

只有你能点，只有你知道怎么点，只有你点的好，点点点也会很重要滴。

那就解决自研平台的问题呗。

有些公司质量管理和测试其实是两个维度~

拒绝假敏捷，是兄弟就来砍我。

真敏捷了，生产事故第一责任人就不可能只是测试。

你们这种如果恶性循环了，是团队的问题。意识和认知的问题不解决，会一直这样的。

就是模拟支付成功、失败、超时等微信/支付宝的返回，但是不实际调用微信/支付宝。

就用不同的 json 当数据驱动

专业词汇量够，其实也没必要特意去学。技术类的文档没啥复杂的语法。除非特别前沿的技术，都没有国内有人理解翻译的那种，一般不那么前沿的技术翻译还算信雅达。

嗯，很多时候其实是我们语文水平影响了我们的理解。

测试技术现在都是跟着开发走的~

转了内，短期内会不会遇到被优化的问题，如果有，就不要转，因为这样转了没有意义。
如果转了不会被优化，长远看对自身是好事。

对比两个 json 就行了吧~

内部系统都这样，保障流程正确就不管其他了，反正也造成不了多少损失，大家都承担得起风险。

一般都是证书问题

所以长的文章得配图

先抄，再给自己提需求，再去实现。三步就完事儿

确实太浅显了，哈哈

这顶多叫中文变量编程。。。

中文编程 function、class、return 这种就不要来了撒。

public function 运行 ()
至少也得改成
公共函数：运行（）

学习了，链接的文章很赞。