处理闰年时间相关的问题在软件开发中是常见的，特别是在处理日期、时间计算以及有效期管理时。密钥缓存时间计算错误如果与闰年有关，可能是因为程序未能正确处理 2 月的天数变化或者在进行日期递增或递减时没有考虑到闰年的规则。

以下是一些排查和预防闰年相关风险的步骤：

1. 代码审查：

   • 对涉及日期计算、有效期管理和缓存逻辑的代码进行详细审查，确保在处理 2 月份日期时考虑到了闰年的情况。
   • 检查所有使用到java.util.Calendar、java.time.LocalDate（Java 8 及以上版本）或类似日期类的地方，确保它们自动处理了闰年。

2. 单元测试：

   • 设计并执行针对闰年的边界条件测试，包括但不限于：
     • 平年 2 月底至闰年 2 月初的缓存失效问题。
     • 闰年 2 月 29 日相关的特殊场景，如密钥在这一天过期后是否能在 3 月 1 日正常更新等。

3. 集成测试：

   • 使用历史上的闰年日期数据作为输入来模拟实际环境中的情况，比如 2000 年、2004 年、2012 年和 2020 年等。
   • 如果产品有 API 接口，可以通过伪造请求头中的日期来进行跨年测试，模拟不同客户端系统时间对服务器缓存的影响。

4. 工具辅助：

   • 利用持续集成/持续部署（CI/CD）流程中的自动化测试工具，编写脚本生成各种边界条件和极端情况下的测试用例，覆盖闰年及非闰年的转换点。

5. 设计改进：

   • 考虑重构代码以抽象出一个统一的日期处理模块或服务，该模块应包含一个经过验证且能够正确处理闰年的日期计算方法。
   • 不依赖于系统当前时间进行缓存逻辑判断，而是根据缓存创建时间和设定的有效期限进行计算。

6. 模拟环境：

   • 虽然云服务无法直接修改系统时间进行测试，但可以搭建隔离的测试环境，并在数据库层面对时间戳字段进行临时篡改，模拟闰年边界跨越情况。

7. 监控和日志分析：

   • 在生产环境中增加额外的日志记录，以便捕获与日期相关的异常和临界值行为。
   • 分析过往的用户反馈或内部日志，查看是否有闰年交接时出现的问题迹象。

为每个问题提供更具体的例子：

App 测试实例：

• 安装测试：检查 app 在不同操作系统版本和设备上的安装过程是否顺畅，包括下载、安装包验证、安装进度及成功后图标是否正常显示等。
• 弱网测试示例：模拟网络环境为 2G/3G，在这种情况下，检查 app 的加载情况（如列表刷新、页面跳转）是否能够适应并给出相应的提示。

Python 多态性实例：

class Animal:
    def speak(self):
        pass

class Dog(Animal):
    def speak(self):
        return "Woof!"

class Cat(Animal):
    def speak(self):
        return "Meow!"

def make_sound(animal):
    animal.speak()

dog = Dog()
cat = Cat()

# 多态性体现在这里，虽然传入的是父类引用，但调用的是子类的方法
make_sound(dog)  # 输出: "Woof!"
make_sound(cat)  # 输出: "Meow!"

显式等待与隐式等待在 Selenium 中的例子：

• 显式等待：

  from selenium.webdriver.common.by import By
  from selenium.webdriver.support.ui import WebDriverWait
  from selenium.webdriver.support import expected_conditions as EC
  
  wait = WebDriverWait(driver, 10)
  element = wait.until(EC.presence_of_element_located((By.ID, 'dynamicElement')))
  

• 隐式等待：

  driver.implicitly_wait(10)  # 设置全局隐式等待时间为10秒
  element = driver.find_element(By.ID, 'dynamicElement')  # 自动等待元素出现或可交互
  

定位 alert 弹框的实际代码：

alert = driver.switch_to.alert
alert.accept()  # 接受弹窗

定位动态元素示例（假设一个新消息会在页面中动态加载出来）：

# 使用显式等待定位动态加载的消息元素
wait = WebDriverWait(driver, 10)
message_box = wait.until(EC.presence_of_element_located((By.CLASS_NAME, 'new-message')))

