1、和产品对齐口径，避免开发和你理解的存在歧义
2、常规同比，环比，增长，减少，增长率，这些插入指定数据，执行程序，查看结果，确认逻辑无误；
2.1 2024 年 9 月打款金额为 0，2023 年 9 月打款金额 100，同比增长程序是否计算正确
2.2 2024 年 9 月打款金额为 100，2023 年 9 月打款金额 0，同比增长程序是否计算正确
2.3 2024 年 9 月打款 100，2023 年 9 月打款金额 50，同比是增长计算正确；2024 年 9 月打款 50，2023 年 9 月打款金额 100，同比是增长计算正确
2.4 数据库用于存储计算结果（打款金额）字段属性设置是否合理，够长吗？最大能存储的数字和业务产生的比较，谁大？
2.5 数据报表是实时统计还是每月底 11:59 分结束统计，在这之内的数据是否全部统计在内
2.6 程序计算的结果需要展示到第几位小数，后边的小数是直接舍去，还是直接进位
3、查看 SQL，逐字逐句分析 SQL 是否存在不合理的写法（设置的筛选条件对不对）
4、数据是读取的 TIDB 库还是 MYSQL 库，不同库，有的 MYSQL 无法正常执行

是二线城市，先找找看；也会去北京碰碰运气

同情吧，买的期房，还没交呢，已经降价啦，哈哈哈
我要是有大佬你的履历，裁员不过是些许风霜罢了

女朋友在北京，我不会离太远的

UI 自动化，对变动频繁的项目没有用，用例需要不断的调整以适应项目的变化，ROI 太低，我们是一周一发版，最后都放弃 UI 自动化；
对于变动频繁的系统，自动化的收益都不高，优先保证已经不会变动的核心流程，使用接口自动化结合覆盖率工具一起去保证测试质量
如果是 go 语言我记得有框架，可以输出，每次调整影响的返回，可以根据这个确定回归范围
《最近几周线上经常发现漏测的 BUG，是不是该搞自动化了》
和开发明确测试范围，范围之外的 BUG，你不需要负责，先明确责任范围

1、冒烟测试就是主流程走的通，例如登录注册页面测试；最起码新注册（或登录）一个账号流程走的通过
2、测试用例这个事，还是要写的，毕竟你不能在这个公司呆一辈子，还是要考虑以后的，这个也是对自己能力的一种提升
3、不同产品，有不同风格，所以需求有大有小，例如登录时候加一个可勾选的用户协议算一个需求，也有整个登录注册模块也算一个需求；
4、没有问题，标准最好对齐下，避免开发有疑问，对高优先级的 bug 不上心
6、都挺好，分享一个很好的思路：尝试用代码实现你想的自动化形式，尝试有什么思路都用代码实现

《因为之前看到论坛里有说不要把缺陷数量化这种类似 kpi，我担心写了之后上级会盯这个数量》，先确认里 BUG 等级，根据等级去列出数量，有问题就和领导沟通，消除疑惑，不用防着他，前提他是个正常人，好沟通

第一个测试，太爽了
1、可以考虑建立提测标准；开发自测到什么程度，才能达到提测标准；前期你可以写冒烟测试用例，开发慢慢接受之后，就让开发自己写，自己做
2、一定要写测试用例；描述好测试点，前置准备、执行步骤、检查点等，用例要评审，这样用例没有覆盖的部分，出现 BUG 你就不是主责，对测试结果，最好留存截图，防止甩锅
3、BUG 数量是一定要提的，这个是测试工作价值最直观的体现，你是第一个测试，公司也在观察你这个岗位的价值，作为公司第一测试，统计所有需求/BUG，计算出一个需求平均产生多少 BUG，以后测试工作完成后，根据平均值算下，低于的，就需要回去再看看
4、建立 BUG 等级（BUG 质量），可以抄网上同类型公司相关 BUG 的等级（一般根据上线之后，触发 BUG 造成影响划分）
5、建立用例留存，防止相关功能改动，测试不是原负责人，抓瞎
6、尝试建立自动化体系；先用现成 Jmeter，Postman（后期购买或自研），快速回归，划分上线核心场景（上线必回归）

赞同，最好是有同类型产品的相关用户画像参考一下

1、最重要是通过官方数据统计网站确认中国市场手机型号的市场份额，以及用户画像，两者结合分析，重点覆盖哪些机型；
2、最简单最省成本办法 - 员工内测，公司内测版 apk 可以获取手机型号，进行兼容性测试，收集遇到的 BUG，以及已经覆盖了哪些机型
3、花💰-腾讯的性能狗，付费测试，还有报告可看。