CN113342676A - 一种软件测试的评估方法、装置、计算设备及存储介质 - Google Patents
一种软件测试的评估方法、装置、计算设备及存储介质 Download PDFInfo
- Publication number
- CN113342676A CN113342676A CN202110724104.7A CN202110724104A CN113342676A CN 113342676 A CN113342676 A CN 113342676A CN 202110724104 A CN202110724104 A CN 202110724104A CN 113342676 A CN113342676 A CN 113342676A
- Authority
- CN
- China
- Prior art keywords
- test
- software
- target
- sub
- historical
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000011156 evaluation Methods 0.000 title claims abstract description 28
- 238000003860 storage Methods 0.000 title claims abstract description 15
- 230000007547 defect Effects 0.000 claims abstract description 271
- 238000012360 testing method Methods 0.000 claims abstract description 263
- 238000000034 method Methods 0.000 claims abstract description 39
- 230000001186 cumulative effect Effects 0.000 claims description 22
- 230000002159 abnormal effect Effects 0.000 claims description 20
- 238000013522 software testing Methods 0.000 claims description 15
- 238000004590 computer program Methods 0.000 claims description 14
- 238000001914 filtration Methods 0.000 claims description 6
- 238000009826 distribution Methods 0.000 description 29
- 238000010586 diagram Methods 0.000 description 15
- 230000008569 process Effects 0.000 description 12
- 238000005516 engineering process Methods 0.000 description 7
- 230000006870 function Effects 0.000 description 7
- 238000012545 processing Methods 0.000 description 7
- 238000012986 modification Methods 0.000 description 5
- 230000004048 modification Effects 0.000 description 5
- 230000005856 abnormality Effects 0.000 description 3
- 238000009825 accumulation Methods 0.000 description 3
- 239000006185 dispersion Substances 0.000 description 2
- 238000005315 distribution function Methods 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 230000008439 repair process Effects 0.000 description 2
- 230000004075 alteration Effects 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
Abstract
本申请实施例提供了一种软件测试的评估方法、装置、计算设备及存储介质，该方法包括：根据测试软件所对应的多个历史版本软件的历史比例，确定测试软件的目标比例；根据所述目标比例、所述测试软件在拐点子周期的测试缺陷累计数量以及所述测试软件的拐点子周期在测试中的次序，确定所述测试软件在测试中目标子周期的目标缺陷数量；将所述测试软件在所述目标子周期的测试缺陷数量与对应的目标缺陷数量进行比对，根据比对结果确定所述测试软件是否测试充分。由于测试软件与其历史版本软件关联性较大，受测试环境、测试人员等因素影响小，基于历史版本软件的历史比例，较为准确地确定该测试软件的目标比例，从而精准地评估该测试软件是否测试充分。
Description
技术领域
本申请实施例涉及金融科技(Fintech)领域，尤其涉及一种软件测试的评估方法、装置、计算设备及存储介质。
背景技术
随着计算机技术的发展，越来越多的技术应用在金融领域，传统金融业正在逐步向金融科技转变，但由于金融行业的安全性、实时性要求，也对技术提出的更高的要求。在金融领域中，为了保证软件正常高效运行，需要对软件进行测试，以修复软件缺陷。如果软件没有充分测试，就无法较好的修复软件缺陷。
相关技术中，通过代码覆盖率来评估软件测试是否充分，然而开发人员编写的代码受技术和经验的影响，所写代码可能无法完全覆盖到需求，测试人员根据已经存在疏漏的代码，无法精准地评估软件是否测试充分。
综上，目前亟需一种软件测试的评估方法，用以精准评估软件是否测试充分。
发明内容
本申请实施例提供了一种软件测试的评估方法、装置、计算设备及存储介质，用以精准评估软件是否测试充分。
第一方面，本申请实施例提供了一种软件测试的评估方法，该方法包括：
根据测试软件所对应的多个历史版本软件的历史比例，确定所述测试软件的目标比例；其中，任一历史版本软件的历史比例为在对应的历史拐点子周期的测试缺陷累计数量相对于对应的历史测试中测试缺陷总数的比例；任一历史版本软件对应的历史拐点子周期，为所述历史版本软件在对应的历史测试的多个子周期中测试缺陷数量最多的子周期；
根据所述目标比例、所述测试软件在拐点子周期的测试缺陷累计数量以及所述测试软件的拐点子周期在测试中的次序，确定所述测试软件在测试中目标子周期的目标缺陷数量；
将所述测试软件在所述目标子周期的测试缺陷数量与对应的目标缺陷数量进行比对，根据比对结果确定所述测试软件是否测试充分。
上述技术方案中，由于各软件与其历史版本软件关联性较大，即同一项目的软件在测试过程中缺陷分布较为相似，不同项目的软件受测试环境、测试人员等因素的影响在测试过程中缺陷分布差异较大，因此，根据测试软件所对应的多个历史版本软件的历史比例，就能确定出当该测试软件测试充分时，在拐点子周期的缺陷累计数量相对于缺陷总数的目标比例，进而根据该目标比例就能准确地确定当该测试软件测试充分时目标子周期的目标缺陷数量，根据在目标子周期的实际测试中的测试缺陷数量与对应的当测试充分时的目标缺陷数量的比对结果，就能精准地确定该测试软件是否测试充分。
可选地，根据测试软件所对应的多个历史版本软件的历史比例，确定所述测试软件的目标比例，包括：
从多个历史比例中过滤异常的历史比例；
将过滤后的历史比例的平均值确定为所述目标比例。
上述技术方案中，由于多个历史版本软件中部分历史版本软件可能测试异常，这些历史版本软件在测试中的缺陷分布与其他历史版本软件在测试中的缺陷分布差异较大，这些历史版本软件就对应了异常的历史比例，因此通过从多个历史版本软件的历史比例过滤掉异常的历史比例，进而将过滤后的历史比例的平均值确定为目标比例，就减少了异常的测试的影响。
可选地，通过以下方式确定异常的历史比例：
确定所述多个历史比例对应的标准差；
针对任一历史比例，若所述历史比例相对于所述多个历史比例的平均值的偏差大于所述标准差，则将所述历史比例确定为异常的历史比例。
上述技术方案中，由于多个历史比例对应的标准差反映了多个历史比例的离散程度，如果某一历史比例相对于多个历史比例的平均值的偏差大于上述标准差，说明该历史比例相对与该平均值的偏差较大，是多个历史比例中的离群点，因此将该历史比例确定为异常的历史比例。
可选地，根据所述目标比例、所述测试软件在拐点子周期的测试缺陷累计数量以及所述测试软件的拐点子周期在测试中的次序，确定所述测试软件在测试中目标子周期的目标缺陷数量，包括：
将所述测试软件在拐点子周期的测试缺陷累计数量与所述目标比例的比值确定为目标缺陷总数；
根据所述目标缺陷总数以及所述测试软件的拐点子周期在测试中的次序，确定拐点子周期的目标缺陷数量；和/或根据所述目标缺陷总数、所述测试软件的拐点子周期在测试中的次序以及所述测试软件除拐点子周期之外的其他目标子周期在测试中的次序，确定所述其他目标子周期的目标缺陷数量。
上述技术方案中，由于目标比例是当测试软件测试充分时，在拐点子周期的缺陷累计数量相对于缺陷总数的比例，因此确定测试软件在拐点子周期的测试缺陷累计数量与该目标比例的比值，就得到当测试软件测试充分时的目标缺陷总数；进而基于该目标缺陷总数以及拐点子周期在测试中的次序就能准确地确定当测试软件测试充分时，各目标子周期的目标缺陷数量，通过上述两种方式可提高目标缺陷数量确定的灵活性，进一步的，相比第一种方式由拐点子周期在测试中的次序确定拐点子周期的目标缺陷数量，第二种方式基于第一种方式再结合拐点子周期在测试中的次序以及所述测试软件除拐点子周期之外的其他目标子周期在测试中的次序，确定目标缺陷数量，可提高数据计算的全面性，降低误差，进一步提高目标缺陷数量确定的准确性。
可选地，若所述测试软件的拐点子周期的次序不是目标次序，则所述目标子周期包括所述测试软件的拐点子周期以及所述目标次序的子周期；若所述拐点子周期的次序是目标次序，则所述目标子周期包括所述测试软件的拐点子周期；
其中所述目标次序是根据所述测试软件在测试中的子周期总数以及第一预设比例确定的。
上述技术方案中，由于当测试软件测试充分时，在目标次序的子周期较为稳定；拐点子周期也是测试中的重要时期，因此，当测试软件的拐点子周期的次序不是目标次序时，目标子周期包括目标次序的子周期以及拐点子周期；当测试软件的拐点子周期的次序是目标次序时，拐点子周期就是目标次序的子周期，目标子周期只需包括拐点子周期。
可选地，根据比对结果确定所述测试软件是否测试充分，包括：
若所述测试软件在所述目标子周期的测试缺陷数量相对于对应目标缺陷数量的变化幅度，没有超过预设幅度，则确定所述测试软件测试充分。
上述技术方案中，由于当测试软件测试充分时，在目标子周期较为稳定，测试缺陷数量相对于对应目标缺陷数量的变化幅度不会过大，因此，测试软件在目标子周期的测试缺陷数量相对于对应目标缺陷数量的变化幅度，没有超过预设幅度，说明测试软件测试时在目标子周期较为稳定，可以较为准确地确定测试软件测试充分。
可选地，在确定所述测试软件测试充分之前，还包括：
确定所述测试软件在测试中的最后一个子周期的测试缺陷数量，相对于在测试中测试缺陷总数的比例没有超过第二预设比例。
上述技术方案中，由于当测试软件测试充分时，在测试的末期不会新增很多缺陷，因此，通过在确定测试软件测试充分之前，先确定测试软件在测试中的最后一个子周期的测试缺陷数量，相对于在测试中测试缺陷总数的比例没有超过第二预设比例，就能更加准确地确定测试软件测试充分。
第二方面，本申请实施例还提供了一种软件测试的评估装置，包括：
比例确定模块，用于根据测试软件所对应的多个历史版本软件的历史比例，确定所述测试软件的目标比例；其中，任一历史版本软件的历史比例为在对应的历史拐点子周期的测试缺陷累计数量相对于对应的历史测试中测试缺陷总数的比例；任一历史版本软件对应的历史拐点子周期，为所述历史版本软件在对应的历史测试的多个子周期中测试缺陷数量最多的子周期；
数量确定模块，用于根据所述目标比例、所述测试软件在拐点子周期的测试缺陷累计数量以及所述测试软件的拐点子周期在测试中的次序，确定所述测试软件在测试中目标子周期的目标缺陷数量；
评估模块，用于将所述测试软件在所述目标子周期的测试缺陷数量与对应的目标缺陷数量进行比对，根据比对结果确定所述测试软件是否测试充分。
第三方面，本申请实施例提供一种计算设备，包括至少一个处理器以及至少一个存储器，其中，所述存储器存储有计算机程序，当所述程序被所述处理器执行时，使得所述处理器执行上述第一方面任一所述的软件测试的评估方法。
第四方面，本申请实施例提供一种计算机可读存储介质，其存储有可由计算设备执行的计算机程序，当所述程序在所述计算设备上运行时，使得所述计算设备执行上述第一方面任一所述的软件测试的评估方法。
另外，第二至四方面中任一种实现方式所带来的技术效果可参见第一方面中不同实现方式所带来的技术效果，此处不再赘述。
附图说明
为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简要介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为本申请实施例提供的第一种软件测试的评估方法的流程示意图；
图2为本申请实施例提供的第二种软件测试的评估方法的流程示意图；
图3为本申请实施例提供的第一历史版本软件在对应历史测试中的缺陷分布示意图；
图4为本申请实施例提供的第二历史版本软件在对应历史测试中的缺陷分布示意图；
图5为本申请实施例提供的第三历史版本软件在对应历史测试中的缺陷分布示意图；
图6为本申请实施例提供的第四历史版本软件在对应历史测试中的缺陷分布示意图；
图7为本申请实施例提供的第五历史版本软件在对应历史测试中的缺陷分布示意图；
图8为本申请实施例提供的第三种软件测试的评估方法的流程示意图；
图9为本申请实施例提供的第四种软件测试的评估方法的流程示意图；
图10为本申请实施例提供的软件测试的评估装置的结构示意图；
图11为本申请实施例提供的计算设备的结构示意图。
具体实施方式
为了使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请作进一步地详细描述，显然，所描述的实施例仅仅是本申请的一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。
术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。在本申请的描述中，除非另有说明，“多个”的含义是两个或两个以上。
术语“测试缺陷数量”，是指在对应子周期内产生的缺陷的数量；
术语“测试缺陷累计数量”，是指在对应子周期内产生的缺陷的数量与在对应子周期之前产生的缺陷的数量之和；
术语“测试缺陷总数”，是指在对应测试中产生的所有缺陷的数量。
为了保证软件正常高效运行，需要对软件进行测试，以修复软件缺陷。如果软件没有充分测试，就无法较好的修复软件缺陷。可通过代码覆盖率来评估软件是否测试充分，但开发人员编写的代码受技术和经验的影响，所写代码可能无法完全覆盖到需求，测试人员根据已经存在疏漏的代码，无法精准地评估软件是否测试充分。
一些实施例中，通过为所有软件设定一个统一比例，该比例为当软件测试充分时，在拐点子周期的缺陷累计数量相对于缺陷总数的比例，进而根据该比例确定当软件测试充分时的缺陷分布，根据测试充分时的缺陷分布以及实际测试时的缺陷分布，来判断软件是否测试充分。
然而，不同项目的软件测试环境不同，有些项目的软件测试环境较为稳定，有些项目的软件的测试环境并不稳定；不同项目的软件测试人员不同，有些项目的软件测试人员经验丰富、测试能力较强，有些项目的软件测试人员缺乏经验、测试能力较差。因此不同项目的软件受测试环境、测试人员等因素的影响在测试过程中缺陷分布差异较大，难以精准地设定一个适合所有项目的软件的统一比例，因此，根据设定的统一比例，不能准确确定当软件测试充分时的缺陷分布。
鉴于此，本申请实施例提出一种软件测试的评估方法、装置、计算设备及存储介质，由于各软件与其历史版本软件关联性较大，即同一项目的软件在测试过程中缺陷分布较为相似，不同项目的软件受测试环境、测试人员等因素的影响在测试过程中缺陷分布差异较大。因此，根据测试软件所对应的多个历史版本软件的历史比例，就能确定出当该测试软件测试充分时，在拐点子周期的缺陷累计数量相对于缺陷总数的目标比例，进而根据该目标比例就能准确地确定当该测试软件测试充分时目标子周期的目标缺陷数量，根据在目标子周期的实际测试中的测试缺陷数量与对应的当测试充分时的目标缺陷数量的比对结果，就能精准地确定该测试软件是否测试充分。
下面将结合附图及具体实施例，对本申请的技术方案以及本申请的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。
本申请实施例提供第一种软件测试的评估方法，如图1所示，包括以下步骤：
步骤S101：根据测试软件所对应的多个历史版本软件的历史比例，确定所述测试软件的目标比例。
其中，任一历史版本软件的历史比例为在对应的历史拐点子周期的测试缺陷累计数量相对于对应的历史测试中测试缺陷总数的比例；任一历史版本软件对应的历史拐点子周期，为所述历史版本软件在对应的历史测试的多个子周期中测试缺陷数量最多的子周期。
本实施例，由于不同项目的软件受测试环境、测试人员等因素的影响，在测试过程中缺陷分布差异较大，难以精准地设定一个适合所有项目的软件的统一比例。而相同项目的软件(对于某一软件，与其对应的历史版本软件为相同项目的软件)，测试人员是相同的，测试环境也较为相似，因此，根据测试软件所对应的多个历史版本软件的历史比例，就能确定出当该测试软件测试充分时，在拐点子周期的缺陷累计数量相对于缺陷总数的目标比例。
步骤S102：根据所述目标比例、所述测试软件在拐点子周期的测试缺陷累计数量以及所述测试软件的拐点子周期在测试中的次序，确定所述测试软件在测试中目标子周期的目标缺陷数量。
上述测试软件对应的拐点子周期，是测试软件在测试的多个子周期中测试缺陷数量最多的子周期。
本实施例，在确定出当该测试软件测试充分时，在拐点子周期的缺陷累计数量相对于缺陷总数的目标比例，还需要基于该目标比例确定当该测试软件测试充分时目标子周期的目标缺陷数量。
步骤S103：将所述测试软件在所述目标子周期的测试缺陷数量与对应的目标缺陷数量进行比对，根据比对结果确定所述测试软件是否测试充分。
实施中，测试软件在目标子周期的测试缺陷数量，是测试中在目标子周期内实际产生的缺陷的数量；测试软件在目标子周期的目标缺陷数量，是当测试充分时在目标子周期内应该产生的缺陷的数量。因此，需要将这两个数量进行比对。一些具体的实施例中，测试缺陷数量相对于对应目标缺陷数量的变化幅度越小，就代表在目标子周期内实际产生的缺陷的数量与测试充分时应该产生的缺陷数量越接近，说明测试软件测试越充分。
上述技术方案中，由于各软件与其历史版本软件关联性较大，即同一项目的软件在测试过程中缺陷分布较为相似，不同项目的软件受测试环境、测试人员等因素的影响在测试过程中缺陷分布差异较大，因此，根据测试软件所对应的多个历史版本软件的历史比例，就能确定出当该测试软件测试充分时，在拐点子周期的缺陷累计数量相对于缺陷总数的目标比例，进而根据该目标比例就能准确地确定当该测试软件测试充分时目标子周期的目标缺陷数量，根据在目标子周期的实际测试中的测试缺陷数量与对应的当测试充分时的目标缺陷数量的比对结果，就能精准地确定该测试软件是否测试充分。
本申请实施例提供第二种软件测试的评估方法，如图2所示，包括以下步骤：
步骤S201：从测试软件所对应的多个历史版本软件的历史比例中过滤异常的历史比例。
如上所述，相同项目的软件，测试人员是相同的，测试环境也较为相似，根据测试软件所对应的多个历史版本软件的历史比例，就能较为准确地确定出当该测试软件测试充分时，在拐点子周期的缺陷累计数量相对于缺陷总数的目标比例。
然而，测试软件所对应的多个历史版本软件中，部分历史版本软件可能测试异常，这些历史版本软件在测试中的缺陷分布与其他历史版本软件在测试中的缺陷分布差异较大，这些历史版本软件就对应了异常的历史比例。
参阅图3-7所示，为与测试软件属于同一项目的五个历史版本软件在对应历史测试中的缺陷分布：
参阅图3所示，第一历史版本软件在对应历史测试中，历史拐点子周期为第9个周期，历史拐点子周期的测试缺陷累计数量为74，测试缺陷总数为100，第一历史版本软件的历史比例A1＝74/100＝0.74(74％)；
参阅图4所示，第二历史版本软件在对应历史测试中，历史拐点子周期为第4个周期，历史拐点子周期的测试缺陷累计数量为21，测试缺陷总数为29，第二历史版本软件的历史比例A2＝21/29＝0.724(72.4％)；
参阅图5所示，第三历史版本软件在对应历史测试中，历史拐点子周期为第3个周期，历史拐点子周期的测试缺陷累计数量为23，测试缺陷总数为32，第三历史版本软件的历史比例A3＝23/34＝0.676(67.6％)；
参阅图6所示，第四历史版本软件在对应历史测试中，历史拐点子周期为第3个周期，历史拐点子周期的测试缺陷累计数量为25，测试缺陷总数为32，第四历史版本软件的历史比例A4＝25/32＝0.781(78.1％)；
参阅图7所示，第五历史版本软件在对应历史测试中，历史拐点子周期为第2个周期，历史拐点子周期的测试缺陷累计数量为14，测试缺陷总数为50，第五历史版本软件的历史比例A5＝14/50＝0.28(28％)。
显然第五历史版本软件的历史比例与其他四个版本的历史比例差异较大，如果在确定目标比例时将异常的第五历史版本软件的历史比例也考虑进去，会影响目标比例的准确性。基于此，需要从测试软件所对应的多个历史版本软件的历史比例(以下简称多个历史比例)中过滤异常的历史比例。即过滤上述第五历史版本软件的历史比例，只考虑其他四个历史版本软件的历史比例。
一些可选的实施方式中，可通过以下方式确定异常的历史比例：
确定所述多个历史比例对应的标准差；
针对任一历史比例，若所述历史比例相对于所述多个历史比例的平均值的偏差大于所述标准差，则将所述历史比例确定为异常的历史比例。
还是以上述五个历史版本软件为例，对应的五个历史比例的平均值B1＝(0.74+0.724+0.676+0.781+0.28)/5＝0.6402；
标准差
确定A1相对于B1的偏差C1，C1＝|A1-B1|＝|0.74-0.6402|＜0.18；
确定A2相对于B1的偏差C2，C2＝|A2-B1|＝|0.724-0.6402|＜0.18；
确定A3相对于B1的偏差C3，C3＝|A3-B1|＝|0.676-0.6402|＜0.18；
确定A4相对于B1的偏差C4，C4＝|A4-B1|＝|0.781-0.6402|＜0.18；
确定A5相对于B1的偏差C5，C5＝|A5-B1|＝|0.28-0.6402|＞0.18。
通过上述方式确定A5(第五历史版本软件的历史比例)为异常的历史比例。
由于多个历史比例对应的标准差反映了多个历史比例的离散程度，如果某一历史比例相对于多个历史比例的平均值的偏差大于上述标准差，说明该历史比例相对与该平均值的偏差较大，是多个历史比例中的离群点，因此将该历史比例确定为异常的历史比例。
步骤S202：将过滤后的历史比例的平均值确定为所述目标比例。
本实施例，从上述多个历史比例中，过滤掉异常的历史比例后，基于过滤后的历史比例就可确定出减少了异常的测试的影响的目标比例。
还是以上述五个历史版本软件为例，从A1、A2、A3、A4以及A5中，过滤掉A5，将A1、A2、A3以及A4的平均值B2作为目标比例，B2＝(A1+A2+A3+A4)/4＝(0.74+0.724+0.676+0.781)/4＝0.73。
上述历史版本软件的数量、各历史版本软件的历史比例等参数均只是示例性说明，本申请对这些参数不做具体限定。
步骤S203：根据所述目标比例、所述测试软件在拐点子周期的测试缺陷累计数量以及所述测试软件的拐点子周期在测试中的次序，确定所述测试软件在测试中目标子周期的目标缺陷数量。
步骤S204：将所述测试软件在所述目标子周期的测试缺陷数量与对应的目标缺陷数量进行比对，根据比对结果确定所述测试软件是否测试充分。
该步骤S203-S204的具体实现方式可参照下述实施例，此处不再赘述。
上述技术方案中，由于多个历史版本软件中部分历史版本软件可能测试异常，这些历史版本软件在测试中的缺陷分布与其他历史版本软件在测试中的缺陷分布差异较大，这些历史版本软件就对应了异常的历史比例，因此通过从多个历史版本软件的历史比例过滤掉异常的历史比例，进而将过滤后的历史比例的平均值确定为目标比例，就减少了异常的测试的影响。
本申请实施例提供第三种软件测试的评估方法，如图8所示，包括以下步骤：
步骤S801：根据测试软件所对应的多个历史版本软件的历史比例，确定所述测试软件的目标比例。
其中，任一历史版本软件的历史比例为在对应的历史拐点子周期的测试缺陷累计数量相对于对应的历史测试中测试缺陷总数的比例；任一历史版本软件对应的历史拐点子周期，为所述历史版本软件在对应的历史测试的多个子周期中测试缺陷数量最多的子周期。
该步骤S801的具体实现方式可参照上述实施例，此处不再赘述。
步骤S802：将所述测试软件在拐点子周期的测试缺陷累计数量与所述目标比例的比值确定为目标缺陷总数。
实施中，由于目标比例是当测试软件测试充分时，在拐点子周期的缺陷累计数量相对于缺陷总数的比例，因此，测试软件在拐点子周期的测试缺陷累计数量与该目标比例的比值，就是当测试软件测试充分时应该产生的目标缺陷总数。
步骤S803：根据所述目标缺陷总数以及所述测试软件的拐点子周期在测试中的次序，确定拐点子周期的目标缺陷数量；和/或根据所述目标缺陷总数、所述测试软件的拐点子周期在测试中的次序以及所述测试软件除拐点子周期之外的其他目标子周期在测试中的次序，确定所述其他目标子周期的目标缺陷数量。
本实施例，在确定当测试软件测试充分时应该产生的目标缺陷总数后，基于该目标缺陷总数以及拐点子周期在测试中的次序就能准确地确定当测试软件测试充分时，在各子周期内应该产生的缺陷的数量。
由于当软件在测试充分时，通常在拐点子周期之前的子周期，缺陷数量依次呈增长趋势；拐点子周期的缺陷数量达到顶峰；在拐点子周期之后的子周期，缺陷数量依次呈下降趋势；最后一个子周期的缺陷数量趋近于0。因此，当软件在测试充分时，缺陷数量的分布符合瑞利分布。
基于此，一些具体的实施例中，可以通过瑞利分布公式，计算测试软件在测试充分时在各子周期的目标缺陷数量；或者直接通过瑞利分布公式，计算测试软件在测试充分时在目标子周期的目标缺陷数量。瑞利分布公式包括：累积分布函数以及概率密度函数。
上述累积分布函数为：F(ti)＝K*(1-e-(ti/c)*(ti/c))，
tm为拐点子周期在测试中的次序，ti为子周期i在测试中的次序，K为目标缺陷总数，F(ti)为当测试软件测试充分时在子周期i的目标缺陷累计数量。
上述概率密度函数为：f(ti)＝2*K*ti*(1/c)2*e-(ti/c)*(ti/c)，
tm为拐点子周期在测试中的次序，ti为子周期i在测试中的次序，K为目标缺陷总数，f(ti)为当测试软件测试充分时在子周期i的目标缺陷数量。
以测试软件在测试中共有10个子周期，测试软件的目标比例为0.73(73％)为例，在各子周期的测试缺陷数量如表1所示：
表1
| 次序 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 测试缺陷数量 | 1 | 8 | 7 | 8 | 2 | 14 | 3 | 8 | 11 | 1 |
拐点子周期为测试中的第6个子周期(次序为6)，测试软件在拐点子周期的测试缺陷累计数量为1+8+7+8+2+14＝40。当测试软件测试充分时的目标缺陷总数K＝40/73％＝55，
当测试软件测试充分时，第i个子周期的目标缺陷数量
将各子周期的次序代入上述公式中，即可得到表2所示的各子周期的目标缺陷数量：
表2
| 次序 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 目标缺陷数量 | 1.5 | 2.9 | 4 | 4.9 | 5.4 | 5.6 | 5.4 | 5 | 4.5 | 3.8 |
当然，在一些实施例中，也可以只计算目标子周期的目标缺陷数量，如第6个子周期、第7个子周期以及第10个子周期为目标子周期，只用计算出f(t6)、f(t7)以及f(t10)。
步骤S804：将所述测试软件在所述目标子周期的测试缺陷数量与对应的目标缺陷数量进行比对，根据比对结果确定所述测试软件是否测试充分。
该步骤S804的具体实现方式可参照下述实施例，此处不再赘述。
上述技术方案中，由于目标比例是当测试软件测试充分时，在拐点子周期的缺陷累计数量相对于缺陷总数的比例，因此确定测试软件在拐点子周期的测试缺陷累计数量与该目标比例的比值，就得到当测试软件测试充分时的目标缺陷总数；进而基于该目标缺陷总数以及拐点子周期在测试中的次序就能准确地确定当测试软件测试充分时，各目标子周期的目标缺陷数量。
本申请实施例提供第四种软件测试的评估方法，如图9所示，包括以下步骤：
步骤S901：根据测试软件所对应的多个历史版本软件的历史比例，确定所述测试软件的目标比例。
其中，任一历史版本软件的历史比例为在对应的历史拐点子周期的测试缺陷累计数量相对于对应的历史测试中测试缺陷总数的比例；任一历史版本软件对应的历史拐点子周期，为所述历史版本软件在对应的历史测试的多个子周期中测试缺陷数量最多的子周期。
步骤S902：根据所述目标比例、所述测试软件在拐点子周期的测试缺陷累计数量以及所述测试软件的拐点子周期在测试中的次序，确定所述测试软件在测试中目标子周期的目标缺陷数量。
实施中，可以根据实际应用场景确定上述目标子周期。由于当测试软件测试充分时，在测试的目标次序(如中后期)的子周期较为稳定，测试缺陷数量相对于对应目标缺陷数量的变化幅度不会过大；另外，拐点子周期也是测试中的重要时期。因此，上述目标子周期需要涵盖测试的目标次序(如中后期)的子周期，还需包括拐点子周期。
一些可选的实施方式中，根据测试软件在测试中的子周期总数以及第一预设比例确定目标次序，如将子周期总数以及第一预设比例的乘积作为目标次序，该目标次序表征了测试的中后期。还是以测试软件在测试中共有10个子周期为例，第一预设比例为2/3，10*(2/3)＝20/3≈6.67，由于目标次序是正整数，因此将7作为目标次序。
上述测试软件的拐点子周期的次序可能不是目标次序(拐点子周期的次序为6)，此时目标子周期包括拐点子周期(第6个子周期)以及目标次序的子周期(第7个子周期)；
上述测试软件的拐点子周期的次序可能就是目标次序，此时目标子周期包括拐点子周期(第7个子周期)。
步骤S903：若所述测试软件在所述目标子周期的测试缺陷数量相对于对应目标缺陷数量的变化幅度，没有超过预设幅度，则确定所述测试软件测试充分。
由于当测试软件测试充分时，在测试的末期不会产生很多缺陷。基于此，在一些可选的实施方式中，在确定测试软件测试充分之前，还需要确定测试软件在测试中的最后一个子周期的测试缺陷数量，相对于在测试中测试缺陷总数的比例没有超过第二预设比例。
上述预设幅度以及第二预设比例的具体值均可以根据实际应用场景设定，如预设幅度为30％(0.3)，第二预设比例为10％(0.1)。下面以两个具体的实施例进行说明：
1)参阅表3所示，为一种测试软件在各子周期的测试缺陷数量以及目标缺陷数量。测试软件在拐点子周期(第6个子周期)的测试缺陷数量为14，目标缺陷数量为5.6，对应的变化幅度D0＝|14-5.6|/5.6＝1.5＞0.3，超过预设幅度，就可以直接确定测试软件没有测试充分。
表3
| 次序 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 测试缺陷数量 | 1 | 8 | 7 | 8 | 2 | 14 | 3 | 8 | 11 | 1 |
| 目标缺陷数量 | 1.5 | 2.9 | 4 | 4.9 | 5.4 | 5.6 | 5.4 | 5 | 4.5 | 3.8 |
2)参阅表4所示，为另一种测试软件在各子周期的测试缺陷数量以及目标缺陷数量。测试软件在拐点子周期(第2个子周期)的测试缺陷数量为13，目标缺陷数量为10.61，对应的变化幅度D1＝|13-10.61|/10.61＝0.225＜0.3，没有超过预设幅度；
测试软件在目标次序的子周期(第4个子周期)的测试缺陷数量为6，目标缺陷数量为4.74，对应的变化幅度D2＝|6-4.74|/4.74＝0.269＜0.3，没有超过预设幅度；
测试软件在最后一个子周期(第6个子周期)的测试缺陷数量为1，测试中测试缺陷总数为37，在最后一个子周期的测试缺陷数量相对于测试缺陷总数的比例E＝1/37＝0.027＜0.1，没有超过第二预设比例。
确定测试软件测试充分。
表4
| 次序 | 1 | 2 | 3 | 4 | 5 | 6 |
| 测试缺陷数量 | 1 | 13 | 11 | 6 | 5 | 1 |
| 目标缺陷数量 | 7.72 | 10.61 | 8.52 | 4.74 | 1.92 | 0.58 |
上述两个具体的实施例只是示例性说明，本申请并不以此为限。
实施中，如果确定测试软件没有测试充分，需要调整测试资源，以保证软件的质量。
基于相同的发明构思，本申请实施例提供一种软件测试的评估装置，参阅图10所示，软件测试的评估装置1000包括：
比例确定模块1001，用于根据测试软件所对应的多个历史版本软件的历史比例，确定所述测试软件的目标比例；其中，任一历史版本软件的历史比例为在对应的历史拐点子周期的测试缺陷累计数量相对于对应的历史测试中测试缺陷总数的比例；任一历史版本软件对应的历史拐点子周期，为所述历史版本软件在对应的历史测试的多个子周期中测试缺陷数量最多的子周期；
数量确定模块1002，用于根据所述目标比例、所述测试软件在拐点子周期的测试缺陷累计数量以及所述测试软件的拐点子周期在测试中的次序，确定所述测试软件在测试中目标子周期的目标缺陷数量；
评估模块1003，用于将所述测试软件在所述目标子周期的测试缺陷数量与对应的目标缺陷数量进行比对，根据比对结果确定所述测试软件是否测试充分。
可选地，比例确定模块1001，具体用于：
从多个历史比例中过滤异常的历史比例；
将过滤后的历史比例的平均值确定为所述目标比例。
可选地，比例确定模块1001，还用于：
确定所述多个历史比例对应的标准差；
针对任一历史比例，若所述历史比例相对于所述多个历史比例的平均值的偏差大于所述标准差，则将所述历史比例确定为异常的历史比例。
可选地，数量确定模块1002，具体用于：
将所述测试软件在拐点子周期的测试缺陷累计数量与所述目标比例的比值确定为目标缺陷总数；
根据所述目标缺陷总数以及所述测试软件的拐点子周期在测试中的次序，确定拐点子周期的目标缺陷数量；和/或根据所述目标缺陷总数、所述测试软件的拐点子周期在测试中的次序以及所述测试软件除拐点子周期之外的其他目标子周期在测试中的次序，确定所述其他目标子周期的目标缺陷数量。
可选地，若所述测试软件的拐点子周期的次序不是目标次序，则所述目标子周期包括所述测试软件的拐点子周期以及所述目标次序的子周期；若所述拐点子周期的次序是目标次序，则所述目标子周期包括所述测试软件的拐点子周期；
其中所述目标次序是根据所述测试软件在测试中的子周期总数以及第一预设比例确定的。
可选地，评估模块1003，具体用于：
若所述测试软件在所述目标子周期的测试缺陷数量相对于对应目标缺陷数量的变化幅度，没有超过预设幅度，则确定所述测试软件测试充分。
可选地，评估模块1003在确定所述测试软件测试充分之前，还用于：
确定所述测试软件在测试中的最后一个子周期的测试缺陷数量，相对于在测试中测试缺陷总数的比例没有超过第二预设比例。
由于该装置即是本申请实施例中的方法中的装置，并且该装置解决问题的原理与该方法相似，因此该装置的实施可以参见方法的实施，重复之处不再赘述。
基于相同的技术构思，本申请实施例还提供了一种计算设备1100，如图11所示，包括至少一个处理器1101，以及与至少一个处理器连接的存储器1102，本申请实施例中不限定处理器1101与存储器1102之间的具体连接介质，图11中处理器1101和存储器1102之间通过总线1103连接为例。总线可以分为地址总线、数据总线、控制总线等。为便于表示，图11中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。
其中，处理器1101是计算设备的控制中心，可以利用各种接口和线路连接计算设备的各个部分，通过运行或执行存储在存储器1102内的指令以及调用存储在存储器1102内的数据，从而实现数据处理。可选的，处理器1101可包括一个或多个处理单元，处理器1101可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理下发指令。可以理解的是，上述调制解调处理器也可以不集成到处理器1101中。在一些实施例中，处理器1101和存储器1102可以在同一芯片上实现，在一些实施例中，它们也可以在独立的芯片上分别实现。
处理器1101可以是通用处理器，例如中央处理器(CPU)、数字信号处理器、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件，可以实现或者执行本申请实施例中公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者任何常规的处理器等。结合软件测试的评估方法实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。
存储器1102作为一种非易失性计算机可读存储介质，可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块。存储器1102可以包括至少一种类型的存储介质，例如可以包括闪存、硬盘、多媒体卡、卡型存储器、随机访问存储器(Random AccessMemory，RAM)、静态随机访问存储器(Static Random Access Memory，SRAM)、可编程只读存储器(Programmable Read Only Memory，PROM)、只读存储器(Read Only Memory，ROM)、带电可擦除可编程只读存储器(Electrically Erasable Programmable Read-Only Memory，EEPROM)、磁性存储器、磁盘、光盘等等。存储器1102是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。本申请实施例中的存储器1102还可以是电路或者其它任意能够实现存储功能的装置，用于存储程序指令和/或数据。
在本申请实施例中，存储器1102存储有计算机程序，当该程序被处理器1101执行时，使得处理器1101执行：
根据测试软件所对应的多个历史版本软件的历史比例，确定所述测试软件的目标比例；其中，任一历史版本软件的历史比例为在对应的历史拐点子周期的测试缺陷累计数量相对于对应的历史测试中测试缺陷总数的比例；任一历史版本软件对应的历史拐点子周期，为所述历史版本软件在对应的历史测试的多个子周期中测试缺陷数量最多的子周期；
根据所述目标比例、所述测试软件在拐点子周期的测试缺陷累计数量以及所述测试软件的拐点子周期在测试中的次序，确定所述测试软件在测试中目标子周期的目标缺陷数量；
将所述测试软件在所述目标子周期的测试缺陷数量与对应的目标缺陷数量进行比对，根据比对结果确定所述测试软件是否测试充分。
可选地，所述处理器1101具体用于：
从多个历史比例中过滤异常的历史比例；
将过滤后的历史比例的平均值确定为所述目标比例。
可选地，所述处理器1101还用于：
确定所述多个历史比例对应的标准差；
针对任一历史比例，若所述历史比例相对于所述多个历史比例的平均值的偏差大于所述标准差，则将所述历史比例确定为异常的历史比例。
可选地，所述处理器1101具体用于：
将所述测试软件在拐点子周期的测试缺陷累计数量与所述目标比例的比值确定为目标缺陷总数；
根据所述目标缺陷总数以及所述测试软件的拐点子周期在测试中的次序，确定拐点子周期的目标缺陷数量；和/或根据所述目标缺陷总数、所述测试软件的拐点子周期在测试中的次序以及所述测试软件除拐点子周期之外的其他目标子周期在测试中的次序，确定所述其他目标子周期的目标缺陷数量。
可选地，若所述测试软件的拐点子周期的次序不是目标次序，则所述目标子周期包括所述测试软件的拐点子周期以及所述目标次序的子周期；若所述拐点子周期的次序是目标次序，则所述目标子周期包括所述测试软件的拐点子周期；
其中所述目标次序是根据所述测试软件在测试中的子周期总数以及第一预设比例确定的。
可选地，所述处理器1101具体用于：
若所述测试软件在所述目标子周期的测试缺陷数量相对于对应目标缺陷数量的变化幅度，没有超过预设幅度，则确定所述测试软件测试充分。
可选地，所述处理器1101在确定所述测试软件测试充分之前，还用于：
确定所述测试软件在测试中的最后一个子周期的测试缺陷数量，相对于在测试中测试缺陷总数的比例没有超过第二预设比例。
由于该计算设备即是本申请实施例中的方法中的计算设备，并且该计算设备解决问题的原理与该方法相似，因此该计算设备的实施可以参见方法的实施，重复之处不再赘述。
基于相同的技术构思，本申请实施例还提供了一种计算机可读存储介质，其存储有可由计算设备执行的计算机程序，当所述程序在所述计算设备上运行时，使得所述计算设备执行上述软件测试的评估方法的步骤。
本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本申请是参照根据本申请的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。
显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。
Claims (10)
1.一种软件测试的评估方法，其特征在于，该方法包括：
根据测试软件所对应的多个历史版本软件的历史比例，确定所述测试软件的目标比例；其中，任一历史版本软件的历史比例为在对应的历史拐点子周期的测试缺陷累计数量相对于对应的历史测试中测试缺陷总数的比例；任一历史版本软件对应的历史拐点子周期，为所述历史版本软件在对应的历史测试的多个子周期中测试缺陷数量最多的子周期；
根据所述目标比例、所述测试软件在拐点子周期的测试缺陷累计数量以及所述测试软件的拐点子周期在测试中的次序，确定所述测试软件在测试中目标子周期的目标缺陷数量；
将所述测试软件在所述目标子周期的测试缺陷数量与对应的目标缺陷数量进行比对，根据比对结果确定所述测试软件是否测试充分。
2.如权利要求1所述的方法，其特征在于，根据测试软件所对应的多个历史版本软件的历史比例，确定所述测试软件的目标比例，包括：
从多个历史比例中过滤异常的历史比例；
将过滤后的历史比例的平均值确定为所述目标比例。
3.如权利要求2所述的方法，其特征在于，通过以下方式确定异常的历史比例：
确定所述多个历史比例对应的标准差；
针对任一历史比例，若所述历史比例相对于所述多个历史比例的平均值的偏差大于所述标准差，则将所述历史比例确定为异常的历史比例。
4.如权利要求1所述的方法，其特征在于，根据所述目标比例、所述测试软件在拐点子周期的测试缺陷累计数量以及所述测试软件的拐点子周期在测试中的次序，确定所述测试软件在测试中目标子周期的目标缺陷数量，包括：
将所述测试软件在拐点子周期的测试缺陷累计数量与所述目标比例的比值确定为目标缺陷总数；
根据所述目标缺陷总数以及所述测试软件的拐点子周期在测试中的次序，确定拐点子周期的目标缺陷数量；和/或根据所述目标缺陷总数、所述测试软件的拐点子周期在测试中的次序以及所述测试软件除拐点子周期之外的其他目标子周期在测试中的次序，确定所述其他目标子周期的目标缺陷数量。
5.如权利要求1所述的方法，其特征在于，若所述测试软件的拐点子周期的次序不是目标次序，则所述目标子周期包括所述测试软件的拐点子周期以及所述目标次序的子周期；若所述拐点子周期的次序是目标次序，则所述目标子周期包括所述测试软件的拐点子周期；
其中，所述目标次序是根据所述测试软件在测试中的子周期总数以及第一预设比例确定的。
6.如权利要求1-5任一项所述的方法，其特征在于，根据比对结果确定所述测试软件是否测试充分，包括：
若所述测试软件在所述目标子周期的测试缺陷数量相对于对应目标缺陷数量的变化幅度，没有超过预设幅度，则确定所述测试软件测试充分。
7.如权利要求6所述的方法，其特征在于，在确定所述测试软件测试充分之前，还包括：
确定所述测试软件在测试中的最后一个子周期的测试缺陷数量，相对于在测试中测试缺陷总数的比例没有超过第二预设比例。
8.一种软件测试的评估装置，其特征在于，包括：
比例确定模块，用于根据测试软件所对应的多个历史版本软件的历史比例，确定所述测试软件的目标比例；其中，任一历史版本软件的历史比例为在对应的历史拐点子周期的测试缺陷累计数量相对于对应的历史测试中测试缺陷总数的比例；任一历史版本软件对应的历史拐点子周期，为所述历史版本软件在对应的历史测试的多个子周期中测试缺陷数量最多的子周期；
数量确定模块，用于根据所述目标比例、所述测试软件在拐点子周期的测试缺陷累计数量以及所述测试软件的拐点子周期在测试中的次序，确定所述测试软件在测试中目标子周期的目标缺陷数量；
评估模块，用于将所述测试软件在所述目标子周期的测试缺陷数量与对应的目标缺陷数量进行比对，根据比对结果确定所述测试软件是否测试充分。
9.一种计算设备，其特征在于，包括至少一个处理器以及至少一个存储器，其中，所述存储器存储有计算机程序，当所述程序被所述处理器执行时，使得所述处理器执行权利要求1至7任一所述的方法。
10.一种计算机可读存储介质，其特征在于，其存储有可由计算设备执行的计算机程序，当所述程序在所述计算设备上运行时，使得所述计算设备执行权利要求1至7任一所述的方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110724104.7A CN113342676A (zh) | 2021-06-29 | 2021-06-29 | 一种软件测试的评估方法、装置、计算设备及存储介质 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110724104.7A CN113342676A (zh) | 2021-06-29 | 2021-06-29 | 一种软件测试的评估方法、装置、计算设备及存储介质 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN113342676A true CN113342676A (zh) | 2021-09-03 |
Family
ID=77481275
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110724104.7A Pending CN113342676A (zh) | 2021-06-29 | 2021-06-29 | 一种软件测试的评估方法、装置、计算设备及存储介质 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113342676A (zh) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114779058A (zh) * | 2022-06-23 | 2022-07-22 | 联宝(合肥)电子科技有限公司 | 动态调整测项比例的主板检测方法、装置、设备及介质 |
-
2021
- 2021-06-29 CN CN202110724104.7A patent/CN113342676A/zh active Pending
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114779058A (zh) * | 2022-06-23 | 2022-07-22 | 联宝(合肥)电子科技有限公司 | 动态调整测项比例的主板检测方法、装置、设备及介质 |
| CN114779058B (zh) * | 2022-06-23 | 2022-09-23 | 联宝(合肥)电子科技有限公司 | 动态调整测项比例的主板检测方法、装置、设备及介质 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN107885656B (zh) | 产品算法自动化测试方法及应用服务器 | |
| CN109643271B (zh) | 识别不稳定测试 | |
| CN111124921B (zh) | 内存越界的检测方法、装置、设备和存储介质 | |
| CN113342676A (zh) | 一种软件测试的评估方法、装置、计算设备及存储介质 | |
| CN115470141A (zh) | 一种故障模拟方法、装置及相关设备 | |
| CN115794570A (zh) | 压力测试方法、装置、设备及计算机可读存储介质 | |
| CN113360389A (zh) | 一种性能测试方法、装置、设备及存储介质 | |
| CN113127331A (zh) | 一种基于故障注入的测试方法、装置及计算机设备 | |
| CN116150020A (zh) | 一种测试用例的转换方法及装置 | |
| CN113360402B (zh) | 一种测试方法、电子设备、芯片和存储介质 | |
| CN106250309A (zh) | 一种内存压力变化测试方法及装置 | |
| CN113704871B (zh) | 车轮弯曲疲劳的确定方法、装置、终端设备及介质 | |
| CN115269389A (zh) | 一种项目质量确定方法、装置、电子设备及存储介质 | |
| CN112035364B (zh) | 功能测试结果评估方法及装置 | |
| US10330728B2 (en) | Method and apparatus for obtaining a maximally compressed verification test set | |
| CN108628750B (zh) | 一种测试代码处理方法及装置 | |
| CN111427620A (zh) | 嵌入式系统的启动方法及装置 | |
| CN112463577B (zh) | 一种用于样本数据的处理方法、装置及电子设备 | |
| CN110928765A (zh) | 一种链路测试方法及装置 | |
| CN109242442A (zh) | 任务监测方法、装置、电子设备及计算机可读存储介质 | |
| CN112650679B (zh) | 一种测试校验方法、装置及计算机系统 | |
| CN116594862B (zh) | Dbms的测试方法、装置、电子设备及可读存储介质 | |
| US11061745B2 (en) | Shared resource analysis for embedded multi-core systems | |
| CN110309158B (zh) | 日志文件的滚动异常判断方法、装置及可读介质 | |
| CN116501587A (zh) | 数据处理方法、装置、电子设备及存储介质 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |