学东西肯定是按照个人当前需求学 急切用到的 边学边用 效果最好 然后是可能用到的 扩展能力的 可以系统的学一下 短期看不到任何使用可能的 了解下就行了 刚毕业的时候还有兴趣学这学那的 后期年纪大了 精力时间有限 还是把精力集中投入到能挣钱的知识上 功利性要更强

对的 我主要想表达的是 既然有心把自动化的功能包含上 要不就不做 要不就做到好用和易用 不要为了追求系统的大而全 整个拖后腿的自动化出来 给整个系统的推广带来阻力 适得其反

个人认为平台的作用更应该关注重管理轻业务
管理包括 测试任务管理 交付物管理 测试用例管理 测试报告等等 流程性的东西 方便对测试工作进行统一的跟踪管理 也可以作为测试人员效能的考察工具
测试执行因为测试方式不同 很难用一个工具统一起来 尤其是自动化和性能
不管是接口自动化还是 UI 自动化 自己去做都比不上市面上流行的成熟工具
但是使用成熟的工具 又不如自己写代码来的更方便和灵活
测试平台包含自动化更多的是对当前测试人员技能水平普遍比较低和对工作效率、时间进度要求越来越高的各种现状的妥协
作用正如低代码平台对开发的期望 简单功能能 hold 住 但是复杂场景还是要写代码 导致处于一种很尴尬矛盾的状况
自动化工具也是 但是做测试平台的人的代码能力普遍不高 提供的平台的自动化功能和易用性都比较差 更多是一些普通功能的 web 化 简单的测试点点或者配置一下可以做到 复杂功能搞不定 有代码能力的测试人员又不屑于用这种比较死板的方式写脚本 推广效果不好
破解这个问题 感觉希望有更多更成熟和强大的专业开发团队做类似的平台 就想目前的低代码产品 好的产品越来越多 功能越来越强 不能指望每个公司随便拉几个人整一套 搞出大量雷同又弱鸡的所谓测试平台用来刷 KPI 用的人怨声载道 实际效果很差

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

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

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

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

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

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

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