left join 和 inner join 示例（使用 SQL 查询语句）：

-- LEFT JOIN 示例
SELECT Customers.CustomerName, Orders.OrderID
FROM Customers
LEFT JOIN Orders
ON Customers.CustomerID = Orders.CustomerID;

-- INNER JOIN 示例
SELECT Customers.CustomerName, Orders.OrderID
FROM Customers
INNER JOIN Orders
ON Customers.CustomerID = Orders.CustomerID;

Python 面向对象编程实例：

class Person:
    def __init__(self, name, age):
        self.name = name
        self.age = age

    def introduce_self(self):
        return f"Hello, I am {self.name} and I am {self.age} years old."

# 创建对象
person1 = Person("Alice", 25)
print(person1.introduce_self())  # 输出: Hello, I am Alice and I am 25 years old.

# 继承与多态示例
class Student(Person):
    def __init__(self, name, age, grade):
        super().__init__(name, age)
        self.grade = grade

    def introduce_self(self):
        return super().introduce_self() + f" and I am in grade {self.grade}."

student1 = Student("Bob", 16, 10)
print(student1.introduce_self())  # 输出: Hello, I am Bob and I am 16 years old and I am in grade 10.

1、关于 app 测试，您的回答基本正确。在测试过程中确实需要关注安装与卸载流程、权限管理、弱网络环境下的表现、后台切换及进程杀掉后恢复情况、安全测试（如数据加密、防止注入攻击等）、稳定性测试（例如 Monkey 测试）以及专项性能测试，比如耗电量、流量使用、启动速度、页面跳转速度、内存消耗、内存泄漏检测、CPU 和 GPU 占用率等。同时，针对界面和功能的测试也类似于 Web 端。

2、Python 的多态描述得较为准确。多态性是指允许你使用一个接口处理多种类型的对象，即同一种操作作用于不同的对象会得到不同的结果。例如，在继承关系中，父类的引用可以指向子类的对象，当调用具有多态性的方法时，实际执行的是子类重写的方法。

3、对于显示等待与隐式等待的概念阐述正确。显式等待是在代码中明确指定某个条件满足时继续执行，否则持续等待；而隐式等待是 Selenium 中设置全局等待时间，系统会自动在元素查找时等待指定时间，若超过这个时间还没找到元素则抛出异常。

4、定位 alert 弹窗的方法无误。通过 driver.switchTo().alert() 可以处理 alert、confirm 或 prompt 等弹窗，并使用 .accept() 接受或 .dismiss() 关闭弹窗。

5、定位动态元素的部分存在混淆。动态元素是指在页面加载后或者用户交互过程中才生成或变化的元素。定位动态元素通常采用以下策略：

• 显式等待：根据预期条件（如元素可见、可交互等）设置等待；
• 使用 xpath、CSS 选择器或其他定位方式结合动态属性值来定位；
• JavaScript 执行命令获取动态元素；
• 轮询检查元素是否存在。

6、left join、right join 与 inner join 的区别解释正确。left join 返回左表所有记录，右表匹配不到的数据为 NULL；right join 则相反，返回右表所有记录，左表匹配不到的数据为 NULL；inner join 只返回两个表的交集部分。

7、Python 面向对象的概述比较笼统。面向对象的三大特性包括封装、继承和多态。在 Python 中，可以通过定义类来创建对象，类包含了属性（数据成员）和方法（成员函数），实现对现实世界问题的抽象建模，同时支持多重继承和 Mixin 类等灵活的面向对象机制。

找了一圈，确实没有删除按钮

以下是对类似 Keep 运动轨迹功能进行详细测试的步骤及可能使用的工具：

1. 单元测试：

   • 对处理定位数据、计算速度、距离、消耗卡路里等算法编写单元测试用例，确保输入不同经纬度坐标序列时，输出的距离、时间、速度计算结果准确无误。

