可以分类

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

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

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

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

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

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

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

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

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

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

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

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

一个 iframe 直接定位即可。

厉害！

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

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

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

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

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

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

你想问的是不是单纯的对比数据，自动化测试显然比人表现的好。

如果是说分布式架构的数据一致性相关，可以从以下几个方面：

1. 早点参与设计评审，从业务出发审核一致性模型，再看看实现是否合理正确
2. 设计专门的数据测试覆盖数据一致性问题（容错和并发数据场景重点考虑） 正所谓 CAP 不可兼得，得根据软件你特性考虑要重点保障哪个，有时候是要为了可用性牺牲一致性的。

先把需求测一遍，再根据完善的需求中规格说明 + 开发的详细设计和领域知识辅助完善场景和用例。

总是存在的话，就不算概率性问题了。能找原因尽量先找吧。

如果实在找不了，评估下这个问题的风险，如果无关紧要，可以写到风险里。如果风险是你们无法承担的，请写测试不通过。

叫抢活了，那只能说太闲了。。。手上事情多的时候，那不叫抢，那叫帮忙分担~
楼主举的例子也不叫抢活，我觉得是去别人的专业领域指手画脚。

1. 单独搞个隔离的干净环境
2. 数据库备份替换
3. 规模小又不影响的话就不回收

价值不需要被证明，你在就是价值。如何提高自己的价钱倒是真的。

如果你的用例已经很完善，每次评审开发打酱油，并且也没有漏测的。这种可以故意写漏几个增强下他们的参与感，如果他们没看出来，那就是态度问题咯。

每次埋个漏洞，大家来找茬，没找到买奶茶。

如果开发确实水平不够（不熟业务或者不相干的人），就别勉强他们来评审了。来评审的，共同对用例质量负责。

这种跟人的主观能动性和经验相关的流程，和团队氛围、公司制度要求、考核、对质量的态度都有关系，想要立竿见影要从多方面下手。

没啥产品说明书吗？方向就是老八样啊，功能、性能、易用性、可靠性、安全、可维护性、兼容性、可移植性。

找到你心仪公司的招聘要求，按要求提升自己就行。

如果自己学习，给自己定几个目标，按时定期提交相应的产出。产出可以是作品、代码、心得文章等等。有产物的学习和自己随便看看随便弄弄是两码事。

如果想系统学习，可以看看极客时间软件测试 52 讲，顺便抽空去考个软件评测师也可，新版教材还不错。

无论是运动还是学习，真的是贵在坚持~