• 说的很好 很多都是把开源的东西集成了一块就敢叫平台。很多人做这个的初心并不是为了推广,更多是为了kpi,为了领导的要求,后期推广的怎么样,多少人在用,提升了多少效率就不管了。测试平台永远是整个研发体系中的一环,有价值的平台肯定是打通了上下游的,从需求管理、交付物管理到用例设计、用例评审、环境部署、测试执行、进度跟踪、结果反馈、上线发布各个环境都是能连贯起来。所谓的UI自动化、接口自动化等等 只是整个体系中一小部分

  • 建议再学下 java 用python做主力语言 面比较窄

  • 迭代较快 资源又不足的情况下 建议从app与后端对接的接口自动化开始做 执行效率高 变动相对慢 写起来也容易些 UI自动化 性价比低一些

  • 我并没有说 要全部实现自动化 自动化的目标应该是测试场景的自动化 而不是针对接口或者某个功能的自动化 只能说借助某个接口(接口自动化)或者某个功能(UI自动化)达到场景覆盖的目的 自动化实现有成本 但是因为接口相对更稳定些 所以实现起来效果更好 性价比更高 UI变动更频繁 执行效果差 性价比低 要不要把某些场景自动化 得综合考虑 业务重要程度 测试资源 执行频率 和实现难度

    1. 你这个只能算半自动化,本身用例管理就应该有一套专门的系统,不应该把功能测试用例和自动化测试用例分开,自动化测试用例其实就是功能测试用例的自动化实现
    2. 自动化测试用例不应该是自动化测试团队写,自动化测试团队负责工具研发和推广,工具不好用就想办法优化,实际用例应该是各个业务组写,因为只有各个业务的测试人员才最了解业务,工具不应该是障碍,掌握起来不应该有有太多难度,如果这些东西都学不会,测试人员的能力说不过去,这也得看领导的支持力度和推动的决心
    3. 自动化测试的价值在快速回归,执行高效通过率高,能保证系统质量的底线,前端有Bug不会影响核心功能,只要接口能保证没问题,就不会出大问题
    4. 测试数据的构建是一个大问题,建议有能力就自己开发一套测试数据的构建系统,针对一些测试数据提供一套通用的接口,保证生成的测试数据独立,互不干扰,不受数据库迁移影响
    5. 接口文档不规范是整个研发体系的不规范,这不是测试的问题,需要测试去主动推动规范,而且现在微服务化之后,其实这块会越来越容易,对微服务来说服务的注册信息极其重要,不然运行时就会有问题。测试可以直接取这些信息,未必非得让人家提供一个文档啥的
  • 线上验证怎么区分测试数据和正常业务数据? 如果是一些查询的功能没有问题,如果涉及到数据库数据新增和编辑的场景,怎么处理呢

  • 目前暂时还没有

  • 2~3人

  • wnform的客户端的兼容性其实比web的要好很多 很久之前Winform流行的时候 自动化比Web自动化也早的多 最早之前的winrunner RFT之类的 都很流行 现在没落了 用的不错的 微软自带的CodedUITest 也很好用 如果开发能力强 可根据微软UIA MSAA框架 自己封装

  • 新能源行业 汽车充电桩 软件部只是公司的一部分 不到200人😀