2. 模拟 GPS 信号工具：

   • 使用如 Robolectric（Android）或 Xcode 自带的 Simulator（iOS）中的模拟定位服务来生成不同的运动轨迹场景。
   • 在 Android 设备上，可以使用LocationManager.addTestProvider()API 设置模拟 GPS 提供者，并通过setTestProviderLocation()更新模拟位置信息。
   • 对于 iOS 设备，在模拟器中可直接修改模拟位置，或者在真机调试时利用 Core Location 框架提供的 CLLocationManager 的 simulateLocation(_:) 方法模拟 GPS 数据。

3. 集成测试

   • 设计一系列模拟轨迹场景，比如：直线路径、环形路径、折返路径、室内外切换等，模拟用户步行、跑步、骑行的不同速度和方向变化。
   • 验证 APP 能否正确捕获并记录这些模拟位置变化，同时检查路线绘制是否平滑、里程统计是否精确。

4. 实地测试

   • 携带多款手机实际行走或骑行预设路线，与专业 GPS 运动手表或 Google 地图等权威应用对比轨迹准确性。
   • 测试各种环境下的表现，例如高楼林立的城市区域、开阔地带、隧道、桥梁等可能导致 GPS 信号不稳定的情况。

5. 性能测试

   • 通过长时间持续记录轨迹以及频繁切换地点，监控 APP 的内存占用、CPU 使用率以及电池消耗情况。
   • 测试大量数据同步至服务器的速度和稳定性，特别是在弱网络环境下。

6. 兼容性测试

   • 在多种型号和系统版本的设备上运行 APP，包括主流品牌和老款机型，确保轨迹记录功能在不同硬件配置上的表现一致性。

7. UI/UX 测试

   • 检查轨迹展示界面的用户体验，包括地图加载速度、轨迹线条颜色和样式、暂停/继续记录按钮响应、缩放和平移地图时轨迹显示的流畅性。
   • 验证轨迹回放功能，检查是否能按时间轴顺序准确重现实时运动路径。

8. 异常处理测试

   • 强制模拟 GPS 信号丢失、恢复以及错误数据输入，验证软件对异常情况的容错机制和提示信息是否合理。

9. 自动化测试

   • 利用 Appium、Espresso（Android）、XCUITest(iOS) 等自动化测试框架编写脚本，模拟 GPS 位置变化和用户操作，自动化执行轨迹记录和展示的功能验证。

10. 回归测试

    • 在每次迭代或发布新版本前，重新运行关键的 GPS 轨迹测试用例，确保新功能不影响原有功能的表现。

我也没做过类似的，我帮你问了下 AI

在银行等对数据安全性要求极高的行业，确实无法直接在生产环境中进行压力测试或使用生产数据进行模拟。但是，为了模拟真实的生产环境以及处理几亿条级别的大数据量压测，可以采用以下策略：

1. 数据生成工具：

   • 使用专门的数据生成工具如 TPC-H、TPC-DS 等来创建与生产数据类似特征的虚拟数据集。这些工具可以根据业务规则和数据模型生成大量随机但结构合理的数据。

2. 脱敏数据迁移：

   • 对生产环境下的实际数据进行严格的脱敏处理（去标识化），确保敏感信息被移除或替换后，将脱敏后的数据复制到测试环境中。

3. 子集抽样：

   • 如果数据规模太大，在保证测试效果的前提下，可以抽取生产数据的一个有代表性的子集，并通过扩展该子集来模拟大规模场景。

4. 数据合成：

   • 利用统计学方法分析生产数据分布特性，然后根据这些特性合成新的数据集，保持数据分布的一致性。

5. 集群模拟：

   • 在非生产环境搭建与生产环境类似的硬件配置和软件架构的大数据集群，以模拟真实世界的并发访问和处理能力。

6. 性能测试工具：

   • 使用 JMeter、LoadRunner 或其他适合大数据系统的性能测试工具，构造复杂的负载场景，模拟大规模并发用户行为和海量数据处理流程。

7. 日志回放：

   • 分析生产环境的日志记录，提取出关键交易请求和行为模式，编写脚本并利用工具进行日志回放，以实现接近真实情况的压力测试。

