用例是用例，流程是流程。1、2 没有啥分支流程，本来就只需要个 3 就行。

你把用例理解为业务逻辑 + 断言，用例 1-用例 2-用例 3 就可以拆分成：
用例 1=流程 1+ 断言，
用例 2=流程 1+ 流程 2+ 断言，
用例 3=流程 1+ 流程 2+ 流程 3+ 断言，
用例 3 失败了不就从流程 1 开始走了么。

另外就场景法来说
流程 1->流程 2->流程 3 这个场景属于基本场景，只看正向覆盖，只需要 1 条用例覆盖整条即可。
中间流程 1、流程 2 如果有其他分支应该作为可选场景进行路径覆盖。（比如流程 1->流程 4）

光一个东西的升级、优化、重构就够折腾人了。。。
如果做完不管，那当我没说

没 HC，没楼主的烦恼。人面多了短时间内就麻木了。。。

没点确定？
要么直接 js 传过去不点控件

注册的用例：注册 + 验证
登录的用例：注册->登录->验证
很独立啊，哪个不能单独运行？

单从问题来看，罗列的这些其实是平行越权、垂直越权、XSS 等安全问题，肯定是 bug。只是看你们实际情况是否容忍这些 BUG。如果应用不对外，有严格的安全策略，整个系统价值也不大，接口层不做那些验证其实也可以接受，大家都省点事。

如果有价值，可以从风险考虑，此类 BUG 被别有用心的人利用，会造成多大的后果和影响。（都这样了，估计基本属于不设防状态）

对接口测试来说，也许不会对每一个出现的异常都定义，但是对一类异常应该是有定义的。如果没有做过接口测试，可以从接口开发规范着手，建立起一套质量保障体系。

一些人其实就是在当前混口饭吃，才不管以后有没有饭吃~

虽然很久没接触前端测试，但是你这帖子成功让我想起了当年被兼容性测试支配的痛苦~那会儿就想整个类似的，可惜当年能力不行。给楼主赞一个

你可以选择不看撒，又不是构建一次你就要测一次，如果真的是，让他们给个提测申请，按你的要求让他们填，自己就会降低构建次数了。

看项目吧 有些项目进度要求严 可能就统筹一下。

1. 反馈问题不带情绪，不指向个人，不怕自黑可以把人和自己一起来起来黑，我自己都黑，你就别 JJYY 了
2. 分析问题根因，提出解决问题的办法，别抱着解决人的目的。。。
3. 上升高度，让领导发起，开展类似问题排查总结，往什么 CMMI 之类高大上靠，规范项目流程，提高项目质量，顺便给领导找点事儿做（大概率会坑了自己，谨慎！）
4. 用技术手段做点锦上添花的事，比如回归 bug 自动化，你们设置个提测标准，开发做完自动跑一下什么的，让领导觉得你有技术、有思考、会来事儿

然后这事儿就解决了。

给 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，有人地位高，有人就是不行。