聊一聊低代码自动化测试平台的设计思路

nico 9
2022-07-27 01:28:14 未知地区 1F
回复

又是一个轮子 赞一个，设计的比较好。缺前置处理，后置处理。我在做这个平台设计的时候还不知道市面上有哪些测试平台，全都是自己一点点思考出来的。后来也有发现一些接口测试平台，但还没有遇到把 API 和 UI 融合在一起的，可能是我平时关注的少。不知道您有没有试用过，相比其他接口平台，自我觉得有不足但也有我的创新和特点，我的理念是简洁易用，所以功能都设计的比较简单。或许与其他平台有相似之处，但我是不认同您的重复造轮子的说法。谢谢。确实还没做前后置处理，其实我也有考虑过。做个类似 jmeter 那样的 beanshell 其实不难，关键这样就与低代码理念有点相悖。前置处理如果是请求参数相关的处理是可以用自定义函数来覆盖大部分场景，后置处理如果仅用于提取参数的话其实大部分情况也能支持。但其实确实有很多其他相关的使用场景，因为还没有具体遇到，所以目前还没想出来有什么好的替代设计方案，后续会继续收集优化。最后再次谢谢您的建议。但凡稍微复杂的场景，用低代码平台就是痛苦肯定有利有弊的。写的时候麻烦，但是后期用例管理和维护总归更清晰方便。之所以不想再用框架也是因为各种弊端，看实际取舍了。LuckyFrame 就是接口 +ui 混合的。这个是看个人，融合起来在实际情况中使用场景有限且不便于管理。
你这个想法挺好，加油谢谢鼓励。其实混合只是多提供一个可用性，管理方面其实无外乎就是放在两个菜单还是一个菜单，这些我还在探索更有效的办法。
主要目的还是希望能用一套方案解决所有的测试，我目前正在做 APP 测试的设备管理和云测平台，去补齐最后一环看着就头疼，特别是定位问题的时候，没有代码来的直接和方便，更别提 debug 了平台看着不错，其实实用效果不强。现在的接口平台都是集成接口管理，接口自动化，Mock 平台，监控，项目管理，持续集成一体化的，单一的接口平台只是工具，简化了 PostMan 而已。WebUI 为什么没有人做平台呢？因为不适合做平台，UI 自动化维护成本高，录制回放的方式都没有流行起来，更不用说使用平台写用例了。这个项目你用来做练习还可以，如果想通用，这个是远远不够的。针对定位问题，常见错误处在日志中都有提示，比如请求参数格式、断言、提取参数等。如果是其他不可控错误，日志中会打印出堆栈信息。当然如果使用者代码能力不错的话，测试引擎本地启动，也是支持像框架 debug 一样的调试。我做的这个平台根本上就是在常规测试框架上面包了一层，不懂代码可以用，懂代码的人能更好的用。但是比框架来说，用例管理和维护就方便了许多框架设计合理的话，还是写代码效率高，并且灵活。我觉得低代码就是一个伪命题，各种框架或者库的封装就是为了少写代码提高效率。很多的低代码实际上是往无代码上靠，而完成业务肯定需要实现逻辑，低代码平台就变成了另一种形式的编程语言。即使不写常规意义上的代码也需要掌握技术理论和编程思维，如果缺乏基础，小白上手很慢，会代码的人可能又不太愿意使用，不过造轮子的精神还是值得肯定感谢讨论。确实这些是很重要的功能模块，除了 mock 功能，其实在我设计的平台上都是有的，只不过是简化版。
您所说的这些其实更像是在做一个一站式平台，但我的观念可能不太支持一站式。因为不论测试平台这些功能做的再好，研发也不会用的，比如说接口管理，开发可能更喜欢使用 swagger 等专业工具，最终导致测试平台做了很全面的接口管理，最终还是外部导入。那我们做这些功能的价值是什么呢？所以我的观念是自动化测试平台就该是一个简单易用的工具，而不是去替代研发管理等方面的东西。
其次，针对 UI 测试，目前实现方式还是相当于用关键字翻译测试框架的脚本代码，因为测试引擎是可以本地跑的，等同于在使用测试框架。当然平台上写用例关键字步骤确实不如脚本便捷，但还会继续优化的。我想如果大家都认为事不可为，技术怎么进步呢。总归是在不断尝试中前进。
以上都是我在实际工作中产生的一些感悟，再次感谢提醒。您说的对，低代码确实相当于另一种编程语言。但是这种语言门槛相对较低，我想既然能做业务测试，那至少基本的测试理论和逻辑思维还是有的。相比使用框架而言，至少不再需要他们去学习一门或多门脚本语言，更容易培训上手。就好像会用 postman 就能上手接口测试，学会 selenium 定位和基础就能做 UI 测试。
另外，平台化相对框架的优势在于管理方便、容易持续集成、输出可视化等方面，但是有得必有舍，牺牲一些用例编写的便捷性就看实际的利弊了。不是所有项目都适合用低代码平台，但还是有大部分项目适合用的，这也是一个不断探索的过程。从楼主的设计初衷看，应该是主要针对相对复杂度不那么高的项目快速建立自动化用例用。从这个角度来看，建议楼主可以针对这个方向进一步优化，比如加上一些自动生成用例或者说录制生成基础用例的手段？