8. 容量规划：

   • 依据现有的业务增长趋势和系统指标，预测未来的数据规模和处理需求，以此为依据设计测试用例和场景。

在所有操作过程中，务必遵循相关的法律法规和公司内部安全规定，确保任何涉及到生产数据的操作都符合隐私保护和数据安全的要求。同时，与项目经理及相关部门紧密协作，确保整个测试方案得到批准并在可控的安全环境下实施。

统招专升本属于全日制本科教育的一种形式。这里的 “统招” 指的是通过统一招生考试录取的方式，而 “全日制” 则意味着学生全天在校学习，和普通本科生一样接受正规、系统的高等教育。

尽管统招专升本与直接通过高考进入本科阶段的学生在就读方式和学制上有所不同（专升本通常需要先完成三年专科再读两年本科），但一旦成功通过统招专升本考试并被录取，其后的本科学习阶段确实是全日制性质的，并且最终获得的学历也是国家承认的全日制本科学历，在法律地位上与四年全日制本科并无本质区别。然而，在实际操作中，社会上对于专升本和四年全日制本科的认知可能会有差异，尤其是在就业市场上可能存在不同的评价标准。不过，随着教育政策的完善和用人单位观念的变化，这种差距正在逐渐缩小。

2024，共勉

这个问题可能是由于 StaleElementReferenceException 异常引起的，这意味着当 Selenium 尝试操作一个元素时，该元素在 DOM 中已发生改变或不再存在。在微前端框架（如 single-spa、qiankun 等）中，由于其动态加载和渲染机制，可能会导致这种问题。

针对这种情况，你可以尝试以下策略：

1. 使用 ExpectedConditions 配合 WebDriverWait 来等待元素可交互状态：

from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

wait = WebDriverWait(driver, 10)  # 设置最长等待时间
element = wait.until(EC.element_to_be_clickable((By.XPATH, "//div[@id='app-alarm-search']/div/div[1]/div/button[1]")))
element.click()

1. 在执行点击操作前，确保元素仍存在于 DOM 中，可以先检查一下元素是否可见或者是否存在：

def is_element_present(xpath):
    try:
        driver.find_element(By.XPATH, xpath)
        return True
    except NoSuchElementException:
        return False

while is_element_present("//div[@id='app-alarm-search']/div/div[1]/div/button[1]"):
    element = driver.find_element(By.XPATH, "//div[@id='app-alarm-search']/div/div[1]/div/button[1]")
    if element.is_displayed():
        element.click()
        break

1. 如果上述方法仍无法解决，可能需要深入理解微前端框架的渲染机制，并根据实际情况调整定位和操作元素的方式。例如，在微前端应用完全加载完成之后再进行元素查找和点击操作。

身体保护好，赚钱的机会有的是。

在使用测试框架（如 PyTest、unittest 等）编写自动化测试用例时，推荐采用多个独立的测试方法（如 test_case1(), test_case2(), test_case3()），分别对应不同的测试点。原因如下：

1. 可读性与维护性：每个测试方法只关注一个特定的测试点，使得测试逻辑清晰明了，方便阅读和理解。当某个测试点需要修改或排查问题时，不会影响到其他测试点。

2. 原子性：每个测试方法应当是独立且完整的，即每个测试用例的成功或失败不应依赖于其他测试用例的结果。如果将多个测试点放在一个测试方法中，一旦其中一个测试点失败，可能导致整个测试用例失败，无法准确判断其他测试点是否正常。

3. 报告粒度：在生成测试报告时，每个测试方法的结果都会单独体现，有利于快速定位问题所在。

4. 并行执行：很多测试框架支持测试用例的并行执行，如果每个测试点都是独立的方法，那么可以同时进行测试，提高测试效率。

综上所述，建议按照第一个示例的方式组织测试用例代码。

然而，如果你有一些测试点是紧密相关的，或者需要在相同的测试环境下进行多个测试，你可以考虑将这些测试点放在同一个测试用例中。但即使在这种情况下，也建议尽可能将每个测试点分开成独立的测试用例，因为这样可以更好地组织代码，使其更易于阅读和维护。

