能找到更好的，肯定去啊，，人是不能太安逸的，否则，淘汰的第一批，一定是生活在安逸且舒适的这批人

你在哪个地方工作，具体需要看你在哪个城市吧。

很多时候，前端开发，都是组件，直接从别的地方复制过来，可能改都没改，所以，组件的问题，可能性还是很大的

先排除，是输入框，限制了输入内容吧，，，有的输入 ，只能输入数字什么的，你输入中文，当然不可以

第一个，开个用例评审会，把测试用例过一遍，比如：登录功能测试用例，就需要评审这些测试用例，是否对登录功能进行全面的覆盖，覆盖测试需求点，如果都覆盖了，那就符合标准的测试用例；
第二个，就是评审一下，操作步骤，预期结果，期望结果，是否便于执行，是否规范等；
第三个，最好做一个版本管理，一旦，确定测试用例了，就封存，然后，如果线上出现问题，就根据这些测试用例，来查找，是不是漏测，是不是哪个测试需求点没有校验到，还可以看出，是否按照测试用例严格执行；

这是转发哪里的

不写测试用例，直接测

你是开发吗？还是项目负责人，，我很好奇，有这样的一种需求场景，，是单独成立一个项目吗？然后你是怎么分配前端和后端的开发任务的？

1. 冒烟测试
2. 校验业务场景【重要】
3. 再校验关键字段的，边界值（最大，最小）
4. 看返回的字段，是否符合需求
5. 为空校验，一些关键参数，必填项肯定是要校验一下，比如，客户表，客户名，手机号，如果这两个字段的数据，都没有，那么后面的业务逻辑，可能会异常，所以，该校验还是要校验必填的
6. 对于数字，金额，是否可以为 0（购买数量），是否可以小于 0（金额）

提醒：

1. 类型校验，基本上没必要，输入，字段是数字类型，你输入个字符串，其实没有必要测试，因为前端那边几乎不可能传一个字符串，除非是通过接口测试工具调用的

另外，我个人觉得，你的执行能力很强，从需求场景的构思，再到方案的决策，再到具体的实现，最后的推行实施，离不开一个关键人物，就是这个体系搭建的负责人（你的文章，没有提及，所以，如果你是负责人的），我会觉得，你的能力真的很 OK。

哈哈，我觉得，现在越来越内卷了，，滑水摸鱼，似乎变的越来越难了。

这样做，对于团队，企业，提升，是有益处的，总之，优点大于缺点。

不过，我觉得，最难能可贵的是，从构思，到实现，再到落地，并能够在实际工作中展开，是非常不容易的。

离不开，每个小伙伴的支持与配合，我还是相信，你这套体系，会越来越完善。

我觉得最好的方式，就是完全剥离和工作考核，仅不作为参考，也不作为依据。

可以只作为，兴趣提升平台，可以在月度，季度，年度，对榜上优秀的，奖励一些小礼品什么的。

还可以设计成匿名天梯积分，到年末才会公布具体名单。

一旦剥离了和工作之间的关系，这个就变成纯粹的兴趣爱好，那么，对于个人来说，是有好处的，但对团队是否有益处，这个不好判断；

这种标准化，量化，刷分是不可避免的，所以，就不存在，一定 “准确” 和一定 “公平” 的情况。

最终，我的个人观点，还是一样，天梯积分，要么和考核挂钩，要么和考核毫不相关，因为你一旦出现，要么相关，要么不相关的复杂联系，程序是没办法主观判断（无法做到公平公正），最终还是需要人去主观判断（就一定会出现情绪判断，谁和我关系好，谁和我关系不好），这样还是会回归本质，并没有实质性解决根本问题。

其实，只要有排名，就一定会有漏洞。
初衷是好的，不过，我倒希望，这种天梯积分，可以对绩效起到引导作用，而不是决定性的作用。

首先，调岗、降薪都属于劳动合同的变更。
一、调岗如果公司有合法理由，是可以调岗的，不过要保证调岗不具有惩罚性、针对性、侮辱性。

二、降薪必须要经过员工同意，如果未经同意强制降薪，那就属于克扣工资了.

其次，针对公司强制调岗降薪，我们要如何做？
其实有两种方法。

一、要求公司恢复原岗位和工资。

做好取证工作那是必须的，在证据充分的情况下，给工资发函，要求公司按照劳动合同约定提供劳动条件和薪资待遇。如果公司不理会，那就申请仲裁，目标只要求恢复原岗位和薪资。这样不论胜诉还是败诉，劳动关系都不会被解除，也算为自己留一条后路。

二、以未提供劳动条件及克扣工资为由申请被迫解除劳动合同。

这种方法有何弊端，就是一旦仲裁等失败了，劳动关系就解除。所以没有十分的把握和证据，不要轻易的用这种方法。一般是先发函告知公司限期改正，如果公司不改正，再发函申请被迫离职，接下来就是去申请劳动仲裁，会要求公司支付经济补偿金。

你就明白一个点，，现在公司缺人吗？答案：肯定缺，，但是缺的是你这种吗？你值得深思，如果你可有可无，别人随时可以替代你，那么，你工作当然难找；其实，每天都有大量的公司，招不到人的，所以，找工作的难度，放在任何一个时候，都是一样的，从来没有变过。

首先，要先解决你的脚本稳定性吧

元素定位，是否唯一匹配，且稳定

这跟程序，关系不大，你提供一个精准的定位，程序当然会按照你提供的去找，，如果都找不到，那肯定会报错，所以，不存在什么误报，，问题还是存在你的脚本，元素定位的处理。

有几个点优化一下

1. 添加元素加载完后再执行，获取元素
2. 可以适当添加 sleep，强制等待，因为操作太快的话，也容易出错，所以会牺牲一点执行效率，换取稳定性
3. 多使用多组合的定位方式，确保能够精准定位到元素
4. 可以添加，异常处理，让异常情况，不直接打断程序运行，输出错误日志即可

robotframework，说实话，操作是比较复杂的，，他每条测试集合，都要手动导入一些数据，，太麻烦了，，，不过，界面 UI 的操作，，确实方便了没有代码基础的测试人员，，，不过，，实用性太差

大数据测试，没有本科学历，就不要碰了；
web 技术，你还得学前端 + 后端，，学习成本是非常高的，如果你有大量的学习时间，是可以尝试的；

笑死，你领导不会是看到了，rootframework 吧

游戏测试，没那么复杂，，就是写用例的时候，会比较费脑，你要考虑游戏的各种参数，，难点在测试用例，，如何全面覆盖测试点，所以，对游戏的逻辑，装备，各种情况，，需要一个比较深入的了解。

什么 app 测试，，最开始都是手工点点点，，不存在什么技术性吧。

app 测试，顶到天，就是用 monkey 压力测一下，，自动化是用 appium，但是也用不到游戏测试。

一般年底了，，都不会有人辞职的，一个是为了拿年终奖，，一个是要过年了，有假期，不香吗？

还有一个就是，在年底招聘的公司，一般都有问题，一个是人员突然辞职，为什么会突然辞职？所以，要么员工有问题，要么是公司有问题。

所以，年底是最不好找工作的，年后估计可以。

你那个 demo 网址，打不开，能否优化一下，，，我体验看看

一般直接找开发，协调，要么取消验证码，要么给万能验证码

逆向思维

为什么一定要用 excel 呢，可以向 httprunner 借鉴一下，，使用 yaml 作为数据格式，，每一条测试用例，就是一个 yaml 文件