卷的过别人就去卷，卷不过就躺。只要你不焦虑，就不会焦虑。

以上都是废话，哈哈。小公司的测试想提高，最好的方式就是跳槽。有些公司的测试，其实也就是个 title，没有测试还是照样玩得转~在这种公司，你是没办法提高的。

评审大家都看得懂，通得过，可重用就行。别给自己找麻烦。

转对象之后，按对象是否 equal 来对比就行了吧，我记得 word 转的 document 是包含格式的，另外两个没用过。

先看需求，再看接口类型，对外提供的接口和内部使用的接口，测试策略和方案也不一样。

具体测试来说，先进行正向业务覆盖，把需求中的场景和隐含的正向场景都提取出来一一覆盖。再进行异常覆盖，必填参数验证算异常覆盖的一种。
其他测试根据需求和测试策略来。

接口测试数据，是否要枚举？——普通参数，划分等价类，比如特殊字符、中文，有时候他们是等价的，有时候又不同，根据实际处理逻辑来。（参数是枚举类型，一定要枚举，一般正常场景测试都会覆盖完所有枚举类型，如果发现枚举没有覆盖完，检查下场景覆盖是否有漏掉）

感觉可视化系统才是核心~

量化的东西，初期基本都怀着美好期望的，随着人员流动，团队变化，个人诉求转移，久了必失真，如何长期维持下去很考验水平。

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

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

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

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

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

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

内容很 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 自动化，你们设置个提测标准，开发做完自动跑一下什么的，让领导觉得你有技术、有思考、会来事儿

然后这事儿就解决了。