• 第八点: 场景通常发生在 H5 页,需求只有前端页面(大部分是旧页面改皮活动),后台数据拿的旧接口或者其他项目组的。转测只有前端页面,开发转测时会附带 mock 数据模板 eg:

    {
      "user": {
        "id": 1,
        "name": "test",
         "years": 25
      }
    }
    

    实际上旧的接口可能已经发生了变化,新的返回数据是

    {
      "person": {
        "userId": 1,
        "fullName": "test",
         "age": 25
      }
    }
    

    前端这边按照旧的数据进行调试,告诉你也是旧接口,如果没有踩坑经验的就会用他给的这个旧数据模板去测试。那上了体验服或者现网就会因为结构不同,产生代码错误、页面显示问题、逻辑错误

  • 是不是你本地的 adb 和模拟器的 adb 冲突了

  • import os 
    import fnmatch
    
    def find_files_key(keyWord, dicretory='.'):
      matching_files = []
    
    
      for root,dirs,files in os.walk(dicretory):
        for file in files:
          if fnmatch.fnmatchcase(file, keyWord):                 # 不区分大小写用fnmatch
            file_path = os.path.abspath(os.path.join(root,file))
            matching_files.append(file_path)
    
      return matching_files 
    
    
    #test
    keyword = "1.py"
    directory_to_search = "./"  
    result = find_files_key(keyword, directory_to_search)
    if result:
        print("匹配到的文件:")
        for file_path in result:
            print(file_path)
    else:
        print(f"未找到包含关键字 '{keyword}' 的文件。")
    
    

    os.path.abspath(path) 该方法返回指定路径的绝对路径

  • 有个和自己磨合至少一年的开发很重要

  • 卧槽,真的他们可以接收进去学习的人吗? 哪个地区的公司,有 JD 看下吗

  • 机会和风险并存,虽然看起来是坑

  • 不会的,Java 的不知道怎么弄,但是普遍是用 pytest 的话,fixture 是可以创建测试环境的前置条件和后置条件,确保每个测试用例都在独立的环境/测试数据中运行。pytest.mark.dependency 和 pytest.mark.dependency(depends) 标签,可以指定测试用例的依赖关系。至于维护,其实也是用 yaml 写的测试数据,差不多的

  • 😂 不是纠结于哪种语言,只是看到原来用 Java 实现的接口自动化和 python 实现的差不多,但是代码居然能多出这么多感到惊讶😂

  • 你应该反过来说😁

  • 学习了,好强

  • 肯定的😂 毕竟你永远也想不到会遇到什么性格的开发/产品/领导/老板,有个过了磨合期的开发/产品,才可以少踩坑。否则真的防不胜防

  • 类似一个最基础的项目结构和配置。类似 “npx create-react-app react-basic” 的指令,就会生成一个基础的 react 项目结构文件,你可以直接去上面写和改

  • java 我只是略懂,虽然看结构图感觉很高大上,但是细看下是不是就是比较通用的【yaml 数据驱动方式自动化测试】: 用 python 可以省至少一半的代码😂

    只看了 Demo 的 testcase,你的思路大概是 先创建了一个 Request 实例,用于发起请求。然后,通过 doRequest() 方法发起请求,获取响应。接着,从响应中获取一些信息,如 HTML、请求头和 Cookie。然后,创建了一个新的 Request 实例,用于发起另一个请求。通过 addHeaders() 和 addCookies() 方法向请求中添加请求头和 Cookie。最后,通过 doRequest() 方法发起请求,并使用 assertThat() 方法进行响应状态码的校验😂

    在参数化测试方法中,也是先创建了一个 Request 实例,用于发起请求,通过 setParameter() 方法向请求中添加参数。接着,通过 doRequest() 方法发起请求,并获取响应。最后使用断言方法进行响应状态码的校验😂 中间还有使用读取 excel 文件作为参数数据源。

    如果用性价比平替的方式,我建议还是用 pytest😁 ,第一种方式使用 python Request 的 Session 对象发送请求。第二种用 pytest 的@parametrize装饰器为数据提供参数化测试,然后还是用 assert 语句断言检查。数据驱动的方式也是 yaml 文件,就用 pyyaml,测试报告用 allure

  • 不需要吧,一个吐槽帖,没啥技术含量😂

  • 感觉可以按照一条回归用例 1 分钟的执行速度算,多少条自动化用例就减少多少分钟

  • 是的,有前端基础上手是挺快,但是很多人争着要,转行还能要的 20K.。。。。就这个太离谱了,我了解了下市场,boss 上没多少 qt 的岗位。。。。。

  • 需求量大吗?

  • 她说的 qml 查了下,的确是用的前端技能可以快速入手,但是她说能拿到 20K+ ,我就觉得挺魔幻的

  • 不是呀,刷脉脉看到的,想着是不是信息差,生怕错过这等好事

  • 我也感觉,看底下评论,感觉这个楼主好像煞有其事一样。真的挺扯的,qt 基本嵌入式开发都会学,但是专门岗位给一个 31 岁转岗的前端 20 几 K,怎么想都离谱

  • 老开发写时会比较鸡贼,有些产品没提,虽然他知道但是他不写,新开发比较积极去对业务 但是因为理解不同,导致功能实现跟测试理解的很不一致。测试这边测试时,要么背用户投诉 bug(业务点遗漏),要么就是跟新开发不断吵

  • 测试工作中大部分难题都是这个,重大技术 bug 现在还没遇到过,大部分感觉都是边角料 bug

  • 自动化除了你写了多少条自动化用例拿来生成个柱形图外,基本没法量化吧? 根本不指望它能发现多少 bug 的。我工作价值就比较容易写,直接写了全年写了多少测试用例,发现多少 bug,测试了多少项目........虽然很多大佬看不上这个指标,但是的确是量化的好数据

  • 只有一个前端一个后端,加我一个测试,没项目,就干杂活,有测试项目了,只需要点点点,不需要用到深圳那么多技术,也不需要数据库命令,更不需要自动化

    好羡慕这种状态,这才是工作的本质

  • 这个工具除了证书不好用之外,其实已经是能满足大部分需求了