接口的响应结果通常为html和Json格式的数据,主要会用到正则提取器、Json提取器,还有Xpath器以及边界值提取器,还有beanshell来进行数据的提取,而对于html这种响应结果我们通常会用正则或者是Xpath来进行数据的提取;对于Json格式的数据通常会用Json提取器。
第一种,可以通过函数助手来实现参数化,比如说像_RandomString这种随机函数;
第二种:通过CSV读取文档数据实现参数化;
第三种:通过配置元件、用户定义的变量来实现参数化;
第四种:通过前置处理器中的用户参数也可以实现参数化。
用户定义的变量,在启动运行时获取一次值,在运行过程中,不再动态获取值(不管设置多少个线程数或者循环多少次,都只获取一次值,不会变);
用户参数在启动时获取一次值,在运行过程中,每次使用该参数都会动态获取一次值。
我们先要做需求的分析,你要确定你们的这个产品的功能以及架构,还有我们的这个用户的这个分布的一个情况,通过这些,你能制定你的这个测试目标;
你就要开始搭建这个测试环境,因为我们的这个性能测试环境和功能测试环境、自动化测试环境是不能共用的,这是要独立搭建我们的测试环境的;
根据我们的这个接口来写我们的这个接口的脚本;
就是要对我们刚才写好的这个脚本来进行性能的转换,在这个里面要注意特别重要的一个点就是要加上性能场景的设计;
就是要去搭建我们的监控平台,因为监控平台它是对整个过程的一些数据来进行一个监控与收集的,只有收集的这些数据你才能做接下来的第6步;
就是我们的性能分析,分析的时候,我们要先从硬件、网络、配置,再来做我们的这个应用的一个分析,你不能说一上来就做应用分析,那你是分析任何问题你都分析不出来的;
我们要把整个这个过程所产生的所有的数据收集,最终整理成为一份报告来提交给我们的领导,那这个才是我们领导层所需要的整个过程的一份测试报告。
在测试计划里添加线程组;
在测试计划里添加非测试元件的HTTP代理服务器;
配置代理服务器-----端口可以设置成8888,把目标控制器选成测试计划 > 线程组,这样做的目的是录制的脚本直接生成在线程组下面,然后设置Requests Filtering(请求过滤器),若想排除一些我们不需要的东西,则可以点击添加建议排除,但这个也只能排除大部分的,小部分的还是排除不了;
启动代理服务器;
打开浏览器,对浏览器进行设置,设置对应的代理信息-----地址:127.0.0.1,端口:8888,保存;
访问网站:http://www.lemonban.com;
查看线程组,可看到下面录制的脚本在增加;
添加监听器-察看结果树;
运行,看录制的脚本能否运行成功;
把不是网站的脚本禁用,看运行是否还能成功;
运行成功之后删除禁用的那些脚本。
get在url里传参,post在bady里传参;
get长度限制(浏览器限制),post传参长度没有限制;
get相比较post安全高。
它们的用例组织方式是不一样的,jmeter来说比较扁平,而soapui它最上层是工作空间,工作空间下面每一个会有一个项目,然后项目下面又可以添加多个TestSuite(测试套件)这种;
在支持的接口类型和测试类型上面,jmeter和soapui工具差不太多,它们都可以支持Soap和Rest接口,也都可以进行接口的压力测试和功能测试;
在流程控制方面,jmeter可以由switch控制器等一系列控制器和beanshall脚本进行一个流程控制,而soapui它一般可以用Conditional Goto以及Groovy脚本来进行一个流程控制;
在断言方面,jmeter它的一个测试计划、线程组还有取样器都可以添加断言,soapui每一个request可以添加断言;
在脚本扩展能力,jmeter主要支持Java,而soapui主要支持groovy。
它们的用例组织方式是不一样的,像jmeter它的用例组织方式就比较扁平化,它没有测试集合和空间的一个概念,直接就是TestPlan,而postman它比较轻量级,主要是针对的是单个http请求;
它们支持的接口类型以及测试类型也是有不一样的,jmeter相对来说比较强大一些,它可以支持Rest风格的接口,还有Soap类型的接口,以及它可以去测试接口测试功能,以及测试一个性能测试,而postman它只支持Rest风格的接口,而且也基本上做的比较多的是功能测试;
在流程控制上面它们也是不太一样的,比如说jmeter它是通过像Switch控制器等一系列控制器以及像beanshall脚本来实现一个流程控制的,而postman通过JavaScript来进行一个流程控制;
它们两个在脚本结果解析和展示以及在断言还有一些功能扩展性也是有很多的区别的。
测试准备:我们先要去了解需求,熟悉业务,确定咱们的这个性能的指标(指标要非常清晰的确定下来),然后准备我们的测试方案、测试用例、测试模型、预估工作量等等为后期做好准备;
环境搭建:因为性能测试是需要独立的测试环境,所以我们需要独立 的搭建应用环境、数据库环境还有网络,另外还有一个性能的监控环境;
脚本开发:环境搭建好了之后开始写脚本,写脚本要根据不同的一个协议来选择不同的工具。写好脚本之后就要进行一个调试,调试通过了之后,然后把它转化为性能的脚本 (非常重要);
测试执行:我们根据前期写好的这些测试用例或者测试模型来设计不同的性能的场景来运行。在这个运行过程中,要使用性能的监控来监控运行过程中的数据,有了这些数据才能做后面的性能分析;
结果分析:通过监控,我们可以做一些初步的分析,分析硬件的、分析这个应用的,然后还有各种反复的调优反复的定位,最终发现你这个问题,能调优的自己调优,不能调优的要提交缺陷,然后还要提交测试报告。
测试用例和测试脚本是完全两个不一样的概念的东西。
测试用例是为了测试的执行而编写的一个关于测试的输入输出以及执行的步骤,还有测试环境、执行结果和预期结果这么一个文档的集合,它是我们测试执行的一个非常重要的依据。
而测试脚本是我们为了达到某一些特定的需求而编写的,比如说我要做自动化测试要编写自动化的脚本,要去做性能测试要编写性能脚本等等,但一般来说,我们的测试脚本也会对应的一个测试用例。
作者:糖心baby
原文链接:https://blog.csdn.net/qq_54725031/article/details/117423611