低代码平台一般初衷是相对代码经验弱一些的同学，或者通过高度的封装极大降低代码量。看楼主的思路，应该属于前者。对于代码经验弱的同学来说，自动生成/录制生成会比在界面拖拉拽写用例吸引力更大。如果不写代码但还得要求有编程思想，容易不上不下，写代码的人不喜欢用，不怎么写代码的人也觉得写起来不如自己直接执行方便。感谢建议。我也在不断思考一些优化手段，设计这个平台主要是因为发现框架后期维护很难，而且产出量化困难，很容易失去作用。
设计成低代码但又支持自定义代码的原因主要还是为了拓展性，可能我心目中理想化的测试团队应该是一到两个有经验的测开带着数个业务测试。在推进自动化的时候，那些比较麻烦的业务逻辑由测开来通过自定义代码封装成函数或控件，然后业务测试只需要调用即可。当然使用前总归需要一些培训工作。这个模式在之前工作中也实践过，效果还算不错，我也在不断探索。
层主建议的的录制和自动生成我也在调研中，感谢您的建议。非常同意这一楼的观点。

这个项目更多是帖主展示自己的思考和技术，很值得肯定。
但是如果让我来用或者让我给其他同学推广，我其实不太情愿，这个平台从实用性上看还处于比较浅层的封装，从产品化的角度来看，我觉得更有实际意义的方向还是如何一站式或体系化地解决问题，而不是单纯把一个工具上升为一个平台。（不是在贬低帖主的平台，只是一些实际看到的经验）感谢讨论。我想可能是每个人的经历不一样导致最终这方面的看法不一致。我是赞成体系化的，但是不赞成一站式。
我没在一线大厂待过，就我待过的公司而言，一站式测试平台的其他功能基本不会被使用。比如说目前我司正在使用 ms，这个平台的体系化功能够全了，组织空间、项目管理、接口管理、用例评审、迭代计划等等功能，可是实际上呢，真正的研发线根本不会使用这些功能，毕竟原有的研发管理平台已经覆盖了这些功能，想让别人使用，很难，更何况我们又不能保证这些能力比专业的研发管理更完善，即便做的完善那么测试平台也会很臃肿。
但是我是支持体系化的，自动化测试是要融入到研发管理中去，但仅作为体系里的一环嵌入进去，所以我也加了研发管理相关的字段，但是仅做对接使用。我的想法就是让自动化平台就做自动化，不做其他的。
其实我的目标是做一个工具平台而不是完整的测试管理平台，当然如您所说，目前确实封装不够深。主要我是觉得封装的越深，耦合性就越强，拓展性就越差，那么可能就不能通用，需要对不同项目做定制化开发。目前我还刚从 0 到 1，需要解决的是整体架构设计和可拓展性，保障更广泛的适用性。未来还会从 1 到 100+，不断探索去找到一个平衡点来保障通用性。“体系化” 和 “一站式” 不完全是两个概念，“体系化” 是一种思想，而 “一站式” 只是一个表象或者一种实现，一起谈容易出现误解。

自动化平台确实就应该先做好自动化，但是在这个探讨语境中，我认为自动化平台最重要的不仅仅是自动化，用例管理、与 CICD 系统的集成或被集成等其他很多外围功能，也是平台的生命线。之所以这样说，是因为观察过实际工作，大家不会因为一件好像不是那么重要的事而不断给自己的工作引入复杂度（比如我要在代码 Merge 时跑个自动化，我不希望还要切到 CICD 其他平台看这看那的，我只需要一个测试结论）。所以 “体系化” 这里可以指代系统被外界集成的可行性和复杂度，甚至是信息信噪比（假设日常工作是围绕 CICD 来开展，以被集成到 CICD 作为设计目标 “之一”）。

另外，个人理解自动化是一个上层概念，它代表某种提效的手段，那么就底层就可以引入更多能力来让自动化做得更好，如 Mock 就是一个很大加分项。不过需要谨慎看待，实际工作中要结合内部已有的能力来建设就会少人喷一些……

而 “一站式”，更多时候像是在搞重复建设，卷其他部门，实际工作中见到好多这种皮包平台，把别人做好的能力拉过来集成包装一下就美其名曰是效率提升，实际上没有任何实际额外内容在里面，随着内部平台的大一统治理肯定会被干掉。

所以个人建议是帖主可以考虑围绕着自动化场景去引入更多能力，这些能力应该能让自动化做得更高效更准确更舒服，也是从 1 到 100 的过程。这几年写过纯接口功能用例自动化的平台。UI 自动化平台。推广几乎都失败。因为要使用成本。而且针对稍微复杂的场景又不太够用。最终放弃了。然后今年参考了某个公司的写了另外一种接口自动化测试平台。就是框架搭好。公共方法类都自己写好。稍微简单培训会写代码或者不会写代码的人去写测试用例。然后在解析每个测试人员写的用例到平台上。平台只负责解析写的代码用例转化成可视化平台去执行维护。这样大部分测试觉的自己能过学到一定的代码能力。又能因为可视化出来大家都能看到自己写的。也方便统计 kpi有收获总让我想起来 robotframework 和 cucumber