测试方法和装置与流程

本发明涉及软件测试技术领域，具体而言，涉及一种测试方法和装置。

背景技术：

随着计算机互联网技术的发展，软件的应用已非常普及，对于软件可靠性而言，系统的稳定性尤为重要。软件可靠性是指软件产品在规定的条件下和规定的时间区间完成规定功能的能力，其中，规定的条件是指直接与软件运行相关的计算机系统的状态和软件的输入条件；规定的时间区间是指软件的实际运行时间；规定功能是指提供给定的功能，软件产品所必须具备的功能。软件的可靠性直接关系着用户的体验效果。如果使用软件的过程中，碰到软件系统崩溃、宕机、蓝屏、无响应等严重失效行为，容易给用户带来数据损失、效率损失。因而，如何验证、度量软件系统的稳定性，给用户以质量担保、提供应对措施等显得非常重要。

目前，对软件稳定性的认识大多局限于一个泛的概念或一种感觉。针对软件稳定性的测试，现有技术主要是针对某种特定场景作强化测试，或采取猴子测试法，即取得某种场景的特定数据，依据某种公式做推导来预测故障在用户中出现的几率等。

现有技术的方案，由于软件稳定性在软件度量体系的可靠性中只有泛泛的提及，没有针对软件稳定性的度量或测试的系统方法和思路。而现有度量体系主要是以故障(Bug)数作为重要统计参数，并没有针对稳定性度量方法。另外，由于现有的度量体系中对软件预测多以复杂的经验公式，不直观，有效性、时效性差，与真实用户的体验差别较大。

针对上述的问题，目前尚未提出有效的解决方案。

技术实现要素：

本发明实施例提供了一种测试方法和装置，以至少解决现有技术中没有针对软件稳定性的度量的技术问题。

根据本发明实施例的一个方面，提供了一种测试方法，包括：在执行测试任务的过程中，获取待测试软件所出现的异常状态，其中，异常状态是预先设定的范围内的状态；获取长度为预定时长的时间段内的异常状态出现的情况，其中，异常状态出现的情况包括：待测试软件在不同测试设备上出现的异常状态；至少根据异常状态出现的情况评估待测试软件的稳定性。

根据本发明实施例的另一方面，还提供了一种测试装置，包括：第一获取单元，用于在执行测试任务的过程中，获取待测试软件所出现的异常状态，其中，异常状态是预先设定的范围内的状态；第二获取单元，用于获取长度为预定时长的时间段内的异常状态出现的情况，其中，异常状态出现的情况包括：待测试软件在不同测试设备上出现的异常状态；评估单元，用于至少根据异常状态出现的情况评估待测试软件的稳定性

在本发明实施例中，通过在执行测试任务的过程中，获取待测试软件所出现的异常状态，其中，异常状态是预先设定的范围内的状态；获取长度为预定时长的时间段内的异常状态出现的情况，其中，异常状态出现的情况包括：待测试软件在不同测试设备上出现的异常状态；至少根据异常状态出现的情况评估待测试软件的稳定性，达到了即时了解软件系统的稳定状态，并根据该稳定状态及时提供应对策略的目的，从而实现了降低用户损失、提高用户体验的技术效果，进而解决了现有技术中没有针对软件稳定性的度量的技术问题。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是根据本发明实施例的一种测试方法流程图；

图2是根据本发明实施例的一种可选的测试方法流程图；

图3是根据本发明实施例的一种可选的测试方法流程图；

图4是根据本发明实施例的一种可选的测试方法流程图；

图5是根据本发明实施例的一种优选的测试方法流程图；以及

图6是根据本发明实施例的一种测试装置示意图。

具体实施方式

为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

实施例1

根据本发明实施例，提供了一种测试方法实施例，需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

图1是根据本发明实施例的一种测试方法流程图，如图1所示，该方法包括如下步骤：

步骤S102，在执行测试任务的过程中，获取待测试软件所出现的异常状态，其中，异常状态是预先设定的范围内的状态；

