• benshell完全能满足,是看你怎么用,本身就是轻java脚本,jemter尽量不要依赖正则,多用beanshell,你就会发现很多你要问的难题,一下子就自己能解决了。

  • 把第1个接口的请求写在setUp线程组里,用beanshell拿出所有要用的ID放在局部环境里;并发线程看你选择是暴力的并发还是阶梯压测,再写一个对应线程执行第2个接口,用benashell前置脚本取ID。这样可以满足你,接口1只跑1次拿ID,接口2跑并发。

  • request的session机制,把token实例化就可以

  • result.userInfo.id

  • 接口测试用例设计 at November 05, 2019

    我打个比方,单接口的数据验证=高中的英语难度,多接口的业务关联验证=考过GRE的英语水平,接口全自动化=你在华尔街工作的英语水平。难度,技术,关注点和认可度,以及对项目的作用,可想而知。
    接口是为业务服务的,如果接口最终的闭环回不到业务上,那么这个接口测试就没有了灵魂

  • 首推pytest,但我有种错觉,你要的做的UI测试,那么你这个时候就要关注selenium,CSS,xpath,allure了。

  • JMETER_16 个逻辑控制器详解 at November 05, 2019

    敢问你的帖子都是这么明目张胆抄袭百度张贴,这么没水准的

  • 接口测试用例设计 at November 04, 2019

    第一,针对问题1的接口问题,首先你要确定APP请求的接口response有什么数据,然后你在看web请求的接口response又是什么数据,打个比方,如果APP接口返回的response里有文章的数量节点number,还有文章的排序节点sort,那么你一定要校验web接口返回的文章数量和排序是否一致做对比;其次你还需要对APP接口获取到的内容与web端获取到的内容做对比(一般都是存数据库,内容对比意义不大,翻到是id对比有意义)。
    第二,针对问题1的用例设计,首先提示不要用功能用例的设计思维去设计接口用例,你要明白接口测试的核心是什么(最简单是4个点:1.接口的格式是什么,2.接口的数据怎么动态,3.接口的业务怎么关联,4.接口的响应怎么验证),如果你用Excel这种功能用例方式来维护接口用例,灵活性差不说,维护成本非常高(建议你前期直接用接口工具维护测试用例,利用工具输出测试报告作为留本。后期熟悉了技术上来了再用数据驱动的方式管理用例)。
    第三,针对问题2,接口测试如果仅仅关注单接口的格式和数据验证,那么接口的灵魂就没有了。所谓接口测试,1.是为了在功能测试之前提前规范和消灭bug,减少功能测试的负担和盲点;2.是作为回归,减少测试人力的同时保证系统每日的稳定运行,同时也在系统出问题是得知问题所在(打个比方,一个系统有很多个接口,如果你的接口脚本每天都在线上定时跑,A接口报错了,但是用户没有返回,说明暂时没人发现,这个时候你们就可以在用户发现前解决问题)。所以,接口的业务关联性是最重要,这点取决于你对系统的熟知程度来设计业务场景,也能体现出你的测试嗅觉。
    综上所述,这都是我的一番废话而已,接口这条路好好走下去吧。

  • 存储过程测试 at October 16, 2019

    sql存储过程测试:1,校验入参和出参;2,校验SQL逻辑;3,优化SQL性能。
    楼主文章涉及了第一点,其实我们最重要是第二点,最难得是第三点。
    我的理解和测试是,在充分读懂要测试的SQL存储过程,将它的SQL逻辑,一点点分解,然后自己写SQL校验所测试得到的数据是否和开发的SQL逻辑得到的数据能一致,这个还是要多提高SQL能力。
    至于SQL性能,很多开发的SQL存储过程有可能会出现冗长,在你的能力范围内给出响应更快的SQL,尤其是当SQL出现索引要重点注意。

  • 最近在研究和使用pipeline,易上手,简洁明了。
    之前总认为Jenkins的CI/CD是很复杂难懂,一直不想入门。
    其实想多了,Jenkins是一个自动化引擎,入门上手还是比较简单。
    对于我来说选择pipeline是因为我对于Jenkins的需求简单,我能满足我的测试即可,
    大家多研究。