测试的价值在于被测对象的沉没成本。
测试的能力体现也是在被测对象的 NB 程度，甚至可以说是平台能力的体现。NB 的多是团队和平台。

当然，把别人吹的 NB 实现了，你就是有能力的人。

做这个的目的是啥？如果是你的 KPI，将就做呗，管他用不用的起来呢

工业 App 理论上应该更重视测试，只是管理人员不重视吧。。。

兄弟，每次你名字我都看成花泽香菜。。。

死道友不要死贫道，人之常情，特别是大龄团队，背锅=影响收入=可能失业=一家人没饭吃，非常焦虑。但是如果开发和产品的工作靠 bug 来导向，那肯定是团队出了问题，考核和指标的设置也可能已经变质，一个团队共同利益都没，就是外包的个体，确实谈不上共建，不内卷已经不错了。

长短连接只是三次握手的区别吧，排除网络因素，一般两个都行。
另外 conn reset 要保证客户端和服务端统一的连接配置（特别是 Nginx 这种默认客户端长链接，对服务器短连接的）。

门门通 + 一门精 + 适应变化。

开发：你行你上
测试：爬开老子来
这种程度就行。

质量是共建的，不是测出来的。出了线上问题，大概率团队本身也有或多或少的问题，盲目归结于某个人的原因，要么缺乏对质量的认识，要么就是管理水平低劣。对质量毫无作用，下次还会再犯。

当然，该反思还是要反思。
测试为什么没测到？——这是质量把关者应该考虑的问题，不逃避。
开发为什么犯这么低级的错？——这是生产者也要考虑的问题，不忽略。

只问测试不问开发，或者只问开发不问测试，都是有问题的。

当团队所有人都重视质量的时候，质量才会越来越好。（任何一个人不重视，他的质量就是团队质量的上限）

合理，可以根据这个设置准入标准。

max_area =a_area + b_area< (a_area + b_area) * 2 也相交？

另外都给了左下右上的坐标，还平行于坐标轴，直接判断两个左下和另外两个右上的关系不就行了。

没做过，不过再多的场景，等价类、分类树一分，就化无限为有限了。

PC 端如果没有针对性的需求，我一般不管分辨率。

如果经常出错，尽量还是花大力气整理一下规则。梳理好了进行自动化。

换个思路看，其实也算配置规则的测试没考虑完全。

这不是兼容性测试的一个环节吗？

java8 一行就行了

System.out.println(
LocalDate.now().equals(LocalDate.now().with(TemporalAdjusters.lastDayOfMonth()))
?"最后一天":"不是最后一天");

覆盖所有基础重要功能。其他根据资源情况来。

一次性提测的功能太多就这样，建议开发再次细分，多次少提。

看团队吧。对项目影响是积极的有益的。但对个人来说，上升空间≈阻断。

就是对定义测试的范围和需求，选择的测试方法，制定测试启动、停止、完成的标准和条件进行评审。

测试资源充足的时候，做不做还不是你自己主观的事。

首先看团队有没有组织级测试策略，说明压力测试、安全测试等测试的归属方（例如专门的团队），
如果没有，可以根据自身风险承担情况，要求项目负责人或者决策者给出意见。

正常情况下，一个接口要不要做压力测试，应该是在测试策略评审的时候就确定了，可以避免你说的问题。

数据流图了解下

具体的问题已经忘记了，但是有一个问题仍然是我过不去的坎。做来帮助自己工作的，非要我写个收益率分析，体现了什么价值，还要搞分享。我特么分享给一堆玩手机的开发有什么意思。。。