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

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

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

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

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

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

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

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

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

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

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

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

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

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

java8 一行就行了

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

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

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

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

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

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

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

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

数据流图了解下

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

软件测试是咋有限资源约束下，如何去尽可能发现缺陷的技术和管理活动，理想的结果是实现测试代价和测试质量的最佳平衡。测个分数相加，竟然要进行穷举测试，我个人认为测试策略就是有问题的。

这么搞的人，要么是外行的要求，要么就是闲的。

1. 自动化的全跑
2. 没有自动化的，可以基于风险来做回归测试策略。根据业务的社会风险、商业风险、系统风险几个维度，分析风险发生可能性和损失高的用例（部分 SB 公司请根据自身风险承受度来做回归）。先做回归，再做自动化测试覆盖。
3. 根据经验查漏补缺

我已经成功打入产品团队，成为了他们的顾问。

安全漏洞:越权修改

上世纪大厂是这么写的吧。。。这玩意儿我们这儿培养测试新员工才这么写。

excel 不好维护。就 xmind 挺好。excel 可以移植过去的。

“人员变动，不方便后续人员测试。”——这算哪门子缺点。非要为这个理由花一倍多的时间写一大堆废话吗？

提了就走，别犹豫，犹豫你就会败北