总的来说，建议每个测试用例只关注一个特定的测试点或功能点。这样可以使你的测试代码更加清晰、可维护和可扩展。

二宝，恭喜

点赞，祝越来越好

@debugtalk 找框架的开发者问问

可以考，虽然在 IT 行业没有什么用，多学点总不是坏事情

针对你的滚动查询和删除问题，以下是一些优化建议：

1. 滚动查询优化：

• scroll 时间设置：2m 的滚动时间可能较长，这会占用更多的资源。你可以尝试将滚动时间减少到 1m 或者更短，看看是否会影响数据处理的稳定性。理想情况下，滚动时间应该足够长以处理一批数据，但又不能过长以免占用过多资源。
• size 设置：你目前设置为 10000，这个值可以根据你的系统性能和数据处理速度进行调整。如果处理速度较慢，可以尝试减小 size，比如设置为 5000 或 2000，这样每次处理的数据量会减少，可能会提高处理效率。但是请注意，减小 size 会增加网络通信的次数，需要找到一个平衡点。

另外，你可以在处理数据的过程中记录下处理时间和数据量，根据这些信息来动态调整 scroll 时间和 size。

1. 数据删除优化：

• 使用 _delete_by_query 时，添加 conflicts=proceed 参数可以避免因冲突而导致的删除失败，这是一个好的做法。
• scroll_size=10000 参数用于控制每次批量删除的数量，这个值可以根据你的系统性能进行调整。如果你的系统能够承受更大的批量删除操作，可以适当增大这个值，但要注意不要过大导致系统压力过大。
• wait_for_completion=false 参数表示异步删除，这是正确的做法，可以避免长时间阻塞等待删除操作完成。

如果你发现数据量太大导致删除失败，可以考虑分批删除或者在数据生成后立即进行删除，以减少数据积累。

哈哈哈，笑死我了

以下是一些可能的解决方案和建议：

1. 滚动查询优化：

   • 增大批次大小：在滚动查询时，尝试增大每次查询的数据量，但要注意不要过大导致内存问题。
   • 优化查询语句：确保你的查询语句尽可能高效，避免不必要的字段检索和排序。
   • 使用 scroll 参数：Elasticsearch 的 scroll API 可以用于高效的批量数据检索。它允许你在一段时间内保持搜索上下文，这样你就可以获取大量数据而无需多次重新计算得分。但是请注意，scroll 查询可能会占用更多的内存。
   • 分布式处理：如果可能，将数据处理任务分布到多个节点或实例上，以提高处理速度和减少单个节点的压力。

2. 大批量数据删除：

   • 使用 Delete By Query API：Elasticsearch 提供了 Delete By Query API，可以用于根据条件删除大批量数据。你可以设置一个定时任务，在每天的特定时间执行删除过期数据的操作。
   • 考虑使用 TTL（Time To Live）：为索引中的文档设置 TTL，这样 Elasticsearch 会在文档过期后自动删除它们，无需手动删除。
   • 分批删除：如果一次性删除整个索引或者大量数据导致性能问题，可以考虑分批删除。例如，每次删除一定时间段内的数据，或者限制每次删除的数据量。

3. 数据保留策略：

   • 确定数据保留期限：根据业务需求，明确数据需要保留多久，然后据此制定删除策略。
   • 使用 curator 或类似的工具：Curator 是一个开源的 Elasticsearch 索引管理工具，可以帮助你自动化一些任务，如索引备份、 rollover 和删除过期数据。

对于 CPU 高和 load 高的问题，除了上述的优化措施外，还需要检查服务器的硬件资源是否足够，以及 Elasticsearch 集群的配置是否合理。可能需要增加硬件资源，或者调整 Elasticsearch 的 JVM 参数、索引分片数等配置以优化性能。

理论上，本地是可以搭建一个类似 Copilot 的编辑工具的，但这需要考虑以下几个关键因素：

1. 训练数据：Copilot 的强大之处在于它基于大量的公开代码（如 GitHub 上的代码）进行训练。如果你的项目代码没有上传到 Git，那么你无法利用类似的海量数据进行训练。但是，你可以尝试使用你的本地项目代码和相关文档作为训练数据，尽管这可能会限制 AI 模型的能力和准确性。