步骤S104，获取长度为预定时长的时间段内的异常状态出现的情况，其中，异常状态出现的情况包括：待测试软件在不同测试设备上出现的异常状态；

步骤S106，至少根据异常状态出现的情况评估待测试软件的稳定性。

作为一种可选的实施例，上述测试任务可以为用于测试软件或软件系统的稳定性的任务，测试的软件或软件系统可以但不限于运行在计算机、平板电脑、笔记本、手机等智能设备上；上述异常状态可以为预先设定的状态范围内的状态，一种可选的实施方式中，针对不同的软件或软件系统，可以根据该软件或软件系统所在的运行平台和应用场景定义该软件或软件系统的异常状态，对异常状态包含的现象范围进行定义，并对出现的异常现象进行标定。上述异常状态出现的情况可以包括待测试的软件或软件系统在不同运行测试设备(运行该软件或软件系统的设备)上出现的异常状态。基于上述步骤S102至S106公开的技术方案，在执行测试任务的过程中，获取待测试软件所出现的异常状态，以及预设时间段内该异常状态在不同测试设备上出现的情况，并根据这些异常状态在不同测试设备上出现的情况来评估待测试软件的稳定性。

此处需要说明的是，针对某一款软件或软件系统，可以将该软件或软件系统的可能异常状态进行定义，并对这些异常状态包含的现象范围进行定义，进而对出现的异常现象进行标定。容易注意的是，由于软件或软件系统的失效行为所表现的现象很多，作为一种可选的实施方案，可以只选取严重的失效行为作为统计。

此处需要说明的是，时间段的长度是可以根据软件开发的不同周期来进行确定的，也可以是根据软件发布运行后的运行阶段来确定的。或者，时间段的长度也可以是根据所执行的测试任务来确定的，如果测试任务执行的是用例测试，那么此时就可以根据用例测试中的内容确定该时间段的长度，如果执行的是自由测试，此时可以对时间段的长度进行调整。

一种可选的实施例中，上述异常状态可以为收集的来自多个不同操作系统(例如，Windows，iOS，Android等)的异常状态，此时的异常状态可以用于表征该待测试软件的一个整体的情况，或者也可以区分一下操作系统，此时可以获得每个操作系统上的该待测试软件的异常状态。

由上可知，在本申请上述实施例中，针对某一款软件或软件系统，定义该软件或软件系统可能出现的异常状态，对这些异常状态包含的现象范围进行定义，并对出现的异常现象进行标定；在执行测试任务的过程中，首先获取为待测试软件预先设定的状态范围内的至少一个异常状态，并获取该异常状态在预设时间段内在不同测试设备(运行待测软件的设备)上出现的情况，至少根据这些异常状态的出现的情况来评估待测试软件的稳定性。通过本实施例公开的方案，达到了即时了解软件系统的稳定状态，并根据该稳定状态及时提供应对策略的目的，从而实现了降低用户损失、提高用户体验的技术效果，进而解决了现有技术中没有针对软件稳定性的度量的技术问题。

在软件或软件系统的开发周期的不同阶段，或在软件或软件系统运行后的不同时间段，该软件或软件系统上出现的异常状态可能不同，因而，可以获取待测软件或软件系统在预设时间内的异常状态出项的情况来综合判断该软件或软件系统的稳定性，在一种可选的实施例中，如图2所示，至少根据异常状态出现的情况评估待测试软件的稳定性，可以包括如下步骤：

步骤S202，获取相邻的多个时间段内的异常状态出现的情况；

步骤S204，根据相邻的多个时间段内异常状态出现的情况确定异常状态出现的趋势；

步骤S206，根据趋势评估待测试软件的稳定性。

具体地，在上述实施例中，在获取长度为预定时长的时间段内的异常状态出现的情况之后，获取相邻的多个时间段内的异常状态出现的情况，并根据相邻的多个时间段内的异常状态出现的情况确定待测试软件的异常状态出现的趋势，最后根据趋势来评估待测软件的稳定性。

