参考劳动合同，可以起诉违约。建议咨询法律相关人员。

测试项目本身是本职工作，做的自动化这些，不就是为了项目本身做的嘛。

也要看绩效的导向是什么，如果本职工作做得再好，也比不上整花样的，他们这么做我觉得人之常情。

另外对项目本身来说，可能有些属于样子货范畴，但是对人来说，他们有自我实现的需要，有想进步，想不被淘汰，保持竞争力的需要，有技术储备的需要，花一些成本在上面，我觉得也是可以的，理想的情况是能落地，能验收，能持续用起来并进行改进，并且项目因此而受益。

个人觉得可以不用关注他们玩什么花样，只要对项目有益，关注这些花样落地、效果、持续改进方面即可。

现在打工人的新年心愿是身体健康，永无疫情。

内容很 OK，就是图片不够清晰。

有没有一种可能，就是行情不好。

一般 A 用例失败，B 用例都没法进行下去的，其实都是把 A 和 B 写到了一条用例中。

我以为我数学很差，原来比我想象的更差啊。。。

用例是用例，流程是流程。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。。。

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

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