2. 模型选择和训练：你需要选择一个适合代码生成的 AI 模型，如 GPT-3、GPT-4 或其他开源变体。然后，使用你的本地项目数据对模型进行训练或微调。这可能需要相当大的计算资源和专业知识。

3. 集成到编辑器：将训练好的模型集成到你的代码编辑器中，如 VSCode、IntelliJ IDEA 等，以提供代码补全和建议功能。这可能需要开发插件或者使用已有的框架和库。

4. 自然语言交互：如果你想实现类似 Chat 的自然语言交互来查找和调用函数，你可能需要在模型之上构建一个对话系统。这可能涉及到自然语言理解（NLU）、对话管理（DM）和自然语言生成（NLG）等技术。

以下是一种可能的实现方案：

• 使用你的本地项目代码和相关文档作为训练数据，训练或微调一个代码生成 AI 模型。
• 将训练好的模型部署到本地服务器或者使用本地运行的 Docker 容器。
• 开发一个编辑器插件或者使用现有插件（如 LSP 插件），将其配置为连接到你的本地模型服务器。
• 对于自然语言交互部分，你可以考虑使用像 Rasa、DialoGPT 或其他开源对话系统框架来构建一个能够理解和响应测试用例编写需求的对话系统。

需要注意的是，这种方法的复杂性和效果取决于你的项目规模、代码质量、可用的计算资源以及团队的技术能力。与 Copilot 相比，本地搭建的工具可能在代码建议的质量和广度上存在差距，但针对你的特定项目，它仍有可能提供一定的辅助作用。

你的测试逻辑已经相当详细和全面，以下是一些可能的优化和补充建议：

1. 自动化测试：你可以考虑使用游戏测试自动化工具或者编程语言（如 Python、Java 等）编写脚本进行自动化测试。例如，可以编写脚本自动执行布阵、战斗、检查 BUFF 和 DEBUFF 等操作，并自动比较预期结果和实际结果。

2. 数据驱动测试：你可以创建一个包含各种卡牌组合、技能参数、战斗环境等因素的数据集，然后使用数据驱动的测试方法来遍历所有可能的情况。

3. 性能测试：除了功能测试外，你还需要考虑性能测试。例如，测试在大规模战斗中，技能的触发和效果是否仍然正常，游戏的帧率和延迟是否在可接受范围内。

4. 异常测试：测试在各种异常情况下，技能的效果是否仍然正常。例如，网络中断、游戏崩溃、卡牌被移除等情况下，BUFF 和 DEBUFF 是否正确清除。

5. 回归测试：每次修改或添加新的卡牌、技能、羁绊等元素后，都需要进行回归测试，确保现有的功能没有被破坏。

6. 使用专门的游戏测试工具：市面上有一些专门的游戏测试工具，如 Unity Test Tools、Unreal Engine's Automation Tool 等，可以帮助你更方便地进行游戏测试。

7. 与开发团队紧密合作：测试人员需要与开发团队紧密合作，了解游戏的设计和实现细节，以便更准确地定位和解决问题。

以下是一些更具体和有价值的建议：

