• 8 号,提前休假

  • @ZhouYixun 感谢 Sonic 提供了这么一个功能强悍的云真机平台。
    反馈 2 个问题:
    1、同事把手机拔了,手机还是显示在线中,后来我远程重启手机,状态才变成了离线。
    2、新增手机设备的时候,不能立刻就显示出来,页面刷了好几次也不行,后来重新执行了 java -Dfile.encoding=utf-8 -jar sonic-agent-windows-x86_64.jar,才显示了新增的设备。

  • 哈哈,技术群真实状态。

  • 对于较小的数据规模(如您提供的几个键的情况),使用列表或集合在any()函数内部进行成员资格测试,性能差异通常并不显著。但如果要对比在大规模数据下哪种方式更高效:

    • 集合(set):在 Python 中,集合的成员查找操作具有 O(1) 的时间复杂度,这意味着无论集合有多大,查找一个元素所需的时间基本是恒定的。

    • 列表(list):列表的成员查找操作平均时间复杂度为 O(n),即如果列表很大,查找特定元素可能需要遍历整个列表。

    因此,在处理大量数据时,如果关注效率和性能优化,使用集合会更加高效。但是,对于只有少量固定键值需要检查的情况,使用列表也不会造成明显的性能瓶颈。在您的代码片段中,因为涉及的键数量很少,所以选择列表还是集合对整体程序执行效率影响不大。

  • 这种效率高:any(key in result.keys() for key in {'IOTregist', 'lift', 'loginName', 'beginTime'})

  • 只有测试背锅? at 2024年01月30日

    测试领导明显不懂业务逻辑,怎么能附和开发和运维的思维,自己揽责任。
    重启问题应该是开发自己做的不到位,和测试有什么关系,自己考虑不全,测试负责的是基本功能回归,不负责线上的运维服务,由于服务流程和部署问题导致的问题,不属于测试问题。
    需要明确责任边界,为啥没有重启,为啥发布之前没有考虑到,是什么原因? 有没有提醒过测试,需要做重启后的验证?发布之前有没有影响范围的说明?

  • 笑死我了,哈哈哈,大活宝😀

  • 学习了,先收藏一下

  • 闰年相关风险如何排查? at 2024年01月19日

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

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

    1. 代码审查

      • 对涉及日期计算、有效期管理和缓存逻辑的代码进行详细审查,确保在处理 2 月份日期时考虑到了闰年的情况。
      • 检查所有使用到java.util.Calendarjava.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. 如果上述方法仍无法解决,可能需要深入理解微前端框架的渲染机制,并根据实际情况调整定位和操作元素的方式。例如,在微前端应用完全加载完成之后再进行元素查找和点击操作。
  • 我的 2023 年终总结 at 2024年01月09日

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

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

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

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

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

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

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

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

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

  • 二宝,恭喜😁

  • 点赞,祝越来越好

  • @debugtalk 找框架的开发者问问

  • 关于软考证书 at 2024年01月02日

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

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

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

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

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

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

  • 2023 年终总结 at 2023年12月28日

    哈哈哈,笑死我了