学习啦

我记得 number 类型不支持 maxlenth，所以可以直接输入超过 11 位。不过你后面 slice 了前 11 位，最终可能也就长得不好看，还是能用的。

看了下周围人的标签
令人羡慕的标签：NB、屌、大神
耻辱的标签：拖拉、慢、混子、轴、技术差

有点大。。老实说，真·小作坊花不起这个钱。搞个样子货也没啥意思。

单就安全制度来看，就应该分两层，国家安全制度（各类法律法规，涉外的还应该遵守当地的法律法规如 GDPR 之类）、公司安全制度（安全生产、值班、应急、审计、隐患排查、调查处理）等等。每个都有一大堆东西。

有了制度，得有组织吧，组织结构、职责得有吧，组织内每个人至少得有国家的安全人员从业资格认证吧。

组织有了，得出技术标准吧，安全开发、安全测试、安全运维标准等等得有吧。

标准有了，一些安全组件服务得提供吧，什么基本的 XSS 防御、验证码、数据清洗等等得有吧。

组件有了，得有个统一管理的平台吧等等。

平台有了，是不是也要把整个公司安全意识也要提升起来吧？是不是得组织下攻防演练吧，什么钓鱼渗透也得安排起来吧？

至于你反复提及的安全评审，首先你得保证评审人员有基本的安全素质，都不是安全领域的人，评审不出啥的。

工具而已，哪有什么必须用的。参考工具人

上班没事的时候，进来逛逛都成了习惯了。无论以后多少个十年，祝社区永葆青春

首先，你要让他们体会到写这个是帮助自己，而不是负担。

可以配成 mvn test 吧。。。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

就用不同的 json 当数据驱动

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

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

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

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

对比两个 json 就行了吧~