1. 使用游戏测试框架：例如，对于 Unity 开发的游戏，可以使用 Unity Test Framework 或者 NUnit 进行自动化测试。这些框架可以帮助你编写和组织测试用例，自动化执行测试，并提供详细的测试报告。
2. 创建特定的测试工具或脚本：你可以与开发团队合作，创建一些特定的测试工具或脚本。例如，一个自动布阵和战斗的脚本，它可以模拟各种战斗场景并检查结果。另一个例子是一个技能效果检查工具，它可以实时监控和分析游戏中的 BUFF 和 DEBUFF 状态。
3. 采用灰盒测试方法：除了功能测试（黑盒测试）外，还可以结合一些内部知识（白盒测试）进行测试。例如，了解技能的实现机制和公式，可以帮助你设计出更有效的测试用例。
4. 实施持续集成和持续测试：将测试集成到开发流程中，每次代码提交后自动运行测试，可以尽早发现和修复问题。你可以使用如 Jenkins、Travis CI 等工具来实现持续集成和持续测试。
5. 进行性能和压力测试：使用性能测试工具（如 LoadRunner、JMeter 等）模拟大量用户并发战斗，检查游戏在高负载下的表现，包括帧率、延迟、内存占用等指标。
6. 进行兼容性和设备测试：确保游戏在不同操作系统、浏览器、设备和分辨率下都能正常运行。可以使用云测试平台（如 BrowserStack、Sauce Labs 等）进行大规模的兼容性测试。
7. 进行用户体验测试：除了技术测试外，也要考虑用户体验。可以通过用户调研、A/B 测试等方式收集用户反馈，优化游戏设计和平衡。
8. 建立详尽的测试文档和知识库：记录所有的测试用例、测试结果、问题跟踪和解决方法等信息，形成一个可供团队共享和参考的知识库。

卷到公司倒闭，笑死我了

在你的代码中，你已经找到了匹配的文件名，但是没有返回文件的绝对路径。要获取文件的绝对路径，你可以简单地将找到的文件名与当前目录（root）合并使用 os.path.join() 方法：

import os
import fnmatch

def find_file_by_key(path: str, key: str):
    """
    遍历目录模糊匹配文件并返回其绝对路径
    :param path: 公盘路径
    :param key: 搜索关键字
    :return: 文件的绝对路径或者 None 如果没有找到匹配的文件
    """
    for root, dirs, files in os.walk(path):
        for f in files:
            if fnmatch.fnmatch(f, '*' + key + '.pdf'):
                return os.path.join(root, f)  # 返回找到的文件的绝对路径
    return None  # 如果没有找到匹配的文件，返回 None

这个修改后的函数会返回第一个匹配到的文件的绝对路径。如果你想要返回所有匹配的文件的绝对路径，你可以将它们存储在一个列表中并返回该列表：

import os
import fnmatch

def find_file_by_key(path: str, key: str):
    """
    遍历目录模糊匹配文件并返回其绝对路径列表
    :param path: 公盘路径
    :param key: 搜索关键字
    :return: 包含匹配文件绝对路径的列表 或者 空列表 如果没有找到匹配的文件
    """
    matching_files = []
    for root, dirs, files in os.walk(path):
        for f in files:
            if fnmatch.fnmatch(f, '*' + key + '.pdf'):
                matching_files.append(os.path.join(root, f))  # 添加找到的文件的绝对路径到列表中
    return matching_files  # 返回包含所有匹配文件绝对路径的列表

错误日期已更新

现身说法，外企制造业，确实整体上是 WLB，内卷不是很严重。

你可以尝试使用 Allure 的标签功能来区分不同的环境。在执行测试时，为每个环境打上相应的标签，例如 @test 和 @pre-release 等。然后在 Allure 报告中，你可以选择按标签进行筛选，从而分别查看各个环境的测试结果。
此外，你也可以考虑使用 Jenkins 的参数化构建功能，在每次构建时指定要使用的环境。这样，你就可以在一个 Job 中为多个环境生成 Allure 报告了。
具体步骤如下：

1. 在 Jenkins 中创建一个新的自由风格项目。
2. 在源码管理部分添加你的代码仓库，并设置相应的分支和 credentials。
3. 在构建触发器部分设置你的构建触发规则。
4. 在构建环境中添加你的构建工具和依赖项，例如 Maven 或 Gradle。
5. 在构建部分，添加一个执行 shell 命令或 batch 命令的步骤，用于运行你的测试并生成 Allure 报告。你可以使用 Allure 插件提供的命令行工具来实现这一点。
6. 在构建后操作部分，添加一个 publish allure reports 的步骤，用于将生成的 Allure 报告上传到 Jenkins。
7. 最后，保存你的设置并启动一次新的构建。 在以上过程中，你需要确保你的测试代码能够根据环境的不同而执行不同的测试用例。你可以通过读取 Jenkins 构建参数的方式来实现这一点。