需要说明的是，在对软件或软件系统测试的过程中，基于上述步骤S202至S206公开的方案，可以根据某一软件或软件系统在预设时间内所有的异常状态出现的情况来评估待测软件的稳定性，而不是仅仅依靠错误或故障的频次，或者依靠经验公式来判定待测试软件或软件系统的稳定性。

通过上述实施例，可以根据待测软件的异常状态出现的趋势来评估待测软件的稳定性，提高了评估软件稳定性的准确性。

由于每个测试设备的硬件配置或操作系统不同，同一软件或软件系统安装在不同的测试设备上其稳定性不一定相同，在另一种可选的实施例中，如图3所示，至少根据异常状态出现的情况评估待测试软件的稳定性可以包括如下步骤：

步骤S302，根据异常状态出现在的测试设备的数量和/或异常状态出现的次数评估待测试软件的稳定性。

具体地，在上述实施例中，上述测试设备可以当前安装待测试软件的至少一个设备；在根据待测试设备的异常状态出现的情况在评估待测试软件的稳定性的过程中，一种可选的实施方式中，可以获取待测试软件或软件系统的异常状态在至少一个测试设备上出现的次数来评估待测软件的稳定性；另一种可选的实施方式中，还可以获取出现异常状态的测试设备的数量，优选地，可以统计不同操作系统(例如，Windows，iOS，Android等)或不同类型(例如，计算机、平板电脑、笔记本、手机等)的测试设备的数量，来评估待测试软件或软件系统的稳定性。作为一种优选的实施方式，可以结合上述两种实施方式，即根据异常状态出现在的测试设备的数量和异常状态出现的次数评估待测试软件的稳定性。

需要说明的是，稳定性的结果可以使用自然语言来进行描述，使用自然语言描述的稳定性结果可以使用户更加容易了解该待测试软件或软件系统的状态。

通过上述实施例，可以考虑了安装待测软件或软件系统的硬件设备的因素，避免了测试设备自身的原因造成对安装在该测设备上的软件或软件系统的误判，提高了评估软件稳定性的准确性。

基于上述实施例，在一种可选的实施例中，如图4所示，根据异常状态出现在的测试设备的数量和/或异常状态出现的次数评估待测试软件的稳定性，可以包括如下步骤：

步骤S402，根据测试设备的数量和/或异常状态出现的次数所在范围确定待测试软件的稳定性，其中，范围为预先设定的。

在一种可选的实施例中，上述范围可以是根据待测试软件的同类型软件出现异常状态的情况确定的。

具体地，上述同类型软件可以是与待测软件功能或业务类型相同的其他软件；也可以待测测试软件的其他版本，包括稳定的版本和非稳定的版本。具体地，在软件的整个开发周期中，从待测试软件的版本可测并初步稳定后，便开始统计数据。其中，版本不稳定时统计的数据，不仅可以用于度量产品的即时稳定性状态，也用于表征开发能力和水平；而截取到的版本稳定后的数据，可以用于评估产品发布后的稳定性。

作为一种优选的实施方式，图5是根据本发明实施例的一种优选的测试方法流程图，如图5所示，该测试方法可以包括如下步骤：

步骤S502，定义稳定性及范围。

具体地，在上述步骤中，给出一个具体软件系统稳定性定义，概括待测试软件或软件系统给用户可能带来损失的异常现象。对这些异常状态包含的现象范围进行定义，对出现的形象进行标定。确定即在软件运行过程中出现一次异常现象，计数1次。

步骤S504，确定度量单位。

具体地，在上述步骤中，确定度量刻度，即定义出度量的单位，如时长(时，天等)；又如人、台等。

步骤S506，确定测试策略和计划。

具体地，在上述步骤中，制定软件版本周期内测试策略和计划。

步骤S508，执行测试。

