软件测试方法、装置及系统
阅读：376发布：2021-06-07
专利汇可以提供软件测试方法、装置及系统专利检索，专利查询，专利分析的服务。并且本 发明 公开了一种 软件 测试方法、装置及系统，其中，方法包括：获取接收到的开发自测 请求 中包含的请求参数信息，根据请求参数信息确定待测软件；根据预设的开发自测规则对待测软件进行自动化测试，根据测试结果生成结果反馈消息，以供确定自测是否通过；当接收到自测通过后提交的 质量 测试请求后，根据与开发自测规则相匹配的质量测试规则对待测软件进行质量测试。利用本发明提供的软件测试方法，能够简化软件测试流程，大大缩减了软件从开发到上线的时间，简化了软件开发人员和质量监管部 门 检测的工作内容。，下面是软件测试方法、装置及系统专利的具体信息内容。
1.一种软件测试方法，包括：
获取接收到的开发自测请求中包含的请求参数信息，根据所述请求参数信息确定待测软件；
根据预设的开发自测规则对所述待测软件进行自动化测试，根据测试结果生成结果反馈消息，以供确定自测是否通过；
当接收到自测通过后提交的质量测试请求后，根据与所述开发自测规则相匹配的质量测试规则对所述待测软件进行质量测试。
2.根据权利要求1所述的方法，其中，所述根据预设的开发自测规则对所述待测软件进行自动化测试，根据测试结果生成结果反馈消息的步骤具体包括：
判断生成的结果反馈消息是否为失败类反馈消息，若否，则显示用于触发质量测试请求的质量测试入口；若是，则根据接收到的版本迭代请求对所述待测软件进行版本迭代测试，并在迭代测试的测试结果为成功时显示用于触发质量测试请求的质量测试入口。
3.根据权利要求1或2所述的方法，其中，当所述结果反馈消息为失败类反馈消息时，所述根据测试结果生成结果反馈消息的步骤之后，进一步包括：
输出与所述待测软件相对应的测试日志，以供分析失败原因。
4.根据权利要求1-3任一所述的方法，其中，当接收到的开发自测请求为多次时，分别针对每次接收到的开发自测请求生成对应的结果反馈消息；则所述根据与所述开发自测规则相匹配的质量测试规则对所述待测软件进行质量测试的步骤具体包括：
根据最后一次生成的结果反馈消息确定所述待测软件的质量。
5.根据权利要求1-4任一所述的方法，其中，所述根据与所述开发自测规则相匹配的质量测试规则对所述待测软件进行质量测试的步骤之后，进一步包括：
针对所述待测软件进行功能测试和/或回归测试，并在接收到测试通过后发出的发布请求后，对所述待测软件进行发布。
6.根据权利要求1-5任一所述的方法，其中，所述请求参数信息包括以下中的至少一个：待测软件在版本服务器中对应的存储地址、待测软件的软件版本号、待测软件的端口号、以及测试维度。
7.根据权利要求6所述的方法，其中，所述测试维度包括以下中的至少一个：启动停止类测试、功能自动化测试、性能测试、稳定性测试、单机自动化建库测试、异常测试、以及内存泄露专项测试。
8.一种软件测试系统，包括：
获取模块，适于获取接收到的开发自测请求中包含的请求参数信息，根据所述请求参数信息确定待测软件；
自测模块，适于根据预设的开发自测规则对所述待测软件进行自动化测试，根据测试结果生成结果反馈消息，以供确定自测是否通过；
质量测试模块，适于当接收到自测通过后提交的质量测试请求后，根据与所述开发自测规则相匹配的质量测试规则对所述待测软件进行质量测试。
9.一种电子设备，包括：处理器、存储器、通信接口和通信总线，所述处理器、所述存储器和所述通信接口通过所述通信总线完成相互间的通信；
所述存储器用于存放至少一可执行指令，所述可执行指令使所述处理器执行如权利要求1-7中任一项所述的软件自测方法对应的操作。
10.一种计算机存储介质，所述存储介质中存储有至少一可执行指令，所述可执行指令使处理器执行如权利要求1-7中任一项所述的软件测试方法对应的操作。
软件测试方法、装置及系统
技术领域
[0001] 本发明涉及计算机技术领域，具体涉及一种软件测试方法、装置及系统。
背景技术
[0002] 随着计算机技术的飞速发展，越来越多的软件被开发出来并使用。新开发的软件在上线之前为了检验是否有缺陷、是否符合预期效或者以最优的方法实现、或者是否有利于以后系统的维护优化，都需要经过一系列的检测之后确认没有缺陷才能被发布并且上线使用。所以，软件测试显得尤为重要。
[0003] 但是在现有技术中，软件被开发出来往往要经过自测、冒烟测试、提测、自动化测试和新功能测试、版本迭代、回归测试等一系列过程才能被上线使用。其中，在开发自测的过程中，需要对软件进行打包、部署、执行测试；对软件进行冒烟测试的时候，需要开发人员向质量监管部门获取一些自动化测试用例。所以，操作复杂繁琐而且消耗时间和精力。而且在真正提测的时候，质量监管部门需要针对提测的软件版本对开发人员执行过的测试进行二轮校验，所以存在重复性的工作。在提测之后，由于开发自测的结论受环境、自测测试方法、自测不充分等因素影响，结果认可度并不高等一系列的原因，被提测软件版本被打回频次较大，版本迭代的概率比较高。当提测软件版本被打回去之后还要重新进行提测、反复进行之前重复的测试步骤，所以耗时耗力，而且需要引入很大的沟通成本。由于种种不确定因素在里面，版本从提测到真正上线，持续周期往往比较长，经常出现版本延迟上线的问题。所以，现有技术中缺少一种新的软件测试方法来解决上述问题。
发明内容
[0004] 鉴于上述问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的软件测试方法、装置及系统。
[0005] 根据本发明的一个方面，提供了一种软件测试方法，该方法包括：
[0007] 根据预设的开发自测规则对待测软件进行自动化测试，根据测试结果生成结果反馈消息，以供确定自测是否通过；
[0008] 当接收到自测通过后提交的质量测试请求后，根据与开发自测规则相匹配的质量测试规则对待测软件进行质量测试。
[0009] 根据本发明的另一方面，提供了一种软件测试装置，该装置包括：
[0010] 获取模块，适于获取接收到的开发自测请求中包含的请求参数信息，根据请求参数信息确定待测软件；
[0011] 自测模块，适于根据预设的开发自测规则对待测软件进行自动化测试，根据测试结果生成结果反馈消息，以供确定自测是否通过；
[0012] 质量测试模块，适于当接收到自测通过后提交的质量测试请求后，根据与开发自测规则相匹配的质量测试规则对待测软件进行质量测试。
[0014] 存储器用于存放至少一可执行指令，可执行指令使处理器执行上述软件测试方法对应的操作。
[0015] 根据本发明的再一方面，提供了一种计算机存储介质，存储介质中存储有至少一可执行指令，可执行指令使处理器执行如上述软件测试方法对应的操作。
[0016] 根据本发明的软件自测方法、装置及系统，通过接收开发者自测请求，并获取开发自测请求中包含的请求参数信息，并根据预设的开发自测规则对待测软件进行自动化测试，将开发人员自己测试软件和质量管理人员测试软件质量的过程统一起来，在两个环节中设置同样的测试标准，这样开发者和质量管理者对测试数据的理解会高度一致，方便了开发人员和质量管理者的沟通协作。这样既简化了开发自测过程，开发人员可以使用现成的标准化环境对软件进行测试从而省去了开发人员自己单独找机器、建立测试环境对软件进行自测、也省去了在冒烟测试的时候向质量监管部门获取一些自动化测试用例等一系列的繁琐过程，省时省力。同时，也规范了开发自测过程和结果，使开发自测流程标准化。通过根据预设的开发自测规则对待测软件进行自动化测试，根据测试结果生成结果反馈消息，以供确定自测是否通过，并当接收到自测通过后提交的质量测试请求后，根据与开发自测规则相匹配的质量测试规则对待测软件进行质量测试。减少了比如开发自测的重复工作，缩短了提测周期，将问题暴露时间点提前，并将版本迭代放在了自测阶段。利用本发明提供的软件测试方法，能够简化软件测试流程，大大缩减了软件从开发到上线的时间，简化了软件开发人员和质量监管部门检测的工作内容，使质量监管部门可以将更多地精力关注测试流程工具的维护、测试方法的创新。
[0017] 上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。附图说明
[0018] 通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：
[0020] 图2示出了本发明另一个实施例的软件测试方法的流程图；
[0021] 图3示出了本发明根据测试结果生成结果反馈消息的一种示意图；
[0022] 图4示出了根据本发明一实施例提供的软件测试方法测试软件的一种结果示意图；
[0023] 图5示出了本发明又一个实施例的软件测试装置的功能框图；
[0024] 图6示出了本发明实施例的一种电子设备的结构示意图。
具体实施方式
[0025] 下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。
[0026] 图1示出了本发明一个实施例的软件测试方法的流程图。如图1所示，该方法包括以下步骤：
[0027] 步骤S101，获取接收到的开发自测请求中包含的请求参数信息，根据请求参数信息确定待测软件。
[0028] 当开发人员需要对软件进行测试时，通过预先设置的接口发出自测请求，通过获取接收到的开发自测请求中包含的请求参数信息，并根据这些参数信息可以通过检测或运算等步骤对应地确定待测软件的版本信息和需要测试的内容等。其中，请求参数信息包括以下中的至少一个：待测软件在版本服务器中对应的存储地址、待测软件的软件版本号、待测软件的端口号、以及测试维度等，在此不一一叙述。
[0029] 步骤S102，根据预设的开发自测规则对待测软件进行自动化测试，根据测试结果生成结果反馈消息，以供确定自测是否通过。
[0030] 质量管理部门预先设置开发自测规则并提供给开发人员使用，开发人员通过该预设的开发自测规则对待测软件进行自动化测试，开发人员只需要填写如步骤S101中的请求参数，即可触发启动测试任务。其中，预先设置的开发自测规则可以包括测试环境、自动化维度或其它的细节等，在此不一一叙述。根据测试结果生成的结果反馈消息可以为测试通过类的反馈信息，测试失败类的反馈信息。比如测试结果生成的结果反馈消息为启动停止类测试通过，功能自动化测试失败，从而可以确定启动停止类测试通过，功能自动化测试未通过。也可以为其它测试项目的测试结果反馈信息，在此不一一叙述。
[0031] 步骤S103，当接收到自测通过后提交的质量测试请求后，根据与开发自测规则相匹配的质量测试规则对待测软件进行质量测试。
[0032] 在步骤S102中测试通过后，当接收到自测通过后提交的质量测试请求后，根据与开发自测规则相匹配的质量测试规则对待测软件进行质量测试。
[0033] 当接收到的开发自测请求为多次时，分别针对每次接收到的开发自测请求生成对应的结果反馈消息；则上述根据与开发自测规则相匹配的质量测试规则对待测软件进行质量测试的步骤具体包括：根据最后一次生成的结果反馈消息确定待测软件的质量，这样质量监管部门可以省去了重复执行自动化测试的繁琐过程。比如，如果总共接受到3次开发自测请求，针对第一次接收到的开发自测请求生成对应的结果反馈消息a，针对第二次接收到的开发自测请求生成对应的结果反馈消息b，针对第三次接收到的开发自测请求生成对应的结果反馈消息c，则根据结果反馈消息c对待测软件进行质量测试从而确定待测软件的质量。
[0034] 其中测试结果可以大致分为如下几类：
[0035] 功能自动化回归类：不需要人工干预，结果直接会报通过与否。自动化建库相关类：不需要人工干预，通过与否结果直接显示。性能及稳定性结果类，需要针对格式化的结果输出，结合提测版本特性，评估能否通过。
[0036] 其中，质量测试规则可以是一套与开发自测规则相同或者基本相同的规则，也可以直接将质量测试规则设置为：根据自测的结果确定质量测试结果的规则，在此不作限制。从而将开发人员自己测试待测软件的环节和质量管理人员测试对该提测的待测软件的质量的环节统一起来，通过在两个环节中设置同样的测试标准，以规范开发人员的自测方式和结果。比如开发人员使用质量监管部门提供的开发自测规则A对待测软件进行测试并且通过提测之后，质量监管部门可以将与开发自测规则A相匹配的质量测试设置为开发自测规则A或者与开发自测规则A基本相同的规则，也可以直接将质量测试规则设置为：根据通过开发自测规则A自测的结果确定质量测试结果的规则B。
[0037] 另外，上述步骤S101～S103中提到的测试的维度包括以下中的至少一个：启动停止类测试、功能自动化测试、性能测试、稳定性测试、单机自动化建库测试、异常测试、以及内存泄露专项测试等，在此不一一叙述。
[0038] 根据本实施例提供的软件测试方法，通过接收开发者自测请求，并获取开发自测请求中包含的请求参数信息，并根据预设的开发自测规则对待测软件进行自动化测试，将开发人员自己测试软件和质量管理人员测试软件质量的过程统一起来，在两个环节中设置同样的测试标准，这样开发者和质量管理者对测试数据的理解会高度一致，方便了开发人员和质量管理者的沟通协作。这样既简化了开发自测过程，开发人员可以使用现成的标准化环境对软件进行测试从而省去了开发人员自己单独找机器、建立测试环境对软件进行自测、也省去了在冒烟测试的时候向质量监管部门获取一些自动化测试用例等一系列的繁琐过程，省时省力。同时，也规范了开发自测过程和结果，使开发自测流程标准化。通过根据预设的开发自测规则对待测软件进行自动化测试，根据测试结果生成结果反馈消息，以供确定自测是否通过，并当接收到自测通过后提交的质量测试请求后，根据与开发自测规则相匹配的质量测试规则对待测软件进行质量测试。减少了比如开发自测的重复工作，缩短了提测周期，将问题暴露时间点提前，并将版本迭代放在了自测阶段。利用本发明提供的软件测试方法，能够简化软件测试流程，大大缩减了软件从开发到上线的时间，简化了软件开发人员和质量监管部门检测的工作内容，使质量监管部门可以将更多地精力关注测试流程工具的维护、测试方法的创新。
[0039] 图2示出了本发明另一个实施例的软件测试方法的流程图。如图2所示，该方法包括以下步骤：
[0040] 步骤S201，通过预设的开发自测接口接收开发自测请求。
[0041] 当开发人员需要对软件进行测试时，首先，预先设置开发自测接口，通过预先设置的开发自测接口来接收待测软件的开发自测请求。
[0042] 步骤S202，获取接收到的开发自测请求中包含的请求参数信息，根据请求参数信息确定待测软件。
[0043] 通过获取接收到的开发自测请求中包含的请求参数信息，并根据这些参数信息确定待测软件的版本信息和需要测试的内容等。其中，请求参数信息包括以下中的至少一个：待测软件在版本服务器中对应的存储地址、待测软件的软件版本号、待测软件的端口号、以及测试维度等，在此不一一叙述。
[0044] 步骤S203，根据预设的开发自测规则对待测软件进行自动化测试，根据测试结果生成结果反馈消息。
[0045] 质量管理部门预先设置开发自测规程并提供给开发人员使用，开发人员通过该预设的开发自测规则对待测软件进行自动化测试，开发人员只需要填写如步骤S202中的请求参数，即可触发启动测试任务。其中，预先设置的开发自测规则可以包括测试环境、自动化维度或其它的细节等，在此不一一叙述。具体地，测试的具体流程比如可以为：测试人员对待测软件在版本服务器中对应的存储地址进行检测、blade编译、基于业务进行deploy部署、测试环境检测、启动服务、执行测试、测试完成收集数据、最后进行结果分析并且格式化输出测试结果。
[0046] 根据测试结果生成的结果反馈消息可以为测试通过类的反馈信息，测试失败类的反馈信息。比如测试结果生成的结果反馈消息可以为启动停止类测试通过，功能自动化测试失败，从而可以确定启动停止类测试通过，功能自动化测试未通过。也可以为其它测试项目的测试结果反馈信息，在此不一一叙述。
[0047] 实现上述测试过程需要的程序设计技术可以为Jenkins、shell、python、php等，在此不一一叙述。
[0048] 步骤S204，判断生成的结果反馈消息是否为失败类反馈消息。
[0049] 进一步地判断在步骤S203中生成的结果反馈消息是否为失败类反馈消息。
[0050] 步骤S205，若是，则输出与待测软件相对应的测试日志，以供分析失败原因。
[0051] 图3示出了本发明根据测试结果生成结果反馈消息的一种示意图。若在步骤S204中判断生成的结果反馈消息为失败类反馈消息，则输出如图3所示的与待测软件相对应的测试日志，以供分析失败原因。如图3所示，在本次软件测试过程中，与待测软件相对应的测试日志测试的项目包括:占用机器、打包、部署、branch版本建库测试、Declarative:Post Actions、释放机器等。并且显示了它们的平均测试所用时间分别为：8s、1min 47s、3min 8s、1min 43s、8min 53s、573ms、8s。同时也示出了上述测试项目本次的测试所用时间分别为：6s、118ms、2min 40s、188ms、17ms、577ms、6s。并且如图3所示，在“部署”测试项目的本次测试所用时间表格内显示有“failed”字样，则表示本次测试中“部署”测试项目存在bug或者其它问题。从而开发人员可以从中清楚地分析出本次软件测试失败原因，从而针对存在的bug或者其它问题对软件进行修改并且进行版本迭代过程。
[0052] 步骤S206，根据接收到的版本迭代请求对待测软件进行版本迭代测试。
[0053] 当在步骤S205中找出待测软件存在的bug或者其它问题之后，需要针对出现的bug或者其它问题对软件进行修改并且进行版本迭代过程。对版本进行迭代之后，需要进一步地进行版本迭代测试。在本步骤S206中，根据接收到的版本迭代请求对待测软件进行版本迭代测试，从而判断待测软件是否解决了在步骤S205中发现的bug或者其它问题，并且检测是否有新的bug或者其它问题的出现。
[0054] 步骤S207，判断迭代测试的结果是否为成功。
[0055] 若否，则重复执行步骤S205、S206中的内容。若判断迭代测试的结果为成功，则执行步骤S208。
[0056] 步骤S208，显示用于触发质量测试请求的质量测试入口。
[0057] 当在步骤S204中判断生成的结果反馈信息不是失败类反馈信息或者在步骤S207中判断迭代测试的结果为成功时，则显示用于触发质量测试请求的质量测试入口。比如有时候为了确立软件操作系统的稳定性或者服务器的承受能力，需要对其进行压测，如果根据预设的开发自测规则对待测软件进行压测，根据测试结果生成结果反馈消息不是失败类反馈信息或者在迭代测试的结果是为成功时，则显示用于触发质量测试请求的质量测试入口，表示此次测试通过。
[0058] 步骤S209，根据与开发自测规则相匹配的质量测试规则对待测软件进行质量测试。
[0059] 在步骤S208中显示用于触发质量测试请求的质量测试入口之后，根据与开发自测规则相匹配的质量测试规则对待测软件进行质量测试。
[0060] 当接收到的开发自测请求为多次时，分别针对每次接收到的开发自测请求生成对应的结果反馈消息；则上述根据与开发自测规则相匹配的质量测试规则对待测软件进行质量测试的步骤具体包括：根据最后一次生成的结果反馈消息确定待测软件的质量，这样质量监管部门可以省去了重复执行自动化测试的繁琐过程。比如，如果总共接受到3次开发自测请求，针对第一次接收到的开发自测请求生成对应的结果反馈消息a，针对第二次接收到的开发自测请求生成对应的结果反馈消息b，针对第三次接收到的开发自测请求生成对应的结果反馈消息c，则根据结果反馈消息c对待测软件进行质量测试从而确定待测软件的质量。
[0061] 其中测试结果可以大致分为如下几类：
[0062] 功能自动化回归类：不需要人工干预，结果直接会报通过与否。自动化建库相关类：不需要人工干预，通过与否结果直接显示。性能及稳定性结果类，需要针对格式化的结果输出，结合提测版本特性，评估能否通过。
[0063] 其中，质量测试规则可以是一套与开发自测规则相同或者基本相同的规则，也可以直接将质量测试规则设置为：根据自测的结果确定质量测试结果的规则，在此不作限制。从而将开发人员自己测试待测软件的环节和质量管理人员测试对该提测的待测软件的质量的环节统一起来，通过在两个环节中设置同样的测试标准，以规范开发人员的自测方式和结果。比如开发人员使用质量监管部门提供的开发自测规则A对待测软件进行测试并且通过提测之后，质量监管部门可以将与开发自测规则A相匹配的质量测试设置为开发自测规则A或者与开发自测规则A基本相同的规则，也可以直接将质量测试规则设置为：根据通过开发自测规则A自测的结果确定质量测试结果的规则B。
[0064] 步骤S2010，针对待测软件进行功能测试和/或回归测试，并在接收到测试通过后发出的发布请求后，对待测软件进行发布。
[0065] 在步骤S209中根据与开发自测规则相匹配的质量测试规则对待测软件进行质量测试并且通过之后，针对待测软件进行功能测试和/或回归测试，并在接收到测试通过后发出的发布请求后，对待测软件进行发布，这样待测软件就可以上线使用。
[0066] 另外，上述步骤S201～S2010中提到的测试维度包括以下中的至少一个：启动停止类测试、功能自动化测试、性能测试、稳定性测试、单机自动化建库测试、异常测试、以及内存泄露专项测试等，在此不一一叙述。
[0067] 图4示出了根据一实施例提供的软件测试方法测试软件的一种结果示意图。如图4所示，本次测试为Searcher常规化测试，图中并显示了本次测试结果详情。如图4所示，本次测试项目的总数为7个，测试通过的个数为7个，失败的个数为0个，通过率为100％，失败率为0，query数为678。从表示成功或失败的饼状图中可以看出本次测试的结果为通过。图5中还示出了其它测试详情信息比如本次测试的功能，测试服务器、Base服务器、开始时间、结束时间、和耗时等等。通过如图4所示的测试结果，质量测试部门可以清晰的看出开发人员进行测试的详情结果，从而比较容易地确定此次被测软件的质量。
[0068] 根据本实施例提供的软件测试方法，首先通过预设的开发自测接口接收开发自测请求，并获取开发自测请求中包含的请求参数信息，并根据预设的开发自测规则对待测软件进行自动化测试，根据测试结果生成结果反馈消息。由于开发自测规则是由质量管理部门预先设定的，其包括的测试环境、自动化维度或其它的细节等由质量管理部门设定的、测试的结果数据也由质量管理部门收集的，所以简化了开发自测过程，开发人员可以使用现成的标准化环境对软件进行测试从而省去了开发人员自己单独找机器、建立测试环境对软件自测、也省去了在冒烟测试的时候向质量监管部门获取一些自动化测试用例等一系列的繁琐过程，省时省力。因为将开发人员自己测试软件和质量管理人员测试软件质量的过程统一了起来，在两个环节中设置同样的测试标准，整个测试的过程是可控的，这样开发者和质量管理者对测试数据的理解会高度一致，方便了开发人员和质量管理者的沟通协作。同时，也规范了开发自测过程和结果，使开发自测流程标准化。然后进一步地，判断生成的结果反馈消息是否为失败类反馈消息。若是，则输出与待测软件相对应的测试日志，以供分析失败原因，并根据接收到的版本迭代请求对待测软件进行版本迭代测试。通过输出与待测软件相对应的测试日志，开发人员可以清楚的看到并分析出测试失败的原因并对待测软件进行然本迭代。通过将版本迭代放在了自测阶段，将问题暴露时间点提前了，并缩短了提测周期。若判断出生成的结果反馈消息不是失败类反馈消息或者判断迭代测试的结果成功时，显示用于触发质量测试请求的质量测试入口并根据与开发自测规则相匹配的质量测试规则对待测软件进行质量测试。由于质量管理部门只根据最后一次生成的结果反馈消息确定待测软件的质量，这样质量监管部门可以省去了重复执行自动化测试的繁琐过程。最后针对待测软件进行功能测试和/或回归测试，并在接收到测试通过后发出的发布请求后，对待测软件进行发布。利用本发明提供的软件测试方法，能够简化软件测试流程，大大缩减了软件从开发到上线的时间，简化了软件开发人员和质量监管部门检测的工作内容，使质量监管部门可以将更多地精力关注测试流程工具的维护、测试方法的创新。
[0069] 图5示出了本发明又一个实施例的软件测试装置的功能框图。如图5所示，该装置包括：接收模块501、获取模块502、自测模块503、质量测试模块504以及功能测试和/或回归测试模块505。
[0070] 其中，接收模块501，适于在获取接收到的开发自测请求中包含的请求参数信息的步骤之前，通过预设的开发自测接口接收开发自测请求。
[0071] 当开发人员需要对软件进行测试时，首先，预先在软件测试装置中设置开发自测接口，通过预先设置的开发自测接口来接收待测软件的开发自测请求。
[0072] 获取模块502，适于获取接收到的开发自测请求中包含的请求参数信息，根据请求参数信息确定待测软件。
[0073] 获取模块502通过获取接收模块501接收到的开发自测请求中包含的请求参数信息，并根据这些参数信息确定待测软件的版本信息和需要测试的内容等。其中，请求参数信息包括以下中的至少一个：待测软件在版本服务器中对应的存储地址、待测软件的软件版本号、待测软件的端口号、以及测试维度等，在此不一一叙述。
[0074] 自测模块503，适于根据预设的开发自测规则对待测软件进行自动化测试，根据测试结果生成结果反馈消息，以供确定自测是否通过。
[0075] 质量管理部门预先设置开发自测规程并提供给开发人员使用，自测模块503通过该预设的开发自测规则对待测软件进行自动化测试，开发人员只需要填写如获取模块502中获取的请求参数，即可触发启动测试任务。其中，预先设置的开发自测规则可以包括测试环境、自动化维度或其它的细节等，在此不一一叙述。具体地，测试的具体流程比如可以为：测试人员对待测软件在版本服务器中对应的存储地址进行检测、blade编译、基于业务进行deploy部署、测试环境检测、启动服务、执行测试、测试完成收集数据、最后进行结果分析并且格式化输出测试结果。
[0076] 根据测试结果生成的结果反馈消息可以为测试通过类的反馈信息，测试失败类的反馈信息。比如测试结果生成的结果反馈消息可以为启动停止类测试通过，功能自动化测试失败，从而可以确定启动停止类测试通过，功能自动化测试未通过。也可以为其它测试项目的测试结果反馈信息，在此不一一叙述。
[0077] 实现上述测试过程需要的程序设计技术可以为Jenkins、shell、python、php等，在此不一一叙述。
[0078] 自测模块503进一步适于判断生成的结果反馈消息是否为失败类反馈消息，若否，则显示用于触发质量测试请求的质量测试入口；若是，则根据接收到的版本迭代请求对待测软件进行版本迭代测试，并在迭代测试的测试结果为成功时显示用于触发质量测试请求的质量测试入口。
[0079] 自测模块503进一步适于在当结果反馈消息为失败类反馈消息时，根据测试结果生成结果反馈消息的步骤之后输出与待测软件相对应的测试日志，以供分析失败原因。
[0080] 具体地，图3示出了本发明根据测试结果生成结果反馈消息的一种示意图。若自测模块503判断生成的结果反馈消息为失败类反馈消息，则输出如图3所示的与待测软件相对应的测试日志，以供分析失败原因。如图3所示，在某次软件测试过程中，与待测软件相对应的测试日志测试的项目包括:占用机器、打包、部署、branch版本建库测试、Declarative:Post Actions、释放机器等。并且显示了它们的平均测试所用时间分别为：8s、1min 47s、
3min 8s、1min 43s、8min 53s、573ms、8s。同时也示出了上述测试项目本次的测试所用时间分别为：6s、118ms、2min 40s、188ms、17ms、577ms、6s。并且如图3所示，在“部署”测试项目的本次测试所用时间表格内显示有“failed”字样，则表示本次测试中“部署”测试项目存在bug或者其它问题。从而开发人员可以从中清楚地分析出本次软件测试失败原因，从而对针对存在的bug或者其它问题对软件进行修改并且进行版本迭代过程。对版本进行迭代之后，需要进一步地进行版本迭代测试。根据接收到的版本迭代请求对待测软件进行版本迭代测试，从而判断待测软件是否解决了发现的bug或者其它问题，并且检测是否有新的bug或者其它问题的出现。若判断生成的结果反馈信息不是失败类反馈信息或者判断迭代测试的结果是为成功时，则显示用于触发质量测试请求的质量测试入口。比如有时候为了确立软件操作系统的稳定性或者服务器的承受能力，需要对其进行压测，如果根据预设的开发自测规则对待测软件进行自动化测试，根据测试结果生成结果反馈消息不是失败类反馈信息或者在迭代测试的结果是为成功时，则显示用于触发质量测试请求的质量测试入口，表示此次测试通过。
3min 8s、1min 43s、8min 53s、573ms、8s。同时也示出了上述测试项目本次的测试所用时间分别为：6s、118ms、2min 40s、188ms、17ms、577ms、6s。并且如图3所示，在“部署”测试项目的本次测试所用时间表格内显示有“failed”字样，则表示本次测试中“部署”测试项目存在bug或者其它问题。从而开发人员可以从中清楚地分析出本次软件测试失败原因，从而对针对存在的bug或者其它问题对软件进行修改并且进行版本迭代过程。对版本进行迭代之后，需要进一步地进行版本迭代测试。根据接收到的版本迭代请求对待测软件进行版本迭代测试，从而判断待测软件是否解决了发现的bug或者其它问题，并且检测是否有新的bug或者其它问题的出现。若判断生成的结果反馈信息不是失败类反馈信息或者判断迭代测试的结果是为成功时，则显示用于触发质量测试请求的质量测试入口。比如有时候为了确立软件操作系统的稳定性或者服务器的承受能力，需要对其进行压测，如果根据预设的开发自测规则对待测软件进行自动化测试，根据测试结果生成结果反馈消息不是失败类反馈信息或者在迭代测试的结果是为成功时，则显示用于触发质量测试请求的质量测试入口，表示此次测试通过。
[0081] 另外，当接收到的开发自测请求为多次时，自测模块503进一步适于分别针对每次接收到的开发自测请求生成对应的结果反馈消息。
[0082] 质量测试模块504，适于当接收到自测通过后提交的质量测试请求后，根据与开发自测规则相匹配的质量测试规则对待测软件进行质量测试。
[0083] 质量测试模块504进一步适于根据最后一次生成的结果反馈消息确定待测软件的质量。
[0084] 当接收到的开发自测请求为多次时，自测模块503分别针对每次接收到的开发自测请求生成对应的结果反馈消息；则质量测试模块504根据最后一次生成的结果反馈消息确定待测软件的质量，这样质量监管部门可以省去了重复执行自动化测试的繁琐过程。比如，如果总共接受到3次开发自测请求，针对第一次接收到的开发自测请求生成对应的结果反馈消息a，针对第二次接收到的开发自测请求生成对应的结果反馈消息b，针对第三次接收到的开发自测请求生成对应的结果反馈消息c，则根据结果反馈消息c对待测软件进行质量测试从而确定待测软件的质量。
[0085] 其中测试结果可以大致分为如下几类：
[0086] 功能自动化回归类：不需要人工干预，结果直接会报通过与否。自动化建库相关类：不需要人工干预，通过与否结果直接显示。性能及稳定性结果类，需要针对格式化的结果输出，结合提测版本特性，评估能否通过。
[0087] 其中，质量测试规则可以是一套与开发自测规则相同或者基本相同的规则，也可以直接将质量测试规则设置为：根据自测的结果确定质量测试结果的规则，在此不作限制。从而将开发人员自己测试待测软件的环节和质量管理人员测试对该提测的待测软件的质量的环节统一起来，通过在两个环节中设置同样的测试标准，以规范开发人员的自测方式和结果。比如开发人员使用质量监管部门提供的开发自测规则A对待测软件进行测试并且通过提测之后，质量监管部门可以将与开发自测规则A相匹配的质量测试设置为开发自测规则A或者与开发自测规则A基本相同的规则，也可以直接将质量测试规则设置为：根据通过开发自测规则A自测的结果确定质量测试结果的规则B。
[0088] 测试发布模块505，适于在根据与开发自测规则相匹配的质量测试规则对待测软件进行质量测试的步骤之后，针对待测软件进行功能测试和/或回归测试，并在接收到测试通过后发出的发布请求后，对待测软件进行发布。
[0089] 在质量测试模块504根据与开发自测规则相匹配的质量测试规则对待测软件进行质量测试并且通过之后，测试发布模块505针对待测软件进行功能测试和/或回归测试，并在接收到测试通过后发出的发布请求后，对待测软件进行发布，这样待测软件就可以上线使用了。
[0090] 另外，上述模块501～模块505中提到的测试维度包括以下中的至少一个：启动停止类测试、功能自动化测试、性能测试、稳定性测试、单机自动化建库测试、异常测试、以及内存泄露专项测试等，在此不一一叙述。
[0091] 利用本实施例提供的测试装置，能够简化软件测试流程，大大缩减了软件从开发到上线的时间，简化了软件开发人员和质量监管部门检测的工作内容，使质量监管部门可以将更多地精力关注测试流程工具的维护、测试方法的创新。
[0092] 根据本发明一个实施例提供了一种非易失性计算机存储介质，所述计算机存储介质存储有至少一可执行指令，该计算机可执行指令可执行上述任意方法实施例中的软件测试方法。
[0093] 图6示出了本发明实施例的一种电子设备的结构示意图，本发明具体实施例并不对电子设备的具体实现做限定。
[0094] 如图6所示，该电子设备可以包括：处理器(processor)602、通信接口(Communications Interface)604、存储器(memory)606、以及通信总线608。
[0095] 其中：
[0096] 处理器602、通信接口604、以及存储器606通过通信总线608完成相互间的通信。
[0097] 通信接口604，用于与其它设备比如客户端或其它服务器等的网元通信。
[0098] 处理器602，用于执行程序610，具体可以执行上述软件测试方法实施例中的相关步骤。
[0099] 具体地，程序610可以包括程序代码，该程序代码包括计算机操作指令。
[0100] 处理器602可能是中央处理器CPU，或者是特定集成电路ASIC(Application Specific Integrated Circuit)，或者是被配置成实施本发明实施例的一个或多个集成电路。电子设备包括的一个或多个处理器，可以是同一类型的处理器，如一个或多个CPU；也可以是不同类型的处理器，如一个或多个CPU以及一个或多个ASIC。
[0101] 存储器606，用于存放程序610。存储器606可能包含高速RAM存储器，也可能还包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。
[0102] 程序610具体可以用于使得处理器602执行以下操作：
[0103] 获取接收到的开发自测请求中包含的请求参数信息，根据请求参数信息确定待测软件；
[0104] 根据预设的开发自测规则对待测软件进行自动化测试，根据测试结果生成结果反馈消息，以供确定自测是否通过；
[0105] 当接收到自测通过后提交的质量测试请求后，根据与开发自测规则相匹配的质量测试规则对待测软件进行质量测试。
[0106] 在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。
[0107] 在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。
[0108] 类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。
[0109] 本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。
[0110] 此外，本领域的技术人员能够理解，尽管在此的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。
[0111] 本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发明实施例的软件测试系统中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。
[0112] 应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。
[0113] 本发明公开了：A1.一种软件测试方法，包括：
[0114] 获取接收到的开发自测请求中包含的请求参数信息，根据所述请求参数信息确定待测软件；
[0115] 根据预设的开发自测规则对所述待测软件进行自动化测试，根据测试结果生成结果反馈消息，以供确定自测是否通过；
[0116] 当接收到自测通过后提交的质量测试请求后，根据与所述开发自测规则相匹配的质量测试规则对所述待测软件进行质量测试。
[0117] A2.根据A1所述的方法，其中，所述根据预设的开发自测规则对所述待测软件进行自动化测试，根据测试结果生成结果反馈消息的步骤具体包括：
[0118] 判断生成的结果反馈消息是否为失败类反馈消息，若否，则显示用于触发质量测试请求的质量测试入口；若是，则根据接收到的版本迭代请求对所述待测软件进行版本迭代测试，并在迭代测试的测试结果为成功时显示用于触发质量测试请求的质量测试入口。
[0119] A3.根据A1或A2所述的方法，其中，当所述结果反馈消息为失败类反馈消息时，所述根据测试结果生成结果反馈消息的步骤之后，进一步包括：
[0120] 输出与所述待测软件相对应的测试日志，以供分析失败原因。
[0121] A4.根据A1-A3任一所述的方法，其中，当接收到的开发自测请求为多次时，分别针对每次接收到的开发自测请求生成对应的结果反馈消息；则所述根据与所述开发自测规则相匹配的质量测试规则对所述待测软件进行质量测试的步骤具体包括：
[0122] 根据最后一次生成的结果反馈消息确定所述待测软件的质量。
[0123] A5.根据A1-A4任一所述的方法，其中，所述根据与所述开发自测规则相匹配的质量测试规则对所述待测软件进行质量测试的步骤之后，进一步包括：
[0124] 针对所述待测软件进行功能测试和/或回归测试，并在接收到测试通过后发出的发布请求后，对所述待测软件进行发布。
[0125] A6.根据A1-A5任一所述的方法，其中，所述请求参数信息包括以下中的至少一个：待测软件在版本服务器中对应的存储地址、待测软件的软件版本号、待测软件的端口号、以及测试维度。
[0126] A7.根据A6所述的方法，其中，所述测试维度包括以下中的至少一个：启动停止类测试、功能自动化测试、性能测试、稳定性测试、单机自动化建库测试、异常测试、以及内存泄露专项测试。
[0127] A8.根据A1-A7任一所述的方法，其中，所述获取接收到的开发自测请求中包含的请求参数信息的步骤之前，进一步包括：通过预设的开发自测接口接收所述开发自测请求。
[0128] 本发明还公开了：B9.一种软件测试系统，包括：
[0129] 获取模块，适于获取接收到的开发自测请求中包含的请求参数信息，根据所述请求参数信息确定待测软件；
[0130] 自测模块，适于根据预设的开发自测规则对所述待测软件进行自动化测试，根据测试结果生成结果反馈消息，以供确定自测是否通过；
[0131] 质量测试模块，适于当接收到自测通过后提交的质量测试请求后，根据与所述开发自测规则相匹配的质量测试规则对所述待测软件进行质量测试。
[0132] B10.根据B9所述的系统，其中，自测模块进一步适于判断生成的结果反馈消息是否为失败类反馈消息，若否，则显示用于触发质量测试请求的质量测试入口；若是，则根据接收到的版本迭代请求对所述待测软件进行版本迭代测试，并在迭代测试的测试结果为成功时显示用于触发质量测试请求的质量测试入口。
[0133] B11.根据B9或B10所述的系统，其中，所述自测模块进一步适于在当所述结果反馈消息为失败类反馈消息时，所述根据测试结果生成结果反馈消息的步骤之后输出与所述待测软件相对应的测试日志，以供分析失败原因。
[0134] B12.根据B9-B11任一所述的系统，其中，当接收到的开发自测请求为多次时，所述自测模块进一步适于分别针对每次接收到的开发自测请求生成对应的结果反馈消息；则所述质量测试模块进一步适于根据最后一次生成的结果反馈消息确定所述待测软件的质量。
[0135] B13.根据B9-B12任一所述的系统，所述系统还包括测试发布模块，适于在所述质量测试模块根据与所述开发自测规则相匹配的质量测试规则对所述待测软件进行质量测试之后，针对所述待测软件进行功能测试和/或回归测试，并在接收到测试通过后发出的发布请求后，对所述待测软件进行发布。
[0136] B14.根据B9-B13任一所述的系统，其中，所述请求参数信息包括以下中的至少一个：待测软件在版本服务器中对应的存储地址、待测软件的软件版本号、待测软件的端口号、以及测试维度。
[0137] B15.根据B14所述的系统，其中，所述测试维度包括以下中的至少一个：启动停止类测试、功能自动化测试、性能测试、稳定性测试、单机自动化建库测试、异常测试、以及内存泄露专项测试。
[0138] B16.根据B9-B15任一所述的系统，所述系统还包括接收模块，适于在所述获取模块获取接收到的开发自测请求中包含的请求参数信息之前，通过预设的开发自测接口接收所述开发自测请求。
[0139] 本发明还公开了：C17.一种电子设备，包括：处理器、存储器、通信接口和通信总线，所述处理器、所述存储器和所述通信接口通过所述通信总线完成相互间的通信；
[0140] 所述存储器用于存放至少一可执行指令，所述可执行指令使所述处理器执行如A1-A8中任一项所述的软件自测方法对应的操作。
[0141] 本发明还公开了：D15.一种计算机存储介质，所述存储介质中存储有至少一可执行指令，所述可执行指令使处理器执行如A1-A8中任一项所述的软件测试方法对应的操作。
| 标题 | 发布/更新时间 | 阅读量 |
|---|---|---|
| 一种计算机软件编程用键盘装置 | 2021-05-13 | 5 |
| 基于扫码设备的软件安装方法及其系统 | 2020-07-23 | 2 |
| 一种软件发布系统及发布方法 | 2021-06-16 | 4 |
| 软件运行数据处理方法及软件运行数据处理装置 | 2021-01-07 | 5 |
| 网络中软件下载的方法和装置 | 2021-07-24 | 4 |
| 基于软件过程时序数据自动挖掘的多步预测方法和系统 | 2020-08-08 | 2 |
| 机载显示控制软件的测试方法 | 2021-10-12 | 2 |
| 软件项目管理系统及方法 | 2020-06-09 | 4 |
| 一种机顶盒软件动态升级的方法 | 2022-06-08 | 0 |
| 一种简洁实用的软件包装装置 | 2021-02-07 | 1 |
高效检索全球专利专利汇是专利免费检索,专利查询,专利分析-国家发明专利查询检索分析平台，是提供专利分析，专利查询，专利检索等数据服务功能的知识产权数据服务商。
我们的产品包含105个国家的1.26亿组数据，免费查、免费专利分析。
分析报告
专利汇分析报告产品可以对行业情报数据进行梳理分析，涉及维度包括行业专利基本状况分析、地域分析、技术分析、发明人分析、申请人分析、专利权人分析、失效分析、核心专利分析、法律分析、研发重点分析、企业专利处境分析、技术处境分析、专利寿命分析、企业定位分析、引证分析等超过60个分析角度，系统通过AI智能系统对图表进行解读，只需1分钟，一键生成行业专利分析报告。
软件热门专利
QQ群二维码
意见反馈
意见反馈