没怎么接触过，以下是我想到的：

1. 法律法规要求，例如欧盟 GDPR
2. 文化上，有没有踩坑的（这玩意儿最好找个当地人。。。）
3. 外观页面上的，如文本图片信息，有没有错漏、排版等问题
4. 易用性上，符不符合当地人习惯
5. 支付相关，货币类型、单位、支付方式等，适不适合当地人
6. 流程上，当地人的一般信息，是否支持你们的业务，例如注册、登录、验证、找回以及后续运维等等
7. 兼容性上，本地化的浏览器、app、机型等等的验证
8. 架构部署设计上，性能、安全等是否符合要求，特别是不同时区，有没有涉及时间的任务、日志等

先招招人的人，再招人 哈哈

好文！不过向上管理挺难的。特别是整个研发中心都是成本中心的情况下。

1. 挖掘新的质量关注点。比如安全，这个很好推进，一般正常点的领导都不会忽视安全的。安全测试、安全设计、渗透测试、安全攻防、secOps 等等
2. 建设强大有效易用的测试基建。
3. 对个人来说的话，你想获取工作中的正反馈，可以先做点团队里大家都不想干的脏活累活难活，能让这些活不脏不累不难，这就是价值。

一般这种情况有以下几个原因：

1. 开发人员比较闲
2. 业务承担风险能力比较强
3. 测试人员能力比较弱，技术型业务弄不了

测试的价值一直都在，测试人员的价值就得靠自己挖掘了，每个团队测试人员表现出来的价值是不同的。

只是数值上的对比的话想办法获取就行。不过一些前端渲染啊样式这些，还是得靠看。
另外如果重构方案你参与过评审的话，测起来可能更有头绪一点。

如果后端没变，仅仅是前端展示有变化，做个前端 diff 测试就行了吧。

本来该长一样的数据，结果变了，一下子就出来了。

可以问问自己以下两个问题：

1. 经过评审后的需求（如果有）是否明确要做验证？
2. 如果不做验证，会产生什么风险，这些风险是否可控？

有 SQL 注入风险，可以用 SQLMAP 扫一遍，用安全缺陷说话。
有功能上的缺陷，可以用功能缺陷来说话。

设计上的问题，我们可以给建议，但是建议最好有事实的依据，毕竟你不是产品，也不是设计者。

没测试过，不过如果我遇到，我应该把一些差不多大小的文件改成测试的图片音频格式直接上传来验证边界。
至于是否会产生文件损坏以及其他啥的，那是另外的测试了。

可以分类

1. 流程规范 你们的研发周期有哪些环节，每个环节测试要组织或参与哪些活动，要有哪些产出，测试准入准出标准等
2. 文档规范 测试计划规范、用例规范、报告规范、缺陷提交规范等
3. 工具上的，比如缺陷记录、测试管理等工具要用啥
4. 技术上的，自动化测试的一些规范，如结构、语言、质量标准等，安全测试的一些规范，如常态化安全测试、安全扫描等等

还有些比如线上测试规范、测试数据管理、环境管理规范等等

本来就不是一个东西。
不过实际工作中，有些可能是描述上的问题，我们产品爱用并发用户数来描述性能，因为他们关心的是客户端用户情况，他们对服务器处理能力说实话有些没有太大的概念，在他们看来是一回事儿。。。所以提的性能指标需求翻译过来可能就是线程数。

但是做性能测试和分析的人得知道差别。

可以从短期和长期结合来考虑：

1. 短期是否会因此涨工资
2. 长期是否能显著提升你的竞争力

两个都不搭边，就是来白嫖的。

你们这种情况做做接口自动化回归就行，变来变去成本太大。

这么霉。。。另外都要解散了还招人的公司也无语的

如果被裁了，裁员是被淘汰还是被动涨工资，取决于你的实力~
如果不想被裁，取决于运气加实力。运气不好整个业务都砍，那真没辙。

语言用的溜，常见算法 OK，实习期熟悉下研发流程的各个环节，各种规范，用到的工具和技术就行，这些才是你实习期该积累的经验，其他的学习都是长期的过程。

积分来了，不整个头衔 + 成就？

一个 iframe 直接定位即可。

厉害！

啥 app 还要获取你来电信息？大概率有侵犯隐私的风险

领导让干啥就干啥呗，除非又让你干活，又不给你时间，还不给你钱。

套一下开发的一本书，《用例整洁之道：编写优雅的用例》？
老实说，同等质量的用例，评价哪个更优雅比较主观。。。

交付时间长短和造成长时间服务中断也没什么联系吧？有些东西难点交付周期长点，很正常。
如果这里的交付时间是停机上线时间，那当我没说。

个人觉得交付时长和质量挂钩不是很准确，用过程质量中的进度把控比较好。

制裁只能说是给国产软件机会。应用级软件可替代的很多。