我跟楼主一样在二线，即然选择二线就不要焦虑，只要工资在二线属于中上水平，可以过的很好，没有很大经济压力、家庭也能兼顾。在一线卷死卷活，只要不是大厂，工资可能就比在二线多 30、40%。多的这点钱跟：“早 9 晚 6”、“周末双休”、“没有较大工作压力”、“兼顾家庭” 比起来，其实收益差不多。再就是即使 35 岁测试职业生涯到头，还有很多其他的事情可以干。

开发如果是容器化技术部署的后端服务，docker 经常用呀，要进去查错误日志、排查服务问题、查测试环境开发提交的版本是否是最新，有时候还要用 K8S 排查问题或者做性能测试时查看节点服务健康度，超过预警阀值会不会触发告警

楼主也可以跟这位小伙子比较下（毕业 3 年，现在 26 岁左右），比他优秀还是比他差一些，有他这能力水平，再积累点业务知识，基本已经超过 70% 的测试了，但是和他差不多的能力的人现在外面很多，再加上这 3 年所有 IT 专业的毕业生，就预计干测试这行的 30% 的毕业生不出 3 年，也能到这个水平，加上这些，你就知道有多卷了

现在 30~35 岁的情况，以前的经历基本不适用了，不如做下沉市场，面向行业，找一些冷门行业，也许还有点机会，之前学习 AI，想着往 AI 行业跳，但是现在有点技术的 AI 岗位，哪一个不是在大厂手里？去大厂做超过 30 岁的大头兵已经不可能有机会了。过了 30 岁，学历、背景、技术能力、业务能力这 4 个维度，抛开大厂的背景，能比 30 岁以下的人唯一有优势的就是业务能力了。

年龄、学历、技术、业务匹配

因为你上了 localhost 的黑名单，要联系小黑子给你开权限

这个：https://www.tsting.cn/get-certified/exam-booking

测试之家的前端页面改版安排起，有无私贡献的前端了，还差一个无私贡献的后端接口，现在发文章好麻烦

特意去搜了一下
问题一：BC 覆盖方法的测试条件
对于输入参数 A（A1, A2）、B（B1, B2, B3）、C（C1, C2）、D（D1, D2, D3, D4），使用基本选择（BC）方法时，测试条件如下：

‌选择每个参数的基本值‌：假设选各参数的第一个值作为基本值（A1, B1, C1, D1）。
‌生成测试条件‌：对于每个参数的非基本值，生成一个测试条件，其他参数取基本值。
‌测试条件列表‌：

A2, B1, C1, D1
A1, B2, C1, D1
A1, B3, C1, D1
A1, B1, C2, D1
A1, B1, C1, D2
A1, B1, C1, D3
A1, B1, C1, D4
‌总数‌：7 个测试条件。

问题二：边界值法结合基本选择法的测试用例
‌参数范围‌：

l ∈ [1500, 1800]（整数）
m ∈ [2, 15]（整数）
n ∈ [3, 25]（整数）
‌策略‌：

‌边界值法‌：为每个参数选择最小值（min）、最大值（max）和中间值（nominal）。
l: 1500（min）, 1650（nominal）, 1800（max）
m: 2（min）, 8.5 → 9（nominal）, 15（max）
n: 3（min）, 14（nominal）, 25（max）
‌基本选择法‌：以中间值为基本值，生成用例覆盖各参数的 min 和 max。
‌测试用例‌：

‌基本组合‌：l=1650, m=9, n=14
‌l 的边界值‌：
l=1500, m=9, n=14（l 的 min）
l=1800, m=9, n=14（l 的 max）
‌m 的边界值‌：
l=1650, m=2, n=14（m 的 min）
l=1650, m=15, n=14（m 的 max）
‌n 的边界值‌：
l=1650, m=9, n=3（n 的 min）
l=1650, m=9, n=25（n 的 max）
‌最少用例数‌：7 个。

你这样说就极端了，做不完加班，无话可说。我指的卷是卷王，那种没事不下班还在那坐着内耗的这种。而且我的说的是技术一般的，不是不行。

