写，有单元测试覆盖率要求。
还是有用，起码能提高开发的测试意识。

大部分管理者为了自己的绩效，会鼓励多搞花样的，管理层大多认为稳定=死水一潭，必须弄点花活来搞创新，太稳定一个 PPT 不好看，第二会认为你没有能力，没啥存在感。
不过出发点没啥不好，就是落地困难没有持续性的创新，大多变成了花活。

服务器看看连接数呢？

window.navigator.webdriver 改成 undefined 试试

看项目和资源。给资源，让我做啥就做啥。
说实话，部分项目两者表现并没啥区别。有时候先天条件不行，搞敏捷就是个负担。

你的领导有前途并且你要一条路走到黑，就跟着他走，如果你不长久待就去开发。

《软件评测师教程》(第二版) 清华大学出版社。直接天猫进清华旗舰店买就行。
有些错漏，还有些划分右前后矛盾的地方，不过瑕不掩瑜。

倒不是纠结，只是想说这个没啥理论依据（也可能是我孤陋寡闻）。最近看管理方面的帖子，看到过 5% 的淘汰率（我第一次看到是华为的例子，老任说的）。当时有过这样一个思考，对于创业团队，要保持活力，5% 淘汰率绝对不高，但是对于同质化工作、创新乏力的稳定期，强调淘汰率就是卷的开始。当然，这些和帖子的主题无关。

比如公司规定团队必须有 5% 的淘汰率，相信这背后肯定是经过非常多的数据论证的

楼主说经过很多数据论证来着，我不是很同意这点。

作为 CV 程序员的我，早就注意到有些 CV 下来里面就用了这玩意儿打了个水印。。。哈哈

钱少事多 + 强制淘汰的时候，就是你必须溜的时候。

所以作为管理者，要理解绩效管理工具的意义和对企业的价值。比如公司规定团队必须有 5% 的淘汰率，相信这背后肯定是经过非常多的数据论证的，可能不太科学，但这就是公司的制度。尤其是绩效考核，如果大锅饭反而是最大的不公平。

第一句是 OK 的，但是举的例子不敢苟同。
淘汰率绝对是拍脑袋出来的。

此外，使用工具的始终是人，是人，就有偏好，有倾向。好的工具，使用的人不同表现出来的也五花八门。有些东西大家其实都懂，但是操作起来就很难了。

小丑：快乐都是别人的，我只剩下吵闹
牛马：欲做诸佛龙象，先做众生马牛。——PS:同为走狗，至少听起来地位要高点。

不明觉厉~

让你成为行业专家

开发自主优化这个动作是没问题的，定期偿还下技术债务，避免大窟窿。

楼主的苦恼应该是以下几点：

• 最近手上工作很多，开发这玩意儿提测给你增加了工作量
• 开发提测描述模糊
• 要进行主流程回归，工作量很大，不做的话，风险又感觉挺大

开发做了优化，肯定得测试的，这块工作量无法避免。
但是可以要求他们走正常的提测流程，有需求、测试申请、备注改动范围和方法，优先级，上线时间等。这样就可以综合其他任务来进行排期。
以上有了之后，就可以大致的划分测试范围，看看是不是仍然要进行主流程全回归。

说了这么多，其实核心就是做好任务跟踪，每个任务有准入准出标准，有工作量预估，有优先级，有测试资源分配安排。你做的事情都能看得见，统计得到，可以追溯。应该可以减少楼主的一些烦恼。

最后，需要提醒楼主的是，开发 “过一下普通下单流程” 只是建议（除非这是和你商讨之后得出的结论），还是需要你根据他们改动的范围（自己对比代码版本差异也行，不过感觉你应该也没空）自己判断应该测哪些内容，毕竟你才是专业的测试，避免他说测啥就测啥。

收藏了，感谢！

有 YY 小说那味儿了。。。

哈哈，感谢认可，暂时没有打算。

晓光老师您的每篇文章和帖子的回复我都拜读过，学习到了很多东西！

特别是《聊一聊职业发展》，每年我都会回头看一遍，年年都有新的收获。

作为您的前前前同事（我是分子公司的），您的经历也很传奇，我辈榜样~

试试 pm.environment.set("password",JSON.parse(pm.request.body.raw).password),

另外调试可以用 console.log(JSON.parse(pm.request.body.raw).password) 自己先看看能不能获取

包含以下几大块：
1.制度——好的制度能减少矛盾，大家有力一起使
2.资源——没钱没人=想 peach，另外合理的人员结构也比较重要
3.技术——工具上的、平台的、个人的。

我现在听到 “简单” 就头疼。。。简单意味着你的工作是理所当然的。别人的预期和你的预期相差甚远，做完之后可能存在较大的心理落差。而且测试从来都不会仅仅只考虑功能，从质量特性上看，功能、性能、易用性、可靠性、安全、可维护、兼容性等都要考虑。

【假设】微信支持余额支付时，不足的部分可以信用卡补充一起支付，但针对使用余额支付的部分给予 3% 的优惠（直接用于本次支付中）

单就这一句话的业务来分析，就有相当多的场景维度要考虑：

• 微信版本（海外版\国内版\Android\IOS），
• 微信支付的方式（扫码\被扫），
• 是否有支付优惠（红包\直减），
• 支付状态（超时支付、不支付、支付但金额不足、支付超额），
• 结算货币（人民币、外币、混合），
• 支付同时的临时动作（首次开通微信支付、支付时开通免密、支付时查看消息后再支付等等），
• 不足判定的方式、精度，
• 信用卡种类（VISA\Visa Electron (UK only)\Visa Debit\JCB\Diners\MasterCard\MasterCard Debit）及 3DS 认证设置，
• 信用卡额度限制，
• 3% 优惠的精度，
• 优惠方计算，
• 优惠是否可逆可退可改，
• 报表如何展示
• 交易是否可追溯、可核查
• 交易个人信息加密情况
• 交易如果产生纠纷是否可以被证实且不可否认

以上只是我想的一部分，实际上涉及支付的，业务安全和技术安全应该都是重点要考虑的，如果没有预设的背景，发散性的思考，上述维度多条件组合再加上边界值分析，产生的用例可真就多了去了。。。

如果不和年终考核挂钩，建议写成给自己看的总结。
如果要和考核挂钩，罗列数据，然后分析这些数据。

十年了。每天都在想如果发生了战争，我要怎么活下去。

这年头环游世界有风险呀