具体地，在上述步骤中，在软件的开发周期或运行过程中按照测试策略和测试计划，执行测试，测试可以是用例测试、自由测试等。测试用例包括对基本功能、用户流程、用户场景测试，甚至可以包括用户参加的测试等的系统测试。

步骤S510，记录异常次数。

具体地，在上述步骤中，记录度量刻度段内异常次数。按照确定的度量刻度段记录产生异常现象的次数，统计出现的异常次数、人次数或台次数。

步骤S512，计算异常值。

具体地，在上述步骤中，将异常次数与度量刻度段进行比值，得出待测软件或软件系统即时的异常值，该异常值可以用于表征待测试软件的稳定性。一种可选的实施方式中，将一段刻度内出现的异常次数、异常人次数或台次数与度量刻度段进行比较，将得出的比值定义成一个指数或参数，表征特定刻度段的稳定性值，标识软件系统的即时稳定性数据。

步骤S514，判断是否完成。

具体地，在上述步骤中，在软件开发周期或运行时间段内持续测试和记录，并判断测试是否完成，如果完成，则执行步骤S516；反之，则执行步骤S508。

步骤S516，数据统计分析。

具体地，在上述步骤中，截取记录段进行统计，例如，均值等，得出软件系统总体稳定性参数。在统计一段时间的这些数据值后，对统计的稳定性数据进行趋势分析，预测软件系统稳定性趋势，从而得到待测试软件或软件系统的稳定性数据。

基于上述步骤S512至S516公开的方案，提供了一种稳定性度量系统，通过该稳定性度量系统，可以即时了解软件系统的稳定状态，开发及时分析推测用户可能出现几率并提供应对策略，避免造成用户损失。

需要说明的是，本实施例已在内部电子图板、实体设计、协同管理等软件系统产品中得到了实际应用和验证，通过定义各个版本周期中的稳定性数据(包括异常状态和为这些异常状态包含的现象标定的范围)，在软件产品的测试过程中，从开发视角进行分析和验证，最后，产品发布后的用户反馈和系统验证结果基本能够吻合。

实施例2

根据本发明实施例，还提供了一种用于实现上述测试方法的装置实施例，图6是根据发明实施例的一种测试装置示意图，如图6示，该装置包括：第一获取单元601、第二获取单元603和评估单元605。

其中，第一获取单元601，用于在执行测试任务的过程中，获取待测试软件所出现的异常状态，其中，异常状态是预先设定的范围内的状态；

第二获取单元603，用于获取长度为预定时长的时间段内的异常状态出现的情况，其中，异常状态出现的情况包括：待测试软件在不同测试设备上出现的异常状态；

评估单元605，用于至少根据异常状态出现的情况评估待测试软件的稳定性。

此处需要说明的是，上述第一获取单元601、第二获取单元603和评估单元605对应于实施例1中的步骤S102至S106，上述单元与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例1所公开的内容。需要说明的是，上述单元可以作为装置的一部分可以在诸如一组计算机可执行指令的计算机系统中执行。

在一种可选的实施例中，上述评估单元605可以包括：第一获取模块，用于获取相邻的多个时间段内的异常状态出现的情况；第二获取模块，用于根据相邻的多个时间段内异常状态出现的情况确定异常状态出现的趋势；评估模块，用于根据趋势评估待测试软件的稳定性。

此处需要说明的是，上述第一获取模块、第二获取模块和评估模块对应于实施例1中的步骤S202至S206，上述模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例1所公开的内容。需要说明的是，上述模块作为装置的一部分可以在诸如一组计算机可执行指令的计算机系统中执行。

在一种可选的实施例中，上述评估单元还可以用于根据异常状态出现在的测试设备的数量和/或异常状态出现的次数评估待测试软件的稳定性。

在一种可选的实施例中，上述评估单元还可以用于根据数量和/或次数所在范围确定待测试软件的稳定性，其中，范围为预先设定的。

在一种可选的实施例中，上述范围是根据待测试软件的同类型软件出现异常状态的情况确定的。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

在本发明的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的技术内容，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，可以为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。