本发明涉及程序测试领域，具体而言，涉及一种生成测试脚本的方法、装置及系统。
背景技术：
在计算机领域，程序代码修改后，需要对修改后的代码进行回归测试，以确保修改没有引用新的错误，或者导致其他代码产生错误，因此需要编写或录制测试脚本，对修改后的程序或者代码进行测试。
目前，录制jmeter测试脚本的方式为测试人员手动编写，或者，jmeter通过页面抓取录制测试脚本，但是，测试人员手动编写jmeter测试脚本的效率低下，图1是根据现有技术的一种测试人员手动编写测试脚本的流程示意图，如图1所示，由于测试人员要手动编写测试脚本，然后运行脚本，得到jmeter测试脚本，编写测试脚本过程需要测试人员负责且非常耗时，并且如果程序发生变化，也很难同步修改jmeter测试脚本。另一方面，jmeter为一种基于java的压力测试工具，其中，jmeter可以提供一些自动录制测试脚本的方法，通过jmeter页面抓取录制jmeter测试脚本，是通过一些访问的坐标点击来获取测试脚本，不仅效率低下且难于修改维护。
针对上述的现有技术中，生成测试脚本的效率低下且难于修改维护的问题，目前尚未提出有效的解决方案。
技术实现要素：
本发明实施例提供了一种生成测试脚本的方法、装置及系统，以至少解决现有技术中，录制测试脚本的效率低下且难于修改维护的技术问题。
根据本发明实施例的一个方面，提供了一种生成测试脚本的方法，包括：监测web容器是否接收到测试请求；在监测到web容器接收到测试请求的情况下，web容器转发测试请求至目标设备；通过监听web容器与目标设备之间的测试端口，获取至少一种脚本数据，其中，至少一种脚本数据包括：测试请求中携带的测试参数、目标设备响应测试请求所返回的返回参数，以及通过标注返回参数得到的测试结果；通过对测试参数、返回参数和测试结果进行封装处理，生成测试脚本。
进一步的，在监测web容器是否接收到测试请求之前，方法还包括：通过测试目标设备，得到测试结果；标注测试结果是否正确，并获取标注为正确的测试结果；将标注为正确的测试结果，确定为第一测试结果，其中，第一测试结果包括：标准测试参数和标准返回参数。
进一步的，通过监听web容器与目标设备之间的测试端口，获取至少一种脚本数据，包括：通过监听web容器与目标设备之间的请求端口，获取测试请求中携带的测试参数，其中，测试参数包括如下至少之一：测试请求的方法名称、参数名称、测试类型和参数值；通过监听web容器与目标设备之间的返回端口，获取目标设备响应测试请求所返回的返回参数，其中，返回参数包括如下至少之一：目标设备的方法名称、参数名称、测试类型和参数值；根据标准返回参数对返回参数进行标注，得到目标设备的测试结果。
进一步的，在生成测试脚本之后，方法还包括：通过判断是否对目标设备进行回归测试，得到判断结果；在判断结果为是的情况下，输出测试脚本测试目标设备；接收目标设备返回的第二测试结果。
进一步的，在接收目标设备返回的第二测试结果之后，方法还包括：验证目标设备所返回的第二测试结果是否为预设测试结果；在验证出第二测试结果不是预设测试结果的情况下，调整目标设备或测试脚本。
进一步的，在通过判断是否对目标设备进行回归测试，得到判断结果之后，方法还包括：在判断结果为否的情况下，存储测试脚本。
进一步的，在根据标准返回参数对返回参数进行标注，得到目标设备的测试结果之前，方法还包括：显示返回参数。
进一步的，在web容器转发测试请求至目标设备之前，方法还包括：web容器加载目标设备。
根据本发明实施例的另一个方面，提供了一种生成测试脚本的装置，包括：监测模块，用于监测web容器是否接收到测试请求；转发模块，用于在监测到web容器接收到测试请求的情况下，web容器转发测试请求至目标设备；获取模块，用于通过监听web容器与目标设备之间的测试端口，获取至少一种脚本数据，其中，至少一种脚本数据包括：测试请求中携带的测试参数、目标设备响应测试请求所返回的返回参数，以及通过标注返回参数得到的测试结果；生成模块，用于通过对测试参数、返回参数和测试结果进行封装处理，生成测试脚本。
根据本发明实施例的另一个方面，提供了一种生成测试脚本的系统，包括：终端设备，用于发送测试请求；web容器，与终端设备连接，用于在接收到测试请求的情况下，将测试请求转发至目标设备；通过监听web容器与目标设备之间的测试端口，获取至少一种脚本数据，其中，至少一种脚本数据包括：测试请求中携带的测试参数、目标设备响应测试请求所返回的返回参数，以及通过标注返回参数得到的测试结果；通过对测试参数、返回参数和测试结果进行封装处理，生成测试脚本；目标设备，与web容器连接，用于接收web容器转发的测试请求，并根据测试请求返回相应的返回参数。
根据本发明实施例的另一个方面，提供了一种存储介质，存储介质包括存储的程序，其中，程序执行上述任意一项可选或优选的生成测试脚本的方法。
根据本发明实施例的另一个方面，还提供了一种处理器，处理器用于运行程序，其中，程序运行时执行上述任意一项可选或优选的生成测试脚本的方法。
在本发明实施例中，通过监测web容器是否接收到测试请求；在监测到web容器接收到测试请求的情况下，web容器转发测试请求至目标设备；通过监听web容器与目标设备之间的测试端口，获取至少一种脚本数据，其中，至少一种脚本数据包括：测试请求中携带的测试参数、目标设备响应测试请求所返回的返回参数，以及通过标注返回参数得到的测试结果；通过对测试参数、返回参数和测试结果进行封装处理，生成测试脚本，达到了自动化生成测试脚本的目的，从而实现了提高生成测试脚本的效率的技术效果，进而解决了现有技术中，录制测试脚本的效率低下且难于修改维护的技术问题。
附图说明
此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：
图1是根据现有技术的一种测试人员手动编写测试脚本的流程示意图；
图2是根据本发明实施例的一种生成测试脚本的方法的步骤流程图；
图3是根据本发明实施例的一种可选的生成测试脚本的方法的步骤流程图；
图4是根据本发明实施例的一种可选的生成测试脚本的方法的步骤流程图；
图5是根据本发明实施例的一种可选的生成测试脚本的方法的步骤流程图；
图6是根据本发明实施例的一种可选的生成测试脚本的方法的步骤流程图；
图7是根据本发明实施例的一种生成测试脚本的装置的结构示意图；以及
图8是根据本发明实施例的一种生成测试脚本的系统的结构示意图。
需要说明的是，以上附图中至少包括以下附图标记：
监测模块70、转发模块72、获取模块74、生成模块76、终端设备80、web容器82以及目标设备84。
具体实施方式
为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。
需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
实施例1
本发明实施例提供了一种生成测试脚本的方法实施例，需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。
在计算机领域中，应用程序的每一次很小的改动都要进行全量的回归测试，以确认修改没有引用新的错误或者导致其他代码产生错误，可以降低系统测试、维护升级等阶段的成本。因此，需要录制用于回归测试的测试脚本来测试修改后的代码或者英语程序，基于此，本申请提供了一种生成测试脚本的方法。
图2是根据本发明实施例的一种生成测试脚本的方法的步骤流程图，如图2所示，该方法包括如下步骤：
步骤s102，监测web容器是否接收到测试请求；
步骤s104，在监测到web容器接收到测试请求的情况下，web容器转发测试请求至目标设备。
具体的，上述web容器为windows系统的应用容器，需要说明的是，web容器为一种服务程序，服务器一个端口就有一个提供相应服务的程序，相应地，一个服务器可以有多个web容器，这些服务程序可以用于处理从客户端发出的请求，如java中的tomcat容器，asp的iis或pws都是web容器。
在上述步骤s102中，执行主体可以为web容器，通过监测web容器的数据收发端口，来判断web容器是否接收到测试请求，其中，该测试请求可以为用户终端发出的测试请求，优选的，可以是客户端发出的用于请求测试被测试系统的测试请求，其中，该测试请求可以用于请求回归测试、功能测试、性能测试、安全性测试、配置和兼容性测试、可用性测试、链接测试等。
可选的，上述目标设备可以为被测试系统，例如，账号管理系统，信息存储系统等web系统。
在一种可选的实施例中，软件的测试流程可以为：首先，用户提出测试需求并通过客户端发出测试请求，web容器接收到测试请求的情况下，表明当前需要对被测试系统进行测试，因而，可以根据客户端发出的测试请求建立测试用例，在web容器将接收到的测试请求转发至被测试系统之后，执行该测试用例对被测试系统进行测试。
步骤s106，通过监听web容器与目标设备之间的测试端口，获取至少一种脚本数据，其中，至少一种脚本数据包括：测试请求中携带的测试参数、目标设备响应测试请求所返回的返回参数，以及通过标注返回参数得到的测试结果。
步骤s108，通过对测试参数、返回参数和测试结果进行封装处理，生成测试脚本。
可选的，上述测试端口可以为web容器的80端口，至少一种脚本数据包括：测试请求中携带的测试参数、目标设备响应测试请求所返回的返回参数，以及通过标注返回参数得到的测试结果。
可选的，上述通过标注返回参数得到的测试结果，是根据测试人员在生成测试脚本之前得到的测试结果，通过web插件来标注返回参数是否为期望的正确结果。
在一种可选的实施例中，可以通过在web容器中设置web容器插件的方式，来监听web容器与被测试系统之间的数据收发端口，可选的，该web容器插件可以但不限于为能够监听web容器收发端口的任意一种插件，其中，可以通过热加载、java反射技术进行监听，例如，plugin-cfg.xmlhis与was均独立安装，以插件文件实现webserver与applicationserver间的请求与转发的监听。
需要说明的是，上述可选实施例所提及的热加载为一种表现形式，也即代码修改后，解析生成class文件，并将class文件复制(copy)到服务器web容器下(也即，发布程序)，web容器无需重启，class文件则可以直接生效的表现形式。
仍需要说明的是，上述可选实施例所提及的java反射技术为允许java程序对自身进行检查，并能直接操作程序的内部属性的技术，可以通过class对象调用类里面的方法。
在一种可选的实施例中，可以通过web容器插件监听web容器的80端口截获测试人员人工测试被测试web系统功能，以及被测web系统功能的响应返回的返回参数，来获取请求测试的方法名称、参数名称、类型及参数值和测试系统响应返回的参数名称、参数类型值及参数值，以及测试人员通过标注被测试系统响应返回的返回参数的测试结果。
作为一种可选的实施例，本申请根据获取到的测试参数、返回参数和测试结果进行封装处理，可以生成jmeter测试脚本，其中，jmeter全称apachejmeter是apache组织开发的基于java的压力测试工具，用于对软件做压力测试，它最初被设计用于web应用测试，但后来扩展到其他测试领域，可以用于测试静态和动态资源，例如静态文件、java小服务程序、cgi脚本、java对象、数据库、ftp服务器，等等。
在一种可选的实施例中，jmeter能够对应用程序做功能/回归测试，通过创建带有断言的脚本来验证所测试的程序是否返回期望的正确结果；为了最大限度的灵活性，jmeter允许使用正则表达式创建断言。
其中，上述可选的实施例中所提及的断言可以为布尔表达式，由于测试人员相信在程序中的某个特定点该表达式值为真，可以在任何时候启用和禁用断言验证，因此可以在测试时启用断言而在部署时禁用断言。同样，程序投入运行后，最终用户在遇到问题时可以重新启用断言。
以上述web容器为tomcat容器为例，本申请实施例可以通过监听tomcat的doget、dopost请求接口，获取被测试系统功能接口的uri、参数、方法、返回值，自动封装成测试用例及测试脚本。本申请所提供的上述实施例所得到的jmeter接口测试脚本，相比较现有的脚本录制方法，在可阅读、可维护性、准确性都有很大提高，提高了录制接口测试脚本的效率。
基于上述步骤s102至步骤s108所提供的实施例，通过监测web容器是否接收到测试请求；在监测到web容器接收到测试请求的情况下，web容器转发测试请求至目标设备；通过监听web容器与目标设备之间的测试端口，获取至少一种脚本数据，其中，至少一种脚本数据包括：测试请求中携带的测试参数、目标设备响应测试请求所返回的返回参数，以及通过标注返回参数得到的测试结果；通过对测试参数、返回参数和测试结果进行封装处理，生成测试脚本，达到了自动化录制测试脚本的目的，从而实现了提高录制测试脚本的效率的技术效果，进而解决了现有技术中，录制测试脚本的效率低下且难于修改维护的技术问题。
基于上述步骤s102至步骤s108所提供的实施例，本申请还提供了如下可选或优选的技术方案：
在一种可选的实施例中，图3是根据本发明实施例的一种可选的生成测试脚本的方法的步骤流程图，如图3所示，在监测web容器是否接收到测试请求之前，该方法还包括如下步骤：
步骤s202，通过测试目标设备，得到测试结果；
步骤s204，标注测试结果是否正确，并获取标注为正确的测试结果；
步骤s206，将标注为正确的测试结果，确定为第一测试结果，其中，第一测试结果包括：标准测试参数和标准返回参数。
为了确保回归测试的准确性，在进行回归测试，录制测试脚本之前，可以通过人工测试对测试系统一次，其中，人工测试的所采用的测试脚本可以为任意一种形式得到的测试脚本，例如，测试人员手工编写的测试脚本，jmeter自动录制的测试脚本等，标注得到的测试结果是否正确，并获取标注测试结果为正确的测试结果，以实现对回归测试被测试系统所返回的得到的返回参数进行标注，验证所测试的程序是否返回期望的正确结果。
在一种可选的实施例中，以上述被测试系统为账号管理系统为例，由于该系统中程序的每一次很小的改动都要进行全量的回归测试，但是通过使用web容器插件，测试人员不用学习jmeter的语法，也不用编写维护jmeter的测试脚本了，测试人员所要做的只是人工测试一次被测试系统功能，web容器就能输出所有测试功能的jmeter脚本，在进行回归测试时，可以直接采用测试脚本进行自动化测试。
在一种可选的实施例中，通过监听web容器与目标设备之间的测试端口，获取至少一种脚本数据，包括：通过监听web容器与目标设备之间的请求端口，获取测试请求中携带的测试参数，其中，测试参数包括如下至少之一：测试请求的方法名称、参数名称、测试类型和参数值；通过监听web容器与目标设备之间的返回端口，获取目标设备响应测试请求所返回的返回参数，其中，返回参数包括如下至少之一：目标设备的方法名称、参数名称、测试类型和参数值；根据标准返回参数对返回参数进行标注，得到目标设备的测试结果。
在一种可选的实施例中，图4是根据本发明实施例的一种可选的生成测试脚本的方法的步骤流程图，如图4所示，在生成测试脚本之后，该方法还包括如下步骤：
步骤s302，通过判断是否对目标设备进行回归测试，得到判断结果；
步骤s304，在判断结果为是的情况下，输出测试脚本测试目标设备；
步骤s306，接收目标设备返回的第二测试结果。
在上述步骤s302至步骤s306中，本申请实施例可以通过自动化生成的测试脚本对被测试系统进行回归测试，在被测试系统需要进行回归测试的情况下，可以通过引入测试脚本至被测试系统进行回归测试，并接收被测试系统返回的测试结果，以便于通过验证回归测试得到的测试结果是否正确，对所测试的程序进行调整。
在一种可选的实施例中，图5是根据本发明实施例的一种可选的生成测试脚本的方法的步骤流程图，如图5所示，在接收目标设备返回的第二测试结果之后，该方法还包括如下步骤：
步骤s402，验证目标设备所返回的第二测试结果是否为预设测试结果；
步骤s404，在验证出第二测试结果不是预设测试结果的情况下，调整目标设备或测试脚本。
在一种可选的实施例中，在通过判断是否对目标设备进行回归测试，得到判断结果之后，该方法还包括步骤：在判断结果为否的情况下，存储测试脚本。
在一种可选的实施例中，在根据标准返回参数对返回参数进行标注，得到目标设备的测试结果之前，该方法还包括步骤：显示返回参数。
在上述可选实施例中，在根据标准返回参数对返回参数进行标注，得到目标设备的测试结果之前，被测试系统可以显示上述返回参数，以便于测试人员对该次回归测试，被测试系统所返回的返回参数进行标注是否返回了预期结果。
在一种可选的实施例中，在web容器转发测试请求至目标设备之前，该方法还包括步骤：web容器加载目标设备。
以下提供一种可选的实施方案对上述实施例进行说明，图6是根据本发明实施例的一种可选的生成测试脚本的方法的步骤流程图，如图6所示，上述生成测试脚本的方法可以通过如下步骤实现：
步骤s502，测试被测试系统，并标注得到的测试结果是否正确。
具体的，可以通过测试人员人工测试被测试系统的功能或者程序，并通过人工标注测试结果是否正确，提高了首次测试的准确性，以达到根据首次测试结果对后期得到的测试脚本进行回归测试得到的测试结果进行验证，判断是否返回了期望的测试结果的目的。
步骤s504，web容器加载被测试系统。
具体的，上述web容器可以为基于windows系统的应用容器，上述被测试系统可以为被测试web系统，web容器可以自动加载被测试系统。
步骤s506，在web容器接收到测试请求的情况下，web容器转发测试请求到被测试系统。
具体的，该测试请求可以为客户端发送至web容器的测试请求。
步骤s508，监听web容器与被测试系统之间的数据收发端口。
具体的，上述端口可以为web容器的80端口,可选的，可以通过在web容器中设置web容器插件的方式，监听web容器与被测试系统之间的数据收发端口，以获取测试请求中携带的测试参数、目标设备响应测试请求所返回的返回参数。
以上述web容器为tomcat容器为例，可以通过监听tomcat的doget、dopost请求接口，获取被测试系统功能接口的uri、参数、方法、返回值等参数。
步骤s510，被测试系统显示web容器插件监听得到与请求测试相对应的返回参数。
具体的，在根据标准返回参数对返回参数进行标注，得到目标设备的测试结果之前，被测试系统可以显示上述返回参数，以便于测试人员对测试被测试系统所返回的返回参数进行标注是否返回了预期结果。
步骤s512，对返回参数进行标注，得到目标设备的测试结果。
具体的，对被测试系统根据测试请求所得到的返回参数进行标注，可以验证所测试的程序或者系统功能是否返回期望的正确结果。
步骤s514，通过对测试参数、返回参数和测试结果进行封装处理，生成测试脚本。
具体的，可以将测试请求中携带的测试参数、目标设备响应测试请求所返回的返回参数，以及通过标注返回参数得到的测试结果，按照jmeter语法请求及断言(期望的输出数据)输出被测功能的jmeter脚本。
步骤s516，判断是否对目标设备进行回归测试，得到判断结果。
在上述步骤s516中，在判断结果为是的情况下，执行步骤s518，在判断结果为否的情况下，执行步骤s520。
步骤s518，引入测试脚本，并通过web容器对被测试系统进行测试。
步骤s520，结束测试。
具体的，上述步骤s516至步骤s520是在得到回归测试脚本之后，判断是否自动化回归测试被测试系统的功能或者程序。
实施例2
本发明实施例提供了一种生成测试脚本的装置，需要说明的是，上述实施例1所提供的方法步骤，可以但不限于在本发明实施例所提供的生成测试脚本的装置中执行。
图7是根据本发明实施例的一种生成测试脚本的装置的结构示意图，如图7所示，该装置包括以下模块：监测模块70、转发模块72、获取模块74以及生成模块76，其中，
监测模块70，用于监测web容器是否接收到测试请求；转发模块72，用于在监测到web容器接收到测试请求的情况下，web容器转发测试请求至目标设备；获取模块74，用于通过监听web容器与目标设备之间的测试端口，获取至少一种脚本数据，其中，至少一种脚本数据包括：测试请求中携带的测试参数、目标设备响应测试请求所返回的返回参数，以及通过标注返回参数得到的测试结果；生成模块76，用于通过对测试参数、返回参数和测试结果进行封装处理，生成测试脚本。
需要说明的是，上述监测模块70、转发模块72、获取模块74以及生成模块76对应于实施例1中的步骤s102至步骤s108，上述模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例1所公开的内容。需要说明的是，上述模块作为装置的一部分可以在诸如一组计算机可执行指令的计算机系统中执行。
仍需要说明的是，上述各个模块是可以通过软件或硬件的形式来实现的，对于后者，可以通过以下方式来实现，但不限于此：上述各个模块位于同一处理器中；或者，上述各个模块位以任意组合的形式于不同的处理器中。
实施例3
本发明实施例提供了一种生成测试脚本的系统，需要说明的是，上述实施例1所提供的方法步骤和上述实施例2所提供的装置模块，可以但不限于在本发明实施例所提供的生成测试脚本的系统中执行或运行。
图8是根据本发明实施例的一种生成测试脚本的系统的结构示意图，如图8所示，该系统包括：终端设备80、web容器82以及目标设备84，其中，
终端设备80，用于发送测试请求；web容器82，与终端设备80连接，用于在接收到测试请求的情况下，将测试请求转发至目标设备；通过监听web容器与目标设备之间的测试端口，获取至少一种脚本数据，其中，至少一种脚本数据包括：测试请求中携带的测试参数、目标设备响应测试请求所返回的返回参数，以及通过标注返回参数得到的测试结果；通过对测试参数、返回参数和测试结果进行封装处理，生成测试脚本；目标设备84，与web容器82连接，用于接收web容器转发的测试请求，并根据测试请求返回相应的返回参数。
具体的，上述终端设备80可以为客户端，上述web容器82为windows系统的应用容器，需要说明的是，web容器可以是一种服务程序，服务器一个端口就有一个提供相应服务的程序，相应地，一个服务器可以有多个web容器，这些服务程序可以用于处理从客户端发出的请求，如java中的tomcat容器，asp的iis或pws都是web容器。
具体的，上述目标设备可以为被测试系统，例如，账号管理系统，信息存储系统等web系统。
可选的，上述测试端口可以为web容器的80端口，至少一种脚本数据包括：测试请求中携带的测试参数、目标设备响应测试请求所返回的返回参数，以及通过标注返回参数得到的测试结果。
可选的，上述通过标注返回参数得到的测试结果，是根据测试人员在生成测试脚本之前得到的测试结果，通过web插件来标注返回参数是否为期望的正确结果。
在一种可选的实施例中，可以通过监测web容器的数据收发端口，来判断web容器是否接收到测试请求，其中，该测试请求可以为用户终端发出的测试请求，优选的，可以是客户端发出的用于请求测试被测试系统的测试请求。
在一种可选的实施例中，可以通过在web容器中设置web容器插件的方式，来监听web容器与被测试系统之间的数据收发端口，可选的，该web容器插件可以但不限于为能够监听web容器收发端口的任意一种插件，其中，可以通过热加载、java反射技术进行监听，例如，plugin-cfg.xmlhis与was均独立安装，以插件文件实现webserver与applicationserver间的请求与转发的监听。
作为一种可选的实施例，可以通过web容器插件监听web容器的80端口截获测试人员人工测试被测试web系统功能，以及被测web系统功能的响应返回的返回参数，来获取请求测试的方法名称、参数名称、类型及参数值和测试系统响应返回的参数名称、参数类型值及参数值，以及测试人员通过标注被测试系统响应返回的返回参数的测试结果。
作为一种可选的实施例，本申请根据获取到的测试参数、返回参数和测试结果进行封装处理，可以生成jmeter测试脚本，其中，jmeter全称apachejmeter是apache组织开发的基于java的压力测试工具，用于对软件做压力测试。在一种可选的实施例中，jmeter能够对应用程序做功能/回归测试，通过创建带有断言的脚本来验证所测试的程序是否返回期望的正确结果；为了最大限度的灵活性，jmeter允许使用正则表达式创建断言。
需要说明的是，上述可选的实施例中所提及的断言可以为布尔表达式，由于测试人员相信在程序中的某个特定点该表达式值为真，可以在任何时候启用和禁用断言验证，因此可以在测试时启用断言而在部署时禁用断言。同样，程序投入运行后，最终用户在遇到问题时可以重新启用断言。
以上述web容器为tomcat容器为例，本申请实施例可以通过监听tomcat的doget、dopost请求接口，获取被测试系统功能接口的uri、参数、方法、返回值，自动封装成测试用例及测试脚本。本申请所提供的上述实施例所得到的jmeter接口测试脚本，相比较现有的脚本录制方法，在可阅读、可维护性、准确性都有很大提高，提高了录制接口测试脚本的效率。
实施例4
本发明实施例提供了一种存储介质，存储介质包括存储的程序，其中，程序执行上述任意一项可选或优选的生成测试脚本的方法。
本发明实施例提供的存储介质用于存储执行以下功能的程序：监测web容器是否接收到测试请求；在监测到web容器接收到测试请求的情况下，web容器转发测试请求至目标设备；通过监听web容器与目标设备之间的测试端口，获取至少一种脚本数据，其中，至少一种脚本数据包括：测试请求中携带的测试参数、目标设备响应测试请求所返回的返回参数，以及通过标注返回参数得到的测试结果；通过对测试参数、返回参数和测试结果进行封装处理，生成测试脚本。
本发明实施例提供的存储介质用于存储执行以下功能的程序：通过测试目标设备，得到测试结果；标注测试结果是否正确，并获取标注为正确的测试结果；将标注为正确的测试结果，确定为第一测试结果，其中，第一测试结果包括：标准测试参数和标准返回参数。
本发明实施例提供的存储介质用于存储执行以下功能的程序：通过监听web容器与目标设备之间的请求端口，获取测试请求中携带的测试参数，其中，测试参数包括如下至少之一：测试请求的方法名称、参数名称、测试类型和参数值；通过监听web容器与目标设备之间的返回端口，获取目标设备响应测试请求所返回的返回参数，其中，返回参数包括如下至少之一：目标设备的方法名称、参数名称、测试类型和参数值；根据标准返回参数对返回参数进行标注，得到目标设备的测试结果。
本发明实施例提供的存储介质用于存储执行以下功能的程序：通过判断是否对目标设备进行回归测试，得到判断结果；在判断结果为是的情况下，输出测试脚本测试目标设备；接收目标设备返回的第二测试结果。
本发明实施例提供的存储介质用于存储执行以下功能的程序：验证目标设备所返回的第二测试结果是否为预设测试结果；在验证出第二测试结果不是预设测试结果的情况下，调整目标设备或测试脚本。
实施例5
本发明实施例提供了一种处理器，处理器用于运行程序，其中，程序运行时执行上述任意一项可选或优选的生成测试脚本的方法。
本发明实施例提供的处理器用于运行执行以下功能的程序：监测web容器是否接收到测试请求；在监测到web容器接收到测试请求的情况下，web容器转发测试请求至目标设备；通过监听web容器与目标设备之间的测试端口，获取至少一种脚本数据，其中，至少一种脚本数据包括：测试请求中携带的测试参数、目标设备响应测试请求所返回的返回参数，以及通过标注返回参数得到的测试结果；通过对测试参数、返回参数和测试结果进行封装处理，生成测试脚本。
本发明实施例提供的处理器用于运行执行以下功能的程序：通过测试目标设备，得到测试结果；标注测试结果是否正确，并获取标注为正确的测试结果；将标注为正确的测试结果，确定为第一测试结果，其中，第一测试结果包括：标准测试参数和标准返回参数。
本发明实施例提供的处理器用于运行执行以下功能的程序：通过监听web容器与目标设备之间的请求端口，获取测试请求中携带的测试参数，其中，测试参数包括如下至少之一：测试请求的方法名称、参数名称、测试类型和参数值；通过监听web容器与目标设备之间的返回端口，获取目标设备响应测试请求所返回的返回参数，其中，返回参数包括如下至少之一：目标设备的方法名称、参数名称、测试类型和参数值；根据标准返回参数对返回参数进行标注，得到目标设备的测试结果。
本发明实施例提供的处理器用于运行执行以下功能的程序：通过判断是否对目标设备进行回归测试，得到判断结果；在判断结果为是的情况下，输出测试脚本测试目标设备；接收目标设备返回的第二测试结果。
本发明实施例提供的处理器用于运行执行以下功能的程序：验证目标设备所返回的第二测试结果是否为预设测试结果；在验证出第二测试结果不是预设测试结果的情况下，调整目标设备或测试脚本。
上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。
在本发明的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。
在本申请所提供的几个实施例中，应该理解到，所揭露的技术内容，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，可以为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些端口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本发明实施例方案的目的。
另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。