一线都这么难，二线更难了，现在是供大于求，先找一个合适的，薪资比预期降低 20%~30%，现在还在招人的公司，大部分不会太差，太差的也不会招人。当然外包公司除外，外包是一直招人。还是有实力的，能收到这么多家公司的面试邀请

银行、国央企、事业单位、政府部门，这些企业都是外包相对而言要舒服点的

看学历不看专业，因为很多 HR 不懂，只看的懂全日制和非全日制

二线城市，测试能过万就不错了，很多公司只要点点点的，6、7 千就能找到。
自动化的、有开发提效工具的、有专项测试的，可以过万，但是有多少公司实际需要呢？

二线城市，好点的公司都是要统招一本了，我在武汉也一样，都是卡学历，不是统招本不要，内推都过不了，最后选择的外包。
建议在二线找工作：不要排斥外包，有的外包很舒服，早 9 晚 5，双休，就是工资和福利都不行，有时候大企业的外包比本地小企业还稳定。

感觉比去年好，今年 2 周至少还能发几份简历出去，去年几个月都没几份

现在非统招本科，内推都没机会投，哎

8 字真言：幽默风趣，勇于搭讪

好吧，我现在需要帮助用户解决他们在公司遇到的一个自动化测试难题。用户已经运行了三年的平台，现在面临一些挑战，尤其是如何提升自动化效率和 KPI，同时他们只有一个高级测试人员负责 QA 工作。

首先，我要理解用户的背景：他们是一个小公司，100 人左右，研发团队 30 人，QA 团队只有一个人，负责高级测试。他们的平台已经运行了三年，目前有 600 个左右的 API 接口需要自动化测试。用户提到每次上线前会运行一次自动化脚本，检查接口响应码和预期结果是否匹配。

当前的问题在于领导希望提高 KPI，而他们想提升自动化效率，但找不到有效的方法或工具。用户的困难是无法找到合适的自动化方案，尤其是因为公司应用迭代快，不适合自动化，但被要求来做。

接下来，我需要分析用户提供的现有情况：

1. API 自动化：已经有脚本处理 600 个左右的接口，每次上线前运行一次。这说明他们已经在做自动化测试，但可能效率较低或不够智能。

2. App 自动化：Android 和 iOS 平台都有自动化测试脚本，每次发布新版本时触发脚本。这部分自动化依赖于手动操作模拟器，可能需要调整包安装和重启。

3. 现有挑战：

   • 领导希望提升 KPI，但用户觉得自动化效率不大提升。
   • 公司应用迭代快，不适合做自动化。
   • 用户自己技术有限，难以找到更好的方案。

4. 领导的需求：寻找新的工具、新技术或总结大会上的展示点来提高业绩。

基于以上分析，我需要思考可能的解决方案：

1. 智能化脚本优化

当前脚本可能是手动触发，逐个接口运行。可以考虑将脚本改为智能触发，比如在某些条件变化时自动检测并执行相关接口测试。例如，如果某个接口的响应码异常或参数变化，自动化测试会自动重新运行该接口的检查。

2. 路径自动化

对于应用端的 Android 和 iOS 自动化，用户已经使用 Appium、Allure 进行测试。可以考虑将这些测试路径记录为可重用的脚本，并且在每次发布时自动触发相关测试路径，而不是手动操作模拟器。这需要让开发团队按照固定的步骤提交代码，减少人工干预。

3. 报告优化

自动化报告的质量和分析功能可能影响测试人员的工作效率。可以利用生成详细的 HTML 报告，并结合机器学习算法，预测潜在的问题或异常情况，提前提醒相关人员。

4. 分散化测试

如果自动化脚本过于集中，可能导致维护困难。可以通过分阶段、分批次的方式运行测试，比如每次发布前仅测试部分接口和关键路径，而不是整个应用。

5. 集成工具

寻找一些集成工具或平台，将 API 测试和 App 测试更紧密地结合在一起，可能实现自动化测试的统一管理和执行，提升整体效率。

