给 UI 用例瘦身，部分用例转成接口测试进行覆盖。

如果不加资源，可以考虑先从以下方面入手：

1. 看现有服务器资源利用情况，如果资源利用率不高，先用满
2. 审核自动化用例，降低重复检测，精简用例
3. 分层，降低 UI 脚本执行比例，提高接口执行比例

学习了。

感觉和我们的测试环境完全是不同维度的东西，哈哈哈

我给个邪门歪道的做法

楼主说的我曾经遇到过，直到测试人员大量离职，测试开发比降到 1:10、1:10+ 后，就没人 BB 什么输出、什么效率了，开发提测质量低，也不敢在我面前 JJYY 了，让干啥就干啥，很爽的。
适当把测试资源降低到预期以下，正所谓 “天之道，损有余而补不足”~~

PS:测试资源充足后，很多时候会找些性价比低的事情干，嗯，以回应某些 “输出不足” 的质疑。

把不同点抽取出来单独配置就行。

另外，线上环境不建议搞自动化测试，要弄也要有完善的经过测试的 teardown。。。

用例不是测试说了算吗，开发懂锤子的用例。。。

还给出没深度的结论，也是醉了，用例只有覆盖的全不全，没有什么浅显和高深之分。

我先来个现实点的：

1. 不被水呲不是人行道应该考虑的功能，属于正常现象——甩锅
2. 想要不被水呲，需要提需求，重新开发——加功能
3. 用户反馈太模糊，被水呲可能受到天气强度，人体体重，踩路面的角度，走路或者是蹦跳的方式有关，复现需要一定时间，期间我们先把人行道封了，禁止使用——配置关闭
4. 基于用户投诉被水呲，我们决定砍掉人行道，防止用户被水呲——产品重构
5. 有人恶意破坏路面——被黑
6. 路面维护人员被裁，路面年久失修——降低人力成本
7. 被投诉呲水的那块砖修复了，至于其他还有没有，发现再说——属遗留问题

回到题目，这题相当于在规模大的系统找到一类 bug，可以分以下几步：

1. 被水呲的砖应该有一定共同特征，肉眼扫描把 3kg 内所有符合此类特征的砖找出来标记好。（静态测试）
2. 扫描完后应该有漏网之余，也就是看着正常但是还是能呲水的砖，不计成本，可以每块砖挨个踩一下。（手工测试）
3. 由于有进度压力，每块砖踩一下花时间，决定加 3000 个人，每个人负责 1 米（项目冲刺）
4. 3000 人成本太高，决定买个检测工具，一个人执行一下就能检查 100 米，裁掉 2970 人。（降本增效）
5. 为了快速监测线上用户问题，决定每隔 100 米增加摄像头，并设置呲水报警系统。（监控报警）
6. 30 个人还是太多，引入智能机器人，每天按时在人行道巡逻，发现有问题的地砖报警，裁掉 29 人。（智能化）
7. 为了避免以后用户被水呲，定期加固地砖。（迭代）
8. 地砖的人行道始终可能导致呲水，决定换成沥青的。（产品重构）

理论上可以帮助完善用例质量，实际操作比较困难。

导致数据在融合的过程中，有一部分数据缺失了某些字段.---------------这不就是测试点之一么~

一点都不爽啊

没有时间约束的情况下，可以根据自己开发大概要用多少时间做依据来预估。
有时间约束的情况下，按自己测试要多久来反向预估。

可能是压力不大，三心二意，啥都想学。
不会坚持的话，真没办法的。
能坚持，哪怕每天一道 LeetCode，一页书，几年后都不得了

单纯工作而已是没有地位之分的。地位只针对人，同样的 titile，有人地位高，有人就是不行。

学习啦

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

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

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

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

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

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

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

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

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

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

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

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

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

可以配成 mvn test 吧。。。

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

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

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

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

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