• 为了快速实现需求 快速上线 都敏捷化了 把很多传统的步骤都省掉了
    现在就是要效率 接口 ui 等等 就是为了能跟上节奏
    又快又好 只能说是追求的目标
    另外,测试的上限本来就不高,选择了这个职业就要接收这个现实
    技术是一方面 业务上也要精通 尽量在组织内体现出自己的价值就好了
    但是技术一般有通性 业务在不同的行业和组织差别很大 更多的还是要沉淀自己理解需求、快速解决问题的能力

  • 其实很多公司自研的平台都能做到 用 excel 和 xmind 的问题就是用例的风格很难统一 灵活性太强 格式太随意 版本管理缺失 测试执行无法跟踪 与自动化集成困难 我们这边是用的开源的脑图组件 然后做的二次开发 定义了集中 节点的类型 比如场景分组和用例节点 用例节点 可以添加前置条件、测试步骤 预期结果的节点 这样大家写的用例风格比较好固定 也比较适合用例的统一管理 持久化起来很方便 用例统一管理之后 就可以作进一步的集成 比如与自动化的集成 与代码变更的集成等等 把测试过程融入到整个研发体系中
    当然很多测试场景 更适合用表格做判定表 反正前端只是一种展现方式 用例都是统一存储的 只要数据结构设计好 怎么展现都可以

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

  • 请教下各位测试开发前辈 at 2019年04月22日

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

  • APP 自动化测试怎么开始 at 2019年04月12日

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

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

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

  • 目前暂时还没有

  • 2~3 人