• 需要把工具放到工程化中来看 且被使用才能产生价值 ,只是为了 KPI 的工具 确实没什么用 ,当然做一个工具提升一下编码能力也是 OK 的 ,有些人呢做一个 demo 就当时面试时的谈资了 有点可笑

  • icodes.work 不限功能 只限用户数 10 个用户免费 不够可申请 ,且是安装在你本地 下面是 windows 版 最多 2 G 内存就行
    https://download.icodes.work/codes_base/Codes1.0.0GA_home-SetupBindMysql8TomcatJreRedis.zip

  • 系统级的搞破坏也算呀 😀

  • 目的不同,对象也不同
    chaos(混沌测试) 是系统级别的 fuzz(模糊测试) 都是函数或者类级别的
    fuzz testing(模糊测试) 是为了发现安全漏洞,内存泄露,以及其他冲突问题
    haos testing(混沌测试) 是为了验证系统的弹性能力,错误容忍能力,以及自愈能力

  • https://testerhome.com/topics/30495 完全可以用我这里的 接口混沌测试,你只要配置参数规侧 ;我来排列组合后去调用
    只需要配置好混沌规则 ,然后以 “撞库” 的形式排列组合,替换掉正向接口用例中的参数值去执行撞库,瞬间完成接口健壮性测试 “撞库时” 先单个一个一个去换, 然后再排例组合。



  • 做了不等于做好了 ! 没有可改进的,没有可再优化的?

  • 自动化用例一定要保证每个用例可以单独执行,简单的依赖就是我昨天说的 ,场景就是把多个接口用例编排为场景
    也就是接口用例是原子的, 可复用他们来构造业务场景
    说起来抽象 试试 itest work 你就明白 了

  • 和是不是压测没关系 压测和接口测试时他的依赖你必须跑呀,再说了出了问题你分析他的调用链么,如果慢的话 。就拿你的 B 来说 要是压 A 受 B 的影响 , B 很慢也能找原因的 ,照你说的方式你只压 A 性能很好 ,到了生产环境真实是要调 B 的 , B 把 A 拖慢了 ,是不是也要找你 ,谁压的 。压测 我要是要压单一接口估计还得要开发配合, 要是我我不管这些 肯定是按真实场景压 ,要是慢能找到原因就行 ,或是让开发自己去找。 要不然生产慢得要死 是不是要找你麻 烦。一句话压也是要按真实的场景 (或是依赖) 去压。准确来说是压以 A 接口为入口的接口, A 依赖的接口都要一起压了 ,致于是哪个该死的接口拖慢了 A 你能找出来更好 ,找不出来 就让开发来,不是用调用链吗,这很好分析出来,没问就让开发去排查

  • 接口用例是接口用例 他们是独立的 运行的时候自动按参数依赖执行前置用例


    接口间只要存在参数引用,就必须存在依赖关系,完全可以根据依赖关系推导出来,执行顺序,执行 A 接口时他引用了 B 接口的参数 你只执行的是 A 但会自动帮你先执行 B 然后才执行 A 。下面这图引用了其他接口提取的参数 就建立了他们的依赖关系 ,我认为接口的依赖关系在开发的时候 就决定了他们的关系 依赖是客观存在的 不是测试的时候才存在 ,所以只要按业务要求做好相关相关的引用就行了 ,平台给你推荐他们的关系拼按依赖帮你把所依赖的也执行了

    根本不需要你来关注依赖 详见下面贴子 ,这里有关于接口测试的创新的想法

    https://testerhome.com/topics/30495

  • 认识的一个朋友 虽然没写代码 人家把甩 60 多人的测试团队管理得好好的 人家的价值怕是比你这技术多得多 不要以技术看人 要以创造的格值看人 虽然人家不写代码不代表人家眼界低

  • itest 是免费的,他的接口测试看这里




    还有调用链等

    具体看这个贴子,有不少创新思路
    https://testerhome.com/topics/30495

  • 贴主这精神值得赞杨,从 0 搞工程量大。要是我肯定是用开源的二开,除非我发现开源的二开也不行,或是有一些别的限制,在动工前,做一个选型,确实没办法才从 0 开始搞,不是一上来就干。

  • 有朋友做硬件测试,学历和你差不多也是一线 18K(他没有编码和自动化这些技术),以你这能力,我觉得 16K 应不是事,不过现在大环境不好,先不动吧。

  • 历害 itest 编外开发人员非你莫属

  • 聊聊团队对用例的想法 at 2022年08月28日

    你们实际可以沉淀出用例库,某个迭代测试时,导入相关产品用例库用例到项目中,然后以脑图模式显示就行
    新的改动先用脑图写用例, 空了再基于脑图转 EXCEL 把细节补充进去 (不空的话,业务稳定直接用脑图来执行也 O K),再导入到用例库中,这样的话,就算人员流失,造成的损失最小

  • 聊聊团队对用例的想法 at 2022年08月28日

    手工测试是 要手工去改用例状态,只是我们是以敏捷测试的方式一个一个迭代的来执行;
    自动执行是接口测试,可定时执行 也可通过 jenkins 触发执行,他可以手动一键执行一个场景下的所有接口用例

  • 还吊打 pm ??好自大,哪个平台不能接口集成 .https://testerhome.com/topics/30495 我这里写得清清楚楚,自己看。不要动不动上来喊口号。各个工具都有各个优势,都可以讲出来,动不动一句话,喊口号,不知是什么心太 。我这所以回贴是因为你说的 MS ,太牛 B 了,天下无敌,我有必要让别人知道还有别选择。

  • 如果 2 开,确实要选技术,只是用只要好用就 OK 。选型的话,不二开和技术无关,只和能不能解决需求有关,别急,我们新版就会出来
    前后端,这些都不是事,,也不是什么高深技术,坐等新版
    loadrunner 10 年前的技术了,现在不一样有人用得欢吗

  • 用 itest 呀 看看这就明白 itest 的创新 https://testerhome.com/topics/30495

    MS 没一点创新 不如用 postman ,起步 4C8G ,,itest 1c2g 就够

  • 聊聊团队对用例的想法 at 2022年08月23日

    这就是脑图的本真用法,没有前置也没有步骤和预期;想要标准用例,转为标准时可以改 或是用这个第三方开源插件
    https://testerhome.com/topics/34094 ,这就是别人写的用脑图写标准用例,转为 itest excel 导入模板的格式,再导入到 ITEST 中

  • 没写,功有是有的,先在全局设置中配置好规则,然后建接口场景,在场景中就可以用上,或进 Q 群问

  • 聊聊团队对用例的想法 at 2022年08月23日

    如果你认为是广告,我无力反驳。我主要是看贴主,有这块的管理问题,我简单分享一下,ITEST ,也不收费,免费用,好东西分享一下,测试人员,不应该多些好奇心,多了解一些工具么,我是本着真正敏捷测试落地的好东西和得大家分享,你无视就行。

  • 聊聊团队对用例的想法 at 2022年08月20日

    itest work
    第 1 步写脑图用例

    第 2 步把脑图用例同步为标准用例,同步的时候要选一个迭代

    第 3 步,在脑图上执行用例 或是在迭代下执行用例(也可以以第 4 第 5 步的方式执行更便于管理 )

    第 4 步,分配迭代下,不同的人执行不同的用例。更细化管理测试迭代,一个迭代有可以几 100 上到几 1000 用例,
    按功能分配不同的人执行不同的用例

    第 5 步,在迭代下以需求树执行用例,需求树进行了过滤,只显示执行人所分配的用例所对应的需求

    第 6 查看迭代执行用例情况及 BUG 情况

    iest work 是免费的,一个月发两到 3 版,官网及在线体验
    www.itest.work

  • itest xmind 转 Excel 小工具 at 2022年08月15日

    哈哈,不错。itest 就是不支持用脑图写标准用例,要这样用,只能自行扩展。itest 坚持脑图的本真用法,保持脑图的简洁。存在就是合理的,有这场景的,可以用你这工具转为 EXCEL 后再导入 itest 中,后续我们可把你这个集成进去,就不用再 EXCEL 了,只直导入到 itest 中。兄弟这水平不错,不爽就自动动手😃

  • 但这标题,会让人误解,和 itest 没关系