精准测试，不知道又是哪个大厂的人才提出来的新名词，今天开会刚讨论这个。
我的结论就是，这玩意不如一个经验丰富的测试自己评估来的准。做的不好的投产比可以干成负数，毕竟一个推荐不准确漏测上线那就是事故了。
如果测试效率可以提升，那么自动化就能完成 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 那种风格维护，看个人喜好了。

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

目前还在优化中，而且还在设计开发 app 的云测。等功能都稳定下来再开源。

其实就是辅助断言和提取参数嘛，这个功能 ms 也有，比您说的这个还智能。我在上家公司也做过，因为我现在是第一版，所以还没来得及开发这些辅助功能。
另外您在使用参数的时候直接选是挺方便的，但是有两种情况不知道您考虑过没有：一是如果这个参数的入参不止提取的值呢，比如说 token，登录接口提取了 token，但是请求的时候前面需要加 bearer 才行，又或者某个入参是多个提取参数的组合。二是我不知道您这个接口的提取参数作用域是多大，假如说在一些流程用例场景时，某个用例的提取参数需要在下一个用例使用，不知道这时候是否支持，这种情况还是挺多见的。
然后我看了您的这个平台，接口采用 KV 形式写用例的，我最早也是这样设计的，对 json 做一个格式化解析。但说实话，遇到复杂的 json，特别是 jsonArray 和 jsonobject 的多层嵌套，维护起来特别麻烦，最终呈现还是 json 方便，所以后来就放弃了这条路。

您说的对，低代码确实相当于另一种编程语言。但是这种语言门槛相对较低，我想既然能做业务测试，那至少基本的测试理论和逻辑思维还是有的。相比使用框架而言，至少不再需要他们去学习一门或多门脚本语言，更容易培训上手。就好像会用 postman 就能上手接口测试，学会 selenium 定位和基础就能做 UI 测试。
另外，平台化相对框架的优势在于管理方便、容易持续集成、输出可视化等方面，但是有得必有舍，牺牲一些用例编写的便捷性就看实际的利弊了。不是所有项目都适合用低代码平台，但还是有大部分项目适合用的，这也是一个不断探索的过程。

感谢讨论。确实这些是很重要的功能模块，除了 mock 功能，其实在我设计的平台上都是有的，只不过是简化版。
您所说的这些其实更像是在做一个一站式平台，但我的观念可能不太支持一站式。因为不论测试平台这些功能做的再好，研发也不会用的，比如说接口管理，开发可能更喜欢使用 swagger 等专业工具，最终导致测试平台做了很全面的接口管理，最终还是外部导入。那我们做这些功能的价值是什么呢？所以我的观念是自动化测试平台就该是一个简单易用的工具，而不是去替代研发管理等方面的东西。
其次，针对 UI 测试，目前实现方式还是相当于用关键字翻译测试框架的脚本代码，因为测试引擎是可以本地跑的，等同于在使用测试框架。当然平台上写用例关键字步骤确实不如脚本便捷，但还会继续优化的。我想如果大家都认为事不可为，技术怎么进步呢。总归是在不断尝试中前进。
以上都是我在实际工作中产生的一些感悟，再次感谢提醒。

针对定位问题，常见错误处在日志中都有提示，比如请求参数格式、断言、提取参数等。如果是其他不可控错误，日志中会打印出堆栈信息。当然如果使用者代码能力不错的话，测试引擎本地启动，也是支持像框架 debug 一样的调试。我做的这个平台根本上就是在常规测试框架上面包了一层，不懂代码可以用，懂代码的人能更好的用。但是比框架来说，用例管理和维护就方便了许多

谢谢鼓励。其实混合只是多提供一个可用性，管理方面其实无外乎就是放在两个菜单还是一个菜单，这些我还在探索更有效的办法。
主要目的还是希望能用一套方案解决所有的测试，我目前正在做 APP 测试的设备管理和云测平台，去补齐最后一环

肯定有利有弊的。写的时候麻烦，但是后期用例管理和维护总归更清晰方便。之所以不想再用框架也是因为各种弊端，看实际取舍了。