软件系统自动自检方法、介质和装置与流程

1.本公开总体上涉及软件系统的自动自检，更具体地涉及使用机器人自检系统对待测软件系统进行自动自检的方法、介质和装置。


背景技术：

2.当前，大中小企业的软件系统日渐复杂化、智能化和多元化。对于如此复杂的软件系统，高可用和高性能保障能力往往不足。在软件系统的上线、稳定性使用过程中，需要持续对软件系统进行测试。然而，常见的手工测试，无法快速、全面、重复地进行软件系统的稳定检查，通常需要投入大量的人力才能实现。若使用兼容性差的测试工具开发专门的测试流程，则开发效率低，而且针对性太强而无法扩展应用到其他软件或程序的测试。一旦原有软件上线完成，针对此软件开发的测试工具再无用武之地，这样造成了大量的浪费。
3.由此，需要一种自动、高效的软件自检方法，能够适应各种软件系统的自检需要，减少人员投入。


技术实现要素：

4.在下文中给出了关于本公开的简要概述，以便提供关于本公开的一些方面的基本理解。但是，应当理解，这个概述并不是关于本公开的穷举性概述。它并不是意图用来确定本公开的关键性部分或重要部分，也不是意图用来限定本公开的范围。其目的仅仅是以简化的形式给出关于本公开的某些概念，以此作为稍后给出的更详细描述的前序。
5.本发明的目的在于提出了一种对软件系统进行自动自检的方法，以解决手动测试无法进行快速、全面、重复检查，而专门测试工具兼容性插、复用性低的至少一个或一些问题。
6.根据本公开的一个方面，提供一种用于待测软件系统的自动自检方法。该方法包括由机器人自检系统接收对用于待测软件系统的测试场景的选择。该方法还包括由机器人自检系统确定与所选择的测试场景对应的测试数据。测试数据包括对一个或多个测试用例的描述。每个测试用例包括在选择的测试场景下对待测软件系统的一个或多个操作。该一个或多个操作中的通用操作被封装为能够被多个测试用例共享的公共关键字。至少一个测试用例包括对公共关键字的引用。该方法还包括解析所确定的测试数据以生成该一个或多个测试用例。该方法还包括执行一个或多个测试用例。该方法还包括基于待测软件系统对该一个或多个操作的响应生成测试报告。
7.根据本公开的另一个方面，提供一种用于待测软件系统的自动自检装置。该装置包括存储有指令的存储器和被配置为执行存储在存储器上的指令以执行如上所述的方法的处理器。
8.根据本公开的又一个方面，提供一种计算机可读存储介质，其包括计算机可执行指令，计算机可执行指令在由一个或多个处理器执行时，使得一个或多个处理器执行根据本公开的上述方面所述的方法。
9.根据本公开的实施例的优点之一在于，由于可以由机器人自检系统自动执行，代替人工测试，减少人为干预，节省了人力成本。
10.根据本公开的实施例的另一优点在于，测试用例通过使用公共关键字替代通用操作，复用性和可扩展性强，开发效率高，而且在发生变化时可以方便地进行二次定制。
11.根据本公开的实施例的又一优点在于，可以安排机器人自检系统在软件系统服务器的空闲时间进行自检测试，节省了服务器资源。
12.根据本公开的实施例的又一优点在于，可以通过多种接口并行地对软件系统进行操作和测试，缩短了测试所需时间。
13.应当认识到，上述优点不需全部集中在一个或一些特定实施例中实现，而是可以部分分散在根据本公开的不同实施例中。根据本公开的实施例可以具有上述优点中的一个或一些，也可以替代地或者附加地具有其它的优点。
14.通过以下参照附图对本发明的示例性实施例的详细描述，本发明的其它特征及其优点将会变得更为清楚。
附图说明
15.构成说明书的一部分的附图描述了本公开的实施例，并且连同说明书一起用于解释本公开的原理。
16.参照附图，根据下面的详细描述，可以更清楚地理解本公开，其中：
17.图1示出了根据本公开的实施例的对待测软件系统进行自动自检的系统示意图；
18.图2示出了根据本公开的实施例的对待测软件系统进行自动自检的方法流程图；和
19.图3示出了可以实现根据本公开的实施例的计算设备的示例性配置。
具体实施方式
20.参考附图进行以下详细描述，并且提供以下详细描述以帮助全面理解本公开的各种示例实施例。以下描述包括各种细节以帮助理解，但是这些细节仅被认为是示例，而不是为了限制本公开，本公开是由随附权利要求及其等同内容限定的。在以下描述中使用的词语和短语仅用于能够清楚一致地理解本公开。另外，为了清楚和简洁起见，可能省略了对公知的结构、功能和配置的描述。本领域普通技术人员将认识到，在不脱离本公开的精神和范围的情况下，可以对本文描述的示例进行各种改变和修改。
21.如前所述，手工测试方法需要大量的人力投入且无法满足当前繁多且复杂的软件系统的测试需求，而针对某个软件系统定制的专门测试工具开发效率低且由于无法迁延至其它软件系统而可重用性差。
22.本公开的实施例提供了用于对待测软件系统进行自动自检的方法、系统、装置和介质。该方法可以主要由机器人自检系统执行。机器人自检系统通过将选择的测试场景映射到测试数据、解析测试数据生成测试用例、执行测试用例以及生成测试报告来完成自动测试过程。整个过程可以减少人工参与。进一步地，通过将对待测系统的一些通用操作封装为不同测试用例之间可以共享的公共关键字，并在测试用例中引用这样的公共关键字，这样对重复的操作可以只编写一次测试代码，因而进一步节省了不必要的重复人力投入，提
高了测试系统的开发效率。
23.图1示出了根据本公开的实施例的对待测软件系统进行自动自检的系统示意图。如图1所示，对待测软件系统120的自动自检主要由机器人自检系统100来实现。机器人自检系统100可以包括测试场景-数据映射模块102、自动解析模块104、执行模块108和报告模块110。
24.待测软件系统120可以是任意一个或多个程序的集合。例如，待测软件系统120可以是电信运营商的办公网(oa)系统、客户关系管理(crm)系统、资源系统、计费系统、门户系统等中一个或多个业务系统的组合。例如，该软件系统120的运行可以涉及到响应对来自各种终端(web、移动终端、个人电脑(pc)端等)的访问请求、响应来自远程客户端的对远程服务器进行连接和操作的请求、响应对数据库的访问请求、响应用户接口(i/o，包括图形用户界面gui)操作等。该软件系统120可以运行在各种不同的操作系统(ios、android、windows、linux)上或者可以通过不同的操作系统接口来访问。相应地，对该软件系统120进行测试就意味着对该软件系统120提供各种输入(即，进行各种操作)以使其遍历其各种不同状态、阶段或功能，以验证其是否工作正常或检测工作性能如何。
25.机器人自检系统100的测试场景-数据映射模块102接收用于待测软件系统120的测试场景的选择。测试场景可以按待测软件系统120的业务系统来划分，每种测试场景下对相应业务系统的一个或多个业务逻辑进行测试。例如，测试场景可以分为“oa系统”、“crm系统”、“资源系统”、“门户系统”、“资源系统”等，其中在“oa系统”测试场景中需要对“前期数据准备”、“oa系统登录”和“系统退出”这一条业务逻辑进行测试。测试场景也可以由多个业务系统中的部分功能组合而成。例如，在“自动化巡检”测试场景中可以对“oa系统”、“crm系统”、“资源系统”、“门户系统”、“资源系统”中每个业务系统的登录/访问操作进行一轮遍历测试。通过这种定制测试场景的设计，可以方便地对软件系统进行统一管理。例如可以根据不同行业的门户管理需求构筑专属的统一门户，在一个测试场景中对所有门户统一进行登录。
26.在一些实施例中，对测试场景的选择可以由开发人员预先固定设置在机器人自检系统中。替代地或者附加地，对测试场景的选择可由机器人自检系统100从外部的可视化接口101接收。可视化接口101例如是图形用户界面(gui)，其中测试人员可以通过操作gui中的控件来定制测试场景。
27.基于接收到已选择的测试场景，测试场景-数据映射模块102可以确定与所选择的测试场景对应的测试数据。机器人自检系统100可以预设有多个测试数据的文件，每个测试数据的文件对应于至少一种测试场景。测试场景与测试数据(或测试数据的文件)之间的映射关系可以预设在映射模块102中。当选择了测试场景后，映射模块102可以基于映射关系读取相应的测试数据的文件来确定测试数据。
28.确定测试数据后，自动解析模块104解析所确定的测试数据以生成一个或多个测试用例(例如图1中的测试用例1和测试用例2，统称为测试用例105)。
29.测试数据包括对一个或多个测试用例的描述，而每个测试用例包括在所选择的测试场景下对待测软件系统120的一个或多个操作。例如，在图1中，由映射模块102确定的测试数据包括对测试用例1和测试用例2的描述。在一些实施例中，测试数据以表格格式被定义。例如，测试数据可以是使用超文本标记语言(html)、制表符分隔值(tsv)、纯文本(txt)
或restructuredtext(rest)格式中的任一种格式的表格数据。此时，测试数据包括测试用例的表格。对每个测试用例的描述包括测试用例的名称、一个或多个动作和与动作对应的参数。动作和参数的组合构成了一个操作。根据以上对待测软件系统120的描述，相应地，测试用例中对待测软件系统120的一个或多个操作可以包括但不限于：驱动特定浏览器并访问定位到待测软件系统120的服务器的特定网址、驱动移动终端操作系统上用于启动待测软件系统120的特定应用程序、连接与待测软件系统120相关的特定远程服务器并对其进行特定操作、发送和解析依据http协议的请求或者从待测软件系统120的i/o接口发出特定请求。
30.在一些实施例中，测试数据还可以进一步包括设置表格、变量表格和关键字表格中的一个或多个。通过解析测试数据，可以获得相应测试用例的设置信息、引用的变量和关键字信息，以供执行模块108执行测试用例时使用。
31.在一些实施例中，测试用例可以为以下类型中的一个或多个：(1)基于界面的测试；(2)基于协议的测试；以及(3)基于代码的测试。基于界面的测试主要负责用户界面的自动模拟操作，包括各种客户端/服务器(c/s)、浏览器/服务器(b/s)架构的界面操作。基于协议的测试主要负责接口调度、移动应用模拟自检和数据库操作，以及实现不同服务器之间的交互。基于代码的测试主要负责性能自检和可靠性自检，例如针对客户端频繁、高速的访问操作对服务器性能进行自检。如在下文将介绍的，测试用例通过共享公共关键字可以节省测试开发时间，从而测试人员能够在同样时间成本下开发出更多的测试用例，覆盖更全面的测试场景。而且，公共关键字可以基于测试库的库关键字开发，而测试库可以包括针对各种功能的第三方扩展库，因此，测试用例所能覆盖的功能也得以丰富。
32.对待测软件系统120的一个或多个操作中的通用操作可以封装为公共关键字以供多个测试用例共享。在一些实施例中，通用操作可以是操作的频次达到一定阈值的操作。例如，若发现对某些gui控件的操作频次较高(超过一定阈值)，则可以将对这些gui控件的操作封装成一个公共关键字。在一些实施例中，通用操作可以是操作逻辑相同或相近的操作。例如，若多个测试用例中都有“打开火狐浏览器
”‑“
打开某个网址
”‑“
输入账户密码登录”的操作逻辑，则可以将具有这样的操作逻辑的一系列操作封装成一个公共关键字。通常而言，操作是由动作和参数的组合构成，动作体现了逻辑，参数表示对象。将操作抽取为公共关键字时，可以固定参数(即操作对象)，也可以不固定参数，而仅仅抽取操作的逻辑，并将操作对象作为与公共关键字一起使用的变量。
33.对于封装好的公共关键字，可以通过在测试用例中对其进行引用来体现相应的通用操作。公共关键字可以具有很好的复用性，使测试人员更便捷地搭建测试系统。例如，在图1中，测试用例1引用公共关键字106。这样可以避免对通用操作重复编写测试代码的人力开销。测试用例可以由一个或多个公共关键字的集合组成。这样的测试用例可以视作是关键字驱动的。由于在测试用例中可以隐去关键字所代表的通用操作的底层实现逻辑，而仅需引用关键字的名称(必要的话，还指定操作对象)，测试用例具有更好的可读性和可维护性，是面向对象的。在公共关键字只封装有操作的逻辑，而未封装操作对象时，这样的测试用例可以进一步视为是数据驱动的。因为，一旦业务逻辑或者操作对象发生变化，无需做整体改动，只需要修改关键字的底层逻辑实现或者修改操作对象数据即可。
34.执行模块108执行所生成的一个或多个测试用例(例如，测试用例105)。对于测试
用例中的公共关键字(例如公共关键字106)，执行模块108可以对其解封装，进而执行公共关键字所代表的通用操作。通过执行测试用例，执行模块108对待测软件系统120做出所选择的测试场景下的一个或多个操作，并从待测软件系统120接收到相应的响应。执行模块108将响应传递给报告模块110。
35.在一些实施例中，执行模块108包括或者调用测试库109。测试库109提供与待测软件系统进行交互的接口。测试库109可以包括机器人自检系统100的内置库、从第三方导入的外部扩展库或者开发人员自行设计的其它测试库。来自第三方的外部扩展库可以采用与机器人自检系统100相同或不同的语言编写。例如，机器人自检系统100可以采用java语言、python语言或c语言编写，而外部扩展库可以采用与之相同或不同的语言编写。测试库109可以支持被不同服务器引用，因而兼容多种执行环境，大幅降低自检系统的部署成本，简化部署过程。
36.在一些情况下，测试库109包括库关键字，而公共关键字106包括基于库关键字编写的用户关键字。例如，库关键字可以与选自以下组中的一个或多个操作相关联：用于移动终端操作系统的用户接口ui自动化测试、远程服务器连接与操作测试、http请求发送和解析测试、以及输入/输出i/o接口测试。可见，库关键字用作底层接口方法，而用户关键字则是在较高层级上的封装。通过关键字的分层设计，基于关键字的测试用例具有更好的兼容性和灵活性。譬如，可以在库关键字的层面实现对各种接口的支持，而在用户关键字层面可以不用具体关心下层的接口实现，而是聚焦于业务逻辑的实现。这样，一旦底层接口发生变化，只用修改库关键字的实现即可。而且，这样的分层设计也更有利于在发生测试错误时定位故障点。
37.在一些实施例中，执行模块108可以通过多个接口并行地对待测软件系统120进行操作。如前所述，待测软件系统120可以通过不同的操作系统接口来访问。相应地，执行模块108可以同时通过这多个不同的操作系统接口来对软件系统120进行测试，由此缩短测试的时间开销。不同的操作系统接口可以包括基于web网页的接口、基于移动终端操作系统(例如ios、android等)的接口和基于pc桌面操作系统(例如windows、linux等)的接口。在通过测试库109提供与待测软件系统120的接口的实施例中，为了提供多个不同的操作系统接口，测试库109可以包括来自第三方的相应的多个外部扩展库，例如用于web用户接口的selenium、用于移动终端的appium和用于http协议接口的requests等。
38.报告模块110分析从执行模块108接收到的来自待测软件系统120的响应并基于该响应生成一个或多个测试报告。在一个或多个实施例中，测试的目标是待测软件系统120是否具有高可用性。此时，来自待测软件系统120的对特定测试用例的响应可以是业务流程是否工作正常(即，没有宕机或者不可用)，例如，是否正常登录并显示欢迎界面，或者客户的套餐订单是否能够正常订购等。响应于指示业务流程工作正常，报告模块110在生成的测试报告中指示对相应特定测试用例的测试成功。在其它替代或附加的实施例中，测试的目标还可以是待测软件系统120是否具有高性能。此时，报告模块110可以基于待测软件系统120对特定测试用例的一个或多个操作的响应来确定其响应时间，并在响应时间小于阈值时间的情况下，在生成的测试报告中指示对相应特定测试用例的测试成功。
39.在一些实施例中，为了便于快速定位导致测试失败的故障点，可以在测试报告中提供辅助信息。测试报告可以包括测试用例中引用的公共关键字的名称、执行状态以及执
行失败时的错误信息，由此帮助测试人员定位故障发生的位置。
40.在一些实施例中，测试报告可以以多种不同的文件格式生成，例如xml或html格式。除了有关各个关键字信息的输出报告，测试报告还可以包括详细日志文件和汇总报告文件。通过提供各种不同形式的测试报告，便于测试人员全面了解自检运行过程的各方面情况。
41.在一些实施例中，用于待测软件系统120的自动自检方法还涉及构建工具130。构建工具130可以对机器人自检系统100进行构建和管理。在具体实施例中，构建工具130可以对机器人自检系统100提供配置信息，包括配置机器人自检系统在何时和/或以何种频率执行自检方法。由此，机器人自检系统100可以被配置为在特定时间或以特定频率执行自检方法。作为示例，可以由机器人自检系统100或者构建工具130监视待测软件系统120的服务器空闲时间。构建工具130可以将机器人自检系统100配置为在服务器空闲时间执行自检方法，由此可以避免干扰待测软件系统120的日常工作，提高系统资源的利用率。譬如，待测软件系统120可能在日间被频繁使用/访问，而在清晨或夜间业务量较少，那么可以由构建工具130将机器人自检系统100配置为在清晨或夜间执行自检程序。作为另一个示例，构建工具130可以配置机器人自检系统100在待测软件系统120上线初期以相对较高的频率执行自检方法，而在待测软件120稳定运行期以相对较低的频率执行自检方法。构建工具130可以记录待测软件系统120的运行状态进而判断其是在上线初期还是稳定运行期。
42.在一些实施例中，构建工具130还可以对报告模块110生成的测试报告进行后处理，包括报告格式的调整、报告的进一步推送。在一些示例中，构建工具130可以经由多种网络通讯工具推送所生成的测试报告，以确保测试报告能够被目标对象成功接收并注意到。网络通讯工具的示例包括但不限于：微信、邮箱、短信、电话等。测试报告可以由构建工具130通过该多种网络通讯工具被推送给测试人员，由此测试人员可以仅在测试发生失败时开展进一步工作，从而帮助企业节省了人力成本。
43.在一些实施例中，机器人自检系统100可以基于robot framework(rf)开发平台。机器人自检系统100可以通过rf驱动操作pybot、jybot接口执行多种通用格式(例如.py或.txt)的自检脚本来启动运行。在一些实施例中，构建工具130可以基于jenkins持续集成工具开发。
44.根据本公开的自检方法利用机器人进行自动自检，代替人工自检的方式，能够支撑日常的系统高可用自检及固定化场景的自动化执行，减少人员投入。此外，通过编写公共关键字，可以在不同软件系统自检场景中引用，复用性高。而且，基于关键字驱动的测试用例扩展能力强，敏捷性高，可以根据后续业务变化(通用逻辑或数据对象变化)，灵活弹性进行二次定制。
45.图2示出了根据本公开的实施例的对待测软件系统进行自动自检的方法流程图。自动自检方法200可以由机器人自检系统(例如图1中的机器人自检系统100)的各个模块执行。以下仅简要描述自动自检方法200的主要步骤，对于步骤中所涉及的要素的具体介绍可以参见图1，在此不做赘述。
46.在步骤s202，机器人自检系统接收对用于待测软件系统的测试场景的选择。对测试场景的选择可以以预先固定设置在机器人自检系统中的方式来实现，也可以由机器人自检系统从外部接口接收。
47.在步骤s204，机器人自检系统确定与在步骤s202所选择的测试场景对应的测试数据。机器人自检系统可以基于预先设置号的测试场景和测试数据之间的映射关系来确定相应的测试数据。测试数据包括对一个或多个测试用例的描述。每个测试用例包括在选择的测试场景下对待测软件系统的一个或多个操作。该一个或多个操作中的通用操作被封装为能够被多个测试用例共享的公共关键字。测试用例中的至少一个测试用例包括对公共关键字的引用。对测试用例的描述可以包括测试用例的名称、一个或多个动作和与动作对应的参数。动作和相应参数的组合构成了操作。
48.在步骤s206，机器人自检系统解析在步骤s204确定的测试数据以生成该一个或多个测试用例。机器人自检系统可以基于测试数据中包括的对一个或多个测试用例的描述来生成该一个或多个测试用例。
49.在步骤s208，机器人自检系统执行在步骤s206生成的该一个或多个测试用例。对于测试用例中的公共关键字，机器人自检系统可以对其解封装，进而执行公共关键字所代表的通用操作。
50.在步骤s210，机器人自检系统基于待测软件系统对该一个或多个操作的响应生成测试报告。
51.在一些实施例中，步骤s202至s210可以由构建工具(例如图1的构建工具130)设置为在特定时间或以特定频率被执行。例如，可以在监视到的待测软件系统的服务器空闲时间来执行方法200的步骤s202至s210。
52.在一些实施例中，方法200还包括(例如由构建工具)经由多种网络通讯工具将在步骤s210生成的测试报告推送出去。
53.虽然在附图2中以特定次序描绘了操作，但是这不应该被理解为要求以所示的特定次序或者以顺序次序执行这样的操作，或者要求执行所有图示的操作以实现所希望的结果。在某些情况下，多任务处理和并行处理可以是有利的。
54.图3示出了能够实现根据本公开的实施例的计算设备300的示例性配置。
55.计算设备300是能够应用本公开的上述方面的硬件设备的实例。计算设备300可以是被配置为执行处理和/或计算的任何机器。计算设备300可以是但不限制于工作站、服务器、台式计算机、膝上型计算机、平板计算机、个人数据助手(pda)、智能电话、车载计算机或以上组合。
56.如图3所示，计算设备300可以包括可以经由一个或多个接口与总线302连接或通信的一个或多个元件。总线302可以包括但不限于，工业标准架构(industry standard architecture，isa)总线、微通道架构(micro channel architecture，mca)总线、增强isa(eisa)总线、视频电子标准协会(vesa)局部总线、以及外设组件互连(pci)总线等。计算设备300可以包括例如一个或多个处理器304、一个或多个输入设备306以及一个或多个输出设备308。一个或多个处理器304可以是任何种类的处理器，并且可以包括但不限于一个或多个通用处理器或专用处理器(诸如专用处理芯片)。处理器302例如被配置为实现图1中的机器人自检系统100或者还进一步实现构建工具130。输入设备306可以是能够向计算设备输入信息的任何类型的输入设备，并且可以包括但不限于鼠标、键盘、触摸屏、麦克风和/或远程控制器。输出设备308可以是能够呈现信息的任何类型的设备，并且可以包括但不限于显示器、扬声器、视频/音频输出终端、振动器和/或打印机。
57.计算设备300还可以包括或被连接至非暂态存储设备314，该非暂态存储设备314可以是任何非暂态的并且可以实现数据存储的存储设备，并且可以包括但不限于盘驱动器、光存储设备、固态存储器、软盘、柔性盘、硬盘、磁带或任何其他磁性介质、压缩盘或任何其他光学介质、缓存存储器和/或任何其他存储芯片或模块、和/或计算机可以从其中读取数据、指令和/或代码的其他任何介质。计算设备300还可以包括随机存取存储器(ram)310和只读存储器(rom)33。rom 33可以以非易失性方式存储待执行的程序、实用程序或进程。ram 310可提供易失性数据存储，并存储与计算设备300的操作相关的指令。计算设备300还可包括耦接至数据链路318的网络/总线接口316。网络/总线接口316可以是能够启用与外部装置和/或网络通信的任何种类的设备或系统，并且可以包括但不限于调制解调器、网络卡、红外线通信设备、无线通信设备和/或芯片集(诸如蓝牙
tm
设备、802.11设备、wifi设备、wimax设备、蜂窝通信设施等)。
58.本公开可以被实现为装置、系统、集成电路和非瞬时性计算机可读介质上的计算机程序的任何组合。可以将一个或多个处理器实现为执行本公开中描述的部分或全部功能的集成电路(ic)、专用集成电路(asic)或大规模集成电路(lsi)、系统lsi，超级lsi或超lsi组件。
59.本公开包括软件、应用程序、计算机程序或算法的使用。可以将软件、应用程序、计算机程序或算法存储在非瞬时性计算机可读介质上，以使诸如一个或多个处理器的计算机执行上述步骤和附图中描述的步骤。例如，一个或多个存储器以可执行指令存储软件或算法，并且一个或多个处理器可以关联执行该软件或算法的一组指令，以根据本公开中描述的实施例提供各种功能。
60.软件和计算机程序(也可以称为程序、软件应用程序、应用程序、组件或代码)包括用于可编程处理器的机器指令，并且可以以高级过程性语言、面向对象编程语言、功能性编程语言、逻辑编程语言或汇编语言或机器语言来实现。术语“计算机可读介质”是指用于向可编程数据处理器提供机器指令或数据的任何计算机程序产品、装置或设备，例如磁盘、光盘、固态存储设备、存储器和可编程逻辑设备(pld)，包括将机器指令作为计算机可读信号来接收的计算机可读介质。
61.举例来说，计算机可读介质可以包括动态随机存取存储器(dram)、随机存取存储器(ram)、只读存储器(rom)、电可擦只读存储器(eeprom)、紧凑盘只读存储器(cd-rom)或其他光盘存储设备、磁盘存储设备或其他磁性存储设备，或可以用于以指令或数据结构的形式携带或存储所需的计算机可读程序代码以及能够被通用或专用计算机或通用或专用处理器访问的任何其它介质。如本文中所使用的，磁盘或盘包括紧凑盘(cd)、激光盘、光盘、数字多功能盘(dvd)、软盘和蓝光盘，其中磁盘通常以磁性方式复制数据，而盘则通过激光以光学方式复制数据。上述的组合也包括在计算机可读介质的范围内。
62.综上所述，本公开提供了一种用于待测软件系统的自动自检方法，包括由机器人自检系统执行以下步骤：接收对用于待测软件系统的测试场景的选择；确定与所选择的测试场景对应的测试数据，测试数据包括对一个或多个测试用例的描述，其中每个测试用例包括在选择的测试场景下对待测软件系统的一个或多个操作，一个或多个操作中的通用操作被封装为能够被多个测试用例共享的公共关键字，其中至少一个测试用例包括对公共关键字的引用；解析所确定的测试数据以生成一个或多个测试用例；执行一个或多个测试用
例；以及基于待测软件系统对一个或多个操作的响应生成测试报告。
63.在一些实施例中，机器人自检系统被配置为在特定时间或以特定频率执行自检方法。
64.在一些实施例中，该方法还包括监视待测软件系统的服务器空闲时间，机器人自检系统被配置为在服务器空闲时间执行自检方法。
65.在一些实施例中，通用操作包括操作频次达到一定阈值的操作或者操作逻辑相同或相近的操作。
66.在一些实施例中，一个或多个操作中的通用操作的操作逻辑被封装为能够被多个测试用例共享的公共关键字。
67.在一些实施例中，一个或多个测试用例包括具有选自以下类型中的一个或多个的测试用例：基于界面的测试；基于协议的测试；以及基于代码的测试。
68.在一些实施例中，公共关键字包括基于来自测试库的库关键字编写的用户关键字。
69.在一些实施例中，库关键字与选自以下组中的一个或多个操作相关联：用于移动终端操作系统的用户接口ui自动化测试；远程服务器连接与操作测试；http请求发送和解析测试；以及输入/输出i/o接口测试。
70.在一些实施例中，执行一个或多个测试用例包括通过以下中的多于一个接口并行地对待测软件系统进行操作：基于web网页的接口；基于移动终端操作系统的接口；以及基于pc桌面操作系统的接口。
71.在一些实施例中，基于待测软件系统对一个或多个操作的响应生成测试报告包括：确定待测软件系统对特定测试用例的一个或多个操作的响应时间；响应于响应时间小于阈值时间，在测试报告中指示针对特定测试用例的测试成功。
72.在一些实施例中，该方法还包括经由多种网络通讯工具推送所生成的测试报告。
73.在一些实施例中，测试数据以表格格式被定义。
74.在一些实施例中，测试报告包括公共关键字的名称、执行状态以及执行失败时的错误信息。
75.本公开还提供了一种用于待测软件系统的自动自检装置，包括处理器和存储器，该存储器存储计算机程序指令，该计算机程序指令在被处理器执行时使得处理器执行如上所述的自动自检方法。
76.本公开还提供了一种计算机可读存储介质，其存储有计算机程序指令，该计算机程序指令在由计算机系统执行时，使得计算机系统执行根据前述任一项所述的方法。
77.提供本公开的主题作为用于执行本公开中描述的特征的装置、系统、方法和程序的示例。但是，除了上述特征之外，还可以预期其他特征或变型。可以预期的是，可以用可能代替任何上述实现的技术的任何新出现的技术来完成本公开的部件和功能的实现。
78.另外，以上描述提供了示例，而不限制权利要求中阐述的范围、适用性或配置。在不脱离本公开的精神和范围的情况下，可以对所讨论的元件的功能和布置进行改变。各种实施例可以适当地省略、替代或添加各种过程或部件。例如，关于某些实施例描述的特征可以在其他实施例中被结合。