在日常开发过程中, 不知道你有没有遇到过这种情况, 产品提出某个功能需要调整逻辑, 结果发现需要修改的方法被多个地方复用, 而你却根本无法评估改动是否会对其他调用的地方带来影响, 这种时候如果硬着头皮修改, 可能会对某个未知的地方带来难以预测的风险, 而保守策略则是将这段代码拷贝出来, 然后进行修改, 当前改动的业务调用这段新的代码, 其他调用关系不变. 这样既不必承担风险, 又实现了需求, 但是却会让系统逐渐变得臃肿和难以维护, 所以这个问题的本质是测试覆盖不到位, 导致无法评估带动对系统的影响. 而如果可以对系统接口进行全覆盖测试, 那我们大可以大胆地对代码进行修改重构, 然后重新进行一次全覆盖测试即可.
小钻风的目标就是完成这样的接口的覆盖巡检任务, 是基于若依(http://ruoyi.vip) 脚手架搭建的一个接口自动化测试工具, 接口的巡检就相当于是巡山, 所以取名为小钻风.
小钻风的总体设计目标是能够灵活方便地对系统全部或部分业务场景进行接口覆盖测试.
为了实现上述目标, 抽象除了接口模板, 任务, 任务-接口关系, 登录配置等概念.
接口调用结果判定表达式和依赖参数的表达式解析为同一套规则, 整体遵循简单易用的思路, 无需定义变量类型, 也不支持运算符号, 全部以函数的方式进行抽象(系统已经提供一系列常用函数, 还在源码层面以SPI的方式对自定义函数提供支持). 对于依赖参数来说, return的变量可以用于替换对应的预定参数; 对于接口结果判定表达式, return的结果必须是boolean类型, 用于判定接口是否调用成功; 如果返回多个变量, 取它们与运算的结果. 具体使用方式可参考初始化的默认样例的写法.
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。
1. 开源生态
2. 协作、人、软件
3. 评估模型