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

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

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

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

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

java8 一行就行了

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

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

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

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

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

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

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

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

数据流图了解下

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

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

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

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

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

安全漏洞:越权修改

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

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

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

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

自动化测试只是一个手段，要不要测由你自己决定。

随机 9 位（512）+ 随机 8 位（256）+ 随机 7 位（128）+ 随机 6 位（64）+ 随机 5 位（32）+ 随机 3 位（8）=1000？
不知道随机数加随机数算不算随机数

断龙石

Math.ceil(random.nextDouble()*1000) 就行了吧。。。
取 0-1 之间的小数，乘 1000 后向上取整。

对好的团队，在背锅方面，测试报告确实没那么重要了，因为所有的总结、数据都分解到了研发的各个环节，避免背锅也没必要非要用测试报告。

但是作为普遍意义上的准出标准，测试报告还是很重要的，不过形式更灵活，轻便，重点突出，根据团队关注点写上对应内容，体现测试对质量评测的专业性。

对一些互相甩锅的团队，有没有测试报告，其实没多大区别，欲加之罪，何患无辞？