6. 智能化测试策略

基于历史数据和结果，可以建立一个模型来预测哪些接口在上线时更容易出现问题。这样，在每次发布前，优先测试这些高风险接口，从而提高整体的成功率。

7. 技术能力提升

虽然现在自动化效率有限，但可以通过学习新工具和技术，提升自己的能力。例如，学习 Cypress、Splunk 等工具，并将其与现有的脚本集成起来，以实现更高效的测试和数据分析。

8. 用户反馈机制

建立一个持续的反馈机制，让用户能够即时了解接口测试的结果变化，并根据需要调整自动化策略。这可能包括实时报告或动态调整脚本触发条件。

综上所述，用户可以从以下几个方面入手：

• 优化现有脚本：提升自动化效率和智能性。
• 整合工具：引入更高效的自动化工具和服务。
• 提升报告分析：生成更有价值的报告，帮助预测和预防问题。
• 分散化测试策略：减少自动化资源的集中依赖。

通过这些方法，用户可以在有限的资源下，尽可能提升自动化测试的效果，同时满足领导对 KPI 的要求。虽然目前效率有限，但通过持续改进和技术学习，未来仍有提升的空间。

根据上述思考，以下是分步骤的解决方案：

1. 优化现有自动化脚本：

   • 分析现有脚本，识别重复或冗余的部分，进行优化以减少运行时间。
   • 将多个依赖的接口测试集成到一个更智能的脚本中，例如使用条件触发（如果某个接口响应码异常，则重新运行该接口的检查）。

2. 引入路径自动化工具：

   • 使用 Allure 等工具记录和管理 UI 测试脚本，减少手动操作模拟器的工作量。
   • 确保开发团队遵循固定的测试流程，将测试作为代码提交的一部分。

3. 提升报告分析能力：

   • 集成机器学习模型或数据分析工具，基于历史数据预测接口的成功率，并生成详细的报告和可视化图表。
   • 提供实时的自动化测试结果反馈，帮助用户快速了解问题并进行调整。

4. 分散化自动化执行：

   • 将自动化任务分散到不同的阶段，例如在每次发布前仅测试关键路径或高风险接口，减少对单一脚本的依赖。

5. 探索集成自动化工具：

   • 寻找能够整合 API 和 App 测试的平台，例如使用 SAPMM 等服务，将自动化测试流程自动化，并生成统一报告。

6. 持续学习和提升技术能力：

   • 投资学习新工具和技术，如 Cypress、Splunk 等，以提升自动化测试的效率和分析能力。
   • 组织内部培训或学习小组，促进团队成员之间的技术交流和共享。

通过以上步骤，用户可以在现有资源限制下，尽可能提升自动化测试的效果，并满足领导对 KPI 的需求。虽然目前效率有限，但通过持续改进和技术学习，未来仍有显著提升的空间。

现在没以前那么影响大了，还是看外包去的有没有大厂背景，外包去大厂，并且一直做了很多年，比不知名的公司做很多年要好

大厂流程都很严谨，但是执行流程的人就一言难尽了

我们是这样

openai 根据需求和模板生成测试用例和通过接口参数生成相关接口测试用例，这些可不是光靠测试可以做到的，产品的需求文档质量、开发的接口 API 质量，这些同样非常重要，羡慕你们有认真负责的产品和开发。

想靠 AI 降本不太可能，高配置的机器、硬件、AI 人才、AI 训练成本，这些加起来花的钱可以请好几个功能测试，花大价钱请的 AI 人才还不一定能达到想要的效果，项目很大概率会失败，即使成功顶多也是增效提质。再如果领导想让搞 AI 的去做功能测试，得被怼到地底，不又得招功能测试，然后呢，就会发现，功能测试人员没少几个，但是多了 AI、高配置的机器和硬件成本、AI 训练成本，最后得到一个年终 AI 在测试行业落地项目评奖的 PPT。

一周运动 3 次，每次运动 1 小时，力量加有氧，到年底发现越减越肥