文档还在补充，web 测试和 app 测试使用方法差不多

补上演示平台的账号密码：demo/123456

如果是做 web 自动化，不如试试流马测试？还能跟接口测试配合使用，同样也不需要写代码，当然对于有代码追求的，也可以用代码做一些复杂操作或者场景步骤的封装。

自动生成用例这个功能我之前二开 ms 做过。我自己开源的平台也准备做这个功能，不用生成一百个用例，一个用例请求 100 个接口也一样。
原理也很简单，先生成一条正向用例，然后在此基础上针对每个参数不同校验替换值并且换断言就行。

新用户都没优惠吗，像腾讯云阿里云这些基本新用户 2C4G 第一年 100，后面续费也会有个折扣，比这 140 一个月便宜得多

明白了，这和我们讨论的不是一种类型。我们这测试想要的是功能测试用例的推荐，我觉得是不切实际的，即便技术可行，前期录制用来映射关系也非常消耗时间

请教下你们用例和代码关联时基于什么方案做的呢

精准测试，不知道又是哪个大厂的人才提出来的新名词，今天开会刚讨论这个。
我的结论就是，这玩意不如一个经验丰富的测试自己评估来的准。做的不好的投产比可以干成负数，毕竟一个推荐不准确漏测上线那就是事故了。
如果测试效率可以提升，那么自动化就能完成 90%，其他的都是面子工程。

首先先确认你们的登录鉴权是哪种方式，审批流类系统常用的是 session&cookie 或者 token。
第一种一般是每个用户的审批写成一条用例，先登录再操作，然后用测试套件组合一下，这类灵活可以复用。
第二种一般先写登录用例，一次性登录多个用户并保存 token，再写审批用例，切换 token 即可。
如果是别的鉴权方式，那也有对应的办法，可以参考我之前的帖子。

可以尝试分三步：第一步通过 js 设置该组件获取焦点，第二步输入，第三步选择

这是前端组件的原因，这个组件归根结底是个下拉选择框，不是输入框，输入只是让你搜索使用，不是给你输入用的

要不试试流马测试平台。架构轻，代码少，更适合学习使用，自动化测试核心功能都已完善，可拓展性强。另外引擎也是基于 python+unittest 写的，正好给你参考参考怎么从框架到测试平台。
关于测试平台如何设计，你可以看我之前发的帖子，供参考。
如果有帮助的话，可以 github 给个 star，哈哈。

你都说了呀，复杂 bug 多。另外，我还是倾向于自动化测试平台就做自动化测试，周边功能不用做那么多。还有一点我当时做的时候 ms 是没有 WEB 和 APP 测试的

其实把测试引擎独立出来本地启动就行了，我做的测试平台就是这么干的。与其把测试引擎放在和平台一起的网络，不如把引擎放在和测试环境的网络下 (也就是任意环境下都可以执行了)

应其他同学需要，源码上传了 gitee 仓库：Gitee 地址

厉害厉害。我懒得弄容器化部署，前后端不太需要，引擎倒是需要但是因为 WEB 测试依赖 Chrome，镜像太大了，实在懒得弄。

我没用。我也是做平台的。应该有的吧，元素单独维护这是基本的设计要求 =。=

平台化不做数据驱动但是页面元素还是单独维护的啊

数据驱动在测试框架设计时很有意义，但做平台化意义不大。如果把用例抽象成一个步骤模板，类似于 pom 里的模型，反而会给用例维护带来更大的成本，这是血泪教训。像你说的登录用例，步骤是一样的结果不一样，但步骤真的完全一样吗，像你说的登陆成功跳转的页面和失败后跳转的页面必然不同，那断言的对象就不同，用一个模板去做说实话真心划不来。如果是其他步骤完全一致的场景，会不会在某次迭代又改成不一致，那到时候还要重新拆分用例。我理解的数据驱动的最初目的是为了数据管理方便而设计出来的，方便数据统一维护，平台化就没这一点的困扰，所以不需要。如果嫌弃一条用例步骤反复写，用例支持复制功能就好了。

断言也是操作的一部分，我理解你这属于两条用例了。以前我们做平台的时候为了解决这种场景把操作拎出来当模板，后来发现维护反而更麻烦，不如写成两条用例。

您说得对，我闲着无聊在造轮子呢

引擎是 Python 写的，上面有写，管理平台和引擎两块，管理平台包括前后端，后端不等于引擎，注意审题

感谢讨论。我想可能是每个人的经历不一样导致最终这方面的看法不一致。我是赞成体系化的，但是不赞成一站式。
我没在一线大厂待过，就我待过的公司而言，一站式测试平台的其他功能基本不会被使用。比如说目前我司正在使用 ms，这个平台的体系化功能够全了，组织空间、项目管理、接口管理、用例评审、迭代计划等等功能，可是实际上呢，真正的研发线根本不会使用这些功能，毕竟原有的研发管理平台已经覆盖了这些功能，想让别人使用，很难，更何况我们又不能保证这些能力比专业的研发管理更完善，即便做的完善那么测试平台也会很臃肿。
但是我是支持体系化的，自动化测试是要融入到研发管理中去，但仅作为体系里的一环嵌入进去，所以我也加了研发管理相关的字段，但是仅做对接使用。我的想法就是让自动化平台就做自动化，不做其他的。
其实我的目标是做一个工具平台而不是完整的测试管理平台，当然如您所说，目前确实封装不够深。主要我是觉得封装的越深，耦合性就越强，拓展性就越差，那么可能就不能通用，需要对不同项目做定制化开发。目前我还刚从 0 到 1，需要解决的是整体架构设计和可拓展性，保障更广泛的适用性。未来还会从 1 到 100+，不断探索去找到一个平衡点来保障通用性。

ms 是有辅助断言和提取参数的哦，只是呈现方式不一样，我记得是自动推荐，其实这些都是辅助功能，更方便使用。
我明白您这边的设计了，和我最早在公司里做的差不多，两种模式可以切换。
不过我个人还是喜欢接口按照 postman 那种风格维护，看个人喜好了。

感谢建议。我也在不断思考一些优化手段，设计这个平台主要是因为发现框架后期维护很难，而且产出量化困难，很容易失去作用。
设计成低代码但又支持自定义代码的原因主要还是为了拓展性，可能我心目中理想化的测试团队应该是一到两个有经验的测开带着数个业务测试。在推进自动化的时候，那些比较麻烦的业务逻辑由测开来通过自定义代码封装成函数或控件，然后业务测试只需要调用即可。当然使用前总归需要一些培训工作。这个模式在之前工作中也实践过，效果还算不错，我也在不断探索。
层主建议的的录制和自动生成我也在调研中，感谢您的建议。